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

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

手机号码,快捷登录

手机号码,快捷登录

找回密码

  登录   注册  

快捷导航
搜帖子
查看: 2160|回复: 4

[讨论] 有高手知道吗? 这种情况好奇特 Encounter

[复制链接]
发表于 2016-1-28 08:54:13 | 显示全部楼层 |阅读模式

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

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

x
这样的,比如我有个net ,名字是ptest_scan , 上面挂着3200个叶子,都是SDFF 的se 端, 我在sdc 里面设置了set max fanout 32, set max transition 1.5ns , 然后正常地,placedesign 完成后,进入prects 阶段,进行optdesign -prects , 就是进行一些timing opt & transition opt嘛,一切都很正常,但是我发现,ptest_scan net 也正常进行了fanout buff tree 的形成,从tansition violation report里面我发现,net ptest_scan 有3.0ns 的transition 违反,是因为pteest_scan 上面挂了180个SDFF se端,因为一共有3200个SDFF se端连接到ptest_scan 上面,我browers 了一下,其它的3000多个叶子都按照约束生成了buff tree,唯独这剩下的180个SDFF的se端还直接挂在ptest_scan net上面,没有被blance ,那么我就奇怪了,这是为什么呢???百思不得其解。。。,所以想请教一下这里的专家是否有此类经验!
  另外我还发现一个奇怪的现象,就是我在脚本的开始,一般会设定一些不想被用到的cell , 例如CK 开头的cell 是clock 专用的,我会set_dont_use CK* true , 那么我发现ptest_scan transition 违例变得更厉害了,变成-6.0ns ,因为ptest_scan net上面直接挂了300个se 端,也就是说其余的2900个是被正确作了tree的, 如果我去除掉set_dont_use CK* true 这句,那么就是上面说的,最后下来ptest_scan 上会剩余180个叶子,还是形成transtion violation .这真的是好奇怪, 欢迎大家积极讨论给出建议~~~~~~
 楼主| 发表于 2016-1-28 17:43:17 | 显示全部楼层
?? no one
发表于 2016-1-29 17:24:25 | 显示全部楼层
这180 个为什么没有长tree?
 楼主| 发表于 2016-1-29 17:49:20 | 显示全部楼层
回复 3# frustrate


    是啊,为什么啊? ,为什么其余的都长tree 了呢。。,
发表于 2016-2-1 15:34:23 | 显示全部楼层
问题解决了吗?
您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

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


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

GMT+8, 2024-11-23 00:21 , Processed in 0.019985 second(s), 8 queries , Gzip On, Redis On.

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