Language Change Specification for Protected Type: Shared Variables On Entity Interface

Voting Results: Cast your votes here

Yes:

1. Jim Lewis - 2017-02-19 ver 5
2. Martin Zabel - 2017-02-20 ver 5
3. Torsten Meissner - 2017-02-15 ver 4
4. Patrick Lehmann - 2017-02-19 ver 5

No:

Abstain:

1. Lieven Lemiengre - 2017-02-16 - ver 4
2. Thomas Preusser - 2017-02-15 - ver 4 - vars on ports does still not feel quite right but I will not block advancing
3. Brent Hayhoe - 2017-02-16 Version 4 - Abstain due to lack of personal time for review.
4. Martin Thompson- 2017-02-17 Version 2 - Abstain due to lack of personal time for review.

Revision Notes

• Comprehensive review of LRM for every usage of word port resulted in additional edits.
• add signal port 6.5.2

Revision 4

• variable ports are now explicitly a reference

Revision 3

• Added and updated edits on page 205

Revision 2

• Added Edit: page 88, 3st paragraph of page

Afterword Pre-comments

Lieven is correct in observing that a generic can pass a package and a package can contain objects such as signals and variables. Hence, a package is a container that may contain objects.

Note that generic lists pass instances of generic packages. Currently we have no mechanism to pass regular packages. We have a proposal for abstract packages. The abstract package would define the template (ie: what subprograms the actual package must support to be allowed to be passed) and only the items in the template may be accessed from the actual package.

OTOH, a shared variable is an object that is also a container with other objects in it. Like a signal and regular variable, a shared variable has a type. While protected types and packages have similarity in structure, they are different.

Generic lists pass values (constants) and declarative type things: types, subprograms, and package instances. Generally actual generics are in some sense static, however, packages do blur that line in that they can contain objects.

With subprogram parameters we have another sense of language precedence. Variables (which includes shared variables) and signals are together in a subprogram parameter list, hence, for consistency, signals and shared variables belong together on the port list. For mode the language requires that a variable parameter that is a protected type have the mode inout. Hence, for shared variable ports, the mode should also be inout.

For more clarity, LCS_2016_059 introduces additions to formal generic types. Note though, when you pass a scalar type, you do not know anything about the type other than certain properties. Hence, if you pass an enumerated type, inside the program with the generic clause, you cannot do any reasoning about the values of the enumerated type. In a similar fashion, you cannot pass a protected type as a generic type as you would not know the methods of the type, and without them, you cannot do anything.

Hence, when we pass a shared variable of a protected type, we need to pass both the object and the type of the object. The object is passed by reference. The type of the object is a specific protected type and is made visible by a package reference.

LCS_2016_034 adds a generic clause to protected types. With this, we could, and perhaps in the next revision we will, add formal generic protected types. In this case, what would be passed is an instance of a generic protected type. Since the actual is an instance of the formal, we know all of the protected type method. Note though, what we would be passing is an instance of a protected type and not a shared variable of a protected type.

Comments

I think it makes more sense to pass them via the generic list or maybe we need to add a variable list.

-- Lieven Lemiengre - 2017-01-27

@LL Interface lists on subprograms are used to pass signals and variables. A port list is simply a specialization of an interface list. Generic lists are for objects that are static. While a protected type handle may be static, its contents certainly are not.

-- Jim Lewis - 2017-01-29

@JimLewis

1) Packages are passed through generic lists & they can hold references to mutable state.

2) If we consider a port list a specialization of an interface list there should be a grammar change to make things consistent. If you pass a shared variable through a port list it should be prefixed with 'variable', just like ports can be (optionally) prefixed with 'signal'.

-- Lieven Lemiengre - 2017-01-29

Maybe, I don't see it, but neither clause 14.3.5 nor any other clause in section 14 of the LRM defines how the reference of the shared variable is passed through the model.

-- Martin Zabel - 2017-01-30

Do you look for 4.2.2.2 Constant and variable parameters?
For a subprogram having a parameter whose type is a protected type, the parameter is passed by reference. It is an error if the mode of the parameter is other than inout.

-- Patrick Lehmann - 2017-01-30

@LL.1 Ok, but that is not the same at all. We do not pass just any old package as a generic, we only pass an instance of generic package. Given that LCS_2016_034 adds generics to protected types, at some point, we could pass an instance of a protected type as a generic, but not a shared variable. Note, passing an instance of a generic protected type as formal generic ranked lower than my other LCS' so I did not work on it for this revision.

OK, so packages do have some quirks in that they allow either signal or a shared variable declarations internal to them. Since signals can be internal to a package, you could revise your argument to say, lets forget about generics and ports and pass them all by the same list. And since we are now ordering interface lists, perhaps this is feasible.

Going further, with subprograms we already have a precedent for variables being in the same list as signals. Files are also on the subprogram interface list. They have similar properties to shared variables. If we create pointers to protected types, and perhaps at some point, allow pointers to protected types to be a shared variable, then clearly we will not want them to be a generic parameter.

@LL2 Already required. The additional sentence/paragraph on page 80 says, " If a formal port does not explicitly specify the object class, signal is assumed." Hence, if the keyword variable is not used, it is a signal. Note subprograms have similar, but perhaps more complex defaults as it also uses the mode - in defaults to constant class, out or inout default to variable class.

@MZ and @PL, it must be a reference, just like signals and just like what is stated in 4.2.2.2. Any idea where this goes? It is much different for ports than parameters since entities are persistent and most subprograms have a lifetime. I think it is likely that it goes in the elaboration section. The search is on.

-- Jim Lewis - 2017-01-30

@TODO: Add variables to 14.3.4 Port clause and 14.3.5 Port map aspect. Add: for every formal variable port, there shall be one and only one actual variable port

-- Jim Lewis - 2017-02-02

Posted revision 3 to address all outstanding issues.

-- Jim Lewis - 2017-02-09

WRT, how are shared variables passed through a port? @LL, MZ, and PL: Through statements of Lieven, Martin, and Patrick, there is an implied question as to how a shared variable is "passed" through a port. Is it a reference or something else.

Passing is a term that references how parameters are exchanged by a subprogram. This term is relevant to sequential subprograms since they are dynamically elaborated and often have a limited lifetime. Hence, for subprogram parameters, it is relevant to talk about passing by value or reference.

Ports of an entity do not have a limited lifetime. The design elaborates them at the start of a simulation and they stay live for the entire simulation time. The term used for port objects is "associate". Signal ports are ultimately associated with an object that is either a signal (either explicitly declared or implicitly declared in the case of a signal expression) or a constant value. Per this LCS, variable ports are ultimately associated with a shared variable whose type is a protected type. So for each variable port, somewhere in the design hierarchy is an explicitly declared shared variable. Since these connections last the lifetime of a simulation, the only thing "associate" can mean is some sort of reference.

-- Jim Lewis - 2017-02-09

Version 4 that explicitly makes shared variable ports a reference.

-- Jim Lewis - 2017-02-09

I don't have the time to check so, these are open questions

1) Do the chapters on elaboration need updating with this change? 2) And does this change cover all the places where ports are used: block statements, configurations, ...?

-- Lieven Lemiengre - 2017-02-16