myhdl-list

[myhdl-list] Bit-wise inversion issue

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

Chris Felton has recently signalled an issue with bit-wise
inversion. Hereby an analysis.

Consider the following interpreter log:

 >>> from myhdl import *
 >>> ~5
-6
 >>> ~intbv(5)
intbv(-6)
 >>> ~intbv(5)[3:]
intbv(2L)

You can see that an "unsized" intbv behaves like an int,
but a "sized" intbv behaves differently. Obviously confusing.

Why is this? The answer is in the original support for
conversion to Verilog and VHDL. Originally, only unsigned
values were supported. But in Verilog and VHDL those
don't behave like a Python int: bit-wise inversion of
an unsigned (and therefore positive) number still returns
a positive number. In contrast, the sign of an int
is always changed upon bit-wise inversion.

I modified the behavior of sized intbv's to mimic Verilog
behavior. In this way the original convertor could support
bit-wise inversion without signed/unsigned machinery. This
behavior has not been changed since.

Looking at this now, I think it is wrong. A sized intbv
should also behave like a Python int. So I think the current
behavior should be changed.

The convertor should cast unsigned arguments to signed,
to get the desired result (hopefully, to be checked).

This would imply a backward-incompatible change of intbv
behavior (but it could be viewed as a bug fix). So please
review this carefully and give feedback if necessary.

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] Bit-wise inversion issue

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

Hi,

I'm not sure there is anything wrong, although I may not fully understand...

On Wednesday 27 February 2008 10:06:33 am Jan Decaluwe wrote:
> Chris Felton has recently signalled an issue with bit-wise
> inversion. Hereby an analysis.
>
> Consider the following interpreter log:
>  >>> from myhdl import *
>  >>> ~5
> -6

That is because a python int is signed, right?
>
>  >>> ~intbv(5)
> intbv(-6)

default intbv must be signed as well.

>
>  >>> ~intbv(5)[3:]
>intbv(2L)

intbv(5)[3:] is unsigned, so I think 2L is the right answer. 

I would not expect a unsigned to get changed to signed with the ~ operator.

So I think the only question is should intbv(5)[3:] result in a signed or unsigned result?

I don't know if I would use Verilog as the guideline for how anything signed should work, as the 
Verilog rules are fairly complicated (overly I think).

Tom

Re: [myhdl-list] Bit-wise inversion issue

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

Tom Dillon wrote:

> I'm not sure there is anything wrong, although I may not fully understand...
> 
> On Wednesday 27 February 2008 10:06:33 am Jan Decaluwe wrote:
> 
>>Chris Felton has recently signalled an issue with bit-wise
>>inversion. Hereby an analysis.
>>
>>Consider the following interpreter log:
>> >>> from myhdl import *
>> >>> ~5
>>-6
> 
> That is because a python int is signed, right?
> 
>> >>> ~intbv(5)
>>intbv(-6)
> 
> default intbv must be signed as well.
> 
>> >>> ~intbv(5)[3:]
>>intbv(2L)
> 
> intbv(5)[3:] is unsigned, so I think 2L is the right answer.

That's not how I think about it. (Warning: this may get subtle.)
To me, intbv(5)[3:] is simply intbv(5) with constraints on the allowed
values. If the constraints are such that the value must be positive,
then we can choose to represent such an intbv as an unsigned in
another language such as Verilog or VHDL. An optimization really.

On the other hand, I see your point of course. We should be
practical. I have to think further, there may be compromise solutions.

In any case, there really is something wrong. Consider:

 >>> ~intbv(5, min=-6, max=6)
intbv(10L)

This intbv would have to be represented by a signed in a target
language, yet bitwise inversion still returns a positive number
with the current implementation. As a miminum, this should be
fixed - if someone disagrees, let me know.

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] Bit-wise inversion issue

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

> In any case, there really is something wrong. Consider:
> 
> >>> ~intbv(5, min=-6, max=6)
> intbv(10L)
>
> This intbv would have to be represented by a signed in a target
> language, yet bitwise inversion still returns a positive number
> with the current implementation. As a miminum, this should be
> fixed - if someone disagrees, let me know.

I agree, we are representing 2 types (at least in Verilog speak) with
intbv.  Unsigned bit vectors and signed bit vectors.  As you pointed
out we need to determine what is the correct usage given the context.

As Tom pointed out for the bit vector that would be the expected value
but for a signed bit vector value you will run into the problem above.

Thanks!

Re: [myhdl-list] Bit-wise inversion issue

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

Does this make sense, and is it possible (easily possible)

intbv(5)                     -> signed, because this is consistent with
                                 default python as you showed
                                 default min=-??, default max=??

