set_input_daley

set_input_delay -min到底有什么用?set_input_delay -max是为了满足建立时间，那么set_input_delay应该是为了保证满足保持时间吧?为什么在做timequest分析时序的时候只是用了set_input_delay -max没有时序违例，但是加上了set_input_delay -min就是出现了setup违例呢?而且为什么是setup违例?

这是图，上升沿和下降沿双沿采样。
下面是约束文件
set_input_delay -add_delay -max -clock [get_clocks {rgmii_rxclk}]  0.500 [get_ports {rgmii_rxctrl}]
#set_input_delay -add_delay -min -clock [get_clocks {rgmii_rxclk}]  -0.500 [get_ports {rgmii_rxctrl}]
set_input_delay -add_delay -max -clock_fall -clock [get_clocks {rgmii_rxclk}]  0.500 [get_ports {rgmii_rxctrl}]
#set_input_delay -add_delay -min -clock_fall -clock [get_clocks {rgmii_rxclk}]  -0.500 [get_ports {rgmii_rxctrl}]
当我把set_input_delay -min加上的时候回会在下降沿触发器的前面多一个逻辑块，这我能理解。但是多了一块让我奖励时间违例，我TM搞不懂。哦，前提是数据在进入触发器前没有任何组合逻辑。

set_input_delay,用于约束输入端口信号在芯片外面的虚拟组合逻辑延时。-max和-min分别代表外部最长组合逻辑路径以及最短组合逻辑路径。
正常而言，对于最短路径，即-min，最小也只能等于0，就是完全没有组合逻辑；但是，可以考虑一种情况，外部用于产生rgmii_rxctrl信号的寄存器，它的时钟和你内部用于采样的时钟相位不一致，而是相对内部相位提前了0.5ns，那寄存器输出信号自然也提前0.5ns，现在假设寄存器输出信号还是维持原样，那就相当于说外部有一个虚拟的组合逻辑，它将rgmii_rxctrl提前了0.5ns，等价于这个组合逻辑的delay为负的0.5ns。这其实是灵活骗工具的一种约束，-min为负一般是过约束。
做hold检查的时候会使用-min，假如信号进来后内部没有任何组合逻辑，直接进入寄存器的D端，即使寄存器对hold时间需求只有0ns，显然内部就至少需要补偿0.5ns的buffer做delay。
回头看setup，使用-max，此时data path上的路径，除了外部的0.5ns，还要加上内部增加的这部分组合逻辑延时了。从而可能导致出现你说的setup不满足的情况。
上面解释的是原因。出现这个问题，你需要确认的是，自己的这个约束值是否合理。

   我使用set_input_delay -max ......是没有setup违例的，我同时使用set_input_delay -max..........和set_input_delay -min..........才出现setup违例。按理说，添加了这个最多出现hold违例，怎么会出现setup违例呢?

额，我以为我上面说的已经足够清楚了。简而言之，加了-min为负的约束，导致综合时内部多出了buffer逻辑，增加了数据delay，更容易出现setup违例了。

   我看了这个是多了个逻辑，我也知道，但是他为什么不弄个延时小点的逻辑，这样就不会违例了啊?难道没有更小的了?还是其他什么原因?

用延时小点的逻辑可能hold又无法满足了。按你目前给的约束，很可能是setup和hold无法做到同时满足，所以我才说要你确认自己给的这个约束值是否合理。

   没有道理啥，输入前没有任何逻辑，这个值完全是能保证 的啊

   把setup的timing report贴出来看看

   

   

中间插入的组合逻辑这个延时也太大了点吧

表示无法看懂你的report，没有类似DC的report timing报告显示出路径上每个cell的delay，以及setup要求和clock cycle之类么?
那你就别浪费时间在为什么加的组合逻辑延时这么大问题上了。还是回到自己下的约束问题上，-min设置-0.5是否合理，毕竟这个属于过约束。约束设置多少不是随随便便写的值，你要依据自己的实际情况给。如果说-min设置-0.5是设计必须的，那只能说你的电路达不到这个要求，跑不了这么快。

   好像很有道理