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

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

手机号码,快捷登录

手机号码,快捷登录

找回密码

  登录   注册  

快捷导航
搜帖子
查看: 7452|回复: 18

[求助] 增加clock latency的后果?

[复制链接]
发表于 2012-9-27 12:33:36 | 显示全部楼层 |阅读模式

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

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

x
1.我把clock network latency 增加以后, synthesis以后发现timing 变好了,area power都变大了。这是怎么个情况?

2.我把 clock source latency  增加以后synthesis以后发现timing没变,这又是怎么个情况?
发表于 2012-9-27 13:37:20 | 显示全部楼层
network latency 应该是指你的delay insertion 可以大些, 假设的clock skew 宽松些
 楼主| 发表于 2012-9-27 14:09:08 | 显示全部楼层
发表于 2012-9-27 18:10:09 | 显示全部楼层
假设你的clock source是A
clock network latency约束的是A点到clock sink的delay,当你释放这个约束,意味着CTS可以有更长的clock path来平衡达到DFF的skew,所以tool会插入更多的buffer或者inverter来balance skew,当然timing就变好啦,但是这样却付出了power和area的代价,因为driver cell变多了嘛。

这里,在65nm以前,这么做似乎是对timing有利,有时也确实这样去improve timing的。
但是,各位需要考虑一下32nm之后,如果还用这种延长clock path来侥幸balance skew的话会出现什么情况呢?
发表于 2012-9-27 23:34:46 | 显示全部楼层
各位需要考虑一下32nm之后,如果还用这种延长clock path来侥幸balance skew的话会出现什么情况呢?

我猜测, 为了平衡SKEW,  线会绕远  是吗,
发表于 2012-9-28 01:03:04 | 显示全部楼层
同意楼上观点,32nm以后线间距更小,插入过多的buf会使得绕线变长,cross talk的影响反而会使timing更差。个人猜测,欢迎指正。
 楼主| 发表于 2012-9-28 02:09:18 | 显示全部楼层
版主,但是我的这是synthesis,还没有CTS呢



假设你的clock source是A
clock network latency约束的是A点到clock sink的delay,当你释放这个约束,意味 ...
joemool 发表于 2012-9-27 18:10

发表于 2012-9-28 09:33:26 | 显示全部楼层


各位需要考虑一下32nm之后,如果还用这种延长clock path来侥幸balance skew的话会出现什么情况呢?

我猜 ...
729050850 发表于 2012-9-27 23:34



是的,如果用传统的CTS方法的话,确实需要这么做,那么请想想线宽变窄,OCV更严重,要求的RC抽取更精确。此时,path变长的话等于增加了更大的不确定性。特别在32nm之下,这种不确定性将使得skew根本不可能满足。意味着,你如何使用传统方法去CTS,也没有办法实现balanced skew。
发表于 2012-9-28 09:34:17 | 显示全部楼层


版主,但是我的这是synthesis,还没有CTS呢
xilinx_zhao 发表于 2012-9-28 02:09




   不好意思,我望文生义了。 不过,这是个很好的议题,毕竟这是前端和后端都很严峻的事。
发表于 2012-9-28 10:18:23 | 显示全部楼层
加大network delay,时钟延时变大了,相对于我们只关注的setup slack而言,肯定是有利的,所以timing是变好了,虽然是综合,但是也有wlm,这种加大network delay,意味着virtual wire length 和power也增加吧!
您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

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


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

GMT+8, 2024-11-14 15:53 , Processed in 0.024870 second(s), 8 queries , Gzip On, Redis On.

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