ECSS Secretariat ESA-ESTEC Requirements & Standards Division Noordwijk, The Netherlands Space engineering

SpaceWire- Links, nodes, routers and networks

This Draft is distributed to the ECSS community for Public Review. START of Public Review: 24 November 2015 End of Public Review: 30 January 2016 DISCLAIMER (for drafts) This document is an ECSS Draft Standard. It is subject to change without any notice and may not be referred to as an ECSS document until published as such. This document is an ECSS Draft Standard. It is subject to change without any notice and may not be referred to as an ECSS document until published as such.

Foreword

This Standard is one of the series of ECSS Standards intended to be applied together for the management, engineering and product assurance in space projects and applications. ECSS is a cooperative effort of the European Space Agency, national space agencies and European industry associations for the purpose of developing and maintaining common standards. Requirements in this Standard are defined in terms of what shall be accomplished, rather than in terms of how to organize and perform the necessary work. This allows existing organizational structures and methods to be applied where they are effective, and for the structures and methods to evolve as necessary without rewriting the standards.

This Standard has been prepared by the ECSS-E-ST-50-12C Rev.1 WG Working Group, reviewed by the ECSS Executive Secretariat and approved by the ECSS Technical Authority.

Disclaimer

ECSS does not provide any warranty whatsoever, whether expressed, implied, or statutory, including, but not limited to, any warranty of merchantability or fitness for a particular purpose or any warranty that the contents of the item are error-free. In no respect shall ECSS incur any liability for any damages, including, but not limited to, direct, indirect, special, or consequential damages arising out of, resulting from, or in any way connected to the use of this Standard, whether or not based upon warranty, business agreement, tort, or otherwise; whether or not injury was sustained by persons or property or otherwise; and whether or not loss was sustained from, or arose out of, the results of, the item, or any services that may be provided by ECSS.

Published by:	ESA Requirements and Standards Division

ESTEC, P.O. Box 299,

2200 AG Noordwijk

The Netherlands

Copyright:	2015 © by the European Space Agency for the members of ECSS

Change log

Draft	Details
ECSS‐E‐50‐12A 24 January 2003	First issue.
ECSS‐E‐50‐12B	Never issued.
ECSS‐E‐ST‐50‐12C	Second issue. Editorial changes to conform with the new ECSS template and reorganization of information in clause 10.
ECSS-E-ST-50-12C Rev.1 DIR3 23 November 2015	Second issue, Revision 1 Complete rewriting of the standard that aims to be compliant to the previous issues, while making essential improvements and required additions. General improvement of terms and clauses in line with ECSS rules. Removal of errors and ambiguities throughout document. Clarifications of terms and inclusion of more terms in the list of terms. Improvement to the protocol layering and inclusion of a protocol stack diagram. Improvement to SpaceWire port architecture diagram. Improvements to physical level to allow other cable and connector solutions. Addition of recovery state diagram making the recovery operation clear. Detailing of multicast operation. Addition of distributed interrupts. Addition of UML diagrams and detailed descriptions of node, routing switch, network, broadcast code, unit and device. Addition of service interface specifications for all layers.

Table of contents

Change log	3

1 Scope	9

2 Normative references	11

3 Terms, definitions and abbreviated terms	13

3.1	Terms from other standards	13

3.2	Terms specific to the present standard	13

3.3	Abbreviated terms	23

3.4	Conventions	25

3.4.1	Numbers	25

3.4.2	Differential signals	25

3.4.3	Order of sending bits in symbols	25

3.4.4	Graphical representation of packets	26

3.4.5	State diagram notation	26

3.4.6	UML diagram notation	27

4 Overview of SpaceWire	29

4.1	Introduction	29

4.2	SpaceWire Spacecraft Data-Handling Network	29

4.2.1	The rationale for and brief history of SpaceWire	29

4.2.2	Example of SpaceWire application	30

4.2.3	How SpaceWire Works	32

5 General Requirements	38

5.1	Overview	38

5.2	Protocol stack and interface architecture	38

5.2.1	Protocol stack	38

5.2.2	Network layer	40

5.2.3	Data link layer	40

5.2.4	Encoding layer	41

5.2.5	Physical layer	41

5.2.6	Management layer	42

5.2.7	Service interfaces	42

5.2.8	SpaceWire port architecture	42

5.3	Physical layer	45

5.3.1	Cables	45

5.3.2	Connectors	47

5.3.3	Cable assemblies	50

5.3.4	PCB tracks	57

5.3.5	Line drivers and receivers	58

5.3.6	Data-Strobe skew	66

5.3.7	Physical layer management parameters	68

5.4	Encoding layer	68

5.4.1	Serialisation and de-serialisation	68

5.4.2	Character and control code encoding	69

5.4.3	Data strobe encoding and decoding	72

5.4.4	First Null	73

5.4.5	Null detection	74

5.4.6	Parity error	75

5.4.7	Disconnect	75

5.4.8	ESC error	75

5.4.9	Data signalling rate	75

5.4.10	Encoding layer management parameters	77

5.5	Data link layer	77

5.5.1	Data link layer interfaces	77

5.5.2	Data link layer management parameters	78

5.5.3	Sending priority	79

5.5.4	Flow control	79

5.5.5	Flow control errors	81

5.5.6	Link initialisation behaviour	81

5.5.7	Link error recovery	87

5.5.8	Accepting broadcast codes for sending	90

5.6	SpaceWire network layer	90

5.6.1	SpaceWire packets	90

5.6.2	Broadcast codes	91

5.6.3	SpaceWire time-codes	92

5.6.4	SpaceWire distributed interrupts	95

5.6.5	SpaceWire nodes	103

5.6.6	SpaceWire node management parameters	105

5.6.7	SpaceWire routing	105

5.6.8	SpaceWire routing switch management parameters	113

5.6.9	SpaceWire network	113

5.6.10	SpaceWire units	114

5.7	SpaceWire management layer	115

5.7.1	SpaceWire management layer services	115

5.7.2	Physical layer management parameters	115

5.7.3	Encoding layer management parameters	115

5.7.4	Data link layer management parameters	116

5.7.5	Network layer management parameters	116

6 Service Interfaces Requirements	117

6.1	Overview	117

6.2	Network layer service interface	117

6.2.1	Packet service interface	117

6.2.2	Time-code service interface	118

6.2.3	Distributed interrupt service interface	119

6.3	Data link layer service interface	122

6.3.1	N-Char service interface	122

6.3.2	Broadcast code service interface	123

6.4	Encoding layer service interface	124

6.4.1	Encoding service interface	124

6.4.2	Decoding service interface	125

6.5	Physical layer service interface	128

6.5.1	Line transmit service interface	128

6.5.2	Line receive service interface	129

6.6	Management layer service interface	129

6.6.1	Set parameter service interface	129

6.6.2	Get parameter service interface	130

Annex A (informative) Measurement of Data-Strobe Skew and Jitter	131

A.1	Introduction	131

A.2	Transmitter specifications	131

A.3	Cable assembly specifications	135

A.4	Receiver specifications	136

A.5	Maximum data signalling rate	137

Bibliography	139

Figures

Figure 11: The current family of SpaceWire standards: ECSS-E-ST-50-12C, ECSS-E-ST-50-51C, ECSS-E-ST-50-52C, ECSS-E-ST-50-53C	9

Figure 31: Convention for first bit to be sent	25

Figure 32: Graphical packet notation	26

Figure 33: State diagram style	26

Figure 34: UML notation	27

Figure 41: Example SpaceWire Architecture without redundancy	31

Figure 42 SpaceWire Packet Format	33

Figure 43 Path Addressing – driver analogy	35

Figure 44: Path Addressing – SpaceWire implementation	35

Figure 45 Logical Addressing – driver analogy	36

Figure 46 Logical Addressing – SpaceWire implementation	36

Figure 51: SpaceWire protocol stack according to the present document	39

Figure 52: Comparison of SpaceWire “layers” to ECSS-E-ST-50-12C “levels”	39

Figure 53: SpaceWire port architecture	44

Figure 54: SpaceWire connector with female contacts signal identification	49

Figure 55: SpaceWire cable assembly type A	53

Figure 56: SpaceWire cable assembly type AL	55

Figure 57: SpaceWire LVDS	59

Figure 58: LVDS line driver output signals	60

Figure 59: LVDS line driver differential output signal	61

Figure 510: LVDS receive signal eye pattern mask	66

Figure 511: Physical layer components	67

Figure 512: Data character encoding.	69

Figure 513: Control character encoding	70

Figure 514: Null control code encoding	71

Figure 515: Broadcast code encoding	71

Figure 516: Parity coverage	72

Figure 517: Data­Strobe (DS) encoding	72

Figure 518: Data and strobe signals for first Null	74

Figure 519: Null detection sequence	75

Figure 520: Link initialisation behaviour.	81

Figure 521: Link error recovery behaviour	88

Figure 522: Link error recovery process	90

Figure 523: Specialisations and relationships of a SpaceWire broadcast code	92

Figure 524 Network layer time-code	93

Figure 525: Network layer interrupt	96

Figure 526: Network layer interrupt acknowledgement code	97

Figure 527: Components and specialisations of a SpaceWire node	104

Figure 528: Components of a SpaceWire routing switch	107

Figure 529: Components of a SpaceWire network	114

Figure 530: Components and specialisations of a SpaceWire unit	115

Tables

Table 51: Insertion loss values to be respected for a cable	46

Table 52: Cable PSNEXT specification	46

Table 53: Cable PSELFEXT specification	47

Table 54: Connector with female contacts signal identification	49

Table 55: Cable assembly type A signal wire connections	53

Table 56: Cable assembly type AL signal wire connections	55

Table 57: Example calculation of maximum bit rate	68

Table 58: Address function	109

Scope

SpaceWire is a standard for medium-speed data communication links and networks for use on on-board spacecraft (ranging from 2 Mbps to about 1 Gbps). It covers roughly the Physical Layer and the Data-Link Layer of the Open System Interconnection (OSI) model (see Bibliography, [1]). In order to satisfy more complex needs from communicating applications, the SpaceWire standard (ECSS-E-ST-50-12C Rev.1) is complemented with higher level protocols such as the Remote Memory Access Protocol (ECSS-E-ST-50-52) that allows an Initiator to read or write from/to a Target memory block of which it knows the structure; and the CCSDS Packet Transfer Protocol (ECSS-E-ST-50-53) which allows carrying ECSS-E-70-41 packets (Ground systems and operations —Telemetry and telecommand packet utilization) within SpaceWire cargo; both of them following the SpaceWire protocol identification standard (ECSS-E-ST-50-51).

Figure 11 illustrates how the current family of SpaceWire standards (in green) can be used to connect communicating on-board applications (in brown) through some SpaceWire network, potentially making use of the so-called “Packet Utilisation Standard” (in purple).

Figure 11: The current family of SpaceWire standards: ECSS-E-ST-50-12C, ECSS-E-ST-50-51C, ECSS-E-ST-50-52C, ECSS-E-ST-50-53C

SpaceWire technology has grown from the needs of spacecraft on‐board data handling applications. This Standard provides a formal basis for the exploitation of SpaceWire in a wide range of on‐board processing systems.

One of the principal aims of SpaceWire is the support of equipment compatibility and reuse at both the component and subsystem levels. In principle, a data‐handling subsystem developed for an optical instrument, for example, can be used for a radar instrument by unplugging the optical sensor and plugging in the radar one. Processing units, mass‐memory units and down‐link telemetry equipment developed for one mission can be readily used on another mission, reducing the cost of development, improving reliability and most importantly increasing the amount of scientific work that can be achieved within a limited budget.

Integration and test of complex on‐board subsystems is also supported by SpaceWire with ground support equipment plugging directly into the on‐board data‐handling subsystem. Monitoring and testing can be carried out with a seamless interface into the on‐board elements and subsystems.

SpaceWire is the result of the efforts of many individuals within the European Space Agency, European Space Industry and Academia.

This standard may be tailored for the specific characteristic and constraints of a space project in conformance with ECSS-S-ST-00.

Normative references

The following normative documents contain provisions which, through reference in this text, constitute provisions of this ECSS Standard. For dated references, subsequent amendments to, or revision of any of these publications do not apply. However, parties to agreements based on this ECSS Standard are encouraged to investigate the possibility of applying the more recent editions of the normative documents indicated below. For undated references, the latest edition of the publication referred to applies.

ECSS-S-ST-00-01	ECSS system - Glossary of terms
ECSS-E-ST-50-51	Space engineering - SpaceWire protocol identification
ECSS-E-ST-50-52	Space engineering - Remote Memory Access Protocol
ECSS-Q-ST-70-08	Space product assurance - Manual soldering of high-reliability electrical connections
ECSS-Q-ST-70-26	Space product assurance - Crimping of high-reliability electrical connections
TIA-644-A:2012	TIA-644-A, Electrical Characteristics of Low Voltage Differential Signalling (LVDS) Interface Circuits, Revision A, Reaffirmed 12/07/12, Telecommunications Industry Association, 2012.
ESCC 3401/029:2010	Connectors, Electrical, Rectangular, Microminiature, based on type MDM, ESCC Detail Specification no. 3401/029, Issue 6, February 2010.
ESCC 3401/071:2010	Connectors, Electrical, Rectangular, Microminiature, Solder Bucket Contacts, with EMI Backshell based on type MDM, ECSS Detail Specification no. 3401/071, Issue 2, March 2010.
ESCC 3902:2002	Cables, Coaxial, Radio Frequency, Flexible, ESCC Generic Specification No. 3902, Issue 1 October 2002.
ESCC 3902/002:2010	Coaxial, triaxial and symmetric cables, flexible, -200 to +180 deg C, ESCC Detail Specification No. 3902/2002, Issue 3 September 2010.
ESCC 3902/003:2011	Cable, “Spacewire”, Round, Quad using Symmetric Cables, Flexible, –200 to +180 °C, Detail Specification no. 3902/003, Issue 3, August 2011.
ESCC 3902:1999	Connectors, electrical, non-filtered circular and rectangular; ESCC No. 340, is. 7 rev. B, April 1999.
MIL-DTL-17 J:2014	Military Specification: Cables, Radio, Frequency, Flexible and Semirigid, General Specification for, 10th February 2014.

Terms, definitions and abbreviated terms

Terms from other standards

For the purpose of this Standard, the terms and definitions from ECSS-S-ST-00-01 apply.

Terms specific to the present standard

The UML diagrams of Figure 523, Figure 527, Figure 528, Figure 529 and Figure 530 in clause 5.6 illustrate the relationships between various terms used within this standard.

after 6,4 μs

condition in which a delay of 6,4 μs is measured from when a state is entered

A 6,4 delay actually refers to a time interval as specified in requirement 5.5.6.1c

after 12,8 μs

condition in which a delay of 12,8 μs is measured from when a state is entered

A 12,8 delay actually refers to a time interval as specified in requirement 5.5.6.1d.

allocated output port

output port that a packet is to be routed through

AutoStart

management parameter set by hardware or software which, when asserted, causes an enabled SpaceWire port to start the SpaceWire link as soon as a Null is received

bit error rate

ratio of the number of bits received in error to the total number of bits sent across a link

broadcast code

time-code or distributed interrupt code

broadcast code identifier

two bit code that identifies the type of broadcast

A value of 0b00 identifies a time-code and a value of 0b10 identifies a distributed interrupt code.

byte

eight bits in which bit seven is the MSB

character

unit of information within the Data Link layer

A character can be a control character or data character.

coding

process through which a character is translated into a symbol

configuration node

node whose purpose is to configure the routing switch of the device it is part of

configuration port

port in a routing switch or node that gives access to a configuration node

control character

character used to pass control information across a link

Examples of control characters are ESC, FCT, EOP and EEP.

control code

sequence of an ESC followed by an FCT or by a data character

1	The sequence of an ESC followed by an FCT forms a NULL character (see definition in 3.2.77).

