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

[Christopher L. F. <cf...@uc...>]

On Jun 16, 2008, at 1:35 PM, Jan Decaluwe wrote:

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

I agree about the targeted use case, that most should design with the  
intended functionality.  But it was also indicated that backward  
support (if you can do it in Verilog/VHDL you can do it in MyHDL)  
should be included.

>>> The goal is that MyHDL should make certain things easier, while
>>> keeping other things at least as easy as in Verilog/VHDL.
>>>
>>> I believe that using intbv's can avoid unsigned/signed
>>> confusion often found in VHDL/Verilog for numeric operations.
>>> But of course, hardware designers also have a need to access and
>>> manipulate bit representations. I believe it's possible to make
>>> this as easy as in VHDL/Verilog. But we may not be there yet
>>> completely, as this case shows.

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

Good point, trying to add this "feature"  (Verilog/VHDL hardware type  
support) looks like it would be too kludgy.  At this juncture do you  
suggest the implementation be left as is?  This would be one of the  
cases where it is not pratical to make things as easy as Verilog/ 
VHDL?  Or try to find a more elegant implementation that will first  
not break the constraint integer model and second support bit  
manipulation while maintaining sign?