Re: [myhdl-list] MEP : Signal Containers

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

On 5/17/12 8:35 AM, Tom Dillon wrote:
>
>
> 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?

I have already implemented this feature and created a MEP write-up, 
MEP-108, http://www.myhdl.org/doku.php/meps:mep-108.  There hasn't been 
much discussion so I haven't posted the patch yet.  I will post the 
patch soon.

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

Yes, that is the intent of the class attribute "signal container".  A 
tool to group associated signals, like an embedded bus such as, Wishbone 
or Avalon.

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

A complex number is a good example as well but also an example that 
illustrates why I have some reservations.

With a complex number, in the SW world you also would want to define the 
operators on the new "type".  This MEP only covers class use as a 
container and not general OO.  That is my worry given some of the recent 
threads that this will open more confusion and misunderstanding, at 
least with Mr.Issues.

The signal container MEP is simply to use the classes like a VHDL record 
or an SV struct.  You can group associated signals and constants.  But I 
think the class attribute signal container could be very useful if the 
confusion can be curbed.

>
> Now, this all works now, other than you can't use the class object as a
> top level port of your MyHDL module.  For now, I have to make a top
> level wrapper that breaks out the complex object into its real and
> imaginary signals and creates twice as many ports. Not horrible, but it
> is tedious and prone to errors.

I believe I have this resolved as long as the community agrees with the 
"feature", i.e gives the thumbs up.

>
> What I think would be useful, is for the class to have some hooks for
> conversion. For instance you may want to tell it to break out the object
> into two separate signals. Or you may want to concatenate them together
> into one long vector.
>
> I am very unfamiliar with conversion so have no idea the best way to
> achieve something like this.
>
> I guess I need to understand other issues to know what everybody else
> wants out of this.

I think the "hooks" could be a follow-on feature.  I believe the current 
proposal is clear that it only allows the class attribute to be used a 
signal container.  You still need to use the contained signal the same 
as you would handle current signals.  Once the straight-up signal 
attribute and class methods are supported it is a good stepping stone 
for what you suggest.

As mentioned, probably the most familiar example (I will add this to the 
MEP) is an embedded bus.  I can create the following class

     class WishboneBus(object):
         def __init__(self, DataWidth=16, AddressWidth=8):
             self.clk = Signal(False)
	    self.rst = Signal(False)
	    self.cyc = Signal(False)
             self.stb = Signal(False)
             self.adr = Signal(intbv(0)[AddressWeidth:])
             self.dat_i = Signal(intbv(0)[DataWidth:])
             self.dat_o = Signal(intbv(0)[DataWidth:])
             self.we = Signal(False)
             self.sel = Signal(intbv(0)[int(DataWidth/8)"])
             self.ack = Signal(False)

     def WbGpio(wb_bus, outs, ints):
	...

     wb_bus = WishboneBus()
     outs = Signal(intbv(0)[8:])
     ints = Signal(intbv(0)[8:])
     iGpio = WbGpio(wb_bus, outs, ins)


In the above example the embedded bus is contained in the class 
description.  The benefit is clumping associated signals together.  It 
simply makes the hardware description more compact without losing 
descriptive information.  In the above example, if I have a bunch of 
peripherals the bus that connects them all is in a neat compact 
description.  As the MEP indicates the converted code these will all be 
individual signals in the lower HDLs, mainly so that the older most 
supported versions of Verilog/VHDL can be supported.

Regards,
Chris