the compliancy with the new standard extensions, PID and. RMAP is still missing. ... Exchange, defining the protocol for link initialization, flow control, error ...
Router IP
radiation tolerant Networking
macrocell for
SpaceWire
Marco Tonarelli, Esa Petri, Sergio Saponara, Luca Fanucci Dept. of Information Engineering University of Pisa via Caruso 1-56122 Pisa, Italy Standard [1] is being integrated with two new chapters: RMAP (Remote Memory Access Protocol) [2] and PID (Protocol IDentification) [3]. In order to simplify the development of complex SpaceWire communication systems it is of paramount importance the availability of SpaceWire IP macrocells developed according to a proper design and verification methodology. The state-of-the-art is characterized by the implementation on radiation-tolerant devices of SpaceWire interfaces compliant with basic standard version. A SpaceWire router has been proposed [4] in Xilinx FPGA technology but is not compliant with the requirements of space missions. No SpaceWire router IP core for radiation tolerant technology is at present already available. Moreover, the compliancy with the new standard extensions, PID and RMAP is still missing. To overcome such limits in this paper we present the VLSI design of SpaceWire router and interface IP cores targeted on radiation-tolerant devices and proved in a space ESA project. The proposed router is compliant with the SpaceWire standard plus the RMAP and PID extensions. The rest of the paper is structured as follows: Section 2 briefly introduces the SpaceWire Standard; Section 3 presents the router and interfaces architectures; validation plan and physical implementation results are discussed in Section 4; finally, conclusions are drawn in Section 5.
Abstract-New scientific missions require the capability to handle large amount of data for earth observation, atmospheric sounding, planetary exploration. The European Space Agency recently proposed a serial data link standard, the SpaceWire (ECSS-E-50-12A), to facilitate the set up of onboard high-speed and reliable networks, to reduce system integration costs, to promote compatibility between equipment and to encourage the re-use of digital interfaces across different missions. To this aim this paper presents the VLSI design of configurable SpaceWire router and interface IP cores, the first in state-of-the-art compliant with the newest standard extensions Protocol IDentifier and Remote Memory Access Protocol. The IP cells have been integrated and tested on radiation-tolerant antifuse FPGA device by Actel, in the framework of an ESA space project. The achieved performances of 8 SpaceWire links routing, 100 Mbits/s datarate, 1.2 W power consumption, 300 Krad radiation tolerance meet the requirements of planned ESA space missions. The proposed SpaceWire IPs simplify the on board connectivity, provide network redundancy and guarantee to handle very high bandwidth data flows. I. INTRODUCTION In the last years the satellites design for telecommunications and scientific applications has risen deeply. This has showed the importance of a communication standard among all devices on board that can also allow a reuse of the Intellectual Properties (IP) and devices specifically projected for space applications to other aims and research areas. High-bandwidth instrumentations such as radars, image cameras, X-ray detectors, require a high datarate (up to hundreds of Mbits/s) backbone for on-board reliable communication. State-of-the-art standards for space/avionic communication such as MIL-STD-1553 or CAN provide a bandwidth below 1 Mbits/s whereas highspeed serial bus in consumer applications (e.g. FireWire) are not enough reliable for space. This recently led to the introduction by ESA (European Space Agency) of the standard for on-board SpaceWire high-speed communications to facilitate the integration and verification of embedded space systems and reduce the project costs. Several space missions in Europe, Japan and US planned the use of SpaceWire. At the present time the basic SpaceWire
SPACEWIRE STANDARD SpaceWire (SpW) is a bi-directional, full-duplex, pointto-point, high-speed, serial data communication link. It was born from the IEEE-1355 standard [5] and is based on an LVDS physical layer [6], resulting in a low-power highspeed link suitable for space applications. The Standard is defined at different levels of protocol [1]: Physical, taking into account cables and connectors; Signal, covering signal voltage levels, noise margins and signal encoding; Character, which adds the Time-Codes to the IEEE-1355 character level protocol, in order to support the distribution of system time. A basic SpW network is event-driven (e.g. like CAN) but through time-codes distribution timeII.
-
-
-
This work has been partially supported by ESA under contract n. 18780/04/NL/JA
1-4244-0157-7/06/$20.00 C2006 IEEE
221
answers) which allow a SpW network to be configured, SpW nodes to be controlled and data and status information from those units to be gathered. RMAP may operate alongside other custom protocols (with PID.1) running over SpW.
triggered communications can be set up (e.g. as in TTCAN) where a single node acts as time master while the others are time slaves; - Exchange, defining the protocol for link initialization, flow control, error detection and error recovery; - Packet, following the one defined in IEEE-1355; - Network, describing the structure of a SpW network, the routing techniques and the addressing schemes; it also defines network level errors and the correspondent error recovery protocols. A SpW network is made up of links, nodes and routing switches (i.e. routers). Information is sent in discrete packets from one node to another; nodes can be either directly connected by links or via routers to form a network. SpW packets are composed of characters: a group of 10 bits for data characters or 4 bits for control ones. A packet comprises a destination address, one or more characters and an end of packet control character. A SpW router is based on wormhole routing. Each packet contains a header holding the address of the destination node. When a packet is received, the router determines the output port to send the packet out of. If the requested output port is free, the whole packet is immediately routed to that port, otherwise the incoming packet is halted until the output port becomes free. The SpW router implements the following packetaddressing schemes: Path, Logical and Regional addressing. In Path addressing the destination address is specified as a sequence of valid output port numbers used to drive the packet across the network. At each routing switch passed through by the packet, a port identifier is stripped off (header deletion) in the destination address, so that the subsequent switch takes the routing decision upon the following port identifier. In Logical addressing each destination node has a unique logical address and each network router has a routing table binding each logical address with a physical output port. Regional logical addressing is based on logical addressing in conjunction with header deletion, allowing packet transfer across an arbitrary sized network. In regional logical addressing the routing table also holds information about the headers to delete or to keep, for each logical address. To guarantee path redundancy and tolerance to link failure Group adaptive routing is implemented. This is a means of routing packets to a requested destination over different paths through a network. Two or more output ports can be grouped together so that, if a link in the group is busy or unavailable due to hardware failure, a packet is sent through the next available link in that group. To define and standardize higher level protocol layers and so to increase the hardware and software compatibility among SpW systems, the PID has been introduced in 2005 [3]. The PID scheme enables many different protocols to operate concurrently over a SpW network without them interfering with each other. In the same year, the SpW Standard has been extended with the RMAP [2] to which PID=1 has been assigned. This high level protocol specifies procedures (read, write and read-modify-write commands) and command/data message formats (verified/not-verified, acknowledged/not-acknowledged, CRC type, error types and
III. DESIGN ARCHITECTURE The SpW router IP is a technology-independent VHDL macrocell providing a complete SpW routing and interfacing solution compliant with basic standard plus RMAP and PID extensions. As reported in Fig. 1 the router IP features a parametrizable number of SpW interfaces plus relevant switching matrix, a programmable router table, a dedicated decoder for RMAP, a time-code interface, a control/status interface and a data interface, all accessible by an external host through a 32-bit AHIB bus wrapper. All building blocks are detailed hereafter.
A. Sp W router core The SpW router core is a switching matrix connected to the external world via N SpW interfaces, one time-code interface, one control/status interface and one host data transfer interface. The VHDL model is parametric in terms of number of ports N, address intervals and size of receiving/transmitting buffers. The control/status interface provides a host unit read (for status check) and write (for configuration) access to internal registers of the SpW router and interfaces. The time-code interface distributes system time over SpW network. The router can be time master or time slave; in master mode the time-code interface provides SpW interfaces with time-codes either controlled by host or internally generated. The switching matrix and ctrl units in Fig. 1 connect an input port to any output port. Data transfer through the switch is accomplished after an arbitration phase which grants multiple requests at the same port with round robin priority. The routing table provides the physical address of the destination, header deletion flag and group information for Group adaptive routing. The SpW router is configured by the internal programming interface accessible via the switching matrix from the AHB or the SpW bus.
Router Core Arbiter
Route decoder Time-code Interface
c r
ctrl 2
x
Control
4_0
interface
0)
.C-cctrl N
""T
nternal
Program. nterface
ctrl Data
ml CD
Figure 1: Architectures of SpW router and interfaces
222
The RMAP decoder in Fig. 1 allows the hardware management of Remote Memory Access Protocol.
SpW Encoder-Decoder
Sp W interface Each SpW interface, whose architecture is sketched in Fig. 2, is composed of a SpW Encoder-Decoder (Codec) and a SpW I/0 wrapper. The SpW Codec is made up of three main parts: an encoder (or transmitter), a decoder (or receiver), and a finite state machine which implements the Exchange Level Protocol. The SpW I/0 wrapper connects the SpW Codec to the router core through transmitting (TX) and receiving (RX) FIFO. The SpW interface is also responsible for error detection and recovery at exchange level. To avoid receiver FIFO overflow and loss of data, data flow across a link is controlled using the flow control tokens (FCT) control characters [1]. Through FCT a SpW interface indicates to external transmitting link the amount of free space in its receiving FIFO.
SpW I/Owrapper
B.
Figure 2: Architecture of the SpW interface
internal prescaler two separate clock domains for the SpW TX interface and for the router are derived) and one for the AHB bus. A fourth clock domain, for the SpW RX interface, is automatically reconstructed as xor of the received data and strobe signals according to the signal level of the standard. Different run-time programmable TX data-rates (100, 50, 10, 5 Mbits/s) are supported by each SpW link.
C. AMBA AHB wrapper The AHB bridge in Fig. 1 is a wrapper between the router and the AHB AMBA bus (compliant with AMBA bus 2.0 [7]), a de-facto standard in embedded system design. This module can act as both master and slave on the AMBA bus. Moreover, it can ask the control of the bus to execute a DMA transfer into memory devices, or to initiate a SpW remote control session to a host system connected at AHB.
IV.
VALIDATION AND PHYSICAL IMPLEMENTATION
Validation plan Being a new IP macrocell, the SpW router has been tested at two levels: 1) test of the developed VHDL code using the ESA SpW IP Codec as reference link [10], see Fig. 3; 2) test of the FPGA prototyped router using as reference a commercial version of SpW links (a PCI-SpW card [11] in Xilinx FPGA featuring 3 unrouted SpW links) and a SpW link analyzer [11] provided by ESA, see Fig. 4. The first set of tests have been conducted on the VHDL code at functional, post-synthesis and post-fitting level of SpW router vs. the HDL SpW Codec provided by ESA [10].
A.
Integration ofthe SpWIP cells in ESA space systems The above IP cores have been used to build a complete SpW (router and interfaces) network solution within the ESA project IPPM (Integrated Payload and Processing Module), carried out by Aurelia Microelettronica (prime), Caen Aereospace and Consorzio Pisa Ricerche [8]. IPPM is a flexible, programmable and modular electronic system, able to operate as a real single board compact computer suitable for supporting requirements coming from scientific space missions. The processing and communication core of IPPM foresees a 100 MIPS LEON2-FT CPU enhanced by radiation tolerant FPGA module providing communication facilities at different bit-rates with the external world. To this aim CAN, MIL-STD-1553 and SpW devices are embedded in the FPGA chip, with on-chip communication based on AHB bus. High data-rate communications are based on the SpW standard. Starting from the aforementioned technology independent VHDL model an optimized router, compliant with IPPM specification, has been derived and targeted on radiation tolerant Actel Axcelerator technology [9]. IPPM needs a SpW router compliant with the standard with latest PID and RMAP extensions, also including 1 host time-code interface, 1 host control/status interface, 1 host SpW data interface, 9-port router (ports 1-8: 8 SpW links, port 9: host data interface). The IP cell can be master (for remote access to the host) or slave of the AHB bus and it implements DMA functionalities too. The router can be programmed via SpW links, by RMAP access or direct access to the internal programming interface, and via AHB bus. Two external clocks are required: one for the SpW bus (thanks to router
D.
|
AHB AMBA
|
AHB wrapper
t
Port 9
|SpWitff1 (byESA)
|
