On 6/5/05, Jack Carroll <[EMAIL PROTECTED]> wrote: > 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).
There's the theory that you can do that, but you can't really do that with real logic, due to fan-in limits. > 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. It doesn't add gate delays, although it may add wire delays, which are usually worse than gate delays. It just depends on how the logic is placed and routed. Really, the module boundaries don't matter so much. One just needs to follow certain conventions so that things hook up well. For instance, if you always register your outputs, then you won't end up connecting combinatorial outputs of one block to combinatorial inputs to another block, potentially doubling your setup time. > > 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. Yes, of course. We'll have fifos that cross clock domains. In fact, that's pretty much the primary way to get data across clock domains. But the first fifos I'll show you are just simple 16-entry units. > 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. This isn't a BUS. It's a hard-wired, dedicated connection between two fixed pieces of logic. The point isn't to develop some complicated bus protocol but to develop a convention that is applied to different pieces of logic and to reusable pieces of logic so that different blocks can be developed independently and then hook together correctly. It's merely an engineering practice intended to save work and reduce errors. > It would take some scribbling to figure out whether this kind of > handshake causes wait states. Which handshake? The one I describe doesn't insert any of its own accord, but it allows them to be inserted when necessary. > 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. That's what synchronizing clocks are for. :) > What's more of a question is the delay through the FIFO itself, > but that might not be all that important. The fifo will result in some latency. There's always a tradeoff between throughput and latency. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
