--- Quote Start ---
Can you throw some more light on the constraint with the input to output pin propagation delay?
--- Quote End ---
Consider the following example:
- FPGA design has two inputs 'A' and 'B'; one output 'C'. The functional requirement is simply C <= A and B;
- 'A' and 'B' are outputs of some other device(s) on the board that is clocked by the signal 'CLK'; the clock to output delay of that device(s) is 5 ns. This device is 'U1'.
- 'C' is received by yet another device on the board that is clocked by 'CLK'. There is a setup time requirement on that device that 'C' must arrive at the device at least 3 ns before the rising edge of 'CLK'. This receiving device is 'U2'.
- The period of 'CLK' is 20 ns.
- The skew of 'CLK' between U1 and U2 is estimated to be no more than 0.5 ns.
So the function that the FPGA is implementing is simply an 'and' gate, there are no flip flops involved, no clock. Therefore 'A' and 'B' would not have any setup time requirements; 'C' would have no clock to output requirements. Yet the system as a whole does have timing requirements. However, if you tried to enter setup requirements for 'A' or 'B' or clock to output requirements for 'C', Quartus would ignore them (and it would also list those requirements as being ignored).
What the FPGA is implementing though is a purely combinatorial logic path which means that the requirement that needs to be specified is a pin to pin propogation delay. For this example, the tpd requirement for 'A' would be calculated as:
Tpd_Rqmt_A_To_C = Clock_Period - Tco(A) - Tsu(C) - Clock_Skew
Tpd_Rqmt_A_To_C = 20 ns - 5 ns - 3 ns - 0.5 ns = 11.5 ns
Signal 'B' would have an analogous calculation and in this example the computed number would be the same 11.5 ns. However, one must still treat these as independent logic paths. If 'B' came from some other device than 'A' and had a different delay then 'Tpd_Rqmt_B_To_C' would have a different value than 'Tpd_Rqmt_A_To_C'. Whether they are the same or different, both constraints are entered into Quartus and as with the other timing requirements mentioned in my previous response would be taken into account during place/route and reported on to determine if the requirements have been met.
One simple way to check to see if you have all of these basic requirements (setup, clock to output, prop delay) specified is to look at the Quartus timing report. It will have a section called 'Unconstrained Paths'. Basically what this is listing are paths that have no timing requirements specified. At a minimum, you should have no such paths if you think you have fully specified the timing requirements.
There can be situations where you really do not have any specific prop delay requirement. Taking this same example, what if there was no setup time requirement on 'C' (perhaps the receiving device really can take this signal in completely asynchronously). Now you would have no prop delay requirements from 'A' to 'C' or 'B' to 'C'. What you can do in that situation is simply enter a nominal delay into Quartus. What this does is removes these paths from Quartus' list of 'Unconstrained Paths' but does not overly burden the place/route operation trying to meet some absurd requirement. This makes it easier to verify that the timing requirements are met as you do new builds since you simply need to see that there are no failing timing paths and no unconstrained paths.
As you change your design to fix functional problems, you should also look to see that there are no new 'Unconstrained Paths' that are popping up. Again, taking this example (with 'C' still having a setup time requirement), what if you changed the function so that 'C' is now a clocked output. In that situation, the prop delay requirement that you previously specified would now show up as an 'Ignored timing assignment'; setup time to 'A' and 'B' as well as clock to output delay of 'C' should show up as 'Unconstrained Paths'. So logic changes can alter what you need to specify as the timing constraints.
Kevin Jennings
Honored Contributor
