Timing Constraints Tutorial

Have you found yourself frustrated at the lack of some decent timing constraints? Perhaps made
critical floorplanning and placement decisions only to have them thrown out because someone
forgot to mention a tiny detail in the constraints? Often times, the role of timing constraints is
marginalized until it‟s just too late.

Instead of assuming the constraints are correct, and getting rid of the attitude “That‟s not my
responsibility” or “I didn‟t know”, let‟s explore some questions we can ask the Timing
Constraint Designer that will help insure quality up front, instead of patching them in later on.
Even if you‟re not responsible for writing the constraints, at least this will help you become more
aware of what to look for to avoid a disaster.

I‟m going to assume right off the bat that you have a wonderful document in your hands that
might have the name “Clock and Timing Specification”. What‟s that you say? You never
received one? Never heard of such a thing? Indeed more often than not, a document which
clearly defines the clocking and timing relationship of a design can also fall by the wayside.
That‟s ok, let‟s use the same questions to help build a timing specification as well. But it sure
would have been nice to have that document, right? Insist on it as soon as possible!

I‟m going to break the topic into 4 posts as follows:

1. Clock Constraints
2. I/O Constraints
3. Path Exceptions
4. Design Rules and Operating Modes

I hope you walk away with some of the right questions to ask, and perhaps get your feedback on
ones I might have over looked. In between, I‟ll try and add some famous last words for a little
humor to lighten the mood. Isn‟t timing analysis supposed to be fun anyway?

Part 1 - CLOCKS: The Constraints Backbone

Timing constraints would have nothing to time against if there were no clocks defined. Let‟s
first go over the questions to ask about the clocks and whether the constraints reflect that or not.

 Ideal Waveform and Frequency

o (create_clock)
o What should the waveform look like?
o What is it‟s cycle and half-cycle time?
o Does the constraint defined match the intended frequency?

 Non-Ideal Incoming/Generated Waveform

o What will the REAL waveform look like coming into the system?
o Should it be allowed to distort to 55/45? 60/40?
o How will you model this with the tool and has it been tested properly to insure
correct use?

“But in school, they never told us that things are not ideal in the real world!”
  Source Locations (Internal/External)
o Where is the clock entering the system?
o Through an I/O cell?
o From the output of a clock divider?
o How about an on-chip PLL?
o Later on, are you adjusting that PLL correctly?

 Relationships Between Other Clock Domains

o (set_false_path -clock_from/-clock_to)
o How will the clocks interact with each other?
o Are they asynchronous or synchronous to one another?

“You mean I didn‟t have to spend my entire vacation closing timing on these 10,000 violating
paths because they were false?”

 Positive Or Negative Active Clock

o Will the clock be used by negative active flops or not?
o Has the clock been properly defined to reflect positive or negative active use?

 Clock Gating Requirements

o (set_clock_gating_check)
o What sort of setup/hold protection is needed when gating the clock?

“You really think you‟re passing timing on that clock gate with only 1ps of uncertainty? Sure
you don‟t want a little cushion in that?”

 Accounting For Jitter/Uncertainty

o (set_clock_uncertainty)
o Does the source of the clock have uncertainties to model jitter correctly?

“Management didn‟t tell you they purchased a PLL that had 350ps of jitter? Hey it was on
sale!! What did you expect?”

 Min and Max Clock Latency

o (set_clock_latency)
o Is there a maximum that the clock should take to reach its destination?
o When running ideal clock timing, should there be specific latenciesset to time the
system correctly?

Now to help check some of these items, I like to run the check timing analysis function in
Encounter (check_timing). This helps give a quick and organized report to review and share
with whoever is responsible for the constraints.

In the case of clocks, it will help find flops that are not receiving any clocks, spot where clock
gating situations occur, or even when multiple clocks are arriving at a destination. All of this can
point out big flaws in the constraints or even design.

Some of the checks it will do:

 Clock Signal Found Where Not Expected

  Clock Clipping Possible
 Clock Not Found Where Expected
 Data Gating Clock
 Clock Not Propagated
 Master Clock Does Not Reach Generated Clock Target
 Multiple Clocks Arriving At Gate Endpoint
 No Clock Source Found For Generated Clock
 Unconstrained Signal Reach Pin

Next time, we‟ll go over the importance of having good I/O constraints and what to look for!

Part 2 – I/O TIMING: Talking Outside The Box

