- 主题:借人气，有没有大拿熟悉FPGA时序约束的？
我有一个寄存器信号，从子模块直接连到顶层模块，然后就直接输出了，
中间没有任何逻辑，但时序分析后，在管脚的IO_BUF里产生了4ns的延迟，
造成时序违约。
set_output_delay已经设置了，哪怕设置成0延迟，能减少一点slack，
但还是违约。
这个寄存器信号本身逻辑简单，没有多少优化空间，延迟集中在io_buf这里，
感觉无处下手呀，
--
FROM 115.220.225.*
卧槽，发现不止一个信号这样，还有一个信号，直接在顶层，就是clk_out=clk_in这样一句（输出引脚等于输入引脚），也在IOOBUF这里产生了大概4ns延迟。。。
--
FROM 115.220.225.*
赞，牛逼。
我为了追求低延迟
把io输出约束到2ns.
反倒造成-4ns的slack
我把这些约束取消掉
反倒没有违约了，
奇怪。。。
【 在 haoboy 的大作中提到: 】
: 大概率是你的约束写的不对
--
FROM 39.183.38.*
不知道我我能否查看取消掉约束后，实际的延迟
是多少。我感觉不是没检查。。
【 在 veriloghdl 的大作中提到: 】
: 没约束了，自然没有违约，不检查了呗
--
FROM 39.183.38.*
多谢
【 在 veriloghdl 的大作中提到: 】
: 你就设一下呗，别太离谱的
--
FROM 49.78.21.*
兄台，
我把所有输出io的set_output_delay取消掉，
时序违约没有了，只是时序报告里列出了“unconstrained output ports”
但只要我把输出io的set_output_delay一加上去，
不管是加多大的延迟，还是多小的延迟，都造成整个系统的时序大面积违约。
其实这些输出io对整个系统来说是次要逻辑，负责输出状态啥的
要求不严格的，
我把这些约束都取消掉了，
但程序跑起来数据有随机错乱，
逼得我又回头来看是不是这里有问题，按说这些输出io不涉及核心
不该对数据有影响才是。。。
现在就是吃不准了，要加上set_output_delay又会整个系统时序违约。
头疼。。。
【 在 veriloghdl 的大作中提到: 】
: 你就设一下呗，别太离谱的
--
FROM 183.157.108.*
rtl图？
逻辑有点复杂，而且巨大，看起来有点儿费劲
【 在 whotwho 的大作中提到: 】
: 综合出的电路图展开看看
--
FROM 39.183.37.*
收到，多谢
【 在 whotwho 的大作中提到: 】
: 布局布线后的，看IO附近
--
FROM 115.198.95.*
cylone iv e系列。
report timing比较恶心，会误导人
最开始我有io输出约束的时候，
显示在io端口，iobuf里产生了最多的延迟
问题是iobuf是最基本的fpga单元了吧？
看走线的跨度也不大，
这还怎么搞？
无意中把io的set-input-delay约束去掉，
才把原来的违约去掉，
但又出现未约束的路径警告。
但好歹没有致命警告了
【 在 StrongLeg 的大作中提到: 】
: 什么型号器件？贴report_timing报告？
:
: #发自zSMTH@TAS-AL00
--
FROM 115.198.95.*
赞，
我也试试。
我每次编译倒是都能通过，
但是数据过一段时间就会偶尔随机错一个数据
以前约束过io的，虽然时序的slack负很多
但是还是稳定的。。。
【 在 dansen 的大作中提到: 】
: 我也有遇到过这问题，x家的K7, output_delay max设成0了还是无法满足时序要求（差不到1ns），设成负数不行，输出路径主要的延时在时钟bufg和输出obuf上，但是约束了确实有效果，不约束会出现这次编译没问题，下次编译有问题的情况，后面用set_clock_uncertainty -setup -from [get_clocks usb_clk_i] -to [get_clocks clk_virt] -1加1ns让它不报错。
--
FROM 115.198.95.*