Forum Discussion

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

IO constraints for buses routed through FPGA

Hi,

I hope this is the right place for this question...

I have the following situation...

* multiple SPI buses connected to my FPGA (connecting SPI slaves to FPGA)

* a DSP as SPI master; handles SPI timing

* FPGA behaves as a MUX for the SPI interfaces; purely combinatorial

My question is how should I constraint the SPI interfaces so that the timing at the output of the DSP (correct SPI timing) is kept at the output of the FPGA after routing?

I hope you can easily understand what I meant... Thanks in advance!

12 Replies

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

    For a pure combinational design, only the propagation delay matters, but for the overall operation, a sum of FPGA and slave delays (particularly for the most critical CLK to MISO delay) counts.

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

    What you said makes sense if the delays of the FPGA are insignificant compared to the MOSI/SCK relation. My problem is I can't (don't know how to) trace the delays through the FPGA and I don't just want to assume they will be less than 1 ns... A constraint would spare me of these assumptions...

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

    They are surely a lot more than 1 ns. You can expect around 5 ns for each direction. This are mainly I/O delays that aren't affected by the fitter, so you will hardly achieve a considerably lower value.

    However, I didn't suggest to make no constraints. I mentioned, that only tpd constraints are applicable. You have to find out, if they are helpful somehow.

    Personally, I would start to check the delays reported by the timing analyzer without any constraints.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    That's the way I wanted to avoid :cry:

    I have to analyze 6 interfaces (MUX6:1)... probably every P&R run...

    what kind of constraints can I actually make? I use no clocks, no registers in the path... TimeQuest is not really useful in this situation...

    Thanks for the help so far...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    As already mentioned, you would want to specify maximum tpd constraints.

    P.S.: (From Rysc's TimeQuest User Guide)

    --- Quote Start ---

    Combinatorial Paths through Device:

    set_max_delay -from [get_ports {<input>} -to [get_ports {<output>}] <Tpd_Requirement>

    --- Quote End ---

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

    Thanks, this helped... I had no idea about the existence of this manual, it's awesome :) Thanks!

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

    :cry: unfortunately my problem was not so easily solved...

    My FPGA is a Cyclone III.

    I tried to constrain the delays between some ranges but it's impossible to match constraints for both slow and fast devices :-( in slow devices typical delay is ~14 ns, I tried to set min 14, max 15 to ensure approx the same delay for all bus signals but than it fails with the fast device that can at most delay ~6 ns...

    I don't care how much delay I have, I just want to keep the relation between signals the same and for this only setting maximum delay is not enough :cry:

    I noticed in TimeQuest that the delays are though similar for all signals for fast and slow devices (+- 200 ps), I could live with this but I need an automated way of checking this...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    I don't understand why you apparently need a minimum tpd constraint? What's the problem when allowing a delay of 6 to 16 ns (if these are the tpd numbers achieved with various devices you want to use for your design)?

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

    --- Quote Start ---

    I don't understand why you apparently need a minimum tpd constraint? What's the problem when allowing a delay of 6 to 16 ns (if these are the tpd numbers achieved with various devices you want to use for your design)?

    --- Quote End ---

    because I am afraid that delays for individual lines of the bus will be different with 0-10 ns...

    with a tpd in range 6-10 I ensure that the signals will have a timing variation at the output of the FPGA of maximum 4 ns... that's how I understand it...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    O.K., I can understand why. I fear, Timequest isn't prepared for this.

    If the logic is simple and not involving a different number of logic cells for individual pathes, the skew can be expected rather small (< 1 ns). If you are using a robust spi timing, there won't be a problem. The most critical parameter would be the SCK to MISO round trip delay.