Preface to Shared Variable Language Change Specification:

This is a DRAFT language change specification (LCS) proposing a revision of the VHDL-93 language reference manual (LRM) with respect to shared variables. Please send comments on this draft language change specification (LCS) to:

jwillis@acm.org            [John Willis: Language Designer]
stephen@srbailey.com       [Steve Bailey: WG Chair]
mench@mench.com            [Paul Menchini: LRM Editor]
rouillard@acm.org          [Jacques Rouillard: Technical Committee]
chuck_swart@analogy.com    [Chuck Swart: Technical Committee]
berman@cadence.com         [Victor Berman: Technical Committee]
vijay@webpage.com          [Vijay Vaidyanathan: Technical Committee]
dunlop@cadence.com         [Doug Dunlop: Interested Party]
newshutz@ftlsys.com        [Rob Newshutz: Interested Party]

Before this LCS revises the VHDL LRM, it will be:
1. Reviewed and potentially revised by SV Technical Committee
2. Reviewed and potentially revised by SV Working Group
3. Balloted by SV Working Group

John Willis

9/12/96

Shared Variable Language Change Specification
(PAR 1076A)

Version 5.7

9/12/96


Number:     LCS-1076A
Title:      Shared Variables
Designers:  John Willis with contributions from Steve Bailey & Chuck Swart

Requirements-addressed-herein: VHDL 1076A Requirements Document

Requirements-addressed-herein: VHDL 1076A Requirements Ballot Analysis Document

Requirements-addressed-herein: VHDL92-DG-18

Requirements-addressed-herein: VHDL92-DG-28
History Log:

(1) September 15, 1994      -- Initial Version (willis@vhdl.org)

(2) September 19, 1994      -- Incorporated Paul Menchini's comments

(3) November 7, 1994        -- Responded to Paul Menchini, Chuck Swart
                            -- Peter Ashenden, Doug Dunlop, Jayaram Bhasker

(4) November 9, 1994        -- Joseph Skudlarek found three errors in V 2.0

(5) November 9, 1994        -- Bill Paulsen found seven errors in V 2.0

(6) November 9, 1994        -- Added section numbering

(7) April 2, 1995           -- Incorporated response to reviews of LCS Version 2.* from ISAC

(8) June 2, 1995            -- Incorporated responses from review in San Diego

(9) June 10, 1995           -- Incorporated Chuck Swart's comments and example

(10) October 10, 1995       -- Incorporated Doug Dunlop and Paul Menchini's comments

(11) November 2, 1995       -- Incorporated comments from review in Boston

(12) February 18, 1996      -- Revised per Steve Bailey and Peter Ashenden's comments

(13) May 31, 1996           -- Revised per Steve Bailey and Chuck Swart's comment

(14) September 12, 1996     -- Revised to eliminate protected types with
                            -- wait and composite types with subelements 
                            -- of protected type per Chuck Swart's
                            -- extensive analysis of this LCS.

This LCS adds three different forms of non-normative annotation to the LCS normative text: notes, ramifications and rationale. Note annotations assist the reader to better understand the points made by normative text. Ramification annotations explain implications of the normative text which are not likely to be apparent to the casual reader. Rationale annotations explain the reasons behind a particular language design decision. In this LCS, rationale annotations distributed throughout the LCS replace an explicit rationale section typically found in an Ada or VHDL LCS. Although the LCS is generally structured along the lines of the VHDL LRM, integration and editing into the LRM will be completed after SVWG approval of the LCS. This LCS is formatted for a 38 page printout where the last page is so identified.

Table of Contents

1.0 Brief Overview of the Problem

        1.1 VHDL-93 SV Requirements

        1.2 SV Working Group Requirements 
2.0 Proposed Solution

        2.1 General Monitor Approach

        2.2 Overview of LCS's Monitor Design

        2.3 Declaring Protected Types

                2.3.1 Protected Type Specification:

                        2.3.1.1 Procedure Specifications

                        2.3.1.2 Function Specifications

                        2.3.1.3 Attribute Specifications

                        2.3.1.3 Attribute Declarations

                2.3.2 Protected Type Body:

                        2.3.2.1 Subprogram Declarations

                        2.3.2.2 Subprogram Bodies

                        2.3.2.3 Type Declarations

                        2.3.2.4 Subtype Declarations

                        2.3.2.5 Constant Declarations

                        2.3.2.6 Variable Declarations

                        2.3.2.7 File Declarations

                        2.3.2.8 Alias Declarations

                        2.3.2.9 Use Clauses

                        2.3.2.10 Attribute Specifications

                        2.3.2.11 Attribute Declarations

                        2.3.2.12 Group Template Declarations

                        2.3.2.13 Group Declarations

        2.4 Use of Protected Type Declarations:

                2.4.1 Use within a Subtype Indication

                        2.4.1.1 New Subtypes of a Protected Type

                        2.4.1.2 Objects of Protected Type

                2.4.2 Attributes Related to Protected Types

                2.4.3 Use of (Protected) Type Marks

                2.4.4 Semantically Prohibited Uses

        2.5 Use of Protected Objects: 

                2.5.1 In Expressions

                2.5.2 In Sequential Statements

                2.5.3 In Concurrent Statements

        2.6 Scope and Visibility Rules:

                2.6.1 Declarative Regions

                2.6.2 Scope of Declarations

                2.6.3 Visibility

                2.6.4 Use Clauses

        2.7 Elaboration and Execution:

                2.7.1 Elaboration of Protected Type Declarations

                2.7.2 Elaboration of Protected Type Bodies

                2.7.3 (Static) Elaboration of Protected Type Variables

                2.7.4 (Dynamic) Elaboration of Protected Type Objects in a Subprogram

                2.7.5 (Dynamic) Elaboration of Interface Objects of Protected Type in a

                        Non-protected Type Subprogram

                2.7.6 (Dynamic) Elaboration of Protected-Type Subprograms

                2.7.7 Read and Write of Shared Variables

        2.8 Lexical Elements:

                2.8.1 Reserved Word(s)
        3.0 Optional Extensions

                3.1 Overloaded Assignment

                3.2 Constructors

                3.3 Destructors

                3.4 Process ID
        4.0 Examples

                4.1 Atomic Counter

                4.2 Complex Number

                4.3 Variable Size Array

                4.4 Mutual Exclusion Semaphore
        5.0 Upward Compatibility
        6.0 Other Alternatives Considered

                6.1 Semaphores

                6.2 Critical Regions

                6.3 Monitors

1.0 Brief Overview of the Problem

This section enumerates some of the requirements for shared variables coming from both the VHDL 1076-93 language revision process and the subsequent Shared Variable Working Group (SVWG) requirements process. Both of these processes have distinct documentation. The interested reader should consult those documents for more detail. Requirements coming from the later (SVWG) process were more focused and had the benefit of being prioritized by a balloting process. Thus where the requirements are in conflict, this LCS responds to prioritization determined by the SVWG requirements process.

1.1 VHDL-93 SV Requirements

The original requirements included:

• A need to share data between processes without the need for explicit modeling of the access discipline for the shared data. Essentially, shared variables are a modeling convenience in which the shared variables are not part of the physical hardware (such as modeling statistics and gathering trace data).
• A need to efficiently communicate dynamically sized data between processes, using data structures such as queues and stacks. Note: VHDL signals cannot have an access type and unconstrained ports become fixed in size at elaboration time, thus signals are not a practical "container" for variable size values.
• A need to translate from other languages, such as Verilog and C, which have global variables.
• A need to model stochastic processes. For example, stochastic processes are often useful when simulating the environment that the hardware is to operate in (such as pseudo-random number generators and queuing models).

