For performance reasons, we prefer to avoid combinatorial loops. Combinatorial loops are combinatorial logic chains wherein a signal enters a module, is processed by some logic, and then returned to another module, all without being registered. Many interfaces are simpler with combinatorial loops. For instance, fifos make more sense when there's a FULL signal, and an agent writing to the fifo simply doesn't assert the ENQUEUE signal during that time. Unfortunately, that requires a combinatorial loop in the data source, where it combines the FULL signal with whatever is necessary to determine its desire to write to the queue. We would prefer that both the ENQUEUE signal from the writer and the FULL signal from the fifo be registered. It is possible to do this and get full throughput, but it complicates the interface a bit.
First, have a look at the timing diagram: http://opengraphics.gitk.com/fifo_handshake.gif I'll provide the source to a basic fifo later, but below is the sort of code that is necessary for another agent to use a fifo. To write to a fifo looks something like this: always @(posedge clock) begin if (!enqueue || !fifo_full) begin enqueue <= has_data_to_enqueue; fifo_data_out <= new_data; end end Notice that this logic will assert a write to the fifo, even if the fifo says it's full. When the fifo is ready, it'll take the data. Furthermore, the enqueue signal is not allowed to be deasserted until the fifo_full signal goes away. To read from a fifo looks something like this: always @(posedge clock) begin if (fifo_data_valid) dequeue <= 0; if (want_data) dequeue <= 1; if (fifo_data_valid && want_data) begin my_regsiter <= fifo_data_in; end end The read logic here is tricky, because the fifo won't dequeue when output is not valid, and the reader needs to ensure that the right number of entries gets popped. I have a feeling I didn't get it quite right. BTW, there's nothing that says that this is the best way to do it. I just made it up. If someone has better ideas, please, by all means, present them! Thanks. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
