(r4) TopLCS2016_045b < P1076

P1076 Web>Vhdl2019CollectedRequirements>InterfaceConstructandPortModeConfigurations>TopLCS2016_045b (revision 4) (raw view)~~EditAttach~~
<sticky><!--
   * Local SB = <sticky><b>
   * Local BS = </b></sticky>
--></sticky>

---+!! Language Change Specification for Interface Construct and Port Mode Configurations Proposal
---++!! Secondary LCS:

This LCS details the interface 'null' mode support required for a mode view interface construct at the RTL.

%TOC%

| %SB%LCS Number:%BS%  | LCS-2016-045b |
| %SB%Version:%BS%  | 1 |
| %SB%Date:%BS%  | 13-Mar-17 |
| %SB%Status:%BS%  | Ballot |
| %SB%Author:%BS%  | [[Main.BrentHahoe][Brent Hayhoe]] |
| %SB%Email:%BS%  | %USERINFO{"BrentHahoe" format="$emails"}% |
| %SB%Source Doc:%BS%  | [[InterfaceConstructandPortModeConfigurations#Analysis][Interface Construct and Port Mode Configurations]] %BR% \
[[UCComplexRTLSignalCPUInterface][Use Case - Complex RTL Signal CPU Interface]] |
| %SB%Summary:%BS%  | Provide the independent interface mode control for the elements of composite type objects |
| %SB%Related LCS:%BS% | [[LCS2016_045a][LCS-2016-045a]] %BR% \
[[LCS2016_045c][LCS-2016-045c]] |

---++ Voting Results: Cast your votes here

   * Yes:
      1 %USERSIG{BrentHahoe - 2017-03-13}% - Version 1
      1 %USERSIG{SteveGrout - 2017-03-16}%- Version 1

   * No:
      1 %USERSIG{JimLewis - 2017-03-24}% - Version 1
      1 %USERSIG{PatrickLehmann - 2017-03-27}% - Version 1
      1 %USERSIG{RobGaddi - 2017-03-30}% - Version 1

   * Abstain:
      1 %USERSIG{PeterFlake - 2017-03-16}% - Version 1 - see comment

---++ Format Key
   * LRM text is shown between single quotes <sticky>%BLACK%'... P1076 LRM quoted text ...'%ENDCOLOR%</sticky>
   * Existing LRM text is shown in <sticky>%BLACK%<b>BLACK</b> coloured font%ENDCOLOR%</sticky>
   * Additional LRM text is shown in <sticky>%RED%<b>RED</b> coloured font%ENDCOLOR%</sticky>
   * Deleted LRM text is shown in <sticky>%RED%<strike><b>RED</b> with strike-through</strike>%ENDCOLOR%</sticky>
   * In order to try and emphasize text in italic font:
      * Italic font in existing LRM text is shown in <sticky>%GRAY%<i><b>GRAY</b> italic font</i>%BLACK%</sticky>
      * Italic font in new LRM text is shown in <sticky>%ORANGE%<i><b>ORANGE</b> italic font</i>%ENDCOLOR%</sticky>
      * Italic font in deleted LRM text is shown in <sticky>%ORANGE%<strike><i><b>ORANGE</b> with strike-through</i></strike>%ENDCOLOR%</sticky>
   * Editing instructions (and informative annotations) are shown in <sticky>%GREEN%<b>GREEN</b> coloured font%ENDCOLOR%</sticky>

---++ Details of Language Change:

%GREEN%
<b>Annot:</b> The following details the modifications to the LRM for the inclusion
of a *null* mode which enables the termination of a composite object's element
at an interface boundary, but disables the association of the element's actual part
from its formal part in the mapping of the interface object  instantiation.

---+++ LRM 4.2.2.1 Formal parameter lists
---++++!! page 21 top

%GREEN%
<b>Edit:</b> Replace the 1st paragraph beginning:

'For those parameters with modes, ...'

%GREEN%
<b>Edit:</b> with the following paragraph:

'For those parameters with modes, the only modes that are allowed for formal
parameters of a procedure are *in*, *inout*, and *out*. If the
mode is *in* and no object class is explicitly specified, <b>constant</b>
is assumed. If the mode is *inout* or *out*, and no object class is
explicitly specified, *variable* is assumed.%RED% For a parameter of a
composite type, a mode view indication is allowed, replacing the mode in order
to specify the individual composite elements of the parameter. In addition to
the allowable modes above, a mode view indication may also use the *null* mode.%BLACK%'

---+++ LRM 4.2.2.2 Constant and variable parameters
---++++!! page 21 middle

%GREEN%
<b>Edit:</b> Replace the 3rd paragraph beginning:

'For a nonforeign subprogram having a parameter whose type is an array or ...'

%GREEN%
<b>Edit:</b> with the following paragraph:

'For a nonforeign subprogram having a parameter whose type is an array or record, an implementation may
pass parameter values by copy, as for scalar types. In that case, after completion of the subprogram body, if
the mode is *inout* or *out*, the value of each subelement of the formal parameter is only copied back to the
corresponding subelement of the associated actual parameter if the subelement of the associated actual
parameter is not forced. If a parameter of mode *out* is passed by copy, then the range of each index position
of the actual parameter is copied in, and likewise for its subelements or slices. Alternatively, an
implementation may achieve these effects by reference; that is, by arranging that every use of the formal
parameter (to read or update its value) be treated as a use of the associated actual parameter throughout the
execution of the subprogram call. The language does not define which of these two mechanisms is to be
adopted for parameter passing, nor whether different calls to the same subprogram are to use the same
mechanism. The execution of a subprogram is erroneous if its effect depends on which mechanism is
selected by the implementation.%RED% The actual of a parameter subelement of mode
<b>null</b> is neither updated by copy nor reference.%BLACK%'

---+++ LRM 4.10 Conformance rules
---++++!! page 34 middle

%GREEN%
<b>Edit:</b> Replace the 4th paragraph beginning:

'Two subprogram declarations are said to have ...'

%GREEN%
<b>Edit:</b> with the following paragraph:

'Two subprogram declarations are said to have conforming profiles if and only
if both are procedures or both are functions, the parameter and result type
profiles of the subprograms are the same and, at each parameter position, the
corresponding parameters have the same %RED%<strike>class and mode</strike>
mode indication and class%BLACK%.'

---+++ LRM 5.3.2.2 Index constraints and discrete ranges
---++++!! page 48 middle

%GREEN%
<b>Edit:</b> Replace list item e) sublist item 3) with:

'
&emsp;3)
   * icon:web-bg If the subtype index range is undefined, and the interface object is associated in whole (see 6.5.7.1) or is a subelement that is associated individually by a single association element other than one in which the formal designator is a slice name, then the index range of the object is obtained from the association element in the following manner:
      * icon:line_lr For an interface object or subelement whose mode is *in*, <b>inout</b>%RED%, <strike>or </strike>%BLACK%<b>linkage</b>%RED%, or <b>null</b>%BLACK%, if the actual part includes a conversion function or a type conversion, then the result type of that function or the type mark of the type conversion shall define a constraint for the index range corresponding to the index range of the object, and the index range of the object is obtained from that constraint; otherwise, the index range is obtained from the object or value denoted by the actual designator.
      * icon:line_lr For an interface object or subelement whose mode is *out*, *buffer*, *inout*,%RED% <strike>or </strike>%BLACK%<b>linkage</b>%RED%, or <b>null</b>%BLACK%, if the formal part includes a conversion function or a type conversion, then the parameter subtype of that function or the type mark of the type conversion shall define a constraint for the index range corresponding to the index range of the object, and the index range is obtained from that constraint; otherwise, the index range is obtained from the object denoted by the actual designator.
   * icon:web-bg For an interface object of mode *inout* or *linkage*, the index range determined by the first rule shall be identical to the index range determined by the second rule.'

---+++ LRM 6.5.2 Interface object declarations
---++++!! page 73 middle

%GREEN%
<b>Edit:</b> Replace the BNF productions with:

<sticky><pre>%BLACK%
interface_object_declaration ::=
     interface_constant_declaration
   | interface_signal_declaration
   | interface_variable_declaration
   | interface_file_declaration

