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?

Also, when I think about the meaning of a C++ programme, I do so in 
terms of the C++ standard and the language elements, not in terms of 
the implementation. I _know_ that references are implemented as 
pointers all the time, but that's not what's important about them, in 
fact, it doesn't matter one bit how they're implemented (and besides, 
there are no guarantees about that anyway). What's important about 
references is that they can't be assigned, only constructed, that they 
can't be NULL, that they can be invalid, that you use & to declare 
them, and so on.

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?

Lourens

Attachment: pgpTS9aC2nwQ2.pgp
Description: PGP signature

_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to