Re: [myhdl-list] essay about integer arithmetic

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

Michael Baxter wrote:

> Specifying a number of bits does not place an interpretation upon the use of a
> bitfield. A number range does.

> The simple case I pointed out before was microprocessor hardware where the
> bits are interpreted as both signed and unsigned, at the same or different
> times. Take an 8-bit example. If the interval [0, 255] is used to specify some
> byte-oriented function by implication, how will the byte be interpreted when
> the exact same flip-flops are expected to mean an interval of [-128,127] at a
> later time in the same hardware?
>
> IMHO, it's a serious elision error to specify a 1 byte register by
> implication, using a range, when in the course of use the bits comprising the
> byte, the interpretation could necessarily vary from that range. 
> 
> A set range, as a specification syntax or an HDL, appears to imply only one
> possible interpretation. But hardware is regularly used right now with dual
> interpretations, and sometimes more. Another example of multivariate bit-level
> interpretation is for a signum taken over a field of bits. One range does not
> elucidate all possible outcomes of representation.
> 
> I will aver IMHO that this is literally an example of the problem inherent is
> attempting to use strong data typing practices from software unto hardware
> problems. Hardware is different.

Strong typing's answer to mutability of meaning is data type conversion.
Actually I consider this to be an appopriate usage of conversion functions,
in contrast to the ones caused by VHDL's low level approach to arithmetic,
as described in the essay.

I you need to transport bits, use a bit vector. If a part of it should be
interpreted as an interval in some module, convert it to an interval
and do the operation. An so on. Seems to me this makes the purpose
clearer than having to work with naked bits everywhere.

There's actually a user example of this on the MyHDL website,
where a complex number is tranported over a data bus:

http://www.myhdl.org/doku.php/projects:cplx_math


> Now, apparently, I did have a misapprehension reading the essay that inferring
> bit-widths was the ONLY way arithmetic was to be supported in MyHDL ... if
> this is not so, then my bad, and I am sorry for that mistake. If slice
> notation is still available, and you don't need to do any casting to produce
> operands or results, then one possible use of MyHDL includes just ignoring
> number ranges that infer a specific finitude.

I will modify a sentence in the essay to make it absolutely clear that
bit-width support is here to stay. In fact intbv's behavior is quite stable
for a number of years now, including both bit vector support and integer
subtype-like support. I am now just taking some time to describe certain
aspects which some may find useful. I have waited with this (as I expect
it will be controversial) until I could back it up with working silicon.

Thanks for the feedback.

> I will check this in more detail. I never use signed regs, and this generally
> avoids all kinds of problems. So, I need to look further into this, and will
> take your example under advisement. Something does not sound right here, and
> I'm wonder if there's an easy explanation for the phenomena you describe.

It's easy enough: the result is what you get when you apply Verilog's
rules on this. I believe therefore that the rules are flawed. The basic
issue is that when you mix signed and unsigned operands, all operands
are implicitly cast to unsigned, instead of signed as it should be.

>>> (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.
> 
> Actually this is pretty easy. This can be shown with logic designs that cannot
> be inferred from behavioral Verilog, but are still written in Verilog.

It seems to me that your are questioning logic synthesis itself. And indeed,
I can imagine that there are applications where it's not applicable or
efficient. One shouldn't use MyHDL in such cases, its paradigm relies on
efficient synthesis.

What I'm claiming is that *if* synthesis is applicable, there will be
no significant difference between a MyHDL and a Verilog-based design flow.
I'm quite confident that there remain sufficient applications for
which synthesis works very well. I'm also pretty sure that I'll be
able to show you examples for which it actually works better than
what can be expected from a human designer in a reasonable time.

Jan


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