myhdl-list

[myhdl-list] 0.5dev3 testing

[Tom D. <td...@di...>]

I had been using the following:

Signal(intbv(0,min=0,max=2))

to get a 1 bit register or wire.

With the development version I get a 2 bit signal. Is that intentional?

I thought the range should be min <= Num < max.

Tom

[myhdl-list] Re: 0.5dev3 testing

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

Tom Dillon wrote:
> I had been using the following:
> 
> Signal(intbv(0,min=0,max=2))
> 
> to get a 1 bit register or wire.
> 
> With the development version I get a 2 bit signal. Is that intentional?
> 
> I thought the range should be min <= Num < max.

Tom:

To understand whether this is expected or not, can you please tell
me if you have *somewhere* in your MyHDL code, an intbv that can
have negative values?

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Electronic design with Python:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Re: 0.5dev3 testing

[Tom D. <td...@di...>]

Jan Decaluwe wrote:

> Tom Dillon wrote:
>
>> I had been using the following:
>>
>> Signal(intbv(0,min=0,max=2))
>>
>> to get a 1 bit register or wire.
>>
>> With the development version I get a 2 bit signal. Is that intentional?
>>
>> I thought the range should be min <= Num < max.
>
>
> Tom:
>
> To understand whether this is expected or not, can you please tell
> me if you have *somewhere* in your MyHDL code, an intbv that can
> have negative values?
>
Yes.

[myhdl-list] Re: 0.5dev3 testing

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

Tom Dillon wrote:
> 
> 
> Jan Decaluwe wrote:
> 
>> Tom Dillon wrote:
>>
>>> I had been using the following:
>>>
>>> Signal(intbv(0,min=0,max=2))
>>>
>>> to get a 1 bit register or wire.
>>>
>>> With the development version I get a 2 bit signal. Is that intentional?
>>>
>>> I thought the range should be min <= Num < max.
>>
>>
>>
>> Tom:
>>
>> To understand whether this is expected or not, can you please tell
>> me if you have *somewhere* in your MyHDL code, an intbv that can
>> have negative values?
>>
> Yes.

Tom:

In that case, it was not possible to convert with 0.4, so you already
gain :-)

What I expect is that you don't just get a 2 bit signal, but a *signed*
2 bit signal. For a signed representation of just 0 and 1, you do need
an additional sign bit (which will be zero).

Of course the question is - why a signed representation for a positive
intbv? I have tried to answer that here:

http://myhdl.jandecaluwe.com/doku.php/whatsnew:0.5#support_for_signed_arithmetic

Please review this. The point is that it's tricky to get signed right
in Verilog - using signed as a "default" for intbv representation
helps in getting it right.

Note that there are special cases, such as slicing, indexing and also
single bit signals. The latter is relevant to you. As a matter of style,
I suggest to use Signal(bool()) to represent single bit signals. It's
more efficient, less typing, and it is clearer. You dont' lose anything
in terms of operations because bool is a subtype of int in Python.

Moreover, bool() is treated specially by the convertor - the reasoning
is that signed/unsigned clearly doesn't make a lot of sense in this
case. Moreover, you want signals like clocks and resets to be single
bit (unsigned) regs in Verilog. So if you use bool(), you will still
get a single bit unsigned reg/wire in Verilog.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Electronic design with Python:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Re: 0.5dev3 testing

[Tom D. <td...@di...>]

Jan,

I don't like making all signals signed in a design just because you use 
one signed number somewhere in the design.  Let's say you have a design 
basically working (with all unsigned numbers) and you need to pull in a 
module that needs to do a single signed operation, all your signals now 
grow by a bit, for no good reason. That doesn't seem right to me.

I would prefer to be in control of the bit widths of all signals from 
the MyHDL source.

MyHDL simulation really does all math signed, and the only concern it 
has is that you always assign a number to a variable that is within its 
min/max range.

For example, if you do the following with a, b, x all having their _min 
set to 0,

x.next = a - b,

it will work fine until you try it with b > a. Once you try with b > a, 
you get a MyHDL simulation error and need to fix the problem.  The fix 
is as a minimum make x._min negative enough to hold all the the results 
of your simulation. This is no different than the simulation catch a 
x._max too small.

