what are the problems associated with asynchronous design

I had this interview questions regarding asynhronous design, and I was
not able to answer it. Question was regarding desing where one end of
the block was at x freq and other end of the block was at y freq.
So what are the problems associated with this design, and how can we
fix them.
Can you guys provide me few hints, pointers and suggestions
Thank you.

ankitks@yahoo.com

wrote:
> I had this interview questions regarding asynhronous design, and I was
> not able to answer it. Question was regarding desing where one end of
> the block was at x freq and other end of the block was at y freq.
> So what are the problems associated with this design, and how can we
> fix them.
> Can you guys provide me few hints, pointers and suggestions
> Thank you

Think - Metastability.

Niv

Niv a écrit :
> wrote:
>> I had this interview questions regarding asynhronous design, and I was
>> not able to answer it. Question was regarding desing where one end of
>> the block was at x freq and other end of the block was at y freq.
>> So what are the problems associated with this design, and how can we
>> fix them.
>> Can you guys provide me few hints, pointers and suggestions
>> Thank you
>
> Think - Metastability.
>
Race conditions, too.

Nicolas

Nicolas Matringe

<> wrote in message
news: ups.com...
>I had this interview questions regarding asynhronous design, and I was
> not able to answer it. Question was regarding desing where one end of
> the block was at x freq and other end of the block was at y freq.
> So what are the problems associated with this design, and how can we
> fix them.

First of all, if you have two things running synchronously at two different
frequencies (x and y per your post) then this is not asynchronous design.
Asynchronous design does not have free running clocks running at any preset
frequency, they handshake things across.

But now if you do have two things running at 'x' and 'y' frequency and they
need to communicate with each other the general approach is a dual clock
fifo to move stuff in one clock domain into the other. As a designer of
such a system you would generally use an already designed dual clock fifo
and plop them down and now the two sides are talking.

Many times the signals that cross the clock domains are relatively static
and do not require any high speed communications path. An very simple
example is a reset signal. Maybe the 'reset' signal gets generated at power
up in the 'x' clock domain but needs to make it over into the 'y' clock
domain so that it can be used with the 'y' clock. All you need for these
types of signals is a set of flip flops instead of a full blown dual clock
fifo. Now sit down and look at timing specifications for flip flops and
work through the problem of how you can sample a signal that is synchronized
to the 'x' clock with a set of flip flops that are all clocked by the 'y'
clock. In particular ponder on the setup and hold time parameters and how
can you guarantee proper behaviour on your output given that you have no
control over the input times.

That will lead you into the subject of timing analysis in general and
metastability as a particular sub-topic which will lead you to the fact that
you won't be able to make an absolute guarantee of correct operation but
will only be able to provide a statistical guarantee of correct behaviour
(something of the form "Expected to have one failure only once every 10,000
years"). Once you have a good understanding of how you would move one
signal from one clock domain to the other you'll have a basic appreciation
for how difficult it might be to actually design a true dual clock fifo
which does not have the luxury of assuming that the signals that are moving
clock domains are relatively low occurances (like the 'reset' signal).

KJ

KJ