Jan Decaluwe jan at
Tue Mar 11 12:17:47 CET 2003

Thomas Heller wrote:
> Jan Decaluwe <jan at> writes:
> > Thomas Heller wrote:
> > > What will be the future of this package?
> >
> > I will be actively promoting/developing it in the short term, but
> > in the longer term this will depend on the amount of user interest.
> > A good sign would be if people start complaining about performance,
> > because that would mean they are actually using it <wink>.
> So let me complain that I cannot print the PDF documentation, although
> I'm not sure whether this is your fault or that of our printer ;-)

Mm - no idea what would cause that. I reused the Python flow from latex
to pdf to generate the pdf file - can you print Python pdf docs?

> >  (The bad
> > news would be that someone, perhaps me, would then have to recode
> > the package as an extension module in C.)
> >
> I may be able to help with that (if it's really required).

If the package is successful, I anticipate that it will be required
at some point.

> > First on my list is to couple the package to a HDL simulator. My
> > goal is to be able to use Python's unit test framework on hardware
> > design written in an HDL - I believe Python would make a superior HVL.
> > Unfortunately, I don't have access to any commercial simulator right
> > now - only Icarus Verilog and I'm not sure that it supports the
> > Verilog PLI completely. I'm also not yet clear on how to do it best -
> > probably the best is to run MyHDL code in slave mode without
> > time queue (delta cycles only).
> I don't know *anything* about Icarus Verilog, but isn't there a limited
> version of ModelSim in Xilinx Webpack?

Yes, but if I'm not mistaken, "limited" implies no access to the PLI.

> >
> > >Ideas I have for it include
> > > generation of VCD files to view the simulation results in graphical
> > > mode,
> >
> > Definitely possible and interesting of course, but don't count on me for
> > that one.
> >
> > >and (eventually) generating VHDL code.
> >
> > Well anticipated - it should indeed possible to generate HDL code from
> > an elaborated MyHDL description - this could be interesting for the
> > synthesizable subset for example. I guess I would tackle Verilog
> > first - as a back-end format it is just fine <wink>.
> I don' care whether this is VDHL, Verilog or whatever, as long as
> I can synthesize my hardware from it.
> Maybe I'm missing the big picture, but what would you do with
> a verified hardware description in Python (except to build the hardware
> from it?)

I subscribe to Janick Bergeron's message that the design problem is
much more verification than implementation. Therefore, my priority 
is to position Python/MyHDL as a hardware verification language (such
as e, OpenVera, Testbuilder). There should be much more to be gained
Python's high-level concepts (dynamic data types, object orientation,
framework), which are not present in Verilog or VHDL, than from mimicing
the synthesizable subset in MyHDL. 

I still call MyHDL an HDL, not an HVL, though, because implementation
definitely also be possible, and because I believe a good verification
language should be a good description language in the first place. 

> I hope you get enough interested users so that this project starts
> flying, I'm quite convinced there is enough potential in the combination
> of hardware descriptions/simulations and Python (although I always was
> quite disappointed that I didn't find anything of interest when googling
> for 'Python HDL'.
> Thanks,
> Thomas

Jan Decaluwe - Resources bvba
Losbergenlaan 16, B-3010 Leuven, Belgium
mailto:jan at

More information about the Python-list mailing list