[Open-graphics] HQ stub in place

[Petter Urkedal]

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).