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
>