myhdl-list

[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

Re: [myhdl-list] User-defined code

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

On 09/26/2011 01:18 AM, Bob Cunningham wrote:
> 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()?

No, but you'll get errors from the VHDL compiler of course :-)

  And vice-versa?  Is there
> any problem having both .vhdl_code and .verilog_code definitions?

No, that's the intention. toVHDL() and toVerilog() know where
to look.

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

Probably, but why would you?

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

Yes. This works especially well if you can use a high-level model
in MyHDL for simulation, and at the same time getting the IP
inserted when converting. Note that when you use those hooks, you
no longer have to take the conversion restrictions into account for
the model that sits alongside with the hooks. toVerilog() or toVHDL()
know when to stop converting.

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

As always in HDLs, we have two kinds for compilers: for modeling/simulation
and for synthesis. The modeling/simulation part is Ok today: you can
use it for a MyHDL centric design flow. Note that large parts of the
code, for high-level modeling and test benches, don't need to be converted
at all. (Except when using test bench conversion as an alternative to
cosimulation for verifying RTL code.)

For synthesis, it is probably unrealistic to assume that an EDA vendor
will soon be interested to support MyHDL natively. I fear we'll have
to deal with the tricky conversion issues ourselves. However, once you
accept the conversion restrictions (which are severe, but much less
so than those for synthesis) the flow can be largely automated. I
like to think of Verilog/VHDL as a "back-end format" like many others,
that is used at one particular stage of an automated flow.


> 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
>
>
> ------------------------------------------------------------------------------
>
>
All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2


-- 
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
     World-class digital design: http://www.easics.com