Re: [myhdl-list] intbv wrap

[Christopher F. <chr...@gm...>]

On 5/4/2011 9:11 AM, Tom Dillon wrote:
>
>
> On 05/04/2011 03:00 AM, Christopher Felton wrote:
>> At this point in time I am going to defer converting the wrap function
>> as briefly discussed in other threads.  It is beyond my current
>> capabilities.  But this doesn't change the approach.  It simply means
>> the wrap can only be used as an attribute of the intbv object, thank you
>> Tom Dillon for the pointer here.
>
> Do you mean we won't have wrap support in conversion? Would it be
> possible to put an error or warning in so you would know the logic won't
> match the MyHDL code?

No, it will be *available* in conversion.  And the Verilog/VHDL will 
match.

In my previous post I mentioned there might be two approaches supported.

   1.  x = Signal(intbv(0, wrap=True)
       x.next[:] = x + 1  # automatically wraps
This method is automatically handled by the conversion, nothing has to 
be done.  But the designer needs to remember which Signal(intbv) have 
been setup to wrap.

   2.  x.next[:] = x.wrap(x + 1).
This approach is more explicit and follows current approach of 
explicitly indicating a wrap (for unsigned).  I think both approaches 
would be nice, but with approach 1 conversion is free and approach 2 
conversion is not free :(

>
> It is beyond my capabilities too, I still conversion is magic.
>
>> It also seemed appropriate to add a property for _val, see the following.
>>
>>        # val property
>>        def _get_val(self):
>>            return self._val
>>
>>        def _set_val(self, pval):
>>
>>            if self._wrap:
>>                self._val = self.wrap(pval)
>>            else:
>>                self._val = pval
>>
>>            self._checkBounds()
>>
>>        val = property(_get_val, _set_val)
>>
>>
>> This had been discussed in some older threads.  Are there any objections
>> against this type of implementation?  The _checkBounds and wrap will be
>> called only from the _set_val property function.
>
> Will intbv work as it does now? I am a little rusty on properties.

Yes, this does not change the functionality only the implementation.  A 
property is syntax sugar, when you have a data member _val you can 
assign getter and setter functions using the property.  Instead of using 
this._val = x, this.val = x is used and will call _set_val(x).

This way the wrap checking and bound checking which would be included 
with each _val assignment can be confined to one spot.  Hopefully 
minimize human errors without too much overhead.

This was discussed previously, that a property be added as an 
alternative to assign values to intbv

x = intbv(0, min=-8, max=8)
x[:]  = 4
x.val = 4

Both accomplish the same thing.  This was mentioned as a *possible* 
addition in the past.  I forget if there were any reasons not to do this.

Chris