I have a doubt about STA's `set_input_delay` and o...
# timing-closure
m
I have a doubt about STA's
set_input_delay
and openlane default
base.sdc
file: The base.sdc file assigns set_input_delay a positive number: IO_PCT * CLOCK_PERIOD, in my case 4ns. Is that positive delay in the inputs ports set as a pessimistic delay value between the input clock and the data ports? To account for a possible external delay? If that is the case, wouldn't that delay be pessimistic for SETUP violations, but optimistic for HOLD violations? Shouldn't be better to use 0 or negative number for hold analysis?
m
Yes, this is usually a pessimistic delay value as you suggest. You are correct about the hold checks. I'm not sure about having different corner setups in the flow though...
m
wouldn't a "normal" input delay between clk and inputs be 0 (or near that)? Because if I ran the make rcx-xxx with an input delay of 0, after having built my design with an input delay of 4ns I'm getting lots of hold violations.
m
This is meant to be pessimistic. I normally use the CLK-Q delay for a macro and I usually always drive outputs directly from DFFs, but I'm assuming they know that isn't true here. Instead, these are either coming from the LA or the GPIO. The LA is probably from DFFs, but the GPIO goes through the IO pads
or the wishbone output...
m
I think I'm starting to get it a little bit more (I'm fairly new to many of this topics) In most cases the inputs are passing to some DFF (or other synchronous cells?) that runs on the same clock, so there's no way the input delay could be 0, is going to be at least the propagation delay from CLK to Q. Is that right?
m
It also depends on the clock skew though. Right now, inputs are assumed to be synchronous to the ideal clock. Your other DFFs on chip will have a big delay due to the clock tree delay. In my case, it is like 6.5ns!
m
yes, that was my concern respect to the input delay parameter, because the DFF I was looking had a more direct path to the external input than the external clk, so I need to assume the input will always have some positive delay respect to the ideal clk, or else I would get hold violations
m
The way that you normally do this is use an off-chip clock, and then synchronize one of the clock leaves to it with the PLL. However, they don't have that option AFAIK
Or, you assume it is async and add a synchronizer