Part 2 - I/O TIMING: Talking Outside The BoxIt 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.
"That's great you closed timing on the interface. Too bad it was with the wrong clock."
"Wait, you mean data flows in both directions? Why didn't someone tell me that!"
"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..."
"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:
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!
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.
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.