jitter on SPI interface and clock-domains

Probably not. But the wires might cause ringing, or possible crosstalk between the three or four lines. A little ringing can wreck SPI. If you roll your own SPI slave, it probably won't have schmitts on the clock and cs lines, as many dedicated SPI chips do.

--

John Larkin         Highland Technology, Inc 

lunatic fringe electronics

I'm not sure why you are asking about jitter in relation to jumper wires. Jitter is a function of the driver. Using jumper wires is not a good idea as this will introduce ringing and can cause extra clock edges which a Schmitt trigger can't fix.

SPI is fast enough that the clock edges have to be fast enough to cause ringing if your traces are very long and not properly terminated.

I'm not sure how much "that much" is. The data sheet should give you input clock setup and hold times and clock to output min and max requirements for the SPI port. You use that data from both parts and the wire length delay if it is a significant fraction of the timing and analyze this info to see what your max speed will be.

Again, I'm not sure of what you are asking. A 50 MHz clock should be fast enough to sample a 12 MHz clock and data reliably. I designed a digital phase locked loop that resyncs to the edges of the data to sample a data stream with the internal clock at 4x the data rate. That would be 48 MHz in your case.

I wouldn't. Just sample the clock and collect the data when appropriate. Or you can run the interface directly from the SPI clock (I'm assuming your FPGA is a slave). When the /SS signal is deasserted, use that to trigger a transfer of the data word to your other clock domain (12 or 50 MHz) and use the data. Appropriate clock domain crossing circuits should be used.

50 MHz should work just fine. Think of analyzing the sampled clock as a finite state machine.

Not sure what you mean by "normal clock rate". But in no case do you need a FIFO unless the interface is running at a much higher rate than the system clock (I assume what you mean by "normal clock") with the data arriving in bursts that are too fast for the system clock to accept.

Is your 50 MHz clock your system clock?

--

Rick C

Hi John,

I am sorry. I meant "ringing", not jitter. My error. (writing messages past midnight .. bad idea).

The SPI-master does is the SPI-interface of a STM32F1, which might have some analog filters on the input, but probably not on the output.

I have downloaded a document on the EP4CE10 I/O pin configuration. I'll have a look at this.

BTW. This started out as just a small exercise on VHDL but -as usual- it semas to bring up all kind of other (and very interesting) issues.

Cheerio! Kr. Bonne.

Hi Rickman,

Sorry, I meant ringing, not jitter.

Well, it's the setup I have. A STM32F1 on a broadboard talking to a FPGA on a devboard.

Now, for sake of just the VHDL exercise, I can of course run the SPI interface at a lower speed but the figure of "maximum bitrate for SPI:

12 Mbps" in the STM32F1 spec did get me thinking.

Which is probably the case here. :-)

I'll do a test this evening.

OK, as said, I'm just starting out on VHDL and at this point, I just do edge-detection based on the system clock (50 Mhz) and a "last bit was 1, new bit is 0" circuit.

My idea was to create a low-pass filter with a moving-window average.

(...)

yes. 50 Mhz is my system-clock (at least on the Altera board). (that is what I called the "normal" clock, my appologies if I do not always use the correct jargon).

As mentioned in my message to John, this started out as just a small VHDL exercise, i.e. implement a SPI slave. Now, every time, all kind of other stuff turns up (in this case, different clock domains) which makes the exercise much more interesting.

I need to do some research on the "clock domain crossing circuits" you mention.

That's indeed what I had in mind, but this is the first time I would

Thx! :-)

Cheerio! Kr. Bonne.

If I had to guess I would say look at ground bounce between the two systems. Make sure the grounds are tied together as closely as possible, then start looking at the signal integrity elsewhere. Regarding ringing the STM32 parts I have used have PIO settings to control the slew rates but I have not used the F1. You could look at adding termination too but if the grounds are connected with a 6 inch jumper wire it is going to be hard to make it work reliably I think.

--

John Devereux