The next problem you will run into is anywhere x goes, will also need to 
be have a similar _min or else the simulation will again flag an error 
and stop when the assignment occurs that violates the _min. My point is, 
MyHDL simulation forces proper prorogation of the signed numbers, at 
least if you do a reasonable simulation. So far this is good with MyHDL 
providing a very nice means of making sure all your numbers can be 
contained within all the signals of your design.

The real trouble comes if only one of a or b are signed and the target 
is signed. Since the MyHDL simulation will always do the math correctly, 
it is hard to match the Verilog simulation.  

I would suggest one of the following for this case:

   1. Do nothing, force a good simulation which will leave some Verilog
      debugging.
   2. Locally add a bit to a or b if unsigned and make MSB 0, basically
      concatenate a 0 during the operation and force the operation to be
      signed.

Another note on signed numbers. I have found that the only way to 
propagate a negative number through a slice operation is to use a[:n]. 
That seems to work fine, while slicing from the MSB down doesn't get the 
negative number passed. This is OK, but maybe a note is needed in the 
manual on that.

What if I want to concat() some bits together to form a signed number (a 
negative one). For example if I wanted to sign extend a negative number. 
Normally I would expect this to work (at least in an HDL):

b.next = concat(a[MSB],a[MSB],a) # with b 2 bits bigger than a.

But this will always result in a positive number in the MyHDL simulation.

Tom



Jan Decaluwe wrote:

> Tom Dillon wrote:
>
>>
>>
>> Jan Decaluwe wrote:
>>
>>> Tom Dillon wrote:
>>>
>>>> I had been using the following:
>>>>
>>>> Signal(intbv(0,min=0,max=2))
>>>>
>>>> to get a 1 bit register or wire.
>>>>
>>>> With the development version I get a 2 bit signal. Is that 
>>>> intentional?
>>>>
>>>> I thought the range should be min <= Num < max.
>>>
>>>
>>>
>>>
>>> Tom:
>>>
>>> To understand whether this is expected or not, can you please tell
>>> me if you have *somewhere* in your MyHDL code, an intbv that can
>>> have negative values?
>>>
>> Yes.
>
>
> Tom:
>
> In that case, it was not possible to convert with 0.4, so you already
> gain :-)
>
> What I expect is that you don't just get a 2 bit signal, but a *signed*
> 2 bit signal. For a signed representation of just 0 and 1, you do need
> an additional sign bit (which will be zero).
>
> Of course the question is - why a signed representation for a positive
> intbv? I have tried to answer that here:
>
> http://myhdl.jandecaluwe.com/doku.php/whatsnew:0.5#support_for_signed_arithmetic 
>
>
> Please review this. The point is that it's tricky to get signed right
> in Verilog - using signed as a "default" for intbv representation
> helps in getting it right.
>
> Note that there are special cases, such as slicing, indexing and also
> single bit signals. The latter is relevant to you. As a matter of style,
> I suggest to use Signal(bool()) to represent single bit signals. It's
> more efficient, less typing, and it is clearer. You dont' lose anything
> in terms of operations because bool is a subtype of int in Python.
>
> Moreover, bool() is treated specially by the convertor - the reasoning
> is that signed/unsigned clearly doesn't make a lot of sense in this
> case. Moreover, you want signals like clocks and resets to be single
> bit (unsigned) regs in Verilog. So if you use bool(), you will still
> get a single bit unsigned reg/wire in Verilog.
>
> Regards, Jan
>

[myhdl-list] Re: 0.5dev3 testing

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

Hi:

I have put the current approach on hold for reconsideration.

See also my comments:

Tom Dillon wrote:
> Jan,
> 
> I don't like making all signals signed in a design just because you use 
> one signed number somewhere in the design.  Let's say you have a design 
> basically working (with all unsigned numbers) and you need to pull in a 
> module that needs to do a single signed operation, all your signals now 
> grow by a bit, for no good reason. That doesn't seem right to me.

I agree it seems brute-force, but the good reason would be get it right.

