On 11/11/05, Viktor Pracht <[EMAIL PROTECTED]> wrote: > Am Donnerstag, den 10.11.2005, 17:20 -0500 schrieb Timothy Miller: > > > But there's another problem. In order for the fifo to hold 16 entries > > (using 16-entry memory blocks), I needed to use a 5-bit counter. The > > upper bit serves as a "wrap" flag. If both the head and tail are the > > same value, is the fifo empty or full? Having the high bits of head > > and tail differ serves to indicate that the tail pointer (where stuff > > goes in) has "lapped" the head pointer (where stuff comes out). > > The 5th bit (only one, shared by both counters) can be set by every > write and reset by every read. If it's set, then the FIFO can't be > empty, and a read is allowed even if the pointers are equal. If it's > reset, the FIFO can't be full and a write is allowed even if the > pointers are equal.
How do you set and reset it like that from two different clock domains? I suppose we could have two bits and look at their XOR. > > The remaining question is (at least for me), what do we do to prevent > the 5th bit and the rest of the counters from changing their outputs > before the data can be read from RAM? (This applies even to the > 15-entry-FIFO when it's empty and a read comes too soon after a write, > so it's probably already solved, but I'm too lazy to search the list > archives now.) If a read comes "too soon", the read side will not have sensed the change in the tail pointer and will therefore report that the fifo is empty. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
