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 History
Version:	6
Date:	2017-Mar-30
Status:	Voting
Author:	Jim Lewis, Patrick Lehmann, Lieven Lemiengre
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

Voting Results: Cast your votes here

• Yes:
  1. Steve Grout - 2017-03-16 - Version 1
  2. Kevin Jennings - Mar-30-2017 - Ver 5
  3. Patrick Lehmann - 2017-03-30 - ver 6
  4. Lieven Lemiengre - 2017-03-30 - ver 6
  5. Jim Lewis - 2017-03-30 - ver 6
  6. Rob Gaddi - Mar-30-2017 - Ver 6

• No:
  1. Peter Flake - 2017-03-16 - Version 1 - see comment
  2. Brent Hayhoe - 2017-04-02 - Version 6

• Abstain:

Revision History

Revision 6 2017-Mar-30

• fixed Lieven's issues
  • split mode view indications from 2 into 4 EBNF rules
  • adjusted text

Revision 5 2017-Mar-28

• Removed mode views for array types; replaced by view (view_name) syntax
• Described the syntax [ of subtype]
• Removed interface variables with mode views (Lieven + Patrick)
• Added more error conditions
• Split mode view indication into two parts: array + record

Revision 4 2017-Mar-27

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

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

Arrays views are problematic: currently port modes are checked during analysis, with array views we would have to check them at runtime.

I also believe that they are unnecessary.

-- Lieven Lemiengre - 2017-03-23

1. I'm against generics on mode views. Records don't have discriminants (discrete generics). I think this idea is born from a false design pattern on the SPI bus, because the given example was not divided into semantically disjunct busses.
2. The solution of such a design is an entity or map function but not generics. Generics solve only one special use case where address decoding exists as a binary or one-hot select line.
3. unresolved_composite_subtype_indication: I think it needs to be an unresolved composite type mark. The text calls it reserved, which is probably an error.
4. As said before the lexically conformance rule makes no sense. It's a single lexical element.
5. I'm also against different modes of array elements or slices. That again is a false design pattern.

-- Patrick Lehmann - 2017-03-23

What about the green text for subprograms?

-- Patrick Lehmann - 2017-03-28

@PL

I don't think defining views in subprograms or package bodies makes sense right now since you can't initialize them without an instantiation.

-- Lieven Lemiengre - 2017-03-28

a. Why are mode view declarations allowed in entity declarative regions and in block declarative regions? How are they to be used there?

b. What does the "No edits" quote in reference to '4.3 Subprogram bodies' mean?

c. What does the "No edits" quote in reference to '4.8 Package bodies ' mean?

d. In '6.3 Subtype declarations ', the new paragraph defining a resolved/unresolved type/subtype may be a relevant addition to the LRM, but should it be in this LCS?

e. I have noticed some subtle changes to the BNF productions and I think that an 'examples' block is needed.

f. The altered BNF productions seem to preclude the ability to define any form of default 'static expression' for the composite as a whole, or the individual elements, if a mode view is defined for a composite interface object?

g. Similarly, for a composite signal object with a mode view, there is no way to define an element of that object as a guarded signal.

h. An interface may have a generic clause to add constraints to declarations within a template of the interface port/parameter clause. The lack of a generic clause on a mode view declaration limits the generic control to that via a generic package. If there is more than one generic instance of a mode view declaration used in a given design, then more than one instantiation of the generic package will be required and the mode view instances will need to be referenced via package pathnames. I think this is a clumsy enforced design methodology.

-- Brent Hayhoe - 2017-03-28

BH: a)
PL: Block statements with port clauses and port map aspects can be defined locally. It might be no common use case but should be considered.

BH: b) and c)
PL: These are leftovers.

BH: d)
PL: This declaration is needed for this LCS and we are overtime to create new LCS which get approved.

BH: e)
PL: I'm not sure if the topic is so complex to require an example, but we can add one.

BH: f) composite as a whole
PL: There is no solution to describe uninitialized subelements in an aggregate, that needs to be used in such a default expression.

BH: f) For individual subelements
PL: Views are applied to several e.g. slaves and might require individual default expressions per slave. Moreover, non of the old rules allowed a default expression for a nested view mode.

The EBNF can be extended in the next revision if a solution is found.

BH: g)
PL: Are guarded signals still in use? Do we still need to carry n an unused feature in a new feature?

BH: h)
PL: I still haven't seen a good use case of generics on mode views. Moreover, records don't have discriminants... Please paste or email a convincing example where I need such a generic. I couldn't find it between the tons of example code.

However, the EBNF can be extended in a later revision to allow generics.

