-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathatom.xml
73 lines (41 loc) · 22.5 KB
/
atom.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Huangjian's Blog</title>
<subtitle>Record</subtitle>
<link href="/atom.xml" rel="self"/>
<link href="http://imhjnju.github.io/"/>
<updated>2021-06-10T04:46:06.475Z</updated>
<id>http://imhjnju.github.io/</id>
<author>
<name>Jian Huang</name>
</author>
<generator uri="https://hexo.io/">Hexo</generator>
<entry>
<title>GCN hardware summary</title>
<link href="http://imhjnju.github.io/2021/06/10/GCN%E6%96%87%E7%AB%A0%E6%80%BB%E7%BB%93/"/>
<id>http://imhjnju.github.io/2021/06/10/GCN%E6%96%87%E7%AB%A0%E6%80%BB%E7%BB%93/</id>
<published>2021-06-10T04:37:57.944Z</published>
<updated>2021-06-10T04:46:06.475Z</updated>
<content type="html"><![CDATA[<h1 id="GCN文章总结"><a href="#GCN文章总结" class="headerlink" title="GCN文章总结"></a>GCN文章总结</h1><p>有没有可能出现新的数据压缩方式适配GCN的处理模式</p><p>[TOC]</p><h2 id="UWB-GCN-Hardware-Acceleration-of-Graph-Convolution-Network-through-Runtime-Workload-Rebalancing"><a href="#UWB-GCN-Hardware-Acceleration-of-Graph-Convolution-Network-through-Runtime-Workload-Rebalancing" class="headerlink" title="UWB-GCN: Hardware Acceleration of Graph-Convolution-Network through Runtime Workload Rebalancing"></a>UWB-GCN: Hardware Acceleration of Graph-Convolution-Network through Runtime Workload Rebalancing</h2><p>最早的一篇文章，提出了GCN推理加速的一个最早的设计。主要关注点在数据稀疏以及load balance。</p><p>首先是baseline 设计：这个设计也是最早的GCN加速器，然后在baseline的基础上进行workload rebalancing.成为最终设计。</p><p>首先在计算模式上，先计算AXW的时候分为两种方式，(AX)W或者A(XW),由于不同的稀疏度，A十分稀疏，X一般稀疏，W比较密集，这里选用A(XW)的计算模式，这样两步计算中都会是SPMM(Sparse Dense Matrix Multiplication), 计算workload会比较小。</p><p>SPMM具体的计算方式：由$A\times B = C$变换得到：</p><p>$C=\left[\sum_{j=0}^{n-1} A_{j} b_{(j, 0)}, \sum_{j=0}^{n-1} A_{j} b_{(j, 1)}, \ldots, \sum_{j=0}^{n-1} A_{j} b_{(j, k-1)}\right]$</p><p>具象表示：()</p><p><img src="https://cdn.mathpix.com/snip/images/73Z0zKGCsY6aOjs93Y-3yMjGQXs1VjxE_QduuGGocGI.original.fullsize.png" alt=""></p><p>workload的分配，在假设数据按照行均匀分布的前提下，每两行的数据(3个非0数据)分配到一个PE。</p><p>并行化处理的一个划分:</p><p><img src="https://cdn.mathpix.com/snip/images/KkpKMxOgRSUxBqCDWiCPbZvKNQHS017mS62tcmuC-uQ.original.fullsize.png" alt=""></p><p>同时他这个一次处理一列带来的效果是：</p><ol><li>很好地提高并行度，可以流水线操作，一次一列交替执行。</li><li>减少片上存储，不需要同时存储整个图，而只需要其中的一列。</li></ol><p>主要的架构设计如下：</p><p><img src="https://gitee.com/imhjnju/imagebed/raw/master/o-VEq8_dTnu3-HJQEFWklc98NqqWzvUQ3nqytM4sTUs.original.fullsize.png" alt=""></p><p>主要包含以下几个部分：</p><ul><li><p>sparse-matrix-memory (SP-MMeM)</p><p> SPMMeM buffers the input sparse matrix A</p></li><li><p>dense-column-memory (DCM)</p><p>DCM buffers the input dense matrix B .</p></li><li><p>task-distributor & Queue (TDQ)</p></li><li><p>PE-array</p></li><li><p>accumulation-buffers-array (ACC).<br>ACC buffers the partial results of the resulting matrix C for accumulation.</p></li></ul><p>其中根据稀疏程度TDQ分为两类，在通常稀疏的时候(50%左右)，为TDQ1，上图左边。在十分稀疏的时候（90%以上）为TDQ2。</p><p>TDQ2采用多级Omega路由网络，同时考虑到MAC可能需要多个周期进行计算，可能会产生RaW冒险，因此两者都配备RaW检查其和Stall Buffer，其处理思路类似于处理器中的scoreboard。</p><p>主要的处理顺序是：</p><ol><li>首先计算$X\times W$的时候，是一个一般稀疏矩阵跟密集矩阵相乘，使用TDQ1。</li><li>$X\times W$计算的结果中，每计算好一列就可以送到下一个计算序列中，也就是$A\times (X \times W)$这个时候A是极度稀疏矩阵，采用TDQ2进行分发。</li></ol><p>由于以上处理方式是建立在load balance的基础上，现在作者主要解决的问题是load imbalance。其中有两种主要的imbalance方式,如下图所示：</p><p><img src="https://cdn.mathpix.com/snip/images/AzyPnUi5h-orohH1G2tqpo0tVKCCdadrwx17C0PsX9s.original.fullsize.png" alt=""></p><ul><li>Local imbalance 主要是相邻的两行之间会有跳跃，也就是波动。</li><li>Remote imbalance 或者可以说波动的特别大，集中在某些特殊行</li></ul><p>两者的稀疏统计直方图可以显示如下：</p><p><img src="https://cdn.mathpix.com/snip/images/wsvoKxoP7T46M0-glR-H550-c6xyGmi2yyWO9f2oN9M.original.fullsize.png" alt=""></p><p>为此作者进一步改善，提出两种方式解决这个不平衡问题：</p><ol><li><p>Dynamic Local Sharing</p><p>因为这个解决的思路就是将一个比较多的区域平均分到邻域，这也是无法处理Remote Imbalance的原因，</p></li><li><p>Dynamic Remote Switching</p><p>Remote Imbalance的这个因素需要提前调整一下，加上一个switch操作也就是将特别密集的图调整到其他空白的区域，由此形成local imbalance，进而可以使用上一种方式进一步调整。</p></li></ol><p>过程如下：</p><img src="https://cdn.mathpix.com/snip/images/neW0p19BeM0abDANS04aSUTarY_oSOv8KWhwiR0A1H4.original.fullsize.png" style="zoom:50%;" /><h2 id="HyGCN-A-GCN-Accelerator-with-Hybrid-Architecture"><a href="#HyGCN-A-GCN-Accelerator-with-Hybrid-Architecture" class="headerlink" title="HyGCN: A GCN Accelerator with Hybrid Architecture"></a>HyGCN: A GCN Accelerator with Hybrid Architecture</h2><p>主要点是在GCN的推理阶段，分成两个阶段专门进行优化，一个是Aggregation，另一个是Combine，这两个阶段可以以流水线方式执行。</p><p>首先是在Aggregation，一个节点的邻节点(相隔k个元素，k一般为1,2.)会将他自己的feature聚集给这个节点，这一部分的数据往往是依赖于图的结构，非常irregular和dynamic。而在Combine阶段，则主要执行MLP(Multi-Layer Multiplication )操作,也就是CNN中的全连接操作。主要进行矩阵向量相乘。这部分数据模式是static和regular的，与Aggregation完全相反。</p><p>从并行度角度出发：</p><ol><li>feature vector 长度更长且多变，可以实现更好的intra-vertex parallalism.</li><li>GCN中参数可以共享，进而可以在Combination阶段实现inter-vertex parallelism.</li></ol><p>整体架构：</p><p><img src="https://cdn.mathpix.com/snip/images/BLfBbCkkBCG0hgeeODnLzIDOfAR_e_tOfq8CJjbV7Os.original.fullsize.png" alt=""></p><p>分为四大块：</p><ul><li>Aggregation Engine</li><li>Combination Engine</li><li>Coordinator</li><li>Memory Access Handler</li></ul><h3 id="Aggregation-Engine"><a href="#Aggregation-Engine" class="headerlink" title="Aggregation Engine"></a>Aggregation Engine</h3><ul><li><p>interval shade graph partitioning</p><p>通过数据复用来减少数据的不规律性。</p></li><li><p>window sliding-shrinking methods</p><p>利用稀疏特性来减少数据访存。</p></li></ul><p>这一部分主要是因为Aggregation阶段数据极度不规律已经动态变化，在DRAM中的读取比较杂乱，数据读取耗能大。</p><ul><li><p>使用了gather-based methods</p><p>相比scatter-based methods，这一方法主要是在同步耗能更少。然后结合Edge-Centric PM来增加并行度处理。</p></li><li><p>vertex-disperse processing mode</p><p>相比vertex-concentrated，一个顶点的工作负载都分配给单独的SIMD core。这样的方式延迟大同时负载不均衡，效率低以及浪费了并行度。因此选用vertex disperse。<img src="https://cdn.mathpix.com/snip/images/7OTNaWWBh-u9FvdDfuaK-Cmd78_Ey06JOlGJ_BpudzE.original.fullsize.png" alt=""></p></li><li><p>图划分和稀疏减少</p><p><img src="https://cdn.mathpix.com/snip/images/fX-iKsW8P8TkRozaMmWbW9u3ZICQd8uvv5nPL3xOefM.original.fullsize.png" alt=""></p></li></ul><p>这一部分主要是包括图a的划分，然后进行滑窗操作（顶行对应有数据的地方）然后进行window shrinking(底行回缩到有数据的地方)</p><h3 id="Combine-Engine"><a href="#Combine-Engine" class="headerlink" title="Combine Engine"></a>Combine Engine</h3><ul><li>Multi granular systolic array </li><li>复用参数</li></ul><p>这一部分数据比较规律，主要问题是不同线程之间数据复用和同步耗时长。</p><ul><li>然后使用MVM-Centric PM 来并行处理MVM计算。</li></ul><p>提出了两种模式： </p><p><img src="https://cdn.mathpix.com/snip/images/CGf96hohnoGeIaNdSRiunzbtj0Xofshs4KUM1f4kBKk.original.fullsize.png" alt=""></p><ul><li><p>Independent Working Mode</p><p>图a这种方式对应了低延时，</p></li><li><p>Cooperative Working Mode</p><p>图b这种方式对应了低能耗</p></li></ul><h3 id="Coordinator"><a href="#Coordinator" class="headerlink" title="Coordinator"></a>Coordinator</h3><p>这一设计主要在优化从DRAM中的读取，最开始是混乱的读取，数据地址不规律，不利用cache等发挥作用。</p><p><img src="https://cdn.mathpix.com/snip/images/e2KfewzDTZhEC_90zdvkD0_HIxGkTbrmd8Z6CTSAw44.original.fullsize.png" alt=""></p><p> 将顺序更改为：</p><p> edges > input features > weights > output features</p><p>不过这个不跨越batch，也就是后面的batch里高优先级数据不比当前batch里低优先级的数据提前。</p><h2 id="GraphACT-Accelerating-GCN-Training-on-CPU-FPGA-Heterogeneous-Platforms"><a href="#GraphACT-Accelerating-GCN-Training-on-CPU-FPGA-Heterogeneous-Platforms" class="headerlink" title="GraphACT: Accelerating GCN Training on CPU-FPGA Heterogeneous Platforms"></a>GraphACT: Accelerating GCN Training on CPU-FPGA Heterogeneous Platforms</h2><p>这文章的专注点不同于上两篇文章，这个是在进行训练加速，以上两者是在推理阶段的加速。</p><p>核心思想是：</p><ol><li><p>算法</p><p>算法选择上是在选择合适的算法，其能够得到合适的minibatch, 资源上能够适配BRAM，作者总结了三类算法：</p><ul><li><p>Minibatch by sampling GCN layers</p><p>最后一层抽取b个nodes，前一层抽取a·b个nodes，第一层抽取 $a^L \times b$个nodes</p></li><li><p>Minibatch by sampling training graph</p><p>直接从图中抽样，抽样的图更小</p></li><li><p>Remark on notation</p></li></ul><p>最后通过比较computation to communication ratio得到一个合适的训练算法：</p><p>H. Zeng, H. Zhou, A. Srivastava, R. Kannan, and V. Prasanna. 2019. Accurate, Efficient and Scalable Graph Embedding. In 2019 IEEE International Parallel and Distributed Processing Symposium (IPDPS). 462–471. <a href="https://doi.org/10.1109/IPDPS.2019.00056" target="_blank" rel="noopener">https://doi.org/10.1109/IPDPS.2019.00056</a></p></li><li><p>消除冗余(有点类似VLSI课程里算法强度缩减)</p><p>消除冗余核心思想是提前计算后面复用较高的单元，根据图的特性有一些具体的算法，这里没有细看。</p></li><li><p>并行化加速</p></li></ol><p>架构设计：</p><p><img src="https://cdn.mathpix.com/snip/images/BK-OX_b8t1Fp2_g9HP3EUXL_NIEdP8tryTFvUT5d2QM.original.fullsize.png" alt=""></p><ul><li>CPU performs graph sampling, and then converts Gs to Gs，softmax loss ; FPGA performs the forward and backward pass.</li><li>通过合适的参数配置，一些图数据在读取到BRAM之后就能够供FPGA一直使用从第一层计算到最后一层。</li><li>分为两大块，Feature Aggregation Module & Weight Transformation Module</li></ul><p>CPU和FPGA之间的调度：</p><img src="https://cdn.mathpix.com/snip/images/xG34ghELqfTV3cf_pQ8e4aEI8at_YVIQgaU4STE5nu0.original.fullsize.png" style="zoom:50%;" />]]></content>
<summary type="html">
<h1 id="GCN文章总结"><a href="#GCN文章总结" class="headerlink" title="GCN文章总结"></a>GCN文章总结</h1><p>有没有可能出现新的数据压缩方式适配GCN的处理模式</p>
<p>[TOC]</p>
<h2 id=
</summary>
<category term="Tech" scheme="http://imhjnju.github.io/categories/Tech/"/>
<category term="IC" scheme="http://imhjnju.github.io/tags/IC/"/>
</entry>
<entry>
<title>Eyeriss Notes</title>
<link href="http://imhjnju.github.io/2020/04/24/Eyeriss/"/>
<id>http://imhjnju.github.io/2020/04/24/Eyeriss/</id>
<published>2020-04-24T08:34:13.446Z</published>
<updated>2021-06-05T02:06:30.880Z</updated>
<content type="html"><![CDATA[<h1 id="Eyeriss"><a href="#Eyeriss" class="headerlink" title="Eyeriss"></a>Eyeriss</h1><h2 id="system-architecture"><a href="#system-architecture" class="headerlink" title="system architecture"></a>system architecture</h2><p><img src="https://gitee.com/imhjnju/imagebed/raw/master/image-20210605100246725.png" alt="image-20210605100246725"></p><p><strong><em>工作流程：</em></strong></p><p> Eyeriss只运行的DNN的<strong>推理(inference)</strong>阶段，不做训练。</p><ol><li>接受配置流(图中Configuration Bits，1794 b)，配置计算模式(卷积核大小，步长；输入大小与维度；输出大小与维度)</li><li>从DRAM中读取数据，计算一层结果，(一层都计算完之后)将结果写回到DRAM</li><li>回到1，重新配置下一层结果</li></ol><h3 id="on-chip"><a href="#on-chip" class="headerlink" title="on-chip"></a>on-chip</h3><p>两个时钟域，分开独立工作：</p><ol><li><p>Core Clock</p><p>核心的计算单元，在这里运行计算部分，主要包含以下几个部分：</p><ol><li><p>数据编码解码</p><p>Eyeriss-v1采用RLC编码(游程编码)，V2采用CSR编码。这种数据压缩表示能够1. 减少存储空间 2. 降低传输数据量，提升传输速度。特别是数据在ReLU之后，数据中有比较多的0，这种编码方式能极大提升效率。</p></li><li><p>Global Buffer(108 KB)</p><p>Eyeriss片上一次能够计算一层，因此需要这些一个比较大的存储空间，当filter，ifmap等数据从DRAM中读取之后，先存储到Global Buffer(存储介质为SRAM)中，SRAM相比DRAM，数据读取能耗更小。</p></li><li><p>PE array(计算单元阵列)</p><p>这里是12<em>14的计算阵列，一个PE中完成一个1-D的卷积运算，PE之间通过*</em>NoC** communicate，每一个PE还有一个local的存储叫<strong>spads</strong>(scratch pads)。详细信息见后。</p></li></ol></li><li><p>Link Clock</p><p>这一部分主要就是控制数据的传输，时钟独立于计算单元。</p></li></ol><h3 id="off-chip"><a href="#off-chip" class="headerlink" title="off-chip"></a>off-chip</h3><p>主要就是DRAM，从DRAM中读取数据，一层都计算完之后将结果写回到DRAM，与片上之间有一个异步的FIFO中间层。</p><p>整个系统的4级存储hierarchy((由大到小)：</p><p><strong>DRAM， GLB，inter-PE communication，spads</strong></p><p>Eyeriss的主要两部分工作：</p><ol><li>通过数据复用(data reuse)来减少数据流动。</li><li>压缩数据，减少存储与传输。</li></ol><p>对应图中结构就是，<strong>PE来实现数据复用</strong>，<strong>编解码部分来压缩数据</strong>。</p><h2 id="PE-array"><a href="#PE-array" class="headerlink" title="PE array"></a>PE array</h2><h3 id="1-D-Convolution-Primitive-in-a-PE"><a href="#1-D-Convolution-Primitive-in-a-PE" class="headerlink" title="1-D Convolution Primitive in a PE"></a>1-D Convolution Primitive in a PE</h3><p>每一个PE计算1-D卷积，filter，ifmap，和psum都可以存储在PE中的spads，不需要数据流动：需要存储的大小为：</p><table><thead><tr><th align="center">type</th><th align="center">size</th></tr></thead><tbody><tr><td align="center">filter</td><td align="center">S(卷积核一行中的元素个数)</td></tr><tr><td align="center">ifmap</td><td align="center">S</td></tr><tr><td align="center">psum</td><td align="center">1</td></tr></tbody></table><p>1-D卷积如下所示：</p><p><img src="https://gitee.com/imhjnju/imagebed/raw/master/image-20210605100316253.png" alt="image-20210605100316253"></p><p>这里图示只是在说明一般的1-D卷积。图示计算模式会分给3个PE来计算，也就是按照右边的划分方式分成3组。</p><h3 id="Row-Stationary"><a href="#Row-Stationary" class="headerlink" title="Row-Stationary"></a>Row-Stationary</h3><p>在2-D的计算模式中：一个卷积核行数为3，ifmap行数为5的计算过程如下：</p><p><img src="https://gitee.com/imhjnju/imagebed/raw/master/image-20210605100342808.png" alt="image-20210605100342808"></p><p>运算模式如下：</p><table><thead><tr><th>cycle</th><th>filter</th><th>ifmap</th><th>compute</th></tr></thead><tbody><tr><td>0</td><td>row1-> PE1,1 PE1,2 PE1,3</td><td>row1->PE1,1</td><td>PE1,1</td></tr><tr><td>1</td><td>row2-> PE2,1 PE2,2 PE2,3</td><td>row2->PE2,1 PE1,2</td><td>PE2,1 PE1,2</td></tr><tr><td>2</td><td>row3-> PE3,1 PE3,2 PE3,3</td><td>row3 -> PE3,1 PE2,2 PE1,3</td><td>PE3,1 PE,2,2 PE1,3</td></tr><tr><td>3</td><td></td><td>row4 -> PE3,2 PE2,3</td><td>PE3,2 PE2,3</td></tr><tr><td>4</td><td></td><td>row5-> PE3,3</td><td>PE3,3</td></tr></tbody></table><p>按照这样理解，感觉PSUM箭头的方向是反的？在cycle 0是计算PE1,1，然后结果给PE2,1？</p><h3 id="PE-sets-logical-mapping"><a href="#PE-sets-logical-mapping" class="headerlink" title="PE sets(logical mapping)"></a>PE sets(logical mapping)</h3><p>在PE sets设计中，一个卷积核大小和R S，ofmap大小为E F，需要的PE sets为$R\times E$</p><p>也就是PE sets的行数为卷积核大小，列数为ofmap的行数。</p><h3 id="physical-mapping"><a href="#physical-mapping" class="headerlink" title="physical mapping"></a>physical mapping</h3><p>由于PE array的大小固定，不一定适配PE sets的大小，因此需要调整PE sets，进而能够放到PE array中进行计算。</p><ul><li><p>PE sets大小超过168(12*14的)</p><p>就将分割行数，一次处理e行，e < E。</p></li><li><p>PE sets宽度大于12的，长度大于14，但是总大小不超过168的</p><p>调整合并到一个PE array中。</p></li></ul><p>举例如下：</p><p><img src="https://gitee.com/imhjnju/imagebed/raw/master/image-20210605100405768.png" alt="image-20210605100405768"></p><p>AlexNet 信息如下：</p><p><img src="https://gitee.com/imhjnju/imagebed/raw/master/image-20210605100429795.png" alt="image-20210605100429795"></p><ul><li>CONV1 PE sets为11*55，拆解成11*7，图中有两组，每组对应不同的filter channel，使用相同的ifmap channel。同时 Stride为4。并行处理两个channel。</li><li>CONV2 PE sets为5*27，拆解成5*13和5*14，这两组使用相同的filter channel，因此不是并行处理。</li><li>CONV3 PE sets为3*13，可以放到PE array中，还可以多并行处理，也就是这里对应4个filter channel。</li><li>CONV4-CONV5 PE sets也为3*13，但是这里做了另外一种并行化处理。1,2(3,4)组内是同一filter内的channel并行；3,4组与1,2组之间是在对相同的ifmap使用不同的filter。</li></ul><p>进一步，如果需要增加并行度：可以考虑增大PE的计算能力：</p><p><img src="https://gitee.com/imhjnju/imagebed/raw/master/image-20210605100452681.png" alt="image-20210605100452681"></p><ul><li><p>a 相当于将ifmap中的两行存到spad中，PE计算一行之后结果放到相应的PSUM中，然后再开始计算另外一行。</p></li><li><p>b 文章中只讲到了time interleaving，没有过多的细节，我猜测是在PE中有更多的控制细节，控制计算filter 1中的第一个元素再来计算filter 2中的第一个元素，(ifmap)保持不动。</p></li><li><p>c感觉跟b类似，filter和ifmap都交替着来，最后的psum还是将两者相加起来。</p><p>最后实现的大小是：</p><table><thead><tr><th>type</th><th>ifmap spad</th><th>filter spad</th><th>psum spad</th></tr></thead><tbody><tr><td>size</td><td>12 * 16b</td><td>224 * 16b</td><td>24 * 16b</td></tr></tbody></table></li></ul><h2 id="RLC-Run-length-Coding"><a href="#RLC-Run-length-Coding" class="headerlink" title="RLC (Run length Coding)"></a>RLC (Run length Coding)</h2><p>编码示意图如下：5b表示0的数目，16bit表示非零值。</p><p><img src="https://gitee.com/imhjnju/imagebed/raw/master/image-20210605100525561.png" alt="image-20210605100525561"></p><p>每3组run和level打包成一个64bit的集合，其中最后一位表示是否是编码的最后值。</p><h2 id="system-modules"><a href="#system-modules" class="headerlink" title="system modules"></a>system modules</h2><h3 id="GLB"><a href="#GLB" class="headerlink" title="GLB"></a>GLB</h3><ul><li>100KB存储ifmap和psum，分成25个bank,根据ifmap和psum需要动态调整。</li><li>8KB存储filter，本来大部分都是存储在DRAM中，但是考虑到带宽需求，部分filter存储到GLB中，在计算其他部分的时候预先存储到GLB中。</li></ul><h3 id="Network-on-Chip"><a href="#Network-on-Chip" class="headerlink" title="Network on Chip"></a>Network on Chip</h3><ul><li><p>Global Input Network</p><p>根据ID(row, col)来进行匹配multicast</p></li></ul><p><img src="https://gitee.com/imhjnju/imagebed/raw/master/image-20210605100544979.png" alt="image-20210605100544979"></p><ul><li><p>Global Output Network</p><p>基本是Input的反向传输</p></li><li><p>Local Network </p><p>主要是方便psum的流动</p></li></ul><h3 id="PE-and-Data-Gating"><a href="#PE-and-Data-Gating" class="headerlink" title="PE and Data Gating"></a>PE and Data Gating</h3><p>针对零元素，不需要计算，因此可以跳过，PE结构如下：</p><p><img src="https://gitee.com/imhjnju/imagebed/raw/master/image-20210605100610583.png" alt="image-20210605100610583"></p><h2 id="Results"><a href="#Results" class="headerlink" title="Results"></a>Results</h2><ul><li>工作频率200MHz</li><li>16 bit 定点</li><li>Alexnet 34.7 frame/s，278mW， VGG16 0.7 frame/s</li></ul>]]></content>
<summary type="html">
<h1 id="Eyeriss"><a href="#Eyeriss" class="headerlink" title="Eyeriss"></a>Eyeriss</h1><h2 id="system-architecture"><a href="#system-archite
</summary>
<category term="Tech" scheme="http://imhjnju.github.io/categories/Tech/"/>
<category term="IC" scheme="http://imhjnju.github.io/tags/IC/"/>
</entry>
</feed>