Using the set_clock_sense -stop_propagation Command Properly With PrimeTime SI 02/10/17, 12(17 PM

Search SolvNet Go Advanced

SYNOPSYS.COM | FEEDBACK | SITE MAP | HELP | SIGN OUT

Documentation Support Downloads Training Methodology My Profile

HOME SOLVNET ARTICLE

Using the set_clock_sense -stop_propagation Command SAVED ARTICLES

Properly With PrimeTime SI TAGS

Doc Id: 020879 Product: PrimeTime;PrimeTime SI Last Modified: 12/05/2007 None

Add Tags
Average User Rating: (4) Rate Article: Send comment

Save Article Tag Article Print Email

Question:
I have a design in which I want to stop a clock from propagating down a certain logic path. I heard that there are some
caveats when using this feature with PrimeTime SI. What should I keep in mind when configuring my clock logic?

Answer:

Introduction
The stop clock propagation feature is a very powerful feature that allows you to specify certain complex clock
configurations in PrimeTime. The feature works by allowing the propagation of one or more clocks to be stopped at an
arbitrary pin or arc, while allowing the remaining clocks to propagate through. There are, however, some ramifications to
this feature that you must keep in mind when performing a crosstalk analysis. To understand this, we can look at two
examples - one in which the feature is used correctly and another where it is used incorrectly.

Correct "Stop Clock" Usage

Consider the following design:

Figure 1: Cascaded MUX Example Circuit

In this design, UMUX0 selects between CLKA and a test mode clock TSTCLK. UMUX1 is cascaded off UMUX0 and selects
between CLKB and the output of UMUX0. The control logic for this design is such that the MUX selects never allows TSTCLK
to propagate through UMUX1 to FF3 and FF4.

Since the clock physically does not emerge from the UMUX1/Z output, you can model this control logic behavior in
PrimeTime with the following commands:

set_clock_sense -stop_propagation \
-clocks [get_clocks TSTCLK] \
[get_pins UMUX1/Z]

This is a correct use of stop clock propagation - TSTCLK never physically propagates through UMUX1/Z.

Incorrect "Stop Clock" Usage

Consider the following design:

https://solvnet.synopsys.com/retrieve/020879.html?otSearchResultSrc=advSearch&otSearchResultNumber=25&otPageNum=3 Page 1 of 3
Using the set_clock_sense -stop_propagation Command Properly With PrimeTime SI 02/10/17, 12(17 PM

Figure 2: Simultaneous Input Clock Circuit

In this circuit, two clocks are defined on input port CLK - a high speed clock (HSCLK) and a low speed clock (LSCLK). The
circuit can operate in two modes:

High speed mode - the high speed clock is provided at CLK and the HS* flops capture the data on the rising edge
only
Low speed mode - the low speed clock is provided at CLK and the LS* flops capture the data on both the rising and
falling edges

When both clocks are defined at input port CLK in PrimeTime, both clocks propagate to both the HS* and LS* flops. We are
not, however, interested in HSCLK timing paths launched from the LS* flops or LSCLK timing paths launched from the HS*
flops. The logic is unused in these scenarios and the timing paths are uninteresting.

To suppress these paths, you might be tempted to stop the clocks from triggering the other domain's data capturing flops:

set_clock_sense -stop_propagation \
-clocks [get_clocks LSCLK] [get_pins HS*/CP]
set_clock_sense -stop_propagation \
-clocks [get_clocks HSCLK] [get_pins LS*/CP]

Consider the possibility, however, that there are downstream crosstalk interactions from these flops:

Figure 3: Crosstalk Interactions in Simultaneous Input Clock Circuit

It is possible (and perhaps likely) that there coupling capacitances downstream from the data capturing flops. Physically, the
LS* flops receive HSCLK in high-speed mode and launch HSCLK-domain data edges into the downstream logic. These
HSCLK-sourced edges could aggress other logic, such as victim2 in the schematic. If you stopped the clock propagation
with the commands above, you would actually be turning off crosstalk interactions that should be modeled! The converse
case is also true of LSCLK-launched edges propagating through the HS* flops.

In this case, the correct way to suppress these undesired timing paths is with the set_false_path command:

set_false_path -from [get_clocks LSCLK] -through [get_pins HS*/CP]

set_false_path -from [get_clocks HSCLK] -through [get_pins LS*/CP]

Notice that the -from object is a clock object (a type of path startpoint) and the next -through object is a clock pin (also a
type of path startpoint). This syntax of specifying paths by clocks and startpoints is valid and supported, but not widely
known. It allows paths that launch from an object, but only from certain clock domains to be specified. If you were running
a non-crosstalk PrimeTime analysis, the scenario above would not be a concern; however, this is still not a recommended
practice. At some point in the future, you could repeat this analysis with crosstalk enabled. After the constraints are written,
it is difficult to detect the optimistic misuse of stop clock propagation.

Further Details
PrimeTime SI performs delay calculation on stages, which is the combination of the driving cell and the driven net. If the
"stop clock" property is applied to a cell output pin, the clock edge will be stopped from further propagating forward from
that stage. Since the clock has already arrived at the cell (stage) input pin, SI effects for that stage are computed, and any
resulting delta delays will still be applied to the net directly after the cell output pin where the clock was stopped.
If you still see unexpected delta delays downstream from the stop pin, ensure that the nets are reselected. If the nets are
not reselected, first-iteration delta delays will be computed and kept for the net. You can use the "set_si_delay_analysis

https://solvnet.synopsys.com/retrieve/020879.html?otSearchResultSrc=advSearch&otSearchResultNumber=25&otPageNum=3 Page 2 of 3
Using the set_clock_sense -stop_propagation Command Properly With PrimeTime SI 02/10/17, 12(17 PM

-reselect" command to force nets to be reselected and recomputed in subsequent iterations.

In versions prior to A-2007.12, applying "stop clock" to a pin will stop the propagation of the clock edge. However, there
was a shadow data edge which propagates in parallel with the clock edge that was not stopped. This meant that the clock
would no longer propagate logically and trigger downstream sequential cells, but the shadow data edges would continue to
propagate downstream from the stop pins and incur delta delays and act as aggressors.

In A-2007.12, this behavior was corrected so that the "stop clock" property stops both the clock edge and the
corresponding shadow data edge.

Summary
You can use stop clock propagation to turn off the propagation of a clock if the clock physically does not propagate past
that point in the actual silicon. If the clock propagates past that point, but the timing paths are uninteresting, you should
use the set_false_path or set_clock_groups commands instead.

Average User Rating: (4) Rate Article: Send comment

Save Article Tag Article Print Email

Your Recently Viewed Articles

Using the set_clock_sense -stop_propagation Command Properly With PrimeTime SI

Clock Gating Checks on Multiplexers
Huge Delay of 999 for Memory CLK-to-Q Arcs
How are Parallel Constraint Arcs Handled?
How write_interface_timing -timing_type arc_values Calculates combo_delay and setup/hold
Arc Values
Conditional Timing Arc FAQ
When Can report_timing and report_delay_calculation Differ?
Specifying MUXed Clocks in PrimeTime
negedge and posedge in SDF for Mux Written by PrimeTime
How Can I Find And Report the Clock Steering Logic in My Design?

Your Recent Searches

mux select arc

uix select arc
mix select arc
mix select lines
divide by two clock
create generated clocks
generated clocks

© 2017 Synopsys, Inc. All Rights Reserved. CONTACT US | TERMS OF USE | PRIVACY POLICY

https://solvnet.synopsys.com/retrieve/020879.html?otSearchResultSrc=advSearch&otSearchResultNumber=25&otPageNum=3 Page 3 of 3