SPI Slave and Timing Constraints

[Altera_Forum]

I am currently working on a project where we are using a MAX II EPM570-C5N. I am currently working in Quartus on compiling my HDL and fitting it to the part. While working with my constraints, I have run in to a bit of an interesting issue with constraining a clock. The CPLD is implementing a SPI slave to talk to a DSP Spi master. Our spi protocol dictates that: 

  1. Data is placed on the MOSI and MISO lines at the falling edge of the clock.  2. Data is sampled on the rising edge of the clock.    This makes it a bit difficult to write the input and output delay constraints, because the launch edge and latch edge don’t exactly line up. All negative edges are launch edges, and all positive edges are latch edges. Initially, I just doubled my frequency for the created spi clock. This makes the speed of each transaction correct. However, this is a slightly different model, whereby data is launched and latched at the same time.   Anyone tried constraining the spi miso / mosi lines or have some suggestions?

[Altera_Forum]

I expect, that you have edge sensitive blocks for both edges in your code. Specifying a duty cycle for the SPI clock gives all necessary information to the timing analyzer in my opinion. 

 P.S.: I didn't yet meet a case, where it was necessary to constrain the SPI data lines.

[Altera_Forum]

The set_input_delay command has a -clock_fall option which specifies a falling edge launch. Similarly set_output_delay -clock_fall specifies a falling edge latch. These may be used with a virtual -clock.

[Altera_Forum]

> P.S.: I didn't yet meet a case, where it was necessary to constrain the SPI data lines. 

 I am surprised and concerned not to. Are constraints considered unnecessary given Cyclone III project with ~5 SPI ports at 20MHz system clock (SPI clock ~5MHz)? Is there something specific about SPI that makes constraints less important? The inference is for MISO and MOSI; I wonder also about the clocks and chip selects.