Re: [myhdl-list] Inclusion of Libraries in MyHDL
Brought to you by:
jandecaluwe
From: Jan D. <ja...@ja...> - 2011-04-15 13:46:53
|
On 04/15/2011 03:13 PM, Ben wrote: > 2011/4/15 Günter Dannoritzer<dan...@we...>: >> Am 15.04.2011 09:56, schrieb Jan Decaluwe: >> ... >> >>> For clarity: it is not my intention to include design IP >>> libaries ever in MyHDL itself. Those should be different >>> (potentially competing) libraries, with an appropriate >>> license, as decided by the project. >> >> >> Would you be willing to host that library under myhdl.org or do you see >> it as something, placed at a different site? >> >> This idea hast been around on the mailing list on and off, but never >> really started to be implemented. However, looking at the wiki, there >> are already now generic functions that could go into such a library. One >> to name would be the CORDIC core. >> >> Say it would be under myhdl.org, starting from the wiki perspective, the >> documentation of the library and its cores could be under a different >> namespace. Then an extra mecurial repository could be set up for the >> source code in a similar manner as it is done for the myhdl code itself. >> >> I think setting up the structure and documenting it on the wiki might >> attract other developers to contribute. >> >> However, it would be good to setup quality guidelines to avoid >> cluttering the library with unfinished projects, as can be seen on >> opencores. > > I would propose the scheme used by mercurial with its numerous > extensions. there are two kind of them. The one integrated with > mercurial source code (living beside mercurial in the same > repository), and the other ones. The promotion to the "integrated" > status is based on the code maturity, stability, usability, and use of > the extension. What they win in being integrated is that they are then > also maintained by the core developers. At any point in time, they > will work, and won't stop working if the original maintainer isn't > interested in it any more (running their testsuite is part of > mercurial testsuite). Another big advantage is being integrated in the > mercurial documentation. > > In the same manner, external MyHDL libraries implement extra features > who don't make sense cut away from MyHDL, but MyHDL still works > perfectly fine without them. This is why, I think the same model as > mercurial extensions could be applied to MyHDL libraries. They don't > need to be integrated from day 1, but knowing that the possibility > exists would be a bonus for the contributors of those external > libraries. I think you are mixing two seperate issues. One is extensions to MyHDL itself. For example: a floating-point number class. Or Chris Felton's fix-point numbers. Those are extensions similar in nature to the mercurial extensions. They may start out separately,but eventually live under the myhdl namespace. Guenter is talking about design IP libraries. For example, a library of floating-point modules written in MyHDL. I don't want to put those under the myhdl namespace. In my mind, design IP is completely separate from the language. There is a single MyHDL, but I hope to see a lot of (potentially competing and overlapping) libraries with design IP and various licenses. 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 |