时序约束常识问题

菜鸟学习fpga

各位大佬，请问实际工程当中，当一个FPGA程序实现的时候时序收敛了，还有必要继续优化，提升时序裕量吗？如果要继续提高时序裕量，是为什么，好处是什么？

eric_firebird

实际没太大必要提高余量。当然，前提是原来的约束已经有一定的余量。余量太大，虽然不会像ASIC那样额外消耗芯片面积，但功耗上升是必然的。

Love24

完全没有必要。

菜鸟学习fpga

eric_firebird 发表于 2022-6-16 08:51
实际没太大必要提高余量。当然，前提是原来的约束已经有一定的余量。余量太大，虽然不会像ASIC那样额外消耗 ...

“一定余量”大概是多少呢，比如我现在要做100M的时钟约束，最终约束后，实际模块最大可以运行103M,是否就可以不继续优化了呢？

innovation

这个问题，我给你的建议是先换个角度看：如果我要继续提高时序裕量，坏处是什么？
因为我只了解xilinx的FPGA，所以后面的理解都是基于xilinx的。
就xilinx的FPGA设计来说，其实时序裕量不是设计输入，是设计输出，也就是说我们通过时序约束告诉xilinx的工具软件，我们要什么，然后它执行并报告结果，如果结果不符合我们的预期，我们再修改/调整约束，如此叠代。。。所以，xilinx的文档中关于这个问题的描述，就是查看它文档中关于Over-Constraints的描述：
1）Ug612相关：

2) Ug903相关

3) Ug945相关

所以，我理解xilinx其实想对用户说：“你如果非常清楚你的设计在各种条件下的需求，并能精准而完备的通过约束文件告诉工具软件，那么你可以约束到恰好就够了，不必过约束”。

我们做到了“非常清楚设计需求”、设计了“精准而完备”的约束文件，获得了什么呢？较少的软件编译时间。

那么，就xilinx的FPGA设计而言，如果你要求了更高的时序约束，除非是不现实的要求（我想你100M的设计，要求到120M不会是不现实的），那么坏处就是需要等软件多跑一会儿，就不知道你能否接受了。当然，也可能你当前的代码设计，约束超过100M后，时序不能收敛？

!5236860

观看留言，学习学习

weiyishh

我只说我们实际应用情况，工具只要时序通过了，哪怕0.001ns的正slack，我们都认为这个版本是OK。再优化代码，或者优化结构，可能会更容易跑出时序OK的版本。工程状态很临界的时候，需要跑多个种子，才能跑出几个可以用的版本时，肯定有必要继续优化。优化肯定是没问题的，有时间有精力搞搞肯定更好。对我来说，如果后续没有太大的升级，当前版本有个0.1ns以上的余量，基本就不会管了。

菜鸟学习fpga

weiyishh 发表于 2022-6-17 08:50
我只说我们实际应用情况，工具只要时序通过了，哪怕0.001ns的正slack，我们都认为这个版本是OK。再优化代码 ...

好的，感谢解答。

菜鸟学习fpga

innovation 发表于 2022-6-16 20:01
这个问题，我给你的建议是先换个角度看：如果我要继续提高时序裕量，坏处是什么？
因为我只了解xilinx的FPG ...

大致收获我想要知道的了，意思是在目标时序收敛的条件下，过度约束几乎是没有必要的。我开发的平台也是xilinx的，目前100M的目标频率已经达到了，十分感谢回答

innovation

菜鸟学习fpga 发表于 2022-6-17 16:20
大致收获我想要知道的了，意思是在目标时序收敛的条件下，过度约束几乎是没有必要的。我开发的平台也是xi ...

我想，跟我想表达的意思还是有点儿出入。

我们不应聚焦于我们给了软件一个约束需求，软件报告时序收敛了，这个结果是否可信。而应聚焦于我们是否考虑了我们的设计在各种环境下的运行需求？我们是否添加了足够精细的约束条件？简单说吧，你给出100M的约束，如果你的设计实际运行的系统时钟就是100M，那么，我认为约束目标是不够的。我的建议是：
1）你实际要跑100M，那么你的设计目标最好能定到120M，所有的约束以120M条件下为基础
2）如果你约束到100M，且设计的时序是收敛的，而实际运行时钟低于80M，通常来说，应该是够的。