AN FPGA ABSTRACTION LAYER FOR THE SPACE TELECOMMUNICATIONS RADIO SYSTEM
by
JENNIFER NAPPIER
Submitted in partial fulfillment of the requirements For the degree of Master of Science
Thesis Advisor: Dr. Frank Merat
Department of Electrical Engineering and Computer Science CASE WESTERN RESERVE UNIVERSITY
January, 2009
CASE WESTERN RESERVE UNIVERSITY
SCHOOL OF GRADUATE STUDIES
We hereby approve the thesis/dissertation of
______Jennifer M. Nappier
Master of Science candidate for the ______degree *.
Dr. Frank Merat (signed)______(chair of the committee)
Dr. Marc Buchner ______
Dr. Christos Papachristou ______
______
______
______
11/05/08 (date) ______
*We also certify that written approval has been obtained for any proprietary material contained therein. Table of Contents
List of Abbreviations ...... vi
List of Abbreviations ...... vi
Abstract...... viii
1 Introduction...... 10
2 STRS Waveform Development Goals ...... 14
2.1 Design a waveform that is reconfigurable ...... 14
2.2 Design a waveform that is reusable and portable across SDRs...... 14
2.3 Design a waveform that is platform independent ...... 15
3 Current STRS Architecture Standard ...... 16
4 Other Standards...... 18
4.1 Joint Tactical Radio System (JTRS) Software Communication Architecture.. 18
4.2 WISHBONE System-on-Chip Interconnection Architecture ...... 19
4.3 Open Core Protocol Specification ...... 20
5 Extension to STRS: Firmware Developer Interface ...... 22
6 Implementation ...... 27
7 FDI Testing ...... 33
7.1 GPP Control Read and Control Write...... 33
7.2 GPP Data Read and Data Write...... 34
7.3 ADC Data Read and DAC Data Write ...... 35
8 Future Work...... 37
9 References...... 39
iii
List of Tables
Table 1: Control FDI signals...... 25
Table 2: Corresponding FDI DATA and API NAME pairs...... 25
Table 3: Data FDI signals...... 26
Table 4: FDI Verilog file descriptions...... 30
iv
List of Figures
Figure 1: STRS Hardware Architecture Diagram...... 11
Figure 2: MHAL API diagram [4]...... 19
Figure 3: WISHBONE module interfaces [5]...... 20
Figure 4: OCP IP cores communicate via a wrapped buss [6]...... 21
Figure 5: Conceptual drawing of the Firmware Developer Interface in the FPGA...... 23
Figure 6: High level block diagram of SDR breadboard...... 28
Figure 7: Conceptual implementation example of the Firmware Developer Interface. ... 28
Figure 8: FDI implementation with file structure labeled...... 29
Figure 9: FPGA waveform controller...... 33
Figure 10: GPP control read and control write test...... 34
Figure 11: GPP data read and data write test...... 35
Figure 12: ADC data read and DAC data write loop back test...... 36
v
List of Abbreviations
ADC – Analog to digital converter
API – Application programmer interface
ASIC – Application specific integrated circuit
CoNNeCT – Communications, Navigation and Networking re-Configurable Test bed
DAC – Digital to analog computer
DSP – Digital signal processor
FDI – Firmware developer interface
FEC – Forward error correction
FIFO – First in first out
FPGA – Field programmable gate array
GPM – General-purpose processing module
GPP – General purpose processor
GRC – Glenn Research Center
HDL – Hardware description language
HID – Hardware interface description
IF – Intermediate frequency
ISE – Integrated software environment
ISS – International Space Station
JPEO – Joint Program Executive Office
JTRS – Joint Tactical Radio System
MHAL – Modem Hardware Abstraction Layer
OCP – Open Core Protocol
vi
NASA – National Aeronautics and Space Administration
RF – Radio frequency
RFM – Radio frequency module
SCA – Software Communications Architecture
SDR – Software defined radio
SPM – Signal processing module
SOC – Silicon-on-a-chip
SSP – Specialized signal processing
STRS – Space Telecommunications Radio System
VHDL – Very high speed integrated circuits (VHSIC) hardware description language
VHSIC – Very high speed integrated circuits
vii
An FPGA Abstraction Layer for the Space Telecommunications Radio System
Abstract
by
Jennifer Nappier
The Space Telecommunications Radio System (STRS) Architecture Standard describes a standard for NASA space software defined radios (SDRs). It provides a common framework that can be used to develop and operate a space SDR in a reconfigurable and reprogrammable manner. One goal of the STRS Architecture is to promote waveform reuse among multiple software defined radios. Many space domain waveforms are designed to run in the specialized signal processing (SSP) hardware.
However, the STRS Architecture is currently incomplete in defining a standard for designing waveforms in the SSP hardware. Therefore, the STRS Architecture needs to be extended to encompass waveform development in the SSP hardware. The extension of STRS to the SSP hardware will promote easier waveform reconfiguration and reuse.
Extensions of the STRS Architecture Standard in the field programmable gate array
(FPGA) were proposed. The extensions included a standard hardware abstraction layer for firmware in FPGAs. Current existing FPGA hardware abstraction layer standards were researched. These standards included the Joint Tactical Radio System (JTRS)
Modem Hardware Abstraction Layer (MHAL), the WISHBONE Architecture, and the
Open Core Protocol (OCP). The proposed STRS hardware abstraction layer was designed to provide standardized interfaces to the STRS waveform application running on the FPGA. Therefore, the waveform developer would not have to know a lot of
viii
information about the rest of the SDR platform. This standard hardware abstraction layer was called the Firmware Developer Interface (FDI). The FDI was implemented and tested on a laboratory breadboard SDR. The implementation and testing of the FDI on a laboratory breadboard SDR will be discussed.
ix
1 Introduction
The Space Telecommunications Radio System (STRS) Architecture Standard [1] specifies an open architecture for NASA space software defined radios (SDRs). The
STRS Architecture Standard divides the SDR into three functional hardware modules – the general-purpose processing module (GPM), the radio frequency module (RFM), and the signal processing module (SPM). There is a hardware interface description (HID) between each module that describes all of the physical hardware interfaces. The GPM contains a general purpose processor (GPP), memory, and the Spacecraft Telemetry
Interface. The GPM runs the STRS Infrastructure and configures and controls the entire
radio. The RFM contains filters, up/down converters, power amplifiers, digital to analog
converters (DACs), and analog to digital converters (ADCs). It handles the conversion
between the radio frequency (RF) and the intermediate frequency (IF) signals. The SPM
contains a field programmable gate array (FPGA), digital signal processor (DSP),
application specific integrated circuit (ASIC), or other specialized signal processing
(SSP) device. The SPM performs the transformations between the IF digitally sampled
signals and the data packets. These transformations are currently the reconfigurable part
of the SDR waveforms. A drawing of the functional hardware modules of the STRS
Architecture is shown in Figure 1.
10
Figure 1: STRS Hardware Architecture Diagram.
In the context of STRS and SDRs, “a waveform is the set of transformations applied to information (e.g. voice or data) that is transmitted over the air and the corresponding set of transformations to convert received signals back to their information contents [2].”
The part of a space waveform that is placed in FPGAs is the data formatting, modulation, forward error correction (FEC) coding and decoding, spreading and despreading, filtering, etc. The waveform on the FPGA usually takes in user data through a data source, performs transformations, and outputs a signal at base band or at IF (~70 MHz).
The “waveform application is the code that implements all the functions and algorithms
11
necessary to realize a waveform [2].” The waveform application in the FPGA consists of
the very high speed integrated circuits (VHSIC) hardware description language (VHDL)
or Verilog code that implements the waveforms.
It is desirable to place a space waveform in the FPGA due to the reconfigurable
nature of the device and the ability to support high digital data rates. However, the STRS
Architecture only specifies high-level standards for waveforms developed in the FPGA.
This research explores a concept for developing a firmware-based STRS compliant
waveform that is reconfigurable and reusable. A hardware abstraction layer for FPGAs
was proposed, implemented, and tested on a space SDR breadboard. This hardware
abstraction layer is called the Firmware Developer Interface (FDI). The FDI implements
the device drivers required to access devices outside of the FPGA. The FDI is meant to
be a standardized interface across all FPGAs on all SDR platforms. The purpose of the
FDI is to allow a waveform developer to place a waveform in an FPGA with less knowledge of the rest of the SDR platform. This will save development time since waveform developers will not have to write device drivers for each platform on which they place their waveform. It will also allow waveforms to be ported among STRS compliant SDR platforms more easily since the interfaces to devices will be more similar.
This concept is the first step towards extending the STRS Architecture standard to the firmware inside the FPGA.
A brief outline of the rest of the thesis follows. The development goals for developing STRS waveforms will be discussed in section 2. The current STRS
Architecture’s support of these goals is discussed in section 3. A summary of other relevant standards will be discussed in section 4. Section 5 describes the extension to the
12
STRS Architecture to support the STRS waveform development goals. This extension is a hardware abstraction layer for FPGAs, called the FDI. Section 6 discusses lab-based implementations of the extensions and section 7 describes the FDI testing that was performed. Finally, section 8 describes possible future work and plans to incorporate the
FDI into the STRS Architecture Standard document.
13
2 STRS Waveform Development Goals
2.1 Design a waveform that is reconfigurable
Reconfigurability is the ability to modify functionality of a radio by changing the operational parameters without requiring a software update. One reason to reconfigure a space SDR may be in response to changes in environmental or physical conditions experienced by the spacecraft. Another need for SDR reconfiguration is that the same communication network might use several variations of one waveform to perform different operations (e.g. different phases of a mission or modes of spacecraft operations).
There could be little or no operational down time during reconfiguration.
2.2 Design a waveform that is reusable and portable across SDRs
Reusability is the degree to which a software module or other work product can be used in more than one computing program or software system. The number of waveforms being used by NASA is limited and unlikely to increase or dramatically change. Reusing all or part of the code for this limited number of waveforms will decrease development time and cost and increase reliability. It is desired that both the individual waveform functions and the entire waveform as a whole be reusable. A waveform developer should be able to port individual waveform functions between SDR platforms. This might include replacing individual functions in a waveform, or reusing individual functions across several waveforms. A waveform developer should also be able to easily port entire waveforms to many different SDR platforms.
14
2.3 Design a waveform that is platform independent
One way to promote waveform reusability is to start with a platform independent
design methodology. The highest level of abstraction of the waveform design should be platform independent. This might be accomplished with a platform independent simulation tool model, or HDL code that is written in a platform independent manner.
15
3 Current STRS Architecture Standard
The current STRS Architecture Standard enables many of the waveform design goals
listed in section 2 to be achieved. The STRS Architecture is more defined for the GPM
than the SPM. This section describes how the current software and firmware sections of
the architecture enable the waveform design goals to be met, but also points out some
shortcomings.
The software section of the STRS Architecture Standard specifies a common way to
reconfigure waveform parameters on a space SDR without waveform reloading. The
STRS Infrastructure running on the GPP specifies the use of STRS Application Program
Interface (API) calls. These STRS API calls utilize device drivers on the GPP which
interface to corresponding devices on the SPM or RFM. These APIs include the
STRS_DeviceRead, STRS_DeviceWrite, STRS_DeviceGetAttribute, and
STRS_DeviceSetAttribute APIs. They can be used to control and reconfigure the
waveform components resident in the FPGA.
The software section of the STRS Architecture Standard supports the ability to
remotely reprogram a compliant SDR with a different compliant waveform. The
STRS_LoadDevice API can load a bit file that has been sent to a radio onto a FPGA or other device. In this way, a new waveform can be remotely loaded onto a FPGA.
The software section of the STRS Architecture Standard specifies standard APIs that
interface to waveform functions running on the GPP. Therefore, code that is written on
the GPP is portable and reusable across different SDRs. Software is platform
independent because it is written in a high-level language like C.
16
The firmware section of the STRS Architecture Standard supports the use of modeling based firmware design techniques. Models can be developed using platform independent design techniques, but they could also be platform specific. The Firmware
Architecture also supports the use of modularity and clear interfaces in waveform design and modeling. However, the Firmware Architecture does not define these interfaces in detail.
The firmware section of the STRS Architecture Standard supports reusable firmware- based waveforms through the use of a common waveform library. It also specifies an internal HID and an external HID. Device drivers are used to interface to the internal and external HID. The internal HID is an interface between devices on the SPM. The external HID is a set of interfaces from each device on the SPM to the GPM and RFM.
However, these interfaces are not specifically defined. Waveforms could be more reusable and portable if a common interface would be defined.
17
4 Other Standards
4.1 Joint Tactical Radio System (JTRS) Software Communication
Architecture
The Joint Tactical Radio System (JTRS) is a standard system of military radios
designed for deployment after 2010. The radios must conform to the Software
Communications Architecture (SCA) [3]. The main goals of the SCA include promoting
portability of SCA software applications, reducing radio design time, leveraging current
commercial standards, and building on current industry frameworks.
The SCA contains a Modem Hardware Abstraction Layer (MHAL) Application
Program Interface (API) [4], which is the extension of the SCA to specialized signal
processing devices. The MHAL separates the specialized signal processing device API
extensions into separate extensions for the GPP, DSP, FPGA, and RF chain coordinator.
Each device on the radio contains a platform specific transport, which is vendor proprietary and is not standardized by the SCA. The SCA standardizes the interfaces to
the transport, which are called Data Sink and Data Source functions. The MHAL API
diagram, shown in figure 2, illustrates the Data Sink and Source functions with the
platform specific transport. The SCA also defines a standard message format.
18
Figure 2: MHAL API diagram [4].
The FPGA MHAL API extension Data Sink and Data Source functions are called
transmit and receive nodes. The transmit node consists of a multi-depth FIFO with
standardized signals and timing diagrams. There are several standard receive nodes
available. They are the multi-depth and single-depth FIFO nodes, the RAM receive node, and the N-word register. These receive nodes also consist of standard signals and
timing diagrams.
4.2 WISHBONE System-on-Chip Interconnection Architecture
The WISHBONE Architecture [5] is designed for the interfaces to soft, firm, or hard
IP cores. WISHBONE supports master and slave functions, and has a SYSCON module
which is used for clock generation. The basic relationship between the WISHBONE
MASTER, SLAVE, and SYSCON modules is shown in figure 3. There is a set of
minimum signals that must be implemented in WISHBONE. The rest of the signals are
optional. One important aspect of WISHBONE is the standard signal naming
19
convention. Input signals are tagged with a _I suffix and output signals are tagged with a
_O suffix. The standardization of the documentation for IP core interfaces is another important part of WISHBONE. The documentation must specify information such as the signal names and descriptions, whether the interface is a master or a slave, WISHBONE revision, data transfer description, and clock timing constraints.
Figure 3: WISHBONE module interfaces [5].
4.3 Open Core Protocol Specification
The Open Core Protocol (OCP) [6] is a bus independent set of interfaces designed for system-on-a-chip (SOC) intellectual property (IP) cores. The OCP is not specifically design for FPGAs and focuses on IP core interfaces, not device abstraction layers. It divides the functions into master and/or slave IP cores. The IP cores are connected together using the on-chip bus. The basic OCP function relationship is shown in figure 4.
20
The interfaces are separated into read and write interfaces. There is a minimum set of signals for the interfaces, called the basic signals. There are also additional signals to perform additional operations such as bursting, command and control, and testing.
Figure 4: OCP IP cores communicate via a wrapped buss [6].
21
5 Extension to STRS: Firmware Developer Interface
The standards described in section 4 are useful in some aspects to the STRS Standard,
but cannot be fully adopted. The JTRS concept of having different hardware abstraction
layers for different processing devices on SDRs is an excellent idea. However, STRS
does not define a standard messaging passing method and the MHAL for FPGAs might
be too extensive for resource constrained space platforms. The Wishbone and OCP
standards are more oriented towards IP cores within the FPGA than towards interfaces to
devices external to the FPGAs. These standards could be applicable in the
standardization of waveform function interfaces running on the FPGA, but this is not the
focus of this thesis.
The current release of the STRS Architecture is currently incomplete in defining a
standard in FPGAs. In this thesis, an extension to the STRS Architecture Standard was
developed to promote waveform portability and reuse in FPGAs placed in space SDRs.
In order to promote portability, waveforms should be developed to contain minimal external interfaces to resources outside the FPGA. Limiting the waveform dependency on SDR platform hardware devices external to the FPGA enables reuse across many different STRS compliant SDR platforms. One way to minimize waveform dependency on devices external to the FPGA is to define a set of common external interfaces. The common interface is called the Firmware Developer Interface (FDI). The FDI abstracts the device drivers between the waveform application and devices external to FPGA, presenting a standard interface to the firmware-based waveform functions. The FDI is a set of standard interfaces, but does not specify the device drivers that implement these interfaces. These device drivers are vendor proprietary information, and it is not desired
22
to standardize the implementation of these drivers. The implementation and documentation of the FDI is the platform designer’s responsibility. The waveform designer will use the FDI to access radio platform devices outside the FPGA. A conceptual drawing of the FDI on the FPGA is shown in Figure 5. The FDI is shown in shaded red, and its implementation is shown within the platform specific wrapper in light blue. The platform specific wrapper contains the device drivers as well as other vendor specific proprietary information necessary to run the SDR platform. There is an FDI interface to each waveform function on the FPGA. The FDI could be extended to other non-FPGA SPM devices, but the focus of this thesis is on standardization in FPGAs because most space SDR platforms currently use the FPGAs to implement the waveform applications.
Figure 5: Conceptual drawing of the Firmware Developer Interface in the FPGA.
23
There are two types of FDIs proposed: the control FDI and the data FDI. The control
and data FDIs have the capability to both read from and write to devices external to the
FPGA.
The control FDI provides a control interface into the FPGA. A waveform controller
running on another device, such as the GPP, would use this interface to control the
waveform functions running in the FPGA. This control interface is currently defined for
the situation in which the GPP is the master and the FPGA is the slave. This interface is
a memory mapped interface with corresponding data address busses. The control
interface consists of data, address, clock, and enable signals. The data address (DATA,
ADDRESS) pairs in the FDI should correspond to the name value (NAME, VALUE)
pairs in the STRS_DeviceRead, STRS_DeviceWrite, STRS_DeviceGetAttribute, and
STRS_DeviceSetAttribute APIs on the GPP. The proposed control FDI signals are
shown in table 1. The proposed common FDI DATA and corresponding API NAME
pairs are shown in table 2.
The data FDI is an interface to a hardware device where a continuous data stream is
needed. The data FDI signals can be used with or without handshaking signals. The
minimum data FDI signals without handshaking are proposed to be data, clock, and
enable, as shown in table 3. Handshaking signals for the data FDI will be defined in the
future. It is up to the waveform developer to choose the type of signals to use, but both
the minimum signals and handshaking signals must be implemented by the platform
provider.
There should also be a standard set of interfaces to the clock manager on the FPGA.
The clock manager generates the clocks that are used in the FPGA. These interfaces are
24
not defined in this paper, but their documentation by the platform provider is part of the proposed extension.
Table 1: Control FDI signals.
Control FDI Read Direction Name IN ControlRDY IN Address IN Data OUT Clock Write Direction Name IN ControlRDY IN Address OUT Data OUT Clock
Table 2: Corresponding FDI DATA and API NAME pairs.
FDI DATA API NAME FDI_START/STOP API_ START/STOP FDI_DATA_RATE API_ DATA_RATE FDI_DATA_FORMAT API_ DATA_FORMAT FDI_MODULATION API_ MODULATION FDI_IF API_ IF FDI_CODING API_ CODING FDI_AGC_GAIN API_ AGC_GAIN FDI_FUNCTION_ENABLE API_ FUNCTION_ENABLE FDI_FUNCTION_RESET API_ FUNCTION_RESET
25
Table 3: Data FDI signals.
Data FDI Read Direction Name IN Data IN Enable OUT Clock Write Direction Name OUT Data OUT Enable OUT Clock
26
6 Implementation
The control and data FDIs have been implemented on a laboratory SDR breadboard.
The SDR contains two Xilinx 2000e FPGAs, a Coldfire microprocessor, four ADCs, and eight DACs, 4 MB of SRAM, and 1 MB of flash memory. There is a 32 bit data and address bus between the FPGAs and the Coldfire microprocessor and the ADCs and
DACs have a bus width of 10 bits. A functional block diagram can be seen in figure 6.
In the past this breadboard has been primarily used to develop the part of space waveforms up to IF (~70 MHz). Similarly capable SDRs have flown missions in space.
Therefore, this SDR platform was a good candidate on which to implement the first FDI.
The HDL code was written in Verilog, and this is indicated by a .v file extension.
The development tool used to create the .bit file was Xilinx Integrated Software
Environment (ISE).
The FDI has been implemented to replace the functions of the platform specific wrapper supplied by the platform vendor, so that there is not an impact on performance.
Test functions have been created to use the FDI to interface with components on both the
GPM and the RFM. A diagram of the interfaces that were implemented is shown in figure 7.
27
Figure 6: High level block diagram of SDR breadboard.
Figure 7: Conceptual implementation example of the Firmware Developer Interface.
The interface to the GPM was the most difficult to implement. The GPM HID consisted of an address bus and a data bus, but the FDI was implemented to abstract the
28
HID from the firmware as a control read/write and a data read/write. The read functions were placed in one file and the write functions were placed in another file, as shown in figure 8. Table 4 contains descriptions of each of the files shown in figure 8.
Figure 8: FDI implementation with file structure labeled.
29
Table 4: FDI Verilog file descriptions.
File Name File Description FDI Placement Wrapper.v Highest level .v file. Contains ADC_Read (Data Read) direct connection to the FPGA pins. The clock manager and ADC read functions are implemented here. This file also contains platform specific functions that do not interface to the waveform application. GPP_Read.v This function contains a state GPP Control/Data Read machine to implement the GPP control and data read function. Controls and data are placed in the correct asynchronous FIFO. GPP_Write.v This file contains a state machine GPP Control/Data Write that implements a function to write to the GPP. The control signals do not use a FIFO, but the data uses an asynchronous FIFO. DAC_Write.v This file contains the DAC Data Write implementation of the DAC interface.
The control and data read functions were implemented in one file, GPP_Read.v. The control read interface was implemented using state machine. The control signals were placed in an asynchronous first in first out (FIFO) memory. The ControlRDY signal indicated when a control data address pair was placed in the FIFO and was stable to be read out by the waveform application. The data read interface was also implemented using an asynchronous FIFO. The data read enable signal indicated when data could be read from the FIFO by the waveform application.
The control and data write functions were implemented in a separate file,
GPP_Write.v. The control interface could not be implemented with a FIFO because of
30
the GPP master FPGA slave data flow configuration. When the ControlRDY signal was asserted, the waveform application would place the data that corresponded to the requested address on the bus. The data write interface was implemented with an asynchronous FIFO. The enable signal indicated to the FIFO when a write operation was performed.
Although these interfaces were implemented as separate interfaces to the firmware developer, the actual HID between the FPGA and the GPP consisted of a single common address and a data bus. Data and control signals were separated by using one single address to indicate that the incoming signal from or outgoing signal to the GPP was a data stream. All other addresses were assumed to be data address pairs.
The interface to the ADC and DAC was very simple to implement. The enable signal indicated when the read or write was performed. The devices were also given a clock signal. The ADC FDI was implemented in the Wrapper.v file. The DAC FDI was implemented in a separate file, DAC_Write.v. This was done to illustrate that it does not matter how the FDI is implemented. Platform developers should be free to implement the interfaces in whatever manner they choose. The interfaces are the same to the waveform application in STRS_Waveform.v regardless of the implementation. The FDI implementation did not address ADC/DAC bit width variations. However, in the future a variable bit width control parameter could be added to the FDI.
The clocks that were generated by the clock manager were fed into the test waveform application for use by the waveform. However, the test waveform did not control the clock rate. It simply used the clocks provided by the clock generator function as
31
necessary. Control of the clock rate is something that could be placed in the FDI in the future.
32
7 FDI Testing
The FDI was tested using test waveform functions in the FPGA. Each interface was tested. The waveform application in the FPGA consisted of a waveform controller which routed clock and control signals to the appropriate function or device. The signal routing is shown in figure 9. The following tests were performed to verify the FDI implementations.
Firmware Developer Interface Signal Processing Module (FPGA)
Waveform Application ControlRDY Control Data Data Data DAC Address Enable Read CLK CLK Write
ControlRDY Controller Control Address Data Data ADC Data Enable GPP Write CLK CLK Read
Data Enable Data Read CLK
CLK1 Data Enable CLK2 Data CLK Write CLK Manager
Figure 9: FPGA waveform controller.
7.1 GPP Control Read and Control Write
The GPP control read and control write interfaces were tested using a counter in the
FPGA. The counter was connected to the DAC. The GPP would send a control signal to the FPGA through the control read interface to control the counting direction. Then the
GPP would read this register through the control write interface to verify that the register
33
was properly set. The register was also verified by the counter direction visible on the
output of the DAC. This test is shown below in figure 10.
Firmware Developer Interface Signal Processing Module (FPGA)
Waveform Application ControlRDY Control Data Data Data DAC Address Enable FDI Read CLK CLK FDI Write Counter ControlRDY Control Address Data Data ADC Data Enable GPP Write FDI CLK CLK FDI Read
Data Enable Data Read FDI CLK
CLK1 Data Enable CLK2 Data CLK FDI Write CLK Manager
Figure 10: GPP control read and control write test.
7.2 GPP Data Read and Data Write
The GPP data read and data write interfaces were tested using a loop back test. A
counter was the data source on the GPP. The data was written to the FPGA. The
controller on the FPGA stored the data in the outgoing data write FIFO. Then the GPP performed a data read operation to read the data back. This test is shown below in figure
11.
34
Firmware Developer Interface Signal Processing Module (FPGA)
Waveform Application ControlRDY Control Data Data Data DAC Address Enable FDI Read CLK CLK FDI Write
ControlRDY Control Address Data Data ADC Data Enable GPP Write FDI CLK CLK FDI Read Loopback
Data Enable Data Read FDI CLK
CLK1 Data Enable CLK2 Data CLK FDI Write CLK Manager
Figure 11: GPP data read and data write test.
7.3 ADC Data Read and DAC Data Write
The ADC data read and DAC data write interfaces were tested using a loop back test.
The data from the ADC input was routed directly out of the FPGA through the DAC.
This is shown in figure 12.
35
Figure 12: ADC data read and DAC data write loop back test.
36
8 Future Work
The first version of the FDI has been implemented and tested on a SDR breadboard that is similar to SDRs that fly in space.
The FDI extension to the STRS Firmware Architecture Standard is not in the currently release of the standard. However, in part as a result of this work, the STRS
Standard specifies that platform developers must implement their own platform specific wrapper for FPGAs on their SDR platform. They must also document the interfaces and provide the interface code as part of a deliverable for STRS conformant SDRs.
In the future, the FDI will be implemented on an FPGA on another SDR platform.
This will test if the data and control interfaces listed in this thesis are truly applicable to other SDR platforms. The FDI will be implemented by someone else. This will hopefully improve the FDI by getting another perspective on how easily the FDI can be implemented.
Next, plans include targeting the first platform on which the working FPGA FDI is implemented with a space waveform application. The ability to pass data to and configure the FPGA waveform using the FDI will be demonstrated using controls from the STRS Infrastructure running on the GPP. The waveform will be then ported to the second platform. Porting time and effort associated with SDRs with an FDI will be compared to the metrics of past waveform porting efforts without an FDI. This will test and demonstrate how the extensions to the STRS Firmware Architecture Standard enable waveform reusability, portability, and reconfiguration.
NASA is currently preparing a flight experiment which will demonstrate the STRS
Architecture Standard. The project is called the Communications, Navigation and
37
Networking re-Configurable Test bed (CoNNeCT). Three STRS conformant SDR
platforms will fly in low earth orbit. One of the experiments of CoNNeCT is for the
platforms will demonstrate on-orbit reconfiguration. The vendors for these platforms are
also interested in extending the STRS Architecture to the FPGAs. Therefore, a FDI for
the CoNNeCT vendors will be designed. Each vendor has a different design flow and design tool for waveforms, and so it will be important to show that the FDI can be implemented on a variety of platforms and with different waveform development tools.
Feedback from the vendors will be collected and used to improve the FDI.
The FDI concept will also be presented at the SDR Forum Technical Conference in
October 2008. The SDR Forum consists of companies, universities, and government agencies from across the world that work in the SDR industry. Feedback from SDR technical experts will be collected in order to enhance and improve future version of the
FDI.
The results from the implementation of the FDI on several platforms as well as the input from the SDR industry experts will be compiled. The information will be used to modify and improve the FDI. If the results and feedback indicate that the FDI will enhance waveform portability and reusability in FPGAs on SDR platforms, a future version of the FDI will become a part of the STRS Standard Architecture. The FDI could also be extended to other SSP devices such as DSPs on the SPM. The STRS Architecture
Standard will be modified over time as technology continues to change, as space waveforms are implemented in different ways, and as ways to improve the Standard become more evident.
38
9 References
[1] National Aeronautics and Space Administration, Headquarters, Space
Telecommunications Radio System STRS Open Architecture Standard 1.0,
Washington D.C., April 2006.
[2] National Aeronautics and Space Administration, Headquarters, Space
Telecommunications Radio System STRS Definitions and Acronyms, Washington
D.C., May 2008.
[3] JTRS Standards, Joint Program Executive Office (JPEO) Joint Tactical Radio System
(JTRS), Space and Naval Warfare Systems Center San Diego, Software
Communications Architecture Specification, Version 2.2.2, San Diego, CA, May
2006.
[4] JTRS Standards, Joint Program Executive Office (JPEO) Joint Tactical Radio System
(JTRS), Joint Tactical Radio System (JTRS) Standard Modem Hardware Abstraction
Layer Application Program Interface (API), Version 2.11.1, May 2007.
[5] OpenCores Organization, WISHBONE System-on-Chip (SoC) Interconnection
Architecture for Portable IP Cores Revision B.3, September 2002.
[6] OCP International Partnership Association, Open Core Protocol Specification 2.2,
Document Revision 1.0, Beaverton, OR, 2006.
39