FIFO in SDRAM

This kind of design has too many variables and trade-offs that
different users will never agree upon.
I started thinking SRAM, which is the right approach up to a certain
size. Cost is the question.
Then there is speed and acceptable through-delay or latency or block
length.
I still believe in using a dual-ported BlockRAM a the staging area,
because it offers so much timing flexibility.
Peter Alfke

Hello,

Thanks for your answer and advices.
What you describe is pretty much like what I have planned to do, just not to
say this is what I wanted to do !!

St�phane.




"Gabor" <gabor@alacron.com> a &#4294967295;crit dans le message de news:
1137626090.900239.283190@g47g2000cwa.googlegroups.com...
St&#4294967295;phane,

I do similar designs to this (framegrabber cards) and haven't found a
ready-made SDRAM FIFO, although I haven't looked in a long time
since rolling my own many designs ago.

I think that getting good performance from SDRAM in this situation
involves tuning the burst accesses to allow continuous use of the
data bus when not changing direction between read and write.

Peter was on the right track with the read / write ping-pong machine,
but for SDRAM you need to read multiple words / write multiple words
to get any sort of performance.

A design I re-use frequently has a constant 21-cycle loop in which
16 of the cycles are used for either read or write (not both) during
one loop.  Un-needed loops are replaced by a 21-cycle NOP and
auto refresh.  Start-up code counts refresh loops until 8 refreshes
occur and then sets the mode register.  For simplicity, the address
pins are reset to the state required for the mode register set (MRS)
and not clock enabled until the MRS has completed.  This reduces
the gate depth of the address mux.

I have a simple "arbiter" that decides what to do with the next 21
clock
cycles (read, write, or refresh).  To reduce power on some designs
I only refresh if a refresh timer has expired, then unused 21-clock
loops are just completely NOP'd.

Memories are set for burst length of 4 and one burst of 4 words is
sent to each bank (thus overlapping data and control cycles).  Think
of the bank address as the least significant address bits.  For better
throughput you can increase the loop length and each additional
16 cycles would add 16 more memory accesses (e.g. 32 accesses
in a 37-cycle loop).

The basic element going in or out of this "FIFO" is then a burst of
16 words (think of this as your FIFO width if you will.  Generally I
use
a COREgen FIFO to buffer up data at both ends of the SDRAM to
deal with asynchronous data rates and differing byte widths on
input and output.

The whole design is remarkably small, but as I said I haven't seen such
a design made generally available.

Good luck,
Gabor

sjulhes wrote:
> Hello,
>
> The goal is not to create delay but to handle the fact the 32 bits / 33
Mhz
> bus is not always available.
>
> For the SDRAM controller I already have my solution in mind.
>
> I was only wondering if this function ( huge FIFO for FPGA using an
external
> SDRAM ) ,which i'm shure a lot of people would need, would already exist
and
> be available.
>
> St&#4294967295;phane.
>
> "Peter Alfke" <peter@xilinx.com> a &#4294967295;crit dans le message de news:
> 1137514850.769502.197970@f14g2000cwb.googlegroups.com...
> > Give more details:
> > depth, width, clock rate for write and for read. Asynchronous clocks?
> > Peter Alfke, Xilinx
> >