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

[Per K. <bas...@gm...>]

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

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.

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?
I personally don't see how that is possible, 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.

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

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, but it is
really the only way?

Humble greetings in small words
/Per




On Tue, Feb 26, 2013 at 8:45 PM, Jan Decaluwe <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...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>