IEEE Standard VHDL Language Reference Manual Manual, Standard. 2000

User Manual:

Open the PDF directly: View PDF .
Page Count: 299

Download
Open PDF In Browser	View PDF

IEEE Std 1076, 2000 Edition
(Incorporates IEEE Std 1076-1993
and IEEE Std 1076a-2000)

IEEE Standard VHDL
Language Reference Manual

Cosponsors

Design Automation Standards Committee (DASC)
of the
IEEE Computer Society
and
Automatic Test Program Generation Subcommittee
of the
IEEE Standards Coordinating Committee 20 (SCC 20)
Approved 30 January 2000

IEEE-SA Standards Board

Abstract: VHSIC Hardware Description Language (VHDL) is defined. VHDL is a formal notation
intended for use in all phases of the creation of electronic systems. Because it is both machine readable and human readable, it supports the development, verification, synthesis, and testing of hardware designs; the communication of hardware design data; and the maintenance, modification, and
procurement of hardware. Its primary audiences are the implementors of tools supporting the language and the advanced users of the language.
Keywords: computer languages, electronic systems, hardware, hardware design, VHDL

The Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, USA
Copyright © 2000 by the Institute of Electrical and Electronics Engineers, Inc.
All rights reserved. Published 29 December 2000. Printed in the United States of America.
Print:
PDF:

ISBN 0-7381-1948-2
ISBN 0-7381-1949-0

SH94817
SS94817

No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior
written permission of the publisher.

IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (IEEE-SA) Standards Board. Members of the committees serve
voluntarily and without compensation. They are not necessarily members of the Institute. The standards
developed within IEEE represent a consensus of the broad expertise on the subject within the Institute as
well as those activities outside of IEEE that have expressed an interest in participating in the development of
the standard.
Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there
are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to
the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and
issued is subject to change brought about through developments in the state of the art and comments
received from users of the standard. Every IEEE Standard is subjected to review at least every ﬁve years for
revision or reafﬁrmation. When a document is more than ﬁve years old and has not been reafﬁrmed, it is reasonable to conclude that its contents, although still of some value, do not wholly reﬂect the present state of
the art. Users are cautioned to check to determine that they have the latest edition of any IEEE Standard.
Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership
afﬁliation with IEEE. Suggestions for changes in documents should be in the form of a proposed change of
text, together with appropriate supporting comments.
Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they
relate to speciﬁc applications. When the need for interpretations is brought to the attention of IEEE, the
Institute will initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus of
all concerned interests, it is important to ensure that any interpretation has also received the concurrence of a
balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating
Committees are not able to provide an instant response to interpretation requests except in those cases where
the matter has previously received formal consideration.
Comments on standards and requests for interpretations should be addressed to:
Secretary, IEEE-SA Standards Board
445 Hoes Lane
P.O. Box 1331
Piscataway, NJ 08855-1331
USA

Note: Attention is called to the possibility that implementation of this standard may
require use of subject matter covered by patent rights. By publication of this standard,
no position is taken with respect to the existence or validity of any patent rights in
connection therewith. The IEEE shall not be responsible for identifying patents for
which a license may be required by an IEEE standard or for conducting inquiries into
the legal validity or scope of those patents that are brought to its attention.

IEEE is the sole entity that may authorize the use of certiﬁcation marks, trademarks, or other designations to
indicate compliance with the materials set forth herein.
Authorization to photocopy portions of any individual standard for internal or personal use is granted by the
Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright
Clearance Center. To arrange for payment of licensing fee, please contact Copyright Clearance Center,
Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; (978) 750-8400. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the
Copyright Clearance Center.

Introduction
(This introduction is not part of IEEE Std 1076, 2000 Edition, IEEE Standards VHDL Language Reference Manual.)

The VHSIC Hardware Description Language (VHDL) is a formal notation intended for use in all phases of
the creation of electronic systems. Because it is both machine readable and human readable, it supports the
development, veriﬁcation, synthesis, and testing of hardware designs; the communication of hardware
design data; and the maintenance, modiﬁcation, and procurement of hardware.
This document speciﬁes IEEE Std 1076, 2000 Edition, which incorporates IEEE Std 1076-1993 and IEEE
Std 1076a-2000.

Participants
The following individuals participated in the development of this standard:
Stephen A. Bailey, Chair
Peter J. Ashenden
David L. Barton
Victor Berman
Alain Fonkoua
Andrew Guyler
John Hillawi

Serge Maginot
Paul J. Menchini
Jean Mermet
Rob Newshutz
William R. Paulsen

Gregory D. Peterson
Jacques Rouillard
Ron Werner
John Willis
Phil Wilsey
Alex Zamﬁrescu

The following members of the balloting committee voted on this standard:
Peter J. Ashenden
Stephen A. Bailey
David L. Barton
Victor Berman
J. Bhasker
Dominique Borrione
Todd P. Carpenter
Allen Dewey
Douglas D. Dunlop
Wayne P. Fischer
Rita A. Glover
Kenji Goto
Brian S. Grifﬁn
Andrew Guyler
M. M. Kamal Hashmi

Copyright © 2000 IEEE. All rights reserved.

Rich Hatcher
Carl E. Hein
John Hillawi
John Hines
Osamu Karatsu
Jake Karrfalt
Michael D. McKinney
Paul J. Menchini
John T. Montague
Gabe Moretti
Gerald Musgrave
Zainalabedin Navabi
Kevin O’Brien
Seraﬁn Olcoz
Vincent Olive

Gregory D. Peterson
Markus Pfaff
Steffen Rochel
Jacques Rouillard
Quentin G. Schmierer
Steven E. Schulz
Moe Shahdad
Charles F. Shelor
Hiroshi Shinkai
Joseph J. Stanco
Atsushi Takahara
David Tester
Peter Trajmar
J. Richard Weger
John Willis

iii

When the IEEE-SA Standards Board approved this standard on 30 January 2000, it had the following
membership:
Richard J. Holleman, Chair
Donald N. Heirman, Vice Chair
Judith Gorman, Secretary
Satish K. Aggarwal
Dennis Bodson
Mark D. Bowman
James T. Carlo
Gary R. Engmann
Harold E. Epstein
Jay Forster*
Ruben D. Garzon

Louis-François Pau
Ronald C. Petersen
Gerald H. Peterson
John B. Posey
Gary S. Robinson
Akio Tojo
Hans E. Weinrich
Donald W. Zipse

James H. Gurney
Lowell G. Johnson
Robert J. Kennelly
E. G. “Al” Kiener
Joseph L. Koepﬁnger*
L. Bruce McClung
Daleep C. Mohla
Robert F. Munzner

*Member Emeritus

Also included is the following nonvoting IEEE-SA Standards Board liaison:
Robert E. Hebner

Andrew D. Ickowicz
IEEE Standards Project Editor

iv

Copyright © 2000 IEEE. All rights reserved.

Contents
0.

Overview of this standard .................................................................................................................... 1
0.1 Intent and scope of this standard.................................................................................................. 1
0.2 Structure and terminology of this standard.................................................................................. 1
0.2.1 Syntactic description................................................................................................................. 2
0.2.2 Semantic description ................................................................................................................. 3
0.2.3 Front matter, examples, notes, references, and annexes ........................................................... 3

1.

Design entities and configurations....................................................................................................... 5
1.1 Entity declarations ....................................................................................................................... 5
1.1.1 Entity header ............................................................................................................................. 5
1.1.1.1 Generics ................................................................................................................................. 6
1.1.1.2 Ports ....................................................................................................................................... 7
1.1.2 Entity declarative part ............................................................................................................... 8
1.1.3 Entity statement part ................................................................................................................. 9
1.2 Architecture bodies ...................................................................................................................... 9
1.2.1 Architecture declarative part ................................................................................................... 10
1.2.2 Architecture statement part ..................................................................................................... 10
1.3 Configuration declarations......................................................................................................... 12
1.3.1 Block configuration ................................................................................................................ 13
1.3.2 Component configuration ....................................................................................................... 15

2.

Subprograms and packages................................................................................................................ 19
2.1 Subprogram declarations ........................................................................................................... 19
2.1.1 Formal parameters .................................................................................................................. 20
2.1.1.1 Constant and variable parameters ........................................................................................ 20
2.1.1.2 Signal parameter .................................................................................................................. 21
2.1.1.3 File parameters ..................................................................................................................... 22
2.2 Subprogram bodies .................................................................................................................... 22
2.3 Subprogram overloading............................................................................................................ 25
2.3.1 Operator overloading .............................................................................................................. 26
2.3.2 Signatures ................................................................................................................................ 26
2.4 Resolution functions .................................................................................................................. 27
2.5 Package declarations.................................................................................................................. 28
2.6 Package bodies........................................................................................................................... 29
2.7 Conformance rules ..................................................................................................................... 31

3.

Types.................................................................................................................................................. 33
3.1 Scalar types ................................................................................................................................ 34
3.1.1 Enumeration types .................................................................................................................. 34
3.1.1.1 Predefined enumeration types .............................................................................................. 35
3.1.2 Integer types ............................................................................................................................ 36
3.1.2.1 Predefined integer types ....................................................................................................... 36
3.1.3 Physical types .......................................................................................................................... 36
3.1.3.1 Predefined physical types .................................................................................................... 38
3.1.4 Floating point types ................................................................................................................. 39
3.1.4.1 Predefined floating point types ............................................................................................ 40
3.2 Composite types......................................................................................................................... 40

Copyright © 2000 IEEE. All rights reserved.

v

3.2.1 Array types .............................................................................................................................. 40
3.2.1.1 Index constraints and discrete ranges .................................................................................. 42
3.2.1.2 Predefined array types .......................................................................................................... 44
3.2.2 Record types ............................................................................................................................ 44
3.3 Access types............................................................................................................................... 45
3.3.1 Incomplete type declarations .................................................................................................. 46
3.3.2 Allocation and deallocation of objects .................................................................................... 47
3.4 File types.................................................................................................................................... 47
3.4.1 File operations ......................................................................................................................... 48
3.5 Protected types ........................................................................................................................... 50
3.5.1 Protected type declarations ..................................................................................................... 50
3.5.2 Protected type bodies .............................................................................................................. 51
4.

Declarations ....................................................................................................................................... 55
4.1 Type declarations ....................................................................................................................... 55
4.2 Subtype declarations .................................................................................................................. 56
4.3 Objects ....................................................................................................................................... 57
4.3.1 Object declarations .................................................................................................................. 58
4.3.1.1 Constant declarations ........................................................................................................... 58
4.3.1.2 Signal declarations ............................................................................................................... 59
4.3.1.3 Variable declarations ........................................................................................................... 60
4.3.1.4 File declarations ................................................................................................................... 62
4.3.2 Interface declarations .............................................................................................................. 63
4.3.2.1 Interface lists ........................................................................................................................ 65
4.3.2.2 Association lists ................................................................................................................... 66
4.3.3 Alias declarations .................................................................................................................... 68
4.3.3.1 Object aliases ....................................................................................................................... 69
4.3.3.2 Nonobject aliases ................................................................................................................. 70
4.4 Attribute declarations................................................................................................................. 71
4.5 Component declarations............................................................................................................. 72
4.6 Group template declarations ...................................................................................................... 72
4.7 Group declarations ..................................................................................................................... 73

5.

Specifications..................................................................................................................................... 75
5.1 Attribute specification................................................................................................................ 75
5.2 Configuration specification........................................................................................................ 77
5.2.1 Binding indication ................................................................................................................... 78
5.2.1.1 Entity aspect ......................................................................................................................... 80
5.2.1.2 Generic map and port map aspects ...................................................................................... 81
5.2.2 Default binding indication ...................................................................................................... 83
5.3 Disconnection specification ....................................................................................................... 84

6.

Names ................................................................................................................................................ 87
6.1
6.2
6.3
6.4
6.5
6.6

vi

Names ........................................................................................................................................ 87
Simple names ............................................................................................................................. 88
Selected names........................................................................................................................... 89
Indexed names ........................................................................................................................... 91
Slice names ................................................................................................................................ 92
Attribute names.......................................................................................................................... 92

Copyright © 2000 IEEE. All rights reserved.

7.

Expressions ........................................................................................................................................ 95
7.1 Rules for expressions ................................................................................................................. 95
7.2 Operators.................................................................................................................................... 96
7.2.1 Logical operators .................................................................................................................... 96
7.2.2 Relational operators ................................................................................................................ 97
7.2.3 Shift operators ......................................................................................................................... 98
7.2.4 Adding operators ................................................................................................................... 100
7.2.5 Sign operators ....................................................................................................................... 102
7.2.6 Multiplying operators ............................................................................................................ 102
7.2.7 Miscellaneous operators ........................................................................................................ 104
7.3 Operands .................................................................................................................................. 104
7.3.1 Literals .................................................................................................................................. 105
7.3.2 Aggregates ............................................................................................................................. 106
7.3.2.1 Record aggregates .............................................................................................................. 106
7.3.2.2 Array aggregates ................................................................................................................ 107
7.3.3 Function calls ........................................................................................................................ 108
7.3.4 Qualified expressions ............................................................................................................ 108
7.3.5 Type conversions .................................................................................................................. 109
7.3.6 Allocators .............................................................................................................................. 110
7.4 Static expressions..................................................................................................................... 111
7.4.1 Locally static primaries ......................................................................................................... 111
7.4.2 Globally static primaries ....................................................................................................... 112
7.5 Universal expressions .............................................................................................................. 113

8.

Sequential statements....................................................................................................................... 115
8.1 Wait statement ......................................................................................................................... 115
8.2 Assertion statement.................................................................................................................. 117
8.3 Report statement ...................................................................................................................... 118
8.4 Signal assignment statement .................................................................................................... 118
8.4.1 Updating a projected output waveform ................................................................................. 120
8.5 Variable assignment statement ................................................................................................ 123
8.5.1 Array variable assignments................................................................................................... 124
8.6 Procedure call statement .......................................................................................................... 124
8.7 If statement............................................................................................................................... 125
8.8 Case statement ......................................................................................................................... 125
8.9 Loop statement......................................................................................................................... 126
8.10 Next statement ......................................................................................................................... 127
8.11 Exit statement........................................................................................................................... 127
8.12 Return statement ...................................................................................................................... 128
8.13 Null statement .......................................................................................................................... 128

9.

Concurrent statements...................................................................................................................... 129
9.1 Block statement........................................................................................................................ 129
9.2 Process statement ..................................................................................................................... 130
9.3 Concurrent procedure call statements...................................................................................... 131
9.4 Concurrent assertion statements .............................................................................................. 132
9.5 Concurrent signal assignment statements ................................................................................ 133
9.5.1 Conditional signal assignments ............................................................................................. 135
9.5.2 Selected signal assignments .................................................................................................. 137
9.6 Component instantiation statements ........................................................................................ 138
9.6.1 Instantiation of a component ................................................................................................. 139

Copyright © 2000 IEEE. All rights reserved.

vii

9.6.2 Instantiation of a design entity .............................................................................................. 141
9.7 Generate statements ................................................................................................................. 144
10.

Scope and visibility.......................................................................................................................... 145
10.1 Declarative region.................................................................................................................... 145
10.2 Scope of declarations ............................................................................................................... 145
10.3 Visibility .................................................................................................................................. 146
10.4 Use clauses............................................................................................................................... 150
10.5 The context of overload resolution .......................................................................................... 150

11.

Design units and their analysis ........................................................................................................ 153
11.1 Design units ............................................................................................................................. 153
11.2 Design libraries ........................................................................................................................ 153
11.3 Context clauses ........................................................................................................................ 154
11.4 Order of analysis ...................................................................................................................... 155

12.

Elaboration and execution................................................................................................................ 157
12.1 Elaboration of a design hierarchy ............................................................................................ 157
12.2 Elaboration of a block header .................................................................................................. 159
12.2.1 The generic clause ............................................................................................................... 159
12.2.2 The generic map aspect ....................................................................................................... 159
12.2.3 The port clause .................................................................................................................... 159
12.2.4 The port map aspect ............................................................................................................ 159
12.3 Elaboration of a declarative part .............................................................................................. 160
12.3.1 Elaboration of a declaration ................................................................................................ 161
12.3.1.1 Subprogram declarations and bodies ............................................................................... 161
12.3.1.2 Type declarations ............................................................................................................. 161
12.3.1.3 Subtype declarations ........................................................................................................ 162
12.3.1.4 Object declarations ........................................................................................................... 162
12.3.1.5 Alias declarations ............................................................................................................. 163
12.3.1.6 Attribute declarations ....................................................................................................... 163
12.3.1.7 Component declarations ................................................................................................... 163
12.3.2 Elaboration of a specification ............................................................................................. 163
12.3.2.1 Attribute specifications .................................................................................................... 163
12.3.2.2 Configuration specifications ............................................................................................ 163
12.3.2.3 Disconnection specifications ........................................................................................... 164
12.4 Elaboration of a statement part ................................................................................................ 164
12.4.1 Block statements ................................................................................................................. 164
12.4.2 Generate statements ............................................................................................................ 164
12.4.3 Component instantiation statements ................................................................................... 166
12.4.4 Other concurrent statements ............................................................................................... 166
12.5 Dynamic elaboration................................................................................................................ 167
12.6 Execution of a model ............................................................................................................... 167
12.6.1 Drivers ................................................................................................................................. 168
12.6.2 Propagation of signal values ............................................................................................... 168
12.6.3 Updating implicit signals .................................................................................................... 171
12.6.4 The simulation cycle ........................................................................................................... 172

viii

Copyright © 2000 IEEE. All rights reserved.

13.

Lexical elements .............................................................................................................................. 175
13.1 Character set............................................................................................................................. 175
13.2 Lexical elements, separators, and delimiters ........................................................................... 178
13.3 Identifiers ................................................................................................................................. 179
13.3.1 Basic identifiers .................................................................................................................. 179
13.3.2 Extended identifiers ............................................................................................................ 179
13.4 Abstract literals ........................................................................................................................ 179
13.4.1 Decimal literals ................................................................................................................... 180
13.4.2 Based literals ....................................................................................................................... 180
13.5 Character literals ...................................................................................................................... 181
13.6 String literals............................................................................................................................ 181
13.7 Bit string literals....................................................................................................................... 182
13.8 Comments ................................................................................................................................ 183
13.9 Reserved words........................................................................................................................ 184
13.10 Allowable replacements of characters ................................................................................... 185

14.

Predefined language environment.................................................................................................... 187
14.1 Predefined attributes ................................................................................................................ 187
14.2 Package STANDARD ............................................................................................................. 201
14.3 Package TEXTIO..................................................................................................................... 208

Annex A (informative) Syntax Summary .................................................................................................... 213
Annex B (informative) Glossary.................................................................................................................. 233
Annex C (informative) Potentially nonportable constructs ......................................................................... 251
Annex D (informative) Bibliography........................................................................................................... 253
Index............ ................................................................................................................................................ 255

Copyright © 2000 IEEE. All rights reserved.

ix

IEEE Standard VHDL
Language Reference Manual
0. Overview of this standard
This clause describes the purpose and organization of this standard.

0.1 Intent and scope of this standard

5

10

The intent of this standard is to deﬁne VHSIC Hardware Description Language (VHDL) accurately. Its
primary audiences are the implementor of tools supporting the language and the advanced user of the
language. Other users are encouraged to use commercially available books, tutorials, and classes to learn the
language in some detail prior to reading this standard. These resources generally focus on how to use the
language, rather than how a VHDL-compliant tool is required to behave.
At the time of its publication, this document was the authoritative deﬁnition of VHDL. From time to time, it
may become necessary to correct and/or clarify portions of this standard. Such corrections and clariﬁcations
may be published in separate documents. Such documents modify this standard at the time of their publication and remain in effect until superseded by subsequent documents or until the standard is ofﬁcially revised.

0.2 Structure and terminology of this standard
This standard is organized into clauses, each of which focuses on some particular area of the language.
Every ﬁfth line of each clause, not including clause headings, footers, and the clause title, is numbered in the
left margin. Within each clause, individual constructs or concepts are discussed in each subclause.

15

Each subclause describing a speciﬁc construct begins with an introductory paragraph. Next, the syntax of the
construct is described using one or more grammatical productions.
A set of paragraphs describing the meaning and restrictions of the construct in narrative form then follow.
Unlike many other IEEE standards, which use the verb shall to indicate mandatory requirements of the standard and may to indicate optional features, the verb is is used uniformly throughout this document. In all
cases, is is to be interpreted as having mandatory weight.

20

Additionally, the word must is used to indicate mandatory weight. This word is preferred over the more common shall, as must denotes a different meaning to different readers of this standard.
a)

To the developer of tools that process VHDL, must denotes a requirement that the standard imposes.
The resulting implementation is required to enforce the requirement and to issue an error if the
requirement is not met by some VHDL source text.

Copyright © 2000 IEEE. All rights reserved.

1

IEEE
Std 1076, 2000 Edition

25

IEEE STANDARD VHDL

b)

To the VHDL model developer, must denotes that the characteristics of VHDL are natural consequences of the language deﬁnition. The model developer is required to adhere to the constraint
implied by the characteristic.

c)

To the VHDL model user, must denotes that the characteristics of the models are natural consequences of the language deﬁnition. The model user can depend on the characteristics of the model
implied by its VHDL source text.

30

Finally, each clause may end with examples, notes, and references to other pertinent clauses.
0.2.1 Syntactic description
The form of a VHDL description is described by means of context-free syntax using a simple variant of the
backus naur form; in particular:
a)
35

Lowercase words in roman font, some containing embedded underlines, are used to denote syntactic
categories, for example:
formal_port_list
Whenever the name of a syntactic category is used, apart from the syntax rules themselves, space
take the place of underlines (thus, “formal port list” would appear in the narrative description when
referring to the above syntactic category).

b)

40

Boldface words are used to denote reserved words, for example:
array
Reserved words must be used only in those places indicated by the syntax.

c)

A production consists of a left-hand side, the symbol “::=” (which is read as “can be replaced by”),
and a right-hand side. The left-hand side of a production is always a syntactic category; the righthand side is a replacement rule. The meaning of a production is a textual-replacement rule: any
occurrence of the left-hand side may be replaced by an instance of the right-hand side.

d)

A vertical bar (|) separates alternative items on the right-hand side of a production unless it occurs
immediately after an opening brace, in which case it stands for itself, as follows:

45

letter_or_digit ::= letter | digit
choices ::= choice { | choice }

50

In the ﬁrst instance, an occurrence of “letter_or_digit” can be replaced by either “letter” or “digit.” In
the second case, “choices” can be replaced by a list of “choice,” separated by vertical bars [see item
f) for the meaning of braces].
e)
55

Square brackets [ ] enclose optional items on the right-hand side of a production; thus, the following
two productions are equivalent:
return_statement ::= return [ expression ] ;
return_statement ::= return ; | return expression ;
Note, however, that the initial and terminal square brackets in the right-hand side of the production
for signatures (see 2.3.2) are part of the syntax of signatures and do not indicate that the entire righthand side is optional.

60

f)

Braces { } enclose a repeated item or items on the right-hand side of a production. The items may
appear zero or more times; the repetitions occur from left to right as with an equivalent left-recursive
rule. Thus, the following two productions are equivalent:
term ::= factor { multiplying_operator factor }
term ::= factor | term multiplying_operator factor

65

2

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

70

IEEE
Std 1076, 2000 Edition

g)

If the name of any syntactic category starts with an italicized part, it is equivalent to the category
name without the italicized part. The italicized part is intended to convey some semantic information. For example, type_name and subtype_name are both syntactically equivalent to name alone.

h)

The term simple_name is used for any occurrence of an identiﬁer that already denotes some declared
entity.

0.2.2 Semantic description
The meaning and restrictions of a particular construct are described with a set of narrative rules immediately
following the syntactic productions. In these rules, an italicized term indicates the deﬁnition of that term and
identiﬁers appearing entirely in uppercase letters refer to deﬁnitions in package STANDARD (see 14.2).
The following terms are used in these semantic descriptions with the following meanings:
75

erroneous: The condition described represents an ill-formed description; however, implementations are not
required to detect and report this condition. Conditions are deemed erroneous only when it is impossible in
general to detect the condition during the processing of the language.
error: The condition described represents an ill-formed description; implementations are required to detect
the condition and report an error to the user of the tool.

80

illegal: A synonym for “error.”
legal: The condition described represents a well-formed description.
0.2.3 Front matter, examples, notes, references, and annexes
Prior to this subclause are several pieces of introductory material; following the ﬁnal clause are some
annexes and an index. The front matter, annexes, and index serve to orient and otherwise aid the user of this
standard, but are not part of the deﬁnition of VHDL.

85

90

Some clauses of this standard contain examples, notes, and cross-references to other clauses of the standard;
these parts always appear at the end of a clause. Examples are meant to illustrate the possible forms of the
construct described. Illegal examples are italicized. Notes are meant to emphasize consequences of the rules
described in the clause or elsewhere. In order to distinguish notes from the other narrative portions of this
standard, notes are set as enumerated paragraphs in a font smaller than the rest of the text. Cross-references
are meant to guide the user to other relevant clauses of the standard. Examples, notes, and cross-references
are not part of the deﬁnition of the language.

Copyright © 2000 IEEE. All rights reserved.

3

IEEE
Std 1076, 2000 Edition

4

IEEE STANDARD VHDL

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

1. Design entities and conﬁgurations

5

The design entity is the primary hardware abstraction in VHDL. It represents a portion of a hardware design
that has well-deﬁned inputs and outputs and performs a well-deﬁned function. A design entity may represent
an entire system, a subsystem, a board, a chip, a macro-cell, a logic gate, or any level of abstraction in
between. A conﬁguration can be used to describe how design entities are put together to form a complete
design.
A design entity may be described in terms of a hierarchy of blocks, each of which represents a portion of the
whole design. The top-level block in such a hierarchy is the design entity itself; such a block is an external
block that resides in a library and may be used as a component of other designs. Nested blocks in the hierarchy are internal blocks, deﬁned by block statements (see 9.1).

10

15

A design entity may also be described in terms of interconnected components. Each component of a design
entity may be bound to a lower-level design entity in order to deﬁne the structure or behavior of that
component. Successive decomposition of a design entity into components, and binding those components to
other design entities that may be decomposed in like manner, results in a hierarchy of design entities
representing a complete design. Such a collection of design entities is called a design hierarchy. The
bindings necessary to identify a design hierarchy can be speciﬁed in a conﬁguration of the top-level entity in
the hierarchy.
This clause describes the way in which design entities and conﬁgurations are deﬁned. A design entity is
deﬁned by an entity declaration together with a corresponding architecture body. A conﬁguration is deﬁned
by a conﬁguration declaration.

1.1 Entity declarations
20

25

30

An entity declaration deﬁnes the interface between a given design entity and the environment in which it is
used. It may also specify declarations and statements that are part of the design entity. A given entity
declaration may be shared by many design entities, each of which has a different architecture. Thus, an
entity declaration can potentially represent a class of design entities, each with the same interface.
entity_declaration ::=
entity identiﬁer is
entity_header
entity_declarative_part
[ begin
entity_statement_part ]
end [ entity ] [ entity_simple_name ] ;
The entity header and entity declarative part consist of declarative items that pertain to each design entity
whose interface is deﬁned by the entity declaration. The entity statement part, if present, consists of
concurrent statements that are present in each such design entity.

35

If a simple name appears at the end of an entity declaration, it must repeat the identiﬁer of the entity
declaration.
1.1.1 Entity header
The entity header declares objects used for communication between a design entity and its environment.
entity_header ::=
[ formal_generic_clause ]
[ formal_port_clause ]

Copyright © 2000 IEEE. All rights reserved.

5

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

generic_clause ::=
generic ( generic_list ) ;

40

port_clause ::=
port ( port_list ) ;

45

The generic list in the formal generic clause deﬁnes generic constants whose values may be determined by
the environment. The port list in the formal port clause deﬁnes the input and output ports of the design entity.
In certain circumstances, the names of generic constants and ports declared in the entity header become
visible outside of the design entity (see 10.2 and 10.3).
Examples:
—

An entity declaration with port declarations only:
entity Full_Adder is
port (X, Y, Cin: in Bit; Cout, Sum: out Bit) ;
end Full_Adder ;

50

—

An entity declaration with generic declarations also:
entity AndGate is
generic
(N: Natural := 2);
port
(Inputs: in Bit_Vector (1 to N);
Result: out Bit) ;
end entity AndGate ;

55

60

—

An entity declaration with neither:
entity TestBench is
end TestBench ;

1.1.1.1 Generics

65

Generics provide a channel for static information to be communicated to a block from its environment. The
following applies to both external blocks deﬁned by design entities and to internal blocks deﬁned by block
statements.
generic_list ::= generic_interface_list
The generics of a block are deﬁned by a generic interface list; interface lists are described in 4.3.2.1. Each
interface element in such a generic interface list declares a formal generic.

70

75

The value of a generic constant may be speciﬁed by the corresponding actual in a generic association list. If
no such actual is speciﬁed for a given formal generic (either because the formal generic is unassociated or
because the actual is open), and if a default expression is speciﬁed for that generic, the value of this expression is the value of the generic. It is an error if no actual is speciﬁed for a given formal generic and no default
expression is present in the corresponding interface element. It is an error if some of the subelements of a
composite formal generic are connected and others are either unconnected or unassociated.
NOTE—Generics may be used to control structural, dataﬂow, or behavioral characteristics of a block, or may simply be
used as documentation. In particular, generics may be used to specify the size of ports; the number of subcomponents
within a block; the timing characteristics of a block; or even the physical characteristics of a design such as temperature,
capacitance, or location.

6

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

1.1.1.2 Ports
80

Ports provide channels for dynamic communication between a block and its environment. The following
applies to both external blocks deﬁned by design entities and to internal blocks deﬁned by block statements,
including those equivalent to component instantiation statements and generate statements (see 9.7).
port_list ::= port_interface_list

85

90

95

100

The ports of a block are deﬁned by a port interface list; interface lists are described in 4.3.2.1. Each interface
element in the port interface list declares a formal port.
To communicate with other blocks, the ports of a block can be associated with signals in the environment in
which the block is used. Moreover, the ports of a block may be associated with an expression in order to
provide these ports with constant driving values; such ports must be of mode in. A port is itself a signal (see
4.3.1.2); thus, a formal port of a block may be associated as an actual with a formal port of an inner block.
The port, signal, or expression associated with a given formal port is called the actual corresponding to the
formal port (see 4.3.2.2). The actual, if a port or signal, must be denoted by a static name (see 6.1). The
actual, if an expression, must be a globally static expression (see 7.4).
After a given description is completely elaborated (see Clause 12), if a formal port is associated with an
actual that is itself a port, then the following restrictions apply depending upon the mode (see 4.3.2) of the
formal port:
a)
b)
c)
d)
e)

For a formal port of mode in, the associated actual may only be a port of mode in, inout, or buffer.
For a formal port of mode out, the associated actual may only be a port of mode out or inout.
For a formal port of mode inout, the associated actual may only be a port of mode inout.
For a formal port of mode buffer, the associated actual may only be a port of mode buffer.
For a formal port of mode linkage, the associated actual may be a port of any mode.

A buffer port may have at most one source (see 4.3.1.2 and 4.3.2). Furthermore, after a description is
completely elaborated (see Clause 12), any actual associated with a formal buffer port may have at most one
source.

105

If a formal port is associated with an actual port, signal, or expression, then the formal port is said to be
connected. If a formal port is instead associated with the reserved word open, then the formal is said to be
unconnected. A port of mode in may be unconnected or unassociated (see 4.3.2.2) only if its declaration
includes a default expression (see 4.3.2). A port of any mode other than in may be unconnected or
unassociated as long as its type is not an unconstrained array type. It is an error if some of the subelements of
a composite formal port are connected and others are either unconnected or unassociated.

Copyright © 2000 IEEE. All rights reserved.

7

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

1.1.2 Entity declarative part
110

The entity declarative part of a given entity declaration declares items that are common to all design entities
whose interfaces are deﬁned by the given entity declaration.
entity_declarative_part ::=
{ entity_declarative_item }
entity_declarative_item ::=
subprogram_declaration
| subprogram_body
| type_declaration
| subtype_declaration
| constant_declaration
| signal_declaration
| shared_variable_declaration
| ﬁle_declaration
| alias_declaration
| attribute_declaration
| attribute_speciﬁcation
| disconnection_speciﬁcation
| use_clause
| group_template_declaration
| group_declaration

115

120

125

130

Names declared by declarative items in the entity declarative part of a given entity declaration are visible
within the bodies of corresponding design entities, as well as within certain portions of a corresponding
conﬁguration declaration.
Example:
—

An entity declaration with entity declarative items:
entity ROM is
port (

135

Addr: in
Word;
Data: out
Word;
Sel:
in
Bit);
type
Instruction is array (1 to 5) of Natural;
type
Program is array (Natural range <>) of Instruction;
use Work.OpCodes.all, Work.RegisterNames.all;
constant ROM_Code: Program :=
(
(STM, R14,
R12,
12,
R13) ,
(LD,
R7,
32,
0,
R1 ) ,
(BAL, R14,
0,
0,
R7 ) ,
•
•
-- etc.
•
);
end ROM;

140

145

150

NOTE—The entity declarative part of a design entity whose corresponding architecture is decorated with the 'FOREIGN
attribute is subject to special elaboration rules. See 12.3.

8

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

1.1.3 Entity statement part

155

The entity statement part contains concurrent statements that are common to each design entity with this
interface.
entity_statement_part ::=
{ entity_statement }

160

entity_statement ::=
concurrent_assertion_statement
| passive_concurrent_procedure_call
| passive_process_statement
Only concurrent assertion statements, concurrent procedure call statements, or process statements may
appear in the entity statement part. All such statements must be passive (see 9.2). Such statements may be
used to monitor the operating conditions or characteristics of a design entity.

165

Example:
—

An entity declaration with statements:
entity Latch is
port (

170

175

180

Din:
in
Word;
Dout: out
Word;
Load: in
Bit;
Clk:
in
Bit );
constant Setup: Time := 12 ns;
constant PulseWidth: Time := 50 ns;
use Work.TimingMonitors.all;
begin
assert Clk='1' or Clk'Delayed'Stable (PulseWidth);
CheckTiming (Setup, Din, Load, Clk);
end ;

NOTE—The entity statement part of a design entity whose corresponding architecture is decorated with the 'FOREIGN
attribute is subject to special elaboration rules. See 12.4.

1.2 Architecture bodies
An architecture body deﬁnes the body of a design entity. It speciﬁes the relationships between the inputs and
outputs of a design entity and may be expressed in terms of structure, dataﬂow, or behavior. Such speciﬁcations may be partial or complete.

185

190

architecture_body ::=
architecture identiﬁer of entity_name is
architecture_declarative_part
begin
architecture_statement_part
end [ architecture ] [ architecture_simple_name ] ;
The identiﬁer deﬁnes the simple name of the architecture body; this simple name distinguishes architecture
bodies associated with the same entity declaration.

Copyright © 2000 IEEE. All rights reserved.

9

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

The entity name identiﬁes the name of the entity declaration that deﬁnes the interface of this design entity.
For a given design entity, both the entity declaration and the associated architecture body must reside in the
same library.
195

If a simple name appears at the end of an architecture body, it must repeat the identiﬁer of the architecture
body.
More than one architecture body may exist corresponding to a given entity declaration. Each declares a
different body with the same interface; thus, each together with the entity declaration represents a different
design entity with the same interface.

200

NOTE—Two architecture bodies that are associated with different entity declarations may have the same simple name,
even if both architecture bodies (and the corresponding entity declarations) reside in the same library.

1.2.1 Architecture declarative part
The architecture declarative part contains declarations of items that are available for use within the block
deﬁned by the design entity.
architecture_declarative_part ::=
{ block_declarative_item }

205

block_declarative_item ::=
subprogram_declaration
| subprogram_body
| type_declaration
| subtype_declaration
| constant_declaration
| signal_declaration
| shared_variable_declaration
| ﬁle_declaration
| alias_declaration
| component_declaration
| attribute_declaration
| attribute_speciﬁcation
| conﬁguration_speciﬁcation
| disconnection_speciﬁcation
| use_clause
| group_template_declaration
| group_declaration

210

215

220

225

The various kinds of declaration are described in Clause 4, and the various kinds of speciﬁcation are
described in Clause 5. The use clause, which makes externally deﬁned names visible within the block, is
described in Clause 10.
NOTE—The declarative part of an architecture decorated with the 'FOREIGN attribute is subject to special elaboration
rules. (See 12.3).

1.2.2 Architecture statement part

230

The architecture statement part contains statements that describe the internal organization and/or operation
of the block deﬁned by the design entity.
architecture_statement_part ::=
{ concurrent_statement }

10

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

All of the statements in the architecture statement part are concurrent statements, which execute asynchronously with respect to one another. The various kinds of concurrent statements are described in Clause 9.
235

Examples:
—

architecture DataFlow of Full_Adder is
signal A,B: Bit;
begin
A <= X xor Y;
B <= A and Cin;
Sum <= A xor Cin;
Cout <= B or (X and Y);
end architecture DataFlow ;

240

245

—

255

—

265

270

275

A body of entity TestBench:
library Test;
use Test.Components.all;
architecture Structure of TestBench is
component Full_Adder
port (X, Y, Cin: Bit; Cout, Sum: out Bit);
end component;
signal A,B,C,D,E,F,G: Bit;
signal OK: Boolean;
begin
UUT:
Full_Adder
port map (A,B,C,D,E);
Generator: AdderTest
port map (A,B,C,F,G);
Comparator: AdderCheck
port map (D,E,F,G,OK);
end Structure;

250

260

A body of entity Full_Adder:

A body of entity AndGate:
architecture Behavior of AndGate is
begin
process (Inputs)
variable Temp: Bit;
begin
Temp := '1';
for i in Inputs'Range loop
if Inputs(i) = '0' then
Temp := '0';
exit;
end if;
end loop;
Result <= Temp after 10 ns;
end process;
end Behavior;

NOTE—The statement part of an architecture decorated with the 'FOREIGN attribute is subject to special elaboration
rules. See 12.4.

Copyright © 2000 IEEE. All rights reserved.

11

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

1.3 Conﬁguration declarations

280

The binding of component instances to design entities is performed by conﬁguration speciﬁcations (see 5.2);
such speciﬁcations appear in the declarative part of the block in which the corresponding component
instances are created. In certain cases, however, it may be appropriate to leave unspeciﬁed the binding of
component instances in a given block and to defer such speciﬁcation until later. A conﬁguration declaration
provides the mechanism for specifying such deferred bindings.
conﬁguration_declaration ::=
conﬁguration identiﬁer of entity_name is
conﬁguration_declarative_part
block_conﬁguration
end [ conﬁguration ] [ conﬁguration_simple_name ] ;

285

conﬁguration_declarative_part ::=
{ conﬁguration_declarative_item }
conﬁguration_declarative_item ::=
use_clause
| attribute_speciﬁcation
| group_declaration

290

295

The entity name identiﬁes the name of the entity declaration that deﬁnes the design entity at the apex of the
design hierarchy. For a conﬁguration of a given design entity, both the conﬁguration declaration and the
corresponding entity declaration must reside in the same library.
If a simple name appears at the end of a conﬁguration declaration, it must repeat the identiﬁer of the
conﬁguration declaration.
NOTES

300

1—A conﬁguration declaration achieves its effect entirely through elaboration (see Clause 12). There are no behavioral
semantics associated with a conﬁguration declaration.
2—A given conﬁguration may be used in the deﬁnition of another, more complex conﬁguration.

Examples:
—

An architecture of a microprocessor:
architecture Structure_View of Processor is
component ALU port ( ••• ); end component;
component MUX port ( ••• ); end component;
component Latch port ( ••• ); end component;
begin
A1: ALU port map ( ••• ) ;
M1: MUX port map ( ••• ) ;
M2: MUX port map ( ••• ) ;
M3: MUX port map ( ••• ) ;
L1: Latch port map ( ••• ) ;
L2: Latch port map ( ••• ) ;
end Structure_View ;

305

310

315

12

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

—

320

325

330

IEEE
Std 1076, 2000 Edition

A conﬁguration of the microprocessor:
library TTL, Work ;
conﬁguration V4_27_87 of Processor is
use Work.all ;
for Structure_View
for A1: ALU
use conﬁguration TTL.SN74LS181 ;
end for ;
for M1,M2,M3: MUX
use entity Multiplex4 (Behavior) ;
end for ;
for all: Latch
— use defaults
end for ;
end for ;
end conﬁguration V4_27_87 ;

1.3.1 Block conﬁguration

335

340

A block conﬁguration deﬁnes the conﬁguration of a block. Such a block may be either an internal block
deﬁned by a block statement or an external block deﬁned by a design entity. If the block is an internal block,
the deﬁning block statement may be either an explicit block statement or an implicit block statement that is
itself deﬁned by a generate statement.
block_conﬁguration ::=
for block_speciﬁcation
{ use_clause }
{ conﬁguration_item }
end for ;
block_speciﬁcation ::=
architecture_name
| block_statement_label
| generate_statement_label [ ( index_speciﬁcation ) ]

345

350

index_speciﬁcation ::=
discrete_range
| static_expression
conﬁguration_item ::=
block_conﬁguration
| component_conﬁguration
The block speciﬁcation identiﬁes the internal or external block to which this block conﬁguration applies.

355

If a block conﬁguration appears immediately within a conﬁguration declaration, then the block speciﬁcation
of that block conﬁguration must be an architecture name, and that architecture name must denote a design
entity body whose interface is deﬁned by the entity declaration denoted by the entity name of the enclosing
conﬁguration declaration.
If a block conﬁguration appears immediately within a component conﬁguration, then the corresponding
components must be fully bound (see 5.2.1.1), the block speciﬁcation of that block conﬁguration must be an
architecture name, and that architecture name must denote the same architecture body as that to which the
corresponding components are bound.

Copyright © 2000 IEEE. All rights reserved.

13

IEEE
Std 1076, 2000 Edition

360

365

370

375

380

385

IEEE STANDARD VHDL

If a block conﬁguration appears immediately within another block conﬁguration, then the block
speciﬁcation of the contained block conﬁguration must be a block statement or generate statement label, and
the label must denote a block statement or generate statement that is contained immediately within the block
denoted by the block speciﬁcation of the containing block conﬁguration.
If the scope of a declaration (see 10.2) includes the end of the declarative part of a block corresponding to a
given block conﬁguration, then the scope of that declaration extends to each conﬁguration item contained in
that block conﬁguration, with the exception of block conﬁgurations that conﬁgure external blocks. Similarly,
if a declaration is visible (either directly or by selection) at the end of the declarative part of a block
corresponding to a given block conﬁguration, then the declaration is visible in each conﬁguration item
contained in that block conﬁguration, with the exception of block conﬁgurations that conﬁgure external
blocks. Additionally, if a given declaration is a homograph of a declaration that a use clause in the block
conﬁguration makes potentially directly visible, then the given declaration is not directly visible in the block
conﬁguration or any of its conﬁguration items. See 10.3.
For any name that is the label of a block statement appearing immediately within a given block, a
corresponding block conﬁguration may appear as a conﬁguration item immediately within a block conﬁguration corresponding to the given block. For any collection of names that are labels of instances of the same
component appearing immediately within a given block, a corresponding component conﬁguration may
appear as a conﬁguration item immediately within a block conﬁguration corresponding to the given block.
For any name that is the label of a generate statement immediately within a given block, one or more corresponding block conﬁgurations may appear as conﬁguration items immediately within a block conﬁguration
corresponding to the given block. Such block conﬁgurations apply to implicit blocks generated by that generate statement. If such a block conﬁguration contains an index speciﬁcation that is a discrete range, then the
block conﬁguration applies to those implicit block statements that are generated for the speciﬁed range of
values of the corresponding generate parameter; the discrete range has no signiﬁcance other than to deﬁne
the set of generate statement parameter values implied by the discrete range. If such a block conﬁguration
contains an index speciﬁcation that is a static expression, then the block conﬁguration applies only to the
implicit block statement generated for the speciﬁed value of the corresponding generate parameter. If no
index speciﬁcation appears in such a block conﬁguration, then it applies to exactly one of the following sets
of blocks:
—

All implicit blocks (if any) generated by the corresponding generate statement, if and only if the
corresponding generate statement has a generation scheme including the reserved word for

—

The implicit block generated by the corresponding generate statement, if and only if the corresponding generate statement has a generation scheme including the reserved word if and if the condition in
the generate scheme evaluates to TRUE

—

No implicit or explicit blocks, if and only if the corresponding generate statement has a generation
scheme including the reserved word if and the condition in the generate scheme evaluates to FALSE.

390

395

If the block speciﬁcation of a block conﬁguration contains a generate statement label, and if this label
contains an index speciﬁcation, then it is an error if the generate statement denoted by the label does not
have a generation scheme including the reserved word for.

400

405

Within a given block conﬁguration, whether implicit or explicit, an implicit block conﬁguration is assumed
to appear for any block statement that appears within the block corresponding to the given block
conﬁguration, if no explicit block conﬁguration appears for that block statement. Similarly, an implicit
component conﬁguration is assumed to appear for each component instance that appears within the block
corresponding to the given block conﬁguration, if no explicit component conﬁguration appears for that
instance. Such implicit conﬁguration items are assumed to appear following all explicit conﬁguration items
in the block conﬁguration.

14

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

It is an error if, in a given block conﬁguration, more than one conﬁguration item is deﬁned for the same
block or component instance.
NOTES
410

415

1—As a result of the rules described in the preceding paragraphs and in Clause 10, a simple name that is visible by
selection at the end of the declarative part of a given block is also visible by selection within any conﬁguration item
contained in a corresponding block conﬁguration. If such a name is directly visible at the end of the given block declarative part, it will likewise be directly visible in the corresponding conﬁguration items, unless a use clause for a different
declaration with the same simple name appears in the corresponding conﬁguration declaration, and the scope of that use
clause encompasses all or part of those conﬁguration items. If such a use clause appears, then the name will be directly
visible within the corresponding conﬁguration items except at those places that fall within the scope of the additional use
clause (at which places neither name will be directly visible).
2—If an implicit conﬁguration item is assumed to appear within a block conﬁguration, that implicit conﬁguration item
will never contain explicit conﬁguration items.

420

3—If the block speciﬁcation in a block conﬁguration speciﬁes a generate statement label, and if this label contains an
index speciﬁcation that is a discrete range, then the direction speciﬁed or implied by the discrete range has no signiﬁcance other than to deﬁne, together with the bounds of the range, the set of generate statement parameter values denoted
by the range. Thus, the following two block conﬁgurations are equivalent:
for Adders(31 downto 0) ••• end for;
for Adders(0 to 31) ••• end for;

425

4—A block conﬁguration may appear immediately within a conﬁguration declaration only if the entity declaration
denoted by the entity name of the enclosing conﬁguration declaration has associated architectures. Furthermore, the
block speciﬁcation of the block conﬁguration must denote one of these architectures.

Examples:
—

for ShiftRegStruct
-- Conﬁguration items
-- for blocks and components
-- within ShiftRegStruct.
end for ;

430

435

440

A block conﬁguration for a design entity:

—

-- An architecture name.

A block conﬁguration for a block statement:
for B1
-- Conﬁguration items
-- for blocks and components
-- within block B1.
end for ;

-- A block label.

1.3.2 Component conﬁguration
A component conﬁguration deﬁnes the conﬁguration of one or more component instances in a
corresponding block.

445

component_conﬁguration ::=
for component_speciﬁcation
[ binding_indication ; ]
[ block_conﬁguration ]
end for ;

Copyright © 2000 IEEE. All rights reserved.

15

IEEE
Std 1076, 2000 Edition

450

IEEE STANDARD VHDL

The component speciﬁcation (see 5.2) identiﬁes the component instances to which this component
conﬁguration applies. A component conﬁguration that appears immediately within a given block
conﬁguration applies to component instances that appear immediately within the corresponding block.
It is an error if two component conﬁgurations apply to the same component instance.

455

If the component conﬁguration contains a binding indication (see 5.2.1), then the component conﬁguration
implies a conﬁguration speciﬁcation for the component instances to which it applies. This implicit
conﬁguration speciﬁcation has the same component speciﬁcation and binding indication as that of the
component conﬁguration.

460

If a given component instance is unbound in the corresponding block, then any explicit component conﬁguration for that instance that does not contain an explicit binding indication will contain an implicit, default
binding indication (see 5.2.2). Similarly, if a given component instance is unbound in the corresponding
block, then any implicit component conﬁguration for that instance will contain an implicit, default binding
indication.
It is an error if a component conﬁguration contains an explicit block conﬁguration and the component
conﬁguration does not bind all identiﬁed component instances to the same design entity.

465

Within a given component conﬁguration, whether implicit or explicit, an implicit block conﬁguration is
assumed for the design entity to which the corresponding component instance is bound, if no explicit block
conﬁguration appears and if the corresponding component instance is fully bound.
Examples:
—

A component conﬁguration with binding indication:
for all: IOPort
use entity StdCells.PadTriState4 (DataFlow)
port map (Pout=>A, Pin=>B, IO=>Dir, Vdd=>Pwr, Gnd=>Gnd) ;
end for ;

470

—

A component conﬁguration containing block conﬁgurations:

for D1: DSP
for DSP_STRUCTURE
-- Binding speciﬁed in design entity or else defaults.
for Filterer
-- Conﬁguration items for ﬁltering components.
end for ;
for Processor
-- Conﬁguration items for processing components.
end for ;
end for ;
end for ;

475

480

16

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

485

490

495

500

IEEE
Std 1076, 2000 Edition

NOTE—The requirement that all component instances corresponding to a block conﬁguration be bound to the same
design entity makes the following conﬁguration illegal:
architecture A of E is
component C is end component C;
for L1: C use entity E1(X);
for L2: C use entity E2(X);
begin
L1: C;
L2: C;
end architecture A;
conﬁguration Illegal of Work.E is
for A
for all: C
for X
-- Does not apply to the same design entity in all instances of C.
•••
end for; -- X
end for; -- C
end for; -- A
end conﬁguration Illegal ;

Copyright © 2000 IEEE. All rights reserved.

17

IEEE
Std 1076, 2000 Edition

18

IEEE STANDARD VHDL

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

2. Subprograms and packages
Subprograms deﬁne algorithms for computing values or exhibiting behavior. They may be used as computational resources to convert between values of different types, to deﬁne the resolution of output values driving
a common signal, or to deﬁne portions of a process. Packages provide a means of deﬁning these and other
resources in a way that allows different design units to share the same declarations.
5

10

There are two forms of subprograms: procedures and functions. A procedure call is a statement; a function
call is an expression and returns a value. Certain functions, designated pure functions, return the same value
each time they are called with the same values as actual parameters; the remainder, impure functions, may
return a different value each time they are called, even when multiple calls have the same actual parameter
values. In addition, impure functions can update objects outside of their scope and can access a broader class
of values than can pure functions. The deﬁnition of a subprogram can be given in two parts: a subprogram
declaration deﬁning its calling conventions, and a subprogram body deﬁning its execution.
Packages may also be deﬁned in two parts. A package declaration deﬁnes the visible contents of a package;
a package body provides hidden details. In particular, a package body contains the bodies of any subprograms declared in the package declaration.

2.1 Subprogram declarations
15

A subprogram declaration declares a procedure or a function, as indicated by the appropriate reserved word.
subprogram_declaration ::=
subprogram_speciﬁcation ;

20

subprogram_speciﬁcation ::=
procedure designator [ ( formal_parameter_list ) ]
| [ pure | impure ] function designator [ ( formal_parameter_list ) ]
return type_mark
designator ::= identiﬁer | operator_symbol
operator_symbol ::= string_literal

25

30

The speciﬁcation of a procedure speciﬁes its designator and its formal parameters (if any). The speciﬁcation
of a function speciﬁes its designator, its formal parameters (if any), the subtype of the returned value (the
result subtype), and whether or not the function is pure. A function is impure if its speciﬁcation contains the
reserved word impure; otherwise, it is said to be pure. A procedure designator is always an identiﬁer. A
function designator is either an identiﬁer or an operator symbol. A designator that is an operator symbol is
used for the overloading of an operator (see 2.3.1). The sequence of characters represented by an operator
symbol must be an operator belonging to one of the classes of operators deﬁned in 7.2. Extra spaces are not
allowed in an operator symbol, and the case of letters is not signiﬁcant.
NOTES
1—All subprograms can be called recursively.

35

2—The restrictions on pure functions are enforced even when the function appears within a protected type. That is, pure
functions whose body appears in the protected type body may not directly reference variables declared immediately
within the declarative region associated with the protected type. However, impure functions and procedures whose
bodies appear in the protected type body may make such references. Such references are made only when the referencing subprogram has exclusive access to the declarative region associated with the protected type.

Copyright © 2000 IEEE. All rights reserved.

19

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

2.1.1 Formal parameters
The formal parameter list in a subprogram speciﬁcation deﬁnes the formal parameters of the subprogram.
formal_parameter_list ::= parameter_interface_list

40

Formal parameters of subprograms may be constants, variables, signals, or ﬁles. In the ﬁrst three cases, the
mode of a parameter determines how a given formal parameter may be accessed within the subprogram. The
mode of a formal parameter, together with its class, may also determine how such access is implemented. In
the fourth case, that of ﬁles, the parameters have no mode.
45

50

For those parameters with modes, the only modes that are allowed for formal parameters of a procedure are
in, inout, and out. If the mode is in and no object class is explicitly speciﬁed, constant is assumed. If the
mode is inout or out, and no object class is explicitly speciﬁed, variable is assumed.
For those parameters with modes, the only mode that is allowed for formal parameters of a function is the
mode in (whether this mode is speciﬁed explicitly or implicitly). The object class must be constant, signal,
or ﬁle. If no object class is explicitly given, constant is assumed.
In a subprogram call, the actual designator (see 4.3.2.2) associated with a formal parameter of class signal
must be a signal. The actual designator associated with a formal of class variable must be a variable. The
actual designator associated with a formal of class constant must be an expression. The actual designator
associated with a formal of class ﬁle must be a ﬁle.

55

NOTE—Attributes of an actual are never passed into a subprogram. References to an attribute of a formal parameter are
legal only if that formal has such an attribute. Such references retrieve the value of the attribute associated with the
formal.

2.1.1.1 Constant and variable parameters

60

65

70

75

For parameters of class constant or variable, only the values of the actual or formal are transferred into or
out of the subprogram call. The manner of such transfers, and the accompanying access privileges that are
granted for constant and variable parameters, are described in this subclause.
For a nonforeign subprogram having a parameter of a scalar type or an access type, the parameter is passed
by copy. At the start of each call, if the mode is in or inout, the value of the actual parameter is copied into
the associated formal parameter; it is an error if, after applying any conversion function or type conversion
present in the actual part of the applicable association element (see 4.3.2.2), the value of the actual parameter
does not belong to the subtype denoted by the subtype indication of the formal. After completion of the
subprogram body, if the mode is inout or out, the value of the formal parameter is copied back into the associated actual parameter; it is similarly an error if, after applying any conversion function or type conversion
present in the formal part of the applicable association element, the value of the formal parameter does not
belong to the subtype denoted by the subtype indication of the actual.
For a nonforeign subprogram having a parameter whose type is an array or record, an implementation may
pass parameter values by copy, as for scalar types. If a parameter of mode out is passed by copy, then the
range of each index position of the actual parameter is copied in, and likewise for its subelements or slices.
Alternatively, an implementation may achieve these effects by reference; that is, by arranging that every use
of the formal parameter (to read or update its value) be treated as a use of the associated actual parameter
throughout the execution of the subprogram call. The language does not deﬁne which of these two mechanisms is to be adopted for parameter passing, nor whether different calls to the same subprogram are to use
the same mechanism. The execution of a subprogram is erroneous if its effect depends on which mechanism
is selected by the implementation.

20

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

80

IEEE
Std 1076, 2000 Edition

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.

90

For a formal parameter of a constrained array subtype of mode in or inout, it is an error if the value of the
associated actual parameter (after application of any conversion function or type conversion present in the
actual part) does not contain a matching element for each element of the formal. For a formal parameter
whose declaration contains a subtype indication denoting an unconstrained array type, the subtype of the
formal in any call to the subprogram is taken from the actual associated with that formal in the call to the
subprogram. It is also an error if, in either case, the value of each element of the actual array (after applying
any conversion function or type conversion present in the actual part) does not belong to the element subtype
of the formal. If the formal parameter is of mode out or inout, it is also an error if, at the end of the subprogram call, the value of each element of the formal (after applying any conversion function or type conversion
present in the formal part) does not belong to the element subtype of the actual.

95

NOTE—For parameters of array and record types, the parameter passing rules imply that if no actual parameter of such
a type is accessible by more than one path, then the effect of a subprogram call is the same whether or not the implementation uses copying for parameter passing. If, however, there are multiple access paths to such a parameter (for example,
if another formal parameter is associated with the same actual parameter), then the value of the formal is undeﬁned after
updating the actual other than by updating the formal. A description using such an undeﬁned value is erroneous.

85

2.1.1.2 Signal parameter
For a formal parameter of class signal, references to the signal, the driver of the signal, or both, are passed
into the subprogram call.

100

For a signal parameter of mode in or inout, the actual signal is associated with the corresponding formal signal parameter at the start of each call. Thereafter, during the execution of the subprogram body, a reference
to the formal signal parameter within an expression is equivalent to a reference to the actual signal.
It is an error if signal-valued attributes 'STABLE, 'QUIET, 'TRANSACTION, and 'DELAYED of formal signal parameters of any mode are read within a subprogram.

105

A process statement contains a driver for each actual signal associated with a formal signal parameter of
mode out or inout in a subprogram call. Similarly, a subprogram contains a driver for each formal signal
parameter of mode out or inout declared in its subprogram speciﬁcation.
For a signal parameter of mode inout or out, the driver of an actual signal is associated with the corresponding driver of the formal signal parameter at the start of each call. Thereafter, during the execution of the
subprogram body, an assignment to the driver of a formal signal parameter is equivalent to an assignment to
the driver of the actual signal.

110

115

120

If an actual signal is associated with a signal parameter of any mode, the actual must be denoted by a static
signal name. It is an error if a conversion function or type conversion appears in either the formal part or the
actual part of an association element that associates an actual signal with a formal signal parameter.
If an actual signal is associated with a signal parameter of any mode, and if the type of the formal is a scalar
type, then it is an error if the bounds and direction of the subtype denoted by the subtype indication of the
formal are not identical to the bounds and direction of the subtype denoted by the subtype indication of the
actual.
If an actual signal is associated with a formal signal parameter, and if the formal is of a constrained array
subtype, then it is an error if the actual does not contain a matching element for each element of the formal.
If an actual signal is associated with a formal signal parameter, and if the subtype denoted by the subtype
indication of the declaration of the formal is an unconstrained array type, then the subtype of the formal in
any call to the subprogram is taken from the actual associated with that formal in the call to the subprogram.

Copyright © 2000 IEEE. All rights reserved.

21

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

It is also an error if the mode of the formal is in or inout and if the value of each element of the actual array
does not belong to the element subtype of the formal.

125

130

A formal signal parameter is a guarded signal if and only if it is associated with an actual signal that is a
guarded signal. It is an error if the declaration of a formal signal parameter includes the reserved word bus
(see 4.3.2).
NOTE—It is a consequence of the preceding rules that a procedure with an out or inout signal parameter called by a
process does not have to complete in order for any assignments to that signal parameter within the procedure to take
effect. Assignments to the driver of a formal signal parameter are equivalent to assignments directly to the actual driver
contained in the process calling the procedure.

2.1.1.3 File parameters

135

For parameters of class ﬁle, references to the actual ﬁle are passed into the subprogram. No particular
parameter-passing mechanism is deﬁned by the language, but a reference to the formal parameter must be
equivalent to a reference to the actual parameter. It is an error if an association element associates an actual
with a formal parameter of a ﬁle type and that association element contains a conversion function or type
conversion. It is also an error if a formal of a ﬁle type is associated with an actual that is not of a ﬁle type.

140

At the beginning of a given subprogram call, a ﬁle parameter is open (see 3.4.1) if and only if the actual ﬁle
object associated with the given parameter in a given subprogram call is also open. Similarly, at the beginning of a given subprogram call, both the access mode of and external ﬁle associated with (see 3.4.1) an
open ﬁle parameter are the same as, respectively, the access mode of and the external ﬁle associated with the
actual ﬁle object associated with the given parameter in the subprogram call.

145

At the completion of the execution of a given subprogram call, the actual ﬁle object associated with a given
ﬁle parameter is open if and only if the formal parameter is also open. Similarly, at the completion of the
execution of a given subprogram call, the access mode of and the external ﬁle associated with an open actual
ﬁle object associated with a given ﬁle parameter are the same as, respectively, the access mode of and the
external ﬁle associated with the associated formal parameter.

2.2 Subprogram bodies
A subprogram body speciﬁes the execution of a subprogram.
subprogram_body ::=
subprogram_speciﬁcation is
subprogram_declarative_part
begin
subprogram_statement_part
end [ subprogram_kind ] [ designator ] ;

150

subprogram_declarative_part ::=
{ subprogram_declarative_item }

22

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

155

160

165

170

IEEE
Std 1076, 2000 Edition

subprogram_declarative_item ::=
subprogram_declaration
| subprogram_body
| type_declaration
| subtype_declaration
| constant_declaration
| variable_declaration
| ﬁle_declaration
| alias_declaration
| attribute_declaration
| attribute_speciﬁcation
| use_clause
| group_template_declaration
| group_declaration
subprogram_statement_part ::=
{ sequential_statement }
subprogram_kind ::= procedure | function

175

The declaration of a subprogram is optional. In the absence of such a declaration, the subprogram
speciﬁcation of the subprogram body acts as the declaration. For each subprogram declaration, there shall be
a corresponding body. If both a declaration and a body are given, the subprogram speciﬁcation of the body
shall conform (see 2.7) to the subprogram speciﬁcation of the declaration. Furthermore, both the declaration
and the body must occur immediately within the same declarative region (see 10.1).
If a subprogram kind appears at the end of a subprogram body, it must repeat the reserved word given in the
subprogram speciﬁcation. If a designator appears at the end of a subprogram body, it must repeat the
designator of the subprogram.

180

185

190

195

It is an error if a variable declaration in a subprogram declarative part declares a shared variable. (See 4.3.1.3
and 8.1.4.)
A foreign subprogram is one that is decorated with the attribute 'FOREIGN, deﬁned in package
STANDARD (see 14.2). The STRING value of the attribute may specify implementation-dependent information about the foreign subprogram. Foreign subprograms may have non-VHDL implementations. An
implementation may place restrictions on the allowable modes, classes, and types of the formal parameters
to a foreign subprogram; such restrictions may include restrictions on the number and allowable order of the
parameters.
Excepting foreign subprograms, the algorithm performed by a subprogram is deﬁned by the sequence of
statements that appears in the subprogram statement part. For a foreign subprogram, the algorithm
performed is implementation deﬁned.
The execution of a subprogram body is invoked by a subprogram call. For this execution, after establishing
the association between the formal and actual parameters, the sequence of statements of the body is executed
if the subprogram is not a foreign subprogram; otherwise, an implementation-deﬁned action occurs. Upon
completion of the body or implementation-dependent action, if exclusive access to an object of a protected
type was granted during elaboration of the declaration of the subprogram (see 12.5), the exclusive access is
rescinded. Then, return is made to the caller (and any necessary copying back of formal to actual parameters
occurs).
A process or a subprogram is said to be a parent of a given subprogram S if that process or subprogram
contains a procedure call or function call for S or for a parent of S.

Copyright © 2000 IEEE. All rights reserved.

23

IEEE
Std 1076, 2000 Edition

200

205

IEEE STANDARD VHDL

An explicit signal is a signal other than an implicit signal GUARD or other than one of the implicit signals
deﬁned by the predeﬁned attributes 'DELAYED, 'STABLE, 'QUIET, or 'TRANSACTION. The explicit
ancestor of an implicit signal is found as follows. The implicit signal GUARD has no explicit ancestor. An
explicit ancestor of an implicit signal deﬁned by the predeﬁned attributes 'DELAYED, 'STABLE, 'QUIET, or
'TRANSACTION is the signal found by recursively examining the preﬁx of the attribute. If the preﬁx
denotes an explicit signal, a slice, or a member (see Clause 3) of an explicit signal, then that is the explicit
ancestor of the implicit signal. Otherwise, if the preﬁx is one of the implicit signals deﬁned by the predeﬁned
attributes 'DELAYED, 'STABLE, 'QUIET, or 'TRANSACTION, this rule is recursively applied. If the preﬁx
is an implicit signal GUARD, then the signal has no explicit ancestor.

215

If a pure function subprogram is a parent of a given procedure and if that procedure contains a reference to
an explicitly declared signal or variable object, or a slice or subelement (or slice thereof) of an explicit
signal, then that object must be declared within the declarative region formed by the function (see 10.1) or
within the declarative region formed by the procedure; this rule also holds for the explicit ancestor, if any, of
an implicit signal and also for the implicit signal GUARD. If a pure function is the parent of a given procedure, then that procedure must not contain a reference to an explicitly declared ﬁle object (see 4.3.1.4) or to
a shared variable (see 4.3.1.3).

220

Similarly, if a pure function subprogram contains a reference to an explicitly declared signal or variable
object, or a slice or subelement (or slice thereof) of an explicit signal, then that object must be declared
within the declarative region formed by the function; this rule also holds for the explicit ancestor, if any, of
an implicit signal and also for the implicit signal GUARD. A pure function must not contain a reference to
an explicitly declared ﬁle object.

210

A pure function must not be the parent of an impure function.

225

The rules of the preceding four paragraphs apply to all pure function subprograms. For pure functions that
are not foreign subprograms, violations of any of these rules are errors. However, since implementations
cannot in general check that such rules hold for pure function subprograms that are foreign subprograms, a
description calling pure foreign function subprograms not adhering to these rules is erroneous.
Example:
—

The declaration of a foreign function subprogram:

package P is
function F return INTEGER;
attribute FOREIGN of F: function is "implementation-dependent information";
end package P;

230

NOTES
1—It follows from the visibility rules that a subprogram declaration must be given if a call of the subprogram occurs
textually before the subprogram body, and that such a declaration must occur before the call itself.
235

2—The preceding rules concerning pure function subprograms, together with the fact that function parameters may only
be of mode in, imply that a pure function has no effect other than the computation of the returned value. Thus, a pure
function invoked explicitly as part of the elaboration of a declaration, or one invoked implicitly as part of the simulation
cycle, is guaranteed to have no effect on other objects in the description.
3—VHDL does not deﬁne the parameter-passing mechanisms for foreign subprograms.

240

4—The declarative parts and statement parts of subprograms decorated with the 'FOREIGN attribute are subject to
special elaboration rules. See 12.3 and 12.4.5.
5—A pure function subprogram may not reference a shared variable. This prohibition exists because a shared variable
may not be declared in a subprogram declarative part and a pure function may not reference any variable declared outside of its declarative region.

24

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

245

IEEE
Std 1076, 2000 Edition

6—A subprogram containing a wait statement must not have an ancestor that is a subprogram declared within either a
protected type declaration or a protected type body.

2.3 Subprogram overloading

250

255

Two formal parameter lists are said to have the same parameter type proﬁle if and only if they have the same
number of parameters, and if at each parameter position the corresponding parameters have the same base
type. Two subprograms are said to have the same parameter and result type proﬁle if and only if both have
the same parameter type proﬁle, and if either both are functions with the same result base type or neither of
the two is a function.
A given subprogram designator can be used in several subprogram speciﬁcations. The subprogram designator is then said to be overloaded; the designated subprograms are also said to be overloaded and to overload
each other. If two subprograms overload each other, one of them can hide the other only if both subprograms
have the same parameter and result type proﬁle.
A call to an overloaded subprogram is ambiguous (and therefore is an error) if the name of the subprogram,
the number of parameter associations, the types and order of the actual parameters, the names of the formal
parameters (if named associations are used), and the result type (for functions) are not sufﬁcient to identify
exactly one (overloaded) subprogram speciﬁcation.

260

Similarly, a reference to an overloaded resolution function name in a subtype indication is ambiguous (and is
therefore an error) if the name of the function, the number of formal parameters, the result type, and the relationships between the result type and the types of the formal parameters (as deﬁned in 2.4) are not sufﬁcient
to identify exactly one (overloaded) subprogram speciﬁcation.
Examples:

265

—

Declarations of overloaded subprograms:
procedure Dump(F: inout Text; Value: Integer);
procedure Dump(F: inout Text; Value: String);
procedure Check (Setup: Time; signal D: Data; signal C: Clock);
procedure Check (Hold: Time; signal C: Clock; signal D: Data);

270

—

Calls to overloaded subprograms:
Dump (Sys_Output, 12);
Dump (Sys_Error, "Actual output does not match expected output");
Check (Setup=>10 ns, D=>DataBus, C=>Clk1);
Check (Hold=>5 ns, D=>DataBus, C=>Clk2);
Check (15 ns, DataBus, Clk) ;
-- Ambiguous if the base type of DataBus is the same type as the base type of Clk.

275

NOTES
1—The notion of parameter and result type proﬁle does not include parameter names, parameter classes, parameter
modes, parameter subtypes, or default expressions or their presence or absence.
280

2—Ambiguities may (but need not) arise when actual parameters of the call of an overloaded subprogram are
themselves overloaded function calls, literals, or aggregates. Ambiguities may also (but need not) arise when several
overloaded subprograms belonging to different packages are visible. These ambiguities can usually be solved in two
ways: qualiﬁed expressions can be used for some or all actual parameters and for the result, if any; or the name of the
subprogram can be expressed more explicitly as an expanded name (see 6.3).

Copyright © 2000 IEEE. All rights reserved.

25

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

2.3.1 Operator overloading
285

290

The declaration of a function whose designator is an operator symbol is used to overload an operator. The
sequence of characters of the operator symbol must be one of the operators in the operator classes deﬁned in
7.2.
The subprogram speciﬁcation of a unary operator must have a single parameter. The subprogram
speciﬁcation of a binary operator must have two parameters; for each use of this operator, the ﬁrst parameter
is associated with the left operand, and the second parameter is associated with the right operand.
For each of the operators “+” and “–”, overloading is allowed both as a unary operator and as a binary
operator.
NOTES

295

1—Overloading of the equality operator does not affect the selection of choices in a case statement in a selected signal
assignment statement, nor does it have an affect on the propagation of signal values.
2—A user-deﬁned operator that has the same designator as a short-circuit operator (i.e., a user-deﬁned operator that
overloads the short-circuit operator) is not invoked in a short-circuit manner. Speciﬁcally, calls to the user-deﬁned operator always evaluate both arguments prior to the execution of the function.

300

3—Functions that overload operator symbols may also be called using function call notation rather than operator
notation. This statement is also true of the predeﬁned operators themselves.

Examples:
type MVL is ('0', '1', 'Z', 'X') ;
function "and" (Left, Right: MVL) return MVL ;
function "or" (Left, Right: MVL) return MVL ;
function "not" (Value: MVL) return MVL ;

305

signal Q,R,S: MVL ;
Q <= 'X' or '1';
R <= "or" ('0','Z');
S <= (Q and R) or not S;
2.3.2 Signatures
310

A signature distinguishes between overloaded subprograms and overloaded enumeration literals based on
their parameter and result type proﬁles. A signature can be used in an attribute name, entity designator, or
alias declaration.
signature ::= [ [ type_mark { , type_mark } ] [ return type_mark ] ]

315

(Note that the initial and terminal brackets are part of the syntax of signatures and do not indicate that the
entire right-hand side of the production is optional.) A signature is said to match the parameter and the result
type proﬁle of a given subprogram if, and only if, all of the following conditions hold:

320

26

—

The number of type marks prior to the reserved word return, if any, matches the number of formal
parameters of the subprogram.

—

At each parameter position, the base type denoted by the type mark of the signature is the same as the
base type of the corresponding formal parameter of the subprogram.

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

—

325

IEEE
Std 1076, 2000 Edition

If the reserved word return is present, the subprogram is a function and the base type of the type
mark following the reserved word in the signature is the same as the base type of the return type of
the function, or the reserved word return is absent and the subprogram is a procedure.

Similarly, a signature is said to match the parameter and result type proﬁle of a given enumeration literal if
the signature matches the parameter and result type proﬁle of the subprogram equivalent to the enumeration
literal deﬁned in 3.1.1.
Example:

330

attribute BuiltIn of "or" [MVL, MVL return MVL]: function is TRUE;
-- Because of the presence of the signature, this attribute speciﬁcation
-- decorates only the "or" function deﬁned in the previous clause.
attribute Mapping of JMP [return OpCode] : literal is "001";

2.4 Resolution functions

335

340

345

350

A resolution function is a function that deﬁnes how the values of multiple sources of a given signal are to be
resolved into a single value for that signal. Resolution functions are associated with signals that require
resolution by including the name of the resolution function in the declaration of the signal or in the declaration of the subtype of the signal. A signal with an associated resolution function is called a resolved signal
(see 4.3.1.2).
A resolution function must be a pure function (see 2.1); moreover, it must have a single input parameter of
class constant that is a one-dimensional, unconstrained array whose element type is that of the resolved
signal. The type of the return value of the function must also be that of the signal. Errors occur at the place of
the subtype indication containing the name of the resolution function if any of these checks fail (see 4.2).
The resolution function associated with a resolved signal determines the resolved value of the signal as a
function of the collection of inputs from its multiple sources. If a resolved signal is of a composite type, and
if subelements of that type also have associated resolution functions, such resolution functions have no effect
on the process of determining the resolved value of the signal. It is an error if a resolved signal has more
connected sources than the number of elements in the index type of the unconstrained array type used to
deﬁne the parameter of the corresponding resolution function.
Resolution functions are implicitly invoked during each simulation cycle in which corresponding resolved
signals are active (see 12.6.1). Each time a resolution function is invoked, it is passed an array value, each
element of which is determined by a corresponding source of the resolved signal, but excluding those
sources that are drivers whose values are determined by null transactions (see 8.4.1). Such drivers are said to
be off. For certain invocations (speciﬁcally, those involving the resolution of sources of a signal declared
with the signal kind bus), a resolution function may thus be invoked with an input parameter that is a null
array; this occurs when all sources of the bus are drivers, and they are all off. In such a case, the resolution
function returns a value representing the value of the bus when no source is driving it.

Copyright © 2000 IEEE. All rights reserved.

27

IEEE
Std 1076, 2000 Edition

355

IEEE STANDARD VHDL

Example:
function WIRED_OR (Inputs: BIT_VECTOR) return BIT is
constant FloatValue: BIT := '0';
begin
if Inputs'Length = 0 then
-- This is a bus whose drivers are all off.
return FloatValue;
else
for I in Inputs'Range loop
if Inputs(I) = '1' then
return '1';
end if;
end loop;
return '0';
end if;
end function WIRED_OR;

360

365

370

2.5 Package declarations
A package declaration deﬁnes the interface to a package. The scope of a declaration within a package can be
extended to other design units.
package_declaration ::=
package identiﬁer is
package_declarative_part
end [ package ] [ package_simple_name ] ;

375

package_declarative_part ::=
{ package_declarative_item }
package_declarative_item ::=
subprogram_declaration
| type_declaration
| subtype_declaration
| constant_declaration
| signal_declaration
| shared_variable_declaration
| ﬁle_declaration
| alias_declaration
| component_declaration
| attribute_declaration
| attribute_speciﬁcation
| disconnection_speciﬁcation
| use_clause
| group_template_declaration
| group_declaration

380

385

390

395

If a simple name appears at the end of the package declaration, it must repeat the identiﬁer of the package
declaration.
If a package declarative item is a type declaration (i.e., a full type declaration whose type definition is a protected type definition), then that protected type definition must not be a protected type body.

28

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

400

Items declared immediately within a package declaration become visible by selection within a given design
unit wherever the name of that package is visible in the given unit. Such items may also be made directly
visible by an appropriate use clause (see 10.4).
NOTE—Not all packages will have a package body. In particular, a package body is unnecessary if no subprograms,
deferred constants, or protected type deﬁnitions are declared in the package declaration.

Examples:
405

410

—

package TimeConstants is
constant tPLH :
constant tPHL :
constant tPLZ :
constant tPZL :
constant tPHZ :
constant tPZH :
end TimeConstants ;
—

415

420

A package declaration that needs no package body:
Time := 10 ns;
Time := 12 ns;
Time := 7 ns;
Time := 8 ns;
Time := 8 ns;
Time := 9 ns;

A package declaration that needs a package body:

package TriState is
type Tri is ('0', '1', 'Z', 'E');
function BitVal (Value: Tri) return Bit ;
function TriVal (Value: Bit) return Tri;
type TriVector is array (Natural range <>) of Tri ;
function Resolve (Sources: TriVector) return Tri ;
end package TriState ;

2.6 Package bodies
A package body deﬁnes the bodies of subprograms and the values of deferred constants declared in the
interface to the package.

425

package_body ::=
package body package_simple_name is
package_body_declarative_part
end [ package body ] [ package_simple_name ] ;
package_body_declarative_part ::=
{ package_body_declarative_item }

430

435

440

package_body_declarative_item ::=
subprogram_declaration
| subprogram_body
| type_declaration
| subtype_declaration
| constant_declaration
| shared_variable_declaration
| ﬁle_declaration
| alias_declaration
| use_clause
| group_template_declaration
| group_declaration

Copyright © 2000 IEEE. All rights reserved.

29

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

The simple name at the start of a package body must repeat the package identiﬁer. If a simple name appears
at the end of the package body, it must be the same as the identiﬁer in the package declaration.

445

In addition to subprogram body and constant declarative items, a package body may contain certain other
declarative items to facilitate the deﬁnition of the bodies of subprograms declared in the interface. Items
declared in the body of a package cannot be made visible outside of the package body.

450

If a given package declaration contains a deferred constant declaration (see 4.3.1.1), then a constant declaration with the same identiﬁer must appear as a declarative item in the corresponding package body. This
object declaration is called the full declaration of the deferred constant. The subtype indication given in the
full declaration must conform to that given in the deferred constant declaration.

455

Within a package declaration that contains the declaration of a deferred constant, and within the body of that
package (before the end of the corresponding full declaration), the use of a name that denotes the deferred
constant is only allowed in the default expression for a local generic, local port, or formal parameter. The
result of evaluating an expression that references a deferred constant before the elaboration of the corresponding full declaration is not deﬁned by the language.
Example:
package body TriState is
function BitVal (Value: Tri) return Bit is
constant Bits : Bit_Vector := "0100";
begin
return Bits(Tri'Pos(Value));
end;

460

function TriVal (Value: Bit) return Tri is
begin
return Tri'Val(Bit'Pos(Value));
end;

465

function Resolve (Sources: TriVector) return Tri is
variable V: Tri := 'Z';
begin
for i in Sources'Range loop
if Sources(i) /= 'Z' then
if V = 'Z' then
V := Sources(i);
else
return 'E';
end if;
end if;
end loop;
return V;
end;

470

475

480

end package body TriState ;

30

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

2.7 Conformance rules
Whenever the language rules either require or allow the speciﬁcation of a given subprogram to be provided
in more than one place, the following variations are allowed at each place:
—
485

—

490

A numeric literal can be replaced by a different numeric literal if and only if both have the same
value.
A simple name can be replaced by an expanded name in which this simple name is the selector if,
and only if, at both places the meaning of the simple name is given by the same declaration.

Two subprogram speciﬁcations are said to conform if, apart from comments and the above allowed variations, both speciﬁcations are formed by the same sequence of lexical elements and if corresponding lexical
elements are given the same meaning by the visibility rules.
Conformance is likewise deﬁned for subtype indications in deferred constant declarations.
NOTES
1—A simple name can be replaced by an expanded name even if the simple name is itself the preﬁx of a selected name.
For example, Q.R can be replaced by P.Q.R if Q is declared immediately within P.

495

2—The subprogram speciﬁcation of an impure function is never conformant to a subprogram speciﬁcation of a pure
function.
3—The following speciﬁcations do not conform since they are not formed by the same sequence of lexical elements:

500

procedure P (X,Y : INTEGER)
procedure P (X: INTEGER; Y : INTEGER)
procedure P (X,Y : in INTEGER)

Copyright © 2000 IEEE. All rights reserved.

31

IEEE
Std 1076, 2000 Edition

32

IEEE STANDARD VHDL

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

3. Types
This clause describes the various categories of types that are provided by the language as well as those speciﬁc types that are predeﬁned. The declarations of all predeﬁned types are contained in package
STANDARD, the declaration of which appears in Clause 14.

5

A type is characterized by a set of values and a set of operations. The set of operations of a type includes the
explicitly declared subprograms that have a parameter or result of the type. The remaining operations of a
type are the basic operations and the predeﬁned operators (see 7.2). These operations are each implicitly
declared for a given type declaration immediately after the type declaration and before the next explicit
declaration, if any.
A basic operation is an operation that is inherent in one of the following:

10

—
—
—
—

15

—

20

25

30

35

An assignment (in assignment statements and initializations)
An allocator
A selected name, an indexed name, or a slice name
A qualiﬁcation (in a qualiﬁed expression), an explicit type conversion, a formal or actual part in the
form of a type conversion, or an implicit type conversion of a value of type universal_integer or
universal_real to the corresponding value of another numeric type
A numeric literal (for a universal type), the literal null (for an access type), a string literal, a bit string
literal, an aggregate, or a predeﬁned attribute

There are ﬁve classes of types. Scalar types are integer types, ﬂoating point types, physical types, and types
deﬁned by an enumeration of their values; values of these types have no elements. Composite types are array
and record types; values of these types consist of element values. Access types provide access to objects of a
given type. File types provide access to objects that contain a sequence of values of a given type. Protected
types provide atomic and exclusive access to variables accessible to multiple processes.
The set of possible values for an object of a given type can be subjected to a condition that is called a
constraint (the case where the constraint imposes no restriction is also included); a value is said to satisfy a
constraint if it satisﬁes the corresponding condition. A subtype is a type together with a constraint. A value is
said to belong to a subtype of a given type if it belongs to the type and satisﬁes the constraint; the given type
is called the base type of the subtype. A type is a subtype of itself; such a subtype is said to be unconstrained
(it corresponds to a condition that imposes no restriction). The base type of a type is the type itself.
The set of operations deﬁned for a subtype of a given type includes the operations deﬁned for the type;
however, the assignment operation to an object having a given subtype only assigns values that belong to the
subtype. Additional operations, such as qualiﬁcation (in a qualiﬁed expression) are implicitly deﬁned by a
subtype declaration.
The term subelement is used in this standard in place of the term element to indicate either an element, or an
element of another element or subelement. Where other subelements are excluded, the term element is used
instead.
A given type must not have a subelement whose type is the given type itself.
A member of an object is one of the following:

40

—
—
—

A slice of the object
A subelement of the object
A slice of a subelement of the object

Copyright © 2000 IEEE. All rights reserved.

33

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

The name of a class of types is used in this standard as a qualiﬁer for objects and values that have a type or
nature of the class considered. For example, the term array object is used for an object whose type is an
array type; similarly, the term access value is used for a value of an access type.
NOTE—The set of values of a subtype is a subset of the values of the base type. This subset need not be a proper subset.

3.1 Scalar types
45

Scalar types consist of enumeration types, integer types, physical types, and ﬂoating point types. Enumeration types and integer types are called discrete types. Integer types, ﬂoating point types, and physical types
are called numeric types. All scalar types are ordered; that is, all relational operators are predeﬁned for their
values. Each value of a discrete or physical type has a position number that is an integer value.
scalar_type_deﬁnition ::=
enumeration_type_deﬁnition | integer_type_deﬁnition
| ﬂoating_type_deﬁnition
| physical_type_deﬁnition

50

range_constraint ::= range range
range ::=
range_attribute_name
| simple_expression direction simple_expression

55

direction ::= to | downto
A range speciﬁes a subset of values of a scalar type. A range is said to be a null range if the speciﬁed subset
is empty.
60

65

70

The range L to R is called an ascending range; if L > R, then the range is a null range. The range L downto
R is called a descending range; if L < R, then the range is a null range. The smaller of L and R is called the
lower bound, and the larger, the upper bound, of the range. The value V is said to belong to the range if the
relations (lower bound <= V) and (V <= upper bound) are both true and the range is not a null range. The
operators >, <, and <= in the preceding deﬁnitions are the predeﬁned operators of the applicable scalar type.
For values of discrete or physical types, a value V1 is said to be to the left of a value V2 within a given range
if both V1 and V2 belong to the range and either the range is an ascending range and V2 is the successor of
V1, or the range is a descending range and V2 is the predecessor of V1. A list of values of a given range is in
left to right order if each value in the list is to the left of the next value in the list within that range, except for
the last value in the list.
If a range constraint is used in a subtype indication, the type of the expressions (likewise, of the bounds of a
range attribute) must be the same as the base type of the type mark of the subtype indication. A range
constraint is compatible with a subtype if each bound of the range belongs to the subtype or if the range constraint deﬁnes a null range. Otherwise, the range constraint is not compatible with the subtype.
The direction of a range constraint is the same as the direction of its range.
NOTE—Indexing and iteration rules use values of discrete types.

3.1.1 Enumeration types
75

An enumeration type deﬁnition deﬁnes an enumeration type.
enumeration_type_deﬁnition ::=
( enumeration_literal { , enumeration_literal } )
enumeration_literal ::= identiﬁer | character_literal

34

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

80

85

The identiﬁers and character literals listed by an enumeration type deﬁnition must be distinct within the
enumeration type deﬁnition. Each enumeration literal is the declaration of the corresponding enumeration
literal; for the purpose of determining the parameter and result type proﬁle of an enumeration literal, this
declaration is equivalent to the declaration of a parameterless function whose designator is the same as the
enumeration literal and whose result type is the same as the enumeration type.
An enumeration type is said to be a character type if at least one of its enumeration literals is a character
literal.
Each enumeration literal yields a different enumeration value. The predeﬁned order relations between
enumeration values follow the order of corresponding position numbers. The position number of the value of
the ﬁrst listed enumeration literal is zero; the position number for each additional enumeration literal is one
more than that of its predecessor in the list.

90

If the same identiﬁer or character literal is speciﬁed in more than one enumeration type deﬁnition, the corresponding literals are said to be overloaded. At any place where an overloaded enumeration literal occurs in
the text of a program, the type of the enumeration literal is determined according to the rules for overloaded
subprograms (see 2.3).
Each enumeration type deﬁnition deﬁnes an ascending range.

95

Examples:
type MULTI_LEVEL_LOGIC is (LOW, HIGH, RISING, FALLING, AMBIGUOUS) ;
type BIT is ('0','1') ;
type SWITCH_LEVEL is ('0','1','X') ;

-- Overloads '0' and '1'

3.1.1.1 Predeﬁned enumeration types

100

The predeﬁned enumeration types are CHARACTER, BIT, BOOLEAN, SEVERITY_LEVEL,
FILE_OPEN_KIND, and FILE_OPEN_STATUS.
The predeﬁned type CHARACTER is a character type whose values are the 256 characters of the ISO
8859-1: 1987 [B4]1 character set. Each of the 191 graphic characters of this character set is denoted by
the corresponding character literal.

105

The declarations of the predeﬁned types CHARACTER, BIT, BOOLEAN, SEVERITY_LEVEL,
FILE_OPEN_KIND, and FILE_OPEN_STATUS appear in package STANDARD in Clause 14.
NOTES

110

1—The ﬁrst 17 nongraphic elements of the predeﬁned type CHARACTER (from NUL through DEL) are the ASCII
abbreviations for the nonprinting characters in the ASCII set (except for those noted in Clause 14). The ASCII names are
chosen as ISO 8859-1: 1987 [B6] does not assign them abbreviations. The next 16 (C128 through C159) are also not
assigned abbreviations, so names unique to VHDL are assigned.
2—Type BOOLEAN can be used to model either active high or active low logic depending on the particular conversion
functions chosen to and from type BIT.

1The

numbers in brackets correspond to those of the bibliography in Annex D.

Copyright © 2000 IEEE. All rights reserved.

35

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

3.1.2 Integer types
An integer type deﬁnition deﬁnes an integer type whose set of values includes those of the speciﬁed range.
integer_type_deﬁnition ::= range_constraint
115

An integer type deﬁnition deﬁnes both a type and a subtype of that type. The type is an anonymous type, the
range of which is selected by the implementation; this range must be such that it wholly contains the range
given in the integer type deﬁnition. The subtype is a named subtype of this anonymous base type, where the
name of the subtype is that given by the corresponding type declaration and the range of the subtype is the
given range.

120

Each bound of a range constraint that is used in an integer type deﬁnition must be a locally static expression
of some integer type, but the two bounds need not have the same integer type. (Negative bounds are
allowed.)

125

Integer literals are the literals of an anonymous predeﬁned type that is called universal_integer in this standard. Other integer types have no literals. However, for each integer type there exists an implicit conversion
that converts a value of type universal_integer into the corresponding value (if any) of the integer type (see
7.3.5).
The position number of an integer value is the corresponding value of the type universal_integer.

130

The same arithmetic operators are predeﬁned for all integer types (see 7.2). It is an error if the execution of
such an operation (in particular, an implicit conversion) cannot deliver the correct result (that is, if the value
corresponding to the mathematical result is not a value of the integer type).
An implementation may restrict the bounds of the range constraint of integer types other than type
universal_integer. However, an implementation must allow the declaration of any integer type whose range
is wholly contained within the bounds –2147483647 and +2147483647 inclusive.
Examples:
type TWOS_COMPLEMENT_INTEGER is range –32768 to 32767;

135

type BYTE_LENGTH_INTEGER is range 0 to 255;
type WORD_INDEX is range 31 downto 0;
subtype HIGH_BIT_LOW is BYTE_LENGTH_INTEGER range 0 to 127;
3.1.2.1 Predeﬁned integer types
140

The only predeﬁned integer type is the type INTEGER. The range of INTEGER is implementation dependent, but it is guaranteed to include the range –2147483647 to +2147483647. It is deﬁned with an ascending
range.
NOTE—The range of INTEGER in a particular implementation may be determined from the 'LOW and 'HIGH
attributes.

3.1.3 Physical types
145

Values of a physical type represent measurements of some quantity. Any value of a physical type is an
integral multiple of the primary unit of measurement for that type.

36

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

150

IEEE
Std 1076, 2000 Edition

physical_type_deﬁnition ::=
range_constraint
units
primary_unit_declaration
{ secondary_unit_declaration }
end units [ physical_type_simple_name ]
primary_unit_declaration ::= identiﬁer
secondary_unit_declaration ::= identiﬁer = physical_literal ;

155

160

physical_literal ::= [ abstract_literal ] unit_name
A physical type deﬁnition deﬁnes both a type and a subtype of that type. The type is an anonymous type, the
range of which is selected by the implementation; this range must be such that it wholly contains the range
given in the physical type deﬁnition. The subtype is a named subtype of this anonymous base type, where the
name of the subtype is that given by the corresponding type declaration and the range of the subtype is the
given range.
Each bound of a range constraint that is used in a physical type deﬁnition must be a locally static expression
of some integer type, but the two bounds need not have the same integer type. (Negative bounds are
allowed.)

165

Each unit declaration (either the primary unit declaration or a secondary unit declaration) deﬁnes a unit
name. Unit names declared in secondary unit declarations must be directly or indirectly deﬁned in terms of
integral multiples of the primary unit of the type declaration in which they appear. The position numbers of
unit names need not lie within the range speciﬁed by the range constraint.
If a simple name appears at the end of a physical type declaration, it must repeat the identiﬁer of the type
declaration in which the physical type deﬁnition is included.

170

The abstract literal portion (if present) of a physical literal appearing in a secondary unit declaration must be
an integer literal.
A physical literal consisting solely of a unit name is equivalent to the integer 1 followed by the unit name.

175

180

There is a position number corresponding to each value of a physical type. The position number of the value
corresponding to a unit name is the number of primary units represented by that unit name. The position
number of the value corresponding to a physical literal with an abstract literal part is the largest integer that
is not greater than the product of the value of the abstract literal and the position number of the accompanying unit name.
The same arithmetic operators are predeﬁned for all physical types (see 7.2). It is an error if the execution of
such an operation cannot deliver the correct result (i.e., if the value corresponding to the mathematical result
is not a value of the physical type).
An implementation may restrict the bounds of the range constraint of a physical type. However, an implementation must allow the declaration of any physical type whose range is wholly contained within the
bounds –2147483647 and +2147483647 inclusive.

Copyright © 2000 IEEE. All rights reserved.

37

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

Examples:
type DURATION is range –1E18 to 1E18
units
fs;
-ps
= 1000 fs;
-ns
= 1000 ps;
-us
= 1000 ns;
-ms = 1000 us;
-sec = 1000 ms;
-min = 60 sec;
-end units;

185

190

type DISTANCE is range 0 to 1E16
units
-- primary unit:
A;

195

-- metric lengths:
nm = 10 A;
um = 1000 nm;
mm = 1000 um;
cm = 10 mm;
m
= 1000 mm;
km = 1000 m;

200

205

-- English lengths:
mil = 254000 A;
inch = 1000 mil;
ft
= 12 inch;
yd = 3 ft;
fm = 6 ft;
mi = 5280 ft;
lg
= 3 mi;
end units DISTANCE;

210

femtosecond
picosecond
nanosecond
microsecond
millisecond
second
minute

-- angstrom
-- nanometer
-- micrometer (or micron)
-- millimeter
-- centimeter
-- meter
-- kilometer
--------

mil
inch
foot
yard
fathom
mile
league

variable x: distance; variable y: duration; variable z: integer;

215

x := 5 A + 13 ft – 27 inch;
y := 3 ns + 5 min;
z := ns / ps;
x := z * mi;
y := y/10;
z := 39.34 inch / m;

220

NOTES
1— The 'POS and 'VAL attributes may be used to convert between abstract values and physical values.
225

2— The value of a physical literal, whose abstract literal is either the integer value zero or the ﬂoating point value zero,
is the same value (speciﬁcally zero primary units) no matter what unit name follows the abstract literal.

3.1.3.1 Predeﬁned physical types
The only predeﬁned physical type is type TIME. The range of TIME is implementation dependent, but it is
guaranteed to include the range –2147483647 to +2147483647. It is deﬁned with an ascending range. All

38

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

speciﬁcations of delays and pulse rejection limits must be of type TIME. The declaration of type TIME
appears in package STANDARD in Clause 14.
230

235

240

By default, the primary unit of type TIME (1 femtosecond) is the resolution limit for type TIME. Any TIME
value whose absolute value is smaller than this limit is truncated to zero (0) time units. An implementation
may allow a given execution of a model (see 12.6) to select a secondary unit of type TIME as the resolution
limit. Furthermore, an implementation may restrict the precision of the representation of values of type
TIME and the results of expressions of type TIME, provided that values as small as the resolution limit are
representable within those restrictions. It is an error if a given unit of type TIME appears anywhere within
the design hierarchy deﬁning a model to be executed, and if the position number of that unit is less than that
of the secondary unit selected as the resolution limit for type TIME during the execution of the model.
NOTE—By selecting a secondary unit of type TIME as the resolution limit for type TIME, it may be possible to simulate for a longer period of simulated time, with reduced accuracy, or to simulate with greater accuracy for a shorter
period of simulated time.

Cross-references: Delay and rejection limit in a signal assignment, 8.4; disconnection, delay of a guarded
signal, 5.3; function NOW, 14.2; predeﬁned attributes, functions of TIME, 14.1; simulation time, 12.6.2 and
12.6.3; type TIME, 14.2; Updating a projected waveform, 8.4.1; wait statements, timeout clause in, 8.1.
3.1.4 Floating point types
245

Floating point types provide approximations to the real numbers. Floating point types are useful for models
in which the precise characterization of a ﬂoating point calculation is not important or not determined.
ﬂoating_type_deﬁnition ::= range_constraint

250

255

A ﬂoating type deﬁnition deﬁnes both a type and a subtype of that type. The type is an anonymous type, the
range of which is selected by the implementation; this range must be such that it wholly contains the range
given in the ﬂoating type deﬁnition. The subtype is a named subtype of this anonymous base type, where the
name of the subtype is that given by the corresponding type declaration and the range of the subtype is the
given range.
Each bound of a range constraint that is used in a ﬂoating type deﬁnition must be a locally static expression
of some ﬂoating point type, but the two bounds need not have the same ﬂoating point type. (Negative bounds
are allowed.)
Floating point literals are the literals of an anonymous predeﬁned type that is called universal_real in this
standard. Other ﬂoating point types have no literals. However, for each ﬂoating point type there exists an
implicit conversion that converts a value of type universal_real into the corresponding value (if any) of the
ﬂoating point type (see 7.3.5).

260

265

The same arithmetic operations are predeﬁned for all ﬂoating point types (see 7.2). A design is erroneous if
the execution of such an operation cannot deliver the correct result (that is, if the value corresponding to the
mathematical result is not a value of the ﬂoating point type).
An implementation may restrict the bounds of the range constraint of ﬂoating point types other than type
universal_real. However, an implementation must allow the declaration of any ﬂoating point type whose
range is wholly contained within the bounds –1.0E38 and +1.0E38 inclusive. The representation of ﬂoating
point types must include a minimum of six decimal digits of precision.
NOTE—An implementation is not required to detect errors in the execution of a predeﬁned ﬂoating point arithmetic
operation, since the detection of overﬂow conditions resulting from such operations may not be easily accomplished on
many host systems.

Copyright © 2000 IEEE. All rights reserved.

39

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

3.1.4.1 Predeﬁned ﬂoating point types
270

The only predeﬁned ﬂoating point type is the type REAL. The range of REAL is host-dependent, but it is
guaranteed to include the range –1.0E38 to +1.0E38 inclusive. It is deﬁned with an ascending range.
NOTE—The range of REAL in a particular implementation may be determined from the 'LOW and 'HIGH attributes.

3.2 Composite types

275

Composite types are used to deﬁne collections of values. These include both arrays of values (collections of
values of a homogeneous type) and records of values (collections of values of potentially heterogeneous
types).
composite_type_deﬁnition ::=
array_type_deﬁnition
| record_type_deﬁnition

280

An object of a composite type represents a collection of objects, one for each element of the composite
object. A composite type may only contain elements that are of scalar, composite, or access types; elements
of ﬁle types or protected types are not allowed in a composite type. Thus an object of a composite type
ultimately represents a collection of objects of scalar or access types, one for each noncomposite subelement
of the composite object.
3.2.1 Array types

285

An array object is a composite object consisting of elements that have the same subtype. The name for an
element of an array uses one or more index values belonging to speciﬁed discrete types. The value of an
array object is a composite value consisting of the values of its elements.
array_type_deﬁnition ::=
unconstrained_array_deﬁnition | constrained_array_deﬁnition
unconstrained_array_deﬁnition ::=
array ( index_subtype_deﬁnition { , index_subtype_deﬁnition } )
of element_subtype_indication

290

constrained_array_deﬁnition ::=
array index_constraint of element_subtype_indication
index_subtype_deﬁnition ::= type_mark range <>
index_constraint ::= ( discrete_range { , discrete_range } )

295

discrete_range ::= discrete_subtype_indication | range
An array object is characterized by the number of indices (the dimensionality of the array); the type, position, and range of each index; and the type and possible constraints of the elements. The order of the indices
is signiﬁcant.
300

A one-dimensional array has a distinct element for each possible index value. A multidimensional array has
a distinct element for each possible sequence of index values that can be formed by selecting one value for
each index (in the given order). The possible values for a given index are all the values that belong to the corresponding range; this range of values is called the index range.

40

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

305

310

IEEE
Std 1076, 2000 Edition

An unconstrained array deﬁnition deﬁnes an array type and a name denoting that type. For each object that
has the array type, the number of indices, the type and position of each index, and the subtype of the
elements are as in the type deﬁnition. The index subtype for a given index position is, by deﬁnition, the subtype denoted by the type mark of the corresponding index subtype deﬁnition. The values of the left and right
bounds of each index range are not deﬁned, but must belong to the corresponding index subtype; similarly,
the direction of each index range is not deﬁned. The symbol <> (called a box) in an index subtype deﬁnition
stands for an undeﬁned range (different objects of the type need not have the same bounds and direction).
A constrained array deﬁnition deﬁnes both an array type and a subtype of this type:
—

The array type is an implicitly declared anonymous type; this type is deﬁned by an (implicit) unconstrained array deﬁnition, in which the element subtype indication is that of the constrained array
definition and in which the type mark of each index subtype deﬁnition denotes the subtype deﬁned
by the corresponding discrete range.

—

The array subtype is the subtype obtained by imposition of the index constraint on the array type.

315

If a constrained array deﬁnition is given for a type declaration, the simple name declared by this declaration
denotes the array subtype.

320

The direction of a discrete range is the same as the direction of the range or the discrete subtype indication
that deﬁnes the discrete range. If a subtype indication appears as a discrete range, the subtype indication
must not contain a resolution function.
Examples:
—

325

Examples of constrained array declarations:

type MY_WORD is array (0 to 31) of BIT ;
-- A memory word type with an ascending range.
type DATA_IN is array (7 downto 0) of FIVE_LEVEL_LOGIC ;
-- An input port type with a descending range.
—

330

Example of unconstrained array declarations:

type MEMORY is array (INTEGER range <>) of MY_WORD ;
-- A memory array type.
—

Examples of array object declarations:

signal DATA_LINE : DATA_IN ;
-- Deﬁnes a data input line.
335

variable MY_MEMORY : MEMORY (0 to 2**n–1) ;
-- Deﬁnes a memory of 2n 32-bit words.
NOTE—The rules concerning constrained type declarations mean that a type declaration with a constrained array
deﬁnition such as
type T is array (POSITIVE range MINIMUM to MAX) of ELEMENT;

340

is equivalent to the sequence of declarations
subtype index_subtype is POSITIVE range MINIMUM to MAX;
type array_type is array (index_subtype range <>) of ELEMENT;
subtype T is array_type (index_subtype);
where index_subtype and array_type are both anonymous. Consequently, T is the name of a subtype and all objects
declared with this type mark are arrays that have the same index range.

Copyright © 2000 IEEE. All rights reserved.

41

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

3.2.1.1 Index constraints and discrete ranges
345

350

355

360

An index constraint determines the index range for every index of an array type and, thereby, the
corresponding array bounds.
For a discrete range used in a constrained array deﬁnition and deﬁned by a range, an implicit conversion to the
predeﬁned type INTEGER is assumed if each bound is either a numeric literal or an attribute, and if the type
of both bounds (prior to the implicit conversion) is the type universal_integer. Otherwise, both bounds must
be of the same discrete type, other than universal_integer; this type must be determined independently of the
context, but using the fact that the type must be discrete and that both bounds must have the same type. These
rules apply also to a discrete range used in an iteration scheme (see 8.9) or a generation scheme (see 9.7).
If an index constraint appears after a type mark in a subtype indication, then the type or subtype denoted by
the type mark must not already impose an index constraint. The type mark must denote either an unconstrained array type or an access type whose designated type is such an array type. In either case, the index
constraint must provide a discrete range for each index of the array type, and the type of each discrete range
must be the same as that of the corresponding index.
An index constraint is compatible with the type denoted by the type mark if, and only if, the constraint
deﬁned by each discrete range is compatible with the corresponding index subtype. If any of the discrete
ranges deﬁnes a null range, any array thus constrained is a null array, having no components. An array value
satisﬁes an index constraint if at each index position the array value and the index constraint have the same
index range. (Note, however, that assignment and certain other operations on arrays involve an implicit
subtype conversion.)
The index range for each index of an array object is determined as follows:

365

—

For a variable or signal declared by an object declaration, the subtype indication of the corresponding
object declaration must deﬁne a constrained array subtype (and thereby, the index range for each
index of the object). The same requirement exists for the subtype indication of an element declaration, if the type of the record element is an array type, and for the element subtype indication of an
array type deﬁnition, if the type of the array element is itself an array type.

370

—

For a constant declared by an object declaration, the index ranges are deﬁned by the initial value, if
the subtype of the constant is unconstrained; otherwise, they are deﬁned by this subtype (in which
case the initial value is the result of an implicit subtype conversion).

—

For an attribute whose value is speciﬁed by an attribute speciﬁcation, the index ranges are deﬁned by
the expression given in the speciﬁcation, if the subtype of the attribute is unconstrained; otherwise,
they are deﬁned by this subtype (in which case the value of the attribute is the result of an implicit
subtype conversion).

—

For an array object designated by an access value, the index ranges are deﬁned by the allocator that
creates the array object (see 7.3.6).

—

For an interface object declared with a subtype indication that deﬁnes a constrained array subtype,
the index ranges are deﬁned by that subtype or subnature.

—

For a formal parameter of a subprogram that is of an unconstrained array type and that is associated
in whole (see 4.3.2.2), the index ranges are obtained from the corresponding association element in
the applicable subprogram call.

—

For a formal parameter of a subprogram that is of an unconstrained array type and whose
subelements are associated individually (see 4.3.2.2), the index ranges are obtained as follows: The
directions of the index ranges of the formal parameter are that of the type of the formal; the high and
low bounds of the index ranges are respectively determined from the maximum and minimum values
of the indices given in the association elements corresponding to the formal.

375

380

385

42

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

—

For a formal generic or a formal port of a design entity or of a block statement that is of an
unconstrained array type and that is associated in whole, the index ranges are obtained from the
corresponding association element in the generic map aspect (in the case of a formal generic) or port
map aspect (in the case of a formal port) of the applicable (implicit or explicit) binding indication.

—

For a formal generic or a formal port of a design entity or of a block statement that is of an unconstrained array type and whose subelements are associated individually, the index ranges are obtained
as follows: The directions of the index ranges of the formal generic or formal port are that of the type
of the formal; the high and low bounds of the index ranges are respectively determined from the
maximum and minimum values of the indices given in the association elements corresponding to the
formal.

—

For a local generic or a local port of a component that is of an unconstrained array type and that is
associated in whole, the index ranges are obtained from the corresponding association element in the
generic map aspect (in the case of a local generic) or port map aspect (in the case of a local port) of
the applicable component instantiation statement.

—

For a local generic or a local port of a component that is of an unconstrained array type and whose
subelements are associated individually, the index ranges are obtained as follows: The directions of
the index ranges of the local generic or local port are that of the type of the local; the high and low
bounds of the index ranges are respectively determined from the maximum and minimum values of
the indices given in the association elements corresponding to the local.

390

395

400

405

410

If the index ranges for an interface object or member of an interface object are obtained from the corresponding association element (when associating in whole) or elements (when associating individually), then
they are determined either by the actual part(s) or by the formal part(s) of the association element(s),
depending upon the mode of the interface object, as follows:
—

For an interface object or member of an interface object whose mode is in, inout, or linkage, if the
actual part includes a conversion function or a type conversion, then the result type of that function or
the type mark of the type conversion must be a constrained array subtype, and the index ranges are
obtained from this constrained subtype; otherwise, the index ranges are obtained from the object or
value denoted by the actual designator(s).

—

For an interface object or member of an interface object whose mode is out, buffer, inout, or
linkage, if the formal part includes a conversion function or a type conversion, then the parameter
subtype of that function or the type mark of the type conversion must be a constrained array subtype,
and the index ranges are obtained from this constrained subtype; otherwise, the index ranges are
obtained from the object denoted by the actual designator(s).

415

420

IEEE
Std 1076, 2000 Edition

For an interface object of mode inout or linkage, the index ranges determined by the ﬁrst rule must be
identical to the index ranges determined by the second rule.
Examples:
425

type Word is array (NATURAL range <>) of BIT;
type Memory is array (NATURAL range <>) of Word (31 downto 0);
constant A_Word: Word := "10011";
-- The index range of A_Word is 0 to 4

430

entity E is
generic (ROM: Memory);
port (Op1, Op2: in Word; Result: out Word);

Copyright © 2000 IEEE. All rights reserved.

43

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

end entity E;
-- The index ranges of the generic and the ports are deﬁned by the actuals associated
-- with an instance bound to E; these index ranges are accessible via the predeﬁned
-- array attributes (see 14.1).

435

signal A, B: Word (1 to 4);
signal C: Word (5 downto 0);
Instance: entity E
generic map ((1 to 2) => (others => '0'))
port map (A, Op2(3 to 4) => B (1 to 2), Op2(2) => B (3), Result => C (3 downto 1));
-- In this instance, the index range of ROM is 1 to 2 (matching that of the actual),
-- The index range of Op1 is 1 to 4 (matching the index range of A), the index range
-- of Op2 is 2 to 4, and the index range of Result is (3 downto 1)
-- (again matching the index range of the actual).

440

3.2.1.2 Predeﬁned array types
445

The predeﬁned array types are STRING and BIT_VECTOR, deﬁned in package STANDARD in Clause 14.
The values of the predeﬁned type STRING are one-dimensional arrays of the predeﬁned type
CHARACTER, indexed by values of the predeﬁned subtype POSITIVE:
subtype POSITIVE is INTEGER range 1 to INTEGER'HIGH ;
type STRING is array (POSITIVE range <>) of CHARACTER ;

450

The values of the predeﬁned type BIT_VECTOR are one-dimensional arrays of the predeﬁned type BIT,
indexed by values of the predeﬁned subtype NATURAL:
subtype NATURAL is INTEGER range 0 to INTEGER'HIGH ;
type BIT_VECTOR is array (NATURAL range <>) of BIT ;
Examples:
variable MESSAGE : STRING(1 to 17) := "THIS IS A MESSAGE" ;

455

signal LOW_BYTE : BIT_VECTOR (0 to 7) ;
3.2.2 Record types
A record type is a composite type, objects of which consist of named elements. The value of a record object
is a composite value consisting of the values of its elements.
record_type_deﬁnition ::=
record
element_declaration
{ element_declaration }
end record [ record_type_simple_name ]

460

element_declaration ::=
identiﬁer_list : element_subtype_deﬁnition ;

465

identiﬁer_list ::= identiﬁer { , identiﬁer }
element_subtype_deﬁnition ::= subtype_indication

44

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

470

IEEE
Std 1076, 2000 Edition

Each element declaration declares an element of the record type. The identiﬁers of all elements of a record
type must be distinct. The use of a name that denotes a record element is not allowed within the record type
deﬁnition that declares the element.
An element declaration with several identiﬁers is equivalent to a sequence of single element declarations.
Each single element declaration declares a record element whose subtype is speciﬁed by the element subtype
deﬁnition.

475

If a simple name appears at the end of a record type declaration, it must repeat the identiﬁer of the type
declaration in which the record type deﬁnition is included.
A record type deﬁnition creates a record type; it consists of the element declarations in the order in which
they appear in the type deﬁnition.
Example:

480

type DATE is
record
DAY
MONTH
YEAR
end record;

: INTEGER range 1 to 31;
: MONTH_NAME;
: INTEGER range 0 to 4000;

3.3 Access types
485

An object declared by an object declaration is created by the elaboration of the object declaration and is
denoted by a simple name or by some other form of name. In contrast, objects that are created by the evaluation of allocators (see 7.3.6) have no simple name. Access to such an object is achieved by an access value
returned by an allocator; the access value is said to designate the object.
access_type_deﬁnition ::= access subtype_indication

490

495

For each access type, there is a literal null that has a null access value designating no object at all. The null
value of an access type is the default initial value of the type. Other values of an access type are obtained by
evaluation of a special operation of the type, called an allocator. Each such access value designates an object
of the subtype deﬁned by the subtype indication of the access type deﬁnition. This subtype is called the
designated subtype and the base type of this subtype is called the designated type. The designated type must
not be a ﬁle type or a protected type; moreover, it may not have a subelement that is a ﬁle type or a protected
type.
An object declared to be of an access type must be an object of class variable. An object designated by an
access value is always an object of class variable.

500

The only form of constraint that is allowed after the name of an access type in a subtype indication is an
index constraint. An access value belongs to a corresponding subtype of an access type either if the access
value is the null value or if the value of the designated object satisﬁes the constraint.
Examples:
type ADDRESS is access MEMORY;
type BUFFER_PTR is access TEMP_BUFFER;

Copyright © 2000 IEEE. All rights reserved.

45

IEEE
Std 1076, 2000 Edition

505

IEEE STANDARD VHDL

NOTES
1—An access value delivered by an allocator can be assigned to several variables of the corresponding access type.
Hence, it is possible for an object created by an allocator to be designated by more than one variable of the access type.
An access value can only designate an object created by an allocator; in particular, it cannot designate an object declared
by an object declaration.

510

2—If the type of the object designated by the access value is an array type, this object is constrained with the array
bounds supplied implicitly or explicitly for the corresponding allocator.

3.3.1 Incomplete type declarations

515

The designated type of an access type can be of any type except a ﬁle type (see 3.3). In particular, the type of
an element of the designated type can be another access type or even the same access type. This permits
mutually dependent and recursive access types. Declarations of such types require a prior incomplete type
declaration for one or more types.
incomplete_type_declaration ::= type identiﬁer ;
For each incomplete type declaration there must be a corresponding full type declaration with the same identiﬁer. This full type declaration must occur later and immediately within the same declarative part as the
incomplete type declaration to which it corresponds.

520

Prior to the end of the corresponding full type declaration, the only allowed use of a name that denotes a type
declared by an incomplete type declaration is as the type mark in the subtype indication of an access type
deﬁnition; no constraints are allowed in this subtype indication.
Example of a recursive type:
type CELL;

-- An incomplete type declaration.

type LINK is access CELL;

525

type CELL is
record
VALUE
: INTEGER;
SUCC
: LINK;
PRED
: LINK;
end record CELL;
variable HEAD : LINK := new CELL'(0, null, null);
variable \NEXT\ : LINK := HEAD.SUCC;

530

Examples of mutually dependent access types:
type PART;
type WIRE;

535

-- Incomplete type declarations.

type PART_PTR is access PART;
type WIRE_PTR is access WIRE;
type PART_LIST is array (POSITIVE range <>) of PART_PTR;
type WIRE_LIST is array (POSITIVE range <>) of WIRE_PTR;

540

type PART_LIST_PTR is access PART_LIST;
type WIRE_LIST_PTR is access WIRE_LIST;

46

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

545

type PART is
record
PART_NAME
CONNECTIONS
end record;

550

type WIRE is
record
WIRE_NAME
CONNECTS
end record;

: STRING (1 to MAX_STRING_LEN);
: WIRE_LIST_PTR;

: STRING (1 to MAX_STRING_LEN);
: PART_LIST_PTR;

3.3.2 Allocation and deallocation of objects

555

An object designated by an access value is allocated by an allocator for that type. An allocator is a primary
of an expression; allocators are described in 7.3.6. For each access type, a deallocation operation is implicitly declared immediately following the full type declaration for the type. This deallocation operation makes
it possible to deallocate explicitly the storage occupied by a designated object.
Given the following access type declaration:
type AT is access T;
the following operation is implicitly declared immediately following the access type declaration:

560

565

procedure DEALLOCATE (P: inout AT) ;
Procedure DEALLOCATE takes as its single parameter a variable of the speciﬁed access type. If the value
of that variable is the null value for the speciﬁed access type, then the operation has no effect. If the value of
that variable is an access value that designates an object, the storage occupied by that object is returned to
the system and may then be reused for subsequent object creation through the invocation of an allocator. The
access parameter P is set to the null value for the speciﬁed type.
NOTE—If a pointer is copied to a second variable and is then deallocated, the second variable is not set to null and thus
references invalid storage.

3.4 File types
A ﬁle type deﬁnition deﬁnes a ﬁle type. File types are used to deﬁne objects representing ﬁles in the host
system environment. The value of a ﬁle object is the sequence of values contained in the host system ﬁle.
570

575

ﬁle_type_deﬁnition ::= ﬁle of type_mark
The type mark in a ﬁle type deﬁnition deﬁnes the subtype of the values contained in the ﬁle. The type mark
may denote either a constrained or an unconstrained subtype. The base type of this subtype must not be a ﬁle
type, an access type, or a protected type. If the base type is a composite type, it must not contain a
subelement of an access type, a ﬁle type, or a protected type. If the base type is an array type, it must be a
one-dimensional array type.

Copyright © 2000 IEEE. All rights reserved.

47

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

Examples:
ﬁle of STRING
ﬁle of NATURAL
580

-----

Deﬁnes a ﬁle type that can contain
an indeﬁnite number of strings of arbitrary length.
Deﬁnes a ﬁle type that can contain
only nonnegative integer values.

3.4.1 File operations
The language implicitly deﬁnes the operations for objects of a ﬁle type. Given the following ﬁle type
declaration:
type FT is ﬁle of TM;

585

where type mark TM denotes a scalar type, a record type, or a constrained array subtype, the following
operations are implicitly declared immediately following the ﬁle type declaration:
procedure FILE_OPEN (ﬁle F: FT;
External_Name: in STRING;
Open_Kind: in FILE_OPEN_KIND := READ_MODE);
procedure FILE_OPEN (Status: out FILE_OPEN_STATUS;
ﬁle F: FT;
External_Name: in STRING;
Open_Kind: in FILE_OPEN_KIND := READ_MODE);

590

procedure FILE_CLOSE (ﬁle F: FT);
procedure READ (ﬁle F: FT; VALUE: out TM);
procedure WRITE (ﬁle F: FT; VALUE: in TM);

595

function ENDFILE (ﬁle F: FT) return BOOLEAN;

600

The FILE_OPEN procedures open an external ﬁle speciﬁed by the External_Name parameter and associate
it with the ﬁle object F. If the call to FILE_OPEN is successful (see below), the ﬁle object is said to be open
and the ﬁle object has an access mode dependent on the value supplied to the Open_Kind parameter (see
14.2).

605

610

48

—

If the value supplied to the Open_Kind parameter is READ_MODE, the access mode of the ﬁle
object is read-only. In addition, the ﬁle object is initialized so that a subsequent READ will return the
ﬁrst value in the external ﬁle. Values are read from the ﬁle object in the order that they appear in the
external ﬁle.

—

If the value supplied to the Open_Kind parameter is WRITE_MODE, the access mode of the ﬁle
object is write-only. In addition, the external ﬁle is made initially empty. Values written to the ﬁle
object are placed in the external ﬁle in the order in which they are written.

—

If the value supplied to the Open_Kind parameter is APPEND_MODE, the access mode of the ﬁle
object is write-only. In addition, the ﬁle object is initialized so that values written to it will be added
to the end of the external ﬁle in the order in which they are written.

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

In the second form of FILE_OPEN, the value returned through the Status parameter indicates the results of
the procedure call:
—

A value of OPEN_OK indicates that the call to FILE_OPEN was successful. If the call to
FILE_OPEN speciﬁes an external ﬁle that does not exist at the beginning of the call, and if the access
mode of the ﬁle object passed to the call is write-only, then the external ﬁle is created.

—

A value of STATUS_ERROR indicates that the ﬁle object already has an external ﬁle associated
with it.

—

A value of NAME_ERROR indicates that the external ﬁle does not exist (in the case of an attempt to
read from the external ﬁle) or the external ﬁle cannot be created (in the case of an attempt to write or
append to an external ﬁle that does not exist). This value is also returned if the external ﬁle cannot be
associated with the ﬁle object for any reason.

—

A value of MODE_ERROR indicates that the external ﬁle cannot be opened with the requested
Open_Kind.

615

620

625

The ﬁrst form of FILE_OPEN causes an error to occur if the second form of FILE_OPEN, when called
under identical conditions, would return a Status value other than OPEN_OK.
A call to FILE_OPEN of the ﬁrst form is successful if and only if the call does not cause an error to occur.
Similarly, a call to FILE_OPEN of the second form is successful if and only if it returns a Status value of
OPEN_OK.

630

635

640

If a ﬁle object F is associated with an external ﬁle, procedure FILE_CLOSE terminates access to the external
ﬁle associated with F and closes the external ﬁle. If F is not associated with an external ﬁle, then
FILE_CLOSE has no effect. In either case, the ﬁle object is no longer open after a call to FILE_CLOSE that
associates the ﬁle object with the formal parameter F.
An implicit call to FILE_CLOSE exists in a subprogram body for every ﬁle object declared in the
corresponding subprogram declarative part. Each such call associates a unique ﬁle object with the formal
parameter F and is called whenever the corresponding subprogram completes its execution.
Procedure READ retrieves the next value from a ﬁle; it is an error if the access mode of the ﬁle object is
write-only or if the ﬁle object is not open. Procedure WRITE appends a value to a ﬁle; it is similarly an error
if the access mode of the ﬁle object is read-only or if the ﬁle is not open. Function ENDFILE returns FALSE
if a subsequent READ operation on an open ﬁle object whose access mode is read-only can retrieve another
value from the ﬁle; otherwise, it returns TRUE. Function ENDFILE always returns TRUE for an open ﬁle
object whose access mode is write-only. It is an error if ENDFILE is called on a ﬁle object that is not open.
For a ﬁle type declaration in which the type mark denotes an unconstrained array type, the same operations
are implicitly declared, except that the READ operation is declared as follows:
procedure READ (ﬁle F: FT; VALUE: out TM; LENGTH: out Natural);

645

650

The READ operation for such a type performs the same function as the READ operation for other types, but
in addition it returns a value in parameter LENGTH that speciﬁes the actual length of the array value read by
the operation. If the object associated with formal parameter VALUE is shorter than this length, then only
that portion of the array value read by the operation that can be contained in the object is returned by the
READ operation, and the rest of the value is lost. If the object associated with formal parameter VALUE is
longer than this length, then the entire value is returned and remaining elements of the object are unaffected
by the READ operation.
An error will occur when a READ operation is performed on ﬁle F if ENDFILE(F) would return TRUE at
that point.

Copyright © 2000 IEEE. All rights reserved.

49

IEEE
Std 1076, 2000 Edition

655

IEEE STANDARD VHDL

NOTE—Predeﬁned package TEXTIO is provided to support formatted human-readable I/O. It deﬁnes type TEXT (a ﬁle
type representing ﬁles of variable-length text strings) and type LINE (an access type that designates such strings). READ
and WRITE operations are provided in package TEXTIO that append or extract data from a single line. Additional operations are provided to read or write entire lines and to determine the status of the current line or of the ﬁle itself. Package
TEXTIO is deﬁned in Clause 14.

3.5 Protected types

660

A protected type deﬁnition deﬁnes a protected type. A protected type implements instantiatiable regions of
sequential statements, each of which are guaranteed exclusive access to shared data. Shared data is a set of
variable objects that may be potentially accessed as a unit by multiple processes.
protected_type_definition ::=
protected_type_declaration
| protected_type_body

665

670

Each protected type declaration appearing immediately within a given declarative region (see 10.1) must
have exactly one corresponding protected type body appearing immediately within the same declarative
region and textually subsequent to the protected type declaration. Similarly, each protected type body
appearing immediately within a given declarative region must have exactly one corresponding protected
type declaration appearing immediately within the same declarative region and textually prior to the
protected type body.
3.5.1 Protected type declarations
A protected type declaration declares the external interface to a protected type.
protected_type_declaration ::=
protected
protected_type_declarative_part
end protected [ protected_type_simple_name ]

675

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

680

If a simple name appears at the end of a protected type declaration, it must repeat the identiﬁer of the type
declaration in which the protected type deﬁnition is included.

685

690

Each subprogram speciﬁed within a given protected type declaration deﬁnes an abstract operation, called a
method, that operates atomically and exclusively on a single object of the protected type. In addition to the
(implied) object of the protected type operated on by the subprogram, additional parameters may be explicitly speciﬁed in the formal parameter list of the subprogram declaration of the subprogram. Such formal
parameters must not be of an access type or a ﬁle type; moreover, they must not have a subelement that is an
access type or a ﬁle type. Additionally, in the case of a function subprogram, the return type of the function
must not be of an access type or ﬁle type; moreover, it must not have a subelement that is an access type or a
ﬁle type.

50

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

Examples:

695

700

705

type SharedCounter is protected
procedure increment (N: Integer := 1);
procedure decrement (N: Integer := 1);
impure function value return Integer;
end protected SharedCounter;
type ComplexNumber is protected
procedure extract (variable r, i: out Real);
procedure add (variable a, b: inout ComplexNumber);
end protected ComplexNumber;
type VariableSizedBitArray is protected
procedure add_bit (index: Positive; value: Bit);
impure function size return Natural;
end protected VariableSizedBitArray;
3.5.2 Protected type bodies
A protected type body provides the implementation for a protected type.

710

protected_type_body ::=
protected body
protected_type_body_declarative_part
end protected body [ protected_type_simple name ]
protected_type_body_declarative_part ::=
{ protected_type_body_declarative_item }

715

720

725

protected_type_body_declarative_item ::=
subprogram_declaration
| subprogram_body
| type_declaration
| subtype_declaration
| constant_declaration
| variable_declaration
| file_declaration
| alias_declaration
| attribute_declaration
| attribute_specification
| use_clause
| group_template_declaration
| group_declaration
Each subprogram declaration appearing in a given protected type declaration shall have a corresponding
subprogram body appearing in the corresponding protected type body.

730

NOTE—Subprogram bodies appearing in a protected type body not conformant to any of the subprogram declarations
in the corresponding protected type declaration are visible only within the protected type body. Such subprograms may
have parameters and (in the case of functions) return types that are or contain access and ﬁle types.

Copyright © 2000 IEEE. All rights reserved.

51

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

Examples:
type SharedCounter is protected body
variable counter: Integer := 0;
procedure increment (N: Integer := 1) is
begin
counter := counter + N;
end procedure increment;

735

procedure decrement (N: Integer := 1) is
begin
counter := counter – N;
end procedure decrement;

740

impure function value return Integer is
begin
return counter;
end function value;
end protected body SharedCounter;

745

type ComplexNumber is protected body
variable re, im: Real;
procedure extract (r, i: out Real) is
begin
r := re;
i := im;
end procedure extract;

750

procedure add (variable a, b: inout 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;

755

760

52

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

765

IEEE
Std 1076, 2000 Edition

type VariableSizeBitArray is protected body
type bit_vector_access is access Bit_Vector;
variable bit_array: bit_vector_access := null;
variable bit_array_length: Natural := 0;

770

775

780

785

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 := new bit_vector (1 to index);
if tmp /= null then
bit_array (1 to bit_array_length) := tmp.all;
deallocate (tmp);
end if;
bit_array_length := index;
end if;
bit_array (index) := value;
end procedure add_bit;
impure function size return Natural is
begin
return bit_array_length;
end function size;
end protected body VariableSizeBitArray;

Copyright © 2000 IEEE. All rights reserved.

53

IEEE
Std 1076, 2000 Edition

54

IEEE STANDARD VHDL

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

4. Declarations
The language deﬁnes several kinds of entities that are declared explicitly or implicitly by declarations.

5

10

15

20

declaration ::=
type_declaration
| subtype_declaration
| object_declaration
| interface_declaration
| alias_declaration
| attribute_declaration
| component_declaration
| group_template_declaration
| group_declaration
| entity_declaration
| conﬁguration_declaration
| subprogram_declaration
| package_declaration
For each form of declaration, the language rules deﬁne a certain region of text called the scope of the declaration (see 10.2). Each form of declaration associates an identiﬁer with a named entity. Only within its
scope, there are places where it is possible to use the identiﬁer to refer to the associated declared entity; these
places are deﬁned by the visibility rules (see 10.3). At such places the identiﬁer is said to be a name of the
entity; the name is said to denote the associated entity.
This clause describes type and subtype declarations, the various kinds of object declarations, alias declarations, attribute declarations, component declarations, and group and group template declarations. The other
kinds of declarations are described in Clause 1 and Clause 2.

25

A declaration takes effect through the process of elaboration. Elaboration of declarations is discussed in
Clause 12.

4.1 Type declarations
A type declaration declares a type.
type_declaration ::=
full_type_declaration
| incomplete_type_declaration
30

35

full_type_declaration ::=
type identiﬁer is type_deﬁnition ;
type_deﬁnition ::=
scalar_type_deﬁnition
| composite_type_deﬁnition
| access_type_deﬁnition
| ﬁle_type_deﬁnition
| protected_type_deﬁnition
The types created by the elaboration of distinct type deﬁnitions are distinct types. The elaboration of the type
deﬁnition for a scalar type or a constrained array type creates both a base type and a subtype of the base type.

Copyright © 2000 IEEE. All rights reserved.

55

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

40

The simple name declared by a type declaration denotes the declared type, unless the type declaration
declares both a base type and a subtype of the base type, in which case the simple name denotes the subtype
and the base type is anonymous. A type is said to be anonymous if it has no simple name. For explanatory
purposes, this standard sometimes refers to an anonymous type by a pseudo-name, written in italics, and
uses such pseudo-names at places where the syntax normally requires an identiﬁer.

45

NOTES
1—Two type deﬁnitions always deﬁne two distinct types, even if they are lexically identical. Thus, the type deﬁnitions in
the following two integer type declarations deﬁne distinct types:
type A is range 1 to 10;
type B is range 1 to 10;

50

This applies to type declarations for other classes of types as well.
2—The various forms of type deﬁnition are described in Clause 3. Examples of type declarations are also given in that
clause.

4.2 Subtype declarations
A subtype declaration declares a subtype.
subtype_declaration ::=
subtype identiﬁer is subtype_indication ;

55

subtype_indication ::=
[ resolution_function_name ] type_mark [ constraint ]
type_mark ::=
type_name
| subtype_name

60

constraint ::=
range_constraint
| index_constraint

65

A type mark denotes a type or a subtype. If a type mark is the name of a type, the type mark denotes this type
and also the corresponding unconstrained subtype. The base type of a type mark is, by deﬁnition, the base
type of the type or subtype denoted by the type mark.
A subtype indication deﬁnes a subtype of the base type of the type mark.

70

75

If a subtype indication includes a resolution function name, then any signal declared to be of that subtype
will be resolved, if necessary, by the named function (see 2.4); for an overloaded function name, the meaning of the function name is determined by context (see 2.3 and 10.5). It is an error if the function does not
meet the requirements of a resolution function (see 2.4). The presence of a resolution function name has no
effect on the declarations of objects other than signals or on the declarations of ﬁles, aliases, attributes, or
other subtypes.
If the subtype indication does not include a constraint, the subtype is the same as that denoted by the type
mark. The condition imposed by a constraint is the condition obtained after evaluation of the expressions and
ranges forming the constraint. The rules deﬁning compatibility are given for each form of constraint in the
appropriate clause. These rules are such that if a constraint is compatible with a subtype, then the condition
imposed by the constraint cannot contradict any condition already imposed by the subtype on its values. An
error occurs if any check of compatibility fails.

56

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

80

85

IEEE
Std 1076, 2000 Edition

The direction of a discrete subtype indication is the same as the direction of the range constraint that appears
as the constraint of the subtype indication. If no constraint is present, and the type mark denotes a subtype,
the direction of the subtype indication is the same as that of the denoted subtype. If no constraint is present,
and the type mark denotes a type, the direction of the subtype indication is the same as that of the range used
to deﬁne the denoted type. The direction of a discrete subtype is the same as the direction of its subtype
indication.
A subtype indication denoting an access type, a ﬁle type, or a protected type may not contain a resolution
function. Furthermore, the only allowable constraint on a subtype indication denoting an access type is an
index constraint (and then only if the designated type is an array type).

90

A subtype indication denoting a subtype of a record type, a ﬁle type, or a protected type may not contain a
constraint.
NOTE—A subtype declaration does not deﬁne a new type.

4.3 Objects
An object is a named entity that contains (has) a value of a type. An object is one of the following:

95

100

—
—
—
—
—
—
—
—

An object declared by an object declaration (see 4.3.1)
A loop or generate parameter (see 8.9 and 9.7)
A formal parameter of a subprogram (see 2.1.1)
A formal port (see 1.1.1.2 and 9.1)
A formal generic (see 1.1.1.1 and 9.1)
A local port (see 4.5)
A local generic (see 4.5)
An implicit signal GUARD deﬁned by the guard expression of a block statement (see 9.1)

In addition, the following are objects, but are not named entities:
—

105

110

—
—

An implicit signal deﬁned by any of the predeﬁned attributes 'DELAYED, 'STABLE, 'QUIET, and
'TRANSACTION (see 14.1)
An element or slice of another object (see 6.3, 6.4, and 6.5)
An object designated by a value of an access type (see 3.3)

There are four classes of objects: constants, signals, variables, and ﬁles. The variable class of objects also
has an additional subclass: shared variables. The class of an explicitly declared object is speciﬁed by the
reserved word that must or may appear at the beginning of the declaration of that object. For a given object
of a composite type, each subelement of that object is itself an object of the same class and subclass, if any,
as the given object. The value of a composite object is the aggregation of the values of its subelements.
Objects declared by object declarations are available for use within blocks, processes, subprograms, or packages. Loop and generate parameters are implicitly declared by the corresponding statement and are available
for use only within that statement. Other objects, declared by interface declarations, create channels for the
communication of values between independent parts of a description.

Copyright © 2000 IEEE. All rights reserved.

57

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

4.3.1 Object declarations
115

An object declaration declares an object of a speciﬁed type. Such an object is called an explicitly declared
object.
object_declaration ::=
constant_declaration
| signal_declaration
| variable_declaration
| ﬁle_declaration

120

125

An object declaration is called a single-object declaration if its identiﬁer list has a single identiﬁer; it is
called a multiple-object declaration if the identiﬁer list has two or more identiﬁers. A multiple-object declaration is equivalent to a sequence of the corresponding number of single-object declarations. For each identiﬁer of the list, the equivalent sequence has a single-object declaration formed by this identiﬁer, followed by
a colon and by whatever appears at the right of the colon in the multiple-object declaration; the equivalent
sequence is in the same order as the identiﬁer list.
A similar equivalence applies also for interface object declarations (see 4.3.2).
NOTE—The subelements of a composite declared object are not declared objects.

4.3.1.1 Constant declarations
130

A constant declaration declares a constant of the speciﬁed type. Such a constant is an explicitly declared
constant.
constant_declaration ::=
constant identiﬁer_list : subtype_indication [ := expression ] ;

135

140

If the assignment symbol ":=" followed by an expression is present in a constant declaration, the expression
speciﬁes the value of the constant; the type of the expression must be that of the constant. The value of a
constant cannot be modiﬁed after the declaration is elaborated.
If the assignment symbol ":=" followed by an expression is not present in a constant declaration, then the
declaration declares a deferred constant. Such a constant declaration may only appear in a package declaration. The corresponding full constant declaration, which deﬁnes the value of the constant, must appear in the
body of the package (see 2.6).
Formal parameters of subprograms that are of mode in may be constants, and local and formal generics are
always constants; the declarations of such objects are discussed in 4.3.2. A loop parameter is a constant
within the corresponding loop (see 8.9); similarly, a generate parameter is a constant within the corresponding generate statement (see 9.7). A subelement or slice of a constant is a constant.

145

It is an error if a constant declaration declares a constant that is of a ﬁle type, an access type, a protected
type, or a composite type that has a subelement that is a ﬁle type, an access type, or a protected type.
NOTE—The subelements of a composite declared constant are not declared constants.

Examples:
constant TOLER : DISTANCE := 1.5 nm;
constant PI : REAL := 3.141592 ;
constant CYCLE_TIME : TIME := 100 ns;
constant Propagation_Delay : DELAY_LENGTH;

150

58

-- A deferred constant.

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

4.3.1.2 Signal declarations
A signal declaration declares a signal of the speciﬁed type. Such a signal is an explicitly declared signal.

155

signal_declaration ::=
signal identiﬁer_list : subtype_indication [ signal_kind ] [ := expression ] ;
signal_kind ::= register | bus
If the name of a resolution function appears in the declaration of a signal or in the declaration of the subtype
used to declare the signal, then that resolution function is associated with the declared signal. Such a signal
is called a resolved signal.

160

165

170

175

If a signal kind appears in a signal declaration, then the signals so declared are guarded signals of the kind
indicated. For a guarded signal that is of a composite type, each subelement is likewise a guarded signal. For
a guarded signal that is of an array type, each slice (see 6.5) is likewise a guarded signal. A guarded signal
may be assigned values under the control of Boolean-valued guard expressions (or guards). When a given
guard becomes False, the drivers of the corresponding guarded signals are implicitly assigned a null transaction (see 8.4.1) to cause those drivers to turn off. A disconnection speciﬁcation (see 5.3) is used to specify
the time required for those drivers to turn off.
If the signal declaration includes the assignment symbol followed by an expression, it must be of the same
type as the signal. Such an expression is said to be a default expression. The default expression deﬁnes a
default value associated with the signal or, for a composite signal, with each scalar subelement thereof. For a
signal declared to be of a scalar subtype, the value of the default expression is the default value of the signal.
For a signal declared to be of a composite subtype, each scalar subelement of the value of the default expression is the default value of the corresponding subelement of the signal.
In the absence of an explicit default expression, an implicit default value is assumed for a signal of a scalar
subtype or for each scalar subelement of a composite signal, each of which is itself a signal of a scalar
subtype. The implicit default value for a signal of a scalar subtype T is deﬁned to be that given by T'LEFT.
It is an error if a signal declaration declares a signal that is of a ﬁle type, an access type, a protected type, or
a composite type having a subelement that is a ﬁle type, an access type, or a protected type. It is also an error
if a guarded signal of a scalar type is neither a resolved signal nor a subelement of a resolved signal.

180

185

190

A signal may have one or more sources. For a signal of a scalar type, each source is either a driver (see
12.6.1) or an out, inout, buffer, or linkage port of a component instance or of a block statement with which
the signal is associated. For a signal of a composite type, each composite source is a collection of scalar
sources, one for each scalar subelement of the signal. It is an error if, after the elaboration of a description, a
signal has multiple sources and it is not a resolved signal. It is also an error if, after the elaboration of a
description, a resolved signal has more sources than the number of elements in the index range of the type of
the formal parameter of the resolution function associated with the resolved signal.
If a subelement or slice of a resolved signal of composite type is associated as an actual in a port map aspect
(either in a component instantiation statement or in a binding indication), and if the corresponding formal is
of mode out, inout, buffer, or linkage, then every scalar subelement of that signal must be associated
exactly once with such a formal in the same port map aspect, and the collection of the corresponding formal
parts taken together constitute one source of the signal. If a resolved signal of composite type is associated
as an actual in a port map aspect, that is equivalent to each of its subelements being associated in the same
port map aspect.

Copyright © 2000 IEEE. All rights reserved.

59

IEEE
Std 1076, 2000 Edition

195

IEEE STANDARD VHDL

If a subelement of a resolved signal of composite type has a driver in a given process, then every scalar
subelement of that signal must have a driver in the same process, and the collection of all of those drivers
taken together constitute one source of the signal.
The default value associated with a scalar signal deﬁnes the value component of a transaction that is the
initial contents of each driver (if any) of that signal. The time component of the transaction is not deﬁned,
but the transaction is understood to have already occurred by the start of simulation.
Examples:

200

signal S : STANDARD.BIT_VECTOR (1 to 10) ;
signal CLK1, CLK2 : TIME ;
signal OUTPUT : WIRED_OR MULTI_VALUED_LOGIC;
NOTES

205

1—Ports of any mode are also signals. The term signal is used in this standard to refer to objects declared either by
signal declarations or by port declarations (or to subelements, slices, or aliases of such objects). It also refers to the
implicit signal GUARD (see 9.1) and to implicit signals deﬁned by the predeﬁned attributes 'DELAYED, 'STABLE,
'QUIET, and 'TRANSACTION. The term port is used to refer to objects declared by port declarations only.
2—Signals are given initial values by initializing their drivers. The initial values of drivers are then propagated through
the corresponding net to determine the initial values of the signals that make up the net (see 12.6.3).

210

3—The value of a signal may be indirectly modiﬁed by a signal assignment statement (see 8.4); such assignments affect
the future values of the signal.
4—The subelements of a composite, declared signal are not declared signals.

Cross-references: disconnection speciﬁcations, 5.3; disconnection statements, 9.5; guarded assignment, 9.5;
guarded blocks, 9.1; guarded targets, 9.5; signal guard, 9.1.
4.3.1.3 Variable declarations
215

A variable declaration declares a variable of the speciﬁed type. Such a variable is an explicitly declared
variable.
variable_declaration ::=
[ shared ] variable identiﬁer_list : subtype_indication [ := expression ] ;

220

225

A variable declaration that includes the reserved word shared is a shared variable declaration. A shared
variable declaration declares a shared variable. Shared variables are a subclass of the variable class of
objects. The base type of the subtype indication of a shared variable declaration must be a protected type.
Variables declared immediately within entity declarations, architecture bodies, packages, package bodies,
and blocks must be shared variables. Variables declared immediately within subprograms and processes
must not be shared variables. Variables may appear in protected type bodies; such variables, which must not
be shared variables, represent shared data.
If a given variable declaration appears (directly or indirectly) within a protected type body, then the base
type denoted by the subtype indication of the variable declaration may not be the protected type deﬁned by
the protected type body.

230

If the variable declaration includes the assignment symbol followed by an expression, the expression speciﬁes an initial value for the declared variable; the type of the expression must be that of the variable. Such an
expression is said to be an initial value expression. A variable declaration, whether it is a shared variable
declaration or not, whose subtype indication denotes a protected type may not have an initial value expression (nor may it include the immediately preceding assignment symbol).

60

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

235

240

IEEE
Std 1076, 2000 Edition

If an initial value expression appears in the declaration of a variable, then the initial value of the variable is
determined by that expression each time the variable declaration is elaborated. In the absence of an initial
value expression, a default initial value applies. The default initial value for a variable of a scalar subtype T
is deﬁned to be the value given by T'LEFT. The default initial value of a variable of a composite type is
deﬁned to be the aggregate of the default initial values of all of its scalar subelements, each of which is itself
a variable of a scalar subtype. The default initial value of a variable of an access type is deﬁned to be the
value null for that type.
NOTES
1—The value of a variable that is not a shared variable may be modiﬁed by a variable assignment statement (see 8.5);
such assignments take effect immediately.

245

2—The variables declared within a given procedure persist until that procedure completes and returns to the caller. For
procedures that contain wait statements, a variable may therefore persist from one point in simulation time to another,
and the value in the variable is thus maintained over time. For processes, which never complete, all variables persist from
the beginning of simulation until the end of simulation.
3—The subelements of a composite, declared variable are not declared variables.

250

255

260

4— Since the language guarantees mutual exclusion of accesses to shared data, but not the order of access to such data
by multiple processes in the same simulation cycle, the use of shared varaibles can be both non-portable and non-deterministic. For example, consider the following architecture:

architecture UseSharedVariables of SomeEntity is
subtype ShortRange is INTEGER range -1 to 1;
type ShortRangeProtected is protected
procedure Set(V: ShortRange);
procedure Get(V: out ShortRange);
end protected;
type ShortRangeProtected is protected body
variable Local: ShortRange := 0;
begin
procedure Set(V: ShortRange) is
begin
Local := V;
end procedure Set;

265

procedure Get(V: out ShortRange) is
begin
V := Local;
end procedure Get;
end protected body;

270

shared variable Counter: ShortRangeProtected ;

275

280

285

begin
PROC1: process
variable V: ShortRange;
begin
Counter,Get( V );
Counter.Set( V+1 );
wait;
end process PROC1;
PROC2: process
variable V: ShortRange;
begin
Counter,Get( V );
Counter.Set( V–1 );
wait;
end process PROC2;
end architecture UseSharedVariables;
In particular, the value of Counter after the execution of both processes is not guaranteed to be 0.
5—Variables that are not shared variables may have a subtype indication denoting a protected type.

Copyright © 2000 IEEE. All rights reserved.

61

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

Examples:
variable INDEX : INTEGER range 0 to 99 := 0 ;
-- Initial value is determined by the initial value expression

290

variable COUNT : POSITIVE ;
-- Initial value is POSITIVE'LEFT; that is,1
variable MEMORY : BIT_MATRIX (0 to 7, 0 to 1023) ;
-- Initial value is the aggregate of the initial values of each element

295

shared variable Counter: SharedCounter;
-- See 3.5.1 and 3.5.2 for the deﬁnitions of SharedCounter
shared variable addend, augend, result: ComplexNumber;
-- See 3.5.1 and 3.5.2 for the deﬁnition of ComplexNumber
variable bit_stack: VariableSizeBitArray;
-- See 3.5.1 and 3.5.2 for the deﬁnition of VariableSizeBitArray;

300

4.3.1.4 File declarations
A ﬁle declaration declares a ﬁle of the speciﬁed type. Such a ﬁle is an explicitly declared ﬁle.
ﬁle_declaration ::=
ﬁle identiﬁer_list : subtype_indication [ ﬁle_open_information ] ;
ﬁle_open_information ::= [ open ﬁle_open_kind_expression ] is ﬁle_logical_name

305

ﬁle_logical_name ::= string_expression
The subtype indication of a ﬁle declaration must deﬁne a ﬁle subtype.

310

315

320

If ﬁle open information is included in a given ﬁle declaration, then the ﬁle declared by the declaration is
opened (see 3.4.1) with an implicit call to FILE_OPEN when the ﬁle declaration is elaborated (see 12.3.1.4).
This implicit call is to the FILE_OPEN procedure of the ﬁrst form, and it associates the identiﬁer with the
ﬁle parameter F, the ﬁle logical name with the External_Name parameter, and the ﬁle open kind expression
with the Open_Kind parameter. If a ﬁle open kind expression is not included in the ﬁle open information of
a given ﬁle declaration, then the default value of READ_MODE is used during elaboration of the ﬁle
declaration.
If ﬁle open information is not included in a given ﬁle declaration, then the ﬁle declared by the declaration is
not opened when the ﬁle declaration is elaborated.
The ﬁle logical name must be an expression of predeﬁned type STRING. The value of this expression is
interpreted as a logical name for a ﬁle in the host system environment. An implementation must provide
some mechanism to associate a ﬁle logical name with a host-dependent ﬁle. Such a mechanism is not
deﬁned by the language.
The ﬁle logical name identiﬁes an external ﬁle in the host ﬁle system that is associated with the ﬁle object.
This association provides a mechanism for either importing data contained in an external ﬁle into the design
during simulation or exporting data generated during simulation to an external ﬁle.

325

If multiple ﬁle objects are associated with the same external ﬁle, and each ﬁle object has an access mode that
is read-only (see 3.4.1), then values read from each ﬁle object are read from the external ﬁle associated with
the ﬁle object. The language does not deﬁne the order in which such values are read from the external ﬁle,
nor does it deﬁne whether each value is read once or multiple times (once per ﬁle object).

62

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

330

The language does not deﬁne the order of and the relationship, if any, between values read from and written
to multiple ﬁle objects that are associated with the same external ﬁle. An implementation may restrict the
number of ﬁle objects that may be associated at one time with a given external ﬁle.
If a formal subprogram parameter is of the class ﬁle, it must be associated with an actual that is a ﬁle object.
Examples:
type IntegerFile is ﬁle of INTEGER;
ﬁle F1: IntegerFile;

-- No implicit FILE_OPEN is performed
-- during elaboration.

ﬁle F2: IntegerFile is "test.dat";

-----

335

340

At elaboration, an implicit call is performed:
FILE_OPEN (F2, "test.dat");
The OPEN_KIND parameter defaults to
READ_MODE.

ﬁle F3: IntegerFile open WRITE_MODE is "test.dat";
-- At elaboration, an implicit call is performed:
-- FILE_OPEN (F3, "test.dat", WRITE_MODE);
NOTE—All ﬁle objects associated with the same external ﬁle should be of the same base type.

4.3.2 Interface declarations

345

350

355

An interface declaration declares an interface object of a speciﬁed type. Interface objects include interface
constants that appear as generics of a design entity, a component, or a block, or as constant parameters of
subprograms; interface signals that appear as ports of a design entity, component, or block, or as signal
parameters of subprograms; interface variables that appear as variable parameters of subprograms; interface
ﬁles that appear as ﬁle parameters of subprograms.
interface_declaration ::=
interface_constant_declaration
| interface_signal_declaration
| interface_variable_declaration
| interface_ﬁle_declaration
interface_constant_declaration ::=
[constant] identiﬁer_list : [ in ] subtype_indication [ := static_expression ]
interface_signal_declaration ::=
[signal] identiﬁer_list : [ mode ] subtype_indication [ bus ] [ := static_expression ]
interface_variable_declaration ::=
[variable] identiﬁer_list : [ mode ] subtype_indication [ := static_expression ]

360

interface_ﬁle_declaration ::=
ﬁle identiﬁer_list : subtype_indication
mode ::= in | out | inout | buffer | linkage
If no mode is explicitly given in an interface declaration other than an interface ﬁle declaration, mode in is
assumed.

Copyright © 2000 IEEE. All rights reserved.

63

IEEE
Std 1076, 2000 Edition

365

IEEE STANDARD VHDL

For an interface constant declaration or an interface signal declaration, the subtype indication must deﬁne a
subtype that is neither a ﬁle type, an access type, nor a protected type. Moreover, the subtype indication may
not denote a composite type with a subelement that is a ﬁle type, an access type, or a protected type.
For an interface ﬁle declaration, it is an error if the subtype indication does not denote a subtype of a ﬁle
type.

370

375

If an interface signal declaration includes the reserved word bus, then the signal declared by that interface
declaration is a guarded signal of signal kind bus.
If an interface declaration contains a ":=" symbol followed by an expression, the expression is said to be the
default expression of the interface object. The type of a default expression must be that of the corresponding
interface object. It is an error if a default expression appears in an interface declaration and any of the
following conditions hold:
—

The mode is linkage.

—

The interface object is a formal signal parameter.

—

The interface object is a formal variable parameter of mode other than in.

—

The subtype indication of the interface declaration denotes a protected type.

380

In an interface signal declaration appearing in a port list, the default expression deﬁnes the default value(s)
associated with the interface signal or its subelements. In the absence of a default expression, an implicit
default value is assumed for the signal or for each scalar subelement, as deﬁned for signal declarations (see
4.3.1.2). The value, whether implicitly or explicitly provided, is used to determine the initial contents of
drivers, if any, of the interface signal as speciﬁed for signal declarations.

385

An interface object provides a channel of communication between the environment and a particular portion
of a description. The value of an interface object may be determined by the value of an associated object or
expression in the environment; similarly, the value of an object in the environment may be determined by the
value of an associated interface object. The manner in which such associations are made is described in
4.3.2.2.

390

The value of an object is said to be read when one of the following conditions is satisﬁed:

395

400

—

When the object is evaluated, and also (indirectly) when the object is associated with an interface
object of the modes in, inout, or linkage

—

When the object is a signal and a name denoting the object appears in a sensitivity list in a wait statement or a process statement

—

When the object is a signal and the value of any of its predeﬁned attributes 'STABLE, 'QUIET,
'DELAYED, 'TRANSACTION, 'EVENT, 'ACTIVE, 'LAST_EVENT, 'LAST_ACTIVE, or
'LAST_VALUE is read

—

When one of its subelements is read

—

When the object is a ﬁle and a READ operation is performed on the ﬁle

The value of an object is said to be updated when one of the following conditions is satisﬁed:
—
—
—

64

When it is the target of an assignment, and also (indirectly) when the object is associated with an
interface object of the modes out, buffer, inout, or linkage
When one of its subelements is updated
When the object is a ﬁle and a WRITE operation is performed on the ﬁle

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

405

IEEE
Std 1076, 2000 Edition

Only signal, variable, or ﬁle objects may be updated.
An interface object has one of the following modes:
—

in. The value of the interface object may only be read. In addition, any attributes of the interface
object may be read, except that attributes 'STABLE, 'QUIET, 'DELAYED, and 'TRANSACTION of
a subprogram signal parameter may not be read within the corresponding subprogram. For a ﬁle
object, operation ENDFILE is allowed.

—

out. The value of the interface object may be updated. Reading the attributes of the interface element,
other than the predeﬁned attributes 'STABLE, 'QUIET, 'DELAYED, 'TRANSACTION, 'EVENT,
'ACTIVE, 'LAST_EVENT, 'LAST_ACTIVE, and 'LAST_VALUE, is allowed. No other reading is
allowed.

—

inout. The value of the interface object may be both read and updated. Reading the attributes of the
interface object, other than the attributes 'STABLE, 'QUIET, 'DELAYED, and 'TRANSACTION of a
signal parameter, is also permitted. For a ﬁle object, all ﬁle operations (see 3.4.1) are allowed.

—

buffer. The value of the interface object may be both read and updated. Reading the attributes of the
interface object is also permitted.

—

linkage. The value of the interface object may be read or updated, but only by appearing as an actual
corresponding to an interface object of mode linkage. No other reading or updating is permitted.

410

415

420

NOTES

425

1—Although signals of modes inout and buffer have the same characteristics with respect to whether they may be read
or updated, a signal of mode inout may be updated by zero or more sources, whereas a signal of mode buffer must be
updated by at most one source (see 1.1.1.2).
2—A subprogram parameter that is of a ﬁle type must be declared as a ﬁle parameter.
3—Since shared variables are a subclass of variables, a shared variable may be associated as an actual with a formal of
class variable.

4.3.2.1 Interface lists

430

An interface list contains the declarations of the interface objects required by a subprogram, a component, a
design entity, or a block statement.
interface_list ::=
interface_element { ; interface_element }
interface_element ::= interface_declaration

435

A generic interface list consists entirely of interface constant declarations. A port interface list consists
entirely of interface signal declarations. A parameter interface list may contain interface constant
declarations, interface signal declarations, interface variable declarations, interface ﬁle declarations, or any
combination thereof.
A name that denotes an interface object may not appear in any interface declaration within the interface list
containing the denoted interface object except to declare this object.

Copyright © 2000 IEEE. All rights reserved.

65

IEEE
Std 1076, 2000 Edition

440

IEEE STANDARD VHDL

NOTE—The restriction mentioned in the previous sentence makes the following three interface lists illegal:
entity E is
generic
port
procedure X

445

(G1:
(P1:

INTEGER;
STRING;

(Y1, Y2: INTEGER;

G2:
P2:
Y3:

INTEGER := G1);
STRING(P1'RANGE));
INTEGER range Y1 to Y2);

-- Illegal
-- Illegal
-- Illegal

end E;
However, the following interface lists are legal:
entity E is
generic
port
procedure X
end E;

450

(G1, G2, G3, G4:
(P1, P2:
(Y3:

INTEGER);
STRING (G1 to G2));
INTEGER range G3 to G4);

4.3.2.2 Association lists
An association list establishes correspondences between formal or local generic, port, or parameter names
on the one hand and local or actual names or expressions on the other.
association_list ::=
association_element { , association_element }

455

association_element ::=
[ formal_part => ] actual_part
formal_part ::=
formal_designator
| function_name ( formal_designator )
| type_mark ( formal_designator )

460

formal_designator ::=
generic_name
| port_name
| parameter_name

465

actual_part ::=
actual_designator
| function_name ( actual_designator )
| type_mark ( actual_designator )
actual_designator ::=
expression
| signal_name
| variable_name
| ﬁle_name
| open

470

475

Each association element in an association list associates one actual designator with the corresponding interface element in the interface list of a subprogram declaration, component declaration, entity declaration, or
block statement. The corresponding interface element is determined either by position or by name.

66

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

480

IEEE
Std 1076, 2000 Edition

An association element is said to be named if the formal designator appears explicitly; otherwise, it is said to
be positional. For a positional association, an actual designator at a given position in an association list
corresponds to the interface element at the same position in the interface list.
Named associations can be given in any order, but if both positional and named associations appear in the
same association list, then all positional associations must occur ﬁrst at their normal position. Hence once a
named association is used, the rest of the association list must use only named associations.

485

490

495

500

505

510

515

520

In the following paragraphs, the term actual refers to an actual designator, and the term formal refers to a
formal designator.
The formal part of a named element association may be in the form of a function call, where the single argument of the function is the formal designator itself, if and only if the mode of the formal is out, inout,
buffer, or linkage, and if the actual is not open. In this case, the function name must denote a function
whose single parameter is of the type of the formal and whose result is the type of the corresponding actual.
Such a conversion function provides for type conversion in the event that data ﬂows from the formal to the
actual.
Alternatively, the formal part of a named element association may be in the form of a type conversion, where
the expression to be converted is the formal designator itself, if and only if the mode of the formal is out,
inout, buffer, or linkage, and if the actual is not open. In this case, the base type denoted by the type mark
must be the same as the base type of the corresponding actual. Such a type conversion provides for type conversion in the event that data ﬂows from the formal to the actual. It is an error if the type of the formal is not
closely related to the type of the actual. (See 7.3.5.)
Similarly, the actual part of a (named or positional) element association may be in the form of a function
call, where the single argument of the function is the actual designator itself, if and only if the mode of the
formal is in, inout, or linkage, and if the actual is not open. In this case, the function name must denote a
function whose single parameter is of the type of the actual, and whose result is the type of the corresponding formal. In addition, the formal must not be of class constant for this interpretation to hold (the actual is
interpreted as an expression that is a function call if the class of the formal is constant). Such a conversion
function provides for type conversion in the event that data ﬂows from the actual to the formal.
Alternatively, the actual part of a (named or positional) element association may be in the form of a type
conversion, where the expression to be type converted is the actual designator itself, if and only if the mode
of the formal is in, inout, or linkage, and if the actual is not open. In this case, the base type denoted by the
type mark must be the same as the base type of the corresponding formal. Such a type conversion provides
for type conversion in the event that data ﬂows from the actual to the formal. It is an error if the type of the
actual is not closely related to the type of the formal.
The type of the actual (after applying the conversion function or type conversion, if present in the actual
part) must be the same as the type of the corresponding formal, if the mode of the formal is in, inout, or
linkage, and if the actual is not open. Similarly, if the mode of the formal is out, inout, buffer, or linkage,
and if the actual is not open, then the type of the formal (after applying the conversion function or type
conversion, if present in the formal part) must be the same as the corresponding actual.
For the association of signals with corresponding formal ports, association of a formal of a given composite
type with an actual of the same type is equivalent to the association of each scalar subelement of the formal
with the matching subelement of the actual, provided that no conversion function or type conversion is
present in either the actual part or the formal part of the association element. If a conversion function or type
conversion is present, then the entire formal is considered to be associated with the entire actual.

Copyright © 2000 IEEE. All rights reserved.

67

IEEE
Std 1076, 2000 Edition

525

530

535

540

IEEE STANDARD VHDL

Similarly, for the association of actuals with corresponding formal subprogram parameters, association of a
formal parameter of a given composite type with an actual of the same type is equivalent to the association
of each scalar subelement of the formal parameter with the matching subelement of the actual. Different
parameter passing mechanisms may be required in each case, but in both cases the associations will have an
equivalent effect. This equivalence applies provided that no actual is accessible by more than one path (see
2.1.1.1).
A formal may be either an explicitly declared interface object or member (see Clause 3) of such an interface
object. In the former case, such a formal is said to be associated in whole. In the latter cases, named
association must be used to associate the formal and actual; the subelements of such a formal are said to be
associated individually. Furthermore, every scalar subelement of the explicitly declared interface object
must be associated exactly once with an actual (or subelement thereof) in the same association list, and all
such associations must appear in a contiguous sequence within that association list. Each association
element that associates a slice or subelement (or slice thereof) of an interface object must identify the formal
with a locally static name.
If an interface element in an interface list includes a default expression for a formal generic, for a formal port
of any mode other than linkage, or for a formal variable or constant parameter of mode in, then any
corresponding association list need not include an association element for that interface element. If the
association element is not included in the association list, or if the actual is open, then the value of the
default expression is used as the actual expression or signal value in an implicit association element for that
interface element.
It is an error if an actual of open is associated with a formal that is associated individually. An actual of open
counts as the single association allowed for the corresponding formal, but does not supply a constant, signal,
or variable (as is appropriate to the object class of the formal) to the formal.

545

NOTES
1—It is a consequence of these rules that, if an association element is omitted from an association list in order to make
use of the default expression on the corresponding interface element, all subsequent association elements in that association list must be named associations.

550

2—Although a default expression can appear in an interface element that declares a (local or formal) port, such a default
expression is not interpreted as the value of an implicit association element for that port. Instead, the value of the expression is used to determine the effective value of that port during simulation if the port is left unconnected (see 12.6.2).
3—Named association may not be used when invoking implicitly deﬁned operations, since the formal parameters of
these operators are not named (see 7.2).

555

4—Since information ﬂows only from the actual to the formal when the mode of the formal is in, and since a function
call is itself an expression, the actual associated with a formal of object class constant is never interpreted as a conversion function or a type conversion converting an actual designator that is an expression. Thus, the following association
element is legal:
Param => F (open)

560

under the conditions that Param is a constant formal and F is a function returning the same base type as that of Param
and having one or more parameters, all of which may be defaulted.
5—No conversion function or type conversion may appear in the actual part when the actual designator is open.

4.3.3 Alias declarations
An alias declaration declares an alternate name for an existing named entity.
alias_declaration ::=
alias alias_designator [ : subtype_indication ] is name [ signature ] ;
alias_designator ::= identiﬁer | character_literal | operator_symbol

565

68

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

An object alias is an alias whose alias designator denotes an object (i.e., a constant, a variable, a signal, or a
ﬁle). A nonobject alias is an alias whose alias designator denotes some named entity other than an object. An
alias can be declared for all named entities except for labels, loop parameters, and generate parameters.

570

The alias designator in an alias declaration denotes the named entity speciﬁed by the name and, if present,
the signature in the alias declaration. An alias of a signal denotes a signal; an alias of a variable denotes a
variable; an alias of a constant denotes a constant; and an alias of a ﬁle denotes a ﬁle. Similarly, an alias of a
subprogram (including an operator) denotes a subprogram, an alias of an enumeration literal denotes an
enumeration literal, and so forth.
NOTES

575

1—Since, for example, the alias of a variable is a variable, every reference within this document to a designator (a name,
character literal, or operator symbol) that requires the designator to denote a named entity with certain characteristics
(e.g., to be a variable) allows the designator to denote an alias, so long as the aliased name denotes a named entity having
the required characteristics. This situation holds except where aliases are speciﬁcally prohibited.
2—The alias of an overloadable object is itself overloadable.

4.3.3.1 Object aliases
580

The following rules apply to object aliases:
a)

A signature may not appear in a declaration of an object alias.

b)

The name must be a static name (see 6.1) that denotes an object. The base type of the name speciﬁed
in an alias declaration must be the same as the base type of the type mark in the subtype indication
(if the subtype indication is present); this type must not be a multidimensional array type. When the
object denoted by the name is referenced via the alias deﬁned by the alias declaration, the following
rules apply:

585

1)

— If the alias designator denotes a slice of an object, then the subtype of the object is
viewed as if it were of the subtype speciﬁed by the slice.
— Otherwise, the object is viewed as if it were of the subtype speciﬁed in the declaration of
the object denoted by the name.

590

2)

If the subtype indication is present and denotes a constrained array subtype, then the object is
viewed as if it were of the subtype speciﬁed by the subtype indication; moreover, the subtype
denoted by the subtype indication must include a matching element (see 7.2.2) for each element
of the object denoted by the name.

3)

If the subtype indication denotes a scalar subtype, then the object is viewed as if it were of the
subtype speciﬁed by the subtype indication; moreover, it is an error if this subtype does not
have the same bounds and direction as the subtype denoted by the object name.

595

600

If the subtype indication is absent or if it is present and denotes an unconstrained array type

c)

The same applies to attribute references where the preﬁx of the attribute name denotes the alias.

d)

A reference to an element of an object alias is implicitly a reference to the matching element of the
object denoted by the alias. A reference to a slice of an object alias consisting of the elements e1, e2,
..., en is implicitly a reference to a slice of the object denoted by the alias consisting of the matching
elements corresponding to each of e1 through en.

Copyright © 2000 IEEE. All rights reserved.

69

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

4.3.3.2 Nonobject aliases
The following rules apply to nonobject aliases:
605

a)

A subtype indication may not appear in a nonobject alias.

b)

A signature is required if the name denotes a subprogram (including an operator) or enumeration
literal. In this case, the signature is required to match (see 2.3) the parameter and result type proﬁle
of exactly one of the subprograms or enumeration literals denoted by the name.

c)

If the name denotes an enumeration type, then one implicit alias declaration for each of the literals
of the type immediately follows the alias declaration for the enumeration type; each such implicit
declaration has, as its alias designator, the simple name or character literal of the literal and has, as
its name, a name constructed by taking the name of the alias for the enumeration type and substituting the simple name or character literal being aliased for the simple name of the type. Each implicit
alias has a signature that matches the parameter and result type proﬁle of the literal being aliased.

d)

Alternatively, if the name denotes a physical type, then one implicit alias declaration for each of the
units of the type immediately follows the alias declaration for the physical type; each such implicit
declaration has, as its name, a name constructed by taking the name of the alias for the physical type
and substituting the simple name of the unit being aliased for the simple name of the type.

e)

Finally, if the name denotes a type, then implicit alias declarations for each predeﬁned operator for
the type immediately follow the explicit alias declaration for the type and, if present, any implicit
alias declarations for literals or units of the type. Each implicit alias has a signature that matches the
parameter and result type proﬁle of the implicit operator being aliased.

610

615

620

Examples:
variable REAL_NUMBER : BIT_VECTOR (0 to 31);
alias SIGN : BIT is REAL_NUMBER (0);
-- SIGN is now a scalar (BIT) value

625

alias MANTISSA : BIT_VECTOR (23 downto 0) is REAL_NUMBER (8 to 31);
-- MANTISSA is a 24b value whose range is 23 downto 0.
-- Note that the ranges of MANTISSA and REAL_NUMBER (8 to 31)
-- have opposite directions. A reference to MANTISSA (23 downto 18)
-- is equivalent to a reference to REAL_NUMBER (8 to 13).

630

alias EXPONENT : BIT_VECTOR (1 to 7) is REAL_NUMBER (1 to 7);
-- EXPONENT is a 7-bit value whose range is 1 to 7.

635

640

70

alias STD_BIT

is STD.STANDARD.BIT;

-- explicit alias

-- alias '0'
--- alias '1'
--- alias "and"
---- alias "or"
---

is STD.STANDARD.'0'
-- implicit aliases …
[return STD.STANDARD.BIT];
is STD.STANDARD.'1'
[return STD.STANDARD.BIT];
is STD.STANDARD."and"
[STD.STANDARD.BIT, STD.STANDARD.BIT
return STD.STANDARD.BIT];
is STD.STANDARD."or"
[STD.STANDARD.BIT, STD.STANDARD.BIT
return STD.STANDARD.BIT];

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

645

650

655

660

665

670

675

-- alias "nand"
---- alias "nor"
---- alias "xor"
---- alias "xnor"
---- alias "not"
---- alias "="
---- alias "/="
---- alias "<"
---- alias "<="
---- alias ">"
---- alias ">="
---

IEEE
Std 1076, 2000 Edition

is STD.STANDARD."nand"
[STD.STANDARD.BIT, STD.STANDARD.BIT
return STD.STANDARD.BIT];
is STD.STANDARD."nor"
[STD.STANDARD.BIT, STD.STANDARD.BIT
return STD.STANDARD.BIT];
is STD.STANDARD."xor"
[STD.STANDARD.BIT, STD.STANDARD.BIT
return STD.STANDARD.BIT];
is STD.STANDARD."xnor"
[STD.STANDARD.BIT, STD.STANDARD.BIT
return STD.STANDARD.BIT];
is STD.STANDARD."not"
[STD.STANDARD.BIT, STD.STANDARD.BIT
return STD.STANDARD.BIT];
is STD.STANDARD."="
[STD.STANDARD.BIT, STD.STANDARD.BIT
return STD.STANDARD.BOOLEAN];
is STD.STANDARD."/="
[STD.STANDARD.BIT, STD.STANDARD.BIT
return STD.STANDARD.BOOLEAN];
is STD.STANDARD."<"
[STD.STANDARD.BIT, STD.STANDARD.BIT
return STD.STANDARD.BOOLEAN];
is STD.STANDARD."<="
[STD.STANDARD.BIT, STD.STANDARD.BIT
return STD.STANDARD.BOOLEAN];
is STD.STANDARD.">"
[STD.STANDARD.BIT, STD.STANDARD.BIT
return STD.STANDARD.BOOLEAN];
is STD.STANDARD.">="
[STD.STANDARD.BIT, STD.STANDARD.BIT
return STD.STANDARD.BOOLEAN];

NOTE—An alias of an explicitly declared object is not an explicitly declared object, nor is the alias of a subelement or
slice of an explicitly declared object an explicitly declared object.

4.4 Attribute declarations
680

An attribute is a value, function, type, range, signal, or constant that may be associated with one or more
named entities in a description. There are two categories of attributes: predeﬁned attributes and user-deﬁned
attributes. Predeﬁned attributes provide information about named entities in a description. Clause 14
contains the deﬁnition of all predeﬁned attributes. Predeﬁned attributes that are signals may not be updated.
User-deﬁned attributes are constants of arbitrary type. Such attributes are deﬁned by an attribute declaration.

685

attribute_declaration ::=
attribute identiﬁer: type_mark ;
The identiﬁer is said to be the designator of the attribute. An attribute may be associated with an entity
declaration, an architecture, a conﬁguration, a procedure, a function, a package, a type, a subtype, a constant,
a signal, a variable, a quantity, a terminal, a component, a label, a literal, a unit, a group, or a ﬁle.

Copyright © 2000 IEEE. All rights reserved.

71

IEEE
Std 1076, 2000 Edition

690

IEEE STANDARD VHDL

It is an error if the type mark denotes an access type, a ﬁle type, a protected type, or a composite type with a
subelement that is an access type, a ﬁle type, or a protected type. The denoted type or subtype need not be
constrained.
Examples:
type COORDINATE is record X,Y: INTEGER; end record;
subtype POSITIVE is INTEGER range 1 to INTEGER'HIGH;
attribute LOCATION: COORDINATE;
attribute PIN_NO: POSITIVE;

695

NOTES
700

705

710

1—A given named entity E will be decorated with the user-deﬁned attribute A if and only if an attribute speciﬁcation for
the value of attribute A exists in the same declarative part as the declaration of E. In the absence of such a speciﬁcation,
an attribute name of the form E'A is illegal.
2—A user-deﬁned attribute is associated with the named entity denoted by the name speciﬁed in a declaration, not with
the name itself. Hence, an attribute of an object can be referenced by using an alias for that object rather than the
declared name of the object as the preﬁx of the attribute name, and the attribute referenced in such a way is the same
attribute (and therefore has the same value) as the attribute referenced by using the declared name of the object as the
preﬁx.
3—A user-deﬁned attribute of a port, signal, variable, or constant of some composite type is an attribute of the entire
port, signal, variable, or constant, not of its elements. If it is necessary to associate an attribute with each element of
some composite object, then the attribute itself can be declared to be of a composite type such that for each element of
the object, there is a corresponding element of the attribute.

4.5 Component declarations
A component declaration declares a virtual design entity interface that may be used in a component
instantiation statement. A component conﬁguration or a conﬁguration speciﬁcation can be used to associate
a component instance with a design entity that resides in a library.
component_declaration ::=
component identiﬁer [ is ]
[ local_generic_clause ]
[ local_port_clause ]
end component [ component_simple_name ] ;

715

720

Each interface object in the local generic clause declares a local generic. Each interface object in the local
port clause declares a local port.
If a simple name appears at the end of a component declaration, it must repeat the identiﬁer of the
component declaration.

4.6 Group template declarations
A group template declaration declares a group template, which deﬁnes the allowable classes of named
entities that can appear in a group.
group_template_declaration ::=
group identiﬁer is ( entity_class_entry_list ) ;

725

72

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

entity_class_entry_list ::=
entity_class_entry { , entity_class_entry }
entity_class_entry ::= entity_class [ <> ]
730

735

A group template is characterized by the number of entity class entries and the entity class at each position.
Entity classes are described in 5.1.
An entity class entry that is an entity class deﬁnes the entity class that may appear at that position in the
group type. An entity class entry that includes a box (<>) allows zero or more group constituents to appear in
this position in the corresponding group declaration; such an entity class entry must be the last one within
the entity class entry list.
Examples:

740

group PIN2PIN is (signal, signal);

-- Groups of this type consist of two signals.

group RESOURCE is (label <>);

-- Groups of this type consist of any number
-- of labels.

group DIFF_CYCLES is (group <>);

-- A group of groups.

4.7 Group declarations
A group declaration declares a group, a named collection of named entities. Named entities are described
in 5.1.
group_declaration ::=
group identiﬁer : group_template_name ( group_constituent_list ) ;
745

group_constituent_list ::= group_constituent { , group_constituent }
group_constituent ::= name | character_literal
It is an error if the class of any group constituent in the group constituent list is not the same as the class
speciﬁed by the corresponding entity class entry in the entity class entry list of the group template.

750

A name that is a group constituent may not be an attribute name (see 6.6), nor, if it contains a preﬁx, may
that preﬁx be a function call.
If a group declaration appears within a package body, and a group constituent within that group declaration
is the same as the simple name of the package body, then the group constituent denotes the package declaration and not the package body. The same rule holds for group declarations appearing within subprogram
bodies containing group constituents with the same designator as that of the enclosing subprogram body.

755

If a group declaration contains a group constituent that denotes a variable of an access type, the group
declaration declares a group incorporating the variable itself, and not the designated object, if any.

Copyright © 2000 IEEE. All rights reserved.

73

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

Examples:

760

74

group G1: RESOURCE (L1, L2);

-- A group of two labels.

group G2: RESOURCE (L3, L4, L5);

-- A group of three labels.

group C2Q: PIN2PIN (PROJECT.GLOBALS.CK, Q);

-- Groups may associate named
-- entities in different declarative
-- parts (and regions).

group CONSTRAINT1: DIFF_CYCLES (G1, G3);

-- A group of groups.

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

5. Speciﬁcations
This clause describes speciﬁcations, which may be used to associate additional information with a VHDL
description. A speciﬁcation associates additional information with a named entity that has been previously
declared. There are three kinds of speciﬁcations: attribute speciﬁcations, conﬁguration speciﬁcations, and
disconnection speciﬁcations.
5

10

A speciﬁcation always relates to named entities that already exist; thus a given speciﬁcation must either
follow or (in certain cases) be contained within the declaration of the entity to which it relates. Furthermore,
a speciﬁcation must always appear either immediately within the same declarative part as that in which the
declaration of the named entity appears, or (in the case of speciﬁcations that relate to design units or the
interface objects of design units, subprograms, or block statements) immediately within the declarative part
associated with the declaration of the design unit, subprogram body, or block statement.

5.1 Attribute speciﬁcation
An attribute speciﬁcation associates a user-deﬁned attribute with one or more named entities and deﬁnes the
value of that attribute for those entities. The attribute speciﬁcation is said to decorate the named entity.
attribute_speciﬁcation ::=
attribute attribute_designator of entity_speciﬁcation is expression ;
15

20

25

entity_speciﬁcation ::=
entity_name_list : entity_class
entity_class ::=
entity
| procedure
| type
| signal
| label
| group

| architecture
| function
| subtype
| variable
| literal
| ﬁle

| conﬁguration
| package
| constant
| component
| units

entity_name_list ::=
entity_designator { , entity_designator }
| others
| all
entity_designator ::= entity_tag [ signature ]
entity_tag ::= simple_name | character_literal | operator_symbol

30

35

40

The attribute designator must denote an attribute. The entity name list identiﬁes those named entities, both
implicitly and explicitly deﬁned, that inherit the attribute, described as follows:
—

If a list of entity designators is supplied, then the attribute speciﬁcation applies to the named entities
denoted by those designators. It is an error if the class of those names is not the same as that denoted
by the entity class.

—

If the reserved word others is supplied, then the attribute speciﬁcation applies to named entities of
the speciﬁed class that are declared in the immediately enclosing declarative part, provided that each
such entity is not explicitly named in the entity name list of a previous attribute speciﬁcation for the
given attribute.

—

If the reserved word all is supplied, then the attribute speciﬁcation applies to all named entities of the
speciﬁed class that are declared in the immediately enclosing declarative part.

Copyright © 2000 IEEE. All rights reserved.

75

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

An attribute speciﬁcation with the entity name list others or all for a given entity class that appears in a
declarative part must be the last such speciﬁcation for the given attribute for the given entity class in that
declarative part. No named entity in the speciﬁed entity class may be declared in a given declarative part
following such an attribute speciﬁcation.
45

If a name in an entity name list denotes a subprogram or package, it denotes the subprogram declaration or
package declaration. Subprogram and package bodies cannot be attributed.
An entity designator that denotes an alias of an object is required to denote the entire object, not a member of
an object.

50

55

60

65

The entity tag of an entity designator containing a signature must denote the name of one or more subprograms or enumeration literals. In this case, the signature must match (see 2.3.2) the parameter and result type
proﬁle of exactly one subprogram or enumeration literal in the current declarative part; the enclosing
attribute speciﬁcation then decorates that subprogram or enumeration literal.
The expression speciﬁes the value of this attribute for each of the named entities inheriting the attribute as a
result of this attribute speciﬁcation. The type of the expression in the attribute speciﬁcation must be the same
as (or implicitly convertible to) the type mark in the corresponding attribute declaration. If the entity name
list denotes an entity interface, architecture body, or conﬁguration declaration, then the expression is
required to be locally static (see 7.4).
An attribute speciﬁcation for an attribute of a design unit (i.e., an entity interface, an architecture, a conﬁguration, or a package) must appear immediately within the declarative part of that design unit. Similarly, an
attribute speciﬁcation for an attribute of an interface object of a design unit, subprogram, or block statement
must appear immediately within the declarative part of that design unit, subprogram, or block statement. An
attribute speciﬁcation for an attribute of a procedure, a function, a type, a subtype, an object (i.e., a constant,
a ﬁle, a signal, or a variable), a component, literal, unit name, group, or a labeled entity must appear within
the declarative part in which that procedure, function, type, subtype, object, component, literal, unit name,
group, or label, respectively, is explicitly or implicitly declared.
For a given named entity, the value of a user-deﬁned attribute of that entity is the value speciﬁed in an
attribute speciﬁcation for that attribute of that entity.

70

It is an error if a given attribute is associated more than once with a given named entity. Similarly, it is an
error if two different attributes with the same simple name (whether predeﬁned or user-deﬁned) are both
associated with a given named entity.
An entity designator that is a character literal is used to associate an attribute with one or more character
literals. An entity designator that is an operator symbol is used to associate an attribute with one or more
overloaded operators.

75

The decoration of a named entity that can be overloaded attributes all named entities matching the
speciﬁcation already declared in the current declarative part.
If an attribute speciﬁcation appears, it must follow the declaration of the named entity with which the
attribute is associated, and it must precede all references to that attribute of that named entity. Attribute speciﬁcations are allowed for all user-deﬁned attributes, but are not allowed for predeﬁned attributes.

80

An attribute speciﬁcation may reference a named entity by using an alias for that entity in the entity name
list, but such a reference counts as the single attribute speciﬁcation that is allowed for a given attribute and
therefore prohibits a subsequent speciﬁcation that uses the declared name of the entity (or any other alias) as
the entity designator.

76

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

85

IEEE
Std 1076, 2000 Edition

An attribute speciﬁcation whose entity designator contains no signature and identiﬁes an overloaded subprogram has the effect of associating that attribute with each of the designated overloaded subprograms
declared within that declarative part.
Examples:

90

attribute PIN_NO of CIN: signal is 10;
attribute PIN_NO of COUT: signal is 5;
attribute LOCATION of ADDER1: label is (10,15);
attribute LOCATION of others: label is (25,77);
attribute CAPACITANCE of all: signal is 15 pF;
attribute IMPLEMENTATION of G1: group is "74LS152";
attribute RISING_DELAY of C2Q: group is 7.2 ns;
NOTES

95

1—User-deﬁned attributes represent local information only and cannot be used to pass information from one description
to another. For instance, assume some signal X in an architecture body has some attribute A. Further, assume that X is
associated with some local port L of component C. C in turn is associated with some design entity E(B), and L is associated with E’s formal port P. Neither L nor P has attributes with the simple name A, unless such attributes are supplied via
other attribute speciﬁcations; in this latter case, the values of P'A and X'A are not related in any way.

100

2—The local ports and generics of a component declaration cannot be attributed, since component declarations lack a
declarative part.
3—If an attribute speciﬁcation applies to an overloadable named entity, then declarations of additional named entities
with the same simple name are allowed to occur in the current declarative part unless the aforementioned attribute
speciﬁcation has as its entity name list either of the reserved words others or all.

105

4—Attribute speciﬁcations supplying either of the reserved words others or all never apply to the interface objects of
design units, block statements, or subprograms.
5—An attribute speciﬁcation supplying either of the reserved words others or all may apply to none of the named
entities in the current declarative part, in the event that none of the named entities in the current declarative part meet all
of the requirements of the attribute speciﬁcation.

5.2 Conﬁguration speciﬁcation
110

A conﬁguration speciﬁcation associates binding information with component labels representing instances
of a given component declaration.
conﬁguration_speciﬁcation ::=
for component_speciﬁcation binding_indication;

115

component_speciﬁcation ::=
instantiation_list : component_name
instantiation_list ::=
instantiation_label { , instantiation_label }
| others
| all

Copyright © 2000 IEEE. All rights reserved.

77

IEEE
Std 1076, 2000 Edition

120

IEEE STANDARD VHDL

The instantiation list identiﬁes those component instances with which binding information is to be associated, deﬁned as follows:
—

If a list of instantiation labels is supplied, then the conﬁguration speciﬁcation applies to the corresponding component instances. Such labels must be (implicitly) declared within the immediately
enclosing declarative part. It is an error if these component instances are not instances of the component declaration named in the component speciﬁcation. It is also an error if any of the labels denote a
component instantiation statement whose corresponding instantiated unit does not name a component.

—

If the reserved word others is supplied, then the conﬁguration speciﬁcation applies to instances of
the speciﬁed component declaration whose labels are (implicitly) declared in the immediately
enclosing declarative part, provided that each such component instance is not explicitly named in the
instantiation list of a previous conﬁguration speciﬁcation. This rule applies only to those component
instantiation statements whose corresponding instantiated units name components.

—

If the reserved word all is supplied, then the conﬁguration speciﬁcation applies to all instances of the
speciﬁed component declaration whose labels are (implicitly) declared in the immediately enclosing
declarative part. This rule applies only to those component instantiation statements whose corresponding instantiated units name components.

125

130

135

A conﬁguration speciﬁcation with the instantiation list others or all for a given component name that
appears in a declarative part must be the last such speciﬁcation for the given component name in that declarative part.

140

145

The elaboration of a conﬁguration speciﬁcation results in the association of binding information with the
labels identiﬁed by the instantiation list. A label that has binding information associated with it is said to be
bound. It is an error if the elaboration of a conﬁguration speciﬁcation results in the association of binding
information with a component label that is already bound.
NOTE—A conﬁguration speciﬁcation supplying either of the reserved words others or all may apply to none of the
component instances in the current declarative part. This is the case when none of the component instances in the current
declarative part meet all of the requirements of the given conﬁguration speciﬁcation.

5.2.1 Binding indication
A binding indication associates instances of a component declaration with a particular design entity. It may
also associate actuals with formals declared in the entity interface.
binding_indication ::=
[ use entity_aspect ]
[ generic_map_aspect ]
[ port_map_aspect ]

150

155

The entity aspect of a binding indication, if present, identiﬁes the design entity with which the instances of a
component are associated. If present, the generic map aspect of a binding indication identiﬁes the expressions to be associated with formal generics in the design entity interface. Similarly, the port map aspect of a
binding indication identiﬁes the signals or values to be associated with formal ports in the design entity
interface.
When a binding indication is used in a conﬁguration speciﬁcation, it is an error if the entity aspect is absent.

160

A binding indication appearing in a component conﬁguration need not have an entity aspect under the
following condition: The block corresponding to the block conﬁguration in which the given component
conﬁguration appears is required to have one or more conﬁguration speciﬁcations that together conﬁgure all
component instances denoted in the given component conﬁguration. Under this circumstance, these binding

78

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

165

indications are the primary binding indications. It is an error if a binding indication appearing in a component conﬁguration does not have an entity aspect and there are no primary binding indications. It is also an
error if, under these circumstances, the binding indication has neither a generic map aspect nor a port map
aspect. This form of binding indication is the incremental binding indication, and it is used to incrementally
rebind the ports and generics of the denoted instance(s) under the following conditions:
—

For each formal generic appearing in the generic map aspect of the incremental binding indication
and denoting a formal generic that is unassociated or associated with open in any of the primary
binding indications, the given formal generic is bound to the actual with which it is associated in the
generic map aspect of the incremental binding indication.

—

For each formal generic appearing in the generic map aspect of the incremental binding indication
and denoting a formal generic that is associated with an actual other than open in one of the primary
binding indications, the given formal generic is rebound to the actual with which it is associated in
the generic map aspect of the incremental binding indication. That is, the association given in the
primary binding indication has no effect for the given instance.

—

For each formal port appearing in the port map aspect of the incremental binding indication and
denoting a formal port that is unassociated or associated with open in any of the primary binding
indications, the given formal port is bound to the actual with which it is associated in the port map
aspect of the incremental binding indication.

—

It is an error if a formal port appears in the port map aspect of the incremental binding indication and
it is a formal port that is associated with an actual other than open in one of the primary binding
indications.

170

175

180

IEEE
Std 1076, 2000 Edition

If the generic map aspect or port map aspect of a binding indication is not present, then the default rules as
described in 5.2.2 apply.
185

Examples:
entity AND_GATE is
generic (I1toO, I2toO: DELAY_LENGTH := 4 ns);
port
(I1, I2: in BIT;
O: out BIT);
end entity AND_GATE;

190

195

200

entity XOR_GATE is
generic (I1toO, I2toO : DELAY_LENGTH := 4 ns);
port
(I1, I2: in BIT;
O : out BIT);
end entity XOR_GATE;
package MY_GATES is
component AND_GATE is
generic (I1toO, I2toO: DELAY_LENGTH := 4 ns);
port
(I1, I2: in BIT;
O: out BIT);
end component AND_GATE;
component XOR_GATE is
generic
(I1toO, I2toO: DELAY_LENGTH := 4 ns);
port
(I1, I2: in BIT; O : out BIT);
end component XOR_GATE;
end package MY_GATES;

Copyright © 2000 IEEE. All rights reserved.

79

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

entity Half_Adder is
port (X, Y: in BIT;
Sum, Carry: out BIT);
end entity Half_Adder;

205

use WORK.MY_GATES.all;
architecture Structure of Half_Adder is
for L1: XOR_GATE use
entity WORK.XOR_GATE(Behavior)
generic map (3 ns, 3 ns)
port map (I1 => I1, I2 => I2, O => O);

210

for L2: AND_GATE use
entity WORK.AND_GATE(Behavior)
generic map (3 ns, 4 ns)
port map (I1, open, O);

215

-- The primary binding indication
-- for instance L1.

-- The primary binding indication
-- for instance L2.

begin
L1: XOR_GATE
L2: AND_GATE
end architecture Structure;

220

port map (X, Y, Sum);
port map (X, Y, Carry);

use WORK.GLOBAL_SIGNALS.all;
conﬁguration Different of Half_Adder is
for Structure
for L1: XOR_GATE
generic map (2.9 ns, 3.6 ns);
end for;

225

for L2: AND_GATE
generic map (2.8 ns, 3.25 ns)
port map (I2 => Tied_High);
end for;
end for;
end conﬁguration Different;

230

-- The incremental binding
-- indication of L1; rebinds its generics.
-- The incremental binding
-- indication L2; rebinds its generics
-- and binds its open port.

5.2.1.1 Entity aspect

235

An entity aspect identiﬁes a particular design entity to be associated with instances of a component. An
entity aspect may also specify that such a binding is to be deferred.
entity_aspect ::=
entity entity_name [ ( architecture_identiﬁer) ]
| conﬁguration conﬁguration_name
| open

240

245

The ﬁrst form of entity aspect identiﬁes a particular entity declaration and (optionally) a corresponding
architecture body. If no architecture identiﬁer appears, then the immediately enclosing binding indication is
said to imply the design entity whose interface is deﬁned by the entity declaration denoted by the entity name
and whose body is deﬁned by the default binding rules for architecture identiﬁers (see 5.2.2). If an
architecture identiﬁer appears, then the immediately enclosing binding indication is said to imply the design
entity consisting of the entity declaration denoted by the entity name together with an architecture body
associated with the entity declaration; the architecture identiﬁer deﬁnes a simple name that is used during the
elaboration of a design hierarchy to select the appropriate architecture body. In either case, the corresponding component instances are said to be fully bound.

80

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

250

255

260

IEEE
Std 1076, 2000 Edition

At the time of the analysis of an entity aspect of the ﬁrst form, the library unit corresponding to the entity
declaration denoted by the entity name is required to exist; moreover, the design unit containing the entity
aspect depends on the denoted entity declaration. If the architecture identiﬁer is also present, the library unit
corresponding to the architecture identiﬁer is required to exist only if the binding indication is part of a component conﬁguration containing explicit block conﬁgurations or explicit component conﬁgurations; only in
this case does the design unit containing the entity aspect also depend on the denoted architecture body. In
any case, the library unit corresponding to the architecture identiﬁer is required to exist at the time that the
design entity implied by the enclosing binding indication is bound to the component instance denoted by the
component conﬁguration or conﬁguration speciﬁcation containing the binding indication; if the library unit
corresponding to the architecture identiﬁer was required to exist during analysis, it is an error if the
architecture identiﬁer does not denote the same library unit as that denoted during analysis. The library unit
corresponding to the architecture identiﬁer, if it exists, must be an architecture body associated with the
entity declaration denoted by the entity name.
The second form of entity aspect identiﬁes a design entity indirectly by identifying a conﬁguration. In this
case, the entity aspect is said to imply the design entity at the apex of the design hierarchy that is deﬁned by
the conﬁguration denoted by the conﬁguration name.

265

270

At the time of the analysis of an entity aspect of the second form, the library unit corresponding to the
conﬁguration name is required to exist. The design unit containing the entity aspect depends on the conﬁguration denoted by the conﬁguration name.
The third form of entity aspect is used to specify that the identiﬁcation of the design entity is to be deferred.
In this case, the immediately enclosing binding indication is said to not imply any design entity. Furthermore, the immediately enclosing binding indication must not include a generic map aspect or a port map
aspect.
5.2.1.2 Generic map and port map aspects
A generic map aspect associates values with the formal generics of a block. Similarly, a port map aspect
associates signals or values with the formal ports of a block. The following applies to both external blocks
deﬁned by design entities and to internal blocks deﬁned by block statements.

275

generic_map_aspect ::=
generic map ( generic_association_list )
port_map_aspect ::=
port map ( port_association_list )
Both named and positional association are allowed in a port or generic association list.

280

The following deﬁnitions are used in the remainder of this subclause:
—
—

The term actual refers to an actual designator that appears either in an association element of a port
association list or in an association element of a generic association list.
The term formal refers to a formal designator that appears either in an association element of a port
association list or in an association element of a generic association list.

Copyright © 2000 IEEE. All rights reserved.

81

IEEE
Std 1076, 2000 Edition

285

The purpose of port and generic map aspects is as follows:
—

Generic map aspects and port map aspects appearing immediately within a binding indication
associate actuals with the formals of the design entity interface implied by the immediately enclosing
binding indication. No scalar formal may be associated with more than one actual. No scalar subelement of any composite formal may be associated more than once in the same association list.
Each scalar subelement of every local port of the component instances to which an enclosing conﬁguration speciﬁcation or component conﬁguration applies must be associated as an actual with at least
one formal or with a scalar subelement thereof. The actuals of these associations for a given local
port may be the entire local port or any slice or subelement (or slice thereof) of the local port. The
actuals in these associations must be locally static names.

290

295

300

305

IEEE STANDARD VHDL

—

Generic map aspects and port map aspects appearing immediately within a component instantiation
statement associate actuals with the formals of the component instantiated by the statement. No
scalar formal may be associated with more than one actual. No scalar subelement of any composite
formal may be associated with more than one scalar subelement of an actual.

—

Generic map aspects and port map aspects appearing immediately within a block header associate
actuals with the formals deﬁned by the same block header. No scalar formal may be associated with
more than one actual. No scalar subelement of any composite formal may be associated with more
than one actual or with a scalar subelement thereof.

An actual associated with a formal generic in a generic map aspect must be an expression or the reserved
word open; an actual associated with a formal port in a port map aspect must be a signal, an expression, or
the reserved word open.
Certain restrictions apply to the actual associated with a formal port in a port map aspect; these restrictions
are described in 1.1.1.2.
A formal that is not associated with an actual is said to be an unassociated formal.

310

NOTE—A generic map aspect appearing immediately within a binding indication need not associate every formal
generic with an actual. These formals may be left unbound so that, for example, a component conﬁguration within a
conﬁguration declaration may subsequently bind them.

Example:
entity Buf is
generic (Buf_Delay: TIME := 0 ns);
port (Input_pin: in Bit; Output_pin: out Bit);
end Buf;

315

architecture DataFlow of Buf is
begin
Output_pin <= Input_pin after Buf_Delay;
end DataFlow;

320

entity Test_Bench is
end Test_Bench;
architecture Structure of Test_Bench is
component Buf is
generic (Comp_Buf_Delay: TIME);
port (Comp_I: in Bit; Comp_O: out Bit);
end component;

325

82

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

-- A binding indication; generic and port map aspects within a binding indication
-- associate actuals (Comp_I, etc.) with formals of the design entity interface
-- (Input_pin, etc.):
for UUT: Buf
use entity Work.Buf(DataFlow)
generic map (Buf_Delay => Comp_Buf_Delay)
port map (Input_pin => Comp_I, Output_pin=> Comp_O);

330

signal S1,S2: Bit;

335

begin
-- A component instantiation statement; generic and port map aspects within a
-- component instantiation statement associate actuals (S1, etc.) with the
-- formals of a component (Comp_I, etc.):
UUT: Buf
generic map(Comp_Buf_Delay => 50 ns)
port map(Comp_I => S1, Comp_O => S2);

340

345

350

-- A block statement; generic and port map aspects within the block header of a block
-- statement associate actuals (4, etc.) with the formals deﬁned in the block header:
B: block
generic (G: INTEGER);
generic map(G => 4);
begin
end block;
end Structure;
NOTE—A local generic (from a component declaration) or formal generic (from a block statement or from the entity
declaration of the enclosing design entity) may appear as an actual in a generic map aspect. Similarly, a local port (from
a component declaration) or formal port (from a block statement or from the entity declaration of the enclosing design
entity) may appear as an actual in a port map aspect.

5.2.2 Default binding indication
355

In certain circumstances, a default binding indication will apply in the absence of an explicit binding indication. The default binding indication consists of a default entity aspect, together with a default generic map
aspect and a default port map aspect, as appropriate.
If no visible entity declaration has the same simple name as that of the instantiated component, then the
default entity aspect is open. A visible entity declaration is either

360

365

a)

An entity declaration that has the same simple name as that of the instantiated component and that is
directly visible (see 10.3), or

b)

An entity declaration that has the same simple name as that of the instantiated component and that
would be directly visible in the absence of a directly visible (see 10.3) component declaration with
the same simple name as that of the entity declaration.

These visibility checks are made at the point of the absent explicit binding indication that causes the default
binding indication to apply.

Copyright © 2000 IEEE. All rights reserved.

83

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

Otherwise, the default entity aspect is of the form
entity entity_name ( architecture_identiﬁer )

370

375

where the entity name is the simple name of the instantiated component, and the architecture identiﬁer is the
same as the simple name of the most recently analyzed architecture body associated with the entity declaration. If this rule is applied either to a binding indication contained within a conﬁguration speciﬁcation or to a
component conﬁguration that does not contain an explicit inner block conﬁguration, then the architecture
identiﬁer is determined during elaboration of the design hierarchy containing the binding indication.
Likewise, if a component instantiation statement contains an instantiated unit containing the reserved word
entity but does not contain an explicitly speciﬁed architecture identiﬁer, this rule is applied during the
elaboration of the design hierarchy containing a component instantiation statement. In all other cases, this
rule is applied during analysis of the binding indication.
It is an error if there is no architecture body associated with the entity interface denoted by an entity name
that is the simple name of the instantiated component.

380

The default binding indication includes a default generic map aspect if the design entity implied by the entity
aspect contains formal generics. The default generic map aspect associates each local generic in the corresponding component instantiation (if any) with a formal of the same simple name. It is an error if such a
formal does not exist or if its mode and type are not appropriate for such an association. Any remaining
unassociated formals are associated with the actual designator open.

385

The default binding indication includes a default port map aspect if the design entity implied by the entity
aspect contains formal ports. The default port map aspect associates each local port in the corresponding
component instantiation (if any) with a formal of the same simple name. It is an error if such a formal does
not exist or if its mode and type are not appropriate for such an association. Any remaining unassociated formals are associated with the actual designator open.

390

If an explicit binding indication lacks a generic map aspect, and if the design entity implied by the entity
aspect contains formal generics, then the default generic map aspect is assumed within that binding indication. Similarly, if an explicit binding indication lacks a port map aspect, and the design entity implied by the
entity aspect contains formal ports, then the default port map aspect is assumed within that binding
indication.

5.3 Disconnection speciﬁcation
395

A disconnection speciﬁcation deﬁnes the time delay to be used in the implicit disconnection of drivers of a
guarded signal within a guarded signal assignment.
disconnection_speciﬁcation ::=
disconnect guarded_signal_speciﬁcation after time_expression;
guarded_signal_speciﬁcation ::=
guarded_signal_list : type_mark

400

signal_list ::=
signal_name { , signal_name }
| others
| all

84

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

405

410

415

IEEE
Std 1076, 2000 Edition

Each signal name in a signal list in a guarded signal speciﬁcation must be a locally static name that denotes
a guarded signal (see 4.3.1.2). Each guarded signal must be an explicitly declared signal or member of such
a signal.
If the guarded signal is a declared signal or a slice thereof, the type mark must be the same as the type mark
indicated in the guarded signal speciﬁcation (see 4.3.1.2). If the guarded signal is an array element of an
explicitly declared signal, the type mark must be the same as the element subtype indication in the (explicit
or implicit) array type declaration that declares the base type of the explicitly declared signal. If the guarded
signal is a record element of an explicitly declared signal, then the type mark must be the same as the type
mark in the element subtype deﬁnition of the record type declaration that declares the type of the explicitly
declared signal. Each signal must be declared in the declarative part enclosing the disconnection
speciﬁcation.
Subject to the aforementioned rules, a disconnection speciﬁcation applies to the drivers of a guarded signal S
of whose type mark denotes the type T under the following circumstances:
—

For a scalar signal S, if an explicit or implicit disconnection speciﬁcation of the form
disconnect S: T after time_expression;

420

exists, then this disconnection speciﬁcation applies to the drivers of S.
—

For a composite signal S, an explicit or implicit disconnection speciﬁcation of the form
disconnect S: T after time_expression;
is equivalent to a series of implicit disconnection speciﬁcations, one for each scalar subelement of
the signal S. Each disconnection speciﬁcation in the series is created as follows: it has, as its single
signal name in its signal list, a unique scalar subelement of S. Its type mark is the same as the type of
the same scalar subelement of S. Its time expression is the same as that of the original disconnection
speciﬁcation.

425

The characteristics of the disconnection speciﬁcation must be such that each implicit disconnection
speciﬁcation in the series is a legal disconnection speciﬁcation.
430

—

435

If the signal list in an explicit or implicit disconnection speciﬁcation contains more than one signal
name, the disconnection speciﬁcation is equivalent to a series of disconnection speciﬁcations, one for
each signal name in the signal list. Each disconnection speciﬁcation in the series is created as follows: It has, as its single signal name in its signal list, a unique member of the signal list from the
original disconnection speciﬁcation. Its type mark and time expression are the same as those in the
original disconnection speciﬁcation.
The characteristics of the disconnection speciﬁcation must be such that each implicit disconnection
speciﬁcation in the series is a legal disconnection speciﬁcation.

—

An explicit disconnection speciﬁcation of the form
disconnect others: T after time_expression;

440

445

is equivalent to an implicit disconnection speciﬁcation where the reserved word others is replaced
with a signal list comprised of the simple names of those guarded signals that are declared signals
declared in the enclosing declarative part, whose type mark is the same as T, and that do not
otherwise have an explicit disconnection speciﬁcation applicable to its drivers; the remainder of the
disconnection speciﬁcation is otherwise unchanged. If there are no guarded signals in the enclosing
declarative part whose type mark is the same as T and that do not otherwise have an explicit
disconnection speciﬁcation applicable to its drivers, then the above disconnection speciﬁcation has
no effect.
The characteristics of the explicit disconnection speciﬁcation must be such that the implicit disconnection speciﬁcation, if any, is a legal disconnection speciﬁcation.

Copyright © 2000 IEEE. All rights reserved.

85

IEEE
Std 1076, 2000 Edition

450

—

IEEE STANDARD VHDL

An explicit disconnection speciﬁcation of the form
disconnect all: T after time_expression;
is equivalent to an implicit disconnection speciﬁcation where the reserved word all is replaced with
a signal list comprised of the simple names of those guarded signals that are declared signals
declared in the enclosing declarative part and whose type mark is the same as T; the remainder of the
disconnection speciﬁcation is otherwise unchanged. If there are no guarded signals in the enclosing
declarative part whose type mark is the same as T, then the above disconnection speciﬁcation has no
effect.

455

The characteristics of the explicit disconnection speciﬁcation must be such that the implicit
disconnection speciﬁcation, if any, is a legal disconnection speciﬁcation.
460

A disconnection speciﬁcation with the signal list others or all for a given type that appears in a declarative
part must be the last such speciﬁcation for the given type in that declarative part. No guarded signal of the
given type may be declared in a given declarative part following such a disconnection speciﬁcation.
The time expression in a disconnection speciﬁcation must be static and must evaluate to a non-negative
value.

465

It is an error if more than one disconnection speciﬁcation applies to drivers of the same signal.
If, by the aforementioned rules, no disconnection speciﬁcation applies to the drivers of a guarded, scalar
signal S whose type mark is T (including a scalar subelement of a composite signal), then the following
default disconnection speciﬁcation is implicitly assumed:
disconnect S : T after 0 ns;

470

A disconnection speciﬁcation that applies to the drivers of a guarded signal S is the applicable disconnection
speciﬁcation for the signal S.
Thus the implicit disconnection delay for any guarded signal is always deﬁned, either by an explicit
disconnection speciﬁcation or by an implicit one.
NOTES

475

1—A disconnection speciﬁcation supplying either the reserved words others or all may apply to none of the guarded
signals in the current declarative part, in the event that none of the guarded signals in the current declarative part meet all
of the requirements of the disconnection speciﬁcation.
2—Since disconnection speciﬁcations are based on declarative parts, not on declarative regions, ports declared in an
entity interface cannot be referenced by a disconnection speciﬁcation in a corresponding architecture body.

480

Cross-references: disconnection statements, 9.5; guarded assignment, 9.5; guarded blocks, 9.1; guarded
signals, 4.3.1.2; guarded targets, 9.5; signal guard, 9.1.

86

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

6. Names
The rules applicable to the various forms of names are described in this clause.

6.1 Names
Names can denote declared entities, whether declared explicitly or implicitly. Names can also denote

5

10

15

20

—

Objects denoted by access values

—

Methods (see 3.5.1) of protected types

—

Subelements of composite objects

—

Subelements of composite values

—

Slices of composite objects

—

Slices of composite values

—

Attributes of any named entity

name ::=
simple_name
| operator_symbol
| selected_name
| indexed_name
| slice_name
| attribute_name
preﬁx ::=
name
| function_call
Certain forms of name (indexed and selected names, slices, and attribute names) include a preﬁx that is a
name or a function call. If the preﬁx of a name is a function call, then the name denotes an element, a slice,
or an attribute, either of the result of the function call, or (if the result is an access value) of the object designated by the result. Function calls are deﬁned in 7.3.3.

25

If the type of a preﬁx is an access type, then the preﬁx must not be a name that denotes a formal parameter of
mode out or a member thereof.
A preﬁx is said to be appropriate for a type in either of the following cases:
—
—

30

The type of the preﬁx is the type considered.
The type of the preﬁx is an access type whose designated type is the type considered.

The evaluation of a name determines the named entity denoted by the name. The evaluation of a name that
has a preﬁx includes the evaluation of the preﬁx, that is, of the corresponding name or function call. If the
type of the preﬁx is an access type, the evaluation of the preﬁx includes the determination of the object
designated by the corresponding access value. In such a case, it is an error if the value of the preﬁx is a null
access value. It is an error if, after all type analysis (including overload resolution) the name is ambiguous.

Copyright © 2000 IEEE. All rights reserved.

87

IEEE
Std 1076, 2000 Edition

35

IEEE STANDARD VHDL

A name is said to be a static name if and only if one of the following conditions holds:
—

The name is a simple name or selected name (including those that are expanded names) that does not
denote a function call, an object or value of an access type, or an object of a protected type and (in
the case of a selected name) whose preﬁx is a static name.

—

The name is an indexed name whose preﬁx is a static name, and every expression that appears as part
of the name is a static expression.

—

The name is a slice name whose preﬁx is a static name and whose discrete range is a static discrete
range.

40

Furthermore, a name is said to be a locally static name if and only if one of the following conditions hold:
—

The name is a simple name or selected name (including those that are expanded names) that is not an
alias and that does not denote a function call, an object or value of an access type, or an object of a
protected type and (in the case of a selected name) whose preﬁx is a locally static name.

—

The name is a simple name or selected name (including those that are expanded names) that is an
alias, and that the aliased name given in the corresponding alias declaration (see 4.3.3) is a locally
static name, and (in the case of a selected name) whose preﬁx is a locally static name.

—

The name is an indexed name whose preﬁx is a locally static name, and every expression that appears
as part of the name is a locally static expression.

—

The name is a slice name whose preﬁx is a locally static name and whose discrete range is a locally
static discrete range.

45

50

55

A static signal name is a static name that denotes a signal. The longest static preﬁx of a signal name is the
name itself, if the name is a static signal name; otherwise, it is the longest preﬁx of the name that is a static
signal name. Similarly, a static variable name is a static name that denotes a variable, and the longest static
preﬁx of a variable name is the name itself, if the name is a static variable name; otherwise, it is the longest
preﬁx of the name that is a static variable name.
Examples:

60

S(C,2)
R(J to 16)

--A static name: C is a static constant.
--A nonstatic name: J is a signal.
--R is the longest static preﬁx of R(J to 16).

T(n)
T(2)

--A static name; n is a generic constant.
--A locally static name.

6.2 Simple names
65

70

A simple name for a named entity is either the identiﬁer associated with the entity by its declaration, or
another identiﬁer associated with the entity by an alias declaration. In particular, the simple name for an
entity interface, a conﬁguration, a package, a procedure, or a function is the identiﬁer that appears in the
corresponding entity declaration, conﬁguration declaration, package declaration, procedure declaration, or
function declaration, respectively. The simple name of an architecture is that deﬁned by the identiﬁer of the
architecture body.
simple_name ::= identiﬁer
The evaluation of a simple name has no other effect than to determine the named entity denoted by the name.

88

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

6.3 Selected names
A selected name is used to denote a named entity whose declaration appears either within the declaration of
another named entity or within a design library.
75

selected_name ::= preﬁx . sufﬁx

80

sufﬁx ::=
simple_name
| character_literal
| operator_symbol
| all
A selected name may be used to denote an element of a record, an object designated by an access value, or a
named entity whose declaration is contained within another named entity, particularly within a library, a
package, or a protected type. Furthermore, a selected name may be used to denote all named entities whose
declarations are contained within a library or a package.

85

For a selected name that is used to denote a record element, the sufﬁx must be a simple name denoting an
element of a record object or value. The preﬁx must be appropriate for the type of this object or value.
For a selected name that is used to denote the object designated by an access value, the sufﬁx must be the
reserved word all. The preﬁx must belong to an access type.

90

The remaining forms of selected names are called expanded names. The preﬁx of an expanded name may
not be a function call.

95

An expanded name denotes a primary unit contained in a design library if the preﬁx denotes the library and
the sufﬁx is the simple name of a primary unit whose declaration is contained in that library. An expanded
name denotes all primary units contained in a library if the preﬁx denotes the library and the sufﬁx is the
reserved word all. An expanded name is not allowed for a secondary unit, particularly for an architecture
body.
An expanded name denotes a named entity declared in a package if the preﬁx denotes the package and the
sufﬁx is the simple name, character literal, or operator symbol of a named entity whose declaration occurs
immediately within that package. An expanded name denotes all named entities declared in a package if the
preﬁx denotes the package and the sufﬁx is the reserved word all.

100

An expanded name denotes a named entity declared immediately within a named construct if the preﬁx
denotes a construct that is an entity interface, an architecture, a subprogram, a block statement, a process
statement, a generate statement, or a loop statement, and the sufﬁx is the simple name, character literal, or
operator symbol of a named entity whose declaration occurs immediately within that construct. This form of
expanded name is only allowed within the construct itself.

105

An expanded name denotes a named entity declared immediately within a protected type if the preﬁx
denotes an object of a protected type and the sufﬁx is a simple name of a method whose declaration appears
immediately within the protected type declaration.

110

If, according to the visibility rules, there is at least one possible interpretation of the preﬁx of a selected name
as the name of an enclosing entity interface, architecture, subprogram, block statement, process statement,
generate statement, or loop statement, or if there is at least one possible interpretation of the preﬁx of a
selected name as the name of an object of a protected type, then the only interpretations considered are those
of the immediately preceding two paragraphs. In this case, the selected name is always interpreted as an
expanded name. In particular, no interpretations of the preﬁx as a function call are considered.

Copyright © 2000 IEEE. All rights reserved.

89

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

Examples:
115

-- Given the following declarations:

120

type INSTR_TYPE is
record
OPCODE: OPCODE_TYPE;
end record;
signal INSTRUCTION: INSTR_TYPE;
-- The name "INSTRUCTION.OPCODE" is the name of a record element.
-- Given the following declarations:
type INSTR_PTR is access INSTR_TYPE;
variable PTR: INSTR_PTR;
-- The name "PTR.all" is the name of the object designated by PTR.

125

-- Given the following library clause:
library TTL, CMOS;
-- The name "TTL.SN74LS221" is the name of a design unit contained in a library
-- and the name "CMOS.all" denotes all design units contained in a library.
-- Given the following declaration and use clause:

130

library MKS;
use MKS.MEASUREMENTS, STD.STANDARD;
-- The name "MEASUREMENTS.VOLTAGE" denotes a named entity declared in a
-- package and the name "STANDARD.all" denotes all named entities declared in a
-- package.

135

-- Given the following process label and declarative part:
P: process
variable DATA: INTEGER;
begin
-- Within process P, the name "P.DATA" denotes a named entity declared in process P.

140

end process;
counter.increment(5);
-- See 4.3.1.3 for the deﬁnition of "counter."
counter.decrement(i);
if counter.value = 0 then … end if;
145

90

result.add(sv1, sv2);

-- See 4.3.1.3 for the deﬁnition of "result."

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

-- See 4.3.1.3 for the deﬁnition of "bit_stack."

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

NOTES
150

155

1—The object denoted by an access value is accessed differently depending on whether the entire object or a subelement
of the object is desired. If the entire object is desired, a selected name whose preﬁx denotes the access value and whose
sufﬁx is the reserved word all is used. In this case, the access value is not automatically dereferenced, since it is necessary to distinguish an access value from the object denoted by an access value.
If a subelement of the object is desired, a selected name whose preﬁx denotes the access value is again used; however,
the sufﬁx in this case denotes the subelement. In this case, the access value is automatically dereferenced.
These two cases are shown in the following example:
type rec;
type recptr is access rec;

160

165

type rec is
record
value
: INTEGER;
\next\
: recptr;
end record;
variable list1, list2: recptr;
variable recobj: rec;
list2 := list1;
list2 := list1.\next\;

170
recobj := list2.all;

-- Access values are copied;
-- list1 and list2 now denote the same object.
-- list2 denotes the same object as list1.\next\.
-- list1.\next\ is the same as list1.all.\next\.
-- An implicit dereference of the access value occurs before the
-- "\next\” ﬁeld is selected.
-- An explicit dereference is needed here.

2—Overload resolution may be used to disambiguate selected names. See rules a) and c) of 10.5.
175

3—If, according to the rules of this clause and of 10.5, there is not exactly one interpretation of a selected name that satisﬁes these rules, then the selected name is ambiguous.

6.4 Indexed names
An indexed name denotes an element of an array.
indexed_name ::= preﬁx ( expression { , expression } )

180

The preﬁx of an indexed name must be appropriate for an array type. The expressions specify the index
values for the element; there must be one such expression for each index position of the array, and each
expression must be of the type of the corresponding index. For the evaluation of an indexed name, the preﬁx
and the expressions are evaluated. It is an error if an index value does not belong to the range of the corresponding index range of the array.
Examples:

185

REGISTER_ARRAY(5)
MEMORY_CELL(1024,7)

-- An element of a one-dimensional array
-- An element of a two-dimensional array

NOTE—If a name (including one used as a preﬁx) has an interpretation both as an indexed name and as a function call,
then the innermost complete context is used to disambiguate the name. If, after applying this rule, there is not exactly
one interpretation of the name, then the name is ambiguous. See 10.5.

Copyright © 2000 IEEE. All rights reserved.

91

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

6.5 Slice names
190

A slice name denotes a one-dimensional array composed of a sequence of consecutive elements of another
one-dimensional array. A slice of a signal is a signal; a slice of a variable is a variable; a slice of a constant is
a constant; a slice of a value is a value.
slice_name ::= preﬁx ( discrete_range )
The preﬁx of a slice must be appropriate for a one-dimensional array object. The base type of this array type
is the type of the slice.

195

200

The bounds of the discrete range deﬁne those of the slice and must be of the type of the index of the array.
The slice is a null slice if the discrete range is a null range. It is an error if the direction of the discrete range
is not the same as that of the index range of the array denoted by the preﬁx of the slice name.
For the evaluation of a name that is a slice, the preﬁx and the discrete range are evaluated. It is an error if
either of the bounds of the discrete range does not belong to the index range of the preﬁxing array, unless the
slice is a null slice. (The bounds of a null slice need not belong to the subtype of the index.)
Examples:
signal R15: BIT_VECTOR (0 to 31) ;
constant
DATA:
BIT_VECTOR (31 downto 0) ;
R15(0 to 7)
DATA(24 downto 1)
DATA(1 downto 24)
DATA(24 to 25)

205

210

-----

A slice with an ascending range.
A slice with a descending range.
A null slice.
An error.

NOTE—If A is a one-dimensional array of objects, the name A(N to N) or A(N downto N) is a slice that contains one
element; its type is the base type of A. On the other hand, A(N) is an element of the array A and has the corresponding
element type.

6.6 Attribute names
An attribute name denotes a value, function, type, range, signal, or constant associated with a named entity.
attribute_name ::=
preﬁx [ signature ] ' attribute_designator [ ( expression ) ]
attribute_designator ::= attribute_simple_name
215

220

The applicable attribute designators depend on the preﬁx plus the signature, if any. The meaning of the preﬁx
of an attribute must be determinable independently of the attribute designator and independently of the fact
that it is the preﬁx of an attribute.
A signature may follow the preﬁx if and only if the preﬁx denotes a subprogram or enumeration literal, or an
alias thereof. In this case, the signature is required to match (see 2.3.2) the parameter and result type proﬁle
of exactly one visible subprogram or enumeration literal, as is appropriate to the preﬁx.
If the attribute designator denotes a predeﬁned attribute, the expressions either must or may appear, depending upon the deﬁnition of that attribute (see Clause 14); otherwise, they must not be present.

92

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

225

If the preﬁx of an attribute name denotes an alias, then the attribute name denotes an attribute of the aliased
name and not the alias itself, except when the attribute designator denotes any of the predeﬁned attributes
'SIMPLE_NAME, 'PATH_NAME, or 'INSTANCE_NAME. If the preﬁx of an attribute name denotes an alias
and the attribute designator denotes any of the predeﬁned attributes SIMPLE_NAME, 'PATH_NAME, or
'INSTANCE_NAME, then the attribute name denotes the attribute of the alias and not of the aliased name.
If the attribute designator denotes a user-deﬁned attribute, the preﬁx cannot denote a subelement or a slice of
an object.

230

Examples:
REG'LEFT(1)

-- The leftmost index bound of array REG

INPUT_PIN'PATH_NAME

-- The hierarchical path name of the port INPUT_PIN

CLK'DELAYED(5 ns)

-- The signal CLK delayed by 5 ns

Copyright © 2000 IEEE. All rights reserved.

93

IEEE
Std 1076, 2000 Edition

94

IEEE STANDARD VHDL

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

7. Expressions
The rules applicable to the different forms of expression, and to their evaluation, are given in this clause.

7.1 Rules for expressions
An expression is a formula that deﬁnes the computation of a value.

5

10

expression ::=
relation { and relation }
| relation { or relation }
| relation { xor relation }
| relation [ nand relation ]
| relation [ nor relation ]
| relation { xnor relation }
relation ::=
shift_expression [ relational_operator shift_expression ]
shift_expression ::=
simple_expression [ shift_operator simple_expression ]

15

simple_expression ::=
[ sign ] term { adding_operator term }
term ::=
factor { multiplying_operator factor }

20

25

30

factor ::=
primary [ ** primary ]
| abs primary
| not primary
primary ::=
name
| literal
| aggregate
| function_call
| qualiﬁed_expression
| type_conversion
| allocator
| ( expression )
Each primary has a value and a type. The only names allowed as primaries are attributes that yield values
and names denoting objects or values. In the case of names denoting objects, the value of the primary is the
value of the object.

35

40

The type of an expression depends only upon the types of its operands and on the operators applied; for an
overloaded operand or operator, the determination of the operand type, or the identiﬁcation of the overloaded operator, depends on the context (see 10.5). For each predeﬁned operator, the operand and result
types are given in the following subclause.
NOTE—The syntax for an expression involving logical operators allows a sequence of and, or, xor, or xnor operators
(whether predeﬁned or user-deﬁned), since the corresponding predeﬁned operations are associative. For the operators
nand and nor (whether predeﬁned or user-deﬁned), however, such a sequence is not allowed, since the corresponding
predeﬁned operations are not associative.

Copyright © 2000 IEEE. All rights reserved.

95

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

7.2 Operators
The operators that may be used in expressions are deﬁned below. Each operator belongs to a class of operators, all of which have the same precedence level; the classes of operators are listed in order of increasing
precedence.
45

50

logical_operator

::=

and

|

or

|

nand |

nor

|

xor | xnor

relational_operator

::=

=

|

/=

|

<

|

<=

|

>

| >=

shift_operator

::=

sll

|

srl

|

sla

|

sra

|

rol

| ror

adding_operator

::=

+

|

–

|

&

sign

::=

+

|

–

multiplying_operator

::=

*

|

/

|

mod

|

rem

miscellaneous_operator

::=

**

|

abs

|

not

55

Operators of higher precedence are associated with their operands before operators of lower precedence.
Where the language allows a sequence of operators, operators with the same precedence level are associated
with their operands in textual order, from left to right. The precedence of an operator is ﬁxed and may not be
changed by the user, but parentheses can be used to control the association of operators and operands.

60

In general, operands in an expression are evaluated before being associated with operators. For certain
operations, however, the right-hand operand is evaluated if and only if the left-hand operand has a certain
value. These operations are called short-circuit operations. The logical operations and, or, nand, and nor
deﬁned for operands of types BIT and BOOLEAN are all short-circuit operations; furthermore, these are the
only short-circuit operations.
Every predeﬁned operator is a pure function (see 2.1). No predeﬁned operators have named formal parameters; therefore, named association (see 4.3.2.2) may not be used when invoking a predeﬁned operation.
NOTES
1—The predeﬁned operators for the standard types are declared in package STANDARD as shown in 14.2.

65

2—The operator not is classiﬁed as a miscellaneous operator for the purposes of deﬁning precedence, but is otherwise
classiﬁed as a logical operator.

7.2.1 Logical operators

70

The logical operators and, or, nand, nor, xor, xnor, and not are deﬁned for predeﬁned types BIT and
BOOLEAN. They are also deﬁned for any one-dimensional array type whose element type is BIT or
BOOLEAN. For the binary operators and, or, nand, nor, xor, and xnor, the operands must be of the same
base type. Moreover, for the binary operators and, or, nand, nor, xor, and xnor deﬁned on one-dimensional
array types, the operands must be arrays of the same length, the operation is performed on matching
elements of the arrays, and the result is an array with the same index range as the left operand. For the unary
operator not deﬁned on one-dimensional array types, the operation is performed on each element of the
operand, and the result is an array with the same index range as the operand.

96

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

75

80

85

The effects of the logical operators are deﬁned in the following tables. The symbol T represents TRUE for
type BOOLEAN, '1' for type BIT; the symbol F represents FALSE for type BOOLEAN, '0' for type BIT.
A
T
T
F
F

B
T
F
T
F

A and B
T
F
F
F

A
T
T
F
F

B
T
F
T
F

A or B
T
T
T
F

A
T
T
F
F

B
T
F
T
F

A xor B
F
T
T
F

A
T
T
F
F

B
T
F
T
F

A nand B
F
T
T
T

A
T
T
F
F

B
T
F
T
F

A nor B
F
F
F
T

A
T
T
F
F

B
T
F
T
F

A xnor B
T
F
F
T

A
T
F
90

95

not A
F
T

For the short-circuit operations and, or, nand, and nor on types BIT and BOOLEAN, the right operand is
evaluated only if the value of the left operand is not sufﬁcient to determine the result of the operation. For
operations and and nand, the right operand is evaluated only if the value of the left operand is T; for operations or and nor, the right operand is evaluated only if the value of the left operand is F.
NOTE—All of the binary logical operators belong to the class of operators with the lowest precedence. The unary
logical operator not belongs to the class of operators with the highest precedence.

7.2.2 Relational operators
Relational operators include tests for equality, inequality, and ordering of operands. The operands of each
relational operator must be of the same type. The result type of each relational operator is the predeﬁned
type BOOLEAN.

Operator
100

Operation

Result type

=

Equality

Any type, other
than a ﬁle type or a
protected type

BOOLEAN

/=

Inequality

Any type, other
than a ﬁle type or a
protected type

BOOLEAN

<
<=
>
>=

Ordering

Any scalar type or
discrete array type

BOOLEAN

105

110

Operand type

The equality and inequality operators (= and /=) are deﬁned for all types other than ﬁle types and protected
types. The equality operator returns the value TRUE if the two operands are equal and returns the value
FALSE otherwise. The inequality operator returns the value FALSE if the two operands are equal and
returns the value TRUE otherwise.

Copyright © 2000 IEEE. All rights reserved.

97

IEEE
Std 1076, 2000 Edition

115

IEEE STANDARD VHDL

Two scalar values of the same type are equal if and only if the values are the same. Two composite values of
the same type are equal if and only if for each element of the left operand there is a matching element of the
right operand and vice versa, and the values of matching elements are equal, as given by the predeﬁned
equality operator for the element type. In particular, two null arrays of the same type are always equal. Two
values of an access type are equal if and only if they both designate the same object or they both are equal to
the null value for the access type.

120

For two record values, matching elements are those that have the same element identiﬁer. For two onedimensional array values, matching elements are those (if any) whose index values match in the following
sense: the left bounds of the index ranges are deﬁned to match; if two elements match, the elements immediately to their right are also deﬁned to match. For two multidimensional array values, matching elements are
those whose indices match in successive positions.

125

The ordering operators are deﬁned for any scalar type and for any discrete array type. A discrete array is a
one-dimensional array whose elements are of a discrete type. Each operator returns TRUE if the corresponding relation is satisﬁed; otherwise, the operator returns FALSE.

130

For scalar types, ordering is deﬁned in terms of the relative values. For discrete array types, the relation <
(less than) is deﬁned such that the left operand is less than the right operand if and only if the left operand is
a null array and the right operand is a nonnull array.
Otherwise, both operands are nonnull arrays, and one of the following conditions is satisﬁed:
a)
b)

135

The leftmost element of the left operand is less than that of the right, or
The leftmost element of the left operand is equal to that of the right, and the tail of the left operand is
less than that of the right (the tail consists of the remaining elements to the right of the leftmost
element and can be null).

The relation <= (less than or equal) for discrete array types is deﬁned to be the inclusive disjunction of the
results of the < and = operators for the same two operands. The relations > (greater than) and >= (greater
than or equal) are deﬁned to be the complements of the <= and < operators, respectively, for the same two
operands.
7.2.3 Shift operators
140

The shift operators sll, srl, sla, sra, rol, and ror are deﬁned for any one-dimensional array type whose
element type is either of the predeﬁned types BIT or BOOLEAN.

Operator

145

Operation

Left operand type

Right operand type

Result type

sll

Shift left
logical

Any one-dimensional array type whose
element type is BIT or BOOLEAN

INTEGER

Same as left

srl

Shift right
logical

Any one-dimensional array type whose
element type is BIT or BOOLEAN

INTEGER

Same as left

sla

Shift left
arithmetic

Any one-dimensional array type whose
element type is BIT or BOOLEAN

INTEGER

Same as left

sra

Shift right
arithmetic

Any one-dimensional array type whose
element type is BIT or BOOLEAN

INTEGER

Same as left

rol

Rotate left
logical

Any one-dimensional array type whose
element type is BIT or BOOLEAN

INTEGER

Same as left

ror

Rotate right
logical

Any one-dimensional array type whose
element type is BIT or BOOLEAN

INTEGER

Same as left

150

98

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

155

IEEE
Std 1076, 2000 Edition

The index subtypes of the return values of all shift operators are the same as the index subtypes of their left
arguments.
The values returned by the shift operators are deﬁned as follows. In the remainder of this clause, the values of
their leftmost arguments are referred to as L and the values of their rightmost arguments are referred to as R.
—

The sll operator returns a value that is L logically shifted left by R index positions. That is, if R is 0
or if L is a null array, the return value is L. Otherwise, a basic shift operation replaces L with a value
that is the result of a concatenation whose left argument is the rightmost (L'Length – 1) elements of L
and whose right argument is T'Left, where T is the element type of L. If R is positive, this basic shift
operation is repeated R times to form the result. If R is negative, then the return value is the value of
the expression L srl –R.

—

The srl operator returns a value that is L logically shifted right by R index positions. That is, if R is 0
or if L is a null array, the return value is L. Otherwise, a basic shift operation replaces L with a value
that is the result of a concatenation whose right argument is the leftmost (L'Length – 1) elements of L
and whose left argument is T'Left, where T is the element type of L. If R is positive, this basic shift
operation is repeated R times to form the result. If R is negative, then the return value is the value of
the expression L sll –R.

—

The sla operator returns a value that is L arithmetically shifted left by R index positions. That is, if R
is 0 or if L is a null array, the return value is L. Otherwise, a basic shift operation replaces L with a
value that is the result of a concatenation whose left argument is the rightmost (L'Length – 1)
elements of L and whose right argument is L(L'Right). If R is positive, this basic shift operation is
repeated R times to form the result. If R is negative, then the return value is the value of the
expression L sra –R.

—

The sra operator returns a value that is L arithmetically shifted right by R index positions. That is, if
R is 0 or if L is a null array, the return value is L. Otherwise, a basic shift operation replaces L with a
value that is the result of a concatenation whose right argument is the leftmost (L'Length – 1) elements
of L and whose left argument is L(L'Left). If R is positive, this basic shift operation is repeated R
times to form the result. If R is negative, then the return value is the value of the expression L sla –R.

—

The rol operator returns a value that is L rotated left by R index positions. That is, if R is 0 or if L is
a null array, the return value is L. Otherwise, a basic rotate operation replaces L with a value that is
the result of a concatenation whose left argument is the rightmost (L'Length – 1) elements of L and
whose right argument is L(L'Left). If R is positive, this basic rotate operation is repeated R times to
form the result. If R is negative, then the return value is the value of the expression L ror –R.

—

The ror operator returns a value that is L rotated right by R index positions. That is, if R is 0 or if L
is a null array, the return value is L. Otherwise, a basic rotate operation replaces L with a value that is
the result of a concatenation whose right argument is the leftmost (L'Length – 1) elements of L and
whose left argument is L(L'Right). If R is positive, this basic rotate operation is repeated R times to
form the result. If R is negative, then the return value is the value of the expression L rol –R.

160

165

170

175

180

185

190

NOTES
1—The logical operators may be overloaded, for example, to disallow negative integers as the second argument.
2—The subtype of the result of a shift operator is the same as that of the left operand.

Copyright © 2000 IEEE. All rights reserved.

99

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

7.2.4 Adding operators
195

The adding operators + and – are predeﬁned for any numeric type and have their conventional mathematical
meaning. The concatenation operator & is predeﬁned for any one-dimensional array type.

Operator

200

Operation

Left operand type

Right operand type

Result type

+

Addition

Any numeric type

Same type

Same type

–

Subtraction

Any numeric type

Same type

Same type

&

Concatenation

Any array type

Same array type

Same array type

Any array type

The element type

Same array type

The element type

Any array type

Same array type

The element type

The element type

Any array type

For concatenation, there are three mutually exclusive cases, as follows:
205

a)

210

If both operands are one-dimensional arrays of the same type, the result of the concatenation is a
one-dimensional array of this same type whose length is the sum of the lengths of its operands, and
whose elements consist of the elements of the left operand (in left-to-right order) followed by the
elements of the right operand (in left-to-right order). The direction of the result is the direction of the
left operand, unless the left operand is a null array, in which case the direction of the result is that of
the right operand.
If both operands are null arrays, then the result of the concatenation is the right operand. Otherwise,
the direction and bounds of the result are determined as follows: Let S be the index subtype of the
base type of the result. The direction of the result of the concatenation is the direction of S, and the
left bound of the result is S'LEFT.

215

b)

If one of the operands is a one-dimensional array and the type of the other operand is the element
type of this aforementioned one-dimensional array, the result of the concatenation is given by the
rules in case a, using in place of the other operand an implicit array having this operand as its only
element.

c)

If both operands are of the same type and it is the element type of some one-dimensional array type,
the type of the result must be known from the context and is this one-dimensional array type. In this
case, each operand is treated as the one element of an implicit array, and the result of the concatenation is determined as in case a) above.

220

225

In all cases, it is an error if either bound of the index subtype of the result does not belong to the index
subtype of the type of the result, unless the result is a null array. It is also an error if any element of the result
does not belong to the element subtype of the type of the result.
Examples:
subtype BYTE is BIT_VECTOR (7 downto 0);
type MEMORY is array (Natural range <>) of BYTE;

230

-- The following concatenation accepts two BIT_VECTORs and returns a BIT_VECTOR
-- [case a)]:
constant ZERO: BYTE := "0000" & "0000";

100

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

-- The next two examples show that the same expression can represent either case a) or
-- case c), depending on the context of the expression.

235

-- The following concatenation accepts two BIT_VECTORS and returns a BIT_VECTOR
-- [case a)]:
constant C1: BIT_VECTOR := ZERO & ZERO;
-- The following concatenation accepts two BIT_VECTORs and returns a MEMORY
-- [case c)]:
constant C2: MEMORY := ZERO & ZERO;

240

-- The following concatenation accepts a BIT_VECTOR and a MEMORY, returning a
-- MEMORY [case b)]:
constant C3: MEMORY := ZERO & C2;
-- The following concatenation accepts a MEMORY and a BIT_VECTOR, returning a
-- MEMORY [case b)]:

245

constant C4: MEMORY := C2 & ZERO;
-- The following concatenation accepts two MEMORYs and returns a MEMORY [case a)]:
constant C5: MEMORY := C2 & C3;
type R1 is 0 to 7;
type R2 is 7 downto 0;

250

type T1 is array (R1 range <>) of Bit;
type T2 is array (R2 range <>) of Bit;
subtype S1 is T1(R1);
subtype S2 is T2(R2);

255

260

constant K1: S1 := (others => '0');
constant K2: T1 := K1(1 to 3) & K1(3 to 4);
constant K3: T1 := K1(5 to 7) & K1(1 to 2);
constant K4: T1 := K1(2 to 1) & K1(1 to 2);

-- K2'Left = 0 and K2'Right = 4
-- K3'Left = 0 and K3'Right = 4
-- K4'Left = 0 and K4'Right = 1

constant K5: S2 := (others => '0');
constant K6: T2 := K5(3 downto 1) & K5(4 downto 3);
constant K7: T2 := K5(7 downto 5) & K5(2 downto 1);
constant K8: T2 := K5(1 downto 2) & K5(2 downto 1);

-- K6'Left = 7 and K6'Right = 3
-- K7'Left = 7 and K7'Right = 3
-- K8'Left = 7 and K8'Right = 6

NOTES

265

1—For a given concatenation whose operands are of the same type, there may be visible more than one array type that
could be the result type according to the rules of case c). The concatenation is ambiguous and therefore an error if, using
the overload resolution rules of 2.3 and 10.5, the type of the result is not uniquely determined.
2—Additionally, for a given concatenation, there may be visible array types that allow both case a) and case c) to apply.
The concatenation is again ambiguous and therefore an error if the overload resolution rules cannot be used to determine
a result type uniquely.

Copyright © 2000 IEEE. All rights reserved.

101

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

7.2.5 Sign operators

270

Signs + and – are predeﬁned for any numeric type and have their conventional mathematical meaning: they
respectively represent the identity and negation functions. For each of these unary operators, the operand and
the result have the same type.

Operator

275

Operand type

Result type

+

Identity

Any numeric type

Same type

–

Negation

Any numeric type

Same type

NOTE—Because of the relative precedence of signs + and – in the grammar for expressions, a signed operand must not
follow a multiplying operator, the exponentiating operator **, or the operators abs and not. For example, the syntax does
not allow the following expressions:

A/+B
A**–B
280

Operation

-- An illegal expression.
-- An illegal expression.

However, these expressions may be rewritten legally as follows:
A/(+B)
A ** (–B)

-- A legal expression.
-- A legal expression.

7.2.6 Multiplying operators

285

The operators * and / are predeﬁned for any integer and any ﬂoating point type and have their conventional
mathematical meaning; the operators mod and rem are predeﬁned for any integer type. For each of these
operators, the operands and the result are of the same type.

Operator
*

/

Operation
Multiplication

Division

290

Left operand type

Right operand type

Result type

Any integer type

Same type

Same type

Any ﬂoating point type

Same type

Same type

Any integer type

Same type

Same type

Any ﬂoating point type

Same type

Same type

mod

Modulus

Any integer type

Same type

Same type

rem

Remainder

Any integer type

Same type

Same type

Integer division and remainder are deﬁned by the following relation:
A = (A/B) ∗ B +(A rem B)
295

where (A rem B) has the sign of A and an absolute value less than the absolute value of B. Integer division
satisﬁes the following identity:
(–A)/B = –(A/B) = A/(–B)

102

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

The result of the modulus operation is such that (A mod B) has the sign of B and an absolute value less than
the absolute value of B; in addition, for some integer value N, this result must satisfy the relation:
300

A = B ∗ N + (A mod B)
In addition to the above table, the operators ∗ and / are predeﬁned for any physical type.

Operator
*

Operation
Multiplication

305

/

310

Division

Left operand type

Right operand type

Result type

Any physical type

INTEGER

Same as left

Any physical type

REAL

Same as left

INTEGER

Any physical type

Same as right

REAL

Any physical type

Same as right

Any physical type

INTEGER

Same as left

Any physical type

REAL

Same as left

Any physical type

The same type

Universal integer

Multiplication of a value P of a physical type Tp by a value I of type INTEGER is equivalent to the following
computation:
Tp'Val( Tp'Pos(P) ∗ I )
Multiplication of a value P of a physical type Tp by a value F of type REAL is equivalent to the following
computation:

315

Tp'Val( INTEGER( REAL( Tp'Pos(P) ) ∗ F ))
Division of a value P of a physical type Tp by a value I of type INTEGER is equivalent to the following
computation:
Tp'Val( Tp'Pos(P) / I )

320

Division of a value P of a physical type Tp by a value F of type REAL is equivalent to the following
computation:
Tp'Val( INTEGER( REAL( Tp'Pos(P) ) / F ))
Division of a value P of a physical type Tp by a value P2 of the same physical type is equivalent to the
following computation:
Tp'Pos(P) / Tp'Pos(P2)

Copyright © 2000 IEEE. All rights reserved.

103

IEEE
Std 1076, 2000 Edition

325

Examples:

330

335

IEEE STANDARD VHDL

5
5

rem
mod

3
3

=
=

2
2

(–5)
(–5)

rem
mod

3
3

= –2
= 1

(–5)
(–5)

rem
mod

(–3)
(–3)

= –2
= –2

5
5

rem
mod

(–3)
(–3)

= 2
= –1

NOTE—Because of the precedence rules (see 7.2), the expression “–5 rem 2” is interpreted as “–(5 rem 2)” and not as
“(–5) rem 2.”

7.2.7 Miscellaneous operators
The unary operator abs is predeﬁned for any numeric type.

340

345

Operator

Operation

Operand type

Result type

abs

Absolute value

Any numeric type

Same numeric type

The exponentiating operator ** is predeﬁned for each integer type and for each ﬂoating point type. In either
case the right operand, called the exponent, is of the predeﬁned type INTEGER.

Operator

Operation

**

Exponentiation

Left operand type

Right operand type

Result type

Any integer type

INTEGER

Same as left

Any ﬂoating point type

INTEGER

Same as left

Exponentiation with an integer exponent is equivalent to repeated multiplication of the left operand by itself
for a number of times indicated by the absolute value of the exponent and from left to right; if the exponent
is negative, then the result is the reciprocal of that obtained with the absolute value of the exponent.
Exponentiation with a negative exponent is only allowed for a left operand of a ﬂoating point type. Exponentiation by a zero exponent results in the value one. Exponentiation of a value of a ﬂoating point type is
approximate.

7.3 Operands
350

The operands in an expression include names (that denote objects, values, or attributes that result in a value),
literals, aggregates, function calls, qualiﬁed expressions, type conversions, and allocators. In addition, an
expression enclosed in parentheses may be an operand in an expression. Names are deﬁned in 6.1; the other
kinds of operands are deﬁned in the following subclauses.

104

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

7.3.1 Literals

355

360

A literal is either a numeric literal, an enumeration literal, a string literal, a bit string literal, or the literal
null.
literal ::=
numeric_literal
| enumeration_literal
| string_literal
| bit_string_literal
| null
numeric_literal ::=
abstract_literal
| physical_literal

365

Numeric literals include literals of the abstract types universal_integer and universal_real, as well as literals
of physical types. Abstract literals are deﬁned in 13.4; physical literals are deﬁned in 3.1.3.
Enumeration literals are literals of enumeration types. They include both identiﬁers and character literals.
Enumeration literals are deﬁned in 3.1.1.

370

375

380

String and bit string literals are representations of one-dimensional arrays of characters. The type of a string
or bit string literal must be determinable solely from the context in which the literal appears, excluding the
literal itself but using the fact that the type of the literal must be a one-dimensional array of a character type.
The lexical structure of string and bit string literals is deﬁned in Clause 13.
For a nonnull array value represented by either a string or bit-string literal, the direction and bounds of the
array value are determined according to the rules for positional array aggregates, where the number of
elements in the aggregate is equal to the length (see 13.6 and 13.7) of the string or bit string literal. For a null
array value represented by either a string or bit-string literal, the direction and leftmost bound of the array
value are determined as in the non-null case. If the direction is ascending, then the rightmost bound is the
predecessor (as given by the 'PRED attribute) of the leftmost bound; otherwise the rightmost bound is the
successor (as given by the 'SUCC attribute) of the leftmost bound.
The character literals corresponding to the graphic characters contained within a string literal or a bit string
literal must be visible at the place of the string literal.
The literal null represents the null access value for any access type.
Evaluation of a literal yields the corresponding value.
Examples:

385

390

3.14159_26536
5280
10.7 ns
O"4777"
"54LS281"
""

Copyright © 2000 IEEE. All rights reserved.

-------

A literal of type universal_real.
A literal of type universal_integer.
A literal of a physical type.
A bit-string literal.
A string literal.
A string literal representing a null array.

105

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

7.3.2 Aggregates
An aggregate is a basic operation (see the introduction to Clause 3) that combines one or more values into a
composite value of a record or array type.
aggregate ::=
( element_association { , element_association } )
395

element_association ::=
[ choices => ] expression
choices ::= choice { | choice }

400

405

410

415

choice ::=
simple_expression
| discrete_range
| element_simple_name
| others
Each element association associates an expression with elements (possibly none). An element association is
said to be named if the elements are speciﬁed explicitly by choices; otherwise, it is said to be positional. For
a positional association, each element is implicitly speciﬁed by position in the textual order of the elements
in the corresponding type declaration.
Both named and positional associations can be used in the same aggregate, with all positional associations
appearing ﬁrst (in textual order) and all named associations appearing next (in any order, except that no associations may follow an others association). Aggregates containing a single element association must always
be speciﬁed using named association in order to distinguish them from parenthesized expressions.
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 speciﬁes the element at the corresponding index value, whereas a
discrete range speciﬁes the elements at each of the index values in the range. The discrete range has no
signiﬁcance other than to deﬁne the set of choices implied by the discrete range. In particular, the direction
speciﬁed or implied by the discrete range has no signiﬁcance. An element association with the choice others
is allowed in either an array aggregate or a record aggregate if the association appears last and has this single
choice; it speciﬁes all remaining elements, if any.
Each element of the value deﬁned by an aggregate must be represented once and only once in the aggregate.

420

The type of an aggregate must be determinable solely from the context in which the aggregate appears,
excluding the aggregate itself but using the fact that the type of the aggregate must be a composite type. The
type of an aggregate in turn determines the required type for each of its elements.
7.3.2.1 Record aggregates

425

430

If the type of an aggregate is a record type, the element names given as choices must denote elements of that
record type. If the choice others is given as a choice of a record aggregate, it must represent at least one
element. An element association with more than one choice, or with the choice others, is only allowed if the
elements speciﬁed are all of the same type. The expression of an element association must have the type of
the associated record elements.
A record aggregate is evaluated as follows. The expressions given in the element associations are evaluated
in an order (or lack thereof) not deﬁned by the language. The expression of a named association is evaluated
once for each associated element. A check is made that the value of each element of the aggregate belongs to
the subtype of this element. It is an error if this check fails.

106

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

7.3.2.2 Array aggregates

435

440

445

450

For an aggregate of a one-dimensional array type, each choice must specify values of the index type, and the
expression of each element association must be of the element type. An aggregate of an n-dimensional array
type, where n is greater than 1, is written as a one-dimensional aggregate in which the index subtype of the
aggregate is given by the ﬁrst index position of the array type, and the expression speciﬁed for each element
association is an (n–1)-dimensional array or array aggregate, which is called a subaggregate. A string or bit
string literal is allowed as a subaggregate in the place of any aggregate of a one-dimensional array of a
character type.
Apart from a ﬁnal element association with the single choice others, the rest (if any) of the element
associations of an array aggregate must be either all positional or all named. A named association of an array
aggregate is allowed to have a choice that is not locally static, or likewise a choice that is a null range, only if
the aggregate includes a single element association and this element association has a single choice. An
others choice is locally static if the applicable index constraint is locally static.
The subtype of an array aggregate that has an others choice must be determinable from the context. That is,
an array aggregate with an others choice may only appear
a)

As an actual associated with a formal parameter or formal generic declared to be of a constrained
array subtype (or subelement thereof)

b)

As the default expression deﬁning the default initial value of a port declared to be of a constrained
array subtype

c)

As the result expression of a function, where the corresponding function result type is a constrained
array subtype

d)

As a value expression in an assignment statement, where the target is a declared object, and the
subtype of the target is a constrained array subtype (or subelement of such a declared object)

e)

As the expression deﬁning the initial value of a constant or variable object, where that object is
declared to be of a constrained array subtype

f)

As the expression deﬁning the default values of signals in a signal declaration, where the corresponding subtype is a constrained array subtype

g)

As the expression deﬁning the value of an attribute in an attribute speciﬁcation, where that attribute
is declared to be of a constrained array subtype

h)

As the operand of a qualiﬁed expression whose type mark denotes a constrained array subtype

i)

As a subaggregate nested within an aggregate, where that aggregate itself appears in one of these
contexts

455

460

465

470

The bounds of an array that does not have an others choice are determined as follows. If the aggregate
appears in one of the contexts in the preceding list, then the direction of the index subtype of the aggregate is
that of the corresponding constrained array subtype; otherwise, the direction of the index subtype of the
aggregate is that of the index subtype of the base type of the aggregate. For an aggregate that has named
associations, the leftmost and rightmost bounds are determined by the direction of the index subtype of the
aggregate and the smallest and largest choices given. For a positional aggregate, the leftmost bound is determined by the applicable index constraint if the aggregate appears in one of the contexts in the preceding list;
otherwise, the leftmost bound is given by S'LEFT where S is the index subtype of the base type of the array.
In either case, the rightmost bound is determined by the direction of the index subtype and the number of
elements.

Copyright © 2000 IEEE. All rights reserved.

107

IEEE
Std 1076, 2000 Edition

475

480

IEEE STANDARD VHDL

The evaluation of an array aggregate that is not a subaggregate proceeds in two steps. First, the choices of
this aggregate and of its subaggregates, if any, are evaluated in some order (or lack thereof) that is not
deﬁned by the language. Second, the expressions of the element associations of the array aggregate are evaluated in some order that is not deﬁned by the language; the expression of a named association is evaluated
once for each associated element. The evaluation of a subaggregate consists of this second step (the ﬁrst step
is omitted since the choices have already been evaluated).
For the evaluation of an aggregate that is not a null array, a check is made that the index values deﬁned by
choices belong to the corresponding index subtypes, and also that the value of each element of the aggregate
belongs to the subtype of this element. For a multidimensional aggregate of dimension n, a check is made
that all (n-1)-dimensional subaggregates have the same bounds. It is an error if any one of these checks fails.
7.3.3 Function calls

485

A function call invokes the execution of a function body. The call speciﬁes the name of the function to be
invoked and speciﬁes the actual parameters, if any, to be associated with the formal parameters of the
function. Execution of the function body results in a value of the type declared to be the result type in the
declaration of the invoked function.
function_call ::=
function_name [ ( actual_parameter_part ) ]
actual_parameter_part ::= parameter_association_list

490

495

500

For each formal parameter of a function, a function call must specify exactly one corresponding actual
parameter. This actual parameter is speciﬁed either explicitly, by an association element (other than the
actual part open) in the association list, or in the absence of such an association element, by a default
expression (see 4.3.2).
Evaluation of a function call includes evaluation of the actual parameter expressions speciﬁed in the call and
evaluation of the default expressions associated with formal parameters of the function that do not have
actual parameters associated with them. In both cases, the resulting value must belong to the subtype of the
associated formal parameter. (If the formal parameter is of an unconstrained array type, then the formal
parameter takes on the subtype of the actual parameter.) The function body is executed using the actual
parameter values and default expression values as the values of the corresponding formal parameters.
NOTE—If a name (including one used as a preﬁx) has an interpretation both as a function call and an indexed name,
then the innermost complete context is used to disambiguate the name. If, after applying this rule, there is not exactly
one interpretation of the name, then the name is ambiguous. See 10.5.

7.3.4 Qualiﬁed expressions
A qualiﬁed expression is a basic operation (see the introduction to Clause 3) that is used to explicitly state
the type, and possibly the subtype, of an operand that is an expression or an aggregate.
505

510

qualiﬁed_expression ::=
type_mark ' ( expression )
| type_mark ' aggregate
The operand must have the same type as the base type of the type mark. The value of a qualiﬁed expression
is the value of the operand. The evaluation of a qualiﬁed expression evaluates the operand and checks that its
value belongs to the subtype denoted by the type mark.
NOTE—Whenever the type of an enumeration literal or aggregate is not known from the context, a qualiﬁed expression
can be used to state the type explicitly.

108

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

7.3.5 Type conversions
A type conversion provides for explicit conversion between closely related types.
type_conversion ::= type_mark ( expression )
515

The target type of a type conversion is the base type of the type mark. The type of the operand of a type
conversion must be determinable independent of the context (in particular, independent of the target type).
Furthermore, the operand of a type conversion is not allowed to be the literal null, an allocator, an aggregate,
or a string literal. An expression enclosed by parentheses is allowed as the operand of a type conversion only
if the expression alone is allowed.

520

If the type mark denotes a subtype, conversion consists of conversion to the target type followed by a check
that the result of the conversion belongs to the subtype.
Explicit type conversions are allowed between closely related types. In particular, a type is closely related to
itself. Other types are closely related only under the following conditions:
a)

Abstract Numeric Types—Any abstract numeric type is closely related to any other abstract numeric
type. In an explicit type conversion where the type mark denotes an abstract numeric type, the operand can be of any integer or ﬂoating point type. The value of the operand is converted to the target
type, which must also be an integer or ﬂoating point type. The conversion of a ﬂoating point value to
an integer type rounds to the nearest integer; if the value is halfway between two integers, rounding
may be up or down.

b)

Array Types—Two array types are closely related if, and only if, all of the following apply:

525

530

— The types have the same dimensionality
— For each index position, the index types are either the same or are closely related
— The element types are the same

535

540

In an explicit type conversion where the type mark denotes an array type, the following rules apply:
if the type mark denotes an unconstrained array type and if the operand is not a null array, then, for
each index position, the bounds of the result are obtained by converting the bounds of the operand to
the corresponding index type of the target type. If the type mark denotes a constrained array subtype,
then the bounds of the result are those imposed by the type mark. In either case, the value of each
element of the result is that of the matching element of the operand (see 7.2.2).
No other types are closely related.
In the case of conversions between numeric types, it is an error if the result of the conversion fails to satisfy
a constraint imposed by the type mark.

545

In the case of conversions between array types, a check is made that any constraint on the element subtype is
the same for the operand array type as for the target array type. If the type mark denotes an unconstrained
array type, then, for each index position, a check is made that the bounds of the result belong to the corresponding index subtype of the target type. If the type mark denotes a constrained array subtype, a check is
made that for each element of the operand there is a matching element of the target subtype, and vice versa.
It is an error if any of these checks fail.

Copyright © 2000 IEEE. All rights reserved.

109

IEEE
Std 1076, 2000 Edition

550

555

IEEE STANDARD VHDL

In certain cases, an implicit type conversion will be performed. An implicit conversion of an operand of type
universal_integer to another integer type, or of an operand of type universal_real to another ﬂoating point
type, can only be applied if the operand is either a numeric literal or an attribute, or if the operand is an
expression consisting of the division of a value of a physical type by a value of the same type; such an operand is called a convertible universal operand. An implicit conversion of a convertible universal operand is
applied if and only if the innermost complete context determines a unique (numeric) target type for the
implicit conversion, and there is no legal interpretation of this context without this conversion.
NOTE—Two array types may be closely related even if corresponding index positions have different directions.

7.3.6 Allocators
The evaluation of an allocator creates an object and yields an access value that designates the object.

560

565

allocator ::=
new subtype_indication
| new qualiﬁed_expression
The type of the object created by an allocator is the base type of the type mark given in either the subtype
indication or the qualiﬁed expression. For an allocator with a subtype indication, the initial value of the
created object is the same as the default initial value for an explicitly declared variable of the designated
subtype. For an allocator with a qualiﬁed expression, this expression deﬁnes the initial value of the created
object.
The type of the access value returned by an allocator must be determinable solely from the context, but using
the fact that the value returned is of an access type having the named designated type.

570

575

The only allowed form of constraint in the subtype indication of an allocator is an index constraint. If an
allocator includes a subtype indication and if the type of the object created is an array type, then the subtype
indication must either denote a constrained subtype or include an explicit index constraint. A subtype indication that is part of an allocator must not include a resolution function.
If the type of the created object is an array type, then the created object is always constrained. If the allocator
includes a subtype indication, the created object is constrained by the subtype. If the allocator includes a
qualiﬁed expression, the created object is constrained by the bounds of the initial value deﬁned by that
expression. For other types, the subtype of the created object is the subtype deﬁned by the subtype of the
access type deﬁnition.
For the evaluation of an allocator, the elaboration of the subtype indication or the evaluation of the qualiﬁed
expression is ﬁrst performed. The new object is then created, and the object is then assigned its initial value.
Finally, an access value that designates the created object is returned.

580

In the absence of explicit deallocation, an implementation must guarantee that any object created by the
evaluation of an allocator remains allocated for as long as this object or one of its subelements is accessible
directly or indirectly; that is, as long as it can be denoted by some name.
NOTES

585

1—Procedure deallocate is implicitly declared for each access type. This procedure provides a mechanism for explicitly
deallocating the storage occupied by an object created by an allocator.
2—An implementation may (but need not) deallocate the storage occupied by an object created by an allocator, once this
object has become inaccessible.

110

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

Examples:

590

new NODE
new NODE'(15 ns, null)
new NODE'(Delay => 5 ns, \Next\=> Stack)
new BIT_VECTOR'("00110110")
new STRING (1 to 10)
new STRING

-------

Takes on default initial value.
Initial value is speciﬁed.
Initial value is speciﬁed.
Constrained by initial value.
Constrained by index constraint.
Illegal: must be constrained.

7.4 Static expressions
595

600

Certain expressions are said to be static. Similarly, certain discrete ranges are said to be static, and the type
marks of certain subtypes are said to denote static subtypes.
There are two categories of static expression. Certain forms of expression can be evaluated during the analysis of the design unit in which they appear; such an expression is said to be locally static. Certain forms of
expression can be evaluated as soon as the design hierarchy in which they appear is elaborated; such an
expression is said to be globally static.
7.4.1 Locally static primaries

605

610

An expression is said to be locally static if and only if every operator in the expression denotes an implicitly
deﬁned operator whose operands and result are scalar and if every primary in the expression is a locally
static primary, where a locally static primary is deﬁned to be one of the following:
a)

A literal of any type other than type TIME

b)

A constant (other than a deferred constant) explicitly declared by a constant declaration and initialized with a locally static expression

c)

An alias whose aliased name (given in the corresponding alias declaration) is a locally static primary

d)

A function call whose function name denotes an implicitly deﬁned operator, and whose actual
parameters are each locally static expressions

e)

A predeﬁned attribute that is a value, other than the predeﬁned attribute 'PATH_NAME, and whose
preﬁx is either a locally static subtype or is an object name that is of a locally static subtype

f)

A predeﬁned attribute that is a function, other than the predeﬁned attributes 'EVENT, 'ACTIVE,
'LAST_EVENT, 'LAST_ACTIVE, 'LAST_VALUE, 'DRIVING, and 'DRIVING_VALUE, whose
preﬁx is either a locally static subtype or is an object that is of a locally static subtype, and whose
actual parameter (if any) is a locally static expression

g)

A user-deﬁned attribute whose value is deﬁned by a locally static expression

h)

A qualiﬁed expression whose operand is a locally static expression

i)

A type conversion whose expression is a locally static expression

j)

A locally static expression enclosed in parentheses

615

620

625

A locally static range is either a range of the second form (see 3.1) whose bounds are locally static expressions, or a range of the ﬁrst form whose preﬁx denotes either a locally static subtype or an object that is of a
locally static subtype. A locally static range constraint is a range constraint whose range is locally static. A
locally static scalar subtype is either a scalar base type or a scalar subtype formed by imposing on a locally
static subtype a locally static range constraint. A locally static discrete range is either a locally static subtype
or a locally static range.

Copyright © 2000 IEEE. All rights reserved.

111

IEEE
Std 1076, 2000 Edition

630

635

IEEE STANDARD VHDL

A locally static index constraint is an index constraint for which each index subtype of the corresponding
array type is locally static and in which each discrete range is locally static. A locally static array subtype is
a constrained array subtype formed by imposing on an unconstrained array type a locally static index
constraint. A locally static record subtype is a record type whose ﬁelds are all of locally static subtypes. A
locally static access subtype is a subtype denoting an access type. A locally static ﬁle subtype is a subtype
denoting a ﬁle type.
A locally static subtype is either a locally static scalar subtype, a locally static array subtype, a locally static
record subtype, a locally static access subtype, or a locally static ﬁle subtype.
7.4.2 Globally static primaries
An expression is said to be globally static if and only if every operator in the expression denotes a pure
function and every primary in the expression is a globally static primary, where a globally static primary is a
primary that, if it denotes an object or a function, does not denote a dynamically elaborated named entity
(see 12.5) and is one of the following:

640

645

a)

A literal of type TIME

b)

A locally static primary

c)

A generic constant

d)

A generate parameter

e)

A constant (including a deferred constant)

f)

An alias whose aliased name (given in the corresponding alias declaration) is a globally static
primary

g)

An array aggregate, if and only if
1)
2)

650

h)

A record aggregate, if and only if all expressions in its element associations are globally static
expressions

i)

A function call whose function name denotes a pure function and whose actual parameters are each
globally static expressions

j)

A predeﬁned attribute that is a value and whose preﬁx is either a globally static subtype or is an
object or function call that is of a globally static subtype

k)

A predeﬁned attribute that is a function, other than the predeﬁned attributes 'EVENT, 'ACTIVE,
'LAST_EVENT, 'LAST_ACTIVE, 'LAST_VALUE, 'DRIVING, and 'DRIVING_VALUE, whose
preﬁx is either a globally static subtype or is an object or function call that is of a globally static subtype, and whose actual parameter (if any) is a globally static expression

l)

A user-deﬁned attribute whose value is deﬁned by a globally static expression

m)

A qualiﬁed expression whose operand is a globally static expression

n)

A type conversion whose expression is a globally static expression

o)

An allocator of the ﬁrst form (see 7.3.6) whose subtype indication denotes a globally static subtype

p)

An allocator of the second form whose qualiﬁed expression is a globally static expression

q)

A globally static expression enclosed in parentheses

r)

A subelement or a slice of a globally static primary, provided that any index expressions are globally
static expressions and any discrete ranges used in slice names are globally static discrete ranges

655

660

665

All expressions in its element associations are globally static expressions, and
All ranges in its element associations are globally static ranges

112

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

670

675

680

A globally static range is either a range of the second form (see 3.1) whose bounds are globally static expressions, or a range of the ﬁrst form whose preﬁx denotes either a globally static subtype or an object that is of
a globally static subtype. A globally static range constraint is a range constraint whose range is globally
static. A globally static scalar subtype is either a scalar base type or a scalar subtype formed by imposing on
a globally static subtype a globally static range constraint. A globally static discrete range is either a globally
static subtype or a globally static range.
A globally static index constraint is an index constraint for which each index subtype of the corresponding
array type is globally static and in which each discrete range is globally static. A globally static array
subtype is a constrained array subtype formed by imposing on an unconstrained array type a globally static
index constraint. A globally static record subtype is a record type whose ﬁelds are all of globally static
subtypes. A globally static access subtype is a subtype denoting an access type. A globally static ﬁle subtype
is a subtype denoting a ﬁle type.
A globally static subtype is either a globally static scalar subtype, a globally static array subtype, a globally
static record subtype, a globally static access subtype, or a globally static ﬁle subtype.
NOTES

685

1—An expression that is required to be a static expression may either be a locally static expression or a globally static
expression. Similarly, a range, a range constraint, a scalar subtype, a discrete range, an index constraint, or an array
subtype that is required to be static may either be locally static or globally static.
2—The rules for locally and globally static expressions imply that a declared constant or a generic may be initialized
with an expression that is neither globally nor locally static; for example, with a call to an impure function. The resulting
constant value may be globally or locally static, even though its subtype or its initial value expression is neither. Only
interface constant, variable, and signal declarations require that their initial value expressions be static expressions.

7.5 Universal expressions
690

A universal_expression is either an expression that delivers a result of type universal_integer or one that
delivers a result of type universal_real.
The same operations are predeﬁned for the type universal_integer as for any integer type. The same operations are predeﬁned for the type universal_real as for any ﬂoating point type. In addition, these operations
include the following multiplication and division operators:

695

Operator

Operation

*

Multiplication

/

700

Division

Left operand type

Right operand
type

Result type

Universal real

Universal integer

Universal real

Universal integer

Universal real

Universal real

Universal real

Universal integer

Universal real

The accuracy of the evaluation of a universal expression of type universal_real is at least as good as the
accuracy of evaluation of expressions of the most precise predeﬁned ﬂoating point type supported by the
implementation, apart from universal_real itself.

Copyright © 2000 IEEE. All rights reserved.

113

IEEE
Std 1076, 2000 Edition

705

IEEE STANDARD VHDL

For the evaluation of an operation of a universal expression, the following rules apply. If the result is of type
universal_integer, then the values of the operands and the result must lie within the range of the integer type
with the widest range provided by the implementation, excluding type universal_integer itself. If the result is
of type universal_real, then the values of the operands and the result must lie within the range of the ﬂoating
point type with the widest range provided by the implementation, excluding type universal_real itself.
NOTE—The predeﬁned operators for the universal types are declared in package STANDARD as shown in 14.2.

114

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

8. Sequential statements
The various forms of sequential statements are described in this clause. Sequential statements are used to
deﬁne algorithms for the execution of a subprogram or process; they execute in the order in which they
appear.
5

10

15

20

sequence_of_statements ::=
{ sequential_statement }
sequential_statement ::=
wait_statement
| assertion_statement
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement
All sequential statements may be labeled. Such labels are implicitly declared at the beginning of the declarative part of the innermost enclosing process statement or subprogram body.

8.1 Wait statement
The wait statement causes the suspension of a process statement or a procedure.

25

wait_statement ::=
[ label : ] wait [ sensitivity_clause ] [ condition_clause ] [ timeout_clause ] ;
sensitivity_clause ::= on sensitivity_list
sensitivity_list ::= signal_name { , signal_name }
condition_clause ::= until condition
condition ::= boolean_expression
timeout_clause ::= for time_expression

30

The sensitivity clause deﬁnes the sensitivity set of the wait statement, which is the set of signals to which the
wait statement is sensitive. Each signal name in the sensitivity list identiﬁes a given signal as a member of
the sensitivity set. Each signal name in the sensitivity list must be a static signal name, and each name must
denote a signal for which reading is permitted. If no sensitivity clause appears, the sensitivity set is
constructed according to the following (recursive) rule:

35

The sensitivity set is initially empty. For each primary in the condition of the condition clause, if the primary is
—

A simple name that denotes a signal, add the longest static preﬁx of the name to the sensitivity set

—

A selected name whose preﬁx denotes a signal, add the longest static preﬁx of the name to the
sensitivity set

Copyright © 2000 IEEE. All rights reserved.

115

IEEE
Std 1076, 2000 Edition

—

An expanded name whose preﬁx denotes a signal, add the longest static preﬁx of the name to the
sensitivity set

—

An indexed name whose preﬁx denotes a signal, add the longest static preﬁx of the name to the
sensitivity set and apply this rule to all expressions in the indexed name

—

A slice name whose preﬁx denotes a signal, add the longest static preﬁx of the name to the sensitivity
set and apply this rule to any expressions appearing in the discrete range of the slice name

—

An attribute name, if the designator denotes a signal attribute, add the longest static preﬁx of the
name of the implicit signal denoted by the attribute name to the sensitivity set; otherwise, apply this
rule to the preﬁx of the attribute name

—

An aggregate, apply this rule to every expression appearing after the choices and the =>, if any, in
every element association

—

A function call, apply this rule to every actual designator in every parameter association

—

An actual designator of open in a parameter association, do not add to the sensitivity set

—

A qualiﬁed expression, apply this rule to the expression or aggregate qualiﬁed by the type mark, as
appropriate

—

A type conversion, apply this rule to the expression type converted by the type mark

—

A parenthesized expression, apply this rule to the expression enclosed within the parentheses

—

Otherwise, do not add to the sensitivity set.

40

45

50

55

IEEE STANDARD VHDL

This rule is also used to construct the sensitivity sets of the wait statements in the equivalent process
statements for concurrent procedure call statements (9.3), concurrent assertion statements (9.4), and concurrent signal assignment statements (9.5).
60

If a signal name that denotes a signal of a composite type appears in a sensitivity list, the effect is as if the
name of each scalar subelement of that signal appears in the list.
The condition clause speciﬁes a condition that must be met for the process to continue execution. If no
condition clause appears, the condition clause until TRUE is assumed.

65

70

75

80

The timeout clause speciﬁes the maximum amount of time the process will remain suspended at this wait
statement. If no timeout clause appears, the timeout clause for (STD.STANDARD.TIME'HIGH –
STD.STANDARD.NOW) is assumed. It is an error if the time expression in the timeout clause evaluates to a
negative value.
The execution of a wait statement causes the time expression to be evaluated to determine the timeout
interval. It also causes the execution of the corresponding process statement to be suspended, where the
corresponding process statement is the one that either contains the wait statement or is the parent (see 2.2) of
the procedure that contains the wait statement. The suspended process will resume, at the latest, immediately
after the timeout interval has expired.
The suspended process may also resume as a result of an event occurring on any signal in the sensitivity set
of the wait statement. If such an event occurs, the condition in the condition clause is evaluated. If the value
of the condition is TRUE, the process will resume. If the value of the condition is FALSE, the process will
resuspend. Such resuspension does not involve the recalculation of the timeout interval.
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. Finally, it is
an error if a wait statement appears within any subprogram whose body is declared within a protected type
body, or within any subprogram that has an ancestor whose body is declared within a protected type body.

116

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

Example:

85

type Arr is array (1 to 5) of BOOLEAN;
function F (P: BOOLEAN) return BOOLEAN;
signal S: Arr;
signal l, r: INTEGER range 1 to 5;
-- The following two wait statements have the same meaning:
wait until F(S(3)) and (S(l) or S(r));
wait on S(3), S, l, r until F(S(3)) and (S(l) or S(r));

90

NOTES
1—The wait statement wait until Clk = '1'; has semantics identical to

loop

95

wait on Clk;
exit when Clk = '1';
end loop;
because of the rules for the construction of the default sensitivity clause. These same rules imply that wait until True; has
semantics identical to wait;.
2—The conditions that cause a wait statement to resume execution of its enclosing process may no longer hold at the
time the process resumes execution if the enclosing process is a postponed process.

100

3—The rule for the construction of the default sensitivity set implies that if a function call appears in a condition clause
and the called function is an impure function, then any signals that are accessed by the function but that are not passed
through the association list of the call are not added to the default sensitivity set for the condition by virtue of the appearance of the function call in the condition.

8.2 Assertion statement
An assertion statement checks that a speciﬁed condition is true and reports an error if it is not.
105

assertion_statement ::= [ label : ] assertion ;
assertion ::=
assert condition
[ report expression ]
[ severity expression ]

110

115

120

If the report clause is present, it must include an expression of predeﬁned type STRING that speciﬁes a
message to be reported. If the severity clause is present, it must specify an expression of predeﬁned type
SEVERITY_LEVEL that speciﬁes the severity level of the assertion.
The report clause speciﬁes a message string to be included in error messages generated by the assertion. In
the absence of a report clause for a given assertion, the string "Assertion violation." is the default value for
the message string. The severity clause speciﬁes a severity level associated with the assertion. In the absence
of a severity clause for a given assertion, the default value of the severity level is ERROR.
Evaluation of an assertion statement consists of evaluation of the Boolean expression specifying the condition. If the expression results in the value FALSE, then an assertion violation is said to occur. When an
assertion violation occurs, the report and severity clause expressions of the corresponding assertion, if
present, are evaluated. The speciﬁed message string and severity level (or the corresponding default values,
if not speciﬁed) are then used to construct an error message.

Copyright © 2000 IEEE. All rights reserved.

117

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

The error message consists of at least

125

a)
b)
c)
d)

An indication that this message is from an assertion
The value of the severity level
The value of the message string
The name of the design unit (see 11.1) containing the assertion.

8.3 Report statement
A report statement displays a message.

130

135

report_statement ::=
[ label : ]
report expression
[ severity expression ] ;
The report statement expression must be of the predeﬁned type STRING. The string value of this expression
is included in the message generated by the report statement. If the severity clause is present, it must specify
an expression of predeﬁned type SEVERITY_LEVEL. The severity clause speciﬁes a severity level associated with the report. In the absence of a severity clause for a given report, the default value of the severity
level is NOTE.
The evaluation of a report statement consists of the evaluation of the report expression and severity clause
expression, if present. The speciﬁed message string and severity level (or corresponding default, if the severity level is not speciﬁed) are then used to construct a report message.

140

The report message consists of at least
a)
b)
c)
d)

145

An indication that this message is from a report statement
The value of the severity level
The value of the message string
The name of the design unit containing the report statement.

Example:
report "Entering process P";

-- A report statement
-- with default severity NOTE.

report "Setup or Hold violation; outputs driven to 'X'"
severity WARNING;

-- Another report statement;
-- severity is speciﬁed.

8.4 Signal assignment statement
150

A signal assignment statement modiﬁes the projected output waveforms contained in the drivers of one or
more signals (see 12.6.1).
signal_assignment_statement ::=
[ label : ] target <= [ delay_mechanism ] waveform ;

155

delay_mechanism ::=
transport
| [ reject time_expression ] inertial

118

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

target ::=
name
| aggregate
160

165

170

175

180

185

190

waveform ::=
waveform_element { , waveform_element }
| unaffected
If the target of the signal assignment statement is a name, then the name must denote a signal, and the base
type of the value component of each transaction produced by a waveform element on the right-hand side
must be the same as the base type of the signal denoted by that name. This form of signal assignment assigns
right-hand side values to the drivers associated with a single (scalar or composite) signal.
If the target of the signal assignment statement is in the form of an aggregate, then the type of the aggregate
must be determinable from the context, excluding the aggregate itself but including the fact that the type of
the aggregate must be a composite type. The base type of the value component of each transaction produced
by a waveform element on the right-hand side must be the same as the base type of the aggregate. Furthermore, the expression in each element association of the aggregate must be a locally static name that denotes
a signal. This form of signal assignment assigns slices or subelements of the right-hand side values to the
drivers associated with the signal named as the corresponding slice or subelement of the aggregate.
If the target of a signal assignment statement is in the form of an aggregate, and if the expression in an
element association of that aggregate is a signal name that denotes a given signal, then the given signal and
each subelement thereof (if any) are said to be identiﬁed by that element association as targets of the assignment statement. It is an error if a given signal or any subelement thereof is identiﬁed as a target by more than
one element association in such an aggregate. Furthermore, it is an error if an element association in such an
aggregate contains an others choice or a choice that is a discrete range.
The right-hand side of a signal assignment may optionally specify a delay mechanism. A delay mechanism
consisting of the reserved word transport speciﬁes that the delay associated with the ﬁrst waveform element
is to be construed as transport delay. Transport delay is characteristic of hardware devices (such as transmission lines) that exhibit nearly inﬁnite frequency response: any pulse is transmitted, no matter how short its
duration. If no delay mechanism is present, or if a delay mechanism including the reserved word inertial is
present, the delay is construed to be inertial delay. Inertial delay is characteristic of switching circuits: a pulse
whose duration is shorter than the switching time of the circuit will not be transmitted, or in the case that a
pulse rejection limit is speciﬁed, a pulse whose duration is shorter than that limit will not be transmitted.
Every inertially delayed signal assignment has a pulse rejection limit. If the delay mechanism speciﬁes
inertial delay, and if the reserved word reject followed by a time expression is present, then the time expression speciﬁes the pulse rejection limit. In all other cases, the pulse rejection limit is speciﬁed by the time
expression associated with the ﬁrst waveform element.
It is an error if the pulse rejection limit for any inertially delayed signal assignment statement is either
negative or greater than the time expression associated with the ﬁrst waveform element.

195

It is an error if the reserved word unaffected appears as a waveform in a (sequential) signal assignment
statement.
NOTES
1—The reserved word unaffected may only appear as a waveform in concurrent signal assignment statements
(see 9.5.1).

200

2—For a signal assignment whose target is a name, the type of the target may not be a protected type, nor may the target
have a subelement whose type is a protected type.
3—For a signal assignment whose target is in the form of an aggregate, no element of the target may be of a protected
type, nor may any element of the target have a subelement whose type is a protected type.

Copyright © 2000 IEEE. All rights reserved.

119

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

Examples:
-- Assignments using inertial delay:
205

-- The following three assignments are equivalent to each other:
Output_pin <= Input_pin after 10 ns;
Output_pin <= inertial Input_pin after 10 ns;
Output_pin <= reject 10 ns inertial Input_pin after 10 ns;
-- Assignments with a pulse rejection limit less than the time expression:
Output_pin <= reject 5 ns inertial Input_pin after 10 ns;
Output_pin <= reject 5 ns inertial Input_pin after 10 ns, not Input_pin after 20 ns;

210

-- Assignments using transport delay:
Output_pin <= transport Input_pin after 10 ns;
Output_pin <= transport Input_pin after 10 ns, not Input_pin after 20 ns;
215

-- Their equivalent assignments:
Output_pin <= reject 0 ns inertial Input_pin after 10 ns;
Output_pin <= reject 0 ns inertial Input_pin after 10 ns, not Input_pin after 10 ns;
NOTE—If a right-hand side value expression is either a numeric literal or an attribute that yields a result of type
universal_integer or universal_real, then an implicit type conversion is performed.

8.4.1 Updating a projected output waveform
220

The effect of execution of a signal assignment statement is deﬁned in terms of its effect upon the projected
output waveforms (see 12.6.1) representing the current and future values of drivers of signals.
waveform_element ::=
value_expression [ after time_expression ]
| null [ after time_expression ]

225

230

235

240

The future behavior of the driver(s) for a given target is deﬁned by transactions produced by the evaluation
of waveform elements in the waveform of a signal assignment statement. The ﬁrst form of waveform
element is used to specify that the driver is to assign a particular value to the target at the speciﬁed time. The
second form of waveform element is used to specify that the driver of the signal is to be turned off, so that it
(at least temporarily) stops contributing to the value of the target. This form of waveform element is called a
null waveform element. It is an error if the target of a signal assignment statement containing a null waveform element is not a guarded signal or an aggregate of guarded signals.
The base type of the time expression in each waveform element must be the predeﬁned physical type TIME
as deﬁned in package STANDARD. If the after clause of a waveform element is not present, then an implicit
"after 0 ns" is assumed. It is an error if the time expression in a waveform element evaluates to a negative
value.
Evaluation of a waveform element produces a single transaction. The time component of the transaction is
determined by the current time added to the value of the time expression in the waveform element. For the
ﬁrst form of waveform element, the value component of the transaction is determined by the value expression in the waveform element. For the second form of waveform element, the value component is not deﬁned
by the language, but it is deﬁned to be of the type of the target. A transaction produced by the evaluation of
the second form of waveform element is called a null transaction.

120

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

245

250

For the execution of a signal assignment statement whose target is of a scalar type, the waveform on its righthand side is ﬁrst evaluated. Evaluation of a waveform consists of the evaluation of each waveform element in
the waveform. Thus, the evaluation of a waveform results in a sequence of transactions, where each transaction corresponds to one waveform element in the waveform. These transactions are called new transactions.
It is an error if the sequence of new transactions is not in ascending order with respect to time.
The sequence of transactions is then used to update the projected output waveform representing the current
and future values of the driver associated with the signal assignment statement. Updating a projected output
waveform consists of the deletion of zero or more previously computed transactions (called old transactions)
from the projected output waveform and the addition of the new transactions, as follows:
a)
b)

255

c)
d)
e)

265

270

275

280

All old transactions that are projected to occur at or after the time at which the earliest new transaction is projected to occur are deleted from the projected output waveform.
The new transactions are then appended to the projected output waveform in the order of their
projected occurrence.

If the initial delay is inertial delay according to the deﬁnitions of 8.4, the projected output waveform is
further modiﬁed as follows:
a)
b)

260

IEEE
Std 1076, 2000 Edition

All of the new transactions are marked.
An old transaction is marked if the time at which it is projected to occur is less than the time at
which the ﬁrst new transaction is projected to occur minus the pulse rejection limit.
For each remaining unmarked, old transaction, the old transaction is marked if it immediately
precedes a marked transaction and its value component is the same as that of the marked transaction.
The transaction that determines the current value of the driver is marked.
All unmarked transactions (all of which are old transactions) are deleted from the projected output
waveform.

For the purposes of marking transactions, any two successive null transactions in a projected output waveform are considered to have the same value component.
The execution of a signal assignment statement whose target is of a composite type proceeds in a similar
fashion, except that the evaluation of the waveform results in one sequence of transactions for each scalar
subelement of the type of the target. Each such sequence consists of transactions whose value portions are
determined by the values of the same scalar subelement of the value expressions in the waveform, and whose
time portion is determined by the time expression corresponding to that value expression. Each such
sequence is then used to update the projected output waveform of the driver of the matching subelement of
the target. This applies both to a target that is the name of a signal of a composite type and to a target that is
in the form of an aggregate.
If a given procedure is declared by a declarative item that is not contained within a process statement, and if
a signal assignment statement appears in that procedure, then the target of the assignment statement must be
a formal parameter of the given procedure or of a parent of that procedure, or an aggregate of such formal
parameters. Similarly, if a given procedure is declared by a declarative item that is not contained within a
process statement, and if a signal is associated with an inout or out mode signal parameter in a subprogram
call within that procedure, then the signal so associated must be a formal parameter of the given procedure or
of a parent of that procedure.

Copyright © 2000 IEEE. All rights reserved.

121

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

NOTES

285

1—These rules guarantee that the driver affected by a signal assignment statement is always statically determinable if
the signal assignment appears within a given process (including the case in which it appears within a procedure that is
declared within the given process). In this case, the affected driver is the one deﬁned by the process; otherwise, the signal
assignment must appear within a procedure, and the affected driver is the one passed to the procedure along with a signal
parameter of that procedure.
2—Overloading the operator "=" has no effect on the updating of a projected output waveform.
3—Consider a signal assignment statement of the form

290

T <= reject tr inertial e1 after t1 { , ei after ti }
The following relations hold:
0 ns ≤ tr ≤ t1
and
0 ns ≤ ti < ti+1

295

Note that, if tr = 0 ns, then the waveform editing is identical to that for transport-delayed assignment; and if tr = t1,
the waveform is identical to that for the statement
T <= e1 after t1 { , ei after ti }
4—Consider the following signal assignment in some process:
S <= reject 15 ns inertial 12 after 20 ns, 18 after 41 ns

300

where S is a signal of some integer type.
Assume that at the time this signal assignment is executed, the driver of S in the process has the following
contents (the ﬁrst entry is the current driving value):

305

1

2

2

12

5

8

NOW

+3 ns

+12 ns

+13 ns

+20 ns

+42 ns

(The times given are relative to the current time.) The updating of the projected output waveform proceeds as follows:
a)

b)
310

c)

315

122

The driver is truncated at 20 ns. The driver now contains the following pending transactions:
1

2

2

12

NOW

+3 ns

+12 ns

+13 ns

The new waveforms are added to the driver. The driver now contains the following pending transactions:
1

2

2

12

12

18

NOW

+3 ns

+12 ns

+13 ns

+20 ns

+41 ns

All new transactions are marked, as well as those old transactions that occur at less than the time of the ﬁrst new
waveform (20 ns) less the rejection limit (15 ns). The driver now contains the following pending transactions
marked transactions are emboldened):
1

2

2

12

12

18

NOW

+3 ns

+12 ns

+13 ns

+20 ns

+41 ns

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

d)

320
e)

325

Each remaining unmarked transaction is marked if it immediately precedes a marked transaction and has the
same value as the marked transaction. The driver now contains the following pending transactions:
1

2

2

12

12

18

NOW

+3 ns

+12 ns

+13 ns

+20 ns

+41 ns

The transaction that determines the current value of the driver is marked, and all unmarked transactions are then
deleted. The ﬁnal driver contents are then as follows, after clearing the markings:
1

2

12

12

18

NOW

+3 ns

+13 ns

+20 ns

+41 ns

5—No subtype check is performed on the value component of a new transaction when it is added to a driver. Instead, a
subtype check that the value component of a transaction belongs to the subtype of the signal driven by the driver is made
when the driver takes on that value (see 12.6.1).

8.5 Variable assignment statement
A variable assignment statement replaces the current value of a variable with a new value speciﬁed by an
expression. The named variable and the right-hand side expression must be of the same type.
330

335

340

variable_assignment_statement ::=
[ label : ] target := expression ;
If the target of the variable assignment statement is a name, then the name must denote a variable, and the
base type of the expression on the right-hand side must be the same as the base type of the variable denoted
by that name. This form of variable assignment assigns the right-hand side value to a single (scalar or
composite) variable.
If the target of the variable assignment statement is in the form of an aggregate, then the type of the aggregate must be determinable from the context, excluding the aggregate itself but including the fact that the type
of the aggregate must be a composite type. The base type of the expression on the right-hand side must be
the same as the base type of the aggregate. Furthermore, the expression in each element association of the
aggregate must be a locally static name that denotes a variable. This form of variable assignment assigns
each subelement or slice of the right-hand side value to the variable named as the corresponding subelement
or slice of the aggregate.

345

If the target of a variable assignment statement is in the form of an aggregate, and if the locally static name
in an element association of that aggregate denotes a given variable or denotes another variable of which the
given variable is a subelement or slice, then the element association is said to identify the given variable as a
target of the assignment statement. It is an error if a given variable is identiﬁed as a target by more than one
element association in such an aggregate.

350

For the execution of a variable assignment whose target is a variable name, the variable name and the expression are ﬁrst evaluated. A check is then made that the value of the expression belongs to the subtype of the
variable, except in the case of a variable that is an array (in which case the assignment involves a subtype
conversion). Finally, the value of the expression becomes the new value of the variable. A design is erroneous if it depends on the order of evaluation of the target and source expressions of an assignment statement.

355

The execution of a variable assignment whose target is in the form of an aggregate proceeds in a similar
fashion, except that each of the names in the aggregate is evaluated, and a subtype check is performed for
each subelement or slice of the right-hand side value that corresponds to one of the names in the aggregate.

Copyright © 2000 IEEE. All rights reserved.

123

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

The value of the subelement or slice of the right-hand side value then becomes the new value of the variable
denoted by the corresponding name.
An error occurs if the aforementioned subtype checks fail.

360

The determination of the type of the target of a variable assignment statement may require determination of
the type of the expression if the target is a name that can be interpreted as the name of a variable designated
by the access value returned by a function call, and similarly, as an element or slice of such a variable.
NOTES
1—If the right-hand side is either a numeric literal or an attribute that yields a result of type universal integer or universal
real, then an implicit type conversion is performed.

365

2—For a variable assignment whose target is a name, the type of the target may not be a protected type, nor may the
target have a subelement whose type is a protected type.
3—For a variable assignment whose target is in the form of an aggregate, no element may be of a protected type, nor
may element of the target have a subelement whose type is a protected type.

8.5.1 Array variable assignments

370

375

If the target of an assignment statement is a name denoting an array variable (including a slice), the value
assigned to the target is implicitly converted to the subtype of the array variable; the result of this subtype
conversion becomes the new value of the array variable.
This means that the new value of each element of the array variable is speciﬁed by the matching element (see
7.2.2) in the corresponding array value obtained by evaluation of the expression. The subtype conversion
checks that for each element of the array variable there is a matching element in the array value, and vice
versa. An error occurs if this check fails.
NOTE—The implicit subtype conversion described for assignment to an array variable is performed only for the value of
the right-hand side expression as a whole; it is not performed for subelements or slices that are array values.

8.6 Procedure call statement
A procedure call invokes the execution of a procedure body.
procedure_call_statement ::= [ label : ] procedure_call ;
380

procedure_call ::= procedure_name [ ( actual_parameter_part ) ]
The procedure name speciﬁes the procedure body to be invoked. The actual parameter part, if present, speciﬁes the association of actual parameters with formal parameters of the procedure.

385

390

For each formal parameter of a procedure, a procedure call must specify exactly one corresponding actual
parameter. This actual parameter is speciﬁed either explicitly, by an association element (other than the
actual open) in the association list or, in the absence of such an association element, by a default expression
(see 4.3.2).
Execution of a procedure call includes evaluation of the actual parameter expressions speciﬁed in the call
and evaluation of the default expressions associated with formal parameters of the procedure that do not
have actual parameters associated with them. In both cases, the resulting value must belong to the subtype of
the associated formal parameter. (If the formal parameter is of an unconstrained array type, then the formal
parameter takes on the subtype of the actual parameter.) The procedure body is executed using the actual
parameter values and default expression values as the values of the corresponding formal parameters.

124

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

8.7 If statement
An if statement selects for execution one or none of the enclosed sequences of statements, depending on the
value of one or more corresponding conditions.
395

400

if_statement ::=
[ if_label : ]
if condition then
sequence_of_statements
{ elsif condition then
sequence_of_statements }
[ else
sequence_of_statements ]
end if [ if_label ] ;
If a label appears at the end of an if statement, it must repeat the if label.

405

For the execution of an if statement, the condition speciﬁed after if, and any conditions speciﬁed after elsif,
are evaluated in succession (treating a ﬁnal else as elsif TRUE then) until one evaluates to TRUE or all
conditions are evaluated and yield FALSE. If one condition evaluates to TRUE, then the corresponding
sequence of statements is executed; otherwise, none of the sequences of statements is executed.

8.8 Case statement

410

415

A case statement selects for execution one of a number of alternative sequences of statements; the chosen
alternative is deﬁned by the value of an expression.
case_statement ::=
[ case_label : ]
case expression is
case_statement_alternative
{ case_statement_alternative }
end case [ case_label ] ;
case_statement_alternative ::=
when choices =>
sequence_of_statements

420

The expression must be of a discrete type, or of a one-dimensional array type whose element base type is a
character type. This type must be determinable independently of the context in which the expression occurs,
but using the fact that the expression must be of a discrete type or a one-dimensional character array type.
Each choice in a case statement alternative must be of the same type as the expression; the list of choices
speciﬁes for which values of the expression the alternative is chosen.

425

If the expression is the name of an object whose subtype is locally static, whether a scalar type or an array
type, then each value of the subtype must be represented once and only once in the set of choices of the case
statement, and no other value is allowed; this rule is likewise applied if the expression is a qualiﬁed expression or type conversion whose type mark denotes a locally static subtype, or if the expression is a call to a
function whose return type mark denotes a locally static subtype.

Copyright © 2000 IEEE. All rights reserved.

125

IEEE
Std 1076, 2000 Edition

430

If the expression is of a one-dimensional character array type, then the expression must be one of the
following:
—
—

435

—
—
—

440

IEEE STANDARD VHDL

The name of an object whose subtype is locally static
An indexed name whose preﬁx is one of the members of this list and whose indexing expressions are
locally static expressions
A slice name whose preﬁx is one of the members of this list and whose discrete range is a locally
static discrete range
A function call whose return type mark denotes a locally static subtype
A qualiﬁed expression or type conversion whose type mark denotes a locally static subtype.

In such a case, each choice appearing in any of the case statement alternatives must be a locally static
expression whose value is of the same length as that of the case expression. It is an error if the element subtype of the one-dimensional character array type is not a locally static subtype.
For other forms of expression, each value of the (base) type of the expression must be represented once and
only once in the set of choices, and no other value is allowed.

445

The simple expression and discrete ranges given as choices in a case statement must be locally static. A
choice deﬁned by a discrete range stands for all values in the corresponding range. The choice others is only
allowed for the last alternative and as its only choice; it stands for all values (possibly none) not given in the
choices of previous alternatives. An element simple name (see 7.3.2) is not allowed as a choice of a case
statement alternative.
If a label appears at the end of a case statement, it must repeat the case label.

450

The execution of a case statement consists of the evaluation of the expression followed by the execution of
the chosen sequence of statements.
NOTES

455

1—The execution of a case statement chooses one and only one alternative, since the choices are exhaustive and
mutually exclusive. A qualiﬁed expression whose type mark denotes a locally static subtype can often be used as the
expression of a case statement to limit the number of choices that need be explicitly speciﬁed.
2—An others choice is required in a case statement if the type of the expression is the type universal_integer (for
example, if the expression is an integer literal), since this is the only way to cover all values of the type
universal_integer.
3—Overloading the operator “=” has no effect on the semantics of case statement execution.

8.9 Loop statement
460

465

A loop statement includes a sequence of statements that is to be executed repeatedly, zero or more times.
loop_statement ::=
[ loop_label : ]
[ iteration_scheme ] loop
sequence_of_statements
end loop [ loop_label ] ;
iteration_scheme ::=
while condition
| for loop_parameter_speciﬁcation

126

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

470

IEEE
Std 1076, 2000 Edition

parameter_speciﬁcation ::=
identiﬁer in discrete_range
If a label appears at the end of a loop statement, it must repeat the label at the beginning of the loop
statement.

475

Execution of a loop statement is complete when the loop is left as a consequence of the completion of the
iteration scheme (see below), if any, or the execution of a next statement, an exit statement, or a return
statement.
A loop statement without an iteration scheme speciﬁes repeated execution of the sequence of statements.
For a loop statement with a while iteration scheme, the condition is evaluated before each execution of the
sequence of statements; if the value of the condition is TRUE, the sequence of statements is executed; if
FALSE, the iteration scheme is said to be complete and the execution of the loop statement is complete.

480

For a loop statement with a for iteration scheme, the loop parameter speciﬁcation is the declaration of the
loop parameter with the given identiﬁer. The loop parameter is an object whose type is the base type of the
discrete range. Within the sequence of statements, the loop parameter is a constant. Hence, a loop parameter
is not allowed as the target of an assignment statement. Similarly, the loop parameter must not be given as an
actual corresponding to a formal of mode out or inout in an association list.

485

For the execution of a loop with a for iteration scheme, the discrete range is ﬁrst evaluated. If the discrete
range is a null range, the iteration scheme is said to be complete and the execution of the loop statement is
therefore complete; otherwise, the sequence of statements is executed once for each value of the discrete
range (subject to the loop not being left as a consequence of the execution of a next statement, an exit
statement, or a return statement), after which the iteration scheme is said to be complete. Prior to each such
iteration, the corresponding value of the discrete range is assigned to the loop parameter. These values are
assigned in left-to-right order.

490

NOTE—A loop may be left as the result of the execution of a next statement if the loop is nested inside of an outer loop
and the next statement has a loop label that denotes the outer loop.

8.10 Next statement
495

A next statement is used to complete the execution of one of the iterations of an enclosing loop statement
(called “loop” in the following text). The completion is conditional if the statement includes a condition.
next_statement ::=
[ label : ] next [ loop_label ] [ when condition ] ;

500

A next statement with a loop label is only allowed within the labeled loop and applies to that loop; a next
statement without a loop label is only allowed within a loop and applies only to the innermost enclosing loop
(whether labeled or not).
For the execution of a next statement, the condition, if present, is ﬁrst evaluated. The current iteration of the
loop is terminated if the value of the condition is TRUE or if there is no condition.

8.11 Exit statement
An exit statement is used to complete the execution of an enclosing loop statement (called “loop” in the
following text). The completion is conditional if the statement includes a condition.

Copyright © 2000 IEEE. All rights reserved.

127

IEEE
Std 1076, 2000 Edition

505

IEEE STANDARD VHDL

exit_statement ::=
[ label : ] exit [ loop_label ] [ when condition ] ;
An exit statement with a loop label is only allowed within the labeled loop and applies to that loop; an exit
statement without a loop label is only allowed within a loop and applies only to the innermost enclosing loop
(whether labeled or not).

510

For the execution of an exit statement, the condition, if present, is ﬁrst evaluated. Exit from the loop then
takes place if the value of the condition is TRUE or if there is no condition.

8.12 Return statement
A return statement is used to complete the execution of the innermost enclosing function or procedure body.
return_statement ::=
[ label : ] return [ expression ] ;
515

A return statement is only allowed within the body of a function or procedure, and it applies to the innermost
enclosing function or procedure.
A return statement appearing in a procedure body must not have an expression. A return statement appearing
in a function body must have an expression.

520

525

The value of the expression deﬁnes the result returned by the function. The type of this expression must be
the base type of the type mark given after the reserved word return in the speciﬁcation of the function. It is
an error if execution of a function completes by any means other than the execution of a return statement.
For the execution of a return statement, the expression (if any) is ﬁrst evaluated and a check is made that the
value belongs to the result subtype. The execution of the return statement is thereby completed if the check
succeeds; so also is the execution of the enclosing subprogram. An error occurs at the place of the return
statement if the check fails.
NOTES
1—If the expression is either a numeric literal, or an attribute that yields a result of type universal_integer or
universal_real, then an implicit conversion of the result is performed.

530

2—If the return type mark of a function denotes a constrained array subtype, then no implicit subtype conversions are
performed on the values of the expressions of the return statements within the subprogram body of that function. Thus,
for each index position of each value, the bounds of the discrete range must be the same as the discrete range of the
return subtype, and the directions must be the same.

8.13 Null statement
A null statement performs no action.

535

null_statement ::=
[ label : ] null ;
The execution of the null statement has no effect other than to pass on to the next statement.

540

NOTE—The null statement can be used to specify explicitly that no action is to be performed when certain conditions
are true, although it is never mandatory for this (or any other) purpose. This is particularly useful in conjunction with the
case statement, in which all possible values of the case expression must be covered by choices: for certain choices, it
may be that no action is required.

128

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

9. Concurrent statements
The various forms of concurrent statements are described in this clause. Concurrent statements are used to
deﬁne interconnected blocks and processes that jointly describe the overall behavior or structure of a design.
Concurrent statements execute asynchronously with respect to each other.

5

10

15

concurrent_statement ::=
block_statement
| process_statement
| concurrent_procedure_call_statement
| concurrent_assertion_statement
| concurrent_signal_assignment_statement
| component_instantiation_statement
| generate_statement
The primary concurrent statements are the block statement, which groups together other concurrent
statements, and the process statement, which represents a single independent sequential process. Additional
concurrent statements provide convenient syntax for representing simple, commonly occurring forms of
processes, as well as for representing structural decomposition and regular descriptions.
Within a given simulation cycle, an implementation may execute concurrent statements in parallel or in
some order. The language does not deﬁne the order, if any, in which such statements will be executed. A
description that depends upon a particular order of execution of concurrent statements is erroneous.

20

All concurrent statements may be labeled. Such labels are implicitly declared at the beginning of the declarative part of the innermost enclosing entity declaration, architecture body, block statement, or generate
statement.

9.1 Block statement
A block statement deﬁnes an internal block representing a portion of a design. Blocks may be hierarchically
nested to support design decomposition.

25

30

35

block_statement ::=
block_label :
block [ ( guard_expression ) ] [ is ]
block_header
block_declarative_part
begin
block_statement_part
end block [ block_label ] ;
block_header ::=
[ generic_clause
[ generic_map_aspect ; ] ]
[ port_clause
[ port_map_aspect ; ] ]
block_declarative_part ::=
{ block_declarative_item }

40

block_statement_part ::=
{ concurrent_statement }

Copyright © 2000 IEEE. All rights reserved.

129

IEEE
Std 1076, 2000 Edition

45

IEEE STANDARD VHDL

If a guard expression appears after the reserved word block, then a signal with the simple name GUARD of
predeﬁned type BOOLEAN is implicitly declared at the beginning of the declarative part of the block, and
the guard expression deﬁnes the value of that signal at any given time (see 12.6.4). The type of the guard
expression must be type BOOLEAN. Signal GUARD may be used to control the operation of certain statements within the block (see 9.5).
The implicit signal GUARD must not have a source.

50

If a block header appears in a block statement, it explicitly identiﬁes certain values or signals that are to be
imported from the enclosing environment into the block and associated with formal generics or ports. The
generic and port clauses deﬁne the formal generics and formal ports of the block (see 1.1.1.1 and 1.1.1.2);
the generic map and port map aspects deﬁne the association of actuals with those formals (see 5.2.1.2). Such
actuals are evaluated in the context of the enclosing declarative region.
If a label appears at the end of a block statement, it must repeat the block label.
NOTES

55

1—The value of signal GUARD is always deﬁned within the scope of a given block, and it does not implicitly extend to
design entities bound to components instantiated within the given block. However, the signal GUARD may be explicitly
passed as an actual signal in a component instantiation in order to extend its value to lower-level components.
2—An actual appearing in a port association list of a given block can never denote a formal port of the same block.

9.2 Process statement
A process statement deﬁnes an independent sequential process representing the behavior of some portion of
the design.
60

65

process_statement ::=
[ process_label : ]
[ postponed ] process [ ( sensitivity_list ) ] [ is ]
process_declarative_part
begin
process_statement_part
end [ postponed ] process [ process_label ] ;
process_declarative_part ::=
{ process_declarative_item }

70

75

80

process_declarative_item ::=
subprogram_declaration
| subprogram_body
| type_declaration
| subtype_declaration
| constant_declaration
| variable_declaration
| ﬁle_declaration
| alias_declaration
| attribute_declaration
| attribute_speciﬁcation
| use_clause
| group_type_declaration
| group_declaration

130

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

process_statement_part ::=
{ sequential_statement }
85

If the reserved word postponed precedes the initial reserved word process, the process statement deﬁnes a
postponed process; otherwise, the process statement deﬁnes a nonpostponed process.
If a sensitivity list appears following the reserved word process, then the process statement is assumed to
contain an implicit wait statement as the last statement of the process statement part; this implicit wait statement is of the form

90

wait on sensitivity_list ;
where the sensitivity list of the wait statement is that following the reserved word process. Such a process
statement must not contain an explicit wait statement. Similarly, if such a process statement is a parent of a
procedure, then that procedure may not contain a wait statement.

95

Only static signal names (see 6.1), for which reading is permitted, may appear in the sensitivity list of a
process statement.
If the reserved word postponed appears at the end of a process statement, the process must be a postponed
process. If a label appears at the end of a process statement, the label must repeat the process label.
It is an error if a variable declaration in a process declarative part declares a shared variable.

100

The execution of a process statement consists of the repetitive execution of its sequence of statements. After
the last statement in the sequence of statements of a process statement is executed, execution will immediately continue with the ﬁrst statement in the sequence of statements.
A process statement is said to be a passive process if neither the process itself, nor any procedure of which
the process is a parent, contains a signal assignment statement. Such a process, or any concurrent statement
equivalent to such a process, may appear in the entity statement part of an entity declaration.

105

110

115

NOTES
1—The rules in 9.2 imply that a process that has an explicit sensitivity list always has exactly one (implicit) wait statement in it, and that wait statement appears at the end of the sequence of statements in the process statement part. Thus, a
process with a sensitivity list always waits at the end of its statement part; any event on a signal named in the sensitivity
list will cause such a process to execute from the beginning of its statement part down to the end, where it will wait
again. Such a process executes once through at the beginning of simulation, suspending for the ﬁrst time when it executes the implicit wait statement.
2—The time at which a process executes after being resumed by a wait statement (see 8.1) differs depending on whether
the process is postponed or nonpostponed. When a nonpostponed process is resumed, it executes in the current simulation cycle (see 2.6.4). When a postponed process is resumed, it does not execute until a simulation cycle occurs in which
the next simulation cycle is not a delta cycle. In this way, a postponed process accesses the values of signals that are the
“ﬁnal” values at the current simulated time.
3—The conditions that cause a process to resume execution may no longer hold at the time the process resumes
execution if the process is a postponed process.

9.3 Concurrent procedure call statements

120

A concurrent procedure call statement represents a process containing the corresponding sequential
procedure call statement.
concurrent_procedure_call_statement ::=
[ label : ] [ postponed ] procedure_call ;

Copyright © 2000 IEEE. All rights reserved.

131

IEEE
Std 1076, 2000 Edition

125

130

135

IEEE STANDARD VHDL

For any concurrent procedure call statement, there is an equivalent process statement. The equivalent
process statement is a postponed process if and only if the concurrent procedure call statement includes the
reserved word postponed. The equivalent process statement has a label if and only if the concurrent procedure call statement has a label; if the equivalent process statement has a label, it is the same as that of the
concurrent procedure call statement. The equivalent process statement also has no sensitivity list, an empty
declarative part, and a statement part that consists of a procedure call statement followed by a wait
statement.
The procedure call statement consists of the same procedure name and actual parameter part that appear in
the concurrent procedure call statement.
If there exists a name that denotes a signal in the actual part of any association element in the concurrent
procedure call statement, and that actual is associated with a formal parameter of mode in or inout, then the
equivalent process statement includes a ﬁnal wait statement with a sensitivity clause that is constructed by
taking the union of the sets constructed by applying the rule of 8.1 to each actual part associated with a
formal parameter.
Execution of a concurrent procedure call statement is equivalent to execution of the equivalent process
statement.
Example:

140

CheckTiming (tPLH, tPHL, Clk, D, Q);

-- A concurrent procedure call statement.
-- The equivalent process.

145

process
begin
CheckTiming (tPLH, tPHL, Clk, D, Q);
wait on Clk, D, Q;
end process;
NOTES

150

155

1—Concurrent procedure call statements make it possible to declare procedures representing commonly used processes
and to create such processes easily by merely calling the procedure as a concurrent statement. The wait statement at the
end of the statement part of the equivalent process statement allows a procedure to be called without having it loop interminably, even if the procedure is not necessarily intended for use as a process (i.e., it contains no wait statement). Such a
procedure may persist over time (and thus the values of its variables may retain state over time) if its outermost statement
is a loop statement and the loop contains a wait statement. Similarly, such a procedure may be guaranteed to execute
only once, at the beginning of simulation, if its last statement is a wait statement that has no sensitivity clause, condition
clause, or timeout clause.
2—The value of an implicitly declared signal GUARD has no effect on evaluation of a concurrent procedure call unless
it is explicitly referenced in one of the actual parts of the actual parameter part of the concurrent procedure call
statement.

9.4 Concurrent assertion statements
A concurrent assertion statement represents a passive process statement containing the speciﬁed assertion
statement.
160

concurrent_assertion_statement ::=
[ label : ] [ postponed ] assertion ;
For any concurrent assertion statement, there is an equivalent process statement. The equivalent process
statement is a postponed process if and only if the concurrent assertion statement includes the reserved word
postponed. The equivalent process statement has a label if and only if the concurrent assertion statement has

132

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

165

IEEE
Std 1076, 2000 Edition

a label; if the equivalent process statement has a label, it is the same as that of the concurrent assertion statement. The equivalent process statement also has no sensitivity list, an empty declarative part, and a statement
part that consists of an assertion statement followed by a wait statement.
The assertion statement consists of the same condition, report clause, and severity clause that appear in the
concurrent assertion statement.

170

If there exists a name that denotes a signal in the Boolean expression that deﬁnes the condition of the assertion, then the equivalent process statement includes a ﬁnal wait statement with a sensitivity clause that is
constructed by applying the rule of 8.1 to that expression; otherwise, the equivalent process statement
contains a ﬁnal wait statement that has no explicit sensitivity clause, condition clause, or timeout clause.
Execution of a concurrent assertion statement is equivalent to execution of the equivalent process statement.

175

NOTES
1—Since a concurrent assertion statement represents a passive process statement, such a process has no outputs. Therefore, the execution of a concurrent assertion statement will never cause an event to occur. However, if the assertion is
false, then the speciﬁed error message will be sent to the simulation report.

180

2—The value of an implicitly declared signal GUARD has no effect on evaluation of the assertion unless it is explicitly
referenced in one of the expressions of that assertion.
3—A concurrent assertion statement whose condition is deﬁned by a static expression is equivalent to a process statement that ends in a wait statement that has no sensitivity clause; such a process will execute once through at the
beginning of simulation and then wait indeﬁnitely.

9.5 Concurrent signal assignment statements
185

A concurrent signal assignment statement represents an equivalent process statement that assigns values to
signals.
concurrent_signal_assignment_statement ::=
[ label : ] [ postponed ] conditional_signal_assignment
| [ label : ] [ postponed ] selected_signal_assignment
options ::= [ guarded ] [ delay_mechanism ]

190

195

200

205

There are two forms of the concurrent signal assignment statement. For each form, the characteristics that
distinguish it are discussed in the following paragraphs.
Each form may include one or both of the two options guarded and a delay mechanism (see 8.4 for the
delay mechanism, 9.5.1 for the conditional signal assignment statement, and 9.5.2 for the selected signal
assignment statement). The option guarded speciﬁes that the signal assignment statement is executed when
a signal GUARD changes from FALSE to TRUE, or when that signal has been TRUE and an event occurs on
one of the signal assignment statement’s inputs. (The signal GUARD may be one of the implicitly declared
GUARD signals associated with block statements that have guard expressions, or it may be an explicitly
declared signal of type Boolean that is visible at the point of the concurrent signal assignment statement.)
The delay mechanism option speciﬁes the pulse rejection characteristics of the signal assignment statement.
If the target of a concurrent signal assignment is a name that denotes a guarded signal (see 4.3.1.2), or if it is
in the form of an aggregate and the expression in each element association of the aggregate is a static signal
name denoting a guarded signal, then the target is said to be a guarded target. If the target of a concurrent
signal assignment is a name that denotes a signal that is not a guarded signal, or if it is in the form of an
aggregate and the expression in each element association of the aggregate is a static signal name denoting a
signal that is not a guarded signal, then the target is said to be an unguarded target. It is an error if the target
of a concurrent signal assignment is neither a guarded target nor an unguarded target.

Copyright © 2000 IEEE. All rights reserved.

133

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

For any concurrent signal assignment statement, there is an equivalent process statement with the same
meaning. The process statement equivalent to a concurrent signal assignment statement whose target is a
signal name is constructed as follows:
210

a)

If a label appears on the concurrent signal assignment statement, then the same label appears on the
process statement.

b)

The equivalent process statement is a postponed process if and only if the concurrent signal assignment statement includes the reserved word postponed.

c)

If the delay mechanism option appears in the concurrent signal assignment, then the same delay
mechanism appears in every signal assignment statement in the process statement; otherwise, it
appears in no signal assignment statement in the process statement.

d)

The statement part of the equivalent process statement consists of a statement transform (described
below).

e)

If the option guarded appears in the concurrent signal assignment statement, then the concurrent
signal assignment is called a guarded assignment. If the concurrent signal assignment statement is a
guarded assignment, and if the target of the concurrent signal assignment is a guarded target, then
the statement transform is as follows:

215

220

if GUARD then
signal_transform
else
disconnection_statements
end if ;

225

Otherwise, if the concurrent signal assignment statement is a guarded assignment, but if the target of
the concurrent signal assignment is not a guarded target, then the statement transform is as follows:
if GUARD then
signal_transform
end if ;

230

Finally, if the concurrent signal assignment statement is not a guarded assignment, and if the target
of the concurrent signal assignment is not a guarded target, then the statement transform is as
follows:

235

signal_transform
It is an error if a concurrent signal assignment is not a guarded assignment and the target of the
concurrent signal assignment is a guarded target.
A signal transform is either a sequential signal assignment statement, an if statement, a case
statement, or a null statement. If the signal transform is an if statement or a case statement, then it
contains either sequential signal assignment statements or null statements, one for each of the alternative waveforms. The signal transform determines which of the alternative waveforms is to be
assigned to the output signals.

240

f)
245

250

134

If the concurrent signal assignment statement is a guarded assignment, or if any expression (other
than a time expression) within the concurrent signal assignment statement references a signal, then
the process statement contains a ﬁnal wait statement with an explicit sensitivity clause. The sensitivity clause is constructed by taking the union of the sets constructed by applying the rule of 8.1 to
each of the aforementioned expressions. Furthermore, if the concurrent signal assignment statement
is a guarded assignment, then the sensitivity clause also contains the simple name GUARD. (The
signals identiﬁed by these names are called the inputs of the signal assignment statement.) Otherwise, the process statement contains a ﬁnal wait statement that has no explicit sensitivity clause,
condition clause, or timeout clause.

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

255

260

IEEE
Std 1076, 2000 Edition

Under certain conditions (see above) the equivalent process statement may contain a sequence of disconnection statements. A disconnection statement is a sequential signal assignment statement that assigns a null
transaction to its target. If a sequence of disconnection statements is present in the equivalent process statement, the sequence consists of one sequential signal assignment for each scalar subelement of the target of
the concurrent signal assignment statement. For each such sequential signal assignment, the target of the
assignment is the corresponding scalar subelement of the target of the concurrent signal assignment, and the
waveform of the assignment is a null waveform element whose time expression is given by the applicable
disconnection speciﬁcation (see 5.3).
If the target of a concurrent signal assignment statement is in the form of an aggregate, then the same transformation applies. Such a target may only contain locally static signal names, and a signal may not be
identiﬁed by more than one signal name.
It is an error if a null waveform element appears in a waveform of a concurrent signal assignment statement.

265

Execution of a concurrent signal assignment statement is equivalent to execution of the equivalent process
statement.
NOTES

270

1—A concurrent signal assignment statement whose waveforms and target contain only static expressions is equivalent
to a process statement whose ﬁnal wait statement has no explicit sensitivity clause, so it will execute once through at the
beginning of simulation and then suspend permanently.
2—A concurrent signal assignment statement whose waveforms are all the reserved word unaffected has no drivers for
the target, since every waveform in the concurrent signal assignment statement is transformed to the statement
null;
in the equivalent process statement (see 9.5.1).

9.5.1 Conditional signal assignments
275

The conditional signal assignment represents a process statement in which the signal transform is an if
statement.
conditional_signal_assignment ::=
target <= options conditional_waveforms ;

280

conditional_waveforms ::=
{ waveform when condition else }
waveform [ when condition ]
The options for a conditional signal assignment statement are discussed in 9.5.
For a given conditional signal assignment, there is an equivalent process statement corresponding to it as
deﬁned for any concurrent signal assignment statement. If the conditional signal assignment is of the form

285

290

target <= optionswaveform1 when condition1 else
waveform2 when condition2 else
•
•
•
waveformN–1 when conditionN–1 else
waveformN when conditionN;

Copyright © 2000 IEEE. All rights reserved.

135

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

then the signal transform in the corresponding process statement is of the form

295

300

305

if condition1 then
wave_transform1
elsif condition2 then
wave_transform2
•
•
•
elsif conditionN–1 then
wave_transformN–1
elsif conditionN then
wave_transformN
end if ;
If the conditional waveform is only a single waveform, the signal transform in the corresponding process
statement is of the form
wave_transform
For any waveform, there is a corresponding wave transform. If the waveform is of the form
waveform_element1, waveform_element2, ..., waveform_elementN

310

then the wave transform in the corresponding process statement is of the form
target <= [ delay_mechanism ] waveform_element1, waveform_element2, ...,
waveform_elementN;
If the waveform is of the form
unaffected

315

then the wave transform in the corresponding process statement is of the form
null;
In this example, the ﬁnal null causes the driver to be unchanged, rather than disconnected. (This is the null
statement—not a null waveform element).

320

The characteristics of the waveforms and conditions in the conditional assignment statement must be such
that the if statement in the equivalent process statement is a legal statement.
Example:
S <= unaffected when Input_pin = S'DrivingValue else
Input_pin after Buffer_Delay;
NOTE—The wave transform of a waveform of the form unaffected is the null statement, not the null transaction.

136

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

9.5.2 Selected signal assignments
325

The selected signal assignment represents a process statement in which the signal transform is a case
statement.
selected_signal_assignment ::=
with expression select
target <= options selected_waveforms ;

330

selected_waveforms ::=
{ waveform when choices , }
waveform when choices
The options for a selected signal assignment statement are discussed in 9.5.

335

For a given selected signal assignment, there is an equivalent process statement corresponding to it as
deﬁned for any concurrent signal assignment statement. If the selected signal assignment is of the form
with expression select
target <= options

340

waveform1
waveform2
•
•
•
waveformN–1
waveformN

when choice_list1 ,
when choice_list2 ,

when choice_listN–1,
when choice_listN ;

then the signal transform in the corresponding process statement is of the form
345

350

355

case expression is
when choice_list1 =>
wave_transform1
when choice_list2 =>
wave_transform2
•
•
•
when choice_listN–1 =>
wave_transformN–1
when choice_listN =>
wave_transformN
end case ;
Wave transforms are deﬁned in 9.5.1.

360

The characteristics of the select expression, the waveforms, and the choices in the selected assignment statement must be such that the case statement in the equivalent process statement is a legal statement.

Copyright © 2000 IEEE. All rights reserved.

137

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

9.6 Component instantiation statements
A component instantiation statement deﬁnes a subcomponent of the design entity in which it appears,
associates signals or values with the ports of that subcomponent, and associates values with generics of that
subcomponent. This subcomponent is one instance of a class of components deﬁned by a corresponding
component declaration, design entity, or conﬁguration declaration.
365

component_instantiation_statement ::=
instantiation_label :
instantiated_unit
[ generic_map_aspect ]
[ port_map_aspect ] ;

370

instantiated_unit ::=
[ component ] component_name
| entity entity_name [ ( architecture_identiﬁer ) ]
| conﬁguration conﬁguration_name

375

380

385

The component name, if present, must be the name of a component declared in a component declaration.
The entity name, if present, must be the name of a previously analyzed entity interface; if an architecture
identiﬁer appears in the instantiated unit, then that identiﬁer must be the same as the simple name of an
architecture body associated with the entity declaration denoted by the corresponding entity name. The
architecture identiﬁer deﬁnes a simple name that is used during the elaboration of a design hierarchy to
select the appropriate architecture body. The conﬁguration name, if present, must be the name of a
previously analyzed conﬁguration declaration. The generic map aspect, if present, optionally associates a
single actual with each local generic (or member thereof) in the corresponding component declaration or
entity interface. Each local generic (or member thereof) must be associated at most once. Similarly, the port
map aspect, if present, optionally associates a single actual with each local port (or member thereof) in the
corresponding component declaration or entity interface. Each local port (or member thereof) must be associated at most once. The generic map and port map aspects are described in 5.2.1.2.
If an instantiated unit containing the reserved word entity does not contain an explicitly speciﬁed architecture identiﬁer, then the architecture identiﬁer is implicitly speciﬁed according to the rules given in 5.2.2. The
architecture identiﬁer deﬁnes a simple name that is used during the elaboration of a design hierarchy to
select the appropriate architecture body.

390

A component instantiation statement and a corresponding conﬁguration speciﬁcation, if any, taken together,
imply that the block hierarchy within the design entity containing the component instantiation is to be
extended with a unique copy of the block deﬁned by another design entity. The generic map and port map
aspects in the component instantiation statement and in the binding indication of the conﬁguration speciﬁcation identify the connections that are to be made in order to accomplish the extension.

395

NOTES
1—A conﬁguration speciﬁcation can be used to bind a particular instance of a component to a design entity and to
associate the local generics and local ports of the component with the formal generics and formal ports of that design
entity. A conﬁguration speciﬁcation may apply to a component instantiation statement only if the name in the instantiated unit of the component instantiation statement denotes a component declaration. See 5.2.

400

405

2—The component instantiation statement may be used to imply a structural organization for a hardware design. By
using component declarations, signals, and component instantiation statements, a given (internal or external) block may
be described in terms of subcomponents that are interconnected by signals.
3—Component instantiation provides a way of structuring the logical decomposition of a design. The precise structural
or behavioral characteristics of a given subcomponent may be described later, provided that the instantiated unit is a
component declaration. Component instantiation also provides a mechanism for reusing existing designs in a design
library. A conﬁguration speciﬁcation can bind a given component instance to an existing design entity, even if the

138

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

410

IEEE
Std 1076, 2000 Edition

generics and ports of the entity declaration do not precisely match those of the component (provided that the instantiated
unit is a component declaration); if the generics or ports of the entity declaration do not match those of the component,
the conﬁguration speciﬁcation must contain a generic map or port map, as appropriate, to map the generics and ports of
the entity declaration to those of the component.

9.6.1 Instantiation of a component

415

420

425

430

A component instantiation statement whose instantiated unit contains a name denoting a component is
equivalent to a pair of nested block statements that couple the block hierarchy in the containing design unit
to a unique copy of the block hierarchy contained in another design unit (i.e., the subcomponent). The outer
block represents the component declaration; the inner block represents the design entity to which the component is bound. Each is deﬁned by a block statement.
The header of the block statement corresponding to the component declaration consists of the generic and
port clauses (if present) that appear in the component declaration, followed by the generic map and port map
aspects (if present) that appear in the corresponding component instantiation statement. The meaning of any
identiﬁer appearing in the header of this block statement is associated with the corresponding occurrence of
the identiﬁer in the generic clause, port clause, generic map aspect, or port map aspect, respectively. The
statement part of the block statement corresponding to the component declaration consists of a nested block
statement corresponding to the design entity.
The header of the block statement corresponding to the design entity consists of the generic and port clauses
(if present) that appear in the entity declaration that deﬁnes the interface to the design entity, followed by the
generic map and port map aspects (if present) that appear in the binding indication that binds the component
instance to that design entity. The declarative part of the block statement corresponding to the design entity
consists of the declarative items from the entity declarative part, followed by the declarative items from the
declarative part of the corresponding architecture body. The statement part of the block statement corresponding to the design entity consists of the concurrent statements from the entity statement part, followed
by the concurrent statements from the statement part of the corresponding architecture body. The meaning of
any identiﬁer appearing anywhere in this block statement is that associated with the corresponding occurrence of the identiﬁer in the entity declaration or architecture body, respectively.
For example, consider the following component declaration, instantiation, and corresponding conﬁguration
speciﬁcation:

435

440

component
COMP port (A,B : inout BIT);
end component;
for C: COMP use
entity X(Y)
port map (P1 => A, P2 => B) ;
•
•
•
C:
COMP port map (A => S1, B => S2);

Copyright © 2000 IEEE. All rights reserved.

139

IEEE
Std 1076, 2000 Edition

445

450

455

460

465

IEEE STANDARD VHDL

Given the following entity declaration and architecture declaration:
entity X is
port (P1, P2 : inout BIT);
constant Delay: Time := 1 ms;
begin
CheckTiming (P1, P2, 2*Delay);
end X ;
architecture Y of X is
signal P3: Bit;
begin
P3 <= P1 after Delay;
P2 <= P3 after Delay;
B: block
•
•
•
begin
•
•
•
end block;
end Y;
then the following block statements implement the coupling between the block hierarchy in which component instantiation statement C appears and the block hierarchy contained in design entity X(Y):
C: block
port (A,B : inout BIT);
port map (A => S1, B => S2);
begin
X: block
-- Design entity block.
port (P1, P2 : inout BIT);
port map (P1 => A, P2 => B);
constant Delay: Time := 1 ms;
signal P3: Bit;
begin
CheckTiming (P1, P2, 2*Delay);
P3 <= P1 after Delay;
P2 <= P3 after Delay;
B: block -- Internal block hierarchy.
•
•
•
begin
•
•
•
end block;
end block X ;
end block C;

470

475

480

485

490

-- Component block.
-- Local ports.
-- Actual/local binding.

-----

Formal ports.
Local/formal binding.
Entity declarative item.
Architecture declarative item.

-- Entity statement.
-- Architecture statements.

The block hierarchy extensions implied by component instantiation statements that are bound to design
entities are accomplished during the elaboration of a design hierarchy (see Clause 12).

140

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

9.6.2 Instantiation of a design entity
495

A component instantiation statement whose instantiated unit denotes either a design entity or a conﬁguration
declaration is equivalent to a pair of nested block statements that couple the block hierarchy in the
containing design unit to a unique copy of the block hierarchy contained in another design unit (i.e., the
subcomponent). The outer block represents the component instantiation statement; the inner block represents the design entity to which the instance is bound. Each is deﬁned by a block statement.

500

The header of the block statement corresponding to the component instantiation statement is empty, as is the
declarative part of this block statement. The statement part of the block statement corresponding to the
component declaration consists of a nested block statement corresponding to the design entity.

505

510

The header of the block statement corresponding to the design entity consists of the generic and port clauses
(if present) that appear in the entity declaration that deﬁnes the interface to the design entity, followed by the
generic map and port map aspects (if present) that appear in the component instantiation statement that binds
the component instance to a copy of that design entity. The declarative part of the block statement corresponding to the design entity consists of the declarative items from the entity declarative part, followed by the
declarative items from the declarative part of the corresponding architecture body. The statement part of the
block statement corresponding to the design entity consists of the concurrent statements from the entity statement part, followed by the concurrent statements from the statement part of the corresponding architecture
body. The meaning of any identiﬁer appearing anywhere in this block statement is that associated with the
corresponding occurrence of the identiﬁer in the entity declaration or architecture body, respectively.
For example, consider the following design entity:

515

520

525

530

535

entity X is
port (P1, P2: inout BIT);
constant Delay: DELAY_LENGTH := 1 ms;
use WORK.TimingChecks.all;
begin
CheckTiming (P1, P2, 2*Delay);
end entity X;
architecture Y of X is
signal P3: BIT;
begin
P3 <= P1 after Delay;
P2 <= P3 after Delay;
B: block
•
•
•
begin
•
•
•
end block B;
end architecture Y;
This design entity is instantiated by the following component instantiation statement:
C: entity Work.X (Y) port map (P1 => S1, P2 => S2);

Copyright © 2000 IEEE. All rights reserved.

141

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

The following block statements implement the coupling between the block hierarchy in which component
instantiation statement C appears and the block hierarchy contained in design entity X(Y):
540

545

550

555

560

C: block
begin
X: block
port (P1, P2: inout BIT);
port map (P1 => S1, P2 => S2);
constant Delay: DELAY_LENGTH := 1 ms;
use WORK.TimingChecks.all;
signal P3: BIT;
begin
CheckTiming (P1, P2, 2*Delay);
P3 <= P1 after Delay;
P2 <= P3 after Delay;
B: block
•
•
•
begin
•
•
•
end block B;
end block X;
end block C;

-- Instance block.
-----

Design entity block.
Entity interface ports.
Instantiation statement port map.
Entity declarative items.

-- Architecture declarative item.
-- Entity statement.
-- Architecture statements.

Moreover, consider the following design entity, which is followed by an associated conﬁguration declaration
and component instantiation:
565

570

575

580

585

entity X is
port (P1, P2: inout BIT);
constant Delay: DELAY_LENGTH := 1 ms;
use WORK.TimingChecks.all;
begin
CheckTiming (P1, P2, 2*Delay);
end entity X;
architecture Y of X is
signal P3: BIT;
begin
P3 <= P1 after Delay;
P2 <= P3 after Delay;
B: block
•
•
•
begin
•
•
•
end block B;
end architecture Y;

142

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

The conﬁguration declaration is

590

595

conﬁguration Alpha of X is
for Y
•
•
•
end for;
end conﬁguration Alpha;
The component instantiation is
C: conﬁguration Work.Alpha port map (P1 => S1, P2 => S2);
The following block statements implement the coupling between the block hierarchy in which component
instantiation statement C appears and the block hierarchy contained in design entity X(Y):

600

605

610

615

620

C: block
begin
X: block
port (P1, P2: inout BIT);
port map (P1 => S1, P2 => S2);
constant Delay: DELAY_LENGTH := 1 ms;
use WORK.TimingChecks.all;
signal P3: BIT;
begin
CheckTiming (P1, P2, 2*Delay);
P3 <= P1 after Delay;
P2 <= P3 after Delay;
B: block
•
•
•
begin
•
•
•
end block B;
end block X;
end block C;

-- Instance block.
-----

Design entity block.
Entity interface ports.
Instantiation statement port map.
Entity declarative items.

-- Architecture declarative item.
-- Entity statement.
-- Architecture statements.

The block hierarchy extensions implied by component instantiation statements that are bound to design entities occur during the elaboration of a design hierarchy (see Clause 12).

Copyright © 2000 IEEE. All rights reserved.

143

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

9.7 Generate statements

625

630

635

A generate statement provides a mechanism for iterative or conditional elaboration of a portion of a
description.
generate_statement ::=
generate_label :
generation_scheme generate
[ { block_declarative_item }
begin ]
{ concurrent_statement }
end generate [ generate_label ] ;
generation_scheme ::=
for generate_parameter_speciﬁcation
| if condition
label ::= identiﬁer
If a label appears at the end of a generate statement, it must repeat the generate label.

640

For a generate statement with a for generation scheme, the generate parameter speciﬁcation is the declaration of the generate parameter with the given identiﬁer. The generate parameter is a constant object whose
type is the base type of the discrete range of the generate parameter speciﬁcation.
The discrete range in a generation scheme of the ﬁrst form must be a static discrete range; similarly, the
condition in a generation scheme of the second form must be a static expression.
The elaboration of a generate statement is described in 12.4.2.
Example:

645

650

Gen: block
begin
L1: CELL port map (Top, Bottom, A(0), B(0)) ;
L2: for I in 1 to 3 generate
L3: for J in 1 to 3 generate
L4: if I+J>4 generate
L5: CELL port map (A(I–1),B(J–1),A(I),B(J)) ;
end generate ;
end generate ;
end generate ;
L6: for I in 1 to 3 generate
L7: for J in 1 to 3 generate
L8: if I+J<4 generate
L9: CELL port map (A(I+1),B(J+1),A(I),B(J)) ;
end generate ;
end generate ;
end generate ;
end block Gen;

655

660

144

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

10. Scope and visibility

5

The rules deﬁning the scope of declarations and the rules deﬁning which identiﬁers are visible at various
points in the text of the description are presented in this clause. The formulation of these rules uses the
notion of a declarative region.

10.1 Declarative region
A declarative region is a portion of the text of the description. A single declarative region is formed by the
text of each of the following:

10

15

20

a)
b)
c)
d)
e)
f)
g)
h)
i)
j)
k)
l)
m)

An entity declaration together with a corresponding architecture body
A conﬁguration declaration
A subprogram declaration, together with the corresponding subprogram body
A package declaration together with the corresponding body (if any)
A record type declaration
A component declaration
A block statement
A process statement
A loop statement
A block conﬁguration
A component conﬁguration
A generate statement
A protected type declaration, together with the corresponding body.

In each of these cases, the declarative region is said to be associated with the corresponding declaration or
statement. A declaration is said to occur immediately within a declarative region if this region is the innermost region that encloses the declaration, not counting the declarative region (if any) associated with the
declaration itself.
25

Certain declarative regions include disjoint parts. Each declarative region is nevertheless considered as a
(logically) continuous portion of the description text. Hence, if any rule deﬁnes a portion of text as the text
that extends from some speciﬁc point of a declarative region to the end of this region, then this portion is the
corresponding subset of the declarative region (thus, it does not include intermediate declarative items
between the interface declaration and a corresponding body declaration).

10.2 Scope of declarations
30

35

For each form of declaration, the language rules deﬁne a certain portion of the description text called the
scope of the declaration. The scope of a declaration is also called the scope of any named entity declared by
the declaration. Furthermore, if the declaration associates some notation (either an identiﬁer, a character
literal, or an operator symbol) with the named entity, this portion of the text is also called the scope of this
notation. Within the scope of a named entity, and only there, there are places where it is legal to use the associated notation in order to refer to the named entity. These places are deﬁned by the rules of visibility and
overloading.

Copyright © 2000 IEEE. All rights reserved.

145

IEEE
Std 1076, 2000 Edition

40

45

50

55

60

IEEE STANDARD VHDL

The scope of a declaration that occurs immediately within a declarative region extends from the beginning of
the declaration to the end of the declarative region; this part of the scope of a declaration is called the immediate scope. Furthermore, for any of the declarations in the following list, the scope of the declaration
extends beyond the immediate scope:
a)
b)
c)
d)
e)
f)
g)
h)

A declaration that occurs immediately within a package declaration
An element declaration in a record type declaration
A formal parameter declaration in a subprogram declaration
A local generic declaration in a component declaration
A local port declaration in a component declaration
A formal generic declaration in an entity declaration
A formal port declaration in an entity declaration
A declaration that occurs immediately within a protected type declaration.

In the absence of a separate subprogram declaration, the subprogram speciﬁcation given in the subprogram
body acts as the declaration, and rule c) applies also in such a case. In each of these cases, the given declaration occurs immediately within some enclosing declaration, and the scope of the given declaration extends to
the end of the scope of the enclosing declaration.
In addition to the above rules, the scope of any declaration that includes the end of the declarative part of a
given block (whether it be an external block deﬁned by a design entity or an internal block deﬁned by a
block statement) extends into a conﬁguration declaration that conﬁgures the given block.
If a component conﬁguration appears as a conﬁguration item immediately within a block conﬁguration that
conﬁgures a given block, and if the scope of a given declaration includes the end of the declarative part of
that block, then the scope of the given declaration extends from the beginning to the end of the declarative
region associated with the given component conﬁguration. A similar rule applies to a block conﬁguration
that appears as a conﬁguration item immediately within another block conﬁguration, provided that the
contained block conﬁguration conﬁgures an internal block. Furthermore, the scope of a use clause is
similarly extended. Finally, the scope of a library unit contained within a design library is extended along
with the scope of the logical library name corresponding to that design library.
NOTE—These scope rules apply to all forms of declaration. In particular, they apply also to implicit declarations.

10.3 Visibility

70

The meaning of the occurrence of an identiﬁer at a given place in the text is deﬁned by the visibility rules
and also, in the case of overloaded declarations, by the overloading rules. The identiﬁers considered in this
clause include any identiﬁer other than a reserved word or attribute designator that denotes a predeﬁned
attribute. The places considered in this clause are those where a lexical element (such as an identiﬁer)
occurs. The overloaded declarations considered in this clause are those for subprograms and enumeration
literals.

75

For each identiﬁer and at each place in the text, the visibility rules determine a set of declarations (with this
identiﬁer) that deﬁne the possible meanings of an occurrence of the identiﬁer. A declaration is said to be
visible at a given place in the text when, according to the visibility rules, the declaration deﬁnes a possible
meaning of this occurrence. The following two cases may arise in determining the meaning of such a
declaration:

65

—

146

The visibility rules determine at most one possible meaning. In such a case, the visibility rules are
sufﬁcient to determine the declaration deﬁning the meaning of the occurrence of the identiﬁer, or in
the absence of such a declaration, to determine that the occurrence is not legal at the given point.

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

—
80

85

IEEE
Std 1076, 2000 Edition

The visibility rules determine more than one possible meaning. In such a case, the occurrence of the
identiﬁer is legal at this point if and only if exactly one visible declaration is acceptable for the overloading rules in the given context.

A declaration is only visible within a certain part of its scope; this part starts at the end of the declaration
except in the declaration of a design unit or a protected type declaration, in which case it starts immediately
after the reserved word is occurring after the identiﬁer of the design unit or protected type declaration. This
rule applies to both explicit and implicit declarations.
Visibility is either by selection or direct. A declaration is visible by selection at places that are deﬁned as
follows:
a)

For a primary unit contained in a library: at the place of the sufﬁx in a selected name whose preﬁx
denotes the library.

b)

For an architecture body associated with a given entity declaration: at the place of the block speciﬁcation in a block conﬁguration for an external block whose interface is deﬁned by that entity
declaration.

c)

For an architecture body associated with a given entity declaration: at the place of an architecture
identiﬁer (between the parentheses) in the ﬁrst form of an entity aspect in a binding indication.

d)

For a declaration given in a package declaration: at the place of the sufﬁx in a selected name whose
preﬁx denotes the package.

e)

For an element declaration of a given record type declaration: at the place of the sufﬁx in a selected
name whose preﬁx is appropriate for the type; also at the place of a choice (before the compound
delimiter =>) in a named element association of an aggregate of the type.

f)

For a user-deﬁned attribute: at the place of the attribute designator (after the delimiter ') in an
attribute name whose preﬁx denotes a named entity with which that attribute has been associated.

g)

For a formal parameter declaration of a given subprogram declaration: at the place of the formal
designator in a formal part (before the compound delimiter =>) of a named parameter association
element of a corresponding subprogram call.

105

h)

For a local generic declaration of a given component declaration: at the place of the formal designator in a formal part (before the compound delimiter =>) of a named generic association element of a
corresponding component instantiation statement; similarly, at the place of the actual designator in
an actual part (after the compound delimiter =>, if any) of a generic association element of a corresponding binding indication.

110

i)

For a local port declaration of a given component declaration: at the place of the formal designator in
a formal part (before the compound delimiter =>) of a named port association element of a corresponding component instantiation statement; similarly, at the place of the actual designator in an
actual part (after the compound delimiter =>, if any) of a port association element of a corresponding binding indication.

115

j)

For a formal generic declaration of a given entity declaration: at the place of the formal designator in
a formal part (before the compound delimiter =>) of a named generic association element of a corresponding binding indication; similarly, at the place of the formal designator in a formal part (before
the compound delimiter =>) of a generic association element of a corresponding component instantiation statement when the instantiated unit is a design entity or a conﬁguration declaration.

120

k)

For a formal port declaration of a given entity declaration: at the place of the formal designator in a
formal part (before the compound delimiter =>) of a named port association element of a corresponding binding speciﬁcation; similarly, at the place of the formal designator in a formal part
(before the compound delimiter =>) of a port association element of a corresponding component
instantiation statement when the instantiated unit is a design entity or a conﬁguration declaration.

90

95

100

Copyright © 2000 IEEE. All rights reserved.

147

IEEE
Std 1076, 2000 Edition

125

130

135

140

145

IEEE STANDARD VHDL

l)

For a formal generic declaration or a formal port declaration of a given block statement: at the place
of the formal designator in a formal part (before the compound delimiter =>) of a named association
element of a corresponding generic or port map aspect.

m)

For a subprogram declared immediately within a given protected type declaration: at the place of the
sufﬁx in a selected name whose preﬁx denotes an object of the protected type.

Finally, within the declarative region associated with a construct other than a record type declaration or a
protected type, any declaration that occurs immediately within the region and that also occurs textually
within the construct is visible by selection at the place of the sufﬁx of an expanded name whose preﬁx
denotes the construct.
Where it is not visible by selection, a visible declaration is said to be directly visible. A declaration is said to
be directly visible within a certain part of its immediate scope; this part extends to the end of the immediate
scope of the declaration but excludes places where the declaration is hidden as explained in the following
paragraphs. In addition, a declaration occurring immediately within the visible part of a package can be
made directly visible by means of a use clause according to the rules described in 10.4.
A declaration is said to be hidden within (part of) an inner declarative region if the inner region contains a
homograph of this declaration; the outer declaration is then hidden within the immediate scope of the inner
homograph. Each of two declarations is said to be a homograph of the other if both declarations have the
same identiﬁer, operator symbol, or character literal, and if overloading is allowed for at most one of the
two. If overloading is allowed for both declarations, then each of the two is a homograph of the other if they
have the same identiﬁer, operator symbol, or character literal, as well as the same parameter and result type
proﬁle (see 3.1.1).
Within the speciﬁcation of a subprogram, every declaration with the same designator as the subprogram is
hidden. Where hidden in this manner, a declaration is visible neither by selection nor directly.

150

155

Two declarations that occur immediately within the same declarative region must not be homographs, unless
exactly one of them is the implicit declaration of a predeﬁned operation. In such cases, a predeﬁned
operation is always hidden by the other homograph. Where hidden in this manner, an implicit declaration is
hidden within the entire scope of the other declaration (regardless of which declaration occurs ﬁrst); the
implicit declaration is visible neither by selection nor directly.
Whenever a declaration with a certain identiﬁer is visible from a given point, the identiﬁer and the named
entity (if any) are also said to be visible from that point. Direct visibility and visibility by selection are
likewise deﬁned for character literals and operator symbols. An operator is directly visible if and only if the
corresponding operator declaration is directly visible.
In addition to the aforementioned rules, any declaration that is visible by selection at the end of the
declarative part of a given (external or internal) block is visible by selection in a conﬁguration declaration
that conﬁgures the given block.

160

165

170

In addition, any declaration that is directly visible at the end of the declarative part of a given block is
directly visible in a block conﬁguration that conﬁgures the given block. This rule holds unless a use clause
that makes a homograph of the declaration potentially visible (see 10.4) appears in the corresponding conﬁguration declaration, and if the scope of that use clause encompasses all or part of those conﬁguration items.
If such a use clause appears, then the declaration will be directly visible within the corresponding conﬁguration items, except at those places that fall within the scope of the additional use clause. At such places,
neither name will be directly visible.
If a component conﬁguration appears as a conﬁguration item immediately within a block conﬁguration that
conﬁgures a given block, and if a given declaration is visible by selection at the end of the declarative part of
that block, then the given declaration is visible by selection from the beginning to the end of the declarative
region associated with the given component conﬁguration. A similar rule applies to a block conﬁguration

148

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

that appears as a conﬁguration item immediately within another block conﬁguration, provided that the contained block conﬁguration conﬁgures an internal block.

175

180

185

If a component conﬁguration appears as a conﬁguration item immediately within a block conﬁguration that
conﬁgures a given block, and if a given declaration is directly visible at the end of the declarative part of that
block, then the given declaration is visible by selection from the beginning to the end of the declarative
region associated with the given component conﬁguration. A similar rule applies to a block conﬁguration
that appears as a conﬁguration item immediately within another block conﬁguration, provided that the
contained block conﬁguration conﬁgures an internal block. Furthermore, the visibility of declarations made
directly visible by a use clause within a block is similarly extended. Finally, the visibility of a logical library
name corresponding to a design library directly visible at the end of a block is similarly extended. The rules
of this paragraph hold unless a use clause that makes a homograph of the declaration potentially visible
appears in the corresponding block conﬁguration, and if the scope of that use clause encompasses all or part
of those conﬁguration items. If such a use clause appears, then the declaration will be directly visible within
the corresponding conﬁguration items, except at those places that fall within the scope of the additional use
clause. At such places, neither name will be directly visible.
NOTES

190

195

200

1—The same identiﬁer, character literal, or operator symbol may occur in different declarations and may thus be associated with different named entities, even if the scopes of these declarations overlap. Overlap of the scopes of declarations
with the same identiﬁer, character literal, or operator symbol can result from overloading of subprograms and of enumeration literals. Such overlaps can also occur for named entities declared in the visible parts of packages and for formal
generics and ports, record elements, and formal parameters, where there is overlap of the scopes of the enclosing
package declarations, entity interfaces, record type declarations, or subprogram declarations. Finally, overlapping scopes
can result from nesting.
2—The rules deﬁning immediate scope, hiding, and visibility imply that a reference to an identiﬁer, character literal, or
operator symbol within its own declaration is illegal (except for design units). The identiﬁer, character literal, or operator
symbol hides outer homographs within its immediate scope—that is, from the start of the declaration. On the other hand,
the identiﬁer, character literal, or operator symbol is visible only after the end of the declaration (again, except for design
units). For this reason, all but the last of the following declarations are illegal:
constant K: INTEGER := K*K;
constant T: T;
procedure P (X: P);
function Q (X: REAL := Q) return Q;
procedure R (R: REAL);

------

Illegal
Illegal
Illegal
Illegal
Legal (although perhaps confusing)

Example:
205

210

215

L1:

block
signal A,B: Bit ;
begin
L2: block
signal B: Bit ;
begin
A <= B after 5 ns;
B <= L1.B after 10 ns;
end block ;
B <= A after 15 ns;
end block ;

Copyright © 2000 IEEE. All rights reserved.

-- An inner homograph of B.
-- Means L1.A <= L2.B
-- Means L2.B <= L1.B
-- Means L1.B <= L1.A

149

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

10.4 Use clauses
A use clause achieves direct visibility of declarations that are visible by selection.
use_clause ::=
use selected_name { , selected_name } ;

220

Each selected name in a use clause identiﬁes one or more declarations that will potentially become directly
visible. If the sufﬁx of the selected name is a simple name, character literal, or operator symbol, then the
selected name identiﬁes only the declaration(s) of that simple name, character literal, or operator symbol
contained within the package or library denoted by the preﬁx of the selected name. If the sufﬁx is the
reserved word all, then the selected name identiﬁes all declarations that are contained within the package or
library denoted by the preﬁx of the selected name.

225

For each use clause, there is a certain region of text called the scope of the use clause. This region starts
immediately after the use clause. If a use clause is a declarative item of some declarative region, the scope of
the clause extends to the end of the declarative region. If a use clause occurs within the context clause of a
design unit, the scope of the use clause extends to the end of the declarative region associated with the
design unit. The scope of a use clause may additionally extend into a conﬁguration declaration (see 10.2).

230

In order to determine which declarations are made directly visible at a given place by use clauses, consider
the set of declarations identiﬁed by all use clauses whose scopes enclose this place. Any declaration in this
set is a potentially visible declaration. A potentially visible declaration is actually made directly visible
except in the following two cases:
a)

A potentially visible declaration is not made directly visible if the place considered is within the
immediate scope of a homograph of the declaration.

b)

Potentially visible declarations that have the same designator are not made directly visible unless
each of them is either an enumeration literal speciﬁcation or the declaration of a subprogram
(either by a subprogram declaration or by an implicit declaration).

235

NOTES
240

245

1—These rules guarantee that a declaration that is made directly visible by a use clause cannot hide an otherwise directly
visible declaration.
2—If a named entity X declared in package P is made potentially visible within a package Q (e.g., by the inclusion of the
clause "use P.X;" in the context clause of package Q), and the context clause for design unit R includes the clause "use
Q.all;", this does not imply that X will be potentially visible in R. Only those named entities that are actually declared in
package Q will be potentially visible in design unit R (in the absence of any other use clauses).

10.5 The context of overload resolution
Overloading is deﬁned for names, subprograms, and enumeration literals.

250

For overloaded entities, overload resolution determines the actual meaning that an occurrence of an identiﬁer
or a character literal has whenever the visibility rules have determined that more than one meaning is acceptable at the place of this occurrence; overload resolution likewise determines the actual meaning of an
occurrence of an operator or basic operation (see the introduction to Clause 3).
At such a place, all visible declarations are considered. The occurrence is only legal if there is exactly one
interpretation of each constituent of the innermost complete context; a complete context is either a declaration, a speciﬁcation, or a statement.

150

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

255

IEEE
Std 1076, 2000 Edition

When considering possible interpretations of a complete context, the only rules considered are the syntax
rules, the scope and visibility rules, and the rules of the form described below:
a)

Any rule that requires a name or expression to have a certain type or to have the same type as another
name or expression.

b)

Any rule that requires the type of a name or expression to be a type of a certain class; similarly, any
rule that requires a certain type to be a discrete, integer, ﬂoating point, physical, universal, character,
or Boolean type.

c)

Any rule that requires a preﬁx to be appropriate for a certain type.

d)

The rules that require the type of an aggregate or string literal to be determinable solely from the
enclosing complete context. Similarly, the rules that require the type of the preﬁx of an attribute, the
type of the expression of a case statement, or the type of the operand of a type conversion to be
determinable independently of the context.

e)

The rules given for the resolution of overloaded subprogram calls; for the implicit conversions of
universal expressions; for the interpretation of discrete ranges with bounds having a universal type;
and for the interpretation of an expanded name whose preﬁx denotes a subprogram.

f)

The rules given for the requirements on the return type, the number of formal parameters, and the
types of the formal parameters of the subprogram denoted by the resolution function name (see 2.4).

260

265

270
NOTES

275

1—If there is only one possible interpretation of an occurrence of an identiﬁer, character literal, operator symbol, or
string, that occurrence denotes the corresponding named entity. However, this condition does not mean that the occurrence is necessarily legal since other requirements exist that are not considered for overload resolution: for example, the
fact that the expression is static, the parameter modes, conformance rules, the use of named association in an indexed
name, the use of open in an indexed name, the use of a slice as an actual to a function call, and so forth.
2—A loop parameter speciﬁcation is a declaration, and hence a complete context.

280

3—Rules that require certain constructs to have the same parameter and result type proﬁle fall under category a) above.
The same holds for rules that require conformance of two constructs, since conformance requires that corresponding
names be given the same meaning by the visibility and overloading rules.

Copyright © 2000 IEEE. All rights reserved.

151

IEEE
Std 1076, 2000 Edition

152

IEEE STANDARD VHDL

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

11. Design units and their analysis
The overall organization of descriptions, as well as their analysis and subsequent deﬁnition in a design
library, are discussed in this clause.

11.1 Design units
Certain constructs may be independently analyzed and inserted into a design library; these constructs are
called design units. One or more design units in sequence comprise a design ﬁle.
5

design_ﬁle ::= design_unit { design_unit }
design_unit ::= context_clause library_unit
library_unit ::=
primary_unit
| secondary_unit

10

15

20

25

primary_unit ::=
entity_declaration
| conﬁguration_declaration
| package_declaration
secondary_unit ::=
architecture_body
| package_body
Design units in a design ﬁle are analyzed in the textual order of their appearance in the design ﬁle. Analysis
of a design unit deﬁnes the corresponding library unit in a design library. A library unit is either a primary
unit or a secondary unit. A secondary unit is a separately analyzed body of a primary unit resulting from a
previous analysis.
The name of a primary unit is given by the ﬁrst identiﬁer after the initial reserved word of that unit. Of the
secondary units, only architecture bodies are named; the name of an architecture body is given by the identiﬁer following the reserved word architecture. Each primary unit in a given library must have a simple name
that is unique within the given library, and each architecture body associated with a given entity declaration
must have a simple name that is unique within the set of names of the architecture bodies associated with
that entity declaration.
Entity declarations, architecture bodies, and conﬁguration declarations are discussed in Clause 1. Package
declarations and package bodies are discussed in Clause 2.

11.2 Design libraries

30

A design library is an implementation-dependent storage facility for previously analyzed design units. A
given implementation is required to support any number of design libraries.
library_clause ::= library logical_name_list ;
logical_name_list ::= logical_name { , logical_name }
logical_name ::= identiﬁer

Copyright © 2000 IEEE. All rights reserved.

153

IEEE
Std 1076, 2000 Edition

35

40

IEEE STANDARD VHDL

A library clause deﬁnes logical names for design libraries in the host environment. A library clause appears
as part of a context clause at the beginning of a design unit. There is a certain region of text called the scope
of a library clause; this region starts immediately after the library clause, and it extends to the end of the
declarative region associated with the design unit in which the library clause appears. Within this scope each
logical name deﬁned by the library clause is directly visible, except where hidden in an inner declarative
region by a homograph of the logical name according to the rules of 10.3.
If two or more logical names having the same identiﬁer (see 13.3) appear in library clauses in the same
context clause, the second and subsequent occurrences of the logical name have no effect. The same is true
of logical names appearing both in the context clause of a primary unit and in the context clause of a corresponding secondary unit.
Each logical name deﬁned by the library clause denotes a design library in the host environment.

45

50

For a given library logical name, the actual name of the corresponding design libraries in the host environment may or may not be the same. A given implementation must provide some mechanism to associate a
library logical name with a host-dependent library. Such a mechanism is not deﬁned by the language.
There are two classes of design libraries: working libraries and resource libraries. A working library is the
library into which the library unit resulting from the analysis of a design unit is placed. A resource library is
a library containing library units that are referenced within the design unit being analyzed. Only one library
may be the working library during the analysis of any given design unit; in contrast, any number of libraries
(including the working library itself) may be resource libraries during such an analysis.
Every design unit except package STANDARD is assumed to contain the following implicit context items as
part of its context clause:

55

library STD, WORK ; use STD.STANDARD.all ;
Library logical name STD denotes the design library in which package STANDARD and package TEXTIO
reside; these are the only standard packages deﬁned by the language (see Clause 14). (The use clause makes
all declarations within package STANDARD directly visible within the corresponding design unit; see 10.4).
Library logical name WORK denotes the current working library during a given analysis.

60

The library denoted by the library logical name STD contains no library units other than package
STANDARD and package TEXTIO.
A secondary unit corresponding to a given primary unit may only be placed into the design library in which
the primary unit resides.

65

NOTE—The design of the language assumes that the contents of resource libraries named in all library clauses in the
context clause of a design unit will remain unchanged during the analysis of that unit (with the possible exception of the
updating of the library unit corresponding to the analyzed design unit within the working library, if that library is also a
resource library).

11.3 Context clauses
A context clause deﬁnes the initial name environment in which a design unit is analyzed.
context_clause ::= { context_item }
70

context_item ::=
library_clause
| use_clause

154

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

75

IEEE
Std 1076, 2000 Edition

A library clause deﬁnes library logical names that may be referenced in the design unit; library clauses are
described in 11.2. A use clause makes certain declarations directly visible within the design unit; use clauses
are described in 10.4.
NOTE—The rules given for use clauses are such that the same effect is obtained whether the name of a library unit is
mentioned once or more than once by the applicable use clauses, or even within a given use clause.

11.4 Order of analysis
The rules deﬁning the order in which design units can be analyzed are direct consequences of the visibility
rules. In particular
80

a)
b)

A primary unit whose name is referenced within a given design unit must be analyzed prior to the
analysis of the given design unit.
A primary unit must be analyzed prior to the analysis of any corresponding secondary unit.

In each case, the second unit depends on the ﬁrst unit.

85

The order in which design units are analyzed must be consistent with the partial ordering deﬁned by the
above rules.
If any error is detected while attempting to analyze a design unit, then the attempted analysis is rejected and
has no effect whatsoever on the current working library.

90

A given library unit is potentially affected by a change in any library unit whose name is referenced within
the given library unit. A secondary unit is potentially affected by a change in its corresponding primary unit.
If a library unit is changed (e.g., by reanalysis of the corresponding design unit), then all library units that
are potentially affected by such a change become obsolete and must be reanalyzed before they can be used
again.

Copyright © 2000 IEEE. All rights reserved.

155

IEEE
Std 1076, 2000 Edition

156

IEEE STANDARD VHDL

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

12. Elaboration and execution
The process by which a declaration achieves its effect is called the elaboration of the declaration. After its
elaboration, a declaration is said to be elaborated. Prior to the completion of its elaboration (including before
the elaboration), the declaration is not yet elaborated.

5

Elaboration is also deﬁned for design hierarchies, declarative parts, statement parts (containing concurrent
statements), and concurrent statements. Elaboration of such constructs is necessary in order ultimately to
elaborate declarative items that are declared within those constructs.
In order to execute a model, the design hierarchy deﬁning the model must ﬁrst be elaborated. Initialization of
nets (see 12.6.2) in the model then occurs. Finally, simulation of the model proceeds. Simulation consists of
the repetitive execution of the simulation cycle, during which processes are executed and nets updated.

12.1 Elaboration of a design hierarchy
10

15

The elaboration of a design hierarchy creates a collection of processes interconnected by nets; this collection
of processes and nets can then be executed to simulate the behavior of the design.
A design hierarchy may be deﬁned by a design entity. Elaboration of a design hierarchy deﬁned in this
manner consists of the elaboration of the block statement equivalent to the external block deﬁned by the
design entity. The architecture of this design entity is assumed to contain an implicit conﬁguration
speciﬁcation (see 5.2) for each component instance that is unbound in this architecture; each conﬁguration
speciﬁcation has an entity aspect denoting an anonymous conﬁguration declaration identifying the visible
entity declaration (see 5.2) and supplying an implicit block conﬁguration (see 1.3.1) that binds and conﬁgures a design entity identiﬁed according to the rules of 5.2.2. The equivalent block statement is deﬁned in
9.6.2. Elaboration of a block statement is deﬁned in 12.4.1.

20

A design hierarchy may also be deﬁned by a conﬁguration. Elaboration of a conﬁguration consists of the
elaboration of the block statement equivalent to the external block deﬁned by the design entity conﬁgured by
the conﬁguration. The conﬁguration contains an implicit component conﬁguration (see 1.3.2) for each
unbound component instance contained within the external block and an implicit block conﬁguration (see
1.3.1) for each internal block contained within the external block.

25

An implementation may allow, but is not required to allow, a design entity at the root of a design hierarchy to
have generics and ports. If an implementation allows these top-level interface objects, it may restrict their
allowed types and modes in an implementation-deﬁned manner. Similarly, the means by which top-level
interface objects are associated with the external environment of the hierarchy are also deﬁned by an implementation supporting top-level interface objects.

30

Elaboration of a block statement involves ﬁrst elaborating each not-yet-elaborated package containing
declarations referenced by the block. Similarly, elaboration of a given package involves ﬁrst elaborating
each not-yet-elaborated package containing declarations referenced by the given package. Elaboration of a
package consists additionally of the

35

a)
b)

Elaboration of the declarative part of the package declaration, eventually followed by
Elaboration of the declarative part of the corresponding package body, if the package has a corresponding package body.

Step b) above, the elaboration of a package body, may be deferred until the declarative parts of other
packages have been elaborated, if necessary, because of the dependencies created between packages by their
interpackage references.

Copyright © 2000 IEEE. All rights reserved.

157

IEEE
Std 1076, 2000 Edition

40

IEEE STANDARD VHDL

Elaboration of a declarative part is deﬁned in 12.3.
Examples:
-- In the following example, because of the dependencies between the packages, the
-- elaboration of either package body must follow the elaboration of both package
-- declarations.

45

50

55

package P1 is
constant C1: INTEGER := 42;
constant C2: INTEGER;
end package P1;
package P2 is
constant C1: INTEGER := 17;
constant C2: INTEGER;
end package P2;
package body P1 is
constant C2: INTEGER := Work.P2.C1;
end package body P1;
package body P2 is
constant C2: INTEGER := Work.P1.C1;
end package body P2;
-- If a design hierarchy is described by the following design entity:

60

65

70

entity E is end;
architecture A of E is
component comp
port (…);
end component;
begin
C:
comp port map (…);
B:
block
…
begin
…
end block B;
end architecture A;
-- then its architecture contains the following implicit conﬁguration speciﬁcation at the
-- end of its declarative part:
for C: comp use conﬁguration anonymous;

75

-- and the following conﬁguration declaration is assumed to exist when E(A) is
-- elaborated:
conﬁguration anonymous of L.E is
for A
80

-- L is the library in which E(A) is found.
-- The most recently analyzed architecture
-- of L.E.

end for;
end conﬁguration anonymous;

158

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

12.2 Elaboration of a block header
Elaboration of a block header consists of the elaboration of the generic clause, the generic map aspect, the
port clause, and the port map aspect, in that order.
12.2.1 The generic clause
85

90

Elaboration of a generic clause consists of the elaboration of each of the equivalent single generic
declarations contained in the clause, in the order given. The elaboration of a generic declaration consists of
elaborating the subtype indication and then creating a generic constant of that subtype.
The value of a generic constant is not deﬁned until a subsequent generic map aspect is evaluated or, in the
absence of a generic map aspect, until the default expression associated with the generic constant is
evaluated to determine the value of the constant.
12.2.2 The generic map aspect
Elaboration of a generic map aspect consists of elaborating the generic association list. The generic
association list contains an implicit association element for each generic constant that is not explicitly
associated with an actual or that is associated with the reserved word open; the actual part of such an
implicit association element is the default expression appearing in the declaration of that generic constant.

95

100

Elaboration of a generic association list consists of the elaboration of each generic association element in the
association list. Elaboration of a generic association element consists of the elaboration of the formal part
and the evaluation of the actual part. The generic constant or subelement or slice thereof designated by the
formal part is then initialized with the value resulting from the evaluation of the corresponding actual part. It
is an error if the value of the actual does not belong to the subtype denoted by the subtype indication of the
formal. If the subtype denoted by the subtype indication of the declaration of the formal is a constrained
array subtype, then an implicit subtype conversion is performed prior to this check. It is also an error if the
type of the formal is an array type and the value of each element of the actual does not belong to the element
subtype of the formal.
12.2.3 The port clause

105

Elaboration of a port clause consists of the elaboration of each of the equivalent single port declarations
contained in the clause, in the order given. The elaboration of a port declaration consists of elaborating the
subtype indication and then creating a port of that subtype.
12.2.4 The port map aspect
Elaboration of a port map aspect consists of elaborating the port association list.

110

115

Elaboration of a port association list consists of the elaboration of each port association element in the
association list whose actual is not the reserved word open. Elaboration of a port association element consists
of the elaboration of the formal part; the port or subelement or slice thereof designated by the formal part is
then associated with the signal or expression designated by the actual part. This association involves a check
that the restrictions on port associations (see 1.1.1.2) are met. It is an error if this check fails.
If a given port is a port of mode in whose declaration includes a default expression, and if no association
element associates a signal or expression with that port, then the default expression is evaluated and the
effective and driving value of the port is set to the value of the default expression. Similarly, if a given port of
mode in is associated with an expression, that expression is evaluated and the effective and driving value of
the port is set to the value of the expression. In the event that the value of a port is derived from an expression
in either fashion, references to the predeﬁned attributes 'DELAYED, 'STABLE, 'QUIET, 'EVENT, 'ACTIVE,

Copyright © 2000 IEEE. All rights reserved.

159

IEEE
Std 1076, 2000 Edition

120

125

130

135

140

IEEE STANDARD VHDL

'LAST_EVENT, 'LAST_ACTIVE, 'LAST_VALUE, 'DRIVING, and 'DRIVING_VALUE of the port return
values indicating that the port has the given driving value with no activity at any time (see 12.6.3).
If an actual signal is associated with a port of any mode, and if the type of the formal is a scalar type, then it
is an error if (after applying any conversion function or type conversion expression present in the actual part)
the bounds and direction of the subtype denoted by the subtype indication of the formal are not identical to
the bounds and direction of the subtype denoted by the subtype indication of the actual. If an actual expression is associated with a formal port (of mode in), and if the type of the formal is a scalar type, then it is an
error if the value of the expression does not belong to the subtype denoted by the subtype indication of the
declaration of the formal.
If an actual signal or expression is associated with a formal port, and if the formal is of a constrained array
subtype, then it is an error if the actual does not contain a matching element for each element of the formal.
In the case of an actual signal, this check is made after applying any conversion function or type conversion
that is present in the actual part. If an actual signal or expression is associated with a formal port, and if the
subtype denoted by the subtype indication of the declaration of the formal is an unconstrained array type,
then the subtype of the formal is taken from the actual associated with that formal. It is also an error if the
mode of the formal is in or inout and the value of each element of the actual array (after applying any
conversion function or type conversion present in the actual part) does not belong to the element subtype of
the formal. If the formal port is of mode out, inout, or buffer, it is also an error if the value of each element
of the formal (after applying any conversion function or type conversion present in the formal part) does not
belong to the element subtype of the actual.
If an actual signal or expression is associated with a formal port, and if the formal is of a record subtype,
then it is an error if the rules of the preceding three paragraphs do not apply to each element of the record
subtype. In the case of an actual signal, these checks are made after applying any conversion function or type
conversion that is present in the actual part.

12.3 Elaboration of a declarative part

145

150

The elaboration of a declarative part consists of the elaboration of the declarative items, if any, in the order in
which they are given in the declarative part. This rule holds for all declarative parts, with the following three
exceptions:
a)

The entity declarative part of a design entity whose corresponding architecture is decorated with the
'FOREIGN attribute deﬁned in package STANDARD (see 5.1 and 14.2).

b)

The architecture declarative part of a design entity whose architecture is decorated with the
'FOREIGN attribute deﬁned in package STANDARD.

c)

A subprogram declarative part whose subprogram is decorated with the 'FOREIGN attribute deﬁned
in package STANDARD.

For these cases, the declarative items are not elaborated; instead, the design entity or subprogram is subject
to implementation-dependent elaboration.

155

160

In certain cases, the elaboration of a declarative item involves the evaluation of expressions that appear
within the declarative item. The value of any object denoted by a primary in such an expression must be
deﬁned at the time the primary is read (see 4.3.2). In addition, if a primary in such an expression is a function
call, then the value of any object denoted by or appearing as a part of an actual designator in the function call
must be deﬁned at the time the expression is evaluated. Additionally, it is an error if a primary that denotes a
shared variable, or a method of the protected type of a shared variable, is evaluated during the elaboration of
a declarative item.

160

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

165

IEEE
Std 1076, 2000 Edition

NOTE—It is a consequence of this rule that the name of a signal declared within a block cannot be referenced in expressions appearing in declarative items within that block, an inner block, or process statement; nor can it be passed as a
parameter to a function called during the elaboration of the block. These restrictions exist because the value of a signal is
not deﬁned until after the design hierarchy is elaborated. However, a signal parameter name may be used within
expressions in declarative items within a subprogram declarative part, provided that the subprogram is only called after
simulation begins, because the value of every signal will be deﬁned by that time.

12.3.1 Elaboration of a declaration
Elaboration of a declaration has the effect of creating the declared item.

170

For each declaration, the language rules (in particular scope and visibility rules) are such that it is either
impossible or illegal to use a given item before the elaboration of its corresponding declaration. For
example, it is not possible to use the name of a type for an object declaration before the corresponding type
declaration is elaborated. Similarly, it is illegal to call a subprogram before its corresponding body is
elaborated.
12.3.1.1 Subprogram declarations and bodies

175

Elaboration of a subprogram declaration involves the elaboration of the parameter interface list of the
subprogram declaration; this in turn involves the elaboration of the subtype indication of each interface
element to determine the subtype of each formal parameter of the subprogram.
Elaboration of a subprogram body has no effect other than to establish that the body can, from then on, be
used for the execution of calls of the subprogram.
12.3.1.2 Type declarations

180

Elaboration of a type declaration generally consists of the elaboration of the deﬁnition of the type and the
creation of that type. For a constrained array type declaration, however, elaboration consists of the elaboration of the equivalent anonymous unconstrained array type followed by the elaboration of the named subtype
of that unconstrained type.
Elaboration of an enumeration type deﬁnition has no effect other than the creation of the corresponding type.

185

Elaboration of an integer, ﬂoating point, or physical type deﬁnition consists of the elaboration of the
corresponding range constraint. For a physical type deﬁnition, each unit declaration in the deﬁnition is also
elaborated. Elaboration of a physical unit declaration has no effect other than to create the unit deﬁned by the
unit declaration.
Elaboration of an unconstrained array type deﬁnition consists of the elaboration of the element subtype
indication of the array type.

190

Elaboration of a record type deﬁnition consists of the elaboration of the equivalent single element declarations in the given order. Elaboration of an element declaration consists of elaboration of the element subtype
indication.
Elaboration of an access type deﬁnition consists of the elaboration of the corresponding subtype indication.
Elaboration of a protected type deﬁnition consists of the elaboration, in the order given, of each of the declarations occurring immediately within the protected type deﬁnition.

195

Elaboration of a protected type body has no effect other than to establish that the body, from then on, can be
used during the elaboration of objects of the given protected type.

Copyright © 2000 IEEE. All rights reserved.

161

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

12.3.1.3 Subtype declarations

200

Elaboration of a subtype declaration consists of the elaboration of the subtype indication. The elaboration of
a subtype indication creates a subtype. If the subtype does not include a constraint, then the subtype is the
same as that denoted by the type mark. The elaboration of a subtype indication that includes a constraint
proceeds as follows:
a)
b)

205

The constraint is ﬁrst elaborated.
A check is then made that the constraint is compatible with the type or subtype denoted by the type
mark (see 3.1 and 3.2.1.1).

Elaboration of a range constraint consists of the evaluation of the range. The evaluation of a range deﬁnes
the bounds and direction of the range. Elaboration of an index constraint consists of the elaboration of each
of the discrete ranges in the index constraint in some order that is not deﬁned by the language.
12.3.1.4 Object declarations
Elaboration of an object declaration that declares an object other than a ﬁle object or an object of a protected
type proceeds as follows:
a)

The subtype indication is ﬁrst elaborated; this establishes the subtype of the object.

210

b)

If the object declaration includes an explicit initialization expression, then the initial value of the
object is obtained by evaluating the expression. It is an error if the value of the expression does not
belong to the subtype of the object; if the object is an array object, then an implicit subtype conversion is ﬁrst performed on the value unless the object is a constant whose subtype indication denotes
an unconstrained array type. Otherwise, any implicit initial value for the object is determined.

215

c)

The object is created.

d)

Any initial value is assigned to the object.

220

The initialization of such an object (either the declared object or one of its subelements) involves a check
that the initial value belongs to the subtype of the object. For an array object declared by an object declaration, an implicit subtype conversion is ﬁrst applied as for an assignment statement, unless the object is a
constant whose subtype is an unconstrained array type.
The elaboration of a ﬁle object declaration consists of the elaboration of the subtype indication followed by
the creation of the object. If the ﬁle object declaration contains ﬁle open information, then the implicit call to
FILE_OPEN is then executed (see 4.3.1.4).

225

The elaboration of an object of a protected type consists of the elaboration of the subtype indication,
followed by creation of the object. Creation of the object consists of elaborating, in the order given, each of
the declarative items in the protected type body.
NOTES
1—These rules apply to all object declarations other than port and generic declarations, which are elaborated as outlined
in 12.2.1 through 12.2.4.

230

2—The expression initializing a constant object need not be a static expression.
3—Each object whose type is a protected type creates an instance of the shared objects.

162

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

12.3.1.5 Alias declarations

235

Elaboration of an alias declaration consists of the elaboration of the subtype indication to establish the
subtype associated with the alias, followed by the creation of the alias as an alternative name for the named
entity. The creation of an alias for an array object involves a check that the subtype associated with the alias
includes a matching element for each element of the named object. It is an error if this check fails.
12.3.1.6 Attribute declarations
Elaboration of an attribute declaration has no effect other than to create a template for deﬁning attributes of
items.
12.3.1.7 Component declarations
Elaboration of a component declaration has no effect other than to create a template for instantiating component instances.
12.3.2 Elaboration of a speciﬁcation

240

Elaboration of a speciﬁcation has the effect of associating additional information with a previously declared
item.
12.3.2.1 Attribute speciﬁcations
Elaboration of an attribute speciﬁcation proceeds as follows:

245

250

a)

The entity speciﬁcation is elaborated in order to determine which items are affected by the attribute
speciﬁcation.

b)

The expression is evaluated to determine the value of the attribute. It is an error if the value of the
expression does not belong to the subtype of the attribute; if the attribute is of an array type, then an
implicit subtype conversion is ﬁrst performed on the value, unless the subtype indication of the
attribute denotes an unconstrained array type.

c)

A new instance of the designated attribute is created and associated with each of the affected items.

d)

Each new attribute instance is assigned the value of the expression.

The assignment of a value to an instance of a given attribute involves a check that the value belongs to the
subtype of the designated attribute. For an attribute of a constrained array type, an implicit subtype conversion is ﬁrst applied as for an assignment statement. No such conversion is necessary for an attribute of an
unconstrained array type; the constraints on the value determine the constraints on the attribute.
255

NOTE—The expression in an attribute speciﬁcation need not be a static expression.

12.3.2.2 Conﬁguration speciﬁcations
Elaboration of a conﬁguration speciﬁcation proceeds as follows:
a)

The component speciﬁcation is elaborated in order to determine which component instances are
affected by the conﬁguration speciﬁcation.

b)

The binding indication is elaborated to identify the design entity to which the affected component
instances will be bound.

c)

The binding information is associated with each affected component instance label for later use in
instantiating those component instances.

260

Copyright © 2000 IEEE. All rights reserved.

163

IEEE
Std 1076, 2000 Edition

265

IEEE STANDARD VHDL

As part of this elaboration process, a check is made that both the entity declaration and the corresponding
architecture body implied by the binding indication exist within the speciﬁed library. It is an error if this
check fails.
12.3.2.3 Disconnection speciﬁcations
Elaboration of a disconnection speciﬁcation proceeds as follows:
a)

The guarded signal speciﬁcation is elaborated in order to identify the signals affected by the disconnection speciﬁcation.

b)

The time expression is evaluated to determine the disconnection time for drivers of the affected
signals.

c)

The disconnection time is associated with each affected signal for later use in constructing disconnection statements in the equivalent processes for guarded assignments to the affected signals.

270

12.4 Elaboration of a statement part

275

Concurrent statements appearing in the statement part of a block must be elaborated before execution
begins. Elaboration of the statement part of a block consists of the elaboration of each concurrent statement
in the order given. This rule holds for all block statement parts except for those blocks equivalent to a design
entity whose corresponding architecture is decorated with the 'FOREIGN attribute deﬁned in package
STANDARD (see 14.2).
For this case, the statements are not elaborated; instead, the design entity is subject to implementationdependent elaboration.
12.4.1 Block statements

280

285

290

Elaboration of a block statement consists of the elaboration of the block header, if present, followed by the
elaboration of the block declarative part, followed by the elaboration of the block statement part.
Elaboration of a block statement may occur under the control of a conﬁguration declaration. In particular, a
block conﬁguration, whether implicit or explicit, within a conﬁguration declaration may supply a sequence
of additional implicit conﬁguration speciﬁcations to be applied during the elaboration of the corresponding
block statement. If a block statement is being elaborated under the control of a conﬁguration declaration,
then the sequence of implicit conﬁguration speciﬁcations supplied by the block conﬁguration is elaborated
as part of the block declarative part, following all other declarative items in that part.
The sequence of implicit conﬁguration speciﬁcations supplied by a block conﬁguration, whether implicit or
explicit, consists of each of the conﬁguration speciﬁcations implied by component conﬁgurations (see 1.3.2)
occurring immediately within the block conﬁguration, in the order in which the component conﬁgurations
themselves appear.
12.4.2 Generate statements

295

Elaboration of a generate statement consists of the replacement of the generate statement with zero or more
copies of a block statement whose declarative part consists of the declarative items contained within the generate statement and whose statement part consists of the concurrent statements contained within the generate
statement. These block statements are said to be represented by the generate statement. Each block statement is then elaborated.

164

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

For a generate statement with a for generation scheme, elaboration consists of the elaboration of the discrete
range, followed by the generation of one block statement for each value in the range. The block statements
all have the following form:
300

a)

The label of the block statement is the same as the label of the generate statement.

b)

The block declarative part has, as its ﬁrst item, a single constant declaration that declares a constant
with the same simple name as that of the applicable generate parameter; the value of the constant is
the value of the generate parameter for the generation of this particular block statement. The type of
this declaration is determined by the base type of the discrete range of the generate parameter. The
remainder of the block declarative part consists of a copy of the declarative items contained within
the generate statement.

c)

The block statement part consists of a copy of the concurrent statements contained within the
generate statement.

305

310

315

For a generate statement with an if generation scheme, elaboration consists of the evaluation of the Boolean
expression, followed by the generation of exactly one block statement if the expression evaluates to TRUE,
and no block statement otherwise. If generated, the block statement has the following form:
—

The block label is the same as the label of the generate statement.

—

The block declarative part consists of a copy of the declarative items contained within the generate
statement.

—

The block statement part consists of a copy of the concurrent statements contained within the
generate statement.

Examples:
-- The following generate statement:

320

325

330

335

LABL : for I in 1 to 2 generate
signal s1 : INTEGER;
begin
s1 <= p1;
Inst1 : and_gate port map (s1, p2(I), p3);
end generate LABL;
-- is equivalent to the following two block statements:
LABL : block
constant I : INTEGER := 1;
signal s1 : INTEGER;
begin
s1 <= p1;
Inst1 : and_gate port map (s1, p2(I), p3);
end block LABL;
LABL : block
constant I : INTEGER := 2;
signal s1 : INTEGER;
begin
s1 <= p1;
Inst1 : and_gate port map (s1, p2(I), p3);
end block LABL;

Copyright © 2000 IEEE. All rights reserved.

165

IEEE
Std 1076, 2000 Edition

340

345

IEEE STANDARD VHDL

-- The following generate statement:
LABL : if (g1 = g2) generate
signal s1 : INTEGER;
begin
s1 <= p1;
Inst1 : and_gate port map (s1, p4, p3);
end generate LABL;
-- is equivalent to the following statement if g1 = g2;
-- otherwise, it is equivalent to no statement at all:

350

355

LABL : block
signal s1 : INTEGER;
begin
s1 <= p1;
Inst1 : and_gate port map (s1, p4, p3);
end block LABL;
NOTE—The repetition of the block labels in the case of a for generation scheme does not produce multiple declarations
of the label on the generate statement. The multiple block statements represented by the generate statement constitute
multiple references to the same implicitly declared label.

12.4.3 Component instantiation statements

360

365

Elaboration of a component instantiation statement that instantiates a component declaration has no effect
unless the component instance is either fully bound to a design entity deﬁned by an entity declaration and
architecture body or bound to a conﬁguration of such a design entity. If a component instance is so bound,
then elaboration of the corresponding component instantiation statement consists of the elaboration of the
implied block statement representing the component instance and (within that block) the implied block statement representing the design entity to which the component instance is bound. The implied block statements
are deﬁned in 9.6.1.
Elaboration of a component instantiation statement whose instantiated unit denotes either a design entity or
a conﬁguration declaration consists of the elaboration of the implied block statement representing the
component instantiation statement and (within that block) the implied block statement representing the
design entity to which the component instance is bound. The implied block statements are deﬁned in 9.6.2.
12.4.4 Other concurrent statements

370

All other concurrent statements are either process statements or are statements for which there is an equivalent process statement.
Elaboration of a process statement proceeds as follows:
a)
b)
c)

375

The process declarative part is elaborated.
The drivers required by the process statement are created.
The initial transaction deﬁned by the default value associated with each scalar signal driven by the
process statement is inserted into the corresponding driver.

Elaboration of all concurrent signal assignment statements and concurrent assertion statements consists of
the construction of the equivalent process statement followed by the elaboration of the equivalent process
statement.

166

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

12.5 Dynamic elaboration

380

The execution of certain constructs that involve sequential statements rather than concurrent statements also
involves elaboration. Such elaboration occurs during the execution of the model.
There are three particular instances in which elaboration occurs dynamically during simulation. These are as
follows:
a)

Execution of a loop statement with a for iteration scheme involves the elaboration of the loop
parameter speciﬁcation prior to the execution of the statements enclosed by the loop (see 8.9). This
elaboration creates the loop parameter and evaluates the discrete range.

b)

Execution of a subprogram call involves the elaboration of the parameter interface list of the corresponding subprogram declaration; this involves the elaboration of each interface declaration to
create the corresponding formal parameters. Actual parameters are then associated with formal
parameters. Next, if the subprogram is a method of a given protected type (see 3.5.1), the elaboration
blocks, if necessary, until exclusive access to the object denoted by the preﬁx is secured. Finally, if
the designator of the subprogram is not decorated with the 'FOREIGN attribute deﬁned in package
STANDARD, the declarative part of the corresponding subprogram body is elaborated and the
sequence of statements in the subprogram body is executed. If the designator of the subprogram is
decorated with the 'FOREIGN attribute deﬁned in package STANDARD, then the subprogram body
is subject to implementation-dependent elaboration and execution.

c)

Evaluation of an allocator that contains a subtype indication involves the elaboration of the subtype
indication prior to the allocation of the created object.

385

390

395

NOTES
400

405

1—It is a consequence of these rules that declarative items appearing within the declarative part of a subprogram body
are elaborated each time the corresponding subprogram is called; thus, successive elaborations of a given declarative
item appearing in such a place may create items with different characteristics. For example, successive elaborations of
the same subtype declaration appearing in a subprogram body may create subtypes with different constraints.
2—If two or more processes access the same set of shared variables, livelock or deadlock may occur. That is, it may not
be possible to ever grant exclusive access to the shared variable as outlined in item b), above. Implementations are
allowed to, but not required to, detect and, if possible, resolve such conditions.

12.6 Execution of a model
The elaboration of a design hierarchy produces a model that can be executed in order to simulate the design
represented by the model. Simulation involves the execution of user-deﬁned processes that interact with
each other and with the environment.

410

415

The kernel process is a conceptual representation of the agent that coordinates the activity of user-deﬁned
processes during a simulation. This agent causes the propagation of signal values to occur and causes the
values of implicit signals [such as S'Stable(T)] to be updated. Furthermore, this process is responsible for
detecting events that occur and for causing the appropriate processes to execute in response to those events.
For any given signal that is explicitly declared within a model, the kernel process contains a variable
representing the current value of that signal. Any evaluation of a name denoting a given signal retrieves the
current value of the corresponding variable in the kernel process. During simulation, the kernel process
updates these variables from time to time, based upon the current values of sources of the corresponding
signal.

Copyright © 2000 IEEE. All rights reserved.

167

IEEE
Std 1076, 2000 Edition

420

IEEE STANDARD VHDL

In addition, the kernel process contains a variable representing the current value of any implicitly declared
GUARD signal resulting from the appearance of a guard expression on a given block statement. Furthermore, the kernel process contains both a driver for, and a variable representing the current value of, any
signal S'Stable(T), for any preﬁx S and any time T, that is referenced within the model; likewise, for any
signal S'Quiet(T) or S'Transaction.
12.6.1 Drivers

425

430

Every signal assignment statement in a process statement deﬁnes a set of drivers for certain scalar signals.
There is a single driver for a given scalar signal S in a process statement, provided that there is at least one
signal assignment statement in that process statement and that the longest static preﬁx of the target signal of
that signal assignment statement denotes S or denotes a composite signal of which S is a subelement. Each
such signal assignment statement is said to be associated with that driver. Execution of a signal assignment
statement affects only the associated driver(s).
A driver for a scalar signal is represented by a projected output waveform. A projected output waveform
consists of a sequence of one or more transactions, where each transaction is a pair consisting of a value
component and a time component. For a given transaction, the value component represents a value that the
driver of the signal is to assume at some point in time, and the time component speciﬁes which point in time.
These transactions are ordered with respect to their time components.

435

A driver always contains at least one transaction. The initial contents of a driver associated with a given
signal are deﬁned by the default value associated with the signal (see 4.3.1.2).

440

For any driver, there is exactly one transaction whose time component is not greater than the current simulation time. The current value of the driver is the value component of this transaction. If, as the result of the
advance of time, the current time becomes equal to the time component of the next transaction, then the ﬁrst
transaction is deleted from the projected output waveform and the next becomes the current value of the
driver.
12.6.2 Propagation of signal values

445

As simulation time advances, the transactions in the projected output waveform of a given driver (see 12.6.1)
will each, in succession, become the value of the driver. When a driver acquires a new value in this way,
regardless of whether the new value is different from the previous value, that driver is said to be active
during that simulation cycle. For the purposes of deﬁning driver activity, a driver acquiring a value from a
null transaction is assumed to have acquired a new value. A signal is said to be active during a given simulation cycle if
—
—
—

450

—

455

One of its sources is active
One of its subelements is active
The signal is named in the formal part of an association element in a port association list and the
corresponding actual is active
The signal is a subelement of a resolved signal and the resolved signal is active.

If a signal of a given composite type has a source that is of a different type (and therefore a conversion
function or type conversion appears in the corresponding association element), then each scalar subelement
of that signal is considered to be active if the source itself is active. Similarly, if a port of a given composite
type is associated with a signal that is of a different type (and therefore a conversion function or type
conversion appears in the corresponding association element), then each scalar subelement of that port is
considered to be active if the actual signal itself is active.

168

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

In addition to the preceding information, an implicit signal is said to be active during a given simulation
cycle if the kernel process updates that implicit signal within the given cycle.
460

465

If a signal is not active during a given simulation cycle, then the signal is said to be quiet during that
simulation cycle.
The kernel process determines two values for certain signals during any given simulation cycle. The driving
value of a given signal is the value that signal provides as a source of other signals. The effective value of a
given signal is the value obtainable by evaluating a reference to the signal within an expression. The driving
value and the effective value of a signal are not always the same, especially when resolution functions and
conversion functions or type conversions are involved in the propagation of signal values.
A basic signal is a signal that has all of the following properties:

470

—
—
—
—

It is either a scalar signal or a resolved signal (see 4.3.1.2)
It is not a subelement of a resolved signal
Is not an implicit signal of the form S'Stable(T), S'Quiet(T), or S'Transaction (see 14.1)
It is not an implicit signal GUARD (see 9.1).

Basic signals are those that determine the driving values for all other signals.
The driving value of any basic signal S is determined as follows:
—

If S has no source, then the driving value of S is given by the default value associated with S (see
4.3.1.2).

—

If S has one source that is a driver and S is not a resolved signal (see 4.3.1.2), then the driving value
of S is the value of that driver.

—

If S has one source that is a port and S is not a resolved signal, then the driving value of S is the
driving value of the formal part of the association element that associates S with that port (see
4.3.2.2). The driving value of a formal part is obtained by evaluating the formal part as follows: If no
conversion function or type conversion is present in the formal part, then the driving value of the
formal part is the driving value of the signal denoted by the formal designator. Otherwise, the driving
value of the formal part is the value obtained by applying either the conversion function or type
conversion (whichever is contained in the formal part) to the driving value of the signal denoted by
the formal designator.

—

If S is a resolved signal and has one or more sources, then the driving values of the sources of S are
examined. It is an error if any of these driving values is a composite where one or more subelement
values are determined by the null transaction (see 8.4.1) and one or more subelement values are not
determined by the null transaction. If S is of signal kind register and all the sources of S have values
determined by the null transaction, then the driving value of S is unchanged from its previous value.
Otherwise, the driving value of S is obtained by executing the resolution function associated with S,
where that function is called with an input parameter consisting of the concatenation of the driving
values of the sources of S, with the exception of the value of any source of S whose current value is
determined by the null transaction.

475

480

485

490

495

The driving value of any signal S that is not a basic signal is determined as follows:
—
—

If S is a subelement of a resolved signal R, the driving value of S is the corresponding subelement
value of the driving value of R.
Otherwise (S is a nonresolved, composite signal), the driving value of S is equal to the aggregate of
the driving values of each of the basic signals that are the subelements of S.

Copyright © 2000 IEEE. All rights reserved.

169

IEEE
Std 1076, 2000 Edition

500

For a scalar signal S, the effective value of S is determined in the following manner:
—

If S is a signal declared by a signal declaration, a port of mode buffer, or an unconnected port of
mode inout, then the effective value of S is the same as the driving value of S.

—

If S is a connected port of mode in or inout, then the effective value of S is the same as the effective
value of the actual part of the association element that associates an actual with S (see 4.3.2.2). The
effective value of an actual part is obtained by evaluating the actual part, using the effective value of
the signal denoted by the actual designator in place of the actual designator.

—

If S is an unconnected port of mode in, the effective value of S is given by the default value associated with S (see 4.3.1.2).

505

510

IEEE STANDARD VHDL

For a composite signal R, the effective value of R is the aggregate of the effective values of each of the subelements of R.
For a scalar signal S, both the driving and effective values must belong to the subtype of the signal. For a
composite signal R, an implicit subtype conversion is performed to the subtype of R; for each element of R,
there must be a matching element in both the driving and the resolved value, and vice versa.

515

In order to update a signal during a given simulation cycle, the kernel process ﬁrst determines the driving
and effective values of that signal. The kernel process then updates the variable containing the current value
of the signal with the newly determined effective value, as follows:
a)

If S is a signal of some type that is not an array type, the effective value of S is used to update the
current value of S. A check is made that the effective value of S belongs to the subtype of S. An error
occurs if this subtype check fails. Finally, the effective value of S is assigned to the variable representing the current value of the signal.

b)

If S is an array signal (including a slice of an array), the effective value of S is implicitly converted to
the subtype of S. The subtype conversion checks that for each element of S there is a matching
element in the effective value and vice versa. An error occurs if this check fails. The result of this
subtype conversion is then assigned to the variable representing the current value of S.

520

525

If updating a signal causes the current value of that signal to change, then an event is said to have occurred
on the signal. This deﬁnition applies to any updating of a signal, whether such updating occurs according to
the above rules or according to the rules for updating implicit signals given in 12.6.3. The occurrence of an
event may cause the resumption and subsequent execution of certain processes during the simulation cycle
in which the event occurs.

530

For any signal other than one declared with the signal kind register, the driving and effective values of the
signal are determined and the current value of that signal is updated as described above in every simulation
cycle. A signal declared with the signal kind register is updated in the same fashion during every simulation
cycle except those in which all of its sources have current values that are determined by null transactions.

535

A net is a collection of drivers, signals (including ports and implicit signals), conversion functions, and
resolution functions that, taken together, determine the effective and driving values of every signal on the
net.
Implicit signals GUARD, S'Stable(T), S'Quiet(T), and S'Transaction, for any preﬁx S and any time T, are not
updated according to the above rules; such signals are updated according to the rules described in 12.6.3.

170

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

NOTES
540

1—In a simulation cycle, a subelement of a composite signal may be quiet, but the signal itself may be active.

545

2—The rules concerning association of actuals with formals (see 4.3.2.2) imply that, if a composite signal is associated
with a composite port of mode out, inout, or buffer, and if no conversion function or type conversion appears in either
the actual or formal part of the association element, then each scalar subelement of the formal is a source of the matching
subelement of the actual. In such a case, a given subelement of the actual will be active if and only if the matching
subelement of the formal is active.
3—The algorithm for computing the driving value of a scalar signal S is recursive. For example, if S is a local signal
appearing as an actual in a port association list whose formal is of mode out or inout, the driving value of S can only be
obtained after the driving value of the corresponding formal part is computed. This computation may involve multiple
executions of the above algorithm.

550

4—Similarly, the algorithm for computing the effective value of a signal S is recursive. For example, if a formal port S of
mode in corresponds to an actual A, the effective value of A must be computed before the effective value of S can be
computed. The actual A may itself appear as a formal port in a port association list.
5—No effective value is speciﬁed for out and linkage ports, since these ports may not be read.
6—Overloading the operator “=” has no effect on the propagation of signal values.

555

7—A signal of kind register may be active even if its associated resolution function does not execute in the current
simulation cycle if the values of all of its drivers are determined by the null transaction and at least one of its drivers is
also active.
8—The deﬁnition of the driving value of a basic signal exhausts all cases, with the exception of a non-resolved signal
with more than one source. This condition is deﬁned as an error in 4.3.1.2.

12.6.3 Updating implicit signals
560

565

The kernel process updates the value of each implicit signal GUARD associated with a block statement that
has a guard expression. Similarly, the kernel process updates the values of each implicit signal S'Stable(T),
S'Quiet(T), or S'Transaction for any preﬁx S and any time T; this also involves updating the drivers of
S'Stable(T) and S'Quiet(T).
For any implicit signal GUARD, the current value of the signal is modiﬁed if and only if the corresponding
guard expression contains a reference to a signal S and if S is active during the current simulation cycle. In
such a case, the implicit signal GUARD is updated by evaluating the corresponding guard expression and
assigning the result of that evaluation to the variable representing the current value of the signal.
For any implicit signal S'Stable(T), the current value of the signal (and likewise the current state of the
corresponding driver) is modiﬁed if and only if one of the following statements is true:

570

575

—
—

An event has occurred on S in this simulation cycle
The driver of S'Stable(T) is active.

If an event has occurred on signal S, then S'Stable(T) is updated by assigning the value FALSE to the
variable representing the current value of S'Stable(T), and the driver of S'Stable(T) is assigned the waveform
TRUE after T. Otherwise, if the driver of S'Stable(T) is active, then S'Stable(T) is updated by assigning the
current value of the driver to the variable representing the current value of S'Stable(T). Otherwise, neither
the variable nor the driver is modiﬁed.
Similarly, for any implicit signal S'Quiet(T), the current value of the signal (and likewise the current state of
the corresponding driver) is modiﬁed if and only if one of the following statements is true:

580

—
—

S is active
The driver of S'Quiet(T) is active.

Copyright © 2000 IEEE. All rights reserved.

171

IEEE
Std 1076, 2000 Edition

585

IEEE STANDARD VHDL

If signal S is active, then S'Quiet(T) is updated by assigning the value FALSE to the variable representing the
current value of S'Quiet(T), and the driver of S'Quiet(T) is assigned the waveform TRUE after T. Otherwise,
if the driver of S'Quiet(T) is active, then S'Quiet(T) is updated by assigning the current value of the driver to
the variable representing the current value of S'Quiet(T). Otherwise, neither the variable nor the driver is
modiﬁed.
Finally, for any implicit signal S'Transaction, the current value of the signal is modiﬁed if and only if S is
active. If signal S is active, then S'Transaction is updated by assigning the value of the expression (not
S'Transaction) to the variable representing the current value of S'Transaction. At most one such assignment
will occur during any given simulation cycle.

590

For any implicit signal S'Delayed(T), the signal is not updated by the kernel process. Instead, it is updated by
constructing an equivalent process (see 14.1) and executing that process.
The current value of a given implicit signal denoted by R is said to depend upon the current value of another
signal S if one of the following statements is true:
—
—
—

R denotes an implicit GUARD signal and S is any other implicit signal named within the guard
expression that deﬁnes the current value of R.
R denotes an implicit signal S'Stable(T).
R denotes an implicit signal S'Quiet(T).

—
—

R denotes an implicit signal S'Transaction.
R denotes an implicit signal S'Delayed(T).

595

600

605

These rules deﬁne a partial ordering on all signals within a model. The updating of implicit signals by the
kernel process is guaranteed to proceed in such a manner that, if a given implicit signal R depends upon the
current value of another signal S, then the current value of S will be updated during a particular simulation
cycle prior to the updating of the current value of R.
NOTE—These rules imply that, if the driver of S'Stable(T) is active, then the new current value of that driver is the value
TRUE. Furthermore, these rules imply that, if an event occurs on S during a given simulation cycle, and if the driver of
S'Stable(T) becomes active during the same cycle, the variable representing the current value of S'Stable(T) will be
assigned the value FALSE, and the current value of the driver of S'Stable(T) during the given cycle will never be
assigned to that signal.

12.6.4 The simulation cycle

610

The execution of a model consists of an initialization phase followed by the repetitive execution of process
statements in the description of that model. Each such repetition is said to be a simulation cycle. In each
cycle, the values of all signals in the description are computed. If as a result of this computation an event
occurs on a given signal, process statements that are sensitive to that signal will resume and will be executed
as part of the simulation cycle.
At the beginning of initialization, the current time, Tc, is assumed to be 0 ns.

615

The initialization phase consists of the following steps:
—

The driving value and the effective value of each explicitly declared signal are computed, and the
current value of the signal is set to the effective value. This value is assumed to have been the value
of the signal for an inﬁnite length of time prior to the start of simulation.

—

The value of each implicit signal of the form S'Stable(T) or S'Quiet(T) is set to True. The value of
each implicit signal of the form S'Delayed(T) is set to the initial value of its preﬁx, S.

620

172

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

625

IEEE
Std 1076, 2000 Edition

—

The value of each implicit GUARD signal is set to the result of evaluating the corresponding guard
expression.

—

Each nonpostponed process in the model is executed until it suspends.

—

Each postponed process in the model is executed until it suspends.

—

The time of the next simulation cycle (which in this case is the ﬁrst simulation cycle), Tn, is
calculated according to the rules of step f) of the simulation cycle, below.

A simulation cycle consists of the following steps:

630

a)

The current time, Tc, is set equal to Tn. Simulation is complete when Tn = TIME'HIGH and there are
no active drivers or process resumptions at Tn.

b)

Each active explicit signal in the model is updated. (Events may occur on signals as a result.)

c)

Each implicit signal in the model is updated. (Events may occur on signals as a result.)

d)

For each process, P, if P is currently sensitive to a signal, S, and if an event has occurred on S in this
simulation cycle, then P resumes.

e)

Each nonpostponed process that has resumed in the current simulation cycle is executed until it
suspends.

f)

If the break ﬂag is set, the time of the next simulation cycle, Tn, is determined by setting it to the
earliest of

635

1)
2)
3)

640

TIME'HIGH,
The next time at which a driver becomes active, or
The next time at which a process resumes.

If Tn = Tc, then the next simulation cycle (if any) will be a delta cycle.
g)

645

If the next simulation cycle will be a delta cycle, the remainder of this step is skipped. Otherwise,
each postponed process that has resumed but has not been executed since its last resumption is
executed until it suspends. Then Tn is recalculated according to the rules of step f). It is an error if
the execution of any postponed process causes a delta cycle to occur immediately after the current
simulation cycle.

NOTES
1—The initial value of any implicit signal of the form S'Transaction is not deﬁned.
2—Updating of explicit signals is described in 12.6.2; updating of implicit signals is described in 12.6.3.
650

3—When a process resumes, it is added to one of two sets of processes to be executed (the set of postponed processes
and the set of nonpostponed processes). However, no process actually begins to execute until all signals have been
updated and all executable processes for this simulation cycle have been identiﬁed. Nonpostponed processes are always
executed during step e) of every simulation cycle, while postponed processes are executed during step g) of every simulation cycle that does not immediately precede a delta cycle.

655

4—The second and third steps of the initialization phase and steps b) and c) of the simulation cycle may occur in interleaved fashion. This interleaving may occur because the implicit signal GUARD may be used as the preﬁx of another
implicit signal; moreover, implicit signals may be associated as actuals with explicit signals, making the value of an
explicit signal a function of an implicit signal.

Copyright © 2000 IEEE. All rights reserved.

173

IEEE
Std 1076, 2000 Edition

174

IEEE STANDARD VHDL

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

13. Lexical elements
The text of a description consists of one or more design ﬁles. The text of a design ﬁle is a sequence of lexical
elements, each composed of characters; the rules of composition are given in this clause.

13.1 Character set

5

The only characters allowed in the text of a VHDL description are the graphic characters and format effectors. Each graphic character corresponds to a unique code of the ISO eight-bit coded character set (ISO
8859-1: 1987 [B6]) and is represented (visually) by a graphical symbol.
basic_graphic_character ::=
upper_case_letter | digit | special_character | space_character
graphic_character ::=
basic_graphic_character | lower_case_letter | other_special_character

10

basic_character ::=
basic_graphic_character | format_effector
The basic character set is sufﬁcient for writing any description. The characters included in each of the
categories of basic graphic characters are deﬁned as follows:
a)

Uppercase letters
A B C D E F G H I J K L M N O P Q R S T UV W XY Z À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î
. Ñ Ò Ó Ô Õ Ö Ø Ù Ú Û Ü Ý P'
ÏD

15

b)

Digits
0123456789

c)

Special characters
" # & ' () * + , - . / : ; < = > [ ] _ |

20

d)

The space characters
SPACE2 NBSP3

Format effectors are the ISO (and ASCII) characters called horizontal tabulation, vertical tabulation, carriage
return, line feed, and form feed.
25

The characters included in each of the remaining categories of graphic characters are deﬁned as follows:
e)

Lowercase letters
a b c d e f g h i j k l m n o p q r s t u v w x y z ß à á â ã ä å æ ç è é ê ë ì í î ï ∂´ ñ ò ó ô
õ ö ø ù ú û ü ý p' ÿ

f)
30

Other special characters
|

! $ % @ ? \ ^ ` { } ~ ¡ ¢ £ € ¥ | § ¨ © ª « ¬ -® ¯ ° ± 2 3 ´ µ ¶ • ¸ 1 º » 1/4 1/2 3/4 ¿ ◊ ÷ - (soft hyphen)
2The visual representation of the space is the absence of a graphic symbol. It may be interpreted as a graphic character, a control
character, or both.
3The visual representation of the nonbreaking space is the absence of a graphic symbol. It is used when a line break is to be prevented
in the text as presented.

Copyright © 2000 IEEE. All rights reserved.

175

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

Allowable replacements for the special characters vertical line (|), number sign (#), and quotation mark (")
are deﬁned in 13.10.
NOTES
35

1—The font design of graphical symbols (for example, whether they are in italic or bold typeface) is not part of ISO
8859-1:1987 [B6].
2—The meanings of the acronyms used in this clause are as follows: ASCII stands for American Standard Code for
Information Interchange, ISO stands for International Organization for Standardization.
3—There are no uppercase equivalents for the characters ß and ÿ.
4—The following names are used when referring to special characters:

40

Character

45

50

55

60

65

176

Name

"

Quotation mark

#

Number sign

&

Ampersand

'

Apostrophe, tick

(

Left parenthesis

)

Right parenthesis

*

Asterisk, multiply

+

Plus sign

,

Comma

-

Hyphen, minus sign

.

Dot, point, period, full stop

/

Slash, divide, solidus

:

Colon

;

Semicolon

<

Less-than sign

=

Equals sign

>

Greater-than sign

_

Underline, low line

|

Vertical line, vertical bar

!

Exclamation mark

$

Dollar sign

%

Percent sign

?

Question mark

@

Commercial at

[

Left square bracket

\

Backslash, reverse solidus

]

Right square bracket

^

Circumﬂex accent

`

Grave accent

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

70

Character

75

80

85

90

95

100

105

Name

{

Left curly bracket

}

Right curly bracket

~

Tilde

¡

Inverted exclamation mark

¢

Cent sign

£

Pound sign

€

Currency sign

¥
|
|

Yen sign

§

Paragraph sign, clause sign

¨

Diaeresis

©

Copyright sign

ª

Feminine ordinal indicator

«

Left angle quotation mark

¬

Not sign

-

Soft hyphen*

®

Registered trade mark sign

¯

Macron

°

Ring above, degree sign

±

Plus-minus sign

2

Superscript two

3

Superscript three

´

Acute accent

µ

Micro sign

¶

Pilcrow sign

•

Middle dot

Broken bar

¸

Cedilla

1

Superscript one

º

Masculine ordinal indicator

»

Right angle quotation mark

1/
4
1/
2
3/
4

Vulgar fraction one quarter
Vulgar fraction one half
Vulgar fraction three quarters

¿

Inverted question mark

◊

Multiplication sign

÷

Division sign

*The

110

soft hyphen is a graphic character that is represented by a graphic symbol identical with, or similar
to, that representing a hyphen, for use when a line
break has been established within a work.

Copyright © 2000 IEEE. All rights reserved.

177

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

13.2 Lexical elements, separators, and delimiters
The text of each design unit is a sequence of separate lexical elements. Each lexical element is either a
delimiter, an identiﬁer (which may be a reserved word), an abstract literal, a character literal, a string literal,
a bit string literal, or a comment.

115

120

In some cases an explicit separator is required to separate adjacent lexical elements (namely when, without
separation, interpretation as a single lexical element is possible). A separator is either a space character
(SPACE or NBSP), a format effector, or the end of a line. A space character (SPACE or NBSP) is a separator
except within a comment, a string literal, or a space character literal.
The end of a line is always a separator. The language does not deﬁne what causes the end of a line. However
if, for a given implementation, the end of a line is signiﬁed by one or more characters, then these characters
must be format effectors other than horizontal tabulation. In any case, a sequence of one or more format
effectors other than horizontal tabulation must cause at least one end-of-line.
One or more separators are allowed between any two adjacent lexical elements, before the ﬁrst of each
design unit or after the last lexical element of a design ﬁle. At least one separator is required between an
identiﬁer or an abstract literal and an adjacent identiﬁer or abstract literal.

125

A delimiter is either one of the following special characters (in the basic character set):
& ' ( ) * + , - . / : ; < = > |[]
or one of the following compound delimiters, each composed of two adjacent special characters:
=> ** := /= >= <= <>

130

Each of the special characters listed for single character delimiters is a single delimiter except if this character is used as a character of a compound delimiter or as a character of a comment, string literal, character
literal, or abstract literal.
The remaining forms of lexical elements are described in subclauses of this clause.
NOTES

135

1—Each lexical element must ﬁt on one line, since the end of a line is a separator. The quotation mark, number sign, and
underline characters, likewise two adjacent hyphens, are not delimiters, but may form part of other lexical elements.
2—The following names are used when referring to compound delimiters:

140

178

Delimiter

Name

=>

Arrow

**

Double star, exponentiate

:=

Variable assignment

/=

Inequality (pronounced “not equal”)

>=

Greater than or equal

<=

Less than or equal; signal assignment

<>

Box

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

13.3 Identiﬁers
145

Identiﬁers are used as names and also as reserved words.
identiﬁer ::= basic_identiﬁer | extended_identiﬁer
13.3.1 Basic identiﬁers
A basic identiﬁer consists only of letters, digits, and underlines.
basic_identiﬁer ::=
letter { [ underline ] letter_or_digit }

150

letter_or_digit ::= letter | digit
letter ::= upper_case_letter | lower_case_letter
All characters of a basic identiﬁer are signiﬁcant, including any underline character inserted between a letter
or digit and an adjacent letter or digit. Basic identiﬁers differing only in the use of corresponding uppercase
and lowercase letters are considered the same.

155

Examples:
COUNT X
VHSIC X1

c_out
PageCount

FFT
Decoder
STORE_NEXT_ITEM

NOTE—No space (SPACE or NBSP) is allowed within a basic identiﬁer, since a space is a separator.

13.3.2 Extended identiﬁers
Extended identiﬁers may contain any graphic character.
160

165

extended_identiﬁer ::=
\ graphic_character { graphic_character } \
If a backslash is to be used as one of the graphic characters of an extended literal, it must be doubled. All
characters of an extended identiﬁer are signiﬁcant (a doubled backslash counting as one character).
Extended identiﬁers differing only in the use of corresponding uppercase and lowercase letters are distinct.
Moreover, every extended identiﬁer is distinct from any basic identiﬁer.
Examples:
\BUS

\bus\

-- Two different identiﬁers, neither of which is
-- the reserved word bus.

\a\\b\
170

VHDL

-- An identiﬁer containing three characters.
\VHDL\

\vhdl\

-- Three distinct identiﬁers.

13.4 Abstract literals
There are two classes of abstract literals: real literals and integer literals. A real literal is an abstract literal
that includes a point; an integer literal is an abstract literal without a point. Real literals are the literals of the
type universal_real. Integer literals are the literals of the type universal_integer.
abstract_literal ::= decimal_literal | based_literal

Copyright © 2000 IEEE. All rights reserved.

179

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

13.4.1 Decimal literals
175

A decimal literal is an abstract literal expressed in the conventional decimal notation (that is, the base is
implicitly ten).
decimal_literal ::= integer [ . integer ] [ exponent ]
integer ::= digit { [ underline ] digit }
exponent ::= E [ + ] integer | E – integer

180

185

An underline character inserted between adjacent digits of a decimal literal does not affect the value of this
abstract literal. The letter E of the exponent, if any, can be written either in lowercase or in uppercase, with
the same meaning.
An exponent indicates the power of ten by which the value of the decimal literal without the exponent is to
be multiplied to obtain the value of the decimal literal with the exponent. An exponent for an integer literal
must not have a minus sign.
Examples:
12
12.0
1.34E–12

190

0
0.0
1.0E+6

1E6
0.456
6.023E+24

123_456
3.14159_26

-- Integer literals.
-- Real literals.
-- Real literals with exponents.

NOTE—Leading zeros are allowed. No space (SPACE or NBSP) is allowed in an abstract literal, not even between
constituents of the exponent, since a space is a separator. A zero exponent is allowed for an integer literal.

13.4.2 Based literals
A based literal is an abstract literal expressed in a form that speciﬁes the base explicitly. The base must be at
least two and at most sixteen.

195

based_literal ::=
base # based_integer [ . based_integer ] # [ exponent ]
base ::= integer
based_integer ::=
extended_digit { [ underline ] extended_digit }
extended_digit ::= digit | letter

200

An underline character inserted between adjacent digits of a based literal does not affect the value of this
abstract literal. The base and the exponent, if any, are in decimal notation. The only letters allowed as
extended digits are the letters A through F for the digits ten through ﬁfteen. A letter in a based literal (either
an extended digit or the letter E of an exponent) can be written either in lowercase or in uppercase, with the
same meaning.

205

The conventional meaning of based notation is assumed; in particular the value of each extended digit of a
based literal must be less than the base. An exponent indicates the power of the base by which the value of
the based literal without the exponent is to be multiplied to obtain the value of the based literal with the
exponent. An exponent for a based integer literal must not have a minus sign.

180

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

Examples:
210

-- Integer literals of value 255:
2#1111_1111#
16#FF#

016#0FF#

-- Integer literals of value 224:
16#E#E1
2#1110_0000#

215

-- Real literals of value 4095.0:
16#F.FF#E+2
2#1.1111_1111_111#E11

13.5 Character literals
A character literal is formed by enclosing one of the 191 graphic characters (including the space and nonbreaking space characters) between two apostrophe characters. A character literal has a value that belongs to
a character type.
character_literal ::= ' graphic_character '
220

Examples:
'A' '*' ''' ' '

13.6 String literals
A string literal is formed by a sequence of graphic characters (possibly none) enclosed between two quotation marks used as string brackets.
string_literal ::= " { graphic_character } "
225

A string literal has a value that is a sequence of character values corresponding to the graphic characters of
the string literal apart from the quotation mark itself. If a quotation-mark value is to be represented in the
sequence of character values, then a pair of adjacent quotation marks must be written at the corresponding
place within the string literal. (This means that a string literal that includes two adjacent quotation marks is
never interpreted as two adjacent string literals.)

230

The length of a string literal is the number of character values in the sequence represented. (Each doubled
quotation mark is counted as a single character.)
Examples:

235

240

"Setup time is too short"
-- An error message.
""
-- An empty string literal.
""
"A"
""""
-- Three string literals of length 1.
"Characters such as $, %, and } are allowed in string literals."
NOTE—A string literal must ﬁt on one line, since it is a lexical element (see 13.2). Longer sequences of graphic character values can be obtained by concatenation of string literals. The concatenation operation may also be used to obtain
string literals containing nongraphic character values. The predeﬁned type CHARACTER in package STANDARD
speciﬁes the enumeration literals denoting both graphic and nongraphic characters. Examples of such uses of concatenation are
"FIRST PART OF A SEQUENCE OF CHARACTERS " &
"THAT CONTINUES ON THE NEXT LINE"
"Sequence that includes the" & ACK & "control character"

Copyright © 2000 IEEE. All rights reserved.

181

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

13.7 Bit string literals
245

A bit string literal is formed by a sequence of extended digits (possibly none) enclosed between two quotations used as bit string brackets, preceded by a base speciﬁer.
bit_string_literal ::= base_speciﬁer "[ bit_value ]"
bit_value ::= extended_digit { [ underline ] extended_digit }
base_speciﬁer ::= B | O | X

250

255

An underline character inserted between adjacent digits of a bit string literal does not affect the value of this
literal. The only letters allowed as extended digits are the letters A through F for the digits ten through
ﬁfteen. A letter in a bit string literal (either an extended digit or the base speciﬁer) can be written either in
lowercase or in uppercase, with the same meaning.
If the base speciﬁer is 'B', the extended digits in the bit value are restricted to 0 and 1. If the base speciﬁer is
'O', the extended digits in the bit value are restricted to legal digits in the octal number system, i.e., the digits
0 through 7. If the base speciﬁer is 'X', the extended digits are all digits together with the letters A through F.
A bit string literal has a value that is a string literal consisting of the character literals '0' and '1'. If the base
speciﬁer is 'B', the value of the bit string literal is the sequence given explicitly by the bit value itself after
any underlines have been removed.

260

If the base speciﬁer is 'O' (respectively 'X'), the value of the bit string literal is the sequence obtained by
replacing each extended digit in the bit_value by a sequence consisting of the three (respectively four) values
representing that extended digit taken from the character literals '0' and '1'; as in the case of the base speciﬁer
'B', underlines are ﬁrst removed. Each extended digit is replaced as follows:
Extended digit

265

0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F

270

275

280

182

Replacement when the base speciﬁer is
'O'
000
001
010
011
100
101
110
111
(illegal)
(illegal)
(illegal)
(illegal)
(illegal)
(illegal)
(illegal)
(illegal)

Replacement when the base speciﬁer is
'X'
0000
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010
1011
1100
1101
1110
1111

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

The length of a bit string literal is the length of its string literal value.
Example:

285

B"1111_1111_1111"
X"FFF"
O"777"
X"777"

-----

Equivalent to the string literal "111111111111".
Equivalent to B"1111_1111_1111".
Equivalent to B"111_111_111".
Equivalent to B"0111_0111_0111".

constant c1: STRING := B"1111_1111_1111";
constant c2: BIT_VECTOR := X"FFF";
290

type MVL is ('X', '0', '1', 'Z');
type MVL_VECTOR is array (NATURAL range <>) of MVL;
constant c3: MVL_VECTOR := O"777";
assert

295

c1'LENGTH = 12 and
c2'LENGTH = 12 and
c3 = "111111111";

13.8 Comments
A comment starts with two adjacent hyphens and extends up to the end of the line. A comment can appear on
any line of a VHDL description. The presence or absence of comments has no inﬂuence on whether a
description is legal or illegal. Furthermore, comments do not inﬂuence the execution of a simulation module;
their sole purpose is to enlighten the human reader.
300

Examples:
-- The last sentence above echoes the Algol 68 report.
end;

-- Processing of LINE is complete.

-- A long comment may be split onto
-- two or more consecutive lines.
305

----------- The ﬁrst two hyphens start the comment.
NOTE—Horizontal tabulation can be used in comments, after the double hyphen, and is equivalent to one or more
spaces (SPACE characters) (see 13.2).

Copyright © 2000 IEEE. All rights reserved.

183

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

13.9 Reserved words
The identiﬁers listed below are called reserved words and are reserved for signiﬁcance in the language. For
readability of this standard, the reserved words appear in lowercase boldface.
310

abs
access
after
alias
all
and
architecture
array
assert
attribute

315

320

begin
block
body
buffer
bus

325

330

340

generate
generic
group
guarded
if
impure
in
inertial
inout
is

case
component
conﬁguration
constant

label
library
linkage
literal
loop

disconnect
downto

map
mod

else
elsif
end
entity
exit

335

ﬁle
for
function

nand
new
next
nor
not
null

select
severity
signal
shared
sla
sll
sra
srl
subtype

of
on
open
or
others
out

then
to
transport
type

package
port
postponed
procedural
procedure
process
protected
pure
range
record
reference
register
reject
rem
report
return
rol
ror

unaffected
units
until
use
variable
wait
when
while
with
xnor
xor

A reserved word must not be used as an explicitly declared identiﬁer.
NOTES
345

1—Reserved words differing only in the use of corresponding uppercase and lowercase letters are considered as the
same (see 13.3.1). The reserved word range is also used as the name of a predeﬁned attribute.
2—An extended identiﬁer whose sequence of characters inside the leading and trailing backslashes is identical to a
reserved word is not a reserved word. For example, \next\ is a legal (extended) identiﬁer and is not the reserved word
next.

184

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

13.10 Allowable replacements of characters
350

355

The following replacements are allowed for the vertical line, number sign, and quotation mark basic
characters:
—

A vertical line (|) can be replaced by an exclamation mark (!) where used as a delimiter.

—

The number sign (#) of a based literal can be replaced by colons (:), provided that the replacement is
done for both occurrences.

—

The quotation marks (") used as string brackets at both ends of a string literal can be replaced by
percent signs (%), provided that the enclosed sequence of characters contains no quotation marks,
and provided that both string brackets are replaced. Any percent sign within the sequence of characters must then be doubled, and each such doubled percent sign is interpreted as a single percent sign
value. The same replacement is allowed for a bit string literal, provided that both bit string brackets
are replaced.

360

These replacements do not change the meaning of the description.
NOTES

365

1—It is recommended that use of the replacements for the vertical line, number sign, and quotation marks be restricted
to cases where the corresponding graphical symbols are not available. Note that the vertical line appears as a broken line
on some equipment; replacement is not recommended in this case.
2—The rules given for identiﬁers and abstract literals are such that lowercase and uppercase letters can be used indifferently; these lexical elements can thus be written using only characters of the basic character set.

Copyright © 2000 IEEE. All rights reserved.

185

IEEE
Std 1076, 2000 Edition

186

IEEE STANDARD VHDL

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

14. Predeﬁned language environment
This clause describes the predeﬁned attributes of VHDL and the packages that all VHDL implementations
must provide.

14.1 Predeﬁned attributes
Predeﬁned attributes denote values, functions, types, and ranges associated with various kinds of named
entities. These attributes are described below. For each attribute, the following information is provided:
5

—
—
—
—
—

10

T'BASE

15

20

25

30

The kind of attribute: value, type, range, function, or signal
The preﬁxes for which the attribute is deﬁned
A description of the parameters or argument, if one exists
The result of evaluating the attribute, and the result type (if applicable)
Any further restrictions or comments that apply.

Kind:
Preﬁx:
Result:
Restrictions:

Type.
Any type or subtype T.
The base type of T.
This attribute is allowed only as the preﬁx of the name of
another attribute; for example, T'BASE'LEFT.

Kind:
Preﬁx:
Result Type:
Result:

Value.
Any scalar type or subtype T.
Same type as T.
The left bound of T.

Kind:
Preﬁx:
Result Type:
Result:

Value.
Any scalar type or subtype T.
Same type as T.
The right bound of T.

Kind:
Preﬁx:
Result Type:
Result:

Value.
Any scalar type or subtype T.
Same type as T.
The upper bound of T.

Kind:
Preﬁx:
Result Type:
Result:

Value.
Any scalar type or subtype T.
Same type as T.
The lower bound of T.

T'LEFT

T'RIGHT

T'HIGH

T'LOW

Copyright © 2000 IEEE. All rights reserved.

187

IEEE
Std 1076, 2000 Edition

35

T'ASCENDING
Kind:
Preﬁx:
Result Type:
Result:

40

45

T'IMAGE(X)
Kind:
Preﬁx:
Parameter:
Result Type:
Result:

50

55

60

65

70

Restrictions:
75

188

IEEE STANDARD VHDL

Value.
Any scalar type or subtype T.
Type Boolean
It is TRUE if T is deﬁned with an ascending range; FALSE
otherwise.

Function.
Any scalar type or subtype T.
An expression whose type is the base type of T.
Type String.
The string representation of the parameter value, without
leading or trailing whitespace. If T is an enumeration type or
subtype and the parameter value is either an extended identiﬁer
or a character literal, the result is expressed with both a leading
and trailing reverse solidus (backslash) (in the case of an
extended identiﬁer) or apostrophe (in the case of a character
literal); in the case of an extended identiﬁer that has a backslash, the backslash is doubled in the string representation. If T
is an enumeration type or subtype and the parameter value is a
basic identiﬁer, then the result is expressed in lowercase characters. If T is a numeric type or subtype, the result is expressed
as the decimal representation of the parameter value without
underlines or leading or trailing zeros (except as necessary to
form the image of a legal literal with the proper value); moreover, an exponent may (but is not required to) be present and
the language does not deﬁne under what conditions it is or is
not present. If the exponent is present, the “e” is expressed as a
lowercase character. If T is a physical type or subtype, the
result is expressed in terms of the primary unit of T unless the
base type of T is TIME, in which case the result is expressed in
terms of the resolution limit (see 3.1.3.1); in either case, if the
unit is a basic identiﬁer, the image of the unit is expressed in
lowercase characters. If T is a ﬂoating point type or subtype,
the number of digits to the right of the decimal point corresponds to the standard form generated when the DIGITS
parameter to TextIO. Write for type REAL is set to 0 (see
14.3). The result never contains the replacement characters
described in 13.10.
It is an error if the parameter value does not belong to the subtype implied by the preﬁx.

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

80

T'VALUE(X)
Kind:
Preﬁx:
Parameter:
Result Type:
Result:

85

90

Restrictions:

IEEE
Std 1076, 2000 Edition

Function.
Any scalar type or subtype T.
An expression of type String.
The base type of T.
The value of T whose string representation (as deﬁned in
Clause 13) is given by the parameter. Leading and trailing
whitespace is allowed and ignored. If T is a numeric type or
subtype, the parameter may be expressed either as a decimal
literal or as a based literal. If T is a physical type or subtype,
the parameter may be expressed using a string representation of
any of the unit names of T, with or without a leading abstract
literal. The parameter must have whitespace between any
abstract literal and the unit name. The replacement characters
of 13.10 are allowed in the parameter.
It is an error if the parameter is not a valid string representation
of a literal of type T or if the result does not belong to the subtype implied by T.

T'POS(X)
95

100

105

Kind:
Preﬁx:
Parameter:
Result Type:
Result:

Function.
Any discrete or physical type or subtype T.
An expression whose type is the base type of T.
universal_integer.
The position number of the value of the parameter.

Kind:
Preﬁx:
Parameter:
Result Type:
Result:

Function.
Any discrete or physical type or subtype T.
An expression of any integer type.
The base type of T.
The value whose position number is the universal_integer
value corresponding to X.
It is an error if the result does not belong to the range T'LOW
to T'HIGH.

T'VAL(X)

Restrictions:

110

T'SUCC(X)
Kind:
Preﬁx:
Parameter:
Result Type:
Result:

115

Restrictions:

Copyright © 2000 IEEE. All rights reserved.

Function.
Any discrete or physical type or subtype T.
An expression whose type is the base type of T.
The base type of T.
The value whose position number is one greater than that of the
parameter.
An error occurs if X equals T'HIGH or if X does not belong to
the range T'LOW to T'HIGH.

189

IEEE
Std 1076, 2000 Edition

120

T'PRED(X)
Kind:
Preﬁx:
Parameter:
Result Type:
Result:

125

Restrictions:

130

T'LEFTOF(X)
Kind:
Preﬁx:
Parameter:
Result Type:
Result:
Restrictions:

135

140

145

T'RIGHTOF(X)
Kind:
Preﬁx:
Parameter:
Result Type:
Result:
Restrictions:

A'LEFT [(N)]
Kind:
Preﬁx:
Parameter:

Result Type:
Result:

150

155

A'RIGHT [(N)]
Kind:
Preﬁx:
Parameter:

160

Result Type:
Result:

190

IEEE STANDARD VHDL

Function.
Any discrete or physical type or subtype T.
An expression whose type is the base type of T.
The base type of T.
The value whose position number is one less than that of the
parameter.
An error occurs if X equals T'LOW or if X does not belong to
the range T'LOW to T'HIGH.

Function.
Any discrete or physical type or subtype T.
An expression whose type is the base type of T.
The base type of T.
The value that is to the left of the parameter in the range of T.
An error occurs if X equals T'LEFT or if X does not belong to
the range T'LOW to T'HIGH.

Function.
Any discrete or physical type or subtype T.
An expression whose type is the base type of T.
The base type of T.
The value that is to the right of the parameter in the range of T.
An error occurs if X equals T'RIGHT or if X does not belong to
the range T'LOW to T'HIGH.

Function.
Any preﬁx A that is appropriate for an array object, or an alias
thereof, or that denotes a constrained array subtype.
A locally static expression of type universal_integer, the value
of which must not exceed the dimensionality of A. If omitted, it
defaults to 1.
Type of the left bound of the Nth index range of A.
Left bound of the Nth index range of A. (If A is an alias for an
array object, then the result is the left bound of the Nth index
range from the declaration of A, not that of the object.)

Function.
Any preﬁx A that is appropriate for an array object, or an alias
thereof, or that denotes a constrained array subtype.
A locally static expression of type universal_integer, the value
of which must not exceed the dimensionality of A. If omitted, it
defaults to 1.
Type of the Nth index range of A.
Right bound of the Nth index range of A. (If A is an alias for an
array object, then the result is the right bound of the Nth index
range from the declaration of A, not that of the object.)

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

165

A'HIGH [(N)]
Kind:
Preﬁx:
Parameter:

170

Result Type:
Result:
175

A'LOW [(N)]
Kind:
Preﬁx:
180

Parameter:

Result Type:
Result:
185

A'RANGE [(N)]
Kind:
Preﬁx:
190

Parameter:

195

Result Type:
Result:

200

A'REVERSE_RANGE [(N)]
Kind:
Preﬁx:
205

Parameter:

Result Type:
Result:
210

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

Function.
Any preﬁx A that is appropriate for an array object, or an alias
thereof, or that denotes a constrained array subtype.
A locally static expression of type universal_integer, the value
of which must not exceed the dimensionality of A. If omitted, it
defaults to 1.
Type of the Nth index range of A.
Upper bound of the Nth index range of A. (If A is an alias for
an array object, then the result is the upper bound of the Nth
index range from the declaration of A, not that of the object.)

Function.
Any preﬁx A that is appropriate for an array object, or an alias
thereof, or that denotes a constrained array subtype.
A locally static expression of type universal_integer, the value
of which must not exceed the dimensionality of A. If omitted, it
defaults to 1.
Type of the Nth index range of A.
Lower bound of the Nth index range of A. (If A is an alias for
an array object, then the result is the lower bound of the Nth
index range from the declaration of A, not that of the object.)

Range.
Any preﬁx A that is appropriate for an array object, or an alias
thereof, or that denotes a constrained array subtype.
A locally static expression of type universal_integer, the value
of which must not exceed the dimensionality of A. If omitted, it
defaults to 1.
The type of the Nth index range of A.
The range A'LEFT(N) to A'RIGHT(N) if the Nth index range
of A is ascending, or the range A'LEFT(N) downto
A'RIGHT(N) if the Nth index range of A is descending. (If A is
an alias for an array object, then the result is determined by the
Nth index range from the declaration of A, not that of the
object.)

Range.
Any preﬁx A that is appropriate for an array object, or an alias
thereof, or that denotes a constrained array subtype.
A locally static expression of type universal_integer, the value
of which must not exceed the dimensionality of A. If omitted, it
defaults to 1.
The type of the Nth index range of A.
The range A'RIGHT(N) downto A'LEFT(N) if the Nth index
range of A is ascending, or the range A'RIGHT(N) to
A'LEFT(N) if the Nth index range of A is descending. (If A is
an alias for an array object, then the result is determined by the
Nth index range from the declaration of A, not that of the
object.)

191

IEEE
Std 1076, 2000 Edition

215

A'LENGTH [(N)]
Kind:
Preﬁx:
Parameter:

220

Result Type:
Result:
225

A'ASCENDING [(N)]
Kind:
Preﬁx:
230

Parameter:

Result Type:
Result:

235

240

S'DELAYED [(T)]
Kind:
Preﬁx:
Parameter:
Result Type:
Result:

IEEE STANDARD VHDL

Value.
Any preﬁx A that is appropriate for an array object, or an alias
thereof, or that denotes a constrained array subtype.
A locally static expression of type universal_integer, the value
of which must not exceed the dimensionality of A. If omitted, it
defaults to 1.
universal_integer.
Number of values in the Nth index range; i.e., if the Nth index
range of A is a null range, then the result is 0. Otherwise, the
result is the value of T'POS(A'HIGH(N)) – T'POS(A'LOW(N))
+ 1, where T is the subtype of the Nth index of A.

Value.
Any preﬁx A that is appropriate for an array object, or an alias
thereof, or that denotes a constrained array subtype.
A locally static expression of type universal integer, the value
of which must be greater than zero and must not exceed the
dimensionality of A. If omitted, it defaults to 1.
Type Boolean.
TRUE if the Nth index range of A is deﬁned with an ascending
range; FALSE otherwise.

Signal.
Any signal denoted by the static signal name S.
A static expression of type TIME that evaluates to a nonnegative value. If omitted, it defaults to 0 ns.
The base type of S.
A signal equivalent to signal S delayed T units of time.

Let R be of the same subtype as S, let T >= 0 ns, and let P be a process statement of the form
245

P: process (S)
begin
R <= transport S after T;
end process ;
Assuming that the initial value of R is the same as the initial value of S, then the attribute
'DELAYED is deﬁned such that S'DELAYED(T) = R for any T.

250

S'STABLE [(T)]
Kind:
Preﬁx:
Parameter:
255

Result Type:
Result:

192

Signal.
Any signal denoted by the static signal name S.
A static expression of type TIME that evaluates to a nonnegative value. If omitted, it defaults to 0 ns.
Type Boolean.
A signal that has the value TRUE when an event has not
occurred on signal S for T units of time, and the value FALSE
otherwise (see 12.6.2).

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

260

S'QUIET [(T)]
Kind:
Preﬁx:
Parameter:
Result Type:
Result:

265

270

S'TRANSACTION
Kind:
Preﬁx:
Result Type:
Result:

275

Restriction:

IEEE
Std 1076, 2000 Edition

Signal.
Any signal denoted by the static signal name S.
A static expression of type TIME that evaluates to a nonnegative value. If omitted, it defaults to 0 ns.
Type Boolean.
A signal that has the value TRUE when the signal has been
quiet for T units of time, and the value FALSE otherwise (see
12.6.2).

Signal.
Any signal denoted by the static signal name S.
Type Bit.
A signal whose value toggles to the inverse of its previous
value in each simulation cycle in which signal S becomes
active.
A description is erroneous if it depends on the initial value of
S'Transaction.

S'EVENT
Kind:
Preﬁx:
Result Type:
Result:

280

285

Function.
Any signal denoted by the static signal name S.
Type Boolean.
A value that indicates whether an event has just occurred on
signal S. Speciﬁcally:

For a scalar signal S, S'EVENT returns the value TRUE if an event has occurred on S during
the current simulation cycle; otherwise, it returns the value FALSE.
For a composite signal S, S'EVENT returns TRUE if an event has occurred on any scalar
subelement of S during the current simulation cycle; otherwise, it returns FALSE.
S'ACTIVE

290

295

300

305

Kind:
Preﬁx:
Result Type:
Result:

Function.
Any signal denoted by the static signal name S.
Type Boolean.
A value that indicates whether signal S is active. Speciﬁcally:

For a scalar signal S, S'ACTIVE returns the value TRUE if signal S is active during the current
simulation cycle; otherwise, it returns the value FALSE.
For a composite signal S, S'ACTIVE returns TRUE if any scalar subelement of S is active
during the current simulation cycle; otherwise, it returns FALSE.
S'LAST_EVENT
Kind:
Preﬁx:
Result Type:
Result:

Function.
Any signal denoted by the static signal name S.
Type Time.
The amount of time that has elapsed since the last event
occurred on signal S. Speciﬁcally:

For a signal S, S'LAST_EVENT returns the smallest value T of type TIME such that S'EVENT
= True during any simulation cycle at time NOW – T, if such a value exists; otherwise, it
returns TIME'HIGH.

Copyright © 2000 IEEE. All rights reserved.

193

IEEE
Std 1076, 2000 Edition

S'LAST_ACTIVE
Kind:
Preﬁx:
Result Type:
Result:
310

IEEE STANDARD VHDL

Function.
Any signal denoted by the static signal name S.
Type Time.
The amount of time that has elapsed since the last time at
which signal S was active. Speciﬁcally:

For a signal S, S'LAST_ACTIVE returns the smallest value T of type TIME such that
S'ACTIVE = True during any simulation cycle at time NOW – T, if such value exists; otherwise, it returns TIME'HIGH.

315

320

S'LAST_VALUE
Kind:
Preﬁx:
Result Type:
Result:

S'DRIVING
Kind:
Preﬁx:
Result Type:
Result:

325

330

Restrictions:

335

340

194

Function.
Any signal denoted by the static signal name S.
The base type of S.
The previous value of S, immediately before the last change of
S.

Function.
Any signal denoted by the static signal name S.
Type Boolean.
If the preﬁx denotes a scalar signal, the result is False if the
current value of the driver for S in the current process is determined by the null transaction; True otherwise. If the preﬁx
denotes a composite signal, the result is True if and only if
R'DRIVING is True for every scalar subelement R of S; False
otherwise. If the preﬁx denotes a null slice of a signal, the
result is True.
This attribute is available only from within a process, a concurrent statement with an equivalent process, or a subprogram. If
the preﬁx denotes a port, it is an error if the port does not have
a mode of inout, out, or buffer. It is also an error if the
attribute name appears in a subprogram body that is not a
declarative item contained within a process statement and the
preﬁx is not a formal parameter of the given subprogram or of a
parent of that subprogram. Finally, it is an error if the preﬁx
denotes a subprogram formal parameter whose mode is not
inout or out.

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

345

S'DRIVING_VALUE
Kind:
Preﬁx:
Result Type:
Result:

350

Restrictions:

Function.
Any signal denoted by the static signal name S.
The base type of S.
If S is a scalar signal S, the result is the current value of the
driver for S in the current process. If S is a composite signal,
the result is the aggregate of the values of
R'DRIVING_VALUE for each element R of S. If S is a null
slice, the result is a null slice.
This attribute is available only from within a process, a concurrent statement with an equivalent process, or a subprogram. If
the preﬁx denotes a port, it is an error if the port does not have
a mode of inout, out, or buffer. It is also an error if the
attribute name appears in a subprogram body that is not a
declarative item contained within a process statement and the
preﬁx is not a formal parameter of the given subprogram or of a
parent of that subprogram. Finally, it is an error if the preﬁx
denotes a subprogram formal parameter whose mode is not
inout or out, or if S'DRIVING is False at the time of the evaluation of S'DRIVING_VALUE.

355

360

365

E'SIMPLE_NAME
Kind:
Preﬁx:
Result Type:
Result:

Value.
Any named entity as deﬁned in 5.1.
Type String.
The simple name, character literal, or operator symbol of the
named entity, without leading or trailing whitespace or quotation marks but with apostrophes (in the case of a character
literal) and both a leading and trailing reverse solidus (backslash) (in the case of an extended identiﬁer). In the case of a
simple name or operator symbol, the characters are converted
to their lowercase equivalents. In the case of an extended identiﬁer, the case of the identiﬁer is preserved, and any reverse
solidus characters appearing as part of the identiﬁer are represented with two consecutive reverse solidus characters.

370

375

380

E'INSTANCE_NAME
Kind:
Preﬁx:

Value.
Any named entity other than the local ports and generics of a
component declaration.
Type String.
A string describing the hierarchical path starting at the root of
the design hierarchy and descending to the named entity,
including the names of instantiated design entities.
Speciﬁcally:

Result Type:
Result:

The result string has the following syntax:
385

instance_name ::= package_based_path | full_instance_based_path
package_based_path ::=
leader library_logical_name leader package_simple_name leader
[ local_item_name ]

Copyright © 2000 IEEE. All rights reserved.

195

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

full_instance_based_path ::= leader full_path_to_instance [ local_item_name ]
full_path_to_instance ::= { full_path_instance_element leader }

390

local_item_name ::=
simple_name
character_literal
operator_symbol
full_path_instance_element ::=
[ component_instantiation_label @ ]
entity_simple_name ( architecture_simple_name )
| block_label
| generate_label
| process_label
| loop_label
| subprogram_simple_name
generate_label ::= generate_label [ ( literal ) ]

395

400

process_label ::= [ process_label ]
leader ::= :

405

Package-based paths identify items declared within packages. Full-instance-based paths identify items within an elaborated design hierarchy.
A library logical name denotes a library (see 11.2). Since multiple logical names may denote
the same library, the library logical name may not be unique.
There is one full path instance element for each component instantiation, block statement,
generate statement, process statement, or subprogram body in the design hierarchy between the
root design entity and the named entity denoted by the preﬁx.

410

In a full path instance element, the architecture simple name must denote an architecture
associated with the entity interface designated by the entity simple name; furthermore, the
component instantiation label (and the commercial at following it) are required unless the
entity simple name and the architecture simple name together denote the root design entity.

415

The literal in a generate label is required if the label denotes a generate statement with a for
generation scheme; the literal must denote one of the values of the generate parameter.
A process statement with no label is denoted by an empty process label.
All characters in basic identiﬁers appearing in the result are converted to their lowercase equivalents. Both a leading and trailing reverse solidus surround an extended identiﬁer appearing in
the result; any reverse solidus characters appearing as part of the identiﬁer are represented with
two consecutive reverse solidus characters.

420

196

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

425

E'PATH_NAME
Kind:
Preﬁx:

Value.
Any named entity other than the local ports and generics of a
component declaration.
Type String.
A string describing the hierarchical path starting at the root of
the design hierarchy and descending to the named entity,
excluding the name of instantiated design entities. Speciﬁcally:

Result Type:
Result:
430

The result string has the following syntax:
path_name ::= package_based_path | instance_based_path
instance_based_path ::=
leader path_to_instance [ local_item_name ]

435

path_to_instance ::= { path_instance_element leader }
path_instance_element ::=
component_instantiation_label
| entity_simple_name
| block_label
| generate_label
| process_label
| subprogram_simple_name

440

Package-based paths identify items declared within packages. Instance-based paths identify
items within an elaborated design hierarchy.

445

There is one path instance element for each component instantiation, block statement, generate
statement, process statement, or subprogram body in the design hierarchy between the root
design entity and the named entity denoted by the preﬁx.
Examples:
450

library Lib:
package P is
procedure Proc (F: inout INTEGER);

455

460

465

constant C: INTEGER := 42;
end package P;
package body P is
procedure Proc (F: inout INTEGER) is
variable x: INTEGER;
begin
•
•
•
end;
end;

Copyright © 2000 IEEE. All rights reserved.

--------

All design units are in this library:
P'PATH_NAME = ":lib:p:"
P'INSTANCE_NAME = ":lib:p:"
Proc'PATH_NAME = ":lib:p:proc"
Proc'INSTANCE_NAME = ":lib:p:proc"
C'PATH_NAME = ":lib:p:c"
C'INSTANCE_NAME = ":lib:p:c"

-- x'PATH_NAME = ":lib:p:proc:x"
-- x'INSTANCE_NAME = ":lib:p:proc:x"

197

IEEE
Std 1076, 2000 Edition

library Lib;
use Lib.P.all;
entity E is
470

generic (G: INTEGER);
port (P: in INTEGER);
end entity E;
475

IEEE STANDARD VHDL

---------

Assume that E is in Lib and
E is the top-level design entity:
E'PATH_NAME = ":e:"
E'INSTANCE_NAME = ":e(a):"
G'PATH_NAME = ":e:g"
G'INSTANCE_NAME = ":e(a):g"
P'PATH_NAME = ":e:p"
P'INSTANCE_NAME = ":e(a):p"

architecture A of E is
signal S: BIT_VECTOR (1 to G);

485

-- S'PATH_NAME = ":e:s"
-- S'INSTANCE_NAME = ":e(a):s"
procedure Proc1 (signal sp1: NATURAL; C: out INTEGER) is
-- Proc1'PATH_NAME = ":e:proc1:"
-- Proc1'INSTANCE_NAME =:e(a):proc1:"
-- C'PATH_NAME = ":e:proc1:c"
-- C'INSTANCE_NAME = ":e(a):proc1:c"
variable max: DELAY_LENGTH;
-- max'PATH_NAME = ":e:proc1:max"
-- max'INSTANCE_NAME =
-":e(a):proc1:max"

490

begin
max := sp1 * ns;
wait on sp1 for max;
c := sp1;
end procedure Proc1;

480

495

500

505

begin
p1: process
variable T: INTEGER := 12;
begin
•
•
•
end process p1;
process
variable T: INTEGER := 12;
begin
•
•
•
end process ;
end architecture;

198

-- T'PATH_NAME = ":e:p1:t"
-- T'INSTANCE_NAME = ":e(a):p1:t"

-- T'PATH_NAME = ":e::t"
-- T'INSTANCE_NAME = ":e(a)::t"

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

510

515

520

525

530

535

IEEE
Std 1076, 2000 Edition

entity Bottom is
generic(GBottom : INTEGER);
port
(PBottom : INTEGER);
end entity Bottom;
architecture BottomArch of Bottom is
signal SBottom : INTEGER;
begin
ProcessBottom : process
variable V : INTEGER;
begin
if GBottom = 4 then
assert V'Simple_Name = "v"
and V'Path_Name = ":top:b1:b2:g1(4):b3:l1:processbottom:v"
and V'Instance_Name =
":top(top):b1:b2:g1(4):b3:l1@bottom(bottomarch):processbottom:v";
assert GBottom'Simple_Name = "bottom"
and GBottom'Path_Name = ":top:b1:b2:g1(4):b3:l1:gbottom"
and GBottom'Instance_Name =
":top(top):b1:b2:g1(4):b3:l1@bottom(bottomarch):gbottom";
elsif GBottom = -1 then
assert V'Simple_Name = "v"
and V'Path_Name = ":top:l2:processbottom:v"
and V'Instance_Name =
":top(top):l2@bottom(bottomarch):processbottom:v";
assert GBottom'Simple_Name = "gbottom"
and GBottom'Path_Name = "top:l2:gbottom"
and GBottom'Instance_Name =
":top(top):l2@bottom(bottomarch):gbottom";
end if;
wait;
end process ProcessBottom;
end architecture BottomArch;
entity Top is end Top;

540

architecture Top of Top is
component BComp is
generic
(GComp : INTEGER)
port
(PComp : INTEGER);
end component BComp;
signal S : INTEGER;

545

begin
B1 : block
signal S : INTEGER;

Copyright © 2000 IEEE. All rights reserved.

199

IEEE
Std 1076, 2000 Edition

begin
B2 : block
signal S : INTEGER;
begin
G1 : for I in 1 to 10 generate
B3 : block
signal S : INTEGER;
for L1 : BComp use entity Work.Bottom(BottomArch)
generic map
(GBottom => GComp)
port map
(PBottom => PComp);
begin

550

555

560

565

570

575

580

585

590

IEEE STANDARD VHDL

L1 : BComp generic map (I) port map (S);
P1 : process
variable V : INTEGER;
begin
if I = 7 then
assert V'Simple_Name = "v"
and V'Path_Name = ":top:b1:b2:g1(7):b3:p1:v"
andV'Instance_Name=":top(top):b1:b2:g1(7):b3:p1:v";
assert P1'Simple_Name = "p1"
and P1'Path_Name = ":top:b1:b2:g1(7):b3:p1:"
and P1'Instance_Name = ":top(top):b1:b2:g1(7):b3:p1:";
assert S'Simple_Name = "s"
and S'Path_Name = ":top:b1:b2:g1(7):b3:s"
and S'Instance_Name = ":top(top):b1:b2:g1(7):b3:s";
assert B1.S'Simple_Name = "s"
and B1.S'Path_Name = ":top:b1:s"
and B1.S'Instance_Name = ":top(top):b1:s";
end if;
wait;
end process P1;
end block B3;
end generate;
end block B2;
end block B1;
L2 : BComp generic map (-1) port map (S);
end architecture Top;
conﬁguration TopConf of Top is
for Top
for L2 : BComp use
entity Work.Bottom(BottomArch)
generic map
(GBottom => GComp)
port map
(PBottom => PComp);
end for;
end for;
end conﬁguration TopConf;

200

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

595

NOTES
1—The relationship between the values of the LEFT, RIGHT, LOW, and HIGH attributes is expressed as follows:

T'LEFT
T'RIGHT

=
=

Ascending range
T'LOW
T'HIGH

Descending range
T'HIGH
T'LOW

600

2—Since the attributes S'EVENT, S'ACTIVE, S'LAST_EVENT, S'LAST_ACTIVE, and S'LAST_VALUE are functions, not signals, they cannot cause the execution of a process, even though the value returned by such a function may
change dynamically. It is thus recommended that the equivalent signal-valued attributes S'STABLE and S'QUIET, or
expressions involving those attributes, be used in concurrent contexts such as guard expressions or concurrent signal
assignments. Similarly, function STANDARD.NOW should not be used in concurrent contexts.

605

3—S'DELAYED(0 ns) is not equal to S during any simulation cycle where S'EVENT is true.
4—S'STABLE(0 ns) = (S'DELAYED(0 ns) = S), and S'STABLE(0 ns) is FALSE only during a simulation cycle in which
S has had a transaction.
5—For a given simulation cycle, S'QUIET(0 ns) is TRUE if and only if S is quiet for that simulation cycle.
6—If S'STABLE(T) is FALSE, then, by deﬁnition, for some t where 0 ns < t < T, S'DELAYED(t) /= S.

610

7—If Ts is the smallest value such that S'STABLE (Ts) is FALSE, then for all t where 0 ns < t < Ts, S'DELAYED(t) = S.
8—S'EVENT should not be used within a postponed process (or a concurrent statement that has an equivalent postponed
process) to determine if the preﬁx signal S caused the process to resume. However, S'LAST_EVENT = 0 ns can be used
for this purpose.

615

9—The values of E'PATH_NAME and E'INSTANCE_NAME are not unique. Speciﬁcally, named entities in two different, unlabelled processes may have the same path names or instance names. Overloaded subprograms, and named
entities within them, may also have the same path names or instance names.
10—If the preﬁx to the attributes 'SIMPLE_NAME, 'PATH_NAME, or 'INSTANCE_NAME denotes an alias, the result
is respectively the simple name, path name or instance name of the alias. See 6.6.
11—For all values V of any scalar type T except a real type, the following relation holds:

620

V = T'Value(T'Image(V))

14.2 Package STANDARD
Package STANDARD predeﬁnes a number of types, subtypes, and functions. An implicit context clause
naming this package is assumed to exist at the beginning of each design unit. Package STANDARD may not
be modiﬁed by the user.

625

The operators that are predeﬁned for the types declared for package STANDARD are given in comments
since they are implicitly declared. Italics are used for pseudo-names of anonymous types (such as
universal_integer), formal parameters, and undeﬁned information (such as implementation_deﬁned).
package STANDARD is
-- Predeﬁned enumeration types:
type BOOLEAN is (FALSE, TRUE);

Copyright © 2000 IEEE. All rights reserved.

201

IEEE
Std 1076, 2000 Edition

630

IEEE STANDARD VHDL

-- The predeﬁned operators for this type are as follows:
-------

635

640

function "and"
function "or"
function "nand"
function "nor"
function "xor"
function "xnor"

(anonymous, anonymous: BOOLEAN) return BOOLEAN;
(anonymous, anonymous: BOOLEAN) return BOOLEAN;
(anonymous, anonymous: BOOLEAN) return BOOLEAN;
(anonymous, anonymous: BOOLEAN) return BOOLEAN;
(anonymous, anonymous: BOOLEAN) return BOOLEAN;
(anonymous, anonymous: BOOLEAN) return BOOLEAN;

-- function "not"

(anonymous: BOOLEAN) return BOOLEAN;

-------

(anonymous, anonymous: BOOLEAN) return BOOLEAN;
(anonymous, anonymous: BOOLEAN) return BOOLEAN;
(anonymous, anonymous: BOOLEAN) return BOOLEAN;
(anonymous, anonymous: BOOLEAN) return BOOLEAN;
(anonymous, anonymous: BOOLEAN) return BOOLEAN;
(anonymous, anonymous: BOOLEAN) return BOOLEAN;

function "="
function "/="
function "<"
function "<="
function ">"
function ">="

type BIT is ('0', '1');
-- The predeﬁned operators for this type are as follows:

645

-------

650

655

function "and"
function "or"
function "nand"
function "nor"
function "xor"
function "xnor"

(anonymous, anonymous: BIT) return BIT;
(anonymous, anonymous: BIT) return BIT;
(anonymous, anonymous: BIT) return BIT;
(anonymous, anonymous: BIT) return BIT;
(anonymous, anonymous: BIT) return BIT;
(anonymous, anonymous: BIT) return BIT;

-- function "not"

(anonymous: BIT) return BIT;

-------

(anonymous, anonymous: BIT) return BOOLEAN;
(anonymous, anonymous: BIT) return BOOLEAN;
(anonymous, anonymous: BIT) return BOOLEAN;
(anonymous, anonymous: BIT) return BOOLEAN;
(anonymous, anonymous: BIT) return BOOLEAN;
(anonymous, anonymous: BIT) return BOOLEAN;

function "="
function "/="
function "<"
function "<="
function ">"
function ">="

type CHARACTER is (
660

665

670

675

202

NUL,
BS,
DLE,
CAN,

SOH,
HT,
DC1,
EM,

STX,
LF,
DC2,
SUB,

ETX,
VT,
DC3,
ESC,

EOT,
FF,
DC4,
FSP,

ENQ,
CR,
NAK,
GSP,

ACK,
SO,
SYN,
RSP,

BEL,
SI,
ETB,
USP,

' ',
'(',
'0',
'8',

'!',
')',
'1',
'9',

'"',
'*',
'2',
':',

'#',
'+',
'3',
';',

'$',
',',
'4',
'<',

'%',
'-',
'5',
'=',

'&',
'.',
'6',
'>',

''',
'/',
'7',
'?',

'@',
'H',
'P',
'X',

'A',
'I',
'Q',
'Y',

'B',
'J',
'R',
'Z',

'C',
'K',
'S',
'[',

'D',
'L',
'T',
' \ ',

'E',
'M',
'U',
']',

'F',
'N',
'V',
'^',

'G',
'O',
'W',
'_',

'`',
'h',
'p',
'x',

'a',
'i',
'q',
'y',

'b',
'j',
'r',
'z',

'c',
'k',
's',
'{',

'd',
'l',
't',
'|',

'e',
'm',
'u',
'}',

'f',
'n',
'v',
'~',

'g',
'o',
'w',
DEL,

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

680

685

690

C128,
C136,
C144,
C152,

C129,
C137,
C145,
C153,

C130,
C138,
C146,
C154,

C131,
C139,
C147,
C155,

C132,
C140,
C148,
C156,

C133,
C141,
C149,
C157,

C134,
C142,
C150,
C158,

' ', 4
'¨',
'°',
'¸',

'¡',
'©',
'±',
'1',

'¢',
'ª',
'2',
'º',

'£',
'«',
'3',
'»',

'€',
'¬',
'´',
'1/4',

'¥',
'-', 5
'µ',
'1/2',

' | ',
'®',
'¶',
'3/4',

'§',
'¯',
'•',
'¿',

'À',
'È',
. ',
'D

'Á',
'É',

'Â',
'Ê',

'Ã',
'Ë',

'Ä',
'Ì',

'Å',
'Í',

'Æ',
'Î',

'Ç',
'Ï',

'Ø',

'Ñ',
'Ù',

'Ò',
'Ú',

'Ó',
'Û',

'Ô',
'Ü',

'Õ',
'Ý',

'Ö',
'P' ',

'◊',
'ß',

'à',
'è',
'∂',
'ø',

'á',
'é',
'ñ',
'ù',

'â',
'ê',
'ò',
'ú',

'ã',
'ë',
'ó',
'û',

'ä',
'ì',
'ô',
'ü',

'å',
'í',
'õ',
'ý',

'æ',
'î',
'ö',
'
'p',

'ç',
'ï',
'÷',
'ÿ');

|

C135,
C143,
C151,
C159,

-- The predeﬁned operators for this type are as follows:
-------

695

function "="
function "/="
function "<"
function "<="
function ">"
function ">="

(anonymous, anonymous: CHARACTER) return BOOLEAN;
(anonymous, anonymous: CHARACTER) return BOOLEAN;
(anonymous, anonymous: CHARACTER) return BOOLEAN;
(anonymous, anonymous: CHARACTER) return BOOLEAN;
(anonymous, anonymous: CHARACTER) return BOOLEAN;
(anonymous, anonymous: CHARACTER) return BOOLEAN;

type SEVERITY_LEVEL is (NOTE, WARNING, ERROR, FAILURE);
-- The predeﬁned operators for this type are as follows:

700

-------

705

function "="
function "/="
function "<"
function "<="
function ">"
function ">="

(anonymous, anonymous: SEVERITY_LEVEL) return BOOLEAN;
(anonymous, anonymous: SEVERITY_LEVEL) return BOOLEAN;
(anonymous, anonymous: SEVERITY_LEVEL) return BOOLEAN;
(anonymous, anonymous: SEVERITY_LEVEL) return BOOLEAN;
(anonymous, anonymous: SEVERITY_LEVEL) return BOOLEAN;
(anonymous, anonymous: SEVERITY_LEVEL) return BOOLEAN;

-- type universal_integer is range implementation_deﬁned;
-- The predeﬁned operators for this type are as follows:
-------

710

function "="
function "/="
function "<"
function "<="
function ">"
function ">="

-- function "+"
-- function "-"
-- function "abs"

715

4The
5The

(anonymous, anonymous: universal_integer) return BOOLEAN;
(anonymous, anonymous: universal_integer) return BOOLEAN;
(anonymous, anonymous: universal_integer) return BOOLEAN;
(anonymous, anonymous: universal_integer) return BOOLEAN;
(anonymous, anonymous: universal_integer) return BOOLEAN;
(anonymous, anonymous: universal_integer) return BOOLEAN;
(anonymous: universal_integer) return universal_integer;
(anonymous: universal_integer) return universal_integer;
(anonymous: universal_integer) return universal_integer;

nonbreaking space character.
soft hyphen character.

Copyright © 2000 IEEE. All rights reserved.

203

IEEE
Std 1076, 2000 Edition

-------

720

function "+"
function "–"
function "*"
function "/"
function "mod"
function "rem"

IEEE STANDARD VHDL

(anonymous, anonymous: universal_integer) return universal_integer;
(anonymous, anonymous: universal_integer) return universal_integer;
(anonymous, anonymous: universal_integer) return universal_integer;
(anonymous, anonymous: universal_integer) return universal_integer;
(anonymous, anonymous: universal_integer) return universal_integer;
(anonymous, anonymous: universal_integer) return universal_integer;

-- type universal_real is range implementation_deﬁned;
-- The predeﬁned operators for this type are as follows:

725

-------

730

735

function "="
function "/="
function "<"
function "<="
function ">"
function ">="

-- function "+"
-- function "–"
-- function "abs"

(anonymous: universal_real) return universal_real;
(anonymous: universal_real) return universal_real;
(anonymous: universal_real) return universal_real;

-----

(anonymous, anonymous: universal_real) return universal_real;
(anonymous, anonymous: universal_real) return universal_real;
(anonymous, anonymous: universal_real) return universal_real;
(anonymous, anonymous: universal_real) return universal_real;

function "+"
function "–"
function "*"
function "/"

-- function "*"
--- function "*"
--- function "/"
--

740

(anonymous, anonymous: universal_real) return BOOLEAN;
(anonymous, anonymous: universal_real) return BOOLEAN;
(anonymous, anonymous: universal_real) return BOOLEAN;
(anonymous, anonymous: universal_real) return BOOLEAN;
(anonymous, anonymous: universal_real) return BOOLEAN;
(anonymous, anonymous: universal_real) return BOOLEAN;

(anonymous: universal_real; anonymous: universal_integer)
return universal_real;
(anonymous: universal_integer; anonymous: universal_real)
return universal_real;
(anonymous: universal_real; anonymous: universal_integer)
return universal_real;

-- Predeﬁned numeric types:

745

type INTEGER is range implementation_deﬁned;
-- The predeﬁned operators for this type are as follows:

750

755

-- function "**"
--- function "**"
--

(anonymous: universal_integer; anonymous: INTEGER)
return universal_integer;
(anonymous: universal_real; anonymous: INTEGER)
return universal_real;

-------

(anonymous, anonymous: INTEGER) return BOOLEAN;
(anonymous, anonymous: INTEGER) return BOOLEAN;
(anonymous, anonymous: INTEGER) return BOOLEAN;
(anonymous, anonymous: INTEGER) return BOOLEAN;
(anonymous, anonymous: INTEGER) return BOOLEAN;
(anonymous, anonymous: INTEGER) return BOOLEAN;

function "="
function "/="
function "<"
function "<="
function ">"
function ">="

-- function "+"
-- function "–"
-- function "abs"

760

204

(anonymous: INTEGER) return INTEGER;
(anonymous: INTEGER) return INTEGER;
(anonymous: INTEGER) return INTEGER;

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

765

-------

function "+"
function "–"
function "*"
function "/"
function "mod"
function "rem"

(anonymous, anonymous: INTEGER) return INTEGER;
(anonymous, anonymous: INTEGER) return INTEGER;
(anonymous, anonymous: INTEGER) return INTEGER;
(anonymous, anonymous: INTEGER) return INTEGER;
(anonymous, anonymous: INTEGER) return INTEGER;
(anonymous, anonymous: INTEGER) return INTEGER;

-- function "**"

(anonymous: INTEGER; anonymous: INTEGER) return INTEGER;

type REAL is range implementation_deﬁned;
-- The predeﬁned operators for this type are as follows:
770

775

780

-------

function "="
function "/="
function "<"
function "<="
function ">"
function ">="

(anonymous, anonymous: REAL) return BOOLEAN;
(anonymous, anonymous: REAL) return BOOLEAN;
(anonymous, anonymous: REAL) return BOOLEAN;
(anonymous, anonymous: REAL) return BOOLEAN;
(anonymous, anonymous: REAL) return BOOLEAN;
(anonymous, anonymous: REAL) return BOOLEAN;

-- function "+"
-- function "–"
-- function "abs"

(anonymous: REAL) return REAL;
(anonymous: REAL) return REAL;
(anonymous: REAL) return REAL;

-----

(anonymous, anonymous: REAL) return REAL;
(anonymous, anonymous: REAL) return REAL;
(anonymous, anonymous: REAL) return REAL;
(anonymous, anonymous: REAL) return REAL;

function "+"
function "–"
function "*"
function "/"

-- function "**"

(anonymous: REAL; anonymous: INTEGER) return REAL;

-- Predeﬁned type TIME:
785

type TIME is range implementation_deﬁned
units
fs;
ps
ns
us
ms
sec
min
hr
end units;

790

795

=
=
=
=
=
=
=

1000 fs;
1000 ps;
1000 ns;
1000 us;
1000 ms;
60 sec;
60 min;

---------

femtosecond
picosecond
nanosecond
microsecond
millisecond
second
minute
hour

-- The predeﬁned operators for this type are as follows:

800

805

-------

function "="
function "/="
function "<"
function "<="
function ">"
function ">="

-- function "+"
-- function "–"
-- function "abs"

(anonymous, anonymous: TIME) return BOOLEAN;
(anonymous, anonymous: TIME) return BOOLEAN;
(anonymous, anonymous: TIME) return BOOLEAN;
(anonymous, anonymous: TIME) return BOOLEAN;
(anonymous, anonymous: TIME) return BOOLEAN;
(anonymous, anonymous: TIME) return BOOLEAN;
(anonymous: TIME) return TIME;
(anonymous: TIME) return TIME;
(anonymous: TIME) return TIME;

Copyright © 2000 IEEE. All rights reserved.

205

IEEE
Std 1076, 2000 Edition

810

-- function "+"
-- function "–"

(anonymous, anonymous: TIME) return TIME;
(anonymous, anonymous: TIME) return TIME;

-------

(anonymous: TIME;
(anonymous: TIME;
(anonymous: INTEGER;
(anonymous: REAL;
(anonymous: TIME;
(anonymous: TIME;

function "*"
function "*"
function "*"
function "*"
function "/"
function "/"

-- function "/"
815

IEEE STANDARD VHDL

anonymous: INTEGER)
anonymous: REAL)
anonymous: TIME)
anonymous: TIME)
anonymous: INTEGER)
anonymous: REAL)

return TIME;
return TIME;
return TIME;
return TIME;
return TIME;
return TIME;

(anonymous, anonymous: TIME) return universal_integer;

subtype DELAY_LENGTH is TIME range 0 fs to TIME'HIGH;
-- A function that returns universal_to_physical_time (Tc ), (see 12.6.4):
impure function NOW return DELAY_LENGTH;
-- Predeﬁned numeric subtypes:
subtype NATURAL is INTEGER range 0 to INTEGER'HIGH;
subtype POSITIVE is INTEGER range 1 to INTEGER'HIGH;

820

-- Predeﬁned array types:
type STRING is array (POSITIVE range <>) of CHARACTER;
-- The predeﬁned operators for these types are as follows:
-------

function "="
function "/="
function "<"
function "<="
function ">"
function ">="

(anonymous, anonymous: STRING) return BOOLEAN;
(anonymous, anonymous: STRING) return BOOLEAN;
(anonymous, anonymous: STRING) return BOOLEAN;
(anonymous, anonymous: STRING) return BOOLEAN;
(anonymous, anonymous: STRING) return BOOLEAN;
(anonymous, anonymous: STRING) return BOOLEAN;

830

------

function "&"
function "&"
function "&"
function "&"

(anonymous: STRING; anonymous: STRING)
return STRING;
(anonymous: STRING; anonymous: CHARACTER) return STRING;
(anonymous: CHARACTER; anonymous: STRING) return STRING;
(anonymous: CHARACTER; anonymous: CHARACTER)
return STRING;

835

type BIT_VECTOR is array (NATURAL range <>) of BIT;

825

-- The predeﬁned operators for this type are as follows:
-------

840

function "and"
function "or"
function "nand"
function "nor"
function "xor"
function "xnor"

-- function "not"

206

(anonymous, anonymous: BIT_VECTOR) return BIT_VECTOR;
(anonymous, anonymous: BIT_VECTOR) return BIT_VECTOR;
(anonymous, anonymous: BIT_VECTOR) return BIT_VECTOR;
(anonymous, anonymous: BIT_VECTOR) return BIT_VECTOR;
(anonymous, anonymous: BIT_VECTOR) return BIT_VECTOR;
(anonymous, anonymous: BIT_VECTOR) return BIT_VECTOR;
(anonymous: BIT_VECTOR) return BIT_VECTOR;

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

845

850

855

860

865

-------------

function "sll"

-------

function "="
function "/="
function "<"
function "<="
function ">"
function ">="

(anonymous, anonymous: BIT_VECTOR) return BOOLEAN;
(anonymous, anonymous: BIT_VECTOR) return BOOLEAN;
(anonymous, anonymous: BIT_VECTOR) return BOOLEAN;
(anonymous, anonymous: BIT_VECTOR) return BOOLEAN;
(anonymous, anonymous: BIT_VECTOR) return BOOLEAN;
(anonymous, anonymous: BIT_VECTOR) return BOOLEAN;

------

function "&"

(anonymous: BIT_VECTOR; anonymous: BIT_VECTOR)
return BIT_VECTOR;
(anonymous: BIT_VECTOR; anonymous: BIT) return BIT_VECTOR;
(anonymous: BIT; anonymous: BIT_VECTOR) return BIT_VECTOR;
(anonymous: BIT; anonymous: BIT)
return BIT_VECTOR;

function "srl"
function "sla"
function "sra"
function "rol"
function "ror"

function "&"
function "&"
function "&"

(anonymous: BIT_VECTOR; anonymous: INTEGER)
return BIT_VECTOR;
(anonymous: BIT_VECTOR; anonymous: INTEGER)
return BIT_VECTOR;
(anonymous: BIT_VECTOR; anonymous: INTEGER)
return BIT_VECTOR;
(anonymous: BIT_VECTOR; anonymous: INTEGER)
return BIT_VECTOR;
(anonymous: BIT_VECTOR; anonymous: INTEGER)
return BIT_VECTOR;
(anonymous: BIT_VECTOR; anonymous: INTEGER)
return BIT_VECTOR;

-- The predeﬁned types for opening ﬁles:

870

type FILE_OPEN_KIND is (
READ_MODE,
WRITE_MODE,
APPEND_MODE);

-----

Resulting access mode is read-only.
Resulting access mode is write-only.
Resulting access mode is write-only; information
is appended to the end of the existing ﬁle.

-- The predeﬁned operators for this type are as follows:
875

880

-------

function "="
function "/="
function "<"
function "<="
function ">"
function ">="

(anonymous, anonymous: FILE_OPEN_KIND) return BOOLEAN;
(anonymous, anonymous: FILE_OPEN_KIND) return BOOLEAN;
(anonymous, anonymous: FILE_OPEN_KIND) return BOOLEAN;
(anonymous, anonymous: FILE_OPEN_KIND) return BOOLEAN;
(anonymous, anonymous: FILE_OPEN_KIND) return BOOLEAN;
(anonymous, anonymous: FILE_OPEN_KIND) return BOOLEAN;

type FILE_OPEN_STATUS is (
OPEN_OK,
STATUS_ERROR,
NAME_ERROR,
MODE_ERROR);

Copyright © 2000 IEEE. All rights reserved.

-----

File open was successful.
File object was already open.
External ﬁle not found or inaccessible.
Could not open ﬁle with requested access mode.

207

IEEE
Std 1076, 2000 Edition

885

IEEE STANDARD VHDL

-- The predeﬁned operators for this type are as follows:
-------------

890

895

function "="
function "/="
function "<"
function "<="
function ">"
function ">="

(anonymous, anonymous: FILE_OPEN_STATUS)
return BOOLEAN;
(anonymous, anonymous: FILE_OPEN_STATUS)
return BOOLEAN;
(anonymous, anonymous: FILE_OPEN_STATUS)
return BOOLEAN;
(anonymous, anonymous: FILE_OPEN_STATUS)
return BOOLEAN;
(anonymous, anonymous: FILE_OPEN_STATUS)
return BOOLEAN;
(anonymous, anonymous: FILE_OPEN_STATUS)
return BOOLEAN;

-- The 'FOREIGN attribute:
attribute FOREIGN: STRING;
900

end STANDARD;
The 'FOREIGN attribute may be associated only with architectures (see 1.2) or with subprograms. In the
latter case, the attribute speciﬁcation must appear in the declarative part in which the subprogram is declared
(see 2.1).
NOTES

905

910

1—The ASCII mnemonics for ﬁle separator (FS), group separator (GS), record separator (RS), and unit separator (US)
are represented by FSP, GSP, RSP, and USP, respectively, in type CHARACTER in order to avoid conﬂict with the units
of type TIME.
2—The declarative parts and statement parts of design entities whose corresponding architectures are decorated with the
'FOREIGN attribute and subprograms that are likewise decorated are subject to special elaboration rules. See 12.3 and
12.4.

14.3 Package TEXTIO
Package TEXTIO contains declarations of types and subprograms that support formatted I/O operations on
text ﬁles.
package TEXTIO is
-- Type deﬁnitions for text I/O:
915

type LINE is access STRING;

-- A LINE is a pointer to a STRING value.

type TEXT is ﬁle of STRING;

-- A ﬁle of variable-length ASCII records.

type SIDE is (RIGHT, LEFT);

-- For justifying output data within ﬁelds.

subtype WIDTH is NATURAL;

-- For specifying widths of output ﬁelds.

-- Standard text ﬁles:
920

208

ﬁle INPUT:

TEXT open READ_MODE

is "STD_INPUT";

ﬁle OUTPUT:

TEXT open WRITE_MODE

is "STD_OUTPUT";

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

-- Input routines for standard types:
procedure READLINE (ﬁle F: TEXT; L: out LINE);

925

930

935

940

procedure READ (L: inout LINE;
procedure READ (L: inout LINE;

VALUE: out BIT;
VALUE: out BIT);

GOOD: out BOOLEAN);

procedure READ (L: inout LINE;
procedure READ (L: inout LINE;

VALUE: out BIT_VECTOR; GOOD: out BOOLEAN);
VALUE: out BIT_VECTOR);

procedure READ (L: inout LINE;
procedure READ (L: inout LINE;

VALUE: out BOOLEAN;
VALUE: out BOOLEAN);

procedure READ (L: inout LINE;
procedure READ (L: inout LINE;

VALUE: out CHARACTER; GOOD: out BOOLEAN);
VALUE: out CHARACTER);

procedure READ (L: inout LINE;
procedure READ (L: inout LINE;

VALUE: out INTEGER;
VALUE: out INTEGER);

GOOD: out BOOLEAN);

procedure READ (L: inout LINE;
procedure READ (L: inout LINE;

VALUE: out REAL;
VALUE: out REAL);

GOOD: out BOOLEAN);

procedure READ (L: inout LINE;
procedure READ (L: inout LINE;

VALUE: out STRING;
VALUE: out STRING);

GOOD: out BOOLEAN);

procedure READ (L: inout LINE;
procedure READ (L: inout LINE;

VALUE: out TIME;
VALUE: out TIME);

GOOD: out BOOLEAN);

GOOD: out BOOLEAN);

-- Output routines for standard types:
procedure WRITELINE (ﬁle F: TEXT; L: inout LINE);
procedure WRITE (L: inout LINE;
VALUE: in BIT;
JUSTIFIED: in SIDE:= RIGHT; FIELD: in WIDTH := 0);

945

procedure WRITE (L: inout LINE;
VALUE: in BIT_VECTOR;
JUSTIFIED: in SIDE:= RIGHT; FIELD: in WIDTH := 0);
procedure WRITE (L: inout LINE;
VALUE: in BOOLEAN;
JUSTIFIED: in SIDE:= RIGHT; FIELD: in WIDTH := 0);
procedure WRITE (L: inout LINE;
VALUE: in CHARACTER;
JUSTIFIED: in SIDE:= RIGHT; FIELD: in WIDTH := 0);

950

procedure WRITE (L: inout LINE;
VALUE: in INTEGER;
JUSTIFIED: in SIDE:= RIGHT; FIELD: in WIDTH := 0);
procedure WRITE (L: inout LINE;
VALUE: in REAL;
JUSTIFIED: in SIDE:= RIGHT; FIELD: in WIDTH := 0;
DIGITS: in NATURAL:= 0);

955

procedure WRITE (L: inout LINE;
VALUE: in STRING;
JUSTIFIED: in SIDE:= RIGHT; FIELD: in WIDTH := 0);
procedure WRITE (L: inout LINE;
VALUE: in TIME;
JUSTIFIED: in SIDE:= RIGHT; FIELD: in WIDTH := 0;
UNIT: in TIME:= ns);

Copyright © 2000 IEEE. All rights reserved.

209

IEEE
Std 1076, 2000 Edition

960

IEEE STANDARD VHDL

-- File position predicate:
-- function ENDFILE (ﬁle F: TEXT) return BOOLEAN;
end TEXTIO;

965

970

975

Procedures READLINE and WRITELINE declared in package TEXTIO read and write entire lines of a ﬁle
of type TEXT. Procedure READLINE causes the next line to be read from the ﬁle and returns as the value of
parameter L an access value that designates an object representing that line. If parameter L contains a
nonnull access value at the start of the call, the object designated by that value is deallocated before the new
object is created. The representation of the line does not contain the representation of the end of the line. It is
an error if the ﬁle speciﬁed in a call to READLINE is not open or, if open, the ﬁle has an access mode other
than read-only (see 3.4.1). Procedure WRITELINE causes the current line designated by parameter L to be
written to the ﬁle and returns with the value of parameter L designating a null string. If parameter L contains
a null access value at the start of the call, then a null string is written to the ﬁle. It is an error if the ﬁle speciﬁed in a call to WRITELINE is not open or, if open, the ﬁle has an access mode other than write-only.
The language does not deﬁne the representation of the end of a line. An implementation must allow all
possible values of types CHARACTER and STRING to be written to a ﬁle. However, as an implementation
is permitted to use certain values of types CHARACTER and STRING as line delimiters, it may not be
possible to read these values from a TEXT ﬁle.
Each READ procedure declared in package TEXTIO extracts data from the beginning of the string value
designated by parameter L and modiﬁes the value so that it designates the remaining portion of the line on
exit.

980

985

990

The READ procedures deﬁned for a given type other than CHARACTER and STRING begin by skipping
leading whitespace characters. A whitespace character is deﬁned as a space, a nonbreaking space, or a horizontal tabulation character (SP, NBSP, or HT). For all READ procedures, characters are then removed from
L and composed into a string representation of the value of the speciﬁed type. Character removal and string
composition stops when a character is encountered that cannot be part of the value according to the lexical
rules of 13.2; this character is not removed from L and is not added to the string representation of the value.
The READ procedures for types INTEGER and REAL also accept a leading sign; additionally, there can be
no space between the sign and the remainder of the literal. The READ procedures for types STRING and
BIT_VECTOR also terminate acceptance when VALUE'LENGTH characters have been accepted. Again
using the rules of 13.2, the accepted characters are then interpreted as a string representation of the speciﬁed
type. The READ does not succeed if the sequence of characters removed from L is not a valid string representation of a value of the speciﬁed type or, in the case of types STRING and BIT_VECTOR, if the
sequence does not contain VALUE'LENGTH characters.
The deﬁnitions of the string representation of the value for each data type are as follows:
—

The representation of a BIT value is formed by a single character, either 1 or 0. No leading or trailing
quotation characters are present.

—

The representation of a BIT_VECTOR value is formed by a sequence of characters, either 1 or 0. No
leading or trailing quotation characters are present.

—

The representation of a BOOLEAN value is formed by an identiﬁer, either FALSE or TRUE.

—

The representation of a CHARACTER value is formed by a single character.

995

210

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

1000

—

The representation of both INTEGER and REAL values is that of a decimal literal (see 13.4.1), with
the addition of an optional leading sign. The sign is never written if the value is nonnegative, but it is
accepted during a read even if the value is nonnegative. No spaces can occur between the sign and
the remainder of the value. The decimal point is absent in the case of an INTEGER literal and present
in the case of a REAL literal. An exponent may optionally be present; moreover, the language does
not deﬁne under what conditions it is or is not present. However, if the exponent is present, the “e” is
written as a lowercase character. Leading and trailing zeroes are written as necessary to meet the
requirements of the FIELD and DIGITS parameters, and they are accepted during a read.

—

The representation of a STRING value is formed by a sequence of characters, one for each element
of the string. No leading or trailing quotation characters are present.

—

The representation of a TIME value is formed by an optional decimal literal composed following the
rules for INTEGER and REAL literals described above, one or more blanks, and an identiﬁer that is
a unit of type TIME, as deﬁned in package STANDARD (see 14.2). When read, the identiﬁer can be
expressed with characters of either case; when written, the identiﬁer is expressed in lowercase
characters.

1005

1010

1015

IEEE
Std 1076, 2000 Edition

Each WRITE procedure similarly appends data to the end of the string value designated by parameter L; in
this case, however, L continues to designate the entire line after the value is appended. The format of the
appended data is deﬁned by the string representations deﬁned above for the READ procedures.
The READ and WRITE procedures for the types BIT_VECTOR and STRING respectively read and write
the element values in left-to-right order.

1020

1025

1030

1035

1040

For each predeﬁned data type there are two READ procedures declared in package TEXTIO. The ﬁrst has
three parameters: L, the line to read from; VALUE, the value read from the line; and GOOD, a Boolean ﬂag
that indicates whether the read operation succeeded or not. For example, the operation READ (L, IntVal,
OK) would return with OK set to FALSE, L unchanged, and IntVal undeﬁned if IntVal is a variable of type
INTEGER and L designates the line "ABC". The success indication returned via parameter GOOD allows a
process to recover gracefully from unexpected discrepancies in input format. The second form of read operation has only the parameters L and VALUE. If the requested type cannot be read into VALUE from line L,
then an error occurs. Thus, the operation READ (L, IntVal) would cause an error to occur if IntVal is of type
INTEGER and L designates the line "ABC".
For each predeﬁned data type there is one WRITE procedure declared in package TEXTIO. Each of these
has at least two parameters: L, the line to which to write; and VALUE, the value to be written. The additional
parameters JUSTIFIED, FIELD, DIGITS, and UNIT control the formatting of output data. Each write operation appends data to a line formatted within a ﬁeld that is at least as long as required to represent the data
value. Parameter FIELD speciﬁes the desired ﬁeld width. Since the actual ﬁeld width will always be at least
large enough to hold the string representation of the data value, the default value 0 for the FIELD parameter
has the effect of causing the data value to be written out in a ﬁeld of exactly the right width (i.e., no leading
or trailing spaces). Parameter JUSTIFIED speciﬁes whether values are to be right- or left-justiﬁed within the
ﬁeld; the default is right-justiﬁed. If the FIELD parameter describes a ﬁeld width larger than the number of
characters necessary for a given value, blanks are used to ﬁll the remaining characters in the ﬁeld.
Parameter DIGITS speciﬁes how many digits to the right of the decimal point are to be output when writing
a real number; the default value 0 indicates that the number should be output in standard form, consisting of
a normalized mantissa plus exponent (e.g., 1.079236E–23). If DIGITS is nonzero, then the real number is
output as an integer part followed by '.' followed by the fractional part, using the speciﬁed number of digits
(e.g., 3.14159).

Copyright © 2000 IEEE. All rights reserved.

211

IEEE
Std 1076, 2000 Edition

1045

1050

IEEE STANDARD VHDL

Parameter UNIT speciﬁes how values of type TIME are to be formatted. The value of this parameter must be
equal to one of the units declared as part of the declaration of type TIME; the result is that the TIME value is
formatted as an integer or real literal representing the number of multiples of this unit, followed by the name
of the unit itself. The name of the unit is formatted using only lowercase characters. Thus the procedure call
WRITE(Line, 5 ns, UNIT=>us) would result in the string value "0.005 us" being appended to the string
value designated by Line, whereas WRITE(Line, 5 ns) would result in the string value "5 ns" being
appended (since the default UNIT value is ns).
Function ENDFILE is deﬁned for ﬁles of type TEXT by the implicit declaration of that function as part of
the declaration of the ﬁle type.
NOTES

1055

1060

1—For a variable L of type Line, attribute L'Length gives the current length of the line, whether that line is being read or
written. For a line L that is being written, the value of L'Length gives the number of characters that have already been
written to the line; this is equivalent to the column number of the last character of the line. For a line L that is being read,
the value of L'Length gives the number of characters on that line remaining to be read. In particular, the expression
L'Length = 0 is true precisely when the end of the current line has been reached.
2—The execution of a read or write operation may modify or even deallocate the string object designated by input
parameter L of type Line for that operation; thus, a dangling reference may result if the value of a variable L of type Line
is assigned to another access variable and then a read or write operation is performed on L.

212

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

Annex A
(informative)

Syntax summary
This annex provides a summary of the syntax for VHDL. Productions are ordered alphabetically by left-hand
nonterminal name. The number listed to the right indicates the clause or subclause where the production is
given.
abstract_literal ::= decimal_literal | based_literal
access_type_deﬁnition ::= access subtype_indication
actual_designator ::=
expression
| signal_name
| variable_name
| ﬁle_name
| open
actual_parameter_part ::= parameter_association_list
actual_part ::=
actual_designator
| function_name ( actual_designator )
| type_mark ( actual_designator )
adding_operator ::= + | – | &

[§ 13.4]
[§ 3.3]
[§ 4.3.2.2]

[§ 7.3.3]
[§ 4.3.2.2]

[§ 7.2]

aggregate ::=
( element_association { , element_association } )

[§ 7.3.2]

alias_declaration ::=
alias alias_designator [ : subtype_indication ] is name [ signature ] ;

[§ 4.3.3]

alias_designator ::= identiﬁer | character_literal | operator_symbol

[§ 4.3.3]

allocator ::=
new subtype_indication
| new qualiﬁed_expression

[§ 7.3.6]

architecture_body ::=
architecture identiﬁer of entity_name is
architecture_declarative_part
begin
architecture_statement_part
end [ architecture ] [ architecture_simple_name ] ;
architecture_declarative_part ::=
{ block_declarative_item }

Copyright © 2000 IEEE. All rights reserved.

[§ 1.2]

[§ 1.2.1]

213

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

architecture_statement_part ::=
{ concurrent_statement }

[§ 1.2.2]

array_type_deﬁnition ::=
unconstrained_array_deﬁnition | constrained_array_deﬁnition

[§ 3.2.1]

assertion ::=
assert condition
[ report expression ]
[ severity expression ]

[§ 8.2]

assertion_statement ::= [ label : ] assertion ;

[§ 8.2]

association_element ::=
[ formal_part => ] actual_part

[§ 4.3.2.2]

association_list ::=
association_element { , association_element }

[§ 4.3.2.2]

attribute_declaration ::=
attribute identiﬁer : type_mark ;

[§ 4.4]

attribute_designator ::= attribute_simple_name

[§ 6.6]

attribute_name ::=
preﬁx [ signature ] ' attribute_designator [ ( expression ) ]

[§ 6.6]

attribute_speciﬁcation ::=
attribute attribute_designator of entity_speciﬁcation is expression ;

[§ 5.1]

base ::= integer

[§ 13.4.2]

base_speciﬁer ::= B | O | X

[§ 13.7]

base_unit_declaration ::= identiﬁer ;

[§ 3.1.3]

based_integer ::=
extended_digit { [ underline ] extended_digit }

[§ 13.4.2]

based_literal ::=
base # based_integer [ . based_integer ] # [ exponent ]

[§ 13.4.2]

basic_character ::=
basic_graphic_character | format_effector

[§ 13.1]

basic_graphic_character ::=
upper_case_letter | digit | special_character| space_character

[§ 13.1]

basic_identiﬁer ::= letter { [ underline ] letter_or_digit }
binding_indication ::=
[ use entity_aspect ]
[ generic_map_aspect ]
[ port_map_aspect ]

214

[§ 13.3.1]
[§ 5.2.1]

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

bit_string_literal ::= base_speciﬁer " [ bit_value ] "

[§ 13.7]

bit_value ::= extended_digit { [ underline ] extended_digit }

[§ 13.7]

block_conﬁguration ::=
for block_speciﬁcation
{ use_clause }
{ conﬁguration_item }
end for ;

[§ 1.3.1]

block_declarative_item ::=
subprogram_declaration
| subprogram_body
| type_declaration
| subtype_declaration
| constant_declaration
| signal_declaration
| shared_variable_declaration
| ﬁle_declaration
| alias_declaration
| component_declaration
| attribute_declaration
| attribute_speciﬁcation
| conﬁguration_speciﬁcation
| disconnection_speciﬁcation
| use_clause
| group_template_declaration
| group_declaration

[§ 1.2.1]

block_declarative_part ::=
{ block_declarative_item }

[§ 9.1]

block_header ::=
[ generic_clause
[ generic_map_aspect ; ] ]
[ port_clause
[ port_map_aspect ; ] ]

[§ 9.1]

block_speciﬁcation ::=
architecture_name
| block_statement_label
| generate_statement_label [ ( index_speciﬁcation ) ]

[§ 1.3.1]

block_statement ::=
block_label :
block [ ( guard_expression ) ] [ is ]
block_header
block_declarative_part
begin
block_statement_part
end block [ block_label ] ;

[§ 9.1]

block_statement_part ::=
{ concurrent_statement }

[§ 9.1]

Copyright © 2000 IEEE. All rights reserved.

215

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

case_statement ::=
[ case_label : ]
case expression is
case_statement_alternative
{ case_statement_alternative }
end case [ case_label ] ;

[§ 8.8]

case_statement_alternative ::=
when choices =>
sequence_of_statements

[§ 8.8]

character_literal ::= ' graphic_character '

[§ 13.5]

choice ::=
simple_expression
| discrete_range
| element_simple_name
| others

[§ 7.3.2]

choices ::= choice { | choice }

[§ 7.3.2]

component_conﬁguration ::=
for component_speciﬁcation
[ binding_indication ; ]
[ block_conﬁguration ]
end for ;

[§ 1.3.2]

component_declaration ::=
component identiﬁer [ is ]
[ local_generic_clause ]
[ local_port_clause ]
end component [ component_simple_name ] ;

[§ 4.5]

component_instantiation_statement ::=
instantiation_label :
instantiated_unit
[ generic_map_aspect ]
[ port_map_aspect ] ;

[§ 9.6]

component_speciﬁcation ::=
instantiation_list : component_name

[§ 5.2]

composite_type_deﬁnition ::=
array_type_deﬁnition
| record_type_deﬁnition

[§ 3.2]

concurrent_assertion_statement ::=
[ label : ] [ postponed ] assertion ;

[§ 9.4]

concurrent_procedure_call_statement ::=
[ label : ] [ postponed ] procedure_call ;

[§ 9.3]

216

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

concurrent_signal_assignment_statement ::=
[ label : ] [ postponed ] conditional_signal_assignment
| [ label : ] [ postponed ] selected_signal_assignment
concurrent_statement ::=
block_statement
| process_statement
| concurrent_procedure_call_statement
| concurrent_assertion_statement
| concurrent_signal_assignment_statement
| component_instantiation_statement
| generate_statement

IEEE
Std 1076, 2000 Edition

[§ 9.5]

[§ 9]

condition ::= boolean_expression

[§ 8.1]

condition_clause ::= until condition

[§ 8.1]

conditional_signal_assignment ::=
target <= options conditional_waveforms ;

[§ 9.5.1]

conditional_waveforms ::=
{ waveform when condition else }
waveform [ when condition ]

[§ 9.5.1]

conﬁguration_declaration ::=
conﬁguration identiﬁer of entity_name is
conﬁguration_declarative_part
block_conﬁguration
end [ conﬁguration ] [ conﬁguration_simple_name ] ;

[§ 1.3]

conﬁguration_declarative_item ::=
use_clause
| attribute_speciﬁcation
| group_declaration

[§ 1.3]

conﬁguration_declarative_part ::=
{ conﬁguration_declarative_item }

[§ 1.3]

conﬁguration_item ::=
block_conﬁguration
| component_conﬁguration
conﬁguration_speciﬁcation ::=
for component_speciﬁcation binding_indication ;
constant_declaration ::=
constant identiﬁer_list : subtype_indication [ := expression ] ;
constrained_array_deﬁnition ::=
array index_constraint of element_subtype_indication
constraint ::=
range_constraint
| index_constraint

Copyright © 2000 IEEE. All rights reserved.

[§ 1.3.1]

[§ 5.2]

[§ 4.3.1.1]

[§ 3.2.1]

[§ 4.2]

217

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

context_clause ::= { context_item }

[§ 11.3]

context_item ::=
library_clause
| use_clause

[§ 11.3]

decimal_literal ::= integer [ . integer ] [ exponent ]

[§ 13.4.1]

declaration ::=
type_declaration
| subtype_declaration
| object_declaration
| interface_declaration
| alias_declaration
| attribute_declaration
| component_declaration
| group_template_declaration
| group_declaration
| entity_declaration
| conﬁguration_declaration
| subprogram_declaration
| package_declaration

[§ 4]

delay_mechanism ::=
transport
| [ reject time_expression ] inertial

[§ 8.4]

design_ﬁle ::= design_unit { design_unit }

[§ 11.1]

design_unit ::= context_clause library_unit

[§ 11.1]

designator ::= identiﬁer | operator_symbol

[§ 2.1]

direction ::= to | downto

[§ 3.1]

disconnection_speciﬁcation ::=
disconnect guarded_signal_speciﬁcation after time_expression ;

[§ 5.3]

discrete_range ::= discrete_subtype_indication | range

[§ 3.2.1]

element_association ::=
[ choices => ] expression

[§ 7.3.2]

element_declaration ::=
identiﬁer_list : element_subtype_deﬁnition ;

[§ 3.2.2]

element_subtype_deﬁnition ::= subtype_indication

[§ 3.2.2]

entity_aspect ::=
entity entity_name [ ( architecture_identiﬁer) ]
| conﬁguration conﬁguration_name
| open

218

[§ 5.2.1.1]

Copyright © 2000 IEEE. All rights reserved.

IEEE
Std 1076, 2000 Edition

LANGUAGE REFERENCE MANUAL

entity_class ::=
entity
| procedure
| type
| signal
| label

[§ 5.1]
| architecture
| function
| subtype
| variable
| literal

| conﬁguration
| package
| constant
| component
| units

entity_class_entry ::= entity_class [ <> ]

[§ 4.6]

entity_class_entry_list ::=
entity_class_entry { , entity_class_entry }

[§ 4.6]

entity_declaration ::=
entity identiﬁer is
entity_header
entity_declarative_part
[
begin
entity_statement_part ]
end [ entity ] [ entity_simple_name ] ;

[§ 1.1]

entity_declarative_item ::=
subprogram_declaration
| subprogram_body
| type_declaration
| subtype_declaration
| constant_declaration
| signal_declaration
| shared_variable_declaration
| ﬁle_declaration
| alias_declaration
| attribute_declaration
| attribute_speciﬁcation
| disconnection_speciﬁcation
| use_clause
| group_template_declaration
| group_declaration

[§ 1.1.2]

entity_declarative_part ::=
{ entity_declarative_item }

[§ 1.1.2]

entity_designator ::= entity_tag [ signature ]
entity_header ::=
[ formal_generic_clause ]
[ formal_port_clause ]

[§ 5.1]
[§ 1.1.1]

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

[§ 5.1]

entity_speciﬁcation ::=
entity_name_list : entity_class

[§ 5.1]

Copyright © 2000 IEEE. All rights reserved.

219

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

entity_statement ::=
concurrent_assertion_statement
| passive_concurrent_procedure_call_statement
| passive_process_statement

[§ 1.1.3]

entity_statement_part ::=
{ entity_statement }

[§ 1.1.3]

entity_tag ::= simple_name | character_literal | operator_symbol

[§ 5.1]

enumeration_literal ::= identiﬁer | character_literal

[§ 3.1.1]

enumeration_type_deﬁnition ::=
( enumeration_literal { , enumeration_literal } )

[§ 3.1.1]

exit_statement ::=
[ label : ] exit [ loop_label ] [ when condition ] ;

[§ 8.11]

exponent ::= E [ + ] integer | E – integer

[§ 13.4.1]

expression ::=
relation { and relation }
| relation { or relation }
| relation { xor relation }
| relation [ nand relation ]
| relation [ nor relation ]
| relation { xnor relation }

[§ 7.1]

extended_digit ::= digit | letter

[§ 13.4.2]

extended_identiﬁer ::= \ graphic_character { graphic_character } \

[§ 13.3.2]

factor ::=
primary [ ** primary ]
| abs primary
| not primary

[§ 7.1]

ﬁle_declaration ::=
ﬁle identiﬁer_list : subtype_indication [ ﬁle_open_information ] ;

[§ 4.3.1.4]

ﬁle_logical_name ::= string_expression

[§ 4.3.1.4]

ﬁle_open_information ::=
[ open ﬁle_open_kind_expression ] is ﬁle_logical_name

[§ 4.3.1.4]

ﬁle_type_deﬁnition ::=
ﬁle of type_mark
ﬂoating_type_deﬁnition ::= range_constraint
formal_designator ::=
generic_name
| port_name
| parameter_name

220

[§ 3.4]

[§ 3.1.4]
[§ 4.3.2.2]

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

formal_parameter_list ::= parameter_interface_list
formal_part ::=
formal_designator
| function_name ( formal_designator )
| type_mark ( formal_designator )
full_type_declaration ::=
type identiﬁer is type_deﬁnition ;
function_call ::=
function_name [ ( actual_parameter_part ) ]

IEEE
Std 1076, 2000 Edition

[§ 2.1.1]
[§ 4.3.2.2]

[§ 4.1]

[§ 7.3.3]

generate_statement ::=
generate_label :
generation_scheme generate
[ { block_declarative_item }
begin ]
{ concurrent_statement }
end generate [ generate_label ] ;

[§ 9.7]

generation_scheme ::=
for generate_parameter_speciﬁcation
| if condition

[§ 9.7]

generic_clause ::=
generic ( generic_list ) ;

[§ 1.1.1]

generic_list ::= generic_interface_list

[§ 1.1.1.1]

generic_map_aspect ::=
generic map ( generic_association_list )

[§ 5.2.1.2]

graphic_character ::=
basic_graphic_character | lower_case_letter | other_special_character

[§ 13.1]

group_constituent ::= name | character_literal

[§ 4.7]

group_constituent_list ::= group_constituent { , group_constituent }

[§ 4.7]

group_declaration ::=
group identiﬁer : group_template_name ( group_constituent_list ) ;

[§ 4.7]

group_template_declaration ::=
group identiﬁer is ( entity_class_entry_list ) ;

[§ 4.6]

guarded_signal_speciﬁcation ::=
guarded_signal_list : type_mark

[§ 5.3]

identiﬁer ::= basic_identiﬁer | extended_identiﬁer

[§ 13.3]

identiﬁer_list ::= identiﬁer { , identiﬁer }

[§ 3.2.2]

Copyright © 2000 IEEE. All rights reserved.

221

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

if_statement ::=
[ if_label : ]
if condition then
sequence_of_statements
{ elsif condition then
sequence_of_statements }
[ else
sequence_of_statements ]
end if [ if_label ] ;

[§ 8.7]

incomplete_type_declaration ::= type identiﬁer ;

[§ 3.3.1]

index_constraint ::= ( discrete_range { , discrete_range } )

[§ 3.2.1]

index_speciﬁcation ::=
discrete_range
| static_expression

[§ 1.3.1]

index_subtype_deﬁnition ::= type_mark range <>

[§ 3.2.1]

indexed_name ::= preﬁx ( expression { , expression } )

[§ 6.4]

instantiated_unit ::=
[ component ] component_name
| entity entity_name [ ( architecture_identiﬁer ) ]
| conﬁguration conﬁguration_name

[§ 9.6]

instantiation_list ::=
instantiation_label { , instantiation_label }
| others
| all

[§ 5.2]

integer ::= digit { [ underline ] digit }

[§ 13.4.1]

integer_type_deﬁnition ::= range_constraint

[§ 3.1.2]

interface_constant_declaration ::=
[ constant ] identiﬁer_list : [ in ] subtype_indication [ := static_expression ]

[§ 4.3.2]

interface_declaration ::=
interface_constant_declaration
| interface_signal_declaration
| interface_variable_declaration
| interface_ﬁle_declaration

[§ 4.3.2]

interface_element ::= interface_declaration
interface_ﬁle_declaration ::=
ﬁle identiﬁer_list : subtype_indication
interface_list ::=
interface_element { ; interface_element }

222

[§ 4.3.2.1]
[§ 4.3.2]

[§ 4.3.2.1]

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

interface_signal_declaration ::=
[signal] identiﬁer_list : [ mode ] subtype_indication [ bus ] [ := static_expression ]

[§ 4.3.2]

interface_variable_declaration ::=
[variable] identiﬁer_list : [ mode ] subtype_indication [ := static_expression ]

[§ 4.3.2]

iteration_scheme ::=
while condition
| for loop_parameter_speciﬁcation

[§ 8.9]

label ::= identiﬁer

[§ 9.7]

letter ::= upper_case_letter | lower_case_letter

[§ 13.3.1]

letter_or_digit ::= letter | digit

[§ 13.3.1]

library_clause ::= library logical_name_list ;

[§ 11.2]

library_unit ::=
primary_unit
| secondary_unit

[§ 11.1]

literal ::=
numeric_literal
| enumeration_literal
| string_literal
| bit_string_literal
| null

[§ 7.3.1]

logical_name ::= identiﬁer

[§ 11.2]

logical_name_list ::= logical_name { , logical_name }

[§ 11.2]

logical_operator ::= and | or | nand | nor | xor | xnor

[§ 7.2]

loop_statement ::=
[ loop_label : ]
[ iteration_scheme ] loop
sequence_of_statements
end loop [ loop_label ] ;

[§ 8.9]

miscellaneous_operator ::= ** | abs | not

[§ 7.2]

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

[§ 4.3.2]

multiplying_operator ::= * | / | mod | rem

[§ 7.2]

name ::=
simple_name
| operator_symbol
| selected_name
| indexed_name
| slice_name
| attribute_name

[§ 6.1]

Copyright © 2000 IEEE. All rights reserved.

223

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

next_statement ::=
[ label : ] next [ loop_label ] [ when condition ] ;

[§ 8.10]

null_statement ::= [ label : ] null ;

[§ 8.13]

numeric_literal ::=
abstract_literal
| physical_literal

[§ 7.3.1]

object_declaration ::=
constant_declaration
| signal_declaration
| variable_declaration
| ﬁle_declaration

[§ 4.3.1]

operator_symbol ::= string_literal

[§ 2.1]

options ::= [ guarded ] [ delay_mechanism ]

[§ 9.5]

package_body ::=
package body package_simple_name is
package_body_declarative_part
end [ package body ] [ package_simple_name ] ;

[§ 2.6]

package_body_declarative_item ::=
subprogram_declaration
| subprogram_body
| type_declaration
| subtype_declaration
| constant_declaration
| shared_variable_declaration
| ﬁle_declaration
| alias_declaration
| use_clause
| group_template_declaration
| group_declaration

[§ 2.6]

package_body_declarative_part ::=
{ package_body_declarative_item }

[§ 2.6]

package_declaration ::=
package identiﬁer is
package_declarative_part
end [ package ] [ package_simple_name ] ;

[§ 2.5]

224

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

package_declarative_item ::=
subprogram_declaration
| type_declaration
| subtype_declaration
| constant_declaration
| signal_declaration
| shared_variable_declaration
| ﬁle_declaration
| alias_declaration
| component_declaration
| attribute_declaration
| attribute_speciﬁcation
| disconnection_speciﬁcation
| use_clause
| group_template_declaration
| group_declaration

[§ 2.5]

package_declarative_part ::=
{ package_declarative_item }

[§ 2.5]

parameter_speciﬁcation ::=
identiﬁer in discrete_range

[§ 8.9]

physical_literal ::= [ abstract_literal ] unit_name

[§ 3.1.3]

physical_type_deﬁnition ::=
range_constraint
units
base_unit_declaration
{ secondary_unit_declaration }
end units [ physical_type_simple_name ]

[§ 3.1.3]

port_clause ::=
port ( port_list ) ;

[§ 1.1.1]

port_list ::= port_interface_list

[§ 1.1.1.2]

port_map_aspect ::=
port map ( port_association_list )

[§ 5.2.1.2]

preﬁx ::=
name
| function_call

[§ 6.1]

primary ::=
name
| literal
| aggregate
| function_call
| qualiﬁed_expression
| type_conversion
| allocator
| ( expression )

[§ 7.1]

Copyright © 2000 IEEE. All rights reserved.

225

IEEE
Std 1076, 2000 Edition

primary_unit ::=
entity_declaration
| conﬁguration_declaration
| package_declaration

IEEE STANDARD VHDL

[§ 11.1]

procedure_call ::= procedure_name [ ( actual_parameter_part ) ]

[§ 8.6]

procedure_call_statement ::= [ label : ] procedure_call ;

[§ 8.6]

process_declarative_item ::=
subprogram_declaration
| subprogram_body
| type_declaration
| subtype_declaration
| constant_declaration
| variable_declaration
| ﬁle_declaration
| alias_declaration
| attribute_declaration
| attribute_speciﬁcation
| use_clause
| group_template_declaration
| group_declaration

[§ 9.2]

process_declarative_part ::=
{ process_declarative_item }

[§ 9.2]

process_statement ::=
[ process_label : ]
[ postponed ] process [ ( sensitivity_list ) ] [ is ]
process_declarative_part
begin
process_statement_part
end [ postponed ] process [ process_label ] ;

[§ 9.2]

process_statement_part ::=
{ sequential_statement }

[§ 9.2]

protected_type_body ::=
protected body
protected_type_body_declarative_part
end protected body [ protected_type_simple name ]

[§ 3.5.2]

226

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

protected_type_body_declarative_item ::=
subprogram_declaration
| subprogram_body
| type_declaration
| subtype_declaration
| constant_declaration
| variable_declaration
| ﬁle_declaration
| alias_declaration
| attribute_declaration
| attribute_speciﬁcation
| use_clause
| group_template_declaration
| group_declaration

[§ 3.5.2]

protected_type_body_declarative_part ::=
{ protected_type_body_declarative_item }

[§ 3.5.2]

protected_type_declaration ::=
protected
protected_type_declarative_part
end protected [ protected_type_simple_name ]

[§ 3.5.1]

protected_type_declarative_item ::=
subprogram_speciﬁcation
| attribute_speciﬁcation
| use_clause

[§ 3.5.1]

protected_type_declarative_part ::=
{ protected_type_declarative_item }

[§ 3.5.1]

protected_type_deﬁnition ::=
protected_type_declaration
| protected_type_body
qualiﬁed_expression ::=
type_mark ' ( expression )
| type_mark ' aggregate

[§ 3.5]

[§ 7.3.4]

range ::=
range_attribute_name
| simple_expression direction simple_expression

[§ 3.1]

range_constraint ::= range range

[§ 3.1]

record_type_deﬁnition ::=
record
element_declaration
{ element_declaration }
end record [ record_type_simple_name ]

[§ 3.2.2]

relation ::=
shift_expression [ relational_operator shift_expression ]

[§ 7.1]

relational_operator ::= = | /= | < | <= | > | >=

[§ 7.2]

Copyright © 2000 IEEE. All rights reserved.

227

IEEE
Std 1076, 2000 Edition

report_statement ::=
[ label : ]
report expression
[ severity expression ] ;
return_statement ::=
[ label : ] return [ expression ] ;
scalar_type_deﬁnition ::=
enumeration_type_deﬁnition | integer_type_deﬁnition
| ﬂoating_type_deﬁnition
| physical_type_deﬁnition

IEEE STANDARD VHDL

[§ 8.3]

[§ 8.12]

[§ 3.1]

secondary_unit ::=
architecture_body
| package_body

[§ 11.1]

secondary_unit_declaration ::= identiﬁer = physical_literal ;

[§ 3.1.3]

selected_name ::= preﬁx . sufﬁx

[§ 6.3]

selected_signal_assignment ::=
with expression select
target <= options selected_waveforms ;

[§ 9.5.2]

selected_waveforms ::=
{ waveform when choices , }
waveform when choices

[§ 9.5.2]

sensitivity_clause ::= on sensitivity_list

[§ 8.1]

sensitivity_list ::= signal_name { , signal_name }

[§ 8.1]

sequence_of_statements ::=
{ sequential_statement }

[§ 8]

sequential_statement ::=
wait_statement
| assertion_statement
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

[§ 8]

shift_expression ::=
simple_expression [ shift_operator simple_expression ]
shift_operator ::= sll | srl | sla | sra | rol | ror

228

[§ 7.1]
[§ 7.2]

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

sign ::= + | –

[§ 7.2]

signal_assignment_statement ::=
[ label : ] target <= [ delay_mechanism ] waveform ;

[§ 8.4]

signal_declaration ::=
signal identiﬁer_list : subtype_indication [ signal_kind ] [ := expression ] ;

[§ 4.3.1.2]

signal_kind ::= register | bus

[§ 4.3.1.2]

signal_list ::=
signal_name { , signal_name }
| others
| all
signature ::= [ [ type_mark { , type_mark } ] [ return type_mark ] ]

[§ 5.3]

[§ 2.3.2]

simple_expression ::=
[ sign ] term { adding_operator term }

[§ 7.1]

simple_name ::= identiﬁer

[§ 6.2]

slice_name ::= preﬁx ( discrete_range )

[§ 6.5]

string_literal ::= “{ graphic_character } “ "

[§ 13.6]

subprogram_body ::=
subprogram_speciﬁcation is
subprogram_declarative_part
begin
subprogram_statement_part
end [ subprogram_kind ] [ designator ] ;

[§ 2.2]

subprogram_declaration ::=
subprogram_speciﬁcation ;

[§ 2.1]

subprogram_declarative_item ::=
subprogram_declaration
| subprogram_body
| type_declaration
| subtype_declaration
| constant_declaration
| variable_declaration
| ﬁle_declaration
| alias_declaration
| attribute_declaration
| attribute_speciﬁcation
| use_clause
| group_template_declaration
| group_declaration

[§ 2.2]

Copyright © 2000 IEEE. All rights reserved.

229

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

subprogram_declarative_part ::=
{ subprogram_declarative_item }

[§ 2.2]

subprogram_kind ::= procedure | function

[§ 2.2]

subprogram_speciﬁcation ::=
procedure designator [ ( formal_parameter_list ) ]
| [ pure | impure ] function designator [ ( formal_parameter_list ) ]
return type_mark

[§ 2.1]

subprogram_statement_part ::=
{ sequential_statement }

[§ 2.2]

subtype_declaration ::=
subtype identiﬁer is subtype_indication ;

[§ 4.2]

subtype_indication ::=
[ resolution_function_name ] type_mark [ constraint ]

[§ 4.2]

sufﬁx ::=
simple_name
| character_literal
| operator_symbol
| all

[§ 6.3]

target ::=
name
| aggregate

[§ 8.4]

term ::=
factor { multiplying_operator factor }

[§ 7.1]

timeout_clause ::= for time_expression

[§ 8.1]

type_conversion ::= type_mark ( expression )

[§ 7.3.5]

type_declaration ::=
full_type_declaration
| incomplete_type_declaration

[§ 4.1]

type_deﬁnition ::=
scalar_type_deﬁnition
| composite_type_deﬁnition
| access_type_deﬁnition
| ﬁle_type_deﬁnition
| protected_type_deﬁnition

[§ 4.1]

type_mark ::=
type_name
| subtype_name

[§ 4.2]

unconstrained_array_deﬁnition ::=
array ( index_subtype_deﬁnition { , index_subtype_deﬁnition } )
of element_subtype_indication

230

[§ 3.2.1]

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

use_clause ::=
use selected_name { , selected_name } ;
variable_assignment_statement ::=
[ label : ] target := expression ;
variable_declaration ::=
[ shared ] variable identiﬁer_list : subtype_indication [ := expression ] ;

IEEE
Std 1076, 2000 Edition

[§ 10.4]

[§ 8.5]

[§ 4.3.1.3]

wait_statement ::=
[ label : ] wait [ sensitivity_clause ] [ condition_clause ] [ timeout_clause ] ;

[§ 8.1]

waveform ::=
waveform_element { , waveform_element }
| unaffected

[§ 8.4]

waveform_element ::=
value_expression [after time_expression]
| null [after time_expression]

Copyright © 2000 IEEE. All rights reserved.

[§ 8.4.1]

231

IEEE
Std 1076, 2000 Edition

232

IEEE STANDARD VHDL

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

Annex B
(informative)

Glossary
This glossary contains brief, informal descriptions for a number of terms and phrases used to deﬁne this
language. The complete, formal deﬁnition of each term or phrase is provided in the main body of the
standard.
For each entry, the relevant clause numbers in the text are given. Some descriptions refer to multiple clauses
in which the single concept is discussed; for these, the clause number containing the deﬁnition of the
concept is given in italics. Other descriptions contain multiple clause numbers when they refer to multiple
concepts; for these, none of the clause numbers are italicized.
B.1 abstract literal: A literal of the universal_real abstract type or the universal_integer abstract type.
(§13.2, §13.4)
B.2 access mode: The mode in which a ﬁle object is opened, which can be either read-only or write-only.
The access mode depends on the value supplied to the Open_Kind parameter. (§3.4.1, §14.3)
B.3 access type: A type that provides access to an object of a given type. Access to such an object is
achieved by an access value returned by an allocator; the access value is said to designate the object.
(§3, §3.3)
B.4 access value: A value of an access type. This value is returned by an allocator and designates an object
(which must be a variable) of a given type. A null access value designates no object. An access value can
only designate an object created by an allocator; it cannot designate an object declared by an object
declaration. (§3, §3.3)
B.5 active driver: A driver that acquires a new value during a simulation cycle regardless of whether the
new value is different from the previous value. (§12.6.2, §12.6.4)
B.6 actual: An expression, a port, a signal, or a variable associated with a formal port, formal parameter, or
formal generic. (§1.1.1.1, §1.1.1.2, §3.2.1.1, §4.3.1.2, §4.3.2.2, §5.2.1, §5.2.1.2)
B.7 aggregate: (A) The kind of expression, denoting a value of a composite type. The value is speciﬁed by
giving the value of each of the elements of the composite type. Either a positional association or a named
association may be used to indicate which value is associated with which element. (B) A kind of target of a
variable assignment statement or signal assignment statement assigning a composite value. The target is then
said to be in the form of an aggregate. (§7.3.1, §7.3.2. §7.3.4, §7.3.5, §7.5.2)
B.8 alias: An alternate name for a named entity. (§4.3.3)
B.9 allocator: An operation used to create anonymous, variable objects accessible by means of access
values. (§3.3, §7.3.6)
B.10 analysis: The syntactic and semantic analysis of source code in a VHDL design ﬁle and the insertion of
intermediate form representations of design units into a design library. (§11.1, §11.2, §11.4)

Copyright © 2000 IEEE. All rights reserved.

233

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

B.11 anonymous: The undeﬁned simple name of an item, which is created implicitly. The base type of a
numeric type or an array type is anonymous; similarly, the object denoted by an access value is anonymous.
(§4.1)
B.12 appropriate: A preﬁx is said to be appropriate for a type if the type of the preﬁx is the type considered,
or if the type of the preﬁx is an access type whose designated type is the type considered. (§6.1)
B.13 architecture body: A body associated with an entity declaration to describe the internal organization
or operation of a design entity. An architecture body is used to describe the behavior, data ﬂow, or structure
of a design entity. (§1, §1.2)
B.14 array object: An object of an array type. (§3)
B.15 array type: A type, the value of which consists of elements that are all of the same subtype (and hence,
of the same type). Each element is uniquely distinguished by an index (for a one-dimensional array) or by a
sequence of indexes (for a multidimensional array). Each index must be a value of a discrete type and must
lie in the correct index range. (§3.2.1)
B.16 ascending range: A range L to R. (§3.1)
B.17 ASCII: The American Standard Code for Information Interchange. The package Standard contains the
deﬁnition of the type character, the ﬁrst 128 values of which represent the ASCII character set. (§3.1.1,
§14.2)
B.18 assertion violation: A violation that occurs when the condition of an assertion statement evaluates to
false. (§8.2)
B.19 associated driver: The single driver for a signal in the (explicit or equivalent) process statement
containing the signal assignment statement. (§12.6.1)
B.20 associated individually: A property of a formal port, generic, or parameter of a composite type with
respect to some association list. A composite formal whose association is deﬁned by multiple association
elements in a single association list is said to be associated individually in that list. The formats of such
association elements must denote non-overlapping subelements or slices of the formal. (§4.3.2.2)
B.21 associated in whole: When a single association element of a composite formal supplies the association
for the entire formal. (§4.3.2.2)
B.22 association element: An element that associates an actual or local with a local or formal. (§4.3.2.2)
B.23 association list: A list that establishes correspondences between formal or local port or parameter
names and local or actual names or expressions. (§4.3.2.2)
B.24 attribute: A deﬁnition of some characteristic of a named entity. Some attributes are predeﬁned for
types, ranges, values, signals, and functions. The remaining attributes are user deﬁned and are always
constants. (§4.4)
B.25 augmentation set: A set of characteristic expressions, each corresponding to some quantity or the
scalar subelement thereof, used to determine an analog solution point. (§12.6.5)
B.26 base speciﬁer: A lexical element that indicates whether a bit string literal is to be interpreted as a
binary, octal, or hexadecimal value. (§13.7)

234

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

B.27 base type: The type from which a subtype deﬁnes a subset of possible values, otherwise known as a
constraint. This subset is not required to be proper. The base type of a type is the type itself. The base type of
a subtype is found by recursively examining the type mark in the subtype indication deﬁning the subtype. If
the type mark denotes a type, that type is the base type of the subtype; otherwise, the type mark is a subtype,
and this procedure is repeated on that subtype. (§3) See also: subtype.
B.28 based literal: An abstract literal expressed in a form that speciﬁes the base explicitly. The base is
restricted to the range 2 to 16. (§13.4.2)
B.29 basic operation: An operation that is inherent in one of the following:
—
—
—
—

—

An assignment (in an assignment statement or initialization)
An allocator
A selected name, an indexed name, or a slice name
A qualiﬁcation (in a qualiﬁed expression), an explicit type conversion, a formal or actual designator
in the form of a type conversion, or an implicit type conversion of a value of type universal_integer
or universal_real to the corresponding value of another numeric type, or
A numeric literal (for a universal type), the literal null (for an access type), a string literal, a bit string
literal, an aggregate, or a predeﬁned attribute. (§3)

B.30 basic signal: A signal that determines the driving values for all other signals. A basic signal is
— Either a scalar signal or a resolved signal
— Not a subelement of a resolved signal
— Not an implicit signal of the form S'Stable(T), S'Quiet(T), or S'Transaction, and
— Not an implicit signal GUARD. (§12.6.2)
B.31 belong (A) (to a range): A property of a value with respect to some range. The value V is said to
belong to a range if the relations (lower bound <= V) and (V <= upper bound) are both true, where lower
bound and upper bound are the lower and upper bounds, respectively, of the range. (§3.1, §3.2.1) (B) (to a
subtype): A property of a value with respect to some subtype. A value is said to belong to a subtype of a
given type if it belongs to the type and satisﬁes the applicable constraint. (§3, §3.2.1)
B.32 binding: The process of associating a design entity and, optionally, an architecture with an instance of
a component. A binding can be speciﬁed in an explicit or a default binding indication. (§1.3, §5.2.1, §5.2.2,
§12.3.2.2, §12.4.3)
B.33 bit string literal: A literal formed by a sequence of extended digits enclosed between two quotation (")
characters and preceded by a base speciﬁer. The type of a bit string literal is determined from the context.
(§7.3.1, §13.7)
B.34 block:
a) The representation of a portion of the hierarchy of a design. A block is either an external block or an
internal block. (§1, §1.1.1.1, §1.1.1.2, §1.2.1, §1.3, §1.3.1, §1.3.2)
b) The act of suspending the execution of a process for the purposes of guaranteeing exclusive access to
an object of a protected type. (§12.5)
B.35 bound: A label that is identiﬁed in the instantiation list of a conﬁguration speciﬁcation. (§5.2)
B.36 box: The symbol <> in an index subtype deﬁnition, which stands for an undeﬁned range. Different
objects of the type need not have the same bounds and direction. (§3.2.1)

Copyright © 2000 IEEE. All rights reserved.

235

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

B.37 bus: One kind of guarded signal. A bus ﬂoats to a user-speciﬁed value when all of its drivers are turned
off. (§4.3.1.2, §4.3.2)
B.38 character literal: A literal of the character type. Character literals are formed by enclosing one of the
graphic characters (including the space and nonbreaking space characters) between two apostrophe (')
characters. (§13.2, §13.5)
B.39 character type: An enumeration type with at least one of its enumeration literals as a character literal.
(§3.1.1, §3.1.1.1)
B.40 closely related types: Two type marks that denote the same type or two numeric types. Two array
types may also be closely related if they have the same dimensionality, if their index types at each position
are closely related, and if the array types have the same element types. Explicit type conversion is only
allowed between closely related types. (§7.3.5)
B.41 complete: A loop that has ﬁnished executing. Similarly, an iteration scheme of a loop is complete when
the condition of a while iteration scheme is FALSE or all of the values of the discrete range of a for iteration
scheme have been assigned to the iteration parameter. (§8.9)
B.42 complete context: A declaration, a speciﬁcation, or a statement; complete contexts are used in
overload resolution. (§10.5)
B.43 composite type: A type whose values have elements. There are two classes of composite types: array
types and record types. (§3, §3.2)
B.44 concurrent statement: A statement that executes asynchronously, with no deﬁned relative order.
Concurrent statements are used for dataﬂow and structural descriptions. (§9)
B.45 conﬁguration: A construct that deﬁnes how component instances in a given block are bound to design
entities in order to describe how design entities are put together to form a complete design. (§1, §1.3. §5.2)
B.46 conform: Two subprogram speciﬁcations, are said to conform if, apart from certain allowed minor
variations, both speciﬁcations are formed by the same sequence of lexical elements, and corresponding
lexical elements are given the same meaning by the visibility rules. Conformance is deﬁned similarly for
deferred constant declarations. (§2.7)
B.47 connected: A formal port associated with an actual port or signal. A formal port associated with the
reserved word open is said to be unconnected. (§1.1.1.2)
B.48 constant: An object whose value may not be changed. Constants may be explicitly declared, subelements of explicitly declared constants, or interface constants. Constants declared in packages may also be
deferred constants. (§4.3.1.1)
B.49 constraint: A subset of the values of a type. The set of possible values for an object of a given type that
can be subjected to a condition is called a constraint. A value is said to satisfy the constraint if it satisﬁes the
corresponding condition. There are index constraints, range constraints, and size constraints. (§3)
B.50 conversion function: A function used to convert values ﬂowing through associations. For interface
objects of mode in, conversion functions are allowed only on actuals. For interface objects of mode out or
buffer, conversion functions are allowed only on formals. For interface objects of mode inout or linkage,
conversion functions are allowed on both formals and actuals. Conversion functions have a single parameter.
A conversion function associated with an actual accepts the type of the actual and returns the type of the
formal. A conversion function associated with a formal accepts the type of the formal and returns the type of
the actual. (§4.3.2.2)

236

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

B.51 convertible: A property of an operand with respect to some type. An operand is convertible to some
type if there exists an implicit conversion to that type. (§7.3.5)
B.52 current value: The value component of the single transaction of a driver whose time component is not
greater than the current simulation time. (§12.6, §12.6.1, §12.6.2. §12.6.3)
B.53 cycle pure: An expression is cycle pure if its value does not change when evaluated, repeatedly, within
a given analog solution point with identical values for all its quantities. (§12.6, §12.6.1, §12.6.2. §12.6.3)
B.54 decimal literal: An abstract literal that is expressed in decimal notation. The base of the literal is
implicitly 10. The literal may optionally contain an exponent or a decimal point and fractional part. (§13.4.1)
B.55 declaration: A construct that deﬁnes a declared entity and associates an identiﬁer (or some other notation) with it. This association is in effect within a region of text that is called the scope of the declaration.
Within the scope of a declaration, there are places where it is possible to use the identiﬁer to refer to the
associated declared entity; at such places, the identiﬁer is said to be the simple name of the named entity. The
simple name is said to denote the associated named entity. (§4)
B.56 declarative part: A syntactic component of certain declarations or statements (such as entity declarations, architecture bodies, and block statements). The declarative part deﬁnes the lexical area (usually
introduced by a keyword such as is and terminated with another keyword such as begin) within which
declarations may occur. (§1.1.2, §1.2.1, §1.3, §2.6, §9.1, §9.2, §9.6.1, §9.6.2)
B.57 declarative region: A semantic component of certain declarations or statements. A declarative region
may include disjoint parts, such as the declarative region of an entity declaration, which extends to the end of
any architecture body for that entity. (§10.1)
B.58 decorate: To associate a user-deﬁned attribute with a named entity and to deﬁne the value of that
attribute. (§5.1)
B.59 default expression: A default value that is used for a formal generic, port, or parameter if the interface
object is unassociated. A default expression is also used to provide an initial value for signals and their
drivers. (§4.3.1.2, §4.3.2.2)
B.60 deferred constant: A constant that is declared without an assignment symbol (:=) and expression in a
package declaration. A corresponding full declaration of the constant must exist in the package body to
deﬁne the value of the constant. (§4.3.1.1)
B.61 delta cycle: A simulation cycle in which the simulation time at the beginning of the cycle is the same
as at the end of the cycle. That is, simulation time is not advanced in a delta cycle. Only nonpostponed
processes can be executed during a delta cycle. (§12.6.4)
B.62 denote: A property of the identiﬁer given in a declaration. Where the declaration is visible, the identiﬁer given in the declaration is said to denote the named entity declared in the declaration. (§4)
B.63 depend: (A) (on a library unit): A design unit that explicitly or implicitly mentions other library units
in a use clause. These dependencies affect the allowed order of analysis of design units. (§11.4) (B) (on a
signal value): A property of an implicit signal with respect to some other signal. The current value of an
implicit signal R is said to depend on the current value of another signal S if R denotes an implicit signal
S'Stable(T), S'Quiet(T), or S'Transaction, or if R denotes an implicit GUARD signal and S is any other
implicit signal named within the guard expression that deﬁnes the current value of R. (§12.6.3)
B.64 descending range: A range L downto R. (§3.1)

Copyright © 2000 IEEE. All rights reserved.

237

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

B.65 design entity: An entity declaration together with an associated architecture body. Different design
entities may share the same entity declaration, thus describing different components with the same interface
or different views of the same component. (§1)
B.66 design ﬁle: One or more design units in sequence. (§11.1)
B.67 design hierarchy: The complete representation of a design that results from the successive decomposition of a design entity into subcomponents and binding of those components to other design entities that may
be decomposed in a similar manner. (§1)
B.68 design library: A host-dependent storage facility for intermediate-form representations of analyzed
design units. (§11.2)
B.69 design unit: A construct that can be independently analyzed and stored in a design library. A design
unit may be an entity declaration, an architecture body, a conﬁguration declaration, a package declaration, or
a package body declaration. (§11.1)
B.70 designate: A property of access values that relates the value to some object when the access value is
nonnull. A nonnull access value is said to designate an object. (§3.3)
B.71 designated type: For an access type, the base type of the subtype deﬁned by the subtype indication of
the access type deﬁnition. (§3.3)
B.72 designated subtype: For an access type, the subtype deﬁned by the subtype indication of the access
type deﬁnition. (§3.3)
B.73 designator: (A) Syntax that forms part of an association element. A formal designator speciﬁes which
formal parameter, port, or generic (or which subelement or slice of a parameter, port, or generic) is to be
associated with an actual by the given association element. An actual designator speciﬁes which actual
expression, signal, or variable is to be associated with a formal (or subelement or subelements of a formal).
An actual designator may also specify that the formal in the given association element is to be left unassociated (with an actual designator of open). (§4.3.2.2) (B) An identiﬁer, character literal, or operator symbol that
deﬁnes an alias for some other name. (§4.3.3) (C) A simple name that denotes a predeﬁned or user-deﬁned
attribute in an attribute name, or a user-deﬁned attribute in an attribute speciﬁcation. (§5.1, §6.6) (D) A simple
name, character literal, or operator symbol, and possibly a signature, that denotes a named entity in the entity
name list of an attribute speciﬁcation. (§5.1) (E) An identiﬁer or operator symbol that deﬁnes the name of a
subprogram. (§2.1)
B.74 directly visible: A visible declaration that is not visible by selection. A declaration is directly visible
within its immediate scope, excluding any places where the declaration is hidden. A declaration occurring
immediately within the visible part of a package can be made directly visible by means of a use clause.
(§10.3, §10.4) See also: visible.
B.75 discrete array: A one-dimensional array whose elements are of a discrete type. (§7.2.3)
B.76 discrete range: A range whose bounds are of a discrete type. (§3.2.1, §3.2.1.1)
B.77 discrete type: An enumeration type or an integer type. Each value of a discrete type has a position
number that is an integer value. Indexing and iteration rules use values of discrete types. (§3.1)
B.78 driver: A container for a projected output waveform of a signal. The value of the signal is a function of
the current values of its drivers. Each process that assigns to a given signal implicitly contains a driver for
that signal. A signal assignment statement affects only the associated driver(s). (§12.4.4, §12.6.1, §12.6.2,
§12.6.3)

238

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

B.79 driving value: The value a signal provides as a source of other signals. (§12.6.2)
B.80 effective value: The value obtained by evaluating a reference to the signal within an expression.
(§12.6.2)
B.81 elaboration: The process by which a declaration achieves its effect. Prior to the completion of its
elaboration (including before the elaboration), a declaration is not yet elaborated. (§12)
B.82 element: A constituent of a composite type. (§3) See also: subelement.
B.83 entity declaration: A deﬁnition of the interface between a given design entity and the environment in
which it is used. It may also specify declarations and statements that are part of the design entity. A given
entity declaration may be shared by many design entities, each of which has a different architecture. Thus,
an entity declaration can potentially represent a class of design entities, each with the same interface. (§1,
§1.1)
B.84 enumeration literal: A literal of an enumeration type. An enumeration literal may be either an identiﬁer or a character literal. (§3.1.1, §7.3.1)
B.85 enumeration type: A type whose values are deﬁned by listing (enumerating) them. The values of the
type are represented by enumeration literals. (§3.1, §3.1.1)
B.86 erroneous: An error condition that cannot always be detected. (§2.1.1.1, §2.2)
B.87 error: A condition that makes the source description illegal. If an error is detected at the time of analysis of a design unit, it prevents the creation of a library unit for the given design unit. A run-time error causes
simulation to terminate. (§11.4)
B.88 event: A change in the current value of a signal, which occurs when the signal is updated with its
effective value. (§12.6.2)
B.89 execute: (A) When ﬁrst the design hierarchy of a model is elaborated, then its nets are initialized, and
ﬁnally simulation proceeds with repetitive execution of the simulation cycle, during which processes are
executed and nets are updated. (B) When a process performs the actions speciﬁed by the algorithm described
in its statement part. (§12, §12.6)
B.90 expanded name: A selected name (in the syntactic sense) that denotes one or all of the primary units in
a library or any named entity within a primary unit. (§6.3, §8.1) See also: selected name.
B.91 explicit ancestor: The parent of the implicit signal that is deﬁned by the predeﬁned attributes
'DELAYED, 'QUIET, 'STABLE, or 'TRANSACTION. It is determined using the preﬁx of the attribute. If the
preﬁx denotes an explicit signal or a slice or subelement (or member thereof), then that is the explicit ancestor of the implicit signal. If the preﬁx is one of the implicit signals deﬁned by the predeﬁned attributes
'DELAYED, 'QUIET, 'STABLE, or 'TRANSACTION, this rule is applied recursively. If the preﬁx is an
implicit signal GUARD, the signal has no explicit ancestor. (§2.2)
B.92 explicit signal: A signal deﬁned by the predeﬁned attributes 'DELAYED, 'QUIET, 'STABLE, or
'TRANSACTION. (§2.2)
B.93 explicitly declared constant: A constant of a speciﬁed type that is declared by a constant declaration.
(§4.3.1.1)

Copyright © 2000 IEEE. All rights reserved.

239

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

B.94 explicitly declared object: An object of a speciﬁed type that is declared by an object declaration. An
object declaration is called a single-object declaration if its identiﬁer list has a single identiﬁer; it is called a
multiple-object declaration if the identiﬁer list has two or more identiﬁers. (§4.3, §4.3.1) See also:
implicitly declared object.
B.95 expression: A formula that deﬁnes the computation of a value. (§7.1)
B.96 extend: A property of source text forming a declarative region with disjoint parts. In a declarative
region with disjoint parts, if a portion of text is said to extend from some speciﬁc point of a declarative
region to the end of the region, then this portion is the corresponding subset of the declarative region (and
does not include intermediate declarative items between an interface declaration and a corresponding body
declaration). (§10.1)
B.97 extended digit: A lexical element that is either a digit or a letter. (§13.4.2)
B.98 external block: A top-level design entity that resides in a library and may be used as a component in
other designs. (§1)
B.99 ﬁle type: A type that provides access to objects containing a sequence of values of a given type. File
types are typically used to access ﬁles in the host system environment. The value of a ﬁle object is the
sequence of values contained in the host system ﬁle. (§3, §3.4)
B.100 ﬂoating point types: A discrete scalar type whose values approximate real numbers. The representation of a ﬂoating point type includes a minimum of six decimal digits of precision. (§3.1, §3.1.4)
B.101 foreign subprogram: A subprogram that is decorated with the attribute 'FOREIGN, deﬁned in package STANDARD. The STRING value of the attribute may specify implementation-dependent information
about the foreign subprogram. Foreign subprograms may have non-VHDL implementations. An implementation may place restrictions on the allowable modes, classes, and types of the formal parameters to a foreign
subprogram, such as constraints on the number and allowable order of the parameters. (§2.2)
B.102 formal: A formal port or formal generic of a design entity, a block statement, or a formal parameter of
a subprogram. (§2.1.1, §4.3.2.2, §5.2.1.2, §9.1)
B.103 full declaration: A constant declaration occurring in a package body with the same identiﬁer as that
of a deferred constant declaration in the corresponding package declaration. A full type declaration is a type
declaration corresponding to an incomplete type declaration. (§2.6)
B.104 fully bound: A binding indication for the component instance implies an entity interface and an
architecture. (§5.2.1.1)
B.105 generate parameter: A constant object whose type is the base type of the discrete range of a generate
parameter speciﬁcation. A generate parameter is declared by a generate statement. (§9.7)
B.106 generic: An interface constant declared in the block header of a block statement, a component
declaration, or an entity declaration. Generics provide a channel for static information to be communicated
to a block from its environment. Unlike constants, however, the value of a generic can be supplied externally,
either in a component instantiation statement or in a conﬁguration speciﬁcation. (§1.1.1.1)
B.107 generic interface list: A list that deﬁnes local or formal generic constants. (§1.1.1.1, §4.3.2.1)
B.108 globally static expression: An expression that can be evaluated as soon as the design hierarchy in
which it appears is elaborated. A locally static expression is also globally static unless the expression appears
in a dynamically elaborated context. (§7.4)

240

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

B.109 globally static primary: A primary whose value can be determined during the elaboration of its
complete context and that does not thereafter change. Globally static primaries can only appear within statically elaborated contexts. (§7.4.2)
B.110 group: A named collection of named entities. Groups relate different named entities for the purposes
not speciﬁed by the language. In particular, groups may be decorated with attributes. (§4.6, §4.7)
B.111 guard: See: guard expression.
B.112 guard expression: A Boolean-valued expression associated with a block statement that controls
assignments to guarded signals within the block. A guard expression deﬁnes an implicit signal GUARD that
may be used to control the operation of certain statements within the block. (§4.3.1.2, §9.1, §9.5)
B.113 guarded assignment: A concurrent signal assignment statement that includes the option guarded,
which speciﬁes that the signal assignment statement is executed when a signal GUARD changes from
FALSE to TRUE, or when that signal has been TRUE and an event occurs on one of the signals referenced in
the corresponding GUARD expression. The signal GUARD may be one of the implicitly declared GUARD
signals associated with block statements that have guard expressions, or it may be an explicitly declared
signal of type Boolean that is visible at the point of the concurrent signal assignment statement. (§9.5)
B.114 guarded signal: A signal declared as a register or a bus. Such signals have special semantics when
their drivers are updated from within guarded signal assignment statements. (§4.3.1.2)
B.115 guarded target: A signal assignment target consisting only of guarded signals. An unguarded target
is a target consisting only of unguarded signals. (§9.5)
B.116 hidden: A declaration that is not directly visible. A declaration may be hidden in its scope by a
homograph of the declaration. (§10.3)
B.117 homograph: A reﬂexive property of two declarations. Each of two declarations is said to be a
homograph of the other if both declarations have the same identiﬁer and overloading is allowed for at most
one of the two. If overloading is allowed for both declarations, then each of the two is a homograph of the
other if they have the same identiﬁer, operator symbol, or character literal, as well as the same parameter and
result type proﬁle. (§1.3.1, §10.3)
B.118 identify: A property of a name appearing in an element association of an assignment target in the
form of an aggregate. The name is said to identify a signal or variable and any subelements of that signal or
variable. (§8.4, 8.5)
B.119 immediate scope: A property of a declaration with respect to the declarative region within which the
declaration immediately occurs. The immediate scope of the declaration extends from the beginning of the
declaration to the end of the declarative region. (§10.2)
B.120 immediately within: A property of a declaration with respect to some declarative region. A declaration is said to occur immediately within a declarative region if this region is the innermost region that
encloses the declaration, not counting the declarative region (if any) associated with the declaration itself.
(§10.1)
B.121 implicit signal: Any signal S'Stable(T), S'Quiet(T), S'Delayed, or S'Transaction, or any implicit
GUARD signal. A slice or subelement (or slice thereof) of an implicit signal is also an implicit signal.
(§12.6.2, §12.6.3, §12.6.4)

Copyright © 2000 IEEE. All rights reserved.

241

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

B.122 implicitly declared object: An object whose declaration is not explicit in the source description, but
is a consequence of other constructs; for example, signal GUARD. (§4.3, §9.1, §14.1) See also: declared
object.
B.123 imply: A property of a binding indication in a conﬁguration speciﬁcation with respect to the design
entity indicated by the binding speciﬁcation. The binding indication is said to imply the design entity; the
design entity maybe indicated directly, indirectly, or by default. (§5.2.1.1)
B.124 impure function: A function that may return a different value each time it is called, even when different calls have the same actual parameter values. A pure function returns the same value each time it is called
using the same values as actual parameters. An impure function can update objects outside of its scope and
can access a broader class of values than a pure function. (§2)
B.125 incomplete type declaration: A type declaration that is used to deﬁne mutually dependent and
recursive access types. (§3.3.1)
B.126 index constraint: A constraint that determines the index range for every index of an array type, and
thereby the bounds of the array. An index constraint is compatible with an array type if and only if the
constraint deﬁned by each discrete range in the index constraint is compatible with the corresponding index
subtype in the array type. An array value satisﬁes an index constraint if the array value and the index
constraint have the same index range at each index position. (§3.1, §3.2.1.1)
B.127 index range: A multidimensional array has a distinct element for each possible sequence of index
values that can be formed by selecting one value for each index (in the given order). The possible values for
a given index are all the values that belong to the corresponding range. This range of values is called the
index range. (§3.2.1)
B.128 index subtype: For a given index position of an array, the index subtype is denoted by the type mark
of the corresponding index subtype deﬁnition. (§3.2.1)
B.129 inertial delay: A delay model used for switching circuits; a pulse whose duration is shorter than the
switching time of the circuit will not be transmitted. Inertial delay is the default delay mode for signal
assignment statements. (§8.4) See also: transport delay.
B.130 initial value expression: An expression that speciﬁes the initial value to be assigned to a variable.
(§4.3.1.3)
B.131 inputs: The signals identiﬁed by the longest static preﬁx of each signal name appearing as a primary
in each expression (other than time expressions) within a concurrent signal assignment statement. (§9.5)
B.132 instance: A subcomponent of a design entity whose prototype is a component declaration, design
entity, or conﬁguration declaration. Each instance of a component may have different actuals associated with
its local ports and generics. A component instantiation statement whose instantiated unit denotes a component creates an instance of the corresponding component. A component instantiation statement whose
instantiated unit denotes either a design entity or a conﬁguration declaration creates an instance of the
denoted design entity. (§9.6, §9.6.1, §9.6.2)
B.133 integer literal: An abstract literal of the type universal_integer that does not contain a base point.
(§13.4)
B.134 integer type: A discrete scalar type whose values represent integer numbers within a speciﬁed range.
(§3.1, §3.1.2)

242

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

B.135 interface list: A list that declares the interface objects required by a subprogram, component, design
entity, or block statement. (§4.3.2.1)
B.136 internal block: A nested block in a design unit, as deﬁned by a block statement. (§1)
B.137 ISO: The International Organization for Standardization.
B.138 ISO 8859-1: The ISO Latin-1 character set. Package Standard contains the deﬁnition of type
Character, which represents the ISO Latin-1 character set. (§3.1.1, §14.2)
B.139 kernel process: A conceptual representation of the agent that coordinates the activity of user-deﬁned
processes during a simulation. The kernel process causes the execution of I/O operations, the propagation of
signal values, and the updating of values of implicit signals [such as S'Stable(T)]; in addition, it detects
events that occur and causes the appropriate processes to execute in response to those events. (§12.6)
B.140 left of: When both a value V1 and a value V2 belong to a range and either the range is an ascending
range and V2 is the successor of V1, or the range is a descending range and V2 is the predecessor of V1.
(§3.1)
B.141 left-to-right order: When each value in a list of values is to the left of the next value in the list within
that range, except for the last value in the list. (§3.1)
B.142 library: See: design library.
B.143 library unit: The representation in a design library of an analyzed design unit. (§11.1)
B.144 literal: A value that is directly speciﬁed in the description of a design. A literal can be a bit string
literal, enumeration literal, numeric literal, string literal, or the literal null. (§7.3.1)
B.145 local generic: An interface object declared in a component declaration that serves to connect a formal
generic in the interface list of an entity and an actual generic or value in the design unit instantiating that
entity. (§4.3, §4.3.2.2, §4.5)
B.146 local port: A signal declared in the interface list of a component declaration that serves to connect a
formal port in the interface list of an entity and an actual port or signal in the design unit instantiating that
entity. (§4.3, §4.3.2.2, §4.5)
B.147 locally static expression: An expression that can be evaluated during the analysis of the design unit
in which it appears. (§7.4, §7.4.1)
B.148 locally static name: A name in which every expression is locally static (if every discrete range that
appears as part of the name denotes a locally static range or subtype and if no preﬁx within the name is either
an object or value of an access type or a function call). (§6.1)
B.149 locally static primary: One of a certain group of primaries that includes literals, certain constants,
and certain attributes. (§7.4)
B.150 locally static subtype: A subtype whose bounds and direction can be determined during the analysis
of the design unit in which it appears. (§7.4.1)
B.151 longest static preﬁx: The name of a signal or a variable name, if the name is a static signal or variable
name. Otherwise, the longest static preﬁx is the longest preﬁx of the name that is a static signal or variable
name. (§6.1) See also: static signal name.

Copyright © 2000 IEEE. All rights reserved.

243

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

B.152 loop parameter: A constant, implicitly declared by the for clause of a loop statement, used to count
the number of iterations of a loop. (§8.9)
B.153 lower bound: For a range L to R or L downto R, the smaller of L and R. (§3.1)
B.154 match: A property of a signature with respect to the parameter and subtype proﬁle of a subprogram or
enumeration literal. The signature is said to match the parameter and result type proﬁle if certain conditions
are true. (§2.3.2)
B.155 matching elements: Corresponding elements of two composite type values that are used for certain
logical and relational operations. (§7.2.3)
B.156 member: A slice of an object, a subelement, or an object; or a slice of a subelement of an object. (§3)
B.157 method: An abstract operation that operates atomically and exclusively on a single object of a
protected type. (§3.5.1)
B.158 mode: The direction of information ﬂow through the port or parameter. Modes are in, out, inout,
buffer, or linkage. (§4.3.2)
B.159 model: The result of the elaboration of a design hierarchy. The model can be executed in order to
simulate the design it represents. (§12, §12.6)
B.160 name: A property of an identiﬁer with respect to some named entity. Each form of declaration associates an identiﬁer with a named entity. In certain places within the scope of a declaration, it is valid to use the
identiﬁer to refer to the associated named entity; these places are deﬁned by the visibility rules. At such
places, the identiﬁer is said to be the name of the named entity. (§4, §6.1)
B.161 named association: An association element in which the formal designator appears explicitly.
(§4.3.2.2, §7.3.2)
B.162 named entity: An item associated with an identiﬁer, character literal, or operator symbol as the result
of an explicit or implicit declaration. (§4) See also: name.
B.163 net: A collection of drivers, signals (including ports and implicit signals), conversion functions, and
resolution functions that connect different processes. Initialization of a net occurs after elaboration, and a net
is updated during each simulation cycle. (§12, §12.1, §12.6.2)
B.164 nonobject alias: An alias whose designator denotes some named entity other than an object. (§4.3.3,
§4.3.3.2) See also: object alias.
B.165 nonpostponed process: An explicit or implicit process whose source statement does not contain the
reserved word postponed. When a nonpostponed process is resumed, it executes in the current simulation
cycle. Thus, nonpostponed processes have access to the current values of signals, whether or not those
values are stable at the current model time. (§ 9.2)
B.166 null array: Any of the discrete ranges in the index constraint of an array that deﬁne a null range.
(§3.2.1.1)
B.167 null range: A range that speciﬁes an empty subset of values. A range L to R is a null range if L > R,
and range L downto R is a null range if L < R. (§3.1)
B.168 null slice: A slice whose discrete range is a null range. (§6.5)

244

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

B.169 null transaction: A transaction produced by evaluating a null waveform element. (§8.4.1)
B.170 null waveform element: A waveform element that is used to turn off a driver of a guarded signal.
(§8.4.1)
B.171 numeric literal: An abstract literal, or a literal of a physical type. (§7.3.1)
B.172 numeric type: An integer type, a ﬂoating point type, or a physical type. (§3.1)
B.173 object: A named entity that has a value of a given type. An object can be a constant, signal, variable,
or ﬁle. (§4.3.3)
B.174 object alias: An alias whose alias designator denotes an object (that is, a constant, signal, variable, or
ﬁle). (§4.3.3, §4.3.3.1) See also: nonobject alias.
B.175 overloaded: Identiﬁers or enumeration literals that denote two different named entities. Enumeration
literals, subprograms, and predeﬁned operators may be overloaded. At any place where an overloaded
enumeration literal occurs in the text of a program, the type of the enumeration literal must be determinable
from the context. (§2.1, §2.3, §2.3.1, §2.3.2, §3.1.1)
B.176 parameter: A constant, signal, variable, or ﬁle declared in the interface list of a subprogram speciﬁcation. The characteristics of the class of objects to which a given parameter belongs are also characteristics
of the parameter. In addition, a parameter has an associated mode that speciﬁes the direction of data ﬂow
allowed through the parameter. (§2.1.1, §2.1.1.1, §2.1.1.2, §2.1.1.3, §2.3, §2.6)
B.177 parameter and result type proﬁle: Two subprograms that have the same parameter type proﬁle, and
either both are functions with the same result base type, or neither of the two is a function. (§2.3)
B.178 parameter interface list: An interface list that declares the parameters for a subprogram. It may
contain interface constant declarations, interface signal declarations, interface variable declarations,
interface ﬁle declarations, or any combination thereof. (§4.3.2.1)
B.179 parameter type proﬁle: Two formal parameter lists that have the same number of parameters, and at
each parameter position the corresponding parameters have the same base type. (§2.3)
B.180 parent: A process or a subprogram that contains a procedure call statement for a given procedure or
for a parent of the given procedure. (§2.2)
B.181 passive process: A process statement where neither the process itself, nor any procedure of which the
process is a parent, contains a signal assignment statement. (§9.2)
B.182 physical literal: A numeric literal of a physical type. (§3.1.3)
B.183 physical type: A numeric scalar type that is used to represent measurements of some quantity. Each
value of a physical type has a position number that is an integer value. Any value of a physical type is an
integral multiple of the primary unit of measurement for that type. (§3.1, §3.1.3)
B.184 port: A channel for dynamic communication between a block and its environment. A signal declared
in the interface list of an entity declaration, in the header of a block statement, or in the interface list of a
component declaration. In addition to the characteristics of signals, ports also have an associated mode; the
mode constrains the directions of data ﬂow allowed through the port. (§1.1.1.2, §4.3.1.2)
B.185 port interface list: An interface list that declares the inputs and outputs of a block, component, or
design entity. It consists entirely of interface signal declarations. (§1.1.1, §1.1.1.2, §4.3.2.1, §4.3.2.2, §9.1)

Copyright © 2000 IEEE. All rights reserved.

245

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

B.186 positional association: An association element that does not contain an explicit appearance of the
formal designator. An actual designator at a given position in an association list corresponds to the interface
element at the same position in the interface list. (§4.3.2.2, §7.3.2)
B.187 postponed process: An explicit or implicit process whose source statement contains the reserved
word postponed. When a postponed process is resumed, it does not execute until the ﬁnal simulation cycle at
the current modeled time. Thus, a postponed process accesses the values of signals that are the “stable”
values at the current simulated time. (§9.2)
B.188 predeﬁned operators: Implicitly deﬁned operators that operate on the predeﬁned types. Every
predeﬁned operator is a pure function. No predeﬁned operators have named formal parameters; therefore,
named association may not be used when invoking a predeﬁned operation. (§7.2, §14.2)
B.189 primary: One of the elements making up an expression. Each primary has a value and a type. (§7.1)
B.190 projected output waveform: A sequence of one or more transactions representing the current and
projected future values of the driver. (§12.6.1)
B.191 protected type: A type whose objects are protected from simultaneous access by more than one
process. (§3.5)
B.192 pulse rejection limit: The threshold time limit for which a signal value whose duration is greater than
the limit will be propagated. A pulse rejection limit is speciﬁed by the reserved word reject in an inertially
delayed signal assignment statement. (§8.4)
B.193 pure function: A function that returns the same value each time it is called with the same values as
actual parameters. An impure function may return a different value each time it is called, even when different
calls have the same actual parameter values. (§2.1)
B.194 quiet: In a given simulation cycle, a signal that is not active. (§12.6.2)
B.195 range: A speciﬁed subset of values of a scalar type. (§3.1) See also: ascending range; belong (to a
range); descending range; lower bound; upper bound.
B.196 range constraint: A construct that speciﬁes the range of values in a type. A range constraint is
compatible with a subtype if each bound of the range belongs to the subtype or if the range constraint deﬁnes
a null range. The direction of a range constraint is the same as the direction of its range. (§3.1, 3.1.2, §3.1.3,
§3.1.4)
B.197 read: The value of an object is said to be read when its value is referenced or when certain of its
attributes are referenced. (§4.3.2)
B.198 real literal: An abstract literal of the type universal_real that contains a base point. (§13.4)
B.199 record type: A composite type whose values consist of named elements. (§3.2.2, §7.3.2.1)
B.200 reference: Access to a named entity. Every appearance of a designator (a name, character literal, or
operator symbol) is a reference to the named entity denoted by the designator, unless the designator appears
in a library clause or use clause. (§10.4, §11.2)
B.201 register: A kind of guarded signal that retains its last driven value when all of its drivers are turned
off. (§4.3.1.2)

246

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

B.202 regular structure: Instances of one or more components arranged and interconnected (via signals) in
a repetitive way. Each instance may have characteristics that depend upon its position within the group of
instances. Regular structures may be represented through the use of the generate statement. (§9.7)
B.203 resolution: The process of determining the resolved value of a resolved signal based on the values of
multiple sources for that signal. (§2.4, §4.3.1.2)
B.204 resolution function: A user-deﬁned function that computes the resolved value of a resolved signal.
(§2.4, §4.3.1.2)
B.205 resolution limit: The primary unit of type TIME (by default, 1 femtosecond). Any TIME value whose
absolute value is smaller than this limit is truncated to zero (0) time units. (§3.1.3.1)
B.206 resolved signal: A signal that has an associated resolution function. (§4.3.1.2)
B.207 resolved value: The output of the resolution function associated with the resolved signal, which is
determined as a function of the collection of inputs from the multiple sources of the signal. (§2.4, §4.3.1.2)
B.208 resource library: A library containing library units that are referenced within the design unit being
analyzed. (§11.2)
B.209 result subtype: The subtype of the returned value of a function. (§2.1)
B.210 resume: The action of a wait statement upon an enclosing process when the conditions on which the
wait statement is waiting are satisﬁed. If the enclosing process is a nonpostponed process, the process will
subsequently execute during the current simulation cycle. Otherwise, the process is a postponed process,
which will execute during the ﬁnal simulation cycle at the current simulated time. (§12.6.3)
B.211 right of: When a value V1 and a value V2 belong to a range and either the range is an ascending range
and V2 is the predecessor of V1, or the range is a descending range and V2 is the successor of V1. (§14.1)
B.212 satisfy: A property of a value with respect to some constraint. The value is said to satisfy a constraint
if the value is in the subset of values determined by the constraint. (§3, §3.2.1.1)
B.213 scalar type: A type whose values have no elements. Scalar types consist of enumeration types,
integer types, physical types, and ﬂoating point types. Enumeration types and integer types are called
discrete types. Integer types, ﬂoating point types, and physical types are called numeric types. All scalar
types are ordered; that is, all relational operators are predeﬁned for their values. (§3, §3.1)
B.214 scope: A portion of the text in which a declaration may be visible. This portion is deﬁned by visibility
and overloading rules. (§10.2)
B.215 selected name: Syntactically, a name having a preﬁx and sufﬁx separated by a dot. Certain selected
names are used to denote record elements or objects denoted by an access value. The remaining selected
names are referred to as expanded names. (§6.3, §8.1) See also: expanded name.
B.216 sensitivity set: The set of signals to which a wait statement is sensitive. The sensitivity set is given
explicitly in an on clause, or is implied by an until clause. (§8.1)
B.217 sequential statements: Statements that execute in sequence in the order in which they appear.
Sequential statements are used for algorithmic descriptions. (§8)
B.218 shared variable: A variable accessible by more than one process. Such variables must be of a
protected type. (§4.3.1.3)

Copyright © 2000 IEEE. All rights reserved.

247

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

B.219 short-circuit operation: An operation for which the right operand is evaluated only if the left
operand has a certain value. The short-circuit operations are the predeﬁned logical operations and, or, nand,
and nor for operands of types BIT and BOOLEAN. (§7.2)
B.220 signal: An object with a past history of values. A signal may have multiple drivers, each with a current
value and projected future values. The term signal refers to objects declared by signal declarations or port
declarations. (§4.3.1.2)
B.221 signal transform: A sequential statement within a statement transform that determines which one of
the alternative waveforms, if any, is to be assigned to an output signal. A signal transform can be a sequential
signal assignment statement, an if statement, a case statement, or a null statement. (§9.5)
B.222 simple name: The identiﬁer associated with a named entity, either in its own declaration or in an alias
declaration. (§6:2)
B.223 simulation cycle: One iteration in the repetitive execution of the processes deﬁned by process statements in a model. The ﬁrst simulation cycle occurs after initialization. A simulation cycle can be a delta
cycle or a time-advance cycle. (§ 12.6.4)
B.224 single-object declaration: An object declaration whose identiﬁer list contains a single identiﬁer; it is
called a multiple-object declaration if the identiﬁer list contains two or more identiﬁers. (§4.3.1)
B.225 slice: A one-dimensional array of a sequence of consecutive elements of another one-dimensional
array. (§6.5)
B.226 source: A contributor to the value of a signal. A source can be a driver or port of a block with which a
signal is associated or a composite collection of sources. (§4.3.1.2)
B.227 speciﬁcation: A class of construct that associates additional information with a named entity. There
are three kinds of speciﬁcations: attribute speciﬁcations, conﬁguration speciﬁcations, and disconnection
speciﬁcations. (§5)
B.228 statement transform: The ﬁrst sequential statement in the process equivalent to the concurrent signal
assignment statement. The statement transform deﬁnes the actions of the concurrent signal assignment statement when it executes. The statement transform is followed by a wait statement, which is the ﬁnal statement
in the equivalent process. (§9.5)
B.229 static: See: locally static; globally static.
B.230 static name: A name in which every expression that appears as part of the name (for example, as an
index expression) is a static expression (if every discrete range that appears as part of the name denotes a
static range or subtype and if no preﬁx within the name is either an object or value of an access type or a
function call). (§6.1)
B.231 static range: A range whose bounds are static expressions. (§7.4)
B.232 static signal name: A static name that denotes a signal. (§6.1)
B.233 static variable name: A static name that denotes a variable. (§6.1)
B.234 string literal: A sequence of graphic characters, or possibly none, enclosed between two quotation
marks ("). The type of a string literal is determined from the context. (§7.3.1, §13.6)

248

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

B.235 subaggregate: An aggregate appearing as the expression in an element association within another,
multidimensional array aggregate. The subaggregate is an (n–1)-dimensional array aggregate, where n is the
dimensionality of the outer aggregate. Aggregates of multidimensional arrays are expressed in row-major
(right-most index varies fastest) order. (§7.3.2.2)
B.236 subelement: An element of another element. Where other subelements are excluded, the term element
is used. (§3)
B.237 subprogram speciﬁcation: Speciﬁes the designator of the subprogram, any formal parameters of the
subprogram, and the result type for a function subprogram. (§2.1)
B.238 subtype: A type together with a constraint. A value belongs to a subtype of a given type if it belongs
to the type and satisﬁes the constraint; the given type is called the base type of the subtype. A type is a
subtype of itself. Such a subtype is said to be unconstrained because it corresponds to a condition that
imposes no restriction. (§3)
B.239 suspend: A process that stops executing and waits for an event or for a time period to elapse.
(§12.6.4)
B.240 timeout interval: The maximum time a process will be suspended, as speciﬁed by the timeout period
in the until clause of a wait statement. (§8.1)
B.241 to the left of: See: left of.
B.242 to the right of: See: right of.
B.243 transaction: A pair consisting of a value and a time. The value represents a (current or) future value
of the driver; the time represents the relative delay before the value becomes the current value. (§12.6.1)
B.244 transport delay: An optional delay model for signal assignment. Transport delay is characteristic of
hardware devices (such as transmission lines) that exhibit nearly inﬁnite frequency response: any pulse is
transmitted, no matter how short its duration. (§8.4) See also: inertial delay.
B.245 type: A set of values and a set of operations. (§3)
B.246 type conversion: An expression that converts the value of a subexpression from one type to the designated type of the type conversion. Associations in the form of a type conversion are also allowed. These
associations have functions and restrictions similar to conversion functions but can be used in places where
conversion functions cannot. In both cases (expressions and associations), the converted type must be
closely related to the designated type. (§4.3.2.2, §7.3.5) See also: closely related types; conversion
function.
B.247 unaffected: A waveform in a concurrent signal assignment statement that does not affect the driver of
the target. (§8.4, §9.5.1)
B.248 unassociated formal: A formal that is not associated with an actual. (§5.2.1.2)
B.249 unconstrained subtype: A subtype that corresponds to a condition that imposes no restriction. (§3,
§4.2)
B.250 unit name: A name deﬁned by a unit declaration (either the primary unit declaration or a secondary
unit declaration) in a physical type declaration. (§3.1.3)

Copyright © 2000 IEEE. All rights reserved.

249

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

B.251 universal_integer: An anonymous predeﬁned integer type that is used for all integer literals. The
position number of an integer value is the corresponding value of the type universal_integer. (§3.1.2, §7.3.1,
§7.3.5)
B.252 universal_real: An anonymous predeﬁned type that is used for literals of ﬂoating point types. Other
ﬂoating point types have no literals. However, for each ﬂoating point type there exists an implicit conversion
that converts a value of type universal_real into the corresponding value (if any) of the ﬂoating point type.
(§3.1.4, §7.3.1, §7.3.5)
B.253 update: An action on the value of a signal, variable, or ﬁle. The value of a signal is said to be updated
when the signal appears as the target (or a component of the target) of a signal assignment statement
(indirectly); when it is associated with an interface object of mode out, buffer, inout, or linkage; or when
one of its subelements (individually or as part of a slice) is updated. The value of a signal is also said to be
updated when it is subelement or slice of a resolved signal, and the resolved signal is updated. The value of
a variable is said to be updated when the variable appears as the target (or a component of the target) of a
variable assignment statement (indirectly), when it is associated with an interface object of mode out or
linkage, or when one of its subelements (individually or part of a slice) is updated. The value of a ﬁle is said
to be updated when a WRITE operation is performed on the ﬁle object. (§4.3.2)
B.254 upper bound: For a range L to R or L downto R, the larger of L and R. (§3.1)
B.255 variable: An object with a single current value. (§4.3.1.3)
B.256 visible: When the declaration of an identiﬁer deﬁnes a possible meaning of an occurrence of the
identiﬁer used in the declaration. A visible declaration is visible by selection (for example, by using an
expanded name) or directly visible (for example, by using a simple name). (§10.3)
B.257 waveform: A series of transactions, each of which represents a future value of the driver of a signal.
The transactions in a waveform are ordered with respect to time, so that one transaction appears before
another if the ﬁrst represents a value that will occur sooner than the value represented by the other. (§8.4)
B.258 whitespace character: A space, a nonbreaking space, or a horizontal tabulation character (SP, NBSP,
or HT). (§14.3)
B.259 working library: A design library into which the library unit resulting from the analysis of a design
unit is placed. (§11.2)

250

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

Annex C
(informative)

Potentially nonportable constructs
This annex lists those VHDL constructs whose use may result in nonportable descriptions.
A description is considered portable if it
a)
b)

Compiles, elaborates, initializes, and simulates to termination of the simulation cycle on all
conformant implementations, and
The time-variant state of all signals and variables in the description are the same at all times during
the simulation,

under the condition that the same stimuli are applied at the same times to the description. The stimuli applied
to a model include the values supplied to generics and ports at the root of the design hierarchy of the model,
if any.
Note that the content of ﬁles generated by a description are not part of the state of the description, but that
the content of ﬁles consumed by a description are part of the state of the description.
The use of the following constructs may lead to nonportable VHDL descriptions:
—
—
—
—
—
—

Resolution functions that do not treat all inputs symmetrically
The comparison of ﬂoating point values
Events on ﬂoating-point-valued signals
The use of explicit type conversion to convert ﬂoating point values to integer values
Any value that does not fall within the minimum guaranteed range for the type
The use of architectures and subprogram bodies implemented via the foreign language interface (the
'FOREIGN attribute)
— Processes that communicate via ﬁle I/O, including TEXTIO
— Impure functions
— Linkage ports
— Ports and generics in the root of a design hierarchy
— Use of a time resolution greater than fs
— Shared variables
— Procedure calls passing a single object of an array or record type to multiple formals where at least
one of the formals is of mode out or inout
— Models that depend on a particular format of T'Image
— Declarations of integer or physical types that have a secondary unit whose position number is outside
of the range -(2**31-1) to 2**31-1
— The predeﬁned attributes 'INSTANCE_NAME or 'PATH_NAME, if the behavior of the model is
dependent on the values returned by the attributes.

Copyright © 2000 IEEE. All rights reserved.

251

IEEE
Std 1076, 2000 Edition

252

IEEE STANDARD VHDL

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

Annex D
(informative)

Bibliography
[B1] ANSI/MIL-STD-1815A-1983, American National Standard Reference Manual for the Ada Programming Language.6
[B2] IEEE Std 1029.1-1998, IEEE Standard for Waveform and Vector Exchange (WAVES).7
[B3] IEEE Std 1076-1993, IEEE Standard VHDL Language Reference Manual.
[B4] IEEE Std 1076.2-1996, IEEE Standard VHDL Mathematical Packages.
[B5] IEEE Std 1164-1993, IEEE Standard Multivalue Logic System for VHDL Model Interoperability
(Std_logic_1164).
[B6] ISO/IEC 8859-1: 1987, Information Processing—8-Bit Single-Byte Coded Graphic Character Sets—
Part 1: Latin Alphabet No. 1.8

6ANSI publications are available from the Sales Department, American National Standards Institute, 11 West 42nd Street, 13th Floor,
New York, NY 10036, USA.
7IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway,
NJ 08855-1331, USA.
8ISO publications are available from the ISO Central Secretariat, Case Postale 56, 1 rue de Varembe, CH-1211, Geneve 20, Switzerland/Suisse. ISO publications are also available in the United States from the Sales Department, American National Standards Institute,
11 West 42nd Street, 13th Floor, New York, NY 10036, USA.

Copyright © 2000 IEEE. All rights reserved.

253

IEEE
Std 1076, 2000 Edition

254

IEEE STANDARD VHDL

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

Index
A
access types
described, 3.3, 3.3.1, 3.3.2
designated type, 3.3.1
elaboration of, 12.3.1.3
mutually dependent, 3.3, 3.3.2
null, Clause 3, 3.3, 7.3.1
objects designated by, 6.3
dereferencing, 6.3
recursive, 3.3.1
restrictions
on attributes, 4.4
on ﬁle types, 3.4
on preﬁxes, 6.1
on signals, 4.3.1.2
on subtype indications, 4.2, 4.3.2
subprogram parameters of, 2.1.1, 2.1.1.1
usage, Clause 3
in index constraints, 3.2.1.1
where prohibited, 4.3.1, 4.3.1.1
ACTIVE attribute, 4.3.2, 7.4.1, 7.4.2, 14.1
active drivers, 12.6.1, 12.6.4
active signals, 12.6.2, 12.6.3
actual designators
syntax, 4.3.2.2
where used, 4.3.2.2
actual parameter part
syntax, 7.3.3
usage
in functions, 7.3.3
in procedures, 8.6
actuals
associations
with formal function parameters, 7.3.3
with formal procedure parameters, 8.6
with formal subprogram parameters, 4.3.2.2
with formals of blocks, 9.1
in map aspects, 5.2.1.2
syntax, 4.3.2.2
usage, 4.3.2.2
where used, 4.3.2.2
aggregates, Clause 3
array, 7.3.2.2
deﬁning the type of, 7.3.3–7.3.5
described, 7.3.2, 7.3.2.1, 7.3.2.2
record, 7.3.2.1
restrictions
on array types, 7.3.2.2
on globally static primaries, 7.4.2
on record types, 7.3.2.1
subaggregates, 7.3.2
syntax, 7.3.1
type of, 7.3.2, 7.3.2.1, 7.3.2.2

Copyright © 2000 IEEE. All rights reserved.

255

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

usage
as guarded signals, 9.5
as targets of concurrent signal assignment statement, 9.5
as targets of signal assignment statements, 8.4
as targets of variable assignment statements, 8.5, 8.5.1
where used, 7.2, 7.3.3–7.3.5, 8.4
alias declarations
described, 4.3.3, 4.3.3.1, 4.3.3.2
elaboration of, 12.3.1.5
syntax, 4.3.3
where used, 1.1.2, 1.2.1, 2.2, 2.5, 9.2
alias designators
syntax, 4.3.3, 4.3.3.1
where used, 4.3.3, 4.3.3.1
aliases
referenced in attribute speciﬁcations, 5.1
usage
as globally static primaries, 7.4.2
as locally static primaries, 7.4.1
allocators, Clause 3, 3.2.1.1
constraints, 7.3.6
deallocation of, 3.3.2, 7.3.6
deﬁned, 3.3
described, 7.3.6
evaluation of, 7.3.6, 12.5
syntax, 7.3.6
usage, 3.3.1
as globally static primaries, 7.4.2
to access values of objects, 3.3
where used, 7.2
architecture bodies
as declarative regions, 10.1
default binding rules, 5.2.1
described, Clause 1, 1.1, 1.2, 1.2.1, 1.2.2
syntax, 1.2
where used, 5.2.1, 5.2.2
architecture declarative part
described, 1.2.1
syntax, 1.2.1
where used, 1.2
architecture names
where used, 1.3, 1.3.1, 5.2.2, 9.6, 11.1
architecture statement part
described, 1.2.2
syntax, 1.2.2
where used, 1.2
array types
aggregates, 7.3.2
bounds, 3.2.1.1
closely related, 7.3.5
concatenation of, 7.2.4
constrained, 3.2.1
as formal parameters of constants and variables, 2.1.1
as formal parameters of signals, 2.1.1.2
described, 3.2.1, 3.2.1.1
discrete ranges in, 3.2.1.1
implicit ﬁle operations for, 3.4.1
index ranges of, 3.2.1.1
conversions between, 7.3.5

256

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

denoting elements of, 6.4
described, 3.2.1, 3.2.1.1, 3.2.1.2
designated by access values, 3.2.1.1
direction of, 6.5
null arrays, 3.2.1.1
predeﬁned, 3.2.1.2
restrictions
on ﬁle types, 3.4
subprogram parameters of, 2.1.1, 2.1.1.1, 2.1.1.2
syntax, 3.2.1
unconstrained, 3.2.1
described, 3.2.1
elaboration of, 12.3.1.2
used in index constraints, 3.2.1.1
used in subprograms, 3.2.1.1
variables, assignments to, 8.5.1
where used, 3.2.1
ASCENDING attribute, 14.1
ASCII
format effectors, 13.1
non-graphic elements, 3.1.1, 3.1.1.1
assertion statements
described, 8.2
syntax, 8.2
where used, Clause 8, 9.4
assertion statements. See also: concurrent assertion statements.
assignment
as a basic operation, Clause 3
guarded signal, 5.3, 9.5, 12.3.2.3
to arrays, 3.2.1.1
association elements
named, 4.3.2.2, 5.2.1.1, 5.2.1.2
positional, 5.2.1.2
syntax, 4.3.2.2
where used, 4.3.2.2
association lists
described, 4.3.2.2
generic, 1.1.1.1, 12.2.1, 12.2.2
port, 12.2.4
syntax, 4.3.2.2
where used, 5.2.1.2, 7.3.3
attribute declarations
described, 4.4
elaboration of, 12.3.2.1
syntax, 4.4
where used, 1.1.2, 1.2.1, 2.2, 2.5, 9.2
attribute designators
syntax, 6.6
where used, 5.1, 6.6
attribute speciﬁcations
described, Clause 5, 5.1
elaboration of, 12.3.2.1
syntax, 5.1
where used, 1.1.2, 1.2.1, 1.3, 2.2, 2.5, 5.1, 9.2
attributes
allowed as primaries, 7.1
denoting aliases, 6.6
index ranges of, 3.2.1.1
of formal parameters, 2.1.1

Copyright © 2000 IEEE. All rights reserved.

257

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

predeﬁned, Clause 3, 6.6
described, 4.4, 14.1
exclusion from visibility rules, 10.3
used as locally static primaries, 7.4.1
restrictions
on groups, 4.7
on subelements and slices, 6.5, 6.6
on subtype of, 12.3.2.1
signal-valued, 2.1.1.2
user-deﬁned, 4.4, 6.6
described, 4.4
usage, 5.1
as globally static primaries, 7.4.2
as locally static primaries, 7.4.1
where used, 4.4
attributes. See also: speciﬁc names of predeﬁned attributes.

B
backus naur form (BNF), 0.2.1
base
syntax, 13.4.2
where used, 13.4.2
BASE attribute, 14.1
base speciﬁers
syntax, 13.7
where used, 13.7, Annex A
basic operations, Clause 3, 7.2.3, 7.3.2, 7.3.4
bidirectional ports. See: ports, INOUT.
binding indications
containing map aspects, 5.2.1.2
default
described, 5.2.2
described, 5.2.1, 5.2.2
elaboration of, 12.3.2.2
primary, 5.2.1
restrictions
for component conﬁgurations, 5.2.1
for conﬁguration speciﬁcations, 5.2
syntax, 5.2.1
where used, 1.3.1, 5.2
bindings
deferred, 1.3, 5.2.1, 5.2.1.1
BIT type, 3.1.1.1, 3.2.1.2, 7.2, 7.2.1, 7.2.2
bit values
syntax, 13.7
where used, 13.7, Annex A
BIT_VECTOR type, 3.2.1.2
block conﬁgurations
applicability, 1.3.1
as declarative regions, 10.1
described, 1.3.1
implicit, 1.3.1, Clause 12, 12.1
scope of, 10.2
syntax, 1.3.1
usage
to control elaboration of a block statement, 12.4, 12.4.1
when architecture identiﬁer is used, 5.2.1.1
visibility within, 10.3

258

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

where used, 1.3, 1.3.1
block declarative items
syntax, 1.2.1
usage, 1.2.2, Clause 5, 5.1
where used, 9.1, 9.6.2
block declarative part
elaboration of, 12.4.1, 12.4.2
syntax, 9.1
where used, Clause 9, 9.1
block headers
containing map aspects, 5.2.1.2
correspondences
to component declarations, 9.6.1
to component instantiation statements, 9.6.2
to design entities, 9.6.1, 9.6.2
elaboration of, 12.2, 12.4.1
syntax, 9.1
where used, Clause 9, 9.1
block speciﬁcations
syntax, 1.3.1
where used, 1.3.1
block statement part
elaboration of, 12.4.2
syntax, 9.1
where used, Clause 9, 9.1
block statements
as declarative regions, 10.1
described, Clause 9, 9.1
elaboration of, 12.1, 12.4.1, 12.4.2
implied, 9.6.2, 12.4.3
labels, 1.3.1
elaboration of, 12.4.2
where used, 1.3.1
syntax, 9.1
usage, 1.3.1, 9.6.1
where used, Clause 9, 9.1
blocks
communication to, 1.1.1
described, Clause 1, 1.1
interconnection via concurrent statements, Clause 9, 9.1
scope of, 10.2
usage, 9.6, 9.6.1
boldface, 0.2.1
BOOLEAN type, 3.1.1.1, 7.2, 7.2.1, 7.2.2
buffer ports. See: ports.
bus signals, 2.1.1.2, 2.4, 4.3.2

C
case statement alternatives
syntax, 8.8
where used, 8.8
case statements
described, 8.8
syntax, 8.8
usage
as signal transforms, 9.5.2
with null statements, 8.13

Copyright © 2000 IEEE. All rights reserved.

259

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

where used, Clause 8, 8.1, 9.5
character set, VHDL, 13.1
CHARACTER type, 3.2.1.2
character types, used in case statements, 8.8
characters
apostrophe ('), 13.5
backslash (\), 13.3.2
basic
allowable replacements for, 13.10
syntax, 13.1
basic graphic
syntax, 13.1
where used, Clause 13, 13.1
braces {}, 0.2.1
colon (:), 13.10
exclamation mark (!), 13.10
graphic
syntax, 13.1
where used, 13.3.1, 13.5, 13.6
lower case
where used, 13.1
number sign (#), 13.4.2, 13.10
other special
syntax, 13.1
where used, Clause 13, 13.1
percent sign (%), 13.10
quotation mark (“), 13.6
quotation mark ("), 13.10
where used, 13.7
spaces
syntax, 13.1
where prohibited, 13.3.1
where used, Clause 13, 13.1
special
names of, 13.1
syntax, 13.1
where used, Clause 13, 13.1
square brackets [ ], 0.2.1
used in instance names
separator (:), 14.1
used in path names
leader (:), 14.1
separator (:), 14.1
vertical bar (|), 0.2.1
vertical line (|), 13.10
characters. See also: operators, symbols.
choices
in case statements, 8.8
syntax, 7.3.2
where used, 7.3.1, 7.3.2, 8.8
comments, 13.8
component conﬁgurations
as declarative regions, 10.1
binding indications in, 5.2.1
containing block conﬁgurations, 1.3.2
default entity aspect of, 5.2.2
described, 1.3.2
implicit, 1.3.1, Clause 12, 12.1

260

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

restrictions
against conﬂicting conﬁgurations, 1.3.2
syntax, 1.3.2
used to bind component instances to design entities, 4.4
visibility rules for, 10.3
where used, 1.3, 1.3.1
component declarations
as declarative regions, 10.1
bindings to design entities, 5.2.1
described, 4.5
elaboration of, 12.3.1.7
prohibitions on attributes, 5.1
scope of, 10.2
syntax, 4.5
usage, 5.2, 9.6, 9.6.1
where used, 1.2.1, 2.5
component instances
association with conﬁgurations, 1.3.2
bound
described, 1.2.2
elaboration of, 12.4
to design entities, 5.2.1.1
fully bound, 1.3.1, 5.2.1.1
index range, 3.2.1.1
labels
in blocks, 1.3.1
paths to
syntax, 14.1
where used, 14.1
unbound
defaults for, 1.3.2
elaboration of, 12.1
with conﬂicting conﬁgurations, 1.3.2
component instantiation statements
containing map aspects, 5.2.1.2
default entity aspect of, 5.2.2
described, 9.6, 9.6.1, 9.6.2
elaboration of, 12.4.3
interfaces of, 4.5
referenced in conﬁguration speciﬁcations, 5.2
syntax, 9.6
usage
to instantiate a component, 9.6.1
to instantiate a design entity, 9.6.2
where used, Clause 9, 9.1
component names
where used, 9.6
component speciﬁcations
elaboration of, 12.3.2, 12.3.2.2
syntax, 5.2
where used, 1.3.2, 5.2
composite types
described, 3.2
objects of, 4.3, 4.4
restrictions
on ﬁle types, 3.4
syntax, 3.2
usage, Clause 3

Copyright © 2000 IEEE. All rights reserved.

261

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

concurrent assertion statements
described, 9.4
elaboration of, 12.4.4
syntax, 9.4
where used, 1.1.3, Clause 9
concurrent procedure call statements
described, 9.3
syntax, 9.3
usage, 9.3
where used, 1.1.3, Clause 9
concurrent procedure call statements. See also: procedure call statements.
concurrent signal assignment statements, 8.4
containing delay mechanisms, 9.5
described, 9.5
elaboration of, 12.4.4
execution of, 9.5
syntax, 9.5
where used, Clause 9
concurrent signal assignment statements. See also: conditional signal assignments, selected signal assignments, signal assignment statements.
concurrent statements
described, Clause 9
elaboration of, 12.4, 12.4.4
syntax, Clause 9
where used, Clause 1, 1.1, 1.2.1, 9.1, 9.6.2
condition clauses
described, 8.1
syntax, 8.1
where used, 8.1
conditional signal assignments
described, 9.5.1
syntax, 9.5.1
where used, 9.5
conditions
syntax, 8.1
where used, Clause 8, 8.1, 8.7, 8.10, 9.5.1, 9.5.2, 9.7
conﬁguration declarations
anonymous, 12.1
as declarative regions, 10.1
described, 1.3, 1.3.2
scope of, 10.4
syntax, 1.3
usage
to control elaboration of a block statement, 12.4
to deﬁne components, 9.6
visibility of, 1.1.2
where used, 11.1
conﬁguration items
implicit, 1.3.1
syntax, 1.3, 1.3.1
conﬁguration speciﬁcations
default entity aspect of, 5.2.2
described, 5.2, 5.2.1, 5.2.1.1, 5.2.1.2, 5.2.2
elaboration of, 12.3.2.2
implicit, 12.1
restrictions
for binding indications, 5.2.1
for others and all, 5.2
syntax, 5.2

262

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

usage
to bind component instances to design entities, 1.3, 4.5
to deﬁne copies of blocks, 9.6
where used, 1.2.1
conﬁgurations
described, Clause 1
where used, 9.6
constant declarations
described, 4.3.1.1
syntax, 4.3.1.1
where used, 1.1.2, 1.2.1, 2.2, 2.5, 4.3.1.1, 9.2
constants
deferred, 2.6, 4.3.1.1
explicitly declared, 4.3.1.1
generic, 1.1.1.1
in resolution functions, 2.4
index ranges of, 3.2.1.1
initial values of, 12.3.1.4
usage
as generate parameters, 9.7
as globally static primaries, 7.4.2
as subprogram parameters, 2.1.1.1
values of, 4.3.1.1
context clauses
described, 11.3
implicit, 14.2
syntax, 11.3
where used, Clause 11, 11.1
context items
syntax, 11.3
where used, 11.3
conversion functions
restrictions in signal associations, 4.3.2.2

D
deallocation, 3.3.2
declarations
elaboration of, Clause 12, 12.1, 12.3.1, 12.3.1.1–12.3.1.7
occurring immediately within declarative regions, 10.1
of items in a design entity, Clause 1, 1.1
overloaded, 10.3, 10.5
visibility
by selection, 10.3
direct, 10.3
hidden, 10.3
potential, 10.4
declarative parts, elaboration of, 12.3, 12.3.1, 12.3.1.1–12.3.1.7, 12.3.2, 12.3.2.1–12.3.2.3
declarative regions
described, Clause 10, 10.1, 10.2
deferred bindings, 1.3
deferred constants, 2.6
deﬁned, 4.3.1.1
delay mechanisms
described, 8.4
syntax, 8.4
where used, 8.4, 9.5
DELAYED attribute, 2.2, 4.3, 4.3.2, 14.1

Copyright © 2000 IEEE. All rights reserved.

263

IEEE
Std 1076, 2000 Edition

delays, 3.1.3.1
inertial, 8.4
transport, 8.4
delimiters
deﬁned, 13.2
names of, 13.2
design entities
bindings to component instances, 1.3, 5.2.1, 5.2.1.1, 9.6.1, 9.6.2
bodies of, 1.2
declarative items, Clause 1, 1.1, Clause 5, 5.1
deﬁning external blocks, 1.3.1
deﬁning subcomponents of, 9.6
described, Clause 1, 1.1
interfaces of, 1.1, 4.4
library requirements, 1.1.3
ports, 1.1.1
visibility, 1.1.2
design ﬁles
syntax, Clause 11, 11.1
design hierarchies
deﬁned by conﬁgurations, 5.2.1.1, Clause 12, 12.1
deﬁned by design entities, Clause 12, 12.1
described, Clause 1, 1.1
elaboration
conditional or iterative, 9.7
described, 12.2
of component instances, 9.6.1, 9.6.2, 9.7
elaboration
described, Clause 12, 12.1
portability of ports and generics in root, Annex C
design hierarchies. See also: blocks.
design methodologies
portability issues, Annex C
reusing existing libraries, 9.6
structural design, 9.6
design units
described, Clause 11, 11.1–11.4
order of analysis, 11.4
primary
denoting, 6.3
syntax, Clause 11, 11.1
where used, Clause 11, 11.1
reported in assertion violations, 8.2
reported in report statements, 8.3
secondary
portability issues, Annex C
syntax, Clause 11, 11.1
where, Clause 11, 11.1
speciﬁcations related to, Clause 5, 5.1
syntax, Clause 11, 11.1
visibility of packages, 2.5
where used, Clause 11, 11.1
designators
as a basic operation, Clause 3
described, 2.2
overloaded, 2.3.1
syntax, 2.1
where used, Clause 2, 2.1, 2.1.1.3

264

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

digits
decimal
syntax, Clause 13, 13.1
where used, Clause 13, 13.1, 13.3.1, 13.4.1
extended
syntax, 13.4.1, 13.4.2
where used, 13.4.1, 13.4.2, 13.7
direction
of discrete subtype indications, 4.2
syntax, 3.1
where used, 3.1
disconnection speciﬁcations
default
syntax, 5.3
elaboration of, 5.3
syntax, 5.3
usage
to turn off drivers of guarded signals, 4.3.1.2
with concurrent signal assignment statements, 9.5
where used, 1.1.2, 1.2.1, 2.5
discrete ranges
bounds of, 6.5, 10.5
described, 3.2.1.1
direction of, 1.3.1, 6.5
static
described, 7.4
globally static, 7.4.2
locally static, 7.4.1
syntax, 3.2.1
where used, 1.3.1, 3.2.1, 6.5, 7.3.2, 8.9
discrete types
described, 3.1
used in case statements, 8.8
drivers
active, 12.6.1, 12.6.4
assignments to, 2.1.1.2
associated, 12.6.1
constant, 1.1.1.2
creation of, 12.6
described, 12.6.1
determined by null transactions, 2.4, 12.6.1
in kernel process, 12.6, 12.6.1
initial values of, 12.6
of guarded signals, 4.3.1.2, 5.3
disconnection of, 5.3, 12.3.2.3
of signals, 4.3.1.2
DRIVING attribute, 7.4.1, 7.4.2, 14.1
DRIVING_VALUE attribute, 7.4.1, 7.4.2, 14.1

E
elaboration
dynamic, 12.5
implementation-dependent, 12.3, 12.4
of conﬁguration declaration, 1.3
of processes, Clause 12, 12.1
of statement parts, 12.4, 12.4.1–12.4.4

Copyright © 2000 IEEE. All rights reserved.

265

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

elements
associations
named, 7.3.2
positional, 7.3.2
syntax, 7.3.2
where used, 7.3.2
terminology, 3.1
entities
associations
with architectures, 1.2
with components, 5.2.1.1
overloaded, 10.5
entities. See also: named entities.
entity aspect
default, 5.2.2
described, 5.2.1.1
syntax, 5.2.1.1
where used, 5.2.1
entity classes
syntax, Clause 5, 5.1
usage, 4.7
where used, 4.6, 4.7, Clause 5, 5.1
entity declarations
as declarative regions, 10.1
described, Clause 1, 1.1, 1.1.1, 1.1.1.1–1.1.1.2, 1.1.2–1.1.3
scope of, 10.2
syntax, 1.1
usage, 5.2.1.1
visibility
causing default bindings, 5.2.2, Clause 12, 12.1
where used, Clause 11, 11.1
entity declarative part, Clause 1, 1.1
described, 1.1.2
syntax, 1.1.2
entity designators
restrictions, 5.1
syntax, 5.1
where used, Clause 5, 5.1, 14.1
entity headers
described, 1.1.1, 1.1.2
syntax, 1.1.1
where used, Clause 1, 1.1
entity name lists
syntax, 5.1
where used, Clause 5, 5.1
entity names
usage, 5.2.2
where used, 1.1.3, 1.3, 5.2.1.1, 9.6
entity speciﬁcations
elaboration of, 12.3.2.1
syntax, 5.1
where used, Clause 5, 5.1
entity statement part
described, 1.1.3
syntax, 1.1.3
usage, Clause 1, 1.1
entity tags
restrictions, 5.1
syntax, 5.1

266

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

where used, Clause 5, 5.1
enumeration types
described, 3.1.1, 3.1.1.1
elaboration of, 12.3.1.2
predeﬁned, 3.1.1.1
enumeration types. See also: literals—enumeration.
EVENT attribute, 4.3.2, 7.4.1, 7.4.2, 14.1
exit statements
described, 8.11
syntax, 8.11
where used, Clause 8
explicit ancestor. See: signals.
exponents
syntax, 13.4.1, 13.4.2
where used, 13.4.1, 13.4.2
exporting data. See: ﬁles—external.
expressions
as initial values of variables, 4.3.1.3
associated with signal parameters, 2.1.1.3
Boolean, Clause 8, 8.1
containing signal names, 12.3
default
for interface objects, 4.3.2, 4.3.2.2
for signal values, 4.3.1.2
deﬁning the type of, 7.3.4
described, Clause 7, 7.1
guard, 9.1
in attribute speciﬁcations, 12.3.2.1
initializing a constant, 12.3.1.4
primaries in
described, 7.1
where used, Clause 7, 7.1
qualiﬁed, Clause 3
described, 7.3.4
syntax, 7.3.4
used as globally static primaries, 7.4.2
used as locally static primaries, 7.4.1
where used, 7.1, 7.2, 7.4
restrictions
on type, 4.3.1, 4.3.1.1
on type in case statements, 8.8
sequences in, 7.2
shift
syntax, 7.1
where used, 7.1
simple
syntax, 7.1
where used, 7.1, 7.3.2
static
deﬁnition of globally static, 7.4, 7.4.2
deﬁnition of locally static, 7.4
described, 7.4, 7.4.1, 7.4.2
in concurrent assertion statements, 9.4
where used, 1.3.1, 4.3.2
syntax, 7.1
time
usage, 8.4.1
where used, Clause 8, 8.1, 8.4.1
treatment during elaboration, 12.3

Copyright © 2000 IEEE. All rights reserved.

267

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

universal
described, 7.5
used as operands, 7.3
where used, 4.3.1, 4.3.1.1, 4.3.1.2, Clause 5, 5.1, 6.4, 6.6, 7.3.4, 8.2, 8.3, 8.5, 8.8, 8.12, 9.5.2
expressions. See also: guards.
external blocks, 1.3.1

F
factors
syntax, 7.1
where used, 7.1
ﬁle declarations
described, 4.3.1.4
elaboration of, 12.3.1.4
syntax, 4.3.1.4
where used, 1.1.2, 1.2.1, 2.2, 2.5, 4.3.1, 9.2
ﬁle types
described, 3.4, 3.4.1
operations implicitly declared for, 3.4.1
restrictions
on attributes, 4.4
on signals, 4.3.1.2
on subprogram parameters, 4.3.1.4, 4.3.2, 4.3.2.1
on subtype indications, 4.2, 4.3.2
usage, Clause 3
with external ﬁles, 4.3.1.4, 4.3.2
where prohibited, 3.3, 4.3.1
ﬁles
explicit, 4.3.1.4
external, 4.3.1.4
read operations, 4.3.2
used as subprogram parameters, 2.1.1.3
write operations, 4.3.2
ﬂoating point types
described, 3.1.4, 3.1.4.1
elaboration of, 12.3.1.2
portability issues, Annex C
predeﬁned, 3.1.4.1
required precision, 3.1.4
syntax, 3.1.4
FOREIGN attribute, 1.1.2, 1.1.3, 1.2, 1.2.1, 1.2.2, 2.2, 12.4, 14.2
exclusion from elaboration, 12.3
portability issues, Annex C
foreign subprograms, 2.2
formal designators
syntax, 4.3.2.2
where used, 4.3.2.2
formal parameters
as objects, 4.3
described, 2.1.1
scope of, 10.2
syntax, 2.1.1
type proﬁles, 2.3, 10.5
used as constants, 4.3.1.1
where used, Clause 2, 2.1
formal parameters. See also: subprogram speciﬁcations.

268

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

formals
in map aspects, 5.2.1.2, 9.1
syntax, 4.3.2.2
unassociated, 5.2.1.2
usage, 4.3.2.2
where used, 4.3.2.2
formals. See also: formal parameters, generics, ports.
format effectors
end of line, 13.2
syntax, 13.1
where used, Clause 13, 13.1
function calls
deﬁning parentage of subprograms, 2.2
described, 7.3.3
evaluation of, 7.3.3
in association lists
as actuals, 4.3.2.2
as formals, 4.3.2.2
restrictions
on expanded names, 6.3
on groups, 4.7
syntax, 7.3.3
treatment during elaboration, 12.3, 12.3.1
usage
as globally static primaries, 7.4.2
as locally static primaries, 7.4.1
general description, Clause 2, 2.1
where used, 6.1, 7.2
functions
in signatures, 2.3.2
invoking execution of, 7.3.3
object classes for, 2.1.1
overloaded, 4.2
portability issues of impure, Annex C
predeﬁned
NOW, 14.1, 14.2
pure, 2.1, 2.2, 2.7, 7.4.2
resolution, 2.4, 4.2
returned values, 8.12
syntax, 2.1
usage, Clause 2, 2.1
where used, 4.3.2.2
functions. See also: return statements.

G
generate parameters
as objects, 4.3
constants, 4.3.1.1, 12.4.2
usage, 4.3
as globally static primaries, 7.4.2
generate statements
as declarative regions, 10.1
deﬁning internal blocks, 1.3.1
described, 9.7
elaboration of, 12.4.2

Copyright © 2000 IEEE. All rights reserved.

269

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

labels, 1.3.1
elaboration of, 12.4.2
where used, 1.3.1
syntax, 9.7
where used, Clause 9
generation schemes
syntax, 9.7
where used, 9.7
generic clauses
elaboration of, 12.2.1
syntax, 1.1.1.1
where used, 4.5, 9.1
generic lists
deﬁned, 1.1.1
syntax, 1.1.1, 1.1.1.1
where used, 1.1.1, 1.1.1.1
generic map aspect
default, 5.2.2
described, 5.2.1.2
syntax, 5.2.1.2
usage, 5.2.1
where used, 5.2.1, 9.1, 9.6
generic map aspects
elaboration of, 12.2.2
generics
constants, 1.1.1.1, 4.3.1.1, 12.2.1
described, 1.1.1.1
formal, 5.2.2
in binding indications, 5.2.1
in block headers, 9.1
in top-level design entity, 12.1
of unconstrained array types, 3.2.1.1
scope of, 10.2
where used, 4.3.2.2
group constituents
syntax, 4.7
where used, 4.7
group declarations
described, 4.6, 4.7
syntax, 4.7
usage, 4.7
where used, 1.1.2, 1.2.1, 1.3, 2.2, 2.5, 9.2
group template declarations
described, 4.6
syntax, 4.6
where used, 1.1.2, 1.2.1, 2.2, 2.5, 2.6, 9.2
group templates, 4.6
guarded signal speciﬁcations
described, 5.3
elaboration of, 12.3.2.3
syntax, 12.3.2.3
where used, 12.3.2.3
guards, 4.3.1.2, 9.1, 9.4

H
HIGH attribute, 3.1.4.1, 14.1
homographs, 10.3, 11.2

270

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

I
identiﬁers, 4.2
basic
described, 13.3.1
syntax, 13.3.1
where used, 13.3.1
extended
described, 13.3.2
syntax, 13.3.2
where used, 13.3.2
of named entities, Clause 4
referenced within their own declarations, 10.3
restrictions, 13.9
scope of, 10.2
separators required between, 13.2
simple names for, 0.2.1
syntax, 13.3.1, 13.3.2
visibility rules for, 10.3–10.5
where used, 1.1, 1.2, 1.3, 11.2
with overlapping scopes, 10.3
identiﬁers. See also: names.
IEEE Std 1164-1993, Annex D
if statements
described, 8.7
syntax, 8.7
usage, 9.5.1
where used, Clause 8, 9.5, 9.5.1
IMAGE attribute, 14.1
portability issues, Annex C
importing data. See: ﬁles—external.
IN or INOUT ports. See: ports.
incomplete type declarations, 3.3.1
index constraints
described, 3.2.1.1
elaboration of, 12.3.1.3
globally static, 7.4.2
in access types, 3.3
index ranges of array types, 3.2.1.1, 3.2.1.2, 6.5
locally static, 7.4.1
syntax, 3.2.1
usage, 7.3.6
where used, 3.2.1, 4.2
index speciﬁcations
containing discrete ranges, 1.3.1
syntax, 1.3.1
where used, 1.3.1
index subtype deﬁnitions
syntax, 3.2.1
where used, 3.2.1
index subtypes
compatibility with discrete ranges, 3.2.1.1
of shift operators, 7.2.3
instance names, syntax of, 14.1
INSTANCE_NAME attribute, 14.1
instantiated units
syntax, 9.6
where used, 9.6

Copyright © 2000 IEEE. All rights reserved.

271

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

instantiation lists
syntax, 5.2
where used, 5.2
INTEGER type, 3.1.2, 3.2.1.1
integer types
described, 3.1.2
elaboration of, 12.3.1.2
predeﬁned, 3.1.2.1
syntax, 3.1.2
integers
based, 13.4.2
syntax, 13.4.1, 13.4.2
where used, 13.4.1, 13.4.2
interface constant declarations
described, 4.3.2
syntax, 4.3.2
usage, 4.3.2.2
where used, 4.3.2.1
interface declarations
described, 4.3.2, 4.3.2.1, 4.3.2.2
usage, 4.3.1
where used, 4.3.2.1
interface ﬁle declarations
described, 4.3.2
syntax, 4.3.2
where used, 4.3.2.1
interface lists
described, 4.3.2.1
of formal parameters, 2.1.1
elaboration of, 12.3.1.1
of generics, 1.1.1.1
of ports, 1.1.1.2
where used, 1.1.1.1, 1.1.1.2
interface objects
deﬁned, 4.3.2
in top-level design entity, Clause 12, 12.1
index ranges
obtained by association, 3.2.1.1
of constrained arrays, 3.2.1.1
speciﬁcations related to, Clause 5, 5.1
where used, 4.5
interface signal declarations
described, 4.3.2
syntax, 4.3.2
where used, 4.3.2.1
interface variable declarations
described, 4.3.2
syntax, 4.3.2
where used, 4.3.2, 4.3.2.1
internal blocks, 1.3.1
ISO 8859 character set, 3.1.1.1, 13.1, Annex D
italics, meaning of, 0.2.1, 0.2.3, 4.1, 14.2
iteration schemes
for loops, 8.9
syntax, 8.9
where used, 8.9
while loops, 8.9

272

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

L
labels
block, 9.1
bound, 5.2.1
generate
where used, 9.7
instantiation
where used, 5.2, 9.6
loop
where declared, 8.9
where used, 8.9–8.11
of concurrent statements, Clause 9
process
where used, 9.2
syntax, 9.7
where used, Clause 8, 8.2–8.4, 8.5–8.8, 8.11, 8.12
LAST_ACTIVE attribute, 4.3.2, 7.4.1, 7.4.2, 14.1
LAST_EVENT attribute, 4.3.2, 7.4.1, 7.4.2, 14.1
LAST_VALUE attribute, 4.3.2, 7.4.1, 7.4.2, 14.1
LEFT attribute, 14.1
LEFTOF attribute, 14.1
LENGTH attribute, 14.1
letters
lowercase, 0.2.1
syntax, 13.1
where used, 13.3.1, 13.3.2, 13.4.2
uppercase, 0.2.2
syntax, 13.1
where used, 13.1, 13.3.1, 13.3.2, 13.4.2
lexical elements, deﬁned, 13.2
libraries
checks during elaboration, 12.3.2.3, 12.4, 12.4.1
design
analysis of, 11.1
denoting items in, 6.3
description, 11.2
resource, 11.2
STD, 11.2
WORK, 11.2
working, 11.2
library clauses
syntax, 11.2
where used, 11.3, 11.4
library indicators
where used, 14.1
library units
effects of changes to, 11.4
existence requirements, 5.2.1.1
scope of, 10.2
syntax, 11.1
where used, 11.1
line breaks, 13.2, 13.5
linkage ports. See: ports.
literals
abstract
based, 13.4.2
decimal, 13.4.1

Copyright © 2000 IEEE. All rights reserved.

273

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

described, 13.4, 13.4.1, 13.4.2
in a physical type deﬁnition, 3.1.3
separators required between, 13.2
where used, 3.1.3, 7.3.1
bit string
described, 7.3.1, 13.7
syntax, 13.7, Annex A
where used, 7.3.1
character
in enumeration types, 3.1.1
where used, 3.1.1, 3.1.1.1
described, 13.5
referenced within their own declarations, 10.3
scope of, 10.2
syntax, 13.5
where used, 4.3.3, 4.7, 5.1, 6.3
with overlapping scopes, 10.3
described, 7.3.1
enumeration
overloaded, 2.3.1, 3.1.1, 10.5
visibility rules for, 10.3
syntax, 3.1.1
values of, 3.1.1
where used, 3.1.1, 3.1.1.1
integer, 3.1.2, 13.4, 13.4.1, 13.4.2
null, 7.3.1
numeric
allowed variations in subprograms, 2.7
as basic operations, Clause 3
described, 7.3.1
syntax, 7.3.1
where used, 7.3.1
physical
syntax, 3.1.3
where used, 3.1.3, 7.3.1
real, 13.4, 13.4.1, 13.4.2
string, Clause 3
described, 7.3.1, 13.6
syntax, 13.6
where used, 2.1, 7.4.1
syntax, 7.3.1
where used, 7.2, 7.4.1
logical name list, 11.2
loop parameters
as context for overload resolution, 10.5
as objects, 4.3
constants, 4.3.1.1
usage, 4.3
loop parameters. See: parameter speciﬁcations—loop.
loop statements
as declarative regions, 10.1
described, 8.9
execution of, 8.9, 8.10
syntax, 8.9
where used, Clause 8
loop statements. See also: exit statements, next statements.
loops, avoiding inﬁnite, 9.3
LOW attribute, 3.1.4.1, 14.1

274

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

LRM
exclusions from language deﬁnition, 0.2.2
intent, 0.1
notes, 0.2.3
semantics, 0.2.2
structure, 0.2
syntax conventions, 0.2.1
terminology, 0.2, 4.3.1.2

M
models, simulation of, 12.6, 12.6.1–12.6.4
delta cycle, 12.6.4
initialization phase, 12.6.4
simulation cycle, 12.6.4
modes
defaults for interface declarations, 4.3.2
of formal parameters, 2.1.1
of interface objects, 4.3.2, 4.3.2.1
of ports, 1.1.1.2
syntax, 4.3.2
where used, 4.3.2

N
named entities
aliases of, 4.3.3, 5.1
attributes of, 4.4, 6.6
groupings of, 4.6, 4.7
identiﬁers of, Clause 4
overloaded, 5.1
restrictions on globally static primaries, 7.4.2
scope of, 10.2
speciﬁcations of, 5.1
names
allowed as primaries, 7.1
allowed variations in subprograms, 2.7
ambiguous, 6.4, 7.3.3
as a basic operation, Clause 3
declared in entities, 1.1.2
expanded, 6.3
general description, Clause 6, 6.1
in declarations, Clause 4
in paths, 14.1
indexed
described, 6.4
syntax, 6.4
usage, 7.3.3
where used, 6.1
locally static, 6.1
logical
syntax, 11.2
usage, 11.2
where used, 11.2
of architecture bodies, 1.2

Copyright © 2000 IEEE. All rights reserved.

275

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

of attributes, 4.4
described, 6.6
syntax, 6.6
where used, 6.1
of delimiters, 13.2
of ﬁles, 4.3.1.4
of interface declarations, 4.3.2, 4.3.2.1
of objects, 3.2.2
of primary units, 6.3
of signals, 5.3, 6.1
of slices
described, 6.5
syntax, 6.5
where used, 6.1
of special characters, 13.1
of variables, 6.1
overloaded, 10.5
preﬁxes
described, 6.1
of attributes, 4.4
of subprograms, 10.5
syntax, 6.1
where used, 6.3–6.6
selected
described, 6.3
syntax, 6.3
where used, 6.3, 10.4
simple, 0.2.1
described, 6.2
syntax, 6.2
where used, 5.1, 6.1, 6.2
static
deﬁned, 6.1
sufﬁxes
syntax, 6.3
usage in use clauses, 10.4
where used, 6.3
syntax of, 0.2.1
where used, 4.3.3, 7.2, 8.4
names. See also: named entities, path names.
NATURAL subtype, 3.2.1.2
nets
creation of, Clause 12, 12.1
deﬁned, 12.6.2
next statements
described, 8.10
syntax, 8.10
usage, 8.10
where used, Clause 8
non-object aliases
described, 4.3.3.2
notation, decimal, 13.4.1
NOW
predeﬁned function, 14.1
null
default initial values of variables, 4.3.1.3
in access types, Clause 3, 7.3.1
ranges, 3.1
transactions, 2.4, 4.3.1.2, 8.4.1

276

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

used as a literal, 7.3.1
waveform elements, 8.4.1
null statements
described, 8.13
syntax, 8.13
where used, Clause 8, 9.5
numeric types
closely related, 7.3.5
described, 3.1
operators
adding, 7.2.4
sign, 7.2.5
numeric types. See also: literals—numeric.

O
object aliases
described, 4.3.3.1
object declarations
described, 4.3.1, 4.3.1.1–4.3.1.4, 4.3.2, 4.3.2.1, 4.3.2.2, 4.3.3, 4.3.3.1, 4.3.3.2
designated by access value, 3.3
elaboration of, 12.3.1.4
of signals, 3.2.1.1
of variables, 3.2.1.1
syntax, 4.3.1
where used, 4.3
objects
aliases of, 4.3.3.1
allocation and deallocation, 3.3.2
allowed as primaries, 7.1
created by allocators, 7.3.6
deﬁned, 4.3
described, 4.3, 4.3.1, 4.3.1.1–4.3.1.4, 4.3.2, 4.3.2.1, 4.3.2.2, 4.3.3, 4.3.3.1, 4.3.3.2
explicitly declared, 4.3.1
aliases of, 4.3.3.2
initial values of, 12.3.1.4
usage, 4.3
when read, 4.3.2
when updated, 4.3.2
open
ﬁle objects, 3.4.1
ﬁle parameters, 2.1.1.3
in association lists, 4.3.2.2
in entity aspects, 5.2.1.1
in map aspects, 5.2.1.2
ports, 1.1.1.2
operands, 7.3, 7.3.6
convertible universal, 7.3.5
operations
basic, Clause 3, 7.2.3, 7.3.2, 7.3.4
short-circuit, 7.2
visibility of predeﬁned, 10.3
operator symbols
referenced within their own declarations, 10.3
scope of, 10.2
syntax of, 2.1
where used, 2.1, 4.3.2.2, 5.1, 6.1, 6.3
with overlapping scopes, 10.3

Copyright © 2000 IEEE. All rights reserved.

277

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

operators, 7.2, 7.2.1–7.2.7
absolute (abs), 7.2.7
adding
described, 7.2.4
where used, 7.1
addition (+), 7.2.4
arithmetic
for integer types, 3.1.2
for physical types, 3.1.3
binary, 2.3.1, 7.2.1
concatenation (&), 7.2.4
division (/), 7.2.6
equality (=), 2.3.1, 7.2.2, 8.4.1, 8.8
overloaded, 12.6.2
exponentiating (**), 7.2.7
for universal expressions, 7.5
identity (+), 2.3.1, 7.2.5
inequality(/=), 7.2.2
logical, 7.2.1
miscellaneous, 7.2.7
modulus (mod), 7.2.6
multiplication (*), 26-27
multiplying
described, 7.2.6
where used, 7.1
negation (-), 2.3.1, 7.2.5
ordering (<, <=, >, >=), 7.2.2
overloaded, 2.3.1, 2.3.2
precedence of, 7.2, 7.2.1, 7.2.5
predeﬁned, Clause 3, 7.1, 7.2
relational
described, 7.2.2
where used, 7.1
remainder (rem), 7.2.6
rotate left logical (rol), 7.2.3
rotate right logical (ror), 7.2.3
shift
described, 7.2.3
index subtypes of, 7.2.3
subtype of result, 7.2.3
values returned, 7.2.3
where used, 7.1
shift left arithmetic (sla), 7.2.3
shift left logical (sll), 7.2.3
shift right arithmetic (sra), 7.2.3
shift right logical (srl), 7.2.3
short-circuit, 2.3.1
sign operators, 7.2.5
where used, 7.1
subtraction (-), 7.2.4
unary, 2.3.1, 7.2.1, 7.2.5
user-deﬁned, 2.3.1
operators. See also: characters, symbols.
optional items, 0.2.3
options
syntax, 9.4
where used, 9.5, 9.5.2

278

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

others
in array aggregates, 7.3.2.2
in record aggregates, 7.3.2.1
where used, 7.3.2, 7.3.2.1, 7.3.2.2
OUT ports. See: ports.
overload resolution
context of, 10.5
for selected names, 6.3
other factors for legality of named entities, 10.5
overloading. See: literals—enumeration, operators, resolution functions, signatures, subprograms.

P
package bodies
containing group declarations, 4.7
described, Clause 2, 2.6
syntax, 2.6
values of deferred constants, 4.3.1.1
visibility, 2.6
when unnecessary, 2.5
where used, 11.1
package declarations
deferred constants, 4.3.1.1
denoted by group declarations, 4.7
described, Clause 2, 2.5
scope of, 10.2
syntax, 2.5
where used, 11.1
packages
as declarative regions, 10.1
denoting items in, 6.3
elaboration of, 12.1
in instance names, 14.1
in path names, 14.1
predeﬁned
location in STD library, 11.2
STANDARD, 14.2
TEXTIO, 3.4.1, 14.3
scope of declarations in, 2.5
usage, Clause 2
parameter speciﬁcations
generate
where used, 9.7
loop
elaboration of, 12.5
restrictions on, 8.9
syntax, 8.9
where used, 8.9
parameters
constant, 2.1.1.1
ﬁle, 2.1.1.3
mechanisms for passing, 2.2, 4.3.2.2
of functions, 7.3.3
of procedures, 8.6
signal, 2.1.1.2, 12.3
variable, 2.1.1.1
parent
of subprogram, 2.2

Copyright © 2000 IEEE. All rights reserved.

279

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

passive statements, 1.1.3
path names, syntax of, 14.1
PATH_NAME attribute, 7.4.1, 14.1
portability issues, Annex C
physical types
described, 3.1.3, 3.1.3.1
elaboration of, 12.3.1.2
position numbers of values, 3.1.3
predeﬁned, 3.1.3.1
syntax, 3.1.3
unit names, 3.1.3
physical types. See also: literals—physical.
port clauses
elaboration of, 12.2.3, 12.2.4
syntax, 1.1.1
where used, 4.5, 9.1
port lists
containing interface signals, 4.3.2
deﬁned, 1.1.1
syntax, 1.1.1.2
where used, 1.1.1
port map aspect
default, 5.2.2
described, 5.2.1.2
elaboration of, 12.2.4
syntax, 5.2.1.2
usage, 5.2.1
where used, 5.2.1, 9.1, 9.6
ports
actual, 1.1.1.2
as signal sources, 4.3.1.2
associations, 1.1.1.2
connected, 1.1.1.2
described, 1.1.1.2
formal, 1.1.1.2, 5.2.2
as objects, 4.3
in binding indications, 5.2.1
in block headers, 9.1
in top-level design entity, Clause 12, 12.1
INOUT, 1.1.1.2
input, 1.1.1.2
linkage, 1.1.1.2
portability issues, Annex C
of unconstrained array types, 3.2.1.1
open, 1.1.1.2
output, 1.1.1.2
restrictions on mode, 1.1.1.2
scope of, 10.2
unassociated, 1.1.1.2
unconnected, 1.1.1.2, 4.3.2.2
where used, 4.3.2.2
ports. See also: interface objects.
POS attribute, 3.1.3, 14.1
POSITIVE subtype, 3.2.1.2
PRED attribute, 14.1
primaries
globally static, 7.4.2
locally static, 7.4.1

280

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

primary unit declarations
syntax, 3.1.3
where used, 3.1.3
procedure call statements
deﬁning parentage of subprograms, 2.2
described, 8.6
execution of, 8.6
syntax, 8.6
usage, 2.1, 9.3
where used, Clause 8, 9.3
procedure call statements. See also: concurrent procedure call statements.
procedure calls
portability issues, Annex C
procedures
execution of, 8.12
object classes for, 2.1.1
parents of, 8.1
persistence of variables in, 4.3.1.3
restrictions when invoked by concurrent procedure call statements, 9.3
syntax, 2.1
usage, Clause 2, 2.1
procedures. See also: return statements.
process declarative items
syntax, 9.2
where used, 9.2
process declarative part
syntax, 9.2
where used, 9.2
process statement part
syntax, 9.2
where used, 9.2
process statements
as declarative regions, 10.1
described, 9.2, 12.6.1
drivers in, 2.1.1.2
elaboration of, 12.4.4
execution of, 9.2, 9.5
labels within, Clause 8
syntax, 9.2
where used, 1.1.3, Clause 9
processes
communicating via ﬁle I/O, Annex C
execution of, 9.2.1, 12.6.4
initialization of, 12.6.4
interconnection via concurrent statements, Clause 9
kernel, 12.6
non-postponed, 9.2, 12.6.4
passive, 9.2
persistence of variables in, 4.3.1.3
postponed, 8.1, 9.2, 9.4, 9.5, 12.6.4
suspended, 8.1
pulse rejection limits, 3.1.3.1, 8.4

Q
QUIET attribute, 2.2, 4.3, 4.3.2, 12.6.2, 14.1
updating of signals having, 12.6.3

Copyright © 2000 IEEE. All rights reserved.

281

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

R
RANGE attribute, 13.9, 14.1
range constraints
bounds
for ﬂoating point types, 3.1.4
for integer types, 3.1.2
for physical types, 3.1.3
elaboration of, 2.3.1.3
globally static, 7.4.2
in subtype indications, 3.1
locally static, 7.4.1
syntax, 3.1
where used, 3.1.2, 3.1.3, 3.1.4, 4.2
ranges
bounds, 3.1
globally static, 7.4.2
index, 3.2.1
locally static, 7.4.1
null, 3.1
order, 3.1
syntax, 3.1
undeﬁned, 3.2.1
where used, 3.2.1
read-only mode. See: ﬁle types, operations.
REAL type
described, 3.1.4.1
REAL type. See also: literals—real.
record types
aggregates, 7.3.2
described, 3.2.2
elaboration of, 12.3.1.2
implicit ﬁle operations for, 3.4.1
scope of, 10.2
subprogram parameters of, 2.1.1.1
syntax, 3.2.2
where used, 3.2
records
elements of, 6.3
index ranges of array types, 3.2.1.1
relations
syntax, 7.1
where used, 7.1
report statements
described, 8.3
syntax, 8.3
where used, Clause 8
reserved words, 0.2.1
described, 13.9
resolution functions
described, 2.4
for resolved signals, 4.3.1.2
portability issues, Annex C
references to overloaded subprograms, 2.3, 10.5
restrictions with allocators, 7.3.6
usage, 4.2
where used, 4.2
resolution limit, 3.1.3.1

282

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

return statements
described, 8.12
restrictions, 8.12, 10.5
syntax, 8.12
where used, Clause 8, 8.12
REVERSE_RANGE attribute, 14.1
RIGHT attribute, 14.1
RIGHTOF attribute, 14.1

S
scalar types
described, Clause 3, 3.1, 3.2
implicit ﬁle operations for, 3.4.1
restrictions
on signals, 4.3.1.2
subprogram parameters of, 2.1.1.1
used as formal signal parameters, 2.1.1.2
scope
of block conﬁgurations, 1.3.1
of declarations, Clause 4, 10.2
of library clauses, 11.2
overlapping, 10.3
rules for elaboration, 12.3.1
secondary unit declarations
syntax, 3.1.3
where used, 3.1.3
selected signal assignments, 2.3.1
described, 9.5.2
syntax, 9.5.2
where used, 9.5
sensitivity clauses
application of rules for, 9.3, 9.5
described, 8.1
syntax, 8.1
where used, Clause 8, 8.1
sensitivity lists, 4.3.2
restrictions within process statements, 9.2
syntax, 8.1
where used, Clause 8, 8.1, 9.2
separators, 13.2
deﬁned, 13.2
sequence of statements
syntax, Clause 8
where used, 8.8
sequential statements
syntax, Clause 8
where used, 2.2, Clause 8, 9.2
sequential statements. See also: elaboration—dynamic, process statements.
SEVERITY_LEVEL type, 8.3
where used, 8.3
shared variable declarations
described, 4.3.1.3
portability issues, Annex C
syntax, 4.3.1.3
where used, 1.1.2, 1.2.1, 2.5, 2.6

Copyright © 2000 IEEE. All rights reserved.

283

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

signal assignment statements, 4.3.1.2
described, 8.4, 8.4.1
drivers affected by, 8.4.1
drivers associated with, 12.6.1
in procedures outside of processes, 8.4.1
restrictions on types in, 8.4
syntax, 8.4
targets of
composite types, 8.4.1
scalar types, 8.4.1
where used, Clause 8, 9.5
signal assignment statements. See also: concurrent signal assignment statements, conditional signal assignments, selected signal assignments.
signal declarations
described, 4.3.1.2
syntax, 4.3.1.2
where used, 1.1.2, 1.2.1, 2.5, 4.3.1
signal kind
syntax, 4.3.1.2
where used, 4.3.1.2
signal lists
syntax, 5.3
where used, 5.3
signal transforms
described, 9.5, 9.5.1
where used, 9.5, 9.5.1, 9.5.2
signals
active, 12.6.2
associations
with formal parameters, 2.1.1.2
with formal ports, 4.3.2.2
basic, 12.6.2
bus, 2.1.1.2, 2.4, 4.3.2
denoted by concurrent procedure call statements, 9.3
drivers of, 2.1.1.2, 12.6.1
events on, 12.6.2
explicit, 2.2, 4.3.1.2, 12.6.4
when updated, 12.6.2
GUARD, 9.1, 9.3, 9.4, 9.5, 12.6
effect on simulation cycle, 12.6.4
when updated, 12.6.3
guarded, 2.1.1.2, 2.2, 4.3.1.2, 4.3.2, 5.3
elaboration of, 12.3.2.3
usage, 8.4.1
implicit, 2.2, 4.3, 9.1, 12.6.4
when updated, 12.6.2, 12.6.3
index ranges of, 3.2.1.1
initial values of, 4.3.1.2
quiet, 12.6.2
registers, 12.6.2
when updated, 12.6.2
resolved, 2.4, 4.2, 4.3.1.2
restrictions within blocks, 12.3
sources of, 4.3.1.2
terminology, 4.3.1.2
unresolved, 4.3.1.2, 12.3.2
used as subprogram parameters, 2.1.1.2

284

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

values
default, 4.3.1.2
driving, 12.6.2
effective, 12.6.2
in blocks, 12.3
propagation of, 2.3.1, 12.6.2
when updated, 4.3.2
where used, 4.3.2.1, Clause 8
signatures
described, 2.3.2
syntax, 2.3.2
usage, 6.6
where used, 4.3.3.1, 5.1, 6.6
signs. See: operators—sign operators.
simple expressions, where used, 3.1
simple names, where used, 6.6
SIMPLE_NAME attribute, 14.1
simulation cycle. See: models, simulation of.
slices
null, 6.5
of constants, 4.3.1.1
of objects, 4.3
speciﬁcations
deﬁned, Clause 5
elaboration of, 12.3.2.1–12.3.2.3
STABLE attribute, 2.2, 4.3, 4.3.2, 12.6, 14.1
STANDARD package
contents of, 14.2
location in STD library, 11.2
usage, 0.2.2, 2.2, Clause 3, 3.1.1.1, 3.1.3.1, 3.2.1.2, 7.2, 7.5
statement transforms, 9.5
STRING type, 3.2.1.2, 4.3.1.4
where used, 8.3
string types. See also: literals—string.
structural designs, 9.6
subaggregates. See: aggregates.
subelements
of constants, 4.3.1.1
of objects, 4.3.1
of signals, 4.3.1.2
of variables, 4.3.1.3
terminology, Clause 3
usage, Clause 3
subprogram bodies
containing group declarations, 4.7
deﬁned in package, 2.6
described, 2.2
elaboration of, 12.3.1.1
execution, 2.2
labels within, Clause 8
syntax, 2.2
usage, Clause 2
where used, 1.1.2, 1.2.1, 2.2, 2.6, 9.2
subprogram calls
object classes for, 2.1.1
recursive, 2.1
to overloaded subprograms, 2.3, 10.5
usage, 2.2

Copyright © 2000 IEEE. All rights reserved.

285

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

subprogram declarations
described, 2.1, 2.2
elaboration of, 12.3.1.1, 12.5
scope of, 10.2
syntax, 2.1
usage, 2.1, 2.2
where used, 1.1.2, 1.2.1, 2.2, 2.5, 2.6, 9.2
subprogram declarative part
syntax, 2.2
usage, 5.1
where used, 2.2
subprogram kind
syntax, 2.2
usage, 2.2
where used, 2.2
subprogram speciﬁcations
described, 2.2
scope of, 10.2
where used, 2.2
subprogram statement part
syntax, 2.2
where used, 2.2
subprograms
as declarative regions, 10.1
conformance rules, 2.7
drivers in, 2.1.1.2
foreign, 2.2
of unconstrained array types, 3.2.1.1
overloaded, 2.3, 2.3.1
attributes of, 5.1
resolution of, 10.5
visibility rules for, 10.3
parents of, 2.2
usage, Clause 2
subtype declarations
described, 4.2
elaboration of, 12.3.1.3
syntax, 4.2
where used, 1.1.2, 1.2.1, 2.2, 2.5, 2.6, 9.2
subtype indications
containing index constraints, 3.2.1.1
containing range constraints, 3.1
direction, 4.2
elaboration of, 12.3.1.3, 12.3.1.5, 12.5
of incomplete types, 3.3.1
syntax, 4.2
where used, 3.2.1, 3.3, 4.2, 4.3.1.1–4.3.1.4, 4.3.2, 4.3.3, 7.3.6
subtypes
base type of, 4.2
bounds, 2.1.1.1
checking, 8.4.1
conversions, 3.2.1.1, 8.12
with array variables, 8.5.1
designated, 3.3
direction, 2.1.1.1
globally static, 7.4.2
locally static, 7.4.1
of function results, 2.1
operations, Clause 3

286

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

static, 7.4
usage, Clause 3
SUCC attribute, 14.1
symbols
assignment (:=), 4.3.1.1–4.3.1.3, 4.3.2
box (<>)
in group template declarations, 4.6
in undeﬁned ranges, 3.2.1
symbols. See also: characters, operators.

T
targets
array variables, 8.5.1
drivers for, 8.4.1
guarded, 9.5
of signal assignment statements, 8.4
of variable assignment statements, 8.5
syntax, 8.4
where used, 8.4, 8.5, 9.5.1, 9.5.2
terms
syntax, 7.1
where used, 7.1
TEXTIO package
contents of, 14.3
location in STD library, 11.2
usage, 3.4.1
time resolutions, portability issues, Annex C
TIME type, 3.1.3.1, 8.4.1
timeout clauses
described, 8.1
syntax, 8.1
where used, 8.1
TRANSACTION attribute, 2.2, 4.3, 4.3.2, 12.6, 14.1
initial value of signals, 12.6.4
updating of signals having, 12.6.3
transactions
null, 8.4.1
transactions. See also: drivers.
type conversions
as a basic operation, Clause 3
described, 7.3.5
implicit, 8.4, 8.5, 8.1.2, 10.5
in association lists
as actuals, 4.3.2.2
as formals, 4.3.2.2
restrictions
in signal associations, 4.3.2.2
on operands, 7.3.5
syntax, 7.3.5
usage
as globally static primaries, 7.4.2
as locally static primaries, 7.4.1
where used, 95

Copyright © 2000 IEEE. All rights reserved.

287

IEEE
Std 1076, 2000 Edition

IEEE STANDARD VHDL

type declarations
as declarative regions, 10.1
described, 4.1
elaboration of, 12.3.1.2
incomplete, 3.3.1
syntax of full, 4.1
where used, 1.1.2, 1.2.1, 2.2, 2.5, 2.6, 9.2
type marks
described, 4.2
in incomplete type declarations, 3.3.1
syntax, 4.2
where used, 2.3.2, 3.2.1, 4.2, 4.3.2.2, 4.4, 5.3, 7.3.5
type proﬁles, 2.3, 2.3.2
of enumeration literals, 3.1.1
types
anonymous, 3.1.2, 3.1.2.1, 3.1.3, 3.1.4, 4.1, 14.2
universal integer, 3.1.2, 3.2.1.1, 7.3.1, 7.3.5, 7.5, 8.8, 13.4, 14.2
universal real, 7.3.1, 7.3.5, 7.5, 13.4, 14.2
base type of, Clause 3, 4.1
character, 3.1.1.1
closely related, 7.3.5
compatibility with index constraints, 3.2.1.1
constraints, Clause 3
designated, 3.3
ﬂoating point, 7.5
in resolution functions, 2.4
in rules for overload resolution, 10.5
incomplete, 3.3.1
of expressions, 7.1
operations, Clause 3
portability issues, Annex C
predeﬁned
BIT, 14.2
BIT_VECTOR, 14.2
BOOLEAN, 14.2
CHARACTER, 14.2
FILE_OPEN_KIND, 14.2
FILE_OPEN_STATUS, 14.2
INTEGER, 14.2
NATURAL, 14.2
POSITIVE, 14.2
REAL, 14.2
SEVERITY_LEVEL, 14.2
STRING, 14.2
TIME, 14.2
terminology, 3.1
types. See also: names of speciﬁc type categories.

U
underlines, 13.3.1, 13.4.1, 13.4.2
universal types. See: types—anonymous.

288

Copyright © 2000 IEEE. All rights reserved.

LANGUAGE REFERENCE MANUAL

IEEE
Std 1076, 2000 Edition

use clauses
described, 10.4
scope of, 10.2
syntax, 10.4
usage, 2.5
with multiple mentions of a library unit, 11.3
with standard packages, 11.2
where used, 1.1.2, 1.2.1, 1.3, 1.3.1, 2.2, 2.5, 2.6, 9.2, 11.3

V
VAL attribute, 3.1.3, 14.1
VALUE attribute, 14.1
values
allowed as primaries, 7.1
conversion between abstract and physical, 3.1.3
variable assignment statements, 4.3.1.3
described, 8.5
restrictions on types in, 8.5
syntax, 8.5
where used, Clause 8
variable declarations
described, 4.3.1.3
syntax, 4.3.1.3
where used, 2.2, 4.3.1, 9.2
variables
default initial values, 4.3.1.3
explicit, 4.3.1.3
in kernel process, 12.6
index ranges of, 3.2.1.1
initial values of, 4.3.1.3
of access types, 3.3, 4.7
used as subprogram parameters, 2.1.1.1
where used, 4.3.2.2
variables. See also: shared variable declarations.
visibility
by selection, 10.3
direct, 10.3
hidden, 10.3
of block conﬁgurations, 1.3.1
of entity declarations, 5.2.2
of entity declarative items, 1.1.2
of generic constants, 1.1.1.1
of identiﬁers, Clause 4
of items in package bodies, 2.6
of logical names in library clauses, 11.2
of overloaded subprograms, 2.3
of ports, 1.1.1.2
of predeﬁned operations, 10.3
rules
for declarations, 10.3
for elaboration, 12.3.1
for identiﬁers, 10.3, 10.5
of order in which design units are analyzed, 11.4
within block conﬁgurations, 10.3

Copyright © 2000 IEEE. All rights reserved.

289

IEEE
Std 1076, 2000 Edition

W
wait statements
described, 8.1
implicit, 9.2
syntax, 8.1
usage
with concurrent procedure call statements, 9.3
with concurrent signal assignment statements, 9.5
where prohibited, 8.1, 9.2
where used, 8.1
wave transforms
syntax, 9.5.1
where used, 9.5.1
waveform elements
evaluation of, 8.4.1
null, restrictions on, 8.4.1, 9.5
syntax, 8.4.1
unaffected, 9.5
where used, 8.4
waveforms
conditional
syntax, 9.5.1
where used, 9.5, 9.5.1
projected output
described, 12.6.2
updating, 8.4.1
selected
syntax, 9.5.2
where used, 9.5.2
syntax, 8.4
where used, 8.4, 9.5.1, 9.5.2
WAVES standard, Annex D
write-only mode. See: ﬁle types, operations.

290

Copyright © 2000 IEEE. All rights reserved.

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.3
Linearized                      : Yes
Modify Date                     : 2001:01:12 11:51:50
Title                           : IEEE Standard VHDL Language Reference Manual - VHDL Language Reference Manual, IEEE Standard.
Subject                         : 
Author                          : IEEE
Creator                         : IEEE Copyright
Producer                        : Acrobat Distiller 4.05 for Macintosh
Create Date                     : 2001:01:12 11:51:43
Authors                         : 
Page Count                      : 299

EXIF Metadata provided by EXIF.tools

IEEE Standard VHDL Language Reference Manual Manual, Standard. 2000

Navigation menu

Versions of this User Manual:

Views

Navigation