GNSS Baseband Processing in a Multi-core Platform

J. Raasakka, H. Hurskainen, and J. Nurmi Department of Computer Systems

Tampere University of Technology Tampere, Finland

{firstname.lastname@tut.fi}

Abstract— In this paper we describe our work on the design and implementation of GNSS application on a multi-core platform. The emerging systems and advanced algorithm development create the need for flexibility for GNSS receiver, which cannot be met with currently widely used ASIC technology approach. Different technology solutions to meet the flexibility criteria, such as DSPs, and FPGAs are evaluated in this paper with detailed description of our multi-core realization. The multi-core platform designed and developed within CRISP project contains 9 cores per RFD and software benchmarking estimates that up to 13 satellites could be tracked per core. This could be extrapolated to tracking performance of 104 satellites per RFD, when a single core is used for input preprocessing.

Keywords- GNSS, receiver, FPGA, DSP, multi-core

I. INTRODUCTION Satellite navigation has become one of our daily based

technologies. We can use the technology for car navigation, location tagging of photos, animal tracking, and many other common tasks. All of this sounds like modern hi-tech, but still, the system used for this is mainly from last decade, and relies on a constellation of approximately 30 satellites. This situation will change in next few years when competing systems will arise. The number of satellites usable to our every-day navigation will increase close to one hundred.

A. Evolution of the satellite navigation systems

Currently the most widely used Global Navigation Satellite System (GNSS) is U.S. based GPS (Global Positioning System). GPS became available in the last half of the 1990’s and its civilian usage started to grow exponentially after May 2000 removal of the intentional degradation of the signals.

Besides GPS, there are also other global satellite navigation systems. Russian GLONASS is about to achieve its full constellation again, and the development of European Galileo is ongoing, together with the development of Chinese Compass and several regional systems.

Of course the new systems are not just copies of the old one, and new signal characteristics and advanced modulation techniques have been presented. It is evident that the receiver solutions used in legacy receivers are not fully compatible with the requirements set by the characteristics of these new signals and systems.

B. Receiver challenges The main functionality of any GNSS receiver is to receive

the transmitted signal from multiple satellites and use these signals to decode navigation data and to measure the travelling time between the point of transmission (satellite) and the point of reception (receiver). It does not sound complex but we need to keep in mind that the signals are transmitted at a very low power and the signals have to travel over 20000 km. This means that the signal power level seen in the face of Earth is approximately -157 dBW. Noise power level in typical GPS receiver bandwidth of 2MHz is approximately -138 dBW [1]. It is quite obvious that the first challenge of the receiver is to find the signals of interest.

Another challenge is the timing. Radio waves propagate at the speed of light and when measuring the time to travel, even a small mistake means a large error in distance, which relates directly to the positioning accuracy. So, the receiver should be both able to find the transmitted signals hidden under the thermal noise floor and to track them well enough to be able to determine the accurate timing of the signals.

The current solution for these aforementioned challenges is using digital signal processing. Most of the used navigational signals use CDMA technique where signal power is distributed to a larger bandwidth and which also enables the separation of transmitters through usage of unique spreading codes. In receiver, the main tasks of the digital signal processing part are to acquire and track the incoming signals. Acquisition task is a 2-dimensional search over unknown spreading code delay and Doppler frequency. After acquisition task has provided rough estimates of signals parameters, the tracking task can fine tune these estimations and provide both data reception and exact timing of the signal. Usually each received signal needs its own tracking task, or a channel when talking about receiver.

Both acquisition and tracking tasks are composed of relatively simple calculus (mostly multiplication and addition), but the amount of calculus needed with the hard deadline requirements makes these tasks unsuitable for typical embedded microprocessors. Usually either Digital Signal Processor (DSP) or dedicated hardware accelerator is used to perform these tasks.

II. DISCUSSION ON GNSS RX PLATFORMS Traditionally GPS (the only fully functional GNSS at the

time of writing) receivers have been implemented with an

