myhdl-list

[myhdl-list] intbv.signed()

[Günter D. <dan...@we...>]

Hi,

I was gonna try out implementing the signed() function to intbv.

My first question is whether it should be a function or a property? What
would be the decision about what to take. For example with the min and
max values they are implemented as property. As there are no parameters
needed, could the signed by also implemented as property?

My next question is what signed() will return. Just the value as integer
or will it be an intbv instance with the range set based on the _nrbits,
but as +/- range?

So for example if I do this:

a = intbv(0)[8:]
a[:] = 0x19

b = a[4:].signed()

The slice by itself will return a new intbv with min=0, max=16, 
_nrbits=4. From that I would think that the .signed() would change the 
range to min=-4, max=4.

 From the above example, the slice would return the value 0x9, which the 
signed() would converted to -7.

Am I considering that right?

Cheers,

Guenter

Re: [myhdl-list] intbv.signed()

[Günter D. <dan...@we...>]

Günter Dannoritzer wrote:

> 
> The slice by itself will return a new intbv with min=0, max=16, 
> _nrbits=4. From that I would think that the .signed() would change the 
> range to min=-4, max=4.

Just a quick correction, that should be min=-8, max=8.

Re: [myhdl-list] intbv.signed()

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

Günter Dannoritzer wrote:
> Hi,
> 
> I was gonna try out implementing the signed() function to intbv.
> 
> My first question is whether it should be a function or a property? What
> would be the decision about what to take. For example with the min and
> max values they are implemented as property. As there are no parameters
> needed, could the signed by also implemented as property?

To me, a property contains some static info about an existing object (even when
it is implemented as a method behind the curtains), while a method returns
some new object. So, it should be a method. The brackets indicate that
"something is being done".

> My next question is what signed() will return. Just the value as integer
> or will it be an intbv instance with the range set based on the _nrbits,
> but as +/- range?

I would go for an integer to start with. That is what MyHDL does now for
many operators. It is more efficient than constructing intbv's (although
I dont' know how much more) and seems sufficient in many cases. Note that
when we write:

a[:] = <some expression>

the range checking problem is transfered to the left-hand side.

Some other (more bit-oriented) operators return an unconstrained intbv
and we could do this also if there's a good reason. But I would
avoid trying to infer ranges.

Jan

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

Re: [myhdl-list] intbv.signed()

[Günter D. <dan...@we...>]

Jan Decaluwe wrote:
...
> 
> I would go for an integer to start with. That is what MyHDL does now for
> many operators. It is more efficient than constructing intbv's (although
> I dont' know how much more) and seems sufficient in many cases.

I was thinking about the processing of the signed() function and
basically need to do a categorization when the value of an intbv
instance is considered unsigned. In that case the the signed() function 
will change the value based on the msb bit, which is considered the sign 
bit. In the other case the value is considered signed and the function 
will return it just as is.

When considering intbv instances there are several combinations of
min/max values possible. The following diagram shows them:


     ----+----+----+----+----+----+----+----
        -3   -2   -1    0    1    2    3

1                     min  max
2                          min  max
3                min       max
4                min            max
5           min            max
6           min       max
7           min  max
8   neither min nor max is set
9   only max is set
10  only min is set


The horizontal line shows a number range from -3 to 3. Then each line 
shows different cases of min/max values of an intbv instance.

As an example, in the first case min=0 and max > 0. The second case min 
 > 0 and max > min, etc.

 From all those cases I think only two cases, namely 1 and 2, are where
the value is considered unsigned and the signed() function will return a
modified value.

In all other cases either there is no range specified or the min value
is < 0, which makes that intbv instance already considered signed and
the signed() function will just return the value as is.

So the test will be for min >= 0 and _nrbits > 0. That case will 
classify the intbv instance as unsigned and the signed() function will 
return the value as signed, with the sign being determined based on the 
msb. The msb is bit # _nrbits-1.

Note that case #10 (only min is set) could fulfill the requirement min 
 >=0, but as no max is set, _nrbits is 0 and hence the second test will 
not be True.

Guenter

Re: [myhdl-list] intbv.signed()

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

