Re: [myhdl-list] essay about integer arithmetic

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

Michael Baxter wrote:

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

What counts is the actually obtained efficiency, not the efficiency that
one think one sees from the code. If you can design at a higher level
(perhaps with less "isomorphism") without loss of efficiency, you
gain.

It think the real issue is that you seem to deny that synthesis can
provide this kind of efficiency. We should be able to resolve this
through experiments.

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

No, the problem *is* with 2001 signed regs. See the example in the essay
when signed and unsigned are mixed and for example, 7 + -2 = -11
instead of 5.

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

I think it's unfair to make such a statement (no matter how good it
sounds) unless you can prove it. So I challenge you to prove that
MyHDL-based designs are systematically less efficient than pure
Verilog designs.

Note that "synthesising" MyHDL always requires conversion to Verilog or VHDL
first. So it may be sufficient to inspect the Verilog output code :-)
Ohterwise, the MyHDL Cookbook may be a good start. I provides examples,
including one from Xilinx ISE, complete with Verilog code after conversion
and Xilinx ISE synthesis results.

Here are my predictions:

* there will be no systematic efficiency difference between MyHDL and pure Verilog
* there may be significant efficiency differences between different synthesis tools
* for some examples, I will be able to design them at a higher level (e.g using
higher level data types) than the Verilog couterpart, wihout loss of efficiency.

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

Both HDLs and programming languages are simulated/executed on a sequential
computer. Therefore, all HDLs need some cleverness to maintain the concurrency
illusion. MyHDL builds this technique into a powerful programming
language, that's all.

> Once the isomorphism between the HDL representation and the underlying
> hardware representation is lost, how can efficiency even be quantified?

By synthesizing and analyzing the result.

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

Didn't get that, sorry.

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

Again: 	MyHDL doesn't impose this *error* on you. You can set the bit
width directly, using slice notation. If that's all you need or want to know, fine.

Aren't we exaggerating a little here? You make it sound as though inferring
a bit width from an interval requires a complicated optimization. In
reality it's trivial of course.

Since I started with HDL-based design in 1990, I always wished I'd have a
generalized concept of VHDL's integer subtypes. So I thought and worked hard
to implement it the way I want. So be sure the "error* is intentional :-)

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
   Python as a hardware description language:
   http://www.myhdl.org