Hello everyone, This is my 1st post on this forum, so I apologize if I'm doing some noob mistake, i.e. posting this question in the wrong place. I remember doing that in other forums :) Anyways, I'm trying to add a SPI slave to my Cyclone IV VHDL design. It works, but looks like the SPI_CLK pin is very often clocking twice on a single rising edge. An ATXMEGA MCU is generating the signals as the master. First thought was the speed of the rising slope, and so I shortened the wires on my prototype to reduce the load. It helped. The amount of double clocks reduced. But it's still happening, and the wires are pretty short already. My question is: Should I be using a dedicated clock pin of the FPGA for the SPI_CLK? I've read that those dedicated clock pins indeed offer a lower load to the signal, but their main feature is being global and easily accessible to all flip flops.

Just an update, looks like this issue is being caused by noise. If I simply unplug a flat cable from my Cyclone IV development board that connects 10 outputs to some buffers/drivers, the problem stops. The I/Os feeding this cable carry ~5MHz signals, including CLK, Latch & 6-bit Data. Yet, I don't think this should happen. I know FPGAs are not MCUs, but are they that sensitive? Could also be the development board I bought, which's not from Altera. Maybe it's a bad design board.

I think your mistake is using the SPI clock as an actual clock in the design. Use a clock from the PLL as the clock to your module (and entire FPGA design if possible). This should be much faster than the SPI clock. Run the SPI clock through 2 registers to synchronize it to the FPGA clock. After that, run it to your SPI slave. Compare the SPI clock state to the previous state to detect rising or falling edges. Only sample the SPI clock on FPGA clock rising edges. FPGAs are finicky about signals that are not registered to one of their clocks. Search "asynchronous FPGA inputs" for further reading.

Thanks. I'll try that and post the results here. Its strange, though, because I've seen SPI examples in VHDL for FPGAs that simply have an "IF rising_edge(SPI_CLK) THEN..." inside, and without sync with any other clock. And I've done this using an old Lattice and Cypress CPLDs in the past. It's just this FPGA that's giving me trouble. Also, I tried creating a 4th SPI signal called SPI_CHK. This signal will be low at the 1st clock (1st rising and falling SPI_CLK edges), high on the 2nd, low on the 3rd, and so on. Then, once the "IF rising_edge(SPI_CLK) THEN..." reads a bit from SPI_MOSI, it'll only read another if SPI_CHK is the opposite. So if SPI_CLK was triggering rising_edge(SPI_CLK) twice on the same rising edge, or triggering on a falling edge as well, this would stop it. It helped a little, but it's far from solving the issue. I was like... "how come???" And finally, I did not understood this part of your post: "Run the SPI clock through 2 registers to synchronize it to the FPGA clock". I understood that a "routine" on the main FPGA clock should constantly compare SPI_CLK with the state it was on the previous clock. If it changed, then read SPI_MOSI. This would avoid a slow-rising edge of SPI triggering rising_edge(SPI_CLK) twice. Thanks for your help!

--- Quote Start --- Its strange, though, because I've seen SPI examples in VHDL for FPGAs that simply have an "IF rising_edge(SPI_CLK) THEN..." inside, and without sync with any other clock. And I've done this using an old Lattice and Cypress CPLDs in the past. It's just this FPGA that's giving me trouble. --- Quote End --- It's surely possible to use SPI SCK as clock, but the rise time must comply with the FPGA requirements. Old CPLD are considerably slower and may also provide ST clock input buffers. Enabling Cyclone IV bus hold for the SCK input might help to speed up the clock edge. For typical processor SPI speeds, processing SCK in the internal FPGA clock domain as suggested by eng1 is the usual and better way. Using SCK as FPGA clock is preferable for high SPI speeds. Synchronization of the received data to the internal FPGA clock is however required, otherwise you can expect nasty occasional data errors.

--- Quote Start --- And finally, I did not understood this part of your post: "Run the SPI clock through 2 registers to synchronize it to the FPGA clock". --- Quote End --- This document explains what I was getting at: https://www.altera.com/en_us/pdfs/literature/wp/wp-01082-quartus-ii-metastability.pdf Page 3 figure 3 shows the two registers I was talking about under the "Synchronization Chain" label. --- Quote Start --- I've seen SPI examples in VHDL for FPGAs that simply have an "IF rising_edge(SPI_CLK) THEN..." --- Quote End --- You will be better off in the long run to use one clock in the FPGA for everything (unless it is absolutely not possible). Use clock enables to simulate slower clocks when needed. Use the synchronize chain from the document on every signal that comes into the FPGA. Asynchronous inputs and metastability can cause incredibly strange operation.

Designing a SPI slave | Altera Community

12 Replies

Altera_Forum
Honored Contributor
8 years ago
Well, I've made another post above this one, which contains images and hasn't been approved yet, but just to report:

I've studied about synchronization chain, from the document Eng1 posted, as well as other pages about it that I found on Google, and created a 3-stage chain (3 just to be safe) within the same "IF rising_edge(CLK)" of all my code (is this ok?). Here's how it looks:

IF rising_edge(CLK) THEN SPI_CLK_SYNC(0)<=SPI_CLK_SYNC(1); SPI_CLK_SYNC(1)<=SPI_CLK_SYNC(2); SPI_CLK_SYNC(2)<=SPI_CLK; SPI_CS_SYNC(0)<=SPI_CS_SYNC(1); SPI_CS_SYNC(1)<=SPI_CS_SYNC(2); SPI_CS_SYNC(2)<=SPI_CS; (...)

Since I want to detect edges of both the SPI_CLK and SPI_CS, I thought I'd have to synchronize both signals. Well... it worked perfectly!
I'm very amazed about these FPGA phenomenons, and it'd take a long time for me to find out that this was the problem I was having if it weren't for you guys. Thank you both very much!
Altera_Forum
Honored Contributor
8 years ago
It is really amazing how bad things can go if the inputs are not sync'd up.

I have found two stages to be adequate. You could use the third as your previous state.

IF rising_edge(CLK) THEN SPI_CLK_LAST<=SPI_CLK_SYNC(1); SPI_CLK_SYNC(1)<=SPI_CLK_SYNC(2); SPI_CLK_SYNC(2)<=SPI_CLK;

Also, synchronize every signal coming into the FPGA (SPI_MOSI, too) unless there is some good reason not to do so.

Forum Discussion

Designing a SPI slave

12 Replies

Recent Discussions

JTAG Chain Broken on Agilex 7-I Dev Kit

Quartus Prime Pro 25.1 fatal error during fitter: Windows "Efficiency mode" required

DO-254 Cyclone10LP / CycloneV

Download links not working

Agilex 5 Power