Implementation of a CORDIC based double precision floating point by guf14004


									                  Implementation of a CORDIC based
              double precision floating point unit used in an
                       ASIP based GNSS receiver
                                 Götz Kappen, Sofian el Bahri, Oliver Priebe, Tobias G. Noll,
                 Chair of Electrical Engineering and Computer Systems, Aachen University, Germany


Götz KAPPEN received the Dipl.-Ing. degree in 2002 from RWTH Aachen University. Since then he has been working
as a PhD student at the Chair of Electrical Engineering and Computer Systems, RWTH Aachen University. His fields of
research are satellite navigation systems and digital signal processing.

Sofian el BAHRI received the Dipl.-Ing. degree in electrical engineering in 2006 from RWTH Aachen University. His
fields of research are application specific architectures for digital signal processing.

Oliver PRIEBE received the Dipl.-Ing. degree in 2002 from RWTH Aachen University. Since 2004 he has been
working as a scientific co-worker at the Chair of Electrical Engineering and Computer Systems, RWTH Aachen
University. His fields of research are satellite navigation systems and digital signal processing.

Tobias G. NOLL received the Ing. (grad.) degree in Electrical Engineering from the Fachhochschule Koblenz in 1974,
the Dipl.-Ing. degree in Electrical Engineering from the Technical University of Munich in 1982, and the Dr.-Ing.
degree from the Ruhr-University of Bochum in 1989. From 1974 to 1976, he was with the Max-Planck-Institute of
Radio Astronomy, Bonn. Since 1976 he was with the Corporate Research and Development Department of Siemens and
since 1987 he headed a group of laboratories concerned with CMOS circuits for digital signal processing. In 1992, he
joined the RWTH Aachen University where he is a Professor holding the Chair of Electrical Engineering and Computer
Systems. His activities focus on low power deep submicron CMOS architectures, circuits and design methodologies, as
well as digital signal processing for communications and medicine electronics.


Currently GNSS receivers feature an embedded standard processor (e.g. ARM7) as central processing unit to realize
navigation processor functionality (e.g. correlator channel control, position estimation, pseudorange correction and
coordinate transformations). Although the performance of embedded processors increases floating point instructions,
allowing for high accuracy and straightforward implementation of the signal flow developed by the algorithm designer,
offer lower performance as they are emulated in software. For this reason Digital Signal Processors (DSPs) as well as
General Purpose (GP) processors used in high performance signal processing applications often realize floating point
operations using a dedicated Floating Point Unit (FPU) (e.g. [1], [2]). Recently, GNSS receivers for space applications
[3] or high accuracy multioperable positioning [4] are assembled using a FPU to enhance overall performance.

FPUs generally calculate the specified function in a few clock cycles in parallel to the main processor’s pipeline.
Nevertheless, most embedded microprocessors used in mobile and thus energy critical applications do not feature a
dedicated FPU because of power and area overhead. In this case floating point arithmetic is emulated in software. In
addition to emulation of floating point arithmetic most embedded processors’ emulate trigonometric and mathematical
standard functions using floating point arithmetic. Therefore, an enhanced floating point performance will implicitly
improve the performance of trigonometric and mathematical standard functions. Nevertheless, the performance of these
functions can be further improved using dedicated co-processors.

This paper presents a flexible FPU capable of calculating a wide variety of mathematical and floating point functions to
enhance the performance of the Application Specific Instruction Set Processor (ASIP), which forms the central
processing unit of a flexible GNSS receiver architecture. As presented in [5] the target architecture is assembled by
application specific hardware blocks to reduce energy and area consumption of next generation multioperable GNSS
receivers, while maintaining maximum flexibility. In this approach the standard embedded microprocessor used in most
commercially available receivers is replaced by an ASIP to increase the receiver’s area and energy efficiency, i.e. mm²
per Million Operations Per Second (MOPS) and MOPS per mW.

