(r12) BlockInterfaces < P1076/Ballots

P1076/Ballots Web>Vhdl2019CollectedRequirements>BlockInterfaces (revision 12) (raw view)~~EditAttach~~
---+ Records with Directional Subtypes

%TOC%

---++ Proposal Information
   * Who Updates: Main.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

[[http://www.eda.org/vasg/docs/Interfaces.pdf][Jim's old proposal for interfaces]]
   * Jim Opinion: This is not a complete solution to variant interfaces.

[[http://www.eda.org/vhdl-200x/vhdl-200x-ft/proposals/ft17_composite_interface_mode.txt][FT17 Earlier Work]]
---++ Related Issues: Many

ISAC Issues:
   * [[http://www.eda.org/isac/IRs-VHDL-2002/IR2089.txt][IR 2089 - Directional Records]]
   * [[http://www.eda.org/isac/IRs-VHDL-2002/IR2067.txt][IR2067 - Logical link interface abstraction]]
---++ Competing Issues:

[[P1076.InterfaceConstructandPortModeConfigurations][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: Main.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:

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

Main.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):
<verbatim>subtype t_slave is t_cpu_bus port(adr, dat, en : in; sdt, ack, err : out;  we : open);
</verbatim>

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

Main.JimLewis<strong> Question</strong>: Can we allow some ports to not use all elements? In the following, the slave does not use all of the en
<verbatim>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 );
</verbatim>

Main.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.

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

Main.JimLewis *Question*: Can we use others with open?
<verbatim>subtype t_slave is t_cpu_bus port(adr, dat, we, en(1) : in; sdt, ack, err : out ; others  : open );
</verbatim>

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

---++ Questions

---++ <a name="Comments"></a> Comments

-- Main.ErnstChristen - 2015-01-27

There are about 6 proposals related to improving the management of ports:
   * [[P1076.BlockInterfaces][This proposal]]
   * [[P1076.PackageAsInterface][Packages as an interface construct]]
   * [[P1076.InterfaceConstructandPortModeConfigurations][Interface Construct and Port Mode Configurations]]
   * [[P1076.NewBusModeForBidirectionalPortSignals][Add "Bus" mode for bidirectional port signals]]
   * [[P1076.ProtectedTypesPublicSignals][Protected Types with Public Signals]]
   * [[P1076.ProtectedTypeEntity][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

-- Main.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

-- Main.ErnstChristen - 2015-01-21
---++ <a name="Supporters"></a> Supporters

-- Main.JimLewis - 2014-12-02

-- Main.DanielKho - 2015-01-01
Topic revision: r1 - 2020-02-17 - 15:34:50 - TWikiGuest
P1076/Ballots