[IEEE 2013 IEEE Digital Signal Processing and Signal Processing Education Meeting (DSP/SPE) - Napa, CA, USA (2013.08.11-2013.08.14)] 2013 IEEE Digital Signal Processing and Signal Processing Education Meeting (DSP/SPE) - A real-time WARP-based data capture and playback test bed for DSP applications

A REAL-TIME WARP-BASED DATA CAPTURE AND PLAYBACK TEST BED FOR DSP APPLICATIONS Jeremy L. Hershberger 1 , Dr. Elizabeth A. Thompson 2 , Dr. Timothy S. Loos 3 1 Master’s Student, Dept. of Engineering Indiana-Purdue University Fort Wayne Fort Wayne, IN, USA 2 Associate Professor of Electrical Engineering, Dept. of Engineering Indiana-Purdue University Fort Wayne Fort Wayne, IN, USA 3 Engineering Fellow, Raytheon Company (retired) Fort Wayne, IN, USA ABSTRACT A common approach to debugging real-time DSP algorithms for FPGAs is to process a known data set in simulation. However, when large data sets are necessary or desired, simulations can take a significant amount of time. The goal of the architecture presented in this paper is to allow these algorithms to be easily debugged utilizing the Wireless Open-Access Research Platform (WARP). The WARP can be a valuable tool as its 2GB DDR2 memory module is capable of storing a large number of data samples for processing by its FPGA. Data can be obtained in real- time from an RF front end for processing, or loaded into the platform via an Ethernet connection. The WARP can also be used as a waveform capture and export tool, providing data for future processing runs or simulation. In this paper, the architecture’s capabilities for signal capture and storage are demonstrated through the capture of a GPS signal from a RF front end and subsequent export of the digitized signal to Matlab for post-processing. Index Terms— WARP, GPS, playback, capture 1. INTRODUCTION The Wireless Open-Access Research Platform (WARP) has been used extensively for development of software-defined radio networks [1] [2]. However, more than just a radio network development tool, the WARP is being utilized for other signal processing activities like spectrum sensing and receive signal strength indication [3] [4]. This has helped to make the WARP a common algorithm research tool. Among the many signal processing applications, real-time DSP algorithms can be especially challenging to develop. These algorithms can be simulated extensively before deployment, but the simulations can be very time consuming if large simulation times in addition to high sampling rates are needed. Implementing a design on hardware decreases the time required to process a large amount of data, but obtaining and utilizing a large data set becomes problematic, especially if the signal conditions are difficult to re-create in the real world. The architecture presented in this paper is designed to turn the WARP into a flexible test bed for DSP applications. Data can be collected via the RF front end in real-time for storage in the platform’s 2GB DDR2 memory module. This data can either be processed by the FPGA or exported to Matlab via an Ethernet connection. This allows real-world signals to be captured and repeatedly processed. Alternatively, simulated or pre-captured waveform data can be loaded onto the WARP for processing by the FPGA. 2. THE WARP The Wireless-Open Access Research Platform (WARP) is a software-defined radio platform originally developed at Rice University for the purpose of prototyping advanced radio networks [5]. There are several revisions of the WARP FPGA board, but only version 2 and 3 have an available DDR2 RAM module [5]. At the time of this work, the WARP FPGA Board version 3 was unavailable, so the architecture described here applies to the WARP FPGA Board version 2 which will be referred to, hereafter, as the WARP. The specific hardware elements utilized in this architecture are presented here, but a more complete description of the WARP can be found in [1] [5] [2]. 2.1. FPGA/Processor Architecture The WARP features a Xilinx Virtex 4 FPGA which contains a PowerPC general purpose processor. The Processor Local Bus (PLB) connects the processor to FPGA resources. In the PLB, when the processor executes a read or write instruction to a specific memory-mapped address, data is transferred over the bus between FPGA elements and the processor [6]. This allows reads/writes to custom logic and Xilinx pre-built cores which can create functionality like UART communication and digital clock generation in the FPGA. 48978-1-4799-1616-0/13/$31.00 ©2013 IEEE DSPSPE 2013 2.2. Analog to Digital Interface The platform has 4 separate daughercard slots. Each of these slots is capable of holding 1 of 4 different types of daughtercards. The only daughtercard used in this architecture is the “Analog Board”. This daughtercard serves as a baseband ADC/DAC interface to the WARP. The DACs are unused in this implementation. The inputs of the 2-channel, 14-bit, 65MS/s ADC are driven differentially by a specialized buffer amplifier to preserve noise figure. The inputs to the board are restricted to 2V p-p [5]. 2.3. Ethernet Connection The WARP has a single Ethernet transceiver chip which handles the physical layer implementation. To make packet construction easier Rice University has released, as part of its WARPLab architecture, libraries and functions which allow for the easy construction of UDP packets via the PowerPC processor. WARPLab is designed to make creation of radio networks with the WARP easy and is detailed further in [5] and [1]. The Ethernet Lite Media Access Controller (a pre- built Xilinx core) is used in the FPGA firmware as the interface between the processor and the Ethernet transceiver chip. Packets are assembled in the processor utilizing the “WARPxilnet” library which is a hybrid WARP/Xilinx Networking TCP/IP stack library. This library contains the necessary functions for building a packet as well as setup operations such as socket creation, and IP/MAC address assignment. The functions called from this library will instruct the Ethernet Lite Media Access Controller to provide the physical layer transceiver chip with the appropriate packet structure. The physical layer transceiver chip will handle the actual transmission of a packet. 2.4 DDR2 Memory Module The key element in this architecture is the utilization of the 2GB DDR2 memory module on the WARP. This storage device allows for capture and playback of a significant amount of data. In the GPS application detailed later, which uses 4-bit quantization and a sample rate of 6.25MHz, the module can hold approximately 10 minutes of continuous data. To facilitate read/write operations, Xilinx has a pre-built core called the Multi-Port Memory Controller (MPMC) which serves to connect the DDR2 memory module to the PLB [7]. The processor can utilize simple read/write commands to extract/load data from memory. 2.5. Clocking The Virtex 4 on the WARP is driven by a 40MHz temperature compensated crystal oscillator (TCXO), however off-board connectors are available for external clock sources if desired [5]. The clocks for the PLB, processor, DDR2 RAM, and analog board are created by Digital Clock Manager blocks inside of the Virtex 4 which are driven by the 40MHz reference [7]. This provides a great deal of flexibility for the specific clock rates of the FPGA cores and ADC elements. The Digital Clock Manager blocks are configured to generate the frequency of interest based on frequency divide and multiply settings [8]. 2.6. Repository One of the most powerful tools in developing on the WARP is access to the online WARP repository. This is a free collection of schematics, tutorials, libraries, related papers, and example firmware/software builds (like WARPLab) that are all designed to make working with the WARP easier [5]. The open-access nature of the WARP allows users to examine all aspects of the platform. In the case that information is missing, an online user forum allows the general public to ask questions to the original developers of the system. 3. DEVELOPMENT TOOLS Version 1 of the WARP FPGA board contains a Xilinx Virtex 2 FPGA. Xilinx stopped supporting the Virtex 2 in its development tools (ISE Design Suite) following tool version 10.1 [5]. To maintain compatibility with all versions of the WARP boards, a large amount of work in the repository was done utilizing Xilinx ISE version 10.1. As a results of this Xilinx ISE version 10.1 is utilized in this work. It should be noted however, that this version of the tools is incompatible with newer versions of the Xilinx ISE tools. 3.1. Developing Custom Logic Rather than writing custom logic cores for the WARP in VHDL or Verilog, Xilinx provides a tool known as System Generator which is able to speed development significantly. This tool integrates with the graphical programming environment of Matlab’s Simulink interface and allows for the assembly of different FPGA elements (logic gates, mathematical instructions, etc.). System Generator is also able to create an interface to the PLB. This makes developing custom logic cores which are accessible to the processor much easier. 3.2. Assembling the Cores Once all custom logic has been designed in System Generator, it can be imported into the Embedded Development Kit which is another tool in the Xilinx ISE tool set. This environment allows multiple pre-built or custom cores to be instantiated and connected to any 49 required bus structures, FPGA signals, or FPGA pins. The Embedded Development Kit is also capable of running the necessary compilation, map, and route functions necessary to create a complete FPGA image, ready for download. 3.3. Developing Software The final stage of development is processor software. This is done inside of the Software Development Kit, another member of the Xilinx ISE tool set. This integrated development environment allows for processor software to be developed in C, C++, or assembly for compilation and download to the processor. 4. TRANSFERRING DATA By offloading saved data in the WARP’s DDR2 memory to a host-PC, waveforms can be captured for playback at some later date. However, with the 2GB capacity of the memory module, sending this data out of the platform demands a high-speed data link. The Ethernet connection described in section 2.3 is the simplest to utilize high-speed link on the WARP. This is due to the use of Ethernet in Rice University’s WARPLab architecture [1]. In the WARPLab architecture UDP packets are sent from Matlab to the WARP and then back again. Both the host PC side of communication and the WARP side of communication are detailed further in the following sections. 4.1 Ethernet in Matlab Thanks to the open-source TCP/UDP/IP Toolbox for Matlab, sending Ethernet packets does not require the Instrument Control Toolbox from Mathworks [9]. The “pnet” function in this toolbox is capable of handling all of the necessary steps for establishing a UDP connection with the WARP node. In the WARPLab architecture, Matlab creates a control packet which contains a specific command number to be executed in the WARP. This command number is decoded by the processor in the WARP through the use of a large switch statement. Each case in the switch statement represents a different command (get data, store data, etc.) and the processor replies with a specific “acknowledgement packet” that the command was received and executed [1]. The Matlab packet contains a packet number for tracking, a specific memory address in the WARP to be accessed and (if needed) a payload of up to 1024 bytes as illustrated by Figure 1. Once the packet has been constructed and sent, Matlab waits to receive an acknowledgement packet before continuing with any new instructions. Should the WARP not provide an acknowledgement packet, a timeout event occurs and the Matlab program terminates. Figure 1 - Matlab Packet 4.2 Ethernet in the WARP As described in section 2.3, packets are built by the processor at the MAC layer before sending them to the FPGA for transmission. Each command in the processor’s switch statement corresponds to a different type of packet to be built. In the case of a “get data command”, a memory copy function is used to retrieve the 1024 bytes from a memory location and store them in the processor’s data memory as the packet payload. This data is combined with a new packet number, the current command number, the acknowledgement flag, and the memory address from which the payload originated is included. The WARP packet is illustrated in Figure 2. A similar “store data command”, moves 1024 bytes from a received Matlab packet payload to a specific memory address. Once the data transfer is complete, the processor returns an acknowledgement packet (with no payload) to Matlab to signify the data was received and stored. Figure 2 - WARP Packet 5. CAPTURING LIVE DATA The key application of the elements described in this paper is to capture a waveform from an RF front end and store it in the WARP. Specifically this architecture was designed to capture enough GPS data to determine position location, roughly 37 seconds of data. As a result, many of the design decisions are optimized for a GPS receiver; however, this architecture could be adapted for other waveforms. The baseband analog board described in section 2.2 is utilized to digitize the waveform, while the DDR2 RAM interface described in 2.4 stores the samples. Finally, the Ethernet connection detailed in sections 4.1 and 4.2 is slightly altered to allow the data stored in DDR2 RAM to be exported to a host-PC. 5.1. Quantization The ADC on the baseband analog board is 14-bits. In the case of GPS applications, this level of precision is unnecessary, resulting in excessive FPGA element and memory usage [10]. Data communication over the PLB is 50 done in 32-bit transfers. To maximize each transfer, individual samples were quantized to 4-bits and then 8 samples were packed together to create a single 32-bit word. Figure 3 shows the structure of each word, where X[m] represents a data sample at time m. ������� �� ��� �� �� ��� �� �� �� �� �� �� �� �� �� �� �� �� �� ��� �� ��� �� ��� �� ��� �� ��� �� ��� �� ��� Figure 3 – 32-bit Memory Word, 4-bit Quantization The architecture was also modified to test the case of 8-bit samples, consisting of 4 samples packed together. Figure 4 shows the structure of a memory word for this case. Changing the number of bits utilized simply illustrates the expandability of this architecture, since 4 bit samples are sufficient for GPS processing. Figure 4 - 32-bit Memory Word, 8-bit Quantization 5.2 Temporary Data Storage Data is stored into DDR2 by writing to an address assigned to the MPMC core. For this architecture, the processor must access the data and write it to the DDR2 memory. In order to make the input data available to the processor, 32-bit words are first written to FPGA block RAM (each RAM address holds a single 32-bit word) in blocks of 256 words. A ping-pong buffering system is setup such that while one block is filling, the other block is being moved by the processor to DDR2 memory. This process is illustrated in Figure 5 and Figure 6. . Figure 5 - Buffer 1 Recording, Buffer 2 Moving to DDR2 Figure 6 - Buffer 1 Moving to DDR2, Buffer 2 Recording Once a block has successfully been moved, the processor waits for the other block to fill and repeats the process. A timing failure detector is implemented to detect if the time to transfer a block to DDR2 memory exceeds the time to fill a FPGA RAM block with new data. Should this timing constraint be exceeded, the data stored in DDR2 memory would have discontinuities. 5.3 Exporting Data Once the processor has moved enough FPGA RAM blocks to DDR2, it is then tasked with running the Ethernet connection with Matlab. The Ethernet structure described in section 4 is utilized to move the 32-bit words from DDR2 memory to Matlab where they are then written to disk. The only change that needs to be made to the WARPLab Ethernet structure is the packet reception behavior of Matlab. When Matlab is waiting for an acknowledgement packet, a timer is started. Originally, if the packet is not received after certain duration, the reception is aborted and the program is terminated. This behavior is not desirable for large data transfers. Instead, the Matlab behavior was modified such that if Matlab does not receive a reply from the WARP after certain duration, the packet is resent. A “mush” counter ensures that Matlab does not attempt to resend a packet endlessly. The modifications to the WARPLab Ethernet structure allow for the loss of packets without ruining a data transfer. Depending on the processing to be done with the collected data, a user may wish to write a separate program on the host-PC to split the 32-bit words back into the 8, 4-bit samples (or if 8-bit quantization was used, 4, 8-bit samples). 6. CAPTURING A GPS SIGNAL As a demonstration of this architecture’s abilities, the capture data architecture was used in a situation similar to the one described in Thompson et al. [10]. In the situation shown in Figure 7, the signal received from a GPS antenna was filtered and amplified before being passed through a Rohde & Schwarz FSG spectrum analyzer. By setting the spectrum analyzer’s center frequency to the GPS L1 carrier and setting the span to 0 Hz, the analyzer produced a downconverted GPS signal at its IF output. The IF output of 51 the spectrum analyzer was then sampled at 6.25MHz by the WARP for 37 seconds before the data was sent to a host-PC to be processed by GPS receiver software. The receiver software, based in Matlab, computes the user’s position and returns location coordinates in non-real-time based on a given input data file [11]. ���� ���� �� ������� �������� ��� � � ���� ��� �� ���� �� �� � �� ������ �!� "� #� �� $�� %!� !&� '�� (%� ��)* + ,� �� Figure 7 - GPS Receiver Block Diagram In the GPS Receiver Block Diagram of Figure 7, the IF output of the spectrum analyzer is undersampled at a rate of 6.25MHz. This sample rate is able to preserve at least 90% of the signal energy from the GPS direct sequence spread spectrum signal. However, there will be a residual carrier frequency of 1.65MHz [3]. The clock rates selected for the GPS receiver implementation can be seen in Table 1. The ADC can be downsampled by a factor of 6 to attain the sample rate of 6.25MHz. The other clock speeds were selected to increase throughput while still maintaining FPGA timing constraints. Table 1 - FPGA Clock Speed Selections Element Clock Speed (MHz) Analog Board ADC 37.5 PLB 75 Ping-pong buffer system 75 Processor 150 DDR2 150 These clock rates allowed 37 seconds of data to be stored into the DDR2 memory. Once the desired data had been stored, the data was then exported to Matlab via the Ethernet connection, and the samples were de-interleaved and saved to disk. The final step in processing the GPS signal is to invoke the Matlab-based GPS receiver included in Borre et al. [11]. Both 4-bit quantization and 8-bit quantization architectures were tested, and both produced similar results. The results displayed here are for the case of 4-bit quantization levels. The data characteristics (histogram, time-domain plot, and frequency spectrum) are displayed in Figure 8. There are 32 different satellites in orbit, but only a small set are actually visible at any point in time. Figure 9 shows the specific satellites that were detected and tracked by the receiver. The final position was calculated as Lat 41.115679, Long -85.109516. The actual location of the antenna was at Lat 41.115727, Long -85.109465. Figure 8 - Raw Data Analysis Figure 9 - Satellite Acquisition Results 7. CONCLUSIONS The architecture presented here is capable of turning the WARP into a test bed for DSP applications. Real-world signals can be captured by the WARP’s Analog Board and stored in its DDR2 memory module. Once the desired samples have been collected, the data can be exported via Ethernet to Matlab to be saved to disk on the host PC. Alternatively, pre-saved waveforms can be loaded into the WARP’s DDR2 memory module via Ethernet connection to 52 be processed by custom algorithms implemented in the FPGA. The pre-saved waveforms could be WARP- collected data, simulation data, or externally captured signals. While this architecture was developed for the specific purpose of capturing and processing GPS signals, it could be adapted to other DSP applications. 8. ACKNOWLEDGEMENTS We would like to acknowledge the National Science Foundation for sponsoring this research through a grant to Indiana-Purdue University (IPFW) Fort Wayne, DGE-SMP 1010908 titled “Science Master’s Program: Concentration in Wireless Technology and Systems Engineering.” 9. REFERENCES [1] M. Duarte, P. Murphy, C. Hunter, S. Gupta and A. Sabharwal, "WARPLab: Multi-node Prototyping with Real Wireless Data," Journal of the Franklin Institute, October 2011. [2] S. Gupta, "Masters Thesis: WARPnet: A Platform for Clear-Slate Deployed Wireless Networks," Rice University, Houston, TX, December 2009. [3] J. Hershberger, E. Thompson and T. Loos, "Design Considerations for a WARP-Based Real-Time Software-Defined GPS Receiver," in Institute of Navigation: International Technical Meeting, San Diego, CA, January 2013. [4] W. Cheng, K. Tan, V. Omwando, J. Zhu and P. Mohapatra, "RSS-Ratio for Enhancing Performance of RSS-based Applications," in IEEE International Conference on Computer Communications, Turin, Italy, 2013. [5] "WARP Project," Rice University, [Online]. Available: http://warpproject.org. [Accessed 8 April 2013]. [6] J. Noseworthy, "Masters Thesis: Enabling Communications Between an FPGA's Embedded Processor and its Reconfigurable Resources," Northeastern University, Boston, MA, August 2005. [7] Xilinx Inc., "LogiCORE IP Multi-Port Memory Controller," 1 March 2011. [Online]. Available: http://www.xilinx.com/support/documentation/ip_doc umentation/mpmc.pdf. [Accessed 9 April 2013]. [8] Xilinx Inc., "Virtex-4 Family Overview," 30 August 2010. [Online]. Available: http://www.xilinx.com/support/documentation/data_sh eets/ds112.pdf. [Accessed 8 April 2013]. [9] P. Rydesater, "TCP/UDP/IP Toolbox 2.0.6," 6 March 2008. [Online]. Available: http://www.mathworks.com/matlabcentral/fileexchang e/345. [Accessed 9 April 2013]. [10] E. Thompson, N. Clem, T. Loos and I. Renninger, "Software-Defined GPS Receier on USRP-Platform," Journal of Network and Computer Applications, vol. 35, no. 4, pp. 1352-1360, July 2012. [11] K. Borre, D. Akos, N. Bertelsen, P. Rinder and S. Jensen, A Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach, Boston, MA: Birkhauser, 2007. 53