BAHScratchPage-c < Sandbox

Sandbox Web>BAHScratchPage-c (2017-03-23, BrentHahoe) (raw view)EditAttach
<sticky><!--
   * Local SB = <sticky><b>
   * Local BS = </b></sticky>
--></sticky>

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

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

%TOC%

| %SB%LCS Number:%BS%  | LCS-2016-045a |
| %SB%Version:%BS%     | 3 |
| %SB%Date:%BS%        | 21-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% | [[TopLCS2016_045b][LCS-2016-045b]] %BR% \
                         [[TopLCS2016_045c][LCS-2016-045c]] |

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

   * Yes:
      1. %USERSIG{BrentHahoe - 2017-03-21}% - Version 3
      1. %USERSIG{SteveGrout - 2017-03-16}% - Version 1

   * No:
      1. %USERSIG{PeterFlake - 2017-03-16}% - Version 1 - see comment
      1. %USERSIG{PatrickLehmann - 2017-03-20}% - ver 2

   * Abstain:

---++ 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%
*Annot:* The following details the modifications to the LRM for the inclusion of a new mode *view* construct which will enable the individual mode control of the elements of interface objects of a composite type.

---+++ LRM 4.7 Package declarations
---++++!! page 30 middle

%GREEN%
*Edit:* Replace the BNF productions with:
<sticky><pre>%BLACK%
package_declaration ::=
     <b>package</b> identifier <b>is</b>
          package_header
          package_declarative_part
     <b>end</b> [ <b>package</b> ] [ %GRAY%<i>package_</i>%BLACK%simple_name ] ;

package_header ::=
     [ generic_clause
     [ generic_map_aspect ; ] ]

package_declarative_part ::=
     { package_declarative_item }

package_declarative_item ::=
     subprogram_declaration
   | subprogram_instantiation_declaration
   | package_declaration
   | package_instantiation_declaration
   | type_declaration
   | subtype_declaration%RED%
   | mode_view_declaration%BLACK%
   | constant_declaration
   | signal_declaration
   | variable_declaration
   | file_declaration
   | alias_declaration
   | component_declaration
   | attribute_declaration
   | attribute_specification
   | disconnection_specification
   | use_clause
   | group_template_declaration
   | group_declaration
   | %GRAY%<i>PSL_</i>%BLACK%Property_Declaration
   | %GRAY%<i>PSL_</i>%BLACK%Sequence_Declaration
</pre></sticky>

%GREEN%
*Annot:* Update the package declaritive item list. A *view* declaration is only allowed in a package declaration (not in a body)?

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

%GREEN%
*Edit:* 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 : %RED%<strike>[ mode ] subtype_indication [ <b>bus</b> ] [ := %ORANGE%<i>static_</i>%RED%expression ]</strike> %ORANGE%<i>signal_</i>%RED%mode_indication%BLACK%

interface_variable_declaration ::=
     [ <b>variable</b> ] identifier_list : %RED%<strike>[ mode ] subtype_indication [ := %ORANGE%<i>static_</i>%RED%expression ]</strike> %ORANGE%<i>variable_</i>%RED%mode_indication%BLACK%

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

mode_indication ::=
     [ mode ] [ subtype_indication [ <b>bus</b> ] [ := %ORANGE%<i>static_</i>%RED%expression ] ]
   | mode_view_indication%BLACK%

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

mode_view_indication ::=
     <b>view</b> %ORANGE%<i>mode_view_</i>%RED%name
          [ %ORANGE%<i>constant_</i>%RED%generic_map_aspect ]
               [ <b>of</b> %ORANGE%<i>unresolved_composite_</i>%RED%subtype_indication ]
</pre></sticky>

%GREEN%
*Annot:* The 'mode view indication' appears in an interface object declaration where a mode would appear. %BR% As the mode is optional (in interface object declarations) the *view* reserved word is used for parsing simplification. %BR% The 'mode indication' is used within a 'mode view declaration' to define the mode of an element, or in the case of when an element is itself of a composite type, the further option of it being another 'mode view indication'.