1.2 SVWG Requirements

The shared variable working group (SVWG) developed and balloted a requirements document, resulting in a prioritized ranking of design objectives that should and should not be met. The following list summarizes the requirements that the implementation of shared variables should satisfy:

• Maintain compatibility with the VHDL type model, block model and visibility rules.
• Permit shared variable declarations within packages, entities, architectures and blocks.
• Make the characteristic of "shared" manifest in the declaration of the shared variable. Note: The shared reserved word is not actually needed by language design since shared variables can only be declared in a "concurrent" declarative context.
• Provide algorithmic non-determinism. VHDL `87, with a very few exceptions, is a strictly deterministic language. The `93 implementation of shared variables makes VHDL an entirely non-algorithmic language (when shared variables are used). Note: If shared variables provide algorithmic non-determinacy, then it would be possible for different simulation runs (possibly on different simulators or platforms) to get different results, but each set of results should be correct given the design's algorithm.
• Support for dynamically sized data that is shared between processes was re-affirmed following requirement from the initial 1076-92 requirements process. This permits structures such as queues, stacks and trees that can grow and shrink as required during the execution of the VHDL model.
• Although much discussion has taken place as to whether the working group's efforts should define a replacement for 1076-1993's shared variables or complement them, the working group voted to maintain the original charter: to replace the VHDL-93 definition of shared variables.
• The shared variable definition should not arbitrarily restrict the inherent parallelism of VHDL.

Since the working group voted on the priorities of requirements by specifying a value in the range of -3 to +3, it was possible for a requirement to be voted as being dangerous or undesired. The language design team was instructed to avoid satisfying requirements that received a consensus negative priority vote. The requirements in this category include:

• Provide access-typed shared variables. Although dynamically sized shared variables are desired, the working group realized that this requirement could be met without allowing multiple processes to maintain local pointers to shared data.
• Require strict determinism or allow unbounded non-determinism.
• Place arbitrary read/write semantic restrictions on shared variables within a delta cycle (one write, infinite reads as long as reads occur first; no reads if any writes, etc.).
• Remove shared variables from the language.

The next section describes the proposed language design responding to these requirements.

2.0 Proposed-solution

This section first discusses the general approach using monitors and its overall benefits for meeting the requirements. Details of the proposed language design follow.

2.1 General Monitor Approach

In general terms, a monitor is a computer language construct which denotes some form of mutual exclusion with respect to one or more mutable data objects, typically variables. In Hoare's words, "The basic insight is that all meaningful operations on data (including its initialization and also perhaps its finalization) should be collected together with the declaration of the structure and type of the data itself; and these operations should be invoked by procedure calls whenever required by the processes which share the data. The important characteristic of a monitor is that only one of the procedure bodies can be active at a time; even when two processes call a procedure simultaneously (either the same procedure or two different ones), one of the calls is delayed until the other is completed." (C.A.R. Hoare, Communicating Sequential Processes, published by Prentice-Hall in 1985). At about the same time, Per Brinch Hansen reached the same insight. Monitors were chosen as the basis for the implementation of shared variable mutual exclusion semantics based on the outcome of the VHDL-93 and SVWG requirements phase (see Section 1.0 above). Parenthetical references below refer to the Shared Variable Working Group Requirements Ballot Analysis Document:

• Monitors fit nicely with VHDL's current visibility rules (R2.1.5.1), block model (R2.1.2) and typing system (R2.1.1).
• Monitors group shared data with the operations on that data (R2.1.5.1).
• Monitors provide algorithmic non-determinism by associating legal operations with shared resources and by providing an implicit lock and release mutual exclusion semantics based on entry to and exit from the monitor operations (R2.1.3, R2.1.6 and others).
• It is impossible to modify shared data outside of the monitor operations. Because of their superior ability to encapsulate the shared data, monitors support dynamically-sized data internal to a single monitor. The access-typed variables essential to provide dynamically-sized data with VHDL are completely encapsulated within the monitor and can only be accessed by the (protected) monitor operations. The access values cannot be transferred to local processes through the monitor subprogram interfaces. Implicit mutual exclusion semantics ensures the integrity of access values within the monitor.
• Monitors do not arbitrarily restrict the inherent parallelism in the language or of designs modeled in VHDL (R2.1.3). Sequential execution is limited only to the scope of the execution of a monitor operation. Monitor operations are defined by the user (R2.4.3.1.3). Therefore, the user has complete control of the critical region. Monitors do not require strict determinism (R2.4.1). The language implementation can leave the order of process access to shared resources via the monitor undefined. It only needs to guarantee that one and only one process gains access (if the access can change the state of the shared resource) to the shared resource at the same time.

2.2 Overview of LCS's Monitor Design

In this LCS, monitors are added to VHDL via a new, protected type. To use monitors, a protected type must be defined, then instances of shared variables, non-shared variables and interface variable declarations are created using the protected type. Finally, the shared variable value may be accessed via protected calls to specific shared variable objects. Within a call prefixed by a variable of protected type, the privileged callee may then directly reference data elements belonging to the variable's implementation part (body). A process gains and releases exclusive access to one or more shared variables in a user-defined order (one per protected subprogram call), potentially blocking if exclusive access to the protected object is already held by another process. Acquiring and releasing exclusive access to a shared variable is a side effect of calls defined as part of the protected type interface, not an explicit lock and unlock operation. The protected types defined in this LCS resemble Ada 95's protected type constructs in many ways, however protected types in the two languages are not identical. The protected type construct defined here is substantially simpler than Ada's construct. Additional functionality, such as that provided by Ada, could be added at a later time. This section is structured so as to define protected types (see Section "Protected Type Definition" on page 8), the declaration of objects of protected type (see Section "Use of Protected Types" on page 17), the use of objects based on protected types (see Section "Using Protected Objects" on page 21), scope and visibility (see Section "Scope and Visibility Rules" on page 22), elaboration and execution (see Section "Elaboration and Execution" on page 24), and new lexical elements (see Section "Lexical Elements" on page 26).

2.3 Declaring Protected Types

Protected type specification and bodies may only appear as part of a type declaration:

        type identifier is type_definition;

VHDL's type_definition is expanded to include both protected type specifications and bodies:

        type_definition::=
                  scalar_type_definition
                | composite_type_definition
                | access_type_definition
                | file_type_definition
                | protected_type_specification

LRM Change:
Protected type definitions must be added to the grammatical production and text in Section 4.1 of IEEE Std. 1076-93.

In turn, protected type definitions include both specifications and bodies:

        protected_type_specification ::=
                    protected_type_declaration
                |   protected_type_definition

LRM Change:
Section 3.5 must be added to Section 3 of IEEE Std. 1076-93. It is suggested that an introductory section describing protected types be followed by sub-sections 3.5.1 and 3.5.2 describing protected type declarations and protected type definitions (respectively).

Protected type declarations may occur anywhere a subprogram declaration may occur, including:

• entity declarations,
• architecture bodies,
• subprogram bodies,
• package declarations,
• package bodies,
• block statements,
• process statements, and
• generate statements.

LRM Change:
Sections 1.1.2 (entity declarative part), 1.2.1 (architecture declarative part), 2.2 (subprogram bodies), 2.5 (package declarations), 2.6 (package bodies), 9.1 (block statements), 9.2 (process statements) and 9.7 (generate statements) of IEEE Std. 1076-93 will need additional grammar productions for protected type declarations.

