关于工程上的多时钟周期约束的若干问题。

qiurijian

我现在还有一个问题想向大家请教：
就是多时钟周期约束的负面作用是什么？

真正在硬件上进行时序检查，我发现用的最多的就是多时钟周期约束，setup不满足，就根据setup见红的时间大小宽松几个相应的时钟周期，同理对于hold不满足，就根据hold见红的时间大小宽松几个相应的时钟周期；我的说法没有问题吧。

副作用：约束错误了怎么办（只是简单的把见红的地方约束没有了）？我遇到的问题是功能仿真效果挺好的，跑到板子上抓一下波形，简直错的离谱，我怀疑是约束造成了严重的问题，另外我正在筹划重新功能仿真一下，因为我有做程序移植。

点开report timing summary，接着点开见红的setup(假设见红setup是-1.75ns),对应的有问题的路径一般会有好多条，选择第一个有问题的路径，右击选择set multiple path，下级菜单又有两个选项，第一个是startpoint to endpoint,另一个是source clk to destination clk,该选哪个呢，我感觉选source clk to destination clk麻烦少一些，我选了source clk to destination clk之后出现一个对话框，这里又有分流，source clk 和 destination clk是不是同一个时钟（假设时钟同步），是同一个时钟的情况下，假设这个时钟周期是0.5ns,那么显然setup 应该设置成4（setup宽松3个时钟周期），由于是同一个时钟所以start 和end选项没有意义，之后再点第一条路径把hold设置成3（hold宽松3个时钟周期，有没有必要呢，hold不红的话），之后应用观察是否约束成功了。假如是慢到快时钟加一个end就行了，快到满加一个start就行了，但是应该把setup 还有hold设置成多少才对呢？

时序约束一直无法很好的 理解，希望有大神给高屋建瓴的讲一下，结合我上面提到的应用中遇到的问题。

yujuntao

个人理解，设置多周期约束是针对那些launch clock打出的数据，不要求在下一个capture clock必须锁存的路径，和set_false_path比较像
从你描述的情况来看，你是要在下一拍使用前一个寄存器打出来的数据，简单地设一个多周期约束，从时序报告上来说slack是消除了，但是对于你的系统来说，功能依旧是不满足的

qiurijian

回复 2# yujuntao

我觉得与set false path不一样，我觉得set multiple path更像是流水线，过程可能有所增加，但是结果不应该有问题，比如进入一个组合逻辑的数据一个时钟只能出不来，可以把setup宽松一个周期，之后就读到了。

yujuntao

回复 3# qiurijian


    是的，但是你要确保你下个时钟出不来的结果不会影响你系统d的设计;而不是说看到有路径不满足时序，就设一个multicycle

qiurijian

回复 4# yujuntao
谢谢您的回复。
说的有道理，重新更改设计感觉难度一下子大了好多，好不容易功能仿真过了，结果时序不满足，又要重新调整结构，难之又难。。。
另外您认为set multiple path是怎么影响到系统的功能的？我在这里理解的不是很清楚。