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

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

On 02/26/2013 10:52 PM, Per Karlsson wrote:
> Hi guys! I'm just back from vacation. It seems to me that Jan and I
> should both try to keep a little cooler than we are used to when
> we're in the same discussion. I remember no "big" words from my
> keyboard, but I shall try to keep them smaller still. :D

I don't like it if something which is clearly a feature is
described as either an error or an annoyance. And I certainly
don't like it if such an analysis is based on the
"think hardware" conventional wisdom, which is my enemy in
HDL design and which is why I am actually developing MyHDL.

> So, first a little background: Yes, guilty as charged, I am mostly a
> Verilog person. I've spent only a few years with VHDL, and the rest
> of the time with Verilog. Therefore I am quite biased.
>
> I think VHDL is chatty, and for me it's harder to think about
> hardware in VHDL than in Verilog; and I always think about hardware
> when I design RTL. For me RTL is not programming, it is a way to
> describe hardware.

I am tired of such statements. Invariably, they are used as an excuse
for not learning the language in its full expressiveness, and for
ignoring the valuable lessons from software engineering.

> That said I'm very happy that I found MyHdl, because it allows me to
> write hardware in the leaf-cells, but I can use actual programming to
> build up the system from the basic blocks and in the testbenches.
>
> Normally I would either build Verilog from strings in Perl, or riddle
> my Verilog with code-words and then run it through a Perl
> pre-processor (depending on the needs of a particular design). MyHdl
> allows me to stay in the same language and use Verilog as a netlist
> format. I'm quite pleased with the design and test environments I
> have set up using MyHdl, and they are going to get really nice when
> MEP108 is implemented!
>
> Now, on topic: So, Jan, you are saying that we should never write
> hardware where a combinatorial calculation takes more than one delta
> cycle?

No I don't say that. I don't like words like "never" or "always" -
delta cycles have their role.

What I am saying is that the systematic usage of delta cycles and
events as an implicit way to order a sequence of calculations is
a bad idea, given that the language has many provisions to do
so directly, explicitly and locally, without events and delta cycles.

I personally don't see how that is possible,

Really? Well, my designs typically use close to 0 delta cycles. I may use
some combinatorial logic to condition some inputs/outputs, but
that's basically it. Everything is basically done in clocked processes.
BTW - that's much closer to the original meaning of RTL -
Register Transfer Level. True RTL languages don't have events,
delta cycles, or explicit combinatorioal logic.

> but I have some
> respect for the amount of thinking that you have done in this area so
> I am open to the possibility that you will convince me otherwise.

I am not trying to "convince" anyone - everything is provided
for free here so one should convince oneself, or not.

All I'm doing is pointing out misunderstandings and managing
(possibly false) expectations for efficiency reasons. Noone
should lose time unnecessarily.

> It may be my hardware background fooling me (I started out as a
> rectangle pusher), but for me glitches in combinatorial nets are near
> unavoidable.

Of course not.

> You can of course balance all the paths to make the
> logic glitch-free, but its hardly worth the hassle unless you are
> designing clock gating or a reset signal.
>
> This is not to say, of course, that the language has to mimic the
> ripple behavior of physical hardware to be of any use.

That is the point. In synchronous design, that ripple behavior
is irrelevant.

> But still,
> when sub-blocks or IPs have combinatorial inputs and outputs, or when
> there is a combinatorial path through a block I don't see how it is
> avoidable.

All IP blocks should have registered outputs. This is just a matter
of complexity management: localization of concerns.

> You shouldn't take my rant about partitioning design too seriously, I
> usually go a bit overboard when I try to prove a point. Certainly a
> single process is best in a self-contained system with few
> dependencies

Dependencies are not a given, but something that you can
manage and that should be minimized when partitioning a design.

but it is really the only way?

No. It's only the way I prefer.

>
> On Tue, Feb 26, 2013 at 8:45 PM, Jan Decaluwe <ja...@ja...
> <mailto:ja...@ja...>> wrote:
>
> 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
>
>
> ------------------------------------------------------------------------------
>
>
Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics Download AppDynamics Lite
> for free today: http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________ myhdl-list mailing
> list myh...@li...
> <mailto:myh...@li...>
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
>
>
> ------------------------------------------------------------------------------
>
>
Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics Download AppDynamics Lite
> for free today: http://p.sf.net/sfu/appdyn_d2d_feb
>
>
>
> _______________________________________________ myhdl-list mailing
> list myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>


-- 
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