Gmail doesn't seem to quote your email correctly. The intending and stuff shows up here, but it's not included in the response. It may be that you're using HTML formatting, which isn't good for a mailing list.
On 8/14/07, Michael Meeuwisse <[EMAIL PROTECTED]> wrote: > > There's some terminology here which I hopefully correctly understand; you > mean with register x_o and y_o, and port the actual output of stage2 to the > next stage? And because I glued the multiplier to those registers I'm adding > this logic *after* the result has been stored in the register? That's right. > input -(a)--> x_o -(b)--> output > I want to connect the multiplier in phase a, not b, but did b anyhow? What > should I change to connect to a? And one of the things I mentioned at the end was "don't do that." Not in this case anyhow. The reason is that (a) is already a fair amount of logic itself. In fact, it's worse than that. (a) is running at 2x the clock rate of the rest of the design. The timing margin is too small. > > Another rule of thumb, particularly for a pipeline, is to have the > logic for a given stage to sit in the stage it belongs to. You put > oga1hq_multiplier in the stage 2 module, but it's really happening in > stage 3. Architecturally, it's just a big chunk of combinatorial > logic on the output of a module, which is something we want to avoid. > > Rule of thumb != law. But I get your point. Rules of etiquette aren't laws of physics, but not following them can get you into trouble. Only once you have the right amount of experience do you understand when violating the rules is safe. For chip design, I follow this rule as much as possible because I just can't keep track of enough of the low-level aspects of the design all at once. I have to break the design down into parts and work on them piece-by-piece, in isolation. Following this rule (among others) results in a significant reduction in cognitive load. Back to the etiquette angle... Your strengths are different from mine. You may be able to do more complex designs where you have located registers at arbitrary points between inputs and outputs. That's fine for you. It's not fine for the next engineer who doesn't necessary do things that way. I mean, the decision to register outputs vs. inputs is completely arbitrary. It's just that at some point, people chose to register outputs, and now we're stuck with it, because registers are available on the outputs of all logic blocks in the FPGAs. > So, what you've done in your design, if I understand it correctly, is > put a combinatorial multiplier in stage 2 connected straight to some > adders you put in stage 3. But there's nothing magical about the > module hierarchy. It's just how we organized it. And the hierarchy > doesn't insert registers; you have to do that yourself. So you're not > actually pipelining anything. You still have one unbroken > combinatorial chain through the multipler and the adders. This would > be no faster than the earlier version. > > My idea was to not have a straight connection, but have registers in > between. I thought I did that after I defined m_o, but apparently not? The multiplier module does not specify a register. It can. We just haven't done that. > An > 'input' or 'output' doesn't linearly map to registers in verilog? No. Nothing magic happens. It just does what you tell it to. > > If you're thinking about inserting something between the "register > file" and the registers on the output of stage 2, don't. The > registers on the output of the file are actually built into the slices > that implement the file, which is part of our efficiency there. You'd > actually be switching from a synchronous RAM to an asynchronous one, > and there's no way we could get that to run at speed. > > So input maps directly on output, no buffer there at all? Odd, I thought > VHDL did that all the time. No. I know VHDL too, and it doesn't instantiate physical registers unless you your behavioral code is triggered by a clock edge. The syntax is a little different from Verilog, but it's the same idea. > But I'm lost here, what do you mean with > "register file"? :) Different level of abstraction. We're designing a CPU. In CPU terminology, there is a "register file," which is a small memory local to the processor. For the chip designers, it's just a small distributed memory block. > > The original suggestion was to have registered multipliers in stage 3 > and then do the adds in stage 4. The output of stage 4 would mux them > all together on the way into write-back. > > How is this different from your earlier rule of thumb? From my perspective, > the mul and add together make up the operation. Wether we spread it out > across stage 2 and 3, or 3 and 4 makes no difference, right? It's a matter of degree. We're intentionally placing combinatorial logic after the register, but that logic is merely multiplexing. The delay through that is very small. A multiplier, on the other hand, has a very non-trivial delay. In other words, the experience says that sometimes we can get away with adding a trivial amount of combinatorial logic between the register and the output. We put it THERE because it makes architectural sense; we really prefer that it were a register, but because of the way the FPGA structures things, it simply cannot be, so we do the next best thing. Note that just because we think it's trivial doesn't mean it can't come back to bite us. We know that we're violating a rule. So, now we go and design the next stage, conveniently forgetting which inputs are registered and which are going through MUXes. This throws off our mental estimate of what kind of delay we're going to get from the registers in stage X to the registers in stage Y. We synthesize it and discover that we're over on our time budget and have to do some rework. It's always an iterative process. -- 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)