Protected type definitions may occur anywhere a subprogram body may occur, including:

• entity declarations,
• architecture bodies,
• subprogram bodies,
• package bodies,
• block statements,
• process statements, and
• generate statements.

Rationale:

Since protected types generally include subprogram bodies, it seems appropriate to restrict protected type definitions to places where a subprogram body may otherwise appear.

Rationale:

Protected type specifications are included in "non-concurrent" regions, such as process statements and subprogram bodies so that non-shared variables may be declared locally using a protected type (consistency at little or no cost).

LRM Change:
Sections 1.2.2 (entity declarative parts), 1.2.1 (architecture declarative part), 2.2 (subprogram bodies), 2.6 (package bodies), 9.1 (block statements), 9.2 (process statements) and 9.7 (generate statements) of IEEE Std. 1076-93 will need additional grammar productions for protected type specifications.

Note:
Protected type declarations and protected type definitions are respectively analogous to package declarations and package bodies in that both a protected type declaration and a package declaration defines an abstract interface while protected type definitions and package bodies define an implementation part.

Note:
Protected type declarations and protected type definitions respectively differ from package declarations and package bodies in that elaboration may result in multiple instances of a protected type (if the protected type is declared in an entity, architecture or for-generate block) and multiple objects of a given protected type (one per object declaration). Elaboration of a package results in only a single instance. As primary and secondary units within a library, packages have a wider visibility than protected types. Protected types must be declared within an existing primary or secondary unit.

Each protected type declaration must be associated with exactly one protected type definition before objects can be created using the protected type. The declaration must precede the definition within the same declarative region. It shall be an error if, during elaboration of a variable declaration using a protected type, no protected type definition is found. It shall be an error if a protected type definition is already associated with a protected type declaration and another protected type definition is encountered for the same declaration. Note that a protected type declaration appearing in an entity declaration may have more than one protected type definition, each declared in a distinct architecture. The entity/architecture binding encountered during elaboration determines the declarative region formed and thus association used between protected type declaration and definition.

LRM Change:
The intent of the above paragraph should be included in Section 3.5 of IEEE Std. 1076-93. It is an error if a wait statement appears within a function or procedure which has as its (dynamic) parent a subprogram appearing within a monitor interface.

LRM Change:
The intent of the above paragraph should be included in the introductory part of Section 3.5 of IEEE Std. 1076-93. Since VHDL does not make the stack explicit, other words are probably needed for "dynamic" above.

Rationale:
If waits were allowed within a monitor there are numerous undesirable "corner cases". These corner cases must either be addressed by a variety of special case rules or waits must be forbidden. This LCS takes the latter, more conservative approach, leading the future option for flexibility.

No predefined operators or assignment is defined for protected types.

LRM Change:
The intent of the above paragraph should be included somewhere in Section 7 and Section 8.5 of IEEE Std. 1076-93

2.3.1 Protected Type Declaration

Declaration of a protected type requires a protected type declaration having the syntactic form:

        protected_type_declaration ::=
                protected
                        protected_type_declarative_part
                end protected [protected_type_simple_name]

The protected type declaration may only contain subprogram specifications defining abstract operations on objects of the protected type, use clauses or attribute specifications:

        protected_type_declarative_part ::=
                { protected_type_declarative_item }
        protected_type_declarative_item ::=
                    subprogram_specification
                |   use_clause
                |   attribute_specification
                

LRM Change:
The above grammar productions, syntactic and semantic restrictions should be included in the Section 3.5.1 and may need to be incorporated in Section 8.1 of IEEE Std. 1076-93.

2.3.1.1 Protected Type Declaration: Procedure Specification

Each procedure specified within a protected type declaration defines an abstract operation which operates atomically on a single object of the associated protected type. In addition to the (implied) object of protected type being operated on, additional parameters may be specified by the procedure specification interface declarations, as with any other procedure specification. These interface declarations may have any type which is not of and does not contain access or file type(s). Procedures declared in the protected type specification may not have formals of or including access or file type.

LRM Change:
The above syntactic and semantic restrictions should be included in the Section 3.5.1 (Protected Type Specifications) and may need to be incorporated in Section 2.1 (Subprogram declarations) of IEEE Std. 1076-93.

Rationale:
If the interface objects were to have one or more parameters containing an access value, the same dynamically allocated object might become accessible from two or more processes via distinct mutual exclusion mechanisms, thus subverting the implied atomicity of a protected type (monitor).

The interface declarations of a protected type declaration subprogram may include interface declarations of protected type. Although exclusive access is not obtained for interface declarations of protected type directly, the ability to pass objects of protected type, by reference, is essential to implement generalized n-ary (n > 1) operations. VHDL calling semantics allow passing actuals of composite type by either copy or reference (scalars must be passed by value); actuals of protected type must be passed by reference.

LRM Change:
The above semantic restrictions should be included in the Section 2.1.1.1 (Constant and Variable Parameters) of IEEE Std. 1076-93.

2.3.1.2 Protected Type Declaration: Function Specification

Each function specified within a protected type declaration defines an abstract operation which operates atomically on a single object of the associated protected type and returns a value.

NOTE:
Since values cannot be created of protected type (only objects) a function cannot return a protected type.

In addition to the object of protected type to which protected type subprograms have direct visibility (prefix of selection), additional parameters may be specified by the function specification interface declarations, as with any other function specification. These interface declarations may have any type which is not of and does not contain access or file type(s). Functions declared in the protected type interface may not have formals of access or file type.

LRM Change:
The above syntactic and semantic restrictions should be included in the Section 3.5.1 (Protected Type Specifications) and may need to be incorporated in Section 2.1 (Subprogram declarations) of IEEE Std. 1076-93.

Rationale:
If the interface declarations were to have one or more parameters containing an access value, the same dynamically allocated object might become accessible from two or more processes via distinct mutual exclusion mechanisms, thus subverting the implied atomicity of a protected type.

The interface declarations of a protected type specification subprogram may include interface declarations of protected type. Although exclusive access is not obtained for interface declarations of protected type directly, the ability to pass objects of protected type, by reference, is essential to implement generalized n-ary (n > 1) operations. VHDL calling semantics allow passing actuals of composite type by either copy or reference (scalars must be passed by value); actuals of protected type must be passed by reference.

LRM Change:
The above semantic restrictions should be included in the Section 2.1.1.1 (Constant and Variable Parameters) of IEEE Std. 1076-93.

No copy (assignment) operation is predefined at all for protected types.

Note:
Addition of the ability to overload assignment (beyond the scope of this PAR) would provide for user-defined deep copy (See LCS Section 3.1) semantics. Rather than provide an irregular form of predefined shallow copy, no copy (assignment) operation is predefined at all for protected types.

LRM Change:
The above semantic restrictions should be included as a note in Section 3.5 (Protected Types) of IEEE Std. 1076-93.

2.3.1.3 Protected Type Declaration: Attribute Specification

Attribute specifications may appear in the protected type declarations. For further information on attribute specifications, see IEEE Std. 1076-93 Section 5.1.

2.3.1.4 Protected Type Declaration: Use Clause

Use clauses may appear in protected type declarations in order to make declarations directly visible which would otherwise be visible only by selection. For further information on use clauses, see IEEE Std. 1076-93 Section 10.4, which need not change.

2.3.2 Protected Type Definition

Exactly one protected type definition must be associated with each protected type declaration in order to define how the protected type is to be implemented. Protected type definitions have the syntactic form:

        protected_type_definition ::=
                protected body
                        protected_type_definition_declarative_part
                end protected body[protected_type_simple_name]

