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