Re: [myhdl-list] MEP : Signal Containers

[Christopher F. <chr...@gm...>]

On 5/17/12 9:52 AM, Oscar Diaz wrote:
> 2012/5/17 Tom Dillon<td...@di...>:
>>
>>
>> On 05/17/2012 04:03 AM, Oscar Diaz wrote:
>>> 2012/5/14 Christopher Felton<chr...@gm...>:
>>>
>>>> <snip>
>>>>
>>>> I have made some minor changes to the proposed MEP, the modifications
>>>> can be found here, http://www.myhdl.org/doku.php/meps:mep-107
>>>>
>>>> I have been *waffling* if the class attributes should be part of this
>>>> MEP or a separate MEP.  I am leaning more towards inclusion, if a class
>>>> attribute is a convertible type then it can be viewed as a "Signal
>>>> Container".  But it might warrant it separate MEP/thread simply because
>>>> the conversation around class support might be lengthy, e.g. subset of
>>>> class support (the current MEP107 and MEP108) or something different.
>>> I agree: class attributes should be covered in this MEP (as we
>>> discussed in this thread). However, I think this MEP should address
>>> first the easy containers: lists and dictionaries, and after that
>>> experience we can move to support -the more general- class attributes.
>>>
>> I am more interested in using classes. I am not sure what class
>> attributes would do. Can someone provide an example?
>
> My first attempt was to provide a wishbone interface:
>
> class wishbone_iface():
>      def __init__(self, data_bw = 8, addr_bw = 8)
>          ....
>
> And, use it as a container signal but also to hold other information
> and/or useful functions.
>
>>
>> My use for this is really to group related signals, so that you can pass
>> them as a group. Secondary use would be to provide some useful class
>> functions to do redundant tasks that I would prefer to hide in the class.
>>
>> My simple example would be for complex numbers.  The object would simply
>> store two values, real and imaginary. It would have some member
>> functions like next(cplxNum), which would do the complex assignment to
>> the two signals stored in the object. It would have other member
>> functions as well, but you get the idea.
>
> Let me propose a workaround: subclass dict() and add any functions you
> need. That way you can access your signals like any other dict and
> provide your desired functions. In fact, my previous example really
> looks like this:
>
> class wishbone_iface(dict):
>      def __init__(self, data_bw = 8, addr_bw = 8, **kwargs)
>          ....
>
> If we start with lists and dicts, we already cover subclassing of
> these objects, and have customized containers as if you make your own
> class.
>
> Implementation of this functionality requires the conversor to extract
> a complete list of convertible objects (signals and constants),
> something easy for lists and dicts, but not that easy for a generic
> class.
>

I guess I am not following where this conversation went.  Tom asked if 
the complex signal example could be used to *contain* the multiple 
signal related with a complex type and add some methods that work on the 
signals (which would be attributes to the complex object).  The first 
would be supported by the MEP the later would not in the traditional OO 
sense.  But you could write the HDL that describes the assignment in the 
same class.

I don't follow what Oscar means by "starting with lists and dicts, we 
already cover subclassing of these objects ...".  You lost me there.

I don't see that starting with heterogeneous lists (homogenous list of 
signals already supported) and dictionaries is easier or a more 
straight-forward path.  Other than the philosophical confusion using 
classes as Signal Containers I believe they all have the same difficulty 
implementing (my guess, the class attributes might actually be simpler 
to parse the hierarchy).

Back to the complex example, if you wanted to write the method that 
would do the assignment it would have to be a current MyHDL description, 
tried to capture in the example below.

     class Complex(object):
         def __init__(self, max=8, min=8):
             self.real = Signal(intbv(0, min=min, max=max))
             self.imag = Signal(intbv(0, min=min, max=max))

         def assign(self, clk, val):
             @always(clk.posedge)
             def hdl_assign():
                 self.real.next = val.real
                 self.imag.next = val.imag

             return hdl_assign


Now the question is how could this be used.  You would have to create 
instantiations of the types and the /assign/ HDL.

     def SomeOtherHdl(clk)
         c1 = Complex()
         c2 = Complex()
         iAssign1 = c1.assign(clk, c2)
         iAssign2 = c2.assign(clk, c1)

         return iAssign1, iAssign2

The above does absolutely nothing, just an example to illustrate some of 
the above conversations/questions (could do an add and multiply example 
if we wanted something that actually could be usable).

But what might be more desirable, would be:

     def SomeOtherHdl(clk)
         c1 = Complex()
         c2 = Complex()

         @always(clk.posedge)
         def hdl():
             c1.assign(c2)
             c2.assign(c1)

         return hdl

In this second example the /assign/ would probably have to look 
different than what was written in the above Complex description. 
/assign/ would need to be more like a VHDL or Verilog function that 
would be reducible to a combinatorial expression.  I don't think the 
second example is feasible to implement without considerable 
consideration and thought (at least not by me).  In short, class methods 
would not be usable as Tom described.

Regards,
Chris