Re: [myhdl-list] Slicing an unsigned intbv to a signed one

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

Christopher L. Felton wrote:
> We had a similar issue/discussion with the invert (not) function of the 
> intbv class.  There seems to be a couple different specific use cases of 
> the intbv.
> 
> 1. Generic bit container, this is then MyHDL intbv when there is no min, 
> no max value.  This is similar to the Verilog bit vector (reg [], wire 
> []) or VHDLs std_logic_vector.
> 
> 2. Unsigned number, this is the MyHDL min=0, similar to the Verilog bit 
> vector, and VHDL unsigned()
> 
> 3. Signed numbers, this is the MyHDL min is < 0,  similar to the Verilog 
> signed (reg or wire, Verilog 2001 and later) and VHDL signed()

The use case that I really want to push with the intbv is that of
the VHDL constrained integer type. My goal is that designers forget
about signed/unsigned for numeric operations.

For example, when you need a counter that has to count from -1 to 5,
I hope that people will construct it as
     intbv(0, min=-1, max=6)
and not as
     intbv(0, min=-8, max=8)

Why? Because I believe such constraints give you the best assertions that
you'll ever have. My counters usually don't count between powers of 2, but
in my code I systematically make bound errors. The first construction gives
you instant run-time feedback about the error, the second may not.

> The current implementation seems have all the properties that Jan 
> discussed, high level approach while maintaining the low-level hardware 
> access for cases 1 and 2.  For case 3 there are the issues that Günter 
> pointed out, you can't modify the msb and maintain the state of the 
> signed number (or pass the bound checks). 
> 
> Could we do something similar as the invert solution (not) and use the 
> knowledge of the type of number being represented and modify the bits 
> accordingly?

Certainly, but I think the question really is how. The invert problem
was solved by defining what the operator should return depending on
the nature of the operand. We could do a similar thing here using
a method that would do sign-extension. Given the "same" bit pattern,
the result would be different for an "unsigned" versus a "signed".

The proposals I'm seeing do something else: they change the value of
the operand based on the nature of the assignment target. That is much
more tricky and implicit. For example, consider:

     a = intbv(0, min=-8, max=8)

Suppose we do sign extension based on the "sign" bit, then after

     a[:] = 15    # '1111'

a's value would be -1. And after:

     a[:] = 31    # '11111'

it would also be -1. Yet with:

     a[:] = 23    # '10111'

you would get a bound check error. Mm, I don't like it.

Of course, you could make things more sophisticated by only doing
sign-extension if the bit width of rhs and lhs are equal. But this
is getting a little too tricky for my taste.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com