place阶段短线插入大量inverter的原因

quanqiutong

high fanout 应该在place时都解决

allen_tang

截整段的report，包含hier结构，最好有pr工具里的data path走线截图，不然别人很难帮你debug具体原因

无我千里

allen_tang 发表于 2020-11-5 14:28
截整段的report，包含hier结构，最好有pr工具里的data path走线截图，不然别人很难帮你debug具体原因
...

已更新

522284834

你这会不会是input delay设得太过分了呀？在线蹲一个答案

quanqiutong

slack 太大，tools插入buffer，inverter来减少slack

jake

感觉这个设计的前端做得很糟糕。
aclk period 1000ps: 1GHz, quite fast.
*/w_out_fifo/rptr_reg_*: This is probably FIFO read pointer
From FIFO read pointer to axi_wdata output, there is no flop, no pipeline stage.  For high speed design, this is crazy.  
During place_opt_design, Innovus struggled to fix maxCap/maxTrans/maxFanout while trying to meet set_output_delay (600ps out of 1000ps, 12% clock uncertainty, plus derate, that's very tight).  That may be why Innovus inserted large inverters.

Register axi_wdata may fix the problem.  

Quality of front end design looks poor.  It almost seems that the front end designer has no experience in high speed logic design.  Just my 2 cents.  

Lover_Momo

无我千里 发表于 2020-11-5 11:48
这个我问组长，告诉我说place阶段这是正常现象，我有点困惑

41733是cts最后一级推的（多颗DFF/CK接到一起），因为你的flow中没有再place的时候cts，所以此处fanout很大，正常。（因为它是clock net）

Lover_Momo

1. timing path可以再将pad location报出来，可以约么预估问题所在。
2. 看上去像16/14nm一下的工艺，没做过，羡慕。
3. 前端设计有没有问题不知道，但是约束设置的确实有点紧张（output delay 600ps, uncertainty 120ps, Period 1000ps），剩下的给block内部的delay也就280ps。虽然目前的结果有点糟，但是假如去除data path上的buf/inv来说的话，看上去过不是没有可能。
4. 找UG查一查“FE_OCPC”和"FE_OFN"这两个关键字的意义何在。
5. High fanout & Distance都有可能是造成DRV的原因
加油。。

allen_tang

无我千里 发表于 2020-11-5 17:46
已更新

端口约束卡了周期的60%,算很常见，1G频率上一层的时序也会很紧张；

路径上很多inv是为了解hfout的问题，要想place met 60% period output delay，最好的办法就是把data path的reg & logic bounds在端口附近，group的weight加高，尽量把这条路径的data path做的足够短, 但是有可能对internal r2r造成影响，和前端和上层多沟通反馈吧

无我千里

万分感谢以上各位的解答.
结合其他资料个人总结如下：
1. 工具在短线插入的这么多inverter是为了meet maxCap/maxTrans/maxFanout。
2. high fanout在place阶段大属于正常现象。（尝试set_max_fanout使用无效，如17楼所说，place阶段fanout是clock net）
3. 最终的解决方案考虑 距离以及group path

再次感谢以上各位。
有不同意见或者我总结有误的情况也请大家不吝赐教。