myhdl-list — Mailing list for discussions on MyHDL

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

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

On 05/20/2011 05:25 PM, Jan Decaluwe wrote:
> 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.

http://myhdl.org/doku.php/meps:mep-106

-- 
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

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

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

On 05/26/2011 03:22 PM, Christopher Felton wrote:
> On 5/20/2011 10:25 AM, Jan Decaluwe wrote:
>> 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.
>>
>
> If you like, when the 0.8-dev branch is created, I can take the existing
> tests that we created and move them over, as a starting point, for the
> modbv tests.  Note: Ben did majority of the work for the previous tests :)

That would be very welcome.

I have now pushed the 0.8-dev branch that includes my initial
take on the feature. I have some indirect tests that suggest
that it works, but no direct ones like you have.

As for conversion, I have included some checks so that only
"full range" modbv's are supported at this point.

Feedback and bundles or patches with tests (on the 0.8-dev branch)
are welcome.

Jan

-- 
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

Re: [myhdl-list] FW: Floating-point support --> Fixed-point

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

> I am interested in the status of Fix point support in MyHDL. Is there some
> effort on the way to implement this. I am a newbie on the Python side but
> may be able to contribute from the hardware side. I have done some work on
> an ASIC fix point DSP component library in Verilog in the past.

I have had a couple other (offline) inquires on the state of the 
fixed_point object as well.  I have moved(ing) the latest code to 
bitbucket.  I should have the examples etc. move shortly as well (as in 
days not weeks, I hope).

https://bitbucket.org/cfelton/fixed_point/wiki/Home

Chris

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

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

On 5/20/2011 10:25 AM, Jan Decaluwe wrote:
> 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.
>

If you like, when the 0.8-dev branch is created, I can take the existing 
tests that we created and move them over, as a starting point, for the 
modbv tests.  Note: Ben did majority of the work for the previous tests :)

Guess it would look something like the following (as a start).  Should 
add additional tests for the expanded features and some tests for 
conversion.

+++ b/myhdl/test/core/test_modbv.py

class TestModbvWrap(TestCase):

     def testWrap(self):
         x = modbv(0, min=-8, max=8)
         x[:] = x + 1
         self.assertEqual(1, x)
         x[:] = x + 2
         self.assertEqual(3, x)
         x[:] = x + 5
         self.assertEqual(-8, x)
         x[:] = x + 1
         self.assertEqual(-7, x)
         x[:] = x - 5
         self.assertEqual(4, x)
         x[:] = x - 4
         self.assertEqual(0, x)
         x[:] += 15
         x[:] = x - 1
         self.assertEqual(-2, x)

     def testInit(self):
         self.assertRaises(ValueError, intbv, 15, min=-8, max=8)
         x = modbv(15, min=-8, max=8)
         self.assertEqual(-1, x)

         self.assertRaises(ValueError, intbv, 5, min=-3, max=8)
         modbv(5, min=-3, max=8)
	self.assertEqual(5, x)


     def testNoWrap(self):
         # verifies the base class does not wrap
         x = intbv(0, min=-8, max=8)
         try:
             x[:] += 15
             self.fail()
         except ValueError:
             pass


if __name__ == "__main__":
     unittest.main()

Chris

Re: [myhdl-list] Proposal to change license of wwww.myhdl.org

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

On 04/30/2011 09:11 AM, Jan Decaluwe wrote:

> In light of the above, I am proposing to change the license
> for www.myhdl.org to CC BY-SA. Upfront, I cannot see a reason why
> any contributor would object to this: as said, it implements the
> same intent as the GFDL in a way that is workable in practice.
> Therefore, I am essentially looking for a consensus.
>
> I have prepared a draft Terms of Use that explains how www.myhdl.org
> would have to be used with the proposed license, based on the
> corresponding text from wikipedia:
>
> http://www.myhdl.org/doku.php/terms_of_use
>
> I will wait a few days to see if there are any major or
> fundemental objections. I will treat absence of feedback
> as silent agreement, but I will not go ahead if there
> are major contributors who disagree.

On the occasion of an upgrade of dokuwiki, and given that
there were no objections, I have now changed the license
of myhdl.org to CC BY-SA. I have also added a Terms of Use
link in the sidebars.

Jan

-- 
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

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

Re: [myhdl-list] MEP guidelines

[Jan C. <jan...@mu...>]

On 19/05/11 11:12, Jan Decaluwe wrote:
>    . . .
>>
>> If someone get's a new account to the wiki, that user will get an entry
>> in the projects:intro page - edited by the admin. That entry is a link
>> to 'users:<login name>'. The new user can only edit content under the
>> namespace 'users:<login name>'. That way it is possible to contribute to
>> the page, but restrict editing access to users namespace.
>
> All possible and meaningful, but even then, it's reasonable to
> assume that one has to complete a significant MyHDL project before
> being able to contribute meaningful content. I think I'll still
> ask for that first.

