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

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

手机号码,快捷登录

手机号码,快捷登录

找回密码

  登录   注册  

快捷导航
搜帖子
查看: 3857|回复: 6

[求助] CTS后理解clock latency的问题

[复制链接]
发表于 2017-11-23 13:24:28 | 显示全部楼层 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?注册

x

                               
登录/注册后可看大图

想问的是,为什么CTS后,对于input paths,工具只能知道capture clock(FF2)的latency而不知道launch clock(FF1)的latency?我的理解是capture clock是指FF2,launch clock是指FF1,如果我的理解是错的,希望在评论里指正,感谢!
发表于 2017-11-23 22:45:57 | 显示全部楼层
工具只能在端口标一个时钟长度(latency) 这个时钟是sdc里面约的 长度是根据做完cts后真实的始终长度

captrue和launch你理解是正确的
发表于 2017-11-24 13:55:53 | 显示全部楼层
回复 2# 兔老爷


   请问, 一般在CTS前用通过set_clock_latency先设置一个值来做place吗?为了更好的和CTS的情况接近,在place时
 楼主| 发表于 2017-11-24 16:27:40 | 显示全部楼层
为啥我放的图没了。。。。
发表于 2017-11-25 17:16:22 | 显示全部楼层
回复 3# xingyun666666

我觉得没必要,我的理解:1. place的时候clock本就是ideal的
2. cts后出现的io violation有可能是假错,比如对于output port的setup,由于你做的block看不到外面的register,所以capture path的propagated delay是0,是ideal的,而launch path是有tree的,这差了一个tree的长度,可是从chip top上来看,它能看到你的capture path的register,所以capture path不是ideal的,只是可能tree并不平衡罢了,如果是完全平衡的,实际上是没有violation的。
发表于 2017-11-27 09:30:47 | 显示全部楼层
回复 5# xingyun620


    我的意思是为了让place时的情况和CTS时的情况更 correlation,如果在place就标记一个CTS时得到的insert delay的平均值,那place时岂不是和CTS看到的timing差不多了,不知道对不对。您说的是IO timing ,但是reg  to reg呢?
发表于 2017-11-30 09:46:01 | 显示全部楼层
回复 6# xingyun666666

reg to reg,只要tree长得好,与place相比,差异不大啊而且,不是还有postCTS嘛,总之我觉得没有必要。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

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

×

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

GMT+8, 2024-11-26 04:03 , Processed in 0.034120 second(s), 7 queries , Gzip On, Redis On.

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