?? 1076_2.html
字號:
<html>
<head>
<title>VHDL LRM-Introduction</title>
</head>
<body>
<h1><a name="2">Section 2</a></h1>
<a href="../../HTML/HOMEPG.HTM"><img src="HP.GIF" border=0></a>
<a href="1076_TOC.HTM"><img src="TOP.GIF" BORDER=0></a>
<a href="1076_1.HTM"><img src="LEFT.GIF" BORDER=0></a>
<a href="1076_3.HTM"><img src="RIGHT.GIF" BORDER=0></a>
<HR>
<h1>Subprograms and packages</h1>
<p>Subprograms define algorithms for computing values or exhibiting behavior. They may be used as computational resources to convert between values of different types, to define the resolution of output values driving a common signal, or to define portions of a process. Packages provide a means of defining these and other resources in a way that allows different design units to share the same declarations.
<p>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 <i>pure</i> functions, return the same value each time they are called with the same values as actual parameters; the remainder,<i>impure</i> 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 definition of a subprogram can be given in two parts: a subprogram declaration defining its calling conventions, and a subprogram body defining its execution.
<p>Packages may also be defined in two parts. A package declaration defines 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.
<h2><a name="2.1"> <a href = "1076_2.HTM#2.1"> 2.1 </a> Subprogram declarations</a></h2>
<p>A subprogram declaration declares a procedure or a function, as indicated by the appropriate reserved word.
<pre> subprogram_declaration ::=
subprogram_specification ;
subprogram_specification ::=
<b>procedure</b> designator [ ( formal_parameter_list ) ]
| [ <b>pure</b> | <b>impure</b> ] <b>function</b> designator [ ( formal_parameter_list ) ]
<b>return</b> type_mark
designator ::= identifier | operator_symbol
operator_symbol ::= string_literal
</pre>
<p>The specification of a procedure specifies its designator and its formal parameters(if any). The specification of a function specifies its designator, its formal parameters (if any), the subtype of the returned value (the <i>result subtype</i>), and whether or not the function is pure. A function is <i>impure</i> if its specification contains the reserved word <b>impure</b>;otherwise, it is said to be <i>pure</i>. A procedure designator is always an identifier. A function designator is either an identifier or an operator symbol. A designator that is an operator symbol is used for the overloading of an operator (see <a href = "1076_2.HTM#2.3.1"> 2.3.1 </a> ). The sequence of characters represented by an operator symbol must be an operator belonging to one of the classes of operators defined in <a href = "1076_7.HTM#7.2"> 7.2 </a> . Extra spaces are not allowed in an operator symbol, and the case of letters is not significant.
<p>NOTE--All subprograms can be called recursively.
<h3><a name="2.1.1"> <a href = "1076_2.HTM#2.1.1"> 2.1.1 </a> Formal parameters</a></h3>
<p>The formal parameter list in a subprogram specification defines the formal parameters of the subprogram.
<pre> formal_parameter_list ::= <i>parameter</i>_interface_list
</pre>
<p>Formal parameters of subprograms may be constants, variables, signals, or files. In the first 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 files, the parameters have no mode.
<p>For those parameters with modes, the only modes that are allowed for formal parameters of a procedure are <b>in</b>, <b>inout</b>, and <b>out</b>. If the mode is <b>in</b> and no object class is explicitly specified, <b>constant</b> is assumed. If the mode is <b>inout</b> or <b>out</b>, and no object class is explicitly specified, <b>variable</b> is assumed.
<p>For those parameters with modes, the only mode that is allowed for formal parameters of a function is the mode <b>in</b> (whether this mode is specified explicitly or implicitly). The object class must be <b>constant</b>,<b>signal</b>, or <b>file</b>. If no object class is explicitly given,<b>constant</b> is assumed.
<p>In a subprogram call, the actual designator (see <a href = "1076_4.HTM#4.3.2.2"> 4.3.2.2 </a> ) associated with a formal parameter of class <b>signal</b> must be a signal. The actual designator associated with a formal of class <b>variable</b> must be a variable. The actual designator associated with a formal of class <b>constant</b> must be an expression. The actual designator associated with a formal of class <b>file</b> must be a file.
<p>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.
<h4><a name="2.1.1.1"> <a href = "1076_2.HTM#2.1.1.1"> 2.1.1.1 </a> Constant and variable parameters</a></h4>
<p>For parameters of class <b>constant</b> or <b>variable</b>, 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.
<p>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 <b>in</b> or <b>inout</b>, 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 <a href = "1076_4.HTM#4.3.2.2"> 4.3.2.2 </a> ), 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 <b>inout </b>or <b>out</b>, 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.
<p>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 <b>out </b>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 define 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.
<p>For a formal parameter of a constrained array subtype of mode <b>in</b> or <b>inout</b>, 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 <b>out</b> or <b>inout</b>,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.
<p>
<h4>NOTES</h4>
<p>1--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 undefined after updating the actual other than by updating the formal. A description using such an undefined value is erroneous.
<p>2--As a consequence of the parameter-passing conventions for variables, if a procedure is called with a shared variable (see <a href = "1076_4.HTM#4.3.1.3"> 4.3.1.3 </a> ) as an actual to a formal variable parameter of modes <b>inout</b> or <b>out</b>, the shared variable may not be updated until the procedure completes its execution. Furthermore, a formal variable parameter with modes <b>in</b> or <b>inout</b> may not reflect updates made to a shared variable associated with it as an actual during the execution of the subprogram, including updates made to the actual during the execution of a wait statement within a procedure.
<h4><a name="2.1.1.2"> <a href = "1076_2.HTM#2.1.1.2"> 2.1.1.2 </a> Signal parameters</a></h4>
<p>For a formal parameter of class <b>signal</b>, references to the signal, the driver of the signal, or both, are passed into the subprogram call.
<p>For a signal parameter of mode <b>in</b> or <b>inout</b>, 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.
<p>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.
<p>A process statement contains a driver for each actual signal associated with a formal signal parameter of mode <b>out</b> or <b>inout</b> in a subprogram call. Similarly, a subprogram contains a driver for each formal signal parameter of mode <b>out</b> or <b>inout</b> declared in its subprogram specification.
<p>For a signal parameter of mode <b>inout </b>or <b>out</b>, 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.
<p>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.
<p>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.
<p>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. It is also an error if the mode of the formal is <b>in</b> or <b>inout</b> and if the value of each element of the actual array does not belong to the element subtype of the formal.
<p>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 <b>bus</b>(see <a href = "1076_4.HTM#4.3.2"> 4.3.2 </a> ).
<p>NOTE--It is a consequence of the preceding rules that a procedure with an <b>out</b> or <b>inout</b> 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.
<h4><a name="2.1.1.3"> <a href = "1076_2.HTM#2.1.1.3"> 2.1.1.3 </a> File parameters</a></h4>
<p>For parameters of class <b>file</b>, references to the actual file are passed into the subprogram. No particular parameter-passing mechanism is defined 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 file type and that association element contains a conversion function or type conversion. It is also an error if a formal of a file type is associated with an actual that is not of a file type.
<p>At the beginning of a given subprogram call, a file parameter is open (see <a href = "1076_3.HTM#3.4.1"> 3.4.1 </a> ) if and only if the actual file 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 file associated with (see <a href = "1076_3.HTM#3.4.1"> 3.4.1 </a> ) an open file parameter are the same as, respectively, the access mode of and the external file associated with the actual file object associated with the given parameter in the subprogram call.
<p>At the completion of the execution of a given subprogram call, the actual file object associated with a given file 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 file associated with an open actual file object associated with a given file parameter are the same as, respectively, the access mode of and the external file associated with the associated formal parameter.
<h2><a name="2.2"> <a href = "1076_2.HTM#2.2"> 2.2 </a> Subprogram bodies</a></h2>
<p>A subprogram body specifies the execution of a subprogram.
<pre> subprogram_body ::=
subprogram_specification <b>is</b>
subprogram_declarative_part
<b>begin</b>
subprogram_statement_part
<b>end</b> [ subprogram_kind ] [ designator ] ;
subprogram_declarative_part ::=
{ subprogram_declarative_item }
subprogram_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
subprogram_statement_part ::=
{ sequential_statement }
subprogram_kind ::= <b>procedure</b> | <b>function</b>
</pre>
<p>The declaration of a subprogram is optional. In the absence of such a declaration,the subprogram specification of the subprogram body acts as the declaration. For each subprogram declaration, there must be a corresponding body. If both a declaration and a body are given, the subprogram specification of the body must conform (see <a href = "1076_2.HTM#2.7"> 2.7 </a> ) to the subprogram specification of the declaration. Furthermore, both the declaration and the body must occur immediately within the same declarative region (see <a href = "1076_10.HTM#10.1"> 10.1 </a> ).
<p>If a subprogram kind appears at the end of a subprogram body, it must repeat the reserved word given in the subprogram specification. If a designator appears at the end of a subprogram body, it must repeat the designator of the subprogram.
<p>It is an error if a variable declaration in a subprogram declarative part declares a shared variable. (See <a href = "1076_4.HTM#4.3.1.3"> 4.3.1.3 </a> and <a href = "1076_8.HTM#8.1.4"> 8.1.4 </a> .)
<p>A <i>foreign subprogram</i> is one that is decorated with the attribute 'FOREIGN, defined in package STANDARD (see <a href = "1076_14.HTM#14.2"> 14.2 </a> ). 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.
<p>Excepting foreign subprograms, the algorithm performed by a subprogram is defined by the sequence of statements that appears in the subprogram statement part. For a foreign subprogram, the algorithm performed is implementation defined.
<p>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-defined action occurs. Upon completion of the body or implementation-dependent action, return is made to the caller (and any necessary copying back of formal to actual parameters occurs).
<p>A process or a subprogram is said to be a <i>parent</i> 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.
<p>An <i>explicit signal</i> is a signal other than an implicit signal GUARD or other than one of the implicit signals defined by the predefined attributes 'DELAYED, 'STABLE, 'QUIET, or 'TRANSACTION. The <i>explicit ancestor</i> of an implicit signal is found as follows. The implicit signal GUARD has no explicit ancestor. An explicit ancestor of an implicit signal defined by the predefined attributes 'DELAYED, 'STABLE, 'QUIET, or 'TRANSACTION is the signal found by recursively examining the prefix of the attribute. If the prefix denotes an explicit signal, or a member (see <a href = "1076_3.HTM"> Section 3</a>) of an explicit signal then that is the explicit ancestor of the implicit signal. Otherwise, if the prefix is one of the implicit signals defined by the predefined attributes 'DELAYED, 'STABLE,'QUIET, or 'TRANSACTION, this rule is recursively applied. If the prefix is an implicit signal GUARD, then the signal has no explicit ancestor.
<p>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 <a href = "1076_10.HTM#10.1"> 10.1 </a> ) 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 file object(see <a href = "1076_4.HTM#4.3.1.4"> 4.3.1.4 </a> ) or to a shared variable (see <a href = "1076_4.HTM#4.3.1.3"> 4.3.1.3 </a> ).
<p>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 file object.
<p>A pure function must not be the parent of an impure function.
<p>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.
<p><i>Example:</i>
<pre>-- The declaration of a foreign function subprogram:
<b>package</b> P <b>is</b>
<b>function</b> F <b>return</b> INTEGER;
<b>attribute</b> FOREIGN <b>of</b> F: <b>function</b> <b>is</b> "implementation-dependent information";
<b>end</b> <b>package</b> P;
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -