The IEEE standard packages math_real and math_complex define constants and mathematical functions on real and complex numbers, respectively.

   procedure uniform ( variable seed1, seed2 : inout positive;
                       variable × : out real);

   use ieee.numeric_bit.all;
   subtype ALU_func is unsigned(3 downto 0);
   subtype data_word is unsigned(15 downto 0);
   ...
   entity ALU is
     port ( a, b : in data_word;  func : in ALU_func;
            result : out data_word;  carry : out bit );
   end entity ALU;

   architecture random_test of test_ALU is

     use ieee.numeric_bit.all;
     use ieee.math_real.uniform;

     signal a, b, result : data_word;
     signal func : ALU_func;
     signal carry : bit;
   begin
     dut : entity work.ALU(structural)
       port map ( a, b, func, result, carry );
    stimulus : process is
      variable seed1, seed2 : positive := 1;
      variable a_real, b_real, func_real : real;
    begin
      wait for 100 ns;
      uniform ( seed1, seed2, a_real );
      uniform ( seed1, seed2, b_real );
      uniform ( seed1, seed2, func_real );
      a <= to_unsigned(
             natural(a_real
                     * real(2**integer'(data_word'length)) - 0.5),
             data_word'length );
      b <= to_unsigned(
             natural(b_real
                     * real(2**integer'(data_word'length)) - 0.5),
             data_word'length );
      func <= to_unsigned(
             natural(func_real
                     * real(2**integer'(ALU_func'length)) - 0.5),
             ALU_func'length );
    end process stimulus;
    ...    --verification process to check result and carry
   end architecture random_test;

Complex Number Mathematical Package

The math_complex package deals with complex numbers represented in Cartesian and polar form. The package defines types for these representations, as follows:

   type complex is record
       re : real;    -- Real part
       im : real;    -- Imaginary part
     end record;

   subtype positive_real is real range 0.0 to real'high;
   subtype principal_value is real range -math_pi to math_pi;

   type complex_polar is record
      mag : positive_real;    -- Magnitude

      arg : principal_value;  -- Angle in radians; -math_pi is illegal
    end record;

The constants defined in math_complex are

math_cbase_1      1.0 + j0.0
math_cbase_j      0.0 + j1.0
math_czero        0.0 + j0.0

The package defines a number of overloaded operators, listed in Table 9.3. The curly braces indicate that for each operator to the left of the brace, there are overloaded versions for all combinations of types to the right of the brace. Thus, there are six overloaded versions of each of the “+”, “–”, “*” and “/” operators.

Figure 9.3. Overloaded operators defined in math_complex

Overloaded versions of “=” and “/=” are necessary for numbers in polar form, since two complex numbers are equal if their magnitudes are both 0.0, even if their arguments are different. The predefined equality and inequality operators do not have this behavior. No overloaded versions of these operators are required for Cartesian form, since the predefined operators behave correctly.

In addition to the operators, the math_complex package defines a number of mathematical functions, listed in Table 9.4. In the table, the parameters x and y are real, the parameter c is complex, the parameter p is complex_polar, and the parameter z is either complex or complex_polar.

Table 9.4. Functions defined in the package math_complex

Function	Result type	Meaning
cmplx(x, y)get_principal_value(x)complex_to_polar(c)polar_to_complex(p)	complexprincipal_valuecomplex_polarcomplex	x + jyx + 2πk for some k,such that -π < result ≤ πc in polar formp in Cartesian form
arg(z)conj(z)	principal_valuesame as z	arg(z) in radianscomplex conjugate of z
sqrt(z)exp(z)	same as zsame as z	ez
log(z)log2(z)log10(z)log(z, y)	same as zsame as zsame as zsame as z	lnzlog2zlog10zlogyz
sin(z)cos(z)sinh(z)cosh(z)	same as zsame as zsame as zsame as z	sinzcoszsinhzcoshz

The IEEE standard package std_logic_1164 defines types and operations for models that need to deal with strong, weak and high-impedance strengths, and with unknown values. We have already described most of the types and operations in previous chapters and seen their use in examples. For completeness, we draw the information together in this section.

The types declared in std_logic_1164 are

In addition, the package declares the subtypes X01, X01Z, UX01 and UX01Z for cases where we do not need to distinguish between strong and weak driving strengths. Each of these subtypes includes just the values listed in the subtype name.

