时序图对路径

时序图是PrimeTime使用的整个设计的时序数据库的术语。
此数据库是在首次读取netlist并链接设计时创建的。
在定时更新期间，此数据库将填充来自延迟计算的时序值。
更新时序后，将在REPORT_TIMING、REPORT_CONTRAINT和REPORT_MIN_PULSE_WIDTH命令期间使用图中的时序信息。
由于图表示整个设计，所有可能的时序路径都包含在图中。

图的名称来自于将设计表示为节点图。
设计中的端口和引脚成为图形中的节点，时序圆弧成为节点之间的连接。
可以用节点图的形式表示上一个图形示意图，如下图所示：

图存储设计中所有时序弧的最小和最大时序数值，以及其他信息(例如案例分析值、是否禁用弧等)。
PrimeTime中的基于路径分析功能从图中提取任何时序路径，并对该特定路径的执行更精确的时序分析：

对于图，必须能够检查它上面的任何时序路径，并且与路径的实际物理时序相比，图时序必须是保守的。
要理解这一点，首先看图时序是如何计算的。
这将帮助理解边界最小/最大图的重要性，并探索基于路径的分析如何改进图的边界时间。

图摆率(slew)传播

必须计算图上所有时序弧的最小/最大，上升/下降时间值。
当沿edge正向在逻辑中传播时，执行延迟计算。
如果我们计算缓冲链（单入单出）上的时间，我们只需将每个阶段的输出转换到下一个阶段，执行延迟计算，并在沿方向传播时将结果存储在图上。
然而，当同一点有两个不同的slew时，像PrimeTime这样的静态时序分析工具必须选择其中一个slew向前传播，这样它才能继续对下游逻辑进行延迟计算。
最常见的情况是多个时序弧终止的单元的输出引脚。
一种情况是单元的输入引脚，有多个net弧(可能由三态驱动程序驱动)终止。必须选择SLEW的这些点称为SLEW合并点。

在输出点合并例子：

在这个例子中，弧(A)和(B)每个弧都导致一个到达输出引脚U1/Z的唯一slew。哪一个slew从U1/Z向前传播到U2/A？这是一个重要的选择，因为选择的转换也决定了下游逻辑单元U2和U3的延迟和转换时间。
为了确保最小/最大图值始终限制最快和最慢的时间，必须选择最差的转换并向前传播。
对于最小延迟，这是最快(数值最小)的转换；对于最大延迟，这是最慢(数字最大)的转换。
对于示例电路，将传播较快的转换(B)正向以计算最快(最小延迟)定时，而将较慢的转换(A)正向传播到U2/A以计算最慢(最大延迟)时间。
看一下此设计的完整图形，并检查如何计算最关键的最大延迟路径。

在这里，可以在整个图的上下文中看到示例门U1。
显然，最关键的最大延迟定时路径将是从FF2启动的路径，因为该路径上的缓冲区比从FF1启动的缓冲区多三个。
但是，请记住，需要在U1/Z(从U1/A到达)处传播慢切换，以确保U2和U3的下行定时行为尽可能慢：

REPORT_TIMING命令从FF2查看图形路径时，U2和U3的时序比从FF2启动的路径运行中设备的实际物理时序要慢。
如果查看从FF1启动的路径的图形时序，则路径上的延迟和slew将与实际的物理时序相关联。
从这个例子中，可以看到，在一个设计的时序图表示中有内在的悲观。
对于真实的物理设备，一个时序弧可以有多个时序行为，这取决于引起其转换的上游逻辑。
然而，图表示允许每个时间弧只有一个最小/最大上升/下降时间行为-如果尝试为每个可能的上游路径存储一个值，可能会有数千或数百万个值存储在每个圆弧上，从而导致不可能的内存和运行时要求。
对于通过此弧的所有可能的上游路径，单个弧时序值不可能都是正确的！
由于只能为每个圆弧选择一个用于所有路径的单个时序值，现在我们可以理解为什么这个图值必须是安全的保守的。

重新计算时序路径

PrimeTime中基于路径分析功能提供了从图中提取感兴趣的时序路径并对其执行更详细的时序分析的能力。
这个过程被称为路径重新计算，因为我们采用的是图形路径，并为其重新计算新的时序行为。
有三种方法可用于重新计算以提高路径时序的精度：
延迟计算使用路径特定的slew沿单元和网络重新计算新的时序。
这导致了特定于该路径的精确的单元延迟和净延迟，以及这些精确计算带来的沿电阻网络的slew减少。
在下一个示例中，我们可以看到，我们正在通过合并点传播更快的SLEW，尽管到达合并点的其他图侧输入的SLEW速度较慢。

因为考虑的是单一路径，所以不再需要沿路径传播到达窗口。
相反，可以沿路径传播一条边，并且只考虑这条边上的信号完整性效应。
这可以减少或消除在图的最差转换分析中必须保持和考虑的串扰增量延迟。
在下图的左图中，可以看到上受害者到达窗口与下攻击窗口重叠，导致在常规信号完整性分析期间串扰增量延迟减缓。
相反，在最右边的图中基于路径分析中考虑单个边缘时，现在看到这个单一的受害者边缘位于攻击者窗口之外，因此不会受到串扰延迟的影响。

由于只关注单个受害者边缘(而不是完整的受害者窗口)，因此可能会错过可能出现的增量延迟。
请记住，重新计算路径的时间只与该路径相关。
对于给定的网络，如果重新计算通过该网络的所有时序路径(每条路径都有自己的到达时间，并且在网络上有slew特征)，那么就能够探索整个可能的受害者到达空间，并由此产生该网络的增量延迟结果。

图必须沿网传播最慢的最大延迟转移时间。较慢的slew更容易受到串扰延迟效应的影响。路径特定的slew只能比我们的最坏情况下的图slew更快，这进一步减少了仍然存在的任何串扰耦合的影响。
在下图中，基于路径的分析得到的受害者slew率(右)比由最坏slew图(左)计算的上限更快。
因此，在基于路径的分析中，较尖锐的受害者边缘不太容易受到串扰延迟效应的影响。

在图上，用于路径的CRPR值可以是悲观的，最高可达到变量TIMING_CRPR_Threshold_ps指定的阈值。重新计算路径时，将精确地重新计算该路径的CRPR值，有效阈值为零。
这可以在保持时间路径上提供显著的改进，即使是很小的CRPR改进也可以将许多违反图形路径的路径转化为经过重新计算的路径。
CRPR根据以下规则应用于重新计算的路径：

pba_recalculate_full_path	behavior
false	exact CRP computed using graph timing
true	exact CRP computed using PBA timing

重新计算路径的图时序通常会改善路径的slack。
对于路径的发射和捕获部分，最大延迟时序可以变得更快，最小延迟时序可以变得更慢。
但是，重新计算路径的slack并不会使路径的slack变得更差。
这是因为在图的计算过程中非常小心，以确保其最小/最大时间始终是保守的。
在图上，弧只能有一组时序值，这些值用于通过弧的所有图形路径。
由于基于路径分析，每条路径通过弧时，同一时序弧可以具有不同的延迟和slew特性。
在下图的示例中，看到U1的延迟/转换行为对于每个重新计算的路径都是唯一的。

默认情况下，不会重新计算启动和捕获时钟路径。
可以通过将pba_recalculate_Full_Path变量设置为true来启用时钟路径计算。
这有助于为正在分析的路径提供更多的slack改进。
但是，如果设计中的时钟引脚有多条时钟路径，则必须小心。
每个时序路径对象只添加一个时钟路径，并且在应用重新计算后，它可能不是最差的时钟路径。此警告也适用于基于锁存的借用路径。