978-1-61284-4577-0188-7/11/$26.00 c©2011 IEEE42

ASIC technology. Either chipsets (where RF functionality and digital baseband/receiver functionality have been separated) or a single chip (mixed mode ASIC) have been used to realize the functionality of a satellite navigation receiver. Usage of ASICs provides potentially low cost (when high volumes are produced) and low power consumption, but on the downside is the rigid implementation which does not anymore necessarily meet the flexibility requirements from advanced algorithm development and evolving system domain.

A. Field Programmable Gate Arrays

Field Programmable Gate Array (FPGA) technology has successfully been used to implement the GNSS functionality. E.g. in [2], [3], and [4] the FPGA’s are used to implement receiver functionality, while claiming the platform’s flexibility through reconfigurability.

The main advantage of FPGA technology over ASIC is mainly in the flexibility due FPGAs being reconfigurable structures. Another benefit comes from cost when receivers are produced in low or medium volumes. It is estimated that in cheap devices, developing ASIC becomes cheaper after approximately one million sold units [5]. In terms of power consumption and/or maximum clock frequency, the ASIC technology has still an advantage.

B. Digital Signal Processors

DSPs could be listed as one alternative approach for executing the functions of GNSS receiver. The DSPs have the advantage of featuring single instruction MAC (multiply and accumulate) operation. This special operation, together with the parallel execution and/or multi-issuing enables the efficient implementation of correlation, which is widely used in GNSS processing [6]. DSPs also have a good support for Fast Fourier Transform (FFT), which can be used to speed up the GNSS acquisition.

GNSS reception has been ported to DSP, e.g. in [7] a DSP based receiver was implemented in TMS320C6416 DSP from Texas Instruments. This study reports GPS L1 functionality with a real-time performance of 43 signal tracking channels in parallel, continuous acquisition performed in background, and a navigation accuracy of 5 m. To achieve this, fixed point arithmetic and manual pipelining of feedback loops has been exploited. In another study [8], a 12-channel GPS receiver has been created using the same TMS320C6416 DSP.

In general, it has been shown that DSPs are capable of performing the desired functionality of a GNSS application in real-time. They also meet the mandatory flexibility requirement due to the software implementation.

C. Multi-core Platforms

An emerging approach for GNSS processing has been the multi-core approach. Lately this issue has been studied in [9] and [10]. The parallel nature of GNSS application can exploit the parallelism available in an environment consisting of multiple processing cores. Due to the relatively simple calculus of the baseband processes the application itself does not need highly complex cores. If the used cores support DSP

operations, like MACs, the GNSS implementation in this environment becomes quite attractive approach.

The cost of producing a multi-core platform is comparable to ASIC technology. After high non-recurring engineering costs a relatively cheap chips can be produced, yet maintaining the platforms flexibility due software implementation of targeted application.

A comparative table of discussed technologies is shown in Table 1. It is estimated that multi-core technology shares the property of having a high development costs and low unit cost with ASIC and also has a comparative performance and power consumption. Since the multi-core technology has superior flexibility, it gains a potential competitive edge when compared to other technologies. This comparison does not count the efforts in design time and creating tools which, without any doubt are currently much higher with multi-core approach than other technologies where the maturity has already been reached.

Table 1 Relative comparison of ASIC, FPGA, DSP and multi-core technologies, (H=high, M=medium, L=low).

Dev. cost

Perf. Power Unit cost Flex.

ASIC H H L L L FPGA M H M H M DSP L H/M M M H

Multi-core

H H L/M L H

Additional advantage from a multi-core platform is its

versatility when assigning the application to be executed. For example, in case of partial malfunction of a single core in platform, the application may still be executed without errors if platform’s dependability is managed properly. Dependability management system can block out these erroneously behaving parts of the complex platform, where malfunction is either born in run time or is a constant flaw from manufacturing process.

III. GNSS IN A MULTI-CORE PLATFORM In this section we describe the CRISP multi-core GNSS

application.

A. Chosen Multi-core Platform

In our earlier work we used the multi-core platform designed and manufactured in CRISP project. Our earlier papers defined the targeted GNSS application [10] and estimated its complexity in the used platform [11]. The functionality of the application in PC environment was verified in [12].

The chosen multi-core platform is called Reconfigurable Fabric Device (RFD) and is illustrated in Figure 2. This device contains nine Xentium cores [13], two Smart memories and dependability manager hardware. The cores and other units are communicating through Network-on-Chip (NoC). Each RFD has five parallel, off-chip interfaces, which can be used to connect the RFD to other RFDs or General Purpose Processors (GPPs). [14]

43

Figure 1 A simplified block diagram of the RFD architecture;

R=router, X=Xentium core, DM=Dependability manager, MEM=Smart memory, and IF=parallel interface to outside of

the chip.

A commercial GPS L1 RF front end is used to receive the GNSS signals. The single bit digital output stream of the radio is fed to the FPGA located on the demonstration platform. FPGA converts the data to a parallel format and each block of data is forwarded to the array of cores through one parallel interface.

GPP is connected to the NoC via another parallel interface. GNSS application uses the GPP to calculate the receiver’s position from the measured pseudoranges. Navigation computation is less complex than baseband processing, and uses only a single thread. This makes GPP more suitable for navigation computation.

B. Main GNSS Tasks

The overview of the GNSS application processes is given in Figure 2. The radio stream is fed to the digital baseband processing, which is executed on the multi-core platform. The baseband processing consists of a single task of input preprocessing, which processes received samples to be compatible with the rest of the system. The data stream is then broadcasted to multiple parallel acquisition and/or tracking tasks, which forward their outputs to a single navigation task. The navigation task is executed in a single general purpose processor. The details of navigation task implementation are not covered in this paper.

Figure 2 Overview of GNSS application tasks. Input preprocessing precedes multiple acquisition and/or tracking tasks.

1) Input preprocessing Task Input preprocessing task is used to lower the computational

requirements of the other tasks in the system. Input preprocessing receives input from the GNSS radio through FIFO. FIFOs are located in Smart memory tiles.

Data from the radio is first converted into baseband where it is filtered and decimated. After processing, the sampling frequency of the radio data is lowered from 16.368 MHz to 2.046MHz, which is more suitable for software implementation of GNSS acquisition and tracking tasks. Data is processed in 1ms blocks consisting of 16368 samples. After processing, each 1ms block consists of 2046 samples. Each block is assigned a timestamp so that all processing tasks can be easily synchronized.

For the acquisition task the output of the input preprocessing task is put in a FIFO. For the tracking tasks the input preprocessing task writes directly into the local memory of the first Xentium core that is assigned to execute the tracking task. Figure 3 shows the dataflow within the input preprocessing task.

Figure 3 Input preprocessing task. Xn represents an arbitrary Xentium core.

2) Acquisition Task Acquisition task implements the well-known FFT

acquisition technique [15]. The GNSS acquisition task uses 2 Xentium cores to perform the FFT acquisition. The two Xentium cores process the data in pipelined manner. The first Xentium is responsible of performing FFT and IFFT operations. The second Xentium handles the additional multiplication, addition, and bit reversal operations needed for the standard FFT acquisition. The two Xentiums communicate between each other through 2 FIFOs. Figure 4 shows the dataflow between the two Xentium cores executing the acquisition task.

Figure 4 Acquisition task dataflow. Xn represents an arbitrary Xentium core.

44

3) Tracking Task Tracking task performs serial correlation of the locally

generated code against the data received from the input preprocessing task. Current implementation uses three correlators, which enable the usage of typical GNSS receiver tracking algorithms. Correlation results are produced every millisecond, and are written into FIFO where the GPP reads these results and produces correction parameters to the tracking tasks. Dataflow between the Xentiums cores, which are assigned to execute the tracking task, is implemented in daisy chained manner. Input preprocessing task writes into the first Xentium core executing the tracking task, which in turn will forward the data to the next Xentium core in the tracking chain. Daisy chaining of the dataflow between tracking tasks helps in distributing the network load throughout the NoC. Figure 5 shows how the different tracking tasks executed in Xentium cores (Xn) are connected together.