Since the type std_ulogic and the subtype std_logic are scalar enumeration types, all of the predefined operations for such types are available. This includes the relational operators, maximum, minimum, and to_string. In addition, the matching relational operators “?=”, “?/=”, “?>”, “?>=”, “?<”, and “?<=” are predefined for std_ulogic and std_logic. For the array type std_ulogic_vector and the subtype std_logic_vector, the predefined operations on one-dimensional arrays of discrete-type elements are available. This includes “&” and the relational operators. In addition, the matching equality (“?=”) and inequality (“?/=”) operators are defined for these types.

The operations provided by the std_logic_1164 package include overloaded versions of the logical operators and, nand, or, nor, xor, xnor and not, operating on values of each of the scalar and vector types and subtypes listed above. It also includes overloaded versions of the shift operators sll, srl, rol and ror operating on the vector types. It does not overload the sla and sra operators on the premise that they assume a numeric interpretation of vectors. Instead, those operators are overloaded in separate packages, numeric_std and numeric_std_unsigned, that provide arithmetic operations assuming a numeric interpretation (see Section 9.2.3). The std_logic_1164 package provides an overloaded version of the “??” operator, allowing std_ulogic and std_logic value to be used in conditions with implicit conversion.

In Section 4.3.5 we described the to_ostring and to_hstring operations for converting bit_vector operands to strings in octal and hexadecimal form. The std_logic_1164 package provides overloaded versions of these operations for std_ulogic_vector and std_logic_vector operands. The operations group elements into threes (octal) or fours (hexadecimal) for conversion into digits. However, if the vector needs to be extended on the left to make a multiple of three or four, the assumed value for the extra elements depends on the leftmost actual element. If the leftmost element is ‘Z’, then ‘Z’ elements are assumed; if it is ‘X’, then ‘X’ elements are assumed; otherwise, ‘0’ elements are assumed.

Having grouped elements, they are converted to digits. If all of the elements in a group are ‘0’, ‘L’, ‘1’, or ‘H’, the group is converted to a normal digit character, with ‘0’ and ‘L’ elements treated as ‘0’, and ‘1’ and ‘H’ elements treated as ‘1’. If all of the elements in a group are ‘Z’, then ‘Z’ is used as the digit character for the group. In all other cases, where a group contains one or more non-‘0’, -‘L’, -‘1’, -‘H’ or -‘Z’ elements, ‘X’ is used as the digit character for the group. Some examples are

   to_ostring(B"01L_1H1") = "27"
   to_ostring(B"011_ZZZ") = "3Z"
   to_ostring(B"01U_UZZ") = "XX"

   to_ostring(B"HH_000") = to_ostring(B"0HH_000") = "30"
   to_ostring(B"ZZ_ZZZ") = to_ostring(B"ZZZ_ZZZ") = "ZZ"
   to_ostring(B"X1_000") = to_ostring(B"XX1_000") = "X0"
   to_ostring(B"1X_000") = to_ostring(B"01X_000") = "X0"

As well as providing the overloaded to_ostring and to_hstring operations, the std_logic_1164 package provides all of the alternative names: to_bstring, to_binary_string, to_octal_string, and to_hex_string. Further, the package provides overloaded versions of the file read and write operations for text-based input/output. We describe files and input/output in Chapter 16.

In addition to the overloaded operations, the package declares a number of functions for conversion between values of different types. In the following lists, the parameter b represents a bit value or bit vector, the parameter s represents a standard logic value or standard logic vector, and the parameter x represents a value of any of these types.

In these functions, the parameter xmap is a bit value that is used in the result when a bit to be converted is other than ‘0’, ‘1’, ‘L’ or ‘H’. There are multiple alternative names for the second function, allowing us to choose based on consideration of coding style.

Note that the To_StdLogicVector and To_StdULogicVector function perform essentially the same operation. The fact that std_logic_vector has resolved elements is not relevant to the conversion. The two forms are provided for backward compatibility with previous versions of VHDL, where the distinction was relevant.

These strength-stripping functions remove the driving strength information from the parameter value. To_01 convert ‘L’ and ‘H’ digits in a vector to ‘0’ and ‘1’ digits. The optional second parameter specifies the result value to produce if any digit in the first parameter is other than ‘0’, ‘1’, ‘L’ or ‘H’. In that case, all digits of the result are set to the value specified in the second parameter. The default value of the second parameter is ‘0’. Some examples are

   to_01( "LLHH01" ) = "001101"
   to_01( "00X11U" ) = "000110"
   to_01( "100LLL", 'X' ) = "100000"
   to_01( "00W000", 'X' ) = "XXXXXX"

To_X01 converts ‘U’, ‘X’, ‘Z’, ‘W’ and ‘–’ elements to ‘X’. To_X01Z is similar, but leaves ‘Z’ elements intact. To_UX01 is similar to To_X01, but leaves ‘U’ elements intact.

