Simple clock question

K

KK6GM

Guest
Newb question: suppose I want to create a shift register that's
clocked from an external source (like an SPI slave device). My
impression (correct me if I'm confused) is that if the external clock
is slow WRT some other clock on the FPGA (e.g. a 1MHz external clock
and a 50MHz fast clock), I can sync both clock and data to the fast
clock and proceed from there, using the fast clock along with an edge
detected signal for further processing. The fast clock is mapped to
low-skew clock lines which are designed for the purpose, so things are
good.

But what if the clock is not slow WRT the fast clock? What if the
external clock is too fast to reliably sync with the fast clock? e.g.
a 20MHz clock and a 50MHz fast clock. In that case it seems that the
external clock needs to be used directly, but won't there be potential
clock skew problems using a regular input as a clock? I'd appreciate
insight on how such problems are dealt with, if indeed they are even
problems at all.

Mike
 
On Jan 27, 10:12 pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote:
But what if the clock is not slow WRT the fast clock?  What if the
external clock is too fast to reliably sync with the fast clock?  e.g.
a 20MHz clock and a 50MHz fast clock.  In that case it seems that the
external clock needs to be used directly, but won't there be potential
clock skew problems using a regular input as a clock?  I'd appreciate
insight on how such problems are dealt with, if indeed they are even
problems at all.
Click to expand...
They are a problem that in many cases is dealt with using a dual clock
fifo.

KJ
 
On 28 Jan., 04:12, KK6GM <mjsi...@scriptoriumdesigns.com> wrote:
Newb question: suppose I want to create a shift register that's
clocked from an external source (like an SPI slave device).  My
impression (correct me if I'm confused) is that if the external clock
is slow WRT some other clock on the FPGA (e.g. a 1MHz external clock
and a 50MHz fast clock), I can sync both clock and data to the fast
clock and proceed from there, using the fast clock along with an edge
detected signal for further processing.  The fast clock is mapped to
low-skew clock lines which are designed for the purpose, so things are
good.

But what if the clock is not slow WRT the fast clock?  What if the
external clock is too fast to reliably sync with the fast clock?  e.g.
a 20MHz clock and a 50MHz fast clock.  In that case it seems that the
external clock needs to be used directly, but won't there be potential
clock skew problems using a regular input as a clock?  I'd appreciate
insight on how such problems are dealt with, if indeed they are even
problems at all.

Mike
Click to expand...
Hi Mike,
you asked "...how such problems are dealt with,...".
The answer is : "Very carefully.". :)

When it happens that a design really needs some clock routed trough
ordinary routing ressources, the problems you mentioned apply.
So the designer has to make sure that the net stays as small as
possible, and tries to controll it with tight timing constraints.

If you take a look at some DDR Memory controller implementation you
will see how it's done.
There you have a strobe signal, that's used to clock the data from the
RAM into the FPGA FFS (here mostly IDDR2 FFs inside the IOBs)
Now this really happens at high speed. But the next FF stage already
works with the internal clock. and then it's business as usual.

Have a nice synthesis
Eilert
 
On Jan 27, 10:12 pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote:
Newb question: suppose I want to create a shift register that's
clocked from an external source (like an SPI slave device).  My
impression (correct me if I'm confused) is that if the external clock
is slow WRT some other clock on the FPGA (e.g. a 1MHz external clock
and a 50MHz fast clock), I can sync both clock and data to the fast
clock and proceed from there, using the fast clock along with an edge
detected signal for further processing.  The fast clock is mapped to
low-skew clock lines which are designed for the purpose, so things are
good.

But what if the clock is not slow WRT the fast clock?  What if the
external clock is too fast to reliably sync with the fast clock?  e.g.
a 20MHz clock and a 50MHz fast clock.  In that case it seems that the
external clock needs to be used directly, but won't there be potential
clock skew problems using a regular input as a clock?  I'd appreciate
insight on how such problems are dealt with, if indeed they are even
problems at all.

Mike
Click to expand...
20 MHz and 50 MHz are totally compatible in this regard. The "slow"
is not too fast until it is 1/2 the rate of the fast clock or more.
As long as you can sample at least once, both the high and the low
value of the clock you should be able to detect the edge. You do need
a little more margin than exactly 2X because of the variability in
timing between the clock and the data. So this needs to be modified
to say that the sample that detects the active edge of the clock has
to be assured to happen when data is valid too. That will depend on
the setup and hold times of the incoming data.

If you don't have compatibility in clock rates, then you need to
capture the incoming data using the incoming clock and once you have
done the work of serializing it, the resulting data sample rate is
much slower and can be transferred using the standard techniques to
cross clock domains.

The use of a FIFO is required only when you need to cross clock
domains that are nearly equal or the FROM domain is faster than the TO
domain (Even then the FIFO is only needed if the data rate is more
than 1/2 the TO domain clock rate). I tend to avoid using FIFOs just
because they are a bit heavy handed. The other techniques are much
smaller and simpler. I honestly can't remember the last time I used a
FIFO just to cross clock domains.

Rick
 
On 01/27/2011 09:12 PM, KK6GM wrote:
Newb question: suppose I want to create a shift register that's
clocked from an external source (like an SPI slave device). My
impression (correct me if I'm confused) is that if the external clock
is slow WRT some other clock on the FPGA (e.g. a 1MHz external clock
and a 50MHz fast clock), I can sync both clock and data to the fast
clock and proceed from there, using the fast clock along with an edge
detected signal for further processing. The fast clock is mapped to
low-skew clock lines which are designed for the purpose, so things are
good.

But what if the clock is not slow WRT the fast clock? What if the
external clock is too fast to reliably sync with the fast clock? e.g.
a 20MHz clock and a 50MHz fast clock. In that case it seems that the
external clock needs to be used directly, but won't there be potential
clock skew problems using a regular input as a clock? I'd appreciate
insight on how such problems are dealt with, if indeed they are even
problems at all.
That's why Xilinx provides multiple low-skew clock nets on their FPGAs.
Click to expand...
In some cases it is necessary to run significant amounts of logic from
different clocks, and then have some synchronizing mechanism somewhere
in the middle. That can be hard or easy, depending on a number of
circumstances.

Jon
 
When it happens that a design really needs some clock routed trough
ordinary routing ressources, the problems you mentioned apply.
So the designer has to make sure that the net stays as small as
possible, and tries to controll it with tight timing constraints.
Click to expand...
This is where the ability the lock flops into place and hand route i
handy.

Shift registers on high skew clocks are always dicey because you don't hav
any next state logic to help ensure that you meet hold time requirements s
you might get "shoot through". Some things that you can try:


1) Counter flow your clock. Route the clock to the very last flop in th
chain and then from there go to the next to last until you get to the firs
flop. That way you are always sending data to a flop on an earlier cloc
and that delay helps meet hold time.

2) Split your clock in two. Create a clock and clock_n and double th
number of flops in the chain. Alternate clocks on the chain with the risin
one going to the input flop that then feeds a falling clock flop.




---------------------------------------
Posted through http://www.FPGARelated.com
 
On Thu, 27 Jan 2011 19:12:12 -0800 (PST), KK6GM <mjsilva@scriptoriumdesigns.com>
wrote:

Newb question: suppose I want to create a shift register that's
clocked from an external source (like an SPI slave device).

But what if the clock is not slow WRT the fast clock? What if the
external clock is too fast to reliably sync with the fast clock? e.g.
a 20MHz clock and a 50MHz fast clock. In that case it seems that the
external clock needs to be used directly, but won't there be potential
clock skew problems using a regular input as a clock? I'd appreciate
insight on how such problems are dealt with, if indeed they are even
problems at all.
Click to expand...
Some good suggestions here.

One other approach is to derive a faster clock from the 50MHz one, most easily
using a DCM or PLL (to 100 or 200MHz) and sample the serial clock and data from
that. The timing analysis tools will automatically account for any phase/jitter
differences between input and derived clocks.

- Brian
 
On 1/28/2011 12:13 AM, KJ wrote:
On Jan 27, 10:12 pm, KK6GM<mjsi...@scriptoriumdesigns.com> wrote:

But what if the clock is not slow WRT the fast clock? What if the
external clock is too fast to reliably sync with the fast clock? e.g.
a 20MHz clock and a 50MHz fast clock. In that case it seems that the
external clock needs to be used directly, but won't there be potential
clock skew problems using a regular input as a clock? I'd appreciate
insight on how such problems are dealt with, if indeed they are even
problems at all.


They are a problem that in many cases is dealt with using a dual clock
fifo.

KJ
Click to expand...
Concerning the dual clock fifo:
to which domain should belong the "fifo full" and "fifo empty" status
registers?

Al
 
In article <311b9cbf-426b-4e86-8d8a-1ad293d4b018@8g2000prt.googlegroups.com>,
KJ <kkjennings@sbcglobal.net> writes:
On Feb 10, 12:01=A0pm, Alessandro Basili <alessandro.bas...@cern.ch
wrote:

KJ

Concerning the dual clock fifo:
to which domain should belong the "fifo full" and "fifo empty" status
registers?


Fifos can only become full when written to. Therefore, 'fifo full'
should be computed in the 'write clock' domain.
Fifos can only become empty when read from. Therefore, 'fifo empty'
should be computed in the 'read clock' domain.
Click to expand...
Right, but they become un-full on the read clock.


--
These are my opinions, not necessarily my employer's. I hate spam.
 
On Feb 10, 12:01 pm, Alessandro Basili <alessandro.bas...@cern.ch>
wrote:

KJ

Concerning the dual clock fifo:
to which domain should belong the "fifo full" and "fifo empty" status
registers?
Click to expand...
Fifos can only become full when written to. Therefore, 'fifo full'
should be computed in the 'write clock' domain.
Fifos can only become empty when read from. Therefore, 'fifo empty'
should be computed in the 'read clock' domain.

Generally, these are the proper clock domains for the logic that
interfaces to the FIFO that would have need of these status signals.

KJ
 
On Feb 10, 5:59 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
In article <311b9cbf-426b-4e86-8d8a-1ad293d4b...@8g2000prt.googlegroups.com>,

 KJ <kkjenni...@sbcglobal.net> writes:
On Feb 10, 12:01=A0pm, Alessandro Basili <alessandro.bas...@cern.ch
wrote:

KJ

Concerning the dual clock fifo:
to which domain should belong the "fifo full" and "fifo empty" status
registers?

Fifos can only become full when written to.  Therefore, 'fifo full'
should be computed in the 'write clock' domain.
Fifos can only become empty when read from.  Therefore, 'fifo empty'
should be computed in the 'read clock' domain.

Right, but they become un-full on the read clock.
Click to expand...
Generally speaking, becoming 'un-full' on a dual clock fifo is not a
concern. Writing to a full fifo is not recoverable, data has been
lost. At best a status bit gets set reporting this error. For that
reason, the *setting* of 'fifo full' status must always be accurate
and must therefore always be synchronous to the write clock.

The resetting of 'fifo full' (i.e. fifo becoming 'un-full') which
happens during a fifo read is less important to be accurate on any
particular clock cycle. All that is incurred is latency before the
write side is able to again start writing which can be designed for by
sizing the fifo appropriately to account for the latency in
transferring the read request from the read clock domain over into the
write clock domain. Assuming that the fifo is sized to account for
the known latency, then no error occurs.

The same logic applies to having to always be accurate about setting
'fifo empty' relative to the read clock but being allowed to be later
about resetting (i.e. becoming 'un-empty') when a write occurs.

Kevin Jennings
 
In article <3292f4d0-26e9-44fe-9b09-2904190036e0@w36g2000vbi.googlegroups.com>,
KJ <kkjennings@sbcglobal.net> writes:
On Feb 10, 5:59=A0pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
In article <311b9cbf-426b-4e86-8d8a-1ad293d4b...@8g2000prt.googlegroups.c=
om>,

=A0KJ <kkjenni...@sbcglobal.net> writes:
On Feb 10, 12:01=3DA0pm, Alessandro Basili <alessandro.bas...@cern.ch
wrote:

KJ

Concerning the dual clock fifo:
to which domain should belong the "fifo full" and "fifo empty" status
registers?

Fifos can only become full when written to. =A0Therefore, 'fifo full'
should be computed in the 'write clock' domain.
Fifos can only become empty when read from. =A0Therefore, 'fifo empty'
should be computed in the 'read clock' domain.

Right, but they become un-full on the read clock.


Generally speaking, becoming 'un-full' on a dual clock fifo is not a
concern. Writing to a full fifo is not recoverable, data has been
lost. At best a status bit gets set reporting this error. For that
reason, the *setting* of 'fifo full' status must always be accurate
and must therefore always be synchronous to the write clock.

The resetting of 'fifo full' (i.e. fifo becoming 'un-full') which
happens during a fifo read is less important to be accurate on any
particular clock cycle. All that is incurred is latency before the
write side is able to again start writing which can be designed for by
sizing the fifo appropriately to account for the latency in
transferring the read request from the read clock domain over into the
write clock domain. Assuming that the fifo is sized to account for
the known latency, then no error occurs.

The same logic applies to having to always be accurate about setting
'fifo empty' relative to the read clock but being allowed to be later
about resetting (i.e. becoming 'un-empty') when a write occurs.

Kevin Jennings
Click to expand...
The key idea is that full and empty aren't really synchronous
with either read or write clock so you can't just feed them
into a FSM and expect things to work if the tools don't complain.

If you are smart enough, you can think about the issue and use
the going-full path without the delay of a synchronizer as long as
you are careful about the un-full path.

One solution in some cases is to use an almost-full flag. You
can run it through the classic synchronizer and the delay won't
kill you. If it's not almost-full, you can write at
full speed, knowing it won't go full before the signal
gets through the synchronizer. If it is almost-full, you can
go slow enough to let the full flag get through a synchronizer.

--
These are my opinions, not necessarily my employer's. I hate spam.
 
On 2/11/2011 8:38 PM, Hal Murray wrote:
In article<3292f4d0-26e9-44fe-9b09-2904190036e0@w36g2000vbi.googlegroups.com>,
KJ<kkjennings@sbcglobal.net> writes:
On Feb 10, 5:59=A0pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
In article<311b9cbf-426b-4e86-8d8a-1ad293d4b...@8g2000prt.googlegroups.c=
om>,

=A0KJ<kkjenni...@sbcglobal.net> writes:
On Feb 10, 12:01=3DA0pm, Alessandro Basili<alessandro.bas...@cern.ch
wrote:

KJ

Concerning the dual clock fifo:
to which domain should belong the "fifo full" and "fifo empty" status
registers?

Fifos can only become full when written to. =A0Therefore, 'fifo full'
should be computed in the 'write clock' domain.
Fifos can only become empty when read from. =A0Therefore, 'fifo empty'
should be computed in the 'read clock' domain.

Right, but they become un-full on the read clock.


Generally speaking, becoming 'un-full' on a dual clock fifo is not a
concern. Writing to a full fifo is not recoverable, data has been
lost. At best a status bit gets set reporting this error. For that
reason, the *setting* of 'fifo full' status must always be accurate
and must therefore always be synchronous to the write clock.

The resetting of 'fifo full' (i.e. fifo becoming 'un-full') which
happens during a fifo read is less important to be accurate on any
particular clock cycle. All that is incurred is latency before the
write side is able to again start writing which can be designed for by
sizing the fifo appropriately to account for the latency in
transferring the read request from the read clock domain over into the
write clock domain. Assuming that the fifo is sized to account for
the known latency, then no error occurs.

The same logic applies to having to always be accurate about setting
'fifo empty' relative to the read clock but being allowed to be later
about resetting (i.e. becoming 'un-empty') when a write occurs.

Kevin Jennings

The key idea is that full and empty aren't really synchronous
with either read or write clock so you can't just feed them
into a FSM and expect things to work if the tools don't complain.
Click to expand...
I am sorry but I don't understand why not. An FSM can always poll for
the status bit, fifo-full on the write side and fifo-empty on the read
side, and go at full speed until the bit is set. This will require a
poll at each write/read operation. Am I missing something?

If you are smart enough, you can think about the issue and use
the going-full path without the delay of a synchronizer as long as
you are careful about the un-full path.
Click to expand...
Which delay of a synchronizer? As far as I understood there's crossing
over the two clock domains, data are moved in a memory with one clock
and retrieved with another one.

One solution in some cases is to use an almost-full flag. You
can run it through the classic synchronizer and the delay won't
kill you. If it's not almost-full, you can write at
full speed, knowing it won't go full before the signal
gets through the synchronizer. If it is almost-full, you can
go slow enough to let the full flag get through a synchronizer.
Click to expand...
What is the classic synchronizer? What do you mean by "slow enough"?
I apologize for my stupid questions but I may have missed your point.

Al
 
Alessandro Basili <alessandro.basili@cern.ch> wrote:

(snip, someone wrote)
Fifos can only become full when written to. =A0Therefore, 'fifo full'
should be computed in the 'write clock' domain.
Fifos can only become empty when read from. =A0Therefore, 'fifo empty'
should be computed in the 'read clock' domain.
(snip)
Click to expand...

Generally speaking, becoming 'un-full' on a dual clock fifo is not a
concern. Writing to a full fifo is not recoverable, data has been
lost. At best a status bit gets set reporting this error. For that
reason, the *setting* of 'fifo full' status must always be accurate
and must therefore always be synchronous to the write clock.

The key idea is that full and empty aren't really synchronous
with either read or write clock so you can't just feed them
into a FSM and expect things to work if the tools don't complain.

I am sorry but I don't understand why not. An FSM can always poll for
the status bit, fifo-full on the write side and fifo-empty on the read
side, and go at full speed until the bit is set. This will require a
poll at each write/read operation. Am I missing something?
Click to expand...
When you cross a clock domain, there is always the possibility
that the signal will be just slightly before, or slightly after
the clock, and the system has to work either way.

The usual FIFO uses a dual-port RAM, two gray code counters
(or binary counters and gray code conversion). Gray code allows
the count to cross the clock domain, such that either the new
or previous value is seen on the other side.

If you are smart enough, you can think about the issue and use
the going-full path without the delay of a synchronizer as long as
you are careful about the un-full path.
Click to expand...
Things get interesting when the read and write clock edges are
close together. Depending on the timing, the empty/full logic
might see the count off by one. That has to be in the direction
of less full or less empty, rather than the other way around.

Which delay of a synchronizer? As far as I understood there's crossing
over the two clock domains, data are moved in a memory with one clock
and retrieved with another one.
Click to expand...
Yes. The counters have to cross the clock domain, such that the
full/empty logic works.

(snip)

-- glen
 
In article <8rridqF3ndU1@mid.individual.net>,
Alessandro Basili <alessandro.basili@cern.ch> writes:
On 2/11/2011 8:38 PM, Hal Murray wrote:
In article<3292f4d0-26e9-44fe-9b09-2904190036e0@w36g2000vbi.googlegroups.com>,

The key idea is that full and empty aren't really synchronous
with either read or write clock so you can't just feed them
into a FSM and expect things to work if the tools don't complain.

I am sorry but I don't understand why not. An FSM can always poll for
the status bit, fifo-full on the write side and fifo-empty on the read
side, and go at full speed until the bit is set. This will require a
poll at each write/read operation. Am I missing something?
Click to expand...
Assume you have a FSM running on the write clock. It looks at the
full flag. The not-full to full transition is synchronous. The full
to not-full is not synchronous so your FSM may get in trouble.


If you are smart enough, you can think about the issue and use
the going-full path without the delay of a synchronizer as long as
you are careful about the un-full path.

Which delay of a synchronizer? As far as I understood there's crossing
over the two clock domains, data are moved in a memory with one clock
and retrieved with another one.
Click to expand...
The classic synchronizer is 2 FFs and thus 2 cycles of delay.
Thus if it goes full, your FSM won't see that for 2 more cycles.


--
These are my opinions, not necessarily my employer's. I hate spam.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top