IO constraints for buses routed through FPGA

[Altera_Forum]

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!

[Altera_Forum]

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]

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]

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]

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]

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]

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

[Altera_Forum]

: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]

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]

--- 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]

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.

[Altera_Forum]

so since no automated check is possible, with every major change in the source code I should have a look if path delays for the SPI buses are similar... not what I was hoping for...  

 thanks for the answers, they really helped!

[Altera_Forum]

this post helped me alot !! 

cheers