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..


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


2 Answers 2


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.

  • \$\begingroup\$ ohhh this explains a lot !!! my application only works when i add a signal-tap probe on the spi data output .... this is because when i do this , the signal is resync to the 100Mhz clock .... this was very helpfull , thank you very much \$\endgroup\$ Sep 7, 2015 at 9:49

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).


This site is temporarily in read-only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .