Accelerating GNSS Software Receivers

Carles Fernández–Prades, Centre Tecnològic de Telecomunicacions de Catalunya (CTTC), Spain.

Javier Arribas, Centre Tecnològic de Telecomunicacions de Catalunya (CTTC), Spain.
Pau Closas, Centre Tecnològic de Telecomunicacions de Catalunya (CTTC), Spain.

BIOGRAPHY ABSTRACT

Dr. Carles Fernández–Prades holds the position of Se- This paper addresses both the efficiency and the portability of
nior Researcher and served as Head of the Communications a computer program in charge of the baseband signal process-
Systems Division (2013-2016) and the Communication Sus- ing of a GNSS receiver. Efficiency, in this context, refers to
bystems Area (2006-2013) at the Centre Tecnològic de Tele- optimizing the speed and memory requirements of the soft-
comunicacions de Catalunya (CTTC). He received a PhD de- ware receiver. Specifically, the interest is focused on how fast
gree in Electrical Engineering from Universitat Politècnica the software receiver can process the incoming stream of raw
de Catalunya (UPC) in 2006. His primary areas of inter- signal samples and, in particular, if signal processing up to
est include statistical and multi-sensor signal processing, es- the position fix can be executed in real-time (and how many
timation and detection theory, and Bayesian filtering, with channels the host computer executing the receiver application
applications related to communication systems, GNSS and can sustain in parallel). This is achieved by applying the con-
software-defined radio technology. cept of parallelization at different abstraction levels. The pa-
per describes strategies based on task, data and instruction-
level parallelism, as well as actual implementations released
Dr. Javier Arribas holds the position of Senior Researcher under an open source license and the results obtained with
at the Centre Tecnològic de Telecomunicacions de Catalunya different commercially available computing platforms. At the
(CTTC). He received the BSc and MSc degree in Telecom- same time, the proposed solution also addresses portability,
munication Engineering in 2002 and 2004, respectively, at La understood as the usability of the same software in different
Salle University in Barcelona, Spain. His primary areas of computing environments.
interest include statistical signal processing, GNSS synchro-
nization, detection and estimation theory, software defined re-
ceivers, FPGA prototyping and the design of RF front-ends. 1. INTRODUCTION

Back in 2006, Gregory W. Heckler published an open source

Dr. Pau Closas is Head of the Statistical Inference for library implementing SIMD-based correlators for GNSS soft-
Communications and Positioning Department and is a Senior ware receivers [1]. That library included arithmetic func-
Researcher at the Centre Tecnològic de Telecomunicacions tions that operate on 16 bit integers, providing MMX and
de Catalunya. He received the MSc and PhD degrees in Elec- SSE2 versions of each function, as well as an MMX-enabled
trical Engineering from Universitat Politècnica de Catalunya fixed point, radix-2, FFT. The code was then integrated into
in 2003 and 2009, respectively. He also holds a MSc degree a software-defined GPS L1 C/A receiver (still available on-
in Advanced Mathematics and Mathematical Engineering line1 ), which became, to the authors knowledge, the first
from UPC since 2014. During 2008 he was a Research available open source software-defined GPS receiver that at-
Visitor at the Stony Brook University, New York, USA. His tained real-time processing in midrange computers.
primary areas of interest include statistical and array signal
processing, estimation and detection theory, Bayesian filter-
ing, robustness analysis, and game theory, with applications In one decade, processors’ clocking speed has hardly dou-
to positioning systems and wireless communications. bled. A typical desktop bought in 2006 could be shipped with
a Pentium IV processor at 2.0 GHz, with the 64-bit x64 86
1 See https://github.com/gps-sdr/gps-sdr
architecture being introduced in the market. In 2016, Intel is allelism, and it is well supported by the main programming
planning to release their Broadwell-E processor series, with languages, compilers and operating systems [2]. To make this
a clock speed up to 3.50 GHz. Differences are more obvious potential performance gain effective, the software running on
in the number of cores and the memory bandwidth: while in the platform must be written in such a way that it can spread
2006 dual-core processor technology was being introduced in its workload across multiple execution cores. Applications
the market, with memory bandwidths on the order of 2 GB/s, and operating systems that are written to support this feature
Broadwell-E processors can house up to 20 cores, with mem- are referred to as multi-threaded. When programmed with
ory bandwidths on the order of 100 GB/s. The requirements the appropriate design, execution can be accelerated almost
for a GNSS software receiver have also evolved in such pe- linearly with the number of processing cores.
riod: from targeting GPS L1 C/A signals transmitted by 24
satellites, GNSS receiver technology is moving into a sce- 2.2. Data parallelism
nario with more than 100 satellites, 10 different GNSS open
signal waveforms for civilian usage, belonging to 4 different In order to cope with the high computational load of GNSS
systems and broadcast at 4 different frequency bands. The baseband processing, software-defined receivers can resort to
new signals are mostly based on binary offset carrier (BOC) another form of parallelization: instructions that can be ap-
modulations, which require more bandwidth and more pro- plied to multiple data elements in parallel, thus exploiting
cessing complexity on the receiver, and the natural target is data parallelism. This computer architecture is known as Sin-
a multi-constellation, multi-band GNSS receiver operating in gle Instruction Multiple Data (SIMD). Intel introduced the
real-time. It is then of the utmost importance to exploit the first instance of SIMD extensions to the 32-bit x86 architec-
underlying parallelisms in the processing platform executing ture, called MMX, in 1997. MMX added eight 64-bit registers
the software receiver in order to meet real-time requirements. to the x86 instruction set, and a plethora of SIMD operations
to operate on the data in those registers. Later SIMD exten-
sions, named SSE, SSE2, SSE3, SSSE3, SSE4.1 and SSE4.2,
After describing the technical foundations on how the
added eight 128-bit registers to the x86 instruction set. Addi-
typical mathematical operations involved in GNSS baseband
tionally, SSE operations included SIMD floating-point opera-
processing can be accelerated by honoring certain software
tions, and expanded the type of integer operations available to
design patterns and exploiting the underlying hardware archi-
the programmer. The other important processor manufacturer,
tecture of the processing platform, this paper presents a prac-
AMD, quickly followed this technology and thus it is present
tical, reusable, and expandable implementation that meets
in the vast majority of modern personal computers. Starting
another important feature in nowadays computing ecosys-
from Intel’s Sandy Bridge processors (2011), a new instruc-
tem: portability. Solutions are tested in disparate, commer-
tion set called Advanced Vector Extensions (AVX) was incor-
cially available platforms, providing performance measure-
porated which has the capacity to further accelerate the com-
ments both as isolated operations and in the context of a
putation of the vector operations. AVX provides new features,
GNSS software receiver, and releasing all the source code un-
256-bit registers, new instructions and a new coding scheme.
der an open source license. As a practical outcome of the pre-
AVX-2 was introduced with Haswell processors (2013), ex-
sented work, the paper presents the first free and open source
panding most integer commands to 256 bits, and Intel’s Xeon
software defined receiver that is able to operate in real-time
Phi processors (expected in 2016) will support AVX-512, pro-
in ARM-based, commercially available processing platforms,
viding 512-bit extensions to AVX. SIMD technology is also
as well as an independent software library that can be used by
present in embedded systems: NEON technology is a 128-bit
other software applications.
SIMD architecture extension for the ARM Cortex-A series
processors, providing 32 registers, 64-bits wide (dual view as
2. PARALLELIZATION STRATEGIES 16 registers, 128-bits wide).

2.1. Task parallelism 2.3. Instruction-level parallelism

