rapidio_v5

Description

SIM_INTERFACE(rapidio_v5) {
        void (*transaction_request)(
                conf_object_t *obj, uint16 target_id, uint16 source_id,
                uint32 transport_class,
                uint64 addr, rapidio_operation_t op, bytes_t msg, uint64 id);
        void (*transaction_response)(
                conf_object_t *obj, bytes_t msg, uint64 id);
        void (*doorbell)(
                conf_object_t *obj, uint16 target_id, uint16 source_id,
                uint32 transport_class, uint16 val);
        void (*deliver_message)(
                conf_object_t *obj, uint16 target_id, uint16 source_id,
                uint32 transport_class,
                uint16 mbox, uint16 letter, bytes_t msg);
        void (*read_register_request)(
                conf_object_t *obj, uint16 target_id, uint16 source_id,
                uint32 transport_class,
                uint8 hopcount, uint32 reg_no, uint64 id);
        void (*read_register_response)(
                conf_object_t *obj, uint32 val, uint64 id);
        void (*write_register)(
                conf_object_t *obj, uint16 target_id, uint16 source_id,
                uint32 transport_class,
                uint8 hopcount, uint32 reg_no, uint32 val);
        void (*port_write)(
                conf_object_t *obj, uint16 target_id, uint16 source_id,
                uint32 transport_class,
                uint8 hopcount, bytes_t msg);
        void (*stream_data)(
                conf_object_t *obj, uint16 target_id, uint16 source_id,
                uint32 transport_class,
                uint8 cos, uint8 xh, uint16 stream_id, bytes_t pdu);
};
#define RAPIDIO_V5_INTERFACE "rapidio_v5"

This interface is designed for peer-to-peer RapidIO communication. It supersedes the rapidio_v4 interface; adding data streaming support.

The request/response function pairs take an id parameter; the caller of the request function may choose any ID it likes, and the recipient is expected to reply by calling the sender's response function with the same ID. The recipient may delay for as long as it wishes before responding, but it is required to respond exactly once to each request. Both sides may continue to make new calls while a request is underway.

I/O accesses are done using transaction_request and transaction_response; the kind of access is determined by the op argument. The valid values are:

typedef enum {
        RapidIO_Read,
        RapidIO_Write,
        RapidIO_Increment,
        RapidIO_Decrement,
        RapidIO_Test_and_Swap,
        RapidIO_Set,
        RapidIO_Clear,
        RapidIO_Compare_and_Swap,
        RapidIO_Swap
} rapidio_operation_t;

The size of the msg argument decides the transaction size and the addr argument dictates where the access is made. The contents of msg is the input and output values of the transaction (assumed to be big-endian for the purposes of the increment and decrement operations). The plain read and write operations only send useful data in msg in one direction, but a byte sequence of the right length must be sent anyway (but its contents are ignored).

The doorbell method corresponds to a DOORBELL/DONE packet pair, while deliver_message denotes a non-fragmented message. On the physical line this will be split into 256-byte MESSAGE packets, acknowledged with a DONE packet.

read_register_request, read_register_response, and write_register is the way to simulate MAINTENANCE operations.

port_write corresponds to PORT_WRITE packet, with all arguments stored in big-endian order in the msg argument. Typically, this is the four 32-bit words component_tag_csr, port_error_detect_csr, port_id, and transport_layer_error_detect_csr.

The stream_data method corresponds to a non-fragmented DATA STREAM packet. On the physical line this will be split into MTU-sized MESSAGE packets.

From RapidIO specifications Part 10: "Data streaming transactions differ from most other RapidIO transactions in two ways: they must accommodate larger variably sized data transfers, and the transactions are not acknowledged with a response packet."

When xh is set to 1, the stream_data corresponds to the extended DATA STREAM packet used for traffic management. The payload for this extended packet is always four bytes, representing the TM OP, wildcard, mask, parameter 1 and parameter 2 bits stored in big-endian order. Note that xh is the 3+1 bit pair representing Xtype and xh bits from rapidio packet header, not a bool.

The transport_class represents packet fields that are transmitted in the physical layer part. For serial RapidIO, bits are allocated as follows: critical request flow, crf, in bit 0, priority in bit 3-2, and virtual channel in bit 7-4.

This interface is not yet perfect, and may undergo non-compatible changes in the future. Error reporting and cache control packets like IO_READ_HOME and FLUSH are not yet supported.

Execution Context

Cell Context for all methods.