I'll volunteer to try to become a well-mannered contributor:)

At some point I'd like to post details of the j1 SOC project. I 
would only post working code, and host development elsewhere.

The expected source code size for working demo is:
Software: cross compiler & support tools    25kB
Hardware: source & test - MyHDL             25kB

Details of original Verilog based project are here:
http://www.excamera.com/sphinx/fpga-j1.html

Jan Coombs
-- 

[myhdl-list] Stackoverflow

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

Thought this might be of interest for others on this mailing list.

http://stackoverflow.com/questions/6044930/difference-between-yield-statement-in-python-and-myhdl

Chris

Re: [myhdl-list] MEP guidelines

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

On 5/19/2011 5:12 AM, Jan Decaluwe wrote:
> On 05/18/2011 09:53 PM, Günter Dannoritzer wrote:
>> On 18.05.2011 20:58, Jan Decaluwe wrote:
>> ...
>>>
>>> My conclusion: wiki's don't work, at least not the "democratic"
>>> access rights part of them.
>>
>> I believe it is a combination of things, namely:
>>
>> - the amount of content in the wiki
>> - the size of the community that takes part in editing it
>> - the ratio of advanced to beginner level
>> - the sensibility vs boldness of beginner level to know when to edit or
>> when not to edit content
>>
>> I believe, with the amount of content in the MyHDL wiki and the size of
>> the community taking part in editing it, it is wise to restrict access.
>> As a single bold beginner can have a big impact and the social aspect of
>> a big community does not work here. Fortunately, dokuwiki has a good way
>> to do restriction with access rights.
>>
>>>
>>> As a result, I'm changing the policy to grant edit access to
>>> myhdl.org. Instead of a simple request, I will require a
>>> demonstrated level of experience with MyHDL. I have already
>>> implemented this by restoring content as appropriate, updating
>>> the page about access request, and updating the existing
>>> access rights.
>>
>> I think a good idea would be, to grant new users a user space where they
>> are allowed to edit. There they could demonstrate the level of
>> experience, without changing other content of the page.
>>
>> Here is an idea to extend this thought.
>>
>> At the moment there is in the top side bar an entry for "Users&
>> Projects". Following that link will lead to the "intro" page in the
>> projects namespace, with entries of users of MyHDL. Looking at the links
>> there, I see some people have just edited their content in the
>> 'projects' namespace - like myself. Others have done a mix. Some content
>> is in the 'projects' namespace. Other is in the 'users' namespace.
>>
>> Here is an idea for beginners.
>>
>> If someone get's a new account to the wiki, that user will get an entry
>> in the projects:intro page - edited by the admin. That entry is a link
>> to 'users:<login name>'. The new user can only edit content under the
>> namespace 'users:<login name>'. That way it is possible to contribute to
>> the page, but restrict editing access to users namespace.
>
> All possible and meaningful, but even then, it's reasonable to
> assume that one has to complete a significant MyHDL project before
> being able to contribute meaningful content. I think I'll still
> ask for that first.
>
>

Sounds perfectly reasonable to me.

Chris

Re: [myhdl-list] MEP guidelines

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

On 05/18/2011 09:53 PM, Günter Dannoritzer wrote:
> On 18.05.2011 20:58, Jan Decaluwe wrote:
> ...
>>
>> My conclusion: wiki's don't work, at least not the "democratic"
>> access rights part of them.
>
> I believe it is a combination of things, namely:
>
> - the amount of content in the wiki
> - the size of the community that takes part in editing it
> - the ratio of advanced to beginner level
> - the sensibility vs boldness of beginner level to know when to edit or
> when not to edit content
>
> I believe, with the amount of content in the MyHDL wiki and the size of
> the community taking part in editing it, it is wise to restrict access.
> As a single bold beginner can have a big impact and the social aspect of
> a big community does not work here. Fortunately, dokuwiki has a good way
> to do restriction with access rights.
>
>>
>> As a result, I'm changing the policy to grant edit access to
>> myhdl.org. Instead of a simple request, I will require a
>> demonstrated level of experience with MyHDL. I have already
>> implemented this by restoring content as appropriate, updating
>> the page about access request, and updating the existing
>> access rights.
>
> I think a good idea would be, to grant new users a user space where they
> are allowed to edit. There they could demonstrate the level of
> experience, without changing other content of the page.
>
> Here is an idea to extend this thought.
>
> At the moment there is in the top side bar an entry for "Users&
> Projects". Following that link will lead to the "intro" page in the
> projects namespace, with entries of users of MyHDL. Looking at the links
> there, I see some people have just edited their content in the
> 'projects' namespace - like myself. Others have done a mix. Some content
> is in the 'projects' namespace. Other is in the 'users' namespace.
>
> Here is an idea for beginners.
>
> If someone get's a new account to the wiki, that user will get an entry
> in the projects:intro page - edited by the admin. That entry is a link
> to 'users:<login name>'. The new user can only edit content under the
> namespace 'users:<login name>'. That way it is possible to contribute to
> the page, but restrict editing access to users namespace.

