时序优化实验部分 V1.0

时序优化实验部分 V1.0

说明：

由目录可见，贴出的仅为时序优化的实验部分，还有理论部分仍在翻译和整理完善过程中。如果本文反响良好，则预计于1月中旬发布。本实验全程翻译altera官方提供的实验手册和工程，除了翻译外，还把原文中关于“很明显，你可以看见。。”替换成图片，毕竟无图无真相。

又官方提供实验为QuartusII 8.0平台，我使用的是10，故适当更改了一些内容，如大家使用的平台不同，稍作修改即可。

由于本文为初稿，可能翻译略显粗糙，欢迎拍板！

2010.12.31 foreveryoung

QQ：298467204

Email：sunyibin1987@hotmail.com

目录：

3.4 实例解析
   3.4.1 General Timing Optimization
     3.4.1.1 Step 1: Open project and compile
     3.4.1.2 Step 2: Run report to Analyze failing paths in TimeQuest to determine cause
     3.4.1.3 Step 3: Fix parity checking logic failures
     3.4.1.4 Step 4: Fix remaining timing failures
   3.4.2 Timing Optimization using PLLs
     3.4.2.1 Step 1: Open project and compile
     3.4.2.2 Step 2: Analyze failing path in TimeQuest
     3.4.2.3 Step 3: Add PLL and synchronization register and analyzer timing

3.4 实例解析

提供两个例子来说明如何在实际工程中进行时序优化。

3.4.1 General Timing Optimization

本例工程名lab_design，使用POS-PHY level 3连接两个系统。当数据由POS-PHY level 3 receiver接收后，“packet check”模块计算数据包是否正确。之后数据包经过FFT和一系列FIFO（使用一个外部FIFO来增加存储容量），算送给另一个设备。

本例中有三个时钟域，一个100Mhz的外部时钟域，一个195Mhz的内部时钟域，一个133Mhz时钟域（驱动外部FIFO）。

3.4.1.1 Step 1: Open project and compile

1．全编译工程。查看Compilation Report，如下图所示，Timequest Timing Analyzer目录下的Setup Summary报告SCLK时钟域出错。

3.4.1.2 Step 2: Run report to Analyze failing paths in TimeQuest to determine cause

1．打开TimeQuest ，按如下分析。

1．从Tasks栏选择Report Timing，运行一个SCLK时钟域的setup analysis report。

按如下填写：

To clock SCLK

Analysis type Setup

Paths (Report number of paths) 200

Output (Detail level) Summary

得到的报告如下，全是错误。初看可能全无头绪。

可以用以下三条建议来查找并优化时序：

3.4.1.3 Step 3: Fix parity checking logic failures

第一个需要修复的路径是驱动奇偶校验器检错电路的逻辑。

1．点击“From Node”栏，前四个列出的如下图：

右键第一条路径，选择Report Worst-Cast Path。在Statistics栏里可以看到logic level有12条，再看Data Arrival Path栏里的计算可见，这么多logic level贡献了大部分的时序违规。

2．接下来，可以通过Technology Map Viewer验证之前的分析。在Data Arrival Path右键选择Locate Path，如图。

由上图可见，在last_data和parity_error两个寄存器之间有12个logic level，这很好的验证了本章小节“3.3.1 Too many logic levels”所述情况，解决方法如下：

3．在用上述方法修正时序违规之前，有必要先确认fitter的布局没有问题。这可以通过Chip Planner查看。同样在Data Arrival Path右键选择Locate Path，选择Chip Planner。

右下图可见，本条路径中所有的nodes都在两个相邻的Logic Array Blocks（LABs）中，只有一些走线穿过其中。这是个很好的布局，所以可以确定问题处在过多的logic level上。

4．为了修复这条路径，可以增加pipeline registers。这是个可行的解决方案，因为本设计中当校验出错时，出错信息不需要立即被捕获，即延时几个时钟周期是可接受的。具体的实施步骤是在源代码中增加寄存器，减少logic level。

5．更改好源代码。

à

再次全编译。打开Timequest。选择Tasks栏下的Report Timing。按如下填写：

To clock SCLK

To [get_pins iPACKET_CHECK|parity*|datain]

Analysis type Setup

Paths (Report number of paths) 20

Output (Detail level) Summary

通过报告可以发现，本路径已经时序收敛。

3.4.1.4 Step 4: Fix remaining timing failures

1．再次从Tasks栏选择Report Timing，运行setup analysis report。按如下填写。

