FIFO in SDRAM

Give more details: depth, width, clock rate for write and for read. Asynchronous clocks? Peter Alfke, Xilinx

Give more details: depth, width, clock rate for write and for read. Asynchronous clocks? Peter Alfke, Xilinx

Well, I have non continous 16 bits @66Mhz incoming data flow ( video ) which is send to a 32 bits @ 33Mhz bus which is not always available. I have to put a big FIFO between theses two busses, so I have to implement a FIFO using a SDRAM. Transmission data can be up to 32Mbits.

Stéphane.

"Peter Alfke" a écrit dans le message de news: snipped-for-privacy@f14g2000cwb.googlegroups.com...

Stephane, you did not say how big, but let me believe you that you need an external SDRAM. The speed you mention is slow by today's standards. I suggest you use a single read/write SDRAM interface and you inter-digitate (time-share) the read and write operations on that common SDRAM interface. The FPGA is then just the cintroller and arbiter between read and write operations. For simplicity, you could run the memory as a synchronous

2-stroke operation, always a read followed by a write. These two cycles would fit into your 15 ns period. Try to store ony one write word and one read word in the FPGA. But you can also communicate through one 32-bit wide BlockRAM, where you can use one half of the address space on one port as transmit buffer, the other half of the address space on the other port as receive buffer. The possibilities are endless... Peter Alfke, Xilinx

So in 15 ns he has to send a RAS, wait 2 clocks and then a CAS and a further

2 clocks to get the data.

I know the write may be a bit quicker but you still need a couple of clocks for precharge after write.

Are sure each operation can be done in 15ns. That's a mighty fast SDRAM.

I think I'd use a burst of 4 words to reduce the "setting up" overhead of a random read or write. Otherwise yes I'd use a multiple of 33MHz using on board PLL and alternate reads and writes.

Fred, I agree. I was thinking in terms of external SRAM, where timing is so much easier and faster. If the external RAM has to be SDRAM (does it really, is the required depth so large?), it might make sense to convert the transfer to blocks of data, assembled in a BlockRAM. Then there is the question of allowed latency. Peter Alfke

I don't think I would use the block memories since they're another interface to mess around with. Also if written in Verilog or VHDL it would be a more portable piece of code. It all depends on resources and if the design is close to the limit when there are some spare block RAMs.

The fact there's a FIFO creates more latency than any FPGA design can ever add!

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éphane.

"Peter Alfke" a écrit dans le message de news: snipped-for-privacy@f14g2000cwb.googlegroups.com...

St=E9phane,

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:

hz

nal

and

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" a écrit dans le message de news: snipped-for-privacy@g47g2000cwa.googlegroups.com... Sté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:

Mhz

external

and