V4 FIFO16 and SRAM

>>My issue is that in my simulations I see the EMPTY go on for two RDCLKs,
>>whereas I have only written one datum into the FIFO16.
>
> That's a reasonably common problem with FIFOs.  There is a
> pipeline delay in deciding to read the FIFO and/or in updating
> the empty flag after you do the read.

Thanks, Hal.  You might be the only one that understood my question.

> You can probably patch your code to ignore the EMPTY flag until
> it has had time to get the right answer.  The disadvantage with
> that is that you can only read at half speed.  (Or slower if your
> pipeline is longer.)

I'm not following you. The EMPTY flag is actually working OK.
It's the extra cycle of geting the RDEN on that I suspect must be
worked on.  So I guess, because you mentioned pipeline, and I've
been thinking that an extra register needs to be added to the data
output, that there is some circuit that will be robust and will handle
one input data burst or multiple-input data burst.  Right now I can't
wrap my head around what that circuit might be.  If you can give me
any clues I would be most appreciative.

Presently, I am working on driving the RDEN with combinatorial
logic, directly from the two EMPTY flags to get it off faster. I
think this should work, since both EMPTY flags are synched to
the same RDCLK.  There seems to be some flickers, though, on
the output.

Brad Smallridge
Ai Vision

Brad Smallridge wrote:
>  so either
> you don't understand what I'm trying to relate, or I don't understand some
> other issue in the FIFO16 EMPTY flag behavior.
>
Brad, I really do not understand what you are doing with the FIFOs.
I was just (poorly) describing the naturally synchronous rising edge of
EMPTY, and its artificially re-synchronized trailing edge. That's all
in the inards of FIFO16.
I know the FIFO16 inside out (and have designed FIFOs over the past 30
years), so I should be able to understand what you do. But I don't.
Send me an e-mail or call me at work, and we can get to the bottom of
it. Then I can also explain in detail what Ray was referring to.
Peter

Thanks Ray,

> The Virtex4 FIFO16 flag logic has a design flaw that renders them 
> unreliable for asynch operation.

I was aware of this issue.  However I thought that I was "safe" since I am 
not using the ALMOSTEMPTY flag, nor should the two FIFO16s ever be in a 
situation where the ALMOSTEMPTY flag would ever be in transition. It should 
always be on. My circuit is fairly straightforward, as soon as the EMPTY 
flag comes on, address information is passed from the FIFO output to the 
SRAM address lines.  There are two FIFOs competing for the address lines 
with one FIFO having priority for the situation when both EMPTY flags come 
on at the same time.  The data is spread out so presently I would never 
expect to see more than one data in either FIFO at any time.

Since the ALMOSTEMPTY flag is always on, I was hoping that it's metastable 
effect on the EMPTY flag was circumvented.  I guess that's a question for 
Xilinx to answer.

> You can, however use it synchronously and cascade it with a small async 
> coregen fifo implemented in the fabric so that the net effect is an async 
> fifo.

And the coregen fifo is OK?

Brad Smallridge
Ai Vision

Brad
If you program the ALMOST EMPTY flag to a high enough offset above
EMPTY, such that ALMOST EMPTY never (never!) gets deactivated, then the
FIFO16 will always operate perfectly, and you can ignore all
work-arounds. Absolutely, no question...

The problem with the ALMOST flags has nothing to do with metastability,
(we understand that pretty well, and would not be fooled by that), but
is caused by simultaneous read and write clock edges. It's a simple
logic error, hidden and covered up in a piece of "hard logic".

Regarding EMPTY, you must understand that it is obviously started by
the read clock, obviously terminated by the write clock, but then
internally re-synchronized to the read clock. That's where the
ambiguities come from.
Peter

Brad Smallridge wrote:
> Thanks Ray,
> 
> 
>>The Virtex4 FIFO16 flag logic has a design flaw that renders them 
>>unreliable for asynch operation.
> 
> 
> I was aware of this issue.  However I thought that I was "safe" since I am 
> not using the ALMOSTEMPTY flag, nor should the two FIFO16s ever be in a 
> situation where the ALMOSTEMPTY flag would ever be in transition. It should 
> always be on. My circuit is fairly straightforward, as soon as the EMPTY 
> flag comes on, address information is passed from the FIFO output to the 
> SRAM address lines.  There are two FIFOs competing for the address lines 
> with one FIFO having priority for the situation when both EMPTY flags come 
> on at the same time.  The data is spread out so presently I would never 
> expect to see more than one data in either FIFO at any time.
> 
> Since the ALMOSTEMPTY flag is always on, I was hoping that it's metastable 
> effect on the EMPTY flag was circumvented.  I guess that's a question for 
> Xilinx to answer.
> 
> 
>>You can, however use it synchronously and cascade it with a small async 
>>coregen fifo implemented in the fabric so that the net effect is an async 
>>fifo.
> 
> 
> And the coregen fifo is OK?
> 
> Brad Smallridge
> Ai Vision
> 
> 
> 