It wouldn‟t be a chip or block if it didn‟t have to talk to something other than itself right? We
could always assume that every input arrives at exactly the same time, and every output has
exactly the same amount of external delay. The downside is you may never realize some of the
more complex aspects of the I/O timing without digging a little further. Last time we talked
about the right questions to ask with respect to the clocks, now let‟s go over some items to check
in the constraints dealing with I/O and port communication.

 Pad/Bus/Interface Identifications
o Where is data entering the system?
o Is there a relationship in the form of a bus or a more general interface?
o Are there skew requirements that need to be set?
o Is this an interface that is being referenced by a clock leaving the system with the
data, or perhaps data received with incoming clock? (such as a DDR)

 Reference Clock
o What clock domain will this data communicate with?
o Do you want to use virtual clocks as the reference clock(s)?

“That’s great you closed timing on the interface. Too bad it was with the wrong clock.”

 Implementation of I/O
o Is data entering the system through a bi-directional I/O?
o Is data on this I/O only entering or only leaving the system?

“Wait, you mean data flows in both directions? Why didn’t someone tell me that!”

 Setup and Hold Requirements

o What is the setup and hold requirement for the data versus its reference clock?
o Is this valid for all timing conditions, meaning best and worst case?
o Remember these setup and hold requirements need to be translated into the
set_input_delay and set_output_delay

 Absolute Arrival Times

o (set_input_delay/set_output_delay)
o In lieu of Setup and Hold values, is there a min and a max arrival time of data?
 o Does that min and max time change with respect to best or worst case?

“The customer told me that the data could arrive at the beginning of the clock all the way to
the end of the clock. That should be easy to meet…”

 Exception Path I/Os

o Are there any I/Os that should be asynchronous with a false path?
o Should there be multicycle paths set for any specific input or output ports?
o How about any constants to be set at the block level?

 Propagation Delay Requirements

o Is there a requirement that says how long data is allowed to propagate to an
endpoint or output port?

 I/O port modeling

o (set_drive, set_drive_cell, set_input_transition, set_load)
o Is there a driving cell on the input, or perhaps an input transition?
o Is the input port modeling the loading correctly with that driving cell?
o Do the outputs have the correct load assigned to them? Net and Pin loading?

“The only thing with my block is, it must be in a loving environment. Only sharp input slews
and low output capacitance will do with this cream puff.”

Going back to the check_timing report, it should list any I/O ports that have no constraint
input/output delay associated with it. While you may have a set_false_path -from/-to on the port,
it will still remind you to double check that.

Some of the checks it will do:

 Input Delay With No Reference Clock.

 External Delay With No Reference Clock.
 No Input Delay Set On Port.
 No Drive Constraint Set On Port.
 No External Delay Set On Port.

Another thing to think about, if the constraints have been partitioned from the top-level in
Encounter, the I/O constraints should have good realistic values for the items above. Of course
you better hope the constraints at the top-level were defined correctly…

Next time in part 3, we‟ll tackle the questions to ask for Exception Path Timing!

Part 3. EXCEPTION PATHS: For Every Rule, There Is An Exception

More often than not, I‟ll start an optimization on a block only to have it result in thousands of
timing violations. Many times, the culprit is a missing path exception constraint. When you see
timing violations that are suspicious, ask the RTL/constraint developer whether there are
exceptions to the timing rules you‟re trying to meet. Let‟s go over some items to consider when
debugging timing!
  Multi-Cycle
o (set_multicycle_path)
o Are certain paths allowed more than one clock cycle?
o Have these been properly defined for BOTH setup and hold?

“So my setup violation went away, but now I have -2ns hold violation. Come on, that can’t be
real?!”

 False Paths
o (set_false_path)
o Are there asynchronous paths, or ones that no timing is necessary?
o Are you sure that wildcard „*‟ is being applied correctly in this case?

“Finally, a constraint I can use: set_false_path -from * -to *”

 Path Delay
o (set_min_delay/set_max_delay)
o Is there a minimum or maximum amount of time a path should take?

“So you’d like me to work with a path delay between 1.000ns to 1.001ns in all corners. Let me
just put my blind fold on and tie this hand behind my back, cause you’re about to see some
magic…”

 Constants
o (set_case_analysis)
o Are there any ports or the output of a flop that sets the functional or test mode of
the constraints?

 Dont Care Paths

o (set_disable_timing)
o Are there paths that no data or clock should pass through?

“Then I disabled the timing arc on this clock gate and all my problems went away”

 Dont Touch Paths

o (set_dont_touch)
o Are there areas that should be left alone by any optimizer?
o Will the optimizer touch that ring oscillator?

