Signal Containers

— Christopher L. Felton 2012/04/25 22:01

    NOTE: It is being considered by the MEP's author to create   
    a separate MEP for class attributes, this was suggested in 
    the mailing list.  This MEP would then only cover heterogenous 
    list, dictionaries, and some enhancements to tuples.  The MEP 
    has not been updated to account for the change just mentioned.

The following is a proposal to add conversion support for Signal containers. Signal containers are; classes, lists, and dictionaries that contain a Signal type. Lists, and dictionaries are built-in data structures in the Python programming language. A class is the common method to define objects. For more information on Python classes, lists, and dictionaries see [1], [2], [3], and [4].

Another native data structure in the Python programming language is the tuple. Tuples are non-mutable and not usable in this case. Tuples are useful when defining ROMS and currently supported. The rest of this enhancement proposal will outline the addition of classes, lists, and dictionaries to the MyHDL convertible subset of the Python programming language. Through the rest of this document the term “container(s)” will be used to refer to data structures and objects that contains Signals and other convertible types.

The desired approach is to generate a unique name for a Signal that is part of a container. If an expression includes a “container” a net name will be generate for the Signal, example:

myObject.x.next = ListOfSignal[10] + DictOfSignal['fred']

The above example has all three container types; a class, a list with signals and a dictionary with signals. The conversion utilities would determine if the type referenced is a Signal and then create a unique name for the Signal.

myObject_x = ListOfSignal_10 + DictOfSignal_fred

The converter will simply use the container's instance name as part of the net name. The same rules that apply to hierarchy naming will be included. The above might be converted to something like the following to avoid name collisions.

mod1_mod2_myObject_x = mod1_mod2_ListOfSignal_10 + mod1_mod2_DictOfSignal_fred

In other cases a data structure might not contain a Signal but a constant (literals). In this case the conversion methods will dig down to find the constant and use the constant value.

Required support:

• Expansion of Signal container names
• Containers as ports
• Containers as sensitivity lists
• Resolution of data in data structures

In general, containers can be used, as long as the final referenced object is a convertible type (Signal, int, long, bool, intbv). All of the above is supported for modeling in MyHDL 0.7, except for “containers as sensitivity lists” as discussed in the mailing-list.

This feature is similar to the VHDL record and SystemVerilog struct. The idea is that signals can be logically grouped. This can be very useful to a designer to logically group signals.

Variables should be supported as well. When variables are used, if needed, the variable should be converted to a long net name. Variables in containers will follow the same rules as outlined for signals in a container.

Classes that contain Signals or a hierarchy of classes that eventually contain a Signal should be converted. Classes should be converted according to the following rules:

1. The object attribute referenced is a convertible type
   1. Left hand side : Signal of type intbv or bool
   2. Right hand side : int, long, bool, intbv or a Signal of type int, long, bool, intbv
2. The object being referenced will be represented in the converted code as a long-net-name. Long-net-names are derived by
   1. Hierarchy name rules (which are?)
   2. Class path name, example :

  class.refObj = class_refObj
  class1.class2.refObj = class1_class2_refObj

  class MyObj(object):
     def __init__(self):
        x = Signal(intbv(0)[8:])
        y = Signal(intbv(0)[4:])
        z = Signal(intbv(0)[9:])
 
  def foo(clk, srst, xyz):
 
     @always(clk.posedge)
     def rtl():
	xyz.z.next = xyz.x + xyz.y
 
     return rtl
 
  if __name__ == '__main__':
     clk = Signal(False)
     xyz = MyObj()
     toVerilog(foo, clk, xyz)

Verilog example conversion for the above.

   module foo
   (
     input  wire  clk,
     input  wire  [7:0] MyObj_x,
     input  wire  [3:0] MyObj_y,
     output wire  [8:0] MyObj_z
  ):
 
     always @(posedge clk) begin
        MyObj_z <= MyObj_x + MyObj_y
     end  
 
  endmodule

VHDL conversion example.

    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;

Here heterogeneous is used to differentiate a list of signals that contain different signal types versus list of signals that is homogeneous, all the same type of signals. Homogeneous list of signals are currently supported and convert to the underlying HDL as an array of bit-vectors. This is useful for defining memories.

The functions that determines a memory object will need to be enhanced to differentiate a homogeneous list of signals from a heterogeneous list of signals.

Similar to the class conversion dictionaries should be convertible as well. The same rules that applied to class conversion should be applied to dictionaries.