Records with Directional Subtypes

Proposal Information

• Who Updates: PeterFlake, ...
• Date Proposed: 2012-06-22
• Date Last Updated: 2012-06-22
• Priority:
• Complexity:
• Focus: General Language, but specifically Testbench

Summary

Abstract connections between blocks. Allow development and connection of models of different levels of abstraction to connect together.

Need to add SCE-MI as a testbench type candidate

Previous Work Done Under Accellera

Jim's old proposal for interfaces

• Jim Opinion: This is not a complete solution to variant interfaces.

FT17 Earlier Work

Related Issues: Many

ISAC Issues:

• IR 2089 - Directional Records
• IR2067 - Logical link interface abstraction

Competing Issues:

Interface Construct and Port Mode Configurations - a proposal to enhance modes to better handle composite types in port connectivity.

Candidate: Resolved Records

Use records as an inout and require that each element of the record have a resolution function.

This methodology is currently under usage. Limited to types for which it is easy to write a resolution function. Array objects must be fixed in size.

Candidate: Records with directional subtypes

Contributors: PeterFlake,

The syntax makes the mode (in, out, inout) optional in a port. So allowing a user-defined name for a mode would be syntactically difficult, as the parser would not know whether the name was a mode or not.

The simplest way from the syntactic point of view is to make the mode part of a subtype. The question then arises of whether such a subtype can be used in a port with an explicit mode to override the declared mode.

The subtype declaration needs new syntax as shown in the example below:

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);

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

--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_slave
);

--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
);

JimLewis Question: Can we extend this to also allow open in the subtype? The following slave does not use the we element (perhaps it is read only):

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

PeterFlake Answer: Yes. The alternative would be to omit the we from the direction list, but this would not be as clear.

JimLewis Question: Can we allow some ports to not use all elements? In the following, the slave does not use all of the en

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_(7 downto 0) ; --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);

subtype t_slave is t_cpu_bus port(adr, dat, we, en(1) : in; sdt, ack, err : out ; en(7 downto 2), en(0)  : open );

PeterFlake Answer: No. The wiring to the slave should not be done inside the slave. Instead a signal record containing just one enable should be connected via the port map. This answers the next question as well.

JimLewis Question: Inside the slave is en seen as en(1) or just en? Is there a notation that allows just en?

JimLewis Question: Can we use others with open?

subtype t_slave is t_cpu_bus port(adr, dat, we, en(1) : in; sdt, ack, err : out ; others  : open );

PeterFlake Answer: Yes. This is more explicit than just omitting signals from the direction list.

Questions

Comments

-- ErnstChristen - 2015-01-27

There are about 6 proposals related to improving the management of ports:

• This proposal
• Packages as an interface construct
• Interface Construct and Port Mode Configurations
• Add "Bus" mode for bidirectional port signals
• Protected Types with Public Signals
• Protected Type on Entity Interface

It would be worthwhile to derive generic requirements for port/interface management instead of looking at them in isolation.

Arguments AGAINST

-- ErnstChristen - 2015-01-21: This proposal does not scale to VHDL-AMS since it is not possible to change the abstraction level of an element of the record type to a different object class, e.g. a terminal. The competing proposal for an interface construct provides this flexibility.

Against

-- ErnstChristen - 2015-01-21

Supporters

-- JimLewis - 2014-12-02

-- DanielKho - 2015-01-01