On 2006-06-20, Lourens Veen 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?
I think if you leave out a signal which is used in the block, (and the
compiler can not eliminate it,) then the compiler should produce a
warning. Given that, I think it can be a useful verification of the
programmer's expectations.
> It seems that we are talking about generated hardware all the time,
> rather than of the semantics of the Verilog 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. 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?
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.
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. 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.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