Finally, the std_logic_1164 package contains the following utility functions:

The edge-detection functions detect changes between low and high values on a scalar signal, irrespective of the driving strengths of the values. The functions are true only during the simulation cycles on which such events occur. They serve the same purpose as the predefined functions of the same name operating on bit and boolean signals. The unknown-detection function determines whether there is a ‘U’, ‘X’, ‘Z’ or ‘W’ value in the scalar or vector value s.

The IEEE standard packages numeric_bit and numeric_std define arithmetic operations on integers represented using vectors of bit and std_ulogic elements respectively. Most synthesis tools accept models that use these types and operations for numeric computations. We discuss the topic of synthesis of VHDL models in more detail in Chapter 21. In this section, we outline the types and operations provided by the IEEE standard integer numeric packages. Full listings of the package declarations are included in Appendix A.

Each of the packages defines two types, unsigned and signed, to represent unsigned and signed integer values, respectively. In the case of the numeric_bit package, the types are unconstrained arrays of bit elements:

   type unsigned is array ( natural range <> ) of bit;
   type signed is array ( natural range <> ) of bit;

In the case of the numeric_std package, the types are defined similarly, but with resolved std_ulogic as the element type. This package also defines the types unresolved_unsigned and unresolved_signed (and the shorter aliases u_unsigned and u_signed) as arrays of unresolved std_ulogic elements. The declarations are

   type unresolved_unsigned is array (natural range <>) of std_ulogic;
   type unresolved_signed   is array (natural range <>) of std_ulogic;

   alias u_unsigned is unresolved_unsigned;
   alias u_signed   is unresolved_signed;

   subtype unsigned is (resolved) unresolved_unsigned;
   subtype signed   is (resolved) unresolved_signed;

Whichever package and type we use, the leftmost element is the most-significant digit, and the rightmost element is the least-significant digit. Signed numbers are represented using two’s-complement encoding.

We declare objects of these types either directly or using a subtype to define the index range. For example:

   signal head_position : signed ( 0 to 15 );

   subtype address is unsigned ( 31 downto 0 );
   signal next_PC : address;
   constant PC_increment : unsigned := X"4";

The operations defined for unsigned and signed numbers are listed in Table 9.5. The curly braces indicate that for each operator to the left of the brace, there are overloaded versions for all combinations of types to the right of the brace. For example, there are six overloaded versions of each of the “+”, “–”, “*”, “/”, rem and mod operators. The notation “element type” refers to the element type (bit or std_ulogic) of the vector operand or operands.

Figure 9.5. Operators defined in the IEEE standard synthesis packages

The operands of arithmetic and relational operators need not be of the same length. The relational operators determine the result based on the numeric values represented by the operands, rather than using left-to-right lexicographic comparison. For those operators that produce a vector result, the length of the result depends on the length of the operands, as follows.

   signal a, b, sum : unsigned(15 downto 0);
   signal c_out : std_ulogic;

   (c_out, sum) <= ('0' & a) + ('0' & b);

The addition and subtraction operators that have an operand of the scalar element type allow us to describe an addition with carry in or a subtraction with borrow in. For example:

   signal a, b : unsigned(15 downto 0);
   signal sum  : unsigned(16 downto 0);
   signal c_in;
   ...
   sum <= ('0' & a) + ('0' & b) + c_in;

This can be synthesized as a single 16-bit adder with a carry input and a 17-bit result.

   signal inc_en  : std_ulogic;
   signal inc_reg : unsigned(7 downto 0);
   ...
   inc_reg_proc : process (clk) is
   begin
     if rising_edge(clk) then
       inc_reg <= inc_reg + inc_en;
     end if;
   end process inc_reg_proc;

   if inc_en = '1' then
     inc_reg <= inc_reg + 1;
   end if;

For the division, remainder and modulo operators, if the right operand is zero, an assertion violation with severity level error is issued during simulation.

The logical shift operators sll and srl fill the vacated elements with ‘0’. Their behavior is the same as that of the predefined operators for bit_vector values. The behavior of the sla and sra operators, on the other hand, is different from the predefined versions, in that they assume a binary-coded numeric interpretation for a vector. The type of the left operand determines the kind of shift performed. If the operand is unsigned, a logical shift is performed, whereas if the parameter is signed, an arithmetic shift is performed. An arithmetic shift right (sra with a positive right operand or sla with a negative right operand) replicates the sign bit, giving the effect of division by a power of 2. An arithmetic shift left (sra with a negative right operand or sla with a positive right operand) fills the vacated bits on the right with ‘0’, giving the effect of multiplication by a power of 2.

