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.

LCS Number: LCS-2016-045a
Version: 4
Date: 2017-Mar-25
Status: Voting
Author: Brent Hayhoe and Main.JimLewis
Source Doc: Interface Construct and Port Mode Configurations
Use Case - Complex RTL Signal CPU Interface
Summary: Provide the independent interface mode control for the elements of composite type objects
Related LCS: LCS-2016-045b
LCS-2016-045c

LCS-2016-045a.1

Voting Results: Cast your votes here

  • Yes:

  • No:

  • Abstain:

Revision History

Revision 4 2017-Mar-25
  • Removed Generics
  • and more

Revision 3 21-Mar-17

  • Added Generics

Format Key

  • LRM text is shown between single quotes '... P1076 LRM quoted text ...'
  • Existing LRM text is shown in BLACK coloured font
  • Additional LRM text is shown in RED coloured font
  • Deleted LRM text is shown in RED with strike-through
  • In order to try and emphasize text in italic font:
    • Italic font in existing LRM text is shown in GRAY italic font
    • Italic font in new LRM text is shown in ORANGE italic font
    • Italic font in deleted LRM text is shown in ORANGE with strike-through
  • Editing instructions (and informative annotations) are shown in GREEN coloured font

LCS Intent

Add mode view construct which will enable the individual mode control of the elements of interface objects of a composite type.

Details of Language Change:

3.2.3 Entity declarative part

page 8 bottom *Edit:* Add mode_view_declaration as a declarative item

entity_declarative_item ::=
   [beginning items unchanged]
   | type_declaration
   | subtype_declaration
   | mode_view_declaration
   | constant_declaration
   [remaining items unchanged]

3.3.2 Architecture declarative part

page 11 bottom *Edit:* Add mode_view_declaration as a declarative item

block_declarative_item ::=
   [beginning items unchanged]
   | type_declaration
   | subtype_declaration
   | mode_view_declaration
   | constant_declaration
   [remaining items unchanged]

4.3 Subprogram bodies

page 23 bottom *Edit:* Add mode_view_declaration as a declarative item

?Should subprograms allow mode view declaration to be used for lower level subprograms? subprogram_declarative_item ::=

LRM 4.7 Package declarations

page 30 middle *Edit:* Add mode_view_declaration as a declarative item


package_declarative_item ::=
   [beginning items unchanged]
   | type_declaration
   | subtype_declaration
   | mode_view_declaration
   | constant_declaration
   [remaining items unchanged]

4.8 Package bodies

page 32 top *Edit:* Add mode_view_declaration as a declarative item

?Should a package body allow mode view declaration to be used for lower level subprograms? package_body_declarative_item ::=

6.3 Subtype declarations

Add paragraph following 3 paragraph(shown below) where BNF = 1 paragraph

A subtype indication defines a subtype of the base type of the type mark.

A subtype that has a resolution indication is called a resolved subtype. A type or subtype that does not have a resolution indication is called an unresolved type or unresolved subtype respectively.

LRM 6.5.2 Interface object declarations

Add new section title on page 73 middle

*6.5.2.1 General*

page 73 middle, *Edit:* Revise BNF productions as follows:


interface_object_declaration ::=
     interface_constant_declaration
   | interface_signal_declaration
   | interface_variable_declaration
   | interface_file_declaration

interface_constant_declaration ::=
     [ constant ] identifier_list : [ in ] subtype_indication [ := static_expression ]

interface_signal_declaration ::=
     [ signal ] identifier_list : [ mode ] subtype_indication [ bus ] [ := static_expression ] signal_mode_indication

interface_variable_declaration ::=
     [ variable ] identifier_list : [ mode ] subtype_indication [ := static_expression ] variable_mode_indication

interface_file_declaration ::=
     file identifier_list : subtype_indication

mode_indication ::=
     [ mode ] subtype_indication [ bus ] [ := static_expression ] 
   | mode_view_indication

mode ::= in | out | inout | buffer | linkage

mode_view_indication ::=
     view mode_view_name [ of unresolved_composite_subtype_indication ]

Edit: page 73 last paragraph

If no mode is explicitly given in an interface declaration other than an interface file declaration, mode in is assumed.

For an interface constant declaration, if mode in is not explicitly given, it is assumed. For an interface signal or variable declaration, if a mode indication is not a mode view indication and no mode is explicitly given, mode in is assumed.

Edit: page 74 top, 3rd and 4th paragraph paragraph add paragraphs after 5th

Additional paragraphs are shown for review and are unchanged by this LCS

1st paragraph no edits
For an interface constant declaration (other than a formal parameter of the predefined = or /= operator for an access type) or an interface signal declaration, the subtype indication shall define a subtype that is neither a file type, an access type, nor a protected type. Moreover, the subtype indication shall not denote a composite type with a subelement that is of an access type.

