NanoTime Best Practices

Clock
Application Note
Version 1.0, August 2009

Comments?
Send comments on the documentation by going
to http://solvnet.synopsys.com and clicking
Enter a Call to the Support Center.

Copyright Notice and Proprietary Information

Copyright 2009 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and
proprietary information that is the property of Synopsys, Inc. The software and documentation are furnished under a
license agreement and may be used or copied only in accordance with the terms of the license agreement. No part of
the software and documentation may be reproduced, transmitted, or translated, in any form or by any means,
electronic, mechanical, manual, optical, or otherwise, without prior written permission of Synopsys, Inc., or as
expressly provided by the license agreement.

Right to Copy Documentation

The license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only.
Each copy shall include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee
must assign sequential numbers to all copies. These copies shall contain the following legend on the cover page:
This document is duplicated with the permission of Synopsys, Inc., for the exclusive use of
__________________________________________ and its employees. This is copy number __________.

Destination Control Statement

All technical data contained in this publication is subject to the export control laws of the United States of America.
Disclosure to nationals of other countries contrary to United States law is prohibited. It is the readers responsibility to
determine the applicable regulations and to comply with them.

Disclaimer
SYNOPSYS, INC. AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH
REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

Registered Trademarks ()
Synopsys, AMPS, Astro, Behavior Extracting Synthesis Technology, Cadabra, CATS, Certify, CHIPit, Design
Compiler, DesignWare, Formality, HDL Analyst, HSIM, HSPICE, Identify, iN-Phase, Leda, MAST, ModelTools,
NanoSim, OpenVera, PathMill, Physical Compiler, PrimeTime, SCOPE, Simply Better Results, SiVL, SNUG, SolvNet,
Syndicated, Synplicity, the Synplicity logo, Synplify, Synplify Pro, Synthesis Constraints Optimization Environment,
TetraMAX, the Synplicity logo, UMRBus, VCS, Vera, and YIELDirector are registered trademarks of Synopsys, Inc.

Trademarks ()
AFGen, Apollo, Astro-Rail, Astro-Xtalk, Aurora, AvanWaves, BEST, Columbia, Columbia-CE, Confirma, Cosmos,
CosmosLE, CosmosScope, CRITIC, CustomSim, DC Expert, DC Professional, DC Ultra, Design Analyzer, Design
Vision, DesignerHDL, DesignPower, DFTMAX, Direct Silicon Access, Discovery, Eclypse, Encore, EPIC, Galaxy,
Galaxy Custom Designer, HANEX, HAPS, HapsTrak, HDL Compiler, Hercules, Hierarchical Optimization
plus
Technology, High-performance ASIC Prototyping System, HSIM , i-Virtual Stepper, IICE, in-Sync, iN-Tandem,
Jupiter, Jupiter-DP, JupiterXT, JupiterXT-ASIC, Liberty, Libra-Passport, Library Compiler, Magellan, Mars, Mars-Rail,
Mars-Xtalk, Milkyway, ModelSource, Module Compiler, MultiPoint, Physical Analyst, Planet, Planet-PL, Polaris,
Power Compiler, Raphael, Saturn, Scirocco, Scirocco-i, Star-RCXT, Star-SimXT, System Compiler, System
Designer, Taurus, TotalRecall, TSUPREM-4, VCS Express, VCSi, VHDL Compiler, VirSim, and VMC are trademarks
of Synopsys, Inc.

Service Marks (SM)

MAP-in, SVP Caf, and TAP-in are service marks of Synopsys, Inc.
SystemC is a trademark of the Open SystemC Initiative and is used under license.
ARM and AMBA are registered trademarks of ARM Limited.
Saber is a registered trademark of SabreMark Limited Partnership and is used under license.
All other product or company names may be trademarks of their respective owners.

Page ii

Contents
Introduction ............................................................................................................ 1
Clock Definition ..................................................................................................... 1
Generated Clocks .................................................................................................. 2
Reconvergent Clocks ............................................................................................ 3
Clock Propagation ................................................................................................. 4
Dynamic Clock Simulation (DCS).......................................................................... 6
Clock Reporting and Debugging ........................................................................... 7
Summary ............................................................................................................... 9

Page iii