In addition to the overloaded operators, the numeric_bit and numeric_std packages define a number of functions, listed in Table 9.6. As in Table 9.5, the curly braces indicate that for each function to the left of the brace, there are overloaded versions for all combinations of types to the right of the brace.

Figure 9.6. Functions defined in the IEEE standard synthesis packages

The maximum and minimum functions are overloaded to compare their operands based on a numeric interpretation in the same way as the relational operators. For the versions that take two vector operands, the operands do not need to be of the same length.

The shift, rotate and to_01 functions all produce a result that has the same length as the vector parameter. The shift and rotate functions perform similar operations to the overloaded shift and rotate operators. However, their second parameter is constrained to be a non-negative integer. Hence each of these functions can only shift or rotate elements in one direction. These functions were included in the package for earlier versions of VHDL that did not include the shift operators. They are maintained in the package for backward compatibility.

The find_leftmost function returns the index of the leftmost occurrence of the right-operand value in the left-operand vector. Similarly, the find_rightmost function returns the index of the rightmost occurrence of the right-operand value in the left-operand vector. If there is no such occurrence, the functions return –1. Since the index bound of an unsigned or signed vector are natural numbers, –1 is a clear indication that the value was not found. In both functions, search for the element value is performed using a matching equality test. We can use find_leftmost to gauge the magnitude of a number, since the leftmost occurrence of a 1 bit in an unsigned number is approximately log₂ of the number. For a signed number, the leftmost bit that differs from the sign bit is likewise approximately log₂ of the number.

The resize functions produce a result whose length is specified by the second parameter. For a second parameter of type natural, the parameter value specifies the number of bits in the result directly. For a second parameter of type unsigned or signed, the result has the same number of bits as the parameter value. Increasing the size of an unsigned number zero-extends to the left, whereas increasing the size of a signed number replicates the sign bit to the left. Truncating an unsigned number to length L keeps the rightmost L bits. Truncating a signed number to length L keeps the sign bit and the rightmost L – 1 bits.

The to_integer functions convert unsigned or signed values to natural or integer values, respectively. The to_unsigned and to_signed functions convert their first parameter to a vector whose length is given by the second parameter, either as a natural number directly, or as a vector whose length is used.

The edge-detection functions rising_edge and falling_edge are provided as aliases for the predefined edge-detection functions on type bit. They are included here for backward compatibility with earlier versions of VHDL, in which the edge-detection functions were not predefined. The std_match functions perform the same operations as the “?=” operator. Again, they are included for backward compatibility with earlier versions of VHDL that did not provide that operator.

The strength-stripping functions to_01, to_X01, to_X01Z, and to_UX01 are overloaded for unsigned and signed operands, and perform the same operation as the corresponding functions for vectors in the std_logic_1164 package.

Finally, the packages provide the string conversion operations. The to_string operation is actually predefined for unsigned and signed, since they are one-dimensional arrays of character elements in both packages. The to_ostring and to_hstring operations work in the same way as the corresponding operations in the std_logic_1164 package. The only difference is that, when extending a signed value to form a complete group of three (for octal) or four (for hexadecimal) bits, the sign bit is replicated rather than ‘0’ bits being added. The same aliases for all of the operations are also defined. Further, the packages provide overloaded versions of the file read and write operations for text-based input/ output. We describe files and input/output in Chapter 16.

Since the standard numeric packages are widely used in many models, VHDL defines two standard context declarations (see Section 5.4.2) within the standard library ieee:

   context ieee_bit_context is
     library ieee;
     use ieee.numeric_bit.all;
   end context ieee_bit_context;

   context ieee_std_context is
     library ieee;
     use ieee.std_logic_1164.all;
     use ieee.numeric_std.all;
   end context ieee_std_context;

A design based on bit values might refer to the first of these context declarations, either in the context clause of a design unit or nested within a project context declaration. Similarly, a design based on std_ulogic values might refer to the second of these context declarations.

As we have mentioned, the numeric_bit and numeric_std packages define new array types, unsigned and signed, to represent numbers in binary-coded form. Many designers, however, prefer to use the bit_vector and std_ulogic_vector types for numeric data. This approach is particularly useful in designs that include components, such as multiplexers, registers, and so on, that do not rely on numeric properties of data; they just store or manipulate arrays of bits. When such designs also include arithmetic elements, having to convert between the types for numeric interpretation and the plain vector type is a distraction. Historically, designers have adopted non-standard packages that provide arithmetic operations on bit_vector or std_ulogic_vector operands.