This paper focuses on the implementation of a configurable co-processor realizing double precision floating point and
trigonometric as well as standard mathematical functions. A library based modular approach allows using a set of
specified co-processor functions without any modifications of the receiver’s source code. Due to configurable
complexity of the co-processor, the area-energy product can be minimized using an application specific subset of
supported functions.

The rest of the paper is organized as follows: Section 2 sketches the idea of replacing the processor in a standard GNSS
receiver by an ASIP and describes the ASIP’s design flow. Performance analyses of a GNSS receiver algorithm on the
template ASIP shows that real-time constraints could not be achieved. A detailed profiling reveals that floating point
instructions as well as trigonometric instructions are performance critical. To reduce the number of processing cycles,
section 3 introduces the implementation and functional verification of the configurable double precision co-processor to
be used in embedded systems. The presented implementation is compared to existing co-processor. Required accuracy
of the floating point representation is estimated and compared to the accuracy achieved by the co-processor. Section 4
details coupling of ASIP and co-processor. Emphasis is placed on required modifications of the ASIP’s hard- and
software and the approach is compared with existing solutions. Section 5 and 6 summarize the performance and cost
figures of the ASIP / co-processor architecture. In section 7 the presented work is compared to existing co-processors.
Finally, section 7 concludes the paper.


2.1 ASIP Motivation and Design Flow

As described in [6] hardware architectures used for today’s System-on-Chip (SoC) designs face a
power-versus-flexibility conflict. That is, programmable and flexible architectures like for instance GP processors or
DSPs offer the lowest area and power efficiency. On the other hand, dedicated and for that reason fixed hardware
architectures like for instance Application Specific Integrated Circuits (ASICs) offer the highest efficiency in terms of
area and power.

In this context ASIPs offer a trade-off between GP processors and dedicated solutions by exploiting a priori knowledge
about the class of application to be implemented [7]. This knowledge allows for adaptation of the processor’s
instruction set leading to a modified Arithmetic Logic Unit (ALU) as well as pipeline architecture. Additionally, ASIPs
may feature for instance optimized memory architecture as well as external interfaces.


                                                                            Processor Designer

                                     Software Dev. Tools
                                             Simulator                                           Description



                                   Application                                                   Gate Level
                                  (C/C++ Code)                                                     Model


                                     Figure 1. ASIP design and optimization flow
The ASIP’s design and optimization flow is shown in Figure 1 and starts by implementing the target application on a
template processor described in an Architecture Description Language (ADL). In this work the LISA processor
description language [8] is used for description of the ASIP architecture and generation of associated tools and
hardware description files [9]. To allow for meaningful results, the template processor belongs to the same class as the
target processor. Typical classes are for instance Very Long Instruction Word (VLIW) and Single Instruction Multiple
Data (SIMD) architectures often used in parallel data paths. In this paper a Reduced Instruction Set Computer (RISC)
processor architecture typical for control functionality and mostly implemented in standard GNSS receiver architectures
has been chosen as starting point for the development of the navigation processor.

For software development, simulation and performance evaluation the ASIP development tools (i.e. Processor
Designer) automatically generate assembler, linker and compiler as well as a cycle accurate simulator based on the
ADL. By using this automatic tool generation, information about costs and benefit of processor extensions can be
derived rapidly. Additionally, hardware description files are generated based on the ADL description. The HDL
description files can be used to synthesize the ASIP for FPGAs or standard cell technologies allowing for real-time
functional verification and analysis of silicon area and power consumption.

The optimization process is based on profiling data of the cycle accurate ASIP model of, generated throughout the
design flow. The profiling reveals performance critical functions which are potential optimization candidates. During
this optimization process, application specific modifications of the ASIP’s instruction set and architecture can be used
to improve performance and efficiency. Besides instruction set modifications co-processors are another promising
option, as described in [7]. For this paper’s purpose performance constraints are as follows: The ASIP should allow for
real-time position estimation at a position fix rate of 1-10 Hz using at least four satellites in view and a typical GNSS
processor clock frequency of 20 MHz.

2.2 Template ASIP’s Performance Evaluation