Introduction
In the second phase of analysis, you specify all the clocks and topologies in the
design. You can also provide specifics on I/O constraints in SDC format, case
settings and logic constraints, timing exceptions, user-defined timing checks, and
parasitics in either this phase or the next. Some case analysis settings and logic
constraints might be necessary before topology matching to get maximum clock
penetration or for correct MUX recognition, for example. It is generally advisable to
defer specifying case settings and logic constraints until after check_topology so
that you dont have to re-run check_topology to see the effects of changing such
constraints in the design. In this section we will look at clock specification and
propagation in NanoTime.
Ensuring proper clock propagation is crucial for successful timing analysis using
NanoTime. Identifying correct clocks in a design is important for several reasons:

Topology recognition: structures that rely on clocks such as clock gates, sequential
devices like latches, flip flops, domino cells, memory elements, etc.
Installing correct default timing checks: setup/hold checks and clk-to-q checks for latches,
flip-flops, domino precharge structures, input/output constraint checks, etc.
Creating user-defined timing checks.
Tip: As a general practice, always make sure that the clocks are reaching all the
expected points in the design before evaluating the timing report because
unpropagated clocks lead to missing timing paths and checks.

Clock Definition
In case NanoTime is unable to propagate clocks to all the expected endpoints in the
design, there are several commands, variables, and attributes available to you that
check the clock network and also help with debugging any issues. Clocks are
specified using the create_clock and create_generated_clock commands in
NanoTime. For example,
create_clock -name clk1 \
-period 2.0 \
-waveform {0 1} \
[get_ports clk1]

Page 1

Tip: If no physical port or transistor gate pin is specified with the

create_clock command, then a virtual clock is created.

By default, NanoTime treats all clocks as propagated clocks. For propagated clocks,
NanoTime calculates the cumulative delays along the clock network, including wire
delay. The opposite is an ideal clock. For ideal clocks, NanoTime uses the latency
values set on clocks, ports, or pins using the set_clock_latency command, or
zero latency if none has been set.
You can control the ideal or propagated clocking behavior in NanoTime using the
timing_all_clocks_propagated variable or the set_propagated_clock and
remove_propagated_clock commands.
Tip: A few more points about ideal clocking:

Use the set_clock_transition command to set the slope at the ideal clock-tree
endpoints; use the set_input_transition command for propagated clocks
Use set_clock_latency source to specify the source latency, or the delay from
the external ideal waveform to the clock definition point in the design
Use set_clock_latency (without the source option) to specify network
latency, or the delay from the clock definition point to the sequential elements in the
design

Generated Clocks
Another method of specifying clocks in a design involves using the
create_generated_clock command. Using this command, you can create a clock
object and apply the clock to a specified source object in the current design. The
timing characteristics, such as period, waveform, and latency, of the generated clock
depend on another clock in the design, called the master clock. If you change the
characteristics of the master clock, then the generated clock characteristics also
change accordingly.
An example usage of create_generated_clock is shown in Figure 1. The
command used is:
create_generated_clock name CLK2 source [get_ports SCLK] \
divide_by 2 [get_pins FF1/Q]

Page 2

Figure 1 Divide-by-2 clock generator specified with create_generated_clock

Tip: A few notes about create_generated_clock:

Generated clocks can only be specified on actual design objects like port, pin, or net;
you cannot specify a virtual generated clock
A generated clock can, however, be referenced off of a virtual clock source
Unlike create_clock, create_generated_clock can be applied on nets,
including non-stage boundary nets; NanoTime will promote proper pins to the timing
graph
This command can be used to create pulse clocks; it can also be used to create
inverted, multiplied, and divided clocks
To generate a timing model, you need to specify a source clock on a physical port/pin
which can then be referenced using the create_generated_clock source
option. Otherwise you will get a CMDS-047 warning ("Clock <clk> does not
have a source defined")

Reconvergent Clocks
NanoTime automatically detects simple clock shapers and clock pulse generators as
shown in Figure 2. The variable to control "detection of such circuits is
topo_clock_gate_allow_reconvergent_clocks. This variable is set to true by
default. Clock shapers and pulse generators are reported with an (s) or (p)
attribute in report_topology verbose structure_type clock_gate to
represent a clock shaper or a clock pulse generator, respectively.

Page 3

Figure 2 Automatically recognized clock pulse generator

Tip: Only CMOS gates with two reconvergent clocks created from a single clock
source are currently supported for automatic detection of clock shapers and
pulse generators. Feedback shapers/pulse generators and feedback
transparent gated clocks are not supported at this time.

Clock Propagation
In NanoTime, clock propagation occurs when match_topology (or
check_topology in the absence of match_topology) is issued for the first time.
During the clock propagation phase, NanoTime pushes the clock property onto
nets/pins starting from the primary clock definition point through the inverters, buffers,
clock gates, and other structures on the clock network. NanoTime does not check the
logic settings that might otherwise prevent the clock flag from propagating
downstream. This is done to ensure that the clock property reaches all the valid
endpoints in the design.
Tip: In order to force NanoTime to take into consideration the logic settings on
the nets and devices on the clock path, set the variable
topo_clock_propagation_strict_logic_check to true; this strict logic
checking can result in fewer clock nets and sequential devices being reported
in the current design.

Page 4

In some cases, it may be necessary to re-propagate clocks based on some user

topology marking after match_topology. Topology marking commands such as
mark_latch, mark_precharge, mark_register_file, mark_clock_gate,
and mark_feedback can affect clock propagation. Set the variable
topo_match_topology_reset_clock_and_topology to true before
check_topology to allow NanoTime to re-propagate clocks at each subsequent
match_topology or check_topology command.
Tip: NanoTime will re-propagate clock only if one or more of the following
conditions is true:

mark_clock_gate was added to a non-clock device

mark_latch, mark_precharge, or mark_register_file was added on a
clock net
mark_feedback was added on a non-clock net to enable automatic clock gate
recognition on that net

NanoTime must be configured properly when multiple clocks converge at a point as in

the case of a clock MUX. This is required because NanoTime can perform timing
analysis with respect to only one unique clock waveform at a node. A simple 2-to-1
MUX is automatically recognized by NanoTime, but for more complex structures, it
may be necessary to either specify proper logic constraints using the
set_logic_constraint command or manually mark the MUX using the
mark_mux command. However, simply recognizing a MUX is not enough when it is
on clock path. You must also explicitly select a clock for timing analysis. This can be
done by using the set_case_analysis command.
Tip: You may see a TOPO-025 warning ("Clock propagation intersects
at net clk") at the common MUX node; it is generally okay to see this
warning for a properly configured clock MUX.
NanoTime can automatically recognize clock gating structures such as NAND and
NOR gates. Any complex clock gate needs to be manually marked using the
mark_clock_gate command. By default, NanoTime stops propagating a clock flag
after a user-controlled number of static gates are encountered on a particular clock
path. The topo_clock_gate_depth variable controls this behavior in NanoTime.
The variables default value is 5 which means that the clock flag will not propagate
beyond the fifth clock gate on a particular clock path. Inverters and buffers do not
count towards the clock gate depth limit set by this variable.
Tip: If a particular clock path contains more than 5 clock gates, you need to set
the topo_clock_gate_depth limit to a higher number. Otherwise, NanoTime
will stop clock propagation on that path and issue a TOPO-069 warning

Page 5

message ("Maximum clock gate depth of 5 exceeded at net clk5

during clock propagation")

Clock propagation stops at the clock pins of sequential devices and at clock output
ports. If you want to continue clock propagation through a sequential device, use the
mark_clock_network force_propagation command. If you want to stop
clock propagation at any point in the design, use the mark_clock_network
stop_propagation command.

For example, the minimum set of commands required to correctly configure the clock
divider shown in Figure 3 is:
create_clock -name clk -period 2.0 -waveform {0 1} [get_ports clk]
create_generated_clock -name clkdiv2 -edges {1 3 5} \
-source [get_ports clk] [get_nets clkdiv2]
mark_clock_network -force [get_nets {xslave.lat}]

Figure 3 Clock divider example

Tip: mark_clock_network is generally needed in a clock divider circuit to
force clock propagation through the slave latch node.

Dynamic Clock Simulation (DCS)

Clock networks are sometimes built as complex trees that are difficult for NanoTime
to analyze accurately with the default fast internal simulator. To ensure accurate
analysis of these networks, invoke a dynamic clock simulation. For example, if a clock
generation circuit uses feedback loops, multiple paths, simultaneous switches,
latches, flip flops, clock edge chopping, or clock merging, the internal simulator might
not be able to generate the correct clock waveforms. In such cases, you can analyze
the entire clock circuit accurately by using a dynamic clock simulation.

Page 6

To invoke dynamic clock simulation, set the dcs_enable_analysis variable to true.

Note that any special markings required to correctly propagate clocks through a
complex clock tree network are still needed, such as mark_clock_network or
mark_clock_gate. NanoTime uses a dynamic simulation to calculate the entire
clock network delays and uses these clock arrival times for all timing check
evaluations and path reporting.
Tip: A few notes about Dynamic Clock Simulation (DCS):

The internal clock nodes are not visible in DCS; the clock tree is a black box with
waveforms available only at the clock network endpoints
DCS cannot be used with read_spice_model/set_technology flow
Set dcs_spice_header, dcs_control_header, dcs_number_of_cycles
variables to further customize the DCS simulation in NanoSim

Clock Reporting and Debugging

You can verify input clocks and their waveforms by using report_clock. This
provides information about clock properties such as name, period, waveform (rise and
fall times), and clock source objects. If the clock source object is not a physical
port/pin in the design, then it is a virtual clock. The report_clock command will
also report if the clock is ideal or propagated, a pulse clock, or a generated clock.
The report_clock_arrivals command is very useful in NanoTime to check clock
nets and their corresponding min/max rise/fall arrival times. All the boundary nets of
channel-connected blocks (CCBs) are assigned a clock property if they are part of
NanoTime-identified clock network. If a particular net was not identified as a clock net
or if it is not a CCB boundary net even if it is part of a NanoTime identified clock
network, report_clock_arrivals issues the following message:
nt_shell> report_clock_arrivals clk1b
Warning: Net clk1b is not a clock net. (CMDS-043)
0
Clock delays are not calculated until either trace_paths, extract_model, or
characterize_context is run. So at any time between check_design and
trace_paths, report_clock_arrivals clk would return the following:
Net
Min Rise Min Fall Max Rise Max Fall Period
type
---------------- --------- --------- --------- --------- -----clk
------

Page 7

This shows that net clk was identified and marked as a clock net but no delay
numbers were calculated. If the same clock net is queried after trace_paths:
Net
Min Rise Min Fall Max Rise Max Fall Period
type
----------------- --------- --------- --------- --------- ----clk
0.182
1.113
0.182
1.113
2.000
Tip: The report_clock_arrivals tree [-net] utility is a powerful clock
debugging tool in NanoTime; using this, you can find out exactly how far a
particular clock signal traveled and through which devices.
Example report_clock_arrivals tree output:
0.000 r clk (Clock source pin)
`- 0.000 r x6.mn1.g(inv) (via net)
`- 0.023 f x7.mp1.g(inv) (via inverter)
`- 0.042 r xslave.mn1.g(simple_latch) (via inverter)
|- 0.067 f xslave.x2.mp1.g(inv) (via
force_propagation)
| |- 0.102 r x3.mn1.g(inv) (via inverter)
| | `- 0.127 f x4.mp1.g(inv) (via inverter)
| |
`- 0.151 r x5.mn1.g(inv) (via inverter)
| |
`- STOPPED f xmaster.x2.mp1.g(inv) (via
unknown gate type) (false path, logic blocking, other)
| `- 0.102 r clkdiv2 (via inverter) (generated clock
pin)
`- STOPPED r xslave.x2.mn1.g(inv) (via
force_propagation) (false path, logic blocking, other)
You can then focus on the STOPPED clock points and take appropriate action like
mark/remove a clock gate or check logic constraints or path exceptions that may be
preventing clock propagation at that point.
Tip: A few clock debugging tips:

NanoTime, by default, optimizes the timing graph by removing arcs that do not lead to
timing checks or to path endpoints that have timing checks associated with them; you
may see only one clock edge reported by report_clock_arrivals in such cases
o Dead-end paths
o User-defined false paths
For missing clocks, check if there are any:
o set_false_path
o set_case_analysis

Page 8

mark_instance dont_search_thru_gate
[-dont_search_thru_channel]
o Clock merging through a non-static gate
Certain topologies optimize away some arcs:
o Tgate controlled by an inverter
o MUX XOR
o Register files

Refer to SolvNet article 024540 for more information on clock propagation and
debugging tips in NanoTime. Refer to SolvNet article 024473 for clock gating and
pulse generation analysis in NanoTime.

Summary

Ensuring proper clock propagation is very crucial for successful static timing analysis using
NanoTime.
Several different types of clocks such as ideal, propagated, generated, divide-by, multiply-by,
pulse, etc. can be specified in NanoTime; gated clocks are also supported.
Clock selection through MUX is supported but a timing run can only be performed at a single
clock frequency in NanoTime; the path database needs to be cleared before performing timing
analysis at a different clock frequency in the same NanoTime session.
Dynamic Clock Simulation (DCS) can be performed for complex clock network using feedback
loops, simultaneous switching, etc.
Forcing and stopping clock propagation at design pin/net objects is supported in NanoTime;
report_clock_arrivals is a useful clock debugging tool.

Page 9