Draft Standard VHDL Synthesis Package February 13, 1995 (date to be deleted from final version) 1. Overview 1.1 Scope This standard defines standard practices for synthesizing binary digital electronic circuits from VHDL source code. It covers the following areas: a) The hardware interpretation of values belonging to the BIT and BOOLEAN types defined by IEEE Std 1076-1993 and to the STD_ULOGIC type defined by IEEE Std 1164-1993. b) A function (STD_MATCH) that provides "don't care" or "wild card" testing of values based on the STD_ULOGIC type. c) Standard functions for representing sensitivity to the edge of a signal. d) Two packages that define vector types for representing signed and unsigned arithmetic values, and that define arithmetic, shift, and type conversion operations on those types. RATIONALE: A paragraph that begins with the word "RATIONALE:" is not part of the standard but is included in the draft for convenience in revisiting decisions already made. Such paragraphs will be deleted from the published standard. 1.2 Terminology The word shall indicates mandatory requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted (shall equals is required to). The word should is used to indicate that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain course of action is deprecated but not prohibited (should equals is recommended that). The word may indicates a course of action permissible within the limits of the standard (may equals is permitted). A synthesis tool is said to accept a VHDL construct if it allows that construct to be legal input; it is said to interpret the construct (or to provide an interpretation of the construct) by producing something that represents the construct. A synthesis tool is not required to provide an interpretation for every construct that it accepts, but only for those for which an interpretation is specified by this standard. 1.3 Conventions This standard uses the following conventions: a) The body of the text of this standard uses boldface to denote VHDL reserved words (such as downto) and upper case to denote all other VHDL identifiers (such as RANGE or FOO). b) The text of the VHDL packages defined by this standard, as well as the text of VHDL examples and code fragments, is represented in a fixed-width font. All such text represents VHDL reserved words as lower case text and all other VHDL identifiers as upper case text. c) In the body of the text, italics denote words or phrases that are being defined by the paragraph in which they occur. d) VHDL code fragments not supported by this standard are denoted by an italic fixed-width font. 2. References This standard shall be used in conjunction with the following publications. When the following standards are superseded by an approved revision, the revision shall apply. IEEE Std 1076-1993, IEEE Standard VHDL Language Reference Manual. IEEE Std 1164-1993, IEEE Standard Multivalue Logic System for VHDL Model Interoperability (Std_logic_1164). 3. Definitions 3.1 argument: An expression occurring as the actual value in a function call or procedure call. 3.2 arithmetic operation: An operation for which the VHDL operator is +, -, *, /, mod, rem, abs, or **. 3.3 assignment reference: The occurrence of a literal or other expression as the waveform element of a signal assignment statement or as the right-hand side expression of a variable assignment statement. 3.4 don't care value: The enumeration literal '-' of the type STD_ULOGIC defined by IEEE Std 1164- 1993. 3.5 equality relation: A VHDL relational expression in which the relational operator is =. 3.6 high-impedance value: The enumeration literal 'Z' of the type STD_ULOGIC defined by IEEE Std 1164-1993. 3.7 inequality relation: A VHDL relational expression in which the relational operator is /=. 3.8 logical operation: An operation for which the VHDL operator is and, or, nand, nor, xor, xnor, or not. 3.9 metalogical value: One of the enumeration literals 'U', 'X', 'W', or '-' of the type STD_ULOGIC defined by IEEE Std 1164-1993. 3.10 ordering relation: A VHDL relational expression in which the relational operator is <, <=, >, or >=. 3.11 shift operation: An operation for which the VHDL operator is sll, srl, sla, sra, rol, or ror. 3.12 standard logic type: The type STD_ULOGIC defined by IEEE Std 1164-1993, or any type derived from it, including in particular one-dimensional arrays of STD_ULOGIC or of one of its subtypes. 3.13 synthesis tool: Any system, process, or tool that interprets VHDL source code as a description of an electronic circuit in accordance with the terms of this standard and derives an alternate description of that circuit. 3.14 user: A person, system, process, or tool that generates the VHDL source code that a synthesis tool processes. 3.15 well-defined: Containing no metalogical or high-impedance element values. 4. Interpretation of the standard logic types This section defines how a synthesis tool shall interpret values of the standard logic types defined by IEEE Std 1164-1993 and of the BIT and BOOLEAN types defined by IEEE Std 1076-1993. Simulation tools, however, shall continue to interpret these values according to the standards in which the values are defined. 4.1 The STD_LOGIC_1164 values IEEE Std 1164-1993 defines the standard logic type: type STD_ULOGIC is ( 'U', -- Uninitialized 'X', -- Forcing Unknown '0', -- Forcing 0 '1', -- Forcing 1 'Z', -- High Impedance 'W', -- Weak Unknown 'L', -- Weak 0 'H', -- Weak 1 '-' -- Don't care ); The logical values '1', 'H', '0', and 'L' are interpreted as representing one of two logic levels, where each logic level represents one of two distinct voltage ranges in the circuit to be synthesized. IEEE Std 1164-1993 also defines a resolution function named RESOLVED and a subtype STD_LOGIC that is derived from STD_ULOGIC by using RESOLVED. The resolution function RESOLVED treats the values '0' and '1' as forcing values that override the weak values 'L' and 'H' when multiple sources drive the same signal. The values 'U', 'X', 'W', and '-' are metalogical values; they define the behavior of the model itself rather than the behavior of the hardware being synthesized. The value 'U' represents the value of an object before it is explicitly assigned a value during simulation; the values 'X' and 'W' represent forcing and weak values, respectively, for which the model is not able to distinguish between logic levels. The value '-' is also called the don't care value. This standard treats it in the same way as the other metalogical values except when it is furnished as an argument to the STD_MATCH functions in the IEEE.NUMERIC_STD package. The STD_MATCH functions use '-' to implement a "match all" or "wild card" matching. The value 'Z' is called the high impedance value, and represents the condition of a signal source when that source makes no effective contribution to the resolved value of the signal. 4.2 Statically valued expressions Wherever a synthesis tool accepts a reference to a statically valued named constant, it shall treat that constant as the equivalent of the associated static expression. RATIONALE: We had considered saying that a synthesis tool replaces all statically valued expressions (that it accepts) by the equivalent literals, but this goes beyond what any synthesis tool that we're aware of currently does, and it seems wise to limit our remarks to what synthesis tools actually do. The phrase "statically valued" is included so as not to require replacement of named constants declared in subprograms, since they are not statically valued. 4.3 Interpretation of logic values This clause describes the interpretations of logic values occurring as literals (or in literals) after a synthesis tool has replaced named constants by their corresponding values. 4.3.1 Interpretation of the forcing and weak values ('0', '1', 'L', 'H', FALSE, TRUE) A synthesis tool shall interpret the following values as representing a logic value 0: - The BIT value '0'. - The BOOLEAN value FALSE. - The STD_ULOGIC values '0' and 'L'. It shall interpret the following values as representing a logic value 1: - The BIT value '1'. - The BOOLEAN value TRUE. - The STD_ULOGIC value '1' and 'H'. The standard makes no restriction as to the interpretation of the relative strength of values. RATIONALE: Some current synthesis tools treat 'L' and 'H' as equivalent to '0' and '1', but future tools may interpret them in a manner that recognizes that they have a different strength than the forcing values. Until a consensus emerges as to how to handle them, it is better for this standard not to restrict their usage. 4.3.2 Interpretation of the metalogical values ('U', 'W', 'X', '-') 4.3.2.1 Metalogical values in relational expressions If the VHDL source code includes an equality relation (=) for which one operand is a static metalogical value and for which the other operand is not a static value, a synthesis tool shall interpret the equality relation as equivalent to the BOOLEAN value FALSE. If one operand of an equality relation is a vector, and one element of that vector is a static metalogical value, a synthesis tool shall interpret the entire equality relation as equivalent to the BOOLEAN value FALSE. RATIONALE: A non-static one-bit value is synthesized as some real value, and hence in a real circuit always has either a high or low value. Hence a comparison of a non-static value to a literal metalogical value would never be true in a real circuit. Such an equality test is generally used to check for an error or unexpected value, and hence should be treated as FALSE in synthesizing a real circuit. RATIONALE: The don't care value '-' is treated in the same way as a metalogical value, rather than as a "wild card," because the VHDL relational operators are implicitly defined by the STD_LOGIC_1164 package, and those definitions do not treat '-' as a wild card. Wild card behavior for '-' is provided by the STD_MATCH function defined by this standard. A synthesis tool shall interpret an inequality relation (/=) for which one operand is or contains a static metalogical value, and for which the other operand is not a static value, as equivalent to the BOOLEAN value TRUE. A synthesis tool shall treat an ordering relation for which at least one operand is or contains a static metalogical value as an error. RATIONALE: An ordering relation in which both operands contain static metalogical values may actually be unambiguous. For example, for simulation purposes, the expression "0X10" >= "00X0" is definitely TRUE while the expression "01XX" < "00XX" is definitely FALSE. However, neither expression has a clear purpose for synthesis, so this standard requires a synthesis tool to treat them as errors, just as in the case when only one operand contains a static metalogical value. 4.3.2.2 Metalogical values in a choice in a case statement If a metalogical value occurs as a choice or as an element of a choice in a case statement that is interpreted by a synthesis tool, the synthesis tool shall interpret the choice as one that can never occur. That is, the interpretation that is generated is not required to contain any constructs corresponding to the presence or absence of the sequence of statements associated with the choice. Whenever a synthesis tool interprets a case statement alternative that associates multiple choices with a single sequence of statements, it shall produce an interpretation consistent with associating the sequence of statements with each choice individually. Whenever a synthesis tool interprets a selected signal assignment statement, it shall interpret the selected signal assignment statement as if it were the case statement in the equivalent process as defined by IEEE Std 1076-1993. 4.3.2.3 Metalogical values in logical, arithmetic, and shift operations When a static metalogical value occurs as all of, or one element of, an operand to a logical, arithmetic, or shift operation, and when the other operand to the operation is not a static value, a synthesis tool shall treat the operation as an error. RATIONALE: Wherever the NUMERIC_STD and NUMERIC_BIT .packages declare functions for logical, arithmetic, and shift operations, they allow metalogical values in the operands and return a value that usually includes one or more metalogical elements. They do not report errors for operands containing metalogical values. However, the subprogram bodies for these operations define simulation behavior; the synthesis behavior for when an operand contains a static metalogical value is still defined by this clause. RATIONALE: This restriction applies to shift operations because the second operand to the shift operation is an INTEGER. Therefore, the static metalogical value can occur only within the first operand, and by the terms of this clause the second argument is a non-static value. In this case, a synthesis tool cannot determine what element position the static metalogical value is being shifted to. 4.3.2.4 Metalogical values in concatenate operations If a static metalogical value occurs as all of, or as one element of, an operand to the concatenate (&) operator, a synthesis tool shall treat it as if it had occurred as the corresponding element of the expression formed by the concatenate operation. 4.3.2.5 Metalogical values in type conversion and sign-extension functions If a static metalogical value occurs as all of, or as one element of, the value argument to a type conversion or sign-extension function, a synthesis tool shall treat it as if it had occurred as the corresponding element of the expression formed by the function call. 4.3.2.6 Metalogical values used in assignment references A synthesis tool shall accept a static metalogical value used as all of, or as one element of, an assignment reference, but is not required to provide any particular interpretation of that metalogical value. RATIONALE: The committee had considered requiring the synthesis tool to replace the metalogical value by either '0' or '1' where it occurred in the VHDL source code, but a counter example showed that this was not always desirable. In particular, consider a D flip-flop with both SET and RESET inputs. If both SET and RESET are active, the model may specify that the output Q should be a metalogical value, and hence an expression such as "Q xor not Q" is also unknown. If one replaces the metalogical value by either '0' or '1', the expression "Q xor not Q" has the value '1'. This would require the synthesis tool to synthesize a circuit for which the Q and Q-bar outputs of a real flip-flop have opposing values even when SET and RESET are both active. But a user may wish instead to allow a flip-flop for which Q and Q-bar are not necessarily complementary under this condition. So it seems wiser not to require the synthesis tool to treat a metalogical value in an assignment reference as any particular value. 4.3.3 Interpretation of the high impedance value ('Z') If the static value 'Z' occurs as an assignment reference in a signal assignment statement, a synthesis tool shall interpret the assignment as implying the equivalent of a three-state buffer that is disabled by the condition controlling the assignment. The output of the three-state buffer is the target of the assignment. The input of the three-state buffer is the logic network that represents the value of the target apart from any assignments to 'Z'. If the 'Z' occurs as one or more elements of an assignment reference in a signal assignment statement, a synthesis tool shall interpret each such occurrence as implying the equivalent of a three-state buffer in the manner defined by the preceding paragraph. This standard does not specify an interpretation when a static value 'Z' occurs as all of, or one bit of, an assignment reference in a variable assignment statement. RATIONALE: A variable, by definition, is never a resolved object, so it does not make sense to instantiate a three-state buffer. However, a particular synthesis tool may wish either to do so, or to save the value and propagate it to an assignment to a resolved signal. Therefore, this standard does not restrict the interpretation. Whenever a static high-impedance value occurs in any context other than an assignment reference, a synthesis tool shall treat it as equivalent to a static metalogical value. 5. The STD_MATCH function The NUMERIC_STD package defined by this standard defines functions named STD_MATCH to provide wild card matching for the don't care value. Whenever the STD_MATCH function compares two arguments which are STD_ULOGIC values, it returns TRUE if and only if - both values are well-defined and the values are the same, or - one value is '0' and the other is 'L', or - one value is '1' and the other is 'H', or - at least one of the values is the don't care value ('-'). Whenever the STD_MATCH function compares two arguments which are vectors of STD_ULOGIC values, it returns TRUE if and only if a) the operands have the same length, and b) STD_MATCH applied to each pair of matching elements returns TRUE. When one of the arguments to the STD_MATCH function is a static value and the other is not, a synthesis tool shall interpret the call to the STD_MATCH function as equivalent to an equality test on matching elements of the arguments, excepting those elements of the static value which are equal to '-'. NOTE-If any argument value passed to STD_MATCH is or contains a metalogical or high-impedance value other than '-', the function returns FALSE. 6. Signal edge detection Wherever a synthesis tool interprets a particular expression as the edge of a signal, it shall also interpret the function RISING_EDGE as representing a rising edge and the function FALLING_EDGE as representing a falling edge, where RISING_EDGE and FALLING_EDGE are the functions declared either by the package STD_LOGIC_1164 of Std 1076-1993 or by the NUMERIC_BIT package of this standard. 7. Standard arithmetic packages Two VHDL packages are defined by this standard. The NUMERIC_BIT package is based on type BIT, while the NUMERIC_STD package is based on type STD_ULOGIC. Simulations based on the subprograms of the NUMERIC_BIT package ordinarily require less execution time, because the subprograms do not have to deal with operands containing metalogical or high-impedance values. Use of the subprograms of the NUMERIC_STD package allow simulation to detect the propagation or generation of metalogical values. Each package defines a vector type named SIGNED and a vector type named UNSIGNED. The type UNSIGNED represents an unsigned binary integer with the most significant bit on the left, while the type SIGNED represents a two's-complement binary integer with the most significant bit on the left. In particular, a one-element SIGNED vector represents the integer values -1 and 0. To facilitate changing from one package to the other, most of the subprograms declared in one package are also declared for corresponding arguments in the other. The exceptions are a) The NUMERIC_BIT package declares the functions RISING_EDGE and FALLING_EDGE; the corresponding functions for STD_ULOGIC are declared by the STD_LOGIC_1164 package. b) The NUMERIC_STD package declares functions for the logical operators (and, or, not, nand, nor, xor, and xnor) and for the logical shift operators (sll and srl) applied to SIGNED and UNSIGNED types, whereas these operators are defined implicitly by VHDL for the SIGNED and UNSIGNED types in the NUMERIC_BIT package. c) The NUMERIC_STD package declares the STD_MATCH functions, which give special treatment to the don't-care value, whereas the BIT-based types of the NUMERIC_BIT package have no don't-care values. d) The NUMERIC_STD package declares the TO_01 functions, which may be applied to SIGNED and UNSIGNED vector values, and which map the element values of the vectors to the STD_ULOGIC values '0' and '1' and to a third value representing metalogical or high-impedance values. Table 1 shows the order of the function declarations within the package declarations. Table 1-Order of functions within packages Function Id(s) NUMERIC_BIT NUMERIC_STD A.1 A.2 abs unary - abs unary - A.3-8 A.9-14 A.15-20 A.21-26 A.27-32 A.33-38 binary + binary - * / rem mod binary + binary - * / rem mod C.1-6 C.7-12 C.13-18 C.19-24 C.25-30 C.31-36 > < <= >= = /= > < <= >= = /= S.1, S.3 S.2, S.4 S.5, S.7 S.6, S.8 SHIFT_LEFT SHIFT_RIGHT ROTATE_LEFT ROTATE_RIGHT SHIFT_LEFT SHIFT_RIGHT ROTATE_LEFT ROTATE_RIGHT sll srl rol ror R.1-2 RESIZE RESIZE D.1-2 D.3 D.4 TO_INTEGER TO_UNSIGNED TO_SIGNED TO_INTEGER TO_UNSIGNED TO_SIGNED E.1 E.2 RISING_EDGE FALLING_EDGE L.1, L.8 L.2, L.9 L.3, L.10 L.4, L.11 L.5, L.12 L.6, L.13 L.7, L.14 not and or nand nor xor xnor M.1-M.5 STD_MATCH T.1-2 TO_01 RATIONALE: The packages do not provide implementations of the VHDL '93 shift operators sla and sra for the SIGNED and UNSIGNED types. The reason for this is that the VHDL '93 arithmetic shift functions do not interpret the arithmetic shift operators in a manner consistent with interpreting the operations as multiplying or dividing by powers of two, as do the SHIFT_LEFT and SHIFT_RIGHT functions. The names differ in order to emphasize the distinction. RATIONALE: The names of the ROTATE_LEFT and ROTATE_RIGHT functions were chosen to be consistent with the names SHIFT_LEFT and SHIFT_RIGHT. If a null array is furnished as an input argument to any subprogram declared by NUMERIC_BIT or NUMERIC_STD, a synthesis tool shall treat it as an error. All vector return values which are not null array values are normalized so that the direction of the index range is downto and the right bound is 0. A vector return value which is a null array has the index range "0 downto 1". The package declarations use the following format to declare each function: -- Id: function () return ; -- Result Subtype: -- Result: The elements of this format have the following meanings: A unique identifier of the form . A corresponding identifier appears at the beginning of the corresponding function body in the package body for the same package. The function designator as defined by Std 1076-1993. The formal parameter list for the function as defined by Std 1076-1993. A type mark denoting the result subtype of the function as defined by Std 1076-1993. The subtype of the value returned by the function. If the result subtype of the function denotes an unconstrained vector subtype, also includes an index constraint defining the index range of the returned value in terms of sizes and values of the input parameters. is syntactically a subtype indication as defined by Std 1076-1993. An English language description of the operation performed by the function. Both packages shall be analyzed into the library symbolically named IEEE. 7.1 Allowable modifications Vendors of tools conforming to this standard shall not modify the package declarations for NUMERIC_BIT or NUMERIC_STD. However, a vendor may provide package bodies for either or both packages in which subprograms are rewritten for more efficient simulation or synthesis, provided that the behavior of the rewritten subprograms remains the same under simulation. The behavior of the original and rewritten subprograms are the same if for any combination of input values they return the same return values. The text of messages associated with assertions may differ in the rewritten subprogram. The package bodies for both packages declare a constant named NO_WARNING that has the value FALSE. A user may set NO_WARNING to TRUE and reanalyze the package body to suppress warning messages generated by calls to the functions in these packages. For this reason, - A tool vendor who rewrites the package body shall preserve the declaration of the NO_WARNING constant to allow a user to suppress warnings by editing and reanalyzing the package body. - A simulation tool vendor who provides a preanalyzed version of the package body should also provide a mechanism for suppressing warning messages generated by the package functions. 7.2 The NUMERIC_BIT package (Insert NUMERIC_BIT package here) 7.3 The NUMERIC_STD package (Insert NUMERIC_STD package here.) Annex A Notes on the Package Functions (informative) This annex provides notes on functions included in the NUMERIC_BIT and NUMERIC_STD packages. The appearance of a code fragment in this annex does not require a synthesis tool conforming to this standard to accept the construct represented by that fragment. A.1 General considerations A.1.1 Mixing SIGNED and UNSIGNED operands The NUMERIC_BIT and NUMERIC_STD packages do not provide functions for mixing SIGNED and UNSIGNED operands. To do so would make it necessary to use qualified expressions to disambiguate commonly occuring forms. For example, with the declarations, variable S: SIGNED (3 downto 0); variable U: UNSIGNED (4 downto 0); if the arithmetic and relational functions allowed mixing of SIGNED and UNSIGNED operands, it would be necessary to rewrite the expressions S >= "0000" and U + "1" as S >= SIGNED("0000") and U + UNSIGNED("1") To apply a binary operation from the NUMERIC_BIT or NUMERIC_STD package to a combination of SIGNED and UNSIGNED operands, the user must explicitly convert one of the operands to the other type (See A.5.2). A.1.2 Mixing vector and element operands The NUMERIC_BIT and NUMERIC_STD do not declare functions that combine a vector with an operand that belongs to the element type of the vector. For example, with the declarations signal A, B, S: SIGNED(3 downto 0); signal C: BIT; a user may not write S <= A + B(4); or S <= A - C; or S <= A / '1'; For the first and third example, a user may write instead S <= A + B(4 downto 4); and S <= A / "1"; For the second example, the user may introduce a temporary signal or variable: variable C_TEMP: SIGNED(0 downto 0); ... C_TEMP(0) := C; S <= A - C_TEMP; A.2 Arithmetic operator functions A.2.1 Overflow of maximum negative value When the SIGNED operand to an abs (function A.1) or unary - (function A.2) function from either package has the maximum negative value for the number of elements that it has, the result is the maximum negative value of the same size. This means, for example, that - SIGNED'("1000") -> "1000" Similarly, in functions A.22 and A.25, when the first operand to the / operator has the maximum negative value for the number of elements that it has, and when the second operand is either an INTEGER with the value -1 or a SIGNED operand with a value equivalent to -1, the result is the same as the first operand, rather than its complement: SIGNED'("1000") / "11111" -> "1000" SIGNED'("10000") / (- 1) -> "10000" To prevent overflow, a user may add an extra bit to the representation. For example, with the following declarations, variable DIVIDEND: SIGNED (4 downto 0); variable DIVISOR: INTEGER range -8 to 7; variable QUOTIENT: SIGNED (5 downto 0); one may write QUOTIENT := (DIVIDEND(4) & DIVIDEND) / DIVISOR; A.2.2 Lack of carry and borrow When both operands to a binary arithmetic functions + or - are either SIGNED or UNSIGNED, the function returns a value with the same number of elements (bits) as the larger of the two operands. If one operand is SIGNED or UNSIGNED and the other is INTEGER or NATURAL, the function returns a value with the same number of elements as the vector operand. Thus, these functions do not return an extra bit to represent a carry, borrow, or overflow value, nor do they generate a warning if a carry, borrow, or overflow occurs. The choice not to generate a carry or borrow (and not to generate a warning) makes it easier to represent counter operations in the VHDL source code via assignments such as A := A + 1; or B <= B - "1"; To obtain the appropriate carry, borrow, or overflow value, a user may add an extra bit to the vector operand. For example, with the declarations signal U: UNSIGNED (4 downto 0); signal S: SIGNED (5 downto 0); signal SUM: UNSIGNED (5 downto 0); signal DIFFERENCE: SIGNED (6 downto 0); one may write SUM <= ('0' & U) + 1; DIFFERENCE <= (S(5) & S) - "1"; A.2.3 Return value for metalogical and high-impedance operands If an operand to a NUMERIC_STD arithmetic function contains a metalogical or high-impedance value, the function returns a vector in which every element has the value 'X'. The function does not report a warning or error. A.3 Relational operator functions A.3.1 Justification of vector operands The relational operator functions for the SIGNED and UNSIGNED types in both packages have a behavior different from the default behavior defined by Std 1076-1993 for vector types. The default behavior compares the vector elements left to right after the operands are left-justified, whereas the relational operator functions for SIGNED and UNSIGNED treat their operands as representing binary integers. The following table compares results for relational operators when both operands are BIT_VECTORs, SIGNED values, or UNSIGNED values. Expression Value when both operands are ... BIT_VECTOR UNSIGNED SIGNED "001" = "00001" FALSE TRUE TRUE "001" > "00001" TRUE FALSE FALSE "100" < "01000" FALSE TRUE TRUE "010" < "10000" TRUE TRUE FALSE "100" < "00100" FALSE FALSE TRUE A.3.2 Expansion of vector operands compared to integers When a relational operator compares a SIGNED or UNSIGNED argument value with an INTEGER or NATURAL value, the function has the effect of converting the SIGNED or UNSIGNED argument to its equivalent universal integer value and then doing the corresponding comparison of integer values. For example, (SIGNED'("111") > -8) = TRUE and (UNSIGNED'("111") < 8) = TRUE That is, the INTEGER value may be larger in magnitude than any value that can be represented by the num- ber of elements in the SIGNED or UNSIGNED value. A.3.3 Return value for metalogical and high-impedance operands If an operand to any of the NUMERIC_STD relational operator functions for =, <, <=, >, or >= contains a metalogical or high-impedance value, the function returns the value FALSE. If an operand to the NUMERIC_STD relational operator function /= contains a metalogical or high-impedance value, the function returns the value TRUE. A.4 Shift functions A.4.1 Multiplication by a power of 2 with remaindering The SHIFT_LEFT function for an UNSIGNED argument provides for multiplication by a power of 2 remaindered by the maximum size of the vector argument. In particular, if ARG is UNSIGNED and is well-defined, and if the integer values fall within the range allowed for INTEGERs, TO_INTEGER(SHIFT_LEFT(ARG, COUNT)) = TO_INTEGER(ARG) * (2 ** COUNT) rem (2 ** ARG'LENGTH) A.4.2 Division by a power of 2 The SHIFT_RIGHT function for an UNSIGNED argument provides for division by a power of 2. That is, if ARG is UNSIGNED and is well-defined, and if the integer values fall with the range allowed for INTEGERs, TO_INTEGER(SHIFT_RIGHT(ARG, COUNT) = TO_INTEGER(ARG) / (2 ** COUNT) A.5 Type conversion functions A.5.1 Overflow in conversion to INTEGER The TO_INTEGER function does not contain code to check that the SIGNED or UNSIGNED argument has an equivalent universal integer value that belongs to the range defined for the INTEGER or NATURAL subtypes. If TO_INTEGER is called with an argument value that is too large, the simulation tool may therefore detect an overflow. A user should avoid applying TO_INTEGER to argument subtypes for which the number of elements is greater than the number of bits used to represent INTEGERs in the user's simulation and synthesis tools. A.5.2 Conversion between SIGNED and UNSIGNED The packages do not provide functions for converting directly between the SIGNED and UNSIGNED types. Such conversions must be performed by the user. There are several ways to convert between SIGNED and UNSIGNED types. In performing such conversions, a user must determine how to handle any possible differences in the ranges supported by SIGNED and UNSIGNED objects having the same number of elements. For example, suppose the VHDL source code contains the following declarations: signal S: SIGNED(3 downto 0); signal BIG_S: SIGNED(4 downto 0); signal U: UNSIGNED(3 downto 0); constant S1: SIGNED(3 downto 0) := "1000"; -- equivalent to -8 constant U1: UNSIGNED(3 downto 0) := "1100"; -- equivalent to +10 a) A user can use a VHDL type conversion to convert one form to another: S <= SIGNED(U1); -- U1 (= +10) gets converted to S (= -4) U <= UNSIGNED(S1); -- S1 (= -8) gets converted to U (= +8) b) A user can add an extra bit to represent the sign when converting from UNSIGNED to SIGNED: BIG_S <= SIGNED('0' & U1); -- U1 (= +10) gets converted to BIG_S (= +10) c) Finally, a user can generate an error or warning when the value of one cannot be represented in the number of elements available in the other. assert S >= "0000" report "Cannot convert negative value." severity WARNING; U <= UNSIGNED(S); A.6 Logical operator functions A.6.1 Application to SIGNED and UNSIGNED The functions that define the application of the logical operators and, or, nand, nor, xor, and xnor to SIGNED and UNSIGNED argument values are equivalent to functions that apply the same logical operators to STD_LOGIC_VECTOR (or STD_ULOGIC_VECTOR) arguments. This equivalence includes the handling of metalogical and high-impedance element values. That is, for example, if S1 and S2 are SIGNED values of equal length, S1 nand S2 = SIGNED(STD_LOGIC_VECTOR(S1) nand STD_LOGIC_VECTOR(S2)) A.6.2 Index range of return values For the functions and, or, nand, nor, xor, and xnor defined in the NUMERIC_STD package, the index range for the return values has the form "n - 1 downto 0," where n is the number of elements in the return value. In the NUMERIC_BIT package, the corresponding functions are defined implicitly by the type declarations for the SIGNED and UNSIGNED types, so that the index range of the return values is as defined by Std 1076-1993. A.7 The STD_MATCH function The behavior of the STD_MATCH functions in the NUMERIC_STD package differs from that of the = functions for the same types of arguments. The STD_MATCH function compares its arguments element by element, and treats the value '-' as matching any other STD_ULOGIC value. The = function interprets its operands, however, as representing the equivalent integer values, and returns TRUE if the equivalent integer values are equal. RATIONALE: One reason for keeping the = function separate from the STD_MATCH function is so that the behavior of the = function is consistent with that of the other relational operators. In addition, the NUMERIC_STD package defines the STD_MATCH function not only for SIGNED, UNSIGNED, and STD_ULOGIC operands, but also for STD_LOGIC_VECTOR and STD_ULOGIC_VECTOR operands. The package cannot redefine the = function for STD_LOGIC_VECTOR and STD_ULOGIC_VECTOR, since that function is defined by the STD_LOGIC_1164 package in IEEE Std 1164-1993. Since a separate function is required for STD_LOGIC_VECTOR and STD_ULOGIC_VECTOR, the STD_MATCH function is kept separate for the types of the NUMERIC_STD package as well.