请注意，基于路径的分析不能在SDF流程中使用。SDF本质上是存储在文件中的设计时序基于图的表示。这些SDF定时注释是固定的，并且primetime没有执行延迟计算所需的详细寄生信息。因此，基于SDF的流程有一个限制，即所有时间路径都必须具有这种固有的基于图形的悲观，而基于路径的分析不能用来消除这种悲观情绪。
这也是为什么基于路径的时序不能写回SDF文件的原因，时序弧可以在每个路径中具有不同的基于路径的时序，但SDF文件要求只写出一组值。

路径特定重新计算

最基本的基于路径的分析选项是REPORT_TIMING和GET_TIMING_PATHS的-PBA_MODE PATH选项，它只需从设计中获得指定的路径，对每个路径执行路径重新计算，并报告或返回重新计算的时序路径集。
这称为路径特定的路径重新计算；在较早版本的primetime中，这是使用get_recalculated_timing_path命令执行的。
以下是路径特定重新计算和报告的示例：
report_timing -to $endpoint -pba_mode path
还可以使用两种方法中的一种对时序路径集合对象执行重新计算。
可以直接获取重新计算的路径对象：
set recalc_path1 [get_timing_paths -pba_mode path -to $endpoint]
或者，我们可以先得到未重新计算的时间路径，然后合适的时候重新计算：
set path2 [get_timing_paths -to $endpoint]
set recalc_path2 [get_timing_paths -pba_mode path $path2]

这两种方法产生了相同的结果。
第一种方法更容易使用，但当需要在脚本中比较未重新计算和重新计算的slack时，第二种方法可能很有用。
当特定于路径的重新计算与-SLACK_LESSER_THAN一起使用时，重新计算的路径可能具有大于阈值的slack：

这是预期的行为。
使用指定的slack阈值从图中获取路径，然后重新计算并报告路径。

穷尽型重新计算

基于路径的分析可以在给定的路径上提供一定程度的slack改进。
但是，前面的手动示例中的命令不足以确定到兴趣端点的最坏可能路径。重新计算了最坏的图路径得到一定程度的松弛改进。
但是，如果次劣的图路径在重新计算过程中经历了较少的松弛改进，使得它现在成为到端点的最差的重新计算的路径，该怎么办？
为了理解这一点的复杂性，让我们来看一下以下逻辑锥：

这是一个从一个乘法器输出位向前推的逻辑锥。可以立即看到有多条到达端点的路径。但是，到达端点的唯一路径有320条，这一点可能并不是很明显。
影响路径数量的一些因素包括：

• 路径起始点的数量。
• 分别考虑上升边缘和下降边缘。
• 重定向扇出(分开的路径，然后一起返回)。
• 非单调性门(具有反转和非反转圆弧的门，如异或门)。
  若要找到到达某个端点的最坏重新计算路径，必须重新计算到该端点的多条路径，并搜索最坏的重新计算slack。
  这一过程被称为“剥洋葱”，因为必须依次考虑每一条路径，然后才能到达它后面的那条路径，就像剥掉洋葱上的层一样。
  幸运的是，PrimeTime使用一种称为基于路径的穷尽分析(PBA)的功能自动执行所有这些工作。
  使用穷举PBA非常简单，只需将-pba_mode穷举选项添加到所需的REPORT_TIMING或GET_TIMING_PATHS命令：
  report_timing -pba_mode exhaustive -max_paths 5 -nworst 2
  Primetime执行所有的重新计算和洋葱剥皮路径搜索工作，并提供结果最差的重新计算路径。

穷尽的PBA搜索比图搜索花费的时间更长。
使用图搜索时，不需要进行延迟计算，因为图中已填充了边界时序数值。
计算图形路径的松弛只是使用现有图形时间值执行计算的问题。
只需几秒钟，就可以轻松地获得数百万条图形路径。
穷尽PBA搜索所需的运行库比图形搜索所需的运行库要多得多。
重新计算每个路径时，延迟计算引擎(如果启用了信号完整性，则包括增量计算)必须重新计算路径上的每条弧。
基于路径的分析精度的提高伴随着必须重新计算每条路径中时序弧延迟的代价。

