As a hardware designer you have consider the timing constraints of both the input and output device. Input devices specify a setup and hold time reference to the clock (the time in which the data should be stable after a clock edge).
What I can't seem to understand is the output device(I'm not an FPGA engineer). There is a internal clock propagation delay for each flip-flop and its output pin. Let's say that the maximum clock-to-output (tco_max) delay is 7[ns], how can this pin then operate at 100[MHz] as the has a clock period of 10[ns] so 5[ns] high and 5[ns] low.
Data should be sent first as the input device requires a setup time, so let's say the input device has a setup time of 2[ns]. The FPGA should make sure that the data is sent at least 2[ns] before the clock edge. And the input device has a hold time of 1[ns]. A clock controls the output pins so it can never be that the output pins toggle before the clock tells them to. Except if it either delays the clock to the input device or uses an faster different clock internally compared to the outputted clock towards the input device.
Hopefully the picture makes my question a bit more clear. Does the FPGA use a different clock internally compared to externally. And if the external clock is shifted only 7ns what does this mean for the propagation delay you will have on the board due to trace length differences.
-
\$\begingroup\$ Need a bit of clarification. So you have an FPGA sending data to another device, right? And both the FPGA and that other devices are clocked with the same 100 MHz clock? And the both use the same edge of the clock, rising edge? \$\endgroup\$SteveSh– SteveSh2023年12月04日 11:39:54 +00:00Commented Dec 4, 2023 at 11:39
-
\$\begingroup\$ Hi @SteveSh, Indeed the FPGA sends the data and provides the clock. But this is more of a general question. I don't know if the FPGA uses a different clock internally. I don't get how I could realize this otherwise. \$\endgroup\$Dukel– Dukel2023年12月04日 11:48:09 +00:00Commented Dec 4, 2023 at 11:48
-
\$\begingroup\$ Part of the answer comes down to how the clock to output delays, Tco, for an FPGA is specified. Is it relative to the clock input to the FPGA, or is it relative to the internal FPGA clock? In either case, the static timing tool should give you the WC input clock to output delays for every path through the FPGA. \$\endgroup\$SteveSh– SteveSh2023年12月04日 11:52:59 +00:00Commented Dec 4, 2023 at 11:52
-
\$\begingroup\$ If the clock to output delay of the source FPGA is 2 ns (best case, or fastest), and the WC hold time for the destination part is less than 2 ns, then you are OK, assuming the external clock reaches both devices at the same time. \$\endgroup\$SteveSh– SteveSh2023年12月04日 11:55:25 +00:00Commented Dec 4, 2023 at 11:55
-
\$\begingroup\$ Sorry I can't follow. Let me try to change the question in a problem. How would you determine the maximum propagation delay for the trace lengths on the PCB so that the setup and hold times are still met? \$\endgroup\$Dukel– Dukel2023年12月04日 12:09:02 +00:00Commented Dec 4, 2023 at 12:09
1 Answer 1
It seems that in my case the output clock is inverted. Therefore leaving me 5[ns] before and after the edge. So 3[ns] for the setup time and 4[ns] for the hold time. Here the propagation delay inside the FPGA is not taken into account yet, but this will normally be in the picoseconds.
Explore related questions
See similar questions with these tags.