Re: [vhdl-200x] Interfaces with normal, conjugated and monitor flavours

Brent, Andy, Tristan,

You all make similar point that let me believe that my notes were insufficient to explain the issue I am raising. I'll try to clarify and, per Tristan's suggestion, provide some syntax examples.

In VHDL-AMS a port clause has been enhanced to include interface_quantity_declaration and interface_terminal_declaration, in addition to interface_signal_declaration. The syntax for these is:

   interface_quantity_declaration ::=
      quantity identifier_list : [ in | out ] subtype_indication [ := static_expression ]
   interface_terminal_declaration ::=
      terminal identifier_list : subnature_indication
which parallels
   interface_signal_declaration ::=
      [ signal ] identifier_list : [ mode ] subtype_indication [ bus ] [ := static_expression ]

A quantity represents an unknown in a system of differential-algebraic equations that has to be solved simultaneously. Interface terminals allow a user to describe signal flow. A local terminal represents a node at which KCL/KVL hold, generalized to include non-electrical energy domains. An interface terminal becomes part of such a node through its association with an actual. The nature of a terminal defines its properties: the subtype of the across quantity (or potential, for electrical: voltage), the subtype of the through quantity (or flow, for electrical: current), and the reference terminal of the nature (i.e. ground). Natures exist as scalars, arrays and records, paralleling types. A subnature relates to a nature in a similar way as a subtype relates to a type. A collection of natures for electrical, thermal, mechanical, fluidic, and radiant systems has been standardized as 1076.1.1.

The port clause of an entity whose architecture determines the power dissipated in the branch between the two terminals may now look as follows: 
   port (
      terminal plus, minus: electrical;	 -- electrical declared in ieee.electrical_systems
      quantity power: out REAL;
      signal enable: in std_logic:= '0'
   );
The reserved word signal is added here for clarity. In port clauses of 1076-compliant descriptions it is usually omitted, but allowed.

Getting back to the interface discussion, I noticed several emails in which a record *type* was used as the basis for an interface, e.g. 
>
>   type r_cpu_bus is record
>       adr:  std_logic_vector(15 downto 0);  -- Address
>       dat:  std_logic_vector(15 downto 0);  -- Data between master and slave
>       cs:   std_logic_vector(7 downto 0);   -- ChipSelect-bus from master
>       we:   std_logic;                      -- Write enable from master
>       en:   std_logic;                      -- Enable from master
>       ack:  std_logic;                      -- Acknowledge from slave
>       err:  std_logic;                      -- Error from slave
>   end record r_cpu_bus;

The interface then derives from this and specifies just the mode of each record element:

>   interface i_cpu_bus of r_cpu_bus is
>     port master(
>       adr: out;
>       dat: inout;
>       cs:  out;
>       we:  out;
>       en:  out;
>       ack: in;
>       err: in
>      );
>     port slave(master'converse);
>   end interface i_cpu_bus;

In other words, the interface declaration augments the type to include modes. This is then used in a port clause:

>   entity cpu_master is
>     port(
>       rst:     in std_logic;
>       clk:     in std_logic;
>       cpu_bus: i_cpu_bus.master
>     );
>   end entity cpu_master;

Since the interface declaration appears in the port clause as an atomic piece, the interface object that is declared there has to be of a certain object class, in this case a signal. 

I am advocating that an interface be more flexible than this, that it should be extensible to allow the inclusion of terminals and quantities. This precludes a type as a starting point, and it makes the interface concept a new construct that bundles object declarations, something like

   interface r_cpu_bus is
       adr:  std_logic_vector(15 downto 0);  -- Address
       dat:  std_logic_vector(15 downto 0);  -- Data between master and slave
       cs:   std_logic_vector(7 downto 0);   -- ChipSelect-bus from master
       we:   std_logic;                      -- Write enable from master
       en:   std_logic;                      -- Enable from master
       ack:  std_logic;                      -- Acknowledge from slave
       err:  std_logic;                      -- Error from slave
       terminal t1: electrical_vector(7 downto 0);  -- Added to demonstrate VHDL-AMS
	   quantity q: real                    -- Added to demonstrate VHDL-AMS
   end interface r_cpu_bus;

where object class signal is implied if omitted. An interface declared for a procedure could also include interface constants, interface variables and interface files. This can now be configured for a specific application:

  configuration r_cpu_bus_master of r_cpu_bus is
       adr: out;
       dat: inout;
       cs:  out;
       we:  out;
       en:  out;
       ack: in;
       err: in;
       q: in;
  end configuration r_cpu_bus_master;

and instantiated in a port clause:

   port (
      rst: in std_logic;
      clk: in std_logic;
      interface r_cpu_bus_master
   );
or, as a direct instantiation:
   port (
      rst: in std_logic;
      clk: in std_logic;
      interface r_cpu_bus (adr: out, ...)
   );

These port clauses are equivalent to expanding the interface in place, i.e. the 'INSTANCE_NAME of a port that is part of the interface is the same as if the ports had been declared in the traditional way. In other words, the interface behaves as a macro. The drawback is that an interface can only be instantiated once, and there is a potential for name clashes. The alternative would be to give the interface instance a name, e.g.

   port (
      rst: in std_logic;
      clk: in std_logic;
      ifc: r_cpu_bus_master
   );

and similar for a direct instantiation without configuration. Now, name spaces are preserved. Also, if a configuration is used, a 'CONVERSE attribute (or whatever its name will be) is possible, but it would be a stretch to also do this for a direct instantiation of the interface.

I also thought about parameterizing the object class, as I suggested, which would allow changing a signal to a terminal in the configuration (or instantiation), but I reached the conclusion that the ROI is too small since it would add a lot of complexity particularly to a direct instantiation of an interface.

This proposal adds the following items to the language
- The reserved word interface
- The interface declaration
- The interface configuration
- The interface instantiation
but there are obviously many open questions, for example:
- Where to declare interfaces and their configurations: in a package, as separate design units, elsewhere? 
- Should it be possible to include a mode already in an interface declaration? If so, should it be possible to override it in a configuration or instantiation?
- Should it be possible to also parameterize the initial values? It's a trade-off between flexibility and complexity.
- Genericity, i.e. allowing type parameters for an interface (and once genericity is part of 1076.1, nature parameters)
- Detailed semantics for everything

Ernst


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.