On 6/20/06, Lourens Veen <[EMAIL PROTECTED]> wrote:
On Tuesday 20 June 2006 00:37, Timothy Miller wrote:
> On 6/17/06, Petter Urkedal <[EMAIL PROTECTED]> wrote:
> > I think I read that is
> > an error to intentionally leave out variables from the sensitivity
> > list to condition the whole behavioural block to execute only when
> > some of the values are changed. This makes sense, of course.
>
> Yeah. In a real chip, it's sensitive to everything that's an input.
> Leaving someting out will make simulation behavior deviate from
> synthesis behavior.
You've mentioned this before a few times, and it confuses me. Isn't the
point of a simulation that it simulates the actual thing? Then why are
we thinking differently about a simulated chip than an actual one? What
are the differences, and what causes them?
RTL (HDL) is an abstraction. The synthesizer has to do a lot of work
to turn a language designed for simulation into something suitable for
a chip. When you do RTL-level simulation, you're not simulating the
chip. You're simulating the high-level algorithm. So in order to get
a logical match between synthesis and simulation, you need to specify
your sensitivity lists correctly. VHDL has its own goofinesses when
it comes to this.
On the other hand, if you were to do a gate-level simulation, you
_would_ be simulating the actual chip (at least a lot closer to the
hardware). But you can't do gate-level simulation until the
high-level RTL has been through synthesis.
It seems that we are talking about generated hardware all the time,
rather than of the semantics of the Verilog language.
We're talking about both, but mostly we're talking about generating
hardware. There are LOTS of things that you can express in Verilog
that you can simulate but not synthesize into logic. Verilog is just
a high-level language.
That is akin to
writing about the semantics of a C++ programme by what kind of assembly
it compiles to. It just doesn't make much sense to me.
If you write crap C++, you'll get crap assembly. The difference here
is that C++ isn't so massively far removed from the language it's
compiled to. C++ is an object paradigm wrapped around procedural code
that is converted to machine code that is essentially procedural.
It's all sequential.
Verilog is basically a behavioral language that gets simulated
sequentially but which gets converted to parallel logic gates in
hardware.
So we're not talking about Verilog here and just assuming the magic
synthesizer will "do the right thing." We're talking about hardware
and the techniques you have to employ in order to express that
hardware in Verilog.
I did the following once, and it was stupid. Imagine what the code
will synthesize to:
wire [0:255] a;
wire [7:0] ix;
wire in;
reg [0:255] b;
always @(a or ix or in) begin
b = a;
b[ix] = in;
end
Looks simple enough, but it baloons out into massive amounts of logic,
and not just because it's 256 bits wide.
Not thinking in terms of hardware is why the Xilinx chips in Cray
computers go unused. If generating hardware from totally arbitrary
Verilog were simple, then people would already have good translators
from C or Fortran for their supercomputing applications. Even with
something like SystemC (which admittedly, I've never looked at, but I
assume it's a lot like C), you're not going to be able to think like a
software coder.
A reg is
something that can be assigned to (an lvalue, in C++) and a wire is
something that you can only read from (rvalue, in C++). Period! Who
cares whether a register gets synthesised? As long as it does what it's
supposed to do according to the Verilog semantics, it doesn't matter
much, does it?
No, the Verilog semantics are merely an "annoyance" that you have to
work around to get the hardware you're trying to design. See, we're
not just trying to design hardware here; we're trying to design
EFFICIENT hardware, which requires that you think about what you're
designing in terms of hardware. I don't mean that you have to
mentally break adders down into XOR and AND gates. I mean that you
have to understand that adder A is not the same piece of logic as
adder B, so they reside in different places on the chip, they operate
in parallel, they may have different bit widths, etc. The same is
true for any HDL; they have different semantics from Verilog, but what
really matters is what hardware comes out.
Thinking about the specific semantics of Verilog and not worrying
about what it translates to is thinking MUCH too much like a software
programmer. Verilog isn't a programming language; it's a hardware
DESCRIPTION language. If you _program_ in Verilog, you're going to
get something that doesn't synthesize or synthesizes badly. But I
should say that having an intutive sense for what assembly your C++
code gets converted to can significantly improve the efficiency of
your code. It's just that the situation is WAY worse with Verilog.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