Throughout this paper a standard Position, Velocity and Time (PVT) algorithm is used for the performance evaluation
of the ASIP / co-processor architecture. The standard algorithm is further divided into four sub-functions:
     1. Calculation of the satellite position (satellite_position)
     2. Correction of the measured pseudoranges (correction)
     3. Estimation of the receiver position by solving a set of non-linear equations (estimation)
     4. Transformation of Cartesian coordinates to latitude, longitude and height (ecef_to_llh).

Executing this standard algorithm on the template processor shows that the overall number of clock cycles required for
position estimation using 5 satellites is about 78 million cycles and increases if more satellites are visible. As can be
seen this clearly conflicts real-time requirements proposed in section 2.1 and prevents using the template ASIP in a
GNSS receiver.

Profiling and analysis of functions executed by the ASIP shows that floating point as well as trigonometric functions
require a significant fraction of the overall number of processing cycles. For a detailed investigation Table 1 compares
standard functions realized using template ASIP, LEON processors and ARM7TDMI. Results are determined using a
cycle accurate LEON [10] and ARM [11] processor simulator respectively. It can be seen that the template ASIP
requires a significantly larger number of processing cycles for standard operations leading to a poor overall
performance compared to LEON and ARM7TDMI. This performance drawback is based on the flexible library concept
used for ASIP development. As standard and floating point libraries should be compliant with a wide variety of
processor classes during development process, the ASIP feature generic library implementations offering poor

                             Table 1. Comparison of standard mathematical functions
                              Function       Template ASIP         LEON            ARM
                                mul              6354                443            73
                                add              3977                988            78
                                sqrt            175445              2265           1243
                                cos             170393             18281           2176
                                sin             154102             18281           2100

This paper aims to improve the performance of the template ASIP by coupling of a configurable co-processor
supporting trigonometric, standard math and floating point operations. By offering configurability the overall receiver
hardware can be optimized for the application code to offer highest performance at lowest costs in terms of area and
power consumption.


3.1 CORDIC Algorithm

The co-processor implementation is based on the Coordinate Rotation Digital Computer (CORDIC) algorithm first
developed for real-time navigation. The CORDIC algorithm allows for a hardware efficient way to iteratively calculate

trigonometric functions using only shift and add operations. The unified CORDIC [12] extends the basic principle to
allow for calculation of various mathematical functions.

The basic principle behind CORDIC is rotation of two input values interpreted as vector components. In each iteration
step the input vector is rotated by a predefined decreasing angle. There are two different modes of operation. In the
rotation mode the input vector is rotated to a predefined angle by minimizing the angular input value. In contrast to this
the vector mode minimizes one of the input components so that the output vector coincides with the coordinate axis.
The vector mode for instance allows for a simple calculation of the input vector’s length.

The following equations describe the unified CORDIC algorithm presented in [12] for the vector components (x, y) and
the angle z:

         xi +1 = xi − m ⋅ y i ⋅ d i ⋅ 2 −i
         y i +1 = yi + xi ⋅ d i ⋅ 2 −i
         z i +1 = z i − d i ⋅ ei

Here, m specifies the coordinate system (1, 0, -1 for circular, linear and hyperbolic) and ei is the elementary angle at
iteration step i. The decision variable di is determined each step depending on the mode of operation:
                − sign( y i ) for vector mode
          di = 
                 sign( z i ) for rotation mode
In contrast to the integer implementation introduced in [13] the above equations have to be performed in floating point

3.2 Implementation

The co-processor presented in this paper is based on an iterative implementation of CORDIC equations [13]. This is
mainly due to the fact, that the co-processor does not require high throughput rates and that non-continuous
co-processor access prevents reasonable pipelining.

The schematic of the iterative CORDIC implementation is shown in Figure 2. After a mode dependent initialisation the
parameters required for the following CORDIC iterations are determined. The CORDIC calculation block implements
the unified CORDIC equations in double precision IEEE754 compliant arithmetic. Iterations are performed until
predefined accuracy or a maximum number of iterations steps are reached. The CORDIC calculation block shown in
Figure 2 is realized using three pipeline steps to increase the operating frequency.


                                                      CORDIC Core





                                         Figure 2. Schematic of co-processor architecture
