06-04-2019 08:34 AM
There are several document discusses how to specify the input timing. Here are some reference:
The input delay is the "clock to Out" + "trace delay".
But what is "trace delay" aka. "board delay"?
I know that this is the propagation form the source device towards the target device (FPGA), but what retarding effect must be included when I calculate the board delay? How to calculate board delay and what delays included in the "clock to Out" and setup/hold times?
I am sure that the signal propagation thorough a pcb transmission line is part of the board delay. But is this all?
Where do we count the load charging delay? I mean the FPGA pin and the line itself have capacitance. The load of these capacitance (the time when the signal reach the input comparation value) also delays the signal. Should I add this delay to board delay? If not which delay (clock to out or setup/hold) includes this delay?
06-12-2019 02:37 AM
When board designer design the board for system i.e. FPGA + 3rd party ICs. The routing taken place on board is trace delay. All board design team perform tests to find out that what is the min/max delay over PVT.
trace delay is out of scope of FPGA (i.e. exterior for Xilinx tool) so you cannot find those value calculations in Xilinx tools. You need to get those values from board design team or company. And you can then use those value to make your constraints more precise.
06-12-2019 04:17 AM
I can see you are “climbing that hill” towards understanding and writing timing constraints for FPGA IO interfaces. As you have found, a thing called “trace delay” is part of these IO constraints. If we take the words at face value, then “trace delay” is the time needed for a signal to travel the length of a specific trace on your FGPA board. As described by yashp, you can usually get this “trace delay” number from the person who designed your FPGA board. However, the “trace delay” that you need for writing IO constraints is actually a trace-delay-difference.
Xilinx documentation lacks much of the detail and explanation needed for writing IO constraints. However, you might find <this> post to be a good start for “climbing that hill”. I hope (expect) you will have more questions about IO constraints.
06-12-2019 04:35 AM
I wish they would employ you to audit the timming description docs,
when I'm on a machine that I can Kdo fomr , I will do.
06-26-2019 02:41 AM
My misundersooding based on a simple issue.
I standard, perfectly mached connection (transmission line) has well defined distributed-capacitance, and has no discrete-capacitance. And in this case the board delay is the signal propagation thorough a pcb transmission line.
06-26-2019 03:47 AM
If you ever finrd that perfect transmision line, please let us know.
By th etime you probe a line, let alone have bends, pads for components, or forgive me, connectos or vias, its no where near perfect
06-26-2019 04:46 AM
drjohnsmith knows this better than I, but thought you'd like to know....
Here in the good old USA, we use 2ns/foot as a rule-of-thumb for calculating the delay of circuit board traces. Now-a-days, circuit board traces are usually short (<2 inch – don’t you love our measurement system!). So, for the clock and data lines of an FPGA IO interface, the trace-delay is small (< 0.2ns) and the trace-delay-difference is even smaller. Thus, when writing the timing constraints for an FPGA IO interface, the trace-delay-difference is often an almost insignificant factor. However, in older days, the trace-delay-difference was actually used to make the IO interface work properly. That is, we once purposely made the clock-trace-delay different from the data-trace-delay in order to place the clock capture edge in the middle of the data-eye (ie. to achieve center-aligned data).