FIFO Depth Calculation

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.


Thanks

Vips

On 4 Mai, 08:27, Vips <thevipulsi...@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 you want to run that for one year 772 TByte FIFO should be enough.
(The FIFO content will grow with 25MByte/s)
Should fit in a single rack enclosure without problems.

Kolja

"Kolja Sulimma" <ksulimma@googlemail.com> wrote in message 
news:501b9be9-de49-49b2-8ac7-2749b575f0d0@o11g2000yqj.googlegroups.com...
> On 4 Mai, 08:27, Vips <thevipulsi...@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 you want to run that for one year 772 TByte FIFO should be enough.
> (The FIFO content will grow with 25MByte/s)
> Should fit in a single rack enclosure without problems.
>
> Kolja

Actually if it is to run for a year then 394TB should be adequate - half the 
amount. It only needs to fill for 6 months, it will take the other 6 months 
to unload it before the system turns off. Also only half a rack enclosure 
required.

Phil 

On May 4, 2:43=A0pm, "Phil Jessop" <p...@noname.org> wrote:
> "Kolja Sulimma" <ksuli...@googlemail.com> wrote in message
>
> news:501b9be9-de49-49b2-8ac7-2749b575f0d0@o11g2000yqj.googlegroups.com...
>
>
>
> > On 4 Mai, 08:27, Vips <thevipulsi...@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 you want to run that for one year 772 TByte FIFO should be enough.
> > (The FIFO content will grow with 25MByte/s)
> > Should fit in a single rack enclosure without problems.
>
> > Kolja
>
> Actually if it is to run for a year then 394TB should be adequate - half =
the
> amount. It only needs to fill for 6 months, it will take the other 6 mont=
hs
> to unload it before the system turns off. Also only half a rack enclosure
> required.
>
> Phil

Thank you Phil.  You just saved the OP a ton of money :-)

On Mon, 3 May 2010 23:27:57 -0700 (PDT), Vips
<thevipulsinha@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

Muzaffer Kal <kal@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

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.

Symon <symon_brewer@hotmail.com> wrote:
(snip on ethernet collision resolution)

> 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?

Not deliberately force, but if two stations compute the same
backoff delay, proper resolution requires that the collision occur.
That is true, even if the signal from one arrives at the other
before the latter starts sending.  I will have to see about a
reference.

-- glen

Symon <symon_brewer@hotmail.com> 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?

Actually, I believe the one I was thinking about is in the inter-frame 
gap algorithm.  In both the IFG and collision resolution case it
is required that when stations are scheduled to send that they 
actually do so.   If carrier sense is active, a station waits until
it goes inactive, waits the appropriate IFG delay, and transmits.
There is a point during the inter-frame gap time that the station
makes an irrevocable decision to transmit, even if carrier sense
goes active.  That is necessary for fair access to the medium 
within the tolerance of the crystal oscillators, and other possible
delays.  

Also, the RS232 asynchronous communication stop bit is needed
to allow for possible clock differences between two stations.

-- glen

On 5/5/2010 10:03 PM, glen herrmannsfeldt wrote:
> Symon<symon_brewer@hotmail.com>  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?
>
> Actually, I believe the one I was thinking about is in the inter-frame
> gap algorithm.  In both the IFG and collision resolution case it
> is required that when stations are scheduled to send that they
> actually do so.   If carrier sense is active, a station waits until
> it goes inactive, waits the appropriate IFG delay, and transmits.
> There is a point during the inter-frame gap time that the station
> makes an irrevocable decision to transmit, even if carrier sense
> goes active.  That is necessary for fair access to the medium
> within the tolerance of the crystal oscillators, and other possible
> delays.
>
> Also, the RS232 asynchronous communication stop bit is needed
> to allow for possible clock differences between two stations.
>
> -- glen
Dear Glen,

Thanks for the clarification. I wonder, could you point me to a 
'inter-frame gap algorithm' specification which proposes that a user 
should send despite the channel being busy?

Also, I am interested in your concluding statement about RS232 stop 
bits. I gather you live in a world of half-duplex.

How would you propose to eradicate the stop bit in a world where we are 
all synchronised?

How would we synchronise ourselves?

Would we need to be adjacent?

Thanks, Syms.