In this work two different version of the CORDIC co-processor have been developed to trade off co-processor area
versus latency. The difference between these two implementations concerns the realization of the CORDIC calculation
block. Therefore, to reduce the required area the serial version solves the CORDIC equations successively for the
parameters x, y and z. Besides the CORDIC mode and coordinate system Table 2 summarizes latency values of serial
and parallel FPU implementation for each supported function.

                                                                 Table 2. Co-processor instruction’s latency
                                                          Operation                    Coord.            Mode       #lat_ser   #lat_par
                                                          sin(x), cos(x)               Circular          rotation   212        159
                                                          arcsin(x)                    Circular          vector     412        309
                                                          arctan2(x)                   Circular          vector     208        156
                                                          x·y, x+y                     -                 -          5          3
                                                          x/y                          Circular          vector     208        156
                                                          sqrt(x)                      hyperbolic        vector     220        165

3.3 Required Precision

To get a first idea about the required co-processor accuracy the estimation function has been implemented using a
generic floating point format with variable mantissa accuracy. For this purpose ideal measurement data is generated by
choosing a random position on the earth’s surface and computing a variable number of visible satellites based on
almanac data. Using these ideal input values the estimation function computes the receiver’s position using a generic
floating point format. Based on these assumptions, Figure 3 shows the probability that a specified accuracy (i.e. 1m,
2m, 5m and 10m) is achieved with a predefined mantissa bit width. For this simulation and ideal input data 30 mantissa
bits are sufficient to achieve an accuracy of less that 1m.

                                                         < 1m   < 2m    < 5m   < 10m

                      Number of Mantissa Bits





                                                     0             20                      40                60           80              100
                                                                                                  Probability %

                Figure 3. Probability of achieved accuracy depending on number of mantissa bits

3.4. Functional Verification and Achieved Accuracy

The co-processor has been coupled to a reference processor for functional verification of co-processor coupling as well
as for accuracy estimations. For the purpose of this paper a NIOS 2 processor frequently used in FPGA based SoCs is

To estimate the accuracy values with random exponent and mantissa have been generated and used as inputs for each
supported co-processor function. The result of the co-processor computation has been compared to the solution
determined by the NIOS 2 software emulation. Figure 4 shows the minimum number of equal mantissa bits for these
two implementations. It can be seen that for a reasonable input range software emulated and co-processor based floating
point calculations differ by less than 4 mantissa bits. Degradation of the accuracy by more than 3-4 mantissa bits is
mostly based on input range restrictions of software and co-processor implementation.

It can be seen that the co-processor accuracy satisfies the demands of GNSS receivers stated in section 3.3. As the
CORDIC based co-processor implementation gains about 1 bit of accuracy per iteration the possibility of trading
co-processor’s latency against accuracy could be a promising approach to minimize the application’s execution time.

                                                                         cos                                                      arcsin                                                   arctan2

                              Number of Equal Mantissa Bits

                                                                                        Number of Equal Mantissa Bits

                                                                                                                                                  Number of Equal Mantissa Bits
                                                              60                                                        60                                                        60

                                                              40                                                        40                                                        40

                                                              20                                                        20                                                        20

                                                               0                                                        0                                                          0
                                                              -20         0        20                                   -40        -20       0                                    -40        -20       0
                                                                    Exponent Value                                            Exponent Value                                            Exponent Value

                              Number of Equal Mantissa Bits

                                                                                        Number of Equal Mantissa Bits

                                                                                                                                                  Number of Equal Mantissa Bits
                                                                    multiplication                                              division                                                     sqrt
                                                              60                                                        60                                                        60

                                                              40                                                        40                                                        40

                                                              20                                                        20                                                        20

                                                               0                                                        0                                                          0
                                                              -20         0        20                                   -20         0        20                                   -20         0        20
                                                                    Exponent Value                                            Exponent Value                                            Exponent Value

                 Figure 4. Comparison of software emulated and co-processor mantissa accuracy

