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
  • (create_clock)
  • What should the waveform look like?
  • What is it’s cycle and half-cycle time?
  • Does the constraint defined match the intended frequency?

• Non-Ideal Incoming/Generated Waveform
  • What will the REAL waveform look like coming into the system?
  • Should it be allowed to distort to 55/45?  60/40?
  • 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)
  • Where is the clock entering the system?
  • Through an I/O cell?
  • From the output of a clock divider?
  • How about an on-chip PLL?
  • Later on, are you adjusting that PLL correctly?

•  Relationships Between Other Clock Domains
  •   (set_false_path -clock_from/-clock_to)
  •   How will the clocks interact with each other?
  •   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
  • Will the clock be used by negative active flops or not?
  • Has the clock been properly defined to reflect positive or negative active use?

•  Clock Gating Requirements
  •  (set_clock_gating_check)
  •  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
  • (set_clock_uncertainty)
  • 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
  • (set_clock_latency)
  • Is there a maximum that the clock should take to reach its destination?
  • 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
  • Where is data entering the system?
  • Is there a relationship in the form of a bus or a more general interface?
  • Are there skew requirements that need to be set?
  • 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
  • What clock domain will this data communicate with?
  • 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
  • Is data entering the system through a bi-directional I/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
  • What is the setup and hold requirement for the data versus its reference clock?
  • Is this valid for all timing conditions, meaning best and worst case?
  • Remember these setup and hold requirements need to be translated into the set_input_delay and set_output_delay

• Absolute Arrival Times
  • (set_input_delay/set_output_delay)
  • In lieu of Setup and Hold values, is there a min and a max arrival time of data?
  • 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
  • Are there any I/Os that should be asynchronous with a false path?
  • Should there be multicycle paths set for any specific input or output ports?
  • How about any constants to be set at the block level?

• Propagation Delay Requirements
  • Is there a requirement that says how long data is allowed to propagate to an endpoint or output port?

• I/O port modeling
  • (set_drive, set_drive_cell, set_input_transition, set_load)
  • Is there a driving cell on the input, or perhaps an input transition?
  • Is the input port modeling the loading correctly with that driving cell?
  • 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
  • (set_multicycle_path)
  • Are certain paths allowed more than one clock cycle?
  • 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
  • (set_false_path)
  • Are there asynchronous paths, or ones that no timing is necessary?
  • 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
  • (set_min_delay/set_max_delay)
  • 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
  • (set_case_analysis)
  • Are there any ports or the output of a flop that sets the functional or test mode of the constraints?

• Dont Care Paths
  • (set_disable_timing)
  • 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
  • (set_dont_touch)
  • Are there areas that should be left alone by any optimizer?
  • 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
  • (set_dont_use)
  • Are there any cells you’re not allowed to optimize with?
  • 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
  • How many cells should each instance drive?
  • 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
  • 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
  • Should there be a limit to the load on each driving pin?
  • Perhaps even on an input port or internal net?

• Design Environment
  • What timing library should we use?
  • Which timing corners (PVT)?
  • 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?
  • Will one set of constraints handle all the modes?
  • If multiple modes will be used, are all the files correctly defining each mode correctly with the use of constants?

• Test Mode(s)
  • Are there test modes that differ significantly from the functional operation (JTAG Boundary Scan, BIST/MBIST, Shift, and Capture)?
  • 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
  • How many cells should each instance drive?
  • 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
  • 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
  • Should there be a limit to the load on each driving pin?
  • Perhaps even on an input port or internal net?

• Design Environment
  • What timing library should we use?
  • Which timing corners (PVT)?
  • 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?
  • Will one set of constraints handle all the modes?
  • If multiple modes will be used, are all the files correctly defining each mode correctly with the use of constants?

• Test Mode(s)
  • Are there test modes that differ significantly from the functional operation (JTAG Boundary Scan, BIST/MBIST, Shift, and Capture)?
  • 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

Courtesy
Thomas Moore

http://www.cadence.com/community/posts/Thom%20Moore.aspx

© Cadence Design Systems, Inc. All Rights Reserved