关于实现Benchmark

• 

  benjaminweber (stupids do what stupid does.) 组长 楼主 2009-06-27 04:47:26

  非常感谢！ 我自己是做硬件的，说实话想去搞benchmark很有困难，但是感觉上不开始考虑这些就有点晚了。 至于GEMS我听说过，闲下来的话我会研究研究。看来Simics能做到周期精确，应该比较一下smics和OVP。 至于你们研究的静态配置，不知你们是否想过动态配置。静态配置的方法设计NoC也许代价过高，如果能实现动态配置，即使效果没有静态配置的好，但能够适用于更多的应用。 对负载生成没有研究，我现在还只是考虑如果在研究出一个新的router之后，如何能更好地获得它在实际应用下的性能。如果有已经公认的负载生成模型，当然好，但是跑一下实际的benchmark也许更有说服力。

  删除 |

  赞 回复
• 

  benjaminweber (stupids do what stupid does.) 组长 楼主 2009-06-27 10:40:32

  你又把我说糊涂了。 对于buffer，字长和位宽与面积自然是线性关系。关键是分配，把剩余的buffer分给其他的VC来减小面积或提高throughput。 至于你说的连线面积，逻辑综合怎么会有连线面积？你指的mux和demux，这个也算逻辑的面积吧。 是有很多文章用的是综合之后的面积，如果是布局布线的面积，一般会特别说明的。 但是很少有人会把mux和demux的面积忽略，应该不会。

  我说的静态配置的代价是设计成本。如果把一个实际运用放到NoC上还必须先做负载分析，task mapping之类的，然后再设计，最后作芯片的话，芯片的生产规模不会很大，设计成本也比较高。相反，如果网络能够自适应应用，就可以造一个芯片，然后往上放不同的应用就好了。这样芯片的生产规模扩大，设计成本是一次性的，而不需要为每一个应用重新设计一次。

  所以，我并不是反驳静态配置的有效性或者是可能性，我只是从实用性的角度，如果我是一个不懂NoC的人，现在要做一个NoC，也许动态配置更有吸引力，因为我不用懂算法，把别人研究的技术拿来，拼成一个网络，流片，回来把应用放上就好了。

  我现在是初级阶段，还在研究如何搞一个路由器，没有trace。只是在思考。

  删除 |

  赞 回复
• 

  benjaminweber (stupids do what stupid does.) 组长 楼主 2009-06-28 01:22:43

  "通常文献中动态buffer的控制逻辑面积占据设计的很大比重，但是控制逻辑随着缓存深度的增加而线性增加" 没错

  "但是通常不随位宽的增加而增加，我认为这也是文献中动态buffer评估开销的时候选择128位甚至更大的原因" 很有可能

  "还有就是连线面积（通过线负载模型获得的，延迟也是如此），通常连线面积是cell单元面积的10倍左右。" 还是不明白逻辑综合怎么会得到连接线面积,一般是没有的,除非standard cell库有这样的估计，通过fanout来估计。但即使这样，我认为这个估计很不准，线延时从fanout来计算就很不准，何况面积。 至于连接线是cell面积的10倍，不太可能吧。你指的什么cell？连线面积大部分和cell面积是overlap的。只有出现routing congestion的时候，才需要在place and routing的时候为连线预留空间，不然的话，富余的空间一般是留给时钟树，buffer,DFT和spare cell的。

  "这样我前面提到的问题（位宽和深度都会引起设计面积的同比增长现象）和上面实际情况就不大一致了" 确实有问题，位宽应该不会显著影响控制逻辑的面积。检查你的设计和综合，我觉得不太对。

  BTW,你在做buffer对所有的VC的全连解吗？局部连接可以减少连线面积，但是会影响性能。如果你看FPGA里的连接矩阵，他们都是局部连接，而不是全连接的。全连接按节点个数指数增长，局部连接也许能做到线性增长。 不知道是否有关系，吓猜。

  删除 |

  赞 回复
• 

  benjaminweber (stupids do what stupid does.) 组长 楼主 2009-06-29 23:38:12

  比如说下面的面积报告 report_area

  ---

  Report : area Design : router Version: B-2008.09-SP2 Date : Mon Jun 29 16:30:18 2009

  ---

  Library(s) Used:

  gtech (File: /*******/synopsys/syn_B-2008.09-SP2/libraries/syn/gtech.db) fsc0h_d_sc_wc (File: /*******/synopsys/fsc0h_d_sc_wc.ndb)

  Number of ports: 961 Number of nets: 2289 Number of cells: 191 Number of references: 16

  Combinational area: 22185.000000 Noncombinational area: 0.000000 Net Interconnect area: undefined (Wire load has zero net area)

  Total cell area: 22185.000000 Total area: undefined

  ################################################# cell 的面积一般由组合逻辑面积（Combinational area）和非组合逻辑面积（FF 和 Latch）(Noncombinational area)构成，至于连线面积一般为0，大多数cell library不对wire load model定义连线面积。

  （我这里非组合逻辑面积为0是因为我的设计是异步逻辑的，没有latch和FF）

  至于你问的第二个问题，综合之后的面积并不等于最终的面积，尽管我们一般拿综合之后的面积来衡量一个设计的大小。原因很多，比如综合的时候时钟树面积为0，没有spare cell，没有为macro留blockage，没有为routing congestion留空间等等。一般来说，综合之后的面积只占最终流片die size的70-80%。

  另外，综合插进去的buffer往往会被布局布线软件先去掉然后重新插。原因是布局布线软件的时间信息更准，综合软件很可能插错了。这个步骤往往会带来面积又增加5%左右。

  对于一个设计，因为综合后的面积和布局布线后的面积没有直接关系，文章往往还是用综合的面积，如果用的是布局布线的面积，一般使用die size和占用百分比来表示。

  删除 |

  赞 回复
• 

  benjaminweber (stupids do what stupid does.) 组长 楼主 2009-07-02 23:22:25

  从standard cell的lib文件中找出NAND2X1的面积，然后将综合得出的面积除以这个值，就可以得到等效门数。

  删除 |

  赞 回复
• 

  benjaminweber (stupids do what stupid does.) 组长 楼主 2009-07-04 19:38:24

  我所知道的等效门数就是这么算的，那你有没有更官方的定义，比如从什么手册或报告中得到的定义？

  删除 |

  赞 回复
• 

  benjaminweber (stupids do what stupid does.) 组长 楼主 2009-07-08 07:46:12

  呵呵，说等效门就不错了，很多paper直接拿个tech加上面积，没有等效门，不就更不好比了。

  差出20%确实很吓人。我个人来说，由于软件造成10%的面积增加还是有可能的，所以面积大了或小了10%以内，也许不是太大的问题，但是大于10%应该就有设计原因了。

  删除 |

  赞 回复

你的回复

回复请先 登录 , 或 注册