Re: [myhdl-list] MEP : Signal Containers

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

<lots of snips>
> Where I inlined my responses might have made it confusing.  First, the
> reference to MEP-108 was simply to respond to your overall comment (or
> at least my interpretation) that /class methods/ be convertible.  If you
> meant /class method/ conversion would be of interest then MEP-108 is
> relevant, if not I misunderstood.

Any misunderstanding is from my end, I am a little rusty and being a 
little lazy and just asking questions to get back into the flow here.
>
> 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.
>
> 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.

yes, that is how I have been using classes thus far. I get the object 
setup the way I want it then call a function to return the logic 
(generators).


>
> MEP-108 is simple, its only intention is to enable a /class method/ the
> same as a function.  My best example of why you might want to do this is
> the following example, http://bit.ly/w95kOd.
>
> The /class method/ conversion and the /class attribute/ can be viewed as
> separate.  They can be used together but nothing says they have to be
> and the reason for the separate MEPs.  The idea of the /class
> attribute/, when it is a Signal (a.k.a  Signal container), basically
> helps manage namespace and organize collection of Signals.  The MEP-107
> for the attributes simply proposes to create a unique name for /class
> attribute/ when it is a Signal.
>
> If the example in the previous post (the wishbone) didn't illustrate how
> /class attributes/ could be used, either I am poorly explaining or we
> might have a misunderstanding what a /class attribute/ is.  I guess, I
> would refer you back to the internal bus examples I and Oscar provided.

I saw the term class attribute and thought it might be something more 
that converting signals in a class. I thought I was missing a feature 
that was being talked about.


>
> Or maybe there is confusion because it is a basic enhancement proposal
> and you are thinking it might be something more.  The use of classes to
> "contain" Signals doesn't mean a new type is created (this deeply
> depends on ones definition of *type*).  As mentioned, the class is used
> as a VHDL record or SystemVerilog struct and nothing more.  You can't
> build new types, then inherit to create yet another new type and define
> operations and behaviors on the new types.  But as a Signal container it
> still has a lot of benefit and usage in my opinion.  Hope that makes sense?

Yes, I see now.

Thanks.