2nd paragraph no edits
For an interface file declaration, it is an error if the subtype indication does not denote a subtype of a file type.

3rd paragraph with edits
If the mode indication of 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. It is an error if the mode indication of an interface variable declaration includes the reserved word bus.

4rd paragraph with edits
If an interface constant declaration or the mode indication of an interface signal or constant declaration 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 or a mode indication of an interface declaration and any of the following conditions hold:
- The mode is linkage.
- The interface object is a formal signal parameter.
- The interface object is a formal variable parameter of mode other than in.
- The subtype indication of the interface declaration denotes a protected type.

5rd paragraph no edits
In an interface signal declaration appearing in a port list, the default expression defines the default value(s) associated with the interface signal or its subelements. In the absence of a default expression, an implicit default value is assumed for the signal or for each scalar subelement, as defined for signal declarations (see 6.4.2.3). The value, whether implicitly or explicitly provided, is used to determine the initial contents of drivers, if any, of the interface signal as specified for signal declarations.

New paragraph after 5th paragraph (above)
A mode view indication allows each element of a composite to have a different interface mode. Each element of the composite with its respective mode declared in the mode view indication is equivalent to each element being declared as a formal signal port with the mode and type or subtype of the respective composite element.

remaining paragraphs of the section are unedited, 6th paragraph below provided for reference
In an interface signal declaration appearing in a port list, the default expression defines the default value(s) associated with the interface signal or its subelements. In the absence of a default expression, an implicit default value is assumed for the signal or for each scalar subelement, as defined for signal declarations (see 6.4.2.3). The value, whether implicitly or explicitly provided, is used to determine the initial contents of drivers, if any, of the interface signal as specified for signal declarations.

Edit: 3rd paragraph on page 75

An interface object has one of the following modes:

The mode of an interface object or a mode view declaration has one of the following modes:

add new section just before 6.5.3 and after Note 8 on page 75 bottom

*6.5.2.2 Interface mode view declarations*

Additions to 6.5.2.2 (new section)

Add the following

A mode view declaration declares the mode for elements of a composite type or subtype. Mode views may be used in either an interface signal or variable object declaration or within another mode view declaration.


mode_view_declaration ::=
     view identifier of unresolved_composite_subtype_indication is
          { mode_view_element_definition }
     end view [ mode_view_simple_name ] ;

mode_view_element_definition ::=
     composite_element_list : element_mode_indication  ;

composite_element_list ::=
     composite_element_choice { , composite_element_choice }
     
element_mode_indication ::=
     mode  
   | mode_view_indication

A mode view declaration applies to the specified type or subtype as well as any other subtype that is a subtype of the same base type. For a mode view declaration, it is an error if either a resolution function appears in the subtype indication or the subtype is a resolved subtype. However, the elements of a composite may be resolved subtypes.

If the type or subtype of a mode view declaration denotes a record, the composite element choice shall be an identifier. Each record element identifier of the type or subtype shall have a corresponding identifier in the mode view declaration.

If the type or subtype of a mode view declaration denotes an array, the composite element choice shall be a simple expression, a discrete range, or the key word others. In addition, each element of the array shall have the same mode or mode view indication.

It is an error if the mode of an element mode indication is linkage.

LRM 7.2 Attribute specification

Add view to the end of the production for entity_class on page 95 middle

entity_class ::=
      [all unspecified items are unchanged]
      | sequence
      | view

LRM 15.10 Reserved words

Add view to reserved word list on page 236 in alphabetical order

view

LRM Annex C Syntax summary -- To be updated

page 481 To be updated

Edit: Insert after the 'component_specification' BNF production the following:


composite_element_list ::=                                              [§ 6.5.2.1.1]
     composite_element_choice { , composite_element_choice }

page 484

Edit: Replace the 'entity_class' BNF production with the following:


entity_class ::=                                                        [§ 7.2]

page 489

Edit: Replace the 'interface_signal_declaration' BNF production with the following:


interface_signal_declaration ::=                                        [§ 6.5.2]

page 490

Edit: Replace the 'interface_variable_declaration' BNF production with the following:


interface_variable_declaration ::=                                      [§ 6.5.2]


Edit: Insert after the 'mode' BNF production the following:


mode_indication ::=                                                     [§ 6.5.2]

mode_view_declaration ::=                                               [§ 6.5.2.1.1]

mode_view_element_definition ::=                                        [§ 6.5.2.1.1]

mode_view_header ::=                                                    [§ 6.5.2.1.1]

mode_view_indication ::=                                                [§ 6.5.2]

page 492

Edit: Replace the 'package_declarative_item' BNF production with the following:


package_declarative_item ::=                                            [§ 4.7]

LRM Annex I Glossary

Add definition of mode view declaration in alphabetic order on page 572

*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)'

Comments

Topic revision: r3 - 2017-04-02 - 16:07:50 - PatrickLehmann
 
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