A Single-Chip Supervised Partial Self-Reconfigurable Architecture for Software Defined Radio Oliver Faust, Bernhard Sputh, Darran Nathan, Sana Rezgui, Andreas Weisensee Ngee Ann Polytechnic, DSP Technology Center, Singapore
[email protected],
[email protected],
[email protected],
[email protected],
[email protected] Alastair Allen University of Aberdeen, Department of Engineering, Scotland
[email protected]
Abstract Software Defined Radio (SDR) technology seeks to solve the problem of multiple incompatible broadcast / telecom standards available in different locations, by having standard specific processing defined in software. This software will be downloaded and run on generic hardware, so that different broadcast / telecom standards can be supported by downloading corresponding software modules. Computing platform based SDR attempts to bridge the worlds of computing and broadcast / telecoms, by exposing the features and resources of computers to SDR and vice versa. However, such a concept results in certain architectural issues that need to be resolved. This paper describes the concept of Computing Platform based SDR, and the resulting issues & desired features of such a system. An innovative system architecture that involves the supervised partial self-reconfiguration of a single FPGA is proposed and detailed. Finally, a system test is conducted to illustrate and verify the reconfiguration operation.
1
Introduction
In recent years, there has been a proliferation of competing as well as complementary broadcast / telecommunications standards. This has led to equipment designed for a particular standard being rendered useless in a region where only other standards are supported. For example, a GSM (Global System for Mobile Communications) mobile phone that can be used throughout Europe is unusable in most parts of the United States, where the alternative CDMA (Code Division Multiple Access) standard is more
widely supported. Such incompatibilities often lead to inconvenience and frustration for the end-users. Software Defined Radio (SDR) technology seeks to solve these issues by having broadcast / telecom standard specific processing defined in software. This software is downloaded to generic hardware, for support of the particular standard defined by the software. This means that the same SDR Device can be used in different parts of the world where different standards are supplied, by simply downloading the desired SDR Software Module. The ’Proteus Project’ undertaken at NgeeAnn Polytechnic (Singapore) takes this idea one step further by making SDR computing platform based. This allows for a mutually beneficial relationship between the SDR Device and the Computing Platform - typical application programs on the Computing Platform will be able to tap on the flexibility of the SDR Device to send / receive information via different broadcast / telecom standards, while the SDR Device can take advantage of the abundant resources available on the Computing Platform, such as plentiful RAM and hard disk space. However, such a Computing Platform based SDR design exposes certain architectural issues that need to be resolved, mainly concerning the dynamic reconfiguration of the processor on the SDR Device. This article discusses these issues and presents an innovative system architecture that addresses them via the supervised partial self-reconfiguration of an FPGA (Field Programmable Gate Array). Section 2 discusses the issues and desired features of a Computing Platform based SDR design. Section 3 gives an overview of the system architecture and how it satisfies these requirements. Sections 4 and 5 delve into the details of that architecture. Finally, Section 6 describes a system test conducted to illustrate and verify the reconfiguration
0-7695-1926-1/03/$17.00 (C) 2003 IEEE
reserved in each FPGA for implementation of this bus interface. This and other issues mean the processing power of such systems never increases linearly with the number of processors;
operation.
2
Issues and Desired Features of the System
The idea of Computing Platform based SDR brings new issues in architectural design that need to be resolved. These issues and the proposed techniques to address them are detailed below. • A fundamental feature of the Computing Platform based SDR concept is the ability to control the SDR Device from any user application program running on the Computing Platform, such as a PC. For example, a user may initiate a reconfiguration of the SDR Device by using a running SDR Application. This means that the operation will have to be externally ’supervised’ by the computing platform; • The SDR Device is envisioned to have a ’plug-in’ architecture, so that it will be a peripheral device that can be attached to various computing platforms. Only the bus interface between the SDR Device and the Computing Platform will have to be common. The SDR Device will have to be flexible enough to support different bus interface standards as described;
• An alternative design that resolves these problems involves using a single FPGA for all bus interfacing, signal processing, and reconfiguration control tasks. A single chip solution removes the need for an advanced chip interconnect bus, supports higher processing speed since no external data transfer is necessary, and results in a much simpler design of the entire system. Such a single-chip design will require supervised partial self-reconfigurability to be effective at the chip level instead of system level.
3
System Architecture Overview
A prototype single-chip supervised partial selfreconfigurable architecture designed and developed is shown in Figure 1.
• When a new SDR Software Module is downloaded to the SDR Device for reconfiguration, the supervisor (the Computing Platform) will monitor the SDR Device status as reconfiguration is performed. The reconfiguration process will have to be performed by and controlled from within the SDR Device itself, hence the need for ’self-reconfigurability’; • For the computing platform to efficiently monitor the SDR Device during reconfiguration, there is a need for the Device to stay online and accessible by the supervisor throughout the reconfiguration process. Hence, a complete reconfiguration is not desirable - the bus interface on the SDR Device will also be affected in that case, resulting in a loss of connectivity with the supervisor. A ’partial-reconfiguration’, where the bus interface remains unchanged during reconfiguration, offers a solution to this problem; • The above discussed features can be readily implemented on a design that incorporates multiple FPGAs. This FPGA array uses different chips for different purposes, e.g. one FPGA to hold the PC interface, and another to hold the SDR Software Module demodulation algorithm. Scalability is inherent in this design, since additional FPGAs can be incorporated to take on additional processing tasks. However, such a multiplechip architecture will require an advanced inter-chip bus to exchange data quickly. Space will have to be
Figure 1. Overview of the Single Chip Partial Self-Reconfigurable System
The Computing Platform in this case is a general purpose PC, which interfaces with the SDR Device via the common PCI (Peripheral Component Interconnect) [5] bus. The SDR Device holds a single chip FPGA - a Xilinx Virtex XCV800 [6]. The User Application on the PC fulfils the role of the ’supervisor’, while the FPGA Design allows for partial selfreconfiguration. The Configuration Logic on-chip ASIC (Application Specific Integrated Circuit) performs the reconfiguration of the FPGA. The blocks shown in this Figure as being part of the FPGA Design constitute the ’Fixed Part’ of the FPGA, which is not modified in a partial selfreconfiguration operation. The rest of the FPGA not shown holds the SDR Software Module and will be reconfigured entirely.
0-7695-1926-1/03/$17.00 (C) 2003 IEEE
3.1
System Operation
When a user makes a selection on the User Application that seeks the download of a new SDR Software Module, the underlying Control will read a corresponding ’partial reconfiguration file’ (according to the desired broadcast / telecom standard) and send that, via the Device Driver, to the SDR Device over the PCI bus. On the SDR Device, the partial reconfiguration data received will be stored in RAM located on the FPGA. After the complete file has been transferred, further commands from the User Application will signal the Control block (in the FPGA Design) to trigger the Select Map Interface. This initiates a transfer of reconfiguration data from the RAM to the Configuration Logic over the Select Map Bus. The Configuration Logic interprets this partial reconfiguration information, which describes which parts of and how the FPGA should be reconfigured, and performs the reconfiguration accordingly. Once reconfiguration has been completed, the FPGA Design alters a flag. The User Application can poll this flag to check for the completion of the reconfiguration process.
4
User Application & Driver
The User Application on the PC acts as the ’supervisor’ of the system, sending commands to control the SDR Device, downloading & verifying the download of SDR Software Modules, and transferring data with the SDR Device for transmission / reception. The control of the device includes initialization of external components to transmit and receive the communications signal. A Device Driver enables access to the PCI card. In the actual implementation, the FPGA Design on the PCI card exposes two separate address spaces. The first address space is a 16 byte port range, used for control transfers. The second address space is a 1 megabyte memory range used for partial reconfiguration data transfers. The User Application [4], shown in Figure 2, is able to perform read / write operations on both the Port and Memory ranges. To do so, it employs a specific Device Driver [3] which acts as a gateway between the PCI Bus and the User Application. To reconfigure the FPGA, the user has to select a file which contains the reconfiguration data in ASCII format. The program converts the reconfiguration data from ASCII to binary, the resulting bit stream of which is partitioned into 32 bit DWORDs. These DWORDs will then be transferred via the device driver, to a target address in the memory range of FPGA Design, utilizing the Device Driver. The DWORDs are written with increasing offset into the memory range, to prevent overlapping of the data.
Figure 2. Verification succeeded
Upon completion of the reconfiguration download, the user has the ability to verify the downloaded data. This is done by reading back the previous written data from the PCI card, and comparing it with the content of the file.
5
FPGA Design
The FPGA has to incorporate logic for bus interfacing, signal processing, and partial reconfiguration control on a single chip. This imposes a requirement on the FPGA for partial self-reconfiguration capability. To allow for this feature, the ’FPGA Design’ incorporates four components: the PCI Bus Interface, Select Map Interface, RAM Module, and Control Logic as shown in Figure 3.
Figure 3. Block Diagram of the FPGA Design The PCI Interface performs data exchange with the De-
0-7695-1926-1/03/$17.00 (C) 2003 IEEE
vice Driver over the PCI bus. It exposes port and memory ranges for control and data transfers respectively. The port range is organized as a control register bank, while the memory range is used for addressing the RAM Module. The Select Map Interface directly drives the lines of the Select Map Bus during a reconfiguration cycle.
5.1
The Reconfiguration Operation
The RAM Module buffers the reconfiguration data to be transferred from the PCI Interface to the Select Map Interface. This requires both these components to have equal and mutually exclusive access to the RAM Module. During normal operation (no self-reconfiguration), the RAM Module is fully owned and accessible only by the PCI Interface. A reconfiguration file download during this time will correspondingly be enabled by the availability of the RAM Module, for temporary storage of reconfiguration data from the PCI Interface. Once the download is complete, the User Application asserts the ’Reconfiguration Start’ flag in the control port register. This signals the start of the reconfiguration process on the FPGA, and causes the Select Map Interface to drive the address, data, and clock lines for complete and exclusive control over the RAM Module. As a result, the RAM Module is not accessible over the PCI Bus during a reconfiguration of the FPGA. Reconfiguration data stored in the RAM Module will now be sent out over the Select Map Bus. After the Configuration Logic has interpreted this data and reconfigured the FPGA accordingly, the ’Reconfiguration Start’ flag is de-asserted and ownership of the RAM Module is handed back to the PCI Interface. This reconfiguration operation and the protocol between the components is illustrated in Figure 4. During a reconfiguration, access to the RAM Module has to be switched between the PCI Interface and the Select Map Interface. When this occurs, the address, data and clock lines have to be correspondingly switched. This is accomplished by the Multiplexer (MUX). As a precautionary measure, the Control Logic is responsible for intercepting any read or write attempts from the PCI Interface to the RAM Module during a reconfiguration. However, port control registers are still accessible over the PCI Bus.
5.2
Select Map Bus Clock Signal (CCLK)
A PCI Interface implementation includes the generation of a PCI clock signal. This cannot also be used as the clock signal (CCLK) of the Select Map Bus, since the PCI clock can vary in frequency. An external Quartz oscillator
Figure 4. Protocol between the Supervisor and the FPGA Design
is therefore incorporated into the design, to provide an independent CCLK signal.
5.3
Select Map Interface
The Select Map Interface is a critical feature that allows for partial self-reconfiguration of the FPGA. It transfers the downloaded partial reconfiguration data from the FPGA block RAM to the Configuration Logic over the Select Map Bus. The configuration data is stored in the FPGA block RAM in DWORDs, but the Select Map Bus utilizes eight parallel lines for data transfer. For this reason, the DWORD has to be split into four eight-bit units for transfer to the Configuration Logic. To start or stop a reconfiguration data transfer, corresponding start and stop conditions are defined by the Select Map Bus. A Finite State Machine (FSM) was implemented to perform the DWORD splitting and to keep track of the different bus states. The state diagram of this FSM is shown in Figure 5. It is implemented as a Moore machine, and therefore the output signals depend only on the state of the machine. The transitions from one state to another happen on the falling edge of the CCLK signal. Presenting data on the lines of the Select Map Bus only on the falling edge of the CCLK signal helps to ensure a stable data transfer operation. In the initial IDLE state, the Select Map Interface waits for the start command to arrive. When this occurs the state machine transitions to the START state, where the start condition is written to the Select Map Bus. This start condition indicates that a configuration data transfer is about to begin. From the START state, the state machine automatically pro-
0-7695-1926-1/03/$17.00 (C) 2003 IEEE
ceeds to the BYTE1 state, where the data lines of the Select Map Bus are sourced with the first byte of the first configuration DWORD. The next three states, BYTE2, BYTE3 and BYTE4, correspondingly source bytes 2, 3 and 4 of the configuration data DWORD. In state BYTE4, a DWORD counter is incremented. If the value of the DWORD counter exceeds the defined number of DWORDs to transfer, the state machine transitions back to the IDLE state. Otherwise, the BYTE1 state is entered to continue sourcing the next reconfiguration data DWORD onto the Select Map Bus.
In the experimental setup, the IOBs AH18, AJ18 and AL19 named A, B and C respectively, are connected to the CLB R54C33.S0 over the routing network, as shown in Figure 6. The logic dependencies between A, B and C are determined by the LUT in the CLB, which can be expressed as a truth table. During a partial reconfiguration, a bit in the LUT can be altered to cause a corresponding change in the truth table which relates the inputs A and B to the output C. Such a targeted partial change in the truth table is termed partial reconfiguration. Figure 6 illustrates an example of this.
Figure 6. Truth Table for the Inputs A,B and the Output C Figure 5. Finite State Machine of the Select Map Interface
6
System Test
The primary difficulty with partial self-reconfigurable systems stems from the fact that the logic which performs partial reconfiguration is located in the same chip that is to be reconfigured. In addition, a partial self-reconfiguration cannot be effectively simulated with current software tools. The system must therefore be tested as a hardware setup. A test of the hardware setup involves an understanding of the FPGA concept. An FPGA is constructed from arrays of CLBs (Configurable Logic Blocks), with each array surrounded by IOBs (Input Output Blocks). The connections between CLBs and IOBs are established by the programmable routing network [6]. Partial reconfiguration aims to change the logic of the device, where this logic is represented by CLBs and the interconnections between them. XILINX does not disclose information on how the routing network can be programmed, but detailed information is provided on the programming of CLBs [7, 8, 1, 2]. For this reason, the partial self-reconfigurable system was tested by changing the internal logic of one CLB. Basically, the logic operations carried out by a CLB are represented by an LUT (Lookup Table). This LUT associates the logic values of the input signals to that of the output signal of a CLB.
A frame contains the smallest amount of configuration data that can be written, with a single command, to the configuration logic of the FPGA. One frame of configuration data changes certain parts of a single CLB column. For this reason, it is essential to shut down complete CLB columns during partial reconfiguration. The FPGA Design overcomes constraints due to this limitation, by having a strict physical separation between the Fixed and Reconfigurable Parts of the FPGA. The locations of the logic and partitioning of the FPGA in this prototype implementation are shown in Figure 7. The border between the Fixed and Reconfigurable Parts lies between columns 71 and 72 The PCI interface must be located in the Fixed Part of the FPGA, because the SDR Device must be online and available at all times to answer queries from the PC. CLB R54C33.S0, IOBs AH18 AJ18 and AL19, and connections between the IOBs and the CLB are located in the Reconfigurable Part of the FPGA. These represent the logic described by the downloaded partial reconfiguration data. After power up, the FPGA is configured with both the Fixed Part and the Reconfigurable Part of the design. CLB R54C33.S0 represents an AND gate with inputs A and B and output C. Testing the partial self-reconfigurability of the system involves partly changing the truth table relating A, B and C. By applying the appropriate voltages at the inputs (A, B) and measuring the output (C), this change in the truth table can be verified.
0-7695-1926-1/03/$17.00 (C) 2003 IEEE
Table 1. Partial Configuration File
Figure 7. Partitioning of the Virtex XCV800 FPGA chip
6.1
Partial Reconfiguration File
The user initiates the process of partial selfreconfiguration by selecting a partial reconfiguration file via the User Application. This ASCII file contains all the information required for the FPGA Configuration Logic to perform a partial reconfiguration. In general, this file is partitioned into two sections: the header for the Select Map Interface, and the configuration bit stream. The header is simply the length, in bytes, of the configuration bit stream. The configuration bit stream itself can be split into three constituent parts. The first part sets up the Configuration Logic in the FPGA, carrying information such as an indication of partial reconfiguration, the number of frames to be written, and the part of the FPGA to be reconfigured. The second part is the configuration data itself. The last part issues the Configuration Logic with a command to start up the newly reconfigured part of the FPGA. To test partial self-reconfigurability of the system, a partial reconfiguration file was defined to alter the LUT bit number 13 of the CLB R54C33.S0 from logic 0 to logic 1. This change can be performed with a single command frame, but the configuration logic requires a PAD frame (consisting of only zeros) to follow the configuration frame. There are a total of 312 = 0x138h bytes in the configuration bit stream. This value is stored in the first DWORD of the file, as an indication to the Select Map Interface that 0x138h bytes have to be transferred. An extract of this configuration file is given in Table 1.
6.2
Logic Level Measurement of the Select Map Bus
The connection between the Select Map Interface and the Configuration Logic is established over a Select
DWORD Number 0
DWORD Value 0000 0138
1 2 3 4 5 6 7 8 ... 75 76 77 78
FFFF AA99 3000 0028 3000 0000 3000 0804 ... 0000 3000 0000 0000
FFFF 5566 2001 5A00 8001 0001 4044 0C00 0000 8001 0000 0000
Description Length in Bytes Header for the FPGA design Dummy Word Sync. Word Start CLB column for the reconfiguration Write Config. Data No. of DWORDS of Conf. data. First DWORD of Conf. data ... Last DWORD of Conf. data Close transfer with a Dummy Command Stuffing
Map Bus consisting of 8 data lines, a WRITE signal and a Chip Select Signal. The logic level measurement shown in Figure 8 captures the start condition, the dummy and synchronization DWORDs, and the first bytes of a command for the configuration logic. The time window displayed in Figure 8 has a duration of 1.2µs. Before the configuration data is transferred over the Select Map Bus it is ”byte-swapped”. [8] For that reason the Synchronization DWORD appears not as AA99 5566 but as 5599 AA66.
Figure 8. Measurement of the Select map bus
7
Conclusion and Future Work
This article has discussed the issues facing the design of a Computing Platform based SDR System, and presented an innovative system architecture that addresses these issues
0-7695-1926-1/03/$17.00 (C) 2003 IEEE
via the supervised partial self-reconfiguration of an FPGA. A test to verify a reconfiguration operation on the prototype system developed has been described. The protocol and data transfer structure as it stands at this time are not suitable for certain signal processing applications, such as SDR with downloaded telecom modules, because these applications require bidirectional data transfer. Correspondingly, the next step in development will be to improve on these structures and establish a mechanism that allows bidirectional data transfer over the PCI bus. Interfacing between the Fixed Part and the Reconfigurable Part of the FPGA will also have to be investigated in greater detail. This interface is complicated because a precise control of the placement of logic and interconnections is necessary.
8
Acknowledgements
We gratefully acknowledge the support and advice of Prof. Tim Spracklen, Mr. Chua Beng Koon and Dr. Lim Choo Min, and the funding support provided by the NgeeAnn Kongsi (Singapore).
References [1] N. Camilleri. Status and Control Semaphore Registers Using Partial Reconfiguration (XAPP153 Version 1.0). XILINX, June 1999. [2] Mark Ng, Mike Peattie. Using a Microprocessor to Configure Xilinx FPGAs via Slave Serial or SelectMap Mode (XAPP502). XILINX, January 2002. [3] W. Oney. Programming the Microsoft Windows Driver Model. Microsoft Press, 1999. [4] B. Stroustrup. The C++ Programming Language Special Edition. Addison-Wesley, 2000. [5] XILINX. The Real-PCI Design Guide V3.0, September 1999. [6] XILINX. The Programmable Logic Data Book 2000 Section: 3 Virtex Products. 2000. [7] XILINX. Virtex Series Configuration Architecture User Guide (XAPP151). September 2000. [8] XILINX. Virtex FPGA Series Configuration and Readback (XAPP138 Version 2.5). November 2001.
0-7695-1926-1/03/$17.00 (C) 2003 IEEE
