EN 16603-50-52:2014

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Vesoljska tehnika - SpaceWire - Protokol za daljinski dostop do pomnilnikaRaumfahrttechnik - SpaceWire - Protokoll zum ferngesteuerten SpeicherzugriffIngénierie spatiale - SpaceWire - protocole d'accès à distance à la mémoireSpace engineering - SpaceWire - Remote memory access protocol49.140Vesoljski sistemi in operacijeSpace systems and operationsICS:Ta slovenski standard je istoveten z:EN 16603-50-52:2014SIST EN 16603-50-52:2014en,fr,de01-november-2014SIST EN 16603-50-52:2014SLOVENSKI
STANDARD
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 16603-50-52
September 2014 ICS 49.140
English version
Space engineering - SpaceWire - Remote memory access protocol
Ingénierie spatiale - SpaceWire - protocole d'accès à distance à la mémoire
Raumfahrttechnik - SpaceWire - Protokoll zum ferngesteuerten Speicherzugriff This European Standard was approved by CEN on 1 March 2014.
CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN and CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the same status as the official versions.
CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.
CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels © 2014 CEN/CENELEC All rights of exploitation in any form and by any means reserved worldwide for CEN national Members and for CENELEC Members. Ref. No. EN 16603-50-52:2014 E SIST EN 16603-50-52:2014

2 Table of contents Foreword . 7 1 Scope . 8 2 Normative references . 9 3 Terms, definitions and abbreviated terms . 10 3.1 Terms defined in other standards . 10 3.2 Terms specific to the present standard . 10 3.3 Abbreviated terms. 10 3.4 Conventions. 11 4 Principles . 12 4.1 Remote Memory Access Protocol (RMAP) purpose . 12 4.2 Guide to clause 5 . 12 4.3 RMAP operations. 13 4.3.1 Introduction . 13 4.3.2 Write commands . 13 4.3.3 Read commands . 14 4.3.4 Read-modify-write . 14 5 Requirements . 15 5.1 RMAP command and reply fields . 15 5.1.1 Target SpaceWire Address field . 15 5.1.2 Target Logical Address field . 15 5.1.3 Protocol Identifier field . 15 5.1.4 Instruction field . 16 5.1.5 Key field . 17 5.1.6 Reply Address field . 17 5.1.7 Initiator Logical Address field . 19 5.1.8 Transaction Identifier field . 19 5.1.9 Extended Address field . 19 5.1.10 Address field . 19 5.1.11 Data Length field . 20 SIST EN 16603-50-52:2014

4 B.2.3 WRITE.confirmation . 89 B.2.4 Target . 90 B.2.5 WRITE.authorisation.indication . 90 B.2.6 WRITE.authorisation.response . 91 B.2.7 WRITE.data.indication . 91 B.2.8 WRITE.data.response . 92 B.2.9 WRITE.indication . 92 B.3 Read Service . 93 B.3.1 Initiator . 93 B.3.2 READ.request . 93 B.3.3 READ.confirmation . 93 B.3.4 Target . 94 B.3.5 READ.authorisation.indication . 94 B.3.6 READ.authorisation.response . 95 B.3.7 READ.data.indication . 95 B.3.8 READ.data.response . 96 B.3.9 READ.indication . 96 B.4 Read-Modify-Write Service . 97 B.4.1 Initiator . 97 B.4.2 RMW.request . 97 B.4.3 RMW.confirmation. 97 B.4.4 Target . 98 B.4.5 RMW.authorisation.indication . 98 B.4.6 RMW.authorisation.response . 99 B.4.7 RMW.read.data.indication . 99 B.4.8 RMW.read.data.response . 100 B.4.9 RMW.write.data.indication . 100 B.4.10 RMW.write.data.response . 101 B.4.11 RMW.indication . 102 Annex C (informative) Mapping to CCSDS SOIS Remote memory access service . 103 Bibliography . 108
Figures Figure 5-1: Write Command format . 23 Figure 5-2: Write Reply format . 26 Figure 5-3: Write Command/Reply sequence . 28 SIST EN 16603-50-52:2014

