I am using coregen to generate FIFOs for my design and get typically 77LUTs and 38Registers for a 1 BLOCK RAM FIFO. Seems like a lot. I remember using Cypress parts and all the addressing and such for a FIFO was already pretty much incorporated into the Channel RAM, no logic was used outside the Channel RAM to do the basic RAM functions including FIFO. Am I doing Xilinx right? Is there some primitive I should be using instead?
In the new Virtex-4 devices, we incorporate a FIFO controller in every BlockRAM,so the controller is free, and it can handle asynchronous clocks at up to 500 MHz.
The high logic count for the controller that you quoted may be due to elaborate design tricks to cope with fast asynchronous clocks, and the need to generate a reliable EMPTY and FULL signal, even at very high speed. And perhaps also a partial FULL/EMPTY output. That requires duplicated Binary and Gray counters with sophisticated comparators and special precautions against metastability problems (All of which we did in the hidden controller in Virtex-4). If you are not running so fast, some of this can be eliminated in your Virtex-II or Spartan design, but you have to be careful. Asynchronous clocks can bite you, unless you really know what you are doing... Peter Alfke
No, as far as I know I picked the Synchronous option. And there seems to be no way to elliminate the Empty and Full flag outputs, which I don't think I will be using, left them open in the instantiation. There also is no relative placing of the support counters, either with respect to each other or close to the RAM block. Nice to know that the Virtex has some of this stuff built in.
Brad, if your FIFO uses one common clock for write and read, and you really do not care about FULL or EMPTY (because your system design takes care of or avoids that situation), then just ignore the core generator and simply hook two counters to the two address ports, and declare one port the write input side, and the other one the read output side. That means you need one slice per two address bits, and totally exactly as many slices as your addressing is wide, i.e. 16 max.
Most of the complexity (and trouble and frustration...) of a FIFO design is due to the asynchronous nature of the two clocks, while reliable EMPTY/FULL signals must be decoded. Peter Alfke
That's unfortunately true. Came too late for me to catch... The user should select the almost FULL output instead. FULL is not as critical a signal as EMPTY. A well-designed FIFO system should never go FULL, and the exact "full-ness" level is not so important. Hardly anybody cares whether the FIFO can hold 1024, 1023 or
1020 entries. But the user often really wants to empty the FIFO content completely. That's why reliable EMPTY decoding is more important than exact FULL decoding. Nevertheless, it's a cosmetic flaw that will be fixed next time around. Peter Alfke (FIFO is my middle name)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.