FIFO : Synchronous WRITE, Asynchronous READ ?

Hi

I have problem to implement a FIFO with "Synchronous WRITE,
Asynchronous READ" in Xilinx device.

Since the FIFO size is large (more than 48-deep words), I would like
to use BRAM or Built-in FIFO.

I tried "Synchronous WRITE, Synchronous READ" using dual-ported BRAM
and it seems okay.

Problem is that

Every time we 'read', one cycle delay occurs.
I want to 'immediately read' a data in the location that the "read
address" points to.

I am not finding a way to implement "Asynchronous READ" in BRAM.

If anyone has this experience, please let us know.
Thank you in advance

Pasacco wrote:
> Hi
> 
> I have problem to implement a FIFO with "Synchronous WRITE,
> Asynchronous READ" in Xilinx device.
> 
> Since the FIFO size is large (more than 48-deep words), I would like
> to use BRAM or Built-in FIFO.
> 
> I tried "Synchronous WRITE, Synchronous READ" using dual-ported BRAM
> and it seems okay.
> 
> Problem is that
> 
> Every time we 'read', one cycle delay occurs.
> I want to 'immediately read' a data in the location that the "read
> address" points to.
> 
> I am not finding a way to implement "Asynchronous READ" in BRAM.
> 
> If anyone has this experience, please let us know.
> Thank you in advance

It's a FIFO, not a random read so your life is simpler.  The question is 
whether you need first-word fall-through or not.  Peter Alfke is, of 
course, the expert on the ins and outs of FIFOs but I'll make a quick 
suggestion to address your troubles.

For simpler methods to reach your goals, please specify the family of 
device you're using.

It's also not obvious that the clock is the same on both sides of the 
FIFO.  For the moment I'm assuming it is.  You MUST indicate if it's 
different domains.

One approach is to build your own FIFO controller.  Synchronous FIFOs 
are pretty simple: you have a read pointer, a write pointer, some full 
and empty logic per your tastes, and controls to keep the FIFO from an 
overrun or underrun condition.  The total design is about 5 lines of 
active code in RTL (ignoring all the reset states and structure for this 
discussion).

To get the first word there the moment your read pulse is active, you 
need to "prefetch" the first value.  With a write pointer that puts its 
first word into BRAM location 0, the read has to be pointing to BRAM 
location 0 *before* the read pulse and the BlockRAM must be enabled to 
get that first location out.  You have - without using a read pulse - 
the first word present on your FIFO output.  When the read pulse 
indicates you're taking that word, you advance to the next value and 
"preload" that into your BlockRAM output for your next read pulse.  If 
you have two consecutive reads, the combinatorial read address increase 
that you must code will load the next read value on the next clock.  If 
the value isn't written yet for that new value, the empty must be 
asserted until the write value propagates the value to the read port.

You can affect this same behavior with a wrapper on your existing FIFO 
as well.  The empty flag, external read and internal read need to be 
coordinated to perform a preload of your desired "asynchronous" value to 
the output.  It's not that tough if you look at the logic as a preload.

Is you system so messed up that you need the old value to be present 
until the read pulse is active for the new value?  Still not a problem! 
  The preloaded output would work with an external register for the 
previously read value and the preload value.  When the read pulse is not 
active, the register is selected.  When the read pulse *is* active, the 
BRAM value is selected and the hold register updates at the upcoming 
clock edge.

FIFOs with clocks on both the input and output domains are some of the 
simplest control mechanisms you can deal with.

If you actually need two different clock domains for your input and 
output sides, life is less simple but the external wrapper logic I 
suggested earlier will easily provide you with asynchronous access to 
your next word from a standard synchronous-output FIFO when your read 
pulse asserts.

Think more about how your design needs depart from the FIFO structures 
available to you and consider how you can change the FIFO or change your 
system to make everything happy.  The conversion should be reasonably 
clean if you look at it from the proper perspective.

