Re: [myhdl-list] Mixing MyHDL-generated source with other code

[Christopher F. <chr...@gm...>]

On 5/5/2015 3:23 PM, Ben Reynwar wrote:
> Hi again,
>
> One of the things I'm trying to work out as I get acquainted with MyHDL is
> how best to mix MyHDL-generated code with existing code.  This can be
> reduced to two basic problems:
>
> 1) Be able to generate VHDL/verilog with a predictable interface so it can
> used by a non-MyHDL module.
> 2) Be able to generate VHDL/verilog containing an instantiation of a module
> that is not specified by MyHDL.

Yes, if I understand your 1 and 2, I would refer
to it as:

   1. Verilog/VHDL top-levels, including MyHDL
      generated IP.

   2. MyHDL top-level, including Verilog/VHDL
      modules in the converted MyHDL design.

The first, is simply creating blocks in MyHDL and
converting them individually and including them
in an existing flow.  This method seems preferred
for those that use a lot of vendor IP and for
early adoption.  You can still use MyHDL for all
verification.

The second, if you are verifying the MyHDL before
conversion (highly recommended) you have to create
functional models to represent the behavior, then
you can use verilog_code and vhdl_code to instantiate
the V* module/component.  The process should be
seamless :)

>
> For (1) it seems to mostly work out of the box.  Sometimes I find that the
> `_name` property on the signal has not been forced to match the function
> argument name on the top module.  But I'm not sure if that's a bug I've
> introduced myself in my local copy.

You might be venturing into areas that haven't been
explored a whole lot.

If you have a module with ports:

    def my_module(a, b, c d):

and you convert the module using Signals, the names of
the ports will be: a, b, c, d.

If you are using interfaces (and multiple levels of
interfaces) that might not hold.  I think this is
what you might be eluding to?  This might be worth
discussion but is somewhat independent of this thread.

>
> For (2) I can get close using the `vhdl_instance` property but that seems
> like it's more for generating separate VHDL files from MyHDL rather than
> for interfacing with non-MyHDL modules.  The things that make this
> difficult to use are that it assumes an architecture named 'MyHDL' and that
> it does not allow for generic parameters.  The simplest way to get round
> this would be to default to not specifying the architecture and interpret a
> parameter called 'architecture' to be specifying that.  In a similar manner
> a parameter called 'parameters' could be used as the generic parameters.
> This would be a small, local change but would add a lot of flexibility.

The vhdl_code and vhdl_instance are what you would want
to use to have your code instantiate VHDL components.
Note, vhdl_instance is beta and not documented, it is
incomplete at this time (e.g. can't define the architecture,
it defaults to "MyHDL").

I believe others posted some examples, here is another:

https://gist.github.com/cfelton/0b12dd0725eb2decbd2a
https://gist.github.com/cfelton/0792c5823d418afee604

And here are the docs on vhdl_code and verilog_code:
http://docs.myhdl.org/en/latest/manual/conversion.html#user-defined-code

>
> Based on the fact that it's not trival to do this, I'm assuming that most
> people aren't mixing MyHDL with hand-coded Verilog and VHDL much.  Is there
> a reason for this?

Many (most when they start) are mixing.

Regards,
Chris