All possible and meaningful, but even then, it's reasonable to
assume that one has to complete a significant MyHDL project before
being able to contribute meaningful content. I think I'll still
ask for that first.


-- 
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

Re: [myhdl-list] MEP guidelines

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

On 05/18/2011 11:11 PM, Günter Dannoritzer wrote:
> On 18.05.2011 22:57, Christopher Felton wrote:
> ...
>>
>> I like that idea.  One it helps the mechanics, I am one of those mixed
>> contributors :)
>
> ... just to make sure, I might have worded that bad. I did not mean that
> mixing the namespaces for content is something bad. I was not even aware
> that there is a users namespace until later I stumbled upon a link. That
> is the only reason why I have my content all under the projects
> namespace. ;)

No worries - the reason for the two namespaces is simply that
originally some people started adding content under "users",
other under "projects". But it's really the same type of info,
so what I did is join it and link the "users" sidebar to
the "projects" sidebar to make things transparent. Slightly
confusing when you look at the namespace details, I agree.


-- 
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

Re: [myhdl-list] MEP guidelines

[Günter D. <dan...@we...>]

On 18.05.2011 22:57, Christopher Felton wrote:
...
> 
> I like that idea.  One it helps the mechanics, I am one of those mixed 
> contributors :)

... just to make sure, I might have worded that bad. I did not mean that
mixing the namespaces for content is something bad. I was not even aware
that there is a users namespace until later I stumbled upon a link. That
is the only reason why I have my content all under the projects
namespace. ;)

Guenter

Re: [myhdl-list] MEP guidelines

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

<snip>
>
> Here is an idea for beginners.
>
> If someone get's a new account to the wiki, that user will get an entry
> in the projects:intro page - edited by the admin. That entry is a link
> to 'users:<login name>'. The new user can only edit content under the
> namespace 'users:<login name>'. That way it is possible to contribute to
> the page, but restrict editing access to users namespace.
>
> Cheers,
>
> Guenter
>

I like that idea.  One it helps the mechanics, I am one of those mixed 
contributors :)

Users can create projects, content, proposed, MEPs, etc in the 
user-space.   As an example, proposed MEPs can be started in the 
user-space and at some point they can be moved to the official area. 
This assumes all official content supersedes user content.  This adds 
more work to the maintainer but will give users the freedom to add 
content. And it clear what content is user additions vs. myhdl content.

Chris

Re: [myhdl-list] MEP guidelines

[Günter D. <dan...@we...>]

On 18.05.2011 20:58, Jan Decaluwe wrote:
...
> 
> My conclusion: wiki's don't work, at least not the "democratic"
> access rights part of them.

I believe it is a combination of things, namely:

- the amount of content in the wiki
- the size of the community that takes part in editing it
- the ratio of advanced to beginner level
- the sensibility vs boldness of beginner level to know when to edit or
when not to edit content

I believe, with the amount of content in the MyHDL wiki and the size of
the community taking part in editing it, it is wise to restrict access.
As a single bold beginner can have a big impact and the social aspect of
a big community does not work here. Fortunately, dokuwiki has a good way
to do restriction with access rights.

> 
> As a result, I'm changing the policy to grant edit access to
> myhdl.org. Instead of a simple request, I will require a
> demonstrated level of experience with MyHDL. I have already
> implemented this by restoring content as appropriate, updating
> the page about access request, and updating the existing
> access rights.

I think a good idea would be, to grant new users a user space where they
are allowed to edit. There they could demonstrate the level of
experience, without changing other content of the page.

Here is an idea to extend this thought.

At the moment there is in the top side bar an entry for "Users &
Projects". Following that link will lead to the "intro" page in the
projects namespace, with entries of users of MyHDL. Looking at the links
there, I see some people have just edited their content in the
'projects' namespace - like myself. Others have done a mix. Some content
is in the 'projects' namespace. Other is in the 'users' namespace.

Here is an idea for beginners.

If someone get's a new account to the wiki, that user will get an entry
in the projects:intro page - edited by the admin. That entry is a link
to 'users:<login name>'. The new user can only edit content under the
namespace 'users:<login name>'. That way it is possible to contribute to
the page, but restrict editing access to users namespace.

Cheers,

Guenter

Re: [myhdl-list] MEP guidelines

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

On 05/06/2011 05:03 PM, Günter Dannoritzer wrote:
> Hi,
>
> I would like to suggest, adding some guidelines about the MEP process.
> Seeing that the text of an already implemented MEP got changed, I think
> it would be helpfull to have some guidelines how the MEP process is
> intended.
>
> I think, that especially an already implemented MEP should be kept for
> reference as is and not changed later in time. There is the chance, that
> the original notion of the implementation gets altered by editing the
> MEP it originated from.

Now that we have the guidelines, let me comment on that particular
edit itself, which I found very problematic.

