Why am I Getting UITE-461 Messages and Zero Source Latency

Question:
I have a design with an incoming clock CLK that I divide by two with the following circuit:
Figure 1: Example Circuit With Divide-by-2 Logic
Here are clocks that I have defined:
create_clock -period 10 CLK
create_generated_clock \
-name CLKdiv2 \
-divide_by 2 \
-source [get_ports CLK] \
[get_pins Udiv/Q]
These clocks are reported by the report_clocks command as follows:
pt_shell> report_clocks
****************************************
Report : clock
...
****************************************
Attributes:
p - Propagated clock
G - Generated clock
I - Inactive clock
Clock Period Waveform Attrs Sources
-------------------------------------------------------------------------------
CLK 10.00 {0 5} p {CLK}
CLKdiv2 20.00 {0 10} p, G {Udiv/Q} Generated Master Generated Master Waveform Clock Source Source Clock Modification
-------------------------------------------------------------------------------
CLKdiv2 CLK Udiv/Q CLK div(2)
As you can see, I take the 10 ns clock and divide it down to 20 ns with some dividing logic. However, when I review my log file, I noticed that I am getting UITE-461 messages:
Warning: Generated clock 'CLKdiv2' 'rise_edge' is not satisfiable; zero source
latency will be used. (UITE-461)
Warning: Generated clock 'CLKdiv2' 'fall_edge' is not satisfiable; zero source
latency will be used. (UITE-461)
You can also see that the divided clock has zero source latency:
Startpoint: UFF1 (rising edge-triggered flip-flop clocked by CLKdiv2)
Endpoint: UFF2 (rising edge-triggered flip-flop clocked by CLKdiv2)
Path Group: CLKdiv2
Path Type: max
Point Incr Path
---------------------------------------------------------------
clock CLKdiv2 (rise edge) 0.00 0.00
clock source latency 0.00 0.00
Udiv/Q (FD1) 0.00 0.00 r
UFF1/CP (FD1) 0.00 0.00 r
UFF1/Q (FD1) 1.44 1.44 f
UFF2/D (FD1) 0.00 1.44 f
data arrival time 1.44
clock CLKdiv2 (rise edge) 20.00 20.00
clock source latency 0.00 20.00
Udiv/Q (FD1) 0.00 20.00 r
UFF2/CP (FD1) 0.00 20.00 r
library setup time -0.80 19.20
data required time 19.20
---------------------------------------------------------------
data required time 19.20
data arrival time -1.44
---------------------------------------------------------------
slack (MET) 17.76
There is definitely upstream propagation delay in the clock divider circuitry, but it is not present in my timing path. Why am I getting these error messages and zero source latency? Answer:
The example above describes the behavior of PrimeTime version Z-2006.12 and later. To understand what is happening, first take a look at how edge direction is handled during
the source latency calculation for generated clocks. You can then look at how the UITE-461 message can result.
How Source Latency is Computed
Consider the following divide-by-3 clock circuit:
Figure 2: Example Circuit With Divide-by-3 Logic
You can describe these clocks to PrimeTime with the following commands:
create_clock -period 10 CLK
create_generated_clock \
-name CLKdiv3 \
-divide_by 3 \
-source [get_ports CLK] \
[get_pins UOR/Z]
The -source option specifies the source sampling point of the parent clock. This results in the following generated clock relationship between the edges at the parent source input port CLK and the edges at generated clock pin UOR/Z:
Figure 3: Generated Clock Relationship of CLKdiv3 to CLK
You can see from this waveform diagram that the following types of edge relationships exist between the generated clock and its master clock:
•Rising edge at input port CLK -> rising edge at UOR/Z
•Falling edge at input port CLK -> falling edge at UOR/Z
For the divide-by-3 circuit, the following paths exist from the source input port CLK to the generated clock pin UOR/Z:
Figure 4: Possible Paths From Input Port CLK to Pin UOR/Z
The key to understanding the behavior in PrimeTime version Z-2006.12 or later, is that when source latency is computed, both the starting (source pin) and ending transition directions are considered. For the divide-by-3 generated clock above, the rise-to-rise and fall-to-fall propagation delays through the logic are used to construct the source latency
of the generated clock.
Unsatisfiable Generated Clock Specifications
Now that you understand how edge relationships apply to the source latency computation, you can visit the problematic divide-by-2 circuit from the question section again:
Figure 1 Revisited: Example Circuit With Divide-by-2 Logic
In PrimeTime, a generated clock created with the -divide_by 2 option is equivalent to the -edges {1 3 5} option. It specifies that the following edge relationships must exist between the specified source pin and the generated clock creation point:
Figure 5: Required Generated Clock Relationship for a -divide_by 2 Clock
You can see from this waveform diagram that the following types of edge relationships must exist for the -divide_by 2 generated clock:
•Rising edge at parent source -> rising edge at generated clock pin/port
•Rising edge at parent source -> falling edge at generated clock pin/port
With this in mind, you can take a closer look at the original example circuit. If you examine the actual waveforms that would be present during operation at the source port CLK and the generated clock pin Udiv/Q, you see the following:
Figure 6: Available Relationships at Source Port and Generated Clock Pin, for Example
-divide_by 2 circuit
The problem is that there is an inversion in the clock path leading to the divider flop. As a result of this inversion, only falling edges at the input port CLK result in rising or falling edges at the output of the dividing flip-flop. This means that only the following edge relationships are available in the circuit:
Figure 7: Possible Paths From Input Port CLK to Pin Udiv/q
Here, you have a case where the specified generated clock requires edge relationships that the design cannot provide. PrimeTime detects this condition and issues a UITE-461 message:
Warning: Generated clock 'CLKdiv2' 'rise_edge' is not satisfiable; zero source
latency will be used. (UITE-461)
Warning: Generated clock 'CLKdiv2' 'fall_edge' is not satisfiable; zero source
latency will be used. (UITE-461)
Because the design cannot provide the required propagation paths for this generated clock specification, zero source latency is used. The UITE-461 message should be taken seriously - as a result of the mismatch between generated clock specification and logic behavior, it is likely that the resulting analysis is incorrect. This is not a limitation of PrimeTime. Rather, PrimeTime is reporting that it has found a fundamental inconsistency between the generated clock specification and the behavior of the logic. You must compare the generated clock specification against the logic to determine whether the error exists in the generated clock specification or in the logic itself.
In the example circuit, there is a divide-by 2 flip-flop there, so some type of -divide_by 2 specification is needed. The key to resolving this issue is to recall that the parent clock
source pin (specified using the -source option) is used to determine where the clock edges of the parent are examined. To resolve the problem, move the parent clock source pin to the clock pin of the dividing flip-flop:
create_generated_clock \
-name CLKdiv2 \
-divide_by 2 \
-source [get_pins Udiv/CP] \
[get_pins Udiv/Q]
When you rerun, you now find that UITE-461 message is no longer issued and the propagation path is shown in the timing report as expected:
Startpoint: UFF1 (rising edge-triggered flip-flop clocked by CLKdiv2) Endpoint: UFF2 (rising edge-triggered flip-flop clocked by CLKdiv2)
Path Group: CLKdiv2
Path Type: max
Point Incr Path
---------------------------------------------------------------
clock CLKdiv2 (rise edge) 5.00 5.00
clock CLK (source latency) 0.00 5.00
CLK (in) 0.00 5.00 f
U1/Z (IV) 0.58 5.58 r
Udiv/Q (FD1) (gclock source) 1.47 7.05 r
UFF1/CP (FD1) 0.00 7.05 r
UFF1/Q (FD1) 1.44 8.49 f
UFF2/D (FD1) 0.00 8.49 f
data arrival time 8.49
clock CLKdiv2 (rise edge) 25.00 25.00
clock CLK (source latency) 0.00 25.00
CLK (in) 0.00 25.00 f
U2/Z (IV) 0.58 25.58 r
Udiv/Q (FD1) (gclock source) 1.47 27.05 r
UFF2/CP (FD1) 0.00 27.05 r
library setup time -0.80 26.25
data required time 26.25
---------------------------------------------------------------
data required time 26.25
data arrival time -8.49
---------------------------------------------------------------
slack (MET) 17.76
You can even see from the launch at 5 ns and the capture at 25 ns that you correctly model the generated clock launching off the falling edges of the parent clock. You can confirm this by examining the CLKdiv2 waveform reported by using the report_clocks command. For example,
****************************************
Report : clock
...
****************************************
Attributes:
p - Propagated clock
G - Generated clock
I - Inactive clock
Clock Period Waveform Attrs Sources
-------------------------------------------------------------------------------
CLK 10.00 {0 5} p {CLK}
CLKdiv2 20.00 {5 15} p, G {Udiv/Q}
Generated Master Generated Master Waveform Clock Source Source Clock Modification
-------------------------------------------------------------------------------
CLKdiv2 Udiv/CP Udiv/Q CLK div(2) Another Interesting Example
Here is another interesting example that might not be obviously incorrect at first. You have an unconventional divide-by-4 circuit that is structured as follows:
Figure 8: Example Divide-By-4 Circuit
Rather than using sequential cell-based clock dividing logic, this circuit uses cascaded clock-gating NAND cells and a state machine to gate the output clock waveform high and low at key times to perform waveform shaping. The clock gating controls nLO and nHI are active-low, where nLO toggles on the falling edge of CLK and nHI toggles on the rising edge of CLK. The resulting shaped waveform is a divided-by-4 version of the original source clock:
Figure 9: Required Edges for Example Divide-By-4 Circuit
Initially, it might seem reasonable to specify this clock simply as a typical -divide_by 4 clock:
create_generated_clock -name CLKdiv4 \
-divide_by 4 \
-source [get_ports CLK] \
[get_pins U2/Z]
However, when you generate a timing report using this generated clock definition, you see a problem:
Startpoint: UFF1 (rising edge-triggered flip-flop clocked by CLKdiv4)
Endpoint: UFF2 (rising edge-triggered flip-flop clocked by CLKdiv4)
Path Group: CLKdiv4
Path Type: max
Point Incr Path
---------------------------------------------------------------
clock CLKdiv4 (rise edge) 0.00 0.00
clock CLK (source latency) 0.00 0.00
CLK (in) 0.00 0.00 r
Udiv2/CP (FD1) 0.00 0.00 r
Udiv2/Q (FD1) 1.44 1.44 f
U2/B (ND2) 0.00 1.44 f
U2/Z (ND2) (gclock source) 0.85 2.30 r
UFF1/CP (FD1) 0.00 2.30 r
UFF1/Q (FD1) 1.44 3.74 f
UFF2/D (FD1) 0.00 3.74 f
data arrival time 3.74
clock CLKdiv4 (rise edge) 40.00 40.00
clock CLK (source latency) 0.00 40.00
CLK (in) 0.00 40.00 r
U1/A (ND2) 0.00 40.00 r
U1/Z (ND2) 0.20 40.20 f
U2/A (ND2) 0.00 40.20 f
U2/Z (ND2) (gclock source) 0.85 41.05 r
UFF2/CP (FD1) 0.00 41.05 r
library setup time -0.80 40.25
data required time 40.25
---------------------------------------------------------------
data required time 40.25
data arrival time -3.74
---------------------------------------------------------------
slack (MET) 36.51
You see that the launch (slow) side of the setup path has a generated clock path that incorrectly goes through the sequential cells that source the gating signals. To avoid this, you can set the following variable that prevents the generated clock path tracing from tracing back through clock gating enable signals:
set timing_clock_gating_propagate_enable false
For more information on how clock and data paths are controlled by this variable, see SolvNet article 015769. Unfortunately, after these gating paths are removed from the source latency traceback, you get the UITE-461 message:
Warning: Generated clock 'CLKdiv4' 'fall_edge' is not satisfiable; zero source
latency will be used. (UITE-461)
Why are you getting this message?
You have specified this generated clock as a "-divide_by 4" clock, which is equivalent to a generated clock specified with the -edges {1 5 9} option. Such a divide-by-4 clock
defines a 50/50 duty cycle divided clock that requires a rise-to-fall edge relationship from input port CLK to generated clock pin U2/Z. However, the logic provides only a positive-unate (non-inverting) path from input port CLK to pin U2/Z, such that no rise-to-fall edge relationship is available. In this case, specifying a -divide_by 4 generated clock definition was actually incorrect, because the clock circuitry does not create a standard 50/50 duty cycle divided clock. This was a serious error with the generated clock specification that PrimeTime has caught. If this problem had gone uncorrected, you would have had incorrect slack computations for paths between rising-edge and falling-edge flip-flops, or incorrect signal integrity results for the falling edges of CLKdiv8 acting as victims or aggressors in the clock network.
The solution here is to correct the generated clock specification so that it matches the circuit behavior:
create_generated_clock -name CLKdiv4 \
-edges {1 4 9} \
-source [get_ports CLK] \
[get_pins U2/Z]
You can see that the -edges specification is lifted right from the waveform diagram above. With this corrected generated clock specification, the update_timing command completes without warnings/errors and you get exactly the generated clock waveform behavior you needed for CLKdiv4:
****************************************
Report : clock
...
****************************************
Attributes:
p - Propagated clock
G - Generated clock
I - Inactive clock
Clock Period Waveform Attrs Sources
-------------------------------------------------------------------------------
CLK 10.00 {0 5} p {CLK}
CLKdiv4 40.00 {0 15} p, G {U2/Z}
Generated Master Generated Master Waveform Clock Source Source Clock
Modification
-------------------------------------------------------------------------------
CLKdiv4 CLK U2/Z CLK edges( 1 4 9 )
The clock paths in the timing report are also as expected:
Startpoint: UFF1 (rising edge-triggered flip-flop clocked by CLKdiv4) Endpoint: UFF2 (rising edge-triggered flip-flop clocked by CLKdiv4)
Path Group: CLKdiv4
Path Type: max
Point Incr Path
---------------------------------------------------------------
clock CLKdiv4 (rise edge) 0.00 0.00
clock CLK (source latency) 0.00 0.00
CLK (in) 0.00 0.00 r
U1/A (ND2) 0.00 0.00 r
U1/Z (ND2) 0.20 0.20 f
U2/A (ND2) 0.00 0.20 f
U2/Z (ND2) (gclock source) 0.85 1.05 r
UFF1/CP (FD1) 0.00 1.05 r
UFF1/Q (FD1) 1.44 2.49 f
UFF2/D (FD1) 0.00 2.49 f
data arrival time 2.49
clock CLKdiv4 (rise edge) 40.00 40.00
clock CLK (source latency) 0.00 40.00
CLK (in) 0.00 40.00 r
U1/A (ND2) 0.00 40.00 r
U1/Z (ND2) 0.20 40.20 f
U2/A (ND2) 0.00 40.20 f
U2/Z (ND2) (gclock source) 0.85 41.05 r
UFF2/CP (FD1) 0.00 41.05 r
library setup time -0.80 40.25
data required time 40.25
---------------------------------------------------------------
data required time 40.25
data arrival time -2.49
---------------------------------------------------------------
slack (MET) 37.76 Debugging Tips
It can be difficult to trace through a real design to determine why the generated clock specification does not match the logic. The best tool for debugging this is the
arrival_window attribute on pins and ports. These attributes are available by default in PrimeTime SI, but must be enabled in PrimeTime runs by using the following at the beginning of your script:
set timing_save_pin_arrival_and_slack true
To understand how this attribute can be useful, you can apply it to the original test case. First, query the attribute at the clock input port CLK:
pt_shell> get_attribute [get_ports CLK] arrival_window
{{{CLK} pos_edge {min_r_f 0 NA} {max_r_f 0 NA}}
{{CLK} neg_edge {min_r_f NA 0} {max_r_f NA 0}}}
Each major entry in this list contains four pieces of information:
1.Clock name
2.Polarity of original reference clock edge event
3.Min-delay rise/fall arrival values
4.Max-delay rise/fall arrival values
At the CLK input pin, you have two major entries - one for the pos_edge of CLK, and one for the neg_edge of CLK. You can see that the pos_edge entry has only numerical values for the rising arrivals, with NA (no arrival) for the falling arrivals. Similarly, the neg_edge entry has only numerical values for the falling arrivals, with NA for the rising arrivals. This informs you that only the non-inverted sense of the clock exists at this point.
Now, check the arrivals at the negative edge-triggered divider flip-flop output:
pt_shell> get_attribute [get_pins Udiv/Q] arrival_window
{{{CLK} neg_edge {min_r_f 2.04616 2.0853} {max_r_f 2.04616 2.0853}}} Here you can see that both rising and falling edge arrivals are available, but only as a result of a neg_edge event on the source clock. A falling edge of the source clock can result in both a rise and fall at this pin because the flip-flop can launch either a 0-1 or 1-0 transition at its Q output.
Here are some other examples of arrival window attribute values for different types of transformations to a clock waveform:
•Positive-unate (non-inverted) sense:
•{{{CLK} pos_edge {min_r_f 1.21 NA} {max_r_f 1.23 NA}}
•{{CLK} neg_edge {min_r_f NA 1.26} {max_r_f NA 1.28}}}
Here we can see that only rising edges exist as a result of a pos_edge event at the
master, and falling edges exist as a result of a neg_edge event. This describes a
positive-unate sense.
•Negative-unate (inverted) sense:
•{{{CLK} pos_edge {min_r_f NA 1.22} {max_r_f NA 1.24}}
•{{CLK} neg_edge {min_r_f 1.25 NA} {max_r_f 1.27 NA}}}
Here we can see that only falling edges exist as a result of a pos_edge event at the
master, and rising edges exist as a result of a neg_edge event. This describes a
negative-unate sense.
•Both positive-unate (non-inverted) and negative-unate (inverted) senses:
•{{{CLK} pos_edge {min_r_f 1.21 1.22} {max_r_f 1.23 1.24}}
•{{CLK} neg_edge {min_r_f 1.25 1.26} {max_r_f 1.27 1.28}}} Here we can see that a pos_edge event at the master results in both rising and
falling edges at this pin, meaning that both non-inverting and inverting paths
arrive at this pin. Likewise, a neg-edge event at the master also results in both edge directions at this pin.
•Output of positive edge-triggered clock divider flip-flop:
•{{{CLK} pos_edge {min_r_f 1.21 1.22} {max_r_f 1.23 1.24}}} The divider flip-flop triggers only on the rising edge (pos_edge) of the master clock, but a flip-flop can launch both a rising or falling edge at its Q output. As a result, we see only events launched by a pos_edge event at the master, but this pos_edge event can result in both rising and falling edges at this pin.。