A fundamental model of architectural parallelism is found in Computer processors are composed of a number of functional
shared-memory parallel computers, which can work on sev- units that may be able to operate simultaneously. As a re-
eral tasks at once, simply by parceling them out to the differ- sult, a computer might be able to fetch a datum from memory,
ent processors, by executing multiple instruction streams in multiply two floating-point numbers, and evaluate a branch
an interleaved way in a single processor (an approach known condition all at the same time. This is often referred to as
as simultaneous multithreading, or SMT), or by a combina- instruction-level parallelism. A processor that supports this
tion of both strategies. SMT platforms, multicore machines, is said to have a superscalar architecture, and nowadays it is
and shared-memory parallel computers all provide system a common feature in general-purpose microprocessors. Mod-
support for the execution of multiple independent instruction ern compilers put considerable effort into finding a suitable
streams, or threads. This approach is referred to as task par- ordering of operations that keeps many functional units and
paths to memory busy with useful work. Unfortunately, sev- ing point data. The use of GPUs to accelerate a software-
eral studies showed that typical applications are not likely to defined GNSS receiver is not a straightforward process, and
contain more than three or four different instructions that can it requires solving several trade-offs to split the signal pro-
be fed to the computer at a time in this way, limiting the reach cessing chain between the host CPU and the auxiliary GPU
of this approach [3]. Even so, techniques such as manual loop (or GPUs) in order to use the best complementing features of
unrolling can still accelerate execution by a factor of two [1]. both architectures [4]. This paper describes a GPU-based im-
plementation of GNSS multiple correlators that can be seam-
3. COMPUTING ECOSYSTEM lessly integrated into a GNSS software-defined receiver being
executed in a general-purpose processor, sharing the process-
In 2016, desktop computers are not the dominant form fac- ing work with the CPU and thus alleviating the overall load.
tor anymore. Laptops, gaming consoles, mini PCs, tablets
and smartphones has pushed into the market other sort of pro- This rich ecosystem of computing platforms (i.e., several
cessors with low power consumption figures and specific fea- generations of Intel and AMD processors, implementing dif-
tures for multimedia content handling. This is the case of ferent SIMD instruction sets; ARM processors with NEON
the embedded reduced instruction set computing (RISC) mi- extensions, all in 32 and 64-bit architectures; and the possible
croprocessor architecture or, most commonly referred to by presence of GPUs) raises the need to address portability as a
the name of the industry’s leading provider, ARM processors. key feature for a real impact in an open source context.
Starting from Cortex-A series, they support SIMD through
NEON technology, a 128-bit architecture extension consist- The baseband processing acceleration strategies for
ing of a set of registers and operands designed to accelerate GNSS software-defined receivers described on this paper are
image processing tasks such as 2D/3D graphics manipula- put in practice in GNSS-SDR [5], an open source software
tion and video encoding and decoding. In 2016, ARM-based receiver available online2 , that can be executed in Intel, AMD
multi-core systems-on-chip are already available in commer- and ARM processors (32 and 64 bits), thus covering the vast
cial devices such as smartphones and tablets. As a well- majority of today’s computers.
known and accessible example, Raspberry Pi 3 ships with a
quad-core 64-bit ARM Cortex A53 running at 1.2 GHz. This
paper presents an open source library that implements NEON 4. TASK PARALLELIZATION
versions of the most demanding mathematical operations in
Task parallelization focuses on distributing execution pro-
a typical GNSS software receiver, showing accelerations sur-
cesses (threads) across different parallel computing nodes
passing a factor of ten when executed in actual ARM-based
(processors), each executing a different thread (or process)
systems, with the overall result of enabling real-time execu-
on the same or different data. Spreading processing tasks
tion in such devices.
along different threads must be carefully designed in order to
avoid bottlenecks (either in the processing or in memory ac-
Another relevant example is found in Graphic Processing cess) that can block the whole processing chain and prevent
Units, or GPUs, which are specifically designed to accelerate it from attaining real-time operation. This section provides
the creation of images in a frame buffer intended for output an overview of the task scheduling strategy implemented in
to a display. GPUs are commonplace in embedded systems, GNSS-SDR and a description of the most computationally
mobile phones, personal computers, workstations, high-end demanding operations in a GNSS receiver.
video cards and game consoles. Such processor architecture
follows another parallel programming model, called Single
Instruction, Multiple Threads (SIMT). While in SIMD ele- 4.1. Multi-threading in GNSS software receivers
ments of short vectors are processed in parallel, and in SMT GNSS-SDR uses a “thread-per-block” scheduler, which
instructions of several threads are run in parallel, SIMT is means that each instantiated processing block runs in its own
a hybrid between vector processing and hardware threading. thread. This architecture scales very well to multicore proces-
Currently, OpenCL is the most popular open GPU computing sor architectures. The implementation is provided by GNU
language that supports devices from several manufacturers, Radio [6], whose flow graph computations can be jointly
while CUDA is the dominant proprietary framework specific modeled as a Kahn process [7, 8]. A Kahn process describes a
for NVIDIA GPUs. GPUs are massive parallel computing model of computation where processes are connected by com-
platforms that can hold hundreds or even thousands of stream munication channels to form a network. Processes produce
processors. However, each of them runs slower than a CPU data elements or tokens and send them along a communica-
core does and, even though they are Turing complete, they tion channel where they are consumed by the waiting destina-
miss some essential features such as virtual memory man- tion process. Communication channels are the only method
agers or hardware interrupt controllers, and their instruction
sets are optimized mostly for image processing using float- 2 See https://github.com/gnss-sdr/gnss-sdr
processes may use to exchange information. Kahn requires complex baseband signal of the form
the execution of a process to be suspended when it attempts ∞
to get data from an empty input channel. A process may not,
p X
sT (t) = PT d(u)p(t − uTbI ) , (1)
for example, test an input for the presence or absence of data. u=−∞
At any given point, a process can be either enabled or blocked
waiting for data on only one of its input channels: it cannot where
c −1
NX
wait for data from more than one channel. Systems that obey p(t) = q(t − kTP RN ) (2)
Kahn’s mathematical model are determinate: the history of k=0
tokens produced on the communication channels does not de-
and
pend on the execution order [7]. With a proper scheduling c −1
LX
policy, it is possible to implement software defined radio pro- q(t) = ci (l)gT (t − lTc ) , (3)
cess networks holding two key properties: l=0