3.5 Configurations

The complexity of the co-processor, that is the functions which are supported, can be specified at compile time to
perfectly match the considered application. For instance a co-processor implementation supporting only sine and cosine
functions could be an interesting option if the implemented algorithm makes extensive use of these trigonometric
functions. On the other hand a co-processor just featuring floating point additions and multiplications could be
promising for floating point matrix computations. Functions which are not supported by the co-processor are
implemented using the ASIP’s libraries.

                             Table 3. Area Comparison of Co-Processor Configurations
                            Functions                                                                                         Parallel                                                  Serial
                            sin, cos                                                                                          1977 ALUTs                                                2177 ALUTs
                            + [atan, atan2]                                                                                   2013 ALUTs                                                2262 ALUTs
                            + [asin, div, add]                                                                                4779 ALUTs                                                2839 ALUTs
                            + [sqrt]                                                                                          7936 ALUTs                                                6140 ALUTs
                            + [mul]                                                                                           7944 ALUTs                                                6145 ALUTs

Based on a detailed cost-benefit analysis an application specific subset of co-processor functions can be selected to
maximize the area and power efficiency of the overall design. Table 3 summarizes possible configurations and the
required area for the parallel and serial CORDIC implementation using an Altera Stratix II FPGA (i.e.
EP2S60F1020C3). As can be seen maximal and minimal area requirements of the co-processor differ by a factor of
approximately 2.8 and a factor 4 for serial and parallel implementation respectively. For FPGA synthesis replacement
of multiplier logic by internal dedicated multipliers has been turned off. If dedicated multipliers are supported values of
the last two configurations are reduced by approximately 2500 ALUTs.


This section deals with coupling aspects of ASIP and co-processor in the hardware and software domain. The main goal
of this work is the optimization of floating point and trigonometric as well as standard mathematical library functions.
These optimizations will target the ASIP’s mathematical and standard libraries to allow for analysis of various
co-processor configurations without the need for any application source code modifications.

4.1 Hardware Modifications

The template RISC processor used as a starting point for ASIP development features a five stage pipe-line, 16 general
purpose registers and a load / store architecture.
The applied hardware modifications belong to one of the following groups:
    1. Interface extension
    2. Instructions set extension
    3. Processor control flow modifications

To realize coupling of ASIP and co-processor additional input and output ports have been added to the ADL processor
description including two arguments (i.e. arg1, arg2), one result (res) as well as control ports (mode, hold_proc, clk_en,
result_ready). In a next step interface instructions are implemented. One instruction (funcarg) realizes the output of
control signals and arguments. This instruction is present for each co processor instruction (func) supported. The
function (getresult) reads the data after sensing a logical high result_ready signal. Each preceding in-struction is added
as a new leaf in the coding tree. A typical co processor access begins by transmit-ting argument and function specific
control signals and enabling the co processor (clk_en = ´1´). In the following processing cycle the co processor sets the
hold_proc signal and the ASIP stops execution of the pipeline. After the co processor finished calculation the ASIP is
reactivated by setting hold_proc = ´0´ and results are read using the added special instruction get_result.

By adding a co-processor interface the number of required FPGA resources is increasing while the maximum clock
frequency is nearly constant (Table 4).
                                  Table 4. Area overhead for co-processor coupling
                                                              ALUTs                     Frequency
                          Template Processor                  3666                      63.26 MHz
                          + interface                         5081                      58.85 MHz

4.2 Co-Processor Access

Co-processor access (Figure 5) starts by setting the mode signal for the specific instruction and transfer of one or two
input arguments (i.e. arg1 and arg2). In the following cycle the co-processor activates the ASIP’s sleep mode by setting
the proc_sleep signal and begins with CORDIC iteration process. After a predefined accuracy or a maximum of
iteration steps is reached the co-processor sends the result back to the ASIP and releases the proc_sleep signal.

                                      clk (in)

                                      res_ready (out)

                                      clk_en (in)

                                      proc_sleep (out)

                                      mode (in)               mode

                                      arg1 (in)               arg1

                                      arg2 (in)               arg2

                                      res (out)                                   res

                                   Figure 5. Co-Processor Access Timing Diagram
