Attributes for interfaces

-- JohnAasen - 2015-03-19

Proposal Details

• Who Updates: JohnAasen
• Date Proposed: 2015-03-19
• Date Last Updated:2015-03-19
• Priority:
• Complexity:
• Focus:

Requirement Summary

This proposals assumes that there exists an interface construct that describes an interface with individual modes (in, out, inout) . Then this proposal defines attributes to derive new interfaces from the original, avoiding the need to for example defining both a master and slave interface.

Proposal:

The proposal is inspired by the interface construct defined by SysML, where a interface may be typed by an interface either in normal or in conjugated mode.

Conjugated attribute

I'conjugated defines the derived interface where the direction of all elements are reversed.

• in -> out
• out -> in
• inout -> inout
• (buffer -> in)?

This allows a single definition of a bus where the normal interface is used on one side and the conjugated on the other.

The support for buffer mode needs further discussion, since buffer mode is not symmetrical. (Buffer maps to in, but in does not map to buffer.)

Alternative attribute names have been proposed in the mailing list:

• conjugated
• reverse
• reverse_interface
• opposite_mode
• mirrored
• converse

Monitor attribute

I'monitor defines the derived interface where all elements are inputs. This is assumed useful for monitor and scoreboard modules in testbenches.

• in -> in
• out -> in
• inout -> in
• (buffer -> in)?

Alternative attribute names have been proposed in the mailing list:

• monitor
• in

Competing Proposals:

None

Complementing Proposals:

• Records with Directional Subtypes
• Interface Construct and Port Mode Configurations
• Add "Bus" mode for bidirectional port signals

NOTES :

ADVANTAGES :

1) Simplicity

Allow a single interface definition to be used for both ends of an interface.

DISADVANTAGES:

1) Too simple?

The proposed attributes do not cover all possible variants of an interface. This is intentional.

Complex derived interfaces needs a more verbose and detailed syntax as provided by the various interface proposals. The interface attributes are meant to cover the some of the main use cases.

Example of interface attribute use.

This example is based on the Records with Directional Subtypes proposal. Any of the other proposals may also be used.

type t_cpu_bus is record
    adr : std_logic_vector(15 downto 0); --Address
    dat : std_logic_vector(15 downto 0); --Data from master to slave=
    we : std_logic; --Write enable from master=
    en : std_logic; --Enable from master=
    sdt : std_logic_vector(15 downto 0); --Data from slave to master=
    ack : std_logic; --Acknowledge from slave=
    err : std_logic; --Error from slave=
end record;

subtype t_master is t_cpu_bus port(adr, dat, we, en : out; sdt, ack, err : in);

--Master entity
entity master is
port (
    clk : in std_logic;
    bus : t_master
);
end entity;
--Slave entity
entity slave is
port (
    clk : in std_logic;
    bus : t_master'conjugated
);

--Scoreboard entity
entity scoreboard is
port (
    clk : in std_logic;
    bus : t_master'monitor
);

--Top level
signal cpu_bus : t_cpu_bus;

i_master : master
port map (
    clk => clk,
    bus => cpu_bus
);

i_slave : slave
port map (
    clk => clk,
    bus =>  cpu_bus
);

i_scoreboard : scoreboard
port map (
    clk => clk,
    bus =>  cpu_bus
);

End of example.

Comments