-- Patrick Lehmann - 2017-03-28

@PeterFlake

Your issue is resolved in revision 5.

-- Lieven Lemiengre - 2017-03-29

Version 5 comments: #1 Old text (struck out): If no mode is explicitly given in an interface declaration other than an interface file declaration, mode in is assumed.

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

For all of the cases covered, mode 'in' is assumed which implies one of the following is true:

- The original text was correct 'as-is'

- The new text does not cover all cases and therefore is incomplete. It appears that if a mode indication is a mode view indication would be one example not covered.

#2[4rd paragraph with edits]: The case of a 'mode_view_indication' with an initializer does not appear to be covered. Should it be an error?

#3[new paragraphs] Text says: For an array mode view indication that occurs ... is the type or subtype of the corresponding record element.

For an array mode view indication, the type is from the corresponding record element?? What if it's a simple array of scalars?

-- Kevin Jennings - 2017-03-29

#1 I think we covered all cases in which a normal mode can appear. A mode view does always cover all subelements with modes. So there is no need for an implicit in.

#2 The default expression only applies to simple mode indication and thus to mode indication, but not to mode view indication.

#3 The mentioned paragraph describes how to infer the optional part after view myView appended with of myBusType.

There are 2 cases:

• a mode view in a port clauses
• a mode view in a mode view declaration

and 2 possible aggregates

• array
• record

The mentioned sentence describes how to derive of myBusType in this scenario:

type SlaveType is record
end record;

view SlaveView of SlaveType is
end view;

type SlaveVector is array(natural range <>) of SlaveType;

type SystemType is record
    Slaves : SlaveVector;
end record;

view myView of SystemType is
    Slaves : view (SlaveView);        -- of SlaveVector
end view;

So the subtype is taken from the corresponding record element for an array mode view indication.

Does it make sense so far?

-- Patrick Lehmann - 2017-03-29

@KJ1: The old text covered constant, signal and variable. It no longer applies since signals now have either a simple_mode_indication or mode_view_indication. A mode_view_indication does not include the mode directly in it. Hence, it needs to be excluded. Hence, the re-write. For constants, the syntax does not refer to mode, but instead only has mode in, hence, referring to it as mode is not formally correct in the first place. Might as well address this since we must do a re-write.

I agree with your statment, "It appears that if a mode indication is a mode view indication would be one example not covered." I should note that this is intended. A mode view indication does not specify a mode in the interface, instead it specifies a mode view. Inside of a mode view there are modes. Whether these are allowed to have a default mode or not is defined by the mode view declaration.

OTOH, since you got me to re-read the text, I noticed a double negative snuck into variables, so thanks for that.

@KJ2: Mode view indications do not have initialization. It is not part of the BNF.

@KJ3: That is as intended. A mode view declaration currently for records. If the record contains an array, then mode view declaration will have an array mode view indication for that array. In this case, the "of subtype_indication" is optional since the subtype information is already part of the record type declaration for which a mode view declaration is being created.

-- Jim Lewis - 2017-03-29

Improved text for #1.

-- Patrick Lehmann - 2017-03-29

@Jim & Patrick,

#1: The text labelled [replacement] does not cover the case "if a mode indication is a mode view indication and a mode is explicitly given". I assume that this should be an error, but in any case, the condition is not covered in the LCS as I previously mentioned. Leaving that undefined is not appropriate is it?

#2 You seem to be missing my point: The case of a 'mode_view_indication' with an initializer does not appear to be covered. Should it be an error? Right now it looks to me to be undefined by the LCS which again would seem to not be correct.

#3: Still confused by what the statement "For an array mode view indication that occurs in a mode view declaration, the type or subtype is the type or subtype of the corresponding record element." means when the array is an array of scalars. For example, if the array is std_ulogic_vector. What would be the "corresponding record element"?

-- Kevin Jennings - 2017-03-30

@KJ1: "if a mode indication is a mode view indication and a mode is explicitly given"

If I look at the ebnf rules I don't see a 'mode' in mode_view_indication

@KJ2: Maybe I don't understand you but:

1) If you follow the EBNF rules it's clear that an interface_signal_declaration with a mode_view_indication doesn't have an initializer. (as pointed out to you by Jim & Patrick)

2) I don't think the specification should cover cases that aren't allowed by the EBNF rules

@KJ3 You can't define a mode_view_declaration for std_ulogic_vector, you can only define a mode_view_declaration for records (see EBNF it requires a unresolved_record_subtype_indication).

-- Lieven Lemiengre - 2017-03-30

