R&D in Embedded Network Protocols

MIPI UniPro standard  development, simulation and verification

• UniPro specification review

• UniPro standard SDL specification development and verification

• UniPro specification SystemC model

• Further UniPro specification and tools development

So after the implementation of the previously shown architecture we could test the applications and network services by connecting them to a UniPro network:

The MIPI UniPro protocol stack model will facilitate to build platform models with several instances of nodes with MIPI UniPro interface that are connected by UniPro links (channels). Each node model will have socket-based API for access from a C/C++ program.

Thus one could program in C/C++ for applications and services to prototype the concepts and high-level algorithms, make them run over MIPI UniPro protocol stack model and investigate their operation over MIPI UniPro interconnection.

Virtual platform with the MIPI/UniPro stack for software development, for applications and services algorithms prototyping

The second step that could be done is a real drivers and middleware development by using the Linux OS installed over the UniPro stack model.

Such kind of task would be useful for UniPro-specific OS development, middleware implementation and implementation of the first versions of UniPro drivers which would work on a real board also.

As the Operation System we choose the open source Linux platform. It could be modified and installed over the HAL.

The UniPro IP Core (the behavioural model on SystemC) would be added to HAL and the developed UniPro driver would work with it as with the real board. Also the specific UniPro Applications could be tested the same way.

SpaceWire SystemC Model

For the modelling of SpaceWire we choose the modelling per layer method. In this method the decomposition of one task into a set of simpler tasks or modules is heavily used technique. Decomposition procedure includes accurate definition of functions for each module that has to solve particular separate problem and clear specification of the interfaces between them. The consequence is a logical simplification of the problem. Another result is an ability to update these separate modules without changing other parts of the system.

The implemented SpaceWire model includes four standardized layers. The bottom layer is Character layer, than the Exchange, Packet and Network layers are implemented above. To provide an exchange between two or more nodes we use the other model with implementation of Physical and Signal layers of the standard and it is out of the scope of current article. The Traffic Generator is located over the Network layer to generate the outgoing traffic and analyze the incoming one.

RMAP and STP protocols modelling over the SpaceWire SystemC model

SpaceWire standard covers three (physical, data-link and network) of the seven layers of the OSI model and does not specify the transport layer. Therefore to implement the simultaneous operation of multiple applications, pursuing different goals over the SpaceWire it is necessary to connect the transport layer with the previously developed SpaceWire model.

Applications should have possibility to work with remote memory, registers, and support large data level transmission. There are a lot of different transport protocols. We used protocols RMAP and STP, because RMAP is designed to work with remote memory (registers, FIFO, etc.), and STP (it is connection-oriented protocol) provides reliable transmission of large data level.

These models is implemented for testing ability of the transport level protocols work with SpaceWire protocol stack. In addition STP and RMAP models should operate over the SpaceWire simultaneously. Protocol Identifier is used for this purpose. We implemented the model of this protocol also.

A huge test bench needed to test protocol models. It is used for traffic generation and its analysis. The easier implementable and the most convenient method is a point-to-point connection of two models instances. Doing so each model can generate the traffic, but the analysis of the outgoing data mostly would be done by the receiving sides of the both models according to the mechanisms defined in the specification.

So, such modelling method gives a number of benefits:

• The model could test all the internal mechanisms;
• There is a possibility to trace the whole data exchange process in both directions;
• The traffic analysis is done by the model itself according to the specification;
• There is a possibility to check the joint work of protocols.

By comparing of data sent by Node #0 and the data received by the Node #1 the model’s operation correctness could be estimated. If there is any corrupted data received then error is detected. If received data is correct it means that the test is passed and we can start the next one with another portion of data and other settings.

One of the most important advantages of this method is that point-to-point connection mode can simulate work of the model very close to the real devices communication. Applications create various situations of data exchange. Necessary corrections are applied for every unique case of modelling.

Though such modelling case we could find errors in the model or in the specification itself and the developer could fix it.