Home > Community > Blogs > Digital Implementation > constraint construction what s it s function part 2 of 4
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Digital Implementation blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

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

Comments(2)Filed under: Constraint Design, Encounter Timing System, STA, Encounter Digital Implementation

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!

Comments(2)

By dlferrao on February 20, 2009
Great guide!
I really got troubles on that in past designs.
I did close time for some hold/setup environment and then find it was just a draft.
When doing first trial synthesis the I/O constraints should be mature or leave some margin, other way you can find too late that you RTL will not work with the final I/O constraints.
Any suggestion on how to get your initial I/O constraints usefull? I mean, they will change for sure, but I don't want it to make time closure a pain or impossible.

By Thom Moore on March 6, 2009
Hi dferrao!   Thanks for the comment.  I've battled for good I/O constraints from RTL developers as well, and unfortunately I find that every design is different and one rule does not necessarily apply to all.  If we are talking about a block, I generally assign input and output delay values that are 10% for early and 90% for late.  So for example, if I have a clock period of 2.0ns, I'll have:
 set_input_delay 0.200 -clock [get_clocks clk1] -min [get_ports portA] -add_delay
 set_input_delay 1.800 -clock [get_clocks clk1] -max [get_ports portA] -add_delay
That' is certainly aggressive, but I'm doing this in light of the fact I have no idea what these values are and it can help me identify I/O problems early on.  If however this is effecting my reg2reg optimization, I'll back it off to 20% and 80%.  
For chip I/O timing, that's a whole other creature.  Everything depends on how the data is being referenced, and the interface that you are timing.  I have personally worked on a chip where I did not have chip I/O constraints until 2 weeks prior to tapeout.  It's not fun, but the only way I received those was continuously bugging the constraint designer!  You can try your best at having something in place to atleast become more familiar with any problems later on.  Just do your best at having some understanding of the interface and leaning on the pessimistic side for the constraints until you get realistic values.

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.