Re: [myhdl-list] MEP 107 assessment

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

On 06/08/2012 05:28 PM, Tom Dillon wrote:
> First let me say, I don't know much about the code that does the
> conversion but let me throw something out here.
>
> What if we limited ourselves to using a class to define the
> containers? Once in a class, could we not push off some of the
> conversion complexity to methods in the class. Basically, have some
> hooks in conversion that would allow the class to be queried about
> the conversion details.
>
> I know it is not done that way now and we are trying to make
> conversion sort of invisible to the user but this might allow more
> complex signal containers without adding to the complexity of
> conversion.

I think what you propose is to define a dedicated base class
with useful methods and require users to subclass it if they
need conversion.

I think you also refer to the fact that in MyHDL we
have tried to avoid to define such dedicated types.
For example, there are no Module, Memory or ROM objects:
we use generic Python types for the purpose.

This has definitely been a design goal, because I
believe the more general and minimalistic, the better.

However: if there is a good case to be made why a dedicated
type can significantly simplify things, I have nothing
against that in principle.

Now to this specific case. The problem is to support
conversion of attribute lookup for signals, in target
HDLs that do no have such a capability. Within the
context of how MyHDL does things there are 2 options:

1) avoid the issue by using the interpreter
to do the lookup outside of the generators

2) support attribute lookup in generator code conversion,
by supporting it in hierarchy extraction and in the
AST traversal methods that do the conversion.
The proposed mapping method is name mangling that
flattens out the lookup hierarchy.

1) is supported now, 2) requires work. Ideally,
both should be supported so that users have the choice.

The question you raise is whether a dedicated base class
would make 2) it easier. Currently, I don't see why, but I as
always I'm very open to arguments to the contrary.

Note that I have not argued that 2) is extraordinarily
complex - I don't think it is. But will require
a couple of days of intensive work, so I think the issue
is more the usual one of time, priorities, motivation,
and personal requirements.

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