On 2008-07-29, Timothy Normand Miller wrote:
> There's some weirdness we're going to have to deal with. The async
> fifos didn't used to have a used-entry count output. I added a new
> fifo type to the fifos directory that is a modification of
> async_fifo_16, but with a count output. Even though the fifo could
> hold 16 entries, the count output is only 4 bits. It can also report
> valid output, empty, and zero count at the same time. That's because
> the output gets dequeued into a register. What I did, as a hack
> internally, was logically OR the "next" valid signal with the low bit
> of the "next" count. This makes the count either zero or odd and
> potentially an underestimate while guaranteeing a non-zero count if
> there is something that can be dequeued. [...]
If I understand correctly, the correct count is the internal FIFO count
plus valid_out (or !is_empty, if it's registered), but we don't want to
waste gates and timing on the increment. How about ORing 32{!valid_out}
into the MEM_READQ_AVAIL port and document the fact? Then, -1 means
empty and n ≥ 0 means there are (n + 1) entries in the queue. This can
be dealt with in code by replacing tests for zero (jzero) with test for
negativity (jneg).
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
