**3.1 SystemC fixed point data types**

SystemC includes the *sc\_fixed* and *sc\_ufixed* data types to represent fixed point signed and unsigned numbers the syntax to include these in a SystemC program is the following:

*sc\_fixed<wl, iwl, q\_mode, o\_mode, n\_bits> sc\_ufixed<wl, iwl, q\_mode, o\_mode, n\_bits>* 

where

**wl:** total word\_length **iwl:** integer word length **q\_mode:** quantization mode **o\_mode:** overflow mode **n\_bits:** number of saturated bits

130 Wireless Communications and Networks – Recent Advances

have found that several Electronic System Level (ESL) design tools generate SystemC testbenches that could be used as standalone applications as well as integrated into event driven simulators that are the core when designing hardware implementations. Some examples are Pico Extreme from Synfora (acquired by Synopsys and now is SynphonyC compiler)(Synopsys, 2011b) and CatapultC from Mentor Graphics (CatapultC is more like

We have talked about Matlab/Simulink being used at the system level design phase. In order to take full advantage of a common testbench, a hardware design could rely entirely on this platform for rapid prototyping by accomplishing transformations at the level of

Once a design is transformed for example from Matlab m-code to Simulink, or perhaps the design was started in Simulink directly, there are a series of custom libraries that allow the designer to transform their design directly into hardware and keep the original Simulink testbench to feed the hardware design. The design could be verified by generating HDL RTL and by running event driven simulations side by side the Simulink engine and compare with the original Simulink model to verify that the RTL code generated matches the desired abstracted model. Not only a standalone simulation is conceivable, it is possible to download the application directly into an FPGA and generate excitation signals and receive the data back in Simulink. This allows to verify hardware performance at full speed or to accelerate algorithm execution that will take a long time on an event driven simulator. There are several products with similar capabilities such as National Instrument's LabView (NI, 2011) that also allows the option to have "Hardware In the Loop" (HIL) as a way to accelerate computing performance by implementing the algorithm directly in hardware.

The philosophy at this level is to try to reuse the testbench as much as possible to verify correctness of the design at a very high level of abstraction and to code a single testbench that could be used at the system level, while still being able to run the components at single

This section will cover the different formats used to represent a number using fixed point precision. In addition, the effects of truncation, rounding, and saturation will be covered. SystemC provides a standard set of fixed point types that have been also adopted and adapted by electronic system level (ESL) tools. We will talk about SystemC's fixed number representation. We will talk also about traditional RTL fixed point implementations and the

SystemC includes the *sc\_fixed* and *sc\_ufixed* data types to represent fixed point signed and unsigned numbers the syntax to include these in a SystemC program is the following:

levels of abstraction, namely behavioral, RTL and gate level.

**3. Fixed point number representation** 

required hardware, complexity and performance.

**3.1 SystemC fixed point data types** 

*sc\_fixed<wl, iwl, q\_mode, o\_mode, n\_bits> sc\_ufixed<wl, iwl, q\_mode, o\_mode, n\_bits>* 

where

C++rather than SystemC) (MentorGraphics, 2011).

modeling hierarchy.

Quantization modes: SC\_RND, SC\_RND\_ZERO, SC\_RND\_INF, SC\_RND\_MIN\_INF, SC\_RND\_CONV, SC\_TRN, SC\_TRN\_ZERO

Overflow modes: SC\_SAT, SC\_SAT\_ZERO, SC\_SAT\_SYM, SC\_WRAP, SC\_WRAP\_SM

For example if we would like to declare a signed integer variable with 16 total bits of which 8 bits are integer, we declare:

#### *sc\_fixed<16,8> number;*

As can be observed in Figure 2, the 16 bit number will contain 8 integer bits and 8 fractional bits. The maximum number that can be represented is 2� � 2�� ≈ 128 and the minimum number will be �2� = -128 with a 2�� ≈ 3.9x10-3 resolution. By default, the number will have a quantization mode of *q\_mode = SC\_TRN* which means that the number precision will be truncated after each mathematical operation or assignment, and the number will have an overflow mode o\_mode=SC\_WRAP which means that the number will wrap from approximately 128 to -128. The different modes allow for flexibility in the rounding and saturation operations that are useful to limit the number of bits enhance the SQNR and also to allow infrequent numbers to be saturated and save on the total number of bits. Of course, the price is additional hardware and probably timing to perform these operations.