“Good news! I reduced that ring oscillator thingy you guys added in down to a single
inverter. Yeah, I know, you can thank me later.”

 Dont Use Cells

o (set_dont_use)
o Are there any cells you‟re not allowed to optimize with?
o Did the synthesis team follow those rules too?

“Well they were using these cells so I figured I could too…”

It seems like when the physical designer is desperate to meet a timing path, we tend to pray that
there is a false path or multicycle path available to us. But it can often be difficult for the
constraint designer to catch these up front. When that‟s the case, try looking into the Conformal
Constraint Designer (CCD) which can be launched through Encounter. It can be used to catch
these path exceptions early on!

Next up in the last segment of this series we‟ll discuss Design Rules and Modes of Operation.
See you then!

This is the last in the series of Constraint Construction blogs! Today we‟re going to go over
DESIGN RULES and MODES OF OPERATION.

DESIGN RULES: Follow them, or else…

Often times, these rules are indeed set in the timing library. But perhaps you want sharper
transitions in your design to reduce noise issues. Or maybe you want to give yourself some
margin of safety with minimum capacitance. Let‟s go over the main design rules to live by.

 Max Fanout
o How many cells should each instance drive?
o Does the timing library set this at all or is it necessary for any specific library cells
or instances in the design?

 Min/Max Transition
o What is the maximum slew that each pin in the system should have? Should you
have max transitions on any input or output ports?

“So I cranked the max transition down to 100ps, and all my noise problems went away. Of
course the design doesn’t meet timing and is packed with buffers. But focusing on the good,…
I got rid of the noise!”

 Min/Max Capacitance
o Should there be a limit to the load on each driving pin?
o Perhaps even on an input port or internal net?

 Design Environment
o What timing library should we use?
o Which timing corners (PVT)?
o Will you be setting the operating conditions in the constraints?

“So you’re saying there is a Best Case environment? Why would I care about that if it’s so
good?”

MODES OF OPERATION: There‟s more than one way to peel an apple.

Functional Mode(s)

 Is there more than one functional mode?

o Will one set of constraints handle all the modes?
 o If multiple modes will be used, are all the files correctly defining each mode
correctly with the use of constants?

 Test Mode(s)
o Are there test modes that differ significantly from the functional operation (JTAG
Boundary Scan, BIST/MBIST, Shift, and Capture)?
o Have these been defined correctly as well?

Well, I hope this has been informative for everyone! The goal here is, whenever you get some
constraints from someone, and you are not sure how well they are „constructed‟, reference back
to this and ask these simple questions and you just might catch problems early enough!

To read up some more on this topic, check out this section in the Encounter docs (please note, to
access the doc requires and account and password): Setting Constraints and Performing Timing
Analysis in Encounter RTL Compiler
Thomas Moore This is the last in the series of Constraint Construction blogs! Today we‟re going
to go over DESIGN RULES and MODES OF OPERATION.

DESIGN RULES: Follow them, or else…

Often times, these rules are indeed set in the timing library. But perhaps you want sharper
transitions in your design to reduce noise issues. Or maybe you want to give yourself some
margin of safety with minimum capacitance. Let‟s go over the main design rules to live by.

 Max Fanout
o How many cells should each instance drive?
o Does the timing library set this at all or is it necessary for any specific library cells
or instances in the design?

 Min/Max Transition
o What is the maximum slew that each pin in the system should have? Should you
have max transitions on any input or output ports?

“So I cranked the max transition down to 100ps, and all my noise problems went away. Of
course the design doesn’t meet timing and is packed with buffers. But focusing on the good,…
I got rid of the noise!”

 Min/Max Capacitance
o Should there be a limit to the load on each driving pin?
o Perhaps even on an input port or internal net?

 Design Environment
o What timing library should we use?
o Which timing corners (PVT)?
o Will you be setting the operating conditions in the constraints?

“So you’re saying there is a Best Case environment? Why would I care about that if it’s so
good?”

MODES OF OPERATION: There‟s more than one way to peel an apple.

Functional Mode(s)

 Is there more than one functional mode?

o Will one set of constraints handle all the modes?
o If multiple modes will be used, are all the files correctly defining each mode
correctly with the use of constants?

 Test Mode(s)
o Are there test modes that differ significantly from the functional operation (JTAG
Boundary Scan, BIST/MBIST, Shift, and Capture)?
o Have these been defined correctly as well?

Well, I hope this has been informative for everyone! The goal here is, whenever you get some
constraints from someone, and you are not sure how well they are „constructed‟, reference back
to this and ask these simple questions and you just might catch problems early enough!