But if you want more of a turnkey solution, go into more detail on the 
specifics.  Family.  Fall-through.  Clock domains.

- John_H

I use RAMB16_S36_S36 primitive (for the moment) and "common single
clock".
Prefetching is very interesting, though it is hard to understand for
the moment :).
Thank you for info.

Pasacco wrote:
> Hi
> 
> I have problem to implement a FIFO with "Synchronous WRITE,
> Asynchronous READ" in Xilinx device.
> 
> Since the FIFO size is large (more than 48-deep words), I would like
> to use BRAM or Built-in FIFO.
> 
> I tried "Synchronous WRITE, Synchronous READ" using dual-ported BRAM
> and it seems okay.
> 
> Problem is that
> 
> Every time we 'read', one cycle delay occurs.
> I want to 'immediately read' a data in the location that the "read
> address" points to.
> 
> I am not finding a way to implement "Asynchronous READ" in BRAM.
> 
> If anyone has this experience, please let us know.
> Thank you in advance
> 

The BRAMs are synchronous devices; you cannot read them asynchronously. 
So the only solution is some sort of prefetching, as mentioned. The CLB 
RAMs do allow asynchronous reads, and "more than 48-deep words" is not 
terribly large. That means probably 4 CLBs per word bit (depending on 
the device used), so a 16 bit word is 64 CLBs. Not really that many. So 
you might want to consider just using them if you don't want to bother 
with prefetching.

If you use a BlockRAM as a FIFO, you have to accept that any read
operation is synchronous, i.e. the result of a read-clock edge.
First-word-fall-through puts the first word written into a previously
empty FIFO onto the output, synchronously with the read clock, but
irrespective of the read clock enable.
I call it a push operation, as opposed to the pull in normal mode.
Once more than one word is in the FIFO, there is no difference between
the two modes, you can always get a new word on the nect Read clock
tick, if that is what you want.
Peter Alfke, Xilinx


On Jun 2, 11:18 am, Duane Clark <junkm...@junkmail.com> wrote:
> Pasacco wrote:
> > Hi
>
> > I have problem to implement a FIFO with "Synchronous WRITE,
> > Asynchronous READ" in Xilinx device.
>
> > Since the FIFO size is large (more than 48-deep words), I would like
> > to use BRAM or Built-in FIFO.
>
> > I tried "Synchronous WRITE, Synchronous READ" using dual-ported BRAM
> > and it seems okay.
>
> > Problem is that
>
> > Every time we 'read', one cycle delay occurs.
> > I want to 'immediately read' a data in the location that the "read
> > address" points to.
>
> > I am not finding a way to implement "Asynchronous READ" in BRAM.
>
> > If anyone has this experience, please let us know.
> > Thank you in advance
>
> The BRAMs are synchronous devices; you cannot read them asynchronously.
> So the only solution is some sort of prefetching, as mentioned. The CLB
> RAMs do allow asynchronous reads, and "more than 48-deep words" is not
> terribly large. That means probably 4 CLBs per word bit (depending on
> the device used), so a 16 bit word is 64 CLBs. Not really that many. So
> you might want to consider just using them if you don't want to bother
> with prefetching.

"Pasacco" <pasacco@gmail.com> wrote in message 
news:1180790373.677725.6920@q66g2000hsg.googlegroups.com...
>
> I am not finding a way to implement "Asynchronous READ" in BRAM.
>
The bodgers way to do this is to use the falling edge of the clock on the 
read section. Nasty though!
HTH, Syms. 

On Jun 3, 6:20 am, "Symon" <symon_bre...@hotmail.com> wrote:
> "Pasacco" <pasa...@gmail.com> wrote in message
>
> news:1180790373.677725.6920@q66g2000hsg.googlegroups.com...
>
> > I am not finding a way to implement "Asynchronous READ" in BRAM.
>
> The bodgers way to do this is to use the falling edge of the clock on the
> read section. Nasty though!
> HTH, Syms.

