another SPI interface timing constraint question

[Altera_Forum]

This thread describes almost my exact situation: 

 http://www.alteraforum.com/forum/showthread.php?t=48900  I have a SPI master state machine that runs at 96MHz (output of PLL from 24MHz external input clock). The state machine generates SPI_SCK at a rate of 24MHz (96MHz/4) with a 50% duty cycle. SPI_CS_N and SPI_MOSI are also generated directly from the state machine. SPI_MOSI transitions are aligned with the rising edge of SPI_SCK (the external slave samples on the falling edge). The state machine samples SPI_MISO at 96MHz aligned with the falling edges of SPI_SCK (slave generates SPI_MISO off rising edges of SPI_SCK).  I tried the constraints as posted at the end of the thread above:  create_generated_clock -invert -name SPI_SCK -source [get_pins {main_pll_inst|altpll_component|auto_generated|pll1|clk[2]}] -divide_by 4 [get_ports {SPI_SCK}]   set_output_delay -clock SPI_SCK -max 0 [get_ports {SPI_MOSI}]# Slave tSU = 0ns set_output_delay -clock SPI_SCK -min -2 [get_ports {SPI_MOSI}]# Slave tH = 2ns   set_input_delay -clock SPI_SCK -max 13 [get_ports {SPI_MISO}]# Slave tCO max = 13ns set_input_delay -clock SPI_SCK -min 8 [get_ports {SPI_MISO}]# Slave tCO min = 8ns (not specified, typical is 11ns)  Timequest is failing the SPI_MISO input path by about 4ns. The Timequest waveform is attached. It looks like Timequest has the slave launching SPI_MISO off the rising edge of the 96MHz state machine clock (10.415ns period) and the state machine sampling SPI_MISO at the next rising edge of the 96MHz clock. In reality the slave launches off the rising edge of SPI_SCK and the state machine samples at a falling edge of SPI_SCK that is two 96MHz clock periods later (minus the delays getting SPI_SCK over to the slave, and ignoring PCB delays).  Timequest sees SPI_SCK correctly as a 24MHz clock, and it uses SPI_SCK as the launch clock for SPI_MISO. I guess I just don't understand the waveform. In fact I struggle with the SDC timing language in general. Any help on this will be much appreciated.  By the way, if I analyze the paths individually in Timequest it looks like I should be able to meet the SPI_MISO timing. The delay from the SPI_SCK register in the state machine to the SPI_SCK pin is 4.90ns. The tCO delay of the slave is 13ns (max). The input delay from the SPI_MISO pin to the state machine register that it's clocked into is 1.07ns. The sum of these three paths is 4.90 + 13 + 1.07 = 18.97ns, which is comfortably less than 1/2 of the 24MHz SPI_SCK period (20.83ns), which is the time from rising edge launch to falling edge latch.  Thanks, Bob

[Altera_Forum]

Something is definitely wrong with my constraints. I changed SPI_SCK to 16MHz (96MHz/6) and updated the create_generated_clock constraint accordingly, but the SPI_MISO input waveform in Timequest did not change at all. Waveform looks identical and the path still fails by 4ns.

[Altera_Forum]

In your statements can you try putting in -clock_fall: 

 set_output_delay -clock SPI_SCK -clock_fall -max 0 [get_ports {SPI_MOSI}] etc...  for all the statements. Let me know if this changes anything.

[Altera_Forum]

Thanks for the response. -clock_fall made no difference. I also tried -clock_fall after removing -invert from the create_generated_clock statement and that made no difference either.

[Altera_Forum]

I did some timing analysis on Quad SPI flash here: 

 https://www.ovro.caltech.edu/~dwh/correlator/pdf/timequest_quad_spi_flash.pdf https://www.ovro.caltech.edu/~dwh/correlator/pdf/timequest_quad_spi_flash.zip  The timing constraints files should be able to help you.  Cheers, Dave

[David32]

Hi,

I have pretty much the same question and would very much appreciate access to the files mentioned.

The links seem to be no longer valid however.

Could you please repost with updated links.

Thanks in advance.

David

[Altera_Forum]

--- Quote Start ---  I did some timing analysis on Quad SPI flash here:  https://www.ovro.caltech.edu/~dwh/correlator/pdf/timequest_quad_spi_flash.pdf https://www.ovro.caltech.edu/~dwh/correlator/pdf/timequest_quad_spi_flash.zip  The timing constraints files should be able to help you.  Cheers, Dave  --- Quote End ---    Very generous, Dave - thank you! I scanned the pdf briefly and it looks very well written and matches what I'm doing. When I get a chance I'll update my constraints and post the results. Two generated clocks? I never would have figured that out.  Best, Bob

[Altera_Forum]

--- Quote Start ---  Very generous, Dave - thank you! I scanned the pdf briefly and it looks very well written and matches what I'm doing. When I get a chance I'll update my constraints and post the results. Two generated clocks? I never would have figured that out.  --- Quote End ---   I'm glad it looks like it will help - good luck! :)  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  I'm glad it looks like it will help - good luck! :)  Cheers, Dave  --- Quote End ---    Dave -  I used your generated clocks method and it worked great. The only problem I had was that the multicycle constraints were not working until I used [get_clocks {spi1_clk}] instead of just spi1_clk, where spi1_clk is my generated clock name for the external SPI clock. Now the waveforms in Timequest match the way the logic works exactly, and it's very cool that Timequest includes the SPI clock delay.  Tested and working in hardware. Can't thank you enough for the help!  Bob

[Altera_Forum]

--- Quote Start ---   Tested and working in hardware. Can't thank you enough for the help!   --- Quote End ---   You are most welcome!  Cheers, Dave

[conmemsr]

Hi ,

I trying to set proper IO constraints for SPI Master where SPI_CLK_O and SPI_MOSI are generated by an internal clock and SPI_CLK_O is a divide by 4 generated with internal fast clock as source. 

Can you re-post the solution or share the PDF with the timing analysis.

Thanks

msr