Figure 5 Daisy chaining of tracking tasks.

Tracking task also produces phase measurements, which are required to calculate the user Position, Velocity, and Time (PVT) solution. The phase measurements have variable measurement interval, but typical value for these measurements is 1 second.

C. Future focus of the application development

The CRISP RFD platform has been designed with the principles of locality-of-reference in mind. Implementing DSP algorithms and applications efficiently on the platform means that (temporary) data is available as close as possible to the data processing units. Therefore, the Xentium cores in the RFD are equipped with small local data memories that are tightly connected to the datapath of the processor. Having the (temporary) data locally available to the datapath avoids inefficient global data transfers over the chip. Different levels of data memories are available in the platform: local tightly-coupled data memories, distributed on-chip memory and external memory. In order to efficiently implement DSP applications on the platform, DSP developers need to efficiently map the memory needs to the available memory resources that are available in the hardware avoiding inefficient global data transfers.

Since each Xentium core has 16KB of local tightly-coupled data memory [14], it constraints the size of the data blocks that can be efficiently processed within each Xentium core. To circumvent this limitation, Smart memory tiles can be used as

an additional storage buffer. This however increases the NoC traffic substantially. Another method that is being investigated is to divide the processing of a bigger block into several sub blocks, and forward these smaller blocks to different Xentium cores. After processing of the sub blocks, the results can be combined. With these methods we can potentially increase the block size. This would allow us to use e.g. longer FFTs in the acquisition task. Increasing the block size in the acquisition task would yield increased sensitivity and accuracy of the acquisition algorithm.

IV. APPLICATION EVALUATION The processing requirements of the implemented GNSS

application tasks are evaluated against the total clock cycles available for the processing during the block time interval. A single Xentium core runs at 200MHz clock frequency, so 200kcycles are available for processing each 1ms data block. Table 2 shows the different tasks needed for the GNSS application and their processing requirements for 1ms data block.

It can be seen from the Table 2 that input preprocessing is by far the most resource consuming task. This is mainly due to the FIR filtering needed prior to downsampling. Acquisition and tracking tasks require less resources and multiple tasks per core can be executed. Since the platform has nine cores, and one is always used for input preprocessing, we can assume that the remaining eight cores could reach the tracking task execution up to 104 satellites (or 13 per core). This is more than enough even with future estimates of available satellites and signals for navigation.

However, the evaluation does not take into account the time that is used for transferring data through the NoC to each Xentium core.

Table 2 Processing requirements for 1ms block of data. Task Clock Cycles Processor

Load Input Preprocessing (FIR) 47058 23.5%

Acquisition FFT+IFFT 9374 4.7% Acquisition MUL+SUM

+ 2x Bit Reversal 9364 4.7%

Tracking 14331 7.2%

V. CONCLUSIONS In this paper we presented our work on the design and

implementation of GNSS application on a multi-core platform. The multi-core approach is fulfilling the need for flexibility in GNSS receivers. This requirement for flexibility is caused by the emerging systems and advanced algorithm development. Currently widely used ASIC technology approach suffers from being hard to modify. More flexible technologies, such as DSPs and FPGAs have been successfully used for GNSS receiver realization. However, we believe that multi-core platforms could offer a viable alternative. The multi-core platform designed and developed within the CRISP project contains 9 cores per RFD, and software benchmarking estimates that up to 13 satellites per core could be tracked. We

45

can extrapolate this to tracking performance of 104 satellites per RFD, when a single core is dedicated to input preprocessing.

ACKNOWLEDGEMENTS This research is conducted within the FP7 Cutting edge

Reconfigurable ICs for Stream Processing (CRISP) project (ICT-215881) supported by the European Commission.

REFERENCES [1] M.S. Braasch, and A.J. van Dierendonck, "GPS receiver architectures

