网站建设 博客,晨曦云主机,膜结构行业做网站,做网站是不是要域名费#x1f4a1; 回顾基于RTL逻辑时序优化的基本思路#xff0c;在关键路径中插入寄存器来优化时序 分析最坏路径 通过前面对TimeQuest软件的理解#xff0c;基本上可以找到关键路径#xff0c;此文章主要对关键路径时序进行优化#xff0c;使设计达到时序要求#xff0c;以… 回顾基于RTL逻辑时序优化的基本思路在关键路径中插入寄存器来优化时序 分析最坏路径 通过前面对TimeQuest软件的理解基本上可以找到关键路径此文章主要对关键路径时序进行优化使设计达到时序要求以TFT屏驱动为案例介绍插入寄存器优化时序的方法
图1 将TFT驱动模块设为顶层模块将TFT_CTRL设置为顶层之后ctrlL对工程进行全编译
图2 TTF_CTRL设置为顶层模块全编译之后打开TimeQuest读取网表Read SDC之后查看最高频率为270.12MH显然无法达到默认时钟1000MHZ但是这就是设计的最高频率了不能在提升了当然可以提升。
图3 time quest查看最大时钟频率查看最坏传输路径
图4 查看最坏路径可以在报告界面直接选中 vcounter[2]这个节点然后鼠标右击依次选择“Locate- Locate in Design File”来定位到该路径对应在代码中的位置如下图所示
图5 查看最坏路径对应的代码点击后软件会自动跳转到代码的第 85 行如下图所示。在此可以看到vcount_r的变化是受 hcount_ov 和 vcount_ov 控制的而 vcount_ov 则是跟随 vcount_r 的值变化的。所以起点和终点就都找到了。
图6 最坏路径对应代码在上述路径中vcount_r 信号要想影响到 vcount_r 的变化首先是经过一级组合逻辑构成的比较器在该比较器中与一个常量vline_end做比较当两者相等时输出为 1其他情况下为 0输出的信号名为 vcount_ov。vcount_ov 的值才来决定 vcount_r 的值是否变化因此整个传输路径可以总结为下图
图7 最坏路径传输模型通过上图可以看到vcount_r[3]要驱动 vcount_r[2]发生变化。中间一定要经过一级组合逻辑既然经过了组合逻辑就一定会引入组合逻辑延迟。而且整个的路径其实不止这一个组合逻辑事实上vcount_ov 有效后具体 vcount_r[2]是否发生变化还与 vcount_r 这个寄存器中的其他位的值相关所以理论上应该是 vcount_ov 信号还会再进入下一级组合逻辑中参与运算然后才能最终决定 vcount_r[2]的值是否发生变化。这个组合逻辑在图中被放置在了与 D 触发器 vcount_r[2]同一个 LE 内这种情况下理论来说延迟是最小的但是事实上很可能这个组合逻辑并不会与 D 触发器 vcount_r[2]放置在同一个 LE 内那样的话延迟就更大了。所以整个传输路径中至少有 2 级组合逻辑延迟因为加入了产生 vcount_ov 这个信号的组合逻辑导致传输延迟变长了。既然这样只需要将vcount_r[3]到 vcount_r[2]之间的组合逻辑减少应该就能提升最大运行时钟频率了。
RTL 级路径优化 如何优化路径呢优化路径的指导思路又是什么呢其实思路很简单核心思路就是减少寄存器到寄存器之间的组合逻辑链路。本例中 vcount_r[3]要驱动 vcount_r[2]中间至少经历两级组合逻辑如果能够将寄存器到寄存器之间的组合逻辑数量减少一级是不是就能提升运行的时钟频率了呢 vcount_r[3]的输出传递到 vcount_r[2]首先是经历了一级 LUT 实现的查找表然后查找表的输出再进入另一个查找表最后才到达 vcount_r[2]那么如果能够让第一级查找表输出后也经过 D 触发器后再送往下一级查找表那么整个路径就被切为了两段每段路径都只包含 1 级组合逻辑了那样的话传输延迟就会小很多了。如下图所示
图8 最坏路径优化模型通过此图可以看到vcount_ov 不再是直接由 LUT 直接输出而是 LUT 之后马上进入了该 LE 的 D 触发器中再由 D 触发器输出。也就是说此种方式是在原本的时序路径中插入了一级寄存器从而将原本较长的组合逻辑链路路径切割为了两段较短的组合逻辑路径。从而让寄存器到寄存器之间的传递组合逻辑延迟更短提升了系统运行频率。 看上去好像很有道理的样子那这个操作在原本代码工程中该怎么修改才能实现呢其实方法非常简单只需要将 vcount_ov 的产生语句改为时序逻辑即可当然不要忘记了将该信号的定义也由 wire 改为 reg。具体修改内容为 1、 代码 49 行“wire vcount_ov”改为“reg vcount_ov”如下图所示 图9 修改vcount_ov类型2、代码 94 行对 vcount_ov 的 assign 赋值语句采用注释的方式屏蔽掉加上新的时序逻辑描述的代码如下图所示
图10 修改Vcount_ov处代码这里将组合电路改为时序电路vcount_ov 是会延迟一个时钟周期的为什么不把条件vcount_r vline_end 改为vcount_r vline_end -1去弥补这一个时钟周期因为 vcount_r 的变化不是每个时钟都有可能的只有在 hcount_r 每计满一次才会变化一次所以这一个时钟周期的延迟没有影响。 那么上述操作真的就能提升系统性能吗能提升多少呢这个嘛就可以通过修改设计后重新编译再对设计进行时序分析来知晓了。全编译之后再看一下结果如下所示
图11 优化结果300.48MHZ哈哈一顿操作猛如虎之前是270.12MHZ现在是 300.48MHZ提升了近 30MHzZ了。 首先来说经过这一波操作确实没有明显提升最大运行主频但是这并不代表此方法错了或者说此方法是没用的只能说操作还没完。时序分析和约束的过程是一个“约束—分析—再约束/修改—再分析”的往复循环的过程一次操作只能解决部分问题当执行了修改之后也许之前的关键路径解决了但是马上又会有新的路径成为关键路径需要再对新的关键路径进行分析直到最后满足设计需求或者再也无法优化。既然如此那就继续分析吧看看经过修改之后成为新的影响系统运行时钟频率的关键路径是哪个。 通过查看 Worst-Case Timing Paths 下面的 Setup ‘Clk9M’选项可以看到此次 vcount_r到vcount_r的这条路径已经没有提示时序余量为负了甚至都没有出现在Worst-Case Timing Paths 里面那么这里我想留个疑问在这里供有心的童鞋去思考此时hcount_r 到 vcount_r的余量是多少该怎么看或者问个更意外的问题该条路径是否还在本笔记不对该问题作答仅供有心的童鞋去思考。 此次 vcount_r 到 vcount_r 的这条路径已经没有提示时序余量为负了时序余量最小的路径是hcount_r[4]到 vcount_r[3]该路径时序余量为-2.328。
图12 优化后的最坏路径如上图定位到该路径相关的代码位置经过分析发现vcount_r 的计数条件除了和 vcount_ov相关以外还和 hcount_ov 相关而 hcount_ov 的产生方法和 vcount_ov 的完全一致也是使用的组合逻辑直接产生的。 既然这样那就借鉴前面优化 vcount_ov 的思路使用同样的方法把 hcount_ov 也优化了既把 hcount_ov 的产生也改写为时序逻辑。 1、 代码 48行“wire hcount_ov”改为“reg hcount_ov”如下图所示
图13 修改hcount_ov信号类型2、代码 79 行对 hcount_ov 的 assign 赋值语句采用注释的方式屏蔽掉加上新的时序逻辑描述的代码如下图所示
图14 修改hcount_ov处代码至于图中为啥是 hpixel_end – 1 而不是原来的 hpixel_end 因为这是寄存器输出会有一个时钟周期的延迟所以为了和之前没有修改的时序一致需要提前一个时钟周期产生该信号。 全编译之后再看一下结果如下所示 图15 优化后系统最坏路径最坏路径的时序余量为-1.518ns则Fmax 1 / (Tclk - Tslack) 1 / (1 – (-1.518)) 397.1406MHZ 再看下报告里的 Fmax Summary也是一样的值 图16 优化后系统最大时钟频率此时hcount_r 到hcount_r的延迟已经不能够依靠更改RTL代码进行优化了只能通过更改触发器内部结构才能继续优化但是这已经不是用户该考虑的问题了
总结 到此为止已经优化到了一个比较高的程度了要再优化就要从计数器的结构入手了通过修改计数器的结构来优化这就很烧脑了。对于当前这个代码能在 Cyclone IV E 上跑出 393MHz 的频率相信大家已经很满意了。所以呢关于优化的内容讲到这里也就基本差不多了。方法很简单也就是常说的插入寄存器大法。
