Hi All

What could be the optimal buffer for an asynchronous FIFO with the
Write clock at 50 MHz and the Read clock is 25 MHz


Data is coming as 8 bits with each clock write . There is no idle
cycle. We have to keep the synchronization latency also into account.


Thanks

Vips

On May 4, 2:29=A0am, Vips <thevipulsi...@gmail.com> wrote:
> Hi All
>
> What could be the optimal buffer for an asynchronous FIFO with the
> Write clock at 50 MHz and the Read clock is 25 MHz
>
> Data is coming as 8 bits with each clock write . There is no idle
> cycle. We have to keep the synchronization latency also into account.
>
> Thanks
>
> Vips

If I understand correctly you're asking how to calculate the
depth of the FIFO required for your application?  When you
say "there is no idle cycle" I assume you mean that data
is written to the input on every clock cycle.  For how long?
Obviously for this FIFO to work indefinitely, you would
need to adjust the output bandwidth to exceed the input
bandwidth or else its depth would need to be infinite.

For a fixed input packet length you can calculate the depth
as the size of the packet minus the number of words read
from the FIFO while the packet was being written.  In
your case, assuming the FIFO read enable is always active
when the FIFO is not empty, there would only be a short
delay for flag synchronization, then one word read for
every two words written.  So the depth would need to
be half the packet size plus the number of input clock
cycles required to start up the readout.

HTH,
Gabor

On May 4, 3:18=A0pm, Gabor <ga...@alacron.com> wrote:
> On May 4, 2:29=A0am, Vips <thevipulsi...@gmail.com> wrote:
>
> > Hi All
>
> > What could be the optimal buffer for an asynchronous FIFO with the
> > Write clock at 50 MHz and the Read clock is 25 MHz
>
> > Data is coming as 8 bits with each clock write . There is no idle
> > cycle. We have to keep the synchronization latency also into account.
>
> > Thanks
>
> > Vips
>
> If I understand correctly you're asking how to calculate the
> depth of the FIFO required for your application? =A0When you
> say "there is no idle cycle" I assume you mean that data
> is written to the input on every clock cycle. =A0For how long?
> Obviously for this FIFO to work indefinitely, you would
> need to adjust the output bandwidth to exceed the input
> bandwidth or else its depth would need to be infinite.
>
> For a fixed input packet length you can calculate the depth
> as the size of the packet minus the number of words read
> from the FIFO while the packet was being written. =A0In
> your case, assuming the FIFO read enable is always active
> when the FIFO is not empty, there would only be a short
> delay for flag synchronization, then one word read for
> every two words written. =A0So the depth would need to
> be half the packet size plus the number of input clock
> cycles required to start up the readout.
>
> HTH,
> Gabor

Thanks Gabor

I was also thinking the same. I was asked this question in an
interview and wanted to know the answers from the experts. Though I
also answered as infinite but the guy said there could be an "OPTIMAL"
buffer to make sure there is no OVER RUN.

When I asked him to answer and proof he simply declined.

Anyways thanks ..

regards

Vipul

On May 4, 3:18=A0pm, Gabor <ga...@alacron.com> wrote:
> On May 4, 2:29=A0am, Vips <thevipulsi...@gmail.com> wrote:
>
> > Hi All
>
> > What could be the optimal buffer for an asynchronous FIFO with the
> > Write clock at 50 MHz and the Read clock is 25 MHz
>
> > Data is coming as 8 bits with each clock write . There is no idle
> > cycle. We have to keep the synchronization latency also into account.
>
> > Thanks
>
> > Vips
>
> If I understand correctly you're asking how to calculate the
> depth of the FIFO required for your application? =A0When you
> say "there is no idle cycle" I assume you mean that data
> is written to the input on every clock cycle. =A0For how long?
> Obviously for this FIFO to work indefinitely, you would
> need to adjust the output bandwidth to exceed the input
> bandwidth or else its depth would need to be infinite.
>
> For a fixed input packet length you can calculate the depth
> as the size of the packet minus the number of words read
> from the FIFO while the packet was being written. =A0In
> your case, assuming the FIFO read enable is always active
> when the FIFO is not empty, there would only be a short
> delay for flag synchronization, then one word read for
> every two words written. =A0So the depth would need to
> be half the packet size plus the number of input clock
> cycles required to start up the readout.
>
> HTH,
> Gabor

Thanks Gabor

I was also thinking the same. I was asked this question in an
interview and wanted to know the answers from the experts. Though I
also answered as infinite but the guy said there could be an "OPTIMAL"
buffer to make sure there is no OVER RUN.

When I asked him to answer and proof he simply declined.

Anyways thanks ..

regards

Vipul

On Tue, 4 May 2010 12:18:45 -0700 (PDT), Vips wrote:

>I was also thinking the same. I was asked this question in an
>interview and wanted to know the answers from the experts. Though I
>also answered as infinite but the guy said there could be an "OPTIMAL"
>buffer to make sure there is no OVER RUN.
>
>When I asked him to answer and proof he simply declined.

That sounds like an employer you're better off not workiing for.
If what you told us is an accurate reflection of the way the 
question was posed, it is evidence of sloppy thinking, poor
use of language as a communication tool, and ambiguous
specification.  None of these are good attributes when
you're trying to design products :-)

It also sounds rather like an interviewer whose aim is 
not to select the best candidate, but to bully you into
thinking that he's smarter than you.  That sucks too.

I've often heard people reporting the use of such 
FIFO-estimating questions in interviews.  In every
single case, the reported questions have been
unanswerable unless you know the questioner's
hidden assumptions.  The result is that a truly 
smart candidate will have no choice but to ask
a load of questions that the interviewer thinks
are stupid, but in fact are just a reflection of
the interviewer's poor communication.  Great
selection skills, eh?
-- 
Jonathan Bromley