intbv(5)[4:]                 ->  unsigned, has the feel of
                                  Verilog/VHDL bit-vectors
                                  default min=0, default max=16

intbv(5, min=0, max=15)      -> unsigned because explicitly defined no  
min

intbv(5, min=-8, max=7)      -> signed because explicitly defined min

intbv(5, min=-8, max=7)[4:]  -> ??

 >>> x = intbv(5, min=-8, max=7)[4:]
 >>> x
intbv(5L)
 >>> dir(x)
 >>> x._nrbits
4
 >>> x._val
5L
 >>> x.max
16
 >>> x.min
0
 >>>

Think the above would be somewhat straight forward, since the last  
example shows that the [4:] syntax overrides the min.

Chris

On Feb 27, 2008, at 1:33 PM, Jan Decaluwe wrote:

>
>>>> ~intbv(5, min=-6, max=6)
> intbv(10L)
>
> This intbv would have to be represented by a signed in a target
> language, yet bitwise inversion still returns a positive number
> with the current implementation. As a miminum, this should be
> fixed - if someone disagrees, let me know.
>
> Jan
>
> -- 
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Kaboutermansstraat 97, B-3000 Leuven, Belgium
>     From Python to silicon:
>     http://myhdl.jandecaluwe.com
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Bit-wise inversion issue

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

Ok, let's try to reach a decision.

I believe there are 2 solutions that can be defended.

Possible solutions
------------------

1) "Pure Python"
Bit inversion for intbv's behaves like for Python int's.

2) "Practical Hardware"
Make an exception for intbv's whose allowed values are
a finite set of positive values. Let's call these p-intbv's.
For a p-intbv, bits outside the bit range of an unsigned
representation, are assumed to remain zero upon bit-inversion.

Analysis
--------
Both solutions have advantages and drawbacks.

The major drawback of the "Pure Python" solution is that it
may be counter-intuitive to hardware designers. Many designs
mainly use p-intbvs, e.g. created by the form intbv(0)[n:].
But with this solution it would not be possible to represent
the bit-inversion of a p-intbv by another p-intbv. Negative
values would have to be introduced just for this purpose.

The major drawback of the "Practical Hardware" solution is
that the result of a bit-inversion would not just depend
on the intbv value, but also on its constraints. It is the
only operator for which this would be so. This is disturbing.

Conclusion
----------

The drawback of the "Pure Python" solution is probably fatal
for practical purposes. Therefore, I propose to keep the
"Practical Hardware" solution. This is in line with the
feedback from this thread thus far.

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] Bit-wise inversion issue

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

On Mar 3, 2008, at 10:55 AM, Jan Decaluwe wrote:

> Ok, let's try to reach a decision.
>
> I believe there are 2 solutions that can be defended.
>
> Possible solutions
> ------------------
>
> 1) "Pure Python"
> Bit inversion for intbv's behaves like for Python int's.
>
> 2) "Practical Hardware"
> Make an exception for intbv's whose allowed values are
> a finite set of positive values. Let's call these p-intbv's.
> For a p-intbv, bits outside the bit range of an unsigned
> representation, are assumed to remain zero upon bit-inversion.
>
> Analysis
> --------
> Both solutions have advantages and drawbacks.
>
> The major drawback of the "Pure Python" solution is that it
> may be counter-intuitive to hardware designers. Many designs
> mainly use p-intbvs, e.g. created by the form intbv(0)[n:].
> But with this solution it would not be possible to represent
> the bit-inversion of a p-intbv by another p-intbv. Negative
> values would have to be introduced just for this purpose.
>
> The major drawback of the "Practical Hardware" solution is
> that the result of a bit-inversion would not just depend
> on the intbv value, but also on its constraints. It is the
> only operator for which this would be so. This is disturbing.
>
> Conclusion
> ----------
>
> The drawback of the "Pure Python" solution is probably fatal
> for practical purposes. Therefore, I propose to keep the
> "Practical Hardware" solution. This is in line with the
> feedback from this thread thus far.

If I am following, the "Practical Hardware" solution is the proposal,  
but it has the "disturbing" attribute (operate(s) having to look at  
the constraints).
The solution will include the positive and negative intbv (as far as  
the ~ operator goes)?

I agree with the "disturbing" to a new user it may not be clear why or  
how a negative number is represented.  And it also falls out of the  
standard implementation (kinda a kludge).

Overall I think it is a fair compromise / solution.


>
>
> Jan
>
> -- 
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Kaboutermansstraat 97, B-3000 Leuven, Belgium
>     From Python to silicon:
>     http://myhdl.jandecaluwe.com
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Bit-wise inversion issue

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

