Doubt in Asynchronus Circuit design

Hi All,
     I am designing my first real clock domain crossing circuit. My
problem is a high speed wrapper for a low speed device. What is the
general approch to be followed. I will tell you my approch and please
correct me if needed.
The high speed wrapper will write to its registers at 100MHz. First i
am converting this registers to 1MHz domain, using two flops both
using a 1MHz clock. Now the data is safe in the 1MHz domain(And then i
will run some 1MHz state machine using this data). But the problem is
with the write at the first domain. We can have upto 50 writes (a
write wil lhappen only in two cycles) in the wrapper registers. For
this we can take the latest value to the 1MHz domain. But we must
indicate to the 1MHz domain that there was a write in the wrapper in
any of these possible 50 cycles. If any cycle was a write then in the
1MHz domain we must restart the state machine. How this is possible. I
hope i have made myself clear. I cant describe the correct usage since
it is company related things.
  __     __    __     __    __     __    __     __    __     __
__     __    __
_|   |__|   |__|   |__|   |__|   |__|   |__|   |__|   |__|   |__|   |
__|   |__|   |__|   |__

  <w1><r1 ><w2>                 <w3>       <r2 >
      ________                 ________
________                 ________
     |              |_________|              |_________|              |
_________|              |_________
                                     ________
________                  ________
     __________________|              |_________|              |
_________|              |_________
 
<fsm strd wth w2 data>
 
<fsm shd restrt wth w3 data


regards
Sumesh V S

On Jul 5, 8:10 am, vssumesh <vssumesh_a...@yahoo.com> wrote:
> Hi All,
>      I am designing my first real clock domain crossing circuit. My
> problem is a high speed wrapper for a low speed device. What is the
> general approch to be followed. I will tell you my approch and please
> correct me if needed.
> The high speed wrapper will write to its registers at 100MHz. First i
> am converting this registers to 1MHz domain, using two flops both
> using a 1MHz clock. Now the data is safe in the 1MHz domain(And then i
> will run some 1MHz state machine using this data). But the problem is
> with the write at the first domain. We can have upto 50 writes (a
> write wil lhappen only in two cycles) in the wrapper registers. For
> this we can take the latest value to the 1MHz domain. But we must
> indicate to the 1MHz domain that there was a write in the wrapper in
> any of these possible 50 cycles. If any cycle was a write then in the
> 1MHz domain we must restart the state machine. How this is possible. I
> hope i have made myself clear. I cant describe the correct usage since
> it is company related things.
>   __     __    __     __    __     __    __     __    __     __
> __     __    __
> _|   |__|   |__|   |__|   |__|   |__|   |__|   |__|   |__|   |__|   |
> __|   |__|   |__|   |__
>
>   <w1><r1 ><w2>                 <w3>       <r2 >
>       ________                 ________
> ________                 ________
>      |              |_________|              |_________|              |
> _________|              |_________
>                                      ________
> ________                  ________
>      __________________|              |_________|              |
> _________|              |_________
>
> <fsm strd wth w2 data>
>
> <fsm shd restrt wth w3 data
>
> regards
> Sumesh V S


I can't really see your diagram, but there are a couple of points I
can make.

1) Is your 1 MHz domain synchronous to the 100 MHz domain - i.e. do
you just
divide 100 MHz clock by 100 to make 1 MHz clock?  If not and your
domains are
truly asynchronous you need to be sure your sampling of registers is
coherent
when you change clock domains.  For example if you are looking at 8
bits of
data written synchronously to 100 MHz and just put all 8 bits through
2 flip-
flops on the 1 MHz clock, you can sometimes get some bits from before
and
other bits from after a write event.  Since your clocks have a very
large
difference in frequency, it may make sense to sample the 1 MHz clock
in the
100 MHz domain and make a clock enable after the rising edge of 1MHz
clock that
lasts one cycle of the 100MHz clock.  Use this clock enable and the
100 MHz
clock as the first stage of your synchronizer to ensure data
coherency.

2) Generally when you need to indicate an update to an asynchronous
process you
need handshakes.  You can have a register that is set when any of the
data registers
are written in the 100 MHz domain, and cleared when the 1 MHz domain
acknowledges
the change.  This can have a race condition if changes happen
frequently since
the reset signal could come just as another update happens.  Another
approach is
similar to a FIFO controller where you count up with one counter on
any 1 MHz
clock period where an update has occured, and count up with another
counter when
the 1 MHz logic recognizes the change.

