Analyzing Results
这部分算是最重要的一个环节了，不是因为它很难，而因为其他的文档都会跳过分析的环节。
我已经无数次看到设计者花大力气在.sdc上，但却不了解它在final analysis下是什么样的。而这个是一个很重要的技巧。因为可以完善设计者对设计的理解，并帮助设计者完善该.sdc文件。
The Iterative Methodology
当输入约束时，设计者可能会输入错误，所以希望有一个快速的修正、分析、并报告出.sdc文件错误的方法。
首先，进入TimeQuest：
首先推荐点击”Report all Summaries“：
这个操作将会执行以下命令：
1）创建Timing Netlist。默认会创建一个slow timing model netlist。如果设计这想要有一个不同的netlist，可以使用Netlist下拉菜单去 Create Timing Netlist。
2）读取SDC文档。如果有SDC文件被添加入工程（即Assignment->Setting->TimeQuest->Files），那么就被读入，否则系统会搜索和项目名称相符的.sdc文件。如果设计者修改了.sdc文件，则必须重新加载TimeQuest；
3）Update Timing Netlist接下来会将SDC约束加载到设计好的netlist中。
4）Report All Summaries命令会运行Setup, Hold, Recovery, Removal Summaries，Minimum Pulse Width 检查。这只是基本的概要分析(Device Specific checks are not run…)
一旦设计者修改了.sdc并保存后，则需要双击Reset Design。这将会退回到TimeQuest创建了netlist但还没读取SDC文件的状态。再双击 Report All Summaries 将会重新读入sdc文件并进行时序分析。
本质来说，方法如下：
1) Open TimeQuest
2) Double-click "Report All Summaries"
3) Analyze results
4) Make changes to .sdc file and save
5) Double-click "Reset Design"
6) Double-click “Report All Summaries”
7) Analyze results
8) Repeat steps 4-7 as necessary
注意这个方法仅仅是在新的约束下重新开展时序分析，但是布线（Fitter）并没有改变。布线仍然是由老的sdc约束决定的，只不过设计者使用新的约束 来分析在原来约束下的布线。所以即使时序约束报错了，那也仅仅代表这设计者需要重新运行place-and-route来重新布线。
A diving tool
之前的章节已经让设计者们运行了“Report All Summaries”，
这一操作将会运行4个主要的时序分析：
setup
hold
recovery
removal
左上角的任务框叫做Reports。
面框显示了每一个时钟域的Slack。举例来说，第五行，对于每个由sys_clk驱动的目的寄存器，最差的setup slack是6.975ns。
slack是正的，表示这些路径满足了时序要求。End Point TNS代表了所有的Toltal Negative Slack。
当然，这些仅仅是概述。想要了解更多细节，那么设计者需要右击当前行，然后选择Report Timing……
report timing 对话框弹出的时候会自动选择setup Radio并填好To clock的内容。这个例子中，10条最差的路径会被显示出来，设计者可以随意修改这里的 Tcl command 命令。
注意到，任何report_timing命令都可以从console中复制到用户自己的Tcl 文件中，所以设计者可以在将来的设计中，直接手动输入命令，而不用按这么多按钮。
report_timing
report_timing
-from <source_nodes>
-from_clock <source_clock_names>
-rise_from_clock <source_clock_names>
-fall_from_clock <source_clock_names>
-through <thru_node>
-to <destination_nodes>
-to_clock <destination_clock_names>
-rise_to_clock <destination_clock_names>
-fall_to_clock <destination_clock_names>
-setup | - hold| -recovery| -removal
-detail <summary|path_only|path_and_clock |full_path>
-file <file_name>
-append
-panel_name <report_name>
-stdout
-less_than_slack <slack_limit>
-npaths <#_of_paths_to_display> //number of paths to report; defaults to 10
-nworst <max_#_of_paths_per_endpoint>
-false_path
-pairs_only
-show_routing
TimeQuest中的report_timing命令是非常重要的一个工具。让我们看上面的那个截图，主要的选项已经显示出来了。From clock 和 To Clock可以将所选时钟的路径过滤出来。下拉菜单允许我们选择已经存在的时钟。
Targets框中的From 和To允许我们只报告特定的点到点路径，也可以使用通配符 “*”指定多路径。看下面的一个例子：
report_timing -from *|egress:egress_inst|* -to *|egress:egress_inst|* -(other options)
如果-from/-to/-through 选项是空着的，那么将被默认为“*”，即所有可能的设备对象都包含在内。
-through选项是为了限制 经过组合逻辑或特定cell引脚的路径。我的个人设计经验指出，这个是很少用到的，而且有时候用起来很麻烦。所以我一直尝试尽可能只使用- from 和-to选项。同时，在每个选项后的[……]中括号将会开启name finder，这是GUI用来找寻指定name的。这能够保证输入的name和设计中的nodes是匹配的。
我们可以去分析-setup,-hold,-recovery,-removal。这些将会在之后被讨论。
-detail 选项是一个需要被重点关注的项，它有四个options，这里只讨论其中三个。首先讨论summary，选这个只会列出概要信息，即Source Register, Destination Register, Source Clock,Destination Clock, Slack, Setup Relationship, Clock Skew and Data Delay. summary report会报告出更多的细节，如果我们不想要这些细节信息，那么可以使用summary option。一个很好的示例是，将report写到txt文档中，-detail summary可以让文档变得很简洁。
下一个level就是 -path_only。这样就能报告出所有信息，除了clock tree是被报告成一行。当设计者知道所有的clock tree 是正确的，而不想关注它的信息，则可以用这种report。我们可以看summary report中Clock Skew 这一列，如果数值很小，比如比+-150ps小，那么我们就可以认为clock tree在目标和源之间是平衡的。
如果存在时钟偏斜clock skew，那么应当使用-detail full_path来report。这样就能把clock tree的细节详细的报告出来，显示经过的每一个cell，包括input buffer，pll，global buffer（叫做CLKCTRL）等等。如果有clock skew，这样报告出来的细节就可以让设计者知道clock skew 是怎么产生的。-detail full_path选项也推荐在IO分析中使用，因为只有source clock 或者destination clock在FPGA中，其延时在满足时序要求中起了很大作用。
下面是一副对比截图，对比了-detail summary 、-detail path_only 和-detail full_path。注意到clock delay在path_only和full_path命令中都是完全相同的，只是full_path有更多的细节。
quartus II 添加了 +/- 展开功能在Data Path report中。这样我们就可以，即使在使用-detail full_path命令下，也不会被一大堆信息搞的头晕脑胀。
report_timing命令会显示出所有的路径，两点之间可能会存在许多不同的路径。同样的，一个目的地也会包含很多抵达它的路径。因为这样，设计者就可能需要列出很多很多的路径。而checkbox 选项则可以源、目的地间的一条路径。甚至可以通过限制到达目的寄存器的最大点数来过滤report。
最后，在底部，是Tcl 命令输入输出窗口。它可以显示在TimeQuest中运行的Tcl语句的语法。我经常会添加-false_path命令。这样就只有false path被列出来。
Correlating Constraints to the Timing Report
让我们接下来看看一些特定路径的时序报告，上面是setup analysis，下面则是hold analysis：
我们关注上图第一列。这里我们得到一个8ns的 setup relationship和0ns的hold relationship。中间一列，我们通过添加多周期来open the window，这样setup relationship就变成16ns，而hold relationship仍然是0ns。第三列，我们使用set_max_delay和set_min_delay命令，注意到唯一变化的是setup hold 分析时候Launch edge和latch Edge的时间点。
对于IO口的约束来说，除了要添加 -max -min的值，其他都和上面一样。
setup关系会减去 -max的值，这样就让setup relationship更难满足了，因为Data需要比之前更早到达。而-min值也是被减去的，负值让hold timing 更加严格，因为我们想让数据到达时间在数据要求时间之后。(The -min value is also subtracted, which is why a negative numbermakes hold timing more restrictive, since we want the Data Arrival Path to be longer than theData Required Path.)
/3 
用户377235 2015-10-25 22:09
用户1736901 2015-4-10 14:27
用户377235 2015-4-7 12:15
看不懂