SpaceFibre Physical Layer Testing F. Siegle, J. Ilstad 15/09/2017

Motivation Minimize likelihood of (satellite) integration problems Define compliance tests that are possible to verify at system level The tests must ensure that the unit design is done properly It must be possible to test a flight unit as a “black box” Roles must be clearly defined The current ECSS standard is not sufficient for compliance testing, therefore we need to work towards a compliance testing handbook as soon as possible!

The SpaceFibre standard specifies: At the pins: Eye pattern masks Total & deterministic jitter Other driver and receiver characteristics such as transitions times, input return loss etc. At the connectors (near-end and far-end): at-pins specifications are important to choose the right component (FPGA, ASIC, stand-alone SERDES) and to determine the margins within the unit. However, for compliance testing, the at-connector specifications are essential!

Transmitter testing The SpaceFibre standard specifies a test circuit to terminate the transmitter at the connector: TX testing is usually done using an oscilloscope with appropriate bandwidth and high-quality differential probes. For black-box testing, we need to add an option to the SpaceFibre core to generate a test patterns as defined in OIF-CEI-2.0 (PRBS31-based).

Receiver testing Receiver testing requires a Bit Error Ratio Test (BERT) device. The device generates a PRBS that is fed into the receiver of the SERDES. The signal is artificially degraded to meet the specified worst-case eye diagram. Within the UUT, the received bit sequence is looped back to the transmitter. Within the BERT, an error detector compares the received sequence with the transmitted one and calculates the bit error rate. Question: How is the PRBS looped backed within the device?

Receiver testing: loopback options (1/3) The SpaceFibre standard specifies: A far-end serial loopback as an optional “should” requirement. It also does not specify how to enter this loopback mode. Problem: Not all SERDES may have a serial loopback option! Depending on the loopback scheme, the BERT must be able to recover the TX clock!

Receiver testing: loopback options (2/3) We could also add a loopback mechanism above the lane layer: Data is 8B/10B decoded and crosses clock domain through an elastic buffer before it is again 8B/10B encoded and transmitted to the BERT. BERT must be aware of SKIP words etc.

Receiver testing: loopback options (3/3) Both options are interesting and would allow black-box testing. Suggestion: Keep serial far-end loopback as “should” requirement. Add “shall” requirement for parallel far-end loopback. Remaining question: How do we bring the SpaceFibre unit into TX and RX testing mode? SpaceFibre IP Core Configuration options could be defined but it might be tricky or even impossible to send RMAP commands to the unit while being in a test bench setup. Better: Add test mode states to the lane initialization state machine to simplify test equipment implementations.

Receiver testing: test mode states New test mode states could be added for: RX – loopback test TX – PRBS-31 generation These states could be reachable from the Started state. They are left after reset or reception of INIT1 words. BERT could easily train state machine into test states. However, we would also need to define new control words, e.g. TINIT1, TINIT2. RX Test 1023x TINIT1 1023x TINIT2 TX Test

- Thank you -