In the 2008 revision of VHDL, two new packages were added to library ieee for this purpose: numeric_bit_unsigned and numeric_std_unsigned. They are largely compatible with numeric_bit and numeric_std, respectively, and provide the corresponding unsigned operations. In summary, the similarities and differences among the packages are

Many digital-signal processing applications involve mathematical operations on non-integral data. While we could use floating-point representation and hardware, that would be excessively resource intensive in many cases. Instead, we can use a fixed-point representation, in which the radix point (analogous to the base-10 decimal point) is assumed to have a fixed position. VHDL defines a number of packages for fixed-point math that we introduce in this section. Since the packages provide a large number of overloaded operations and functions, we will not describe them in full detail here. We will simply provide an overview of the data types provided and some basic information on their usage. More details are provided in Appendix A and on the author’s companion website for this book. In addition, Section 9.2.6 summarizes the operations provided by these packages and the other standard numeric packages.

For simple cases, fixed-point math amounts to integer math with scaling by a power of 2. More generally, we need to take account of rounding and overflow. The main VHDL fixed-point package, fixed_generic_pkg, is written in such a way that we can choose the rounding and overflow behaviors that are most appropriate for our application. The package uses formal generic constants, a topic that we will cover in detail in Chapter 12. For now, suffice it to say that the package defines four constants as follows:

If the default values are acceptable for our application, we can use a version of the package named fixed_pkg, located in the ieee library. For other cases, the main package must be instantiated, as described in Chapter 12, to supply alternative values for the constants.

The package fixed_generic_pkg (and any instance of it, such as fixed_pkg) defines types for unsigned and signed fixed-point representation in the form of vectors of std_ulogic elements. The base type for unsigned representation is unresolved_ufixed, declared as

   type unresolved_ufixed is array (integer range <>) of std_ulogic;

The name u_ufixed is defined, for convenience, as an alias to unresolved_ufixed. The package also defines a subtype ufixed with resolved elements. The declarations are

   alias u_ufixed is unresolved_ufixed;
   subtype ufixed is (resolved) unresolved_ufixed;

When declaring signals, we should choose between the base type or the subtype with resolved elements, depending on whether the signal has only one source or multiple sources, respectively.

Objects of these types must have descending (downto) index ranges. The whole-number part of the value is on the left of the vector, down to index 0, and the fractional part is on the right, starting at index –1. For example, given the following declaration of a fixed-point signal A:

   signal A : ufixed(3 downto -3) := "0110100";

the whole-number part is A(3 downto 0), and the fractional part is A(–1 downto –3). The range of values represented is 0 to just less than 16 in steps of 0.125 (one-eighth). The value represented by the default initial value is 0110.100₂ = 6.5₁₀.

This example shows a number with both whole-number and fractional parts. In general, we can declare number with just a whole-number part (the right index being 0) or just a fraction part (the left index being –1). Indeed, we can declare numbers in which the radix point is completely outside the index range of the vector. For example, in the following:

   variable X : ufixed(9 downto 2);
   variable Y : ufixed(-5 downto -14);

X is an 8-bit vector representing values in the range 0 to 1020 in steps of 4, and Y is a 10-bit vector representing values in the range 0 to just less than 0.0625 (one-sixteenth) in steps of 2^–14.

The base type defined in the package for signed representation is unresolved_sfixed, declared as:

   type unresolved_sfixed is array (integer range <>) of std_ulogic;

As for the unsigned representation, there is an alias, u_sfixed, and a subtype with resolved elements, sfixed:

   alias u_sfixed is unresolved_sfixed;
   subtype sfixed is (resolved) unresolved_sfixed;

Likewise, the index range for a signed value must be descending (downto), with the radix point being assumed between index 0 and index –1. The difference is that the signed type and subtypes use 2s-complement binary representation, with the leftmost bit being the sign bit. Thus, for example, the signal:

   signal S : sfixed(3 downto -3);

represents values from –8 to just less than 8 in steps of 0.125.

The fixed-point math packages perform operations with full precision. This is illustrated in the following example:

   signal A4_2 : ufixed(3 downto -2);
   signal B3_3 : ufixed(2 downto -3);
   signal Y5_3 : ufixed(4 downto -3);
   ...
   Y5_3 <= A4_2 + B3_3;

The whole-number part of the addition result is one bit larger than the larger of the two operand whole-number parts. In this example, the operand whole-number parts are 4 bits and 3 bits, respectively, so the result’s whole-number part is 5 bits. The fractional part of the result is the larger fractional part of the operands. In this example, the operands’ fractional parts are 2 bits and 3 bits, respectively, so the result has a 3-bit fractional part.

