jitter on SPI interface and clock-domains

[kristoff]

Hi,


I am currently again learning some more VHDL and the exercise project I
am working on now is to implement SPI slave. This is to be used in
combination with a STM32F103 maple mini clone.


Question.
How much jitter can one expect on a SPI-interface between a MPU (in a
breadboard) and a FPGA connected with jumper-wires?

According the datashield of ST, the STM32F103 can do SPI at up to 12
Mbps, so I guess that the jitter on that port wouldn't be that much.


Also,
The two FPGA boards I have (xula2-LX9 and no-name EP4CE10) are clocked
at 12 and 50 Mhz; I guess that is not really enough to process SPI at 12
Mbps.

Can I conclude that I need to use a PLL to speed up the clock for this
particular part of the FPGA? So this would be a part of the FPGA with
its own clock-domain. Correct?
What clock-rate would one need to interface with a SPI-interface at 12 Mbps?



I read somewhere that I then need to use a FIFO to communicate with the
parts of the FPGA running at the normal clock-rate. Is this correct?
(I think I've seen code on opencores.org which does this).


Cheerio! Kr. Bonne.

[John Larkin]

On Tue, 16 Aug 2016 00:32:02 +0200, kristoff <kris...@skypro.be>
wrote:

>Hi,
>
>
>I am currently again learning some more VHDL and the exercise project I
>am working on now is to implement SPI slave. This is to be used in
>combination with a STM32F103 maple mini clone.
>
>
>Question.
>How much jitter can one expect on a SPI-interface between a MPU (in a
>breadboard) and a FPGA connected with jumper-wires?
>
>According the datashield of ST, the STM32F103 can do SPI at up to 12
>Mbps, so I guess that the jitter on that port wouldn't be that much.
>

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.

>
>Also,
>The two FPGA boards I have (xula2-LX9 and no-name EP4CE10) are clocked
>at 12 and 50 Mhz; I guess that is not really enough to process SPI at 12
>Mbps.
>
>Can I conclude that I need to use a PLL to speed up the clock for this
>particular part of the FPGA? So this would be a part of the FPGA with
>its own clock-domain. Correct?
>What clock-rate would one need to interface with a SPI-interface at 12 Mbps?
>
>
>
>I read somewhere that I then need to use a FIFO to communicate with the
>parts of the FPGA running at the normal clock-rate. Is this correct?
>(I think I've seen code on opencores.org which does this).
>
>
>Cheerio! Kr. Bonne.
>

--

John Larkin Highland Technology, Inc

lunatic fringe electronics

[rickman]

On 8/15/2016 6:32 PM, kristoff wrote:
> Hi,
>
>
> I am currently again learning some more VHDL and the exercise project I
> am working on now is to implement SPI slave. This is to be used in
> combination with a STM32F103 maple mini clone.
>
>
> Question.
> How much jitter can one expect on a SPI-interface between a MPU (in a
> breadboard) and a FPGA connected with jumper-wires?

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.

> According the datashield of ST, the STM32F103 can do SPI at up to 12
> Mbps, so I guess that the jitter on that port wouldn't be that much.

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.

> Also,
> The two FPGA boards I have (xula2-LX9 and no-name EP4CE10) are clocked
> at 12 and 50 Mhz; I guess that is not really enough to process SPI at 12
> Mbps.

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.

> Can I conclude that I need to use a PLL to speed up the clock for this
> particular part of the FPGA? So this would be a part of the FPGA with
> its own clock-domain. Correct?

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.

> What clock-rate would one need to interface with a SPI-interface at 12
> Mbps?

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

> I read somewhere that I then need to use a FIFO to communicate with the
> parts of the FPGA running at the normal clock-rate. Is this correct?
> (I think I've seen code on opencores.org which does this).

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

[kristoff]

Hi John,

On 16-08-16 04:24, John Larkin wrote:
>> Question.
>> How much jitter can one expect on a SPI-interface between a MPU (in a
>> breadboard) and a FPGA connected with jumper-wires?
>> According the datashield of ST, the STM32F103 can do SPI at up to 12
>> Mbps, so I guess that the jitter on that port wouldn't be that much.

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

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.

[kristoff]

Hi Rickman,

On 16-08-16 07:29, rickman wrote:
>> Question.
>> How much jitter can one expect on a SPI-interface between a MPU (in a
>> breadboard) and a FPGA connected with jumper-wires?

> I'm not sure why you are asking about jitter in relation to jumper
> wires. Jitter is a function of the driver.

Sorry, I meant ringing, not jitter.

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

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.

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

Which is probably the case here. :-)


I'll do a test this evening.

>> Also,
>> The two FPGA boards I have (xula2-LX9 and no-name EP4CE10) are clocked
>> at 12 and 50 Mhz; I guess that is not really enough to process SPI at 12
>> Mbps.
>
> 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.

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.

>> Can I conclude that I need to use a PLL to speed up the clock for this
>> particular part of the FPGA? So this would be a part of the FPGA with
>> its own clock-domain. Correct?
>
> 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.

(...)

>> I read somewhere that I then need to use a FIFO to communicate with the
>> parts of the FPGA running at the normal clock-rate. Is this correct?
>> (I think I've seen code on opencores.org which does this).
>
> 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?

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

>> What clock-rate would one need to interface with a SPI-interface at 12
>> Mbps?

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

Thx! :-)



Cheerio! Kr. Bonne.

[John Devereux]

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.


>
>
>
> Cheerio! Kr. Bonne.

--

John Devereux

[rickman]

On 8/16/2016 3:05 AM, kristoff wrote:
> Hi Rickman,
>
>
>
> On 16-08-16 07:29, rickman wrote:
>>> Question.
>>> How much jitter can one expect on a SPI-interface between a MPU (in a
>>> breadboard) and a FPGA connected with jumper-wires?
>
>> I'm not sure why you are asking about jitter in relation to jumper
>> wires. Jitter is a function of the driver.
>
> Sorry, I meant ringing, not jitter.
>
>
>> 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.
>
> 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.

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.

>> 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.
>
> Which is probably the case here. :-)
>
>
> I'll do a test this evening.
>
>
>
>>> Also,
>>> The two FPGA boards I have (xula2-LX9 and no-name EP4CE10) are clocked
>>> at 12 and 50 Mhz; I guess that is not really enough to process SPI at 12
>>> Mbps.
>>
>> 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.
>
> 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.

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.

>>> Can I conclude that I need to use a PLL to speed up the clock for this
>>> particular part of the FPGA? So this would be a part of the FPGA with
>>> its own clock-domain. Correct?
>>
>> 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.

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 | | | | |
+---|> | +--|> |
| +------+ | +------+
+-----------------+--------------<<-- 50 MHz Clock


The MISO data will come from a FF clocked by the 50 MHz signal enabled
by the appropriate edge detect. Be mindful of the one cycle of 50 MHz
clock jitter you will see in the MISO signal, but this shouldn't be a
problem unless the MCU has tight timing specs. You may not need the
MOSI sync FF (the one clocked by the SCLK signal) if you have a decent
timing window so the MOSI data can go directly into the FF enabled by
the edge detect.

If the SPI port has to respond in the same transaction to a command
being sent, closing the loop may be a bit tricky with timing. I had to
do that in an SPI like design once and I ended up with 15 ns to get a
result out.

If you are concerned about metastability you will want to be sure the
path from the first FF sampling the SCLK signal has some extra slack to
*all* destinations or add a Ff in front of this one. It only take a
small number of ns of slack to resolve metastability to a very
microscopic possibility.

>>> I read somewhere that I then need to use a FIFO to communicate with the
>>> parts of the FPGA running at the normal clock-rate. Is this correct?
>>> (I think I've seen code on opencores.org which does this).
>>
>> 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?
>
>
> 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.

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.

> That's indeed what I had in mind, but this is the first time I would
>
>
>
>>> What clock-rate would one need to interface with a SPI-interface at 12
>>> Mbps?
>
>> 50 MHz should work just fine. Think of analyzing the sampled clock as a
>> finite state machine.
>
> Thx! :-)
>
>
>
> Cheerio! Kr. Bonne.

--

Rick C

[John Larkin]

On Tue, 16 Aug 2016 08:45:13 +0200, kristoff <kris...@skypro.be>
wrote:

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.

[Lasse Langwadt Christensen]

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

-Lasse

[kristoff]

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.

On 16-08-16 16:40, rickman wrote:
>> 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.

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

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.

[Tim Wescott]

On Mon, 15 Aug 2016 19:24:30 -0700, John Larkin wrote:

> On Tue, 16 Aug 2016 00:32:02 +0200, kristoff <kris...@skypro.be> wrote:
>
>>Hi,
>>
>>
>>I am currently again learning some more VHDL and the exercise project I
>>am working on now is to implement SPI slave. This is to be used in
>>combination with a STM32F103 maple mini clone.
>>
>>
>>Question.
>>How much jitter can one expect on a SPI-interface between a MPU (in a
>>breadboard) and a FPGA connected with jumper-wires?
>>
>>According the datashield of ST, the STM32F103 can do SPI at up to 12
>>Mbps, so I guess that the jitter on that port wouldn't be that much.
>>
>>
> 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.

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

[Lasse Langwadt Christensen]

Den tirsdag den 16. august 2016 kl. 18.27.22 UTC+2 skrev Tim Wescott:
> On Mon, 15 Aug 2016 19:24:30 -0700, John Larkin wrote:
>
> > On Tue, 16 Aug 2016 00:32:02 +0200, kristoff <kris...@skypro.be> wrote:
> >
> >>Hi,
> >>
> >>
> >>I am currently again learning some more VHDL and the exercise project I
> >>am working on now is to implement SPI slave. This is to be used in
> >>combination with a STM32F103 maple mini clone.
> >>
> >>
> >>Question.
> >>How much jitter can one expect on a SPI-interface between a MPU (in a
> >>breadboard) and a FPGA connected with jumper-wires?
> >>
> >>According the datashield of ST, the STM32F103 can do SPI at up to 12
> >>Mbps, so I guess that the jitter on that port wouldn't be that much.
> >>
> >>
> > 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.
>
> 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).

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

