卧槽，发现不止一个信号这样，还有一个信号，直接在顶层，就是clk_out=clk_in这样一句（输出引脚等于输入引脚），也在IOOBUF这里产生了大概4ns延迟。。。
--
FROM 115.220.225.*

赞，牛逼。
我为了追求低延迟
把io输出约束到2ns.
反倒造成-4ns的slack
我把这些约束取消掉
反倒没有违约了，
奇怪。。。
【 在 haoboy 的大作中提到: 】
: 大概率是你的约束写的不对
--
FROM 39.183.38.*

io本身有延迟很正常，实在不行可以把那个寄存器挨着io最近的位置放置。这样布线只有唯一通路的话怎么约束都无所谓了。这样做有两个好处：延迟最短，每次综合后延迟变化不大，比较稳定
【 在 rliw 的大作中提到: 】
: 我有一个寄存器信号，从子模块直接连到顶层模块，然后就直接输出了，  
: 中间没有任何逻辑，但时序分析后，在管脚的IO_BUF里产生了4ns的延迟，  
: 造成时序违约。  
: set\_output\_delay已经设置了，哪怕设置成0延迟，能减少一点slack，  
: 但还是违约。  
:
: ..................

发自「今日水木 on CLT-AL00」
--
FROM 106.121.160.*

你就设一下呗，别太离谱的
【 在 rliw 的大作中提到: 】
: 不知道我我能否查看取消掉约束后，实际的延迟
: 是多少。我感觉不是没检查。。
: 【 在 veriloghdl 的大作中提到: 】
: ...................
--来自微水木3.5.11@PCT-AL10
--
FROM 101.40.138.*

兄台，
我把所有输出io的set_output_delay取消掉，
时序违约没有了，只是时序报告里列出了“unconstrained output ports”

但只要我把输出io的set_output_delay一加上去，
不管是加多大的延迟，还是多小的延迟，都造成整个系统的时序大面积违约。

其实这些输出io对整个系统来说是次要逻辑，负责输出状态啥的
要求不严格的，
我把这些约束都取消掉了，
但程序跑起来数据有随机错乱，
逼得我又回头来看是不是这里有问题，按说这些输出io不涉及核心
不该对数据有影响才是。。。
现在就是吃不准了，要加上set_output_delay又会整个系统时序违约。
头疼。。。

【 在 veriloghdl 的大作中提到: 】
: 你就设一下呗，别太离谱的
--
FROM 183.157.108.*