create_clock

不知各位刚刚开始接触FPGA的童鞋有没发现，自己的工程综合，编译贼长时间了。

“废话，FPGA设计本来就很耗时间啊”

话是这么说，但如果编译理论上一两个小时就应该能结束，实际上却花了十几个小时，而且在生成比特文件的时候直接挂了。经常在完成implementaion 后，显示timing failed。

这种情况很大可能就是时钟没有做好约束。

有的童鞋可能就要问了，时钟约束到底是啥，有啥用，vivado不是保证逻辑正确就OK了吗？

create_clock -period 10.000 -name my_clk[get_ports refclk_p]
有的同学可能在写约束文件的时候会不知不觉加上类似这句话。这句话有什么用呢？

实际上是告诉编译器（比如vivado）这个port进来的信号时钟周期是这么多。

“还是不懂啊”

假如一个时钟需要驱动另外一个模块，时钟信号进入模块的时候经过一个buffer。这样就生成了经过buffer后的时钟（称之为Clk后），和经过buffer前的时钟（称之为Clk前）。那么编译器默认这两个时钟信号应该是同一个时钟源。但是由于进入的端口到buffer的走线长度，以及本身信号经过buffer产生的延迟，这两个时钟肯定不是同相的。如果工程比较复杂，经过buffer比较多，会出现什么情况呢？两个时钟的相位完全乱掉。可能Clk前状态还是高，而Clk后的状态是低。这样就会形成竞争冒险。

而约束了时钟周期后，vivado心里至少有个数，

“这个时钟频率挺高的，那我优化的时候，buffer放得离port近一些，延迟尽量低一些”

但是没啥用啊，buffer有时候必须放那么多，buffer的延迟减少不了，软件opt的时候优化了半天，route布线了半天也没啥结果。于是把Timing的结果告诉你，这里时序有点问题，但是如果你觉得没啥事情也能继续跑。

那就只能降时钟频率了？

恭喜你，没法完成甲方需求，项目经理要找你了。

这个时候怎么办呢？

干脆和vivado说，这两个时钟一点关系都没有。延迟爱多高就多高，我数据流过来的时候不照样有延迟嘛。这时候使用set_false_path把两个时钟关系给干掉就可以了。

使用上述语句的话，两个时钟虽然频率一样，但是已经不同源了。vivado布线的时候可能产生几千纳秒的延迟，但是vivado认为这个完全可以接受，因为set_false_path告诉我，这两个之间的走线不用管

但是数据流怎么保证不产生竞争冒险呢？

可以使用异步fifo。

美滋滋。

经验来说，每个模块WNS，TNS在十几纳秒内，设计都没什么问题

所以说呢，为了防止竞争冒险，有时候必须将一些数据流设计改为流水线形式，而并非并行。掌握这种设计技巧，在今后的FPGA设计中也是十分有帮助的。
————————————————
版权声明：本文为CSDN博主「非权威装家」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u010203275/article/details/80569502