LRM Change:
The above syntactic and semantic restrictions should be included in the Section 3.5.2 (Protected Type Body).

The protected type definition may contain declarative items in any order provided that declaration precedes use (as elsewhere in VHDL, consistent with existing visibility rules):

        protected_type_definition_declarative_part ::=
                { protected_type_body_declarative_item }
                
        protected_type_definition_declarative_item ::=
                     subprogram_declaration
                |    subprogram_body
                |    type_declaration
                |    subtype_declaration
                |    constant_declaration
                |    variable_declaration
                |    file_declaration
                |    alias_declaration
                |    use_clause
                |    attribute_declaration
                |    attribute_specification
                |    group_template_declaration
                |    group_declaration

The declarations which can appear in a protected type definition are identical to those which can appear in a subprogram body. The following subsections discuss each of the protected body declaration items in more detail.

2.3.2.1 Protected Type Definition: Subprogram Declaration

Each subprogram specification which appeared in the protected type specification shall have a corresponding subprogram body in the protected type body. This body defines the subprogram's implementation. It is an error if a subprogram specification declared in the protected type declaration does not have a conforming subprogram body by the end of the protected type definition's declarative region.

Subprogram specifications first appearing in the protected body are only visible to other (subsequent) subprogram bodies appearing in the same protected type. The parameters and, for functions, return type, of subprograms first specified in the protected type body may involve parameters of or containing access types (unlike subprograms specified in the protected type specification).

LRM Change:
The above syntactic and semantic restrictions should be included in the Section 3.5.2 (Protected Type Body) or Section 2.1 (Subprograms).

Note:
Subprograms first declared in the protected type body may facilitate implementation of the protected type. For example, such a "private" function might provide for locating the last dynamically allocated record within a list of dynamically allocated records maintained within a variable of the protected type.

2.3.2.2 Protected Type Definition: Subprogram Bodies

Side-effects from within pure functions, impure functions and procedures remain consistent with VHDL-93. Specifically, pure functions defined in the protected type body may not reference variable declarations that belong to the protected type object to which the function is applied. Impure functions and procedures defined in the protected type body may both read and update variable declarations that belong to the protected-type object to which such subprograms are applied, while exclusive access is granted.

LRM Change:
The above should be summarized in a note associated with the explanation of pure and impure functions in Section 2.1 of IEEE Std 1076-93.

The rules for wait statements contained in subprograms are consistent with VHDL-93, although slightly more restrictive. From the VHDL-93 LRM, Section 8.1: It is an error if a wait statement appears in a function subprogram or in a procedure that has a parent that is a function subprogram. Furthermore, it is an error if a wait statement appears in an explicit process statement that includes a sensitivity list or in a procedure that has a parent that is such a process statement. Further more, a wait statement may not occur within or be reachable from any subprogram declared in a protected type.

LRM Change:
The above semantic restriction (on wait statements) should be added to Section 8.1 of IEEE Std. 1076-93.

Rationale:
If wait statements were to appear in any subprogram bodies appearing within the protected type body then any call of a protected subprogram which blocks may not resume until some subsequent simulation cycle (if at all). Thus one wait statement, even if not directly called from a given process, may suspend execution of other processes referencing the same shared variable.

2.3.2.3 Protected Type Definition: Type Declarations

Type declarations may be declared (and used) within the protected type definition. Such declarations are described in IEEE Std. 1076-93 Section 4.1 and need not be changed.

2.3.2.4 Protected Type Definition: Subtype Declarations

Subtype declarations may be declared (and used) within the protected type definition. Such declarations are described in IEEE Std. 1076-93 Section 4.2 and need not be changed.

Note:
Since subtype declarations are only visible inside a protected type body and signals cannot be declared inside a protected type body, specification of a resolution function within a subtype indication has no significance in the resulting model.

2.3.2.5 Protected Type Definition: Constant Declarations

Constant declarations may be declared (and used) within the protected type definition. Such declarations are described in IEEE Std. 1076-93 Section 4.3.1.1 and need not change. The value of all constant declarations must be given in the initial declaration; deferred constant declarations may not appear in a protected type definition.

LRM Change:
The above semantic restrictions should be included in the Section 4.3.1.1 (Constant Declarations).

2.3.2.6 Protected Type Definition: Variable Declarations

Variable declarations appearing in the protected type body define the encapsulated data representation of a protected type:

        variable_declaration ::= identifier_list : subtype_indication [:= expression] ;

Subtype indications shall not denote the protected type being defined but may denote other, previously defined protected types.

LRM Change:
The above syntax and semantic restrictions should be included in the Section 3.5.2 (Protected Type Body).

Ramification:
Within a protected type, the subtype_indications may denote previously defined scalars, arrays, records, access types, files types and even other protected types.

Each object (instance) of a protected type has distinct storage associated with each variable declaration defined within the protected type.

The variable declaration identifiers are only visible, directly, within the protected type body (including any declarative regions completely enclosed within the protected type body declarative region; see "Scope and Visibility Rules" on page 22).

LRM Change:
The above semantic restrictions should be included in the Section 3.5.2 (Protected Type Body).

Ramification:
Implementation of objects having a protected type may contain several implicit variables denoting the process to which the object has granted exclusive access (if any) and a queue denoting processes (if any) blocked waiting for exclusive access to the object of protected type. Such implicit queues are not to be defined within the normative text and are only used in this LCS to facilitate understanding of possible implementation approaches.

2.3.2.7 Protected Type Definition: File Declarations

File declarations may appear in protected type bodies. For further information on file declarations, see IEEE Std. 1076-93 Section 4.3.1.4 this section need not change.

2.3.2.8 Protected Type Definition: Alias Declarations

Alias declarations, both object and non-object, may appear in protected type bodies. For further information on alias declarations, see IEEE Std. 1076-93 Section 4.3.3, which need not change.

2.3.2.9 Protected Type Definition: Use Clauses

Use clauses may appear in protected type bodies in order to make declarations directly visible which would otherwise be visible by selection. For further information on use clauses, see IEEE Std. 1076-93 Section 10.4, which need not change.

2.3.2.10 Protected Type Definition: Attribute Specification

Attribute specifications may appear in the protected type body. For further information on attribute specifications, see IEEE Std. 1076-93 Section 5.1, which need not change.

2.3.2.11 Protected Type Definition: Attribute Declaration

Attribute declarations may appear in the protected type body. For further information on attribute declarations, see IEEE Std. 1076-93 Section 4.4, which need not change.

2.3.2.12 Protected Type Definition: Group Template Declarations

> Group template declarations may appear in protected type bodies. For further information on group template declarations, see IEEE Std. 1076-93 Section 4.6, which need not change.

2.3.2.13 Protected Type Definition: Group Declarations

Group declarations may appear in protected type bodies. For further information on group declarations, see IEEE Std. 1076-93 Section 4.7, which need not change.

2.4 Use of Protected Types

A name denoting a protected type declaration may appear in several contexts. Subtype indications based (directly or indirectly) on a protected type may be used to derive new types, subtypes or objects. Within an attribute specification, attribute values may be statically assigned to a protected type. A protected type may appear as the prefix of a user-defined attribute name. Use clauses may bring a protected type declaration into direct visibility. This section considers the properties, ramifications and limitations of each such use.

An incomplete type may be completed as a protected type.

LRM Change:
The above semantic restrictions should be incorporated in Section 3.3.1 of IEEE Std. 1076-93.

