FPGA SPI slave not working well

Question

• I'm tring to integrate a SPI Slave in VHDL (opencores) http://opencores.org/project,spi_master_slave
• the idea is to interface a Microcontroller and an FPGA
• I'm Using Quartus..

more info:

• microcontroller diferent clock 50 MHz i think..

• SPI clock frequency is 16Mhz

• SPI VHDL core clock @ 100 Mhz

• I've made an endurance test writing and reading some registers .. no errors with spi

the problem :

• when I try to integrate the VHDL SPI to the rest of my VHDL application (also 100mhz)... the circuit becomes a little "unstable"

some symptoms:

• sometimes in some registers there are bits I didnt write by spi, making the vhdl application to act inexpectecly..

• When adding signaltap probes , the behabior of the vhdl changes a little..

questions:

Do I need to use timequest for the SPI CORE , to add timeconstraingts to SPI input pins? Do I have metastability ?

Answer 1

Your assumption that you have metastability problem seems correct. I did only a survey of the spi slave code, and here what I found:

• The spi clock is used as is, i.e. it requires a clock buffer.
• The data you read from the spi core is not resynchronized to the 100MHz clock, it is on the spi clk domain.
• The data valid signal is resynchronized to the 100Mhz clock.

If you read the data continously, you will have metastability since it is not synchronized. The core's designer probably expects you to use data valid to prevent that. I personally think it's a bad design and would use to shallow FIFO to do the deed cleanly.

Furthermore, I'd prefer to do what Brian suggest and just synchronized the spi clk/data to a faster clock (that 100MHz) and do the core logic with that clock. 16MHz to 100MHz will skew the clock edge for your output logic (after resynchronization), but it should be O.K..

As for constraints, 16MHz is very very slow... You don't need constraints, your CPOL/CPHA has to match though, obviously.

Answer 2

Metastability? Highly unlikely.

Unsynchronised inputs? Very probable and they can cause the symptoms you describe.

So clock each SPI input from your fast clock, and route the clocked versions to the SPI core. (Unless you're already certain that it reclocks them already).