Re: [myhdl-list] Wrap-around support in MyHDL

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

As you like the proposal after putting the feature
back on the map, and I hear no objections, I'd like
to make some progress.

This is definitely a 0.8 feature, so I will open
a 0.8-dev branch for development. I will also turn
the proposal into a MEP.

As typical, one good idea may solve other related
issues. For example, for some time I have struggled
with how to handle an in-place left shift:

     lsfr <<= 1

With intbv, this will always result in upper
bound failures, making the construct unusable.
With modbv, it should work as expected.

Moreover, in the past for some "bit-oriented"
operations, we have made exceptions for "unsigned"
intbv's with a finite bound. Reasonable, but a
little strange. With modbv, such exceptions may
not be necessary. So it may be wise to revert the
intbv behavior at some points and ask designers
to use modbv for certain operations instead.

Jan

On 05/16/2011 01:12 PM, Christopher Felton wrote:
> <large snip, background, wrap, ada>
>>
>> A proposal for MyHDL: the modbv type
>> ------------------------------------
>>
>> Ada's modular type is called 'mod'. By analogy, I am
>> proposing a 'modbv' type in MyHDL. Behaviorally, the only
>> difference with intbv would be how bounds are handled:
>> out-of-bound values result in an error in the intbv, and
>> wrap-around in the modbv. In particular, modbv would have
>> exactly the same interface as the intbv. Wrap-around
>> behavior would be defined as follows:
>>
>>       val = (val - min) % (max - min) + min
>>
>> Unlike Ada, intbv and modbv would be subtypes of a general
>> integer-bitvector type. Therefore, they can be mixed
>> transparantly in expressions. This should be not problem as
>> the bound handling only occurs at assignment time in the
>> assigned object.
>>
>> This proposal addresses the issues mentioned earlier. In
>> particular:
>>
>>        count += 1
>>
>> and
>>
>>        count = modbv(0)[32:]
>>
>> would have wrap-around behavior.
>>
>> Implementation notes
>> --------------------
>>
>> Technically, the cleanest implementation would probably be
>> to make both intbv and modbv a subtype of some general
>> integer-bitvector class. In a first phase, it would
>> probably be OK to simply subclass intbv.
>>
>> To make this kind of subclassing possible, the intbv class
>> has to be made more robust. For example, at some points were
>> it returns a literal 'intbv' object, it should use the
>> actual subtype itself.
>>
>> The basic difference with intbv is bound
>> handling. Currently, this is already done in a separate
>> method called intbv._checkBounds(). This method should
>> probably be renamed to intbv._handleBounds(), and then
>> overwritten with the proper behavior in the subclass.
>>
>> Conversion notes
>> ----------------
>>
>> It is expected that conversion would work directly for the
>> case of "full range" modbv objects. (Note that it is not
>> sufficient that both bounds are powers of 2.) In a first
>> phase, the convertor could impose that restriction.
>>
>> To demonstrate the advantage of the chosen approach, we
>> could attempt to lift some restrictions for interesting use
>> cases. For example, a common use case for wrap-around
>> behavior would be incrementors and decrementors. The
>> analyzer could detect such cases and mark them. For such
>> patterns, we could then support general wrap-around for non
>> full-range objects also. For example:
>>
>>        count.next = count + 1
>>
>> would be converted to:
>>
>>        if count == MAX-1:
>>            count.next = MIN
>>        else:
>>            count.next = count + 1
>>
>> It is probably possible to remove more restrictions in a
>> gradual process. When doing so, we would be adding items to
>> the list of useful features that MyHDL can fully support,
>> even though they have no native support in Verilog/VHDL. At
>> some point, this list of features, unique to MyHDL, could
>> become very attractive to Verilog/VHDL designers.
>>
>>
>
> Excellent!  This is a very comprehensive coverage of the topic.
>
> One additional item I think we should address.  But not to be included
> in the above proposed implementation.  In the past requests for wrap
> have mostly been accompanied by a request for saturate as well.  Since,
> more interesting behaviors are being tackled we might want to mention
> how saturate might be handled (in the future).  If this is another type
> (satbv) or whichever.
>
> Otherwise, I think this is a good proposal for the wrapping behavior.  I
> like the addition of the type, derived class, to handle the behaviors.
> Also, the potential future addition of a new base class.  Understanding
> that this will be future work, if deemed needed after the first pass
> implementation of modbv.
>
> Chris Felton
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com