First, the document in question was clearly marked as "Final". I think
that makes it obvious that one should be very careful when editing, regardless
of any guidelines.

Second, the edit was about an issue that the editor was clearly
struggling with. He had received several references, as well as
repeated advice to study an introductory text to HDL-based design.
Still, he felt confident enough to make a drastic edit.

Most importantly, the edit content was completely wrong, both in the
details and in the concepts.

My conclusion: wiki's don't work, at least not the "democratic"
access rights part of them.

As a result, I'm changing the policy to grant edit access to
myhdl.org. Instead of a simple request, I will require a
demonstrated level of experience with MyHDL. I have already
implemented this by restoring content as appropriate, updating
the page about access request, and updating the existing
access rights.

Jan

-- 
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

Re: [myhdl-list] MEP guidelines

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

Guenter:

I notice no objections, and for me this is fine also.
I propose to add this info, so that the rules are explicitly
clear, and because some MEPs need maintenance.

Jan


On 05/10/2011 04:46 PM, Günter Dannoritzer wrote:
> On 10.05.2011 09:59, Jan Decaluwe wrote:
>> On 05/06/2011 05:03 PM, Günter Dannoritzer wrote:
>>> Hi,
>>>
>>> I would like to suggest, adding some guidelines about the MEP process.
>>> Seeing that the text of an already implemented MEP got changed, I think
>>> it would be helpfull to have some guidelines how the MEP process is
>>> intended.
>>
>> Good idea. Looking at your draft however: without BDFL powers (for me)
>> it's a no-go as for as I'm concerned, and also unworkable in practice
>> I believe.
>
> Yes, I have been thinking about that. Referring to your other post, I
> also agree, not to make this process too complicated.
>
> My suggestion would be, that a MEP can only achieve the final state by
> approval of you. That keeps the process simple and not add additional
> states like 'Rejected'.
>
> I updated the draft and added your case in point to it. So the updated
> version of the guidelines would be like this:
>
> ---------
> MEP stands for MyHDL Enhancement Proposal. A MEP is a design document
> providing information to the MyHDL community, or describing a new
> feature for MyHDL. The MEP should provide a concise technical
> specification of the feature and a rationale for the feature.
>
> We intend MEPs to be the primary mechanisms for proposing new features,
> for collecting community input on an issue, and for documenting the
> design decisions that have gone into MyHDL. The MEP author is
> responsible for building consensus within the community and documenting
> dissenting opinions.
>
> MEPs are maintained on the MyHDL wiki page. The page history resembles
> the development history of the document.
>
> Main responsibility of a MEP lies with its author. Before opening a new
> MEP, its idea should be discussed on the MyHDL mailing list.
>
> In the development phase, the MEP gets the status "Draft" assigned.
> Fully developed and provided with a functional implementation, the MEP
> can get the status "Final", documenting that the content of the MEP is
> ready to be implemented into MyHDL.
>
> The right to change the status of a MEP from "Draft" to "Final" belongs
> exclusively to Jan Decaluwe.
>
> Once the MEP has the status "Final" and its content got added to the
> source code, the MyHDL version will be added to the MEP document. From
> this time on, the text of the document will be frozen. A "Final" MEP
> should not be changed, except for spelling mistakes or language
> corrections from a neutral proofreader. It is intended to document the
> MyHDL development history for experts. The MyHDL language documentation
> for users is in the manuals.
>
> In case the functionality described in a MEP needs to be altered or
> extended, a new MEP shall be created, describing the new desired
> implementation. The new MEP will live through the same steps as the MEP
> process describes. The new MEP should cross reference the MEP its
> implementation is based on.
>
> In case the new MEP will replace an implementation of an existing MEP,
> the old MEP will achieve the status "Deprecated" as soon as the new MEP
> achieves the status "Final". Both MEPs should cross reference each other.
>
> ------------
>
> Hope this did not become too complicated :)
>
> If there are no objections to these guidelines, I will put them on the
> wiki page.
>
> Cheers, Guenter
>
> ------------------------------------------------------------------------------
> 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

Re: [myhdl-list] MyHDL + CalTech + JPL + You

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

Too, early, can't type straight, D'oh.

[myhdl-list] MyPython + CalTech + JPL + You

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

If there are any CalTech students that are interested in MyHDL and radio 
astronomy you might want to check out this summer research program.

http://announcements.surf.caltech.edu/index.cfm?event=ViewAODetail&id=683&inFrame=&type=SURF&formType=AO_CIT

I actually didn't see a date on it, so I don't know if it is for this 
year or not?

Chris

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

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

<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

[myhdl-list] Wrap-around support in MyHDL

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

Recently, there has been a lot of activity regarding
"wrap-around" types. I have looked at the proposals. My own
thoughts on the matter have evolved also. Here is my
analysis and proposal.

Background
----------

