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

Hello,

Tristan wrote:
> 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 ?)

The attribute syntax looks cleaner.
If you spare the interface keyword, can it conflict with the default direction of ports?
Using 'reverse (or 'reverse_interface) is like using 'reverse_range on arrays.

What about using the keyword bus instead of interface?
Pros:
- it's as short as in/out/inout in a port description
- 'reverse_bus looks more like 'reverse_range than 'reverse_interface
Cons:
- maybe it's a widely used signal name
- interface is better known from OOP

 
Additional attributes:
Shout there be a possibility to extract all in or out signals by using the
attribute syntax? This could help to connect new entities with interfaces
to legacy entities with one record per direction.

-- new interface
type t_fifo_in is record
  valid : std_logic;
  data : std_logic_vector(7 downto 0);
end record;

-- legacy double record interface
type t_fifo_out is record
  ack : std_logic;
end record;
type t_fifo is record
  valid : in std_logic;
  data : in std_logic_vector(7 downto 0);
  ack : out std_logic;
end record;

-- signal between 2 fifo coupled modules
signal myfifo1_out : t_fifo;

-- entity declarations
entity fifo_new is
  port (
    OutPort : t_fifo
    [...]);
end entity

entity fifo_old is
  port (
    InPort_in : t_fifo_in;
    InPort_out : t_fifo_out;
    [...]);
end entity

myfifo1 : entity myLib.fifo_new
  port map (
    clock => clock,
    OutPort => myfifo1_out
    [...]
  );

myfifo2 : entity myLib.fifo_old
  port map (
    clock => clock,
    InPort_in => myfifo1_out 'out_signals
    InPort_out => myfifo1_out 'in_signals
    [...]
  );

The names 'in/out_signals' sound not good, so please advise better names :)

Regards
    Patrick

-----Ursprüngliche Nachricht-----
Von: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] Im Auftrag von Tristan Gingold
Gesendet: Donnerstag, 19. Februar 2015 07:20
An: vhdl-200x@eda.org
Betreff: 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/InterfaceConstructandPortM
> odeConfigurations
>
> 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/NewBusModeForBidirectional
> PortSignals#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.




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