[myhdl-list] User-defined code

[Bob C. <Fl...@gm...>]

I've been scanning the myHDL manual trying to learn the limits of myHDL as an 'all-purpose' HDL, and came across the notion of user-defined code (http://www.myhdl.org/doc/current/whatsnew/0.7.html#new-method-to-specify-user-defined-code).

This brings several questions to mind:

1. If I incorporate Verilog into a myHDL file via <func>.vhdl_code, is there a way I can cause an error to be generated if an attempt is made to convert the file using toVHDL()?  And vice-versa?  Is there any problem having both .vhdl_code and .verilog_code definitions?

2. Can/should I use "<func>.verilog_code" to add Verilog synthesis pragmas to my myHDL code?

3. If I have some proven Verilog IP, can/should I wrap it in "<func>.verilog_code" so I can make it a tightly integrated part of my project?

4. Are there examples of using .verilog_code .vhdl_code other than in myhdl-0.7/myhdl/test/conversion/[toVerilog|toVHDL]/test_newcustom.py?


There are several underlying issues:

A. How best to manage a mix of generated and external Verilog and VHDL files?

In the best general case, I would like *all* Verilog and VHDL files to be dynamically generated by myHDL, and thus be treated as a disposable temporary files in the build and synthesis process.

That would require absorbing all external Verilog/VHDL IP into a myHDL files via "<func>.verilog_code" and "<func>.vhdl_code" (or a similar future mechanism).  We've been doing this for decades in the C++ community, wrapping C code with 'extern "C" { ... }' before feeding it to a C++ compiler.

Is a similar technique considered a 'best practice' for using 'legacy' HDL code in a myHDL project?  I'm very much in favor of such a policy for at least three reasons: 1) Eliminate the presence of non-temporary VHDL and Verilog files in the myHDL process (only myHDL files need tracking), 2) over time it would encourage migrating the wrapped 'legacy' code into myHDL, and 3) I can more easily use Python testbenches to test Verilog and VHDL code.


B. It may be useful for myHDL objects to be able to define which of toVerilog() or toVHDL() should be applied to themselves, rather than have this solely be an option of an external agent.  In particular, I'd like the need for 'bad' myHDL code to be present to force an error and remind the user to use the 'other' converter function.

*Feature Wish*: How about a generic "toLegacyHDL()" call that wouldaccess a system/project default conversion preferenceif a function fails to set a preference of its own (by defining either .verilog_code or .vhdl_code)?  That is, it would automatically call toVerilog() if .verilog_code is present, and toVHDL() if .vhdl_code is present.  This would be convenient when wrapping imported 'legacy' IP.  When the legacy IP has been correctly converted to myHDL, the legacy code could be retained as a comment by deleting or commenting-out the .verilog_code or .vhdl_code tag.


C. This actually keys into a much higher-level issue: Is myHDL intended to always be a pre-processor that emits Verilog and VHDL code?  Or is myHDL in principle intended to eventually support its own compiler, as a peer to VHDL, Verilog, SystemC and the other 'native' HDLs?

When I first started using C++ (way back when it was known as "C with Classes"), we had to use the AT&T / Bell Labs "cfront" preprocessor, which converted C++ code to something a C compiler could understand.  But this was a very slow and inefficient process, and it wasn't until native C++ compilers came along that the full power of C++ could be unleashed, and the language could reach its full potential.

Is there anything 'missing' in myHDL that would prevent it becoming a 'full-fledged' HDL?  If a tool vendor were to say "Let's create a myHDL RTL compiler to add to our Verilog and VHDL toolchains!", what limitations of myHDL would prevent success?


Yes, I have an ulterior motive here:  I would very much like there to one day be a world where I could create FPGA code without having to use (or learn) any HDL other than myHDL.  Based on what I've seen so far, I believe myHDL can/should be the 'top dog' in the HDL world, if only because it a) is less verbose and is more clear (to me) than either of Verilog or VHDL, and b) it unleashes the full power of Python in testbenches.

Until myHDL gets its own synthesis chain, I think it should be able to cleanly and easily 'envelop' legacy HDL code.  (Then we could wrap everything in OpenCores and make it a myHDL site!  Bwa-ha-ha-ha!)


-BobC