• Non-termination: understood as an infinite running being PT the transmitting power, d(u) ∈ {−1, 1} the navi-
flow graph process without deadlocks situations, and gation message data symbols, Tb the bit period, Nc the num-
ber of repetitions of a full codeword that spans a bit period,
• Strictly bounded: the number of data elements buffered TP RN = N Tb
the codeword period, ci (l) ∈ {−1, 1} a chip of a
c
on the communication channels remains bounded for spreading codeword i of length Lc chips, gT (t) the transmit-
all possible execution orders. ting chip pulse shape, which is considered energy-normalized
An analysis of such process networks scheduling was pro- for notation clarity, and Tc = NTc L
b
c
is the chip period.
vided in [9]. By adopting GNU Radio’s signal processing
framework, GNSS-SDR bases its software architecture in a The analytic representation of a signal received from a
well-established design and extensively proven implementa- generic GNSS satellite i can be generically expressed as
tion. Section 6.1 provides details on how this concept is ap-
plied in the context of a GNSS software-defined receiver. ri (t) = αi (t)si,T (t − τi (t)) e−j2πfdi (t) ej2πfc t + w(t) , (4)
where αi (t) is the amplitude, si,T (t) is the complex baseband
4.1.1. GPU Offloading transmitted signal, τi (t) is the time–varying delay, fdi (t) =
GPU-accelerated computing consists in the use of a graph- fc τi (t) is the Doppler shift, fc is the carrier frequency, and
ics processing unit (GPU) together with a CPU to acceler- w(t) is a noise term.
ate the execution of a software application, by offloading
computation-intensive portions of the application to the GPU, Assuming w(t) as additive white Gaussian noise, at least
while the remainder of the code still runs on the CPU. The key in the band of interest, it is well known that the optimum re-
idea is to utilize the computation power of both CPU cores ceiver is the code matched filter (often referred to as correla-
and GPU execution units in tandem for better utilization of tor), expressed as
available computing power. Examples of GPU offloading in c −1
LX
the context of GNSS receivers have been extensively reported hM Fi (tk ; τ̂i , fˆdi , φ̂i ) = c∗i (l)gR
∗
(−tk − lTc + τ̂i + Lc Tc )·
in literature (see, for instance, [10, 11, 12]). l=0
ˆ
· e−j φ̂i e−j2πfdi tk =
4.1.2. FPGA Offloading ˆ
∗
= qR (−tk + τ̂i + Lc Tc )e−j φ̂i e−j2πfdi tk , (5)
The commercial availability of system-on-chip (SoC) devices
which integrate the software programmability of an ARM- where ci (l) ∈ {−1, +1} is the l-th chip of a spreading code-
based processor with the hardware programmability of an word (known as pseudorandom sequence) of length Lc , gR (t)
FPGA (e.g., Xilinx’s Zynq-7000 family [13]), allows for sys- is the receiving chip pulse shape, Tc is the chip period, and
tems in which the most computationally demanding opera- τ̂i , fˆdi , φ̂i are local estimates of the time-delay, Doppler-shift
tions of the GNSS receiver are executed in the programmable and carrier phase of the received signal, respectively. The
logic, whereas the rest of the software receiver is executed in code matched filter output can be written as a convolution of
the processing system. The implementation of FPGA-based the form
accelerators and its communication with processes executed
yi (tk ; τ̂ik−1 , fˆdik−1 , φ̂ik−1 ) = (6)
in the ARM processor are out of the scope of this paper.
= ri (tk ; τik , fdik , φik ) ∗ hM F i (tk ; τ̂ik−1 , fˆdik−1 , φ̂ik−1 ) .
4.2. Key operations and data types
Notice that, in the matched filter, we have substituted the es-
In order to describe the most computationally demanding op- timates τ̂ik , fˆdik and φ̂ik for trial values obtained from pre-
erations in the receiver chain, let us assume a generic GNSS vious (in time) estimates of these parameters, which we have
defined as τ̂ik−1 , fˆdik−1 and φ̂ik−1 , respectively. This is the the coherent carrier phase four-quadrant arctangent discrimi-
usual procedure in GNSS receivers, since the estimates are nator  
not really available, but are to be estimated after correlation. ={Pik }
∆φ̂ik = atan2 , (12)
Since the correlators perform the accumulation of the sam- <{Pik }
pled signal during a period Tint and then release an output, and the four-quadrant arctangent FLL discriminator as a mea-
we can write the discrete version of the signal as: sure of the frequency error

|aik | sin(π∆fdik Tint )

  1
yik = K · di [k] Tb · (7) ∆fˆik = · (13)
2 π∆fdik Tint Tint 2π (tk − tk−1 )
<{Pik−1 }<{Pik } + ={Pik−1 }={Pik }
 
−j(π∆fdi Tint +∆φik )
·Rp̃q (∆τik ) · e k + w̃ik · atan2 ,
<{Pik−1 }={Pik } − <{Pik }={Pik−1 }
where we defined aik as the receiving signal complex ampli- where <{·} and ={·} stand for the real and imaginary com-
tude of the GNSS satellite i at time k, ∆fik = fdik − fˆdik−1 , ponents, respectively.
∆φik = φik − φ̂ik−1 and ∆τik = τik − τ̂ik−1 (that is, the
estimation errors of Doppler shift, carrier phase and time The new estimations ∆τ̂ik , ∆φ̂ik and ∆fˆik are then low-
delay, respectively), Tint is the integration time, Rp̃q (t) = pass filtered and reinjected back into the matched filter of
R +∞ ∗
−∞
p̃ (ψ)q(t − ψ)dψ is the cross-correlation function be- Equation (5), thus closing the tracking loops. Such an archi-
tween the received, possibly filtered pulse train modulated by tecture is represented in Figure 1. Delay estimation is used to
the PRN sequence, and a local replica q(t) defined as in (3), compute pseudorange, while phase and frequency estimators
w̃ik as remnant noise, and [k] Tb means the integer part of are used to demodulate and decode the navigation message
Tint
kTint (that is, the sequence of bits denoted as d(u) in Equation (1))
Tb . From now on, we will consider K = TTint as the in-
s and to obtain phase range and phase range rate observables.
teger number of samples collected in an accumulation. This
This is all the information required to compute a position fix.
number will not be an integer in receiver configurations hav-
ing a sample rate incommensurable with the chip rate, and
thus some integration blocks will accumulate K + 1 samples At this level of abstraction, parallelization of operations to
instead of K. the incoming signal is performed at a targeted satellite signal
basis. Explicitly, the stream of digital signal samples at the
output of the analog-to-digital converter of a radio-frequency
The output of the correlator centered at the estimation
front-end, assuming Ns in-view GNSS satellites, can be writ-
of the time delay error in the previous time step, known as
ten as
Prompt correlator, can be the written as:
s −1
NX
α̃i (tn )s̃i,T (tn −τin )e−j2πfdin tn ej2πfIF tn + w̃(tn )
 
Pik = yik ∆τ̂ik−1 , ∆fˆdik−1 , ∆φ̂ik−1 . (8) xq [n]=
i=0
(14)
The other correlators are shifted in time with respect to the
where tn = nTs , Ts ≤ 2Tc is the sampling period, n is the
Prompt, usually in a symmetric arrangement. The advanced
temporal index, fIF is the intermediate frequency, and ˜· de-
and delayed replicas are known as Early and Late correlator
notes a filtered, probably distorted version of the original sig-
outputs, and can be written as
nal. The correlations described in Equation (6) and both the
  delay and phase locked loops are replicated for each received
Eik = yik ∆τ̂ik−1 + , ∆fˆdik−1 , ∆φ̂ik−1 (9) satellite signal (denoted in the equation with the index i), with
a minimum of four of them locked-in at the same time in order
and to be able to compute a position fix.
 
