[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