TWiki
>
P1076 Web
>
Vhdl2019CollectedRequirements
>
BlockInterfaces
(2020-02-17,
JimLewis
)
(raw view)
E
dit
A
ttach
---+ 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
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r19
<
r18
<
r17
<
r16
<
r15
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r19 - 2020-02-17 - 15:34:28 -
JimLewis
P1076
Log In
or
Register
P1076 Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
P1076
Ballots
LCS2016_080
P10761
P1647
P16661
P1685
P1734
P1735
P1778
P1800
P1801
Sandbox
TWiki
VIP
VerilogAMS
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki?
Send feedback