IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 63, NO. 8, AUGUST 2014
2001
A Development and Testing Instrumentation for GPS Software Defined Radio With Fast FPGA Prototyping Support Arpine Soghoyan, Adnan Suleiman, and David Akopian, Senior Member, IEEE
Abstract— The modernization of global positioning systems (GPS) boosts the development of civil and military applications as accuracy and coverage of receivers continually improve. Recently, software defined radio (SDR) approach for GPS receivers (GPSSDR) gained attention because of its flexibility for multimode operations in different environments. The SDR receiver developers continually advance algorithmic and/or hardware accelerator solutions. However, they need fast prototyping and testing instrumentation to refine and evaluate high performance multimode receivers. This paper presents a feasibility study of fast prototyping of the GPS receiver accelerators using graphical user interface environments. It also describes a testbed with integrated RF front-ends, GPS simulator, receiver, and assistance support. Particularly, a novel host-target codesign solution is demonstrated using a field programmable gate array (FPGA) peripheral and LabVIEW FPGA tool for a case study of a GPS acquisition module. Distributing tasks between the FPGA target and the personal computer host achieves a high performance solution. The fast prototyped solution is compared with a conventional FPGA and state-of-the-art implementations. Index Terms— Fast prototyping, field programmable gate array (FPGA), global navigation satellite systems (GNSS), global positioning systems (GPS), software defined radio (SDR), testing.
I. I NTRODUCTION
T
HE U.S. global positioning system (GPS) is one of the existing global navigation satellite systems (GNSS) that provides the end user with global position, velocity, and time solutions [1], [2]. The GPS receivers are used in various instrumentation and measurement systems from phasor measurements in power systems [3], [4] to ionospheric calibration and time transfer [5]. The GPS/GNSS receivers continually evolve supported by new algorithms [1], [6], [7], computing platforms [8], [9], and testing methodologies [10]. They are also integrated with other navigation systems for robust operation during GPS outages [11]–[13].
Manuscript received July 29, 2013; revised December 16, 2013; accepted December 20, 2013. Date of publication February 27, 2014; date of current version July 8, 2014. This work was supported in part by NSF under Grant 0942852 and Grant 0932339, and in part by the UTSA-NEEC Center. The Associate Editor coordinating the review process was Dr. Jesus Urena. A. Soghoyan and D. Akopian are with the University of Texas at San Antonio, San Antonio, TX 78249 USA (e-mail: arpisoghoyan@ gmail.com;
[email protected]). A. Suleiman is with Cirrus Logic Inc, Austin, TX 78710 USA (e-mail:
[email protected]). Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identifier 10.1109/TIM.2014.2304352
Major challenges for advanced receiver development are system development complexity, long development cycles, interfaces for RF front-ends and hardware accelerators for real-time operation, and availability of end-to-end development and testing platforms. Continuous modernization of the GNSS systems, including transmission of new signals also challenges the research community to manage increased system complexities and deeper understanding of various signal distortion phenomena. State-of-the-art receivers should also be flexible to perform multimode tasks for various environments. To facilitate the development of these receivers, researchers need reference systems, associated software development kits, development platforms, simulators, and evaluation testbeds. The software defined radio (SDR) framework [6], [8], [14]–[17] became popular for advanced receiver development and testing because the SDR receiver components are implemented in software and can be reconfigured depending on operational tasks; they are convenient for fast prototyping and academic research. Conventional state-of-the-art GPS receivers typically rely on application specific integrated circuit (ASIC) technology for implementing massive numbers of correlators for improved sensitivity. On the contrary, the SDR solutions use fast correlator algorithms and general purpose computing peripherals, such as field programmable gate arrays (FPGAs) and/or digital signal processors (DSPs), to accelerate algorithm execution (Fig. 1). The ASIC-based implementations are fast but require longer development cycles and constrained hardware–software interfaces. In that sense, the FPGAs/DSPs are less expensive and compromise solutions with welldeveloped support and host-target interfaces. Many open source and commercial SDR receiver solutions are reported [7], [14], [15], [18], [19], including the FPGAbased GPS receivers in [9] and [20] and reference designs mentioned in the following sections. Development platforms range from proprietary solutions providing application program interface access to incorporate third party algorithms [6] to MATLAB-based reference receivers [15], [18], and C/C++ based open source solutions [7], [14], [15], [19]. This paper presents a feasibility study of using graphical user interface environments for fast prototyping of the GPS-SDR receiver accelerators. Particularly, competitive hosttarget FPGA accelerator (software–hardware) solutions are obtained using LabVIEW FPGA tools from National Instruments (NI) and related Xilinx tools [21] and compared with conventional implementation approaches. In addition,
0018-9456 © 2014 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
2002
IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 63, NO. 8, AUGUST 2014
Fig. 1. UTSAs development and testing platform for GPS SDR, including RF front-end, simulator, receiver, A-GPS support, DSP, and FPGA peripherals. Highlighted modules on hardware-software codesign of acquisition unit using FPGA are the main focus of this paper.
the following features of LabVIEW facilitate the GPS receiver development: 1) signal visualization; 2) fast computing options; 3) RF front-end and hardware accelerator interfaces; 4) GPS signal simulation; and 5) assisted GPS (A-GPS) support [22], [23]. A modular advanced GPS acquisition algorithm is used as a case study. This paper is organized as follows. Section II presents the development and testing setup. The case study acquisition module is described in Section III. Section IV presents the fast prototyping of the acquisition system using LabVIEW FPGA. A standalone FPGA implementation for comparison and host connectivity demonstration purposes is described in Section V. Performance figures of LabVIEW-based host-FPGA target implementation are discussed in Section VI. Section VII discusses alignment of proposed solutions with state-ofthe-art implementations. Finally, conclusions are stated in Section VIII. II. D EVELOPMENT AND T ESTING S ETUP The system architecture of the GPS LabVIEW-based development testbed is shown in Fig. 1, which is an enhanced version of the system reported in [24]. The transmitter’s RF front-end consists of an antenna and NI PXIe-5673 RF vector signal generator (VSG), which can be configured to generate various GNSS signals. The GPS signal is generated using a LabVIEW-based NI GPS simulation toolkit [21]. Current setup can be configured to simulate various channel distortions. The simulation toolkit along with the VSG enables concurrent generation of one to twelve satellite signals. Signal powers can be adjusted for each satellite based on testing specifications. The simulator also supports signals of a wide area augmentation system, trajectory scripts, on-the-fly parameters, and stored files for replicating
test signals. The simulator uses orbital data, i.e., ephemeris and almanac data file inputs. The almanac and ephemeris file types, content, and location are described in [25] and [26]. A dedicated A-GPS LabVIEW module is integrated with the transmitter and uses a simulator signal to generate assistance according to the guidelines of the secure user plane location (SUPL) [27] standard developed by open mobile alliance for wireless networks [28]. When a GPS receiver is integrated with wireless communication devices, wireless networks provide assistance data to aid the GPS receiver operation. Delivery of orbital parameters (ephemeris and almanac) and other assistance, such as coarse position and time reference, enhances the GPS receiver operation in weak signal conditions such as indoor areas [1], [23], [29], [30] as receivers are relieved from the task of demodulating navigation data from satellite signals. A detailed description of the assistance data delivery solution can be found in [28]. Thus, the testbed uses two channels to communicate with the receiver. The GPS signals are broadcasted by the signal generator-simulator, whereas A-GPS SUPL data are communicated using IP channels and wireless network links. In the current implementation, the SUPL server and GPS simulator are colocated. The receiver front-end consists of an antenna, a variable gain amplifier (variable gain up to 30 dB) [31], and a NI PXIe-5663RF vector signal analyzer. It is connected to a computer running a GPS-SDR receiver implemented using LabVIEW. Optional hardware DSP/FPGA peripherals are accessible through LabVIEW interfaces. Sampled data from the RF front-end are buffered for further processing in a snapshot mode [32]. The LabVIEW environment provides built-in libraries for development, analysis, and data visualization. It is convenient for the fast algorithm prototyping and testing, comparative
SOGHOYAN et al.: DEVELOPMENT AND TESTING INSTRUMENTATION FOR GPS SDR WITH FAST FPGA PROTOTYPING SUPPORT
2003
TABLE I A DVANCED D EVELOPMENT-T ESTING T OOLKIT TO FACILITATE R ESEARCH AND D ISSEMINATION [23]
studies, real-time performance evaluation, and dissemination. LabVIEW supports multithreading and multicore programming, which are useful for real-time applications. These advantages already have been used in other radio-communication systems [33], [34]. Algorithms can be implemented using LabVIEW library modules, mathscript nodes using MATLAB scripts for fast prototyping, and C/C++ language for fast processing. LabVIEW also has support for external hardware peripherals to accelerate research and simulation of the SDR development. As already mentioned, the hardware accelerators, such as DSPs and FPGAs, can be integrated with LabVIEW [35]. There are two different ways to integrate FPGAs with LabVIEW. One is using a software module called a LabVIEW FPGA module that translates LabVIEW data-flow schematic into FPGA hardware. Another option is to use IP Integration Node to integrate third party Verilog or Very High Speed Integrated Circuit Hardware Description Language (VHDL) designs. LabVIEW FPGA module with its graphical programming language and predesigned library tools allows for fast prototyping of FPGA solutions. The NI PXIe Flex reconfigurable input/output (FlexRIO) FPGA target module with integrated Xilinx Virtex-5 hosts the hardware implementation [35], [36]. It is installed on a NI PXIe 1075 [37] chassis. The peripheral connects to the LabVIEW environment through a NI PXI-ExpressCard8360 connector with a throughput of up to 110 MB/s [38]. Debugging tools built into the environment include rapid edit-time error reporting, ability to view code execution, and an ability to control the execution (single-stepping). Another advantage over using traditional hardware description languages (HDLs) is the ability to develop algorithms and rapidly perform direct functional verification on a personal computer (PC) in a simulation/emulation mode. Table I summarizes strength of the LabVIEW environment for implementing software GPS receivers and exploiting existing host-target interfaces for the FPGA accelerations. III. GPS ACQUISITION M ODULE The case study in this paper is applied to the acquisition of a conventional L1 civilian GPS signal, a direct sequence spread spectrum signal consisting of a multiplication of a sinusoidal carrier at 1.57542 GHz, a binary phase shift keying
(BPSK) navigation signal at 50 Hz, and a BPSK modulated spreading pseudorandom code signal (PRN) at 1.023 Mchips/s. The spreading sequence is called the coarse acquisition (C/A) code [1]. The ultimate goal of a GPS receiver is to provide position, velocity, and time information. For that, receivers measure range, range-rate, and demodulate navigation data. The receiver measurements are extracted by synchronizing locally generated replicas of the code with the received signal. This synchronization is performed in frequency by estimating Doppler modulation, and in time, by aligning the signal and replica and estimating their relative shift called code-phase. The synchronization is typically performed in two phases: acquisition (coarse) and tracking (fine). These two phases constitute a baseband processing stage. After synchronization, navigation data are simply obtained through sinusoidal carrier and PRN code wipe-off. Navigation data contain timestamps, which along with code-phases are used to estimate ranges to satellites. Navigation data also contain orbital parameters, ephemeris, and almanac, all of which are used to find satellite positions provided time. Orbital parameters alternatively can be received using assistance from wireless networks as described in Section II and illustrated in Fig. 1. Satellite positions serve as beacon locations for trilateration using ranges. The first stage of baseband signal processing is acquisition of the GPS satellites. Conventional receivers achieve acquisition by searching over a predicted time-frequency uncertainty zone. It is a 2-D search process in which the receiver replicates candidate code and residual carrier modulations attempting to match those of the received signal. Multiple possible signal replicas are generated and correlated with received signal to find a match and thus to identify input signal parameters. This assumes an elementwise multiplication of the received samples with the samples of each replica. Then, resulting products are added over the coherent integration length. Typically, a statistical test is applied to the correlation results to determine if a signal acquisition has been reached or not. If it has been, the acquisition is terminated and the receiver starts the tracking stage for that satellite; if not, the search continues and moves to the next code-phase/frequency option. There are many fast methods of accelerating acquisition. For example, a convolution theorem can be used to apply fast Fourier transform (FFT) for parallel fast code-phase search (PCS) algorithms [15].
2004
IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 63, NO. 8, AUGUST 2014
conjugated FFT-replicas to samples in each column of the first stage output matrix. Then, compute Inverse Fast Fourier Transform or Inverse FFTs (IFFTs) of each such column-vector. The result is a vector corresponding to one frequency bin, with each vector element representing a correlation corresponding to one codephase, and the whole vector includes N1 correlations for all code-phases. Repeat elementwise multiplications and IFFT stages for all columns, i.e., N2 frequency bins with resolution 1/N2 kHz (total 1-kHz range). Here, the process is similar to conventional FFT-based correlation. The difference is only in the long forward FFT, which is concurrently reused for several fine frequency bins. 4) Coarse frequency bin search: after completing each 1-kHz fine frequency bin search, the next 1-kHz range is processed by one cyclical shift of FFT-of-replica. For K shifts, the total number of frequency bins will be KN 2 for K -kHz total frequency range. 5) Stages 1–4 will conclude the coherent correlation stage for KN 2 frequency bins and N1 code-phase bins, with total number of bins equal to KN 1 N2 . Maximum correlations can be found from this array, or consecutive arrays can be further integrated noncoherently [39]. Fig. 2. Block correlator for acquisition, coherent integration length is N2 code periods (N1 N2 samples for N1 samples per code period) and correlation result plot.
Recently, proposed block correlators extend the PCS concept by combining it with coherent integrations over several code periods exploiting shared computations for reduced computational loads [39], [40]. The block correlators for acquisition efficiently perform concurrent joint search in three dimensions: 1) code-phase; 2) Doppler frequency; and 3) satellite number. For the case study in this paper, an extended PCS algorithm proposed in [39] is selected due to its modular structure, which can be easily explained and used for fast prototyping using the LabVIEW FPGA toolkit and Xilinx core IPs. Fig. 2 illustrates a block diagram of the algorithm. Let N1 denote the number of samples per code period, which is also the number of code phases. N2 is the number of coherently integrated code periods, i.e., correlation lengths are N1 N2 samples. The algorithm computes correlations for all code phases on a grid of frequencies with resolution 1/N2 kHz. Following are the steps of this algorithm. 1) Long FFT Stage: compute FFT of the signal for the whole coherent correlation length N1 N2 . This FFT is computed once and reused for further processing. Rearrange the output of the FFT unit into a matrix with columns of size N1 as shown in Fig. 2. This stage is common for all satellites and can be shared. 2) For each satellite, compute FFT of the replica sequence code at input sampling frequency for total length of N1 samples. These computations can be done offline, saved, and retrieved when processing given satellite signal. 3) Fine concurrent N2 frequency bins searching (for each 1-kHz range). Multiply elementwise samples of
The algorithm implements a massive correlator by combining code-phase and frequency searches and shares computations even for different satellites as forward FFT output is reused for all iterations. As indicated, kilohertz resolution frequency search steps are implemented in the frequency domain by cyclically shifting iterations of FFT-replicas. Sub-kilohertz frequency searches are computed concurrently using IFFTs of multiple vectors after FFT transformation. In our case studies, coherent integration lengths are 1, 2, and 4 ms. The FFTs of PRN code replicas for 24 satellite codes are stored in a 2-D array for faster access. The correlation results can be plotted using LabVIEW visualization tools. As the process is a 2-D search for each satellite over all frequency and code phase bins, the correlation match between incoming signal and the local replica exhibits a peak like the one shown in Fig. 2. The acquisition algorithm has been implemented in several modes: 1) using conventional C/C++ coding and C/C++ modules integrated in LabVIEW; 2) using native LabVIEW functional blocks as shown in Fig. 3; 3) as a standalone FPGA implementation connected to the LabVIEW receiver; and 4) as a host-target codesign where IFFT computations are delegated to the FPGA target. The LabVIEW implementation of Fig. 3 follows the acquisition steps described above and also includes benchmark time readings for performance evaluations in Section V. One can observe that most of the iterations for all satellites and frequency and code-phase bins are performed repeatedly computing the IFFTs. The IFFT operations, in fact, are the highest contributors to the correlator’s computational complexity. The proposed host-target fast prototyping codesign solution delegates IFFT computations to onboard FPGA targets, and the entire solution is designed without the use of traditional ASIC design flow. Detailed descriptions of FPGA solutions are described next.
SOGHOYAN et al.: DEVELOPMENT AND TESTING INSTRUMENTATION FOR GPS SDR WITH FAST FPGA PROTOTYPING SUPPORT
Fig. 3.
2005
Advanced acquisition algorithm (Fig. 2) implementation using LabVIEW function blocks and its benchmarking.
IV. NI F LEX RIO FPGA M ODULE AS A H ARDWARE ACCELERATOR In the past, the FPGA implementation assumed knowledge and many intricacies of hardware programming. The popularity of high-level design tools, however, is changing the rules of FPGA programming; recently emerged tools convert graphical block diagrams or even C/C++ code into digital hardware circuitry. As the development testbed presented in this paper is based on the LabVIEW environment, in the following, fast FPGA prototyping tools provided in the LabVIEW FPGA module [35] are evaluated for FPGA hardware correlator design to accelerate the GPS-SDR acquisition stage. The tools can synthesize FPGA-based solutions from the LabVIEW graphical representation of algorithms. This block diagram realization approach into the FPGA is well suited for fast prototyping, as it is independent of prior knowledge of the HDL programming. Synthesis is the process of translating high-level programming languages into actual logic-level hardware descriptions. For any given piece of synthesizable code, there is a corresponding logic circuit that describes how logic gates should be wired together. The LabVIEW FPGA module generates all necessary logic for every block diagram function before sending a final schematic to the compiler. The LabVIEW FPGA design toolkit has the following features: 1) supports connection and interfaces to PCI/PXI boards; 2) includes FPGA IP blocks library for fast prototyping; 3) provides fast host-target communication using builtin I/O direct memory access (DMA) first-in-first-out (FIFO) buffers; 4) supports various clock rates of 40 MHz, 80 MHz, or faster. In addition, recent versions of the LabVIEW FPGA module introduced a new feature called the IP integration node, which embeds third-party HDLs into LabVIEW FPGA. The IP node is used like any other LabVIEW function block with its inputs and outputs. It also runs in both simulation and target execution modes.
LabVIEW FPGA module development starts once a FPGA project is created. The FPGA targets identified in the LabVIEW project explorer include FPGA programmable I/O nodes to acquire, process, transfer, and output signals using the FPGA. This can be done either using simulated I/O on a development computer or in real-time mode using various hardware targets. A list of LabVIEW FPGA supported hardware targets can be found in [35]. The target boards can be connected to computers through PCI, cPCI, or PXI/PXIe. Some of these boards have purely digital front-ends and others have specialized front-end circuitry, e.g., analog I/O channels, IF transceivers. Software components that are installed and used for the application development include: 1) the LabVIEW real-time module; 2) the LabVIEW FPGA module; and 3) the NI reconfigurable input/output (NI-RIO) driver, which are compatible with Xilinx compilation tools [35]. The target used in this project includes a Virtex-5 SX95T FPGA programmable board, 512-MB onboard DDR2 DRAM, and 16 DMA channels for high-speed data streaming [36]. The host is a PC with Intel(R) Core (2) Duo CPU E8300 processor, 2.83GHz (2CPUs), 2020-MB RAM, and Windows XP Professional OS. The LabVIEW 2011 SP1 version is used as a development environment along with GPS Simulation Toolkit 2 for the GPS signal generation. Performance evaluation of the system in the LabVIEW environment is done using available profiler tools [21] and benchmarking as described later in this paper. The following sections provide more details on various implementation aspects. A. LabVIEW FPGA Development Flow This section proceeds with implementation details. First, an FPGA project is created in the LabVIEW environment for the FlexRIO board as described in [41]. Once the FPGA target is specified, then LabVIEW displays compatible functions for math, signal generation and analysis, comparison logic, array and cluster manipulation, occurrences, analog and digital I/O, and timing. A combination of these functions can be used to design algorithmic logic and embed it onto the FPGA device. Math and control in FPGA are limited to fixed-point operations.
2006
Fig. 4.
IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 63, NO. 8, AUGUST 2014
Application development flow with FPGA compilation steps.
After creating a LabVIEW FPGA virtual instrument (VI), the code must be compiled. Similar to other FPGA development tools, compile time for an FPGA VI can range from minutes to several hours depending on the complexity of the code and specifications of the development system. To maximize development productivity, a bit-accurate emulation mode can be used so the logic of the design can be verified before initiating the compile process. When the FPGA device emulator is used as a target, then LabVIEW accesses I/O from the device and executes the VI logic on the development computer. In this mode, it is possible to use the same debugging tools available in LabVIEW for Windows. Once the LabVIEW FPGA code is compiled, a LabVIEW Host VI is created to integrate the hardware into the rest of the test and control system. Fig. 4 illustrates the development process for creating a FPGA application. The Host VI uses controls and indicators on the FPGA VI front panel to transfer data between the FlexRIO FPGA device and the host processing engine. B. LabVIEW FPGA IP Integration Node. Integration of a Standalone FPGA Acquisition Module Hardware modules that are developed using HDLs can be integrated into LabVIEW FPGA using the IP integration node function. To integrate, e.g., a Verilog code in general, FPGA VI is created and compiled according to the following steps [35], [42]. 1) Create Verilog project, e.g., in the Xilinx integrated software environment, then use the Xilinx Synthesis Technology tool to synthesize the project into NGC netlist. 2) Integrate NGC netlist inside the LabVIEW FPGA project using the IP integration node and configure the node. Connect it to the rest of the VI design. 3) Select project execution mode: FPGA target or simulation. 4) For FPGA target execution, compile the LabVIEW FPGA VI. During compilation, the Xilinx mapping tool configures logic fabric in the target FPGA according to the previously generated netlist. Then, the Xilinx placing and routing (PR) tool iterates PR of contiguous
mapped logic blocks to meet minimum timing and I/O constraints. After this, LabVIEW VI invokes the Xilinx tool to create binary configuration file saved as a bitfile. 5) Running on the Target: LabVIEW VI invokes the Xilinx tool to transmit bitfile to program a FPGA target located on the PXIe FlexRIO integrated board. Using the described approach, a standalone GPS signal acquisition module described in Section III (Fig. 2) is synthesized and integrated in LabVIEW FPGA VI for 1, 2, and 4 ms coherent integration lengths (Fig. 5). Fig. 5 shows target LabVIEW FPGA VI, where the standalone acquisition unit is shown as an IP node connected to DMA FIFOs for communicating with the host VI. Fig. 6 shows a block diagram of the implemented standalone solution. It includes FFT and a data buffer (RAM), and it is configurable for multiple FFT sizes. Following the steps of Section III (Fig. 2), long FFT computation follows by an ordered data placement into a matrix, which is saved in RAM. The general address generator controls the sequence of shifts (coarse frequency loop) and elementwise multiplications of columns of the saved FFT matrix with code replica FFTs. The results are then passed through the IFFT block to obtain an array of correlations and detect the correlation peak. Coherent integration lengths impact FFT and RAM (buffers) sizes. The performance of this design and summary of total hardware utilization is presented in Section V. For conformity of data comparison with other implementations, correlators were placed and routed using 160-MHz timing constraint. C. Host-Target Codesign Using LabVIEW FPGA and Xilinx Core Generator IP Libraries The HDLs provide powerful development environments but they often require an advanced level of programming expertise. For fast prototyping, high level programming tools are typically used. One example can be the Xilinx system generator for the DSP that performs system modeling and automatic code generation from Simulink [36], [42]–[44]. Similarly, Xilinx Coregen IP is a toolset of the most commonly used predesigned IP nodes for LabVIEW FPGA. The nodes functions include, e.g., basic arithmetic operations, accumulators, counters, memory elements, shift registers, filters, transforms, modulation, IP related to FIFOs, RAMs, and ROMs. The inputs and outputs of the IP node should be initialized according to [45]. Thus, the FPGA solutions can be designed using an integration of both predesigned library blocks and external modules. This section demonstrates a straightforward host-target codesign example of fast prototyping for the case study acquisition module. As it is explained in Section III, the significant computational load share is due to iterative IFFT operations. For this reason, the IFFT is computed on the FPGA target. Standard FFT/IFFT modules are available in both LabVIEW FPGA and Xilinx Coregen IP libraries. One module is used for both FFT and IFFT, and in the Xilinx module it is configured by properly setting the FWD_INV input. In host-target codesign, there are two VIs, one for host section and another for the target section. Fig. 7 shows the
SOGHOYAN et al.: DEVELOPMENT AND TESTING INSTRUMENTATION FOR GPS SDR WITH FAST FPGA PROTOTYPING SUPPORT
2007
Fig. 5. Standalone FPGA acquisition module implementation and integration with LabVIEW-based SDR using IP node in LabVIEW FPGA VI. DMA FIFOs connect FPGA module with the host. Tick counters are included for performance evaluations.
Fig. 6. Block diagram of the standalone FPGA acquisition module (Section III) using Xilinx IP Cores, which is integrated with host section as shown in Fig. 5.
section of the acquisition module, which is deployed on the host VI. Fig. 8 shows the target VI section, a single cycle timed loop block diagram. One can note READ / WRITE DMA FIFOs in both sections, these modules connect both sections. The IFFT IP node in Fig. 7 is from the Xilinx Codegen IP library. Fig. 7 highlights specific inputs/outputs (1–7) of this module, which are similar to those of the library IFFT module from LabVIEW FPGA (Fig. 9). Thus, both library units can be used. A selection and integration of a Xilinx Coregen IP library module on the example of IFFT can be described using the following steps. 1) In FPGA VI functions palette, select Xilinx Coregen IP → Digital Signal Processing → Transforms → Fast Fourier Transform. 2) Configure IP page is opened. a) Select Transform Length (e.g., 2048) and Target Clock frequency (e.g., 160 MHz). b) Define the inputs with their data formats (e.g., Integer 8 data type, Unscaled, Natural Order).
c) Additional selections such as Use 4-multiplier structure and Use XtremeDSP slices, and so forth. 3) Generate IP node. 4) Set IP node boolean input parameter FWD_INV to True for FFT or False for IFFT. 5) Connect to the rest of the VI. A more detailed description of the FFT node from the Xilinx CORE generator is given in [45]. The clock rate for the FPGA VI in a single cycle timed loop is 160 MHz. The host application is benchmarked or profiled using LabVIEW profiling tools [21] for performance evaluations. Similar FPGA library modules are available in LabVIEW FPGA, which provides the same graphical programming environment for the creation of FPGA VI as LabVIEW does for standard VIs. The FPGA modules can also run independently. It is possible to implement buffers and FIFOs on target FPGA to store data until the host computer can retrieve it. Another advantage of the FPGA module is parallel execution capability of independent module operations. For example, multipleindependent while loops on a LabVIEW block diagram may execute independently when implemented on FPGA. For performance evaluation, the block diagram in Fig. 8 includes the start and end tick counts that are taken to benchmark the FPGA VI, as the profiling tools are not available on the target. IFFT modules of both Coregen IP and LabVIEW FPGA are tested at 160-MHz device clock rate. V. P ERFORMANCE A NALYSIS The proposed designs achieve 160-MHz FPGA operation. Either profiling or benchmarking methods can be used for performance evaluations in LabVIEW. Profiling resolution is in microseconds, but one can only evaluate performances from the host side, including target operations and hostto-target communication. To evaluate the performance of the target operations only, a benchmarking concept is used. Fig. 3 illustrates the concept of code benchmarking for the acquisition module implemented using native LabVIEW
2008
IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 63, NO. 8, AUGUST 2014
Fig. 7. Host VI section of the host-target co-design of the acquisition module described in Section III. The DMA FIFOs connect to the IFFT module, which is implemented on FPGA target using library blocks. Target VI is in Fig. 8.
Fig. 8. Target VI section of the host-target co-design of the acquisition module described in Section III. The IFFT IP module is from Xilinx Codegen IP and can be replaced with LabVIEW FPGA IFFT function module of Fig. 9. The IFFT communicated with host VI using DMA FIFOs connect.
function blocks (software). The code is divided into three parts (so-called frames) using Flat Sequence structure in the LabVIEW block diagram. The first and the last frames contain timestamp generators (tick counters) with the code to be benchmarked in the center. The actual timing figures are obtained using the clock rate of the timing loop structure. The performance figures are obtained for the following implementations. 1) Software only: a) standalone C/C++; b) C/C++ integrated in LabVIEW with Call library function node; and c) implementation using native LabVIEW blocks. 2) Host-target co-design: a) standalone FPGA implementation integrated as IP node in LabVIEW FPGA, evaluated in LabVIEW; b) standalone FPGA implementation evaluated using Xilinx tools on Virtex-5 target; c) LabVIEW-based host-target implementation
Fig. 9. IFFT module from LabVIEW FPGA function library. This unit can replace IFFT IP node from Codegen IP in Fig. 8, with corresponding inputs and outputs shown on both figures.
computing IFFTs (from Coregen IP) on the target; and d) the same as c) but using IFFTs from LabVIEW FPGA function library. A. IFFT Implementation Performance As described in the previous section, two alternative hosttarget co-design implementations delegate IFFT computations
SOGHOYAN et al.: DEVELOPMENT AND TESTING INSTRUMENTATION FOR GPS SDR WITH FAST FPGA PROTOTYPING SUPPORT
TABLE II IFFT I MPLEMENTATION P ERFORMANCES
2009
TABLE III P ERFORMANCE OF A CQUISITION I MPLEMENTATION ON THE H OST
TABLE IV P ERFORMANCE OF THE H OST-TARGET A CQUISITION C ODESIGN
to the target and use IFFT FPGA modules either from Coregen IP or native LabVIEW FPGA libraries. From this perspective, it is informative to benchmark IFFT performances. Table II shows performance figures for IFFT computation on the target for these two modules along with native software FFT functions in LabVIEW and in MS Visual Studio. One can see that the implementation in the MS Visual Studio platform is slower than the LabVIEW software function due to inherent multithreading and multicore programming capabilities of the current LabVIEW environment. The FFT operation is faster on the FPGA targets, and performance figures show that Coregen IP node implementation is more optimized. B. Acquisition Algorithm Performance In all methods, FFT-based acquisition is used as described in Section III and Fig. 2. The system searches for 24 satellites, in ±10-kHz Doppler frequency range, receiver sampling rate of 2.048 MHz. As it is described in Section III, the frequency bin resolution is 1/N2 kHz, where N2 is the coherent integration length in code periods (millisecond). In our experiments, N2 is 1, 2, and 4. Forward long length FFT is computed only once on the host. Inverse FFTs are computed for all frequency bins and satellites. For this reason, IFFTs’ share of computation complexity prevails and justifies their computation on the FPGA target. The target modules are all implemented in fixedpoint arithmetic. The actual timing figures are obtained using the clock rate of the timing loop structure. The performance figures are obtained for the following implementations (Tables III and IV). 1) Software only: a) standalone C/C++; b) C/C++ integrated in LabVIEW with Call library function node; and c) implementation using native LabVIEW blocks. 2) Host-target co-design: a) standalone FPGA implementation integrated as IP node in LabVIEW FPGA, evaluated in LabVIEW; b) standalone FPGA implementation evaluated using Xilinx tools on Virtex-5 target; c) LabVIEW-based host-target implementation computing IFFTs (from Coregen IP) on the target; and d) the same as c) but using IFFTs from LabVIEW FPGA function library.
Table III shows that C/C++ implementation completes in 0.688 s for 4-ms signal duration. The same implementation can run in LabVIEW using dynamic library function integration with a similar performance. The implementation using native LabVIEW blocks is significantly faster (0.172 s) because of inherent LabVIEW optimizations exploiting multithreading and multicore operations. Table IV shows performance figures for host-FPGA-target codesign. When delegating the IFFT computing from the host to the FPGA target, the overall runtime of the acquisition algorithm is approximately twice as fast as the same algorithm implemented using LabVIEW native function blocks only, comparing numbers in Tables III and IV. The implementation using IFFT from the Xilinx CORE generator IP (second entry of Table IV) is two times faster than the one using IFFT from the LabVIEW FPGA library (first entry of Table IV). For comparison purposes, the third and fourth entries of Table IV show a standalone acquisition implementation on the FPGA without host-target separation of the acquisition unit. Their performance is the same and comparable with host-target codesign using Coregen IP (second entry of Table IV).
2010
IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 63, NO. 8, AUGUST 2014
TABLE V D ETAILED H ARDWARE C OST FOR A CQUISITION C ORRELATORS ON X ILINX V IRTEX -5
Thus, host-target co-designs may serve viable implementation alternatives. Table V summarizes FPGA resources for the standalone implementation for coherent correlation lengths of 1, 2, and 4 ms. The increase of correlation lengths increases FFT calculation and memory usage resources. VI. D ISCUSSION IN THE C ONTEXT OF S TATE - OF - THE -A RT Various GPS acquisition implementation modes with LabVIEW FPGA are demonstrated in previous sections. Particularly, by simply delegating IFFT computations to the FPGA target, one can achieve the performance of standalone FPGA solutions. Proposed LabVIEW FPGA-based host-target codesign solutions are not compared with standalone solutions in terms of hardware resources, as only IFFT modules are implemented on the target using standard library functions, and any other FFT-based implementation should include similar modules. Thus, the focus is on computation time. At the same time, use of hardware resources is summarized for the standalone solution in Table V. When comparing to other reported FPGA GPS acquisition solutions, one should note that the implemented algorithm is an enhanced version of commonly used PCS approach, which integrates PCS, coherent integrations over several code periods, and search over frequency bins in a modular and computationally efficient solution [39]. The overall conclusion is that presented acquisition modules, standalone and hosttarget co-designs provide competitive performance figures using fast-prototyping graphical programming environments. Fast prototyping using graphical programming environments. The proposed solutions demonstrate the feasibility of LabVIEW FPGA SDR development for GPS as it was earlier shown for Simulink [46] in [44], [47], and [48]. Numeric performance details for comparisons were not provided in [47]. Simulink-only implementation was also shown in [44],
taking tens of second for the simulation. Implementations in [44] and [47] addressed implementation feasibility in Simulink rather than performance studies. Another FPGA solution using the Xilinx system generator for the DSP called from Simulink is demonstrated in [48]. We implemented a standalone FFT-based PCS algorithm for 1-ms correlator integration lengths on Xilinx Virtex-II Pro FPGA. The reported design achieved a clock speed of 100 MHz, and execution time is 0.63 s for 21 frequency bins and 16.3676-MHz sampling rate. A similar Simulink-based standalone FPGA solution for Virtex4SX35 is reported in [49] mentioning only computation time of 1 ms for 1.023-MHz sampled signals for a single satellite. We do not indicate if this number is for all Doppler bins. Assuming the all Doppler bins search scenario, 24 satellites will be processed in at least 24 ms. Implementations reported in this paper significantly outperform mentioned solutions achieving 160-MHz operation and faster execution times as shown in Table IV. Conventional FPGA implementations are also reported in [50]–[52]. [50] operates at frequencies up to 56.14 MHz with computing times more than 1ms per frequency bin for each satellite on Virtex II Pro. It results in at least 0.5 s to acquire 24 satellites for a 1.024-MHz sampling rate and more than one second for higher rates. A conventional PCS design for Altera Stratix III FPGA was reported in [52]. For a sampling frequency of 2.048 MHz, one satellite is processed in ∼1 s for 1-ms correlation length, which is significantly slower than solutions in this paper. Maximum achieved clock frequencies are not reported. High performance implementation is presented in [51] for Virtex II Pro FPGA. Here, 4096 samples are fed to an FFT-based PCS module, and the results are integrated for 10-ms coherent correlation lengths. Maximum achieved clock rate is 155 MHz. The settings of this implementation are quite different from the designs of this paper and are not compared.
SOGHOYAN et al.: DEVELOPMENT AND TESTING INSTRUMENTATION FOR GPS SDR WITH FAST FPGA PROTOTYPING SUPPORT
Overall, the achieved performance of LabVIEW FPGA hosttarget codesigns is competitive with reported approaches. The proposed standalone solution is the fastest achieving ∼5-ms acquisition computing time for 1-ms coherent integrations. In [50], the number of block RAMs is 17 for 2048 size IFFT. In Table V, the same number is ∼30% less. Furthermore, the block RAM comparison for different size FFTs is almost identical to the FFT-based correlator implementation in [50]. The PCS algorithms on both low-cost Altera EP3C120 and high-end Altera EP3SE260 FPGA targets with 98.304 MHz (EP3C120) and 196.608 MHz (EP3SE260) clock rates, respectively, were implemented in [52]. The hardware cost analysis in [52] shows that limitations on the FFT implementations are either from the memory blocks or DSP resources. In our proposed implementation, we also notice that the FFTs consume most of the resources (in terms of memory). One can note that in case A-GPS assistance data are available, then the number of searched satellites can be reduced by determining visible satellites from the assistance orbital data and time reference. Other accelerations, such as reducing the number of code-phase search bins, are also possible, as described in [53] for the acquisition algorithm presented in Section III. These scenarios are not considered in this paper. VII. F UTURE W ORK Future extensions of this paper will be based on more compact USRP RF front-ends [21], exploit embedded USRP FPGA modules, and will explore integrations of inertial navigation systems with software receivers. The FFT fixed-point accuracy limitations for input data dynamic range for the used acquisition algorithm will also be addressed in another paper. VIII. C ONCLUSION This paper demonstrated feasibility of the LabVIEW FPGA graphical user interface environment for fast prototyping host-FPGA-target solutions to accelerate the GPS signal acquisition. This paper also describes the first GPS receiver development and testing platform in LabVIEW environment for integrated GPS signal simulation, testing and studies of algorithms, performance analysis, A-GPS, and accelerator (FPGA and DSP) peripheral support. It also demonstrated that LabVIEW-based solutions are competitive alternatives for the GPS-SDR implementations and can facilitate receiver development. An extended PCS acquisition solution reported in [39] is selected for comparative analysis. High performances are achieved using both host-target co-designs and standalone solutions. Particularly, accelerations are achieved by delegating massive IFFT computations to the FPGA peripheral without using HDL. This fast prototyping approach achieves performance of an HDL-based standalone solution. The algorithm is implemented and tested on FlexRIO FPGA with Virtex-5 module using two alternative module libraries from LabVIEW FPGA and Xilinx CORE Generator IP Node tools. Operating frequencies of 160 MHz are easily achieved. A comparative discussion in the context of other implementations is also provided.
2011
ACKNOWLEDGMENT The authors would like to thank anonymous reviewers for valuable comments. This work was partly supported by NSF grants 0942852, 0932339 and UTSA-NEEC Center. The authors would like to thank National Instruments for providing an FPGA module for this research. R EFERENCES [1] P. Misra and P. Enge, Global Positioning System, Signals, Measurements, and Performance. Lincoln, MA, USA: Ganga-Jamuna Press, 2001. [2] E. D. Kaplan, Understanding GPS: Principles and Applications. Boston, MA, USA: Artech House, 1996. [3] A. Carta, N. Locci, C. Muscas, and S. Sulis, “A flexible GPS-based system for synchronized phasor measurement in electric distribution networks,” IEEE Trans. Instrum. Meas., vol. 57, no. 11, pp. 2450–2456, Nov. 2008. [4] D. M. Laverty, R. J. Best, P. Brogan, I. Al Khatib, L. Vanfretti, and D. J. Morrow, “The OpenPMU platform for open-source phasor measurements,” IEEE Trans. Instrum. Meas., vol. 62, no. 4, pp. 701–709, Apr. 2013. [5] C. B. Lee, D. D. Lee, N. S. Chung, I. S. Chang, E. Kawai, and F. Takahashi, “Development of a GPS codeless receiver for ionospheric calibration and time transfer,” IEEE Trans. Instrum. Meas., vol. 42, no. 2, pp. 494–497, Apr. 1993. [6] G. Heinrichs, M. Restle, C. Dreischer, and T. Pany, “NavX NSR— A Novel Galileo/GPS Navigation software receiver,” in Proc. ION GNSS Int. Tech. Meeting Satellite Division, Sep. 2007, pp. 1329–1334. [7] (2013, July). Open Source GPS Software Radio. Documentation and Source Code [Online]. Available: http://www.ctae.org/ sdr/doc/html/index.html [8] D. Akos, “The role of global navigation satellite system (GNSS) software radios in embedded systems,” GPS Solutions, vol. 7, no. 1, pp. 1–4, 2003. [9] A. G. Quinchia and C. Ferrer, “A low-cost GPS&INS integrated system based on a FPGA platform,” in Proc. Int. Conf. Localization GNSS (ICL-GNSS), Tampere, Finland, Jun. 2011, pp. 152–157. [10] D. N. Aloi, M. K. Alsliety, and D. M. Akos, “A methodology for the evaluation of a GPS receiver performance in telematics applications,” IEEE Trans. Instrum. Meas., vol. 56, no. 1, pp. 11–24, Feb. 2007. [11] D. A. Grejner-Brzezinska, C. K. Toth, H. Sun, X. Wang, and C. Rizos, “A robust solution to high-accuracy geolocation: Quadruple integration of GPS, IMU, pseudolite, and terrestrial laser scanning,” IEEE Trans. Instrum. Meas., vol. 60, no. 11, pp. 3694–3708, Nov. 2011. [12] C. Boucher and J.-C. Noyer, “A hybrid particle approach for GNSS applications with partial GPS outages,” IEEE Trans. Instrum. Meas., vol. 59, no. 3, pp. 498–505, Mar. 2010. [13] R. Jirawimut, P. Ptasinski, V. Garaj, F. Cecelja, and W. Balachandran, “A method for dead reckoning parameter correction in pedestrian navigation system,” IEEE Trans. Instrum. Meas., vol. 52, no. 1, pp. 209–215, Feb. 2003. [14] D. M. Akos, P. Normark, A. Hansson, A. Rosenlind, C. Stahlberg, and F. Svensson, “Global positioning system software receiver (gpSrx) implementation in low cost/power programmable processors,” in Proc. ION GPS Conf., Salt Lake City, UT, USA, Sep. 2001, pp. 2851–2858. [15] K. Borre, D. M. Akos, N. Bertelsen, P. Rinder, and S. H. Jensen, “A software-defined GPS and Galileo receiver,” in A Single-Frequency Approach. Boston, MA, USA: Birkhauser, 2006. [16] J. Meier, R. Kelley, B. M. Isom, M. Yeary, and R. D. Palmer, “Leveraging software-defined radio techniques in multichannel digital weather radar receiver design,” IEEE Trans. Instrum. Meas., vol. 61, no. 6, pp. 1571–1582, Jun. 2012. [17] L. Catarinucci, D. De Donno, R. Colella, F. Ricciato, and L. Tarricone, “A cost-effective SDR platform for performance characterization of RFID tags,” IEEE Trans. Instrum. Meas., vol. 61, no. 4, pp. 903–911, Apr. 2012. [18] Software and Documentation, Mathworks, Natick, MA, USA, Nov. 2012. [19] GPS Receivers and SDKs, Fastrax Ltd., Long Beach, CA, USA, Nov. 2012. [20] G. Kappen and T. G. Noll, “Application specific instruction processor based implementation of a GNSS receiver on an FPGA,” in Proc. Design, Autom. Test Eur., vol. 2. Munich, German, Mar. 2006, p. 6.
2012
IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 63, NO. 8, AUGUST 2014
[21] RF Signal Analyzers and Generators, National Instruments—LabVIEW, GPS Simulator, Bangalore, India, Nov. 2012. [22] D. Akopian, A. Soghoyan, S. Chayapathi, and G. V. S. Raju, “A flexible LabVIEW-based GNSS receiver development and testing platform,” in Proc. ION/ITM Conf., San Diego, CA, USA, Jan. 2011, pp. 1270–1280. [23] Y. Zhao, “Standardization of mobile phone positioning for 3G systems,” IEEE Commun. Mag., vol. 40, no. 7, pp. 109–116, Jul. 2002. [24] A. Soghoyan, G. Huang, J. Narisetty, and D. Akopian, “A LabVIEWbased assisted GPS receiver development, simulation and testing platform,” in Proc. 24th Int. Tech. Meeting Satellite Division Inst. Navigat., Oregon Convention Center, Portland, Sep. 2011, pp. 1982–1997. [25] The Navigation Center of Excellence, GPS, Beijing, China, Nov. 2012. [26] Ephemeris Information, NASA Goddard Space Flight Center, Greenbelt, MD, USA, Nov. 2012. [27] UserPlane Location Protocol v1.0, OMA-TS-SUPL_MO-V1_020070615-A, Open Mobile Alliance. San Diego, CA, USA, Nov. 2012. [28] J. Narisetty, A. Soghoyan, M. Sundaramurthy, and D. Akopian, “SUPL support for mobile devices,” Proc. SPIE, vol. 830409, pp. 1–12, Feb. 2012. [29] N. Agarwal, J. Basch, P. Beckmann, P. Bharti, S. Bloebaum, and S. Casadei, “Algorithms for GPS operation indoors and downtown,” GPS Solutions, vol. 6, no. 3, pp. 149–160, 2002. [30] Public Safety and Homeland Security Bereau, FCC, Columbia, MD, USA, Nov. 2012. [31] Standard Line Amplifiers. VGLCDLA30RPDC Product and Datasheet, GPS Networking, Beijing, China, Nov. 2012. [32] Z. Yao, M. Lu, and Z. Feng, “Spreading code phase measurement technique for snapshot GNSS receiver,” IEEE Trans. Consum. Electron., vol. 56, no. 3, pp. 1275–1282, Aug. 2010. [33] Developing an OFDM Transmitter and Receiver System Using LabWindows/CVI and PXI, National Instruments, Austin, TX, USA, Nov. 2012. [34] Prototyping Algorithms for Next-Generation Radio Astronomy Receivers Using PXI-Based Instruments and High-Speed Streaming, National Instruments, Austin, TX, USA, Nov. 2012. [35] LabVIEW FPGA Module. Product and Specifications, National Instruments, Austin, TX, USA, Nov. 2012. [36] NI PXIe-7966R—NI FlexRIO FPGA Module for PXI Express, National Instruments, Austin, TX, USA, Nov. 2012. [37] NI PXIe-1075 18-Slot 3U PXI Express Chassis, National Instruments, Austin, TX, USA, Nov. 2012. [38] NI PXI-ExpressCard8360 Connector, National Instruments, Austin, TX, USA, Nov. 2012. [39] D. Akopian, “Fast FFT based GPS satellite acquisition methods,” Proc. IEE, vol. 152, no. 4, pp. 277–286, Aug. 2005. [40] M. L. Psiaki, “Block acquisition of weak GPS signals in a software receiver,” in Proc. ION GPS Conf., Salt Lake City, UT, USA, Sep. 2001, pp. 2838–2850. [41] Adding FPGA Targets to a LabVIEW Project (FPGA Module). National Instruments, Austin, TX, USA, Nov. 2012. [42] System Generator for DSP-the Leading-Edge Modeling and Implementation Tool for High Performance DSP Systems, San Jose, CA, USA, Xilinx, Oct. 2013. [43] Homepage, Products and Solutions, Celoxica, New York, NY, USA, Oct. 2013. [44] G. Hamza, A. Zekry, and I. Motawie, “Implementation of a complete GPS receiver using simulink,” IEEE Circuits Syst. Mag., vol. 9, no. 4, pp. 43–51, Sep. 2009. [45] LogiCORE IP Fast Fourier Transform v7.1. Documentation, Xilinx Product Support, San Jose, CA, USA, Oct. 2013. [46] (2013 Jul.). Model, Implement, and Verify FPGA Designs, Documentation [Online]. Available: http://www.mathworks.com/fpga-design/ [47] D. Benson, “The design and implementation of a GPS receiver channel,” in Proc. DSP Mag., Oct. 2005, pp. 50–53. [48] S. Ramakrishnan, G. X. Gao, D. De Lorenzo, T. Walter, P. Enge, and P. D. Akos, “Design and analysis of reconfigurable embedded GNSS receivers using model-based design tools,” in Proc. 21st Int. Tech. Meeting Satellite Division Inst. Navigat., Savannah, GA, USA, Sep. 2008, pp. 2293–2303.
[49] K. S. Raju, Y. Pratap, V. Patel, S. M. M. Naidu, A. Patvardhan, and P. B. Prasad, “Acquisition digital baseband module for multichannel GPS receiver,” in Proc. ICICEE, Aug. 2012, pp. 9–13. [50] E. Romero-Aguirre, R. Parra-Michel, O. Longoria-Gandara, and M. Aguirre-Hernandez, “A hardware-efficient frequency domain correlator architecture for acquisition stage in GPS,” in Proc. Int. Conf. Reconfigurable Comput. FPGAs, Dec. 2010, pp. 412–417. [51] C. Sajabi, C.-I. H. Chen, D. M. Lin, and J. B. Y. Tsui, “FPGA frequency domain based GPS coarse acquisition processor using FFT,” in Proc. IEEE IMTC, Apr. 2006, pp. 2353–2358. [52] J. Leclère, C. Botteron, and P. Farine, “Comparison framework of FPGAbased GNSS signals acquisition architectures,” IEEE Trans. Aerosp. Electron. Syst., vol. 49, no. 3, pp. 1497–1518, Jul. 2013. [53] P. Sagiraju, G. V. S. Raju, and D. Akopian, “Fast acquisition implementation for high sensitivity global positioning system receivers based on joint and reduced space search,” IEE Proc. Radar, Sonar, Navigat., vol. 2, no. 5, pp. 376–387, Oct. 2008.
Arpine Soghoyan received the B.Sc. and M.Sc. degrees in radiophysics and electronics from Yerevan State University, Yerevan, Armenia, and the M.Sc. degree in computer and information science from the American University of Armenia, Yerevan. She is currently pursuing the Ph.D. degree in electrical engineering from the University of Texas at San Antonio, San Antonio, TX, USA. Her current research interests include software defined radio, navigation, and global positioning system receivers.
Adnan Suleiman received the B.S. degree in electrical engineering from Ohio State University, Columbus, OH, USA, in 2000, and the M.S. degree in electrical engineering from the University of Texas at San Antonio, San Antonio, TX, USA, in 2007, where he is currently pursuing the Ph.D. degree in electrical engineering. He was with Motorola, Schaumburg, IL, USA, from 2000 to 2006, as a Product Engineer, where he was involved in nonvolatile memory development. He joined Cirrus Logic, Austin, TX, USA, as a Senior Mixed-Signal Product and Test Engineer. Since 2009, he has been a Microchip Digital Design Engineer.
David Akopian (M’02–SM’03) received the M.Sc. degree in radio electronics from the Moscow Institute of Physics and Technology, Moscow, Russia, and the Ph.D. degree in electrical engineering from the Tampere University of Technology (TUT), Tampere, Finland, in 1987 and 1997, respectively. He is an Associate Professor with the University of Texas at San Antonio (UTSA), San Antonio, TX, USA. In 2003, he joined UTSA, where he founded the Software Communication and Navigation Systems Laboratory. From 1999 to 2003, he was a Senior Engineer and Specialist with Nokia Corporation, Espoo, Finland. Prior to joining Nokia in 1999, he was a member of Teaching and Research Staff, TUT. His current research interests include digital signal processing algorithms for communication and navigation receivers, positioning methods, and mobile applications.