One my main critiques on the mainstream use of Verilog/VHDL
is the focus on "representational" types for integer
arithmetic. In other words, the starting point is a bit
vector representation to which an integer interpretation is
added later. The hidden assumption is that this is necessary
for implementation efficiency.

I believe that MyHDL has convincingly demonstrated that
there is a better way by taking a top-down perspective. In
MyHDL, integer arithmetic simply works as expected. The
convertor takes care of representational details as required
by the Verilog/VHDL target.

This is not just a semantic discussion. In MyHDL, you don't
need castings, manual sign extentions or resizings to get
integer arithmetic to work. In Verilog/VHDL, it's the name
of the game. Best of all, there is no implementation
efficiency price to pay.

Understandably, I would like to use a similar approach when
considering to introduce new types: first look at the
modelling aspect, that is, how a designer would prefer to
use a type, and only then move to conversion and efficiency
concerns.

Wrap-around type proposals
--------------------------

There is no question that there is a genuine need for the
elegant modeling of wrap-around behavior in hardware
modeling. The question is whether this is important enough to
warrant dedicated language support.

In the past, I have suggested that this need may not be that
high. For example, in the common case of an incrementer (or
decrementor), it is often necessary to decode the end count
anyway:

     if count == N:
        count.next = 0
        # decode action
     else:
         count.next = count + 1
    
However, I would agree that even then it could be clearer to
keep the incrementer description separate from the decoding:

     if count == N:
         # decode action

     count.next = (count + 1) % N

I have also argued that the modulo operator offers an
explicit and elegant high-level solution to describe
wrap-around behavior in a one-liner. Chris F has pointed out
that this doesn't work for the case of a signed integer. He
has proposed a .wrap() method as a solution.

Both the modulo operator and a wrap() method have some
disadvantages. Through they are explicit in good Python
style, there is a conflict with another good principle: DRY
(Don't Repeat Yourself). If wrap-around is the desired
behavior, it is probably a property of an object and its
type, not of a particular assignment.

The two techniques have another problem that I have
successfully managed to keep out of spotlights in earlier
discussions :-) I believe a common use case would be an
incrementor/decrementer as an intbv variable, using augmented
assignment:

    count += 1

The two techniques above cannot support this.

Tom D has proposed a 'wrap' parameter to the intbv
constructor, with default False. When True, it would modify
the assignment behavior as desired.

This proposal addresses the issues mentioned above, but has
some problems itself.  An additional parameter makes object
construction heavier. Also, the use of a default value
suggests that one type of behavior is the rule, and the
other the exception.  I don't like the idea of modifying the
fundamental behavior of a type in such a way.  If
wrap-around behavior is considered important enough to
warrant direct language support, it should be as easy to use
as other behaviors.

Finally, a parameter cannot support the following conversion
trick:

    a = intbv(0)[N:]

to construct a "N bits wide" positive intbv, even though
such "closer to hardware" objects are probably popular
candidates for wrap-around behavior.

The most important problem that I have with the current
proposals is still elsewhere: they go against the
MyHDL-specific philosophy that I outlined in the
background. The starting point of the proposals is that
wrap-around behavior will only supported on "full range"
bit-vectors. This is likely influenced by implicit
assumptions of efficient hardware implementation.

In my modeling work, I use wrap-around counters all the
time. However, more often than not, their bounds are not
powers of 2. I suspect this is the same for many
designers. As I have argued earlier, we should look at
modeling first, and at hardware efficiency later. In
previous cases, such as the intbv type, we have been able to
achieve much easier modeling without having to pay a price
in efficiency.

Ada modular types
-----------------

Recently I got introduced to Ada modular types. These are
natural integer types with wrap-around behaviour.

The wrap-around behavior of modular types is based on the
sound mathematical concept of modulo arithmetic. Therefore,
the modulus is not limited to powers of 2.

The rationale behind modular types is interesting. For
example:

"The modulus of a modular type need not be a power of two
although it often will be. It might, however, be convenient
to use some obscure prime number as the modulus perhaps in
the implementation of hash tables."

[http://www.adaic.org/resources/add_content/standards/95rat/rat95html/rat95-p2-3.html]

Another resource says:

"Modular types don't need to be powers of two, but if they
are the Ada compiler will select especially efficient
operations to implement them."

[http://www.dwheeler.com/lovelace/s17sf.htm]

This is exactly the kind of reasoning I'm looking for. Ada
considers module arithmetic important enough to warrant
direct language support, but in the general, mathematically
sound sense. On the other hand, it recognizes that
powers of 2 bounds are very important. There is actually a
predefined package with power of 2 based subtypes. Moreover,
the compiler can select "especially efficient operations" to
implement them.

Interestingly, Ada even defines and/or/xor bit operations on
modular types, unlike other integer types. Apparently it
chooses modular types for this purpose because their
"unsigned" interpretation poses less problems than bit
operations on "signed" representations. In any case, the
dual nature of the type - both high-level and
representation-friendly - is similar to what MyHDL does with
the intbv. When reading all this, I can only conclude that
VHDL lost a big opportunity by forgetting about its origins.

I believe the Ada example is the route to follow. Two issues
still have to be addressed:

1) Ada modular types are restricted to natural values.
We want to support integer values.
2) Ada modular types are types, which means that conversions
would be needed to let them work with other integer-like
types. (I am not entirely sure of this statement.)

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.