2.4.1 Use Within a Subtype Indication

Subtype indications generally permit association of a resolution functions and/or subtype constraints with a type mark. In general, subtype indications are derived directly from a protected type without either a resolution function (meaningless) or a subtype constraint (prohibited).

Association of resolution function with a protected type is permitted but lacks utility. Since signals may not be declared with a protected type, a resolution function has no meaning. In keeping with VHDL's philosophy of permitting resolution functions even in situations when the function is ignored (e.g. a variable), resolution functions may be syntactically applied to a protected type but are ignored.

Constraints may not be applied directly to a protected type, preserving the protected type's encapsulation. However since an array may consist of elements having protected type, constraints may be applied to type_marks indirectly containing a protected type.

LRM Change:
The above semantic restrictions should be incorporated in Section 4.2 of IEEE Std. 1076-93.

The resulting subtype indication may be used to declare a new subtype or an object. This subsection will consider each use in turn.

Protected types may not be used in the definition of other composite types.

Rationale:
Subelements of protected type lead to many corner cases which are not readily defined. For example, equality and inequality are predefined for all composite types. Either definition of these relational operators would be needed for protected types or some composites would exist with undefined relational operators. As a compromise, it seems feasible to consider composites in which all subelements are either protected types or all subelements are non-protected types.

2.4.1.1 New Subtypes of Protected Type

Subtypes may be declared in which there is an optional resolution function, a type_mark denoting a protected type and no constraint. Such subtypes are functionally aliases of the original protected type.

2.4.1.2 Objects of Protected Type

Variables, shared variables and interface variable may be declared which directly or indirectly use a protected type.

The VHDL 1076-93 keyword shared must preface all shared variable (and only shared variable) declarations following the VHDL-93 syntax:

        variable_declaration ::=
                [shared] variable identifier_list : subtype_indication;

Rationale:
Explicit use of the keyword for all shared variables satisfies documentation requirements and internal consistency checking requirements.

All shared variables must have a subtype indication which directly denotes a protected type.

LRM Change:
The above semantic restriction must be added to Section 4.3.1.3 of IEEE Std. 1076-93.

Ramification:
Note that the ability to initialize a specific object of protected type is not provided since assignment of protected types is not defined. In the absence of an initializer, VHDL-93 already defines default initialization rules for variable and constant declarations appearing in a protected type body.

LRM Change:
This semantic restriction should be explicit in Section 4.3.1.3 of IEEE Std. 1076-93.

Non-shared variables may be of protected type. The process containing each such variable is given exclusive read/write access to the variable when the variable is elaborated. Such access is never rescinded.

LRM Changes:
The above semantic restrictions on interface declarations impact Section 4.3.1 (Object Declarations).

Ramification:
Non-shared variables of protected type may ignore locking and unlocking implied by the protected type, analogous to the way in which variables ignore resolution functions contained in the defining subtype indication.

Ramification:
Non-shared variables of a protected type may not be initialized as part of the variable's declaration.

Interface variables may be declared which directly or indirectly use a protected type (no shared reserved word is used). Such interface objects are passed by reference, assuming the same properties as the variable object that was passed. All such interface objects must have mode inout; any other mode is an error (detected at analysis time).

LRM Changes:
The above semantic restrictions on interface declarations impact Section 2.1.1.1 (Constant and Variable Parameters), and Section 4.3.2 (Interface Declarations).

2.4.2 Attributes Related To Protected Types

Attribute values may be assigned to both protected types and objects of protected type. The base type of a protected type is always itself.

2.4.3 Semantically Prohibited Uses

A type_mark directly or indirectly denoting a protected type is semantically prohibited in several syntactically valid contexts. These semantic restrictions are an intuitive extension of VHDL's existing semantic limitations.

A file_type_definition may not depend on a type mark which is of or contains a protected type. Instances of file types inherently extend outside of the semantic environment defined by VHDL. This extra-language visibility makes it difficult to assign meaningful semantics to file_types derived from other file types or access types, resulting in IEEE Std. 1076-93 disallowing such file types. In a like manner, extra-language visibility of file types makes it difficult to preserve the encapsulation of protected type instances, hence file types are semantically prohibited.

An access_type_definition may not be defined using a subtype indication which is a protected type.

Rationale:
If an access_type_definition were allowed to depend on a protected type, objects of protected type would need to be dynamically allocated and generally could only be disambiguated at runtime. Such capabilities would both complicate implementation of such objects and generally reduce the performance of language implementations. This restriction is analogous to VHDL's current prohibitions against signals depending on access types.

LRM Change:
These semantic restrictions must be incorporated in Sections 3.3 (Access Types) and 3.4 (File Types) of IEEE Std. 1076-93.

Constants, interface constants (including generic constants) and user-defined attributes may not be of protected type (directly or indirectly).

LRM Change:
These semantic restrictions must be incorporated in Sections 4.3.1.1 (Constant Declarations), 4.3.2 (Interface Declarations) and 4.4 (Attribute Declarations) of IEEE Std. 1076-93.

Signals, signal parameters and ports may not be of protected types (directly or indirectly).

LRM Change:
These semantic restrictions must be incorporated in Section 4.3.1.2 (Signal Declarations) and Section 4.3.2 (Interface Declarations) of IEEE Std. 1076-93.

Since protected types are not scalar types, an index_subtype_definition may not depend on a protected type. Likewise predefined attributes T'LEFT, T'RIGHT, T'HIGH, T'LOW, T'ASCENDING, T'IMAGE, T'VALUE, T'POS, T'VAL, T'SUCC, T'PRED, T'LEFTOF and T'RIGHTOF are prohibited. Ramification:
Protected types may not appear directly or within the definition of an access type.

Ramification:
Protected types may not appear directly or within the definition of a file type.

Ramification:
Protected types may not appear directly or within the definition of a subtype indication used in an allocator expression. Thus objects of protected type may not be dynamically allocated. Objects of protected type may be dynamically elaborated within the declarative region of a subprogram call, however they are not dynamically allocated.

2.5 Using Protected Objects

Protected objects may generally be referenced in expressions, sequential statements and concurrent statements. This section describes all three uses.

Subprograms defined within a protected type specification operate on objects of protected type via selection. The prefix denotes the object of protected type. The suffix denotes the subprogram call, including any actual parameters passed as part of the call. Syntactically such calls have the form:

        protected_object_subprogram_name [ (actual_parameter_part)]

For example, a shared variable called counting_semaphore may be incremented (using a procedure defined within the protected type of counting_semaphore) by the variable n:

   counting_semaphore.increment ( n );

2.5.1 In Expressions

Objects of protected type may be referenced using a function call applied to an object of protected type, returning a value. The value returned may not have protected, access or file type.

Expressions referencing a shared variable may not be evaluated during elaboration of the design hierarchy.

2.5.2 In Sequential Statements

Objects of protected type may appear in sequential statements as:

• To the left of the `.' followed by a protected type function call
• Actuals of a call where the formal is a variable of the same protected type (no subelement association is permitted within the object of protected type). 2.5.3 In Concurrent Statements

Objects of protected type may appear in concurrent statements as:

• To the left of the `.' followed by a protected type procedure call.
• Actuals of a concurrent procedure call where the formal is a variable of the same protected type (no subelement association is permitted within the object of protected type).

Ramification:
Since assignment of values having protected type is undefined and signal assignment is predefined by the language, signal objects cannot take a protected type as their subtype indication.

Ramification:
A call to a protected type subprogram may block on entry to the protected object at time T and resume at some later time, either in the same simulation cycle, or in a different simulation cycle.