-----

%GREEN%
*Edit:* Replace the last paragraph beginning:

'If no mode is explicitly given ...'

%GREEN%
*Edit:* with the following paragraph:

#InMiEgIaI
If no mode is explicitly given in an interface declaration %RED%(or in the mode indication of an interface declaration)%BLACK% other than an interface file declaration, mode *in* is assumed.

-----

%GREEN%
*Edit:* Insert new paragraph after the last paragraph:

#ItMiOaIdD
%RED%
If the mode indication of an interface declaration does not define a mode view indication, then a subtype indication must be present.

---++++!! page 74 top

%GREEN%
*Edit:* Replace the third paragraph beginning:

'If an interface signal declaration includes ...'

%GREEN%
*Edit:* with the following paragraph:

If %RED%the mode indication of%BLACK% an interface signal declaration includes the reserved word *bus*, then the signal declared by that interface declaration is a guarded signal of signal kind *bus*. %RED%It is an error if the mode indication of an interface variable declaration includes the reserved word *bus*.

-----

%GREEN%
*Edit:* Replace the fourth paragraph beginning:

'If an interface declaration contains a ":=" ...'

%GREEN%
*Edit:* with the following paragraph:

If an interface declaration %RED%(or a mode indication of an interface declaration)%BLACK% contains a ":=" symbol followed by an expression, the expression is said to be the _default expression_ of the interface object. The type of a default expression shall be that of the corresponding interface object. It is an error if a default expression appears in an interface declaration %RED%(or a mode indication of an interface declaration)%BLACK% and any of the following conditions hold:

-----

%GREEN%
*Edit:* After the fifth paragraph beginning:

'In an interface signal declaration appearing in ...'

%GREEN%
*Edit:* Insert the following paragraph:

%RED%
A mode view indication specifies a named mode view for the elements of an interface object of a composite type or subtype.

---++++!! page 75 bottom

%GREEN%
*Edit:* Insert the following section after "NOTE 8":

%RED%
*6.5.2.1 Interface mode view declarations*

%RED%
*6.5.2.1.1 General*

%RED%
A mode view declaration defines a named set of modes to be used for the elements of an interface object of a composite type or subtype. More than one mode view may be defined for a given composite type or subtype.

%RED%
A named mode view is used within an interface object declaration in order to define the modes of each element of the given composite type or subtype.

%RED%
The reserved word *view* indicates the start of a mode view declaration and the start of a mode view indication.
<sticky><pre>%RED%
mode_view_declaration ::=
     <b>view</b> identifier
          [ mode_view_header ]
     <b>of</b> %ORANGE%<i>unresolved_composite_</i>%RED%subtype_indication <b>is</b>
          { mode_view_element_definition }
     <b>end</b> <b>view</b> [ %ORANGE%<i>mode_view_</i>%RED%simple_name ] ;

mode_view_header ::=
     <b>generic</b> ( %ORANGE%<i>constant_</i>%RED%generic_list )

mode_view_element_definition ::=
     composite_element_list [ : %ORANGE%<i>composite_element_</i>%RED%mode_indication ] ;

composite_element_list ::=
     %ORANGE%<i>composite_element_</i>%RED%choice { , %ORANGE%<i>composite_element_</i>%RED%choice }
</pre></sticky>

%RED% 
The constant generic list in the mode view header defines generics whose
associated actuals may be determined by the environment (see 6.5.6.2). The
generic clause is only allowed to contain interface constant declarations. 

%RED%
The composite subtype indication of a mode view declaration must not be of a resolved type or subtype.

%RED%
However, the subtype indication of a mode indication of a composite element may be of a resolved type or subtype.

%RED%
The identifiers defined by the mode view element definition must lexically conform to those of the elements of the composite subtype indication.

%RED%
A mode indication specifies a mode, or a named mode view indication for an element of a given composite object type or subtype.