My thinking was that it would not be common to have a single, or a
few signed operations - I thought either none, ore lots of them. But I
agree that the scenario you describe is not like that.

Internally in the design, I think the issue is largely psychological
(although that counts) - I don't think there would be any significant
impact on efficiency in synthesis results by adding a sign bit
systematically (if it's needed, you'll be glad it's there, otherwise
a synthesis tool may remove it by logic optimization).

However, at the port level the additional (unexpected) bit may be
disturbing. And perhaps also for special cases like single-bit signals.

> I would prefer to be in control of the bit widths of all signals from 
> the MyHDL source.
> 
> MyHDL simulation really does all math signed, and the only concern it 
> has is that you always assign a number to a variable that is within its 
> min/max range.
> 
> For example, if you do the following with a, b, x all having their _min 
> set to 0,
> 
> x.next = a - b,
> 
> it will work fine until you try it with b > a. Once you try with b > a, 
> you get a MyHDL simulation error and need to fix the problem.  The fix 
> is as a minimum make x._min negative enough to hold all the the results 
> of your simulation. This is no different than the simulation catch a 
> x._max too small.
> 
> The next problem you will run into is anywhere x goes, will also need to 
> be have a similar _min or else the simulation will again flag an error 
> and stop when the assignment occurs that violates the _min. My point is, 
> MyHDL simulation forces proper prorogation of the signed numbers, at 
> least if you do a reasonable simulation. So far this is good with MyHDL 
> providing a very nice means of making sure all your numbers can be 
> contained within all the signals of your design.
> 
> The real trouble comes if only one of a or b are signed and the target 
> is signed. Since the MyHDL simulation will always do the math correctly, 
> it is hard to match the Verilog simulation.  

Interesting statement :-) (I have to remember that one!)

> I would suggest one of the following for this case:
> 
>    1. Do nothing, force a good simulation which will leave some Verilog
>       debugging.

I think what you suggest here is that after conversion, a succesful
MyHDL simulation would not necessarily match the Verilog simulation.

That would definitely be not an option for me. If at all possible, I
want to make sure (ideally guarantee) that the simulations match.
I believe this is the only way to create a level of confidence in
a new tool. Also, it makes it unambiguous where the bug is (that is,
if the simulations don't match, it's a MyHDL bug).

On 2 occasions in the past, I have rejected EDA tools that didn't
follow this approach.

>    2. Locally add a bit to a or b if unsigned and make MSB 0, basically
>       concatenate a 0 during the operation and force the operation to be
>       signed.

That's a valid alternative - a fine-grained approach.

Initially, I was a little overwhelmed by the apparent complexities
in getting this right in Verilog. So I looked for an approach that
would "always" work. Hence the current coarse-grained approach.

However, during implementation, I noticed that this fine-grained
approach might not be too difficult after all. I don't have to
deal with *any* Verilog, only with code that comes from MyHDL.
And this code is structured in a way that may make it not
too hard to do it like that.

So I'll reconsider all this and give it some thinking.

> Another note on signed numbers. I have found that the only way to 
> propagate a negative number through a slice operation is to use a[:n]. 
> That seems to work fine, while slicing from the MSB down doesn't get the 
> negative number passed. This is OK, but maybe a note is needed in the 
> manual on that.

This is modelled after Verilog.
There's a note on this in the reference part on the intbv. I agree
it should be also be mentioned when slicing is introduced.

> What if I want to concat() some bits together to form a signed number (a 
> negative one). For example if I wanted to sign extend a negative number. 
> Normally I would expect this to work (at least in an HDL):
> 
> b.next = concat(a[MSB],a[MSB],a) # with b 2 bits bigger than a.
> 
> But this will always result in a positive number in the MyHDL simulation.

Of course in this case "b.next = a" would work as expected. In general,
I guess manipulating the bits of a signed number would be easiest:

a[:] = -1
a[3:] = .....

Or a sign-extension function.

concat itself returns positive numbers as you note. To me it's a bit
like slicing: when working on a limited number of bits, I think
you're normally not concerned about positive/negative interpretation.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Electronic design with Python:
     http://myhdl.jandecaluwe.com