If we want to assign a fixed-point value to an object, one way is to use a string literal, for example:

   signal A4 : ufixed(3 downto -3);
   ...
   A4 <= "0110100";  -- string literal for 6.5

Alternatively, we can apply a conversion function, to_ufixed or to_sfixed, to an integer or real value. In this case, we need to specify the index range for the conversion result. There are two forms of conversion function. For the first form, we specify the left and right indices for the result, for example:

   A4 <= to_ufixed(6.5, 3, -3);  -- pass indices

For the second form, we provide an object whose index range is used:

   A4 <= to_ufixed(6.5, A4);  -- sized by A4

In this example, the only use of A4 by the to_ufixed function is to read its left and right indices to determine the index range of the result.

The use of a string literal in an arithmetic expression is problematic, since the index range of such a literal is ascending (to) and starts with integer’low. Fixed-point numbers must have descending index ranges. Instead we can use integer literals, real literals, and qualified string literals, as shown in the following examples:

   subtype ufixed4_3 is ufixed(3 downto -3);
   signal A4, B4 : ufixed4_3;
   signal Y5     : ufixed (4 downto -3);
   ...
   Y5 <= A4 + "0110100";              -- illegal
   Y5 <= A4 + ufixed4_3'("0110100");
   Y5 <= A4 + 6.5;                    -- overloading with real
   Y5 <= A4 + 6;                      -- overloading with integer

In the assignment marked “illegal,” the index range of the string literal would be integer‘low to integer‘low + 6. The type qualification in the next assignment avoids this problem and results in a bit-string value with index bounds taken from the subtype ufixed4_3. We can safely apply the addition operator to this value and the operand A4, giving a result with index range 4 down to –3.

If we need to change the size of an expression result, we can use a resize function. As for the conversion functions, there are two forms, one in which we specify the left and right index values and the other in which we provide an object whose index range is used. For example, in the following accumulator assignment, since the addition result is one bit larger than the accumulator, we need to resize the result:

   signal A4_3 : ufixed(3 downto -3);
   signal Y7_3 : ufixed(6 downto -3);
   ...
   Y7_3 <= Y7_3 + A4_3;   -- illegal, result too big
   Y7_3 <= resize(arg             => Y7_3 + A4_3,
                 size_res       => Y7_3,
                 overflow_style => fixed_wrap,
                 round_style    => fixed_truncate);

The overflow_style and round_style parameters allow us to control the way the value is processed if it cannot be represented exactly. The default values for these parameters are taken from the package constants described on page 314. If those values are satisfactory, we can omit them in the resize call. This is shown in the following example, which uses the form of the function specifying left and right index values for the result:

   Y7_3 <= resize (arg          => Y7_3 + A4_3,
                   left_index  => 7,
                   right_index => -3);

Full-precision arithmetic can lead to some unexpected results in expressions involving multiple operators. Consider, as an example, the following declarations and assignment:

   signal A4, B4, C4, D4 : ufixed(3 downto 0);
   signal Y6             : ufixed(5 downto 0);
   signal Y7A, Y7B       : ufixed(6 downto 0);
   ...
   Y6 <= (A4 + B4) + (C4 + D4);

The expression in the assignment is built as a balanced tree. Each of the additions A4 + B4 and C4 + D4 yields a 5-bit result, so the final result size is 6 bits. However, if we build the expression in a cascaded fashion, the result size is 7 bits. We can see this most clearly by explicitly parenthesizing the expression:

   Y7A <= ((A4 + B4) + C4) + D4;

The addition A4 + B4 yields a 5-bit result. This added to C4 yields a 6-bit result, and the 6-bit result added to D4 yields a 7-bit result. Since addition is associative, the following unparenthesized expression yields the same 7-bit result:

   Y7B <= A4 + B4 + C4 + D4;

Included in the set of operations provided by the fixed-point packages are overloaded versions of the string conversion operations and file read and write operations for text-based input/output. Since the ufixed and sfixed types are one-dimensional arrays of character elements, to_string is predefined for both types. However, the packages overload the operation with a version that includes a radix point (a ‘.’ character) at the appropriate position. For example, given the following declaration:

   constant x : ufixed(3 downto -8) := "010000110101";

to_string(x) returns the string “0100.00110101”.