Be careful with that.  I thought I was safe too, but I got tripped up by 
the flag issue.  I never looked at almost empty, but I don't think my 
design should have reached it (I found this problem before Xilinx did).

The coregen fifo is fine.  It is designed by a separate group, and its 
design is mature.

Ray, with all due respect:
Yes, this problem was first found by a couple of customers, and you
were probably the first. But only we at Xilinx know the innards of the
control logic implementation, and I was the one that clearly traced the
problem to the inputs of two internal flip-flops. Having analyzed it, I
can assure you that there is nothing mysterious about the misbehavior.
It happens very rarely, but always for an identifyable logic reason. It
has nothing to do with metastability, it is totally deterministic. The
description may sound convoluted, but the behavior is clear. It has to
do with the ALMOST EMPTY flag potentially getting and staying
inverted. And since ALMOST EMPTY is used as a necessary condition for
decoding EMPTY, the EMPTY flag also gets impacted, if, AND ONLY IF,
there is a simultaneous read/write operation on the second clock tick
AFTER REACHING OR LEAVING THE THRESHOLD OF "ALMOST EMPTY".
That's why the failure occurs so rarely in an asynchronous FIFO use.
If  ALMOST EMPTY stays active,( i.e. if its deactivating threshold is
set high enough to never be reached) there will never ever be an
erroneous EMPTY flag.
We have analyzed this, and then also simulated and tested it, and
provoked it.
I know all the gory details. That's why I gave Brad this strong
assurance that in his design he can 100% rely on the EMPTY flag going
active when it should, and going inactive soon after something has been
written into the FIFO16.
I have had sleepless nights over this. Brad does not have to...
Peter Alfke, from home

Brad Smallridge wrote:
>>         1   2   3
>>         |   |   |
>>       _   _   _   _   _   _   _   _
>>rdclk / \_/ \_/ \_/ \_/ \_/ \_/ \_/
>>     _____         ________________
>>empty      \_______/
>>                ___
>>rden  _________/   \________________
> 
> 
> This diagram is correct except for the fact that if your RDEN logic
> comes from the EMPTY flag, then RDEN will be two pulses long
> as well.  That could be trouble is you only have one datum.

????

If you set for example

 rden <= not empty;

Then empty will only be negated for 1 cycle. If it's not, then you might
be encountering the FIFO16 bug (see Answer Record 22462), but each time
reproducing that bug in the async case is quite unlikely ...



> 
> By the way, how do you set up Outlook Express to give Courier
> fonts? 

I don't ...
Who use Outlook anyway ... ;p



	Sylvain

Peter Alfke wrote:

> Ray, with all due respect:
> Yes, this problem was first found by a couple of customers, and you
> were probably the first. But only we at Xilinx know the innards of the
> control logic implementation, and I was the one that clearly traced the
> problem to the inputs of two internal flip-flops. Having analyzed it, I
> can assure you that there is nothing mysterious about the misbehavior.
> It happens very rarely, but always for an identifyable logic reason. It
> has nothing to do with metastability, it is totally deterministic. The
> description may sound convoluted, but the behavior is clear. It has to
> do with the ALMOST EMPTY flag potentially getting and staying
> inverted. And since ALMOST EMPTY is used as a necessary condition for
> decoding EMPTY, the EMPTY flag also gets impacted, if, AND ONLY IF,
> there is a simultaneous read/write operation on the second clock tick
> AFTER REACHING OR LEAVING THE THRESHOLD OF "ALMOST EMPTY".
> That's why the failure occurs so rarely in an asynchronous FIFO use.
> If  ALMOST EMPTY stays active,( i.e. if its deactivating threshold is
> set high enough to never be reached) there will never ever be an
> erroneous EMPTY flag.
> We have analyzed this, and then also simulated and tested it, and
> provoked it.
> I know all the gory details. That's why I gave Brad this strong
> assurance that in his design he can 100% rely on the EMPTY flag going
> active when it should, and going inactive soon after something has been
> written into the FIFO16.
> I have had sleepless nights over this. Brad does not have to...
> Peter Alfke, from home
> 

Peter,

I didn't go back and revisit the design afterwards.  At the time I was 
debugging this, we didn't know that the issue was with the almost empty 
flag, and since I was not using it I didn't look at it at all. I don't 
think the FIFO should have ever gotten full enough in the design to 
cause the almost empty to change state, but it is possible either it was 
getting filled up more than I thought during the start-up sequence due 
to the test fixture, or that the almost empty depth attribute was still 
  at the default of 4.  Since I didn't have the benefit of Xilinx's 
description of the problem, I didn't know to look at the almost empty 
and didn't consider it at all in the debug effort (my design doesn't use 
it).

Brad, make sure you set the almost empty threshold high enough that you 
will *never* hit it if you use it as Peter suggests.