Lik = yik ∆τ̂ik−1 − , ∆fˆdik−1 , ∆φ̂ik−1 . (10)
The index q in Equation (14) denotes that the value of
each sample xq [n] is actually quantized and represented with
Very Early and Very Late outputs can be defined likewise with
q bits. Most commercial RF integrated circuits for GNSS re-
0 > . From those correlator outputs, some error functions
ceivers deliver samples with q = 2 or q = 3 bits. However,
(known in this context as discriminators) can be defined [14].
this is not a format that a computer is ready to manipulate in-
For instance, the normalized non-coherent code discriminator
ternally. Even though operations involving values expressed
|Eik | − |Lik |
2 2 with 3 bits can be defined by software, neither the compiler
∆τ̂ik = q P 2 , nor the underlying hardware are optimized to do so. Proces-
U −1 <{Pi }2 + 1 U −1 ={Pi
1
  P 
U u=0 k−u U u=0 k−u
} sor architectures are designed to work more efficiently when
(11) manipulating values with specific bit lengths (that is, 8, 16, 32
 16ic_rotator_dot_prod_16ic_xn
16ic
16ic_x2_dot_prod_16ic_xn
32fc
16ic_x2_multiply_16ic

Integrate E
Input
sample
16ic_32fc_x2_rotator_16ic & Dump
stream Code
Integrate P Code
Loop
& Dump Discr.
Filter
Integrate L
& Dump Carrier
NCO Phase
16ic_x2_dot_prod_16ic Loop
Carrier Discr.
Filter
Generator

PRN Multiple-delay
Codes Resampler
16ic_xn_resampler_16ic_xn

Fig. 1. Diagram of typical code and carrier tracking loops in a GNSS receiver. Colored dotted-line boxes show functions
that have been implemented in SIMD technology. In this example, lanes with label “16ic” are data streams whose items are
complex numbers with real and imaginary components represented with 16-bit integers, whereas label “32fc” indicates lanes
whose items are complex numbers with real and imaginary components in 32-bit floating point representation.

or 64 bits per item), and interpreted either as integers (signed tions is executed in parallel to different sets of data. This
or unsigned) or floating-point values. Some of those specific reduces the amount of hardware control logic needed by N
formats for data items are summarized in Table 1. A con- times for the same amount of calculations, where N is the
version is then required from the sample bit length delivered width of the SIMD unit. In case of SSE, registers are 128-
by the analog-to-digital converter at the output of the front- bits wide, so each one can hold two complex floating point
end to the bit length and format of the data items feeding the samples (denoted as “32fc” in Table 1), or four complex short
software-defined receiver. Section 7 presents results for op- integers (denoted as “16ic” in Table 1). Operations are then
erations (shown in Figure 1) on data types labelled as “16ic” applied to those registers, thus executing the same instruc-
and “32fc” in Table 1. tion to multiple samples at a time, and saving clock cycles.
Hence, SIMD operations can only be applied to certain pre-
defined processing patterns. In addition, it is important to take
5. DATA PARALLELIZATION
into account that Intel’s and AMD’s processors will transfer
data to and from memory into registers faster if the data is
At a lower level of abstraction, some operations on incoming
aligned to 16-byte boundaries. While the compiler will take
data can be further parallelized by applying the same opera-
care of this alignment when using the basic 128-bit type, this
tion on different data samples at a time (i.e., parallelizing in
means that data has to be stored in sets of four 32-bit floating
the temporal index n). This is the approach of SIMD pro-
point values in memory for optimal performance. If data is
cessing, which has been embodied in different technologies
not stored in this kind of fashion then more costly unaligned
described below.
scalar memory moves are needed, instead of packaged 128-
bit aligned moves. Effective SSE will minimize the number
5.1. SSE technology of data movements between the memory subsystem and the
CPU registers. The data should be loaded into SSE registers
The family of Streaming SIMD Extensions (SSE) instruction
only once, and then the results moved back into memory only
sets is now present in all Intel and AMD processors of to-
once when they are no longer needed in that particular code
day’s computers. In this technology, the same set of instruc-
 Type name [15], thus expending extra clock cycles. The same applies to
Definition Sample stream
in VOLK
AVX-2 (which adds integer operations to the AVX instruc-
Signed integer,
8-bit two’s complement number
tion set), and most recent AVX-512, which introduces 512-bit
“8i” [S0 ], [S1 ], [S2 ], ... wide registers.
ranging from -128 to 127.
C type name: int8 t
Unsigned integer, 8 bits
“8u” ranging from 0 to 255. [S0 ], [S1 ], [S2 ], ... 5.3. NEON technology
C type name: unsigned char
Complex samples, with real and SIMD technology is also present in ARM processors through
“8ic” imaginary parts of type int8 t [S0I +jS0Q ], [S1I +jS1Q ], ... the NEON instruction set. The NEON instructions support 8-
C type name: lv 8sc t (*) bit, 16-bit, 32-bit, and 64-bit signed and unsigned integers, as
Signed integer,
16-bit two’s complement number
well as 32-bit single-precision floating point elements. NEON
“16i” [S0 ], [S1 ], [S2 ], ... technology includes support for unaligned data accesses and
ranging from -32768 to 32767
C type name: int16 t easy loading of interleaved data, so there is no need to account
Unsigned integer, 16 bits for that, on the contrary of SSEx and AXV. A draw back is
“16u” ranging from 0 to 65535. [S0 ], [S1 ], [S2 ], ...
that the NEON floating point pipeline is not entirely IEEE-
C++ type name: uint16 t
Complex samples, with real and 754 compliant. This is a problem for blocks when processing
“16ic” imaginary parts of type int16 t [S0I +jS0Q ], [S1I +jS1Q ], ... a large large number of floating point items, since the differ-
C type name: lv 16sc t (*) ent results will accumulate along samples and makes NEON
Unsigned integer, 32 bits
and SSE results not comparable. Countermeasures should be
“32u” ranging from 0 to 4294967295. [S0 ], [S1 ], [S2 ], ...
C type name: uint32 t
taken where applicable.
Signed numbers with fractional parts,
can represent values ranging from
“32f” ≈ 3.4×10−38 to 3.4×1038 [S0 ], [S1 ], [S2 ], ... 6. IMPLEMENTATION
with a precision of 7 digits (32 bits).
C type name: float 6.1. A multi-threaded GNSS receiver
Complex samples, with real and
“32fc” imaginary parts of type float [S0I +jS0Q ], [S1I +jS1Q ], ... Software defined receivers can be represented as flow graph
C++ type name: lv 32fc t (*)
of nodes. Each node represents a signal processing block,
Unsigned integer, 64 bits
“64u” ranging from 0 to 264 − 1. [S0 ], [S1 ], [S2 ], ... whereas links between nodes represents a flow of data. The
C type name: uint64 t concept of a flow graph can be viewed as an acyclic direc-
Signed numbers with fractional parts, tional graph with one or more source blocks (to insert sam-
can represent values ranging from
ples into the flow graph), one or more sink blocks (to termi-
“64f” ≈ 1.7×10−308 to 1.7×10308 [S0 ], [S1 ], [S2 ], ...
with a precision of 15 digits (64 bits). nate or export samples from the flow graph), and any signal
C type name: double processing blocks in between. The diagram of a processing
block (that is, of a given node in the flow graph), as imple-
Table 1. Data type names used in the VOLK library, which mented by the GNU Radio framework, is shown in Figure 2.
also provides the C programming language type name defini- Each block can have an arbitrary number of input and out-
tions marked with an asterisk (*). put ports for data and for asynchronous message passing with
other blocks in the flow graph. In all software applications
based on the GNU Radio framework, the underlying process
block. Listing 1 provides a pseudocode example of SIMD
scheduler passes items (i.e., units of data) from sources to
programming.
sinks. For each block, the number of items it can process
in a single iteration is dependent on how much space it has
5.2. AVX technology in its output buffer(s) and how many items are available on
Intel’s extension to the SSE family is the Advanced Vector the input buffer(s). The larger that number is, the better in
Extension (AVX), which extends the 128-bit SSE register into terms of efficiency (since the majority of the processing time
256-bit AVX register that consist of two 128-bit lanes. An is taken up with processing samples), but also the larger the
AVX lane is an extension of SSE4.2 functionality, with each latency that will be introduced by that block. On the contrary,
register holding eight samples of complex type 16-bit integer the smaller the number of items per iteration, the larger the
or four samples of complex type 32-bit float. AVX operates overhead that will be introduced by the scheduler.
most efficiently when the same operations are performed on
both lanes. On the contrary, cross-lane operations are limited Thus, there are some constraints and requirements in
and expensive, and not all bit shuffling combinations are al- terms of number of available items in the input buffers and
lowed. This leads to higher shuffle-overhead since many op- in available space in the output buffer in order to make all the
erations now require both cross-lane and intra-lane shuffling processing chain efficient. In GNU Radio, each block has a
Algorithm 1 Simplified pseudocode for each block’s thread being executed in its own, independent thread. This strategy
in GNU Radio. results in a software receiver that always attempts to process
1: Set thread’s processor affinity and thread priority. signal at the maximum processing capacity, since each block
2: Handle queued messages. in the flow graph runs as fast as the processor, data flow and
3: Compute items available on input buffer(s) as the differ- buffer space allows, regardless of its input data rate. Achiev-
ence between write and read pointers for all inputs. ing real-time is only a matter of executing the receivers full
4: Compute space on output buffer(s) as the difference be- processing chain in a processing system powerful enough to
tween write pointers to the first read pointer. sustain the required processing load, but it does not prevent
5: if all requirements are fulfilled then from executing exactly the same process at a slower pace, for
6: Get all pointers to input and output buffers. example, by reading samples from a file in a less powerful
7: Execute the actual signal processing (call work()). platform.
8: else
9: Try again. Figure 3 shows the flow graph diagram used in GNSS-
10: end if SDR. There is a signal source block (either a file or a radio-
11: Notify neighbors (tell previous and next blocks that there frequency front-end) writing samples in a memory buffer at a
is input data and/or output buffer space). given sampling rate; some signal conditioning (possible data
12: Propagate to upstream and downstream blocks that the type adaptation, filtering, frequency downshifting to base-
iteration has finalized. band, and resampling); a set of parallel channels, each one
13: Wait for data/space or a new message to handle. reading form the same upstream buffer and targeted to a dif-
ferent satellite; a block in charge of the formation of observ-
ables collecting the output of each satellite channel after the
runtime scheduler that dynamically performs all those com- despreading (and thus in a much slower rate); and a signal
putations, using algorithms that attempt to optimize through- sink, responsible for computing the position-velocity-time so-
put, implementing a process network scheduling that fulfills lution from the obtained observables and providing outputs in
the requirements described in [9]. Each processing block ex- standard formats (such as KML, GeoJSON, RINEX, RTCM
ecutes in its own thread, which runs the procedure sketched and NMEA).
in Algorithm 1. A detailed description of the GNU Radio
internal scheduler implementation (memory management, re- N parallel channels

quirement computations, and other related algorithms and pa-

Acquisition
rameters) can be found in [16], and of course in GNU Radio Signal Signal
Observables
Signal
Source Conditioner Sink
source code3 . Tracking
Nav.
msg

