Download johnson_paper

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