关于优化使用的建议

下面是一些示例命令，用于演示基于路径的分析的使用。

要快速了解重新计算，请使用-pba_mode路径选项：
report_timing -pba_mode path
此手动命令不执行路径搜索；只需重新计算并返回路径。
这将很快返回，并为重新计算的松弛提供了一个很好的概貌，但在设计中可能存在更糟糕的重新计算松弛的路径。

报告每个路径组中使用穷举PBA重新计算的单个最差设置路径：
report_timing -pba_mode exhaustive
-max_path和-nworst的默认值为1，这将导致仅返回每个路径组中的单个最差重新计算路径。默认情况下，将在所有路径组中搜索该组中最差的重新计算路径-甚至没有违规者的路径组。为了避免在这些正向松弛路径组上花费运行时，只能搜索违反路径。
report_timing -pba_mode exhaustive -slack_lesser_than 0

报告使用穷举PBA重新计算保持时间故障的所有端点:
report_timing -delay_type min -pba_mode exhaustive
-slack_lesser_than 0 -max_paths 1000000 -path_type end
我们使用松弛阈值来限制报告失败的重新计算路径。
通过使用-max_path值以及default-nworst值1，搜索将向每个端点返回重新计算的最严重路径hold violation。

请注意，在最后两个示例中，搜索在某种程度上受到约束-在第一个示例中，搜索被限制为隐式-max_path 1，在第二个示例中，搜索被限制-SLACK_LESSER_THAN 0。限制搜索范围有助于保持路径搜索的大小合理。
如果要执行涉及路径组中每个端点的广泛路径搜索，请执行以下操作：
report_timing -pba_mode exhaustive -max_paths 1000000

这将需要非常非常长的时间，因为数以百万计的路径，跨越所有的路径组将被搜索和重新计算。强烈建议不要通过将Timing_Reduce_Parallel_Cell_Arcs变量设置为False，否则会禁用平行弧减少。
开启此功能减少了搜索空间中通过平行圆弧的次关键路径的数量，从而可以显著加快对具有平行圆弧的逻辑的搜索速度。
注意：当与穷举PBA一起使用时，-unique_pin选项可以带来乐观的结果，这是因为-unique_pin是在图形路径获取中深度实现的，以提高效率。
只获得沿每个引脚序列的一条路径，并提供给穷举搜索。
由于不同的上升/下降转换敏感性，PBA的改进可能会有所不同，并且由于沿路径的所有上升/下降边缘配置都没有传递给路径搜索，搜索不完整，因此存在乐观的可能性。
建议在穷尽PBA的情况下使用最差的平行弧特征来代替-unique_pin。
当使用穷举PBA时，PrimeTime还会检查是否有其他设置可以改善穷举PBA性能。
如果是，它们将显示在uite-479消息中：
正如在解释穷尽PBA搜索工作原理的SolvNet文章中所描述的，搜索运行时受到两个因素的影响：

• 重新计算松弛改进的数量。
• 路径的松弛密度。
  考虑使用PBA_EXHAUSTIVE_ENDPOINT_PATH_LIMIT变量。

为了在信号完整性分析中获得最佳性能，建议使用All_VIOLATING_PATH对齐模式来改进运行时。在PrimetimeX-2005.06中引入的这个特性使图形时序更接近基于路径的时序，从而显著地改进了穷尽pba的运行时间。

