问:一个FPGA设计项目需要用哪些评判标准来检验?
时序收敛,即Timing Closure,意思是使设计的各项时序指标能满足设计前所制定要求。因此,整个过程分为两部分:
制定时序要求通常是由整个系统电路的外部环境来决定的,比如:
总结以上各种需求情况,得出FPGA芯片对外的三种时序约束:
有了以上三种约束类型,就可以描述外界的任何可能条件,并清楚的对最终设计需要满足的时序要求作出说明,FPGA实现工具就会依据此要求进行布局布 线,并试图满足要求。Xilinx有许多文档对怎样书写时序约束进行了说明。在此要强调的一点是:时序约束首先是对外界环境的一个反映,其次才是对布局布 线工具的要求。时序约束向工具说明上游器件所给的信号是怎样的,下游器件又要求怎样的输入,FPGA实现工具才好依照此标准来综合、布局、布线,时序收敛 的设计才可能在真正的电路环境中正常工作。
这里有一个误区需要澄清:多数人认为Timing约束是写在UCF文件中的,其实UCF中的Timing约束只有在布局布线过程中才起作用。为了达 到最好的时序性能,我们应该从综合开始就使用约束。不管是Xilinx XST,还是Synplify或者其他综合工具都可以添加时序约束。在综合过程就添加时序约束可以使综合器努力综合出合适的网表,这样在布局布线时就更容 易满足时序要求了。
设计时序不收敛通常有以下的现象:
如果降低时钟速率能让FPGA工作正常,而Timing报告又没有显示时序错误,那么有足够的理由怀疑时序约束没有完全约束到所有片内路径,需要仔细研究并完整约束整个设计。
那么设计中的Timing Error我们该怎么解决呢?最简单的,两眼一抹黑,让工具解决:把map, par等工具的effor level提到最高,但通常情况下对结果的提升是不明显的。我们需要有选择地针对不同的情况使用不同的方法。以下来分析几种常见的情况:
通过在FPGA Cross Probing中找到这根net。如果输入输出距离的确比较长,那么是由于Place问题造成的,要解决Place问题,需要检查为什么工具会把两个LUT/FF放得那么远,是相关的逻辑布局问题,还是因为引脚锁定导致无法移动逻辑的问题。
常用的解决方法可以对前级寄存器做复制寄存器的操作。参考Xilinx AR9410。
如果是因为输入/输出端连接的寄存器被Pack到IOB中导致寄存器无法移动,那么可以使用IOB=false约束将寄存器放在Slice Logic中。
如果是LUT到LUT的层次太多,那么可以先使用XST的register balancing功能。如果还是无法满足,可能需要手动调整组合逻辑,在中间插一级寄存器,并修改其他相关的代码,使得相关数据的latency一致。 其他方法参考Xilinx AR9417。如果是进位链太长,那么就要考虑使用两个小一点的计数器/加法器级联。当考虑到进位逻辑是纵向排列的,当超出一列时,进位会导致延时变长很 多时,更需要注意进位链的长度。
Hold Violation通常都是由Gated Clock引起。检查设计中没有使用门控时钟。门控时钟通常会由计数器分频产生。尽量都使用FPGA提供的时钟资源,尽量使用DCM做deskew。
首先必须保证offset写得是正确的。
然后保证输入/输出数据一进FPGA就用寄存器打一拍,中间不要加组合逻辑。寄存器Pack到IOB中能最大限度得保证Offset约束被满足。(同理,如上所述,不把寄存器放在IOB中将有利于Period约束。)
如果还是满足不了,可能需要调整一下时钟和数据的相位。可以使用DCM Phase Shift调整时钟相位或IDELAY调整数据相位。
在制定Pinout时可以有意地将一组总线按内部IOB的位置排列,低有效位在下方,高有效位在上方,而不是按外部Pinout的位置排列。
如果以上方法都已经使用并且离目标还差一点点,那么可以试图使用工具的某些属性,比如:
map * Timing Driven Packing * Effort Level, Extra Effort * Global Optimization * Allow Logic Optimize Across Hierarchy * Combinational Logic Optimization * Cost Table par * Effort Level * Extra Effort
也可以使用MPPR或Xplorer跑多次实现挑最好的结果。
如果所有的尝试都无法满足先前制定的时序目标,那么可能是时候重新考虑一下目标是否合理了。
文章评论(0条评论)
登录后参与讨论