The packages also define overloaded versions of to_ostring and to_hstring that behave similarly to the versions for the integer numeric packages (see Section 9.2.3). Elements are grouped into threes (for octal) or fours (for hexadecimal) starting either side of the radix point. Extension on the left to make up a complete group is performed in the same way as for unsigned and signed numeric values. If extension is required on the right, ‘0’ bits are added. For values in which the radix-point position lies outside the index range, to_ostring and to_hstring extend the value to include the radix point in the result. For example, a to_hstring operation for the value “10100”with index range 7 down to 3 would result in the string “A0.0”, corresponding to the binary number 10100000.0. Similarly, a to_hstring operation for the value “10100”with index range –3 down to –7 would result in “0.28” (0.0010100 in binary).

The fixed-point math packages described in the previous section allow us to represent non-integral values with constant absolute precision over a given range. In some applications, however, we would prefer to use a floating-point representation, in which we can represent a greater dynamic range with a given number of bits, and have constant relative precision over the range. VHDL provides abstract floating-point types, including the type real, built into the language. However, they are defined to use IEEE 64-bit double-precision representation. That may not be the best choice for all applications. VHDL provides a set of packages for binary-coded floating-point representation and operations in which we can control the range and precision and many aspects of the way arithmetic operations are performed. Floating-point values are represented using the same principles as IEEE-standard floating-point, specified in IEEE Std 754 [9] and IEEE Std 854 [10], with a sign bit, an exponent field, and a fraction field. However, we can choose the field widths that are appropriate for our application.

Since these packages, like the fixed-point packages, provide a large number of overloaded operations and functions, we will not describe them in full detail here. Again, we will simply provide an overview of the data types provided and some basic information on their usage. More details are provided in Appendix A and on the author’s companion website; and Section 9.2.6 summarizes the operations provided.

Like the main fixed-point package, the main VHDL fixed-point package, float_generic_pkg, is written using formal generic constants so that we can choose the behaviors that are most appropriate for our application. The package defines seven constants as follows:

The main package also makes use of the fixed-point package, both for conversions between fixed-point and floating-point values and for internal implementation of floating-point operations. Since we can choose the way the fixed-point package behaves by varying the values of its constants, we need to provide the floating-point package with a reference the appropriate version of the fixed-point package for our application. We can do this, if we need to, using the mechanism of formal generic packages, described in Chapter 12. If the default values for the constants are acceptable for our application, we can use a version of the package named float_pkg, located in the ieee library. For other cases, the main package must be instantiated, as described in Chapter 12, to supply alternative values for the constants.

The package float_generic_pkg (and each instance of it, such as float_pkg) defines the base type for floating-point numbers, unresolved_float, declared as:

   type unresolved_float is array (integer range <>) of std_ulogic;

The alias u_float is defined as a convenient shorthand for this type. There is also a subtype, float, which has resolved elements. The declarations are:

   alias u_float is unresolved_float;
   subtype float is (resolved) unresolved_float;

When declaring signals, we should choose between the base type or the subtype with resolved elements, depending on whether the signal has only one source or multiple sources, respectively.

Objects of these types must have descending (downto) index ranges; for example:

   signal A : float(8 downto -23)
              := "01000000110100000000000000000000";

The sign bit is at index A‘left (bit 8 in this example), the exponent is indexed from A‘left – 1 down to 0 (7 down to 0 in the example), and the fraction is indexed from –1 down to A‘right (–1 down to –23 in the example). Unlike fixed-point numbers, floating-point numbers must have the sign, exponent, and fraction all present. The smallest floating-point representation supported by the package has a range of 3 down to –3. In practice, we would expect representations to be 16 bits or more, with at least 6 bits for the exponent and at least 10 bits for the fraction. For the sign bit, 0 is positive, and 1 is negative. The exponent field is an unsigned binary value representing the actual exponent biased by 2^{e – 1} – 1 (where e is the width of the exponent field). Thus, for the signal A declared above, the bias is 127. The actual fraction is normalized to the range of 1.0 to just less than 2.0. Since the bit to the left of the radix point would always be 1, it is not explicitly represented. Instead, the fraction field of a floating-point number just contains the bits to the right of the radix point, with a 1 bit implied to the left of the radix point.

We can use these properties of the representation to analyze the bit string used as the default initial value for the signal A above. The leftmost bit is 0, so the number is positive. The next 8 bits, A(7 downto 0), are 10000001. As an unsigned number, this is 129. We subtract the bias, 127, to give an actual exponent of 2. The fraction field is 101000000000000000000000. We include the implied 1 bit to give an actual fraction of 1.101. Thus, the value represented is +1.101₂ × 2² = 1.625 × 4 = 6.5.

The packages declare a number of subtypes and aliases for IEEE standard floating-point representations. The unresolved subtypes are

   subtype unresolved_float32 is unresolved_float(8 downto -23);
   subtype unresolved_float64 is unresolved_float(11 downto -52);
   subtype unresolved_float128 is
            unresolved_float (15 downto -112);

