Felix

技术源于积累,成功始于执着! 个人邮箱:justlxy@mail.dhu.edu.cn QQ:1576109464

4.14、静态时序分析之——Diamond时序报告分析简明教程(一)

0
阅读(247) 评论(0)

注:原文作者为小诸葛叶,原文地址:http://www.cnblogs.com/xiaozhuge/p/6442248.html

以一个简单的设计为例:

module control(din,dout);
input din;
output dout;
wire buf1 /* synthesis syn_keep=1 nomerge="on"*/;

BUFBA del1(.Z(buf1), .A(din))/* synthesis loc = "R3C4A" */;
assign dout = buf1;

endmodule

module BUFBA (Z, A);
   output Z ;
   input A ; 
   
endmodule

如上代码用了一个底层BUFBA,对输出的数据做延时。延时报告如下,现在分析延时。

1.png

在FLoorplan中放大之后找到R3C4A,如下图,这个是不包过IO管脚到pad之间的延时的路径,是单纯的布线延时和器件延时和PAD延时。

2.png

然后在Physical中放大找到对应的输入端口din,如下图

双击它,得到如下图,对比报告,如下图,就可以知道第一条延时路径了,71_pad(因为din绑定到71脚上,所以系统命名为71_pad)到71_PADDI的延时1.095ns,这个延时发生在输入端口Din,是pad延时

第二条延时是从71_PADDI出来之后到R3C4A(slice_0)输入端A0的布线延时,经过的布线路径是din_c,时间是0.694ns,下图红色的线是布线路径,下图箭头是R3C4A.A0

第三条延时是从slice_0(R3C4A)输入端A0到slice_0(R3C4A)的输出端的器件延时,即从R3C4A.A0到R3C4A.F0,延时的时间是如下图报告所示0.385ns,这部分延时发生在slice_0(R3C4A)

第四条延时是从slice_0(R3C4A)的输出端到70.PADDO(因为输出dout绑在70脚上,所以命名70.PADDO,70.PADDO对应代码的buf1)的布线延时,经过的布线路径是buf1,延时时间如报告所述是1.394ns,下图红色为布线路径。

第五条延时是从输出端的70.PADDO到dout_padd 的延时,是PAD延时,延时时间如报告所述是1.394ns,延时发生在输出端口的PAD。

我们能控制的是布线延时,器件延时和pad延时是器件物理特性我们没法控制,经过上诉几条路径分析,我们可以知道ROUTE表示的就是布线延时,报告中还给出了最大延时的路径个时间,如下图。

17.png

这只是一个最简单的延时报告,仅仅是告知FPGA由哪些东西组成,路径是怎么走的,延时是怎么产生的,延时报告是如何去看的,并没有告知如何去优化时序,因为里面除了管脚路径可以优化,其他都是器件的特性延时,是不可优化的。复杂的时序报告,就要看时序路径,看看是否是逻辑延时过长?是否是因为资源使用太多,导致绕了一大圈才把线布通?是否是逻辑级数很多?是否是扇出很大?是否是工具不灵光,资源MAP分散,导致路径过长,延时过长?

所以解决时序问题的前提是会看时序报告,分析延时来源。解决的手段是:修改代码,工具优化,工具约束