On Sun, Jun 05, 2005 at 04:40:23PM -0400, Timothy Miller wrote:
> 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.
Sounds like the tradeoff here is minimizing the number of cascaded
gates, so as to meet the setup time before the next clock, so the clock can
run fast, versus using extra clock cycles to execute the handshake.
However, there's that old theorem that says anything that can be implemented
in combinatorial logic can be implemented with 2 gate delays (possibly with
an absurd explosion in transistor count).
I'm still doing my first pass through the Palnitkar Verilog
textbook, so it's far from clear to me whether partitioning a logic function
into two different modules necessarily adds gate delays. At least I'm
starting to understand what you're writing here.
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.
Looks like the sort of thing that only makes sense when both
partners to a handshake are running off the same clock. The FIFO can assert
FIFO_IN_READY whenever it has space to take the next word, and the client
can assert DATA_READY whenever there is valid data on the FIFO input port.
If the FIFO becomes full at the next clock pulse, it de-asserts
FIFO_INPUT_READY. The client can still present the next word and hold
DATA_READY asserted, but it knows that it won't be taken at the following
clock pulse. I'm more used to the goof-proof 4-edge VME bus asynchronous
handshake, but that uses more prop delay in both directions, and isn't
required here.
It would take some scribbling to figure out whether this kind of
handshake causes wait states.
There are a lot of ways to decide the exact meaning of each
handshake signal. Looks like it's possible to set things up so that the
data and the handshake signal can change on the same clock edge without
causing a race condition, so that should result in the highest possible
throughput. What's more of a question is the delay through the FIFO itself,
but that might not be all that important.
> 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)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
