Re: [myhdl-list] intbv with max != 2**n. Error or annoyance?

[Jan D. <ja...@ja...>]

On 02/26/2013 08:02 PM, Christopher Felton wrote:
> On 2/25/2013 10:23 AM, Jan Decaluwe wrote:
>> Chris:
>>
>> We are overthinking this. Forget about delta cycles,
>> combinatorial logic and race conditions.
>
> Fair enough.
>
>>
>> What we have is a language that hopefully tries to
>> help us to write better, clearer code.
>>
>> A signal assignment is an assignment also (albeit
>> to a future value which may or may not be overwritten.)
>> When a designer specifies explicitly that a variable/signal
>> should *always* be within a range that he specifies,
>> it is a good thing that the language flags a
>> violation immediately. The fact that signals have
>> complex postponed behavior is a secondary issue.
>>
>> What disturbs me a little in this discussion is the
>> Verilog angle. I think it is rather clear that
>> VHDL is my reference for "good design" (and Verilog
>> for "very bad design"). No?
>
> It was inadvertent.  It was not the goal to imply myhdl
> should behave like Verilog.  The oversight was --as you
> identified-- not jumping to the VHDL example using a similar
> type, that is: the constraint integer.

Chris - I was not targetting you in any way. I fully
understand how you try to be helpful and open to
arguments.

I referred to the OP (Mr. Karlsson). Yes, I have a
problem with people who, after looking at MyHDL superficially
from just one angle (Verilog), immediately start
using big words and declarations just because it doesn't
look exactly like what they are used to.

Moreover - because of Verilog's bad design choices
(e.g. not making a difference between signals/variables)
what many Verilog designers are used to as a coding style
is equally bad. Using that as the norm is just too
crazy for words to me.

All of this is of course just my personal opinion - but I
made it abundantly clear on many occasions. Quite obviously,
MyHDL is my attempt to offer a sensible Verilog alternative
to those that share this analysis.

> I am in agreement but I may beat on this topic some more,
> purely so that I have a consistent and concise understanding
> for future communications.

No problem. For example: it is *definitely* a problem when
an "invalid" value sneaks through delta cycle. A signal
monitor has no way to know where it is in delta cycle
convergence process. Therefore, it could take seemingly
"impossible" decisions based on that invalid value.

(I am not talking about hardware here, but about the language
as it may be used in models and test benches. The inclination
to interprete everything in a hardware sense is another
sign of a bad methodology.)

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com