Christopher L. Felton wrote:


> If I am following, the "Practical Hardware" solution is the proposal,  
> but it has the "disturbing" attribute (operate(s) having to look at  
> the constraints).
> The solution will include the positive and negative intbv (as far as  
> the ~ operator goes)?

Yes.

-- 
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] Bit-wise inversion issue

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

Jan Decaluwe wrote:

> Conclusion
> ----------
> 
> The drawback of the "Pure Python" solution is probably fatal
> for practical purposes. Therefore, I propose to keep the
> "Practical Hardware" solution.

I have implemented this, including conversion support for
Verilog and VHDL.

This will be included in the upcoming development release 0.6dev7.

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] Bit-wise inversion issue

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

Jan,

First, thanks for the changes in the latest development release,  
incredible effort on your end with the timely changes!

But (there is always a but) the VHDL conversion with the development  
build fails (at least for my example)?  I have not looked into the  
details why it is failing, but I attached the files that I am using  
and below is the error.

The Verilog conversion works fine, by inspection and cosimulation it  
is valid (haven't synthesized).

*** Error ?? ****
     def inferBinaryOpType(self, node, left, right, op=None):
E       if isinstance(left.vhd, (vhd_boolean, vhd_std_logic)):
 >       AttributeError: Invert instance has no attribute 'vhd'
**** ****

Thanks



On Mar 9, 2008, at 10:44 AM, Jan Decaluwe wrote:

> Jan Decaluwe wrote:
>
>> Conclusion
>> ----------
>>
>> The drawback of the "Pure Python" solution is probably fatal
>> for practical purposes. Therefore, I propose to keep the
>> "Practical Hardware" solution.
>
> I have implemented this, including conversion support for
> Verilog and VHDL.
>
> This will be included in the upcoming development release 0.6dev7.
>
> Jan
>
> -- 
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Kaboutermansstraat 97, B-3000 Leuven, Belgium
>     From Python to silicon:
>     http://myhdl.jandecaluwe.com
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Bit-wise inversion issue

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

Christopher L. Felton wrote:
> Jan,
> 
> First, thanks for the changes in the latest development release, 
> incredible effort on your end with the timely changes!
> 
> But (there is always a but) the VHDL conversion with the development 
> build fails (at least for my example)?  I have not looked into the 
> details why it is failing, but I attached the files that I am using and 
> below is the error.
> 
> The Verilog conversion works fine, by inspection and cosimulation it is 
> valid (haven't synthesized).

Thanks, I'm able to reproduce the error. Unfortunately the fix is
not as obvious as I thought at first - apparently some special
care is needed to deal with the conversion of bit inversions used
in expresssions. (And next week I'm on holiday so it may take
some time.)

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] Bit-wise inversion issue

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

Jan Decaluwe wrote:
> Christopher L. Felton wrote:
> 
>>Jan,
>>
>>First, thanks for the changes in the latest development release, 
>>incredible effort on your end with the timely changes!
>>
>>But (there is always a but) the VHDL conversion with the development 
>>build fails (at least for my example)?  I have not looked into the 
>>details why it is failing, but I attached the files that I am using and 
>>below is the error.
>>
>>The Verilog conversion works fine, by inspection and cosimulation it is 
>>valid (haven't synthesized).
> 
> 
> Thanks, I'm able to reproduce the error.

Development 0.6dev8 (just released) solves the problem in my
unit tests. However, I haven't tried it on your example.

In the process, I think I made the type inferencing mechanism
in the VHDL convertor more robust in general.

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] Bit-wise inversion issue

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

Thanks!  VHDL is generated without errors now.

On Mar 27, 2008, at 11:14 AM, Jan Decaluwe wrote:

> Jan Decaluwe wrote:
>> Christopher L. Felton wrote:
>>
>>> Jan,
>>>
>>> First, thanks for the changes in the latest development release,
>>> incredible effort on your end with the timely changes!
>>>
>>> But (there is always a but) the VHDL conversion with the development
>>> build fails (at least for my example)?  I have not looked into the
>>> details why it is failing, but I attached the files that I am  
>>> using and
>>> below is the error.
>>>
>>> The Verilog conversion works fine, by inspection and cosimulation  
>>> it is
>>> valid (haven't synthesized).
>>
>>
>> Thanks, I'm able to reproduce the error.
>
> Development 0.6dev8 (just released) solves the problem in my
> unit tests. However, I haven't tried it on your example.
>
> In the process, I think I made the type inferencing mechanism
> in the VHDL convertor more robust in general.
>
> Jan
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Kaboutermansstraat 97, B-3000 Leuven, Belgium
>     From Python to silicon:
>     http://myhdl.jandecaluwe.com
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Bit-wise inversion issue

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

Jan,

On Wednesday 27 February 2008 02:33:57 pm Jan Decaluwe wrote:

> >
> > intbv(5)[3:] is unsigned, so I think 2L is the right answer.
>
> That's not how I think about it. (Warning: this may get subtle.)
> To me, intbv(5)[3:] is simply intbv(5) with constraints on the allowed
> values. If the constraints are such that the value must be positive,
> then we can choose to represent such an intbv as an unsigned in
> another language such as Verilog or VHDL. An optimization really.

yes, I agree with you thinking there. I was thinking the slice would produce an unsigned intbv, but 
of course that is wrong.

I think it has to make sense and be as simple as possible in MyHDL and force the translation to 
Verilog or VHDL to produce the same results.

>
> On the other hand, I see your point of course. We should be
> practical. I have to think further, there may be compromise solutions.
>
> In any case, there really is something wrong. Consider:
>  >>> ~intbv(5, min=-6, max=6)
>
> intbv(10L)

What about ~intbv(5,min=0, max=15)?

intbv(10L)

I think that is correct.

Tom

Re: [myhdl-list] Bit-wise inversion issue

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

Is the following expected behavior?

 >>> y = intbv(15)[4:]
 >>> ~y
intbv(0L)
 >>> z = ~y
 >>> z._nrbits
0
 >>>

The new number of bits is 0?  I think in normal case this is fine  
because usually it would be Signal.next, and the Signal type wouldn't  
be overridden only the value?


On Feb 27, 2008, at 2:41 PM, Tom Dillon wrote:

> Jan,
>
> On Wednesday 27 February 2008 02:33:57 pm Jan Decaluwe wrote:
>
>>>
>>> intbv(5)[3:] is unsigned, so I think 2L is the right answer.
>>
>> That's not how I think about it. (Warning: this may get subtle.)
>> To me, intbv(5)[3:] is simply intbv(5) with constraints on the  
>> allowed
>> values. If the constraints are such that the value must be positive,
>> then we can choose to represent such an intbv as an unsigned in
>> another language such as Verilog or VHDL. An optimization really.
>
> yes, I agree with you thinking there. I was thinking the slice would  
> produce an unsigned intbv, but
> of course that is wrong.
>
> I think it has to make sense and be as simple as possible in MyHDL  
> and force the translation to
> Verilog or VHDL to produce the same results.
>
>>
>> On the other hand, I see your point of course. We should be
>> practical. I have to think further, there may be compromise  
>> solutions.
>>
>> In any case, there really is something wrong. Consider:
>>>>> ~intbv(5, min=-6, max=6)
>>
>> intbv(10L)
>
> What about ~intbv(5,min=0, max=15)?
>
> intbv(10L)
>
> I think that is correct.
>
> Tom
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Bit-wise inversion issue

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

I don't think the sliced result gets ._nrbits .min or .max set. 

I think it should, at least for clarification.

Tom


On Thursday 28 February 2008 08:00:24 am Christopher L. Felton wrote:
> Is the following expected behavior?
>
>  >>> y = intbv(15)[4:]
>  >>> ~y
>
> intbv(0L)
>
>  >>> z = ~y
>  >>> z._nrbits
>
> 0
>
>
> The new number of bits is 0?  I think in normal case this is fine
> because usually it would be Signal.next, and the Signal type wouldn't
> be overridden only the value?
>
> On Feb 27, 2008, at 2:41 PM, Tom Dillon wrote:
> > Jan,
> >
> > On Wednesday 27 February 2008 02:33:57 pm Jan Decaluwe wrote:
> >>> intbv(5)[3:] is unsigned, so I think 2L is the right answer.
> >>
> >> That's not how I think about it. (Warning: this may get subtle.)
> >> To me, intbv(5)[3:] is simply intbv(5) with constraints on the
> >> allowed
> >> values. If the constraints are such that the value must be positive,
> >> then we can choose to represent such an intbv as an unsigned in
> >> another language such as Verilog or VHDL. An optimization really.
> >
> > yes, I agree with you thinking there. I was thinking the slice would
> > produce an unsigned intbv, but
> > of course that is wrong.
> >
> > I think it has to make sense and be as simple as possible in MyHDL
> > and force the translation to
> > Verilog or VHDL to produce the same results.
> >
> >> On the other hand, I see your point of course. We should be
> >> practical. I have to think further, there may be compromise
> >> solutions.
> >>
> >> In any case, there really is something wrong. Consider:
> >>>>> ~intbv(5, min=-6, max=6)
> >>
> >> intbv(10L)
> >
> > What about ~intbv(5,min=0, max=15)?
> >
> > intbv(10L)
> >
> > I think that is correct.
> >
> > Tom
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > myhdl-list mailing list
> > myh...@li...
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Bit-wise inversion issue

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

Here is a possible enhancement,

from _intbv.py around line 407

<<code>>
     def __invert__(self):
         if self._nrbits:
             if self._min < 0:
                 return intbv(~self._val, min=self._min, max=self._max)
             else:
                 return intbv(~self._val & (1L << self._nrbits)-1)
         else:
             return intbv(~self._val)
<<>>

I ran the test scripts, it didn't break anything.  Also the sequential  
mult that I sent works with the 2's comp flip.


On Feb 28, 2008, at 7:00 AM, Christopher L. Felton wrote:

> Is the following expected behavior?
>
> >>> y = intbv(15)[4:]
> >>> ~y
> intbv(0L)
> >>> z = ~y
> >>> z._nrbits
> 0
> >>>
>
> The new number of bits is 0?  I think in normal case this is fine  
> because usually it would be Signal.next, and the Signal type  
> wouldn't be overridden only the value?
>
>
> On Feb 27, 2008, at 2:41 PM, Tom Dillon wrote:
>
>> Jan,
>>
>> On Wednesday 27 February 2008 02:33:57 pm Jan Decaluwe wrote:
>>
>>>>
>>>> intbv(5)[3:] is unsigned, so I think 2L is the right answer.
>>>
>>> That's not how I think about it. (Warning: this may get subtle.)
>>> To me, intbv(5)[3:] is simply intbv(5) with constraints on the  
>>> allowed
>>> values. If the constraints are such that the value must be positive,
>>> then we can choose to represent such an intbv as an unsigned in
>>> another language such as Verilog or VHDL. An optimization really.
>>
>> yes, I agree with you thinking there. I was thinking the slice  
>> would produce an unsigned intbv, but
>> of course that is wrong.
>>
>> I think it has to make sense and be as simple as possible in MyHDL  
>> and force the translation to
>> Verilog or VHDL to produce the same results.
>>
>>>
>>> On the other hand, I see your point of course. We should be
>>> practical. I have to think further, there may be compromise  
>>> solutions.
>>>
>>> In any case, there really is something wrong. Consider:
>>>>>> ~intbv(5, min=-6, max=6)
>>>
>>> intbv(10L)
>>
>> What about ~intbv(5,min=0, max=15)?
>>
>> intbv(10L)
>>
>> I think that is correct.
>>
>> Tom
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Bit-wise inversion issue

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

Christopher L. Felton wrote:
> Is the following expected behavior?
> 
>> >> y = intbv(15)[4:]
>> >> ~y
> intbv(0L)
>> >> z = ~y
>> >> z._nrbits
> 0
>> >> 
> 
> The new number of bits is 0? 

Now you know why it's a private variable :-)
Seriously, I use 0 (False) to indicate that the nr of bits
is undefined.

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] Bit-wise inversion issue

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

Tom Dillon wrote:
> I don't think the sliced result gets ._nrbits .min or .max set. 
> 
> I think it should, at least for clarification.

Actually a slice returns a new intbv with _nrbits, min and max set.
(this is the idiomatic way to create an "unsigned", hardware-oriented
intbv).

But it is the only operator that does this. All others currently
return unsized intbv's or even int's.

This is usually not an issue, because the idiomiatic MyHDL usage
for updates is:

for intbv's:
    a[m:n] = <expression>
in particular, to set a new value:
    a[:] = <expression>
and for signals:
    s.next = <expression>

Therefore, I don't need to look at the right-hand expression to derive
a bit width. In this way, all issues with this as in VHDL and especially
Verilog are simply avoided. And of course I can optimize a little
(and keep it simple) by not worrying about setting bit widths on operator
results. Last but not least, I don't think that conversion to VHDL or
Verilog would otherwise be feasible.

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] Bit-wise inversion issue

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

On Thursday 28 February 2008 03:36:37 pm Jan Decaluwe wrote:
> Tom Dillon wrote:
> > I don't think the sliced result gets ._nrbits .min or .max set.
> >
> > I think it should, at least for clarification.
>
> Actually a slice returns a new intbv with _nrbits, min and max set.
> (this is the idiomatic way to create an "unsigned", hardware-oriented
> intbv).
>
sorry, I misunderstood the example I ran to come to the conclusion they weren't set. I was wrong, it 
seems fine to me the way it is.