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.

Voting Results: Cast your votes here

• Yes:
  1. Brent Hayhoe - 2017-03-21 - Version 3
  2. Steve Grout - 2017-03-16 - Version 1

• No:
  1. Peter Flake - 2017-03-16 - Version 1 - see comment
  2. Patrick Lehmann - 2017-03-20 - ver 2

• Abstain:

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

Details of Language Change:

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

Edit: Replace the BNF productions with:

package_declaration ::=
     package identifier is
          package_header
          package_declarative_part
     end [ package ] [ package_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
   | mode_view_declaration
   | 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
   | PSL_Property_Declaration
   | PSL_Sequence_Declaration

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

Edit: Replace the BNF productions with:

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
          [ constant_generic_map_aspect ]
               [ of unresolved_composite_subtype_indication ]

Annot: The 'mode view indication' appears in an interface object declaration where a mode would appear.
As the mode is optional (in interface object declarations) the view reserved word is used for parsing simplification.
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'.

Edit: Replace the last paragraph beginning:

'If no mode is explicitly given ...'

Edit: with the following paragraph:

If no mode is explicitly given in an interface declaration (or in the mode indication of an interface declaration) other than an interface file declaration, mode in is assumed.

Edit: Insert new paragraph after the last paragraph:

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

Edit: Replace the third paragraph beginning:

'If an interface signal declaration includes ...'

Edit: with the following paragraph:

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.

Edit: Replace the fourth paragraph beginning:

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

Edit: with the following paragraph:

If an interface declaration (or a mode indication of an interface 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:

Edit: After the fifth paragraph beginning:

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

Edit: Insert the following paragraph:

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

Edit: Insert the following section after "NOTE 8":

6.5.2.1 Interface mode view declarations

6.5.2.1.1 General

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.

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.

The reserved word view indicates the start of a mode view declaration and the start of a mode view indication.

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

mode_view_header ::=
     generic ( constant_generic_list )

mode_view_element_definition ::=
     composite_element_list [ : composite_element_mode_indication ] ;

composite_element_list ::=
     composite_element_choice { , composite_element_choice }

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.

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

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

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

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

If the mode indication does not specify a mode view indication, then:
 — if a mode is not specified then the default mode in is defined;
 — the element subtype indication may be included;
 — an element default expression may be included following a ":=" symbol.

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.

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.

*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.

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

LRM 7.2 Attribute specification

page 95 middle

Edit: Replace the BNF productions with:

attribute_specification ::=
        attribute attribute_designator of entity_specification is expression ;

entity_specification ::=
        entity_name_list : entity_class

entity_class ::=
        entity
      | architecture
      | configuration
      | procedure
      | function
      | package
      | type
      | subtype
      | constant
      | signal
      | variable
      | component
      | label
      | literal
      | units
      | group
      | file
      | property
      | sequence
      | view

entity_name_list ::=
        entity_designator { , entity_designator }
      | others
      | all

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

Edit: Insert the new reserved word 'view' after the reserved word 'variable' in the list:

%TABLE{disableallsort="on" tableframe="void" tablerules ="none" valign="baseline" dataalign="left" columnwidths="20%,20%,20%,20%"}%

LRM Annex C Syntax summary

page 481

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]
        entity
      | architecture
      | configuration
      | procedure
      | function
      | package
      | type
      | subtype
      | constant
      | signal
      | variable
      | component
      | label
      | literal
      | units
      | group
      | file
      | property
      | sequence
      | view

page 489

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

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

page 490

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

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

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

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

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

mode_view_element_definition ::=                                        [§ 6.5.2.1.1]
     composite_element_list [ : composite_element_mode_indication ] ;

mode_view_header ::=                                                    [§ 6.5.2.1.1]
     generic ( constant_generic_list )

mode_view_indication ::=                                                [§ 6.5.2]
     view mode_view_name
          [ constant_generic_map_aspect ]
               [ of unresolved_composite_subtype_indication ]

page 492

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

package_declarative_item ::=                                            [§ 4.7]
     subprogram_declaration
   | subprogram_instantiation_declaration
   | package_declaration
   | package_instantiation_declaration
   | type_declaration
   | subtype_declaration
   | mode_view_declaration
   | 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
   | PSL_Property_Declaration
   | PSL_Sequence_Declaration

LRM Annex I Glossary

page 572

Edit: Insert after the 'mode' item the following:

' 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

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

-- Jim Lewis - 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).

-- Brent Hayhoe - 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.

-- Jim Lewis - 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.

-- Thomas Preusser - 2017-02-23

LRM Annex C BNF production section references corrected.

Grammar rules are still in development, hence draft status.

-- Brent Hayhoe - 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.

-- Jim Lewis - 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?

-- Jim Lewis - 2017-03-02

Version 2

BNFs have been restructured to hopefully avoid parsing ambiguities.

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

@JL 1) The 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 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.

-- Brent Hayhoe - 2017-03-15

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

-- Peter Flake - 2017-03-16

I'm with Peter on the terminology. Would a composite_element_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:

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;

Also, a thing I'm not clear on from all this: if I've got the following:

type T is
  record
   a, b, c : bit;
 end record;

view V of T is
  a, c : in;
end view V;

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

-- Rob Gaddi - 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.

-- Patrick Lehmann - 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.

-- Jim Lewis - 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.

-- Jim Lewis - 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"

-- Jim Lewis - 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:

view V of T is
  a, c : in;
  b;
end view V;

@JL WRT @PL1 & @PL2: "Why is a mode_indication optional ...";
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:
 "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:
 "If no mode is explicitly given ..."

No modifications made.

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

@JL WRT @PL6: "This LCS uses choice ...";
No modifications made.

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

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

Version 3

• Added generic interface to mode views
• Added element choice restrictions
• Restructured new section numbering

-- Brent Hayhoe - 2017-03-21