The unresolved_float32 subtype correponds to IEEE Std 754 single-precision representation. There are a shorthand alias u_float32 and a subtype with resolved elements, float32. Similarly, unresolved_float64 corresponds to IEEE Std 754 double-precision representation (like double float in C, float*8 in Fortran, and real in VHDL), with an alias u_float64 and a subtype with resolve elements, float64; and unresolved_float128 corresponds to IEEE Std 854 extended-precision representation (like long double in C and float*16 in Fortran), with an alias u_float128 and a subtype with resolve elements, float128.

The IEEE floating-point number standards reserve a number of representations for special purposes. In particular, numbers with all 0 or all 1 bits in the exponent field have the following meanings:

Note that there are two representations of 0, one positive and the other negative. Operations on floating-point values generally treat them as equivalent. In addition to these representations, a number with all 1 bits in the exponent field and at least one 1 bit in the fraction field (such as 1 11111111 00000000000000000000001) is called Not-a-Number, or NaN. Such values can result from otherwise illegal operations, such as division of zero by zero, or square root of –1.

Here are some further examples of floating-point numbers. First, the following is a large float32 value (though not the largest, as that is just less than 2**128).

0 11111110 00000000000000000000000

= +1 × 2^254–127 × (1.0 + 0.0)

= 2¹²⁷ = 1.70141 × 10³⁸

Next, the following is the smallest float32 value, without using denormals:

0 00000001 00000000000000000000000

= +1 × 2^1–127 × (1.0 + 0.0)

= 2^–126 = 1.17549 × 10^–38

Finally, the following is a small float32 value using denormals (though not the smallest):

0 00000000 10000000000000000000000

= +1 × 2^1–127 × (0.0 + 0.5)

= +1 × 2^–126 × 0.5

= 2^–127 = 5.87747 × 10^–39

For floating-point math operations, the result always has the largest of the exponent sizes and fraction sizes of the operands. Most often, the numbers are all of the same size, as in the following example:

   signal A32, B32, Y32 : float(8 downto -23);
   ...
   Y32 <= A32 + B32;

Further details of overloaded operations and result sizes are provided in the tables in Section 9.2.6.

If we want to assign a value to a floating-point object, we can either use a string literal or we can apply a to_float conversion function to an integer or real number. This is similar to the way in which we assign values to fixed-point objects (see Section 9.2.4). In the case of conversion functions, we can specify the result size either by specifying the exponent and fraction size, or by providing an object whose index range is used. These approaches are shown in the following example:

   signal A_fp32 : float32;
   ...
   A_fp32 <= "01000000110100000000000000000000";
   A_fp32 <= to_float(6.5, 8, -32);  -- pass sizes
   A_fp32 <= to_float(6.5, A_fp32);  -- size using A_fp32

As with fixed-point math, use of string literals in an expression is problematic, since their index ranges are ascending (to) and start with integer‘low. The solution is the same, namely, using type-qualified string literals or using overloaded operations that accept integer or real operands. These are shown in the following example:

   signal A, Y : float32;
   ...
   Y <= A + "01000000110100000000000000000000";   -- illegal
   Y <= A + float32'("01000000110100000000000000000000");
   Y <= A + 6.5;        -- overloading with real
   Y <= A + 6;          -- overloading with integer

The floating-point packages also include overloaded versions of the string conversion operations and file read and write operations for text-based input/output. The overload to_string operation includes colon characters to separate the sign, exponent, and fraction fields. For example, given the following declaration:

   constant x : float(6 downto -11) := "011101100010001110";

to_string(x) returns the string “0:111011:00010001110”.

The floating-point packages also define overloaded versions of to_ostring and to_hstring that behave similarly to the versions for standard logic vectors (see Section 9.2.2). They do not attempt to include the radix point in the way that the fixed-point versions do, since the radix point is not at a fixed position.

In this section, we summarize the operations defined in the standard packages: std_logic_1164, numeric_std, numeric_bit, numeric_std_unsigned, and numeric_bit_unsigned, fixed_generic_pkg, and float_generic_pkg.

   function to_01   (s : Type; xmap : std_ulogic := '0') return Type;
   function to_X01  (s : Type) return Type;
   function to_X01Z (s : Type) return Type;
   function to_UX01 (s : Type) return Type;

   function is_X (S : Type) return boolean;

   ncs_x01 <= to_X01(ncs);

   assert not is_X(ncs) report "ncs is X" severity error;