(r1) UCProposalBlockInterfaces < P1076

P1076 Web>Vhdl2019CollectedRequirements>InterfaceAndBundleEnhancements>UCProposalBlockInterfaces (revision 1) (raw view)~~EditAttach~~
---++ 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.
Topic revision: r1 - 2016-01-21 - 11:48:50 - TWikiGuest
P1076