Re: [myhdl-list] Top level method conversion

[Henry G. <he...@ca...>]

On 24/01/15 00:06, Christopher Felton wrote:
> On 1/23/15, 4:08 PM, Henry Gomersall wrote:
>> >MEP 108 describes the conversion of top-level methods.
>> >
>> >Please forgive me for being stupid here, but I have a few questions:
>> >
>> >"top-level" in the nomenclature means the outer most collection of
>> >instances, is this correct? It is the most broad view of the design.
>> >Given the hierarchy is flattened, is this simply a conceptual
>> >convenience, or is there more to it than that? (i.e. could one manually
>> >flatten the hierarchy and end up with much the same thing, so top level
>> >would be just "all the instances"?).
> Kinda, you still need to define the top-level ports,
> somehow.
>
>   > Or does it only convey meaning in
>   > the conversion process - It is the outer most factory function?
>
> Yes, the top-level ports.

And presumably, if this was your project top-level, there would be no 
ports (as everything would be a sub-entity?).

>> >Is there a clear use case example of when the mep 108 work would be
>> >useful? In my mind, the main benefit of classes is they retain and
>> >modify state at run-time, which seems to be of little value when
>> >creating instances (at least in the convertible case), but perhaps I'm
>> >missing something?
> If you embed a top-level in a class definition then
> the top-level can be converted without a separate
> function wrapper or not including the HDL in the
> object (i.e. passing the object properties to the
> function module parameters).
>
> I have used this approach with filters.  I can have
> a filter class that I pass high level parameters,
> extract frequency response etc. and include the
> HDL in the "filter" object.  Then if I want I can
> convert (as a top-level) the HDL method in the object.
>

Ok, that makes sense. It's a pythonic convenience to manipulate 
top-level objects.

Thanks for that!

Henry