-- 
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

Re: [myhdl-list] intbv wrap

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

On 5/11/2011 9:54 AM, Jan Decaluwe wrote:
> On 05/11/2011 04:01 PM, Christopher Felton wrote:
>>
>> On 5/11/2011 7:31 AM, Ben wrote:
>>> Hi Chris,
>>>
>>> I am following your struggle with this feature with great interest, as
>>> I do think this would be an interesting addition to MyHDL, however, as
>>> an hypothetical future extension to MyHDL, I think this would deserve
>>> a MEP ... For now, If I want to understand your design decisions, I
>>> have to dig into my mails and look for the relevant part. I for one
>>> have for instance a question about the restrictions you enforce. See
>>> below.
>> Here is the original MEP I wrote.  It is not complete and has not been
>> updated based on the conversations had here.  Also, this MEP simply
>> exists in my user space right now.
>>
>> http://www.myhdl.org/doku.php/user:cfelton:projects:wrap
>>
>> I will try and update the MEP based on the latest developments when time
>> permits.  More comment below.
>>>
>>> On Tue, May 10, 2011 at 13:27, Christopher Felton
>>> <chr...@gm...>    wrote:
>>>> I made a couple of minor adjustments to this patch.
>>>>
>>>>     1. Made the wrap function private (_wrap) and moved _wrap to __wrap.  The
>>>> wrap function should not be used directly because it will not covert
>>>> correctly.  I think for a future (todo) enhancement the wrap function can be
>>>> made public and handled by the converter.  This is an involved modification.
>>>>     For now I think it is good to advertise the wrap function was private.
>>>
>>> I don't really understand the reason of such an enforcement on min and
>>> max for the wrapping. Let's be for a moment the devil's advocate and
>>> say I want my intbv to be between -3 and 12. Why would MyHDL prevent
>>> me to have it wrapped ?
>>
>> The reason is, we want to model natural behavior of a n-bit word.  An
>> n-bit word automatically wraps, by truncating the most-significant bits,
>> when assigned.  We want to prevent the automatic wrap in the example
>> because additional logic is required.  This is the same for the
>> saturate.  This enhancement is simply trying to add the natural
>> occurring wrap of a n-bit binary word.  To model this behavior correctly
>> the min and max need to be the full range of the binary word.
>
> What is "natural" depends entirely on your perspective. If your
> perspective is representation, I agree. But if your perspective is
> modeling in terms of modulo arithmetic, the restrictions would be
> incomprehensible.

So, "natural" was a wrong choice of words, inherent should have been used.

>
> I really think MyHDL should make a difference with Verilog/VHDL here.
> We should concentrate on modeling first, and only then on
> conversion/synthesizability. As the intbv example shows, sometimes
> there isn't even a price to pay! Moreover, we can always impose
> additional restrictions for convertiblity, but we may also find
> ways to implement more powerful solutions than with Verilog/VHDL.

In general I think this is a good approach, adding more modeling 
features.  But I think MyHDL already provides kick-ass "framework" for 
building all kinds of modeling.  If someone wanted an _interesting_ 
behavior, a derived class with the intbv as the base class, can easily 
be created.  And the user knows this will *not* be convertible (some 
cases it will be convertible).

I am not sure about adding non-convertible features to the intbv class. 
  I think it could be confusing.

I would rather see an approach where a derived class with the new 
modeling is added; to simplify use for developers.  And when or if, it 
has a clear path for conversion then it can be added to the intbv class. 
  I think this would limit confusion and disappointment when trying to 
convert a design.  Also, it adds a little agility by adding classes for 
just for modeling.  These classes can be documented in the manual, etc.

In my mind, the current wrap implementation would be added to the intbv 
to capture the inherent behavior of an n-bit word.  And the arbitrary 
wrapping could be added to an enhanced modeling class.

Chris

Re: [myhdl-list] intbv wrap

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