Günter Dannoritzer wrote:
> Jan Decaluwe wrote:
> ...
>> I would go for an integer to start with. That is what MyHDL does now for
>> many operators. It is more efficient than constructing intbv's (although
>> I dont' know how much more) and seems sufficient in many cases.
> 
> I was thinking about the processing of the signed() function and
> basically need to do a categorization when the value of an intbv
> instance is considered unsigned. In that case the the signed() function 
> will change the value based on the msb bit, which is considered the sign 
> bit. In the other case the value is considered signed and the function 
> will return it just as is.
> 
> When considering intbv instances there are several combinations of
> min/max values possible. The following diagram shows them:
> 
> 
>      ----+----+----+----+----+----+----+----
>         -3   -2   -1    0    1    2    3
> 
> 1                     min  max
> 2                          min  max
> 3                min       max
> 4                min            max
> 5           min            max
> 6           min       max
> 7           min  max
> 8   neither min nor max is set
> 9   only max is set
> 10  only min is set
> 
> 
> The horizontal line shows a number range from -3 to 3. Then each line 
> shows different cases of min/max values of an intbv instance.
> 
> As an example, in the first case min=0 and max > 0. The second case min 
>  > 0 and max > min, etc.
> 
>  From all those cases I think only two cases, namely 1 and 2, are where
> the value is considered unsigned and the signed() function will return a
> modified value.
> 
> In all other cases either there is no range specified or the min value
> is < 0, which makes that intbv instance already considered signed and
> the signed() function will just return the value as is.
> 
> So the test will be for min >= 0 and _nrbits > 0. That case will 
> classify the intbv instance as unsigned and the signed() function will 
> return the value as signed, with the sign being determined based on the 
> msb. The msb is bit # _nrbits-1.
> 
> Note that case #10 (only min is set) could fulfill the requirement min 
>  >=0, but as no max is set, _nrbits is 0 and hence the second test will 
> not be True.

Sounds all very logical to me.

Jan


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

Re: [myhdl-list] intbv.signed()

[Günter D. <dan...@we...>]

Jan Decaluwe wrote:
...
> 
> Sounds all very logical to me.

Would that change already qualify for a bundle or does it make more 
sense first to also add the changes so that toVerilog and toVHDL will 
convert this function?

Guenter

Re: [myhdl-list] intbv.signed()

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

Günter Dannoritzer wrote:
> Jan Decaluwe wrote:
> ...
>> Sounds all very logical to me.
> 
> Would that change already qualify for a bundle

Yes, but ideally we should also have a test for it,
perhaps we need to discuss this further.

> or does it make more 
> sense first to also add the changes so that toVerilog and toVHDL will 
> convert this function?

I would keep this separate, let's get the desired behavior
right first.

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

Re: [myhdl-list] intbv.signed()

[Günter D. <dan...@we...>]

Jan Decaluwe wrote:
> Günter Dannoritzer wrote:
>> Jan Decaluwe wrote:
>> ...
>>> Sounds all very logical to me.
>> Would that change already qualify for a bundle
> 
> Yes, but ideally we should also have a test for it,
> perhaps we need to discuss this further.
> 

I have a test case with three tests.

The first test verifies the behavior of the signed() function in
connection with intbv instances having various parameters and values.
The test is divided in two parts. The first part contains cases that
make the signed() function classify the value as unsigned and consider
the bits based on _nrbits as a 2's complement value. The second part
triggers cases were the value is classified as signed and the value
returned as is.

The second test verifies the behavior of the signed() function in
connection with slices. This test can actually be simplified, as the
return of a sliced intbv is always an intbv with min=0 and max>min, 
which is always classified by the signed() function as unsigned. So I 
only did two verifications here, one with a slice and the sign bit set 
and one with a slice with the sign bit not set.

The third test verifies the behavior in connection with the concat()
function. Using the signed() function in connection with concat() only
makes sense, if the concat() function will return an intbv instance. If
I understand the concat() function right, there are cases when it only 
returns an integer value. So here I limited the test to two verifies. In 
one I concat() three bool values, with the msb set and I expect the bit
pattern to be returned as 2's complement value by the signed() function.
In the second test I take an intbv instance that would be classified as
unsigned and concatenate two bool values. Again, expecting the value to
be returned as 2's complement value.

Guenter