A shared variable passed as an actual in a concurrent procedure call has no effect on the static sensitivity list for that concurrent procedure.

2.6 Scope and Visibility Rules

This section discusses the declarative region formed by a protected type, the scope of a protected type, visibility related to protected types and operation of use clauses in conjunction with protected types.

2.6.1 Declarative Regions

A protected type specification, together with its protected body, forms a single declarative region. These two disjoint parts are analogous to the treatment of the single declarative region formed by a package declaration and its corresponding package body.

LRM Change:
This requires addition of another bullet point to Section 10.1.

2.6.2 Scope of Declarations

Declarations appearing in the protected type declaration are directly visible from the point of declaration in the protected type declaration to the end of the protected type declaration and throughout the corresponding protected definition.

Ramification:
Declarations appearing in the protected specification are directly visible in the body of all subprograms contained in the corresponding protected type body unless hidden by VHDL's normal visibility rules.

2.6.3 Visibility

Declarations appearing in the protected type declaration are visible by selection at places that are defined by a prefix which is an object of the specified protected type.

LRM Change:
This requires a change to Section 10.3 describing the selection mechanism.

Declarations appearing in the protected body are directly visible from the point of declaration in the protected type definition to the end of the protected type definition. Ramification:
Declarations appearing in the protected type definition are directly visible in the body of all subsequent subprograms contained in the protected type definition unless hidden by VHDL's normal visibility rules.

Note:
Each object of the protected type is a unique instance of the collection of objects declared in the protected type definition (analogous to objects of a record type).

2.6.4 Use Clauses

Note:
Use clauses in VHDL achieve direct visibility for declarations which are visible by selection such that the selection prefix is a package or library (but not a protected type or shared variable). The declaration brought into direct visibility can be a protected type or shared variable.

Note:
Use clauses can make a package's protected type or shared variable directly visible. Since the package is only elaborated once, the shared variable declared in the package is only elaborated once and thus is uniquely defined.

Use clauses may not be used to make any declaration within the protected type directly visible from outside the protected type.

2.7 Elaboration and Execution

This section describes the additional elaboration and execution functionality associated with protected types.

2.7.1 Elaboration of Protected Types

Elaboration of a protected type declaration consists simply of creating the protected type as a "template". Elaboration of the protected type functionally occurs when and if an object of the protected type is elaborated.

Elaboration of a protected type definition declaration consists simply of creating the protected type definition as a "template" body. Elaboration of the protected type body definition is functionally deferred until an object of the protected type is elaborated. At this time the declarations present in the protected type body are elaborated.

Elaboration of the protected type declaration when an object is created of the protected type involves elaborating the declarative part of the declaration. Elaboration of the protected type defintion involves elaborating the declarative part of the definition.

2.7.2 Elaboration of Protected Type Object Declarations

Elaboration of an object declaration that includes a protected type (directly or indirectly) first involves elaboration of the subtype indication to determine the object's subtype. This is analogous to the template-like elaboration of a component declaration. Since the object includes a protected type, it can't be initialized with an initial value, so step (b) of IEEE Std. 12.3.1.4 does not occur. Step (c) involves creating the object, and for each protected type subelement, the protected type definition is elaborated followed by elaboration of the associated protected type body definition. This step is analogous to the instantiation of an entity/architecture pair from a component declaration. Step (d) of the object elaboration process does not occur.

LRM Change:
The above semantics will need to be incorporated in Section 12.3.1.4 (Object Declarations) of IEEE Std. 1076-93.

2.7.3 (Dynamic) Elaboration of Protected-Type Objects in a Subprogram

Elaboration of a variable of protected type proceeds identically with other VHDL variables declared in a subprogram (See Section 12.5 (b) of IEEE Std. 1076-93) since the subprogram is only accessible to a single process (no atomicity is required).

2.7.4 (Dynamic) Elaboration of Interface Objects in a Non-protected Type Subprogram

Elaboration of interface objects having protected type occurs by reference. It is as if the formal parameter becomes an alias for the actual protected type object.

LRM Change: The LRM must ensure that actuals of protected type are passed by reference, not value. This should probably be noted in Section 2.1.1.1 (Constant and Variable Parameters) of IEEE Std. 1076-93.

2.7.5 (Dynamic) Elaboration & Execution of a Protected Type Subprogram

When such a protected-type subprogram is called by selection, the following happens:

1. The subtype indication of each actual is elaborated.
2. Actuals (and their subtype indication) are associated with formals of the called subprogram.
3. The call blocks until exclusive access is available to the object of protected type denoted by the prefix (note that access may have already been granted to a caller or its caller...).
4. The object of protected type denoted by the prefix assigns exclusive access to the calling process if such exclusive access was not already assigned to the process prior to this call.
5. Any declarations local to the called subprogram are elaborated.
6. The subprogram body executes.
7. The values of all output parameters are copied to the actual (parameters of mode out and inout).
8. If exclusive access to the object was granted as a side-effect of this call (in step 4), exclusive access is rescinded.

LRM Change:
Additional information concerning locking must be added to Section 12.5 (Dynamic Elaboration).

Ramification:
No exclusive access is requested or granted for shared variables passed as actuals in the call association list. Therefore access to the representation of those shared variables must occur, if at all, via subsequent calls where one of these shared variables forms the call prefix.

Note:
Chuck Swart notes that Ada has more restrictions on protected type functions. They are not allowed to update values (they are expected to be pure) and hence, non-mutual read access is allowed. (other processes are blocked from access to the type via procedures). Consideration should be given to making these restrictions on VHDL protected types.

Ramification:
Protected subprogram calls may be nested or recursive.

Ramification:
Signal parameters passed to a subprogram are passed by reference. The significance of this is that, if the call to the protected type subprogram blocks, then the value of the signal when the subprogram resumes will be the current value of the signal and not the value of the signal when the subprogram was initially called (and blocked).

Ramification:
Two or more processes accessing the same set of shared variables, combined with more than one level of nesting (described above) has the potential for livelock and/or deadlock.

Although more than one object of protected type may be assigned exclusively to the same process at the same time, the normal visibility rules determine which internal objects of the protected type are directly visible and which must be access via the protected type declaration subprograms. The only circumstance in which the internal objects of more than one protected type are simultaneously visible is in a protected type body that is statically nested within another protected type body.

2.7.6 Read and Write of Shared Variables

While exclusive access has been granted to a process making a call to a protected type subprogram, the sequential statements within the protected type subprogram may read and write elements of the protected type object in accordance with the nature of the subprogram (pure function, impure function or procedure).

2.8 Lexical Elements

The only change to VHDL's lexical elements are the new reserved word protected.

2.8.1 Reserved Words

This LCS introduces the new reserved work protected.

LCS Change:
This LCS introduces the new keyword protected into Section 13.9 of IEEE Std. 1076-93.

Ramification:
VHDL-87-compliant source code and VHDL-93-compliant source code that legally use "protected" as an identifier will encounter a syntactic error when analyzing VHDL-93 A-compliant source code.

3.0 Optional Extensions

This section briefly discusses five optional extensions to this LCS which provide increased functionality at the cost of increased complexity.

3.1 Overloaded Assignment

In order for the designer of a protected type to define a deep copy appropriate to a specific protected type, it would be useful to be able to overload value assignment of values with protected type. Such an extension is beyond the scope of PAR 1076A.

3.2 Constructors

In order to provide for user-defined assignment, and thus deep-copy, something like constructors would probably be needed. Such an extension is beyond the scope of PAR 1076A.

