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

On 18/02/15 15:40, John.Aasen@kongsberg.com wrote:

 > But I still want to suggest a way of modelling ports that is based on
> the concepts from SysML (http://www.omgsysml.org/) which I believe match
> very well with VHDL.
>
> In SysML a port can typed with an interface. This interface may contain
> flows with directions, i.e. in, out or inout, or other interfaces.
>
> When connecting two ports the directions will be reversed on one side.
> To avoid needing two definitions of the interface, SysML uses the
> concept of a conjugated port. The conjugated port will invert the
> direction of the flows: in becomes out, out becomes in while inout stays
> inout. In addition it is allowed to create ports-of-ports to represent
> bundles of information.
>
> This allows a single interface definition to be used on both sides of a
> connection, and it is no longer necessary to define for example a master
> and a slave interface with the same signals but the opposite direction.

I think this proposal is a good one: it is easy to understand (conjugate
and monitor concepts are clear), and it looks not too difficult to
implement.  (I also think this is a feature asked by users).

There are still a few remaining details: is an interface a type ? Ie, is
is possible to create variables (or signals) of an interface type ? Is
it possible to compare two interfaces ?
Apparently yes, so we'd better to use the type syntax (as suggested by
Patrick Lehmann).

What are the modes allowed ?  In, Out and Inout looks obvious.  Linkage
may be excluded.  What about Buffer ?

May I suggest to use attributes for conjugate and monitor ?  This avoids
creating new reserved words (in particular monitor may be widely used).

Few little comments about your examples:

> entity master is
>    port (
>      clk : in std_logic;
>      bus : interface i_cpu_bus

Should we require the 'interface' word here ?
Maybe it clarify the user intent, so I am not opposed to that.

>      );
> end entity;

>
> --Slave entity - reverses direction for 'in' and 'out' interface elements
>
> entity slave is
>    port (
>      clk : in std_logic;
>      bus : conjugated i_cpu_bus

Let's propose:
        bus : interface i_cpu_bus'conjugated;
or
        bus : i_cpu_bus'conjugated;
(I am not a native English speaker, but there might be a better
  word than conjugated.  Maybe reverse ?)
>    );

> -- bus monitor - all interface elements are 'in'
>    port (
>      clk : in std_logic;
>      bus : monitor i_cpu_bus

Likewise:
        bus: i_cpu_bus'Monitor;
>    );

>    i_monitor : monitor

Ehh, in your proposal, 'monitor' is a reserved word so
the above line is not correct :-(

> Hierarchical interfaces
>
> use 'normal' VHDL syntax to build ports-of-ports and arrays-of-ports, or
> combination
>
> interface i_cpu_bus_vec is array (natural range <>) of i_cpu_bus;

If interfaces were types, there would be no need for a new syntax.

> interface i_foo

Missing 'is' :-(

>    sof  : in std_logic;
>    eof  : in std_logic;
>    data : in std_logic_vector(7 downto 0);
> end interface i_foo;

[...]


> -- use port configurations to disconnect unused elements
>
> -- I am not sure that this is a good syntax, but we need something to
>
> -- avoid connecting elements and pick out elements / vectors of arrays
>
> -- Alternative might be some kind of port configuration
>
> -- see
>
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/InterfaceConstructandPortModeConfigurations
>
> entity slave is
>
>    port (
>
>      clk : in std_logic;
>
>      bus : conjugated i_cpu_bus
>
>    );
>
> i_slave : slave
>
>      port map (
>
> clk => clk,
>
>        bus => cpu_bus(cs => cs(c_SlaveId),  -- pick single element,
>           -- type of cs becomes the base type of the vector,
>           -- i.e. std_logic
>                       data => data(7 downto 0),  -- pick a slice,
>           -- range of data becomes sub_range std_logic_vector(7 downto
> 0)
>                       we => open)  -- unused port (read-only slave)
>      );

There is already a notation for that:
         bus.cs => cs (c_SlaveId), [...]
         bus.we => open);
No need to create a new notation.

> Alternative - limit width in entity
>
> entity slave is
>    generic (
>      c_SlaveId : integer);          -- Selects CS element
>    port (
>      clk : in std_logic;
>      bus : conjugated i_cpu_bus(cs => cs(c_SlaveId),
>                                 data => data(7 downto 0),
>                                 we => open)

Woow.  Looks too complex at that point.

>    );
>
> Final notes:
>
> Records with direction might be used instead of interface. See

I really prefer a new reserved word for interface.

> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/NewBusModeForBidirectionalPortSignals#3_Assignments_can_be_to_a_record
>
> for how a modification to a record assignment may be used to handle
> partial assignments to the elements in a record or interface.
>
> The main point of the proposal is to use normal, conjugated and monitor
> ports and have a single definition of an interface.

I agree that this is the nice point of that proposal: both natural and
easy to understand.

> I also propose that this interface also may be used instead of a type or
> subtype to define signals or variables in a design / testbench.

So, use the type syntax!

Tristan.


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