On 05/11/2011 04:01 PM, Christopher Felton wrote:
>
> On 5/11/2011 7:31 AM, Ben wrote:
>> Hi Chris,
>>
>> I am following your struggle with this feature with great interest, as
>> I do think this would be an interesting addition to MyHDL, however, as
>> an hypothetical future extension to MyHDL, I think this would deserve
>> a MEP ... For now, If I want to understand your design decisions, I
>> have to dig into my mails and look for the relevant part. I for one
>> have for instance a question about the restrictions you enforce. See
>> below.
> Here is the original MEP I wrote.  It is not complete and has not been
> updated based on the conversations had here.  Also, this MEP simply
> exists in my user space right now.
>
> http://www.myhdl.org/doku.php/user:cfelton:projects:wrap
>
> I will try and update the MEP based on the latest developments when time
> permits.  More comment below.
>>
>> On Tue, May 10, 2011 at 13:27, Christopher Felton
>> <chr...@gm...>   wrote:
>>> I made a couple of minor adjustments to this patch.
>>>
>>>    1. Made the wrap function private (_wrap) and moved _wrap to __wrap.  The
>>> wrap function should not be used directly because it will not covert
>>> correctly.  I think for a future (todo) enhancement the wrap function can be
>>> made public and handled by the converter.  This is an involved modification.
>>>    For now I think it is good to advertise the wrap function was private.
>>
>> I don't really understand the reason of such an enforcement on min and
>> max for the wrapping. Let's be for a moment the devil's advocate and
>> say I want my intbv to be between -3 and 12. Why would MyHDL prevent
>> me to have it wrapped ?
>
> The reason is, we want to model natural behavior of a n-bit word.  An
> n-bit word automatically wraps, by truncating the most-significant bits,
> when assigned.  We want to prevent the automatic wrap in the example
> because additional logic is required.  This is the same for the
> saturate.  This enhancement is simply trying to add the natural
> occurring wrap of a n-bit binary word.  To model this behavior correctly
> the min and max need to be the full range of the binary word.

What is "natural" depends entirely on your perspective. If your
perspective is representation, I agree. But if your perspective is
modeling in terms of modulo arithmetic, the restrictions would be
incomprehensible.

I really think MyHDL should make a difference with Verilog/VHDL here.
We should concentrate on modeling first, and only then on
conversion/synthesizability. As the intbv example shows, sometimes
there isn't even a price to pay! Moreover, we can always impose
additional restrictions for convertiblity, but we may also find
ways to implement more powerful solutions than with Verilog/VHDL.

>
> This is a little confusing because the intbv lets you assign arbitrary
> min and max for design checking (which is a good thing).  But note, this
> checking (bound checking) is only enforced during the design, MyHDL
> simulations.
>
> To do the wrapping in your example, the logic would explicitly need to
> be added to the design.  IMO is good and why I think the wrap() will be
> public in the future once direct use of the function is convertible.
>
> This enhancement is intended to handle the generic wrap case.  That
> should not be part of the intbv object.  But rather model the inherent
> wrapping of a bit-vector.
>
>>
>>>
>>>    2. Added myrange to a slot, _range.
>>
>> This is a coding style decision. This _range is used at only one
>> place, and completely redundant with the existence of _nrbits. I don't
>> think it deserves a slot.
>>
>>>
>>>    3. Modified a couple comments.
>>>
>>
>> BTW, did you got the testsuite to run ? To run the "core" one, I don't
>> think you would need py.py. It uses unittest, which is included in
>> your python distribution.
>
> Yes, your additions are perfect and IMO correct.  I reran the tests in
> the core test suite and they are part of the patch.  Thanks again for
> doing this work!
>
>>
>> Best Regards
>> Benoît
>>
>> ------------------------------------------------------------------------------
>> 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
>
>
>
> ------------------------------------------------------------------------------
> 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

Re: [myhdl-list] intbv wrap

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

On 05/11/2011 02:31 PM, Ben wrote:
> Hi Chris,
>
> I am following your struggle with this feature with great interest, as
> I do think this would be an interesting addition to MyHDL, however, as
> an hypothetical future extension to MyHDL, I think this would deserve
> a MEP ... For now, If I want to understand your design decisions, I
> have to dig into my mails and look for the relevant part. I for one
> have for instance a question about the restrictions you enforce. See
> below.
>
> On Tue, May 10, 2011 at 13:27, Christopher Felton
> <chr...@gm...>  wrote:
>> I made a couple of minor adjustments to this patch.
>>
>>   1. Made the wrap function private (_wrap) and moved _wrap to __wrap.  The
>> wrap funct ion should not be used directly because it will not covert
>> correctly.  I think for a future (todo) enhancement the wrap function can be
>> made public and handled by the converter.  This is an involved modification.
>>   For now I think it is good to advertise the wrap function was private.
>
> I don't really understand the reason of such an enforcement on min and
> max for the wrapping. Let's be for a moment the devil's advocate and
> say I want my intbv to be between -3 and 12. Why would MyHDL prevent
> me to have it wrapped ?

In the past days, I have reviewed and thought about all the proposals,
and that is exactly my most important critique. As in the intbv case,
we should consider modeling requirements first, and "efficiency" only
later. (The case of the intbv shows that sometimes you can have easier
modeling without an efficiency price to pay.)

I have also reviewed the concept behind Ada modular types more thorougly,
and I really think this is the way to follow.

I am working on an extensive review and proposal, that I will post
shortly.