#IaMiNsT
%RED%
If the mode indication does not specify a mode view indication, then: %BR% \
   &emsp;&mdash;&ensp;if a mode is not specified then the default mode *in* is defined; %BR% \
   &emsp;&mdash;&ensp;the element subtype indication may be included; %BR% \
   &emsp;&mdash;&ensp;an element %ORANGE%<i>default expression</i>%RED% may be included following a ":=" symbol.

%RED%
If the mode indication of a composite element includes the reserved word *bus*, then the element is a guarded signal of signal kind *bus*. This type of mode indication must only be used within an interface signal declaration. It is an error if it is used within an interface variable declaration.

%RED%
A mode view element definition with a choice that is an element simple name is only allowed in a record aggregate. A mode view element definition with a choice that is a simple expression or a discrete range is only allowed in an array aggregate: a simple expression specifies the element at the corresponding index value, whereas a discrete range specifies the elements at each of the index values in the range. 

%GREEN%
*Annot:*A composite element 'mode indication' defines either a basic mode, or a mode view indication if the composite element itself is of a composite type or subtype.

%GREEN%
*Annot:* A mode view may be record based or array based.

---+++ LRM 7.2 Attribute specification
---++++!! page 95 middle

%GREEN%
*Edit:* Replace the BNF productions with:
<sticky><pre>%BLACK%
attribute_specification ::=
        <b>attribute</b> attribute_designator <b>of</b> entity_specification <b>is</b> expression ;

entity_specification ::=
        entity_name_list : entity_class

entity_class ::=
        <b>entity</b>
      | <b>architecture</b>
      | <b>configuration</b>
      | <b>procedure</b>
      | <b>function</b>
      | <b>package</b>
      | <b>type</b>
      | <b>subtype</b>
      | <b>constant</b>
      | <b>signal</b>
      | <b>variable</b>
      | <b>component</b>
      | <b>label</b>
      | <b>literal</b>
      | <b>units</b>
      | <b>group</b>
      | <b>file</b>
      | <b>property</b>
      | <b>sequence</b>%RED%
      | <b>view</b>%BLACK%

entity_name_list ::=
        entity_designator { , entity_designator }
      | <b>others</b>
      | <b>all</b>
</pre></sticky>

