Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

how to constrain timing between FPGAs?

Hi,

I have two FPGAs which are each clocked by the same system clock. One FPGA provides a data signal to the other. I want to make sure I am meeting timing.

If the source FPGA were a normal datasheet-specified device, this would be straightforward, I would simply specify the external delays to the constraints on the destination FPGA. However, the source timing is flexible depending on the source FPGA design.

One approach seems that I could run the "report datasheet" command in Timequest for the source FPGA. If I do so, some questions:

1. Is the reported Tco (clock-to-output) the maximum Tco? Or is it simply a "nominal" Tco?

2. There is an interaction between the timing of the two FPGAs. Depending on the source timing, which is variable, the slack on the destination may be larger or smaller. How does one go about making the two designs play well together for optimal slack? For instance, how should I constrain the source output timing? Is this just an iterative process? (i.e., constrain source, build, run report, constrain dest, build, run report, repeat until satisfied)

Is the "report datasheet" way of doing this a good approach? Any better ways?

Thanks in advance,

Martin

8 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Martin,

    In short, there is no solution but to do budgeting. And unless you have a lot of experience with the given device, you will need to do some iterations to find the right balance between your source and destination FPGA.

    Because you have a chicken and egg type situation, you will need to pick one of the two FPGAs and use it as a base line. You can then use report_datasheet to get the delays, and use them to determine the input/output delay constraints for the second FPGA. At a high level, the Tsu becomes the output_delay of the other FPGA, and the Tco becomes the input_delay. But after that, you should apply the input/output delay constraints to the first FPGA, so you can be sure you are meeting timing on any subsequent compile.

    Of course, you can go the easy route, and simply give 50% of the budget to one FPGA and 50% to the other. But again, the critical part is to then create the proper SDC file to represent the constraint assumptions you are making (for both FPGAs), and then simply let TimeQuest give you a slack report. If the slack is positive, you are done.

    Don’t forget to model the board delay into your calculations.

    Hope this helps.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Yes, this definitely helps, thank you.

    I guess what this means is that, in the future, if one of the FPGAs gets re-built, then I will need to run the report_datasheet and recheck the timing on the other FPGA to be sure all is still OK.

    Perhaps another approach is to use the set_max_delay and the set_min_delay constraints to put limits on either the Tco/Tco_min or Tsu/Th of the design to help flag an issue during future re-builds. Does this make sense?

    Martin
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    This is why I mentioned that you need to end up with one SDC file for each FPGA that will formalize the allocation of a portion of the budget. You can use set_max/min_delay, but the proper way is to use set_input_delay and set_output_delay to represent the external view of the requirement.

    Imagine you have a 10ns Period, you can have:

    FPGA1:

    set_input_delay -clock [get_clocks clk] [get_ports in] 6ns

    FPGA2:

    set_output_delay -clock [get_clocks clk] [get_ports out] 4ns

    More examples:

    See http://www.altera.com/literature/hb/qts/qts_qii53024.pdf (http://www.altera.com/literature/hb/qts/qts_qii53024.pdf) and/or http://www.alterawiki.com/wiki/timequest_user_guide (http://www.alterawiki.com/wiki/timequest_user_guide) and/or http://www.altera.com/literature/manual/mnl_timequest_cookbook.pdf (http://www.altera.com/literature/manual/mnl_timequest_cookbook.pdf)

    Once you correctly constraint each FPGA (based on your budget), you should be ok, even after some modifications to either FPGA. Of course, if something changes dramatically, then you may need to adjust your budgeting, which is when you need to go back to the original method.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    OK, that makes sense. Perhaps I was over-thinking the problem. Thanks also for the links - it has been long enough since I've seen the "best practices" doc that I forgot about it's existence. It looks useful, along with the super useful wiki user guide.

    -Martin
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    1. Yes, the reported tCO is a maximum.

    2. One FPGA does not know about the other. I would look at Report Datasheet and see what you get with one FPGA, and then constrain the I/O (with set_input_delay and set_output_delay constraints) to meet the values reported in the datasheet. Then use the constrained numbers (not the datasheet numbers) from the first FPGA to constrain the second FPGA. Now if anything changes, you just have check for failing paths in both FPGAs using TimeQuest and you won't have to iterate with Report Datasheet.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Jimbo,

    Thank you for the answers. I think I have pretty much got it going with both FPGAs meeting setup and hold now. I am happy to hear that the reported tCO is a maximum, as that is the assumption I was operating under.

    As to your point# 2, I did use the datasheet numbers from each FPGA to constrain the other. This is because TimeQuests preferred method of constraints involves describing the delays, tCO's, and tSU's outside of the device being constrained. Apparently I can use Timequest to constrain tCO and tSU directly but the guides discourage it. Doing it with the "preferred" constraint technique actually worked out pretty well, after some iterations, the little setup slack I had was evenly split across each FPGA. Maybe I got lucky. As you mention, I just now need to remember to check timing on both FPGAs if anything changes.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I completely agree that I/Os should be constrained with set_input_delay and set_output_delay constraints, which requires an understanding of the external interfaces. My point was that if you constrain both interfaces this way (and choose values for the first FPGA that are slightly larger then the values from report_datasheet), and use these values instead of the ones directly from report_datasheet, the when you make a change to one FPGA, you only have to check timing on the FPGA that you modified, not both.