09-06-2017 06:44 AM
I am using Vivado 2017.2 and have several ODDRs instantiated.
While investigating several a clock to Q setup violations, I stumbled upon something strange.
The OBUFs are having varied Prop_obuf_I_O delay values. I mean the difference is striking!
My understanding was that as per the ODDR location there can be a little variation of the values, but not as much as 1.434 and 3.567. Please take a look at the screenshot.
Can anyone explain why is this so? Is this normal?
09-06-2017 06:57 AM
You haven't given us much context to go on, but most likely you are comparing a timing report at slow process corner and at fast process corner.
The performance of all silicon devices vary across process, voltage and temperature (PVT). This variation is typically about 3:1 in a pure transistor based propagation delay (which is definitely the case for an OBUF). So the values you are showing would be about typical of the fast to slow PVT ratio.
(By default) Vivado performs setup and hold checks at both fast and slow process corner. Each timing report tells you what the corner in the path header...
But you are correct - two ODDRs (on the same clock network) driving two OBUFs (with the same configuration) will have little skew. The value is not specified, and the tools are somewhat pessimistic regarding how much skew they can see, but they definitely will not be this large... The old rule of thumb was around 200ps of skew (assuming the IOBs are relatively close to eachother), or a bit more if they are farther away, although the tools seem to indicate things more in the 500ps range...
09-07-2017 01:34 AM - edited 09-07-2017 03:35 AM
Thanks for the nice short explanation and the 3:1 ratio stuff.
I didn't pay attention to process corner information.
Actually I was packing the device (xc7a200tifbv676-1L) to the max and checking to see if I can pass timing. I wasn't expecting an answer so fast yesterday, so immediately after analyzing the violations, I reduced some of the interface logic and did re-implementation.
I now don't see any ODDRs with such varied delays, as they are all in the fast process corner.
I will trigger this post again, if I am able to re-produce the situation when I am adding back the extra interface-logic in my design.