FPGA Central

Hi Folks,

I am using Altera's LPM FIFOs. These are deep fifos and was wondering
if there are any techniques that people follow to initialize the rd/wr
pointers in the fifo so that I can quickly simulate the overflow
condition. I use modelsim pe.

I would appreciate any thoughts.

TIA.
-sanjay

fpgabuilder wrote:
> Hi Folks,
>
> I am using Altera's LPM FIFOs. These are deep fifos and was wondering
> if there are any techniques that people follow to initialize the rd/wr
> pointers in the fifo so that I can quickly simulate the overflow
> condition. I use modelsim pe.

You could infer the same FIFO from code.
Simulating the code instead of using Altera's netlist
will speed up your simulation.

Or you could test overflow on a smaller FIFO.

-- Mike Treseler

How would I infer the fifo from the code? Do you mean I should write
my own fifo or create a behavioral model of Altera's FIFO? While this
may be the way to go, but last time I tried some thing like this, I
noticed that the FPGA vendor had a much better implementation of the
fifo.

-sanjay

What do you really want to simulate?
Generating the FULL signal after the right amount of writes is really a
trivial decoding job.
Getting back out of "FULL" is tricky, and - I claim- cannot be
simulated exhaustively, since there is an infinite (truly infinite)
number of phase relationships between the write and the read clock ( if
they are asynchronous).
If write and read are synchronous, the whole FIFO design is a trivial
state machine.
Peter Alfke (Xilinx, but posting from home).

fpgabuilder wrote:
> How would I infer the fifo from the code? Do you mean I should write
> my own fifo or create a behavioral model of Altera's FIFO? While
this
> may be the way to go, but last time I tried some thing like this, I
> noticed that the FPGA vendor had a much better implementation of the
> fifo.
>
> -sanjay

Generally when you want to test your code whether it is FIFO or
anything else you would usually like to start by testing the HDL design
as it run much faster and help eliminating all the logic issues.

The use of Behavioral FIFO don't mean you should not use later the
Vendor FIFO as if you find the vendor to give better FIFO go ahead and
use it

The use of Behavioral FIFO (which MUST be working with similar way to
the FIFO you will later use meaning if the input address is sampled the
same should happen in the behavioral and so on) is in order to get your
logic design tested quickly, as running test on netlist is generally
speaking very slow not to mention harder to debug as some nets might be
renamed and counter are now become separate FF's which you need to
group and so on.

Once your HDL testing is done you should run post place and route with
timing information (sdf file) which will verify that the design work
also with all the timing as well as that your RTL was synthesis and
optimized correctly.

To get into overflow and underflow condition in large fifo you can
"play" with the pointer like starting them in certain value or
forcing them at some point to certain value or simple use a smaller
fifo.
Obviously the preferred way is not touch anything and simple run the
test for enough time to get into overflow and underflow (and random the
clock to get as much senario as possiable).

If for example your FIFO can handle let say 100ppm and is deep enough
so cells/frame never cause an underflow or overflow and you want to
verify that if from some reason this does happen your code is robust
enough than simple change your clock's to be with "bigger ppm".

This by the way should be done not only for FIFO but basically for any
design you do, meaning first test it with HDL code and only than with
the netlist.

Have fun.

Thanks Berty.
It confirms my suspicions about starting off the pointers at some
value. And good point about running the clock at higher ppm to test
for the overflow and underflows.

-sanjay