Fig. 2. *sc\_fixed<16,8>* representation of a fixed point number.

There are too many ways to describe fixed point notations and representations, but we think that this represents a commonly used format in most of ESL tools that we have explored.

#### **4. Floating to fixed point design considerations**

A practical implementation of a wireless communication algorithm involves the conversion of a floating point representation into a fixed point representation. This process is related to the optimum number of bits to be used to represent the different quantities through the algorithm. This process is performed to save complexity, area, power, and timing closure. A fixed point implementation is the most efficient solution since it is customized to avoid waste of resources. The tradeoffs against a floating point implementation are noise, non-linearities and other effects introduced by the processes of: quantization, truncation, rounding, saturation and wrapping among the most important.

Both the floating point and the fixed point solutions have to be compared against each other and one of the most common measure of fixed point performance is the signal to quantization noise ratio (SQNR) (Rappaport, 2001).

Several tools are available to allow the evaluation of a fixed point implementation against a floating point implementation. One of the most important factors is the dynamic range of the signal in question. Floating point adapts to the signal dynamic range, but when the conversion is to be done, a good set of statistics has to be obtained in order to get the most out of the fixed point implementation. The probability density function of the signal will give insight on the range of values that occur as well as their frequencies of occurrence. It may be acceptable to saturate a signal if overshoots are infrequent. We need to carefully evaluate the penalty imposed by this saturation operation and the ripple effects that it could have. This process allows to use just the necessary number of bits to handle the signal most of the time, thus saving in terms of area, power and timing. In section 5.3, we talk about some of the little steps that have to be taken throughout the design in order to save in power consumption. As mentioned, power consumption savings start at the system level architecture throughout the ASIC and FPGA methodologies.

Sometimes the processed signal could be normalized in order to have a unique universal hardware to handle the algorithm. It is very important to take into consideration the places where the arithmetic operations involve a growth in the number of bits assigned at each operation. For example, for every addition of two operands, a growth of one bit has to be appended to account for the overflow of adding both signals. If four signals are added, only a growth of two bits is expected. On the other hand a multiplication creates larger precisions since the number of bits in the multiplication result is the addition of the number of bits of the operands and also it has to be taken into account if the numbers are signed or unsigned.

The fixed point resolution at every stage needs to be adapted and maintained by the operations themselves and specific processing needs to be done to generate a common format. These operations are the truncation, rounding, saturation and wrapping covered briefly for SystemC data type in section 3.

A nice framework of the use of fixed point data types that could be incorporated into C/C++ algorithm simulations are the SystemC fixed point types available in the IEEE 1666™-2005: Open SystemC Language Reference Manual (SystemC, 2011). There are some other alternatives to fixed point data types such as the Algorithmic C Datatypes (Mentor-Graphics, 2011) that claim to simulate much faster than the original SystemC types and used in the ESL tool CatapultC. The ESL tool Pico Extreme uses the SystemC fixed point data types as the input to the high level synthesis process.

Matlab/Simulink also has a very nice framework to explore floating to fixed point conversion. When hardware will be generated directly from Simulink, it is very natural to alternate between floating point and fixed point for system level design. Designs that are targeted for Xilinx or Altera FPGAs could naturally use this flow and reuse the floating point testbench to generate the excitation signals that could be used within the Matlab/Simulink environment in for example Hardware in the Loop (HIL) configuration or fed externally to the FPGA using an arbitrary waveform pattern generator.

Another very useful tool for creating executable specifications in C++ is to use IT++ (IT++, 2011) libraries available for simulation of communication systems.

Each EDA vendor has a different set of tools that allow designers to make the implementation of floating point to fixed point as seamless as possible. This conversion process is a required step that cannot be avoided and traditionally it has been done manually and by matching the results of the Golden model against HDL RTL simulation. Sometimes this comparison is bit accurate, but in some cases the comparison is just done at the SQNR level due to the difficulty to model all the internal operations and stages of a particular hardware implementation.
