关于怎样做power plan，保证芯片的std cell 和SRAM可以吃到电
芯片的面积?SRAM的个数和摆放位置?std cell的规模?还是芯片的功耗?IO power的位置和个数?大家在这是怎么做power plan的?
自己顶
芯片的面积?SRAM的个数和摆放位置?std cell的规模?还是芯片的功耗?IO power的位置和个数?
问的很好！还要问metal/via的过电流能力
你们在做项目的时候一般怎么做?怎么做power plan的?书本上写的根本不适用于实际工程中，求教Power ring的宽度和间隔计算方法：
一．宽度
1.计算出功耗P（各种工具）；
2.设宽度为W，高为H，功耗为P，则
Ptop = Pbottom = P * W / (W+H) * 0.5;
Pleft = Pright = P * H / (W+H) * 0.5;
3.每边宽度可以计算为：
W(um) = I / J;
J为电流密度，I(mA)=Pside/V，电流密度可以从厂商提供的工艺库中查到。
4.金属宽度应该有50%的裕度。
二．间隔
间隔根据厂家提供的设计规则中的最小间距决定，一般情况下为最小间距的2倍左右。
Power stripes的宽度和间隔计算方法：
一．宽度
纵向stripe的宽度的最大值取标准单元库中的最小与非门宽度的4倍；
纵向stripe的宽度取值一般为垂直布线间距(pitch)的整数倍，其目的是为了充分利用布线通道。垂直布线间距的值可以从对应工艺的LEF库中查找到；
横向stripe的取值一般是标准单元高度的整数倍，通常选择1倍或者2倍。
我对Power ring的看法不那么绝对，因为有点项目可以不要ring只要stripes，这跟你前面提到的几个因素都有关系，还有vss/vdd的bounding情况有直接关系，具体项目来具体分析
你们在真正做项目的时候是怎么确定这个width spacing数值是多少的?ring的宽度和间距，经验值?你们应该不用公式计算吧。感觉摸不着头脑对于ring，当我做的block中，有很大的SRAM 时我就加两个ring?（VDD VSS）没搞懂何时应该加ring，何时直接打stripe就行了做block时
功耗来确定P/G的pad的个数。macro的摆放位置，macro的P/G情况以及macro的电流大小来确定如何连接macro更合理。
不管是否做ring，还是要判断其合理性，没有ring，但是很宽的stripes还是需要的，只是不是传统的绕一圈的样子，而是更贴近PAD的位置
感觉一言难尽，具体分析吧，总之，合理就好。感觉和没说一样
关于core ring，个人觉得ring还是要有，毕竟ring可以认为是pg pad跟内部strip或mesh的衔接。
当然ring也不一定非得是传统的绕着core外缘的样子。对于IP/memory等比较多的设计，ring可以做到core里面来，节省面积。
"横向stripe的取值一般是标准单元高度的整数倍，通常选择1倍或者2倍。"
做两倍宽很可能会使得相邻rail有打不到stack via的风险。
1倍太细无必要，2倍又太宽，所以我一般做1.6~1.7倍宽，并且跟rail对齐。
不好意思，问您个问题，是我一直以来的困惑：在PT中修timing ECO时，我们会优先选择用size_cell的方法。不用insert buffer,因为不会破坏net的信息，因为PT不知道版图信息,只是insert buffer把net打断了，并不知道打断后怎么分配RC，所以修完logic DRC后，在PT中分析的setup和hold都是不准的，pt评估的还是不够准
，如果是在pt中fix，最好还是不要动net，一动net就没那么准了，若不用insert buffer，影响会小一些，但是现在PT可以吃DEF了，可以知道版图的信息了，所以两种方法并没有什么优先级了，对吗?求证
第二个问题是：在PT中做timing ECO 时的flow是怎样的?实际工程中timingECO 是先选择size_cell中的换VT?因为cell大小不变，如果是多Vt的，就是先看用size_cell的换vt能不能修掉,对吧?因为size_cell的换驱动，也会破坏net的信息?
eco修timing是一个综合考虑的事，也许从前端就开始了，或者floorplan，或者时钟树，总之，单纯的抛开版图用PT修timing的方式，我不太赞同。一般来说，size cell也好，insert buffer也好，需要setup和hold都看一下，分析下，决定如何修正。如果pr工具能够识别的violation，一般工具都可以自我搞定的，pt看到violation，要确认约束问题。如果实在搞不定的，也要确认是否局部的density有问题，以至于pr工具不给修正。
至于eco后timing的准确性，可以pr工具中eco后，再抽取rc，给pt报timing，这样多次迭代吧。
你说的多Vt的指的什么呢?
很开心收到您的耐心解答，那么总结起来就是，
第一不吃DEF的PT仅仅就是作为验证工具，看timing、logicDRC在ICC中修完后有无violation，不能在PT中修。因为在PT中执行fix_eco_timing -setup，在PT中修，PT是不知道layout物理信息的，所以PT中修timing仅仅是基于logic的，根本不靠谱。但是那种PT吃DEF的flow，吃def是新版PT功能，当然准一些，在PT中修timing是可以的，对吗?
第二，正常的timing signoff的flow,应该是在ICC里把logic DRC和timing都clean了，然后用PT验证一下，若有violation，回ICC去分析这些path，依然在ICC中把这些 logic DRC violation、timing violation给clean了?仅仅用ICC 修timing就可以把timing都修clean，并不需要PT修，对吧?
我说的多VT是指一个design中，同时有HVT SVT LVT的cell，可以通过换VT来fix logic DRC和setup、hold
第一不吃DEF的PT仅仅就是作为验证工具，看timing、logicDRC在ICC中修完后有无violation，不能在PT中修。因为在PT中执行fix_eco_timing -setup，在PT中修，PT是不知道layout物理信息的，所以PT中修timing仅仅是基于logic的，根本不靠谱。但是那种PT吃DEF的flow，吃def是新版PT功能，当然准一些，在PT中修timing是可以的，对吗?
pt可以出一个提供参考的脚本，但是最终的实现要在pr工具中。所以不管你用不用pt给的脚本，最后都要能在pr工具中实际执行了，并且绕线成功了，再抽取rc给pt验证，才确认最终的有效性，这么说懂吧。
PT是做STA，也就是静态时序分析。最终的layout还是pr工具来实现。
第二，正常的timing signoff的flow,应该是在ICC里把logic DRC和timing都clean了，然后用PT验证一下，若有violation，回ICC去分析这些path，依然在ICC中把这些 logic DRC violation、timing violation给clean了?仅仅用ICC 修timing就可以把timing都修clean，并不需要PT修，对吧?
仅仅用ICC 修timing就可以把timing都修clean，但还是需要按照流程到pt中进行timing确认。
能混用也行吧，不过我见过的lvt/rvt是不同的track的，也就是单元高度并不一样，所以做的时候从综合开始就需要单独处理