Constraint Construction: What's Its Function? Part 1 of 4

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!