and measurements," Proceedings of the IEEE , vol.87, no.1, pp.48-64, Jan 1999

[2] P.J. Mumford, K. Parkinson, and A. Dempster, “The Namuru Open GNSS Research Receiver,” in Proc. of ION GNSS 2006, Sep 2006, Fort Worth, TX, pp. 2847–2855.

[3] S. Ganguly, A. Jovancevic, A.D. Saxena, B. Sirpatil, and S. Zigic, “Open Architecture Real Time Development System for GPS and Galileo,” in Proc. of ION GNSS 2004, Long Beach, California, Sep 2004, pp. 2655–2666.

[4] H. Hurskainen, T. Paakki, Z. Liu, J. Raasakka, and J. Nurmi, “GNSS Receiver Reference Design,” in Proc. of 4th Advanced Satellite Mobile Systems (ASMS) conference, Bologna, Italy, Aug 2008, pp. 2707–2714.

[5] P.G. Paulin, "DATE panel chips of the future: soft, crunchy or hard?," Design, Automation and Test in Europe Conference and Exhibition, 2004. Proceedings , vol.2, no., pp. 844- 849 Vol.2, 16-20 Feb. 2004

[6] G.W. Hein, T. Pany, S. Wallner, J-H. Won, “Platforms for a Future GNSS Receiver – A Discussion of ASIC, FPGA, and DSP Technologies”, InsideGNSS, March 2006, pp. 56-62.

[7] T.E. Humbhreys, M.L. Psiaki, P.M. Kintner Jr., B.M. Ledvina. “GNSS Receiver Implementation on a DSP: Status, Challenges, and Prospects” In Proc of ION GNSS 2006. Sep, 26-29. 2006. Fort Worth, TX.

[8] Tian, Jin; Ye, Wang; Lin, Shi; Hua, Zhang; , "SDR GNSS Receiver Design over Stand-Alone Generic TI DSP Platform," Spread Spectrum Techniques and Applications, 2008. ISSSTA '08. IEEE 10th International Symposium on , vol., no., pp.37-41, 25-28 Aug. 2008

[9] T.E. Humphreys, J.A. Bhatti, T. Pany, B.M. Ledvina, and B.W. O’Hanlon. “Exploiting Multicore Technology in Software-Defined GNSS Receivers”. In Proc of ION GNSS 2009. Sep, 22-25. 2009. Savannah, GA.

[10] H. Hurskainen, J. Raasakka, and J. Nurmi. ''Specification of GNSS Application for Multiprocessor Platform''. in Proceedings of International Symposium on System-on-Chip (SOC) 2008, Nov 4-6 2008, Tampere, Finland. Pages: 128-133.

[11] H. Hurskainen, J. Raasakka, T. Ahonen, and J. Nurmi, “Multicore Software-Defined Radio Architecture for GNSS Receiver Signal Processing, ” EURASIP Journal on Embedded Systems, vol. 2009, Article ID 543720, 10 pages, 2009. doi:10.1155/2009/543720

[12] J. Raasakka, H. Hurskainen, T. Paakki, and J. Nurmi. ''Modeling Multi-Core Software GNSS Receiver with Real Time SW Receiver'' in Proc. of ION GNSS 2009. Sep, 22-25. 2009. Savannah, GA.

[13] Recore Systems. (2011). Xentium Technology [Online]. Available: http://www.recoresystems.com/technology/xentium-technology/

[14] Timon D. ter Braak, Hermen A. Toersche, Kim Sunesen, Paul M. Heysters, and Gerard J.M. Smit. “A dynamic reconfigurable many-core platform for streaming applications”, In proceedings of 14th Design, Automation & Test in Europe (DATE) 2011.

[15] K. Borre, D.M. Akos, N. Bertelsen, P. Rinder, S.H. Jensen, “A Software-defined GPS and Galileo Receiver – A Single-Frequency Approach”, Birkhäuser Boston, 2007. ISBN 0-8176-4390-7.

46