%GREEN%
*Annot:* A *view* is defined as a 'declaration' and therefore a member of the entity class allowing it to have an attribute (e.g. V'subtype returning the composite type of the *view*).

---+++ LRM 15.10 Reserved words
---++++!! page 236

%GREEN%
*Edit:* Insert the new reserved word '%RED%<b>view</b>%GREEN%' after the reserved word '%BLACK%<b>variable</b>%GREEN%' in the list:

%TABLE{disableallsort="on" tableframe="void" tablerules ="none" valign="baseline" dataalign="left" columnwidths="20%,20%,20%,20%"}%
 | | %SB%abs%BS%              | %SB%fairness%BS% | %SB%nand%BS%               | %SB%select%BS%     |
 | | %SB%access%BS%           | %SB%file%BS%     | %SB%new%BS%                | %SB%sequence%BS%   |
 | | %SB%after%BS%            | %SB%for%BS%      | %SB%next%BS%               | %SB%severity%BS%   |
 | | %SB%alias%BS%            | %SB%force%BS%    | %SB%nor%BS%                | %SB%signal%BS%     |
 | | %SB%all%BS%              | %SB%function%BS% | %SB%not%BS%                | %SB%shared%BS%     |
 | | %SB%and%BS%              |                  | %SB%null%BS%               | %SB%sla%BS%        |
 | | %SB%architecture%BS%     | %SB%generate%BS% |                            | %SB%sll%BS%        |
 | | %SB%array%BS%            | %SB%generic%BS%  | %SB%of%BS%                 | %SB%sra%BS%        |
 | | %SB%assert%BS%           | %SB%group%BS%    | %SB%on%BS%                 | %SB%srl%BS%        |
 | | %SB%assume%BS%           | %SB%guarded%BS%  | %SB%open%BS%               | %SB%strong%BS%     |
 | | %SB%assume_guarantee%BS% |                  | %SB%or%BS%                 | %SB%subtype%BS%    |
 | | %SB%attribute%BS%        | %SB%if%BS%       | %SB%others%BS%             |                    |
 | |                          | %SB%impure%BS%   | %SB%out%BS%                | %SB%then%BS%       |
 | | %SB%begin%BS%            | %SB%in%BS%       |                            | %SB%to%BS%         |
 | | %SB%block%BS%            | %SB%inertial%BS% | %SB%package%BS%            | %SB%transport%BS%  |
 | | %SB%body%BS%             | %SB%inout%BS%    | %SB%parameter%BS%          | %SB%type%BS%       |
 | | %SB%buffer%BS%           | %SB%is%BS%       | %SB%port%BS%               |                    |
 | | %SB%bus%BS%              |                  | %SB%postponed%BS%          | %SB%unaffected%BS% |
 | |                          | %SB%label%BS%    | %SB%procedure%BS%          | %SB%units%BS%      |
 | | %SB%case%BS%             | %SB%library%BS%  | %SB%process%BS%            | %SB%until%BS%      |
 | | %SB%component%BS%        | %SB%linkage%BS%  | %SB%property%BS%           | %SB%use%BS%        |
 | | %SB%configuration%BS%    | %SB%literal%BS%  | %SB%protected%BS%          |                    |
 | | %SB%constant%BS%         | %SB%loop%BS%     | %SB%pure%BS%               | %SB%variable%BS%   |
 | | %SB%context%BS%          |                  |                            | %RED%%BS%view%BS%  |
 | | %SB%cover%BS%            | %SB%map%BS%      | %SB%range%BS%              | %SB%vmode%BS%      |
 | |                          | %SB%mod%BS%      | %SB%record%BS%             | %SB%vprop%BS%      |
 | | %SB%default%BS%          |                  | %SB%register%BS%           | %SB%vunit%BS%      |
 | | %SB%disconnect%BS%       |                  | %SB%reject%BS%             |                    |
 | | %SB%downto%BS%           |                  | %SB%release%BS%            | %SB%wait%BS%       |
 | |                          |                  | %SB%rem%BS%                | %SB%when%BS%       |
 | | %SB%else%BS%             |                  | %SB%report%BS%             | %SB%while%BS%      |
 | | %SB%elsif%BS%            |                  | %SB%restrict%BS%           | %SB%with%BS%       |
 | | %SB%end%BS%              |                  | %SB%restrict_guarantee%BS% |                    |
 | | %SB%entity%BS%           |                  | %SB%return%BS%             | %SB%xnor%BS%       |
 | | %SB%exit%BS%             |                  | %SB%rol%BS%                | %SB%xor%BS%        |
 | |                          |                  | %SB%ror%BS%                |                    |

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

%GREEN%
*Edit:* Insert after the '%BLACK%component_specification%GREEN%' BNF production the following:
<sticky><pre>%RED%
composite_element_list ::=                                              [§ 6.5.2.1.1]
     %ORANGE%<i>composite_element_</i>%RED%choice { , %ORANGE%<i>composite_element_</i>%RED%choice }
</pre></sticky>

---++++!! page 484

%GREEN%
*Edit:* Replace the '%BLACK%entity_class%GREEN%' BNF production with the following:
<sticky><pre>%BLACK%
entity_class ::=                                                        [§ 7.2]
        <b>entity</b>
      | <b>architecture</b>
      | <b>configuration</b>
      | <b>procedure</b>
      | <b>function</b>
      | <b>package</b>
      | <b>type</b>
      | <b>subtype</b>
      | <b>constant</b>
      | <b>signal</b>
      | <b>variable</b>
      | <b>component</b>
      | <b>label</b>
      | <b>literal</b>
      | <b>units</b>
      | <b>group</b>
      | <b>file</b>
      | <b>property</b>
      | <b>sequence</b>%RED%
      | <b>view</b>%BLACK%
</pre></sticky>

---++++!! page 489

%GREEN%
*Edit:* Replace the '%BLACK%interface_signal_declaration%GREEN%' BNF production with the following:
<sticky><pre>%BLACK%
interface_signal_declaration ::=                                        [§ 6.5.2]
     [ <b>signal</b> ] identifier_list : %RED%<strike>[ mode ] subtype_indication [ <b>bus</b> ] [ := %ORANGE%<i>static_</i>%RED%expression ]</strike> %ORANGE%<i>signal_</i>%RED%mode_indication
</pre></sticky>

---++++!! page 490

%GREEN%
*Edit:* Replace the '%BLACK%interface_variable_declaration%GREEN%' BNF production with the following:
<sticky><pre>%BLACK%
interface_variable_declaration ::=                                      [§ 6.5.2]
     [ <b>variable</b> ] identifier_list : %RED%<strike>[ mode ] subtype_indication [ := %ORANGE%<i>static_</i>%RED%expression ]</strike> %ORANGE%<i>variable_</i>%RED%mode_indication
</pre></sticky>

-----

%GREEN%
*Edit:* Insert after the '%BLACK%mode%GREEN%' BNF production the following:
<sticky><pre>%RED%
mode_indication ::=                                                     [§ 6.5.2]
     [ mode ] [ subtype_indication [ <b>bus</b> ] [ := %ORANGE%<i>static_</i>%RED%expression ] ]
   | mode_view_indication

mode_view_declaration ::=                                               [§ 6.5.2.1.1]
     <b>view</b> identifier
          [ mode_view_header ]
     <b>of</b> %ORANGE%<i>unresolved_composite_</i>%RED%subtype_indication <b>is</b>
          { mode_view_element_definition }
     <b>end</b> <b>view</b> [ %ORANGE%<i>mode_view_</i>%RED%simple_name ] ;

mode_view_element_definition ::=                                        [§ 6.5.2.1.1]
     composite_element_list [ : %ORANGE%<i>composite_element_</i>%RED%mode_indication ] ;

mode_view_header ::=                                                    [§ 6.5.2.1.1]
     <b>generic</b> ( %ORANGE%<i>constant_</i>%RED%generic_list )

mode_view_indication ::=                                                [§ 6.5.2]
     <b>view</b> %ORANGE%<i>mode_view_</i>%RED%name
          [ %ORANGE%<i>constant_</i>%RED%generic_map_aspect ]
               [ <b>of</b> %ORANGE%<i>unresolved_composite_</i>%RED%subtype_indication ]

</pre></sticky>

---++++!! page 492

%GREEN%
*Edit:* Replace the '%BLACK%package_declarative_item%GREEN%' BNF production with the following:
<sticky><pre>%BLACK%
package_declarative_item ::=                                            [§ 4.7]
     subprogram_declaration
   | subprogram_instantiation_declaration
   | package_declaration
   | package_instantiation_declaration
   | type_declaration
   | subtype_declaration%RED%
   | mode_view_declaration%BLACK%
   | constant_declaration
   | signal_declaration
   | variable_declaration
   | file_declaration
   | alias_declaration
   | component_declaration
   | attribute_declaration
   | attribute_specification
   | disconnection_specification
   | use_clause
   | group_template_declaration
   | group_declaration
   | %GRAY%<i>PSL_</i>%BLACK%Property_Declaration
   | %GRAY%<i>PSL_</i>%BLACK%Sequence_Declaration
</pre></sticky>

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

%GREEN%
*Edit:* Insert after the '%BLACK%<b>mode</b>%GREEN%' item the following:

'%RED%
*mode view declaration:* A declaration of the modes, of the individual elements, of a composite interface object. A mode view is associated with a composite type or subtype. There may be more than one mode view associated with a given composite type or subtype. (6.5.2, 6.5.6.3)%BLACK%'

---+ Comments

Why do we need mode_view_indication for subprogram variables? A variable of mode_view_indication is no different of a mode of inout.

-- %BUBBLESIG{JimLewis - 2017-01-09}%


Whilst an interface variable of a protected type must have a mode of 'inout', those of a non-protected type may have any mode associated with them.

The 'mode_view_indication' is used for interface variables of a composite type, in order to enable the independent control of the mode associated with each of its elements (similar to those of an interface signal object).

-- %BUBBLESIG{BrentHahoe - 2017-01-10}%


WRT variables, since there are no drivers, the only reason to do this for the formalism of access control of the variables.   WIthout it, all variables are read at the start and written back upon completion.   

-- %BUBBLESIG{JimLewis - 2017-01-11}%


Edits for p. 490: the indications appear to be in 6.5.2 rather than 6.5.2.1. The grammar rules from 6.5.2.2 and 6.5.2.3 seem to be either missing or mislabeled.

-- %BUBBLESIG{ThomasPreusser - 2017-02-23}%


LRM Annex C BNF production section references corrected.

Grammar rules are still in development, hence draft status.

-- %BUBBLESIG{BrentHahoe - 2017-02-24}%


1) The EBNF you have written does not match the syntax you show at: 

