Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Design of a Reusable SpaceWire Link Interface for Space Avionics and Instrumentation Mark A. Johnson, Buddy Walls, Kristian Persson, Sandra G. Dykes, [email protected], [email protected], [email protected], [email protected] Southwest Research Institute 6220 Culebra Road San Antonio, TX 78230 (210) 522-2419 SpaceWire is an emerging network protocol designed to expand on-board spacecraft communications through use of a multi-hop, switched network architecture, supporting data rates from 2Mbps to 400Mbps. Based initially on IEEE 1355-1995, the electrical interface has been optimized for the rigors of spacecraft operations and adopted as standard ECSS-E-50-12A by ESA. With recent standardization of the protocol, attention can now be focused on development of SpaceWire hardware, including interface cards and network routers. This paper describes our approach and technical developments to provide radiation hardened SpaceWire solutions using the high performance CompactPCI (cPCI) bus. Driven by a combination of increasing mission throughput and aggressive processing requirements, the choice of the cPCI bus has fueled development of a new generation of SpaceWire hardware for space applications. For both immediate use in current on-board SpaceWire networks and to facilitate our research into hosting IP on these networks, we have developed a full duplex SpaceWire Link Interface Module (SLIM) interfacing on a 3U cPCI card. Our implementation incorporates two independent 64Kbyte FIFOs for SpaceWire link transmit and receive, a single SpaceWire link interface providing exchange level protocol support, and a programmable interrupt controller, interfacing with the cPCI Bus. A SwRI-developed cPCI target core was employed to provide increased transaction throughput tailored to the high bandwidth capabilities of the SpaceWire bus. Mark A. Johnson 1 #147 MAPLD 2005 TABLE OF CONTENTS 1. Introduction ............................................................................................................. 4 1.1 History................................................................................................................. 4 1.2 Data Network Structure ...................................................................................... 4 1.2.1 Space-based Data Networks ....................................................................... 4 1.3 Introduction to the SpaceWire Serial Bus ........................................................... 5 1.3.1 Physical Level ............................................................................................. 6 1.3.2 Signal Level ................................................................................................ 6 1.3.3 Character Level ........................................................................................... 6 1.3.4 Exchange Level ........................................................................................... 7 1.3.5 Packet Level ................................................................................................ 8 1.3.6 Network Level ............................................................................................ 8 1.4 Core Technologies .............................................................................................. 8 2. Project Objectives ................................................................................................... 8 3. Results and Findings ............................................................................................... 8 3.1 Hardware Design and Development ................................................................... 8 3.1.1 Development of a SpaceWire core ............................................................. 9 3.2 Design of the SpaceWire Link Interface Module (SLIM) ................................ 10 3.2.2 Design Details ........................................................................................... 12 3.2.3 SLIM Verification ..................................................................................... 14 4. References ............................................................................................................. 17 5. Bibliography ......................................................................................................... 17 Mark A. Johnson 2 #147 MAPLD 2005 List of Figures Figure 1. Figure 2. Figure 3. Figure 4. Figure 5. Figure 6. Figure 7. Figure 8. Figure 9. Layer Mapping between OSI and SpaceWire .................................................... 6 Data Character Format [2] .................................................................................. 6 Control Characters [2] ........................................................................................ 7 Link Interface Core Block Diagram [2] ............................................................. 9 SpaceWire Link Exchange Control State Machine [2] .................................... 10 Module Level Architecture............................................................................... 11 SLIM Module - Top ......................................................................................... 12 Slim Module - Bottom ...................................................................................... 12 SLIM Lab Test Setup ....................................................................................... 15 List of Tables Table 1. SLIM Prototype and Flight Equivalent Components ........................................ 12 Table 2. SLIM Performance Metrics ............................................................................... 17 ACRONYMS AND ABBREVATIONS cPCI COTS ECSS ESA FCT FIFO FPGA GSE IEEE IP LAN LVDS Mbps NASA PCB RTL SwRI SEL TID Mark A. Johnson Compact Peripheral Component Interconnect Commercial Off The Shelf European Cooperation for Space Standardization European Space Agency Flow Control Token First-in First-out Field Programmable Gate Array Ground Support Equipment Institute of Electronic and Electrical Engineers Internet Protocol Local Area Network Low Voltage Differential Signal Megabits per second National Aeronautical and Space Administration Printed Circuit Board Register Translation Logic Southwest Research Institute Single Event Latchup Total Ionizing Dose 3 #147 MAPLD 2005 1. Introduction 1.1 History One of the recent trends in spacecraft avionics architectures is the use of Local Area Networks (LANs) to distribute processing and data collection responsibilities. Various network topologies are currently under investigation to support not only intra-spacecraft LANs, but also spacecraft constellation networks and Earth-spacecraft network links. These technologies include traditional IP over Ethernet, SOIF (Spacecraft Onboard Interface), and several custom interfaces. One of the most promising interfaces is the new European standard, SpaceWire. The SpaceWire protocol was first developed by the European Space Agency (ESA) in the late 1990’s to provide a high-speed internal network for spacecraft. SpaceWire is intended as a common interface protocol designed to interface with not only spacecraft instruments and control systems, but also ground support and testing equipment. SpaceWire is a high performance serial bus, supporting data rates from 2Mbps to 400Mbps. Based initially on IEEE 1355-1995, the electrical interface has been optimized for the rigors of spacecraft operations and adopted as standard ECSS-E-50-12A by ESA. The intent of SpaceWire is to provide a unified, high performance data handling infrastructure, designed to meet the needs of future space missions. 1.2 Data Network Structure Traditional terrestrial data networks provide a communication system based on the layered ISO OSI protocol. The OSI model divides the complex task of host-to-host networking into layers. The seven layers that make up the OSI stack (listed highest level to lowest) are [1]: 1. Application 2. Presentation 3. Session 4. Transport 5. Network 6. Data Link 7. Physical One of the most common physical and data-link layer implementations is Ethernet. Ethernet employs a bus topology in which all devices or hosts on the network use the same shared communication lines. Data sent over Ethernet is automatically broadcast to all devices on the network. By comparing their Ethernet addresses against the address in the header of the data, each Ethernet device test each frame to determine if it was intended for them and reads of discards the frame as appropriate. 1.2.1 Space-based Data Networks Intra-satellite data networks are not a new concept. MIL-STD-1553B is a widely implemented serial data network used throughout the spacecraft community. In recent years, a number of NASA and ESA programs have extended the spacecraft data network concept to mimic the layered data networks found in terrestrial applications. Spacecraft Mark A. Johnson 4 #147 MAPLD 2005 wide Local Area Networks (LANs) are moving from the conceptual study phase, to design and implementation in the next generation of missions. The goals of including a packet-based LAN in spacecraft architectures are numerous, and include: a) Improved data collection and distribution for future science missions. Both Earth and space science missions plan to fly more and more sensors and have them interact to form a “Sensor Web” [1]. b) Enabling technology for distributed computing and system functions. Provides the seamless routing of data, remote file systems, and the ability to efficiently offloading processing and data analysis functions c) Ease of use. Industry standard that is known and used throughout the world. d) Leverages off of COTS technology. Allows industry knowledge base and R&D efforts to translate to space networks. The key to implementing a packet-based network within a spacecraft is the choice of a sufficiently robust and capable data and physical layer protocols. The rigors imposed by the harsh space environment limit not only the choice of electrical components, but require a level of error handling and fault tolerance. Several data-link and physical link protocols are being investigated to provide network connectivity within a spacecraft. These include IEEE-1394 “Firewire”, MIL-STD-1553B, I2C, and SpaceWire. SpaceWire has recently been standardized by ESA and has established itself as the defacto data interface on ESA missions. 1.3 Introduction to the SpaceWire Serial Bus SpaceWire provides a means for sending packet information from a source node to a destination node. The SpaceWire interface is a full duplex, point-to-point, serial data communication link. SpaceWire defines the method of data transfer, and the protocol required. It does not specify the contents of the actual packet information. The SpaceWire standard defines a multi-level interface. Each level is summarized in the following sections. SpaceWire differs slightly from the traditional OSI model. Figure 1 illustrates how SpaceWire maps to the traditions ISO OSI layered model. Mark A. Johnson 5 #147 MAPLD 2005 Application Layer Presentation Layer Session Layer Network Level Transport Layer Packet Level Network Layer Exchange Level Data Link Layer Character Level Physical Layer Physical Level ISO OSI Layer Model SpaceWire Layer Model Figure 1. Layer Mapping between OSI and SpaceWire 1.3.1 Physical Level The physical level defines the connectors, cables, cable assemblies, and printed circuit board impedances for implementing a SpaceWire interface. The standard interface cabling is twisted shielded pair of differential signals using a 9-pin micro-miniature Dtype connector. 1.3.2 Signal Level The signal level defines the electrical characteristics, signal timing, and voltage levels of the interface. SpaceWire uses Low Voltage Differential Signaling (LVDS) as the electrical interface. LVDS has the advantage of providing very high-speed data signaling, with good noise margin, using low differential voltage swings. Additionally defined at the signal level in the standard is the data encoding. SpaceWire uses the DataStrobe encoding specified in IEEE 1355-1995 and 1394-1995 (Firewire). 1.3.3 Character Level SpaceWire adopts the character level protocols in IEEE 1355-1994, and builds upon them to provide support for time tag broadcasts. SpaceWire defines two types of characters: Data and control. All serial information sent across a SpaceWire link falls in these two categories. As shown in Figure 2, data characters consist of 8 data bits, 1 parity bit, and a data / control flag which is set to 0 for data characters Figure 2. Data Character Format [2] Control characters are used to control the flow of information across a SpaceWire link, and to signal the occurrence of error conditions. Control characters contain only two bits of information, and are distinguished from data characters by a ‘1’ in the data-control flag Mark A. Johnson 6 #147 MAPLD 2005 position. Figure 3 provides a listing of the defined control characters. Two additional control “tokens” are defined (NULL and time-tag) by concatenating control characters. The NULL token is used as filler to keep the link active and serial data flowing when no data is actually being transmitted (no data or control characters). This gives SpaceWire based systems a mechanism to detect the loss of the link interface, and forward the status onto other hardware to attempt to re-establish the link. Figure 3. Control Characters [2] Parity protection is provided for both data and control characters. SpaceWire uses parity based on the previous 8 bits of data, or two bits of control characters. 1.3.4 Exchange Level The Exchange level is responsible for establishing a SpaceWire link, and managing the flow of information across the link. The exchange level consists of 5 distinct components: Initialization – Responsible for bringing the link out of reset and establishing a connection with the link at the other end of the channel. Verifies that each end of the link interface is able to send and receive data using a handshake protocol. Flow Control – Provides information across the link used to meter the flow of serial data from one end to the other. An interfacing system is only allowed to send data to a host system if there is local space in the hosts receive buffer for the data. The host (or receive interface) transmits this information as a flow control token (FCT), which indicates that it has room for 8 more data characters. A host may send multiple FCTs to indicate that it has extra room in it’s receive buffer. Detection of Disconnect Errors – Detects no data on the bus if no new data bits are received within the link timeout window (850nsec). Once detected, the link attempts to recover and re-establish communications. Detection of Parity Errors – Parity errors are detected based on the parity bit sent with a data or control character. Once detected, the link attempts to recover from this error and re-establish communications. Link Error Recovery – Used to recover from detected errors. The end of the link that detects the errors ceases transmission, and begins to restart the link using an “exchange of silence” protocol. Using a set of timeout conditions the link is reinitialized using the same handshaking called out in the initialization component. Mark A. Johnson 7 #147 MAPLD 2005 1.3.5 Packet Level The packet level protocol defines how data is encapsulated for transfer from source to destination. The protocol follows the same definition as IEEE 1355-1995. The packet format consists of a destination address, the cargo (or packet data field), and an end of packet marker. SpaceWire does not contain a sync marker or other start bit indicator. The first data character following an end of packet is regarded as the start of the next packet. 1.3.6 Network Level The SpaceWire network level defines what a SpaceWire network looks like, how packets are transferred and the overall interconnect of the nodes. Like other packet based networks, SpaceWire nodes are connected either directly, or via routing switches. The routing switches allow the link interfaces to pass packet data to any other link interface via a switching matrix. 1.4 Core Technologies The core technology to providing Internet connectivity in space is the selection of an appropriate physical and data layer, one which provides not only high performance, but is sufficiently robust for the rigors of space. Several candidate technologies exist, including IEEE 1394 (FireWire), MIL-STD-1553B, Ethernet, and SpaceWire. The choice of SpaceWire for investigation in this implementation is based not only on it’s high performance and robust nature (400Mbps LVDS interface), but also on it’s recent adoption as a formal standard by the European Space Agency (ESA). Numerous missions are already base-lining SpaceWire serial interfaces for science instruments as well as command and control systems. 2. Project Objectives The goal of this implementation is separated into two main components with respect to hardware design and development: a) Design and develop a re-usable SpaceWire logic core suitable for inclusion in spacecraft avionics and instrumentation. b) Design and develop a SpaceWire Link Interface prototype module for use in investigating the overall performance, capabilities and LAN applicability of SpaceWire. 3. Results and Findings 3.1 Hardware Design and Development The baseline hardware design concept was structured to produce two major deliverables. A re-usable Verilog based SpaceWire Link Interface core capable of being easily accommodated in existing radiation hardened FPGA’s. A proof of concept SpaceWire Link Interface Module (SLIM) that would be used to validate the SpaceWire Link Interface core, as well as a prototype for SpaceWire network Research. Mark A. Johnson 8 #147 MAPLD 2005 3.1.1 Development of a SpaceWire core The SpaceWire Link Interface core developed in this implementation provides both logic and control for both the transmit and reception of data via the link interface. The logic core is implemented using the Verilog hardware description language. A block diagram of the interface core is shown in Figure 4. Figure 4. Link Interface Core Block Diagram [2] 3.1.1.1 Transmitter The transmitter is responsible for encoding data and transmitting it using the data strobe encoding technique. The transmitter sends either data or control characters. These are generically referred to as N-characters in the SpaceWire context. The transmitter pulls data to be sent by the host interface from the FIFO. The transmitter sends N-characters only if the host system at the other end of the link (end B) has room in its receive buffer. This is indicated the link interface at end B sending an FCT, showing that it is ready to receive (or has room in it’s local buffering for) another 8 N-characters. The transmitter maintains a count of the number of FCTs it has received, and decrements the count every 8 N-characters. If the FCT count is zero, the transmitter does not attempt to send more N-characters, but transitions to sending NULL characters until the link and end B sends more FCTs indicating that it is ready for more data. 3.1.1.2 Receiver The receiver is responsible for decoding data strobe encoded serial data into the equivalent N-characters (data, or control) and storing them into the FIFO for retrieval by the host interface. The receive interface also receives FCTs, NULL, and Time Codes. Upon receiving an FCT, the receive interface instructs the transmit interface to increase its FCT count. NULL characters indicate an active link and are forwarded to the exchange control state machine. The receiver also manages error detection, flagging disconnect, parity, and escape errors. These errors are forwarded onto the exchange control state machine. Mark A. Johnson 9 #147 MAPLD 2005 3.1.1.3 Exchange Control State Machine The State machine controls the overall operation of the link interface. It provides for link initialization, normal operation and error recovery. The state machine is responsible for the protocol specified in section 1.3.4 and is represented by the state diagram shown below in Figure 5. Figure 5. SpaceWire Link Exchange Control State Machine [2] 3.2 Design of the SpaceWire Link Interface Module (SLIM) The SpaceWire Link Interface Module (SLIM) developed as the second hardware objective of this implementation, is a high performance cPCI module providing a dedicated system for the collection and distribution of SpaceWire data. The module implements the following SpaceWire protocol levels: physical, signal, character and exchange Level. The design goals of the module include: 1. A fully Independent SpaceWire Link Interface 2. Independent 16Kx9 transmit and receive FIFO interfaces for each link 3. Polled Data collection mode – SpaceWire data is read / written via cPCI target interface by an external initiator 4. Low Power operation (< 2 Watts) 5. 3U Form Factor 6. 3.3V, 33MHz, 32 bit fully compliant cPCI interface 7. Radiation performance of: a. Design goal of 100 KRads Total Ionizing Dose (TID) b. Design requirement of Single Event Latchup immune (SEL) 3.2.1.1 Module Architecture The cornerstone of the SLIM architecture is a re-usable, SpaceWire Link logic core, described in section 3.1.1. Each core implements the exchange level SpaceWire protocol Mark A. Johnson 10 #147 MAPLD 2005 and provides a single SpaceWire link interface. The design is partitioned in such a manner to take advantage of the increased capacity of flight quality FPGAs, and reduce overall board component density. 16K x 9 FIFO 8 8 8 3 Spacewire Link Core Spacewire Link Core 8 8 3 8 3 Spacewire Link Core LVDS Driver 16K x 9 FIFO 3 8 3 LVDS Receiver LVDS Driver LVDS Receiver 16K x 9 FIFO 3 8 LVDS Driver LVDS Receiver 3.2.1.1.1 Board Level Architecture Figure 6 illustrate the module level overall block diagram. For a given SpaceWire link interface, data is brought to / from the board through standard 9 pin DD connector. The data is routed through LVDS transmitters and receivers and onto the FPGA for processing through the SpaceWire Cores. The core logic is supported by a 16K x 9 FIFO on the board. The FIFO provides transmit and receive message buffering, allowing for the simultaneous storage of outgoing data and receipt of incoming data processed by the core. 8 Data Arbiter and DMA Controller 32 Interrupt Processing Logic 2 cPCI Core 2 cPCI / Spacewire Link FPGA 33MHz, 32bit cPCI Bus Figure 6. Module Level Architecture Figure 7 and Figure 8 show the final 3U cPCI SLIM prototype module. Mark A. Johnson 11 #147 MAPLD 2005 Figure 7. SLIM Module - Top Figure 8. Slim Module - Bottom One of the baseline goals set forth in this implementation was to architect the SLIM to provide a direct upgrade path to a flight equivalent module. Table 1 below provides a comparison of the major components used on the SLIM prototype with equivalent flight components. Table 1. SLIM Prototype and Flight Equivalent Components Part name Flight equivalent Description UT54LVDS031 5962F9583302QXA LVDS Driver UT54LVDS032 5962F9583402QXA LVDS Reciever A54SX72A 5962-0151506QYC FPGA IDT7206 HX6409TSHC FIFO LT1021 OMR9601 Voltage Regulator 3.2.2 Design Details The following diagram shows SLIM broken down into its two major interfaces, one for SpaceWire, the other for the CompactCPCI. A synchronous Local Bus was created to allow the two interfaces to operate together. 12 A/D PAR C/BE# FRAME# IRDY# DEVSEL# TRDY# STOP# P/S ERR# cPCI interface module Local Write Data Local Read Data Local Address Byte Enable [3:0] Chip Select Write Local Ready SpaceWire interface module Tx_S/D Rx_S/D Tx_FIFO_DATA Tx_FIFO controls Tx_FIFO status Rx_FIFO_DATA Rx_FIFO controls Rx_FIFO status Figure 10. Internal SLIM Modules 3.2.2.1 SpaceWire Interface The SpaceWire interface module handles the incoming and outbound serial data and all the controls needed to put the data in a format compatible with the cPCI process. To accomplish this, it is broken down further into the following modules: Rx Deserializer Clock generator from inbound RxS/D signals Parallel data created from inbound serial stream Control / Time Stamp / Data character recognition logic Error recognition logic Tx Serializer Serial data created from characters from Exchange State Machine / FIFOs Tx clock generator synchronous to outbound TxS/D signals Exchange State Machine as shown in Figure 5 FIFO control logic FIFO read/write control FIFO Credit counters that maintain flow-control w/respect to FCTs SpaceWire Control/Status registers Interrupt control/status Link enable Tx clock rate Packet/Buffer control/status 3.2.2.2 CompactPCI Interface The SLIM interfaces to a single board computer (SBC) via a cPCI backplane. The SLIM features the first application of the cPCI to local bus core, developed in a separate SwRI IR&D project. The SwRI cPCI core provides a standard Local Bus interface for onboard logic to the cPCI bus, and achieves a significant reduction in logic resources over commercially available cPCI interface cores. Configuration registers Address decode / ChipSelects generated via parameters Translation to standardized Local Bus 13 3.2.3 SLIM Verification Verification of the SpaceWire core was accomplished using a two-stage approach. Initial verification testing was performed through hardware simulation of the Verilog design using a complete board simulation model. This model provided detailed functional models of the FPGA, FIFOs, and cPCI bus. Validation of the design using an initial full board simulation model significantly reduced the number of problems found in later testing and reduced the overall hardware verification time. The second stage of the SpaceWire core verification was accomplished through hardware testing of the SLIM in a lab. 3.2.3.1 Hardware Simulation Verification Methodology This simulation process occurred in two phases; the first with an RTL version of the FPGA, the last with a back-annotated gate level version that was set up with worst / typical / best case timing delays. The test cases created were run against all versions of the FPGA mentioned previously. The test bench was created from the SLIM board schematic. All digital elements on SLIM (e.g. FIFOs, cPCI interface) were modeled with timings to generate realistic signal transitions, and to check for all possible timing violations. The test cases simulated the following: cPCI transactions with and without errors Tx checking with a modeled external Rx Rx checking with a modeled external Tx Loop-back mode where the Tx is wired to the Rx FIFO operations: normal and with under-runs and over-runs This simulation test bench was set up to track all error conditions and notify the user of any and all errors encountered. 3.2.3.2 SLIM Lab Test Configuration The lab test setup used for verifying SLIM and the overall performance of the SpaceWire core is shown below in Figure 9. The major components of the test setup include: Commercial CompactPCI chassis and Single Board Computer (SBC) VMETRO CompactPCI Bus Analyzer and Protocol Checker Card SwRI SLIM Commercial SpaceWire card from 4Links Agilent Logic Analyzer for detailed timing checks. 14 Figure 9. SLIM Lab Test Setup 3.2.3.2.1 GSE Test Software Development To facilitate testing and exercise the SpaceWire link, custom GSE test software was written to access the SLIM over the cPCI bus from the single board computer. The JUNGO WinDriver tools were used to generate the low level cPCI SLIM driver code and provide configuration and memory accesses to the SLIM. The GSE test software provided the ability, via a menu driven interface, to configure the SLIM, read and write to various control and status registers, load the SpaceWire transmit buffer provided by the card, as well as to read SpaceWire data received by the module. Full duplex SpaceWire data testing was accomplished using the GSE test software and the monitor code provided with the commercial 4Links SpaceWire card. The test code ensured that the SpaceWire link was correctly initialized, the data transmitted and received matched the intended results, and that the link could respond correctly to Null characters and flow control tokens (per the SpaceWire spec). 3.2.3.3 SLIM Functional Interface Testing 3.2.3.3.1 cPCI Bus protocol verification cPCI bus verification was accomplished using the GSE test software and VMETRO cPCI bus analyzer. Basic operation was verified by reading/writing to SLIM control registers via the GSE software. Validation of the cPCI bus protocol was accomplished using the VMETRO cPCI bus analyzer. The VMETRO analyzer provides a cPCI error check loop, which continuously monitors the cPCI bus traffic and ensures that all bus transfers conform to the cPCI protocol and 15 timing. All cPCI tests were successful, validating the SLIM cPCI bus interface, as well as the cPCI to local bus core produced. 3.2.3.3.2 SpaceWire interface The SLIM was designed to support transmission rates of 2-30 Mbps. The rate is controlled through the transmit rate register, which produces the output serial rate based on the 33MHz oscillator. The transmit rate is initialized to 10Mbps. A series of divisors from 0 to FF where written to the register and measured, verifying the correct output serial rate. Initial data testing of the SpaceWire interface was accomplished by connecting the SLIM to the commercial board and attempting to do 4 byte writes. The commercial card software continuously checks the SpaceWire serial link and displays any boards it detects as well as all data it receives via the link. Once basic communication between the two cards was established, a logic analyzer was connected to the SLIM to verify the correct output of a null character after a reset and re-enable. Figures 4 and 5 illustrate the initial output waveform upon power up and link activation, per the specification. Figure 11: SLIM initial output. Figure 12: Expected SLIM initial output. Verification of the transmit credit counter was accomplished via the logic analyzer. The individual serial stream was capture and inspected to verify the value contained in the transmit credit counter by inspecting the number of flow control tokens (FCTs) transmitted. Verification of the data transmission capabilities via the SpaceWire link was accomplished by using the GSE test software to generate a block of 64Kbyte data and write it to the transmit buffers on the SLIM. To further exercise the cPCI interface, the data writes were performed using a variety of D8, D16, and D32 writes. Following the completion of the writes to the transmit buffer, the link was enabled and the data correctly transmitted to the 4Links SpaceWire GSE card. There the data integrity checks were performed and the data content verified. Following this initial verification of the ability to the SLIM to correctly establish a SpaceWire link and transmit data, larger dataset testing was performed. This set of tests looped the SLIM transmit interface back onto its receive interface and performed loop-back testing with large data files. Again, all received data was checked for data content and integrity. Additionally, the ability to correctly respond and handle buffer overrun conditions were exercised in this 16 configuration, demonstrating the ability of the SLIM to respond to and correctly flag buffer overrun conditions. Time Code testing was performed using this same loop-back configuration. A function was added to the SLIM checkout software to write to the time tick register, which increments the time and transmits it over the SpaceWire link. Through the loop-back connection, the SLIM module would receive the time and validate that it correctly incremented. 3.2.3.4 SLIM Performance Summary Table 2 below details the overall performance metrics for the SwRI SpaceWire link and its initial implementation in the prototype SpaceWire Link Interface Module (SLIM). Table 2. SLIM Performance Metrics Item Overall Performance cPCI Bus 33MHz, 32 bit Average throughput of 16MBps SpaceWire Link 10Mbps – 30Mbps FPGA Utilization (based on A54SX72). Includes: Sequential: 650 out of 2012 (32%) SwRI cPCI Target SwRI SpaceWire Link Core Combinatorial: 1209 out of 4024 (30%) Total: 1859 out of 6036 (30.8%) It is important to realize the FPGA utilization includes the SwRI cPCI target core. The cPCI core consumes approximately 11% of an Actel A54SX72 FPGA. Factoring this in provides a total utilization of approximately 20% for each SpaceWire core, making it extremely space efficient. 4. Conclusions This IR&D program has successfully explored the capabilities of the SpaceWire serial protocol and the applicability of traditional Internet Protocol technology to it. Specifically, this IR&D has made the following accomplishments: Designed, developed and tested a re-usable SpaceWire Link Interface logic core providing full duplex spacewire serial communication. Designed, developed and tested a stand-alone CompactPCI SpaceWire Link Interface Module (SLIM), providing a complete SpaceWire link module for inclusion as part of SwRI’s SC-10 line cPCI computers. 17 Developed an Address Resolution Protocol for SpaceWire, leveraging IP technology to expand the applicability and scalability of SpaceWire based networks. Dramatically increased industry awareness through two papers accepted at major space avionics conferences. 5. References [1] K. Hogie, E. Criscuolo, R. Parise, “Link and Routing Issues for Internet Protocols in Space”, 2001 IEEE Aerospace Conference, Big Sky, Montana, March 2001 [2] ECSS-E-50-12A, “Space Engineering: SpaceWire – Links, nodes, routers, and networks”, ESA-ESTEC, January 2003 6. Bibliography Mark Johnson has over twenty-seven years experience in computer chip architecture, design, simulation, synthesis, documentation, debug, verification, release and hardware support. Since joining SwRI in September of 2001, Mr. Johnson has designed electronic subsystems for Deep Impact (DI), GLAST Burst Monitor (GBM), NPOESS Preparatory Project (NPP), and Orbital Express (OE). He has also performed in an advisory role for the REX design on the New Horizons project. Previous to joining SwRI, Mr. Johnson was a consultant for several firms including Lucent/Bell Labs, IBM, Cirrus Logic, Alcatel, NSC, AMD, and a few start-ups. He began his career with sixteen years at IBM designing microprocessor adapters. Mr. Johnson has a bachelor’s degree in mathematics and electrical engineering from the University of Vermont. Buddy Walls is a senior research engineer with Southwest Research Institute. Prior to joining SwRI, Mr. Walls worked on low bit rate speech coding as part of the recent Department of Defense Digital Voice Processing Consortium study. Since joining SwRI, he has developed custom hardware for the IMAGE, QuikSCAT, Coriolis, ROSETTA, and the Swift satellite missions. Mr. Walls is currently serving as deputy program manager for SwRI’s PCI / VME Bridge effort, and as technical lead for the Deep Impact System Control Unit. Mr. Walls has a Bachelors and Masters degree in electrical engineering from Oklahoma State University. Kristian Persson, while at Umeå University Mr. Persson, was involved with the building and characterization of the Mars Express electron spectrometer (ELS). Mr. Persson’s efforts involved redesigning the SwRI vacuum chamber control interface and software, as well as the characterization of the instrument itself. Since joining SwRI in June 2000, Mr. Persson has been responsible for the design and testing of the VME based Solar Array Switching Board (SASB) and General Purpose Switching Board (GPSB) of the Deep Impact mission. He was also part of the team responsible for the testing and verification of the completed Power Interface Control Unit (PICU) and the Remote Interface Unit’s (RIU) and served as the lead test engineer for the Deep Impact Space Craft Control Unit’s (SCU). Mr. Persson has an M.S in Space Technology from Umeå University Sweden. 18 Sandra G. Dykes, PhD has extensive experience in the area of computer networking and security, with an emphasis in protocol design, performance evaluation, and Internet infrastructure research. Prior to joining Southwest Research Institute in August 2001, Dr. Dykes was on the faculty of the University of Texas at San Antonio where she taught graduate and undergraduate courses. She is the author of numerous publications in leading IEEE conferences and journals, has served on NSF review panels for the Advanced Computational Research Program and the Information Technology Research Program, and frequently reviews articles for journals and technical conferences on communications and computer networks. While at Southwest Research Institute, Dr. Dykes has been involved in a variety of projects, including Internet attack traceback, ad hoc routing for mobile wireless devices, a DARPA project for adaptive scheduling on real-time systems, a remote imaging system to send high-resolution streaming video over an IP network, and network security for Web services. Her ad hoc routing research involves development of a middleware layer that enables a device to dynamically join and leave ad hoc networks based on application needs and performance metrics. Sandra has a PhD in Computer Science from the University of Texas. 19