Chapter 10. RapidIO Bringup and Initialization Programming
The RapidIO interconnect architecture is promoted as being transparent to software, so a chapter on RapidIO programming would appear to be unnecessary. However, in any embedded system, software is a critical component. RapidIO programming falls into several categories. This book will examine the following categories of RapidIO programming.
System initialization
Device enumeration
Route table configuration
Memory mapping
In embedded systems there is a much higher degree of interaction between the software and the hardware. In typical computing environments such as a Windows-based desktop computer there is relatively little interaction between the programs running on the main processor and the peripheral devices that, together with the processor, complete the system. In embedded environments there is typically much more interaction between the software and the hardware.
RapidIO systems, once configured, will pass memory and I/O transactions transparently across the RapidIO interconnect. From the point of view of software not specifically interacting with RapidIO, there is no RapidIO hardware. It is invisible to the software. For example, when a processor issues a load instruction to an address space that is configured to reside in or be associated with a device that exists across a RapidIO network, that instruction initiates the generation of a RapidIO READ transaction. The associated RapidIO packet is properly formed and sent across the RapidIO network. The response packet returns the data and the data is forwarded back to the processor to complete the load operation. This process is handled completely in hardware.
This model is very different from that offered for Ethernet; another common interconnect technology. In Ethernet, a processor load or store operation might read and write data to a buffer or it might access an Ethernet controller's configuration or status registers, but it will not automatically generate an Ethernet packet addressed to another device in the system configured to provide a reliable request for data from another device that will be automatically forwarded back to the requesting processor. In Ethernet, to accomplish this task, there needs to be cooperating software processes executing on both the sender and the receivers. These software processes communicate with each other through a stack of software-based drivers. For a technology such as RDMA over Ethernet, this operation typically consumes thousands of processor operations on both the sending and receiving device, with transaction latencies measured in milliseconds and tremendous packet inefficiency on the Ethernet channel itself.
The RapidIO operation is handled completely in hardware and is invisible to the software. The software, except through measuring the latency of the load operation, is unable to distinguish loads of data from cache memory, local memory or remote memory.
RapidIO is invisible to software only when it is serving as a memory-mapped I/O bus. This is only one of several possible operating modes. A second important mode of operation is when the message-passing logical layer transactions described in Chapter 5 are being used. Software must be written to explicitely make use of these transactions. They will not be automatically generated by hardware. Software may also play a role in supporting the streaming fabric logical layer transactions. These transactions would be used to support the transport of data streams across RapidIO. Example data streams might include: Ethernet packets, ATM cells, or even technologies such as MPEG-2 digital video streams. The streaming fabric extensions offer mechanisms for data to be segmented and transported with quality of service guarantees across the RapidIO fabric.
Another aspect of RapidIO that is not transparent to software is the configuration of RapidIO itself. What is meant by this is the interaction between the RapidIO hardware and the system software that is needed to initialize the RapidIO end points to ensure that the links are running and properly sending and receiving packets, so that any switches in the system are properly configured and that memory maps are set up to provide the desired system visibility between devices. The rest of this chapter will present the requirements and specified mechanisms for software support of RapidIO in embedded systems.