Copyright © 2000 by ASC.
Floating Point Types for Synthesis
Alex N. D. Zamfirescu
Contact: A.Zamfirescu@IEEE.Org, Phone 650 473 1067
Mail: Alternative System Concepts, Inc. 644 Emerson St., Suite 10, Palo Alto, CA USA
Abstract
The paper addresses the problem of
synthesizable floating point types and the
integration of such types into VHDL. It includes
a description of the two problems, a) the lack of
support for floating point types for synthesis,
and b) the need for accurate and fast
verification. Several approaches are presented
and analyzed. from the point of view of their
implications (as requirements) for the language
(VHDL), and handling of errors by operators, to
the ease of use. The important aspect of speedy
and accurate verification is also addressed. The
presentation targets the advanced VHDL reader,
but covers also the wider view, standard
evolution aspects. It was intended both as a
trigger of the effort required for the
implementation of the best approach, and for
detecting the solution that is closer to
consensus. The definition of the floating point
types for synthesis could become part of the
next IEEE 1076.3 standard revision (or it could
be developed under IEEE P1076.6).
INTRODUCTION
In essence, computers are integer machines and
are capable of representing real numbers only by
using complex codes. These days, a significant
fraction of numerical work is being done on
workstations that conform to the IEEE (Institute
for Electrical and Electronics Engineers)
standard number 754 for storing and doing
arithmetic with floating-point numbers in
electronic formats. Therefore, the most popular
code for representing real numbers is called the
IEEE Floating-Point Standard Format.
The term floating point is derived from the fact
that there is no fixed number of digits before
and after the decimal point; that is, the decimal
point can float. There are also representations in
which the number of digits before and after the
decimal point is set, called fixed-point
representations. In general, floating-point
representations are slower and less accurate than
fixed-point representations, but they can handle
a larger range of numbers. Note that most
floating-point numbers a computer can represent
are just approximations.
One of the challenges in programming with
floating-point values is ensuring that the
approximations lead to reasonable results. If the
programmer is not careful, small discrepancies
in the approximations can snowball to the point
where the final results become meaningless.
For specific FP algorithms more than necessary
computations are performed. Many extra
operations are performed that have little or no
effect. Because mathematics with floating-point
numbers requires a great deal of computing
power, many older microprocessors use to come
with a chip, called a floating point unit (FPU ),
specialized for performing floating-point
arithmetic. Newer on dedicate a large portion of
the logic, area and power to support standard FP
computing. Smaller cores do not provide FP
handling because supporting the standard is area
and power expensive. A good tutorial on
floating point numbers and in particular how it
affects computer designers is provided in [1]. It
deals with the theoretical aspects of FP
representations and with the implementation
required by the IEEE 754 standard.
The IEEE standard uses rounding, B = 2 and
works from a number written as
FLOATING POINT NUMBERS
VHDL FLOATING POINT PROBLEMS
The general form for a floating point number x
is
Theoretical discussions, such as that in the
ACM article referenced above, discuss
arithmetic in symbolic terms without reference
to an actual format. Although useful, that kind
of approach is more abstract then what VHDL
users are used with.
We can define an IEEE-style representation by
writing something like
x = s * M * B^p
where s is the sign, M is the (normalized)
mantissa, B is the base also known as the
radix), and p is an integer power. The
representation of these numbers in a digital
computer will restrict p to some range, say
[L,U] based on the number of exponent bits Ne,
while the precision of the mantissa M is
restricted to Nf (or Nf+1 if a "hidden" bit is
used) bits. The hidden bit is the first (always 1)
bit that is omitted in most notations. Many
conventions for the choice of B and the
normalization of M. Most computer systems
today, other than IBM mainframes and their
clones, use B = 2. The normalization of the
mantissa M is chosen to be 1.fffff (binary) (as
required by the IEEE FP standard). Some
systems use 0.1fffff (binary). Since only a
certain number of bits for the mantissa are
stored, the question arises of what to do with the
bits that can be computed but cannot be stored.
The obvious two choices are: we can discard
them completely (chop them off) or we can
round the stored part up or down based on
whether the next bit is 1 or 0. For example, if
we have 1.11010101 and need to store it so
there are only 3 places after the binary (radix)
point, chopping gives 1.110 while rounding
gives 1.111.
x = s * 1.ffff...ff (binary) * 2^p
where the mantissa is a binary number whose
leading 1 will be "hidden" when the number is
stored.
s eeeeee fffffffff
to specify that the bits (16 in this case) are
allocated so that there is a leading sign bit, s,
Ne=6 bits (in this case) are devoted to the biased
exponent, while the remaining Nf = 9 bits (in
this case) are used for the fractional part of the
mantissa. Note that there is no rule governing
the number of exponent bits one chooses to use.
With a fixed number of bits, there is a tradeoff
between the size of the exponent (and thus the
largest and smallest numbers that can be
represented) and the size of the mantissa (and
thus the precision of the numbers that can be
represented). The single (32-bit) and double
(64-bit) IEEE standards make choices that were
considered by the committee members to be an
optimal
compromise.
Some
computer
manufacturers reached a different conclusion
and arrange their FP formats following a
different convention. Therefore, one should
always know what arithmetic model was used.
In modeling with VHDL we consider two kinds
of FP formats. Of the first kind is the FP format
of the computer on which the VHDL model is
compiled into. The second kind contains the FP
formats used in the model. To distinguish
between them refer to the first as the machine
kind, and to the second as the model kind.
The first problem that with IEEE 1076-1993
standard is that either the machine and the
model formats are the same or the model format
is not easily recognizable by synthesis tools.
A second problem is that operations with
proprietary model kind FP formats are not fast
enough to enable execution and evaluation of
different choices.
Both problems could be solved if a standard
model kind FP formats would be available.
First custom model kind FP formats could be
recognizable by synthesis tools, and second
acceleration of operation execution for these
new standard FP types would bring the speed
required for verification and evaluation.
mantissa size could be specified using a VHDL
attribute or by the position of a specific bit (for
example bit zero if negative ranges are
permitted). Such type would be easily
accelerated, relatively easily supported by
synthesis tools and easily recognized, but it
would be of little use. First, the need is for
smaller less power consuming formats. Second,
the design of the future high precision machines
will not be addressed, even if the 64 bit wide
and the extended options of the IEEE 754 would
be supported. A third disadvantage of this
simple approach is the arbitrary choices that
have to be made for such things as exception
handling in operations or some representations
for NANs (NAN = not a number).
POSSIBLE SOLUTIONS
Because the Java Virtual Machine support of
FPs is standard, this approach solves the third
concern above (choices are made and are
already standard). Also many of the currently
designed hand held portable devices have to
support Java and its VM.
A few solutions are proposed. Some simply
address only the support of IEEE 754 model
kind formats, with the use of what is provided in
the language today. Other, more complex model
kind FP (like configurable FP types) would
require changes to the language for efficient
implementation. Language additions are needed
in the direction of a template like operator
specification, or capabilities like those provided
in XML (for handling the FP properties).
Note that ADA programming language provide
a series of language defined attributes to reach
the machine kind FP characteristics. Extending
such attributes to the new model kind FP types
would also be a useful language enhancement.
IEEE 754 MODEL KIND VHDL FP TYPE
The simplest solution is to support just the IEEE
754 standard for subtypes of bit_vector and
std_logic_vector. The choice of the sign bit
position requires only a convention, while the
SUPPORT JAVA VIRTUAL MACHINE FP
ARBITRARY FP VHDL TYPES
The challenges for implementing an arbitrary FP
type in VHDL are the following:
1. A relatively complex set of properties has to
be specified to characterize the format
2. Operators have to be specified for all the
possible combinations of choices
3. Lose synthesis choices have to be left in
handling some exceptions
4. Format properties should either be
associated with the model or be
automatically extracted form available
library data.
The first challenge could be addressed by the
use of VHDL attributes, but there is no way to
verify that the set is complete or the values are
in a permitted range. Also challenge number 4
imposes a format that is either embedded inside
the model code or outside but still easily read by
a tool. A solution would be to enter the FP
format properties via XML. The XML code
could become the large string value of a VHDL
attribute, or be directly inserted (after VHDL
language modifications) inside the VHDL code.
XML enables checking of any rules that FP
formats properties have to comply with. The
extra advantage is that the same XML file could
be extracted from libraries and then read by the
synthesis and verification tools.
The second challenge could be addressed via the
introduction of a minimal set of C++ like
templates. In fact such features will also be
required in describing configurable hardware.
The challenge number 3 above is also solved by
the XML approach.
The initial thought is that work could be started
as a project to enhance the IEEE 1076.3 or it
could be hosted by the IEEE project 1076.6.
However, the XML approach for the type
descriptor could become useful in the Verilog
standardization, as well as in other system level
approach. Therefore, the type descriptor belongs
to a set of standards that are used in more
languages. We expect that the development of
such set of top standards will trigger the interest
of Accellera membership companies. The
operator library, is a language specific standard
that has to be kept in sync with any possible
mirror Verilog implementation. All other
choices as the name of the FP type or its
skeleton definition are language specific, but
there is no reason not to try unification of those
too.
HOW TO PROCEED
SPEED OF VERIFICATION
The simpler solutions discussed above require
just an agreement on the definition of the type
and implementation of a library of operators.
The most promising simple choice is the
support of the Java VM FP.
The general approach would require:
Relying on the machine FP for acceleration is
feasible only for FP with all parameter ranges
included in the IEEE 754 permitted ranges. In
general FP acceleration is feasible via machine
byte and word manipulation in C or native code.
A configurable co-processor implemented with
configurable hardware could also be a solution
for acceleration of the verification and
evaluation of models using general model kind
FP types. The buss access delay is reflected in
the speed limit in this case.
1. The design of a DTD (document template
definition) for the XML content
(FP type properties like sizes, normalization,
exponent encoding, base value, truncation
scheme, hidden bit, exception handling,
defaults, etc.)
2. A choice for the XML insertion into VHDL
3. The extension/import of ADA machine kind
FP attributes to the model kind VHDL FP
types
4. The implementation of a library of operators
after extending the language to support
templates.
CONCLUSION
Based on the distinction between machine kind
FP types and model kind FP types the synthesis
support and speed of verification problems were
identified. The simple solution of supporting
IEEE 754 Java VM like FP types in VHDL is
less promising then the support for general
configurable FP types. An XML based FP
descriptor could lead to unified support of FP
types in VHDL and Verilog. A new set of
optimizations for low power become feasible
through the user choice of the FP formats.
REFERENCES
[1] "What Every Computer Scientist Should
Know About Floating-Point Arithmetic" by
David Goldberg, in ACM Computing Surveys
23, 5 (March 1991).