pkgsrc packages altered:
- cad/MyHDL-gplcver
- cad/MyHDL-iverilog
- cad/py-MyHDL
pkgsrc changes:
- Add common Makefile.common for MyHDL packages
- 0.9.0 supports now Python 3.x
- update LICENSE to gnu-lgpl-v2.1
- replace local patch in MyHDL-gplcver and use MAKE_FLAGS to enforce INCS
- set CC in MyHDL-gplcver
- setup test target in cad/py-MyHDL
- share common distinfo
- replace AUTO_MKDIRS with INSTALLATION_DIRS
- switch MASTER_SITES to GitHub
upstream changelog
==================
What’s new in MyHDL 0.9
Python 3 support
Experimental Python 3 support has been added to MyHDL 0.9. This was a major effort to modernize the code. As a result, Python 2 and 3 are supported from a single codebase.
See Python 3 Support for more info.
Interfaces (Conversion of attribute accesses)
Rationale
Complex designs often have many signals that are passed to different levels of hierarchy. Typically, many signals logically belong together. This can be modelled by an interface: an object that has a number of Signal objects as its attributes. Grouping signals into an interface simplifies the code, improves efficiency, and reduces errors.
The following is an example of an interface definition:
class Complex:
def __init__(self, min=-2, max=2):
self.real = Signal(intbv(0, min=min, max=max))
self.imag = Signal(intbv(0, min=min, max=max))
Although previous versions supported interfaces for modeling, they were not convertible. MyHDL 0.9 now supports conversion of designs that use interfaces.
The following is an example using the above Complex interface definition:
a,b = Complex(-8,8), Complex(-8,8)
c = Complex(-128,128)
def complex_multiply(clock, reset, a, b, c):
@always_seq(clock.posedge, reset=reset)
def cmult():
c.real.next = (a.real*b.real) - (a.imag*b.imag)
c.imag.next = (a.real*b.imag) + (a.imag*b.real)
return cmult
Solution
The proposed solution is to create unique names for attributes which are used by MyHDL generators. The converter will create a unique name by using the name of the parent and the name of the attribute along with the name of the MyHDL module instance. The converter will essentially replace the ”.” with an “_” for each interface element. In essence, interfaces are supported using hierarchical name expansion and name mangling.
Note that the MyHDL convertor supports interfaces, even though the target HDLs do not. This is another great example where the convertor supports a high-level feature that is not available in the target HDLs.
See also
For additional information see the original proposal mep-107.
Other noteworthy improvements
ConcatSignal interface
The interface of ConcatSignal was enhanced. In addition to signals, you can now also use constant values in the concatenation.
std_logic type ports
toVHDL() has a new attibute std_logic_ports. When set, only std_logic type ports are used in the interface of the top-level VHDL module.
Development flow
The MyHDL development flow has been modernized by moving to git and github for version control. In addition, travis has set up so that all pull requests are tested automatically, enabling continuous intergration.
Acknowledgments
The Python 3 support effort was coordinated by Keerthan Jaic, who also implemented most of if. Convertible interfaces were championed by Chris Felton, and implemented by Keerthan Jaic.
MyHDL development is a collaborative effort, as can be seen on github. Thanks to all who contributed with suggestions, issues and pull requests.
Problems found with existing distfile for eagle:
distfiles/eagle-lin32-7.4.0.run
No changes made to eagle/distinfo file.
Otherwise, existing SHA1 digests verified and found to be the same on
the machine holding the existing distfiles (morden). All existing
SHA1 digests retained for now as an audit trail.
- Add LICENSE= gnu-gpl-v2
(upstream)
- Update 0.7 to 0.8.1
Release 0.8.1 26-Aug-2014
-------------------------
Maintenance release for 0.8.
Release 0.8 20-May-2013
-----------------------
Full details about new features and changes can be found here:
http://docs.myhdl.org/en/latest/whatsnew/0.8.html
developer is officially maintaining the package.
The rationale for changing this from "tech-pkg" to "pkgsrc-users" is
that it implies that any user can try to maintain the package (by
submitting patches to the mailing list). Since the folks most likely
to care about the package are the folks that want to use it or are
already using it, this would leverage the energy of users who aren't
developers.
