请教时序约束问题

set_input_delay,
假的，只是不报而已
set_max_delay起点到终点的最大延时

Reset设置为false path?但set_max_delay你设置完成后，查看这条路径，你就会发现他是在你设置的值处作为数据的锁存时间，这个怎么解释呢?比如FF之间，你设置两个触发器之间的set_max_delay为10，你发现发送沿还是时钟，但锁存时间成了10ns,这个怎么理解啊?

路径的起点到终点，你是怎么设的起点?起点列表是FF吗?那起点是从CK开始算的。
不是false path,就是约束reset相对clk的相位关系，把它当clk时钟域的普通input。只是让不报removal recovery而已

异步Reset?端口过来的Reset?还是Sync后的?

异步复位如果有同步撤离，那工具自然会分析，不用特别约束。
set_max_delay的原始用法是：在有setup关系的路径上，用设置的值替代原基准值。比如时钟是200MHz，那FF1到FF2之间的setup基准就是5ns。你对FF1到FF2设置set_max_delay 3ns，那FF1到FF2之间的setup基准会变成3ns，相当于单独要求FF1到FF2可以跑到333MHz。
set_max_delay还可能有一些引申用法，但每家工具的定义都不太一样。为了避免出问题，我不会使用引申用法。
在set_max_delay的原始用法下，在没有setup关系的路径上设了是不会有任何效果的，比如组合逻辑节点到组合逻辑节点。

1、在综合时，复位一般设置false_path+ideal_network，不检查时序。因为PR物理实现的时候会重做复位树，在前端优化复位结构没有意义。所以不检查时序
2、set_max_delay是一种timing execption，所谓时序例外
和multicycle/false_path一样，比正常的基于时钟沿的setup/hold时序检查拥有更高的优先级，其约束的是点到点的最大延时，即逻辑延时超过约束值被认为是时序违反；对应的set_min_delay用来约束逻辑最小延时，即逻辑延时小于约束值时认为是时序违反。
一般对一些特殊信号的传输延时有要求时，可用上述两条命令约束
STA中，可用上述命名检查延时是否达标，不符合要求则会报VIO

     感谢大家的解答，楼上两位大神说的让我豁然开朗，其中有一次在做约束的时候，建立时间不满足，FF之间组合逻辑的延迟假设是15ns,满足要求是13ns,当时我想把此FF之间的组合逻辑减少到13ns之内，于是我设置了set_max_delay 10ns，然后我发现组合逻辑的延迟到了12ns,但是锁存沿为我设置的10ns,还是不满足我的约束条件，但是看上去是满足了我的FF之间的建立时间检查，我重新约束set_max_delay 13ns发现FF之间的延迟变成了14ns,fuck，此时的这种现象应该怎么解决呢?各路大神帮分析一下

dingding

参考一下～～

dingding

    timme大神的这句“在set_max_delay的原始用法下，在没有setup关系的路径上设了是不会有任何效果的，比如组合逻辑节点到组合逻辑节点。”这应该是在实践中检验到的真理，记得曾经看过有一篇文档中对set_max_delay的定义是约束组合逻辑间的延迟，于是我做了类似的实验，在纯组合逻辑中对两个pin做set_max_delay，发现确实起到了作用，故意收紧约束后，组合逻辑的延迟是尽量满足你要求的减少的。

    个人猜测这个对组合逻辑的影响应该主要是布线方面的?