IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL IEEE standard VHDL
Overview
Purpose and scope
The IEEE 1076.1 standard defines a hardware description language, known as VHDL-AMS, designed for the description and simulation of analog, digital, and mixed-signal systems This language extends the capabilities of the IEEE Std 1076-1993 (VHDL) by enabling users to write and simulate models that incorporate both analog and mixed-signal components.
The IEEE 1076.1 VHDL language reference document outlines the complete specifications, including both the unchanged elements of the base language and the newly defined extensions Specifically, IEEE Std 1076.1-1999 focuses solely on these extensions, with sections marked by change bars indicating content unique to this standard or modifications from IEEE Std 1076-1993 Text without change bars remains consistent with IEEE Std 1076-1993.
This document is designed for implementors of language-supporting tools and advanced users, focusing on formal definitions of language elements and constructs rather than introductory or tutorial content.
The IEEE 1076.1 language is an extension of the IEEE 1076 language (VHDL), ensuring that all valid IEEE Std 1076-1993 models are also valid under IEEE Std 1076.1-1999 Consequently, any simulation tool compliant with IEEE 1076.1 must yield identical results to those produced by an IEEE 1076 tool Despite this relationship, IEEE Std 1076-1993 and IEEE Std 1076.1-1999 will remain distinct standards Therefore, revisions to IEEE Std 1076-1993 will not automatically apply to IEEE Std 1076.1-1999, necessitating separate efforts to maintain synchronization and prevent inconsistencies between the two standards.
Standards used as references
This standard relies on IEEE Std 1076-1993 and incorporates definitions from IEEE Std 1076.2-1996, which outlines standard packages and mathematical functions applicable in VHDL design units.
IEEE Std 1076-1993, IEEE Standard VHDL Language Reference Model 1 IEEE Std 1076.2-1996, IEEE Standard VHDL Mathermatical Packages.
1 IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O Box 1331, Piscataway,
Std 1076.1-1999 IEEE STANDARD VHDL ANALOG
Structure and terminology of this document
This standard is organized into clauses, each of which focuses on some particular area of the language. Within each clause, individual constructs or concepts are discussed.
Each construct is introduced with a brief overview, followed by an explanation of its syntax through various grammatical productions Subsequently, a series of paragraphs elaborates on the construct's meaning and any associated restrictions in a narrative format.
This document uniquely employs the verb "is" consistently, in contrast to other IEEE standards that utilize "shall" for mandatory requirements and "may" for optional features.
In the context of VHDL standards, the term "is" carries mandatory weight, while "must" is preferred over "shall" to convey essential requirements For tool developers, "must" signifies a standard-imposed requirement that necessitates error enforcement if not adhered to VHDL model developers interpret "must" as a reflection of the language's inherent characteristics, requiring compliance with these constraints Similarly, VHDL model users view "must" as a guarantee that the model's characteristics naturally stem from the language definition, ensuring reliability based on the VHDL source text.
Finally, each clause may end with examples, notes, and references to other pertinent clauses.
VHDL descriptions are structured using a context-free syntax based on a simplified version of Backus-Naur Form (BNF) In this syntax, lowercase words presented in a roman font, including those with embedded underlines, represent specific syntactic categories, such as the term "formal_port_list."
When referring to a syntactic category, spaces replace underlines in the narrative description, such as "formal port list." Additionally, reserved words are indicated using boldface, for example, **array**.
Reserved words should only be utilized in specific locations as dictated by the syntax A production is defined by a left-hand side, the symbol “::=” (interpreted as “can be replaced by”), and a right-hand side The left-hand side represents a syntactic category, while the right-hand side outlines 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.
In the context of mixed-signal extensions as outlined in Std 1076.1-1999, a vertical bar is used to separate alternative items on the right side of a production, except when it follows an opening brace, where it represents itself For example, the definition of 'letter_or_digit' includes both 'letter' and 'digit' as choices, while 'choices' is defined as a series of 'choice' options separated by vertical bars.
In the first instance, an occurrence of “letter_or_digit” can be replaced by either “letter” or “digit.”
In programming syntax, the term "choices" can be substituted with a list of "choice" options, separated by vertical bars Additionally, square brackets denote optional elements on the right side of a production rule, indicating that the following two productions are equivalent: a return statement can either include an expression or stand alone as just a return.
In the context of syntax for signatures, it is important to note that the initial and terminal square brackets do not signify that the entire right-hand side is optional Braces are used to indicate repeated items on the right-hand side of a production, allowing for zero or more occurrences, similar to a left-recursive rule Consequently, the productions "term ::= factor { multiplying_operator factor }" and "term ::= factor | term multiplying_operator factor" are equivalent Additionally, if a syntactic category name begins with an italicized part, it is functionally equivalent to the name without that part, with the italicized portion providing semantic context For instance, both "type_name" and "subtype_name" are syntactically equivalent to "name." Lastly, the term "simple_name" refers to any identifier that represents a previously declared entity.
The meaning and limitations of a specific construct are outlined by narrative rules that follow the syntactic productions In these rules, italicized terms represent their definitions, while identifiers in uppercase refer to definitions found in the STANDARD package (see section 14.2).
In the context of semantic descriptions, the term "erroneous" refers to a poorly formed description that does not necessitate detection or reporting by implementations, as it is generally undetectable during language processing Conversely, an "error" indicates a similarly ill-formed description that implementations must identify and report to the user, making it synonymous with "illegal."
Std 1076.1-1999 IEEE STANDARD VHDL ANALOG
0.3.3 Front matter, examples, notes, references, and annexes
The introductory material preceding this clause, along with the five annexes and index that follow, is designed to assist users of this manual While the front matter, annexes, and index provide valuable orientation, they do not constitute part of the VHDL definition.
Certain clauses in this standard include examples, notes, and cross-references to other sections of the manual, all of which are positioned at the end of each clause Examples illustrate potential forms of the described constructs, with illegal examples italicized for clarity Notes highlight the consequences of the rules outlined in the clause or elsewhere, formatted as enumerated paragraphs in a smaller font to distinguish them from the main text Cross-references direct users to relevant clauses within the manual It is important to note that examples, notes, and cross-references do not constitute part of the VHDL definition.
AND MIXED-SIGNAL EXTENSIONS Std 1076.1-1999
Design entities and configurations
Entity declarations
An entity declaration establishes the interface between a design entity and its operational environment, while also outlining declarations and statements integral to the design entity This declaration can be utilized by multiple design entities, each possessing distinct architectures, thereby allowing it to represent a class of design entities that share a common interface The structure of an entity declaration is defined as: entity_declaration :: entity identifier is entity_header entity_declarative_part.
[ begin entity_statement_part ] end [ entity ] [ entity_simple_name ] ;
The entity header and its declarative section include items related to each design entity, defining its interface through the entity declaration Additionally, if included, the entity statement section comprises concurrent statements relevant to each design entity.
If a simple name appears at the end of an entity declaration, it must repeat the identifier of the entity declaration.
The entity header declares objects used for communication between a design entity and its environment. entity_header ::[ formal_generic_clause ]
Std 1076.1-1999 IEEE STANDARD VHDL ANALOG generic_clause :: generic ( generic_list ) ; port_clause :: port ( port_list ) ;
The formal generic clause outlines generic constants whose values can be influenced by the surrounding environment, while the formal port clause specifies the design entity's ports and their corresponding directions.
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).
— An entity declaration with port declarations only: entity Full_Adder is port (X, Y, Cin: in Bit; Cout, Sum: out Bit) ; end Full_Adder ;
— An entity declaration with generic declarations also: entity AndGate is generic
(Inputs: in Bit_Vector (1 to N);
Result: out Bit) ; end entity AndGate ;
— An entity declaration with neither: entity TestBench is end TestBench ;
The Multiplier entity is defined as a generic component with a bound of type REAL It features input ports for two quantities, Input1 and Input2, both of which are of type REAL, and an output port for the quantity Output, also of type REAL Additionally, it includes a signal port named OutOfBound, which outputs a BOOLEAN value.
Generics serve as a means for static information to be conveyed to a block from its surrounding environment This principle is applicable to both external blocks defined by design entities and internal blocks established by block statements The structure of a generic is defined as a list of generic interfaces.
The generics of a block are defined 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.
In a generic association list, the value of a generic constant can be defined by its corresponding actual If a formal generic lacks an associated actual—either due to being unassociated or because the actual is open—and a default expression is provided, this expression will determine the value of the generic However, it constitutes an error if neither an actual nor a default expression is specified for a formal generic.
In compliance with Std 1076.1-1999, the presence of the expression in the relevant interface element is crucial It constitutes an error if certain subelements of a composite formal generic are connected while others remain unconnected or unassociated.
Generics play a crucial role in defining various characteristics of a block, including structural, dataflow, and behavioral attributes, as well as serving as documentation They can specify essential parameters such as port sizes, the number of subcomponents, timing characteristics, and even physical attributes like temperature, capacitance, and location within a design.
Ports facilitate effective communication between a block and its surroundings, applicable to both external blocks defined by design entities and internal blocks defined by block statements This includes instances equivalent to component instantiation and generate statements, as outlined in section 9.7.
The ports of a block are outlined by a list of port interfaces, as detailed in section 4.3.2.1 Each element within this list specifies a formal port, which can be categorized as a signal port, quantity port, or terminal port.
To enable communication between blocks, a block's signal, terminal, or quantity ports can be linked to corresponding signals, terminals, or quantities in their operational environment Additionally, signal and quantity ports can be assigned expressions to provide constant driving values, requiring these ports to be in input mode A signal port represents a signal, a terminal port represents a terminal, and a quantity port represents a quantity, allowing formal ports of a block to be linked to actual ports of an inner block The port, signal, quantity, terminal, or expression linked to a formal port is referred to as its actual counterpart If the actual is not an expression, it must have a static name; if it is an expression, it must be a globally static expression Notably, terminal ports cannot be linked to an expression.
Once a detailed description is finalized (refer to Clause 12), specific restrictions come into play when a formal port is linked to an actual port These restrictions vary based on the mode outlined in section 4.3.2 For instance, if the formal port operates in the 'in' mode, particular conditions must be adhered to.
— If the formal port is a signal port, the associated actual may only be a signal port of mode in, inout, or buffer.
— If the formal port is a quantity port, the associated actual may only be a quantity port of mode in or out. b) For a formal port of mode out,
— If the formal port is a signal port, the associated actual may only be a signal port of mode out, or inout.
When dealing with formal ports in a system, it's essential to note that a formal port designated as a quantity port can only correspond to an actual port of mode out Similarly, a formal port set to mode inout must be linked to an actual port of the same mode For ports defined as buffer, the associated actual port can only be of mode buffer Lastly, a formal port classified as linkage can be connected to an actual port of any mode.
A buffer port can have only one source, as outlined in sections 4.3.1.2 and 4.3.2 Additionally, once a description is fully developed, any action linked to a formal buffer port is limited to a single source.
Std 1076.1-1999 IEEE STANDARD VHDL ANALOG
A formal port is considered connected when associated with an actual port, signal, terminal, quantity, or expression Conversely, it is deemed unconnected if linked to the reserved word "open." An "in" mode signal or quantity port can be unconnected only if it has a default expression, while ports of other modes can be unconnected as long as they are not of an unconstrained array type Additionally, a terminal port may be unconnected unless it has an unconstrained array nature Errors arise when some subelements of a composite formal port are connected while others are unconnected or unassociated, and it is also an error for any quantity to be associated with multiple "out" mode formals.
Architecture bodies
An architecture body outlines the framework of a design entity, detailing the connections between inputs, outputs, quantities, and terminals It can be represented through various forms such as structure, dataflow, equations, or behavior, and may be either partial or complete The syntax for defining an architecture body includes an identifier for the entity, a declarative part, and a statement part, concluding with optional architecture specifications.
The identifier defines the simple name of the architecture body; this simple name distinguishes architecture bodies associated with the same entity declaration.
The entity name specifies the declaration that defines the interface of a design entity It is essential for both the entity declaration and its corresponding architecture body to be located within the same library for a specific design entity.
If a simple name appears at the end of an architecture body, it must repeat the identifier of the architecture body.
Multiple architectural bodies can correspond to a single entity declaration, each defining a distinct body while maintaining the same interface Collectively, these bodies, along with the entity declaration, represent various design entities that share the same interface.
It is important to note that two architecture bodies linked to different entity declarations can share the same simple name, even when both architecture bodies and their respective entity declarations exist within the same library.
The architecture declarative part includes declarations of items accessible within the designated block of the design entity, consisting of various block declarative items such as subprogram declarations.
Clause 4 outlines the different types of declarations, while Clause 5 details the various kinds of specifications Additionally, Clause 10 explains the use clause, which allows externally defined names to be visible within the block.
NOTE—The declarative part of an architecture decorated with the 'FOREIGN attribute is subject to special elaboration rules See 12.3.
The architecture statement section outlines the internal structure and functioning of the design entity's block It encompasses various types of statements, including simultaneous and concurrent statements, which detail how the components interact and operate within the defined architecture.
The architecture statement section outlines concurrent and simultaneous statements that operate asynchronously For detailed descriptions of the different types of concurrent statements, refer to Clause 9, while Clause 15 covers the various kinds of simultaneous statements.
— A body of entity Full_Adder: architecture DataFlow of Full_Adder is signal A,B: Bit; begin
Cout 10 ns, D=>DataBus, C=>Clk1);
Check (Hold=>5 ns, D=>DataBus, C=>Clk2);
Ambiguous if the base type of DataBus is the same type as the base type of Clk.
1—The notion of parameter and result type profile does not include parameter names, parameter classes, parameter modes, parameter subtypes, or default expressions or their presence or absence.
Ambiguities can occur when the actual parameters of an overloaded subprogram are themselves overloaded function calls, literals, or aggregates, and may also arise when multiple overloaded subprograms from different packages are visible These ambiguities can typically be resolved by using qualified expressions for some or all actual parameters and the result, or by expressing the subprogram's name more explicitly as an expanded name.
To overload an operator, a function must be declared with a designator that is an operator symbol The operator symbol used in the declaration must match one of the operators specified in the operator classes outlined in section 7.2.
A unary operator's subprogram specification requires one parameter, while a binary operator's specification necessitates two parameters In the case of the binary operator, the first parameter corresponds to the left operand and the second parameter corresponds to the right operand for each usage.
For each of the operators “+” and “–”, overloading is allowed both as a unary operator and as a binary operator.
Overloading the equality operator does not influence the choice selection in a case statement within a selected signal assignment, nor does it impact the propagation of signal values.
A user-defined operator that shares the same symbol as a short-circuit operator does not operate in a short-circuit manner Instead, when this operator is called, both arguments are evaluated fully before the function is executed.
3—Functions that overload operator symbols may also be called using function call notation rather than operator nota- tion This statement is also true of the predefined 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 ; signal Q,R,S: MVL ;
A signature differentiates overloaded subprograms and enumeration literals by their parameter and result type profiles It can be utilized in attribute names, entity designators, or alias declarations The syntax for a signature is defined as: signature ::= [ [ type_mark { , type_mark } ] [ return type_mark ] ].
A signature matches the parameter and result type profile of a subprogram if it meets all specified conditions.
— The number of type marks prior to the reserved word return, if any, matches the number of formal parameters of the subprogram.
In a subprogram, the base type indicated by the type mark of the signature must match the base type of the corresponding formal parameter at each parameter position.
In programming, the presence of the reserved word "return" indicates that the subprogram is a function, and the base type of the type mark following "return" in the signature must match the base type of the function's return type Conversely, if the "return" keyword is absent, the subprogram is classified as a procedure.
A signature aligns with the parameter and result type profile of an enumeration literal when it corresponds to the parameter and result type profile of the subprogram equivalent to that enumeration literal, as defined in section 3.1.1.
Example: attribute BuiltIn of "or" [MVL, MVL return MVL]: function is TRUE;
Because of the presence of the signature, this attribute specification
decorates only the "or" function defined in the previous clause. attribute Mapping of JMP [return OpCode] : literal is "001";
Resolution functions
A resolution function determines how to combine values from multiple sources of a specific signal into a single value These functions are linked to signals that need resolution by including the resolution function's name in the signal declaration or its subtype declaration A signal that has an associated resolution function is referred to as a resolved signal.
A resolution function must be a pure function with a single input parameter of class constant, specifically a one-dimensional, unconstrained array of the resolved signal's element type Additionally, the return value of the function must match the signal type If these criteria are not met, errors will arise at the subtype indication where the resolution function is named.
The resolution function of a resolved signal defines its value based on inputs from various sources For composite types, the resolution functions of subelements do not influence the resolved value An error occurs when a resolved signal has more connected sources than the elements in the index type of the unconstrained array defining the resolution function parameter.
Resolution functions are automatically called during each simulation cycle when their corresponding resolved signals are active These functions receive an array of values derived from the active sources of the resolved signal, excluding any drivers that are off due to null transactions In instances where a signal is declared as a bus, the resolution function may receive a null array as an input if all sources are drivers that are off In this scenario, the function returns a value that reflects the state of the bus when no source is actively driving it.
Example: function WIRED_OR (Inputs: BIT_VECTOR) return BIT is constant FloatValue: BIT := '0'; begin if Inputs'Length = 0 then
The function WIRED_OR processes input values, returning a FloatValue when all bus drivers are inactive It iterates through the range of Inputs, returning '1' if any input equals '1' If no conditions are met, it defaults to returning '0'.
Package declarations
A package declaration outlines the interface of a package, allowing its scope to extend to other design units The syntax for a package declaration includes the package identifier followed by the package declarative part, concluding with the keywords "end" and optionally "package" or "package_simple_name." The package declarative part consists of multiple package declarative items, which can include subprogram declarations.
If a simple name appears at the end of the package declaration, it must repeat the identifier of the package declaration.
Items declared within a package become accessible in any design unit where the package name is visible Additionally, these items can be directly accessed through an appropriate use clause.
NOTE—Not all packages will have a package body In particular, a package body is unnecessary if no subprograms or deferred constants are declared in the package declaration.
The VHDL package declaration named "TimeConstants" defines several time constants essential for digital circuit design It includes constants such as tPLH (10 ns), tPHL (12 ns), tPLZ (7 ns), tPZL (8 ns), tPHZ (8 ns), and tPZH (9 ns), which represent various timing parameters for signal transitions This package does not require a package body, making it a streamlined way to manage timing constants in VHDL code.
The TriState package is designed to define a type called Tri, which can hold values '0', '1', 'Z', and 'E' It includes two functions: BitVal, which converts a Tri value to a Bit, and TriVal, which converts a Bit back to a Tri Additionally, the package defines a TriVector type, an array of Tri values indexed by a natural range, and features a Resolve function that processes an array of TriVector sources to return a single Tri value.
Package bodies
A package body specifies the implementations of subprograms and the values of deferred constants declared in the package's interface It follows the syntax: `package body package_simple_name is package_body_declarative_part end [ package body ] [ package_simple_name ];` The declarative part of the package body consists of one or more package body declarative items, which include subprogram declarations.
In a package body, the simple name at the beginning must match the package identifier, and if a simple name is present at the end of the package body, it should also correspond to the identifier stated in the package declaration.
A package body can include additional declarative items alongside subprogram bodies and constant declarations, which aid in defining the subprograms declared in the interface However, any items declared within the package body remain inaccessible outside of it.
In package declarations that include a deferred constant declaration, it is essential for a constant declaration with the same identifier to be present in the corresponding package body This declaration is referred to as the full declaration of the deferred constant Additionally, the subtype indication in the full declaration must align with the subtype indication specified in the deferred constant declaration.
In a package declaration featuring a deferred constant, the name representing that constant can only be used in the default expression for a local generic, local port, or formal parameter before the full declaration is completed The language does not define the outcome of evaluating an expression that references a deferred constant prior to the elaboration of its corresponding full declaration.
The package body TriState defines a function BitVal that converts a Tri value to a Bit by utilizing a constant Bit_Vector It returns the corresponding Bit from the specified position of the Tri value Additionally, the TriVal function converts a Bit back to a Tri, leveraging the Bit's position The Resolve function processes a TriVector, initializing a variable to 'Z' and iterating through the sources to determine the first non-'Z' value, ensuring accurate resolution of the Tri states.
V := Sources(i); else return 'E'; end if; end if; end loop; return V; end; end package body TriState ;
Conformance rules
Whenever the language rules either require or allow the specification of a given subprogram to be provided in more than one place, the following variations are allowed at each place:
— 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 substituted with an expanded name, provided that the simple name serves as the selector and both instances are defined by the same declaration.
Two subprogram specifications are considered to conform if they consist of the same sequence of lexical elements, excluding comments and permitted variations Additionally, the visibility rules must assign the same meaning to corresponding lexical elements in both specifications.
Conformance is likewise defined for subtype indications in deferred constant declarations.
A simple name can be substituted with an expanded name, even when the simple name serves as the prefix of a chosen name For instance, if Q is declared within P, then Q.R can be replaced by P.Q.R.
2—The subprogram specification of an impure function is never conformant to a subprogram specification of a pure function.
3—The following specifications do not conform since they are not formed by the same sequence of lexical elements: procedure P (X,Y : INTEGER) procedure P (X: INTEGER; Y : INTEGER)