To clock SCLK

Analysis type Setup

Paths (Report number of paths) 200

Output (Detail level) Summary

点击“To Node”栏，可见许多时序违规的路径都有一个同样的To Node，即sop_error（packet error flag的起点），这个信号来自receiver block的FIFO地址寄存器。这表示这些时序违规可能可以一次全部修复。

右键上图第一条路径，选择Report Worst-Case Path。从Statisitcs栏中观察到logic level只有3级，故问题可能不在这里。

2．在Data Path栏中右键，Locate Path，选Technology Map Viewer。

由上图可见，本路径由一个RAM block和3级logic，说明问题不是“3.3.1 Too many logic levels”所述logic level太多。

再次观察上图，图中RAM输出的路径由3级组合逻辑组成，换句话说，总的register-to-register delay包括RAM block和3级组合逻辑。这可能是问题所在。

3．再次观察Data Path，如下图，观察第六行最大的一个延时（3.374），显示的Type是cell delay，表示这个延时是通过一个cell的延时。从Location和 Element可知，这个cell是M4K memory block。

这条路径不能像上节那样手动加寄存器，因为RAM是一个MegaCore，无法手动修改，用多周期约束可以修复这条路径，但是功能上可能会出错。

故排除上面两种方法后，可以使用物理综合的register re-timing，当然使用此功能将导致编译时间的延长。

4．打开物理综合。使能Perform register retiming。

再次全编译。打开编译报告，可见时序全部收敛。

3.4.2 Timing Optimization using PLLs

本例讲述如何使用PLL来改善时序结果，本工程实现一个二维离散余弦变换（two-dimensional discrete cosine transform：DCT）。

3.4.2.1 Step 1: Open project and compile

1．全编译工程。查看Compilation Report。打开TimeQuest Timing Analyzer栏，在Setup Summary里发现时序违规。

3.4.2.2 Step 2: Analyze failing path in TimeQuest

1．打开Timequest，按如下操作。

可见时序违规1.424ns。右键clk，选择Report Timing，Report number of paths选50，Detail level 选Summary。

由上图可知，前23条路径违规，这些路径都在输出（dct_out和data_valid）和驱动输出的寄存器之间。而且他们都超过1ns。据此可以看看输出寄存器是不是布局良好。

2．选中第一条路径，右键，Report Worst-Cast Path。

可见不是“3.3.1 Too many logic levels”所述logic level过多造成的时序违规。

3．也不是“3.3.2 Fan-out signals”所述的Fan out太多造成的时序违规。

4．也不是“3.3.3 Conflicting physical constraints”所述的物理约束冲突造成的时序违规。因为查看第五行，选中它所对应的data_valid~reg0，右键Locate Path，选Chip Planner。

下图区域为IO区，data_valid~reg0放置在IOC_X0_Y20_N1（在IO cell block中），这表示这个寄存器已经放置在离设备IO最近的位置（能保证最好的输出建立时间）。

5．也不是“3.3.4 Conflicting timing assignments”所述问题。因为本例的SDC文件中只约束了IO和clock。而如果有牵涉到此寄存器布局的内部约束，他应该是倾向于把寄存器拉出IO cell。

6．排除以上四种情况后，可以初步判断问题是在“3.3.5 Tight timing requirements”

部分引用“3.3.5 Tight timing requirements”所述内容，我们可以加多周期约束，或者重新计算时序约束以验证是不是过约束（比如output maximum delay）。本例采用的是用PLL来对output clocks进行移相。

3.4.2.3 Step 3: Add PLL and synchronization register and analyzer timing

图中的two_d_dct_new模块即原来的设计，本节在此基础上加了PLL来驱动此模块。PLL的c1输出clk_out。

1．全编译工程。从Compilation Report中的Timequest Timing Analyzer栏中可见时序都收敛了。

因为PLL可以有效减少clock tree delay，使设计中的clock-to-output时间减少，output delay时序也收敛了。

2．通过查看报告可以验证。打开Timequest，还是选择Tasks栏中的Report Timing。

To栏填data_valid；

Detail level填Full Path；

由上图可见，第7行的PLL贡献了一个-5.049ns的移相，这把data arrival time减小到足够满足设计输出的setup time时序要求。

posted on 2010-12-31 12:22 foreveryoung 阅读( ...) 评论( ...) 编辑 收藏

转载于:https://www.cnblogs.com/foreveryoung/archive/2010/12/31/1922936.html