[rickman]

On 8/16/2016 11:18 AM, John Larkin wrote:
> On Tue, 16 Aug 2016 08:45:13 +0200, kristoff <kris...@skypro.be>
> wrote:
>
>> Hi John,
>>
>>
>>
>>
>> On 16-08-16 04:24, John Larkin wrote:
>>>> Question.
>>>> How much jitter can one expect on a SPI-interface between a MPU (in a
>>>> breadboard) and a FPGA connected with jumper-wires?
>>>> According the datashield of ST, the STM32F103 can do SPI at up to 12
>>>> Mbps, so I guess that the jitter on that port wouldn't be that much.
>>
>>> 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.
>>
>>
>> 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.
>
> Well, the world is analog!

Actually the world is digital with very large ranges.

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

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

--

Rick C

[rickman]

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

[rickman]

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

[krw]

On Mon, 15 Aug 2016 19:24:30 -0700, John Larkin

<jjla...@highlandtechnology.com> wrote:

>On Tue, 16 Aug 2016 00:32:02 +0200, kristoff <kris...@skypro.be>
>wrote:
>
>>Hi,
>>
>>
>>I am currently again learning some more VHDL and the exercise project I
>>am working on now is to implement SPI slave. This is to be used in
>>combination with a STM32F103 maple mini clone.
>>
>>
>>Question.
>>How much jitter can one expect on a SPI-interface between a MPU (in a
>>breadboard) and a FPGA connected with jumper-wires?
>>
>>According the datashield of ST, the STM32F103 can do SPI at up to 12
>>Mbps, so I guess that the jitter on that port wouldn't be that much.
>>
>
>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.

You can often oversample, or some such, though.