Figure B-1 : SOIS communication architecture . 88 Figure C-1 : RMAP model . 103 Figure C-2 : SOIS model . 104
Tables Table 5-1: RMAP Command Codes . 16 Table 5-2: Reply Address field size . 18 Table 5-3: Example Reply Address field to Reply SpaceWire Address mappings . 18 Table 5-4: Error and Status codes . 71 Table 5-5: SpaceWire RMAP write command . 74 Table 5-6: Example of Write Command Product Characteristics . 74 Table 5-7: SpaceWire RMAP Read Command . 75 Table 5-8: Example Read Command Product Characteristics . 75 Table 5-9: SpaceWire RMAP Read-Modify-Write Command . 76 Table 5-10: Example Read-Modify-Write Command Product Characteristics . 76 SIST EN 16603-50-52:2014

Table C-1 : Comparison of RMAP and Remote Memory Access primitives . 105 Table C-2 : WRITE.request parameters . 106 Table C-3 : WRITE.confirmation parameters . 106 Table C-4 : READ.request parameters . 106 Table C-5 : READ.confirmation parameters . 106 Table C-6 : RMW.request parameters . 107 Table C-7 : RMW.confirmation parameters . 107
8 1 Scope There is a number of communication protocols that can be used in conjunction with the SpaceWire Standard (ECSS-E-ST-50-12), to provide a comprehensive set of services for onboard user applications. To distinguish between the various protocols a protocol identifier is used, as specified in ECSS-E-ST-50-51. This Standard specifies the Remote Memory Access protocol (RMAP), which is one of these protocols that works over SpaceWire. The aim of RMAP is to support reading from and writing to memory in a remote SpaceWire node. RMAP can be used to configure a SpaceWire network, control SpaceWire nodes, and to transfer data to and from SpaceWire nodes. RMAP is specified in this Standard. This standard may be tailored for the specific characteristic and constrains of a space project in conformance with ECSS-S-ST-00. SIST EN 16603-50-52:2014

EN reference Reference in text Title EN 16601-00-01 ECSS-S-ST-00-01 ECSS system - Glossary of terms EN 16603-50-12 ECSS-E-ST-50-12 Space engineering - SpaceWire - Links, nodes, routers and networks EN 16603-50-51 ECSS-E-ST-50-51 Space engineering - SpaceWire protocol identification
10 3 Terms, definitions and abbreviated terms 3.1 Terms defined in other standards For the purpose of this Standard, the terms and definitions from ECSS-S-ST-00-01 and ECSS-E-ST-50-51 apply. 3.2 Terms specific to the present standard None. 3.3 Abbreviated terms The following abbreviations are defined and used within this standard: Abbreviation Meaning CRC cyclic redundancy code EEP error end of packet EOP end of packet FCT flow control token FIFO first in first out ID identifier inc increment Len length LS least-significant LSB least-significant bit MS most-significant MSB most-significant bit RMAP remote memory access protocol RMW read-modify-write SOIS spacecraft onboard interface services SpW SpaceWire SSNSAP source subnetwork service access point SIST EN 16603-50-52:2014

3.4 Conventions 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. SIST EN 16603-50-52:2014

12 4 Principles 4.1 Remote Memory Access Protocol (RMAP) purpose The aim of RMAP is to support reading from and writing to memory in a remote SpaceWire node. RMAP can be used to configure a SpaceWire network, control SpaceWire nodes, and to transfer data to and from SpaceWire nodes. RMAP is specified in this Standard. The remote memory access protocol (RMAP) has been designed to support a wide range of SpaceWire applications. Its primary purposes however are to configure a SpaceWire network, to control SpaceWire nodes and to gather data and status information from those nodes. RMAP can operate alongside other communication protocols running over SpaceWire. RMAP can be used to configure SpaceWire routing switches, setting their operating parameters and routing table information. It can also be used to monitor the status of those routing switches. RMAP can be used to configure and read the status of nodes on the SpaceWire network. For example, the operating data rate of a node can be set to 100 Mbits/s and the interface can be set to auto-start mode. RMAP can also be used to download and debug software on a remote processor. For simple SpaceWire units without an embedded processor, RMAP can be used to set application configuration registers, to read status information and to read from or write data to memory in the unit. For intelligent SpaceWire units RMAP can provide the basis for a wide range of communication services. Configuration, status gathering and data transfer to and from memory or mailboxes can be supported. 4.2 Guide to clause 5 Specification of the fields used in RMAP commands and replies is given in clause 5. The CRC used by RMAP is specified in clause 5.2. The write command is defined in clause 5.3, the read command in clause 5.4 and the read-modify-write command in clause 5.5. The error codes that are used in RMAP replies are listed in clause 5.6. The way in which partial implementations of RMAP can be implemented is described in clause 5.7. Clause 5.8 specifies the conformance statements i.e. clauses that are implemented and the ancillary information that is provided, in order for a supplier to claim conformance to the SpaceWire RMAP standard. Example VHDL and C-code for the 8-bit CRC used by RMAP is given in Annex A. SIST EN 16603-50-52:2014

