Thread: [myhdl-list] Proposal: SignalType symbol
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Jan D. <ja...@ja...> - 2010-06-09 19:02:45
|
In the development branch 'Signal' has become a factory
function instead of a class.
I had complaints about this before, in particular from
Chris Felton. To test whether something is a Signal
instance, it currently means you have to check whether
it is a 'myhdl._Signal' (a "hidden" symbol) instead of
a 'Signal' as previously. Not really nice, a user should
never have to refer to hidden symbols.
In a project, as a user, I now have a need for this myself,
so ... :-) I want to keep the factory function Signal,
but I propose to define a visible symbol 'SignalType'
for the type. This is in line with Python conventions
for type naming. Then you could do:
from myhdl import *
...
if isinstance(a, SignalType):
...
Any remarks?
Jan
--
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
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com
|
|
From: Tom D. <TD...@Di...> - 2010-06-09 19:26:07
|
Jan,
I have lost track of the changes to MyHDL in the last year or so but
just happened to get tripped up over this a week or so ago.
I had to go into some of my old code and change:
if isinstance(x,Signal) :
to:
if isinstance(x,type(Signal(0))) :
I am assuming this is the same issue.
My question is, what advantage does a factory function bring?
I am much more familiar with classes.
Tom
On Wed, 2010-06-09 at 21:02 +0200, Jan Decaluwe wrote:
> In the development branch 'Signal' has become a factory
> function instead of a class.
>
> I had complaints about this before, in particular from
> Chris Felton. To test whether something is a Signal
> instance, it currently means you have to check whether
> it is a 'myhdl._Signal' (a "hidden" symbol) instead of
> a 'Signal' as previously. Not really nice, a user should
> never have to refer to hidden symbols.
>
> In a project, as a user, I now have a need for this myself,
> so ... :-) I want to keep the factory function Signal,
> but I propose to define a visible symbol 'SignalType'
> for the type. This is in line with Python conventions
> for type naming. Then you could do:
>
> from myhdl import *
> ...
> if isinstance(a, SignalType):
> ...
>
>
> Any remarks?
>
> Jan
>
> --
> 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
> Analog design automation: http://www.mephisto-da.com
> World-class digital design: http://www.easics.com
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
|
|
From: Jan D. <ja...@ja...> - 2010-06-09 21:00:36
|
Tom Dillon wrote:
> Jan,
>
> I have lost track of the changes to MyHDL in the last year or so but
> just happened to get tripped up over this a week or so ago.
>
> I had to go into some of my old code and change:
>
> if isinstance(x,Signal) :
>
>
> to:
>
> if isinstance(x,type(Signal(0))) :
>
> I am assuming this is the same issue.
Yes. Apparently the change was much less innocent than I
thought. (I found the problem in old project code of mine also.)
> My question is, what advantage does a factory function bring?
I hoped it provided an easy way out for me to fix
an earlier mistake of too much magic :-)
Seriously, here is the story.
Originally, I designed a Signal with this interface:
Signal(val, delay=0)
With the delay parameter you can create a Signal with
an "automatic" delay. (I don't know if many people use
this but anyway.)
The easiest way to implement the "delayed signal" behavior
is as a Signal subclass:
class DelayedSignal(Signal):
...
The idea is that the user shouldn't need to worry that
this is technically a different class (albeit a subclass):
all he sees is the Signal interface.
However, this means that the Signal constructor had to
construct either a Signal or a DelayedSignal depending
on a parameter of the constructor ... Believe it or not,
but you can do this in Python using the __new__ method.
However, now I am introducing all kinds of other Signal
subclasses (ShadowSignal et all) and this becomes really
confusing. This design choice was a mistake in the
first place.
The right thing to do is to decouple the classes from
the functional interface that creates the required
objects: hence the factory function. This does the
same without magic, expect that its name is no longer
available to refer to the type of the objects.
Hence, my proposal to create dedicated symbols as needed
for myhdl types, named in line with the Python convention.
Jan
--
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
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com
|
|
From: Tom D. <TD...@Di...> - 2010-06-09 21:36:30
|
Jan, OK, I think I get it now. Your factory function Signal() must return the correct class object based upon the parameters passed to it. So Signal is just a function now that returns a class object so there is no such thing as an instance of it. That is confusing, especially when you assume that Signal was a class. I would say the SignalType solution is good. Just out of curiosity, how do you define that SignalType symbol. Tom |
|
From: Jan D. <ja...@ja...> - 2010-06-09 22:25:23
|
Tom Dillon wrote: > Jan, > > OK, I think I get it now. > > Your factory function Signal() must return the correct class object > based upon the parameters passed to it. > > So Signal is just a function now that returns a class object so there is > no such thing as an instance of it. Right. For completeness, there is still the guarantee that any returned object will be of type SignalType (so that the corresponding isinstance check will always be true), but the specific subtype depends on the parameters. > That is confusing, especially when you assume that Signal was a class. > > I would say the SignalType solution is good. > > Just out of curiosity, how do you define that SignalType symbol. The appropriate class exists (myhdl._Signal._Signal), so it is just a matter of making it user-visible. In the myhdl._Signal module I add, after the _Signal definition: SignalType = _Signal and then I export it just like the other visible symbols, in myhdl.__init__. Jan -- 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 Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.com |
|
From: Christopher F. <chr...@gm...> - 2010-06-10 15:12:02
|
> > > Your factory function Signal() must return the correct class object > > based upon the parameters passed to it. > > > > So Signal is just a function now that returns a class object so there is > > no such thing as an instance of it. > > Right. For completeness, there is still the guarantee that any returned > object will be of type SignalType (so that the corresponding isinstance > check will always be true), but the specific subtype depends on the > parameters. > > Ok, I am going to back up and make sure I understand this. We have a base class, *Signal(...)* and derived classes DelayedSignal, ShadowSignal, etc. As you mentioned some earlier design decision guided this path. From a users point of view the desired effect is that they only care about a *Signal* that may have some different attributes but the user doesn't need to know that it is a different object (just refreshing and sync'n out loud). Now we have a factory function (introduced with the ShadowSignal) and a proposed SignalType. The SignalType exposes the actual base class *_Signal_* because we can't have an instance of the factory function (well you can but that is not the use here). So the SignalType property exposes the base class so we identify variable's types. Ok, if I am on the same page, this all works from my perspective. I will double check in the cases were I accessed the private properties as a work around. It will be a couple days before I can check. I like the approach and having access to identify a variables type! If I remember correctly, I was using in in my mixed DSP sim environment (models and RTL) and had assertions to verify the ports in the DSP blocks were Signals, the proposed solution should be applicable in my use cases. .chris |
|
From: Jan D. <ja...@ja...> - 2010-06-11 09:19:34
|
Christopher Felton wrote: > > Your factory function Signal() must return the correct class object > > based upon the parameters passed to it. > > > > So Signal is just a function now that returns a class object so > there is > > no such thing as an instance of it. > > Right. For completeness, there is still the guarantee that any returned > object will be of type SignalType (so that the corresponding isinstance > check will always be true), but the specific subtype depends on the > parameters. > > > Ok, I am going to back up and make sure I understand this. > > We have a base class, *Signal(...)* and derived classes DelayedSignal, > ShadowSignal, etc. As you mentioned some earlier design decision guided > this path. From a users point of view the desired effect is that they > only care about a *Signal* that may have some different attributes but > the user doesn't need to know that it is a different object (just > refreshing and sync'n out loud). > > Now we have a factory function (introduced with the ShadowSignal) and a > proposed SignalType. The SignalType exposes the actual base class > *_Signal_* because we can't have an instance of the factory function > (well you can but that is not the use here). So the SignalType property > exposes the base class so we identify variable's types. Correct. In effect, we decouple the interface to create Signal objects from their base class SignalType. Everywhere where you tested where an instance is a Signal, it should merely be a matter of using SignalType instead. Should I already push this change to the public repo's for experimenting? -- 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 Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.com |
|
From: Christopher L. F. <chr...@gm...> - 2010-06-11 10:31:34
|
On 6/11/2010 4:19 AM, Jan Decaluwe wrote: > Christopher Felton wrote: > >> > Your factory function Signal() must return the correct class object >> > based upon the parameters passed to it. >> > >> > So Signal is just a function now that returns a class object so >> there is >> > no such thing as an instance of it. >> >> Right. For completeness, there is still the guarantee that any returned >> object will be of type SignalType (so that the corresponding isinstance >> check will always be true), but the specific subtype depends on the >> parameters. >> >> >> Ok, I am going to back up and make sure I understand this. >> >> We have a base class, *Signal(...)* and derived classes DelayedSignal, >> ShadowSignal, etc. As you mentioned some earlier design decision guided >> this path. From a users point of view the desired effect is that they >> only care about a *Signal* that may have some different attributes but >> the user doesn't need to know that it is a different object (just >> refreshing and sync'n out loud). >> >> Now we have a factory function (introduced with the ShadowSignal) and a >> proposed SignalType. The SignalType exposes the actual base class >> *_Signal_* because we can't have an instance of the factory function >> (well you can but that is not the use here). So the SignalType property >> exposes the base class so we identify variable's types. >> > Correct. In effect, we decouple the interface to create Signal objects > from their base class SignalType. Everywhere where you tested where > an instance is a Signal, it should merely be a matter of using SignalType > instead. > > Should I already push this change to the public repo's for experimenting? > > > Yes, sounds good to me > > |
|
From: Jan D. <ja...@ja...> - 2010-06-12 07:48:50
|
Christopher L. Felton wrote: > On 6/11/2010 4:19 AM, Jan Decaluwe wrote: >> Correct. In effect, we decouple the interface to create Signal objects >> from their base class SignalType. Everywhere where you tested where >> an instance is a Signal, it should merely be a matter of using SignalType >> instead. >> >> Should I already push this change to the public repo's for experimenting? >> >> >> > Yes, sounds good to me Done -- 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 Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.com |
|
From: Kevin S. <sta...@gm...> - 2010-06-14 02:10:47
|
Jan, The factory function concept sounds nice and clean to me. Kevin On Sat, Jun 12, 2010 at 2:48 AM, Jan Decaluwe <ja...@ja...> wrote: > Christopher L. Felton wrote: > > On 6/11/2010 4:19 AM, Jan Decaluwe wrote: > > > >> Correct. In effect, we decouple the interface to create Signal objects > >> from their base class SignalType. Everywhere where you tested where > >> an instance is a Signal, it should merely be a matter of using > SignalType > >> instead. > >> > >> Should I already push this change to the public repo's for > experimenting? > >> > >> > >> > > Yes, sounds good to me > > Done > > > -- > 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 > Analog design automation: http://www.mephisto-da.com > World-class digital design: http://www.easics.com > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > -- Kevin R. Stanton c | 734•846•3915 e | sta...@gm... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X