HTH,
Gabor

Thanks Gabor for these valuable replys. First of all, how can i draw
waveform diagrams in this group? I have seen lot of sessions with neat
diagarm, my diagarm was also good when i draw it on the tesxt window
but when in converted to the html page it somehow got distotred. How
can i share my diagrams with you?

Comming to your second suggestion, that ack from the 100MHz domain to
the 1MHz domain is exactly what i want, but how we can do that? The
flag which indicates that is set on 100MHz clock and rest on 1MHz
clock. Is that possible to use two clocks in a single FF?

I am thinking of another process similar to your suggestion that the
flag will be set at 100Mhz, but will also be reset at 100MHz when an
edge happend at the 1MHz signal.  But these information that an edge
happend at the 1MHz location is also needed to be synchronised to the
100MHz domain. That will delay it by two more cycles in the 100MHz
domain.

Your first suggestion i could not understand fully. What will happen
if i use only two flops operting at 1MHz clock. Please explian me why
some bits will be differnt from other bits. My two clocks are fully
asynchronus.

vssumesh wrote:
> Thanks Gabor for these valuable replys. First of all, how can i draw
> waveform diagrams in this group? I have seen lot of sessions with neat
> diagarm, my diagarm was also good when i draw it on the tesxt window
> but when in converted to the html page it somehow got distotred. How
> can i share my diagrams with you?

1) Use a fixed size font when drawing it.
2) Make sure your client does cut the line automatically at a certain
   number of character. And in any case try to keep all the line quite
   short (likee ~75 char)

Is it possible to synchronise the 1MHz clock to the 100MHz domain and
keep that clock for all the operations like ADC. (This may not be
possible according to the spec i have but i am asking a general
doubt).

On Thu, 05 Jul 2007 22:58:37 -0700, 
vssumesh <vssumesh_asic@yahoo.com> wrote:

>Is it possible to synchronise the 1MHz clock to the 100MHz domain and
>keep that clock for all the operations like ADC. (This may not be
>possible according to the spec i have but i am asking a general
>doubt).

Easy: just oversample and edge-detect it...

  signal enable_1MHz: std_logic;
  ...
  process (clk_100MHz)
    variable resync1, resync2, delay: std_logic;
  begin
    if rising_edge(clk_100MHz) then
      delay := resync2;
      resync2 := resync1;
      resync1 := clk_1MHz;
      if (resync2 and not delay) = '1' then
        enable_1MHz <= '1';
      else
        enable_1MHz <= '0';
      end if;
    end if;
  end process;

This generates a pulse on enable_1MHz that is synchronous
with clk_100MHz and is exactly one 100MHz clock cycle wide.
So you can then use it to enable any activity in the
100MHz clock domain that must happen once per 1MHz clock.
Of course, it's important to note that this enable will take
effect on the third or fourth 100MHz clock after each rising
edge of the 1MHz clock.  You need to check your system spec
to determine whether this is acceptable.  Usually, though,
it works well.  It's a fairly safe bet that everything in
the 1MHz clock domain is nicely stable by 30ns after a
rising edge on the 1MHz clock.  If you need more settling
time in the 1MHz domain, simply add more delay stages to the
process.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

I also arrived in the same solution, though i reduced the number of
sync flops to two like "if (resync1 and not resync2)". My thought was
now we have some fast FFs and this enable signal is going to be used
only at the next +ve edge of 100MHz, so by that time we get a valid
signal in the "enable_1MHz". Will this assumption work?

On Fri, 06 Jul 2007 01:58:21 -0700, 
vssumesh <vssumesh_asic@yahoo.com> wrote:

>I also arrived in the same solution, though i reduced the number of
>sync flops to two like "if (resync1 and not resync2)". My thought was
>now we have some fast FFs and this enable signal is going to be used
>only at the next +ve edge of 100MHz, so by that time we get a valid
>signal in the "enable_1MHz". Will this assumption work?

The extra FF provides protection against metastable events on 
"resync1".  If your fast clock were, let's say, 20MHz then I
definitely would not bother with the extra FF.  The question
is: how likely is it for a setup/hold violation on "resync1"
to induce enough metastability to push its settling time out
to about 9ns?  A third FF is much cheaper than the time it
takes me to look up, and calculate, the math :-)
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

