Re: [myhdl-list] Shadow signals

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

Felton Christopher wrote:
>> Christopher Felton wrote:
>>> On Tue, Jun 23, 2009 at 3:47 AM, Jan Decaluwe <ja...@ja...>  
>>> wrote:
>>>> Basically I tried to address the problem that some of
>>>> you have struggled with: the inflexibility of MyHDL signals.
>>>> For example, the fact that signal slices don't behave
>>>> as signals.
>>>>
>>>> It's all documented here:
>>>>
>>>>   http://www.myhdl.org/doku.php/meps:mep-105
>>>>
>>>> Feedback welcome!
>>>>
>>>> Jan
>>> I pulled the latest code from the repository this morning and was
>>> unable to check if a variable was a "Signal".  It looks like the
>>> "Signal" changed from a class to a function?
>> Yes, I turned it into a factory function. The existing implementation
>> was way to complex (i.e. using __new__ to construct different Signal
>> subclasses depending on constructor parameters. With the additional
>> Signal subclasses coming up, this was becoming really ugly.
>>
>> I thought this would be an innocent change - I didn't anticipate
>> that a MyHDL user would ever need to test whether an object belongs
>> to the Signal class. Why do you need this?
>>
> 
> I don't know if this is a "need".  I have used this approach for some  
> designs.  As mentioned mainly for modeling and testbenching.  If the  
> change is not backward compatible I need to go modify the usage.
> 
>  >> My "use case", I have used this in modeling modules.  A module might
>  >> be used outside myhdl environment and will except basic inputs.  The
>  >> same module is used in a testbench and thus the module is flexible  
> to
>  >> use a Signal or not.
> 
> In my case, I had some algorithms (modules) prior to utilizing myhdl  
> (or after).  I reused these modules by adding a Signal type and not  
> rewriting a separate module for testbenches.  In this example, the  
> modules still work with my standard python scripts but also work with  
> my hdl testbenches.
> 
> A trivial example (not realistic example, too simple).  Say I had a  
> module that added two types
> 
> def myadd(a, b, c):
>      c = a + b
> 
> I would have changed the module so I could use it in a testbench to  
> something like the following
> 
> def myadd(a, b, c):
>      if isinstance(c, myhdl.Signal):
>          c.next = a + b
>      else:
>          c = a + b
> 
> note, most of the time 'c' is of type numpy.ndarray.
> 
> As mentioned, the module would be compatible with previous usage but  
> now it would also be utilized in testbenching and modeling.  The  
> example I used is overly simple, the usage would apply to something a  
> little more complex.  I would not want dual maintenance for separate  
> modules.
> 
> I do this often when a DSP algorithm is generated.  Usually an  
> algorithm is developed, at the algorithm level, and not hardware  
> level.  At some point later this original algorithm will be used as a  
> golden model in the testbench to validate the hdl implementation.  At  
> that point I add the Signal usage.  Yes, this ends up being a little  
> after thought but not all algorithms are used with hdl simulation  
> adding from the start hasn't made sense yet, that could change.
> 
> Maybe there is a better way to handle this that I have not considered?

Somehow this doesn't feel right to me. If I understand you well, you have
to use type checks in the middle of your algorithms to make it work in
different modes. I don't know whether it's feasible, but I think the
right way would be polymorphism, that is, objects of different types
that can work with the same algorithm unchanged.

Of course, I understand that MyHDL's signal assignment is a bit special.
The question is whether you can't use a wrapper class around some other types
to make them work with the same kind of attribute assignment.
Also, are you sure you need signals? Internally in an algorithm I think
plain variables would be OK, if not better, as they correspond to
"normal" semantics. (Signals are different, and HDL-specific.)

Also, note that the MyHDL signal is in fact designed to take any kind
of object as underlying value. (Warning: I never extensively tried
that with "non-HDL" types.)

Note that 

def myadd(a, b, c):
     c = a + b

can't work, as c will become a local variable in Python. I understand
this is a small example, but still, it shows that you would have to
use a different kind of assignment (slice or attribute) that
modifies an existing object, like MyHDL wants you to do for signals
and also for intbv's if they have to be convertible. If that paradigm
is followed, the wrapper idea mentioned above might work.

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