4.3 Software Modifications

As mentioned above the main goal is to prevent source code modifications. Therefore, the co-processor instructions are
inserted into the AISP’s standard libraries. Using a simple plug-and-play approach shown in Figure 6, functions can be
implemented using the co-processor or software emulation using the ASIP’s generic libraries.
                                     application.c                              math.h

                             #include <math.h>
                             int main(void)                    ...
                             {                                 double cos(double);
                               ...                             double atan2(double,double);
                               a = sin(b);                     ...
                               ...                             double sin(double);
                             }                                 ...

                                  sin.c                                                         sin.c

                                  double sin(double x)                   double sin(double x)
                                  {                                      {
                                   //C Implementation                     sinarg(x);
                                   ...                                    return getresult;
                                  }                                      }

                                                 Figure 6. Library Modifications

Figure 6 shows this approach exemplarily for a sine calculation called in the application domain. As for standard
processors the function call is resolved using mathematical standard libraries(i.e. math.h). Depending on the selection
made in the ASIP’s definition file the compiler selects software emulation or co-processor implementation during the
linker phase.
This approach has been used to include different subsets of co-processor functions in the PVT estimation algorithm’s
compilation process and hence allows for comparison of performance achieved using different co-processor


After implementation of the presented hardware and software modifications described in section 4, the PVT
estimation’s source code can be compiled for the ASIP / co-processor architecture. For a functional verification and
real-time implementation as well as determination of processing cycles the ASIP’s hardware description files are
generated as described in chapter 3. Finally, the ASIP is connected to the co-processor component, program and data
memory. The compiled executable is loaded to program memory. Execution time as well as number of co-processor
active cycles required for power estimation can be determined using Modelsim.

The standard navigation algorithm used as an example throughout this paper has been described in section 2.1. Figure 7
shows reduction of processing cycles per function call, which could be achieved using different configurations.




                                                                                                    template            [sin, cos]          + [atan,                        + [asin, div,       + [sqrt]          + [mul]
                                                                                                      ASIP                                   atan2]                             add]

                                                                                                                            satellite_position ecefecef_to_llh
                                                                                                              estimation pos_est satpos               atmo_corr                                            correction

                                                                  Figure 7. Processing cycles of standard navigation receiver functions
The gain achievable by coupling ASIP and co-processor is clearly related to the fraction of trigonometric and floating
point instructions. Here, reductions by one (ecef_to_llh) to two orders (estimation) of magnitude compared to the
template ASIP could be reached.


For the standard cell implementation costs and performance can be visualized using an Area-Energy (AE) diagram.
Figure 8 shows each co-processor configuration classified by energy consumption per function call and area required
for an implementation using a 90nm standard cell technology.
                            1,20                                                                                                                               0,05

                                                                                                                                                                                                                                       A*E = const
                                                                                                                                        Energy per Call [mJ]

     Energy per Call [mJ]

                                                                                                              A*E = const                                      0,03





                                                                                                                                                                   0,050              0,100             0,150              0,200               0,250            0,300
                               0,050               0,100             0,150                  0,200             0,250             0,300
                                                                                                                                                                                                              Area [mm²]
                                                                               Area [mm²]

                                   [sin, cos]   + [atan, atan2]   + [asin, div, add]   + [sqrt]     + [mul]     template ASIP                                         [sin, cos]   + [atan, atan2]   + [asin, div, add]   + [sqrt]   + [mul]    template ASIP

               Figure 8. AE cost comparisons for co-processor configurations; estimation (left) and correction (right)

For the estimation function (left) one can observe reduced AE costs for each of the co-processor configuration. In
contrast to this only the full featured co-processor offers a slightly improved AE product for the implementation of the
correction (right) function. These functions clarify the importance of choosing an application specific subset of
co-processor functions to improve overall costs and performance.