3.2.1 Destructors

If constructors were to be provided, good language design seems to dictate some form of destruction mechanism. Such an extension is beyond the scope of PAR 1076A.

3.2.2 Process ID

Within the body of a monitor type, it is often useful to identify the process from which the subprogram call originated in order to control functionality of the protected type method. Predefined declaration of a ProcessID type and an impure function returning a value of type ProcessID would accomplish this goal (resembling VHDL's current DelayLength type and impure function Now).

4.0 Examples:

In order to illustrate the protected approach defined in this language change specification, it is useful to consider four examples of increasing complexity: a shared counter protected type, a complex number protected type, a variable size array protected type and a mutual-exclusion semaphore. Each of these examples illustrates a different characteristic of this protected type design.

4.1 Shared Counter

The shared counter example illustrates an integer that must be atomically incriminated, decremented and observed. Note that all three of these operations are monadic in nature. First the shared counter protected type specification and body appear:

        type SharedCounter  is protected
                procedure increment (n: integer);
                procedure decrement (n: integer);
                function value return integer;
        end protected SharedCounter;
        ....
        type SharedCounter is protected body

                variable counter_value: integer := 0;

                procedure increment (n: integer) is
                        begin
                                counter_value := counter_value + n;
                        end procedure increment;
                procedure decrement (n: integer) is
                        begin
                                counter_value:= counter_value - n;
                        end procedure decrement;
                function value return integer is
                        begin
                                return counter_value;
                        end procedure value;

        end protected body SharedCounter;

Then a shared variable is created using the SharedCounter protected type:

        shared variable counter : SharedCounter;

Finally, several processes may utilize the shared variable, such as the example process below:

        example_process:
                process is
                        ...
                        counter.increment(5);
                        ...
                        counter.decrement(i);
                        ...
                        v := counter.value;

                        if (v = 0) then
                                ...-- by the time execution gets to here, the counter may
                                ...-- have changed value!
                        end if;
                end process example_process;

It is important to note that the if condition only insures that the counter was 0 at the instant of the call; by the time comparison occurs, the counter may have increased or decreased in value.

If it is important to insure that the semaphore remains zero while the comparison and if condition executes, a more complex CountingSemaphore would be required with methods to conditionally lock and unlock the counting semaphore. The caller (example_process in this case) would try to acquire the explicitly programmed lock. If the CountingSemaphore's lock subprogram granted access via that call, it would return a key by which the owner would be known in a subsequent call and the semaphore would reject any other lock request. The semaphore would only honor increment and decrement requests which contained the appropriate key (belonging to the exclusive owner). When the conditional operation was done, the owner of exclusive access must unlock the semaphore. While illustrating that a semaphore can be embedded in a monitor with simple monadic functionality, the responsibility is on the human to insure that every lock is matched by an unlock on every path.

Abstracting high-level function into the protected type can simplify the call down to a single call to the object of protected type. For example, the call to get the semaphore's value followed by a comparison with zero and an assert might be abstracted into a single CountingSemaphore subprogram which triggers a VHDL assert statement if the semaphore_value is zero.

4.2 Complex Number

The complex number example illustrates a protected type which could be represented as a real and imaginary part or a phase and magnitude. For purposes of illustration, the example happens to use a real and imaginary representation, although this should not be discernible from the interface. A single operator, addition, serves to illustrate definition of a dyadic operator for the complex number type.

        type ComplexNumber is protected
                procedure extract (variable r, i: out real);
                procedure add (variable a, b: in ComplexNumber);
        end protected ComplexNumber;
        ...
        type ComplexNumber is protected body

                variable re, im: real;

                procedure extract (variable r, i: out real) is
                        begin
                                r := re;
                                i := im;
                        end procedure explode;
                procedure add (variable a, b: in ComplexNumber) is
                                variable a_real, b_real : real;
                                variable a_imag, b_imag : real;
                        begin
                                a.extract(a_real, a_imag);
                                b.extract(b_real, b_imag);
                                re := a_real + b_real;
                                im := a_imag + b_imag;
                        end procedure add;


        end protected body ComplexNumber;

Then in some concurrent declarative region, perhaps that of an architecture, three shared variables are declared with default initial values.

        shared variable sv1, sv2, result : ComplexNumber;

Sequential statements and concurrent procedure calls may reference these shared variables from many different processes. result.add(sv1,sv2); Next we consider an example of a protected type retaining a variable size object.

4.3 Variable Size Array

The variable size array example illustrates a protected type capable of representing an object of varying size. In this case, the varying size refers to the number of bit elements stored:

        type VariableSizeBitArray is protected
                procedure add_bit (index: positive; value: bit);
                function size return integer;
        end protected VariableSizeBitArray;
        type VariableSizeBitArray is protected body
                type bit_vector_access is access bit_vector;

                -- In this simple case, element initalization works, however note
                -- the alternative approach suggested by Peter Ashenden below...
                variable bit_array: bit_vector_access := NULL;
                variable bit_array_length : natural := 0;
                procedure add_bit (index: positive; value : bit) is
                                variable tmp : bit_vector_access;
                        begin
                                if  index > bit_array_length then
                                        tmp := bit_array;
                                        bit_array_length := index;
                                        bit_array := new bit_vector(1 to index);
                                        if tmp /= null then
                                                bit_array(1 to bit_array_length) := tmp.all;
                                                deallocate (tmp);
                                        end if;
                                end if;
                                bit_array (index) := value;
                        end procedure add_bit;

                function size return integer is
                        begin
                                return bit_array_length;
                        end function size;
                impure function initialize return boolean is
                        begin
                                bit_array := null;
                                bit_array_length := 0;
                                return true;
                        end function initialize;
                constant initialized : boolean := initialize;

        end protected body VariableSizeBitArray;

Within a sequential declarative region, perhaps a process, we can then declare a variable bit_stack: variable bit_stack: VariableSizeBitArray; The sequential code within the process may then initialize the bit_stack then adds three elements:

        bit_stack.add_bit(1,'1');
        bit_stack.add_bit(2,'1');
        bit_stack.add_bit(3,'0');

The VariableSizeBitArray protected type could equally well have been used to create a shared variable accessible from several processes during the same delta cycle. As long as the array was initialized once, the bit_stack should function equally well.

The interested reader is urged to sketch other short examples which illustrate use of protected types for scenarios of interest to the reader. Authors of this LCS would be very interested in examples which imply incorrect results under some parallel processing scenerios or which seem unacceptably awkward.

4.4 Semaphore

Monitors are intended to provide a more powerful, higher level mechanism than semaphores, however monitors do not readily replace semaphores. Chuck Swart prepared this example to illustrate the complexity of implementing a semaphore using monitors.

In general, semaphores are used in the following way:

        p1: process is
                ...
                P(s); -- Block until semaphore s is acquired
                ... -- Critical section c1
                V(s); -- Release semaphore s
                ...
        p2: process is
                ...
                P(s); -- Block until semaphore s is acquired
                ... -- Critical section c2
                V(s); -- Release semaphore s;
                ...

The P and V procedures are executed atomically. When a process executes a P the process requests control of the semaphore. If another process controls the semaphore, execution of the requesting process is blocked until the semaphore is available. Execution of V releases the semaphore for use by other processes.

The above code uses semaphores to guarantee that critical regions c1 and c2 will not execute simultaneously.

Here is an example which tries to emulate the above code using protected types:

        entity e is end e;
architecture foo of e is
                type Semaphore is protected
                        procedure up ( variable ret_val: out boolean);
                        procedure down;
                end protected;
                type Sempahore is protected body
                        variable entry_ok: boolean := true;
                        procedure up ( variable ret_val: out boolean) is
                                begin
                                        ret_val := entry_ok;
                                        entry_ok := FALSE;
                                end procedure up;
                        procedure down is
                                begin
                                        entry_ok := true; -- For simplicity, no error checks
                        end procedure down;
                end protected;
                shared variable s: Semaphore;
                procedure P ( variable s: Semaphore) is
                                variable success: boolean := false;
                        begin
                        loop1:                  while not (success)  loop  -- note busy loop
                                                        s.up(success);
                                                end loop loop1;
                                                return;
                        end procedure P;
                procedure V ( variable  s:  Semaphore) is
                        begin
                                s.down;
                        return;
                end procedure V;
                ...
                p1: process is
                        ...
                        P(s); -- Block until semaphore s is acquired;
                        ... -- Critical section c1
                        V(s); -- Release semaphore s;
                        ...
                p2: process is
                        ...
                        P(s); -- Block until semaphore s is acquired;
                        ... -- Critical section c2
                        V(s); -- Release semaphore s;
                        ...

Unless this code executes in an environment which interleaves execution of p1 and p2, the code will not execute as expected. However, most, if not all, current uniprocessor implementations execute a single process until that process executes a wait statement. Under this common implementation, if p1 executes while p2 is in critical section c2, then process p1 will busy wait forever, since control will never be given to p2 and, thus, the semaphore will never be released.

The preferred solution is to reformulate the VHDL code as a monitor. The critical sections (C1 and C2 above) are rewritten as two procedures in a protected type declaration (and body). In this case the protected type body need not have any state (variable declarations). An object of protected type CriticalSection can be created and referenced from two or more processes.

        type CriticalSection is protected
                procedure c1;
                procedure c2;
        end protected CriticalSection;
        ...
        type CriticalSection is protected body

                procedure c1 is
                        begin
                                -- Body of critical section c1
                        end procedure c2;
                procedure c2 is
                        begin
                                -- Body of critical section c2
                        end procedure c2;
                
        end protected body CriticalSection;

        shared variable Semaphore : CriticalSection;

5.0 Upward-compatibility

This language change specification introduces two primary sources of incompatibility relative to VHDL code compliant with IEEE Standard 1076-93. Introduction of the keyword protected may result in an identifier now interpreted as a keyword. This should result in a syntactic error. Any shared variables must now be of protected type. Since protected types did not previously exist, this incompatibility can be detected as part of the syntactic or type analysis phase of compilation.

6.0 Other Alternatives Considered

In the domain of Concurrent Sequential Process (CSP) languages, there are 3 well-known approaches to providing mutual exclusion for shared resources: semaphores, critical regions and monitors. This section discusses how the requirements phase and VHDL-92 negative ballots indicated that semaphores and critical regions not the approach of choice.

6.1 Semaphores

Semaphores provide for independent statements denoting entry to and exit from a critical section. Their apparent simplicity and flexibility hides complications in cases where dynamic code execution does not correctly pair the entry and exit, resulting in deadlock. Within the mutual exclusion literature, semaphores are analogous to the GOTO statement within sequential programming language design. Several VHDL 1076A requirements rated as strongly desirable were not consistent with the semaphore design including:

• R2.1.1: Consistency with VHDL's fundamentals
• R2.4.3.1.1.1: Mandatory integrity for SV of scalar type
• R2.1.5.1: Visibility and encapsulation
• R2.1.4: Portability
• R2.1.6: Maintainability
• R2.1.2: Equivalent block structure
• R2.4.3.1.3: Value integrity among multiple objects
• R2.4.3.1.6: Atomicity of variable assignment statements

6.2 Critical Regions

The first (draft) version of VHDL 1992 provided shared variables with mutual exclusion semantics through a form of critical regions called access statements. The following sections describe this initial implementation and some of the problems associated with it.

In VHDL 1992/A, the access statement defined a critical region of code for one or more shared variables. Some of the more important characteristics of the access statement were:

A shared variable access list, analogous to a process sensitivity list, declared which shared variables needed to be locked before execution of the critical region could proceed.

Limitations were placed on the types of statements that could be executed in a critical region. For example, wait statements were not permitted in critical regions.

To prevent deadlock situations, critical regions could not be accessed from within a another critical region. Because the access statement did not resolve the issue of more than one process containing an access-typed variable referencing the same shared data (alias), shared variables could not be access-typed.

Figure 1 below uses a fragment of code to demonstrate 1076-1992/A access statements. As a result of the mutual exclusion provided by access statements, shared variable SV1 will always have a value of -2, 0, or +2. The addition operation (first access statement) or the subtraction operation (second access statement) will always execute atomically. Without the mutual exclusion assured by the access statement, the SV1 in P1 may be consistently referenced on the right hand side, then the subtraction statement in P2 might execute completely, then the increment and store phase of the sequential statement in process P1 might complete, assigning a sequence of ascending, even values to SV1. With more complex data structures that a single variable and more complex, composite types, even more bizarre results are possible in the absence of mutual exclusion.

Figure 1: Example illustrating VHDL-93 Draft A's access statement

Balloting of 1076-1992/A raised issues concerning access statements ranging from concern that the access statement failed to satisfy the original requirements to concerns that the language definition was ambiguous. Issues raised include:

Problems, primarily ambiguities, surrounding the shared variable access list:

If the shared variable access list contains an indexed name, sliced name or record element, what constitutes the longest static prefix?

Does the language specify the order in which the access list's shared variables are locked?

Restrictions against nesting of access statements (to prevent deadlock) violated principles of information hiding, making access statements effectively unusable within subprograms.

Restrictions against access-typed shared variables left a key requirement for dynamically sized data structures unsatisfied.

The ballot resolution team looked at the problems and issues with the A draft's implementation of shared variables and, due to time constraints and the inability to agree on a better solution, decided to provide the simplest resolution possible, global variables without any form of mutual exclusion.

Because members of the language design team neither had the time to flesh out a new language implementation nor would user pressures permit omission from the language, they chose a solution that many hated and few liked. Since all the issues with the A draft concerning shared variables involved mutual exclusion semantics, the solution was to eliminate all mutual exclusion semantics from the language. This solution required implements to define their own mutual exclusion semantics for multi-threaded simulators and parallel simulators. In the absence of language- mandated mechanisms for mutual-exclusion, users were likely to find that VHDL models using shared variables were at best not portable between simulators or even versions of the same simulator.

The result of balloting the 1076-1992/B draft was predictable. Shared variables were once again the center of attention, primarily from those who understood the long-term ramifications of a parallel language design with shared variables but completely lacking any mechanism for mutual exclusion. Mutual exclusion is primarily a concern for multi-threaded simulators, parallel simulators, synthesis systems and formal verification systems. Such tools with support for shared variables were apparently not widely available to the 1076-1992/B language designers or ballot group, hence the problem was initially not widely understood.

However, since the result of the balloting was predicted, and no one wanted the 1992 standardization held up indefinitely for a complete fix to the shared variable problem, the B draft was distributed to balloters with a cover letter promising the formation of a working group to address this single language issue. Thus was born the Shared Variables Working Group and eventually this language change specification based on monitors.

6.3 Monitors

See the motivational introduction to Section 2 (Section 2.1) for an introduction to monitors. NOTE: This is the last page of the LCS.

Copyright © 1996, Contributors to the Shared Variable Working Group. All rights reserved.