Re: [myhdl-list] MEP 107 assessment

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

On 6/6/2012 2:04 PM, Jan Decaluwe wrote:
> On 06/06/2012 05:47 PM, Oscar Diaz wrote:
>
>> Like you said at beginning of the email, this works fine in
>> simulation, but conversion fails when you try to access container
>> members directly on generators. A workaround I've been using is to use
>> references to local names on elaboration. Taking the example from MEP:
>>
>> def ex1(clk, srst, xyz):
>>
>>       z = xyz.z
>>       x = xyz.x
>>       y = xyz.y
>>
>>       @always(clk.posedge)
>>       def hdl():
>>           z.next = x + y
>>
>>       return hdl
>
> This example got me thinking. I have never used it like that
> but it is a great example of how elaboration can be
> used to support powerful features which are not convertible
> at first sight. It may be that many users are not
> aware of this possibility.
>
> What I was thinking - is this really a workaround, or is it
> rather a desirable coding pattern (with the nice side effect
> that it is supported today)?
>
> Suppose MEP 107 were implemented, we could write
> the example as follows:
>
> def ex1(clk, srst, xyz):
>
>         @always(clk.posedge)
>         def hdl():
>             xyz.z.next = xyz.x + xyz.y
>
>         return hdl
>
> Is this really clearer, especially if there would be a number
> of generators which could be much more complicated than
> in the example?

The examples I believe illustrate attribute container are
clearer:

1.  If there are many attributes in a shallow container.

     The example we have been using is an embedded bus
     like wishbone.  If you had to explicitly reference
     each signal in the container in each module this
     adds redundant code.

     But the embedded bus might not be the best example
     because in your object container you might want some
     methods that retrieve the correct signals per usage.

     clk,rst,cyc,we,dat_i,dat_o,adr = Wishbone.GetPeriphalSignals()
     clk,rst,cyc,we,dat_i,dat_o,adr = Wishbone.GetControllerSignals()

     But in general a shallow container with many attributes,
     IMO, would be clearer without references.

2.  If you have multiple containers.  Managing variable
names become redundant.

     def MyModule(con1, con2, con3):
         con1_x = con1.x
         con1_y = con1.y
         con2_x = con2.x
	con2_y = con2.y
         ...

The examples where I believe referencing is clearer are:

1. Deep containers.
     someContainer.inAnother.yetAnother.toGetTo.x.next = y

2. Possibly, the many generators on small number of
container references.  Because you can simply type 'x',
'y', and 'z' everywhere instead of 'xyz.x', 'xyz.y', 'xyz.z'.

I think both have there uses.  One method obviously has an
advantage, as you mentioned, it is supported today.

>
> When I use classes now, I often get the instance variables
> of the 'self' variable once, especially when methods are
> complex. But this must be done per method. In this case,
> because of the scoping rules, we would have to do it only
> once for all generators in the module. The result would be
> a simplification of all code that follows.
>
> An valid argument for "signal containers" such as xyz is that it
> simplifies interfaces, and makes it easier to modify them.
> Even that could be simpler with the first pattern, because
> it would tend to localize a change (e.g. a name change
> in the interface would have to be done at just one location
> and the code would still work).
>
> As a minimum, we should consider writing a whitepaper/page
> "How to use inferfaces in convertible MyHDL", to
> describes the current state of the art.
>

I agree, simplifying interfaces is a big plus.

Regards,
Chris