timing constraints for SPI (or UART)

There are several misperceptions in your approach.

declaring 100MHz ref clock is ok. deriving PLL clocks is ok.

declaring that virtual clock is a mystery to me (virtual clock is used to model an input device launch clock).

you should instead declare your output data clock (50MHz).

next you set the output delay values referred to output clock.

--- Quote Start ---

...FPGA centric or system centric, both will work.

--- Quote End ---

This is an error I noted several times on this form. fpga centric can't be correct for system centric except in one case: external device does not have tSU/tH timing requirements e.g. automatic tracking...

You need system approach so that fpga knows the host tSU/tH and board delays.

If your 50MHz clock was same edge launch/latch then it becomes a standard source synchronous IF and I advise you to go that way and redesign. Alternatively, one approach is to recalculate tSU/tH... a second approach to assume a DDR like IF then cut off paths of same edge launch/latch and rise-fall launch/latch. In this case your delay values will be:

max = +tSU

min = -tH

kaz,

thank you for your help.

the SPI clock (50 M) is also an input to my FPGA, not its output. Also, since it is very slow compared to my system clock of 333.33 M, I just treat as a regular signal in my design and sample it with my system clock. So I did not declare it as a clock in .sdc file. Should I?

I detect falling edges on the spi clock and have to prepare data such that it is ready to be sampled by the host on the positive edges of spi clock.

Assuming tsu and th as target dff parameters, how and what constraints do I need to add?

Regards,

Firstly it is not clear if the 50MHz is clock input and used to launch registers or is it just data sampled by fast clock) . If it launches then it is a clock and you must declare it since it is a base clock.

Secondly, if the 50MHz is your launching SPI output data clock then the output delays should be referenced to it.

Frankly I am not sure here how delay values of timequest relate to its clock since Altera examples and doc. stress on clock and data going together in same direction. In other words, your IF is not classical source synchronous for outputs. Your latch edge in host device may even occur before its launch edge in FPGA. Moreover, an equal board trace of clock/data does not mean zero effect on timing window here.

Don't worry, to avoid maths, you can do some small research work here:

apply various delay values and check:

1) tCO and tCO min (relative to falling edge, see report datasheet)

2) tSU/tH and timing slack at io(see report io timing).

The difficult bit is how to interpret output results:

example: Assuming +1ns tSU and +.5ns tH (timing window around edge) then optimum reported should be around tSU = 9 ns and tH = - 7.5ns (timing window moved to centre of clock period).

Note:

If your 50MHz signal does not directly launch output data but the fast clock does after reading the falling edge then I am afraid this further complicates timing and validity of reports.

--- Quote Start ---

the SPI clock (50 M) is also an input to my FPGA, not its output. Also, since it is very slow compared to my system clock of 333.33 M, I just treat as a regular signal in my design and sample it with my system clock. So I did not declare it as a clock in .sdc file. Should I?

I detect falling edges on the spi clock and have to prepare data such that it is ready to be sampled by the host on the positive edges of spi clock.

--- Quote End ---

The 50 MHz incoming SPI clock must be regarded as unrelated to the 333 MHz internal clock, two clocks of 20 ns and 3 ns will at some point provoke a metastable operation.

So you need to synchronize this input wit a 2-stage synchronization chain, this takes at most 2 system clocks or 6 ns. The third clock would output the data onto the MiSo pin, bringing it to 9 nsec. Then you have to add the t(CO) of the Miso Pin, making it more then 10 ns, so it wouldn't work. If however you can use the rising edge of the incoming SPI clock to trigger the operation it it will work fine and you can write set_false_path for the MiSo pin as you will meet timing 'by design'. Setting the 'Fast Output Register' for the MiSo pin will keep the t(CO) low and you can achieve about 8ns t(SU).

--- Quote Start ---

Note:

If your 50MHz signal does not directly launch output data but the fast clock does after reading the falling edge then I am afraid this further complicates timing and validity of reports.

--- Quote End ---

Actually this is how I am doing it :). Now I know that a 50 MHz SPI clock is almost equivalent to 7 clock cycles of the fast 333.33 MHz clock. I detect the negative edge on SPI and prepare my data in 3 clock cycles of the fast clock. Now if I set a multi-cycle path of 3 (virtual) clock cycles (and assuming the falling edge of SPI clock and rising edge of virtual clock are aligned), and suppose that the 3 (virtual) clock cycles are being consumed in the FPGA to prepare the data for the host, is my supposition correct and will it give me correct timing analysis?

In other words, keep my constraints as i listed them earlier and just add a 3 cycle multi-cycle path on the failing paths?

Thanks to all gurus for your help.

--- Quote Start ---

Actually this is how I am doing it :). Now I know that a 50 MHz SPI clock is almost equivalent to 7 clock cycles of the fast 333.33 MHz clock. I detect the negative edge on SPI and prepare my data in 3 clock cycles of the fast clock. Now if I set a multi-cycle path of 3 (virtual) clock cycles (and assuming the falling edge of SPI clock and rising edge of virtual clock are aligned), and suppose that the 3 (virtual) clock cycles are being consumed in the FPGA to prepare the data for the host, is my supposition correct and will it give me correct timing analysis?

In other words, keep my constraints as i listed them earlier and just add a 3 cycle multi-cycle path on the failing paths?

--- Quote End ---

IMHO you have to achieve valid setup and hold times to the external master by design. The 50 MHz of the SPI and the internal 333.33 MHz are to be considered as totally unrelated so you cannot express any relationship between the two. So a multi-cycle path will not bring anything. The only constraints left are the ones you originally put in, but instead of virtual_clk_sys you have to use the PLL-generated clock. A 0.0 ns max output delay gives a t(COmax) of 3.0 ns which is hard to achieve. To my idea it is better to set a false path for the spi_miso pin.

set_false-path -to }]

and to verify actual behaviour (and the obtained timings) by simulating the design.