Re: [myhdl-list] another intbv question

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

Neal Becker wrote:
> I noticed that
> 
> x = intbv (5, -16, 15)
> 
> print x._min
>> -16
> 
> print (x >> 1)._min
> None
> 
> This is surprising.  I would have expected that arithmetic operations on 
> intbv would result in an intbv with the same #bits.
> 
> I have implemented a fixed pt arithmetic class in c++ (based on 
> boost::constrained_value).  What I did there is all operations result in the 
> same # bits.  If you want something different, first convert operands to the 
> desired result size.  For example, multiplying 2 8-bit values will give an 
> 8-bit result.  If you wanted a 16-bit result, first convert the inputs to the 
> wider field.
> 
> Others have argued that these conversions should be automatic (e.g., 8 x 8 -
>> 16), but I prefer explicit.
> 
> In any case, I think the intbv behavior is surprising.  Is this really 
> desirable?

In my opinion it is. I don't see the benefit of having to deal
with bit widths myself if a tool can do so (better).

intbv *is* explicit, but not at the bit width level, but at the
level of value constraints. This is inspired by VHDL's integer subtypes.

Arithmetic operations on intbv return integers, the idea is that the
range of a result is checked at the moment when it is assigned to
an existing intbv using slice assignment.

Jan

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