Re: [myhdl-list] MEP : Signal Containers

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

On 11/21/2011 9:39 AM, Oscar Diaz wrote:
> 2011/11/15 Christopher Felton<chr...@gm...>:
>> The following is a *start* to a MEP that describes the conversion
>> support for classes, lists, and dictionaries.  This is just a start of
>> the enhancement description and does not include some of the mechanical
>> (code changes) items worth identifying in a MEP.
>
> Thanks for making this draft. I'm mostly agree this MEP, I'll just add
> some thoughts:
>
> * Since a class could be more powerful than a list or a dict,
> container classes should allow enhanced features i.e. custom naming
> scheme. We can propose hidden methods to support that features, in a
> similar way of the special methods from the python data model:
>
> http://docs.python.org/reference/datamodel.html#special-method-names

If we do this we would need to define a base class, something like 
SignalStruct, that would contain these features.  Past feedback indicate 
they would like general class/objects to be convertible without defining 
a special base class.

I think general class/objects would need to be supported but having an 
additional MyHDL ojbect to help guide conversion would be useful.  Also, 
defining a SignalStruct object would make things easier (my guess) for a 
first implementation.  It might be a good spot to start with and explore 
the conversion routines.

>
> Right now I'm thinking about
>
> * It's not explicitly mentioned, but I guess the conversion step will
> "flatten" the signal container. Although I agree on that, maybe we
> could think about support to conversion to arrays or records (I speak
> mainly for VHDL, I'm not that expert of Verilog).

The argument against using VHDL records is to keep a similar conversion 
for Verilog and VHDL, IMO.  We don't want to use the SystemVerilog 
struct unless it is supported by the open-source compiler/simulators. 
Since we need to flatten it for Verilog I think flattening it VHDL is 
reasonable, least common denominator.

My thought, if we have a special case for VHDL it would be more work to 
develop, maintain, and test.  Personally I like limiting the use of the 
underlying HDL as minimal as possible and maximum overlap between HDLs.

>
> * About the conversion of class methods, I think that should be in
> another MEP, this one is to define signal containers. We should make
> another MEP to add support for conversion of classes (not just class
> methods). However, I do agree that the class methods must have support
> for conversion, as you explained here, and I think it is easy to fix
> the self argument issue in the conversion code.

That is reasonable but I don't follow what you mean by the conversion of 
classes?  In my mind, once you have a mechanism to dig down and find the 
signal, I call them primitives (which is the main purpose of this mep). 
  And generator conversion is already supported (other than a generator 
that is defined in a class).

>
> That's all for now.
>
> Best regards.
>
> P.D.: Perhaps I can help with the VHDL code snippet:
>
> VHDL example conversion.
> .. code-block :: vhdl
>
> entity foo is
>      port (
>          clk: in std_logic;
>          MyObj_x: in unsigned(7 downto 0);
>          MyObj_y: in unsigned(3 downto 0);
>          MyObj_z: out unsigned(8 downto 0)
>      );
> end entity foo;
>
> architecture MyHDL of foo is
>
> begin
>
>      RTL: process(clk) is
>      begin
>          if rising_edge(clk) then
>              MyObj_z<= MyObj_x + MyObj_y
>          end if;
>      end process RTL;
>
> end architecture MyHDL;
>
>

Thanks for the code snip.

> Right now I'm thinking about:
> * custom naming scheme: something like "_names_iter(self)" method that
> returns the desired names for each signal.
I believe an object would need to be provided, that has special hooks 
and methods.  But the use of the object (e.g. SignalStruct) is optional. 
  Converting objects with Signal members should be convertible.  I will 
add this MyHDL object, SignalStruct, to the MEP and outline what you 
have suggested.

> * late signal creation: suppose that I need to calculate the width of
> a signal, but I already create the container object. A method that
> create (or update) the signal objects just before simulation or
> conversion can be defined.
Late/dynamic signal creation is not an issue as long as it is done 
during elaboration.

> * classes with special method names: what happen if I define the
> __slot__ list? or if I define a custom __getattr__ or another methods?

No methods would be used/inspected for conversion (ignoring generators 
for now), special methods shouldn't cause a problem.  A member of an 
object, if it is a convertible Signal or a convertible constant will be 
considered for conversion and flattened.

Thanks for the feedback,
Chris