FPGARelated.com
Forums

show-ahead FIFOs

Started by Bertrik Sikken September 20, 2003
Andrew Paule wrote:
> > Hi Philip - > > you're right on all cases - only thing is that you are going to be > either a half or full clock behind. FWFT Fifo's are done with > transparent latches (that's the limiter) - you have to be cautious in > use of them. I've done fifo's using the transparent latch trick that > are out running at >430MHz, in IBM SiGe (Fishkill) - but in an FPGA, > unless you pay attention to how you're routing the thing, you can have a > nightmare (One of the reasons I like Actels) - the true FWFT types have > the flags updated on the rising edge of the incoming clock and have the > synched flops (look at a Cypress or IDT design) done with the same flop > that's used for the empty flag. What you are doing is great for > avoiding problems in designs that are not well followed through, and > should be a design standard. What goes on in the newsgroups is that > some folks out there will take a quick look at things and then try to > implement them without understanding the real problems in post route > timing (especially over temperature).
Unless I am all wet, these are not true FIFOs, but are only RAM blocks with address counters. I am not sure you are correct about the need for transparent latches. I don't see how you would even use a transparent latch in this application to any advantage. I expect the RAM block is simply leaving out the output latch on the read data. The Altera RAMs work in a way that the output data is not available for half a clock cycle after it is written (internal falling edge write strobe perhaps?). This may look like a transparent latch, but it is not. In this case I don't see how you could use a transparent latch on the output and get it to do anything useful. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
If your external clocking is fast enough to allow use of the timing 
delays inherant in the internals of your FGPA, then using a D and 
running the output to a pad will allow you to get a good Tpd as the 
delay - that's really all a transparent does for you in this case - 
gives a one gate + one (or more pad delays).  if you use the supplied 
macromodels, they will do away with any use for this - roll your own 
means just that, no RAM blocks.  There are other architectures out there 
besides Altera and Xilinx, but most of this newsgroup seems to forget 
this.  They all have their uses, and obviously they all have some good 
points to be considered when choosing your architecture.  just like the 
processor people (I still like MIPs and SHARCs), but that's another 
thread entirely.

Andrew

rickman wrote:

>Andrew Paule wrote: > > >>Hi Philip - >> >>you're right on all cases - only thing is that you are going to be >>either a half or full clock behind. FWFT Fifo's are done with >>transparent latches (that's the limiter) - you have to be cautious in >>use of them. I've done fifo's using the transparent latch trick that >>are out running at >430MHz, in IBM SiGe (Fishkill) - but in an FPGA, >>unless you pay attention to how you're routing the thing, you can have a >>nightmare (One of the reasons I like Actels) - the true FWFT types have >>the flags updated on the rising edge of the incoming clock and have the >>synched flops (look at a Cypress or IDT design) done with the same flop >>that's used for the empty flag. What you are doing is great for >>avoiding problems in designs that are not well followed through, and >>should be a design standard. What goes on in the newsgroups is that >>some folks out there will take a quick look at things and then try to >>implement them without understanding the real problems in post route >>timing (especially over temperature). >> >> > >Unless I am all wet, these are not true FIFOs, but are only RAM blocks >with address counters. > >I am not sure you are correct about the need for transparent latches. I >don't see how you would even use a transparent latch in this application >to any advantage. I expect the RAM block is simply leaving out the >output latch on the read data. The Altera RAMs work in a way that the >output data is not available for half a clock cycle after it is written >(internal falling edge write strobe perhaps?). This may look like a >transparent latch, but it is not. In this case I don't see how you >could use a transparent latch on the output and get it to do anything >useful. > > >