- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In order to constrain I/O timing I need the setup and hold times of the device I am interfacing with.
Usually that can be found in the data sheet of that chip. But what if I am interfacing with another FGPA? Assuming that I design both FPGAs, so I have the design and synthesis of both sides. How do I determine the setup / hold times?Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- In order to constrain I/O timing I need the setup and hold times of the device I am interfacing with. Usually that can be found in the data sheet of that chip. But what if I am interfacing with another FGPA? Assuming that I design both FPGAs, so I have the design and synthesis of both sides. How do I determine the setup / hold times? --- Quote End --- As you realised FPGA is configurable with respect to setup/hold. For two fpgas you can set input delay of destination device to some arbitrary values and see report for achieved tSU/tH (datasheet)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
kaz, I'm not sure I really understand your answer.
Say FPGA 1 communicates with FPGA 2. Now I want to write the I/O constraints for FPGA 1. For that I need the Tsu and Th of the external device, i.e. FPGA 2. For these I/O constraints I am supposed to use arbitrary values? And then look where? The report (of FPGA 2) or the data sheet?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- kaz, I'm not sure I really understand your answer. Say FPGA 1 communicates with FPGA 2. Now I want to write the I/O constraints for FPGA 1. For that I need the Tsu and Th of the external device, i.e. FPGA 2. For these I/O constraints I am supposed to use arbitrary values? And then look where? The report (of FPGA 2) or the data sheet? --- Quote End --- datasheet here does not mean datasheet as we know it. Once you run timequest you get a report section called datasheet which informs of achieved tSU/tH/tCO you apply some sensible values on fpga2 input delays (destination device) run project, run timequest and see datasheet report of timequest Then use that for fpga1 output delay values
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Chicken and the egg. You really have to constrain one before the other. I usually start with the output side. So let's say I have a 20ns clock period feeding both FPGAs, and a 1ns board delay. On FPGA 1 I might do:
create_clock -period 20.0 -name virt_clk set_output_delay -clock virt_clk 20.0 [get_ports fpga1_dout*] This is an impossible constraint, as it says the external device uses up all 20ns of the period and so fpga1 needs to get its data out in 0ns to meet timing. So I compile and find these outputs fail timing by -7.3ns. I would then change my output delay to: set_output_delay -clock virt_clk 12.0 [get_ports fpga1_dout*] This means the external device uses 12ns and fpga1 must get its data out in 8ns or less to meet timing. (You could make the output delay as high as 12.7 and it should work, but there might be some variation compile to compile, so if I can I put a little margin on it. You can tighten it later if need be). I may recompile just to make sure it meets timing. Now onto FPGA2. We know FPGA1 gets its data out in 8ns or less, and the board delay is 1ns, so I would do: set_input_delay -clock virt_clk 9.0 [get_ports fpga2_din*] I am constraint FPGA2 in terms of the constraint I put into FPGA1. If something doesn't meet timing, I tweak it. If FPGA2 has 5ns of slack and FPGA1 has only 0.1ns of slack, I may shift the requirements to even it out some, but I absolutely don't have to either. The problem with Report DataSheet is it's not a requirement. You might look at it after a compile and see that the Tco of fpga1 is 7.3ns, and then use that to constrain fpga2, but on another coompile it might be higher and don't want to check it after every compile. By constraint fpga2 in terms of the constraint you put on fpga1(and conversely fpga1 is now constrained based on the constraint you have for fpga2), if anything fails timing you will see it in TimeQuest.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Okay, so in that example, to constrain FPGA 2 in the second step:
Instead of looking up FPGA 1's actual Tco in "Report DataSheet", I use the constrained 8 ns Tco + 1 ns board delay as the input_delay. That would be the maximum value then. Should I also add a "set_input_delay -min" constraint?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can do a min in a similar manner. In this example there isn't much need for one, as the hold relationship is 0ns across the interface, which is pretty much impossible(a huge amount of clock skew on the receiver might make it possible).
After the compile of fpga1 where the set_output_delay was 20, you may see in the fast timing model that it's Min Tco is 3ns. Then go ahead and put a set_output_delay -clock virt_clk -min -3.0 [get_ports fpga1_dout*] (Add the -max option to the other constraints, I forgot to do that). This says the min external delay is -3ns, so FPGA1 must get it's data out more than +3ns after the clock to meet hold timing. Actually, let'ss loosen the constraint a bit to something like -2ns. Now for fpga2, you know fpga1 has a min output delay of 2ns, and the board delay is 1ns, so do: set_input_delay -min -clock virt_clk 3.0 [get_ports fpga2_din*]- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks kaz and Rysc.
I like both approaches. kaz's is basically straight forward and done as if FPGA 2 was some third party chip where you can look up the timing requirements in the "data sheet". Of course if the FPGA 2 design is recompiled you have to check the "data sheet" report again every time to see if it has changed, just like with a third party chip that has changed. Rysc's approach avoids that by giving FPGA 2 a requirement and therefore let TimeQuest warn you if it doesn't meet it anymore after a recompile. The theoretical disadvantage here is that FPGA 2 might end up with more slack than necessary after a recompile and make it harder for FPGA 1 to reach timing.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Note that if FPGA 1 has more slack and FPGA 2 can't meet timing, you can squeeze down FPGA 1(you can just change the timing constraint without re-fitting if you really want and the slack is there.)

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page