If there's clock in the FIFO output domain, just don't see why he
needs Async read ???

Don't let me guess it correct, the reason he wanna do this because
there's no read clock at all.  If that's true, another nasty way to do
this is to generate a "glitch" from any changing in the address bits.
Make sure it meets the BRAM setup time then the glitch can be used as
the read clock

Marlboro wrote:
> On Jun 3, 6:20 am, "Symon" <symon_bre...@hotmail.com> wrote:
>> "Pasacco" <pasa...@gmail.com> wrote in message
>>
>> news:1180790373.677725.6920@q66g2000hsg.googlegroups.com...
>>
>>> I am not finding a way to implement "Asynchronous READ" in BRAM.
>> The bodgers way to do this is to use the falling edge of the clock on the
>> read section. Nasty though!
>> HTH, Syms.
> 
> If there's clock in the FIFO output domain, just don't see why he
> needs Async read ???
> 

By "Async read", he means that he doesn't want to wait one clock after 
applying the read address before getting the data out.

But can the BRAM FIFO be made to work with back-to-back reads?  Since the 
BRAM registers the address, it won't work if you just increment the read 
address pointer when read enable is true - the output data is a clock behind 
the read address pointer, so you need an idle clock cycle between each read.
Barry Brown

"Peter Alfke" <alfke@sbcglobal.net> wrote in message 
news:1180812666.685871.195270@i38g2000prf.googlegroups.com...
> If you use a BlockRAM as a FIFO, you have to accept that any read
> operation is synchronous, i.e. the result of a read-clock edge.
> First-word-fall-through puts the first word written into a previously
> empty FIFO onto the output, synchronously with the read clock, but
> irrespective of the read clock enable.
> I call it a push operation, as opposed to the pull in normal mode.
> Once more than one word is in the FIFO, there is no difference between
> the two modes, you can always get a new word on the nect Read clock
> tick, if that is what you want.
> Peter Alfke, Xilinx
>
>
> On Jun 2, 11:18 am, Duane Clark <junkm...@junkmail.com> wrote:
>> Pasacco wrote:
>> > Hi
>>
>> > I have problem to implement a FIFO with "Synchronous WRITE,
>> > Asynchronous READ" in Xilinx device.
>>
>> > Since the FIFO size is large (more than 48-deep words), I would like
>> > to use BRAM or Built-in FIFO.
>>
>> > I tried "Synchronous WRITE, Synchronous READ" using dual-ported BRAM
>> > and it seems okay.
>>
>> > Problem is that
>>
>> > Every time we 'read', one cycle delay occurs.
>> > I want to 'immediately read' a data in the location that the "read
>> > address" points to.
>>
>> > I am not finding a way to implement "Asynchronous READ" in BRAM.
>>
>> > If anyone has this experience, please let us know.
>> > Thank you in advance
>>
>> The BRAMs are synchronous devices; you cannot read them asynchronously.
>> So the only solution is some sort of prefetching, as mentioned. The CLB
>> RAMs do allow asynchronous reads, and "more than 48-deep words" is not
>> terribly large. That means probably 4 CLBs per word bit (depending on
>> the device used), so a 16 bit word is 64 CLBs. Not really that many. So
>> you might want to consider just using them if you don't want to bother
>> with prefetching.
>
> 

"Barry Brown" <b0_nws2@agilent.com> wrote in message 
news:1180971829.270177@newsreg.cos.agilent.com...
> But can the BRAM FIFO be made to work with back-to-back reads?  Since the 
> BRAM registers the address, it won't work if you just increment the read 
> address pointer when read enable is true - the output data is a clock 
> behind the read address pointer, so you need an idle clock cycle between 
> each read.
> Barry Brown

If the read address changes combinatorially with the read enable, the clock 
edge will provide the data for the next address in the back-to-back reads 
for the BlockRAM.  No problem.