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 LogicHere are clocks that I have defined:create_clock -period 10 CLKcreate_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 clockG - Generated clockI - Inactive clockClock 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 sourcelatency will be used. (UITE-461)Warning: Generated clock 'CLKdiv2' 'fall_edge' is not satisfiable; zero sourcelatency 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: CLKdiv2Path Type: maxPoint Incr Path---------------------------------------------------------------clock CLKdiv2 (rise edge) 0.00 0.00clock source latency 0.00 0.00Udiv/Q (FD1) 0.00 0.00 rUFF1/CP (FD1) 0.00 0.00 rUFF1/Q (FD1) 1.44 1.44 fUFF2/D (FD1) 0.00 1.44 fdata arrival time 1.44clock CLKdiv2 (rise edge) 20.00 20.00clock source latency 0.00 20.00Udiv/Q (FD1) 0.00 20.00 rUFF2/CP (FD1) 0.00 20.00 rlibrary setup time -0.80 19.20data required time 19.20---------------------------------------------------------------data required time 19.20data arrival time -1.44---------------------------------------------------------------slack (MET) 17.76There 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 duringthe source latency calculation for generated clocks. You can then look at how the UITE-461 message can result.How Source Latency is ComputedConsider the following divide-by-3 clock circuit:Figure 2: Example Circuit With Divide-by-3 LogicYou can describe these clocks to PrimeTime with the following commands:create_clock -period 10 CLKcreate_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 CLKYou 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/ZFor 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/ZThe 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 latencyof the generated clock.Unsatisfiable Generated Clock SpecificationsNow 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 LogicIn 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 ClockYou 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/portWith 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 circuitThe 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/qHere, 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 sourcelatency will be used. (UITE-461)Warning: Generated clock 'CLKdiv2' 'fall_edge' is not satisfiable; zero sourcelatency 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 clocksource 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: CLKdiv2Path Type: maxPoint Incr Path---------------------------------------------------------------clock CLKdiv2 (rise edge) 5.00 5.00clock CLK (source latency) 0.00 5.00CLK (in) 0.00 5.00 fU1/Z (IV) 0.58 5.58 rUdiv/Q (FD1) (gclock source) 1.47 7.05 rUFF1/CP (FD1) 0.00 7.05 rUFF1/Q (FD1) 1.44 8.49 fUFF2/D (FD1) 0.00 8.49 fdata arrival time 8.49clock CLKdiv2 (rise edge) 25.00 25.00clock CLK (source latency) 0.00 25.00CLK (in) 0.00 25.00 fU2/Z (IV) 0.58 25.58 rUdiv/Q (FD1) (gclock source) 1.47 27.05 rUFF2/CP (FD1) 0.00 27.05 rlibrary setup time -0.80 26.25data required time 26.25---------------------------------------------------------------data required time 26.25data arrival time -8.49---------------------------------------------------------------slack (MET) 17.76You 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 clockG - Generated clockI - Inactive clockClock 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 ExampleHere 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 CircuitRather 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 CircuitInitially, 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: CLKdiv4Path Type: maxPoint Incr Path---------------------------------------------------------------clock CLKdiv4 (rise edge) 0.00 0.00clock CLK (source latency) 0.00 0.00CLK (in) 0.00 0.00 rUdiv2/CP (FD1) 0.00 0.00 rUdiv2/Q (FD1) 1.44 1.44 fU2/B (ND2) 0.00 1.44 fU2/Z (ND2) (gclock source) 0.85 2.30 rUFF1/CP (FD1) 0.00 2.30 rUFF1/Q (FD1) 1.44 3.74 fUFF2/D (FD1) 0.00 3.74 fdata arrival time 3.74clock CLKdiv4 (rise edge) 40.00 40.00clock CLK (source latency) 0.00 40.00CLK (in) 0.00 40.00 rU1/A (ND2) 0.00 40.00 rU1/Z (ND2) 0.20 40.20 fU2/A (ND2) 0.00 40.20 fU2/Z (ND2) (gclock source) 0.85 41.05 rUFF2/CP (FD1) 0.00 41.05 rlibrary setup time -0.80 40.25data required time 40.25---------------------------------------------------------------data required time 40.25data arrival time -3.74---------------------------------------------------------------slack (MET) 36.51You 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 falseFor 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 sourcelatency 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 clockdefines 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 clockG - Generated clockI - Inactive clockClock 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 ClockModification-------------------------------------------------------------------------------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: CLKdiv4Path Type: maxPoint Incr Path---------------------------------------------------------------clock CLKdiv4 (rise edge) 0.00 0.00clock CLK (source latency) 0.00 0.00CLK (in) 0.00 0.00 rU1/A (ND2) 0.00 0.00 rU1/Z (ND2) 0.20 0.20 fU2/A (ND2) 0.00 0.20 fU2/Z (ND2) (gclock source) 0.85 1.05 rUFF1/CP (FD1) 0.00 1.05 rUFF1/Q (FD1) 1.44 2.49 fUFF2/D (FD1) 0.00 2.49 fdata arrival time 2.49clock CLKdiv4 (rise edge) 40.00 40.00clock CLK (source latency) 0.00 40.00CLK (in) 0.00 40.00 rU1/A (ND2) 0.00 40.00 rU1/Z (ND2) 0.20 40.20 fU2/A (ND2) 0.00 40.20 fU2/Z (ND2) (gclock source) 0.85 41.05 rUFF2/CP (FD1) 0.00 41.05 rlibrary setup time -0.80 40.25data required time 40.25---------------------------------------------------------------data required time 40.25data arrival time -2.49---------------------------------------------------------------slack (MET) 37.76 Debugging TipsIt 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 thearrival_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 trueTo 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 name2.Polarity of original reference clock edge event3.Min-delay rise/fall arrival values4.Max-delay rise/fall arrival valuesAt 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 themaster, and falling edges exist as a result of a neg_edge event. This describes apositive-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 themaster, and rising edges exist as a result of a neg_edge event. This describes anegative-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 andfalling edges at this pin, meaning that both non-inverting and inverting pathsarrive 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.。