The acknowledged/non-acknowledged and verified/non-verified options to the write command result in four different write operations: • Write non-acknowledged, non-verified - writes zero or more bytes to memory in a target. The command header is checked using a CRC before the data is written, but the data itself is not checked before it is written. No reply is sent to the initiator of the write command. This command is typically used for writing large amounts of data to a target where it can be safely assumed that the write operation completed successfully. For example the writing of camera data to a temporary working buffer. SIST EN 16603-50-52:2014

14 • Write non-acknowledged, verified - writes zero or more bytes to memory in a target. Both the command header and data are checked using CRCs before the data is written. This limits the amount of data that can be transferred in a single write operation, but writing erroneous data to memory is unlikely. No reply is sent to the initiator of the write command. This command is typically used for writing command registers and small amounts of data to a target where it can be safely assumed that the write operation completed successfully. For example writing many commands to different configuration registers in a device and then checking for an error using a status register. • Write acknowledged, non-verified - writes zero or more bytes to memory in a target. The command header is checked using a CRC before the data is written, but the data itself is not checked before it is written. A reply to indicate the command execution status is sent to the initiator of the write command. This command is typically used for writing large amounts of data to a target where it can be safely assumed that the write operation completed successfully, but an acknowledgement is required. For example writing sensor data to memory. • Write acknowledged, verified - writes zero or more bytes to memory in a target. Both the command header and data are checked using CRCs before the data is written. This limits the amount of data that can be transferred in a single write operation, but writing erroneous data to memory is unlikely. A reply to indicate the command execution status is sent to the initiator of the write command. This command is typically used for writing small amounts of data to a target where it is important to have confirmation that the write operation was executed successfully. For example writing to configuration registers. 4.3.3 Read commands The read command provides a means for one node, the initiator, to read zero or more bytes of data from a specified area of memory in another node, the target on a SpaceWire network. The data read is returned in a reply packet which normally goes back to the initiator. 4.3.4 Read-modify-write The read-modify-write command provides a means for one node, the initiator, to read a memory location in another node, the target, modify the value read in some way and then write the new value back to the same memory location. The original value read from memory is returned in a reply packet to the initiator.
16 5.1.4 Instruction field 5.1.4.1 General a. The Instruction field shall be an 8-bit composite field that comprises the packet type, command and Reply Address length fields. 5.1.4.2 Packet type field a. The Packet Type field shall be a 2-bit field that determines the type of RMAP packet i.e. a command (0b01) or reply (0b00).
b. The other possible values (0b10 and 0b11) of the packet type field are reserved. 5.1.4.3 Command field a. Command field shall be: 1. A 4-bit field in an RMAP command that specifies the type of command, or 2. A 4-bit field in an RMAP reply that specifies the type of command that caused the reply. b. The command codes shall have the meanings listed in Table 5-1. Table 5-1: RMAP Command Codes
Bit 5 Bit 4 Bit 3 Bit 2 Command Field Write/ Read Verify Data Before Write Reply Increment Address Function 0 0 0 0 Invalid 0 0 0 1 Invalid 0 0 1 0 Read single address 0 0 1 1 Read incrementing addresses 0 1 0 0 Invalid 0 1 0 1 Invalid 0 1 1 0 Invalid 0 1 1 1 Read-Modify-Write incrementing addresses 1 0 0 0 Write, single address, don’t verify before writing, no reply 1 0 0 1 Write, incrementing addresses, don’t verify before writing, no reply 1 0 1 0 Write, single address, don’t verify before writing, send reply SIST EN 16603-50-52:2014