notify_upstream( ) notify_downstream( )
Runtime Scheduler Fig. 3. Simplified GNSS-SDR flow graph diagram. Each
from upstream from downstream
blue box is a signal processing block sketched in Figure 2.
Upstream output write Circular
Output
handle_msg( )
{ pointer Output
Here, only the data stream layer is represented, where differ-
… work( )
Buffer
}
Buffer ent data rates are indicated with different colors for the mem-
{
… ory buffers.
}
upstream read pointer from downstream
The flow graph in Figure 3 can be expanded to accom-
Fig. 2. Diagram of a signal processing block, as implemented modate more GNSS signal definitions in the same band (for
by GNU Radio. Each block has a completely independent instance, a GPS L1 C/A and Galileo E1b receiver), and to
scheduler running in its own execution thread and a messag- accommodate more bands (thus defining a multi-band, multi-
ing system for communication with other upstream and down- system GNSS receiver). In all cases, each of the process-
stream blocks. The actual signal processing is performed in ing blocks will be executing its own thread, defining a multi-
the work() method. Figure adapted from [17]. threaded GNSS receiver that efficiently exploits task paral-
lelization.

6.2. Single Instruction, Multiple Data (SIMD)

Under this scheme, software-defined signal processing
blocks read the available samples in their input memory The implementation of data parallelization techniques pre-
buffer(s), process them as fast as they can, and place the result sented in this paper extends the Vector-Optimized Library of
in the corresponding output memory buffer(s), each of them Kernels (VOLK4 , see [18, 19, 20]), an open source software
3 Available at https://github.com/gnuradio/gnuradio 4 Available at https://github.com/gnuradio/volk
library that provides an abstraction of optimized mathemati- {
cal routines targeting several SIMD processors. For each tar- / ∗ NEON i m p l e m e n t a t i o n ∗/
/∗ 1 ) Load 4 i t e m s from i n a and i n b ∗/
geted mathematical operation (referred to as kernels in this /∗ i n NEON 128− wide r e g i s t e r s ∗/
context), VOLK provides a “generic” (i.e. written in plain C /∗ 2 ) M u l t i p l y f o u r complex numbers ∗/
language) implementation that can run in virtually every mod- /∗ u s i n g NEON v e c t o r o p e r a n d s ∗/
ern processor, plus a number of versions for different SIMD /∗ 3) Store r e s u l t s in out p o i n t e r ∗/
}
technologies. For each architecture or platform that a devel- f o r ( n = n e o n i t e r s ∗ 4 ; n < n u m p o i n t s ; ++n )
oper wishes to vectorize for (e.g. SSE, AVX, NEON, etc.), {
a new implementation of a given function can be added to /∗ Plain C implementation for t a i l items ∗/
VOLK. The specific host computer devoted to run the soft- / ∗ t h a t do n o t f i t i n 4−i t e m p a c k e t s ∗/
out [ n ] = in a [ n ] ∗ in b [ n ] ;
ware receiver is then benchmarked by executing all the im- }
plementations that it is able to do. At runtime, when such }
functions are called by a software application, VOLK selects
the fastest implementation available for the given processor Listing 1. Example of data parallelization implementation: C
and memory alignment, thus addressing efficiency and porta- code structure for vector element-wise multiplication (16-bit
bility at the same time. Each specific kernel implementation integer complex data type) in NEON technology. Each data
for a given platform, SIMD technology version or run-time item is 32-bit wide, so 4 items fit in a 128-bit register which
condition is known as proto-kernel. can then be operated at the same time, thus saving clock cy-
cles.
As an additional key feature, VOLK provides
volk modtool, an application that generates an empty
copy of VOLK’s software structure (basically all the source 6.3. Single Instruction, Multiple Threads (SIMT)
code tree, with the benchmarking system, architecture and
machine abstractions, automatic selection of best implemen- In the SIMT execution model, the SIMD model is combined
tation at runtime, building scripts, etc., but without including with multi-threading. In a SIMT machine, there is a set
any kernel implementation) ready to be filled with other of processors, each of them enabled to execute N parallel
custom kernels that, by its specificity, are not included in the threads performing the same instruction. The key difference
library. Benefiting from such modular design, and VOLK’s between SIMD and SIMT is that in the latter it is possible
open source license, the authors of this paper developed a to combine a single instruction with multiple registers, mul-
complementary new module, so-called VOLK GNSSSDR, tiple addresses and multiple flow paths. This feature enables
which extends the original VOLK with operations that are the parallel processing of large vectors of data, and it is spe-
useful in the context of a GNSS software receiver, such cially well-suited to speed up the real-time high-resolution 3D
as joint Doppler removal and correlation of the incoming graphics computing-intensive tasks, such as texture process-
signals with multiple delayed local replicas of the PRN code ing. This execution model establishes a hierarchy of execu-
(as shown in Figure 1). Although this new library is used tion units, such as blocks (set of threads) and grids (set of
by GNSS-SDR, it can also be used independently for other blocks). In a GPU kernel call, the programmer must select
purposes. the number of threads per block and the number of blocks per
grid, and this will impact on the amount of computational re-
sources allocated during the call. For more detailed informa-
A pseudocode example of a proto-kernel is shown in List-
tion the reader is referred to [21]. In a GPU-accelerated GNSS
ing 1. The approach consists in processing as many input data
receiver, each of the receiver channels must share the GPU re-
items as possible by packing such items into SIMD registers,
sources, therefore, there is a trade-off in the resources alloca-
and computing the desired result using vector operands, either
tion for each channel and the maximum number of available
using in-line assembly or compiler intrinsics. The “tail” items
channels. If the GPU resource occupancy reaches 100%, the
that do not fit in those packs are then processed separately, in
GPU kernel calls are queued for later execution, so the inte-
a plain C implementation.
gration must be carefully designed in order to avoid blocking
s t a t i c i n l i n e void the whole flow graph execution.
volk gnsssdr 16ic x2 multiply 16ic neon (
l v 1 6 s c t ∗ out , const l v 1 6 s c t ∗ i n a ,
const l v 1 6 s c t ∗ in b , unsigned i n t num points ) For a practical implementation, we opted for
{ the NVIDIA GPU computing platform and the
const unsigned i n t n e o n i t e r s = num points / 4 ; CUDA programming model [22]. A CUDA ker-
/∗ n e o n i t e r s only i n t e g e r p a r t of d i v i s i o n ! ∗/
unsigned i n t n ;
nel was implemented integrating the operations of the
/∗ Declare other l o c a l v a r i a b l e s ∗/ VOLK GNSSSDR kernels “32fc rotator dot prod 32fc xn”
f o r ( n = 0 ; n < n e o n i t e r s ; ++n ) and “32fc xn resampler 32fc xn”, as defined in Figure 1, and
embedded into GNSS-SDR as an option for signal tracking volk gnsssdr profile, and is very welcome to con-
implementation. tribute with bug reports, improvements and the addition of
new kernels and proto-kernels.
7. RESULTS
7.1. SIMD acceleration
The presented VOLK GNSSSDR library provides more than
25 different kernels, for “8ic”, “16ic” and “32fc” data types, 7.1.1. Results in x86 / x86 64 architectures
each one with several proto-kernels, i.e., specific implemen-
The acceleration factor achieved by different SIMD im-
tations targeting a given SIMD technology, such as SSE2,
plementations with respect to the generic version, when
SSE3, SSE4.1, AVX and AVX2 (aligned and unaligned mem-
executed in x86 / x86 64 processor architectures, are
ory versions), as well as NEON. Some of the most relevant
shown in Figures 4 and 5. Notably, the carrier removal
for GNSS baseband processing were shown in Figure 1. The
and multiple correlation kernels for “16ic” and “32fc”
library was then integrated into GNSS-SDR, and the effec-
data types (denoted as 16ic rotator dot prod 16ic xn and
tiveness of the proposed implementation was tested in four
32fc rotator dot prod 32fc xn) showed accelerations close to
different computing platforms, with disparate processors, op-
×15 and ×25, respectively. Three correlators were used in
erating systems and compilers. Namely:
those experiments, although the kernel interface admits an ar-
• Platform #1 - Server: a Dell’s PowerEdge R730 server bitrary number of them.
housing a CPU with two Intel Xeon E5-2630 v3 at
2.4 GHz (8 cores, 16 threads each) and an NVIDIA 7.1.2. Results in ARM architectures
Tesla K10 GPU with 2 x 1536 CUDA cores clocked
at 745 MHz. The operating system during tests was The acceleration factor achieved by NEON implementations
GNU/Linux Ubuntu 14.04, 64 bits, using GCC 4.9.2. with respect to the generic version, when executed in ARM-
based computing platforms, are shown in Figures 6 and 7.
• Platform #2 - Laptop: Apple’s MacBook Pro Late Although, as stated in Section 5.3, NEON is not IEEE-754
2013, with an Intel Mobile Core i7-4558U (quad-core) compliant in its floating-point operations, numerical results
CPU at 2.4 GHz (active cores can be speeded up to show that they remain reasonably close to those obtained by
3.8 GHz), and Hyper Threading technology allows the IEEE-754 compliant technologies (e.g., SSE) when input vec-
system to recognize eight total “cores” or “threads” tors are as long as 50, 000 complex items, which corresponds
(four real and four virtual), plus an NVIDIA GeForce to the number of samples in 1 ms when sampled at 50 Msps
GT 750M GPU with 384 CUDA cores clocked at 967 in baseband, thus covering the GNSS signal with maximum
MHz. The operating system during tests was Mac OS available bandwidth (i.e., Galileo E5).
X 10.11, using Apple LLVM / Clang version 7.0.2.

• Platform #3 - Embedded development kit: NVIDIA’s 7.2. Integration in a GNSS software receiver
Jetson TK1 developer kit, equipped with a quad-
In order to measure the performance of the parallelization
core ARM Cortex-A15 CPU at 2.32 GHz and an
strategies in combination with the data parallelization tech-
NVIDIA Kepler GPU with 192 CUDA cores clocked
niques described in this paper when applied to a full software-
at 950 MHz. The operating system during tests was
receiver, both the VOLK GNSSSDR library and the GPU-
GNU/Linux Ubuntu 14.04, 32 bits, using GCC 4.8.4.
targeted implementations were integrated into GNSS-SDR.
• Platform #4 - Mini-computer: Raspberry Pi 3 Model The results obtained on the aforementioned computing plat-
B, equipped with a Broadcom BCM2837 CPU (64 bit, forms are shown below.
ARMv8 quad-core ARM Cortex A53) clocked at 1.2
GHz. The operating system used during tests was Rasp- 7.2.1. Number of channels processed in real-time
bian GNU/Linux 8 (jessie), 32 bits, using GCC 4.9.2.
Figure 8 shows the execution time for different correlation
This Section reports the results obtained by some of the key vector lengths (2048, 4096, and 8192) and for different num-
kernels implemented in the VOLK GNSSSDR library and the ber of parallel channels targeting GPS L1 C/A signals and
performance achieved by the full software receiver in the de- using three correlators per channel. This configuration mim-
scribed computer environments. All these results were ob- icks typical receiver’s configurations, and corresponds to the
tained using GNSS-SDR v0.0.7 [23]. The reader is free to correlation lengths to be computed in 1 ms when sampling at
reproduce the experiments in his/her own machine by build- 2.048, 4.096, and 8.192 Msps, respectively. In all platforms,
ing that specific source code snapshot (or any other more re- volk profile and volk gnsssdr profile were ex-
cent version) and executing the provided profiling application ecuted before the tests in order to enjoy the fastest available
SIMD implementation for each specific processor. Remark- isters and 64-bit NEON for data parallelization; and FPGA
ably, ARM-based platforms achieved real-time processing of offloading in order to target real-time operation with higher
four or more channels in the narrowest bandwidth configura- signal bandwidths in multi-band, multi-constellation configu-
tion. rations.

7.2.2. GPU offloading

ACKNOWLEDGEMENTS
Fig. 9 shows the execution time for different correlation vec-
tor lengths (2048, 4096, and 8192) and for different num-
This work has been developed in the frame of AUDI-
ber of parallel channels targeting GPS L1 C/A signals, with
TOR. This project has received funding from the European
three correlators per channel. Results show that, as expected,
GNSS Agency under the European Unions Horizon 2020 re-
the amount of available GPU resources limits the paralleliza-
search and innovation programme under grant agreement no.
tion of correlation operations, hence defining the slope of the
687367. Authors ere also supported by the Spanish Ministry
computing time growth. Platform #1 is equipped with the
of Economy and Competitiveness through project TEC2015-
most powerful GPU, and thus it showed the best performance
69868-C2-2-R (MINECO/FEDER) and by the Government
for all the tested correlation lengths. Regarding the real-time
of Catalonia under Grant 2014–SGR–1567.
limit, defined at 1 ms, Table. 2 shows the maximum parallel
channels available for each platform.

REFERENCES
Table 2. Maximum number of real-time parallel channels for
each platform using GPU accelerators. [1] G. W. Heckler and J. L. Garrison, “SIMD correla-
Correlator length 2048 4096 8192 tor library for GNSS software receivers,” GPS Solu-
Platform #1 65 45 25 tions, vol. 10, no. 4, pp. 269–276, Nov. 2006, DOI:
Platform #2 12 11 10 10.1007/s10291-006-0037-5.
Platform #3 1 0 0 [2] B. Chapman, G. Jost, and R. van der Pas, Using
OpenMP: Portable Shared Memory Parallel Program-
ming, The MIT Press, Cambridge, MA, 2008.
8. CONCLUSIONS
[3] N. P. Jouppi and D. Wall, “Available instruction-
This paper described several parallelization techniques ad- level parallelism for superscalar and superpipelined ma-
dressing computational efficiency, at different abstraction lay- chines,” in Proc. International Conference on Archi-
ers, and their specific application in the context of software- tectural Support for Programming Languages and Op-
defined GNSS receivers. All those concepts were applied into erating Systems (ASPLOS-III), Boston, MA, 1998, pp.
a practical implementation available online under a free and 272–282.
open source software license. Building upon well-established
[4] I. Bartunkova and B. Eissfeller, “Massive parallel al-
open source frameworks and libraries, this paper showed that
gorithms for software GNSS signal simulation using
it is possible to achieve real-time operation in different com-
GPU,” in Proc. of the 25th International Technical
puting environments. Portability was demonstrated by build-
Meeting of The Satellite Division of the Institute of Nav-
ing and executing the same source code in a wide range of
igation, Nashville, TN, Sept. 2012, pp. 118–126.
computing platforms, from high-end servers to tiny and af-
fordable computers, using different operating systems and [5] GNSS-SDR. An Open Source Global Navigation Satel-
compilers, and showing notable acceleration factors of key lite Systems Software Defined Receiver, Website:
operations in all of them. http://gnss-sdr.org. Accessed: January 30,
2017.
As a practical outcome of the presented work, this paper
[6] GNU Radio. The Free & Open Software Radio Ecosys-
introduced, to the best of authors’ knowledge, the first free
tem, Website: http://gnuradio.org. Accessed:
and open source software-defined GNSS receiver able to sus-
January 30, 2017.
tain real-time processing and to provide position fixes (as well
as other GNSS data in form of RINEX files or RTCM mes- [7] G. Kahn, “The semantics of a simple language for par-
sages streamed over a network) in ARM-based devices. allel programming,” in Information processing, J. L.
Rosenfeld, Ed., Stockholm, Sweden, Aug 1974, pp.
Future work will be related to the application of OpenMP 471–475, North Holland.
for task parallelization; AVX+ technology using 512-bit reg-
 [8] G. Kahn and D. B. MacQueen, “Coroutines and net- percomputing, Tucson, Arizona, May 31 - June 4, 2011,
works of parallel processes,” in Information processing, pp. 265–274.
B. Gilchrist, Ed., Amsterdam, NE, 1977, pp. 993–998,
North Holland. [16] T. W. Rondeau, Explaining the GNU Radio Scheduler,
Sep. 2013, Slides published online at http://www.
[9] T. M. Parks, Bounded Scheduling of Process Networks, trondeau.com/blog. Accessed: January 30, 2017.
Ph.D. thesis, University of California, Berkeley, CA,
Dec. 1995. [17] J. Corgan, “GNU Radio runtime operation,” in Proc.
GNU Radio Conference, Washington, DC, Aug. 24–28
[10] B. Huang, Z. Yao, F. Guo, S. Deng, X. Cui, and M. Lu, 2015, pp. 1–12.
“STARx – A GPU based multi-system full-band real-
time GNSS software receiver,” in Proc. of the 26th In- [18] Vector-Optimized Library of Kernels, Website: http:
ternational Technical Meeting of The Satellite Division //libvolk.org. Accessed: January 30, 2017.
of the Institute of Navigation, Nashville, TN, Sept. 2013, [19] T. W. Rondeau, N. McCarthy, and T. O’Shea, “SIMD
pp. 1549–1559. programming in GNU Radio: Maintainable and user-
[11] K. Karimi, A. G. Pamir, and H. Afzal, “Accelerat- friendly algorithm optimization with VOLK,” in Proc.
ing a cloud-based software GNSS receiver,” Intl. Jour- of the Wireless Innovation Forum Conference of Wire-
nal of Grid and High Performance Computing, vol. less Communication Technologies and Software Defined
6, no. 3, pp. 17–33, Jul./Sep. 2014, DOI: 10.4018/i- Radio, Washington, DC, Jan. 2013.
jghpc.2014070102. [20] N. West and D. Geiger, “Accelerating software radio
on ARM: Adding NEON support to VOLK,” in Proc.
[12] L. Xu, N. I. Ziedan, X. Niu, and W. Guo, “Correlation
IEEE Radio and Wireless Symposium, Newport Beach,
acceleration in GNSS software receivers using a CUDA-
CA, Jan. 2014.
enabled GPU,” GPS Solutions, pp. 1–12, Available on-
line since Feb. 2016, DOI: 10.1007/s10291-016-0516-2. [21] CUDA Programming Guide, Website:
http://docs.nvidia.com/cuda/
[13] Xilinx, San Jose, CA, Zynq-7000 All Programmable
cuda-c-programming-guide. Accessed: Jan-
SoC Overview DS190 (v1.9). Product Specification, Jan.
uary 30, 2017.
2016.
[22] NVIDIA CUDA Technology, Website: http://www.
[14] E. D. Kaplan, Understanding GPS. Principles and Ap-
nvidia.com/CUDA. Accessed: January 30, 2017.
plications, Artech House Publishers, 1996.
[23] C. Fernández–Prades, J. Arribas, and L. Esteve, GNSS-
[15] D. S. McFarlin, V. Arbatov, F. Franchetti, and
SDR v0.0.7, Zenodo, May 2016, DOI : 10.5281/zen-
M. Püschel, “Automatic SIMD vectorization of Fast
odo.51521. Available online at https://github.com/gnss-
Fourier Transforms for the Larrabee and AVX instruc-
sdr/gnss-sdr/releases/tag/v0.0.7.
tion sets,” in Proc. 25th International Conference on Su-
 Acceleration with respect to plain C Acceleration with respect to plain C Acceleration with respect to plain C

0
5
10
15
20
25

0
5
10
15
20
25
0
5
10
15
20
25
a
av a av
x2 x2 a a
re a ss
e3 ax
lo ss v2
ad e3
a a re
lo
ss s ad a
e3 se3 ss
re e2
lo ge
a ge ne
ge
ge ge d ne ric
ne n ric n er
r i c er i re ic
re c lo
lo ad u
a
u u d ax
av av u v2
x2 x2 u ss
e3
ss
16ic x2 dot prod 16ic

re
lo e3 u

16ic 32fc x2 rotator 16ic

ad re ss
u lo

16ic rotator dot prod 16ic xn

e2
ss ad
e3

Acceleration with respect to plain C Acceleration with respect to plain C Acceleration with respect to plain C

0
5
10
15
20
25
0
5
10
15
20
25
0
5
10
15
20
25

a a
av av
x x 2
a
a ss
e2 a
ss ss
e3 e2
ge ge
ge ne ne
ne ric ge ge ric
ric ne ne
re ric ric
lo
ad sa
t
u u
av u av
x ss x 2
e2
16ic x2 dot prod 16ic xn

u
16ic xn resampler 16ic xn

Operations were applied to vectors of 8111–item length, and the results were averaged over 1987 iterations.
ss 32fc rotator dot prod 32fc xn ss
e3 e2

Fig. 4. Acceleration factor with respect to the generic implementation achieved by different proto-kernels in Platform #1.
 16ic x2 dot prod 16ic 16ic x2 dot prod 16ic xn

Acceleration with respect to plain C

Acceleration with respect to plain C 25 25

20 20

15 15

10
10

5
5

0
0

e2

ric

e2
sa
ss

ss
ne
e2

ric

e2

ric
a

u
ge
ss

ss
ne

ne
a

u
ge

ge
16ic 32fc x2 rotator 16ic 16ic xn resampler 16ic xn
Acceleration with respect to plain C

25 25

20 Acceleration with respect to plain C

20

15
15

10
10
5
5
0
e3

ad

ric

ad

e3

ad
ss

ss
lo

lo

lo
ne

0
re

re

re
a

u
ge

e2

ric

e2
e3

ric

e3

ss

ss
ss

ss

ne
ne

u
a

ge
ge

16ic rotator dot prod 16ic xn 32fc rotator dot prod 32fc xn
Acceleration with respect to plain C

Acceleration with respect to plain C

25 25

20 20

15 15

10 10

5 5

0 0
e3

ad

ric

ad

e3

e3

ric

ad

e3
av

av
ss

ss

ss

ss
lo

lo

lo
ne

ne
re

re

re
a

u
a

u
ge

ge
e3

ric

ric
ss

ne

ne
a

ge

ge

Fig. 5. Acceleration factor with respect to the generic implementation achieved by different proto-kernels in Platform #2.
Operations were applied to vectors of 8111–item length, and the results were averaged over 1987 iterations.
 16ic x2 dot prod 16ic 16ic x2 dot prod 16ic xn
Acceleration with respect to plain C

Acceleration with respect to plain C

25 25

20 20

15 15

10 10

5 5

0 0
ric

on

ric

on

a
sa
m

vm

vm
ne

ne
ne

ne
tv

tv
ric
ge

ge
on

on
op

op
ne
ne

ne
on

on
ge
ne

ne
16ic 32fc x2 rotator 16ic 16ic xn resampler 16ic xn
Acceleration with respect to plain C

25 25

20 Acceleration with respect to plain C 20

15
15

10
10
5
5
0
ic

ad

on

ad
er

lo

ne

lo

0
n

re

re
ge

ric

on
ric

on

ne
ne

ne
ne

ge
ge

16ic rotator dot prod 16ic xn 32fc rotator dot prod 32fc xn
Acceleration with respect to plain C

Acceleration with respect to plain C

25 25

20 20

15 15

10 10

5 5

0 0
ric

ad

on

ric

ad

on
vm
lo

ne

lo

ne
ne

ne
re

re
ge

ge
on
ric

ric
ne
ne

ne
ge

ge

Fig. 6. Acceleration factor with respect to the generic implementation achieved by different proto-kernels in Platform #3.
Operations were applied to vectors of 8111–item length, and the results were averaged over 1987 iterations.
 16ic x2 dot prod 16ic 16ic x2 dot prod 16ic xn
Acceleration with respect to plain C

Acceleration with respect to plain C

25 25

20 20

15 15

10 10

5 5

0 0
ric

on

ric

on

a
sa
m

vm

vm
ne

ne
ne

ne
tv

tv
ric
ge

ge
on

on
op

op
ne
ne

ne
on

on
ge
ne

ne
16ic 32fc x2 rotator 16ic 16ic xn resampler 16ic xn
Acceleration with respect to plain C

25 25

20 Acceleration with respect to plain C 20

15
15

10
10
5
5
0
ic

ad

on

ad
er

lo

ne

lo

0
n

re

re
ge

ric

on
ric

on

ne
ne

ne
ne

ge
ge

16ic rotator dot prod 16ic xn 32fc rotator dot prod 32fc xn
Acceleration with respect to plain C

Acceleration with respect to plain C

25 25

20 20

15 15

10 10

5 5

0 0
ric

ad

on

ric

ad

on
vm
lo

ne

lo

ne
ne

ne
re

re
ge

ge
on
ric

ric
ne
ne

ne
ge

ge

Fig. 7. Acceleration factor with respect to the generic implementation achieved by different proto-kernels in Platform #4.
Operations were applied to vectors of 8111–item length, and the results were averaged over 1987 iterations.
 ×10−3 CPU Correlation size: 2048 samples ×10−3 CPU Correlation size: 4096 samples
1.6 3.5
Platform #1 Platform #1
1.4 Platform #2 Platform #2
3
Platform #3 Platform #3
1.2 Platform #4 Platform #4
2.5
Execution time [s]

Execution time [s]

1
2
0.8
1.5
0.6
1
0.4

0.2 0.5

0 0
0 20 40 60 80 100 0 20 40 60 80 100
Number of parallel channels Number of parallel channels

×10−3 CPU Correlation size: 8192 samples

9
Platform #1
8 Platform #2
Platform #3
7 Platform #4
Execution time [s]

0
0 20 40 60 80 100
Number of parallel channels

Fig. 8. CPU execution times (averaged for 1000 independent realizations) for different number of parallel channels and cor-
relation lengths (2048, 4096 and 8192 samples of type “32fc”) and executing platforms. Each channel was configured with
3 correlators. The intersection of these plots with the dashed red line at 1 ms indicates the number of channels that a given
platform can sustain in real-time for GPS L1 C/A signals.
 GPU Correlation size: 2048 samples GPU Correlation size: 4096 samples
0.02 0.02
Platform #1 Platform #1
0.018 Platform #2 0.018 Platform #2
0.016 Platform #3 0.016 Platform #3
Execution time [s]

Execution time [s]

0.014 0.014
0.012 0.012
0.01 0.01
0.008 0.008
0.006 0.006
0.004 0.004
0.002 0.002
0 0
0 20 40 60 80 100 0 20 40 60 80 100
Number of parallel channels Number of parallel channels

GPU Correlation size: 8192 samples

0.02
Platform #1
0.018 Platform #2
0.016 Platform #3
Execution time [s]

0.014
0.012
0.01
0.008
0.006
0.004
0.002
0
0 20 40 60 80 100
Number of parallel channels

Fig. 9. GPU execution times (averaged for 1000 independent realizations) for different number of parallel channels and cor-
relation lengths (2048, 4096 and 8192 samples of type “32fc”) and executing platforms. Each channel was configured with
3 correlators. The intersection of these plots with the dashed red line at 1 ms indicates the number of channels that a given
platform can sustain in real-time for GPS L1 C/A signals.