2	The sequence of an ESC followed by a data character forms a broadcast code 9 (see definition in 3.2.6.

control symbol

control character encoded in 4-bits for transfer across a link

data character

character used to pass data across a link

data link layer

protocol layer which is responsible for transferring packets and broadcast codes over a link, initialising the SpaceWire link, and managing the recovery from errors on the link

data rate

rate at which the application data is transferred across a link

data signalling rate

rate at which the bits constituting control and data symbols are transferred across a link

data­strobe

sequence of data bits and bit clock encoded into two signals, one containing the data bit sequence (data) and the other changing state whenever the data bit sequence does not (strobe)

data symbol

data character encoded in 10-bits for transfer across a link

decoding

act of translating an encoded set of bits back into the original set of bits prior to encoding

de­serialisation

transformation of a serial bit stream into a sequence of control or data symbols

destination address

series of data characters at the start of a packet and comprising path addresses, logical addresses or both

The first data character of the destination address of each packet is used by a routing switch to determine which port the packet is forwarded through within this switch.

destination node

node that is the destination of one or more SpaceWire packets

Disabled

management parameter which, when asserted, prevents a SpaceWire port from operating

Disabled is the inverse of Enabled.

disconnect

indication from a receiver that there has been no edge on the data or strobe signals for the past 850 ns indicating that the link is disconnected

A 850 ns interval actually refers to an interval as specified in requirement 5.4.7c.

distributed interrupt code

broadcast code used to distribute interrupts over a SpaceWire network

It is either an interrupt code or an interrupt acknowledgement code.

driver

electronic circuit that transmits signals across a transmission medium

Enabled

management parameter which, when asserted, allows a SpaceWire port to operate

Enabled is the inverse of Disabled.

encoding layer

protocol layer which is responsible for the encoding of characters into symbols, symbol serialisation, data-strobe encoding of the serial bit stream, data-strobe decoding, symbol de-serialisation and decoding of symbols into characters

end of packet marker

control character which indicates the end of a packet

end-point

interface between the network and a host system providing a single port into the network

error recovery scheme

method for handling errors detected within a SpaceWire link

ESC

control character which is followed by another control character or data character to form a control code

ESC error

an invalid ESC sequence, formed from an ESC followed immediately by an EOP, EEP or ESC

FIFO port

port that has a FIFO interface

first Null

initial Null received without a parity error when the link state machine is not in the ErrorReset state

flow control token (FCT)

control character used to manage the flow of data across a link

Each flow control token is exchanged for eight N-Chars.

gotBC

status flag indicating that, sometime after the first Null was received, a broadcast code has been received without a parity error

gotFCT

status flag indicating that, sometime after the first Null was received, an FCT has been received without a parity error

gotNchar

status flag indicating that, sometime after the first Null was received, an N-Char has been received without a parity error

gotNull

status flag indicating that, after the receiver has been enabled, the first Null has been received without a parity error

group adaptive routing

dynamic assignment of an output port within a set of several ports associated to a logical address

The group adaptive routing allows to a packet having a specific leading logical address, to be switched to one of the set of ports that is currently available to accept the packet or that becomes available first.

host interface

interface to a host system

host system

function that is connected to the SpaceWire network via an end-point and which uses the services of the SpaceWire network

input port

receive side of a port

interrupt acknowledgement code

code used to confirm that a distributed interrupt has reached the appropriate interrupt handler

interrupt code

code used to distribute an interrupt over a SpaceWire network

interrupt destination

node that receives and handles a distributed interrupt

interrupt handler

node that is responsible for handling an interrupt code with a specific value of interrupt identifier

interrupt identifier

5-bit value which identifies the particular interrupt being carried by the interrupt code or being acknowledged by an interrupt acknowledgement code

1	The 5-bit value represents one of 32 possible interrupts.

2	The interrupt identifier is held in the value field of an interrupt code.

interrupt relay register

register in a routing switch that holds the current state of the distributed interrupt

1	The ith bit of this register relates to the interrupt identifier of value i.

2	This register is used to prevent repeated circular propagation of distributed interrupt codes.

interrupt flag

state machine in a node which holds the current state of a distributed interrupt

interrupt source

node that generates a distributed interrupt

L-Char

link character

leading data character

very first data character sent over a link after initialisation or the first data character following the EOP or EEP that terminated the previous packet

line driver

electronic circuit that drives signals across a transmission medium

line receiver

electronic circuit that receives signals sent across a transmission medium

link

bi-directional connection between two ports used to transfer packets and broadcast codes between the two ports

link character

control character or control code which appears on the link only and is not passed between the data link and the network layer

FCT or Null are examples of link characters.

link error

a disconnect error, parity error, ESC error or credit error

link interface

see “port”(3.2.82)

link receiver

receiver at an end of a SpaceWire link

LinkStart

management parameter set by hardware or software which when asserted causes an enabled SpaceWire port to attempt to start the SpaceWire link by sending Nulls

link transmitter

transmitter at an end of a SpaceWire link

logical address

data character that belongs to the destination address of a packet and has a value greater than 311

1	A Logical Address is intended to be mapped into one or more of the maximum 32 output ports of a SpaceWire switch.

2	A common use case is to place a single logical address in the destination address, following a path address; then, this logical address identifies the destination node for the packet.

low voltage differential signalling

form of differential signalling using low voltage signals

management parameter

configuration parameter, control variable or status variable of a SpaceWire node or routing switch used to manage its operation

multicast

the sending of the same packet from a source node to two or more destination nodes or the sending of the same packet through two or more output ports of a routing switch concurrently

multicast set

set of output ports assigned to a logical address through which a packet with that logical address to be forwarded concurrently

N-Char

normal character

N-Chars are the component of packets.

network

two or more nodes connected together via one or more links and zero or more routing switches

A point-to-point link between two nodes is therefore regarded as a network.

network layer

protocol layer responsible for transferring packets across a SpaceWire network from source node to destination node via links and switches

The network level covers SpaceWire packets and broadcast codes, nodes and routing switches.

node

source or destination of SpaceWire packets and broadcast codes comprising one or more end-points

An example of SpaceWire node is the nominal (respectively redundant) electronic module of an instrument which has a redundant SpaceWire interface (i.e. two End-Points) to the spacecraft platform because these redundant interfaces connect the spacecraft platform to the same function, i.e. the nominal (respectively redundant) electronic module of this instrument.

normal-character

data character, EOP or EEP

Null

control code made up of an ESC followed by an FCT

The Null is sent to keep the data link active when there are no data or control characters to send, thus preventing a disconnect.

output port

transmit side of a port

packet

SpaceWire packet

path address

series of one or more data characters that belong to the destination address of a packet and have a value lower than 32

A path address data character of value N is mapped to output port N of a SpaceWire switch.

physical layer

protocol layer which specifies the cables, connectors, cable assemblies, line drivers and line receivers

port

SpaceWire interface or FIFO interface comprising an input port and an output port

The term “port” is synonymous with “link interface”.

receive error

error detected when receiving a symbol

A parity error is an example of receive error.

receive FIFO

FIFO memory which stores received N-Chars until they can be read by the application via the SpaceWire port interface

receiver

circuit that receives signals from the line receiver and decodes those signals into a stream of characters

router

see “routing switch”(3.2.87)

The term router is used because of the heritage of SpaceWire which is based on IEEE1355-1995 which is in turn based on earlier work on Transputer technology. This work predated the Internet and the use of the term router to mean a device that determines the route to a required destination as opposed to a switch that switches a packet to an output port based on an address. In SpaceWire the term router is used to mean a switch. This is widely understood terminology in the SpaceWire community.

routing switch

switching matrix connected to one or more SpaceWire ports and a configuration port and a local broadcast code register

1	A SpaceWire switch switches packets from one port to another. It optionally also broadcasts broadcast codes to all ports.

2	The term “routing switch” is synonym with “router”. In any case the use of the term router is deprecated throughout this standard.

switching table

table in a routing switch that is used to look-up the output port a packet is to be sent through

The leading data character of the packet is used as an index into the switching table.

serialisation

transformation of a sequence of control or data symbols into a serial bit stream

source node

node that is the source of one or more SpaceWire packets

SpaceWire cargo

information, coded as a series of data characters, encapsulated in a SpaceWire packet, and transferred from a source node to a destination node

SpaceWire interface

interface comprising a transmitter for sending information across a SpaceWire link, and a receiver for receiving information from that SpaceWire link

SpaceWire packet

sequence of normal­characters comprising a destination address, a SpaceWire cargo and an end of packet marker

SpaceWire port

port which has a SpaceWire interface

SpaceWire unit

unit which contains zero or more nodes, zero or more routing switches and at least one node or one routing switch

Examples of SpaceWire units are an instrument, a processor and a mass memory.

switching matrix

non-blocking, worm-hole switching function that switches a packet arriving at an input port of a routing switch to the appropriate output port

SpaceWire worm-hole arbitration policy is explained in the informative section 4.2.3.4.2.

symbol

encoded data character, encoded control character or encoded control code

time­code

code used to distribute synchronisation information over a Space Wire network

time-code master

host application on a node that is responsible for periodically sending out time-codes which are broadcast across the SpaceWire network

time-code master node

node on which the time-code master resides

This node, when requested by a time-code master, sends time-codes out of one or more end-points.

time-code register

register in a node or routing switch that holds the value of the last time-code received

time-code value

six bits of information contained in a time-code

transmit FIFO

FIFO memory which stores N-Chars until they can be sent across the link

transmitter

circuit that encodes the characters that are sent across a link, serialises them, data-strobe encodes them and passes the resulting data and strobe signals to line drivers

Abbreviated terms

The following abbreviations are defined and used within this standard:

Abbreviation	Meaning
AWG	American wire gauge
BC	broadcast code
BER	bit error rate
CLK	clock
D	data
DC	direct current
DMA	direct memory access
DS	Data­Strobe
ECSS	European Cooperation for Space Standardization
EEP	error end of packet
EOP	end of packet
EMI	electromagnetic interference
ESC	escape character
ESCC	European Space Components Coordination
FCT	flow control token
FIFO	first in first out
ID	identifier
IID	interrupt identifier
I/O	input/output
L­Char	link character
LS	least-significant
LSB	least significant bit
LVDS	low voltage differential signalling
LVTTL	low voltage transistor-transistor logic
Mbps	Megabits per second
MSB	most significant bit
N­Char	normal character
OSI	open system interconnection
ns	nanosecond
PRBS	pseudo-random bit stream
ps	picosecond
PSELFEXT	Power Sum Equal Level Far-End Cross-Talk
PSNEXT	Power Sum Near End Cross-Talk
RTC	remote terminal controller
RX	receive
S	strobe
SerDes	serialiser/de-serialiser
SpW	SpaceWire
TDR	time domain reflectometer
TX	transmit
UML	Unified Modelling Language

Conventions

Numbers

In this document hexadecimal numbers are written with the prefix 0x, for example 0x34 and 0xDF15.

Binary numbers are written with the prefix 0b, for example 0b01001100 and 0b01.

Decimal numbers have no prefix.

A set of contiguous bits in a word, indexed from bit i to bit j, with i greater than j, is written as (Bi:j).

Differential signals

The two signals making up a differential pair are given the suffixes + and – to indicate the positive and negative components of the differential signal, respectively.

The SpaceWire differential signals are referred to as D+,D- and S+,S- for Data and Strobe, respectively. When considering the driven end of a SpaceWire link these signals are designated Dout+, Dout- and Sout+ and Sout- for Data and Strobe, respectively. Similarly the signals at the input end of a SpaceWire link are Din+, Din- and Sin+, Sin-.

Order of sending bits in symbols

The first bit of a data symbol or of a control symbol to be sent first is the parity bit.

The data bits of a data symbol are sent least significant bit first.

An arrow is added to relevant diagrams to illustrate the direction that the data moves and which bit is sent first as shown in Figure 31

Figure 31: Convention for first bit to be sent

Graphical representation of packets

Packets and their component fields are represented graphically as shown in Figure 32. The arrow indicates the direction that the packet is travelling, so the destination address field is sent first.

Figure 32: Graphical packet notation

State diagram notation

State diagrams are used to represent the behaviour of several parts of the SpaceWire protocol. All state diagrams in this Standard use the style shown in Figure 33. States are represented by ellipses with the state name written inside the ellipse in bold. Actions to take while in a particular state are written in italics inside the ellipse underneath the state name. Transitions from one state to another are indicated by arrows. The event that causes a transition is written alongside the arrow. Unconditional transitions are indicated by arrows without an event name written next to it. Reset conditions are indicated by transition arrows that start in empty space.

Figure 33: State diagram style

UML diagram notation

UML diagrams in this document use the notation illustrated in Figure 34.

Figure 34: UML notation

Each entity (also called object) is shown as a rectangle divided in two by a horizontal line. The name of the entity is at the top above the line and a list of key attributes is below the line. Only those attributes that are considered relevant to understanding a diagram are shown, for example “Last Time-Code” in the Time-Code Register.

A diamond is used to represent aggregation and is translated as “is made up of”, hence in Figure 34 a node is made up of one or more (1..M) end-points and zero or more (0..M) time-code registers. The number at the end of the line shows the cardinality of the relationship and is either a number (e.g. 1) or a range (e.g. 1..M) with M representing more or many.

A triangle represents generalisation in one direction (reading in the direction the triangle is pointing) and specialisation in the other. So, in Figure 34, a destination node is a special type of node. Reading in the other direction, a node is a generalisation of destination node, source node and configuration node.

Other associations between entities are shown as lines connecting the two objects. A name capturing the intent of the association is written alongside the line. If the association is general, no name needs to be given to it. Hence, in Figure 34, each end-point is associated with zero or more time-code registers and each time-code register is associated with 1 or more end-points.

Nomenclature

The following nomenclature applies throughout this document:

The word “shall” is used in this Standard to express requirements. All the requirements are expressed with the word “shall”.

The word “should” is used in this Standard to express recommendations. All the recommendations are expressed with the word “should”.

It is expected that, during tailoring, recommendations in this document are either converted into requirements or tailored out.

The words “may” and “need not” are used in this Standard to express positive and negative permissions, respectively. All the positive permissions are expressed with the word “may”. All the negative permissions are expressed with the words “need not”.

The word “can” is used in this Standard to express capabilities or possibilities, and therefore, if not accompanied by one of the previous words, it implies descriptive text.

In ECSS “may” and “can” have completely different meanings: “may” is normative (permission), and “can” is descriptive.

The present and past tenses are used in this Standard to express statements of fact, and therefore they imply descriptive text.

Overview of SpaceWire

Introduction

SpaceWire allows building data-handling networks for use on-board spacecraft, which can connect together instruments, mass-memory, processors, downlink telemetry, and other on-board elements and sub-systems. SpaceWire provides high-speed (2 Mbps to about 1 Gbps), bi-directional, full-duplex data-links, which connect together SpaceWire enabled equipment. It delivers high-speed, low-power, simplicity, relatively low implementation cost, and its architectural flexibility makes it ideal for many space missions. Data-handling networks can be built to suit particular applications using point-to-point data-links and routing switches.

Since the SpaceWire standard was published by the European Cooperation for Space Standardization in January 2003, it has been adopted by ESA, NASA, JAXA and Roscosmos for many missions and is being widely used on scientific, Earth observation, commercial and other spacecraft. High-profile missions using SpaceWire include: Gaia, ExoMars, Bepi-Colombo, James Webb Space Telescope, GOES-R, Lunar Reconnaissance Orbiter and ASTRO-H.

SpaceWire has been developed in an extremely successful collaboration between ESA, academia and space industry, involving spacecraft engineers from across the world. This revision of the SpaceWire standard aims to correct errors, remove ambiguities and make clarifications to the previous version. It adjusts the SpaceWire protocol stack to make the layer interfaces clear and provides abstract service interface descriptions for each layer. Distributed interrupts are added to SpaceWire and time-codes are generalised into broadcast codes which comprise time-codes and distributed interrupt codes.

SpaceWire Spacecraft Data-Handling Network

The rationale for and brief history of SpaceWire

Before SpaceWire became a standard, many spacecraft primes and equipment manufacturers had to use ad hoc or their own proprietary interfaces for inter-unit communications, e.g. connecting high data-rate instruments to mass-memory units. This resulted in several different communication links being used on a spacecraft, increasing the cost and extending the time required for spacecraft integration and test. There was a clear need for a standard on-board communication link to simplify spacecraft development.

In 1992, when work on what became SpaceWire started, there was also substantial interest in high performance digital signal processing systems which were beyond the capability of the single-chip devices available at that time. The use of parallel processing was investigated and this required some form of network to interconnect the individual processing elements. The Inmos Transputer (see Bibliography, [2]), a microprocessor designed for parallel processing was studied, and the serial communication links being developed for the T9000 Transputer (see Bibliography, [3]) were identified as being an attractive solution for spacecraft on-board networking. This serial link technology was subsequently standardised as IEEE 1355-1995 (see Bibliography, [4] and [5]).

Several radiation tolerant devices were developed following the IEEE 1355-1995 standard and were used on some space missions. However, there were many problems with this standard, which had to be resolved if this technology was to continue to be used for ESA spacecraft. As from 1997, ESA started a stream of technology development to examine and solve these problems which resulted in the first public draft of the SpaceWire standard. After further work involving spacecraft engineers from across the world, this matured through several more revisions into the SpaceWire standard which was eventually published in 2003.

SpaceWire aims to:

facilitate the construction of high-performance on-board data-handling systems,

help reduce system integration costs

promote compatibility between data-handling equipment and subsystems, and

encourage re-use of data-handling equipment across several different missions.

Use of the SpaceWire standard ensures that equipment is compatible at both the equipment, sub-system and element levels. Instruments, processing units, mass-memory devices and down-link telemetry modules using SpaceWire interfaces developed for one mission can be readily used on another mission. This reduces the cost of development and reduces development timescales while improving reliability and maximising the amount of science and data return that can be achieved within a given budget.

Example of SpaceWire application

SpaceWire allows supporting many different payload processing architectures using point-to-point links and SpaceWire routing switches. The data-handling architecture can be constructed to suit the requirements of a specific mission, rather than having to force the application onto a restricted bus or network with restricted topology.

An example SpaceWire architecture is shown in Figure 41. In this example, two SpaceWire routing switches provide the interconnectivity between instruments, memory, processing units and I/O modules.

Figure 41: Example SpaceWire Architecture without redundancy

Instrument 1 in the top left-hand corner is a high data-rate instrument (e.g. producing data at a rate of 150 Mbps). A SpaceWire point-to-point link is used to stream data from this instrument directly into the Mass Memory Module. If a single SpaceWire link is insufficient to handle the data-rate from this instrument, two or more links can be used in parallel.

Instrument 2 is of lower average data-rate than instrument 1. Its data is passed through SpaceWire Routing Switch 1 to the Mass Memory Module.

Instrument 3 does not have a SpaceWire interface so an I/O module is used to connect the instrument to the SpaceWire switch. Its data may then be sent over the SpaceWire network to the Mass Memory Module.

Instrument 4 is a complex instrument containing a number of sub-modules which are interconnected using the CANbus. An RTC is used to bridge between the CANbus and SpaceWire. Other signals from the instrument are also connected to the RTC, which contains a processor for performing the bridging and local instrument control functions.

Instruments 5, 6 and 7 are located in a remote part of the spacecraft. To avoid having three SpaceWire cables running to this remote location a second routing switch (SpaceWire Routing Switch 2) is used to concentrate the information from these three instruments and send it over a single SpaceWire link to Routing Switch 1 and then on to the Mass Memory Module.

This Mass Memory Module can receive data from any of the instruments either directly, as is the case for Instrument 1, or indirectly via Routing Switch 1. Data stored in the Mass Memory Module can be sent to the Telemetry Formatter/Encryption Module for sending to Earth, or it may first be sent to a Data Processing or Data Compression Unit. This unit may return the processed/compressed data to the Mass Memory Module or send it straight to the Telemetry Module via Routing Switch 1.

The Control Processor is responsible for controlling all the Instruments, the Mass Memory Module and the Telemetry unit. The SpaceWire Network provides access to all these modules so that the Control Processor can configure, control and read housekeeping and status information from them. The Control Processor is also attached to the spacecraft control bus over which it can receive telecommands and forward housekeeping information.

With several instruments and the Data Processor/Compressor sending data to the Mass Memory Module via Routing Switch 1, a single link from that Routing Switch to the Mass Memory Module can be insufficient to handle all the data, so a second link has been added to provide more bandwidth. In a SpaceWire network links can be added to provide additional bandwidth or to add fault tolerance to the system. In Figure 41 no redundancy has been included for clarity. In a spaceflight application, an addition pair of routing switches are normally included with duplicate links to the modules to provide redundancy. It is straightforward to support traditional cross-strapped, redundant modules using SpaceWire.

How SpaceWire Works

General

Having looked at the way in which SpaceWire can be used to provide a spacecraft data-handling system, the present informative section examines SpaceWire in a little more detail to provide an understanding of how SpaceWire works before the normative clauses are presented in clause 5.

SpaceWire links

SpaceWire links are point-to-point data links that connect a SpaceWire node to another node or to a switch. Information can be transferred in both directions of the link at the same time. Each full-duplex, bi-directional, serial data link can operate at data-rates spanning between 2 Mbps and 200 Mbps. Each link sends information as a serial bit stream using two signals, data (D) and strobe (S), in each direction. TIA-644-A requires that both D and S signals are driven across the link using Low Voltage Differential Signalling (LVDS), by means of two wires for each signal: therefore a SpaceWire cable contains four screened twisted pairs.

Bit synchronisation in SpaceWire is achieved by sending a clock signal along with the serial data. To reduce the maximum clock to data skew requirements, the clock signal is encoded into a strobe signal in such a way that XORing the data and strobe signal recovers the clock signal. Data is transferred as a stream of elementary data and control characters. Character synchronisation is only performed once, when the link is started. Any loss of character synchronisation leads to parity errors, that are detected, so the link is restarted and the initial character synchronisation is recovered.

SpaceWire provides a simple mechanism for starting a link, keeping the link running, sending data over the link, ensuring that data is not sent if the receiver at the other end of the link is not ready for it, and for recovering from any errors on the link. All this is handled by a link state-machine in the SpaceWire interface and is transparent to the user application.

SpaceWire Packets

Information is transferred across a SpaceWire link in distinct packets. Packets can be sent in both directions of the link, provided that there is room in the receiver for these data.

A packet is formatted as illustrated in Figure 42.

Figure 42 SpaceWire Packet Format

The "Destination Address" at the beginning of the packet contains either the identity of the destination node or the path the packet has to take through a SpaceWire network to reach the destination node. In the case of a point-to-point link connection directly between two nodes (i.e. no routing switches in between), the destination address is not necessary.

The "SpaceWire cargo" is the data to be transferred from source node to destination node. An arbitrary number of data bytes can be transferred in the cargo of a SpaceWire packet.

The "End_of_Packet" marker is the last character in the packet. The data character following an End_of_Packet is the start of the next packet. There is no limit on the size of a SpaceWire packet.

As can be seen the SpaceWire packet format is very simple. It is, however, also very powerful, allowing SpaceWire to be used to carry a wide range of application protocols, with minimal overhead.

SpaceWire Networks

General

SpaceWire networks are constructed using SpaceWire point-to-point links and routing switches.

SpaceWire Switches

A SpaceWire switch connects together SpaceWire nodes using SpaceWire links, providing a means of switching packets from one SpW node to any of the other SpW nodes connected to this SpW switch, either directly or via other SpW switches. A SpW node is the source or destination of a SpaceWire packet. A SpaceWire switch comprises a number of SpaceWire link interfaces and a switching matrix. The switching matrix enables packets arriving at one link interface to be transferred to and sent out through another link interface on the switch.

Each link interface can be considered as comprising an input port (the link interface receiver) and an output port (the link interface transmitter). A SpaceWire routing switch transfers packets from the input port of the routing switch where the packet arrives, to a particular output port determined by the packet destination address. A routing switch uses the leading data character of a packet (one of the destination address characters) to determine the output port of the routing switch to which the packet is routed. If there are two input ports waiting to use a particular output port when the previous packet has finished being sent, an arbitration mechanism decides which input port is served first. The packet from the other input port is queued until the output port becomes available again. This arbitration policy for the packet flow control is known as “wormhole” switching and requires a very limited amount of buffer memory to be achieved, which enables a SpaceWire routing switch to be implemented in the radiation tolerant technology chip available at the turn of the century.

Packet Addressing

The destination address at the beginning of a SpaceWire packet is used to route the packet through a network from the source node to the destination node. There are two forms of addressing used in SpaceWire networks: path addressing and logical addressing.

Path addressing can best be understood using the simple analogy of providing directions to someone driving a car. To reach the destination, you could suggest that the driver takes exit 2 at the first road-junction, exit 1 at the next road-junction, and finally exit 3 on the third road-junction. The driver will then have reached the required destination (see Figure 43). There is a direction to follow at each road-junction (take a particular exit). Together these directions describe the path from the initial position to the required destination. There is a list of directions to follow: one for each road-junction. Once a direction has been followed it is dropped from the list and the next direction is followed at the next road-junction.

In a SpaceWire network the road-junctions are routing switches and the roads connecting the road-junctions are the links connecting the routing switches (see Figure 43). The list of directions is included in the beginning of the SpaceWire packet forming the destination address. The first direction is followed when the first routing switch is encountered. This direction is simply a data character that specifies which port of the routing switch the packet should be forwarded through. A routing switch can have a maximum of 31 external ports (port numbers 1 to 31) and one internal configuration port (port number 0). The leading data character at the beginning of the packet is used to specify the port that the packet is expected to be forwarded through: for instance, if the leading data character is 3, the packet is forwarded to port 3 of the switch. Once the leading data character has been used to forward a packet, it is removed as it is no longer needed. This makes the next data character first in the path address for routing the packet at the next switch. Figure 44 shows how the path address at the start of the packet is modified as the packet goes through the network. Since a routing switch can have a maximum of 31 ports along with an internal configuration port, each data character forming a path address is in the range 0 to 31.

Figure 43 Path Addressing – driver analogy

Figure 44: Path Addressing – SpaceWire implementation

Logical addressing can also be understood using the analogy of giving directions to a car driver. Logical addressing is like saying to the driver, “follow the signs to the City Centre at each of the road-junctions”. This, of course, requires appropriate signs to be placed at each road-junction and each destination has to have a name or identifier so that it can be recognised on the signs. The logical address analogy is illustrated in Figure 45.

In a SpaceWire network using logical addressing, each destination node is given an identifier, which is a number in the range 32 to 255. Each routing switch in the network has a switching table (like the sign at a road-junction) which specifies what port the packet should be forwarded through for each possible destination identifier. The leading data character of a packet is set to the required destination identifier (e.g. 44 for City Centre). At each routing switch the leading data character is used to look up the appropriate directions from the switching table and the packet is forwarded accordingly. For logical addressing the leading data character is not discarded at each switch, since it will be needed to look up the path to follow at the next routing switch encountered. The use of logical addressing is illustrated in Figure 46. Logical addressing uses just a single data character to identify the destination node which is in the range 32 to 255 so that it does not get confused with path addresses.

Figure 45 Logical Addressing – driver analogy

Figure 46 Logical Addressing – SpaceWire implementation

Logical addressing has the advantage that only a single address byte is required, but it does require the switching tables to be configured before it can be used. Path addressing requires a byte for each routing switch and does not depend on switching tables in the switches.

Time-Codes

SpaceWire time-codes provide a means of synchronising units across a SpaceWire system with low latency and low jitter. This time information is provided as “ticks”, based on an incrementing value that can be synchronized, e.g. to spacecraft time. The time-codes over the SpaceWire network have high priority, alleviating the possible need for a separate time distribution network.

General Requirements

Overview

The following clauses provide the normative aspects for SpaceWire. They are listed according to the respective functional layers.

Clause 5.2 describes the SpaceWire protocol stack and the architecture of a SpaceWire port.

Clause 5.3 specifies the physical layer of SpaceWire.

Clause 5.4 specifies the encoding layer of SpaceWire.

Clause 5.5 specifies the data link layer of SpaceWire.

Clause 5.6 describes the network layer of SpaceWire.

Protocol stack and interface architecture

Protocol stack

The SpaceWire protocol stack shall have the following layers:

network layer

data link layer

encoding layer

physical layer

management layer.

1	The SpaceWire protocol stack is illustrated in Figure 51.

2	A comparison of the “levels” in the ECSS-E-ST-50-12C to the “layers” of this current standard is provided in Figure 52.

3	To avoid confusion between the present standard and the old ECSS-E-ST-50-12C, the protocol stack is now structured in “layers” instead of “levels”. So throughout the present standard, only the term “layer” is used.

Figure 51: SpaceWire protocol stack according to the present document

Figure 52: Comparison of SpaceWire “layers” to ECSS-E-ST-50-12C “levels”

Network layer

The SpaceWire network layer shall provide any of the following services:

the packet service,

the time-code service, and

the distributed interrupt service.

A SpaceWire implementation may support the packet service.

A SpaceWire implementation may support the time-code service.

A SpaceWire implementation may support the distributed interrupt service.

The packet service, if implemented, shall send and receive packets over a SpaceWire network.

The time-code service, if implemented, shall send and receive time-codes over a SpaceWire network.

The distributed interrupt service, if implemented, shall send and receive distributed interrupts over a SpaceWire network.

The SpaceWire network layer shall accept service requests from User Applications.

The SpaceWire network layer shall transfer SpaceWire packets, time-codes and distributed interrupts over a SpaceWire network.

The SpaceWire network layer shall use the services of the SpaceWire data link layer.

Data link layer

The SpaceWire data link layer shall provide any of the following services:

the N-Char service, and

the broadcast code service.

A SpaceWire implementation shall always support the N-Char service.

A SpaceWire implementation may support the broadcast code service.

The N-Char service shall send and receive N-Chars over a SpaceWire link.

The broadcast code service, if implemented, shall send and receive broadcast codes over a SpaceWire link.

The data link layer shall accept service requests from the network layer.

The data link layer shall:

establish communications across the SpaceWire link,

manage the flow of information over the link,

send and receive N-Chars,

optionally send and receive broadcast codes, and

re-establish communications across the link after errors have occurred over the link.

The data link layer shall use the services of the SpaceWire encoding layer.

Encoding layer

The SpaceWire encoding layer shall provide the following two services:

the character encoding service, and

the character decoding service.

The character encoding service shall:

encode characters and control codes into symbols,

serialise the symbols, and

data-strobe encode the symbols ready for transmission over the SpaceWire physical layer.

The character decoding service shall:

recover the data bit stream from the data-strobe signals received from the physical layer,

de-serialise that bit-stream, and

decode the resulting symbols into characters and control codes.

The encoding layer shall accept service requests from the SpaceWire data link layer.

The encoding layer shall encode and decode characters into a form suitable for sending over the SpaceWire physical layer.

The encoding layer shall use the services of the SpaceWire physical layer.

Physical layer

The SpaceWire physical layer shall provide the following two services:

the transmit service, and

the receive service.

The transmit service shall transmit the data and strobe signals from the encoding layer over the physical medium.

The receive service shall receive the data and strobe signals from the physical medium and pass them to the encoding layer

The SpaceWire physical layer shall accept service requests from the encoding layer.

The SpaceWire physical layer shall transmit and receive the data and strobe signals over:

PCB tracks,

connectors, and

cable assemblies.

Management layer

The SpaceWire management layer shall provide two services:

the set parameter service, and

the get status service.

The set parameter service shall write control or configuration information into the other SpaceWire layers.

The get status service shall read the status or current configuration or control values of the other SpaceWire layers.

The SpaceWire management layer shall accept service requests from a management application.

The SpaceWire management layer shall configure, control and monitor the operation of the other SpaceWire layers.

The SpaceWire management layer shall have direct access to the relevant configuration parameters, control parameters and status parameters in the network layer, data link layer, encoding layer and physical layer.

Service interfaces

The service interfaces for each layer of the SpaceWire protocol stack are detailed in clause 6.

SpaceWire port architecture

The SpaceWire port shall comprise:

the SpaceWire port interface,

the transmit FIFO (TX FIFO),

the receive FIFO (RX FIFO),

the flow control manager,

the link state machine,

the transmitter,

the receiver,

the pair of line drivers, and

the pair of line receivers.

The SpaceWire port architecture is illustrated in Figure 53

The SpaceWire port interface shall include:

the packet transmit interface,

the packet receive interface,

the broadcast code transmit interface, and

the broadcast code receive interface.

The transmit FIFO (TX FIFO) shall store N-Chars provided by the user application via the SpaceWire port interface until they can be sent across the link.

The receive FIFO (RX FIFO) shall store received N-Chars until they can be read by the user application via the SpaceWire port interface.

The flow control manager shall manage the flow of data over the link, preventing data from being sent when there is no space for it in the receive FIFO.

The link state machine shall control the starting of a link and its recovery from errors.

The transmitter shall:

encode the characters to be sent over the link into symbols,

serialise the symbols into a bit stream, and

encode the bit stream into a data and strobe pair of signals.

The receiver shall:

decode the received data and strobe pair of signals into a data bit stream,

de-serialise thee bit stream into symbols, and

decode the received symbols into characters.

The pair of line drivers shall convert the data and strobe signals into LVDS or LVTTL signals for driving across the link.

The pair of line receivers shall receive the LVDS or LVTTL signals and recover the data and strobe signals that were driven across the link.

Figure 53: SpaceWire port architecture

Physical layer

Cables

Cables – general

The clauses from 5.3.1.2 to 0 specify the cable characteristics for SpaceWire. Cable assembly is specified in clause 5.3.3.

The rationale for the per metre values in Clause 5.3.1 is based on the hypothesis of a SpaceWire link of up to 10 m length at a bit-rate of 200 Mbits/s.

Cable construction

The SpaceWire cable shall carry four differential signals.

The SpaceWire cable shall comprise four screened twisted-pairs with an overall shield constructed according to ESCC 3902/003.

ESCC 3902/003 describes several variants of the SpaceWire cable to suit a range of spacecraft on-board applications.

Other forms of cable construction, with respect of those specified in requirement 5.3.1.2b, may be used provided that the cable characteristics fulfil the requirements in clause 5.3.1.3.

This permission, which is a relaxation of the requirement 5.3.1.2b, is to allow special forms of cable construction for specific applications.

Differential characteristic impedance

The characteristic impedance of each differential signal pair shall be (100 ±6) Ω.

The characteristic impedance of each differential signal pair shall be verified according to MIL-DTL-17J para. 4.8.7, using a time domain reflectometer (TDR) with a rise time of 150 ps or less.

Skew

The difference in delay of the two conductors forming a differential signal pair shall be less than 0,1 ns/m.

The difference in delay of the two conductors forming a differential signal pair should be less than 0,05 ns/ m.

0,05 ns corresponds approximately to 7 mm of difference in wire length. Skew gives rise to signal jitter but in a non-linear way which depends on the frequency at which it is measured. It is important that the in-pair skew is significantly less than the signal rise time. The minimum signal rise time for LVDS is 260 ns. For a cable assembly of 2,5 m the in-pair skew is half the rise time.

The inter-pairs skew for the four shielded, twisted pair cable shall be less than 0,1 ns/m.

This is straightforward to measure, unlike intra-pair skew. This gives rise to 1 ns skew for a cable of 10 m length.

The inter-pair skew for the four shielded, twisted pair cable may be more than 0,1 ns/m if the overall data-strobe skew budget of the cable assembly is compliant with the requirements stated in clause 5.3.6.

Insertion loss

The signal loss through each differential pair in the cable shall be according to the values provided in Table 51.

Table 51: Insertion loss values to be respected for a cable

Data rate (Mbps)	Frequency of the third harmonic (MHz)	Max. Insertion loss (dB/m)
10	15	0,27
100	150	0,45
200	300	0,65
400	600	0,94
NOTE: The attenuation values in the table concern the cable only and do not take into account the additional losses due to the connectors of a SpaceWire cable assembly.

PSNEXT and PSELFEXT

The SpaceWire cable shall conform to the PSNEXT and PSELFEXT values in Table 52 and Table 53 respectively.

Table 52: Cable PSNEXT specification

Frequency (MHz)	PSNEXT (dB)
100	73,0
500	63,5
1000	39,0

Table 53: Cable PSELFEXT specification

Frequency (MHz)	PSELFEXT (dB)
100	65,0
500	50,5
1000	41,5

Connectors

General

The connectors for the SpaceWire cable assembly shall be either Type A or Type B.

The Type A SpaceWire connector shall be a micro­miniature D­type connector with nine crimp or solder contacts, as defined in ESCC 3401/029 and ESCC 3401/071.

The Type B SpaceWire connector shall be a connector with the following characteristics:

contact pairs with differential impedance of (100 ±6) Ω,

compatible with ESCC 3902/003 cables or balanced cables in ESCC 3902/002, and

compatible with the space environment as defined in ESCC 3401.

The rationale behind this requirement is to allow various connectors to be used for SpaceWire provided that they meet the requirements 5.3.2.1a and 5.3.2.1b. This prevents a connector which has the wrong impedance, for example, from being considered as a SpaceWire connector. It is possible that several different connectors are all classed as Type B connectors, which is acceptable as the aim is to distinguish the Type A connectors from other connectors that have the correct electrical characteristics for SpaceWire. Other non-impedance matched connectors are possible but not recommended.

Connector with female contacts

Connectors with female contacts shall be used on circuit boards and unit assemblies to which SpaceWire cables are expected to be attached.

Connectors with female contacts that are attached to wire conductors shall:

directly solder or crimp the wire conductors to the contacts,

conform to ECSS-Q-ST-70-08 when conductors are soldered, and

conform to ECSS-Q-ST-70-26 when conducts are crimped.

The connection electrical resistance between a mated connector with male contacts and connector with female contacts shall be less than 10 mΩ at DC.

The connection between the mated connector with male contacts and connector with female contacts is a low broadband impedance connection. This is difficult to measure, but is ensured by the design of the interface between the body of the mated connector with male contacts and connector with female contacts.

The connection electrical resistance between the body of the connector with female contacts and unit ground should be less than 10 mΩ at DC.

The body of the connector with female contacts is connected to the board or unit chassis with a low broadband impedance connection. This is difficult to measure, but is ensured by the design of the interface between the body of the connector with female contacts and unit chassis.

The connector with female contacts should include a conductive gasket for EMI improvement.

On flight units, connectors with female contacts and flying leads should be used for connection to a PCB.

The rationale behind this recommendation is to improve robustness against mechanical shock and vibration compared to PCB mounting connectors.

Connectors with male contacts

Connectors with male contacts shall be used on cable assemblies.

The SpaceWire conductors shall be directly soldered or crimped to the contacts.

Soldering shall conform to ECSS-Q-ST-70-08.

Crimping shall conform to ECSS-Q-ST-70-26.

The outer shield of the SpaceWire cable shall be circularly terminated to the connector body via an EMI backshell.

The connection electrical resistance between the outer shield of the SpaceWire cable and the body of the connector with male contacts shall be less than 10 mΩ at DC.

A low broadband impedance connection is used connecting the shield to the body of the connector with male contacts in a cable assembly. This is difficult to measure, but is ensured by the design of the termination of the outer shield to the body of the connector with male contacts.

The inner shields of the SpaceWire cable shall be connected to the connector body by an impedance of less than 10 mΩ at DC.

Any pigtails used to connect the inner shields to the backshell shall be less than 1 cm in length.

Connector signal identification

Type A connector with female contacts

The signals in a connector with female contacts shall be identified according to Table 54 and Figure 54.

When type A connectors with female contacts are used to connect two cables, pin 3 shall be connected to the body of the connector.

Pin 3 of type A connectors with female contacts is connected to Circuit Ground also when used with type A cables. This is to prevent charge accumulation on a floating metallic in an environment of low density plasma of high energy electrons and protons.

Table 54: Connector with female contacts signal identification

Contact number	Signal name
1	Din+
2	Sin+
3	Circuit Ground
4	Sout-
5	Dout-
6	Din-
7	Sin-
8	Sout+
9	Dout+

Figure 54: SpaceWire connector with female contacts signal identification

Type A connector with male contacts

The signals in a connector with male contacts shall be identified according to Table 55 for type A cables and Table 56 for type AL cables Figure 54.

Type B connector

The assignment of signals to connector contacts shall be defined by the supplier.

The two signals in each pair of conductors (Din+ and Din-, Sin+ and Sin-, Dout+ and Dout-, Sout+ and Sout-) shall be assigned to adjacent pins of the connector.

No connector pin shall be connected to the cable shield.

If present, the outer shield of the cable shall be circularly connected to the connector body.

If the connector design allows it, the inner shields shall be circularly connected to the connector body.

PCB mounting connector

Flying lead connectors should be used for connection to a PCB.

Flying lead connectors used for connection to a PCB should have:

all the leads cropped to the same length of less than 25 mm, and

the wires comprising the differential signal pairs be twisted together.

This recommendation helps to minimize the discontinuity in impedance caused by the connector.

PCB mounting right‐angled connectors should not be used.

If a PCB mounting is used where one of the differential signal paths in the connector is longer than that of the related differential signal path, track length compensation shall be performed at the connector end of the PCB tracks to maintain the differential signal across the PCB.

1	For example, one of the differential signal path can be D+ and the related one is D-.

2	The reason for this requirement is that in a right angle connector the topmost row of pins on the right‐angled connector has longer leads than the bottom row.

Cable assemblies

Overview

The clauses from 5.3.2.2 to 5.3.3.5 specify the construction and the electrical properties of cable assemblies.

Connectors

Cable assemblies shall consist of:

two identical connectors of Type A with male contacts joined by a length of cable, or

two connector of Type B joined by a length of cable.

Cable assemblies may consist of:

a Type A connector with male contacts at one end, and

a Type B connector at the other end, and

a length of cable in between the two connectors.

Cable length and electrical performance

The maximum length of the cable assembly shall be determined by data to strobe skew, jitter, and signal attenuation.

1	The maximum length depends on the specification of the cable. For shorter length and when small bend radii are required, flexible cable can be used as long as the signal quality is according to clauses 5.3.5 and 5.3.6.

2	Longer length cables can be used at slow data signalling rates provided that the received signal levels and minimum edge separation timings are satisfied at the operating data signalling rate.

The maximum permitted inter-pair skew of a cable assembly should be less than 0,1 ns/m.

The maximum permitted inter-pair skew of a cable assembly shall be less than 1 ns.

This value corresponds directly to the contribution of the cable assembly to the data to strobe skew. This requirement permits cable assemblies of various lengths to be provided as meeting the requirement.

The maximum intra-pair skew permitted on a cable assembly shall be between -0,5 ns and 0,5 ns.

The maximum intra-pair skew permitted on a cable assembly should be between -0,1 ns and 0,1 ns.

It is important to specify the intra-pair skew so that slack manufacturing tolerances do not result in unacceptable performance of a cable assembly. It is important that the intra-pair skew is significantly less than the signal rise/fall time. The LVDS minimum rise/fall time is 260 ps. The specification of ±0,1 ns is approximately 40 % of 260 ps. At the cable level it is the maximum difference in length of the two signals that make up a differential pair that is measured (see clause 5.3.3.3). At the cable assembly it is the intra-pair skew that is measured as this is easier to do than with just a cable. This clause aims to limit the maximum skew of a cable assembly, so that one cable assembly can be replaced by another without adversely affecting signal quality. The desirable value of 0,1 ns intra pair skew corresponds to a length difference of around 15 mm.

The insertion loss through each differential pair in a cable assembly shall be less than 7 dB at frequencies up to 1,5 times the data signalling rate.

7 dB insertion loss corresponds to a signal of 250 mV dropping to approximately 110 mV when travelling one direction along the cable assembly, giving 10 % margin above the 100 mV threshold. For a 200 Mbps signal, the frequency at which the insertion loss is measured is 300 MHz.

Cable assemblies for type A connectors

General

Two types of standard cable assembly may use type A connectors: type A and type AL.Cable assembly type A

Cable assembly A shall use type A connectors and cable with an outer shield as defined in clause 5.3.1.2.

The connector contacts for cable assembly type A shall be terminated as shown in Figure 55 and Table 55.

The cable signal wires cross over to achieve the necessary transmit to receive interconnection, e.g. Dout+ is connected to Din+.

Figure 55: SpaceWire cable assembly type A

Table 55: Cable assembly type A signal wire connections

Signal at “connector A” end	Pin at A end	Connection/ No connection	Pin at B end	Signal at “connector B”end
A-Din+	1	- Connection -	9	B-Dout+
A-Din-	6	- Connection -	5	B-Dout-
A-Sin+	2	- Connection -	8	B-Sout+
A-Sin-	7	- Connection -	4	B-Sout-
Not connected	3	3	Not connected
A-Sout+	8	- Connection -	2	B-Sin+
A-Sout-	4	- Connection -	7	B-Sin-
A-Dout+	9	- Connection -	1	B-Din+
A-Dout-	5	- Connection -	6	B-Din-
A-Outer Shield	Shell	- Connection -	Shell	B-Outer Shield
A-braids of the 4 pairs	Shell	- Connection -	Shell	B braids of the 4 pairs

Pin 3 of the connector shall be left unconnected.

The individual shields of each of the four differential signal pairs shall be bonded to the connector shell via a low impedance connection of less than 10 mΩ.

A metal backshell shall be used for each connector to create, together with the outer shield, a continuous conductive barrier.

Its secondary purpose can be to facilitate the termination of the inner shields.

The outer shield of the cable shall be 360° terminated to the connector backshell via a low impedance connection.

The connection impedance between the main body of the connector and the backshell shall be less than 10 mΩ.

The differential far end and near end crosstalk (FEXT and NEXT) between any two pairs in the SpaceWire cable assembly shall be less than 20 dB up to 1 GHz.

Most of the crosstalk is due to the connectors when Type A connectors are used.

Cable assembly type AL

Cable assembly type AL should not be used for new designs.

Cable assembly type AL is the cable assembly specified in the previous issues of the SpaceWire standard, ECSS-E-ST-50-12C, prior to the current revision 1. The “L” in the “type AL” stands for “Legacy”.

Cable assembly AL shall use type A connectors and cable with an outer shield as defined in clause 5.3.1.2.

The connector contacts for cable assembly type AL shall be terminated as shown in Figure 56 and Table 56.

The cable signal wires cross over to achieve the necessary transmit to receive interconnection, e.g. Dout+ is connected to Din+.

Figure 56: SpaceWire cable assembly type AL

Table 56: Cable assembly type AL signal wire connections

Signal at “connector A” end	Pin at A end	Connection / No Connection	Pin at B end	Signal at “connector B”end
A-Din+	1	- Connection -	9	B-Dout+
A-Din-	6	- Connection -	5	B-Dout-
A-Sin+	2	- Connection -	8	B-Sout+
A-Sin-	7	- Connection -	4	B-Sout-
A- (Drains of pairs 5,9 and 4,8)	3	- No Connection -	3	B-(Drains of pairs 5,9 and 4,8)
A-Sout+	8	- Connection -	2	B-Sin+
A-Sout-	4	- Connection -	7	B-Sin-
A-Dout+	9	- Connection -	1	B-Din+
A-Dout-	5	- Connection -	6	B-Din-
A-Shield	Shell	- Connection -	Shell	B-Shield

The individual shields of the differential signal pairs carrying the output signals Dout+, Dout- and Sout+ and Sout- shall be connected together and to pin 3 of the connector at the transmitting end.

The inner shields shall be isolated from the outer shield.

The inner shields connected to pin 3 at one end of the cable assembly shall be isolated from the inner shields connected to pin 3 at the other end of the cable assembly.

A metal shell shall be used for each connector to provide necessary shielding of the connector.

The outer shield of the cable shall be bonded to the connector shell via a low impedance connection (less than 10 mΩ).

The metal shell shall be bonded to the main body of the connector via a low impedance connection (less than 10 mΩ).

The differential far end and near end crosstalk (FEXT and NEXT) between any two pairs in the SpaceWire cable assembly shall be less than -20 dB up to 1 GHz.

Most of the crosstalk is due to the connectors.

Cable assembly type B

Cable assembly type B is a supplier defined cable assembly which uses matched impedance connectors.

Cable assembly type B shall use type B connectors and cable with an outer shield as defined in clause 5.3.1.2.

Cable assembly type B may use type B connectors and another form of cable with the following properties:

differential impedance of (100 ± 6) Ω,

compatibility with ESCC 3902/003 cables or balanced cables in ESCC 3902/002,

compatibility with the space environment as defined in ESCC 3401.

The individual shields of each of the four differential signal pairs shall be bonded to the connector shell via a connection having an impedance of less than 10 mΩ.

A metal backshell shall be used for each connector to create, together with the outer shield, a continuous conductive barrier.

The secondary purpose for creating a continuous conductive barrier using a metal backshell is to facilitate the termination of the inner shields.

The outer shield of the cable shall be 360° terminated to the connector backshell via a low impedance connection.

The connection impedance between the main body of the connector and the backshell shall be less than 10 mΩ.

The differential far end and near end crosstalk (FEXT and NEXT) between any two pairs in the SpaceWire cable assembly shall be less than 50 dB up to 1 GHz.

Although mostly due to the connectors, the crosstalk specification takes into account the contribution of the cables and of the connectors.

PCB tracks

LVDS PCB tracks

When using LVDS signals, the PCB tracks shall be differential tracks with a differential impedance of (100 ± 6) Ω.

The difference in length between the two tracks forming a differential pair shall be less than 3 mm.

3 mm corresponds to approximately 20 ps difference in delay which is less than 10 % of the rise or fall time of the LVDS signal, so this difference in length has an insignificant effect on the differential signal.

The difference in length between the pair of tracks used for data and the pair of tracks used for strobe shall be less than 5 mm.

5 mm corresponds to a data-strobe skew of approximately 33 ps, which is small compared to the other skew factors, while being straightforward to achieve with PCB layout.

The use of vias for LVDS PCB tracks should be minimized.

The distance from an external termination resistor to the inputs of a line receiver should be kept as short as possible and less than 20 mm.

20 mm corresponds to the distance travelled by the signal during its rise/fall time. The minimum LVDS rise/fall time is 260 ns which corresponds to around 38 mm. The 20 mm recommendation is half of this value.

LVTTL PCB tracks

When using LVTTL signals, the PCB track shall have an impedance of (50 ±5) Ω.

This impedance range does not guarantee correct operation when the PCB track is interrupted by connectors, unless those connectors are 50 Ω matched impedance. When connectors that are not matched impedance are used, reflections can occur that can degrade the signal.

When running over PCB tracks which are longer than the product of the rise/fall time of the LVTTL signal times the speed of propagation of the signal along the tracks, the source impedance of the LVTTL driver shall be matched to the line impedance.

1	Matching the LVTTL driver to the line impedance is usually done by adding a series resistor close to the signal source or parallel termination close to the signal destination.

2	A PCB track of length 50 mm corresponds to a delay of around 333 ps which is a typical minimum value for the rise and fall time of the LVTTL signal.

If a PCB track is used to connect a SpaceWire interface to a nominal and redundant pair of line drivers/receiver, one or other of the following two approaches should be used:

first approach: the track lengths from driver to all sources is kept less than 50 mm;

second approach: the line driver/receiver devices are placed close together and the following methods applied:

the signals to the driver are terminated at the source with a source termination resistor and the PCB track run to the closest driver device and then on to the further driver device.

the PCB tracks carrying the signals from the receivers are each run to a source termination resistor as close as possible to and equidistant to the two receivers and then the other side of the source termination resistor run to the SpaceWire interface device.

The difference in length between the PCB track used for data and the track used for strobe shall be less than 5 mm.

Line drivers and receivers

General

SpaceWire shall use LVDS or LVTTL signals for transferring data.

SpaceWire may use other forms of line driver and line receiver, provided that:

connectors are different, and

the type of line driver and line receiver are documented in detail.

Justification of requirement: Different type of connectors are required when non-LVDS line drivers/receivers are being used to prevent inadvertent connection of other drivers/receivers to an LVDS driver/receiver which can damage the LVDS driver/receiver.

LVDS

General

Low voltage differential signalling or LVDS as specified for a point-to-point link in the TIA-644-A standard shall be used for driving SpaceWire data and strobe signals over SpaceWire cable assemblies, as illustrated in Figure 57.

1	LVDS uses balanced signals to provide very high-speed interconnection using a low voltage swing (350 mV typical). The balanced or differential signalling provides adequate noise margin to enable the use of low voltages in practical systems. Low voltage swing means low power consumption at high speed. LVDS is appropriate for connections between boards in a unit, and unit to unit interconnections over distances of 10 m or more depending on the data signalling rate. For longer cables the maximum achievable data rate is lower.

2	The TIA-644-A standard describes the way in which the specifications can be measured and verified.

SpaceWire using LVDS line drivers and line receivers shall be referred to as SpW-LVDS.

Figure 57: SpaceWire LVDS

LVDS transmit signals

When terminated, for measurement purposes, by two (50 ±0,5) Ω termination resistors in series forming the required (100 ±1) Ω termination impedance, the two outputs of the LVDS line driver (Out+ and Out-) shall have a common mode voltage, Vcm, measured at the junction of the two (50 ±0,5) Ω termination resistors, in the range (1,125 to 1,45) V, as illustrated in Figure 58.

This requirement is to permit use of drivers which have slightly higher Vcm than the TIA-644-A specification permits, i.e. 1,375 V.

When terminated, for measurement purposes, by a (100 ±1) Ω termination resistor, the two outputs of the LVDS line driver (Out+ and Out-) shall have amplitude, Vtx, in the range (+250 to +450) mV, as illustrated in Figure 58, and a differential amplitude (Out+ minus Out-) of 2 Vtx, as illustrated in Figure 59.

1	Figure 4 of TIA-644-A includes two 3,74 kΩ resistors in the test circuitry which simulate multiple line receivers connected to the line driver. These are not necessary when testing SpaceWire LVDS because the SpaceWire link is point-to-point NOT multi-drop.

2	A higher value of Vtx, within the specified range, allows longer cable lengths, see clause 5.3.5.2.3.

Figure 58: LVDS line driver output signals

If a logic 1 is expected to be transmitted, +Vtx shall be greater than –Vtx.

If a logic 0 is expected to be transmitted, +Vtx shall be less than –Vtx.

The steady state difference in magnitude of the common mode voltage, Vcm, when transmitting a logic 1 compared to when transmitting a logic 0 shall be less than 50 mV.

The steady state difference in magnitude of +Vtx or –Vtx when transmitting logic 1 compared to when transmitting logic 0 shall be less than 50 mV.

The differential output of the line driver, Out+ - Out-, shall rise and fall monotonically with a rise time (Tr) and fall time (Tf) of at least 260 ps and less than 0.3 times the bit period (T), as illustrated in Figure 59.

The differential output of the line driver, Out+ - Out-, shall have a rise time in the range from 20 % to 80 % of the difference between the two steady state values.

The differential output of the line driver, Out+ - Out-, shall have a fall time in the range from 80 % to 20 % of the difference between the two steady state values.

Requirements 5.3.5.2.2g, 5.3.5.2.2h and 5.3.5.2.2i correspond to clause 4.1.4 of TIA-644-A.

The differential output of the line driver, Out+ - Out-, should rise and fall monotonically with a rise time (Tr) and fall time (Tf) of less than 3 ns.

The 3 ns limit is an additional recommended constraint to TIA-644-A so that for slow data rates the edge speed is sufficiently fast to ensure correct operation of the line receiver in a noisy environment.

Ringing on the differential output of the line driver, Out+ - Out-, shall not be between -0,4 Vtx and 0,4 Vtx.

This is illustrated in Figure 59, which shows the same information as TIA-644-A Figure 8, but referenced to 0 V differential, rather than the minimum steady state signal.

Figure 59: LVDS line driver differential output signal

The maximum dynamic difference in magnitude between +Vtx or –Vtx shall be less than 150 mV.

This requirement corresponds to TIA-644-A requirement 4.1.5.

LVDS line receiver characteristics

The receive signals shall be terminated by a (100 ±10) Ω termination resistor.

The nominal impedance is 100 Ω and TIA-644-A allows up to 10 % variation from this nominal value.

The receive signals should be terminated by a (100 ±1) Ω termination resistor when an external termination resistor is being used.

This reduces reflections from the termination resistor and most surface mount resistors are now 1 % tolerance.

The SpaceWire LVDS line receiver input characteristics and sensitivity shall be as defined in TIA-644-A.

A differential signal greater than +100 mV shall result in logic 1 at the line receiver output.

1	A differential signal greater than +100 mV means that +Vrx is greater than –Vrx by more than 100 mV.

2	The common mode voltage plus or minus the differential voltage is required to be always in the range 0 V to +2,4 V, as specified in clause 5.3.5.2.3g This corresponds to clauses 4.1 and 4.2.4 of TIA-644-A which define the signal sense and the receiver sensitivity respectively.

A differential signal less than -100 mV shall result in logic 0 at the line receiver output.

A differential signal lower than -100 mV means that +Vrx is less than –Vrx by more than 100 mV. This corresponds to clauses 4.1 and 4.2.4 of TIA-644-A which define the signal sense and the receiver sensitivity respectively.

The line receiver shall maintain correct operation for differential input voltages of up to 600 mV magnitude.

This corresponds to the maximum permitted receiver differential signal in clause 4.2.4 of TIA-644-A.

The line receiver shall tolerate a voltage on the receiver inputs in the range 0 V to +2,4 V relative to the line receiver ground and operate correctly.

The line receiver is able to operate correctly with a common mode voltage of +0,05 V to +2,35 V when the differential signal is at ±100 mV and with a common mode voltage of +0,3 V to +2,1 V when the differential signal is at ±600 mV. This is as defined in clause 4.2.4 of TIA-644-A.

The line receiver should operate correctly in case a voltage on the line receiver inputs exceeds the range 0 V to +2,4 V relative to the line receiver ground.

This recommendation is to have a line receiver more tolerant to voltage difference in the grounds between the line driver and the line receiver.

Potential difference between two ends of SpaceWire link

The maximum potential difference between the local ground at one end of a SpaceWire link and the local ground at the other end of that SpaceWire link shall be between -1 V and 1 V.

1	This corresponds to TIA-644-A clause 5d.

2	The common mode voltage can be greater than expected when there is a potential difference between the grounds of the equipment at either end a SpaceWire link. This can damage the LVDS line receiver.

3	The TIA-644-A standard provides limited common mode voltage and many devices can be damaged if the voltage on their pins is less than -0,3 V or more than 3,9 V, see requirements 5.3.5.2.5j and 5.3.5.2.5k. It is recommended to use LVDS line receivers with wider common mode voltage tolerance than provided by TIA-644-A.

Fail safe operation of LVDS

The LVDS line driver and line receiver circuits shall not be damaged when powered or not powered under the following conditions:

transmitter outputs are open circuit;

transmitter outputs are shorted together;

transmitter outputs are shorted to local ground;

receiver inputs are open circuit;

receiver inputs are shorted together;

receiver inputs are shorted to local ground.

When either or both of the line driver outputs are short circuited to ground the current out of each of the outputs shall be less than 24 mA.

When the two line driver outputs are short circuited to each other the current flowing between the two outputs shall be less than 12 mA.

If a noise threshold of 10 mV is not exceeded at the line receiver input, the line receiver outputs shall not oscillate and shall be locked to high logic level, when any of the following fault conditions occur:

driver not powered;

driver disabled;

Receiver inputs open circuit.

1	“Driver disabled” means that the driver outputs are in high impedance.

2	“Receiver inputs open circuit” means that the cable or wire in cable is disconnected.

When the driver is not powered, its output should be high impedance with a leakage current of less than 20 μA.

When the line receiver is not powered, its input should be high impedance with a leakage current of less than 20 μA.

Recommendations 5.3.5.2.5e and 5.3.5.2.5f mean that, when off, the output of a driver and the input of a receiver have a high impedance. The 20 μA does not include any current flowing in any external biasing resistors.

When external biasing resistors are used to provide fail safe operation or to increase immunity to noise on the line receiver input, the bias current provided by the external biasing resistors should be less than 0.25 mA.

This bias current is 10% of the expected minimum current through the termination resistor.

A single fault should not lead to a driver emitting a voltage outside the range 0 V to +3,6 V relative to the driver ground reference.

A single fault should not lead to a line receiver emitting a voltage outside the range 0 V to +3,6 V relative to the line receiver ground reference.

A driver output should withstand without failing a direct connection to a voltage between -0,3 V and +3,9 V relative to the driver ground reference.

A line receiver input should withstand without failing a direct connection to a voltage between -0,3 V and +3,9 V relative to the driver ground reference.

LVDS line receive signal at the system level

When a test signal is sent by the line driver through the SpaceWire connectors and cable assembly, the received signal measured at the receiver termination resistor or within 20 mm of the line receiver inputs shall have:

a minimum edge separation which is greater than the minimum edge separation required by the SpaceWire line receiver, see clause 5.3.6,

a differential amplitude of more than +100 mV or less than -100 mV in the region between the edges, and

a differential amplitude of less than 600 mV.

This is illustrated by the forbidden mask regions which are shown as shaded areas in Figure 510. The use of an eye-pattern display on an oscilloscope provides a diagnostic visualisation of SpaceWire signals, but does not show how well a receiver decodes the signals.

The test signal shall comprise a repeating sequence of the following set of SpaceWire packets following one another sent without any Nulls between the data characters:

SpaceWire packet of length greater than 1000 bytes containing a pseudorandom bit sequence;

SpaceWire packet of length greater than 1000 bytes all set to 0x55.

The choice of pseudorandom bit sequence is not critical. The PRBS-15 or the 8 stage Galois LFSR are examples of suitable pseudorandom bit sequences.

The receive signal shall be measured across the line receiver termination resistor using an oscilloscope and differential probes which have bandwidths of at least 1,05 times the reciprocal of the signal rise time.

1	This means that Bandwidth = 1,05/(signal rise time).

2	The factor of 1,05 is a rule of thumb requiring the bandwidth of the oscilloscope and probe to include the third harmonic of the signal edge bandwidth. The signal edge bandwidth is given by 0,35/rise-time (the bandwidth of a signal is 0,35/rise-time). The fastest signal rise time for LVDS is specified in TIA-644-A to be 260 ps, resulting in a minimum combined oscilloscope and probe 3-dB bandwidth of 4 GHz. Allowing some margin gives a recommended combined oscilloscope and probe 3-dB bandwidth of 5 GHz which is the figure recommended in TIA-644-A.

Where the termination resistors are internal to an integrated circuit, the receive signal may be measured within 3 cm of the line receiver pins on the integrated circuit.

When access to the termination resistors is not possible, the receive signal may be measured at the connector adjusting for the transfer impedance between the connector and the termination resistor or other equivalent method.

An example of situation in which the access to the termination resistors is not possible, is the measurement inside a close unit.

Figure 510: LVDS receive signal eye pattern mask

LVTTL

Low Voltage Transistor-Transistor Logic or LVTTL may be used for driving SpaceWire data and strobe signals over short distances over PCB tracks and cables.

1	LVTTL is only intended to be used internally within a unit, so the full details of the LVTTL signals are not specified.

2	In this context “short distance” means less than 30 cm.

SpaceWire using LVTTL line drivers and line receivers shall be referred to as SpW-LVTTL.

Data-Strobe skew

General

The components of the data-strobe skew across a SpaceWire link are separated into the following contributions: transmitter, cable assembly and receiver. This is illustrated in Figure 511

Figure 511: Physical layer components

Contributors to the Data-Strobe skew

The equipment manufacturer shall provide the specification for the worst case skew between the differential data and strobe output signals at the SpaceWire connector of a unit (DSskewOUT), including the effect of transmitter jitter.

The way in which this can be determined is detailed in Annex A.

The cable assembly manufacturer shall provide the worst case skew (DSskewCA) between the differential data and strobe signals.

This maximum permitted value for the differential data to strobe skew in a cable is given by the cable assembly inter-pair skew which is specified in clause 5.3.3.3.

The cable assembly manufacturer shall provide the worst case frequency dependent and data-pattern dependent jitter (JitterCA) of the data or strobe signals.

The way in which this can be determined is detailed in Annex A.

The equipment manufacturer shall provide the specification for the minimum tolerated separation between signal edges (MinsepIN) which can be data to strobe separation, data to data or strobe to strobe.

The way in which this can be determined is detailed in Annex A.

The minimum bit unit interval, TUIMIN, shall be the sum of the following components:

maximum, worst case, source unit output D-S skew, DSskewOUT;

maximum, worst case, cable assembly differential D-S skew, DSskewCA;

maximum, worst case, cable assembly differential jitter, DSjitterCA;

receiving unit minimum tolerated separation between signal edges, MinsepIN;

10 % margin on the sum of (DSskewOUT + DSskewCA + DSjitterCA + MinsepIN ).

A table giving an example calculation is provided in Table 57.

The maximum operating frequency of the SpaceWire link shall be less than the reciprocal of the minimum bit unit interval, TUIMIN.

Table 57: Example calculation of maximum bit rate

Factor	Abbreviation	Value (ps)	Sum (ps)
Maximum, worst case, source unit output D-S skew	DSskewOUT	1234	1234
Maximum, worst case, cable assembly differential D-S skew (e.g. 5 m cable)	DSskewCA	500	1734
Maximum, worst case, data or strobe jitter in the cable assembly	JitterCA	500	2234
Receiving unit minimum tolerated separation between signal edges	MinsepIN	1384	3618
10% Margin	Margin	362	3980
Minimum Bit Unit Interval	TUIMIN	3980
Maximum bit rate	251 Mbits/s

Physical layer management parameters

The following management parameters should be provided to configure, control and monitor the physical layer:

enable line driver (port), which when set enables the line driver of the specified port so that it can transmit information,

enable line receiver (port), which when set enables the line receiver of the specified port so that it can receive information,

connector type and pin out for each connector.

Encoding layer

Serialisation and de-serialisation

Characters and control codes shall be encoded, serialised, data-strobe encoded and transmitted in the order in which they are received from the data link layer.

Received characters and control codes shall be passed to the data link layer in the order in which they are received.

Only received characters and control codes that do not contain a parity error shall be passed to the data link layer.

Only when gotNull is asserted (see Clause 5.4.4), the characters and control codes that are received shall be passed to the data link layer.

The assertion of gotNull implies that the first Null was received.

The operation of the encoding layer shall be controlled by the data link layer using the following control flags:

transmit enable, which enables the transmitter when asserted and reset it when de-asserted, and

receive enable, which enables the receiver when asserted and reset it when de-asserted.

1	The transmitter comprises the character encoder, the serialiser, the data-strobe encoder and the line driver.

2	The receiver comprises the line receiver, the data-strobe decoder, the de-serialiser and the character decoder.

The encoding layer shall inform the data link layer of changes in the encoding layer indicated by the following status flags:

Disconnect;

Receive error;

gotNull.

Character and control code encoding

Data characters

A data character shall be encoded in 10-bits with the resulting data symbol containing a parity bit, a data­control flag and eight bits of data as illustrated in Figure 512.

The data­control flag shall be set to zero to indicate that the current symbol holds a data character.

The eight-bit data value shall be transmitted least significant bit first.

Figure 512: Data character encoding.

Control characters

A control character shall be encoded in four bits with the resulting control symbol containing:

a parity bit,

a data­control flag, and

a two­bit control type.

The control character is illustrated in Figure 513.

Figure 513: Control character encoding

The data­control flag shall be set to one to indicate that the current symbol holds a control character.

A flow control token (FCT) shall be encoded as a control symbol with the two-bit control type set to 0b00.

The FCT is used in the data link layer to manage the flow of N-Chars over a SpaceWire link.

An end of packer marker (EOP) shall be encoded as a control symbol with the two-bit control type set to 0b01.

The EOP is used in the data link layer to mark the end of a packet indicating that the packet was transferred with no parity error being detected.

An error end of packet (EEP) marker shall be encoded as a control symbol with the two-bit control type set to 0b10.

The EEP is used in the data link layer to terminate a packet prematurely at the point where the error occurred. The EEP indicates that an error occurred while the packet was being transferred.

An escape character (ESC) shall be encoded as a control symbol with the two-bit control type set to 0b11.

The ESC is used to form the Null and Broadcast control codes.

Control codes

The ESC shall be used as the first character in a control code.

The Null control code shall be encoded as an ESC followed by a flow control token (FCT) as illustrated in Figure 514.

1	The parity bit (P) in the middle of the control code is zero, in accordance with clause 5.4.2.4.

2	Null is passed to the encoding layer by the data link layer whenever a link is not sending data or control symbols, to keep the link active and to support link disconnect detection (in accordance with clause 5.4.7).

Figure 514: Null control code encoding

The broadcast code (BC) shall be encoded as an ESC followed by a single data character as illustrated in Figure 515.

1	The parity bit (P) in the middle of the broadcast code is one, in accordance with clause 5.4.2.4.

2	The broadcast code is used for time-codes and distributed interrupt codes.

The eight bits of data in the data character of a broadcast code shall be separated into two fields: the type field and the value field.

The type field shall be formed by the most significant two bits (B7:6).

The value field shall be formed by the least significant six bits (B5:0).

Figure 515: Broadcast code encoding

Parity

A parity bit shall be assigned to each encoded data or control character to support the detection of transmission errors.

The parity bit shall cover the previous eight bits of an encoded data character or two bits of an encoded control character, the current parity bit, and the current data­control flag, as illustrated in Figure 516.

The parity bit shall be set to produce odd parity so that the total number of 1’s in the field covered is an odd number.

Figure 516: Parity coverage

Data strobe encoding and decoding

The data bit stream resulting from the serialisation of the symbols to be transmitted shall be encoded using two signals: Data signal and Strobe signal.

The Data signal shall follow the data bit stream.

This means that the Data signal is high when the data bit is 1 and low when the data bit is 0.

The Strobe signal shall change state whenever the Data does not change from one bit to the next.

The Data-Strobe encoding is illustrated in Figure 517.

Figure 517: Data­Strobe (DS) encoding

The Data and Strobe signals shall be set to zero on power up reset.

When the SpaceWire output port is reset it shall be a controlled reset avoiding simultaneous transitions of Data and Strobe signals.

For example, after stopping transmission the Strobe signal can be reset first, followed by the Data signal. This prevents a simultaneous transition on the data and strobe signals which can cause some IEEE 1355-1995 devices to enter an unrecoverable fault state.

When a SpaceWire output port has been transmitting characters and the link state machine enters the ErrorReset state (see clause 5.5.6.2) the data and strobe signals shall be reset with a delay between the reset of the strobe followed by data signal or reset of the data followed by strobe signal.

The delay between the reset of the Strobe signal and the Data signal shall be between 500 ns and the period of the fastest transmit time for the particular transmitter which is dependent upon implementation.

500 ns is the period of slowest permitted transmit bit rate, that is 2 Mbps.

The SpaceWire receiver shall be tolerant of simultaneous transitions on the Data and Strobe lines.

1	This implies that the receiver does not lock up when a simultaneous transition occurs.

2	Simultaneous transitions on the Data and Strobe lines are not part of the normal operation of SpaceWire. They can occur, however, either when a SpaceWire cable is plugged in while the transmitter is trying to make a connection, or when the LVDS driver or receiver circuits are enabled while the transmitter is trying to make a connection.

First Null

The first bit of the first NULL to be sent after the Transmitter Enabled flag is asserted shall be a parity bit, which is set to zero so that the first transition shall be on the Strobe line.

This results in the patterns shown in Figure 518 appearing when a link is started.

Figure 518: Data and strobe signals for first Null

Null detection

Null detection shall be enabled whenever the receiver is enabled.

The gotNull condition shall only be cleared when the RX Enable flag is de-asserted.

First Null detection after the receiver is enabled shall include all three parity bits related to the Null.

The first Null detection therefore includes the parity bit that covers the data­control flag of the Escape character, the parity bit that covers the Escape character, and the parity bit that covers the FCT character.

gotNull shall be asserted when the first Null after the “receiver enabled” is detected.

1	That is the 011101000 sequence of bits is received as illustrated in Figure 519.

2	During initialization the character following a Null is a control character (either another Null or an FCT) so the last parity bit of the Null is zero. See clause 5.4.4 for the format of first Null transmitted by a SpaceWire interface.

Figure 519: Null detection sequence

Parity error

Parity detection shall be enabled whenever the receiver is enabled and the GotNull condition is asserted.

A parity error shall be detected when the parity is not odd.

This means that a parity error is detected when there is an even number of bits set to ‘1’, as detailed in clause 5.4.2.4.

Disconnect

Disconnect shall be detected by the SpaceWire input port.

The disconnect detection shall be enabled when the link state machine leaves the ErrorReset state and the first edge is detected on the D or S line.

A disconnect shall occur when the length of time since the last transition on either the D or S line is longer than 727 ns (8 cycles of 10 MHz clock + 10 %) and 1 µs maximum (9 cycles of 10 MHz clock - 10 %).

ESC error

An escape character (ESC) followed by ESC, EOP or EEP is an invalid sequence and when received shall produce an ESC error.

ESC followed by FCT is a Null and ESC followed by a data character is a broadcast code.

ESC error detection shall be enabled when the GotNull condition is asserted.

Data signalling rate

Initial operating data signalling rate

After a reset or disconnect (see clause 5.4.7) an output port shall start operating at a data signalling rate of (10 1) Mbps.

The SpaceWire output port shall operate at (10 1) Mbps until set to operate at a different data signalling rate.

1	The aim of this requirement is to provide all systems with a common, slow, initial data signalling rate so that system operation can be validated before switching to other and possibly widely different data signalling rates.

2	This initial slow data signalling rate is applicable to all SpaceWire output ports, even when they are not capable of higher data signalling rates.

Minimum data signalling rate

The minimum data signalling rate at which an output port shall operate is 2 Mbps.

The minimum data signalling rate is the lowest data signalling rate at which a SpaceWire link can operate which is determined by the disconnect timeout (clause 5.4.7) to be greater than 1,18 Mbps, i.e. 1/850 ns.

An output port may have a minimum data signalling rate of more than 2 Mbps but at most 10 Mbps + 10 %.

Maximum data signalling rate

The maximum data signal rate shall be the highest data signalling rate at which a SpaceWire link can operate taking into account signal attenuation, skew and jitter.

The maximum data signalling rate shall be specified for each implementation.

The maximum signalling data rate is the fastest data signalling rate that a SpaceWire link can operate whilst decoding the received data bits correctly.

The maximum data signalling rate of a link shall be not less than initial operating data signalling rate (see clause 5.4.9.1).

Operational data signalling rates

The output port at one end of a link shall be able to operate at a different data signalling rate to the output port at the other end of the link.

1	Once in the Run state it is possible to change the output port data signalling rate from the initial data signalling rate to the required operating data signalling rate (see clause 5.5.6.7).

2	The link is able to run at different speeds in each direction. It is advisable to have both directions of the link running at the same or similar speed because a wide difference in speed restricts the rate of FCTs being returned on the slower direction of the link and thus throttle the data rate in the faster direction.

Output ports within a network shall be able to operate at different data signalling rates.

Overall system performance is improved if all links in a network run at the same or similar speed, since a packet is held up on a fast link if it is elsewhere being routed over a slower link (see clause 5.6.7.7).

Encoding layer management parameters

The following management parameters should be provided to configure, control and monitor the encoding layer:

Link speed (port), which controls the operational data signalling rate of the specified port.

Data link layer

Data link layer interfaces

The data link layer shall receive N-Chars and broadcast codes from the network layer.

These N-Chars and broadcast codes are encoded by the encoding layer and sent over the SpaceWire link.

The data link layer shall pass a sequence of data characters, control characters and control codes to the encoding layer.

These data characters, control characters and control codes are character encoded, serialised, data-strobe encoded and transmitted by the encoding layer.

The data link layer shall receive data characters, control characters and control codes from the encoding layer.

The data link layer shall pass N-Chars and broadcast codes to the network layer.

The data link layer shall indicate to the Network layer when it is able to accept another N-Char for sending.

The data link layer shall indicate to the Network layer when it has an N-Char ready for passing to the Network layer.

The data link layer shall indicate to the Network layer when it has a broadcast code ready for passing to the Network layer.

The data link layer shall control the operation of the encoding layer using the “Transmit enable” and “Receive enable” control flags:

“Transmit enable” shall enable the transmitter when asserted and reset it when de-asserted.

The transmitter comprises the character encoder, the serialiser, the data-strobe encoder and the line driver.

“Receive enable” shall enable when asserted and reset it when de-asserted.

The receiver comprises the line receiver, the data-strobe decoder, the de-serialiser and the character decoder.

The data link layer shall respond to changes in the encoding layer indicated by the following status flags:

Disconnect,

Receive error, and

gotNull.

Data link layer management parameters

The data link layer shall be controlled using the following management parameters:

Enabled (port)

LinkStart (port)

AutoStart (port)

1	The Enable condition is the inverse of the Disabled condition.

2	Enabled, LinkStart and AutoStart are the minimum set of management parameters to allow operation of the SpaceWire link.

The data link layer should provide the following status information:

Link state (port), which is the current state of the data link layer state machine for the specified port;

Error flags (port), which is the current state of the following error flags:

Disconnect;

Parity Error;

ESC Error;

Credit Error.

Credit counts (port), which is the values of the transmit and receive credit counters of the specified port.

Sending priority

The order of priority for sending of characters and control codes shall be as follows:

Broadcast codes, highest priority;

FCTs;

N­Chars;

Nulls, lowest priority.

When the link state machine is in the Run state and sending of a broadcast code is requested, it shall be sent as soon as the data link layer has finished sending the current character or control code.

When sending of an FCT is requested, it shall be sent as soon as the current character or control code has been sent provided that no broadcast code is waiting to be sent.

When the link state machine is in the Run state and an N­Char is available in the transmit buffer, it shall be sent as soon as the current character or control code has been sent provided that:

no broadcast code is waiting to be sent,

no FCT is waiting to be sent, and

the transmit credit count is above zero.

When no broadcast code, FCT or N­Char is ready to be sent, a Null shall be sent to indicate that the link is still active.

This requirement prevents the disconnect detection mechanism from being triggered at the far end of the link.

Flow control

The flow of N-Chars across a link shall be controlled using flow control tokens sent from one end of the link (end A) to the other end (end B) to signify that end A is ready to receive some more data.

Each flow control token shall be exchanged for eight N-Chars.

An FCT shall be sent from the data link layer to the encoding layer when the data link layer is ready to receive a further eight N-Chars.

The data link layer shall not send any N-Chars to the encoding layer until it has received one or more FCTs from the encoding layer to indicate that the data link layer at the other end of the link is ready to receive N-Chars.

The data link layer shall maintain a count of the number of N­Chars it has been authorized to send (transmit credit count), according to requirements f and g:

Each time the data link layer receives an FCT from the encoding layer it shall increment its transmit credit count by eight.

Whenever the data link layer sends an N­Char to the encoding layer it shall decrement its transmit credit count by one.

EOP and EEP are N-Chars and thus credit counted even when empty packets are discarded.

If the transmit credit count reaches zero, the data link layer shall cease sending N­Chars to the encoding layer until it receives another FCT from the encoding layer.

When the transmit credit count is zero the data link layer shall continue to send FCTs and Nulls to the encoding layer.

The transmit credit count shall be set to zero whenever the link state machine enters the ErrorReset state.

The transmit credit count shall have a maximum value of 56.

A value of 56 corresponds to seven FCTs.

A maximum of seven FCTs shall be outstanding at any time.

The transmit counter shall not be incremented if a FCT causing the transmit credit counter to exceed it maximum value is received.

A credit error shall be raised if a FCT causing the transmit credit counter to exceed it maximum value is received. (see Clause 5.5.5).

When the link is initialised or re-initialised, one FCT shall be sent for every eight N-Chars that can be held in the receive FIFO up to the maximum of seven FCTs.

The data link layer shall maintain a count of the number of N-Chars it can receive (receive credit count) as follows:

Increment the receive credit count by eight each time an FCT is passed to the encoding layer.

Decrement the receive credit count by one each time an N­Char is received from the encoding layer.

The receive credit count shall be set to zero whenever the link state machine enters the ErrorReset state.

The receive credit count shall have a maximum value of 56.

A value of 56 corresponds to seven FCTs.

A receive credit count may have a maximum value of less than 56 if the data link layer can only hold less than 56 received N-Chars.

The data link layer may hold more received N-Chars than the maximum receive credit count value.

An FCT shall only be sent in the following two cases:

there is room in the data link layer to receive another eight more N-Chars from the encoding layer;

the receive credit count has a value of eight or more less than its maximum value.

Flow control errors

A credit error shall be detected when either of the following conditions occur:

an N-Char is received when the receive credit counter is zero;

an FCT is received which causes the transmit counter to exceed its maximum permitted value.

A credit error indicates that some otherwise undetected error has occurred on the link, which has caused the corruption of the credit count.

Link initialisation behaviour

General

The initialisation, establishing the connection and responding to control requests of the SpaceWire link shall follow the behaviour described in the requirements from 5.5.6.1b to 5.5.6.1e.

The link initialisation behaviour is illustrated by way of a state diagram for a link state machine in Figure 520.

Figure 520: Link initialisation behaviour.

When an error occurs on the link, the link shall:

recover from those errors, and

allow normal link operation to resume.

1	In accordance with Figure 520, Disconnect Error is only enabled after the first transition on the data or strobe line.

2	In accordance with Figure 520, Parity Error, ESC Error, gotFCT, gotN-Char and gotBC are only enabled after the first Null has been received (i.e. gotNull asserted).

3	Figure 520 shows that the transition from the Started state to the ErrorReset state has “after 12,8 µs” in black (dark text) which is intentional as this transition is normal operation and not an error condition. It occurs when this end of the line is trying to start and the other end is disabled. The transition from the Connecting state to the ErrorReset state has “after 12,8 µs” in red (lighter text) because it is an error: although a Null has been received indicating that the other end of the link is active, no FCT is received within 12,8 µs so it is a fault.

The “after 6,4 s” condition shall have a duration of between 5,82 s to 7,22 s.

A timing delay of 6,4 s is the nominal time delay. 5,82 s correspond to 64 cycles of a 10 MHz clock plus 10 % of tolerance. 7,22 s correspond to 65 cycles of a 10 MHz clock minus 10 % of tolerance.

The “after 12,8 s” condition shall have a duration of between 11,64 s to 14,33 s.

A timing delay of 12,8 s is the nominal time delay. 11,64 s correspond to 128 cycles of a 10 MHz clock plus +10 % of tolerance. 14,33 s correspond to 129 cycles of a 10 MHz clock minus 10% of tolerance.

When Port Reset is asserted the TX FIFO and RX FIFO shall be cleared.

ErrorReset state

The link state machine shall enter the ErrorReset state on one of the following conditions:

port Reset is asserted;

the port is disabled or a disconnect, parity error, ESC error, gotFCT, gotN-Char or gotBC event occurs while in the ErrorWait state;

the port is disabled or a disconnect, parity error, ESC error, gotFCT, gotN-Char or gotBC event occurs while in the Ready state;

the port is disabled or a disconnect, parity error, ESC error, gotFCT, gotN-Char or gotBC event occurs while in the Started state;

the link state machine has been in the Started state for more than 12,8 µs;

the port is disabled or a disconnect, parity error, ESC error, gotN-Char or gotBC event occurs while in the Connecting state;

the link state machine has been in the Connecting state for more than 12,8 µs;

the port is disabled (enable de-asserted) or a disconnect, parity error, ESC error or credit error occurs while in the Run state.

When in the ErrorReset state the link state machine shall initiate the following actions in sequence:

de-assert the Transmit Enable control flag;

de-assert the Receive Enable control flag;

set the transmit credit counter to zero;

set the receive credit counter to zero;

clear the gotFCT condition.

start the 6,4 µs timer on entering the ErrorReset state after Port Reset is disabled;

5.5.6.2b.2 causes the Encoding layer to clear the gotNull condition.

When in the ErrorReset state the link state machine should initiate the following actions:

Discard any broadcast code pending to be sent.

The Link state machine shall leave the ErrorReset state on the following condition:

when Port Reset is de-asserted and enable is asserted and 6.4 µs (at least) has elapsed since entering the ErrorReset state, move to the ErrorWait state.

ErrorWait state

The Link state machine shall enter the ErrorWait state on the following condition:

from the ErrorReset state, when the Port Reset is de-asserted and enable is asserted and 6.4 µs (at least) has elapsed since entering the ErrorReset state.

When in the ErrorWait state the Link state machine shall initiate the following actions in sequence:

de-assert the Transmit Enable control flag.

assert the Receive Enable control flag, but do not pass any N-Chars to the Encoding Layer and do not register any received broadcast codes.

start the 12,8 µs timer on entering the ErrorWait state.

The Link state machine shall leave the ErrorWait state on one of the following conditions:

when Port Reset is asserted, move to the ErrorReset state;

when the port is disabled (enable de-asserted), move to the ErrorReset state;

when a disconnect occurs, move to the ErrorReset state;

when a parity error occurs move to the ErrorReset state;

when an ESC error occurs, move to the ErrorReset state;

when an FCT, N-Char or broadcast code is received, move to the ErrorReset state;

if enabled, 12,8 µs after entering the ErrorWait state, move to the Ready state.

Ready state

The Link state machine shall enter the Ready state on the following condition:

from the ErrorWait state, when enable is asserted and 12.8 µs after entering the ErrorWait state.

When in the Ready state the Link state machine shall initiate the following actions in sequence:

de-assert the Transmit Enable control flag;

assert the Receive Enable control flag, but do not pass any N-Chars to the Encoding Layer and do not register any received broadcast codes.

The Link state machine shall leave the Ready state on one of the following conditions:

when Port Reset is asserted, move to the ErrorReset state;

when the port is disabled (enable de-asserted), move to the ErrorReset state;

when a disconnect occurs, move to the ErrorReset state;

when a parity error occurs, move to the ErrorReset state;

when an ESC error occurs, move to the ErrorReset state;

when an FCT, N-Char or broadcast code is received, move to the ErrorReset state;

when enable is asserted and LinkStart is asserted, move to the Started state;

when enable is asserted and AutoStart is asserted and gotNull is asserted, move to the Started state.

Started state

The Link state machine shall enter the Started state on one of the following conditions:

from the Ready state, when enable is asserted and LinkStart is asserted;

from the Ready state, when enable is asserted and AutoStart is asserted and gotNull is asserted.

When in the Started state the Link state machine shall initiate the following actions in sequence:

send Nulls;

assert the Receive Enable control flag, but do not pass any N-Chars to the Encoding Layer and do not register any received broadcast codes.

start a 12.8 µs timer on entering the Started state;

The Link state machine shall leave the Started state on one of the following conditions:

when Port Reset is asserted, move to the ErrorReset state;

when the port is disabled (enable de-asserted), move to the ErrorReset state;

when a disconnect occurs, move to the ErrorReset state;

when a parity error occurs, move to the ErrorReset state;

when an ESC error, move to the ErrorReset state;

when an FCT, N-Char or broadcast code is received, move to the ErrorReset state;

when enable is asserted, at least one Null was sent and gotNull is asserted, move to the Connecting state.

12,8 µs after entering the Started state, move to the ErrorReset state.

The Null causing the gotNull condition to be asserted, could have been received in the ErrorWait, Ready or Started state.

Connecting state

The Link state machine shall enter the Connecting state on the following condition:

From the Started state, when enable is asserted and gotNull is asserted.

When in the Connecting state the Link state machine shall initiate the following actions, in sequence:

start the 12,8 µs timer on entering the Connecting state;

enable sending of FCTs;

send Nulls when there is nothing else to send;

send FCTs and Nulls;

assert the Receive Enable control flag;

after gotFCT is asserted, pass any received N-Chars to the Encoding Layer and register any received broadcast codes.

It is necessary to write the N-Chars into the FIFO and register any broadcast codes in this state after gotFCT has been asserted because it is possible that the far end of the link has initialized and is running at 200 Mbits/s, for example, so that in the time the state machine is in the Connecting state one or more N-Chars or broadcast codes are received after the FCT.

The Link state machine shall leave the Connecting state on one of the following conditions:

when Port Reset is asserted, move to the ErrorReset state;

when the port is disabled (enable de-asserted), move to the ErrorReset state;

when a disconnect occurs, move to the ErrorReset state;

when a parity error occurs, move to the ErrorReset state;

when an ESC error occurs, move to the ErrorReset state;

when enable is asserted, at least one FCT was sent and an FCT has been received (gotFCT asserted), move to the Run state;

when an N-Char or broadcast code is received and no FCT has been received, move to the ErrorReset state;

12,8 µs after entering the Connecting state, move to the ErrorReset state.

Run state

The Link state machine shall enter the Run state on the following condition:

from the Connecting state, when enable is asserted, at least one FCT has been sent and an FCT is received.

When in the Run state the Link state machine shall initiate the following actions, in sequence:

enable sending of FCTs, N-Chars and broadcast codes;

pass Nulls to the Encoding Layer when there is nothing to send;

assert the Receive Enable control flag;

pass received N-Chars and broadcast codes to the Encoding Layer;

pass any received broadcast codes to the Network Layer;

if and when required, change the SpaceWire output port operating rate (see clause 5.4.3).

The Link state machine shall leave the Run state on one of the following conditions:

when Port Reset is asserted, move to the ErrorReset state;

when the port is disabled (enable de-asserted), move to the ErrorReset state;

when a disconnect occurs, move to the ErrorReset state;

when a parity error occurs, move to the ErrorReset state;

when an ESC error occurs, move to the ErrorReset state;

when a credit error occurs, move to the ErrorReset state.

Alternative behaviour when disabled asserted

When Disabled is asserted, alternative behaviour may result as follows:

Disabled are recognised in the Ready and Run state.

when Disabled is asserted in the Ready state, the link state machine remain in the Ready state.

when Disabled is asserted in the Run state, the link state machine moves to the ErrorReset state.

This alternative behaviour allows the link state machine of the previous version of the SpaceWire standard (ECSS-E-ST-50-12C published in 2008) to work. The improvement in the current version (revision 1) permits the link state machine to immediately move to and remain in the ErrorReset state with the receiver disabled, when Disabled is asserted. The functions of Disabled/Enabled, Link Start and AutoStart were separated for clarity.

Link error recovery

General

The recovery of the link from errors shall follow the behaviour described in the clauses 5.5.7.2 and 5.5.7.3.

The link error recovery behaviour is illustrated by way of a state diagram for a link error recovery state machine in Figure 521.

Figure 521: Link error recovery behaviour

Normal state

The Link Error Recovery state machine shall enter the Normal state on one of the following conditions:

Port Reset is asserted;

Error recovery is completed in the Recovery state.

When in the Normal state the Link Error Recovery state machine shall do nothing.

The Link Error Recovery state machine shall leave the Normal state on the following conditions:

When the Link state machine is in the Run state and the port is disabled (enabled de-asserted), the Link Error Recovery state machine moves to the Recovery state.

When the Link state machine is in the Run state and a Disconnect, Parity Error, ESC Error, or Credit Error occurs, the Link Error Recovery state machine moves to the Recovery state.

Recovery state

When the Link State Machine is in the Run state, the Link Error Recovery state machine shall enter the Recovery state on one of the following conditions:

port is disabled (enable de-asserted) in the Normal state;

a disconnect occurs in the Normal state;

a parity error occurs in the Normal state;

an ESC error occurs in the Normal state;

a credit error occurs in the Normal state.

When in the Recovery state the Link Error Recovery state machine shall initiate the following actions:

if currently sending a packet, discard the remainder of the packet that has not yet been sent;

if the last character written to the receive FIFO was a data character, write an EEP to the receive FIFO;

an EEP can be added to the receive FIFO when the last character written was an EOP or EEP;

if an EEP is to be written to the receive FIFO and that FIFO is full preventing an EEP being written, wait until there is space in the receive FIFO and then write the EEP;

Record the cause of the error in a status register.

1	If one or more N-Chars were sent since the link reached the Run state AND the last character sent was not an EOP or EEP, read the transmit FIFO and discard the characters read until an EOP or EEP was read and discarded.

2	Because the remainder of a packet is discarded after an error, very large packets can cause the link to halt for a long period of time while the packet is spilt. In this conditions, the link initializes but is not able to send a packet until the remainder of the packet being spilt was discarded. It is important to consider this when determining the size of packets to use in a particular application.

3	The error recovery process is illustrated in Figure 522.

4	If the receive FIFO is full, it is not possible for the transmitter to send an FCT, therefore the link initialisation cannot take place successfully. The Link state machine cycles through ErrorReset, ErrorWait, Ready and Connected states until space is made in the receive FIFO. When there is room for at least eight N-Chars, at least one FCT can be sent so the link initialisation process can complete successfully.

The Link Error Recovery state machine shall leave the Recovery state on the following conditions:

when Port Reset is asserted, move to the Normal state;

when error recovery is complete, move to the Normal state.

Figure 522: Link error recovery process

Accepting broadcast codes for sending

Broadcast codes passed to the data link layer by the network layer should be discarded unless the link state machine is in the Run state.

This recommendation prevents a broadcast code from being passed to the data link layer and sent some significant time later when the link is started.

SpaceWire network layer

SpaceWire packets

SpaceWire packet format

A SpaceWire packet shall comprise one or more data characters followed by an end of packet marker (EOP) or error end of packet marker (EEP).

The start of a packet shall be either:

The first data character sent after a link is initialised or re-initialised following a disconnect.

The data character that immediately follows an EOP or EEP.

That is the first data character after the end of the previous packet.

The end of a packet shall be indicated by an EOP or EEP.

The packet shall contain one or more data characters.

A packet may contain zero data characters.

In this case the packet is discarded by the first routing switch that it encounters.

Zero or more data characters at the front of a packet shall form a destination address.

The remaining data characters, following the destination address and up to the EOP or EEP, shall form the SpaceWire cargo.

The format of a SpaceWire packet is illustrated in Figure 42.N­Char interleaving

N­Chars from one packet shall not be interleaved with N­Chars from another packet.

N­Chars can be interleaved with FCTs, Nulls and broadcast codes as explained in clause 5.5.3.

Broadcast codes

A time-code shall be a broadcast code with the broadcast code type set to 0b00.

A distributed interrupt code shall be a broadcast code with the broadcast code type set to 0b10.

The specialisations of broadcast codes are illustrated in the UML diagram of Figure 523.

Figure 523: Specialisations and relationships of a SpaceWire broadcast code

There shall be two types of distributed interrupt codes: interrupt code and interrupt acknowledgment code.

The order of priority with which the network layer shall pass different types of broadcast codes to the data link layer shall be as follows:

Time-code, highest priority;

Interrupt acknowledgement code;

Interrupt code, lowest priority.

A broadcast code that has a broadcast code type set to 0b01 or 0b11 shall be deleted and not forwarded by routing switches.

A broadcast code that has a broadcast code type set to 0b01 or 0b11 shall be discarded when it is received by a node.

SpaceWire time-codes

General

SpaceWire time-codes shall be optionally implemented in nodes and switches.

When time-codes are not supported by a node or switch, that node or switch shall ignore any time-codes it receives.

Time-codes

The value field of a time-code shall contain a 6-bit time-code value,

The 6-bit time coded value of a time code shall be an unsigned binary integer.

The network layer time-code is illustrated in Figure 524.

Figure 524 Network layer time-code

Time-code register

A node supporting time-codes shall have one or more time-code registers

Each time-code register as per requirement 5.6.3.3a shall be associated with one or more end-points.

Each time-code register in a node shall be used to hold the value of the last time-code transmitted or received over the end-points it is associated with.

See clause 5.6.3.5 for an explanation of a valid time-code.

A routing switch supporting time-codes shall have one time-code register.

The time-code register as per requirement 5.6.3.3d shall hold the value of the last time-code received.

After reset the time-code register shall be set to have a time-code value of zero.

When a time-code is received by an end-point or routing switch that does not have a time-code register, the time-code shall be discarded.

Time-code master

A network supporting time-code broadcast shall have a single time-code master application running on a single node.

The time-code master application shall be responsible for sending time-codes over the network.

The time-code master shall pass time-codes to one or more end-points for sending across the network.

When more than one end point is being used in a time code master to send time-codes across the network, each end-point shall be associated with the same time-code register.

Each time code register, associated to each end point as per requirement 5.6.3.4d, shall be loaded by the time code master with the time-code value that is to be sent.

When more than one end point is being used as a code master, the time-code master shall request each of the end-points to send a time-code with the value held in the time-code register at the same time.

1	Sending the same time-code over two or more end-points is intended to support redundant systems. If one time-code is lost, another time-code being broadcast through a redundant network takes the place of the lost time-code.

2	The host system does not have to send time-codes with sequential values, but only those with sequential values can propagate across the network. Non-sequential time-codes can be used to reinitialise the time-codes on the network to a new value, or be used to send specific values over a point-to-point link.

Valid time-code

If a time-code is received by an end-point or routing switch, that has a time-code register, the received time-code value shall be compared to the value contained in the time-code register.

If the received time-code has a value which is one more, modulo 64, than the value in the time-code register, the received time-code shall be valid.

If the received time-code has a value which is not one more, modulo 64, than the value in the time-code register, the received time-code shall be invalid.

Valid time-code in switch

If a valid time-code is received by a routing switch with a time-code register, the switch shall:

request to send time-codes with the same value as the received valid time-code out through each of its output ports, except for the output port on which the valid time-code arrived;

update the time-code register in the routing switch to the value of the valid time-code.

Invalid time-code in switch

If an invalid time-code is received by a routing switch with a time-code register, the switch shall update the time-code register in the routing switch to the value of the received time-code.

Valid time-code in a node

If a valid time-code is received by an end-point associated with a time-code register, the node shall:

indicate to the host system that a valid time-code has arrived;

make the value of the time-code available to the host system;

update the time-code register associated with the end-point to the value of the valid time-code.

Invalid time-code in a node

When an invalid time-code is received by an end-point associated with a time-code register, the node shall update the time-code register associated with the end-point to the value of the received time-code.

This is so that when a time-code is lost for any reason the time-code broadcast mechanism can recover and continue to broadcast time-codes across the network after a few more time-codes have been sent. The number of time-codes that need to be sent following a missing time-code depends on the size of the network. If there is path redundancy in the network, the missing time-code is likely to be recovered by that same time-code being received via another path through the network.

SpaceWire distributed interrupts

General

SpaceWire distributed interrupts shall be optionally implemented in nodes and switches.

When distributed interrupts are not supported by a node or switch, that node or routing switch should ignore:

any interrupt codes it receives;

any interrupt acknowledgement codes it receives;

any host requests to send interrupts;

any interrupt acknowledgements.

New routing switch devices that do not support distributed interrupts are recommended to ignore interrupt codes and interrupt acknowledgement codes. Nodes that do not support distributed interrupts can be blocked from receiving them by a switch.

There shall be two modes that an interrupt can function in:

Interrupt mode, and

Interrupt with acknowledgement mode.

In the interrupt mode, only interrupt codes shall be sent across the network.

In the interrupt with acknowledgement mode, interrupt codes and interrupt acknowledgement codes shall be sent across the network.

A node or routing switch that supports distributed interrupts shall operate in one of the following modes:

interrupt mode,

interrupt with acknowledgement mode.

A node or routing switch that supports distributed interrupts shall be configurable to operate in one mode or the other.

It is possible for a network to support both interrupt mode and interrupt with acknowledgement mode provided that a particular interrupt is used in the same mode across the whole network.

When operating in the interrupt with acknowledgement mode, there shall be only one interrupt source and only one interrupt acknowledger for a specific interrupt.

In interrupt mode there may be more than one interrupt source for a specific interrupt.

Interrupt codes

An interrupt code shall be used to broadcast an interrupt across the network.

The network layer interrupt code is illustrated in Figure 525.

Bits 0 to 4 of the value field of an interrupt code shall contain an interrupt identifier, which has a value between 0 and 31.

Bit 5 of the value field of an interrupt code shall be 0.

An interrupt code shall be associated with one of 32 possible interrupts as determined by the value of the interrupt identifier in the interrupt code.

Figure 525: Network layer interrupt

Interrupt acknowledgement codes

An interrupt acknowledgement code shall be used to send an acknowledgement to an interrupt back to the source of the interrupt.

Bits 0 to 4 of the value field of an interrupt acknowledgement code shall contain an interrupt identifier.

The interrupt identifier has therefore a value between 0 and 31.

Bit 5 of the value field of an interrupt acknowledgement code shall be 1.

An interrupt acknowledgement code corresponding to an interrupt code with an interrupt identifier of value N (0 ≤ N ≤ 31) shall have an interrupt identifier of value N.

The network layer interrupt acknowledgement code is illustrated in Figure 526.

Figure 526: Network layer interrupt acknowledgement code

Interrupts in a node

A node supporting distributed interrupts shall allow:

sending of interrupt codes, or

receiving of interrupt codes, or

both sending and receiving of interrupt codes.

When a node supports sending of interrupt codes and the host requests an interrupt to be sent, an interrupt code with the interrupt identifier matching the interrupt shall be passed to the data link layer for sending.

If an interrupt is used in interrupt mode and the host system requests to send an interrupt too fast after the previous identical interrupt was sent (i.e. before the corresponding interrupt time-out timer in the routing switches has expired), the new interrupt code that the node sends is discarded by a switch.

When operating in interrupt mode, there should be a minimum interval between a node sending one interrupt code with a particular value and sending the next interrupt with that same value.

The minimum interval time as per to recommendation 5.6.4.4c should be greater than the maximum propagation time of an interrupt code across the network.

This statement is not essential, therefore it is a recommendation, but if an interrupt is sent before the minimum interval, that interrupt can be discarded by a routing switch in the network. Since the same interrupt has already been sent, this should not be a problem at the system level.

When operating in interrupt acknowledgement mode, there shall be a minimum interval between a node sending one interrupt code with a particular value and sending the next interrupt with that same value.

The minimum interval of recommendation 5.6.4.4e should be greater than:

the maximum propagation time of a interrupt code across the network, and

the maximum time for the interrupt acknowledgement code to be generated and return across the network.

If an interrupt is used in interrupt with acknowledgement mode and the host system requests to send an interrupt too fast after the previous identical interrupt was sent (i.e. either before a corresponding interrupt acknowledgement for the previous interrupt was received, or before the received interrupt acknowledgement code has propagated across the entire network), the result is indeterminate for that specific interrupt. The new interrupt code that the node sends can either be discarded by a switch, or repeatedly propagated through the network if the network has circular connections.

When a node supports receiving of interrupt codes, and an interrupt code is passed to the network layer from the data link layer, the host shall be informed that an interrupt matching the interrupt identifier specified in the interrupt code has arrived.

Relaying interrupts with a switch

Each port of a routing switch that supports distributed interrupts shall be configurable to Enabled or Disabled:

the receiving of interrupt codes in through the input port, and

the sending of interrupt codes out of the output port.

When a port of a routing switch is disabled from receiving interrupt codes, the switch shall discard any interrupt codes received on that port.

When a port of a routing switch is disabled from sending interrupt codes, the switch shall not send any interrupt codes on that port.

A routing switch that supports distributed interrupts shall contain one 32-bit interrupt relay register that has one bit for each possible interrupt identifier, where bit N of the register relates to interrupt identifier N.

The interrupt relay register may be less than 32 bits.

On reset the interrupt relay register shall be cleared to zero.

Each bit in the interrupt relay register shall represent the state of a particular distributed interrupt, with bit N corresponding to interrupt identifier N.

Each bit of the interrupt relay register shall have its own interrupt time-out timer.

The interrupt time-out timers shall have a configurable time-out interval.

When operating in the interrupt mode, the interrupt time-out interval shall be configured to a value, TR,

TR shall be higher than the worst case propagation time of the interrupt code in the network.

1	If TR is configured to a too low value, the distributed interrupts cannot work properly.

2	One common value of TR for all switches in a network is sufficient.

When operating in the interrupt acknowledgement mode, the interrupt time-out interval shall be configured to a value, called TRA,

TRA shall be higher than the sum of the following three contributions:

the worst case propagation time of the interrupt code across the network;

the maximum time it takes for a node to generate an interrupt acknowledgement code;

the time it takes for that interrupt acknowledgement code to propagate across the network.

If TR is configured to a too low value, the routing switch resets the corresponding bit of the interrupt relay register before the interrupt acknowledgement propagates across the network and the acknowledgement is therefore lost.

When a port of a routing switch is configured to enable the receiving of interrupt codes and an interrupt code is received on that port, the following actions shall be performed in sequence:

the bit in the interrupt relay register specified by the interrupt identifier value of the received interrupt code is checked;

if the interrupt relay register is less than 32 bits and the specified bit does not exist, the received interrupt code is discarded;

if the specified bit in the interrupt relay register is 0:

the specified bit is set to 1;

the received interrupt code is passed to all ports of the routing switch for onward transmission, except for the port on which the received interrupt code arrived and the ports that are disabled from sending interrupt codes;

the interrupt time-out timer associated with the specified bit in the interrupt relay register is started.

if the specified bit in the interrupt relay register is 1, the received interrupt code is discarded.

This requirement prevents repeated propagation of interrupt codes in networks with circular connections.

When an interrupt time-out timer expires, the corresponding bit in the interrupt relay register shall be reset to 0.

Acknowledged interrupts in a node

A node not supporting distributed interrupts in the interrupt with acknowledgement mode, should:

discard any received interrupt acknowledgement codes, and

discard any host requests to send interrupt acknowledgements.

A node supporting distributed interrupts in the interrupt with acknowledgement mode, shall conform to clause 5.6.4.4.

A node supporting distributed interrupts in the interrupt with acknowledgement mode shall support:

sending of interrupt acknowledgement codes, or

receiving of interrupt acknowledgement codes, or

both sending and receiving of interrupt acknowledgement codes.

An interrupt acknowledgement code with the specified interrupt identifier shall be passed to the data link layer for sending, if the following conditions occur:

the node supports sending of interrupt acknowledgement codes, and

the host requests an interrupt acknowledgement to be sent.

There shall be a delay between the interrupt code arriving and the interrupt acknowledgement being generated.

The delay specified in the requirement 5.6.4.6e, shall be greater than the propagation time of the interrupt code across the network.

1	If the host system tries to send an interrupt acknowledgement too soon after a corresponding interrupt code has been received (i.e. before the interrupt code has propagated across the entire network), the result is indeterminate for that specific interrupt. The new interrupt acknowledgement code that the node sends can either be discarded by a switch, or repeatedly propagated through the network if the network has circular connections.

The delay between the interrupt code arriving and the interrupt acknowledgement being generated shall be less than the time-out interval set in the routing switches minus the time it takes for an interrupt acknowledgement code to propagate across the network.

If the host system is too slow in sending an interrupt acknowledgement after a corresponding interrupt code has been received (i.e. the interrupt acknowledgement code is sent after the corresponding interrupt time-out timer in the routing switches has expired), the interrupt acknowledgement code is discarded by the first switch.

The host shall be informed that an interrupt acknowledgement matching the interrupt identifier in the interrupt acknowledgement code has arrived if the following conditions occur:

the node supports receiving of interrupt acknowledgement codes, and

the interrupt acknowledgement code is passed to the network layer from the data link layer.

Relaying interrupt acknowledgements with a routing switch

A routing switch not supporting distributed interrupts in the interrupt with acknowledgement mode should discard any received interrupt acknowledgement codes.

A routing switch supporting distributed interrupts in the interrupt with acknowledgement mode operates in a similar way to a routing switch supporting the interrupt mode described in clause 5.6.4.5. The main difference is the value, TR or TRA, configured in the interrupt time-out timer.

Each port of a routing switch that supports distributed interrupts in the interrupt with acknowledgement mode shall be configurable to Enabled or Disabled:

the receiving of interrupt acknowledgement codes in through an input port, and

the sending of an interrupt acknowledgement code out of an output port.

When a port of a routing switch is disabled from receiving interrupt acknowledgement codes, it shall discard any interrupt acknowledgement codes received on that port.

When a port of a routing switch is disabled from sending interrupt acknowledgement codes, it shall not send any interrupt acknowledgement codes on that port.

In the interrupt with acknowledgement mode, the interrupt time-out timers shall have a configurable time-out value, TRA.

One common value of TRA for all switches in a network is sufficient.

When operating in the interrupt acknowledgement mode, TRA shall be configured to a value which is greater than the sum of the following contributes:

the worst case propagation time of the interrupt code in the network:

the maximum delay of the interrupt handler, and

the worst case propagation time of the interrupt acknowledgement code in the network.

If TRA is configured to a too low value the distributed interrupts does not work properly.

When a port of a routing switch is configured to enable the receiving of interrupt acknowledgement codes and an interrupt acknowledgement code is received on that port, the following actions shall be performed:

the bit in the interrupt relay register specified by the interrupt identifier value of the received interrupt acknowledgement code is checked;

if the interrupt relay register is less than 32 bits and the specified bit does not exist, the received interrupt acknowledgement code is discarded;

if the specified bit in the interrupt relay register is 1:

the specified bit is reset to 0;

the received interrupt acknowledgement code is passed to all ports of the routing switch for onward transmission, except for the port on which it arrived and those ports that are disabled from sending interrupt acknowledgement codes;

the interrupt time-out timer associated with the specified bit in the interrupt relay register is stopped and set to its time-out value.

If the specified bit in the interrupt relay register is 0, the received interrupt acknowledgement code is ignored.

This requirement prevents repeated propagation of the interrupt acknowledgement codes in networks with circular connections.

As specified in 5.6.4.5, when an interrupt time-out timer expires, the corresponding bit in the interrupt relay register shall be reset to 0.

This reset recovers from the situation when an interrupt acknowledgement is lost for some reason.

SpaceWire nodes

A SpaceWire node shall act as:

a source of packets and broadcast codes sent over a SpaceWire network,

a destination for packets and broadcast codes received over a SpaceWire network, or

both a source and destination of packets and broadcast codes.

A SpaceWire node shall comprise:

one or more end-points each of which provides an interface between one port and the host system, and

zero or more time-code registers.

The UML diagram in Figure 527 illustrates the components and specialisations of a SpaceWire node.

Figure 527: Components and specialisations of a SpaceWire node

An end-point shall comprise:

one host interface, and

one port.

The port included in an end-point shall be one of the following:

a SpaceWire port,

a FIFO port, or

a configuration port.

An end-point shall accept packets from the host system for sending through the port and across the SpaceWire network it is attached to.

An end-point shall pass packets received from the SpaceWire network through its port to the host system.

SpaceWire packets terminated by an EOP or EEP shall be transferred to the host system.

An end-point that is acting as a time-code master shall accept time-codes from the host system for broadcasting over the SpaceWire network via the port.

When two or more end-points in a time-code master node are associated with the same time-code register, they all broadcast a time-code at the same time. This is useful for networks with redundant paths. Time-codes are sent over each of the redundant paths to ensure robustness against one time-code being lost due to an error on a link.

An end-point that supports time-codes shall pass time-codes, received over the SpaceWire network via the port, to the host system.

Each end-point shall be associated with zero or one time-code registers, which is used to validate time-codes when they are received by the end-point.

An end-point that supports distributed interrupts shall pass distributed interrupts, received over the SpaceWire network via the port, to the host system.

An end-point that supports distributed interrupts shall accept interrupt codes and interrupt acknowledgment codes from the host system for broadcasting over the SpaceWire network via the port.

When a node has a configuration port, it shall be connected via a host interface to a configuration application on the host system which is responsible for configuring the node.

SpaceWire node management parameters

A SpaceWire node shall provide the management parameters for the port in each of its end-points as detailed in the following clauses:

Clause 5.5.2 data link layer management parameters

Clause 5.4.10 encoding layer management parameters

Clause 5.3.7 physical layer management parameters

SpaceWire routing

Routing switch

A SpaceWire routing switch shall forward a packet, arriving at one port, towards its required destination node, through another port or back through the same port as determined by the first data character of the packet and the contents of the switching table.

A packet can be forwarded through two or more ports when packet multicast is being used, see clause 5.6.7.10.

A SpaceWire routing switch shall comprise:

One or more ports, which include SpaceWire ports that interface to the SpaceWire network and FIFO ports that provide a parallel interface into the routing switch.

A switching matrix which connects an input port to an output port.

A switching table which together with the leading byte of a packet (the destination address) determines which port a packet is expected to be forwarded through.

A configuration node which is accessible through the routing switch using port address 0 and which is used to configure the routing switch including the switching table and parameters for each SpaceWire port.

Zero or one time-code register which holds the value of the last time-code received.

Zero or one interrupt relay register which indicates which interrupts are currently active.

1	A FIFO port is the means by which parallel interfaces of various forms can be connected into the switch, including large FIFO interfaces, DMA and parallel buses. The term FIFO port is used because it has to contain a small FIFO whatever the nature of the parallel interface is.

2	Requirement 5.6.7.1b.6 means that a SpaceWire switch sees a SpaceWire interrupt as “active”if the interrupt has crossed this switch and has not been cleared yet.

3	The UML diagram in Figure 528 illustrates the components of a SpaceWire routing switch.

A SpaceWire routing switch that has a time-code register shall broadcast valid time codes as detailed in clause 5.6.2.

A SpaceWire routing switch that has an interrupt relay register shall broadcast distributed interrupt codes as detailed in clause 5.6.4.

A configuration node in a routing switch shall be accessed via a configuration port connected to the switching matrix.

Figure 528: Components of a SpaceWire routing switch

Port addressing

A configuration port shall be assigned port address 0.

SpaceWire and FIFO ports shall be assigned port addresses 1-31, so that there is a maximum of 31 external ports on a routing switch.

A routing switch shall use the leading data character of a packet to determine the output port of the routing switch that the packet is expected to be forwarded through.

Path addressing

A leading data character in the range 0 to 31 shall be all or part of a path address which is used to determine the route the packet will take through the network.

Table 58 summarises the function of each address.

When the leading data character of a packet has a value of 0, the packet shall be routed to the routing switch configuration port.

When the leading data character of a packet has a value between 1 and 31, the packet shall be routed to the output port with the corresponding number.

For example, a leading data character with a value of 6 results in the packet being routed to port 6.

A path address shall comprise one or more data characters at the front of a packet; the first data character specifying the output port of the first routing switch encountered by the packet, the second data character the output port of the second routing switch, and so on for all the routing switches on the path through the network from source node to destination node.

When the leading data character is a path address, that data character shall be discarded once is has been used by the routing switch, thus exposing the next data character as the leading data character of the packet ready for use by the next routing switch encountered by the packet.

A routing switch configuration port shall be accessed using path addressing only.

Logical addressing

A leading data character in the range 32 to 255 shall be a logical address which is used to identify the destination node of the packet and in conjunction with the switching table in the routing switch determine which port of the routing switch the packet is expected to be forwarded through.

Table 58 summarises the function of each address.

The switching table in the routing switch shall hold the logical address to physical port mapping and determine whether leading data character deletion is applied.

When the leading data character of a packet has a value of between 32 and 255, that packet shall be routed to the output port that is referred to in the corresponding location of the switching table within the routing switch.

For example, a leading data character with a value of 49 results in entry 49 of the switching table specifying the output port that the packet is to be forwarded through. If entry 49 contains the value 7, the packet is forwarded through port 7.

The logical address 255 shall not be used.

A logical address shall comprise a single data character at the front of a packet which is used by all routing switches on the path from source node to destination node to look up the required output port numbers in their switching tables.

If logical address deletion is being used (see clause 5.6.7.6) it is possible to have more than one logical address at the start of a packet.

When the leading data character is a logical address, that data character shall be retained as the leading data character of the packet once is has been used by the routing switch, so that the same logical address is used by all routing switches encountered by the packet, unless logical address deletion is being used (see clause 5.6.7.6).

When a leading character is deleted by a routing switch only one data character shall be deleted by that routing switch.

Table 58: Address function

Address range	Function	Leading data character deletion
0 0x00	Direct access to internal configuration port.	Always deleted.
1­31 0x01­0x1F	Direct access to physical output ports.	Always deleted.
32-254 0x20­0xFE	Logical address which is mapped to a physical output port via the switching table.	A logical address is not normally deleted. See clause 5.6.7.6 for cases when a logical address is deleted.
255 0xFF	Reserved logical address, which is treated in the same way as any other logical address.	Treated in the same way as a logical address.

Addressing errors

If a port with a specific number does not exist in the routing switch, a packet arriving with a leading data character that references that non-existent port shall be discarded.

A packet arriving with a leading data character that references a non-existent port should result in an invalid address error being registered.

If the entry in the switching table referenced by the leading data character of a packet has not been configured to contain a valid port number, the packet shall be discarded.

A packet arriving with a leading data character that references an entry in the switching table which does not contain a valid port number should result in an invalid address error being registered.

The default behaviour of logical address 255 is the same as other logical addresses. Since logical address 255 is not to be used, a packet arriving with that address is discarded and an invalid address error registered.

Logical address deletion

A routing switch shall be configurable to delete a logical address from the front of the packet (leading data character with a value in the range 32 to 255) before it is forwarded through that port.

When a packet arrives a routing switch shall:

First use the leading data character (logical address) of the packet to determine the output port that the packet is to be forwarded through.

If the switching table entry for the logical address specifies that the logical address is to be deleted, remove the leading data character, exposing another logical address or path address at the front of the packet.

Forward the packet through the allocated port.

The deletion of a logical address is used to expand the number of nodes that can be accessed using logical addressing. A large network is divided into regions where a logical address applies. When crossing a boundary between regions, the logical address is deleted exposing a new logical address that applies to the next region. Regions using logical addressing can be connected to regions using path addressing.

Wormhole routing

When a packet arrives at a routing switch the output port that is expected to be routed through shall be determined and allocated to that input port.

If the allocated output port is able to accept the start of another packet, the input port shall be connected to the output port so that the packet arriving at the input port is forwarded through the output port.

As each N-Char of the packet arrives at the input port it shall be transferred to the output port it is connected to for transmission.

An output port shall not transmit any other packet until the packet that it is currently transmitting has finished being sent or terminated following an error.

If an input port is waiting for packet characters to arrive, the output port that it is connected to shall also wait.

If an output port is waiting for FCTs to transmit packet characters, the input port it is connected to shall also wait.

If the allocated output port is busy, the newly arrived packet shall wait at the input port until the allocated output port is free to transmit the new packet.

When the output port finishes transmission of a packet, it shall be available to accept a packet from another input port.

Arbitration

When two or more input ports have been allocated to the same output port and that output port has just finished sending a packet, the two or more input ports shall compete for connection to the output port.

The routing switch shall arbitrate between the two or more input ports competing for access to an output port and decide which input port is to be connected to the output port and send the next packet through it.

When the allocated output port becomes free, the input port connected to it after arbitration shall transfer one packet to the output port and then free the output port for subsequent arbitration and use by the same or another input port.

Group adaptive routing

Group adaptive routing shall be optional in a routing switch.

A routing switch that supports group adaptive routing shall be able to route a packet with a logical address to one of several ports which is known as group adaptive routing.

A routing switch that supports group adaptive routing shall:

have entries for each logical address in the switching table which specify one or more output ports that a packet with that logical address is able to be routed to;

route a packet arriving with a leading data character that is a logical address to one port, from the set of ports specified in the switching table, which is currently free;

arbitrate between all the input ports waiting to use the specified output ports as each of these output ports becomes free when all the set of output ports specified for a logical address is currently sending packets;

connect it to the output port that it competed for, when an input port wins the arbitration.

A port is free if it is not currently being used to send a packet.

Packet multicast

Implementation of packet multicasting for a routing switch shall be optional.

Use of packet multicasting is dangerous as it introduces many ways to block or deadlock sections of the network.

The switching table in the routing switch supporting packet multicast shall be configurable to specify the set of ports (multicast set) that a packet with a particular logical address is to be concurrently sent through;

In a routing switch supporting packet multicast, when a packet arrives with a logical address that is configured for multicast, the packet shall be sent to each of the output ports in the multicast set;

In a routing switch supporting packet multicast, the packet to be multicast is sent to the designated output ports only after all of them are ready to accept a new packet;

In a routing switch supporting packet multicast, if one or more of the output ports in the multicast set is not ready, all the output ports shall wait.

In a routing switch supporting packet multicast, if one or more of the output ports in the multicast set is not ready, the packet shall not be sent to any of the multicast output ports until they are all ready.

When one or more of the ports in the multicast set are disabled, the routing switch should continue to forward packets to other ports in that multicast set.

Routing switch reset

On reset of a routing switch the following shall occur, in sequence

all ports are reset;

entries in the switching table for all logical addresses are set to not valid;

group adaptive routing is disabled;

packet multicast is disabled.

Thus a packet arriving with that logical address is discarded, until the corresponding entry in the switching table is configured.

Port time-out

A configurable port time-out should be provided in the routing switch.

The port time-out is used by all ports to detect a packet that has become stuck.

A separate configurable port time-out may be used for each port.

A packet shall be regarded by a port as being stuck when the following conditions are all fulfilled:

it has started;.

it has not yet ended;

the time since the last data character was sent from the input port to the output port is longer than the port time-out period.

This requirement implies that the first data character of the packet has been passed to the output port, and that the EOP or EEP for that packet has not yet been passed to the output port.

When a packet is stuck in a routing switch that supports port time-outs, the following actions, in sequence, shall be taken to clear the stuck packet:

the packet currently being sent is discarded;

an EEP is sent to the output port.

When a packet is stuck in a routing switch that supports port time-outs, this information should be registered.

This recommendation allows a management application to be informed about the error on the packets by reading the configuration space of the routing switch.

It shall be possible to disable the port time-out.

This requirement guarantees that the possibility for the port not to time-out when a packet is stuck.

SpaceWire routing switch management parameters

The management parameters of a SpaceWire routing switch shall be accessed via the routing switch configuration port.

A SpaceWire routing switch shall provide the management parameters for each of its ports as detailed in the following clauses:

Clause 5.5.2 - data link layer management parameters;

Clause 5.4.10 - encoding layer management parameters;

Clause 5.3.7 - physical layer management parameters.

The switching table in a routing switch shall be configurable via the routing switch configuration port.

The port time-out timer for each port shall be configurable via the routing switch configuration port.

The distributed interrupt parameters for each port shall be configurable via the routing switch configuration port.

SpaceWire network

A SpaceWire network shall comprise one or more nodes and zero or more routing switches interconnected with SpaceWire links.

The UML diagram in Figure 529 illustrates the components of a SpaceWire network.

Figure 529: Components of a SpaceWire network

A SpaceWire network shall send packets from each source node to one or more destination nodes.

Packets from a source node shall travel through a SpaceWire link to a routing switch or the destination node.

Packets from a routing switch shall travel across SpaceWire links to other routing switches or to a destination node.

A SpaceWire network shall support broadcast of time-codes and distributed interrupt codes as an option.

It is not necessary for a SpaceWire network to support time-codes and distributed interrupt codes.

For test purposes it should be possible to loop a port back on itself.

SpaceWire units

SpaceWire units

A SpaceWire unit shall comprise zero or more nodes and zero or more routing switches.

A SpaceWire unit shall comprise at least one node or routing switch.

The components of a SpaceWire unit are illustrated in the UML diagram of Figure 530.

Figure 530: Components and specialisations of a SpaceWire unit

A SpaceWire unit shall contain an application which uses the services of a SpaceWire network.

Examples of a SpaceWire unit include a routing switch, an instrument with a SpaceWire interface, a processor with a SpaceWire interface and a mass memory with either an internal SpaceWire network connecting memory modules or external SpaceWire interfaces.

SpaceWire management layer

SpaceWire management layer services

A means shall be provided for a user application in a node to configure and control that node.

A means shall be provided for a user application in a node to read the current configuration, control and status information of that node.

A means shall be provided for a configuration port in a routing switch to configure and control that switch.

A means shall be provided for a configuration port in a routing switch to read the current configuration, control and status information of that switch.

Physical layer management parameters

The physical layer management parameters are detailed in clause 5.3.7.

Encoding layer management parameters

The encoding layer management parameters are detailed in clause 5.4.8.

Data link layer management parameters

The data link layer management parameters are detailed in clause 5.5.2.

Network layer management parameters

The network layer management parameters for a node are detailed in clause 5.6.6. The network layer management parameters for a routing switch are detailed in clause 5.6.8.

Service interfaces requirements

Overview

Clause 6 details the specification of the service interfaces for the services provided by each of the SpaceWire protocol layers. In particular:

Clause 6.2 specifies the services provided by the SpaceWire Network layer to the SpaceWire user application.

Clause 6.3 specifies the services provided by the SpaceWire data link layer to the SpaceWire network layer.

Clause 6.4 specifies the services provided by the encoding layer to the data link layer are specified.

Clause 6.5 specifies the services provided by the physical layer to the encoding layer.

Clause 6.6 specifies the services provided by the SpaceWire management layer to the SpaceWire user application.

Network layer service interface

Packet service interface

General

The service primitives that shall be associated with the SpaceWire packet service are:

SEND_PACKET.request;

RECEIVE_PACKET.indication.

SEND_PACKET.request

Function

The SEND_PACKET.request primitive shall be used to send a SpaceWire packet across a SpaceWire network.

Semantics

The SEND_PACKET.request primitive shall provide the following parameters:

SEND_PACKET.request (End-point, SpaceWire Packet)

When Generated

When the user has a packet to send over the SpaceWire network, it shall generate a SEND_PACKET.request primitive to request to send the SpaceWire packet over the network.

Effect On Receipt

On receipt of the SEND_PACKET.request primitive, the SpaceWire end-point receiving the request shall send the SpaceWire packet though its port.

RECEIVE_PACKET.indication

Function

A SpaceWire end-point receiving a SpaceWire packet shall pass a RECEIVE_PACKET.indication primitive to the Read SpaceWire Packet service user to indicate that a SpaceWire packet has arrived at the end-point and is waiting to be read.

Semantics

The RECEIVE_PACKET.indication primitive shall provide parameters as follows:

RECEIVE_PACKET.indication (End-point, SpaceWire Packet).

When Generated

The RECEIVE_PACKET.indication primitive shall be passed to the Receive Packet Service user when a SpaceWire packet is received.

Effect On Receipt

When a Receive Packet Service user receives a RECEIVE_PACKET.indication primitive, the service user shall read the received SpaceWire packet.

Time-code service interface

General

The service primitives that shall be associated with the time-code service are:

TIME-CODE.request;

TIME-CODE.indication;

TIME-CODE.request

Function

The TIME-CODE.request primitive shall be used by the SpaceWire user to request a SpaceWire end-point to broadcast a time-code over the SpaceWire network.

Semantics

The TIME-CODE.request primitive shall provide the following parameters:

TIME-CODE.request (End-point, Time-code value).

When Generated

When the SpaceWire user wants to broadcast a time-code, it shall generate a TIME-CODE.request primitive to request one or more SpaceWire end-points belonging to the node to send the time-code through its SpaceWire port.

Effect On Receipt

On receipt of the TIME-CODE.request primitive the SpaceWire end-point shall send the time-code through its SpaceWire port.

TIME-CODE.indication

Function

The TIME-CODE.indication primitive shall indicate to the SpaceWire user that a valid time-code has arrived at an end-point.

Semantics

The TIME-CODE.indication primitive shall provide the following parameters:

TIME-CODE.indication (End-point, Time-code value)

When Generated

The TIME-CODE.indication primitive shall be passed to the SpaceWire user, when a valid time-code is received.

Effect On Receipt

The effect on receipt of the TIME-CODE.indication primitive by the SpaceWire user shall be application dependent.

Distributed interrupt service interface

General

The service primitives that shall be associated with the distributed interrupt service are:

DISTRIBUTED_INTERRUPT.request;

DISTRIBUTED_INTERRUPT.indication;

DISTRIBUTED_INTERRUPT_ACK.request;

DISTRIBUTED_INTERRUPT_ACK.indication.

DISTRIBUTED_INTERRUPT.request

Function

The DISTRIBUTED_INTERRUPT.request primitive shall be used by the SpaceWire user to request a SpaceWire end-point to send an interrupt code over the SpaceWire network.

Semantics

The DISTRIBUTED_INTERRUPT.request primitive shall provide the following parameters:

DISTRIBUTED_INTERRUPT.request (End-point, Interrupt Identifier).

When Generated

When the SpaceWire user has a distributed interrupt to send it shall generate a DISTRIBUTED_INTERRUPT.request primitive to request a SpaceWire end-point to send the interrupt code.

Effect On Receipt

On receipt of the DISTRIBUTED_INTERRUPT.request primitive, the SpaceWire end-point shall immediately send the interrupt code through its port.

DISTRIBUTED_INTERRUPT.indication

Function

The DISTRIBUTED_INTERRUPT.indication primitive shall indicate to the SpaceWire user that an interrupt code has arrived at an end-point.

Semantics

The DISTRIBUTED_INTERRUPT.indication primitive provides parameters as follows:

DISTRIBUTED_INTERRUPT.indication (End-point, Interrupt Identifier)

When Generated

The DISTRIBUTED_INTERRUPT.indication primitive shall be passed to the SpaceWire user, when a valid interrupt code is received.

Effect On Receipt

The effect on receipt of the DISTRIBUTED_INTERRUPT.indication primitive by the SpaceWire user shall depend upon the application.

An application which is not sensitive to the received Distributed Interrupt can simply not take any action. Another application can acknowledge Distributed Interrupt and then trigger some action.

DISTRIBUTED_INTERRUPT_ACK.request

Function

The DISTRIBUTED_INTERRUPT_ACK.request primitive shall:

clear a distributed interrupt in the receiving node, or

clear the distributed interrupt from the entire network when distributed interrupt acknowledgments are being used.

Semantics

The DISTRIBUTED_INTERRUPT_ACK.request primitive provides parameters as follows:

DISTRIBUTED_INTERRUPT_ACK.request (End-point, Interrupt Identifier)

When Generated

When a distributed interrupt has been received by a node and passed to the host system, the host system shall acknowledge receipt of the distributed interrupt by generating the DISTRIBUTED_INTERRUPT_ACK.request primitive to request an end-point to clear the distributed interrupt.

Effect On Receipt

On receipt of the DISTRIBUTED_INTERRUPT_ACK.request primitive, the SpaceWire end-point shall clear the distributed interrupt and, if distributed interrupt acknowledgements are enabled, send a interrupt acknowledgement code to clear that distributed interrupt from the entire network.

DISTRIBUTED_INTERRUPT_ACK.indication

Function

The DISTRIBUTED_INTERRUPT_ACK.indication primitive shall indicate to the SpaceWire user that an interrupt acknowledgement code has been received.

Semantics

The DISTRIBUTED_INTERRUPT_ACK.indication primitive shall provide parameters as follows:

DISTRIBUTED_INTERRUPT_ACK.indication (End-point, Interrupt Identifier)

When Generated

The DISTRIBUTED_INTERRUPT_ACK.indication primitive shall be passed to the SpaceWire user, when a valid interrupt acknowledgement code is received.

Effect On Receipt

The effect on receipt of the DISTRIBUTED_INTERRUPT_ACK.indication primitive by the SpaceWire user shall depend upon the application.

An application which is not sensitive to the received Distributed Interrupt Acknowledgement can simply not take any action. Another application can take some decision/action on the basis of the fact that the Distributed Interrupt was acknowledged (by another node).

Data link layer service interface

N-Char service interface

General

The following service primitives shall be associated with the N-Char service:

SEND_NCHAR.request;

READ_NCHAR.request.

SEND_NCHAR.request

Function

The SEND_NCHAR.request primitive shall be used to send an N-Char through a port across a link.

Semantics

The SEND_NCHAR.request primitive shall provide the following parameters:

SEND_NCHAR.request (Port, N-Char)

When Generated

When the SpaceWire network layer has an N-Char to send over through a port, it shall generate a SEND_NCHAR.request primitive to request to load the N-Char into that port for sending over the link.

Effect On Receipt

On receipt of the SEND_NCHAR.request primitive the SpaceWire port receiving the request shall send the N-Char, provided that the link is in the Run state.

READ_NCHAR.request

Function

The READ_NCHAR.request primitive shall be used to read an N-Char received by a port.

Semantics

The READ_NCHAR.request primitive provides parameters as follows:

READ_NCHAR.request (N-Char).

When Generated

When the network layer is ready to read an N-Char from a port, it shall generate a READ_NCHAR.request primitive to request to read a received N-Char from the port.

Effect On Receipt

The effect on receipt of the READ_NCHAR.request primitive by the data link layer shall be that an N-Char from the specified port shall be read by the network layer.

Broadcast code service interface

General

The following service primitives shall be associated with the BROADCAST_CODE service:

BROADCAST_CODE.request;

BROADCAST_CODE.indication.

BROADCAST_CODE.request

Function

The BROADCAST_CODE.request primitive shall be used by the network layer to request a port to broadcast a broadcast code over the SpaceWire network.

Semantics

The BROADCAST_CODE.request primitive shall provide the following parameters:

BROADCAST_CODE.request (Port, Broadcast code value).

When Generated

When the network layer wants to send a broadcast code through a port it shall generate a BROADCAST_CODE.request primitive to request the port to send the broadcast code.

Effect On Receipt

On receipt of the BROADCAST_CODE.request primitive the port shall send the broadcast code immediately after the character current has finished being sent.

BROADCAST_CODE.indication

Function

The function of the BROADCAST_CODE.indication primitive shall be to indicate to the network layer that a broadcast code has arrived at a port.

Semantics

The BROADCAST_CODE.indication primitive provides parameters as follows:

BROADCAST_CODE.indication (Port, Broadcast code value)

When Generated

The BROADCAST_CODE.indication primitive shall be passed to the network layer, when the broadcast code is received.

Effect On Receipt

When the network layer receives the BROADCAST_CODE.indication primitive, the network layer shall, in sequence:

validate the broadcast code,

forward the broadcast code to the host system attached to an end-point, or

forward the broadcast code to all other ports of a routing switch.

Encoding layer service interface

Encoding service interface

General

The following service primitives shall be associated with the encoding service:

TX_CHAR.request;

TX_ENABLE.request.

TX_CHAR.request

Function

The TX_CHAR.request primitive shall be used by the data link layer to send a character through its output port.

Semantics

The TX_CHAR.request primitive shall provide the following parameters:

TX_CHAR.request (Character).

When Generated

When the data link layer wants to send a character through its output port it shall generate a TX_CHAR.request primitive to encode the character, serialise it and send it through its output port.

Effect On Receipt

On receipt of the TX_CHAR.request primitive the encoding layer shall encode the character, serialise it, data-strobe encode it, and pass it to the physical layer for driving across the physical medium to the receiver at the far end of the link.

TX_ENABLE.request

Function

The TX_ENABLE.request primitive shall be used by the data link layer to request that the output port is enabled.

Semantics

The TX_ENABLE.request primitive shall have no parameters:

TX_ ENABLE.request ().

When Generated

When the data link layer wants to enable the output port so that it can make a connection and send data, it shall generate a TX_ENABLE.request primitive.

Effect On Receipt

On receipt of the TX_ENABLE.request primitive the encoding layer shall enable its output port.

Decoding service interface

General

The service primitives that shall be associated with the decoding service are:

RX_CHAR.request;

RX_ENABLE.request;

DISCONNECT.indication;

RECEIVE_ERROR.indication;

gotNULL.indication.

RX_CHAR.request

Function

The RX_CHAR.request primitive shall be used by the data link layer to receive a character through its input port.

Semantics

The RX_CHAR.request primitive shall provide the following parameters:

RX_CHAR.request.

When Generated

When the data link layer wants to read a character from its input port it shall generate a RX_CHAR.request primitive to read the next character received by the input port.

Effect On Receipt

On receipt of the RX_CHAR.request primitive, the encoding layer shall pass a received, de-serialised and decoded character to the data link layer.

RX_ENABLE.request

Function

The RX_ENABLE.request primitive shall be used by the data link layer to enable the input port to receive characters and control codes.

Semantics

The RX_ENABLE.request primitive shall not have any parameters:

RX_ENABLE.request ()

When Generated

When the data link layer wants to enable its input port it shall generate a RX_ENABLE.request primitive.

Effect On Receipt

On receipt of the RX_ENABLE.request primitive, the encoding layer shall enable its input port.

DISCONNECT.indication

Function

The DISCONNECT.indication primitive shall indicate to the data link layer that the SpaceWire link is disconnected.

Semantics

The DISCONNECT.indication primitive shall not have any parameters:

DISCONNECT.indication ()

When Generated

The DISCONNECT.indication primitive shall be passed to the data link layer, when the SpaceWire link becomes disconnected.

Effect On Receipt

On receipt of the DISCONNECT.indication primitive, the data link layer shall move to the ErrorReset state.

RECEIVE_ERROR.indication

Function

The RECEIVE_ERROR.indication primitive shall indicate to the data link layer that an error has occurred in the receiver.

Semantics

The RECEIVE_ERROR.indication primitive shall provide the following parameters:

RECEIVE_ERROR.indication (RX_Error_Flags).

The RX_Error_Flags shall indicate the type of error:

parity error, or

ESC error.

When Generated

The RECEIVE_ERROR.indication primitive shall be passed to the data link layer, when a receive error occurs.

Effect On Receipt

On receipt of the RECEIVE_ERROR.indication primitive, the data link layer shall move to the ErrorReset state.

gotNULL.indication

Function

The gotNULL.indication primitive shall indicate to the data link layer that the first Null has been received, after the receiver has been enabled.

Semantics

The gotNULL.indication primitive shall not have any parameters:

gotNULL.indication ()

When Generated

The gotNULL.indication primitive shall be passed to the data link layer, when the first Null is received without any errors after the receiver has been enabled.

Effect On Receipt

The effect on receipt of the gotNULL.indication primitive by the data link layer shall be according to the state machine specified in clause 5.5.6.

Physical layer service interface

Line transmit service interface

General

The following service primitives shall be associated with the line transmit service:

DS_TX.request.

DS_TX.request

Function

The DS_TX.request primitive shall be used by the encoding layer to drive the data and strobe signals on to the physical medium.

Semantics

The DS_TX.request primitive shall provide the following parameters:

DS_TX.request (Data, Strobe).

When Generated

When the encoding layer wants to drive the data and strobe signals over the physical medium, it shall generate a DS_TX.request primitive.

Effect On Receipt

On receipt of the DS_TX.request primitive, the physical layer shall drive the data and strobe signals over the physical medium to the line receiver at the far end of the link.

Line receive service interface

General

The service primitives that shall be associated with the line receive service are:

DS_RX.request.

DS_RX.request

Function

The DS_RX.request primitive shall be used by the encoding layer to receive data and strobe signals from the line receiver.

Semantics

The DS_RX.request primitive shall not have any parameters:

DS_RX.request ()

When Generated

When the encoding layer wants to read the data and strobe signals received over the physical medium by the line receiver, it shall generate a DS_RX.request primitive.

Effect On Receipt

On receipt of the DS_RX.request primitive the physical layer shall pass the data and strobe signals received over the physical medium to the encoding layer.

Management layer service interface

Set parameter service interface

General

The following service primitives shall be associated with the set parameter service:

SET_PARAMETER.request.

SET_PARAMETER.request

Function

The SET_PARAMETER.request primitive shall be used to write a value to a SpaceWire management parameter.

Semantics

The SET_PARAMETER.request primitive shall provide the following parameters:

SET_PARAMETER.request (Management Parameter, Value)

When Generated

When a SpaceWire user application has to configure or control the SpaceWire unit, it shall generate a SET_PARAMETER.request primitive to request to write a new value into a specified configuration or control register.

Effect On Receipt

On receipt of the SET_PARAMETER.request primitive, the management layer shall write the specified value into the specified configuration or control register.

Get parameter service interface

General

The service primitive that shall be associated with the get parameter service is:

GET_PARAMETER.request.

GET_PARAMETER.request

Function

The GET_PARAMETER.request primitive shall be used to read the current value of a SpaceWire management parameter.

Semantics

The GET_PARAMETER.request primitive shall have the following parameters:

GET_PARAMETER.request (Management Parameter).

When Generated

When a SpaceWire user application wants to read the current status or to check the value of a management parameter, it shall generate a GET_PARAMETER.request primitive to request to read the specified management parameter.

Effect On Receipt

On receipt of the GET_PARAMETER.request primitive, the management layer shall read the specified Management Parameter and return this value to the user application.

(informative)
Measurement of Data-Strobe Skew and Jitter

Introduction

It is useful to break the performance specification for a SpaceWire link down into separate components, as illustrated in Figure A-1:

source logic;

driver;

connections from driver to unit connector;

cable assembly;

connections from unit connector to receiver;

receiver and destination logic.

: Physical layer components

Transmitter specifications

The following specifications are provided for the source logic, the logic generating the data and strobe signals, over the required temperature and radiation total dose limits:

Source logic worst case differential skew (DDskewSL), which is the maximum absolute difference between the differential low to high propagation time (TPLHD) and the differential high to low propagation time (TPHLD) of the data and strobe signals coming from the source logic.

Source logic worst case Data to Strobe skew (DSskewSL), which is the maximum absolute difference in differential delay between the data and strobe signals coming from the source logic.

This information is normally provided by the chip designer or manufacturer.

The following driver specifications are measured using the circuit illustrated in Figure A-2 over the required temperature and radiation total dose limits:

Driver worst case differential skew (DDskewTX), which is the maximum absolute difference between the differential low to high propagation time (TPLHD) and the differential high to low propagation time (TPHLD).

Driver worst case channel to channel skew (DSskewTX), which is the maximum absolute difference in differential delay between one channel of a driver device and another channel in that same device.

This information is normally provided by the driver manufacturer.

: Driver measurement circuit

Only drivers in the same chip ought to be used for a SpaceWire link.

This removes the need to allow for chip to chip variation in skew.

The unit supplier provides the specification for the worst case skew between the differential data and strobe signals from the driver across the PCB, to the contacts of the connector including any leads from the PCB to those contacts (DSskewTXPCB).

This is normally determined from the mismatch between the length of the data signals and the length of the strobe signals, multiplied by the speed that the signals travel across the PCB. The mismatch in the lengths of the wires from the PCB to the connector contact are also to be taken into account.

The unit supplier provides the specification for the worst case differential jitter (JitterTX) on the data and strobe transmit signals (Dout and Sout) at the connector of the unit under the following conditions:

The unit generates a repeating sequence of the following set of SpaceWire packets without any Nulls between the data characters:

SpaceWire packet of length greater than 1000 bytes containing a PRBS-15 pseudorandom bit sequence;

SpaceWire packet of length greater than 1000 bytes all set to 0x55;

The differential signals are terminated by a (100 Ω ±1) Ω resistor, as illustrated in Figure A-3.

The measurement is made with an oscilloscope and differential probe which have a combined bandwidths of at least 1,05/(signal rise time).

The fastest signal rise time for LVDS is specified in TIA-644-A to be 260 ps, so the corresponding oscilloscope and probe bandwidth is 4 GHz.

The measurement is made at room temperature;

The measurement is made at the 0 V differential point as illustrated in Figure A-4.

: Unit transmit jitter measurement circuit

: Jitter measurement on oscilloscope

The worst case data to strobe skew of the transmitter including jitter effects (DSskewOUT) is given by the sum of the following:

Worst case of absolute DDskewSL or absolute DSskewSL;

Worst case of absolute DDskewTX or absolute DSskewTX;

DSskewTXPCB;

JitterTX.

Cable assembly specifications

The cable assembly manufacturer provides the worst case skew between the differential data and strobe signals (DSskewCA).

This maximum permitted value for the differential data to strobe skew in a cable is given by the cable assembly inter-pair skew which is specified in clause 5.3.3.3.

The cable assembly manufacturer measures the worst case differential jitter of the data and strobe transmit signals after propagation through the cable assembly (JitterCA) under the following conditions:

a generator generates a repeating sequence of the following set of SpaceWire packets sent without any Nulls between the data characters:

SpaceWire packet of length greater than 1000 bytes containing a PRBS-15 pseudorandom bit sequence;

SpaceWire packet of length greater than 1,000 bytes all set to 0x55.

the differential signals are terminated by a (100 ±1) Ω resistor, as illustrated in Figure A-5;

the receive signal jitter is measured across the termination resistor using an oscilloscope and differential probes which have bandwidths of at least 1,05 times the inverse of the signal rise time;

The fastest signal rise time for LVDS is specified in TIA-644-A to be 260 ps, so the corresponding oscilloscope and probe bandwidth is 4 GHz.

the measurement is made at room temperature;

the measurement is made at the 0 V differential point as illustrated in Figure A-4.

the measurement is made for each length of cable assembly being provided and at the following data rates: 10 Mbits/s, 20 Mbits/s, 50 Mbits/s, 100 Mbits/s, 200 Mbits/s, 300 Mbits/s and 400 Mbit/s.

Maybe a single measurement made for each length of cable at a set frequency is sufficient, but this needs to be determined.

: Cable assembly jitter measurement circuit

Receiver specifications

The unit manufacturer provides the specification for the worst case skew between the differential data and strobe signals (DSskewRXPCB) from the contacts of the connector, across the PCB, to the receiver.

This is normally determined from the mismatch between the length of the data signals and the length of the strobe signals, multiplied by the speed that the signals travel across the PCB. The mismatch in the lengths of the wires from the connector contact to the PCB are also to be taken into account.

The following receiver specifications are measured using the circuit illustrated in Figure A-6 over the required temperature and radiation total dose limits:

differential skew (DDskewRX), which is the absolute difference between the differential low to high propagation time (TPLHD) and the differential high to low propagation time (TPHLD);

channel to channel skew (DSskewRX), which is the difference in differential delay between one channel of a driver device and another channel in that same device.

This information is normally provided by the driver manufacturer.

: Receiver measurement circuit

Only receivers in the same chip ought to be used for a SpaceWire link.

This removes the need to allow for chip to chip variation in skew.

The following specifications are provided for the destination logic, the logic that uses the received data and strobe signals to recover the data stream, over the required temperature and radiation total dose limits:

Minimum separation between one Data edge and another Data edge or between one Strobe edge and another Strobe edge (DDminsepDL) that can be tolerated by the destination logic.

Minimum separation between a Data edge and a Strobe edge or between one Strobe edge and a Data edge (DSminsepDL) that can be tolerated by the destination logic.

This information is normally provided by the chip designer or manufacturer.

The minimum acceptable edge separation by the destination logic (MinsepDL) is the larger of DDminsepDL and DSminsepDL.

The worst case minimum edge separation is given including jitter effects (Minsep) is given by the following:

MinsepDL;

Minus worst case of absolute DDskewRX or absolute DSskewRX;

Minus DSskewRXPCB;

JitterTX.

Maximum data signalling rate

The maximum data signalling rate of the SpaceWire link is less than the inverse of the minimum bit unit interval, TUIMIN, where TUIMIN is 1,1 times the sum of the following:

Source Logic differential D-S skew, DSskewSL;

Driver channel to channel differential skew, DSskewTX;

Transmitting unit PCB differential D-S skew, DSskewTXPCB;

Transmitter unit jitter, JitterTX;

Cable assembly differential D-S skew, DSskewCA;

Cable assembly jitter, JitterCA;

Receiving unit PCB differential D-S skew, DSskewRXPCB;

Receiver channel to channel differential skew, DSskewRX;

Destination logic minimum tolerated separation between a data edge and a strobe edge, DSminsepDL.

1	The factor of 1,1 is included to provide a 10% margin.

2	A table giving an example calculation is provided in Table A-1.

: Example calculation of maximum data signalling rate

Factor	Abbreviation	Value (ps)	Sum (ps)
Source Logic differential D-S skew	DSskewSL	500	500
Driver channel to channel differential skew (e.g. UT54LVDS031LV)	DSskewTX	400	900
Transmitting unit PCB differential D-S skew (e.g. 5 mm PCB length difference)	DSskewTXPCB	34	934
Transmitter unit jitter	JitterTX	300	1234
Transmitting unit skew and jitter	DSskewOUT	1234
Cable assembly differential D-S skew (e.g. 5 m)	DSskewCA	500	1734
Cable assembly jitter	JitterCA	500	2234
Receiving unit PCB differential D-S skew (e.g. 5 mm PCB length difference)	DSskewRXPCB	34	2268
Receiver channel to channel differential skew (e.g. UT54LVDS032LV)	DSskewRX	350	2618
Destination logic minimum tolerated separation between a data edge and a strobe edge	DSminsepDL	1000	3618
Receiving unit minimum edge separation	DSminsepIN	1384
10% Margin	Margin	362	3980
Minimum Bit Unit Interval	TUIMIN	3980
Maximum bit rate	251 Mbits/s

The maximum operating frequency of the SpaceWire link is also less than the inverse of 1,1 times the sum of the following:

Source Logic differential D-D or S-S skew, DDskewSL;

Driver differential skew, DDskewTX;

Transmitter unit jitter, JitterTX;

Cable assembly jitter, JitterCA;

Receiver differential skew, DDskewRX;

Destination logic minimum tolerated separation between one data edge and the next data edge, or between one strobe edge and the next strobe edge, SEPDD.

This maximum operating frequency determined in this statement is normally much higher than that determined by statement A.5a.

Bibliography

[1]	Open Systems Interconnection, ISO/IEC 7498-1
[2]	The Transputer Databook, Inmos, 1988.
[3]	The T9000 Transputer Hardware Reference Manual, Inmos Limited, 1993 (available at http://www.transputer.net/ibooks/72-trn-238-01/t9000hrm.pdf)
[4]	IEEE Computer Society, “IEEE Standard for Heterogeneous Interconnect (HIC) (Low-Cost, Low-Latency Scalable Serial Interconnect for Parallel System Construction)”, IEEE Standard 1355-1995, IEEE, June 1996.
[5]	Welch, P.H., May, M.D. and Thompson, P.W., Networks, Routers and Transputers: Function, Performance and Application. IOS Press, Netherlands, 1993 (available at http://www.csp-consortium.org/apps/Networks, Routers and Transputers.pdf)