Prev: FIFO Depth Calculation
Next: Unecessary simulation paths
From: Muzaffer Kal on 5 May 2010 01:26
On Mon, 3 May 2010 23:27:57 -0700 (PDT), Vips
<thevipulsinha(a)gmail.com> wrote:

>Hi Guys
>
>What could be the optimal buffer for an asynchronous FIFO with the
>source clock
>
>at 50 MHz and the Read clock is 25 MHz
>
>
>Data is clming as 8 bits with each clock write . There is no idle
>cycle. We have to keep the synchronization latancy also into account.

If the frequencies are given without any accuracy, one can assume that
they're phase locked (but unknown phase difference) with different
frequencies. In that case there is a neat circuit trick which allows
you to generate a sample clock guaranteed to be safe to sample
incoming data with a single period latency of the fast clock. Then you
can store one byte and on the second byte receive two bytes with your
slow clock. In this case the fifo size is 1 byte and latency is 0 to
1 depending on which clock you use to decide.
If on the other hand one interprets the async constraint as a very
slow moving phase difference between the two clocks then the fifo
needs to be arbitrarily large based on the number of bits delivered to
the fifo vs number of bits read ie (50+ X ppm) MHz x 8 vs 25 MHz *
16.
If the interviewer really meant no idle cycle with two actually async
clocks, then you're better off at an other employer.
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com
From: Muzaffer Kal on 5 May 2010 01:32
On Tue, 4 May 2010 18:11:37 -0700 (PDT), KJ <kkjennings(a)sbcglobal.net>
wrote:
>Since this is stated as asynchronous clocks, one would also have to
>deal with whether or not the two clocks are independent or not. An
>input side that is running at 50.00001 MHz, would eventually overrun
>the output if it is running at 25.00000 MHz. To handle that
>situation, the output width just needs to be made wider...24 bits, 32
>bits, depending very strongly on what the output side is connected to.

When the "transmit clock" is faster this is indeed feasible, but what
does one do when it is slower, ie 49.99999 MHz? Borrowing against
future bits has not so nice consequences (as Greece is observing these
days ;-)

--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com
From: glen herrmannsfeldt on 5 May 2010 06:24
Muzaffer Kal <kal(a)dspia.com> wrote:
(snip)

> If the frequencies are given without any accuracy, one can assume that
> they're phase locked (but unknown phase difference) with different
> frequencies.

I suppose so, but in many real problems the accuracy is that of
a crystal oscillator. One of my favorite examples comes from
collision resolution in ethernet. The usual rule is to check to
see if anyone else is transmitting before deciding to transmit.
In case of a collision, each station stops sending, chooses a
random number, and waits an appropriate amount of time based on
that number. If another station is seen to transmit before your
time is up, wait until that transmission is done and try again.

The interesting one comes when transmitting after a collision.
Because of possible variations in the clock (crystal), some
stations will have a slightly faster clock. To avoid giving an
advantage to those with a faster clock, there is a point at which
one will transmit, even if a signal arrives from another station
before transmission actually begins. The crystal variation goes
into calculating that time.

-- glen

From: Symon on 5 May 2010 08:05
On 5/5/2010 11:24 AM, glen herrmannsfeldt wrote:
>
> The interesting one comes when transmitting after a collision.
> Because of possible variations in the clock (crystal), some
> stations will have a slightly faster clock. To avoid giving an
> advantage to those with a faster clock, there is a point at which
> one will transmit, even if a signal arrives from another station
> before transmission actually begins. The crystal variation goes
> into calculating that time.
>
That sounds like nonsense. I don't recall seeing that in the backoff
algorithm for half duplex ethernet. Do you have a source to back up the
apparently preposterous claim that users should deliberately force a
collision?

Thanks, Symon.
From: KJ on 5 May 2010 08:34
On May 5, 1:32 am, Muzaffer Kal <k...(a)dspia.com> wrote:
> On Tue, 4 May 2010 18:11:37 -0700 (PDT), KJ <kkjenni...(a)sbcglobal.net>
> wrote:
>
> >Since this is stated as asynchronous clocks, one would also have to
> >deal with whether or not the two clocks are independent or not.  An
> >input side that is running at 50.00001 MHz, would eventually overrun
> >the output if it is running at 25.00000 MHz.  To handle that
> >situation, the output width just needs to be made wider...24 bits, 32
> >bits, depending very strongly on what the output side is connected to.
>
> When the "transmit clock" is faster this is indeed feasible, but what
> does one do when it is slower, ie 49.99999 MHz? Borrowing against
> future bits has not so nice consequences (as Greece is observing these
> days ;-)
>

What borrowing are you talking about? If the transmit clock is less
than 50 the fifo will simply have times when it is empty and no read
would be performed on those cycles because the fifo flag said it has
nothing in it. There was no stated requirement that there had to be
reads on every clock cycle.

Kevin Jennings

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: FIFO Depth Calculation
Next: Unecessary simulation paths