primetime分析信号完整性的问题

陈涛

你去读一下置顶FAQ的Q1.8

yl5495

你去读一下置顶FAQ的Q1.8
陈涛 发表于 2013-7-4 09:54

                               
登录/注册后可看大图

我的设置跟你所表述不矛盾，设计中没有锁相环，时钟来自外部输入，不没考虑pll jitter ,只是做了预估skew。

postCTS后，为了设计更鲁棒，就保留了之前的预估skew。这么做有问题吗？

陈涛

多加margin当然保险，但是对于high speed design，有可能就做不出来了
而且你这种解释暴露了你对jitter和skew的理解不是十分正确

yl5495

多加margin当然保险，但是对于high speed design，有可能就做不出来了
而且你这种解释暴露了你对jitter和s ...
陈涛 发表于 2013-7-4 10:34

                               
登录/注册后可看大图

怎么会呢？skew 是由于时钟到不同触发器时钟端时间不同引起，跟后端时钟树相关；而jitter是时钟本身固有的抖动，它对性能始终是造成负面的影响。我预估的200ps 也主要考虑jitter等不确定因素。

overdriver

版主的意思是说你的200ps是怎么计算出来的，jitter按多少估计，公式在哪儿？ 经验值也总得有个出处。一般PLL手册都会有不同公式来计算jitter的大小。另外foundry会有一般signoff的参考，uncertainty， derate这种数值一般会有参考的。另外uncertainty和global skew有啥关系么？cts之后，所有时钟点都已经定了，STA可以不考虑这个估计值了吧。

yl5495

公式就不说了，网上到处都是。我们设计中的时钟不是来自pll。cts后，当然时钟的时序都已经确定了，但在做pt时，仍然设置uncertainty是为了设计更可靠。uncertainty 跟skew和jitter都相关，后端时钟树报告显示了最长的skew是60几个ps，说明cts之前的预估有些悲观，但考虑可靠性，就不需要再迭代了。

angangang3484

个人认为uncertainty做完cts留下来，是因为你的path group是默认的**async_default**，为了对异步时钟的check更加稳健，所以没remove。
但是我又看到rpt中是同一个clk（i_sysclk）的hold check，有些疑惑，建议查看sdc。

yl5495

个人认为uncertainty做完cts留下来，是因为你的path group是默认的**async_default**，为了对异步时钟的che ...
angangang3484 发表于 2013-7-4 13:13

                               
登录/注册后可看大图

uncertainty是我在sdc设置的，做pt当然会使用

angangang3484

回复 28# yl5495

我再查看了下你的path rpt，我猜u_init/o_cct_wl2_reg/RB是复位端，这个path是复位信号的hold check，所以放在默认的**async_default**中。既然是同一个clock的hold check，因此，uncertainty是必然要去掉的。
在cmd中加上“remove_clock_uncertainty [all_clocks]”。
原因陈涛大哥说得很清楚。

yl5495

回复  yl5495

我再查看了下你的path rpt，我猜u_init/o_cct_wl2_reg/RB是复位端，这个path是复位信号的 ...
angangang3484 发表于 2013-7-4 13:55

                               
登录/注册后可看大图

同一个clock的hold check，去掉jitter，保留skew。