Re: [myhdl-list] Proposal: better support for hierarchy and user-defined code

[Angel E. <ang...@gm...>]

Jan Decaluwe <jan <at> jandecaluwe.com> writes:

> 
> Support for hierarchical output from conversion is a FAQ.
> 
> In a current project, I need this also, so I have been thinking
> about ways to make this easier. Here is what I came up with.
> 
> The use case I'm concentrating on is where everything is generated
> by the MyHDL convertor (no third-party code in VHDL or Verilog)
> but you still want hierarchy. Currently you can use a 2 step
> approach, using user-defined code to generate an instantation
> when converting the top-level, and then converting the
> lower-level model separately later. One issue is that you
> still have to write the instantiation code in Verilog and
> VHDL itself, which can be tedious for large interfaces.
> 
> The proposal is to keep the 2 step approach, but letting the
> convertor generate the instantiation itself upon user request.
> With some magic, it has all the info to do so, except the 
> desired instance name.

Jan, if you don't mind could you explain a bit further
whether there are technical reasons to not replicate the 
python function hierarchy when you generate the VHDL or
Verilog code? That is, why use this 2-step approach and
not simply generate hierarchy code by default? Are there
some hidden drawbacks that I don't understand? I am still
trying to fully understand how myhdl conversion works, so
maybe there is something obvious that I did not get!

However, if that is not the case, I think that having
a fully automated way of generating hierarchical code
would be really nice.

> The problem then is the user interface. Currently, we use a
> magic variable __verilog__ or __vhdl__ to request user-defined
> code insertion instead of converting. The obvious way would be to
> introduce new magic variables. However, upon investigation it
> became clear this is really not the intended use of magic
> variables. In fact, I'm now convinced that the original
> __verilog__ and __vhdl_ were a bad idea, and my plan is
> to deprecate them in favour of a better solution.
> 
> The right solution I believe is to use function attributes.
> For example, user-defined Verilog code would be done
> as follows:
> 
> def f(...):
>    ...
> 
> f.verilog_code = <template_string>.
> 
> It is also possible to control this from within the function
> itself, which is probably the typical case:
> 
> def f(.., convert):
>    ...
>    if convert:
>        f.verilog_code = None
>    else:
>        f.verilog_code = <template_string>
> 
> And now I would introduce another attribute to request
> an instantiation, by merely specifying the instance name:
> 
> def f(..., convert):
>    ...
>    f.verilog_instance = None if convert else <instance_name>

Sorry, I do not get exactly what would be the use case
for the "verilog_instance" attribute.

> Similarly, we would have vhdl_code and vhdl_instance attributes.

I think that this attribute based approach is a very 
promising. Could this be used to allow you to define 
libraries that must be used when using user generated code?

What I mean is that you could have another pair of attribures,
mamed "vhdl_libraries" and "verilog_libraries", for example, 
which you could use to define some libraries that you must add
when you generate the vhdl or verilog code (as discussed in
one of the recent threads?). Or maybe this could be used for
something even more generic (i.e. not only for library 
declarations).


> I have already pushed a changeset that supports all this to the public
> repo's. However, there are no unit tests yet for the verilog_instance
> and vhdl_instance attributes - the generated instantiations may still
> have problems. Those who can use this and want to
> help debug, thanks. I will be debugging this in the coming weeks.

I'll give this a try. As I said, this seems a much
more flexible way to define user defined code :-)

Angel