interface_constant_declaration ::=
     [ <b>constant</b> ] identifier_list : [ <b>in</b> ] subtype_indication [ := %GRAY%<i>static_</i>%BLACK%expression ]

interface_signal_declaration ::=
     [ <b>signal</b> ] identifier_list : [ mode ] subtype_indication [ <b>bus</b> ] [ := %GRAY%<i>static_</i>%BLACK%expression ]

interface_variable_declaration ::=
     [ <b>variable</b> ] identifier_list : [ mode ] subtype_indication [ := %GRAY%<i>static_</i>%BLACK%expression ]

interface_file_declaration ::=
     <b>file</b> identifier_list : subtype_indication

mode ::= <b>in</b> | <b>out</b> | <b>inout</b> | <b>buffer</b> | <b>linkage</b>%RED% | <b>null</b>
</pre></sticky>

---++++!! page 73 middle

%GREEN%
<b>Edit:</b> After the bullet point beginning:

'
   * icon:line_lr *linkage*. Reading and ...'

%GREEN%
<b>Edit:</b> insert the following bullet point:

'
   * icon:line_lr %RED%<b>null</b>. The *null* mode is intended for use within the elements of an interface object of composite type as defined in the mode view declaration described in 6.5.2.1. %BR% \
The element of a formal of a composite interface object with a mode view defining its mode as *null* is disassociated from its actual in any instantiation of the interface. The actual cannot read nor update the formal and neither can the formal read nor update the actual.

---++++!! page 80 bottom

%GREEN%
<b>Edit:</b> After the bullet point beginning:

'
&emsp;e)&emsp;For a formal port of mode *linkage*, ...'

%GREEN%
<b>Edit:</b> insert the following bullet point:

'%RED%
&emsp;f)&emsp;For a formal port of mode *null*, the associated actual may be a port of any mode.%BLACK%'

---+++ LRM Annex C Syntax summary
---++++!! page 491

%GREEN%
<b>Edit:</b> Replace the %BLACK%'mode'%GREEN% BNF production with the following:

<sticky><pre>%BLACK%
mode ::= <b>in</b> | <b>out</b> | <b>inout</b> | <b>buffer</b> | <b>linkage</b>%RED% | <b>null</b>%BLACK%                    [&#3618;&#3591; 6.5.2]
</pre></sticky>

---+++ LRM Annex I Glossary
---++++!! page 572

%GREEN%
<b>Edit:</b> Replace the %BLACK%'<b>mode</b>'%GREEN% item with the following:

'%BLACK%
<b>mode:</b> The direction of information flow through the port or parameter. Modes are in, out, inout, buffer, %RED%<strike>or </strike>%BLACK% linkage%RED%, or null%BLACK%. (6.5.2, 6.5.6.3)'

---++++!! page 573

%GREEN%
<b>Edit:</b> Insert after the %BLACK%'<b>nonpostponed process</b>'%GREEN% item the following:

'%RED%
<b>null:</b> The reserved word *null* may refer to its use as a literal in a null statement (10.14), as a literal in a null waveform element (10.5.2.2), as a literal defining a null access value for an access type or subtype (5.4.1, 9.3.2), or as a mode specifying a null mode (6.5.2, 6.5.6.3).%BLACK%'

-----

%GREEN%
<b>Edit:</b> Insert after the %BLACK%'<b>null array</b>'%GREEN% item the following:

'%RED%
<b>null mode:</b> A mode used within mode views, that disassociates the actual from the formal within the port/parameter mapping of a composite interface object. The actual cannot read, nor be updated by the formal. Similarly, the formal cannot read, nor be updated by the actual. (6.5.2, 6.5.6.3)%BLACK%'

---+ Comments

I prefer the keyword 'open' to 'null', since an open formal is like an open actual.

-- %BUBBLESIG{PeterFlake - 2017-03-16}%

The 'null' keyword was chosen specifically to distinquish it from an 'open'
port/parameter, because the port is neither 'open' on the formal side, nor on the
actual side. In reality the port/parameter doesn't exist at all, but is just a
lexical terminator for the composite element.

-- %BUBBLESIG{BrentHahoe - 2017-03-21}%
%COMMENT%
Topic revision: r1 - 2017-04-02 - 16:07:50 - TWikiGuest
P1076