FIFO Depth Calculation [FPGA]

Prev: FIFO Depth Calculation
Next: Unecessary simulation paths

From: Vips on 4 May 2010 15:17

On May 4, 3:18 pm, Gabor <ga...(a)alacron.com> wrote:
> On May 4, 2:29 am, Vips <thevipulsi...(a)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

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

From: Vips on 4 May 2010 15:18

From: Jonathan Bromley on 4 May 2010 17:19

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

From: KJ on 4 May 2010 21:11

On May 4, 3:18 pm, Vips <thevipulsi...(a)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 = optimal' might depend on whether you
have flip flops left over to implement the storage or internal memory
blocks, but probably 'minimal = 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

From: KJ on 4 May 2010 21:28

On May 4, 5:19 pm, Jonathan Bromley <s...(a)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. None 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. That 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. In every
> single case, the reported questions have been
> unanswerable unless you know the questioner's
> hidden assumptions.

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.

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

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