Re: [myhdl-list] MEP : Signal Containers

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

On 05/19/2012 09:05 AM, Christopher Felton wrote:
> On 5/19/12 4:02 AM, Jan Decaluwe wrote:
>> On 05/18/2012 09:57 PM, Christopher Felton wrote:
>>
>>> The advantage of a class method over a function ... no advantage per se.
>>>      They both achieve the same thing in the similar manner.  But it gives
>>> the ability to use a method versus a function if someone wanted.
>> I think there has to be a much better reason than this to warrant
>> the effort to support this in conversion. There should be some feature
>> that many people find useful and that cannot reasonably done in
>> a different way. Conversion is complex enough as it is!
> Oh oh, I setup this enhancement up poorly here, doh.  In the context of
> describing hardware behavior using a class method (as proposed) or a
> python function, they will do the same thing.  So what is the benefit to
> justify the changes in the conversion code?
>
> My opinion, the benefit is that it helps organize larger more complex
> designs (yes, complex can be subjective, what is complex?).  To me this
> benefit is worth the inclusion.  In the past couple years this topic has
> surfaced a couple times.  Others do intuitively want to use a class
> method instead of a function in some cases.
>
> The changes can be diffed here (viewed),
> https://bitbucket.org/cfelton/myhdl_0.8dev_work/changeset/d61bf91023b7 .
>
> The changes are localized in two spots.  The enhancement doesn't touch a
> lot of the conversion code.  Hopefully, minimizing additional complexity
> in the conversion code.
>
> Is the concern that it will add unneeded complexity to the conversion
> code or be confusing for users?
>
>>> We have had this conversation a couple times in the past.  The current
>>> solution is to have a method that returns the generators from the
>>> function, essentially wrapping a function in a /class method/.  By
>>> allowing the /class method/ to be directly convertible would remove the
>>> need to wrap a function.
>> I don't remember - can you provide simple examples? Is the issue only
>> related to the very top level, as I MEP 108  seems to suggest, or also
>> to intermediate hierarchical levels?
> Best of my knowledge this is only an issue when the top-level is a class
> method.  It appears class methods can be buried in the hierarchy but not
> the top-level.  Which I think it self is a valid reason to add the
> feature, for completeness.

It is only a top level issue. Works fine at lower levels.

I guess I give some credit to the completeness argument when I think of 
it that way. This is really the same argument for the signal containers 
as it just makes a consistent use for top level vs lower levels.

Sorry about combining two topics again, but I guess in this sense they 
are related.