Finally Figure 9 compares the AE costs for the overall PVT algorithm (i.e. correction, estimation, satellite_position,
                            Scaled A*E

                                                             67.1        65.4


                                         20                                                                         14.1

                                               template    [sin, cos]   + [atan,      + [asin, div,   + [sqrt]     + [mul]
                                                 ASIP                    atan2]           add]

                                          Figure 9. AE cost comparison for overall PVT algorithm


There is a large number of floating point co-processors to enhance the performance of embedded microprocessors.
Prominent examples are presented in [14] and [15]. Most of these attempts realize standard floating point arithmetic
including addition, subtraction, multiplication and division based on double or single precision arithmetic.
In contrast to most FPUs [16] introduces a CORDIC based double precision unit to enhance the performance of
standard processor in a SoC. This unit additionally supports trigonometric and standard math functions.

Finally, [17] describes coupling of configurable and synthesizable LEON processor and CORDIC based single
precision floating point unit. The main difference between the approach in [17] and this work concerns the
implementation of the FPU as well as processor FPU coupling. Especially in the latter aspect the ASIP offers a high
degree of flexibility to modify the register bank, interface ports as well as instruction set and pipeline architecture. This
flexibility enables a tight coupling of the FPU and ASIP ensuring highest performance and smallest amount of interface

As a benefit of the ASIP environment the designer has direct access to floating point and standard libraries. By
modifying these libraries as described in section 4.2 a seamless integration of the co-processor instructions without any
source modifications required in [17] becomes feasible. Especially time consuming replacement of operands (i.e. +, *, /)
by a dedicated co-processor instruction (i.e. cpadd, cpmul, cpdiv) is unnecessary.

                                                Table 5. Comparison of CORDIC based FPUs
                                                      Cycle / MOPS                 Serial                        Parallel
                                                      [16]                         Implementation                Implementation
              FPGA Implementation
                ALUTs                                 5290                         6145                          7944
                fmax                                  109 MHz                      34.86 MHz                     43.94 MHz
              Function Latency
                add / sub                             114 / 0.96                   5 / 6.39                      3 / 12.61
                mul                                   153 / 0.71                   5 / 6.39                      3 / 12.61
                div                                   197 / 0.55                   208 / 0.15                    156 / 0.24
                sqrt                                  141 / 0.77                   220 / 0.15                    165 / 0.23
                sin / cos                             360 / 0.3                    212 / 0.15                    159 / 0.24
                atan                                  467 / 0.23                   208 / 0.15                    156 / 0.24

The FPU implemented throughout this work is based on an iterative CORDIC implementation described in section 3.
This yields latency of co-processor instructions of 3 (for add / mul and a parallel implementation) to approximately 100

(for asin and serial implementation) cycles compared to a constant latency of 3 cycles for the approach [17] and a cycle
number of 114 (for addition) to 467 (arctangent) in [16]. Table 5 compares latency and performance in MOPS of
co-processor instructions as well as required ALUTs of the implementation on a Stratix II FPGA.

                                    Table 6. Profiling of PVT estimation algorithm
                              sin      cos      atan      atan2    asin      div      add       sqrt     mul
         estimation           90       90       0         0        0         96       954       18       1044
         satellite_position   16       17       0         2        1         3        40        2        53
         correction           1        3        0         0        0         10       23        0        31
         ecef_to_llh          3        4        2         0        0         6        7         2        21

Table 6 shows the profiling results of the four PVT sub-functions and a test case with 5 satellites in view. For this test
case the co-processor presented in this work reduces the number of co-processor cycles by a more than factor of 6.2
(parallel) and 4.5 (serial). As the commercial solution [16] features a higher clock frequency the overall performance
(operations per second) increases just by a factor of 2.2 (parallel) and 1.3 (serial) respectively.


This paper presents a double precision floating point unit used to enhance the performance of an ASIP based low power
GNSS receiver architecture. The ASIPs design process has been described and a performance comparison of ASIP and
standard embedded processors reveals a poor floating point performance. To improve performance values for floating
point as well as trigonometric and standard math functions a configurable CORDIC based co processor has been
implemented. To trade off performance and area a serial and a parallel implementation of CORDIC equations for x, y
and z have been implemented and required ALUTs and maximal clock frequency for an FPGA implementation have
been shown. The co processor has been functionally verified and the achieved accuracy has been compared to a NIOS 2
software emulation. For reasonable input parameters the accuracy of the co processor instructions satisfies accuracy
required by the PVT estimation algorithm.

Hardware and software modifications required for ASIP / co processor coupling are described. Special emphasis has
been placed on a seamless integration of the co processor functions. Therefore, a subset of functions can be selected in a
definition file and software emulations are replaced during compilation process.

The gain achievable using the presented co-processor has been exemplary shown for four sub functions of a standard
PVT estimation algorithm. Performance analyses shows improvements by one ore two orders of magnitude compared to
the AISP’s software emulation and depending on the executed function. Hence, using the ASIP / co-processor
architecture assumed real-time processing constraints (i.e. 1-10Hz position fix rate at 20MHz processor clock speed)
could be achieved.

For a comparison of co processor configurations the AE costs have been derived for a 90nm TSMC CMOS standard
cell technology. Results show that for a standard GNSS algorithm the full featured co-processor minimizes the AE
costs. Implementations on an FPGA show performance and area values comparable to a commercial CORDIC

The presented coupling of ASIP / co-processor can be further enhanced replacing the currently used sleep mode by
parallel execution of ASIP and co-processor instructions.


[3]   S. Fischer, P. Rastetter, M. Mittnacht, F. Griesauer, P. Silvestrin, “AGGA-3 in an Avionic System“, ESA
      Workshop on Spacecraft Data Systems and Software.
[5]   G. Kappen, T.G. Noll, “Mapping of multioperable GNSS receiver algorithms to a heterogeneous ASIP based
      platform” , Proceedings of the International Global Navigation Satellite Systems Society (IGNSS) Symposium
      2006, Surfers Paradise, Australia, 17.-21.7.2006.
[6]   T. G. Noll, “Application Domain Specific Embedded FPGAs for SoC Platforms”, Invited Survey Lecture, Irish
      Signals and Systems Conference 2004 (ISSC'04), Jun. 2004.
[7]   K. Keutzer, S. Malik, A. R. Newton, “From ASIC to ASIP: The Next Design Discontinuity”, ICCD Proceedings,

[8]    CoWare, LISATek Language Reference Manual, Version V2005.2.2, July 2006.
[9]    CoWare, LISATek Processor Designer Manual, Version V2005.2.2, July 2006.
[10]   Gaisler Research, “TSIM2 Simulator User’s Manual”, Version 2.0.8, April 2007.
[11]   ARM Ltd, “Benchmarking with ARMulator”, March, 2002.
[12]   J.S. Walther, “A unified algorithm for elementary functions”, Proc. of the Spring Joint Computer Conference,
       1971, pp. 379-385.
[13]   R. Andraka, “A survey of CORDIC algorithms for FPGA based computers”, International Symposium on Field
       Programmable Gate Arrays, Monterey, 1998, pp. 191-200.
[14]   E. Catovic, “GRFPU – High Performance IEEE-754 Floating-Point Unit”, DASIA 2004, Nice.
[15]   Nallatech, “Double Precision Floating Point Core”, 2004.
[16]   Digital Core Design, “DFPMU Floating Point Coprocessor”, 2007.
[17]   T.Vladimirova, D.Eamey, S.Keller, M.N.Sweeting. “Floating-Point Mathematical Co-Processor for a Single Chip
       On-Board Computer”, Proceedings of the 6th Military and Aerospace Applications of Programmable Logic
       Devices and Technologies (MAPLD'2003), September 9-11, 2003, Washington DC, US.


To top