SPI Flash Timing Constraints

Altera_Forum · ‎05-19-2017

Does anyone have an example of how to properly constrain the SPI MISO line when all of these conditions are true:

1) The FPGA is the SPI master

2) The FPGA is generating and providing the SPI clock

3) The FPGA is using the generated SPI clock to clock in the data back from the slave

I thought this would be really easy, but it is surprisingly difficult to find clear information about how to constrain input data paths when the FPGA itself is the clock source. Altera’s examples for source-synchronous serial interfaces in AN433 do not seem to cover that.

In my case, I want to talk to a serial flash part at 98 MHz. My design core clock is already 98 MHz, so I am using it as the SPI clock. It is running fine at 98 MHz on prototype hardware (passing data non-stop without errors), but that is without timing constraints. I can’t leave it that way.

The SPI flash chip drives out on falling edges, so I have my logic written to clock data in on falling edges. That way I have a 10ns cycle available instead of a 5ns half-cycle. The flash Tco is 6ns max.

My current timing constraint attempt looks like this. I am focusing on the data input path from the FPGA’s perspective:


create_clock -name CLK24M -period 41.666 
 
create_generated_clock 
                -name CLK98M 
                -source }] 
                -duty_cycle 50.000 
                -multiply_by 49 
                -divide_by 12 
                -master_clock {CLK24M} 
                }]
 # Flash delays
set flash_tCO_min 0.0
set flash_tCO_max 6.0
 # Board Delays
set flash_BD_min 0.050
set flash_BD_max 0.150
 
set_input_delay -clock CLK98M
                -clock_fall
                -reference_pin 
                -max 
                }]
 
set_input_delay -clock CLK98M
                -clock_fall
                -reference_pin 
                -min 
                }]
 # Constrain the clock output path, since otherwise there are no guarantees on it
set_max_delay -from * -to  3.0
set_min_delay -from * -to  0.0

The -reference_pin is a little strange since it appears to be Altera-specific syntax. However, if I remove that, TimeQuest does not appear to actually account for the significant contribution of the clock output delay to the data input path.

I am not having any luck getting this approach to pass in TimeQuest for Cyclone IV -C8 fabric, so that leads to questions:

1) Is this a valid approach to the constraints?

2) How do I tell when a logic design change is necessary, such as needing a phase-shifted clock for FLASH_SCLK?

Thank you for reading.

Altera_Forum · ‎05-26-2017

I still have not figured this out. I made this diagram to show the path that I am trying to constrain:

https://www.alteraforum.com/forum/attachment.php?attachmentid=13698

Are my constraints appropriate for this situation?

How do I tell when an additional PLL output for phase shifting the clock becomes necessary?