可以打开状态消息以在穷尽PBA路径搜索过程中显示进度：
set timing_report_recalculation_status high
当使用-pba_mode穷举选项发出穷举PBA路径搜索时，您将看到搜索状态消息：
Information(nworst 1, max_paths 100): recalculating group clk…
Information: finished_endpoints 0, total_endpoints 4, recalculated_paths 4
Information: finished_endpoints 2, total_endpoints 4, recalculated_paths 6
Information: recalculated_paths 10
Information: finished_endpoints 2, total_endpoints 4, recalculated_paths 10
Information: finished_endpoints 2, total_endpoints 4, recalculated_paths 18
Information: recalculated_paths 20
Information: recalculated_paths 30
Information: finished_endpoints 3, total_endpoints 4, recalculated_paths 30
Information: finished_endpoints 4, total_endpoints 4, recalculated_paths 38
Information: Recalculated 38 paths and returned 4 paths for group ‘clk’. The
maximum number of paths recalculated at an endpoint was 24.
还可以使用get_timing_path命令来了解穷尽PBA路径搜索的上限有多大。
考虑前面示例中的命令:
report_timing -delay_type min -pba_mode exhaustive -slack_lesser_than 0
-max_paths 1000000
为了确定可以重新计算多少条图路径以完成此搜索的上限，可以获得满足此松弛条件的所有图路径。
set paths [get_timing_paths -delay_type min -slack_lesser_than 0
-max_paths 9999999 -nworst 9999999]
echo "Path count: [sizeof_collection $paths]"

如果使用松弛阈值报告到单个端点的最差路径，需要很长时间，请考虑进行ECO更改，以改进此端点的。
对端点松弛的小改进可以极大时序地减小松弛阈值所导致的复杂锥的搜索空间大小。
下面是另一个向端点报告最差重新计算路径的示例：
report_timing -pba_mode exhaustive -to $endpoint

若要确定此命令的路径搜索空间的上限，可以发出：
set paths [get_timing_paths -to $endpoint
-max_paths 9999999 -nworst 9999999]
echo "Path count: [sizeof_collection $paths]"

为了进一步限制搜索，一次分析单个路径组是可取的。
这可以通过使用-group选项来完成。
可以使用以下命令查看设计中的路径组：
query_objects -truncate 0 [get_path_groups {*}]

默认情况下，不会重新计算时钟和借用路径。
此行为由pba_recalculate_fullpath变量控制，该变量默认为false。
重新计算借用锁存器和某些类型的CRP重新收敛时钟路径可能导致不完全穷尽PBA路径搜索。
如果设计不包含这些构造，则可以将此变量设置为true，从而以运行时为代价实现额外的重新计算松弛改进。

小结

基于路径的分析可以显著提高特定感兴趣路径的准确性。
改进的机制(在隔离其他路径的情况下计算路径的特定计时)正是基于路径的时序不能标注回图的原因。
当重新计算定时路径时，新的特定于路径的延迟和SLEW将被放置到重新计算的路径上。
新时序仅存在于重新计算的Timing_Path对象上，并且不会注释回图上。
对于重新计算的路径，将重新计算精确的CRPR值(有效的Timing_crpr_Threshold_ps为零)。
为了获得最佳的精度，必须使用详细的寄生。
如果使用SDF，则基于路径的分析无法重新计算任何计时圆弧，因为SDF注释是固定的。
SDF是设计时序的固定图形表示，它禁用了基于路径的分析的好处。
详尽无遗的PBA使您很容易安全地搜索您的设计，寻找最糟糕的重新计算的感兴趣的路径。
使用-pba_mode穷举选项的REPORT_TIMING和GET_TIMING_PATHS都可以使用此功能。
请记住，穷尽的PBA搜索可能需要时间。
不要草率地发布详尽的PBA报告。
如果只查找冲突，请使用-SLACK_LESSER_THAN 0。
如果只对某个路径组感兴趣，请使用-group指定该路径组。
如果您只对设计的某个部分感兴趣，则可以使用-from/-to, 将分析限制在该部分。
对于信号完整性分析，请对减少的穷尽PBA运行时使用All_VIOLATED_PATH对齐模式。
将Timing_Reduce_Parallel_Cell_Arcs变量设置为默认值true，以避免不必要的路径搜索。
如果要在重新计算中包括时钟路径，请将pba_recalculated_full_path变量设置为true，并使用-path_type Full_Clock_Extended选项。
如果存在危险的重新收敛时钟路径，或重新计算借用锁存路径，则此变量应保持其默认设置为false。