On 6/20/06, Petter Urkedal <[EMAIL PROTECTED]> wrote:
I really want to understand how the code translate into gates, because
this makes it possible to understand
* How many gates (at least order of magnitude) will be generated. We
have limited space.
* What is the longest chain of gates from any register output to a
register input. I believe that will roughly determine the maximum
clock rate.
These are probably the top two factors that you should consider when
designing something.
After you've been coding Verilog for a while, the right side of your
brain will get an intuitive feel for how logic/arithmetic, pipelining,
etc. translate into area and speed.
[I have reason to doubt the strict right/left brain division people
seem to talk about, but it makes a good metaphor.]
In other words I want to know how to make efficient code. If I do
numerical coding, I may also want to know a bit about how C code is
turned into assembler.
When learning C++, I read lots of books that suggest passing lots of
parameters as const references. Some C++ programmers, I guess, see
this as a rule of thumb or convention. I see it as a way to pass an
object without copying it and give the compiler a chance to optimize
with the assumption that the object won't change during the execution
of the given method. I think about references being implemented
internally as pointers, and I imagine the optimizations the compiler
will perform.
Of course, when dealing with things like STL, I have to kinda let go
of the whole efficiency thing. I mean, I'm sure they're well written,
but the memory management behind them has GOT to be massive. This is
the point where we optimize engineering time rather than code
execution speed or size. And when you're writing large C++ apps, you
have to do this, and that's when you fall back on counting on the
high-level semantics and stop thinking about anything lower than that.
You have to make tradeoffs.
Hardware, though, is expensive. The chip designer tries to put as
little as possible into the hardware. As a practical issue, we're
dealing with designs small enough that we can think about low-level
issues, and to make it cost-effective, we have to.
Agreed, most programming tasks don't require any
low-level knowledge. However, I think in this case, we should know a
bit about the "do" and "don't"s of efficient HDL. I already read some
Verilog tutorial, so I apologise if I'm skipping ahead.
Good students read ahead. :)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