On May 4, 3:18=A0pm, Vips <thevipulsi...@gmail.com> wrote:
>
> I was also thinking the same. I was asked this question in an
> interview and wanted to know the answers from the experts. Though I
> also answered as infinite but the guy said there could be an "OPTIMAL"
> buffer to make sure there is no OVER RUN.
>

The minimal depth would be just large enough to cover the worst case
latency in getting an item through the fifo so it would be roughly
2-3.  Whether or not 'minimal =3D optimal' might depend on whether you
have flip flops left over to implement the storage or internal memory
blocks, but probably 'minimal =3D optimal'

The width of the fifo would be double the width of the input data...in
this case the fifo width would be 16 bits.

> When I asked him to answer and proof he simply declined.
>

That will be left as an exercise to the reader...but presumably you
now recognize that if you can pull data out in chunks that are twice
as wide as the input, that it is now fairly straightforward to run the
output side at half the speed of the input.

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.

Kevin Jennings

On May 4, 5:19=A0pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:
> On Tue, 4 May 2010 12:18:45 -0700 (PDT), Vips wrote:
>
> That sounds like an employer you're better off not workiing for.
> If what you told us is an accurate reflection of the way the
> question was posed, it is evidence of sloppy thinking, poor
> use of language as a communication tool, and ambiguous
> specification. =A0None of these are good attributes when
> you're trying to design products :-)
>

Maybe, but finding a person that is able to deal with ambiguous
specifications and still design a robust product might make for a good
employee.  If you can't design anything until you're told every last
specification, you need to spend some more time thinking rather than
waiting.

The obvious solution in this case is simply to pull the data out at
twice the data width as the input and be able to guarantee that the
output clock frequency will be at least a wee bit greater than 2x the
input clock frequency.  If that guarantee cannot be met, then the
output width must be larger (3x or 4x).

> It also sounds rather like an interviewer whose aim is
> not to select the best candidate, but to bully you into
> thinking that he's smarter than you. =A0That sucks too.
>

Perhaps (and quite likely the case too)...but don't discount the
chance that the interviewer was simply looking for someone who could
notice that data widths are many times a design parameter that can be
adjusted as necessary to meet the overall needs of the design.  In
this case, the input data width was specified (and somewhat
irrelevant), but the output data width was left unconstrained and
therefore open to whatever design considerations the interviewee might
like to apply.

> I've often heard people reporting the use of such
> FIFO-estimating questions in interviews. =A0In every
> single case, the reported questions have been
> unanswerable unless you know the questioner's
> hidden assumptions. =A0

You can also look at it as a chance to state your assumptions
instead...don't ask if those assumptions are correct, simply state
that since they weren't stated as design constraints you made the
following assumptions and then lay out your design plan.

> The result is that a truly
> smart candidate will have no choice but to ask
> a load of questions that the interviewer thinks
> are stupid, but in fact are just a reflection of
> the interviewer's poor communication. =A0

That's why you don't ask for the 'hidden assumptions', instead you
state your assumptions and your solution.

> Great selection skills, eh?

You're probably right...but thought I'd give an opposing viewpoint.

Kevin Jennings

On Tue, 4 May 2010 18:11:37 -0700 (PDT), KJ <kkjennings@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

On May 5, 1:32=A0am, Muzaffer Kal <k...@dspia.com> wrote:
> On Tue, 4 May 2010 18:11:37 -0700 (PDT), KJ <kkjenni...@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. =A0An
> >input side that is running at 50.00001 MHz, would eventually overrun
> >the output if it is running at 25.00000 MHz. =A0To 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

On 5/4/2010 7:29 AM, Vips wrote:
> Hi All
>
> What could be the optimal buffer for an asynchronous FIFO with the
> Write clock at 50 MHz and the Read clock is 25 MHz
>
>
> Data is coming as 8 bits with each clock write . There is no idle
> cycle. We have to keep the synchronization latency also into account.
>
>
> Thanks
>
> Vips

You could have the read side running at 87% of light speed. Then, 
special relativity time dilation effects mean that you will have enough 
time to get the data out with a 25MHz clock, for an observer traveling 
with the read side.

Was the job at CERN?

HTH., Syms.

On 5/4/2010 2:19 PM, Jonathan Bromley wrote:
> On Tue, 4 May 2010 12:18:45 -0700 (PDT), Vips wrote:
>
>> I was also thinking the same. I was asked this question in an
>> interview and wanted to know the answers from the experts. Though I
>> also answered as infinite but the guy said there could be an "OPTIMAL"
>> buffer to make sure there is no OVER RUN.
>>
>> When I asked him to answer and proof he simply declined.
>
> That sounds like an employer you're better off not workiing for.
> If what you told us is an accurate reflection of the way the
> question was posed, it is evidence of sloppy thinking, poor
> use of language as a communication tool, and ambiguous
> specification.  None of these are good attributes when
> you're trying to design products :-)
<snip>
>The result is that a truly
> smart candidate will have no choice but to ask
> a load of questions that the interviewer thinks
> are stupid, but in fact are just a reflection of
> the interviewer's poor communication.  Great
> selection skills, eh?

When interviewing candidates, I almost always ask an impossible question
or two. It is a test of character, not of knowledge. I don't want
someone who just gives up, nor do I want one who guesses at the missing
information. I want someone who is not afraid to question authority
until he is sure he can solve the problem correctly.
Very little in many interviews is as it seems.

Curt