On 14 Aug 2007, at 21:35, Timothy Normand Miller wrote:
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.
I'm actually using Apple Mail. Switched to plain text, hopefully that
solves it.
On 8/14/07, Michael Meeuwisse <[EMAIL PROTECTED]> wrote:
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.
Ok. I just thought that verilog was indentation-sensitive and only
x_lookup_r and y_lookup_r where running at 2x clock. The "Compute x,
y and v" part seemed like direct wiring unrelated to any clock at
all. Anyway, not all of stage 2 is running at 2x clock is it? The
reason I did this was because it looked like the logic to get x_o and
y_o didn't seem like much.
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.
Ok, but the only reason I split it in two was because it seemed to
big for one stage. My only rebellion here was that "we want to avoid"
sounded more like a personal opinion. :)
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.
I blaim that then. I don't see why the wire x_o etc assignments
aren't in such a 'always' block.
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.
I understand what you're going for here, but I'm unable to keep them
apart in verilog. I don't see which parts are before the register,
and which parts are after. It's all a bunch of assigments to me.
Mike
www.wacco.mveas.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)
