• network layer
• UVM
• SpaceFibre

The number of space missions has seen continuous growth in the last years. Accordingly, satellite communications traffic and onboard spacecraft technologies have also increased. Hence, it was necessary to develop communication protocols capable of supporting more and more data.
To manage such a high data handling, the European Cooperation for Space Standardization (ECSS) has released the SpaceFibre protocol in 2019, with support from all major international space agencies, companies, and research institutes. This standard increases the capabilities of its predecessor SpaceWire, among them a higher data rate and the possibility of utilizing optical fibres as communication links. Moreover, it introduces features that its predecessor does not have, such as Quality-of-Service (QoS) and Fault Detection Isolation and Recovery (FDIR).
Together with the back compatibility with the SpaceWire protocol, an important feature of the SpaceFibre standard is that it is possible to create a Router-based Network if the data handling complexity requires it. Consequently, a crucial implementation step towards the realisation of a satellite high speed data-handling network is the hardware design, and hence the verification, of a routing switch, with its functionalities and required compliances. However, there are no structured network-level verification environments, nor in the literature or on the market.

In this thesis, a SystemVerilog Verification IP was developed based on a standard methodology, known as Universal Verification Methodology (UVM), that can verify the functionalities of a SpaceFibre Routing Switch and its conformance with Network Layer specifications. The ultimate intention is to design an IP that can identify failures at an early stage and thus reduce the development and testing time of a generic SpaceFibre Routing Switch.
After a brief SpaceFibre introduction, the underlying reasons for UVM choice and its characteristics are presented. The second part of the thesis is dedicated to the description of the Verification Environment architecture and the Device Under Test (DUT) used, which has been provided by the University of Pisa spin-off company IngeniArs S.r.l.. Lastly, the test plan and the results obtained are discussed highlighting the bugs and non-compliance behaviours found, and also the metrics and limits of the Verification IP developed.

As mentioned, the Verification IP was implemented in SystemVerilog using the UVM standard. The latter is managed by the Accellera Systems Initiative organization, with support from multiple leading vendors in Electronic Design Automation (EDA) industry, and adds features to SystemVerilog language, such as sequence, virtual sequence, and data automation. The overall goals of the UVM methodology are to deliver a simple and more flexible way of creating robust test environments and make it easier to reuse verification components for new projects effortlessly and with small adjustments.
A key advantage of the UVM methodology is the possibility to constrain random stimuli given to the DUT easily, allowing numerous combinations of signals in a short time. This ensures control of all possible corner cases of the standard, understanding of how the DUT behaves when used out of specification, and therefore reduces the verification costs.

The basic approach of the proposed Verification IP consists of one transmitting and one receiving agent for each channel of the ports in the routing switch. The transmitting agent is responsible for sending packets to the DUT through its driver meanwhile its monitor takes care of collecting them. Similarly, the receiving agent samples the incoming packets via its monitor while its driver only manages the read enable signal.

All transmitting monitors send the read words to the Reference Model component, which emulates the Network Layer mechanism of the routing switch. The Reference Model generates the expected packets based on the test stimuli and sends them to the Scoreboard component into a queue of the (port, channel) tuple where they are expected to arrive.
Differently, the receiving monitors send the collected words directly to the Scoreboard. Afterwards, the Scoreboard compares the received packets with the expected ones, indicating whether the test passed or failed.

A peculiar aspect of the proposed solution is that it interfaces with the routing switch via CoDec for each port. As a result, the Verification IP presented can be adopted by any other Routing Switch implementation, or by another device with a SpaceFibre interface, by simply modifying the data-link layer connections.