http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/InterfaceConstructandPortModeConfigurations

You need to delete the end that is part of mode_view_declaration and add the keyword view to the end of a record view. OTOH, a view of a named object is either a single record or a single array. Is there a reason to identify it as an array or a record? Why not just go straight to an element view definition? We do exactly that in an aggregate.

2) Your syntax allows a view object to be both initialized in the interface (as the static_expression) and within the mode indication (as the element_static_expression). I think this should be limited to 1 of these - probably the element static expression.

Also, it does not make alot of sense to do it as the static expression as initializing mode in and mode out have different meanings.

3) We probably want to disallow a composite whose subtype is resolved to be used in a mode view indication. Note it is ok for subelements to have a resolution function.

The problem with a resolved composite is that something that puts a driver on a single element puts a driver on all elements. Basically this implies that if one is an out, they all are an out and vice versa, if one is an in, then they all are in, and hence, the all end up being required to have the same IO modes.

4) "[bus]" is only appropriate for a resolved type. Since resolved types don't make senes (see 3 above), then bus does not either. OTOH, we probably want to have this as part of the mode view declaration.

5) Do we need something for association of an object, or is it already covered since the object in the association is a composite.

-- %BUBBLESIG{JimLewis - 2017-03-02}%


Are we going to introduce something to inverse/reverse the modes of the port? Such as one of the following: 'conjugate, 'inverse, 'reverse? Globals like clock seem to muck this up some - so maybe not or maybe also introduce a 'global on a mode view declaration? This could be a separate LCS.

