I have many clock gating checks in my design. Some of my clock gating checks are complex, where the gating signal is launched by a different clock than the clock being gated. What are the rules for how the setup and hold clock gating checks are inferred?
Answer:
To thoroughly understand clock gating, first consider how clock gating checks are inferred based on the logic in the design. Then, consider the timing aspects of how the clock gating check is actually inferred.
Logical Aspects of Clock Gating Inference
A clock gating check occurs when a gating signal has the potential to enable or disable a clock signal. Figure 1 shows an example of a clock gating circuit:
Figure 1: Example Clock Gating Circuit
In order for a clock gating check to be inferred, the clock pin and gating pin must first meet certain criteria. First, define the property of a clock being consumed. A clock is consumed if the clock fans out to one of the following objects:
- Register clock pin
- Output or bidirectional port
- Generated clock definition that refers to this clock as its master
Stated more intuitively, a clock is consumed when it is used as a clock. If a clock signal were to be captured by a flip-flop's D pin, the clock would not be considered to be consumed as a clock; instead, it is simply captured as a normal data signal. In Figure 1, the bold path indicates the path where the clock is consumed as a clock downstream.
Now, examine the necessary conditions for a clock gating check to be inferred on a cell. The clock pin of the check must
- Have a clock propagating to it
- Be consumed as a clock in the fanout from the clock pin
- Fan out to the same cell output pin as the potential gating pin of the check
The gating pin of the check
- Must fan out to the same cell output pin as the potential clock pin of the check
- Must either
- Not be a clock
- Be a clock that is not actually consumed as a clock in the fanout from the data pin
If all of these criteria are met, the stage is set to infer a clock gating check. Now you must decide what kind of clock gating check (active high or active low clock) to infer.
First, PrimeTime checks to see if a set_clock_gating_check command has been issued, which applies to these cell pins. The data pin is checked first, and only if no specification is found, the clock pin is checked. If neither pin has a set_clock_gating_check specification, the cell functionality between the clock and gating pins is checked. If AND or NAND functionality is found, a high clock gating check is inferred. If OR or NOR functionality is found, a low clock gating check is inferred. If a more complex function is found where a gating relationship is not obvious (such as MUX or XOR arcs), PrimeTime issues a PTE-060 warning:
Warning: No clock-gating check is inferred for clock CLK
at pins UXOR/A and UXOR/B of cell UGAT. (PTE-060)
If a set_clock_gating_check specification is found for the cell pins and the gating functionality is not recognized, the specification is used. If the gating functionality is recognized and it conflicts with the gating specification, PrimeTime uses the specification and issues a PTE-036 warning:
Warning: User specified '-low' in set_clock_gating_check command
overwrites what the logic function of the cell or pin implies
that clock gating check at pin 'UAND/A' should be against the 'high'
of the clock. (PTE-036)
These rules are fairly obvious except for gating pin rule 2b. To illustrate the purpose of this rule, consider the circuit in Figure 2:
Figure 2: Combining Clocks Combinationally
In this circuit, you can see that two clocks are first gated with AND gates, then combined together using OR gates. Clock gating checks are inferred for the two AND gates, but not for the OR gate. This is because although both CLK1 and CLK2 arrive at the OR gate, both are consumed as clocks downstream. PrimeTime therefore understands that both of these are clock signals being steered and combined with logic, and no gating check is inferred.
Now consider the circuit shown in Figure 3:
Figure 3: Using One Clock to Gate Another
In this example, a generated clock of CLK1 is created at the output of the AND gate. The presence of this generated clock causes the propagation of CLK2 to be blocked at the AND gate output. As a result, CLK2 arrives at the AND gate, but is not actually consumed as a clock downstream. In this particular scenario, PrimeTime infers that CLK1 is the clock signal (because it is consumed as a clock downstream) and CLK2 is the gating signal (because it is not consumed as a clock downstream) and infers a gating check accordingly.
Timing Aspects of Clock Gating Inference
The rule for how the timing of a clock gating check is inferred is actually very simple:
For a clock gating signal launched by a launch clock edge, the gating signal's arrival is checked against the current or next inactive period of the clock waveform being gated.
Note that the ideal clock waveforms without clock latency and propagation delays are used to determine these edge relationships. In other words, PrimeTime traces the gating signal back to the reference clock edge that launches the gating signal. Once the gating edge relationships have been determined, the check is performed with the propagated timing.
The clock signal type (active-high or active-low) is determined by the type of logic cell used to gate the clock. If the gate is a complex gate, PrimeTime is not able to infer the clock polarity and issues a PTE-060 warning. In these cases, you can use the set_clock_gating_check information to provide the needed clock polarity information to PrimeTime.
To better understand the timing aspects of clock gating checks, take a look at the following examples.
Clock Gating Example #1
Figure 4: Example Circuit #1
In this example, set CLK1 and CLK2 to have the same waveform:
create_clock -period 16 -waveform {0 8} CLK1
create_clock -period 16 -waveform {0 8} CLK2
The gating signal is launched by the rising edge of CLK1. The clock being gated is CLK2. Because the cell gating CLK2 is an AND gate, the clock is inferred to be active-high, and the inactive portion of the clock waveform is the low portion. When the clock gating signal is asserted low, the clock signal is held inactive-low.
Consider a clock gating signal launched at 0 ns by CLK1. Because this corresponds exactly with the rising edge of CLK2 at 0 ns, the next quiet portion of the CLK2 waveform begins at 8 ns. (The previous inactive region ending at 0 ns does not count, as it is already becoming active at 0 ns.) Clock gating checks are inferred so that the gating signal must arrive between the 8-ns (falling) and 16-ns (rising) edges of CLK2.
You can verify these gating checks with the following timing reports:
report_timing -path_type full_clock -nosplit -delay min_max -group {*gating*}
...
Startpoint: UFF (rising edge-triggered flip-flop clocked by CLK1)
Endpoint: UGAT (rising clock gating-check end-point clocked by CLK2)
Path Group: **clock_gating_default**
Path Type: min
Point Incr Path
---------------------------------------------------------------
clock CLK1 (rise edge) 0.00 0.00
clock source latency 0.00 0.00
CLK1 (in) 0.00 0.00 r
UFF/CP (FD1) 0.00 0.00 r
UFF/Q (FD1) 1.29 1.29 r
UGAT/A (AN2) 0.00 1.29 r
data arrival time 1.29
clock CLK2 (fall edge) 8.00 8.00
clock source latency 0.00 8.00
CLK2 (in) 0.00 8.00 f
UGAT/B (AN2) 0.00 8.00 f
clock gating hold time 0.00 8.00
data required time 8.00
---------------------------------------------------------------
data required time 8.00
data arrival time -1.29
---------------------------------------------------------------
slack (VIOLATED) -6.71
Startpoint: UFF (rising edge-triggered flip-flop clocked by CLK1)
Endpoint: UGAT (rising clock gating-check end-point clocked by CLK2)
Path Group: **clock_gating_default**
Path Type: max
Point Incr Path
---------------------------------------------------------------
clock CLK1 (rise edge) 0.00 0.00
clock source latency 0.00 0.00
CLK1 (in) 0.00 0.00 r
UFF/CP (FD1) 0.00 0.00 r
UFF/Q (FD1) 1.44 1.44 f
UGAT/A (AN2) 0.00 1.44 f
data arrival time 1.44
clock CLK2 (rise edge) 16.00 16.00
clock source latency 0.00 16.00
CLK2 (in) 0.00 16.00 r
UGAT/B (AN2) 0.00 16.00 r
clock gating setup time 0.00 16.00
data required time 16.00
---------------------------------------------------------------
data required time 16.00
data arrival time -1.44
---------------------------------------------------------------
slack (MET) 14.56
You can see that when the sense of the gating signal flip-flop and the flip-flops being gated are the same, the result is a challenging hold time requirement due to the gating checks being pushed into the next inactive clock region.
Clock Gating Example #2
Figure 5: Example Circuit #2
In this example, you again define CLK1 and CLK2 to have the same waveform:
create_clock -period 16 -waveform {0 8} CLK1
create_clock -period 16 -waveform {0 8} CLK2
This time, the gating signal is launched by the falling edge of CLK1. The clock being gated is CLK2. Because the cell gating CLK2 is an AND gate, the clock is inferred to be active-high, and the inactive portion of the clock waveform is the low portion. When the clock gating signal is asserted low, the clock signal is held inactive-low.
The clock gating signal is launched at 8 ns by CLK1. The next quiet portion of the CLK2 waveform begins at 8 ns. Clock gating checks are inferred so that the gating signal must arrive between the 8 ns (falling) and 16 ns (rising) edges of CLK2.
You can verify these gating checks with the following timing reports:
Startpoint: UFF (falling edge-triggered flip-flop clocked by CLK1) Endpoint: UGAT (rising clock gating-check end-point clocked by CLK2) Path Group: **clock_gating_default** Path Type: min Point Incr Path --------------------------------------------------------------- clock CLK1 (fall edge) 8.00 8.00 clock source latency 0.00 8.00 CLK1 (in) 0.00 8.00 f UFF/CP (FD1L) 0.00 8.00 f UFF/Q (FD1L) 1.29 9.29 r UGAT/A (AN2) 0.00 9.29 r data arrival time 9.29 clock CLK2 (fall edge) 8.00 8.00 clock source latency 0.00 8.00 CLK2 (in) 0.00 8.00 f UGAT/B (AN2) 0.00 8.00 f clock gating hold time 0.00 8.00 data required time 8.00 --------------------------------------------------------------- data required time 8.00 data arrival time -9.29 --------------------------------------------------------------- slack (MET) 1.29 Startpoint: UFF (falling edge-triggered flip-flop clocked by CLK1) Endpoint: UGAT (rising clock gating-check end-point clocked by CLK2) Path Group: **clock_gating_default** Path Type: max Point Incr Path --------------------------------------------------------------- clock CLK1 (fall edge) 8.00 8.00 clock source latency 0.00 8.00 CLK1 (in) 0.00 8.00 f UFF/CP (FD1L) 0.00 8.00 f UFF/Q (FD1L) 1.44 9.44 f UGAT/A (AN2) 0.00 9.44 f data arrival time 9.44 clock CLK2 (rise edge) 16.00 16.00 clock source latency 0.00 16.00 CLK2 (in) 0.00 16.00 r UGAT/B (AN2) 0.00 16.00 r clock gating setup time 0.00 16.00 data required time 16.00 --------------------------------------------------------------- data required time 16.00 data arrival time -9.44 --------------------------------------------------------------- slack (MET) 6.56
You can see that when the sense of the gating signal flip-flop and the flip-flops being gated are opposite, the setup and hold gating requirements are fairly easy to meet. This is the most common structure for clock gating circuits.
Clock Gating Example #3
Figure 6: Example Circuit #3
In this example, CLK1 and CLK2 have different waveforms, defined as follows:
create_clock -period 16 -waveform {10 2} CLK1 ;# return-to-one clock
create_clock -period 16 -waveform {2 6 8 12} CLK2
The gating signal is launched by the rising edge of CLK1. The clock being gated is CLK2. Because the cell gating CLK2 is an OR gate, the clock is inferred to be active-low, and the inactive portion of the clock waveform is the high portion. When the clock gating signal is asserted high, the clock signal is held inactive-high.
The clock gating signal is launched at 10 ns by CLK1. This is during the quiet portion of the CLK2 waveform, which began at 8 ns. Clock gating checks are inferred so that the gating signal must arrive between the 8 ns (rising) and 12 ns (falling) edges of CLK2.
You can verify these gating checks with the following timing reports:
Startpoint: UFF (rising edge-triggered flip-flop clocked by CLK1) Endpoint: UGAT (falling clock gating-check end-point clocked by CLK2) Path Group: **clock_gating_default** Path Type: min Point Incr Path --------------------------------------------------------------- clock CLK1 (rise edge) 10.00 10.00 clock source latency 0.00 10.00 CLK1 (in) 0.00 10.00 r UFF/CP (FD1) 0.00 10.00 r UFF/Q (FD1) 1.29 11.29 r UGAT/A (OR2) 0.00 11.29 r data arrival time 11.29 clock CLK2 (rise edge) 8.00 8.00 clock source latency 0.00 8.00 CLK2 (in) 0.00 8.00 r UGAT/B (OR2) 0.00 8.00 r clock gating hold time 0.00 8.00 data required time 8.00 --------------------------------------------------------------- data required time 8.00 data arrival time -11.29 --------------------------------------------------------------- slack (MET) 3.29 Startpoint: UFF (rising edge-triggered flip-flop clocked by CLK1) Endpoint: UGAT (falling clock gating-check end-point clocked by CLK2) Path Group: **clock_gating_default** Path Type: max Point Incr Path --------------------------------------------------------------- clock CLK1 (rise edge) 10.00 10.00 clock source latency 0.00 10.00 CLK1 (in) 0.00 10.00 r UFF/CP (FD1) 0.00 10.00 r UFF/Q (FD1) 1.44 11.44 f UGAT/A (OR2) 0.00 11.44 f data arrival time 11.44 clock CLK2 (fall edge) 12.00 12.00 clock source latency 0.00 12.00 CLK2 (in) 0.00 12.00 f UGAT/B (OR2) 0.00 12.00 f clock gating setup time 0.00 12.00 data required time 12.00 --------------------------------------------------------------- data required time 12.00 data arrival time -11.44 --------------------------------------------------------------- slack (MET) 0.56
Clock Gating Example #4
Figure 7: Example Circuit #4
In this example, CLK1 and CLK2 both have complex multi-pulse waveforms, as follows:
create_clock -name CLK1 -period 16 -waveform {0 2 6 8} CLK1
create_clock -name CLK2 -period 16 -waveform {4 8 12 14} CLK2
The gating signal is launched by the falling edge of CLK1. The clock being gated is CLK2. Because the cell gating CLK2 is an AND gate, the clock is inferred to be active-high, and the inactive portion of the clock waveform is the low portion. When the clock gating signal is asserted low, the clock signal is held inactive-low.
The clock gating signal is launched twice. The clock gating signal launched at 2 ns gates the inactive portion of CLK2 from -2 ns (in the previous cycle) to 4 ns. The clock gating signal launched at 8 ns gates the inactive portion of CLK2 from 8 ns to 12 ns.
The purpose of this example is to demonstrate that all setup and hold clock gating checks are computed between two complex clock waveforms, and the most restrictive setup and hold checks are reported. You can verify this with the following timing reports:
Startpoint: UFF (falling edge-triggered flip-flop clocked by CLK1) Endpoint: UGAT (rising clock gating-check end-point clocked by CLK2) Path Group: **clock_gating_default** Path Type: min Point Incr Path --------------------------------------------------------------- clock CLK1 (fall edge) 8.00 8.00 clock source latency 0.00 8.00 CLK1 (in) 0.00 8.00 f UFF/CP (FD1L) 0.00 8.00 f UFF/Q (FD1L) 1.29 9.29 r UGAT/A (AN2) 0.00 9.29 r data arrival time 9.29 clock CLK2 (fall edge) 8.00 8.00 clock source latency 0.00 8.00 CLK2 (in) 0.00 8.00 f UGAT/B (AN2) 0.00 8.00 f clock gating hold time 0.00 8.00 data required time 8.00 --------------------------------------------------------------- data required time 8.00 data arrival time -9.29 --------------------------------------------------------------- slack (MET) 1.29 Startpoint: UFF (falling edge-triggered flip-flop clocked by CLK1) Endpoint: UGAT (rising clock gating-check end-point clocked by CLK2) Path Group: **clock_gating_default** Path Type: max Point Incr Path --------------------------------------------------------------- clock CLK1 (fall edge) 2.00 2.00 clock source latency 0.00 2.00 CLK1 (in) 0.00 2.00 f UFF/CP (FD1L) 0.00 2.00 f UFF/Q (FD1L) 1.44 3.44 f UGAT/A (AN2) 0.00 3.44 f data arrival time 3.44 clock CLK2 (rise edge) 4.00 4.00 clock source latency 0.00 4.00 CLK2 (in) 0.00 4.00 r UGAT/B (AN2) 0.00 4.00 r clock gating setup time 0.00 4.00 data required time 4.00 --------------------------------------------------------------- data required time 4.00 data arrival time -3.44 --------------------------------------------------------------- slack (MET) 0.56
Clock Gating Example #5
Figure 8: Example Circuit #5
This example is similar to example #2, except that instead of gating off the clock, you are multiplexing in an external test clock into the clock network. You need the clock gating checks to ensure that the MUX select signal arrives at the proper time to cleanly switch over to the test clock. For this example, you are only interested in cleanly switching to/from CLK2. Assume that the test clock is not a free-running clock, and that it is quiet when you switch to/from it.
Define the clocks to have the same waveforms:
create_clock -period 16 -waveform {0 8} CLK1
create_clock -period 16 -waveform {0 8} CLK2
The gating signal is launched by the falling edge of CLK1. The clock being gated is CLK2. Because the cell gating CLK2 is a complex gate, PrimeTime is unable to determine the needed clock gating check for this gate:
Warning: No clock-gating check is inferred for clock CLK2
at pins UMUX/B and UMUX/A of cell UMUX. (PTE-060)
Warning: No clock-gating check is inferred for clock CLK2
at pins UMUX/S and UMUX/A of cell UMUX. (PTE-060)
You want to specify that CLK2 arriving at UMUX/A is an active-high clock, and you want the gating signal to arrive in the inactive-low region:
You can do this with the following command:
set_clock_gating_check -high UMUX/A
When you run the analysis, you see the following clock gating reports:
Startpoint: TSTCLK (input port) Endpoint: UMUX (rising clock gating-check end-point clocked by CLK2) Path Group: **clock_gating_default** Path Type: min Point Incr Path --------------------------------------------------------------- clock (input port clock) (rise edge) 0.00 0.00 clock network delay (ideal) 0.00 0.00 input external delay 0.00 0.00 r TSTCLK (in) 0.00 0.00 r UMUX/B (MUX21H) 0.00 0.00 r data arrival time 0.00 clock CLK2 (fall edge) 8.00 8.00 clock source latency 0.00 8.00 CLK2 (in) 0.00 8.00 f UMUX/A (MUX21H) 0.00 8.00 f clock gating hold time 0.00 8.00 data required time 8.00 --------------------------------------------------------------- data required time 8.00 data arrival time 0.00 --------------------------------------------------------------- slack (VIOLATED) -8.00 Startpoint: UFF (falling edge-triggered flip-flop clocked by CLK1) Endpoint: UMUX (rising clock gating-check end-point clocked by CLK2) Path Group: **clock_gating_default** Path Type: max Point Incr Path --------------------------------------------------------------- clock CLK1 (fall edge) 8.00 8.00 clock source latency 0.00 8.00 CLK1 (in) 0.00 8.00 f UFF/CP (FD1L) 0.00 8.00 f UFF/Q (FD1L) 1.49 9.49 f UMUX/S (MUX21H) 0.00 9.49 f data arrival time 9.49 clock CLK2 (rise edge) 16.00 16.00 clock source latency 0.00 16.00 CLK2 (in) 0.00 16.00 r UMUX/A (MUX21H) 0.00 16.00 r clock gating setup time 0.00 16.00 data required time 16.00 --------------------------------------------------------------- data required time 16.00 data arrival time -9.49 --------------------------------------------------------------- slack (MET) 6.51
You see that a hold clock gating check is inferred which assumes that TSTCLK is actually a gating signal of CLK2. This is incorrect, as the TSTCLK signal is a pseudo-clock signal rather than a data signal. You must additionally specify that inferring clock gating checks on this pin is to be avoided:
set_disable_clock_gating_check UMUX/B
With these clock gating commands in your script, you have now provided PrimeTime with all of the needed information, and you see the desired clock gating checks:
Startpoint: UFF (falling edge-triggered flip-flop clocked by CLK1) Endpoint: UMUX (rising clock gating-check end-point clocked by CLK2) Path Group: **clock_gating_default** Path Type: min Point Incr Path --------------------------------------------------------------- clock CLK1 (fall edge) 8.00 8.00 clock source latency 0.00 8.00 CLK1 (in) 0.00 8.00 f UFF/CP (FD1L) 0.00 8.00 f UFF/Q (FD1L) 1.44 9.44 r UMUX/S (MUX21H) 0.00 9.44 r data arrival time 9.44 clock CLK2 (fall edge) 8.00 8.00 clock source latency 0.00 8.00 CLK2 (in) 0.00 8.00 f UMUX/A (MUX21H) 0.00 8.00 f clock gating hold time 0.00 8.00 data required time 8.00 --------------------------------------------------------------- data required time 8.00 data arrival time -9.44 --------------------------------------------------------------- slack (MET) 1.44 Startpoint: UFF (falling edge-triggered flip-flop clocked by CLK1) Endpoint: UMUX (rising clock gating-check end-point clocked by CLK2) Path Group: **clock_gating_default** Path Type: max Point Incr Path --------------------------------------------------------------- clock CLK1 (fall edge) 8.00 8.00 clock source latency 0.00 8.00 CLK1 (in) 0.00 8.00 f UFF/CP (FD1L) 0.00 8.00 f UFF/Q (FD1L) 1.49 9.49 f UMUX/S (MUX21H) 0.00 9.49 f data arrival time 9.49 clock CLK2 (rise edge) 16.00 16.00 clock source latency 0.00 16.00 CLK2 (in) 0.00 16.00 r UMUX/A (MUX21H) 0.00 16.00 r clock gating setup time 0.00 16.00 data required time 16.00 --------------------------------------------------------------- data required time 16.00 data arrival time -9.49 --------------------------------------------------------------- slack (MET) 6.51
Clock Gating Example #6
Figure 9: Example Circuit #6
In this example, the clock being gated (CLK2) has twice the frequency of the clock launching the gating signal (CLK1):
create_clock -period 16 -waveform {0 8} CLK1
create_clock -period 16 -waveform {0 4 8 12} CLK2
Because the cell gating CLK2 is an AND gate, the clock is inferred to be active-high, and the inactive portion of the clock waveform is the low portion. When the clock gating signal is asserted low, the clock signal is held inactive-low.
By default, the clock gating check is inferred against the current or next inactive portion of the clock being gated. This leads to clock gating checks being inferred such that the gating signal that is launched at 0 ns must arrive between 4 ns (falling) and 8 ns (rising):
You can verify these gating checks with the following timing reports:
Startpoint: UFF (rising edge-triggered flip-flop clocked by CLK1) Endpoint: UGAT (rising clock gating-check end-point clocked by CLK2) Path Group: **clock_gating_default** Path Type: min Point Incr Path --------------------------------------------------------------- clock CLK1 (rise edge) 0.00 0.00 clock source latency 0.00 0.00 CLK1 (in) 0.00 0.00 r UFF/CP (FD1) 0.00 0.00 r UFF/Q (FD1) 1.29 1.29 r UGAT/A (AN2) 0.00 1.29 r data arrival time 1.29 clock CLK2 (fall edge) 4.00 4.00 clock source latency 0.00 4.00 CLK2 (in) 0.00 4.00 f U1/Z (BUF) 0.23 4.23 f U2/Z (BUF) 0.23 4.46 f U3/Z (BUF) 0.23 4.70 f UGAT/B (AN2) 0.00 4.70 f clock gating hold time 0.00 4.70 data required time 4.70 --------------------------------------------------------------- data required time 4.70 data arrival time -1.29 --------------------------------------------------------------- slack (VIOLATED) -3.40 Startpoint: UFF (rising edge-triggered flip-flop clocked by CLK1) Endpoint: UGAT (rising clock gating-check end-point clocked by CLK2) Path Group: **clock_gating_default** Path Type: max Point Incr Path --------------------------------------------------------------- clock CLK1 (rise edge) 0.00 0.00 clock source latency 0.00 0.00 CLK1 (in) 0.00 0.00 r UFF/CP (FD1) 0.00 0.00 r UFF/Q (FD1) 1.44 1.44 f UGAT/A (AN2) 0.00 1.44 f data arrival time 1.44 clock CLK2 (rise edge) 8.00 8.00 clock source latency 0.00 8.00 CLK2 (in) 0.00 8.00 r U1/Z (BUF) 0.58 8.58 r U2/Z (BUF) 0.58 9.16 r U3/Z (BUF) 0.58 9.74 r UGAT/B (AN2) 0.00 9.74 r clock gating setup time 0.00 9.74 data required time 9.74 --------------------------------------------------------------- data required time 9.74 data arrival time -1.44 --------------------------------------------------------------- slack (MET) 8.30
As with example #1, there is a large hold violation. The clock gating checks are inferred using the reference waveforms of the clocks, without any propagation effects taken into account. However, the designer of this circuit has deliberately delayed the CLK2 signal by inserting three buffers. This shifts the CLK2 waveform to the right, such that it would actually be safe to infer the clock gating check against the earlier inactive period in the previous cycle (ending at 0 ns reference time).
To move the clock gating check, you can use the set_multicycle_path -setup command. You can see from the man page that by default, the -setup modifier is relative to the capturing clock (which in the clock gating check report, is CLK2). Because the default setup multicycle modifier is 1, subtract 1 from this value to move the check one CLK2 cycle to the left:
set_multicycle_path 0 -to [get_pins UGAT/A]
This results in the following inferred check (shown twice: once from the original launch at 0 ns, and duplicated for clarity at 16 ns):
After applying this constraint, you can now confirm that the clock gating check is inferred as desired, and that your manually-inserted delay successfully avoids a hold time violation:
Startpoint: UFF (rising edge-triggered flip-flop clocked by CLK1) Endpoint: UGAT (rising clock gating-check end-point clocked by CLK2) Path Group: **clock_gating_default** Path Type: min Point Incr Path --------------------------------------------------------------- clock CLK1 (rise edge) 16.00 16.00 clock source latency 0.00 16.00 CLK1 (in) 0.00 16.00 r UFF/CP (FD1) 0.00 16.00 r UFF/Q (FD1) 1.29 17.29 r UGAT/A (AN2) 0.00 17.29 r data arrival time 17.29 clock CLK2 (fall edge) 12.00 12.00 clock source latency 0.00 12.00 CLK2 (in) 0.00 12.00 f U1/Z (BUF) 0.23 12.23 f U2/Z (BUF) 0.23 12.46 f U3/Z (BUF) 0.23 12.70 f UGAT/B (AN2) 0.00 12.70 f clock gating hold time 0.00 12.70 data required time 12.70 --------------------------------------------------------------- data required time 12.70 data arrival time -17.29 --------------------------------------------------------------- slack (MET) 4.60 Startpoint: UFF (rising edge-triggered flip-flop clocked by CLK1) Endpoint: UGAT (rising clock gating-check end-point clocked by CLK2) Path Group: **clock_gating_default** Path Type: max Point Incr Path --------------------------------------------------------------- clock CLK1 (rise edge) 0.00 0.00 clock source latency 0.00 0.00 CLK1 (in) 0.00 0.00 r UFF/CP (FD1) 0.00 0.00 r UFF/Q (FD1) 1.44 1.44 f UGAT/A (AN2) 0.00 1.44 f data arrival time 1.44 clock CLK2 (rise edge) 0.00 0.00 clock source latency 0.00 0.00 CLK2 (in) 0.00 0.00 r U1/Z (BUF) 0.58 0.58 r U2/Z (BUF) 0.58 1.16 r U3/Z (BUF) 0.58 1.74 r UGAT/B (AN2) 0.00 1.74 r clock gating setup time 0.00 1.74 data required time 1.74 --------------------------------------------------------------- data required time 1.74 data arrival time -1.44 --------------------------------------------------------------- slack (MET) 0.30
Clock Gating Checks and Timing Paths
By default, clock gating checks do not block the propagation of data along the gating path. If you were to "look inside" a gating cell, the timing arcs would look something like this:
Figure 10: Timing Arcs Inside a Clock Gating Cell
You can see both of the existing combinational cell arcs. Also, there is an additional inferred clock gating arc that checks the arrival time of the clock against the gating signal. By default, this check arc is non-blocking and both cell arcs retain their normal behavior.
However, this can affect the timing analysis in unexpected ways. Consider the circuit that follows, where you gate a clock and then send it to an output port CLKOUT:
Figure 11: Example Circuit With Gated Output Clock Path
You have constrained the CLKOUT port with set_output_delay commands to ensure that your clock output port meets your desired timing spec. However, when you generate a hold path timing report to CLKOUT, you get the following timing path:
Startpoint: UFF (rising edge-triggered flip-flop clocked by CLK) Endpoint: CLKOUT (output port clocked by CLK) Path Group: CLK Path Type: min Point Incr Path --------------------------------------------------------------- clock CLK (rise edge) 0.00 0.00 clock source latency 0.00 0.00 CLK (in) 0.00 0.00 r UFF/CP (FD1) 0.00 0.00 r UFF/Q (FD1) 1.29 1.29 r UGAT/A (AN2) 0.00 1.29 r UGAT/Z (AN2) 0.88 2.17 r CLKOUT (out) 0.00 2.17 r data arrival time 2.17 clock CLK (rise edge) 0.00 0.00 clock network delay (propagated) 0.00 0.00 output external delay 0.00 0.00 data required time 0.00 --------------------------------------------------------------- data required time 0.00 data arrival time -2.17 --------------------------------------------------------------- slack (MET) 2.17
For hold time analysis, PrimeTime has found that the critical path is actually launched by UFF, propagating through the gating signal side to CLKOUT. This is undesirable, because you know that your gating circuit is clean and no glitches from the gating side actually propagate onto the clock network.
In PrimeTime, the gating signal propagation behavior is controlled by the timing_clock_gating_propagate_enable variable, whose default value is true. When set to false, the gating signal is prevented from propagating through the gating cell into downstream logic. The path is then segmented at the gating input pin during update. If you were to "look inside" the gating cell, the timing arcs (in the context of your path) would look something like this:
Figure 12: Example Circuit With Clock Gating Propagation Path Disabled
Setting this variable to false can be useful if the data signal is propagating into the clock network and causing unwanted or invalid timing paths to appear during analysis. Note that setting this variable to false also prevents the gating slews from propagating into the clock network as well. In your circuit example, retime the path and to get the following timing report:
Startpoint: CLK (clock source 'CLK') Endpoint: CLKOUT (output port clocked by CLK) Path Group: CLK Path Type: min Point Incr Path --------------------------------------------------------------- clock CLK (rise edge) 0.00 0.00 clock source latency 0.00 0.00 CLK (in) 0.00 0.00 r U1/A (BUF) 0.00 0.00 r U1/Z (BUF) 0.81 0.81 r U2/A (BUF) 0.00 0.81 r U2/Z (BUF) 0.81 1.63 r UGAT/B (AN2) 0.00 1.63 r UGAT/Z (AN2) 0.88 2.50 r CLKOUT (out) 0.00 2.50 r data arrival time 2.50 clock CLK (rise edge) 0.00 0.00 output external delay 0.00 0.00 data required time 0.00 --------------------------------------------------------------- data required time 0.00 data arrival time -2.50 --------------------------------------------------------------- slack (MET) 2.50
This variable can solve other problems, such as undesired generated clock source latency traces through gating paths. However, note that if you are creating a -divide_by 1 generated clock and trying to prevent it from tracing back through sequential cells, the preferred method is to use the -combinational generated clock type:
create_generated_clock -combinational -source [get_ports CLK] [get_pins UGAT/Z]
This type of generated clock is designed to trace back only through combinational logic, avoiding any sequential arcs. For more information, see the PrimeTime User Guide and the create_generated_clock man page.
2945
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