This is a signal integrity issue. You may do just fine with it, but the only way to tell for sure is to scope it and see what you have. You would likely do well to use a ribbon cable and put a ground wire between every signal wire and the next. This helps to lower the impedance of the signal wires (less ringing) as well as reduce the coupling between them (less induced noise).

In the end you may have to reduce your edge rate which may require a slower clock speed. I know FPGAs typically have edge rate control. The only signal that is crucial is the clock. You may do well to use a series terminating resistor, but I'm not sure how well that will work with the varying impedance along your signal path. A trial won't hurt.

I'm not sure how much filtering you can apply effectively. You have a sample rate that is twice your Nyquist rate with only two values of input, 0 and 1. A filter is going to be pretty messy or complicated. I'd stick to a simple state machine and focus on dealing with the SI issues in the hardware rather than trying to filter stuff in the FPGA. In other words, keep the noise out of the FPGA to begin with.

If the FPGA is a slave with a 50 MHz clock, you should be able to do something simple. First, use the SPI clock to capture the bit in a FF on the correct edge. This will be stable for a full SPI clock cycle some time after that edge. Sampling the 12 MHz clock will produce a sequence like "001100110011..." with an extra 0 or 1 on occasion. If you just look for the right edge "01" or "10" and wait one more clock cycle to sample the output of the data captured in the FF. This will give the output of that FF plenty of time to settle so you aren't dealing with a changing value as you clock it into the 50 MHz domain.

(optional) MOSI +------+ +------+ -->>----| D Q |---------| D Q |---->>-- Stable Data | | | | | | +----| CE | SCLK | | | | | -->>----|> | | +--|> | +------+ | | +------+ | | +-)------------------------+ | | | _____ | +---)---------------\ \ | SCLK +------+ | | +------+ ) & )--+-->>-- Rising -->>----| D Q |--+---)--| D Q |----O/____/ Edge Detect | | | | | | | | | | 50CLK | | | | | +---|> | +--|> | | +------+ | +------+ +-----------------+-------------->

Or see above a workable circuit. Be sure to consider the specifics of your interface timing to decide exactly what clock cycle to sample the input data or the change the output data.

--

Rick C

Well, the world is analog!

Some source termination resistors might help. We have, more than once, had to add a capacitor to ground at the end of an SPI clock line. Yes, ugly, but it worked.

SPI clock distribution on a PC board can be a challenge.

--

John Larkin         Highland Technology, Inc 

lunatic fringe electronics

12Mbps sampled with 50MHz is borderline, but it is easy to double the sample rate using the DDR input flops

-Lasse

Hi Rick, (and all others)

I'm currently on the train, so just a quick reply.

First, thank you to everybody who replied. All very interesting reading.

Well, that's why my initial idea was to crack up the samplerate using one of the PLLs as a clock multiplier; so sample at -say- 100 or 200 Mbps and then drive the edge-detection and moving-window low-pass-filter from that clock.

(that is, is the FPGA is able to sample an input pin at that rate)

A longer reply later after I've done some experimentation. :-)

Cheerio! Kr. Bonne.

Use ribbon cable and alternate ground and signal. The result won't be as good as PC board, but it'll be better. Or use twisted pairs, or even coax.

Or, don't try to make it go at 12MHz, and debounce the edges in the FPGA (oh, fun).

--
Tim Wescott 
Control systems, embedded software and circuit design 
I'm looking for work!  See my website if you're interested 
http://www.wescottdesign.com

Sampling the lines requires synchronizing flops anyway so bit debounce takes very little more

and it is already not nearly as critical as when you use the spi as clock input to flops that'll work to hundreds of MHz

-Lasse

Actually the world is digital with very large ranges.

On a PC board it is easy, using jumpers can make it hard.

--

Rick C

Why is it borderline? 50 MHz is more than 48 MHz and so is a great sample rate. The only question is about the detail interface timing.

--

Rick C

That can work, but it will be a *lot* more work than is needed. This is not a hard problem to deal with.

--

Rick C

You can often oversample, or some such, though.