5.1.4.4 Reply Address length field a. The Reply Address Length field shall be:
1. A 2-bit field in an RMAP command that determines the number of bytes in the Reply Address field of a command. 2. A 2-bit field in an RMAP reply that is a copy of the 2-bit Reply Address Length field in the command that caused the reply. 5.1.5 Key field a. The Key field shall be an 8-bit field that contains a key which is matched by the target user application in order for the RMAP command to be authorised. NOTE The Key is only used for command authorisation. It is not used for other purposes. 5.1.6 Reply Address field a. The Reply Address field shall be a 0, 4, 8 or 12-byte field in a command that contains the SpaceWire address for the reply to the command. b. The size of the Reply Address field shall depend on the value of the Reply Address Length field as detailed in Table 5-2. NOTE The Reply Address is not needed if logical addressing is being used. The Reply Address is normally used by the target to send replies or data back to the initiator that requested a write or read operation using path addressing. The Reply Address allows path addressing and regional logical addressing to be used to specify the node that is to receive the reply (normally the initiator). SIST EN 16603-50-52:2014

18 Table 5-2: Reply Address field size Value of Reply Address Length Field Size of Reply Address field 0b00 0 0b01 4 bytes 0b10 8 bytes 0b11 12 bytes
c. Leading bytes with the value 0x00 in the Reply Address field shall be ignored. d. If the Reply Address Length field is not zero and the Reply Address bytes are all zero (0x00), a single zero value data character shall be sent as part of the Reply SpaceWire Address field. NOTE This is so that a Reply SpaceWire Address comprising a single zero (0x00) data character is possible. e. Any characters in the Reply Address field after the leading bytes with the value 0x00 shall form the Reply SpaceWire Address. f. SpaceWire path addressing and regional addressing shall be used to form the Reply Address field. g. Some examples of the mapping between the contents of the Reply Address field and the Reply SpaceWire Address are listed in Table 5-3. Table 5-3: Example Reply Address field to Reply SpaceWire Address mappings Reply Address field Resulting Reply SpaceWire Address 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x02 0x01 0x02 0x00 0x01 0x00 0x02 0x01 0x00 0x02 0x00 0x01 0x02 0x00 0x01 0x02 0x00 0x00 0x00 0x00 0x01 0x02 0x03 0x04 0x05 0x01 0x02 0x03 0x04 0x05 0x00 0x00 0x66 0x05 0x66 0x05 0x00 0x54 0x08 0x00 0x54 0x08 0x00
h. The Reply Address field shall not be used when a single logical address is used for routing the reply to its initiator (or other node). NOTE In this case the reply is routed to the initiator by the Initiator Logical Address. i. An RMAP implementation may use an implicit return address or implicit partial return address. SIST EN 16603-50-52:2014

20 5.1.11 Data Length field a. The Data Length field shall be a 24-bit field that contains the length in bytes of the data field or data and mask field in a command or reply. b. The most significant byte of the Data Length field shall be sent first. 5.1.12 Header CRC field a. The Header CRC field shall be an 8-bit field that contains an 8-bit Cyclic Redundancy Code (CRC) covering each byte in the header, starting with the Target Logical Address and ending with the byte before the Header CRC in a command and starting with the Initiator Logical Address and ending with the byte before the Header CRC in a reply. 5.1.13 Data field a. The Data field shall be a variable length field containing the data bytes that are written in a write command or the data bytes that are read in a read reply, or read and written in a read-modify-write command and reply. NOTE The order of the bytes in the data field is up to the specific implementation and is defined in the target product characteristic table (see clause 5.8). 5.1.14 Mask field a. The Mask field shall be a variable length field containing the mask in a read-modify-write command. 5.1.15 Data CRC field a. The Data CRC field shall be an 8-bit field that contains an 8-bit Cyclic Redundancy Code (CRC) covering each byte in the data and mask field starting with the byte after the Header CRC and ending with the byte before the Data CRC. 5.1.16 Reply SpaceWire Address field a. The Reply SpaceWire Address field shall be a variable length field formed from the contents of the Reply Address field of a command which is used to route a reply back to the initiator or other intended destination for the reply. 5.1.17 Status field a. The Status field shall be an 8-bit field in a reply containing a status/error code as defined in clause 5.6. SIST EN 16603-50-52:2014

