Timing anomaly
The English name is Timing Exception, which can be considered a timing exception or timing exception (the term in this series of articles). "Exception" or "Exception" means that this part of the timing analysis is different from most conventional timing analysis. The following table shows the timing exception commands and functions supported by Vivado:
| command | Features |
|---|---|
| set_multicycle_path | Set the number of clock cycles required to transfer data from the start point to the end point on the path |
| set_false_path | Instruct a certain logic path in the design not to perform timing analysis |
| set_max_delay、set_min_delay | Setting the minimum and maximum path delay values will override the default establishment and maintenance constraints |
| set_case_analysis | Use logic constants or logic conversions on ports or pins for timing analysis to limit signal transfer between designs |
Vivado does not support real-time analysis of contradictory timing exceptions. You need to run report_exceptions for a complete analysis and report all timing exceptions. There are many cases of multi-cycle paths, which are more complicated, and they are described separately in Chapter 35. This article introduces the knowledge of the other three timing anomalies.
False path
Some paths that exist in the design in terms of topological structure, but do not work or do not need to be timed, are called false paths. False paths should be ignored during timing analysis. The following situations are all false paths:
- Where there is dual synchronizer logic, there is clock domain crossing
- Registers that may only be written once at power-up
- Reset or test logic
- The path between the write port of the asynchronous distributed RAM and the asynchronous read clock
Give a specific example to deepen the understanding of the false path, as shown in the figure below:
Two multiplexers MUX control the data transmission between the two registers, but the two MUXs use the same selection signal. Careful analysis will find that no matter what the data from the Q side cannot be transmitted to the D side. Although there seems to be a path between Q and D on the structure diagram, it does not serve any function, so it should be defined as a false path.
Why remove false paths in timing analysis? The reasons are as follows:
- Reduce running time : The tool does not need to time and optimize these false paths, which can reduce a lot of running time.
- Increase the quality of results : removing false paths can greatly increase the quality of results QOR (Quality of Results). The quality of synthesis, layout, and optimization design is largely affected by timing issues, because tools will always try to solve these problems. Including false paths can lead to undesirable results (for example, tools focus too much on solving false paths The timing is in violation, while ignoring the real problem that needs to be solved).
The false path is defined by the set_false_path command, the command template is as follows:
set_false_path [-setup] [-hold] [-from <node_list>] [-to <node_list>] [-through <node_list>]
The meanings of several node list options are as follows:
- -from : A list of valid starting points, including clock objects, clock pins of timing elements, input master ports or bidirectional master ports.
- -to : A list of legal endpoints, including clock objects, data input pins of timing elements, output master ports, or bidirectional master ports.
- -through : A set of legal pins or ports. It is important to pay attention to the order of the nodes. If only -through is used in the constraint, and the -from and -to options are not used, Vivado will remove all paths through the list from the timing analysis. Be careful when using it.
Here are a few examples of defining false paths:
#-through的顺序表示路径穿过节点的顺序，因此下面是两条不同的约束
set_false_path -through cell1/pin1 -through cell2/pin2
set_false_path -through cell2/pin2 -through cell1/pin1
#上图中的虚假路径应该用下面这条命令约束
set_false_path -through [get_pins MUX1/a0] -through [get_pins MUX2/a1]
#使用-through而不用-from和-to的好处是可以确保所有通过此节点的路径都会被移除，而不用考虑起点和终点
#移除复位端口到所有寄存器间的时序路径
set_false_path -from [get_port reset] -to [all_registers]
#禁用两个异步时钟域间的时序路径，从CLKA到CLKB
set_false_path -from [get_clocks CLKA] -to [get_clocks CLKB]
#注意，上述命令并没有禁用从CLKB到CLKA的路径，还需要补充如下约束
set_false_path -from [get_clocks CLKB] -to [get_clocks CLKA]
From the last example, we need to disable the timing path in both directions, but if there are multiple asynchronous clock domains in the design, it is very troublesome to write. I don’t know if you remember the clock constraint method mentioned in Chapter 31. In this case, it is better to use set_clock_groups to set different asynchronous clock groups.
The case of asynchronous distributed RAM was also mentioned above. Here is also an example of constraints. Assuming an asynchronous dual-port distributed RAM, its write operation is synchronized with the RAM clock, but the read operation is asynchronous. In this case, a false path should be set between the write and read clocks. The constraints are as follows:
#在RAM前的写寄存器和RAM后的读寄存器间设置虚假路径
set_false_path -from [get_cells <write_registers>] -to [get_cells <read_registers>]
Case analysis
In the design, some signals are constant values in specific modes, such as: (1). Some test signals will not change and are directly connected to VSS or VDD; (2). Some signals will no longer occur after power-on Change; (3). If the design has multiple functional modes, some signals are active in some modes, but inactive in other modes. These situations belong to "case analysis."
We must tell the static timing analysis engine which signals are constant values, thereby reducing the analysis range, running time and internal occupancy rate, and do not have to report those non-working and irrelevant paths. Usually, the designer uses the set_case_analysis command to declare the signals (pins and ports) as inactive. The syntax of this command is as follows:
set_case_analysis <value> <pins or ports objects>
The parameter value can be 0, 1, zero, one, rise, rising, falling, or falling. The function object can be a port, a pin of a sub-unit (leaf cell in English), or a pin of a hierarchical module. Here are two examples to strengthen the understanding of this timing anomaly.
The first example is as shown in the figure below. Clock_sel is a clock selector. The two input clocks clk_1 and clk_2 are selected and output by selecting the pin s:
if we only want to analyze one case, for example, only analyze the situation when clk_2 is selected. By setting the s pin as a constant, only clk_2 can be passed to the output port o. The constraints are as follows:
set_clock -name -clk_1 -period 10.0 [get_pins clock_sel/I0]
set_clock -name -clk_2 -period 15.0 [get_pins clock_sel/I1]
set_case_analysis 1 {get_pins clock_sel/S}
Setting a case analysis for a certain pin will cause the timing analysis on the path passing through the pin to be disabled, and no related information will be reported. The second example is shown in the figure below. BUFG_GT has a dynamic clock division control pin DIV[2:0], which is driven by other logic instead of directly connected to VCC/GND:
By default, Vivado will assume the worst possible output clock Situation, namely 1 frequency division (equivalent to no frequency division, the frequency is the highest at this time). However, if there is no DIV taking 1 in the design, it becomes an excessive constraint. In order to restrict the design more reasonably, we can perform individual case analysis constraints on the DIV[2:0] bus. For example, the worst case that may occur is DIV takes 3, and the constraints are as follows:
set_case_analysis 0 {get_pins bufg_gt_pclk/DIV[0]}
set_case_analysis 1 {get_pins bufg_gt_pclk/DIV[1]}
set_case_analysis 0 {get_pins bufg_gt_pclk/DIV[2]}
Min/max delay
The maximum delay constraint set_max_delay is used to rewrite the default setup time (or recovery time) requirements of the path ; the minimum delay constraint set_min_delay is used to rewrite the default hold time (or removal time) of the path. The syntax template of the two constraint commands is as follows:
set_max_delay <delay> [-datapath_only] [-from <node_list>] [-to <node_list>] [-through <node_list>]
set_min_delay <delay> [-from <node_list>] [-to <node_list>] [-through <node_list>]
The usage of -from, -to, and -through is the same as in the false path. If -datapath_only is added to the set_max_delay command, the clock slope will not be considered when calculating the margin. Pay attention to the following three points when using the minimum/maximum delay constraint:
- Only the maximum delay constraint is set on the path (the -datapath_only option is not used), and the minimum delay requirement on the path will not be modified. The hold time check still uses the default value, and the opposite is true. However, if -datapath_only is added, the hold time requirement on the path will be ignored.
- Usually, the constraint between the input port and the first-level register uses the set_input_delay command; the constraint between the last-level register and the output port uses the set_output_delay command (see Chapter 32 for details). But the pure combinatorial logic path between the input port and the output port can be constrained with the set_max_delay and set_min_delay commands (usually called the in-to-out I/O path).
- There is no clock relationship between some asynchronous signals, but a maximum delay constraint is required. For example, we usually use set_clock_groups to divide two asynchronous clock domains, but sometimes we need to ensure that the path delay between the two clock domains is not too high. In this case, we have to use the command combination of set_max_delay and set_false_path (because set_clock_groups has a higher priority and will replace set_max_delay, so it cannot be used together).
In addition, when constraining the minimum delay and the maximum delay, if the node selection in -from and -to is unreasonable, path segmentation will occur . Part 34 gives specific examples and explanations of path segmentation.
Disable Timing Arcs
Finally, I will introduce a special case of timing anomalies: Timing Arcs, literally translated as timing arcs. The reason why it is not separately listed as a timing anomaly is because it is inextricably related to other timing anomalies. In fact, in many cases, the timer will automatically disable certain timing arcs in order to handle some special situations, such as:
- The combinational logic feedback loop cannot be timed correctly (so it is not recommended), and the timer will break the loop by disabling a certain timing arc in the loop.
- According to the foregoing, all input data of the MUX will be transmitted to the port by default, but the selection signal of the MUX is set to a constant value in the case analysis, at this time only one data input port will be transmitted to the output port. In fact, this is achieved by the timer interrupting the timing arc from the other data port to the output port.
Vivado provides the set_disable_timing command, which can artificially interrupt the timing arc from the input port to the output port of a unit. Consider the following application scenarios:
- For example, in the case of the first example above, you can manually set which timing arc in the combined feedback loop to interrupt, instead of letting the tool complete it automatically.
- Assume that multiple clocks arrive at the input pin of the LUT at the same time, but only one clock can be passed to the output port of the LUT. At this time, the timing arcs related to other clocks need to be interrupted.
When a timing arc is disabled, all timing paths through the timing arc will not be reported in the timing analysis. Therefore, be extra careful when using it to avoid disabling the necessary timing arcs, leading to hidden timing violations or timing issues that make the design not work properly in hardware. The syntax and examples of set_disable_timing are as follows:
#语法，-from和-to只能设置为库单元的管脚名称（不是设计管脚名称）
set_disable_timing [-from <arg>] [-to <arg>] [-quiet] [-verbose] <objects>
#禁用所有基于LUTRAM的异步FIFO的WCLK到O之间的时序弧
set_disable_timing -from WCLK -to O [get_cells inst_fifo_gen/ gdm.dm/gpr1.dout_i_reg[*]]
#指定对象的所有以O管脚为终点的时序弧都被禁用
set_disable_timing -to O <objects>
#指定对象的所有以WCLK管脚为起点的时序弧都被禁用
set_disable_timing -from WCLK <objects>
#指定对象内的所有时序弧都被禁用
set_disable_timing <objects>
Use the report_disable_timing command to view all the automatically disabled and manually disabled timing arcs. Note that this list may be very large, it is best to add the -file option to save the results to a file for viewing.