Re: [myhdl-list] MEP : Signal Containers

[Oscar D. <osc...@gm...>]

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.

Of course you can argue: "use dir() to get a list of class
attributes", but what about classes that implements __getattr__() to
custom access class attributes? I'd like to have support for class
attributes, but it's still unclear to me how complex this can be, and
also if there's a real need to support it.

>
> 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 know what you mean, I did suffer a lot doing the same thing :)

>
> 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 think the default behavior should be break into separate signals.
Its easier to support long names for signals that deal with complex
structures in VHDL and Verilog. By the way even for distributable IP
cores, you can find that interfaces are just a plain list of signals.
In fact I never have seen VHDL "records" in the projects I've been
working.

The issue here is that the conversor must create unique identifiers
for its signals, this MEP deals with this naming scheme and its
implementation.

Concatenation is another thing, I think it's supported already by
shadow signals.

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

Best regards.
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list



-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.fsf.org/campaigns/opendocument