b. The CRC calculation procedures shall: 1. use modulo 2 arithmetic for polynomial coefficients;
2. use a systematic binary (8,)nn+ block code, where (8)n+ is the number of bits of the codeword ()cx and n is divisible by 8; n is the number of bits covered by the CRC; 3. use the following generating polynomial: 82()1gxxxx=+++ 4. use byte format as input and output, for which the bits are represented as: 76543210bbbbbbbb where 7b is the most significant bit and 0b is the least significant bit; c. The CRC generation procedure shall behave as follows: 1. The procedure accepts an n-bit input which is used to construct ()mx, where: (a) the n-bit input is defined to be the set of bits ,ijB grouped into /8n bytes where {}0,1,,/81in=− is the byte index and {}7,6,,0j= is the bit index; (b) the /8n input bytes correspond to the RMAP fields covered by the CRC excluding the CRC byte; the first byte transmitted has index 0i=; the last byte transmitted has index /81in=−; (c) ()mx is a polynomial 120110.nnnnmxmxmx−−−−+++ having binary coefficients im; (d) ()mx can be represented as an n-bit vector where coefficient 1nm− of the highest power of x is the most significant bit and coefficient 0m of the lowest power of x is the least significant bit; (e) the bit vector representation of ()mx is formed by concatenating the /8n bytes of the input in transmission order, where the least significant bit 0b of each byte is taken first and the most significant bit 7b of each byte is taken last: SIST EN 16603-50-52:2014

22 10,020,130,270,680,7,,,,,,nnnnnmBmBmBmBmB−−−−−=====91,0101,1111,2151,6161,7,,,,,,nnnnnmBmBmBmBmB−−−−−=====7/81,06/81,15/81,21/81,60/81,7,,,,,nnnnnmBmBmBmBmB−−−−−===== 2. The procedure generates the remainder polynomial ()rx given by the equation: 8()()modulo()rxmxxgx=⋅
where 760760()rxrxrxrx=++ and ir are binary coefficients; 3. The Header and Data CRC are formed from the 8-bit vector representation of ()rx; the least significant bit 0b of the CRC byte is coefficient 7r of the highest power of x, while the most significant bit 7b of the CRC byte is coefficient 0r of the lowest power of x:
7061524334251607,,,,,,,brbrbrbrbrbrbrbr======== NOTE 1 The codeword 8()()()cxmxxrx=⋅+ is formed by concatenating the bit vector representations of ()mx and ()rx. NOTE 2 When a Galois version of a Linear Feedback Shift Register is used for CRC generation, its initial value is zero. NOTE 3 Example VHDL and C-code implementations of this CRC algorithm are included in clause Annex A.
d. If the CRC generation procedure is applied to the bytes covered by the CRC excluding the CRC byte then the generated CRC shall be compared directly with the expected CRC byte. If the generated and expected CRC bytes are equal then no errors have been detected; if they are different then an error has been detected. e. If the CRC generation procedure is applied to the bytes covered by the CRC including the CRC byte then the output of the CRC generation procedure shall be zero if no errors have been detected and non-zero if an error has been detected. NOTE 1 When the codeword *()cx is input to the CRC generator then the remainder is the syndrome:
*8()()modulo()sxcxxgx=⋅.
NOTE 2 The codeword *()cx is the concatenation of the Header or Data bytes covered by the CRC, followed by the CRC byte. f. If the value of the data length field is zero, then the Data CRC shall be 0x00. NOTE Read commands and write replies have no Data CRC field. SIST EN 16603-50-52:2014

NOTE 1 The equivalent bit serial version takes the least-significant bit of each byte first and does not include data/control or parity bits, NULL, FCT or other non-data characters. NOTE 2 See clause Annex A for some examples of how t
...