On Jul 6, 5:32 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Fri, 06 Jul 2007 01:58:21 -0700,
>
> vssumesh <vssumesh_a...@yahoo.com> wrote:
> >I also arrived in the same solution, though i reduced the number of
> >sync flops to two like "if (resync1 and not resync2)". My thought was
> >now we have some fast FFs and this enable signal is going to be used
> >only at the next +ve edge of 100MHz, so by that time we get a valid
> >signal in the "enable_1MHz". Will this assumption work?
>
> The extra FF provides protection against metastable events on
> "resync1".  If your fast clock were, let's say, 20MHz then I
> definitely would not bother with the extra FF.  The question
> is: how likely is it for a setup/hold violation on "resync1"
> to induce enough metastability to push its settling time out
> to about 9ns?  A third FF is much cheaper than the time it
> takes me to look up, and calculate, the math :-)

Actually its worse than that.  Since the tools usually work with
a PERIOD constraint, how can you be sure that you have anywhere
near 9 ns of slack in this path to handle this event?  Probably
3 ns is enough for most metastable events, but how do you even
know you have 3 ns slack without looking through the placed design
afterwards?  In the 2 flip-flop case there is a high probability
that the path between flops will have a large slack at 100 MHz
since there are no intervening LUTs.  If you want to go overboard,
you can hand place the synchonizing flops to ensure lots of
timing slack.

Regards,
Gabor

On Jul 6, 1:20 am, vssumesh <vssumesh_a...@yahoo.com> wrote:
> Thanks Gabor for these valuable replys. First of all, how can i draw
> waveform diagrams in this group? I have seen lot of sessions with neat
> diagarm, my diagarm was also good when i draw it on the tesxt window
> but when in converted to the html page it somehow got distotred. How
> can i share my diagrams with you?
>
> Comming to your second suggestion, that ack from the 100MHz domain to
> the 1MHz domain is exactly what i want, but how we can do that? The
> flag which indicates that is set on 100MHz clock and rest on 1MHz
> clock. Is that possible to use two clocks in a single FF?
>

The idea was to use one clock and an asynchronous reset.  This is why
I also suggested that there was a problem concerning multiple events.
It could happen that the asynchronous reset masks out a new update.
If you want to be sure to handle all updates, but are not worried
about responding twice to the same update, you can reverse the process
and use an asynchronous set when the update occurs, and synchronous
reset on the 1 MHz clock when the update is processed.  Still you
need to be careful because the set event can come very close to the
1 MHz clock edge.

> I am thinking of another process similar to your suggestion that the
> flag will be set at 100Mhz, but will also be reset at 100MHz when an
> edge happend at the 1MHz signal.  But these information that an edge
> happend at the 1MHz location is also needed to be synchronised to the
> 100MHz domain. That will delay it by two more cycles in the 100MHz
> domain.
>

This is generally the preferred method.  Keeping handshake in one
clock domain removes the race conditions.  However now you need to
deal with the possibility of a new update occuring just after an
edge of 1 MHz but before the reset signal. Make sure that the 1 MHz
process sees the new updates by re-asserting the flag (or not clearing
it) if another update has occured within 3 100 MHz cycles prior to
the reset signal.

> Your first suggestion i could not understand fully. What will happen
> if i use only two flops operting at 1MHz clock. Please explian me why
> some bits will be differnt from other bits. My two clocks are fully
> asynchronus.

This is important.  Two flops are the approved method of synchronizing
a
single signal to avoid metastability issues.  However this does not
deal
with data coherency.  If your registers are single bits with
independent
functions, or are known to only change one bit at a time (like Grey
code)
then the 2-stage synchronizer is all you need.  But what if you are
transferring binary data like an 8-bit number?  Now if in one clock
domain the number goes from 01111111 to 10000000 binary, the value
has changed by 1 count, but all the bits have changed together (in
that domain).  This does not mean that the bits will change together
as sampled in the other clock domain.  Varying path delays can cause
some bits to meet the setup to the 1 MHz clock when others don't.
Then even though there may be no metastability on any of the sampled
bits, you could easily read a value like 00000000 binary if for
example
the highest bit had a longer path delay than the lower 7.  The
second synchronizing register would not fix this, only delay the
00000000
value by another 1 us.

A much better approach is to use a register clocked by 100 MHz with
a clock enable generated like your handshake reset just after the
rising edge of 1MHz.  This register would be guaranteed to update
coherently, but would have nearly 1 us of setup to the next 1 MHz
rising edge.