FPGA面试题【时序不过怎么办】

1：如果设计验证和测试已经接近尾声，偶尔进行小改可能出现几条时序违例的情况 这个时候就不建议通过修改代码来进行优化了，首先在设计验证和测试几乎完成的情况下，证明你这套逻辑已经经过了层层考验，不会出什么问题。如果这个时候还通过改功能模块来优化时序有可能引入新的不确定因素，还得花很多时间来验证才行。 在这个时候一般的做法是多开几个策略来进行综合或者布局布线。举个简单的例子，因为只是偶尔会出现时序不过的情况，假设概率为0.3。那么如果有3个策略同时编译，则3个都不过的概率就变成0.027了。这样只要哪个策略时序通过了我们就用哪个策略生成的结果即可。

2：逻辑级数过大引起的某些路径经常性违例 有时候几乎每把编译都是那几个路径爆红，很有可能就是那几条路径组合逻辑级数实在是太多了，有时候组合逻辑的逻辑级数甚至到了十几级，这个时候就最好优化一下了。在组合逻辑中间插入一下触发器来降低整体逻辑级数一般就能解决这个问题。

3：扇出过大 首先这个最有可能出现的就是复位信号了，因为大部分童鞋都喜欢用 Always @(posedge i_clk or negedge i_rst_n) 这种写法了。甭管什么逻辑，实现啥功能，都先来一个这样的帽子。 这样就引出了一个问题，i_rst_n是整个工程扇出最大的信号了。这个特别是资源用的比较多得时候就会暴雷了，每次时序违例都是一大堆跟i_rst_n有关的。但绝大多数时候我们的功能是不需要i_rst_n复位的。因此在这里还是强烈推荐大家不用在FPGA设计中使用复位。在资源用的很多的时候这个问题会更加明显。 那这是复位信号可以删掉，如果是其他功能信号呢。 如果是无法忽略的信号，那要么就做 （1） 逻辑复制，以增加资源来减少扇出。 （2） 或者某些情况下我们了解其信号特性，并不需要下一个时钟周期就做出响应的话，可以使用multicycle约束。这样，触发器之间的时延就可以成倍增加了，大大缓解了其布线压力

4：资源拥塞 某一块的逻辑功能特别大，组合逻辑也多，但又不太容易优化，只能说我们在设计的时候不要引入太多不必要的一些控制信号，这里有一个控制集的概念:

触发器中的Flip-flops和flip-flop/latches有着相同的控制信号，CLK，SR, CE等等。那么对用户来说最重要的事情就是尝试着减少用户设计中的控制信号的数量。用户需要加强对控制信号的行为的理解：所有Flip-flops和flip-flop/latches共享所有这些控制信号，这些控制信号主要是时钟，置位和复位。如果一个组中的一个flip-flop用了时钟使能信号，那么所有其他的Flip-Flop必须使用相同的时钟使能或者不用时钟使能。如果一个组中的一个flip-flop用了置位或者复位信号，那么所有其他的Flip-Flop必须使用相同的置位或者复位信号。 这也是经常会出现的资源使用过多得时候，编译不过时vivado会提示的一个错误，但实际上FF和LUT的资源利用率又没有这么高，因此在设计的心里就要有这个意识，尽量减少控制集，例如都不用复位，而不是有些用有些又不用之类的。 例如我之前看到一篇文章，里面有一个这样的题目：

5：vivado版本过低 赶紧把你的vivado升级到最新的，实际上还有一个最大的变量就是，你的时序还跟vivado软件的布局布线的内部算法有很大的关系。每次更新版本有可能在这方面做一些改进，有可能之前版本解决不了的时序问题，到了后面的版本就没有了，这点其实也是经常有的事。

大范围时序违例，时序违例路径成百上千。用了上述的一些方法不管用 碰到这种情况是比较头痛的了，这意味着你的设计有可能无法达到既定要求。当前的时钟和资源利用率已经超出了片子的承受范围。这种情况下无法通过小修小补就能让时序收敛，只能从整个方案设计来看是否有妥协的办法。 (1) 最直接的办法只能是降时钟频率了，头痛医头脚痛医脚嘛，时序不过，说明目前设计时钟频率过高。但大部分情况下是不能这么降系统时钟的，降系统时钟很有可能意味着整体性能的下降，很可能出现无法达成既定指标的情况。 (2) 审视所有功能模块，看看所有模块的数据吞吐量是否有不同的情况。例如我之前弄过FPGA暴力破解算法。A模块是接口模块和路由通路，B模块是解密核心算法。B模块的时钟快慢决定性能的好坏，因此B模块时钟越快越好。但B模块运算时间较长，因此不要A模块这么快的速度传递数据。因此A模块时钟可以用更慢的时钟。 这样比A/B模块都用一个时钟对于时序的压力会减轻。当然这只是一个例子，每个不同的功能都要进行具体的分析，有些是可以优化的，有些的实在没办法就只能从性能上进行取舍了。

总结 时序和资源就是一个矛盾体。当资源利用率不高的时候，可能啥问题都没有。一旦资源利用率上来了，各种问题就暴露了。因此需要在设计的时候就注意上述提到的点，例如扇出、逻辑级数等，再后面就很可能能减少这类时序问题。