Searching \ for '[EE] How do RTC clocks work? Non-synchronous logic' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/timers.htm?key=clock
Search entire site for: 'How do RTC clocks work? Non-synchronous logic'.

Exact match. Not showing close matches.
PICList Thread
'[EE] How do RTC clocks work? Non-synchronous logic'
2005\06\24@181907 by Glenn Jones

picon face
Hello,
I am working on an FPGA design which I want to have a counter which
counts pulses from a V/F converter. I want the counter to be read out
via I2C. My question is, what is the standard way of accomplishing
something like this because it seems to violate some of the rules of
synchonous logic design. How is this done in an RTC (which seems to be
a very analogous situation to this one)? My main concern is that when
the latch signal comes from the I2C address match (to store the
current counter value to be transfered over the I2C bus), how can I
ensure (at least with very high probability) that the counter is not
in the middle of rippling? I suppose I need some sort of synchronizer,
but since I don't want to have to have a 3rd clock source, I'm not
sure what the best way to do this is.
Thank you for any help,
Glenn

2005\06\24@193955 by Mike Harrison

flavicon
face
On Fri, 24 Jun 2005 15:19:06 -0700, you wrote:

>Hello,
>I am working on an FPGA design which I want to have a counter which
>counts pulses from a V/F converter. I want the counter to be read out
>via I2C. My question is, what is the standard way of accomplishing
>something like this because it seems to violate some of the rules of
>synchonous logic design. How is this done in an RTC (which seems to be
>a very analogous situation to this one)? My main concern is that when
>the latch signal comes from the I2C address match (to store the
>current counter value to be transfered over the I2C bus), how can I
>ensure (at least with very high probability) that the counter is not
>in the middle of rippling? I suppose I need some sort of synchronizer,
>but since I don't want to have to have a 3rd clock source, I'm not
>sure what the best way to do this is.
>Thank you for any help,
>Glenn


Why not use a synchronous counter, and have an output latch to freeze the count when it needs
reading.


2005\06\24@201156 by Dave Tweed

face
flavicon
face
Glenn Jones <spam_OUTlynxlabTakeThisOuTspamgmail.com> wrote:
> I am working on an FPGA design which I want to have a counter which
> counts pulses from a V/F converter. I want the counter to be read out
> via I2C. My question is, what is the standard way of accomplishing
> something like this because it seems to violate some of the rules of
> synchonous logic design.

That's correct -- right off the bat, you have two distinct clock domains:
the output of the V/F converter and the I2C clock generated by the I2C
master.

Getting meaningful signals across a clock domain boundary is a deep topic
that could fill a large book. What follows just scratches the surface.

A single signal, such as a handshake line, can be synchronized to the
destination domain by feeding it through a series of two flip-flops, both
clocked by the destination clock. Two such signals, one in each direction
across the boundary, can be used to control the transfer of multi-bit
values without running into race conditions. I like to use what I call a
two-wire four-edge handshake. It's reliable, but slow -- it takes the time
for two complete passes through the synchronizers in each direction to
transfer one multibit quantity.

Complications arise when a clock domain has an intermittent clock, such as
your I2C bus. You may not be able to count on having clock edges when you
need them to operate a conventional synchronizer. In this case, you start
looking at asynchronous state machines (a master-slave flip-flop is an
example of an asynchronous state machine), or -- as you alluded -- you
consider the possiblitity of introducing a third clock domain (usually
running on a continuous clock that's significantly faster than the other
two). But you still need to follow the rules when crossing the boundaries
among all three domains.

> My main concern is that when the latch signal comes from the I2C address
> match (to store the current counter value to be transfered over the I2C
> bus), how can I ensure (at least with very high probability) that the
> counter is not in the middle of rippling?

One approach would be to start the synchronizing process at the beginning
of *every* I2C bus transaction, and use the I2C clock edges that drive the
address to also drive the synchronization. By the time the address is
complete, you should have a stable value ready to go in case the address
matches. (If it doesn't match, no harm done -- you just do it over again
on the next I2C cycle.)

Assuming the I2C clock is at least 2x faster than the highest frequency
generated by the V/F converter, the "synchronizing process" can basically
be an N-bit register that captures the value of the V/F counter after each
time it changes state. This register is enabled by a change detector that
monitors the LSB of the counter, *except* that the latch is inhibited
for the duration of the data transfer if an I2C address match occurs.

I hope this gets you started in the right direction. If you need more
details, I'll attempt an ASCII-art block diagram.

-- Dave Tweed

2005\06\24@201350 by Jose Da Silva

