Re: [myhdl-list] MEP 107 assessment

[Jan D. <ja...@ja...>]

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?

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.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com