[Open-graphics] Challenges with async fifo designs holding up OGD1

Timothy Normand Miller theosib at gmail.com
Tue Feb 13 16:41:16 EST 2007


On 2/13/07, James Richard Tyrer <tyrerj at acm.org> wrote:

> 512 words seems like a lot.  Is there a reason we need this much?

This is the the number of words in a block RAM at 36 bits wide.  Might
as well make them all available.

> IAC, a real FIFO buffer is always the fastest as far as transfer rate is
> concerned.  The problem with using a real FIFO that long would be a
> latency of 512 clocks.

Unfortunately, that doesn't map well to a block RAM.

> You can shorten the latency of a real FIFO by using multiple shift
> registers in parallel.  E.G. using 4 @ 128 each.  They can be striped or
> used in sequence.  This is still a latency of 128 clocks which might not
> be acceptable if they were empty.  You can keep using more smaller shift
> registers till you get to 512 @ 1 each which means just registers/memory
> and there is no difference between striped and sequence.
>
> This might work.
>
> A real FIFO uses an extra bit which is set when data is written and
> cleared when it is read.  Perhaps this would work with memory based
> FIFO.  If you has a "dirty" bit, then you wouldn't need to compare
> addresses to determine if the FIFO was empty.  If the memory location at
> the tail pointer had the dirty bit set, then it would read out that
> memory location, clear the dirty bit and increment the counter.  The
> head pointer would avoid overrun by not writing to a memory location
> till the dirty bit was clear.

We thought about that.  The writer sets the bit, and the reader clears
it.  But that would require a 3-port block RAM, which we don't have.

> In theory, the above will work if at reset all dirty bits are cleared
> and the head and tail pointer are both set to the same value (normally
> 0).  There is an issue of what would happen if this manages to get out
> of sync due to a stray cosmic ray which might need to be addressed.  If
> the FIFO empties this is simple  Wen all dirty bits are reset then the
> two counters are reset to 0.

That's the problem I'm running into.  At power-on, the RAM is all
zero, so that's great.  But if you want to reset the FIFO at a random
point, you're kinda hosed.  It would take 512 cycles to clear it, and
the extra logic would ruin our prop delay.

-- 
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Favorite book:  The Design of Everyday Things, Donald A. Norman, ISBN
0-465-06710-7


More information about the Open-graphics mailing list