flavicon
face
On June 24, 2005 03:19 pm, Glenn Jones wrote:
> Hello,
> I am working on an FPGA design which I want to have a counter which
> counts pulses from a V/F converter. I want the counter to be read out
> via I2C. My question is, what is the standard way of accomplishing
> something like this because it seems to violate some of the rules of
> synchonous logic design. How is this done in an RTC (which seems to
> be a very analogous situation to this one)? My main concern is that
> when the latch signal comes from the I2C address match (to store the
> current counter value to be transfered over the I2C bus), how can I
> ensure (at least with very high probability) that the counter is not
> in the middle of rippling? I suppose I need some sort of
> synchronizer, but since I don't want to have to have a 3rd clock
> source, I'm not sure what the best way to do this is.

Do the same thing done for serial RX/TX type of hardware.
Basically, you use a buffer.
When you ask for a count via the I2C, the count is copied from the
register to a buffer. Now you have a "snapshot" of the count. The
buffer is read by the I2C at whatever speed the I2C runs at, meanwhile,
the real counter is left alone to continue counting.

2005\06\24@203038 by Jose Da Silva

flavicon
face
On June 24, 2005 05:16 pm, Jose Da Silva wrote:
{Quote hidden}

...I forgot to also describe "when" because of the ripple.

A safe time to read is when nothing is happening on your counter.
Suppose that your counter is +ve-edge triggered (going from 0v to 5v).
In this case, you may consider a safe time to read your counter into the
buffer-latch would be during the -ve-edge of your V/F input clock.

Your buffer is read by the I2C at whatever speed it runs at, while the
counter continues to count your V/F.

2005\06\24@205708 by Dave Tweed

face
flavicon
face
I wrote:
> If you need more details, I'll attempt an ASCII-art block diagram.

Actually, what I described previously is a little too simplistic -- it
assumes that at least one V/F count will occur during each I2C cycle,
which isn't general enough. What's really required is a register that
captures the counter value *except* for a few clocks after each LSB
change. This requires that the entire data value be delayed for at
least one clock.

Something like this (view with monospace font):

                       :
      V/F clock domain : I2C clock domain
                       :
          +-----+      :  +-----+      +-----+
          |     |  MSB :  |  R  |      |  R  |
          |  C  |-------->|  e  |----->|  e  |------>
          |  o  |-------->|  g  |----->|  g  |------>
          |  u  |-------->|  i  |----->|  i  |------> to I2C
          |  n  |-------->|  s  |----->|  s  |------> bus interface
          |  t  |-------->|  t  |----->|  t  |------>
          |  e  |-------->|  e  |----->|  e  |------>
 V/F  --->|> r  |-------->|  r  |--+-->|  r  |------>
output    |     |  LSB :  |     |  |   |     |
          +-----+      :  +-----+  |   +-----+
                       :  always   |      ^ enable
                       :  enabled  |      |
                       :           |    +----+
                       :           |    |AND |<---- inhibit (low)
                       :           |    +----+     on address match
                       :           |      ^        to end of cycle
                       :           |      |
                       :           |    +----+
                       :           +--->|XNOR|<-----+
                       :           |    +----+      |
                       :           |                |
                       :           |  +---+   +---+ |
                       :           +->|D Q|-->|D Q|-+
                       :              |   |   |   |
                       :              +---+   +---+
                       :
                       : all registers and flip-flops on this
                       : side are clocked by the (intermittent)
                       : I2C clock
                       :

-- Dave Tweed

2005\06\27@024806 by Buehler, Martin

picon face
you can use a shadow register for the counter.
data is transferred to the shadow register, using the rtc clock.
whenever no i2c access is pending, shadow register updating is
activated.
as soon as a start command is detected on i2c, you disable the shadow
register update, and release it as soon as a stop command is detected.
so you can make sure that the register will not update while reading.

tino

************************************************************************
******************************


>{Original Message removed}

2005\06\27@053231 by Alan B. Pearce

face picon face
>A single signal, such as a handshake line, can be synchronized
>to the destination domain by feeding it through a series of two
>flip-flops, both clocked by the destination clock. Two such
>signals, one in each direction across the boundary, can be used
>to control the transfer of multi-bit values without running into
>race conditions. I like to use what I call a two-wire four-edge
>handshake. It's reliable, but slow -- it takes the time for two
>complete passes through the synchronizers in each direction to
>transfer one multibit quantity.

The bit you haven't covered is that while all this is happening, you can
clock stretch the I2C interface, so it does not need special synchronization
to the internal RTC clock.

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...