>
>>
>>   2. Added myrange to a slot, _range.
>
> This is a coding style decision. This _range is used at only one
> place, and completely redundant with the existence of _nrbits. I don't
> think it deserves a slot.
>
>>
>>   3. Modified a couple comments.
>>
>
> BTW, did you got the testsuite to run ? To run the "core" one, I don't
> think you would need py.py. It uses unittest, which is included in
> your python distribution.
>
> Best Regards
> Benoît
>
> ------------------------------------------------------------------------------
> 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

Re: [myhdl-list] intbv wrap

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

On 5/11/2011 7:31 AM, Ben wrote:
> Hi Chris,
>
> I am following your struggle with this feature with great interest, as
> I do think this would be an interesting addition to MyHDL, however, as
> an hypothetical future extension to MyHDL, I think this would deserve
> a MEP ... For now, If I want to understand your design decisions, I
> have to dig into my mails and look for the relevant part. I for one
> have for instance a question about the restrictions you enforce. See
> below.
Here is the original MEP I wrote.  It is not complete and has not been 
updated based on the conversations had here.  Also, this MEP simply 
exists in my user space right now.

http://www.myhdl.org/doku.php/user:cfelton:projects:wrap

I will try and update the MEP based on the latest developments when time 
permits.  More comment below.
>
> On Tue, May 10, 2011 at 13:27, Christopher Felton
> <chr...@gm...>  wrote:
>> I made a couple of minor adjustments to this patch.
>>
>>   1. Made the wrap function private (_wrap) and moved _wrap to __wrap.  The
>> wrap function should not be used directly because it will not covert
>> correctly.  I think for a future (todo) enhancement the wrap function can be
>> made public and handled by the converter.  This is an involved modification.
>>   For now I think it is good to advertise the wrap function was private.
>
> I don't really understand the reason of such an enforcement on min and
> max for the wrapping. Let's be for a moment the devil's advocate and
> say I want my intbv to be between -3 and 12. Why would MyHDL prevent
> me to have it wrapped ?

The reason is, we want to model natural behavior of a n-bit word.  An 
n-bit word automatically wraps, by truncating the most-significant bits, 
when assigned.  We want to prevent the automatic wrap in the example 
because additional logic is required.  This is the same for the 
saturate.  This enhancement is simply trying to add the natural 
occurring wrap of a n-bit binary word.  To model this behavior correctly 
the min and max need to be the full range of the binary word.

This is a little confusing because the intbv lets you assign arbitrary 
min and max for design checking (which is a good thing).  But note, this 
checking (bound checking) is only enforced during the design, MyHDL 
simulations.

To do the wrapping in your example, the logic would explicitly need to 
be added to the design.  IMO is good and why I think the wrap() will be 
public in the future once direct use of the function is convertible.

This enhancement is intended to handle the generic wrap case.  That 
should not be part of the intbv object.  But rather model the inherent 
wrapping of a bit-vector.

>
>>
>>   2. Added myrange to a slot, _range.
>
> This is a coding style decision. This _range is used at only one
> place, and completely redundant with the existence of _nrbits. I don't
> think it deserves a slot.
>
>>
>>   3. Modified a couple comments.
>>
>
> BTW, did you got the testsuite to run ? To run the "core" one, I don't
> think you would need py.py. It uses unittest, which is included in
> your python distribution.

Yes, your additions are perfect and IMO correct.  I reran the tests in 
the core test suite and they are part of the patch.  Thanks again for 
doing this work!

>
> Best Regards
> Benoît
>
> ------------------------------------------------------------------------------
> 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

Re: [myhdl-list] intbv wrap

[Ben <ben...@gm...>]

Hi Chris,

I am following your struggle with this feature with great interest, as
I do think this would be an interesting addition to MyHDL, however, as
an hypothetical future extension to MyHDL, I think this would deserve
a MEP ... For now, If I want to understand your design decisions, I
have to dig into my mails and look for the relevant part. I for one
have for instance a question about the restrictions you enforce. See
below.

On Tue, May 10, 2011 at 13:27, Christopher Felton
<chr...@gm...> wrote:
> I made a couple of minor adjustments to this patch.
>
>  1. Made the wrap function private (_wrap) and moved _wrap to __wrap.  The
> wrap function should not be used directly because it will not covert
> correctly.  I think for a future (todo) enhancement the wrap function can be
> made public and handled by the converter.  This is an involved modification.
>  For now I think it is good to advertise the wrap function was private.

I don't really understand the reason of such an enforcement on min and
max for the wrapping. Let's be for a moment the devil's advocate and
say I want my intbv to be between -3 and 12. Why would MyHDL prevent
me to have it wrapped ?

>
>  2. Added myrange to a slot, _range.

This is a coding style decision. This _range is used at only one
place, and completely redundant with the existence of _nrbits. I don't
think it deserves a slot.

>
>  3. Modified a couple comments.
>

BTW, did you got the testsuite to run ? To run the "core" one, I don't
think you would need py.py. It uses unittest, which is included in
your python distribution.

Best Regards
Benoît