Re: [myhdl-list] MEP 107 assessment

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

On 06/09/2012 03:48 PM, Tom Dillon wrote:
> On 06/08/2012 04:11 PM, Jan Decaluwe wrote:
>> On 06/08/2012 05:28 PM, Tom Dillon wrote:

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

It is not necessarily a question of many possible structures;
it is more reusing standard types as the first choice
when there is no apparent advantage of a dedicated type:
e.g. list of Signals, tuple of ints.

Note the big advantage of standard types: you can use
the dedicated Python syntax to manipulate them.

For the case of attribute lookup, it could be different
because I currently don't see why it should matter (and
make it easier) what type the "container" object is.
Anything that supports attribute lookup (getattr) should
work, restrictions may be more work than supporting the
generic operation. But if this proves to be wrong, we
can consider a dedicated type, or a good choice of a
standard type.

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

There shouldn't. What you do with attribute lookup outside the
generator is to create a new name in the namespace where the
generator looks for objects to use. It should not matter
how these names are created.




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