Re: [myhdl-list] essay about integer arithmetic

[Michael B. <ma...@cr...>]

On Fri, 06 Mar 2009 17:49:14 +0100, Jan Decaluwe wrote
> Michael Baxter wrote:
> 
> > There are no data types in hardware!

I should have said: "There are no software-like data types in hardware!"
Verilog does have data types, but they meant to indicate hardware, not
represent variable or structures in computer programs.

> No, but that doesn't this prove that there shoudn't be data types
> in hardware description languages. Even a simple bit-vector
> is an abstraction that "doesn't exist" as such in hardware.
> Isn't this just a matter of what you're used to and what
> you trust?

Not at all. I might have done well to explain this better. A HDL should
provide a clean isomorphism between it's text representation and the
underlying hardware representation, most particularly with clearly denoting
the efficiency aspects of the implementation. Verilog does this now.

> > Bits do what their hardware says to do,
> > and it may be completely unrelated to signedness, or even to values. The rules
> > of Verilog for arithmetic DO make sense: they do what hardware does, and that
> > is good.
> 
> I insist that Verilog's implicit casting of signed's to unsigned's
> in an expression does *not* make sense. The rules could have been
> different, and then they would makes sense in terms of their
> integer interpretation. But they would *still* do "what the hardware
> does": the difference would be sign-bit extension (= routing)
>  instead of zero padding.

I don't have the LRM handy, but I'm pretty sure Verilog-2001 deals with this
by allowing signed reg variables, and these do what you would expect. This is
distinct from the behavior of Verilog-1995, and it's treatment of integer
versus reg. Will try to run some compiles to check this out...

> > That is why software is different than hardware, and it's why HDLs
> > are completely different than computer programming languages.
> 
> Needless to say, one of my goals with MyHDL is to prove that this is 
> false. Seems I'm not succeeding :-)

(With apologies to Alan Perlis...) MyHDL programmers know the value of
everything, but the cost of nothing.

So in this matter, I vigorously disagree. HDLs must be different than computer
programming languages, because hardware is concurrent.

Virtually all computer programming languages lack concurrency; more acutely,
they lack explicit concurrency that is crucial to hardware. MyHDL exploits
some novel features in Python very cleverly, and it's very impressive in that
regard. I would not however describe Python as explicitly concurrent.

This does not mean that high-level approaches are inapplicable to HDLs, IMHO.
The issue is over how, the policies to be employed for representation, etc.

> > Applying computer programming language models (such as data types) to hardware
> > is a very dangerous idea for efficient, high-performance hardware engineering
> > of logic. Programming models don't work the way hardware works.
> 
> Many models don't. But with data types such as integers, booleans, 
> and enums there is no loss of efficiency, only a gain in clarity and 
> productivity.

Once the isomorphism between the HDL representation and the underlying
hardware representation is lost, how can efficiency even be quantified? If you
want to synthesize real hardware, and not merely be a modeling language, then
what the hardware is represented as, it's efficiency, and mutability of
purpose has primacy, in order for the efficiency argument to be true.

> > As a designer, I want complete and total control over the number of bits
> > represented in the (simulated or synthesized) hardware. A program should NOT
> > do that for me, because a computer program is too stupid to understand what I
> > want those bits to do, or to mean.
> 
> In case of integer arithmetic, which is really the sole topic of the 
> essay, that statement is evidently incorrect. The support of VHDL 
> integer subtypes in synthesis tools proves it.

Chuckle. I'll evade that argument by describing VHDL as a computer programming
language, which also happens to have a use for hardware design. Verilog is a
lot closer to real hardware, and as a HDL there the isomorphism between
representation as text and as hardware is much stronger.

But, what I said is still true. Automatically inferring the number of bits
required to represent numbers (integers), instead of allowing the designer to
choose that implementation directly is a serious language design error.

Best,
M

> Jan
> 
> -- 
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>     Python as a hardware description language:
>     http://www.myhdl.org
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San 
> Francisco, CA -OSBC tackles the biggest issue in open source: Open 
> Sourcing the Enterprise -Strategies to boost innovation and cut 
> costs with open source participation -Receive a $600 discount off 
> the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list