Are we going to allow aliases of views?   Do we need to do something to allow this?

-- %BUBBLESIG{JimLewis - 2017-03-02}%


%RED%<u><b>
Version 2</b></u>

BNFs have been restructured to hopefully avoid parsing ambiguities.

Additional text has been altered to support the new BNF structure.

!@JL 1) The [[InterfaceConstructandPortModeConfigurations#Analysis][Analysis]] section should now reflect the currect syntax and structure.

!@JL 2) Done.

!@JL 3) Done.

!@JL 4) Done.

!@JL 5) Already covered I think.

!@JL part2a For the new attribute, see [[TopLCS2016_045c][LCS-2016-045c]].

!@JL part2b I had a look at aliases and I think as the mode view declaration is defined as an entity class, it falls into being a simple named "nonobject" alias without any other additions.

-- %BUBBLESIG{BrentHahoe - 2017-03-15}%


I think 'choice' is the wrong syntax, since it includes 'simple expression'.

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


I'm with Peter on the terminology. Would a <i>composite_element_</i>list not be made of one or more _composite_element_ _identifier?

Also, as mentioned on the call, this could definitely do with examples. What about:
<sticky><pre>
type handshake is
 record
   valid, ready: bit;
 end record;

view ControllerHandshake of handshake is
  valid : out;
  ready : in;
end view;

