Re: [myhdl-list] Shadow signals

[Felton C. <chr...@gm...>]

> 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?