Introduction
In recent years, hardware implementations of DSP algorithms became serious competition to their traditional software and signal processor-based counterparts. FPGA technology in combination with HDL design techniques allow to produce flexible and high-performance DSP systems, making FPGA-based implementations of DSP algorithms a common practice that meets increasing performance requirements in consumer electronics.
Silicon vendors are aware of this trend and provide devices tailored for DSP methodologies. For example, modern FPGA architectures contain Multiply and Accumulate (MAC) units that are necessary to design signal processing units like high-performance digital filters.
Likewise, the HDL languages evolve to support DSP design needs. The availability of fixed-point and floating-point (IEEE 754 compatible) HDL packages and libraries with built-in types and functions that enable mathematical and many other operations, became a de facto standard.
Unfortunately, the capabilities of high-performance silicon devices and robust HDLs may be significantly restricted if EDA software for behavioral and RTL-level design is not accommodated to such a changing world.
IEEE 754-2008 Floating-Point Standard
A fundamental issue that is not being addressed is the support of a numbering system used in digital cores. Specifically, the floating-point data format seems to be marginalized by manufacturers of commercial EDA software. The technical standard for floating-point format was established in 1985 by the IEEE and is commonly known as IEEE 754. It’s most recent version IEEE 754™-2008 and its international equivalent ISO/IEC/IEEE 60559:2011 define arithmetic formats, rounding, exceptions handling rules for floating-point numbers, etc.
Floating-point arithmetic has some unique features when compared with fixed-point, allowing to overcome most of the dynamic range and precision constraints imposed on numbers by the fixed-point format. However, IEEE 754 format usage might be troublesome in some aspects. For example, there are some specific issues of noise analysis induced by rounding. Another tricky aspect of floating-point format is its non-intuitive and extremely illegible binary representation. Without specialized debugging tools, it is a challenge to interpret 32- or 64-bit bus values encoded in IEEE 754 single or double format.
Designing a Simple DSP System
Let's consider a quick example to illustrate how important for your debugging environment it is to be able to properly represent objects in the floating-point format. Cascaded-Integrator Comb (CIC) filters are an integral part of all digital rate-converters and are used to remove unwanted alias frequencies. Our sample CIC filter (Figure 1) eliminates signals at frequency f_sample/8. Note that CIC filters typically have a built-in interpolator or decimator. However, the example filter does not contain any rate-converter and works just as a simple moving average filter.
The example filter consists of a comb filter (a block that adds an 8-cycle delayed version of the input signal to itself) followed by a digital integrator (accumulator that consists of a delay block and adder). Up to now, the conceptual design is relatively simple. The complications occur when an engineer has to design this 32-bit floating-point arithmetic system in HDL. While a theoretical analysis is quite obvious to any DSP designer, debugging the corresponding hardware implementation in IEEE 754 floating-point arithmetic might be a completely different story as floating-point format is non-intuitive at all.
Am I Getting Expected System Output?
This fundamental question emerges after implementing a DSP algorithm in hardware. It might not be easy to answer while debugging a system that uses 32 or 64-bit floating-point arithmetic in IEEE 754 format.
A typical design and simulation environment allows presenting bit-vectors in the following decimal notations: unsigned, one's complement, two's complement, and signed magnitude. There is a painful lack of options that interpret bit-vectors pursuant to the IEEE 754 standard. The obvious missing representation option for vectors is floating.
Figure 2 shows your typical debugging environment that offers no floating-point support (or has it disabled). Human-unfriendly streams of hexadecimal values are presented instead of expected floating-point numbers. None of the traditional decimal notations are applicable when it comes to IEEE-754; however, they still are useful for DSP designers since analog waveforms require correct decimal interpretation.
There are several ways to work around the lack of floating-point debugging support:
- Online calculator. Involves copying bit-vectors from the simulation tool and pasting them into a calculator. This method is time consuming.
- Custom application that converts a design's bit-vectors to reals. This approach assures better design verification than calculators but still does not help with debugging. It also takes extra time to create such an application and modify the design to enable dumping values into the converter.
- HDL code modification. It's possible to convert bit-vectors to IEEE 754 floating numbers using HDL converting functions. This method might be useful for small-scale systems but when a large system is designed, a huge number of debug inclusions or hierarchical references make debugging difficult.
Each of these workarounds is painful and not really effective. The lack of floating-point options for vectors may have the following consequences: inconvenient design and debug process, concentration on debug methods instead of system that is being analyzed, partial design verification, and increased time-to-market.
How Floating-Point Aware IDE Makes the Difference
The floating-point aware simulation and debug environment usually has a floating representation option for vectors, such as shown in Figure 3.
A good debugging environment should also provide the following key options (Figure 4) for IEEE 754 arithmetic:
- Notation. Scientific or Fixed depending on the value range. The Auto option automatically sets the notation for an actual value.
- Precision. When Scientific notation is in use, precision determines the number of significant digits to be displayed. With Fixed, precision determines the number of digits displayed after the decimal point.
- Rounding method. Specifies the rounding mode of a floating-point value.
And while precision and notation are intuitive aspects of floating point arithmetic usage, rounding is a bit more complex; here is an overview of typical rounding methods:
- Upward. For example, the value 12.5 is rounded to 13, whereas -8.5 is rounded to -8.
- Downward. For example, the value 16.5 is rounded to 16, whereas -7.5 is rounded to -8.
- Nearest even. For example, 27.5 is rounded to 28, 24.5 is rounded to 24, -26.5 is rounded to -26, and -21.5 is rounded to -22.
- Toward zero. For example, 19.2 is rounded to 19 and -19.2 is rounded to -19.
- Nearest away. For example, the value 4.5 is rounded to 5. In the case when -2.5 is rounded, it is equal to -3.
On top of that, the Floating encoding option may be available to specify the base of the floating encoding. (Binary or decimal, to display the floating point values of radix 2 or 10 respectively; refer to IEEE 754 for details).
Another tool very useful for DSP system debugging is the analog waveform view mode. As presented in Figure 5, analog mode presents the value change trend whereas the literal mode shows even a slight jitter of value which may be invisible in analog waveform.
Another very important feature of the IEEE 754 format is the capability of signaling exceptions in arithmetical operations; the Standard defines the following set on non-numerical values:
- qNaN – "quiet Not a Number"
- sNaN – "signaling Not a Number"
- +INF and -INF – two infinities
Quiet NaN and signaling NaN values denote illegal operations like 0.0/0.0. The difference between qNaN and sNaN is that qNaN is freely propagated through most of the arithmetic operations, while sNaN indicates exceptions. The ±INF is the result of e.g. ±non-zero value/0.0 operations. The IEEE 754 format denotes a -0.0 value that is useful in context of division by zero cases.
Floating-point friendly EDA tools should support all mentioned special values as presented in Figure 6.
Now back to the original question – am I getting what's expected on system outputs? Let's start off by reminding that our example circuit is a CIC filter designed to remove specific frequency from an input signal.
With the floating-point debug and analog waveform mode enabled, waveforms become meaningful and ready for analysis (Figure 7).
At first glance the filter_input and filter_out signals make it obvious that the filter works as expected – high-frequency contents are filtered out from the signal. (Of course, more advanced quantitative analysis is possible based on decimal interpretation of bit-vector values).
Conclusion
There are two types of IDEs – with and without floating-point debug features. When an IDE does not provide floating-point aware debugging tools, engineers have to use workarounds in the design process instead of focusing their attention on DSP concepts and improving productivity.
When you analyze a design with floating-point values stored in 64-bit or 32-bit vectors, it is absolutely necessary to have adequate debugging tools in your design verification environment.
About Aldec, Inc.
Established in 1984, Aldec Inc. is an industry leader in Electronic Design Verification and offers a patented technology suite including: RTL Design, RTL Simulators, Hardware-Assisted Verification, Design Rule Checking, IP Cores, DO-254 Functional Verification and Military/Aerospace solutions. Continuous innovation, superior product quality and total commitment to customer service comprise the foundation of Aldec’s corporate mission. For more information, visit www.aldec.com.