view TargetHandshake of handshake is
  valid : in;
  ready : out;
end view;
</pre></sticky>

Also, a thing I'm not clear on from all this: if I've got the following:
<sticky><pre>
type T is
  record
   a, b, c : bit;
 end record;

view V of T is
  a, c : in;
end view V;
</pre></sticky>

What direction, if any, does V.b have?

-- %BUBBLESIG{RobGaddi - 2017-03-19}%


The presented EBNF breakes the EBNF for normal (old-style modes). The subtype indication can not be optional.

Why is a =mode_indication= optional in a =mode_view_element_definition=?

The lexically conformance rule makes no sense. We are talking about a single lexical element: an identifier.

Why have modes default expressions?

This LCS does not describe how a mode view works/behaves. It misses what choices are allowed (e.g. array indices, because it's still a composite, what I would forbid ...) and how elements in a mode correlate with composite elements.

Don't insert auxiliary sentences with parentheses. It's still an English text in prose.

-- %BUBBLESIG{PatrickLehmann - 2017-03-20}%


!@PF & !@RG
I think choice is the right syntax.   Choice is used with aggregates.   The simple expression allows choices to also be used with array indices.  

-- %BUBBLESIG{JimLewis - 2017-03-20}%


WRT !@PL1, I think we either need text saying that subtype indication is required for interface declarations and optional for mode view declarations.   It would have been

I agree with !@PL2

!@PL6 This LCS uses choice, just like aggregate specifies choice.   To allow use of "," instead of "|" it does not use choices.   WRT array indices, what VHDL does for arrays it generally does for records.  Why would we change that pattern?  

!@PL6  Aggregates has the following text.   Were thinking it needs something like this:
An element association with a choice that is an element simple name is only allowed in a record aggregate.
An element association with a choice that is a simple expression or a discrete range is only allowed in an
array aggregate: a simple expression specifies the element at the corresponding index value, whereas a
discrete range specifies the elements at each of the index values in the range.

-- %BUBBLESIG{JimLewis - 2017-03-20}%


Section numbering is off.   If a section has a subsection, then it has no text in it.   Hence, you need to change your section  6.5.2.1 Interface composite object mode views to 6.5.2.2 and the text that is before this section should be in a section titled "6.5.2.1 General"

-- %BUBBLESIG{JimLewis - 2017-03-20}%


!@RG: WRT "What direction, if any, does V.b have?"
V.b would have a defualt mode of *in*. However, I am proposing that the list has to be complete and would therefore look like this:
<sticky><pre>
view V of T is
  a, c : in;
  b;
end view V;
</pre></sticky>


!@JL WRT !@PL1 & !@PL2: "Why is a mode_indication optional ..."; %BR% \
A mode indication is used within a mode view declaration and an interface object declaration. In an interface object declaration, the only item that is not optional is the subtype indication as described here: %BR% \
   &emsp;[[#ItMiOaIdD]["If the mode indication of an interface declaration ..."]]

However, in a mode view declaration, all that is required is the mode and if
that is ommitted then *in* is assumed as stated here: %BR% \
   &emsp;[[#InMiEgIaI]["If no mode is explicitly given ..."]]

No modifications made.


!@PL3: "The lexically conformance rule ..."; %BR% \
Changed to 'mode view element definition' which I think is correct.


!@JL WRT !@PL6: "This LCS uses choice ..."; %BR% \
No modifications made.


!@JL WRT !@PL6: "Aggregates has the following ..."; %BR% \
I've added slightly modified text as a new paragraph.


!@JL WRT "Section numbering"; %BR% \
I hadn't noticed that before and so have now changed the section numbering.


%RED%<u><b>
Version 3</b></u>
   * Added generic interface to mode views 
   * Added element choice restrictions
   * Restructured new section numbering

-- %BUBBLESIG{BrentHahoe - 2017-03-21}%
%COMMENT%
Topic revision: r23 - 2017-03-23 - 13:12:39 - BrentHahoe
Sandbox