注：原文作者为小诸葛叶，原文地址：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，对输出的数据做延时。延时报告如下，现在分析延时。

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

然后在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表示的就是布线延时，报告中还给出了最大延时的路径个时间，如下图。

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

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