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

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

手机号码,快捷登录

手机号码,快捷登录

找回密码

  登录   注册  

快捷导航
搜帖子
查看: 1357|回复: 11

[讨论] 一条奇怪的 两个有分频时钟关系的clk间 reg2reg的违例

[复制链接]
发表于 2024-1-15 10:11:23 | 显示全部楼层 |阅读模式
20资产
时钟关系

clkA +icg => clkB + icg => clkC + icg , sdc 里已将这几个时钟放在一个group里面。


一条reg2reg 的检查,有700ps的违例:
end_point :  reg1/D  (v)  check with leading edge of  clkC

start_point : reg2/QN  (^) check with trailing edge of  clkB

具体情况:
两条路径都是从 clkA 开始计算的,clkB 之前都是在IP内部,看报告上面的点应该是公共路径。

从clkB 开始看,两个reg 树长都是 800ps 左右 , data path  走了2.8ns左右,其中有2ns是因为经过了一个IP。 (周期 4ns), 看起来是比较合理的。
另外,launch path 物理距离挺短的,因为和其他时钟有check,所以ccopt 做了这么长。


疑惑的点是, 计算launch path的时候, 从clkA到clkB 加了半个周期,也就是2ns,走的是 clkB的v;而 caputre 没有,走的是 clkB 的 ^ 。
问题1: 这种检查路径是合理的吗? 有分频关系的两个时钟,从他们的共同源时钟开始计算延迟,但是共同路径算出来的延迟又不一样?
问题2: 如果这种路径检查合理,是不是有什么约束缺失? 或者是需要直接修?

问题3: 为什么会出现这种加半个周期的情况?

*(有我没描述清楚的可以追问我)


还请各位热心同行,不吝赐教!
一知半解的也可以!大家一起讨论下呀~!




 楼主| 发表于 2024-1-15 14:07:54 | 显示全部楼层
顶顶, 是我描述的不太清楚吗
发表于 2024-1-16 11:42:56 | 显示全部楼层
共同路径算出来的延迟不一样可能是时钟路径上有重汇聚(即起点终点相同,中间经过的路径不同,应在设计和SDC上避免这种情况),但更常见的是因为OCV,不过CRPR会补偿回来

出现加半周期的情况是因为RTL就是这么设计的吧,下降沿/上升沿launch, 上升沿/下降沿capture;如果两个寄存器都是上升沿触发,应该能看到其中一路时钟树多了个反相器
 楼主| 发表于 2024-1-16 15:27:19 | 显示全部楼层


zero_0 发表于 2024-1-16 11:42
共同路径算出来的延迟不一样可能是时钟路径上有重汇聚(即起点终点相同,中间经过的路径不同,应在设计和SD ...


从时序报告和PR工具看出:
公共路径:  IP 内部的pin 产生clkA ,经过一些pin生成clkB (pin 是一样的,只是 显示的沿的变化不一样,因为ip资料不完整,不知道是否有反向器),从同一个IP外部pin出,再经过几个共同的cell。
cppr 只抵消掉了 这几个cell的延迟。  


我的认知是,既然是clkB 和clkC(clkB的分频是时钟)的检查,那clkB之前的不应该都算com path吗?
如果是ip内部走了不同的路径又从同一个ip的pin出来,那是不是应该算互斥,不应检查呢?


发表于 2024-1-16 17:33:54 | 显示全部楼层


卷芯菜 发表于 2024-1-16 15:27
从时序报告和PR工具看出:
公共路径:  IP 内部的pin 产生clkA ,经过一些pin生成clkB (pin 是一样的, ...


你们流程中CPR设的是same_transition?

点评

感谢,解锁了新的知识点。 timing_cppr_transition_sense 设的normal 补充一点,多的半个周期感觉是cycle adjustment,是不是cppr不能抵消这种情况。  发表于 2024-1-17 10:21
 楼主| 发表于 2024-1-17 10:35:13 | 显示全部楼层
本帖最后由 卷芯菜 于 2024-1-17 14:21 编辑

感觉我描述的可能会不太客观,补充timing 报告图

capture

capture

launch

launch
发表于 2024-1-17 12:26:11 | 显示全部楼层


卷芯菜 发表于 2024-1-17 10:35
感觉我描述的可能会不太客观,补充timing 报告图


startpoint的时钟是ref_dig_clk_i的取反,这半周期肯定不能通过crpr抵消,所以目前截取的部分公共路径差异只有0.059而已,其中rising和falling间即使没加derating也有差异,这部分是不能补偿的
 楼主| 发表于 2024-1-17 14:07:45 | 显示全部楼层


zero_0 发表于 2024-1-17 12:26
startpoint的时钟是ref_dig_clk_i的取反,这半周期肯定不能通过crpr抵消,所以目前截取的部分公共路径差 ...


所以这是合理的吗?为什么会出现取反得的情况,是两个reg触发沿不同导致的吗?还是因为存在多条路径,计算capture的时候选择了最差的一条呢?
发表于 2024-1-17 14:12:41 | 显示全部楼层
本帖最后由 zero_0 于 2024-1-17 14:15 编辑


卷芯菜 发表于 2024-1-17 14:07
所以这是合理的吗?为什么会出现取反得的情况,是两个reg触发沿不同导致的吗?还是因为存在多条路径,计 ...


assign clkn = ~clk;
always @(posedge clkn) begin
    data_out <= data_in;
end



 楼主| 发表于 2024-1-17 14:26:16 | 显示全部楼层


zero_0 发表于 2024-1-17 14:12
assign clkn = ~clk;
always @(posedge clkn) begin
    data_out


抱歉,前端的代码我只能看懂一点点 >.<
这个clkn 是clk 的取反时钟, 下降沿触发 ?
那这样是两个时钟了呀, 但是我这条是同一个pin, 同一个clk,分别检查了的上升沿和下降沿,我感觉有点矛盾,我有限的脑细胞理不清楚为什么这样

您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

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

×

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

GMT+8, 2024-11-22 00:30 , Processed in 0.021835 second(s), 7 queries , Gzip On, Redis On.

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