在线咨询
eetop公众号 创芯大讲堂 创芯人才网
切换到宽版

EETOP 创芯网论坛 (原名:电子顶级开发网)

手机号码,快捷登录

手机号码,快捷登录

找回密码

  登录   注册  

快捷导航
搜帖子
查看: 816|回复: 8

[求助] Memory lib retaining rise/fall 参数是否用于hold检查

[复制链接]
发表于 2023-12-26 18:06:24 | 显示全部楼层 |阅读模式
100资产

Memory Compiler产生的lib中,看到有两种类型的 D->Q的delay参数:

1. cell rise/full;
2. retaining rise/full;

对应lib的部分描述如下:

      timing() {
        related_pin : CLK;
        timing_type : rising_edge;
        timing_sense : non_unate;
        when : "!CEN&RET1N&GWEN&!EMA[2]&EMA[1]&EMA[0]";
        sdf_cond : "CEN == 1'b0 && RET1N == 1'b1 && GWEN == 1'b1 && EMA[2] == 1'b0 && \
                EMA[1] == 1'b1 && EMA[0] == 1'b1";
        cell_rise(sram_sp_144_14_clockslew_outputload_delay_template) {
          index_1 ("0.001000, 0.008000, 0.031000, 0.075000, 0.144000, 0.242000, 0.369000");
          index_2 ("0.004000, 0.009000, 0.018000, 0.035000, 0.075000, 0.150000, 0.300000");
          values (\
            "1.590206, 1.600698, 1.614879, 1.640112, 1.689349, 1.778304, 1.952139", \
            "1.591644, 1.602135, 1.616317, 1.641550, 1.690787, 1.779741, 1.953577", \
            "1.603905, 1.614398, 1.628579, 1.653811, 1.703049, 1.792002, 1.965840", \
            "1.624444, 1.634935, 1.649117, 1.674350, 1.723586, 1.812540, 1.986378", \
            "1.654888, 1.665380, 1.679561, 1.704795, 1.754033, 1.842986, 2.016823", \
            "1.688549, 1.699042, 1.713223, 1.738456, 1.787695, 1.876648, 2.050484", \
            "1.716075, 1.726567, 1.740748, 1.765980, 1.815219, 1.904172, 2.078010" \
          );
        }
        retaining_rise(sram_sp_144_14_clockslew_outputload_retain_template) {
          index_1 ("0.001000, 0.008000, 0.031000, 0.075000, 0.144000, 0.242000, 0.369000");
          index_2 ("0.004000, 0.009000, 0.018000, 0.035000, 0.075000, 0.150000, 0.300000");
          values (\
            "0.470076, 0.478470, 0.490384, 0.511301, 0.552343, 0.625640, 0.769816", \
            "0.471345, 0.479739, 0.491653, 0.512570, 0.553613, 0.626909, 0.771086", \
            "0.481654, 0.490048, 0.501962, 0.522879, 0.563921, 0.637217, 0.781395", \
            "0.500874, 0.509267, 0.521182, 0.542098, 0.583140, 0.656436, 0.800613", \
            "0.528794, 0.537187, 0.549102, 0.570018, 0.611061, 0.684357, 0.828534", \
            "0.558269, 0.566663, 0.578578, 0.599494, 0.640537, 0.713833, 0.858011", \
            "0.583185, 0.591579, 0.603493, 0.624409, 0.665453, 0.738748, 0.882927" \
          );



不知道retaining delay是在什么流程中使用的?

通常我们在做后端APR的时候(之前用的Memory Compiler),选用ss corner的cell delay参数进行setup timing check,选用ff corner的cell delay参数进行hold timing check;

现在,ss corner有两个delay参数,cell delay 1.64ns;retaining delay 0.12ns;
ff corner 有两个delay 参数,cell delay 0.90ns;retaining delay 0.25ns;

将lib文件读入工具,
工具会选择最差的做setup timing check(1.64ns),选择最好的做hold timing check(250ps);

cell delay gap相差太大,timing很难收敛。

因此,该选哪个delay参数,作为hold timing check的参数?

对retaining的理解,也有问题。从Liberty User Guides中看到:



retaining_rise and retaining_fall Groups
The retaining delay is the time during which an output port retains its current logical value
after a voltage rise or fall at a related input port.
The retaining delay is part of the arc delay (I/O path delay); therefore, its time cannot exceed
the arc delay time. Because retaining delay is part of the arc delay, the retaining delay tables
are placed within the timing arc.
The value you enter for the retaining_rise attribute determines how long the output pin
retains its current value, 0, after the value at the related input port has changed.
The value you enter for the retaining_fall attribute determines how long the output
retains its current value, 1, after the value at the related input port has changed.


这个仿佛是一种跟sram端口电压有关的设定,用于sram的电压恢复时候的时序检查,不知理解对不对。


补充内容 (2023-12-29 10:13):
参数有误,改为:ss corner有两个delay参数,cell delay 1.64ns;retaining delay 0.51ns;

最佳答案

查看完整内容

哦,那感觉你的主贴说的不是很贴切。应该是无论在哪个corner,都要做setup 、 hold check。但是最终的timing signoff是要在fast corner的hold和slow corner的setup; 另外,我看你的主贴里写ss corner的retaining delay 比 ff corner的更小?所以不是仅仅看fast corner? 应该看最小的min delay? 如果是compiler产生的memory,确实有时候cell delay和retaining delay 会差很多,compiler产生的lib大部分时候会把 out pin bus ...
发表于 2023-12-26 18:06:25 | 显示全部楼层


ljacki 发表于 2023-12-27 21:25
工具做检查的corner是依据给的lib文件的,我想表达的意思是在ss修setup timing,在ff修hold timing;
所 ...


哦,那感觉你的主贴说的不是很贴切。应该是无论在哪个corner,都要做setup 、 hold check。但是最终的timing signoff是要在fast corner的hold和slow corner的setup;

另外,我看你的主贴里写ss corner的retaining delay 比 ff corner的更小?所以不是仅仅看fast corner? 应该看最小的min delay?

如果是compiler产生的memory,确实有时候cell delay和retaining delay 会差很多,compiler产生的lib大部分时候会把 out pin bus merge成一组timing,用最差的window去覆盖这一整组的delay。所以就有可能本来稍微大点的retain delay port取了最差就拥有了较小的retaining delay。 而memory macro char lib时可以选择是否将bus 拆开,每个port分别表征。对于外界就会容易收敛一点。compiler的这个现象是由compiler的设计方法学限制的,这种做法更简单便捷。但是会出现你说的cell_delay和min_delay差的比较大的问题。
发表于 2023-12-27 02:07:29 | 显示全部楼层
Thanks
发表于 2023-12-27 16:39:00 | 显示全部楼层
工具会跨corner做STA?对于memory本身而言,cell_delay就是max delay, retaining就是min delay。
我觉得每个corner收敛就行了吧?
如果跨corner收敛STA,那不是认为一个电路里有很大的global variation?那这个片子应该巨大吧?得有一个wafer那么大了吧?
 楼主| 发表于 2023-12-27 21:25:53 | 显示全部楼层


sunrr1987 发表于 2023-12-27 16:39
工具会跨corner做STA?对于memory本身而言,cell_delay就是max delay, retaining就是min delay。
我觉得每 ...


工具做检查的corner是依据给的lib文件的,我想表达的意思是在ss修setup timing,在ff修hold timing;
所以需要设计在ss和ff都能满足setup和hold timing;

我们report了memory D->Q的路径,setup检查使用的参数是跟cell_delay基本一致。hold检查使用的参数,在单个corner的lib里也基本跟retaining_delay一致;


问题是如果按照ss的cell_delay,ff的retaining_delay修timing,
在优先保证芯片的频率(period 1.78ns)的情况下,hold的timing参数(0.25ps)相对于setup的timing参数(1.64ns)小太多了。
后端觉得这个没有办法修。
 楼主| 发表于 2023-12-29 10:46:37 | 显示全部楼层


sunrr1987 发表于 2023-12-28 10:38
哦,那感觉你的主贴说的不是很贴切。应该是无论在哪个corner,都要做setup 、 hold check。但是最终的tim ...


您描述的比主贴里面更能清晰表达我的意思


ss corner的retaining delay应该为0.51ns,有误已在主贴补充说明;

查看了lib文件,里面确实只有一个bus q的参数,没有将每个端口拆开;




  1. bus(Q) {
  2.       bus_type : sram_sp_144_14_Q;
  3.       direction : output;


复制代码
我暂时还不知道如何将bus拆成每个port;
可以确定的是compiler选用的较小的retaining delay,即使进行拆分的操作,拆分之后的min_delay也会是后端修hold timing的瓶颈。
像您请教:
1. 优先保证setup,我们是否需要考虑舍弃这个ff_corner作为hold timing signoff的条件?
2. 是否有更好的方法,减小cell_delay和min_delya相差大的问题?
感谢!
发表于 2024-1-2 11:55:07 | 显示全部楼层
没有看完所有帖子,就最后一个帖回复:
1. 优先保证setup,我们是否需要考虑舍弃这个ff_corner作为hold timing signoff的条件?
>> 不应该优先保证setup,hold不满足根本无法补救,需要严格按照foundry的要求进行signoff, 通常不能舍弃ff_corner

2. 是否有更好的方法,减小cell_delay和min_delya相差大的问题
>> 选用更快的SRAM,代价是功耗和/或面积
 楼主| 发表于 2024-1-2 21:10:05 | 显示全部楼层


zero_0 发表于 2024-1-2 11:55
没有看完所有帖子,就最后一个帖回复:
1. 优先保证setup,我们是否需要考虑舍弃这个ff_corner作为hold tim ...


感谢,了解到了,还是要严格按照foundry的要求。
发表于 2024-1-13 22:01:16 | 显示全部楼层


ljacki 发表于 2023-12-29 10:46
您描述的比主贴里面更能清晰表达我的意思;


不好意思,好几天没上论坛。刚刚看到消息。


第一个问题,如果bus 拆分开,对于你的情况我觉得会有较大改观。
举个例子max_delay在Q_255, min_delay 在 Q_0, 合并成一个bus表达的timing是 retaining_delay=Q_0 min_delay, cell_delay=Q_255 max_delay;
而bus拆分开后,bus内的每个pin单独表达自身的cell_delay和retaining_delay。
timing_signoff 时就会针对每个pin去收敛各自的max delay和min delay;
毕竟在一块,个体的收敛比团体的收敛要容易;
然后,这个bus的分拆在后端不是很好解决,得re-char memory lib,并设置bus拆分去char;或者和vendor要求需要bus拆分的timing;

另一个,必须保证hold。实际芯片setup不满足时,还可以降频来满足,最多是产品牺牲点性能,保证功能没问题;但hold不满足就可能直接导致功能错误。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

站长推荐 上一条 /2 下一条

小黑屋| 关于我们| 联系我们| 在线咨询| 隐私声明| EETOP 创芯网
( 京ICP备:10050787号 京公网安备:11010502037710 )

GMT+8, 2024-5-1 06:40 , Processed in 0.034359 second(s), 7 queries , Gzip On, Redis On.

eetop公众号 创芯大讲堂 创芯人才网
快速回复 返回顶部 返回列表