Re: [myhdl-list] MEP 107 assessment

[Tom D. <td...@di...>]

On 06/08/2012 04:11 PM, Jan Decaluwe wrote:
> 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.
Yes, I that is what I was thinking.
>
> 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.
I honestly don't know enough about this to have much of an opinion. I 
too like things as simple as they can to be effective. My thought was it 
might keep the core MyHDL simpler and push the complexity of conversion 
off to the classes. And thought that while making a class it would be 
simpler to provide direction to conversion than have conversion 
understand and convert many possible structures.

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

Are there any limitations to this as far as referencing and assignment goes?

I think that is OK. Since it is really low level work you are doing 
inside the generators and I would probably bury a lot of that inside the 
class.

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

I will have to gain some more experience and see what makes the most 
sense to me. I guess it would come down to priorities as we have 
something that works now and would 2) be the next best enhancement to add.