So I've implemented a quick & dirty prototype of this proposal and found an issue:

In an mode_view_element_definition we should not allow you to define the subtype since we can always infer it from the record. Currently it allows you to do apply some constraints to a record element if you specify a subtype. The problem is that you now you can have 2 sets of constraints that may be in conflict: the constraint from the interface_signal_declaration & one from the mode_view_element_definition.

-- Lieven Lemiengre - 2017-03-30

@Lieven, Jim, Patrick, #1: I 'think' we all agree that "if a mode indication is a mode view indication and a mode is explicitly given", there is no rule...but that's my point. The paragraph in question covers all but that one situation. So if the user does specify "a mode indication is a mode view indication and a mode is explicitly given", then is that an error? Right now, it appears to me that if the user did that, then the tools are free to do whatever they want. Shouldn't there be another sentence that starts "If a mode indication is a mode view indication and a mode is explicitly given then ...."?

#2: So what happens when the user does specify a mode view indication with an initializer? Is it supposed to be an error? Right now, the behavior of the tool when the user specifies this condition is not defined...at least not where it should be with all of the other conditions.

Lieven: "I don't think the specification should cover cases that aren't allowed by the EBNF rules"

KJ: The specification is littered with sentences that contain "It is an error if..." or "It is erroneous if...". Every such instance is an example of the specification covering cases that aren't allowed by the EBNF rules.

I'm simply going through the conditions that have been specified and making sure that the behavior under all conditions is defined. I'm not trying to suggest what should happen under those conditions, just pointing out when a condition has not been covered and therefore the behavior under those conditions is undefined. Specifying an EBNF rule is no way constrains what the user types into the source code. One point of the specification is for it to define to the tool what should be done when the rules are broken. We've already had at least one LCS this time around that covers similar missing definitions.

-- Kevin Jennings - 2017-03-30

I'll all condition again, but in one point you are not right. The "it is an error if" sentences appear only if the EBNF allows more than the language allows, because the EBNF of VHDL is very sloppy and rules are reused at several distinct places. So at first a tool has to ensure the basic compliance to the EBNF. At second it has to check the named errors or a tool developer decides to generate an expanded EBNF with disjunct rules. In this case the EBNF can directly enforce what the secondary errors describe.

Otherwise the LRM would need 10 times more error conditions.

-- Patrick Lehmann - 2017-03-30

@KJ1: If "a mode indication is a mode view indication and a mode is explicitly given" the compiler will signal an error because the code has keywords that are not part of the BNF. This is similar to having a signal declaration in a process. Nothing needs be said about this in the text because the EBNF does not allow it.

@KJ2: "What happens when the user does specify a mode view indication with an initializer?" Again, this is not part of the EBNF, so the compiler generates an error. Again, no text needed since this is already clear in the EBNF.

@KJ3: " The specification is littered with sentences that contain "It is an error if..." or "It is erroneous if..."." These in particular are required in places where the EBNF is general enough to allows things that are not appropriate for all situations. For example, subprograms allow all modes, but pure functions only allow mode in. The EBNF is written for all interfaces (meaning parameters, ports, and generics) so error conditions have to be spelled out. In this case, the EBNF is clear and no additional error conditions need to be spelled out.

You may find it helpful to look at the examples under the page: http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/InterfaceAndBundleEnhancements

-- Jim Lewis - 2017-03-30

Composite interface objects can be initialized on an element by element basis by using aggregates in the default 'static expression'. Version 3 of this LCS provides a solution to maintaining this option (when a mode view is used on the interface object) by including the default expression within the mode view declaration of each element. This solution enables initialization expressions to be added to elements on a mode by mode basis. It also provides the additional ability to define the element as 'guarded' if it was a signal. The removal of this option has effectively removed functionality from the language.

Both record and array composite objects can be constrained where they are used within a given interface construct. As such they would benefit from having a generic interface.

WRT to generics and Jim's examples: of course we don't 'need' generics. Code can be duplicated and modified for each instance of a particular generic value, but this is precisely the reason for their development in the first place; to allow code to be minimised and simplify complexity; to allow code structure to be easier to comprehend; to simplify maintenance of developed code. IMHO these examples prove why we need generics.

Over the last three years I have provided use cases to show the need for generics on mode views, but these seem to have been labelled as a 'false design pattern'. I object to this as in my opinion they just show an alternative design methodology and as such are equally valid.

I have removed my name from the authors list at the head of this document, because this current rendition now bares little resemblance to version 3.

I'm unable to alter my vote for this LCS and it remains 'against'.

-- Brent Hayhoe - 2017-04-02