I've added the extra fifos and a stub for were HQ will go. It works correctly in simulation.
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. (We don't want to have HQ unaware that something can be dequeued from the fifo.) For the most part, this is okay. Code will be written to get the count, then to that many dequeues in an unrolled loop, then do it again. It MIGHT be a little better if the fifo could report the true count, but that would only actually matter if the fifo completely filled well before we started dequeueing. If active enqueueing and dequeueing are going on, free and count can never reach their maximum values due to the natural latency of a fifo that has its ends in different clock domains. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
