FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
5988 Discussions

SPI Core: Strange problem with sample and shift clocks

Honored Contributor II

Hi, All, 

I've an SPI Slave IP in my design, and I'm sending and receiving a single 

byte. Every 5-6 time, the bytes sent and received are wrong.  


I've looked inside the SPI core with SignalTap II, and I see that when the 

problem occurs, the Sample Clock or the Shirt clock (or sometimes both) 

don't work. When all is fine, they are in sync with the SPI sclk, but 

every so often some clock edges are missing: instead of 8 clock edges per bytes, I get 2-3 edges. 

All this time, the sclk itself is received ok. 


Some info: system clock is 25MHz, SPI sclk is 50KHz. 


Any ideas? 




[UPDATE] I found the problem, I think. It turns out it was a synchronization problem: the SPI Master has a different system clock then the SPI Slave. I thought that the cores had already a synchronization mechanism built-in, but they don't....so I got meta-stability issues.  

The solution: add a two flip-flops on the slave SCLK path (And maybe also on the SS_N path, just to be on the safe side), to kill the metastability. 



0 Kudos
2 Replies
Honored Contributor II


--- Quote Start ---  

I've an SPI Slave IP in my design 

--- Quote End ---  


Which IP is it? 


I expect a serious timing violation causing the problem.
Honored Contributor II

Hi, FvM, thanks for the reply :-) 


I'm using the serial peripheral interface - master / slave (http://www.cast-inc.com/ip-cores/interfaces/spi_ms/cast_spi_ms-a.pdf) IP core  

that comes with Qsys. I have one board with a Master instance of 

that core, communicating with another board with a Slave Instance. 


I'll try checking the clock constraints, but I'm not very hopeful: I have 

a NiosII with a TSE core in the same system, and they are working fine. Why should the SPI (which is rather slow) cause timing issues?  


I also tried inserting a 1 us delay between the SS_N and SCLK in the SPI master, but that didn't work either.