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

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

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

Below is the output example for a small change that I made to the bit  
vector class
 >>> from myhdl import *
 >>> x = intbv(0, min=-8, max=8)
 >>> x[3] = 1
 >>> x
intbv(-8L)
 >>> x[3] = 0
 >>> x
intbv(0L)

To implement the above I simply modified __setitems__ and used the  
_min and _nrbits values determine what type of number is being  
represented.  If the number is signed multiply the value by -1 if the  
msb is being modified.  There is probably a more elegant way to  
implement this but I think this approach will meet the requirements  
that have been discussed, which are

1.  Support high level modeling
2.  Support low level hardware modeling while maintaining high level  
representation
3.  Synthesizable

I believe the above approach (or one similar) will meet all the above  
requirements and put the work in the intbv class (good or bad?).

My 2 cents.




On Jun 11, 2008, at 2:52 PM, Günter Dannoritzer wrote:

> Jan Decaluwe wrote:
> ...
>> I'm now thinking aloud for the case you describe, sign-extension.
>>
>> The ideal solution might be if we could somehow give an addional
>> parameter to slicing, e.g. asking for "signed" slicing instead
>> of the default, unsigned. But I don't see how.
>
> We actually do that in the DeFixedInt class
>
>  http://www.dilloneng.com/documents/downloads/demodel/
>
> Similar to intbv for an instance of that class a bit width can be
> specified. The msb based on the specified width is considered the sign
> bit. The decision is made whether the msb is included in the slice or
> not. To quote from the doc string of the __getitem__ function:
>
>     When the slice includes the sign bit it is taken over to the  
> return
>     value. If the sign bit is excluded the bits are taken as is with  
> the
>     sign bit set to 0.
>
>     For example using the 4-bit number -6 = b1010, slicing bits 3:1  
> -->
>     b101 includes the sign bit, the result is -3.
>
>     Now using the 4-bit number -3 = b1101, slicing bits 2:1 --> b10,
>     however, the slice excludes the sign bit, hence the result is 2.
>
>
> However, for the case of intbv I would not focus on where the bits  
> come
> from, but rather where they should go to. So if the destination is
> supposed to be signed, then don't worry about where the bits come  
> from.
> With a slice there is a fixed number of bits and depending on how this
> slice gets assigned to the destination should make the decision about
> the sign of the destination. So let's say the destination is a signed
> intbv with _nrbits set and the slice gets assigned to it. If that  
> slice
> matches _nrbits and in the slice the msb is set, that should turn the
> value into a negative value.
>
>>
>> Another interesting way might be to introduce methods to intbv's
>> at this point. We could do this like for python strings: the
>> methods don't modify the object in-place, but instead return a
>> new object with the modified value. (In MyHDL tradition,
>> those intbv methods would return integers.) The advantage
>> of this approach (as opposed to creating new functions)
>> is that adding new methods doesn't pollute the myhdl
>> namespace further.
>
> In a way the sign extension could be done through the __setitem__
> function. Basically the _min, _max attributes decide about how the  
> value
>  assigned is interpreted. If _min=0 the intbv instance is seen as
> unsigned. If _min = -_max the intbv instance is seen as signed and the
> assigned value is interpreted as signed with _nrbits specifying the  
> msb
> and if that bit in the assigned value is set, the value is considered
> negative.
>
> That would allow to assign bit slices that come actually from unsigned
> values and convert to a signed value.
>
> I am probably overlooking something, but maybe some ideas are a  
> starting
> point?
>
> Guenter
>
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list