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

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!