• lattice简单时序报告---timing report


    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,这个延时发生在输入端口Dinpad延时

     

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

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

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

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

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

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

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

    如有疑问请联系QQ:825972925

  • 相关阅读:
    如何提高代码质量
    高效代码审查的十个经验
    代码质量管理(一)
    企业级分布式事务
    X/Open DTP——分布式事务模型
    patchca整合Spring MVC生成超炫的验证码
    兄弟,不要这样写服务器代码
    [转]预备知识—程序的内存分配
    [转]MMORPG服务器架构
    myEclipse使用有感
  • 原文地址:https://www.cnblogs.com/xiaozhuge/p/6442248.html
Copyright © 2020-2023  润新知