Introduction to Serial RapidIO® (SRIO) by IDT
•
3 gefällt mir•2,545 views
This video presents an educational overview of the RapidIO architecture and ecosystem. The RapidIO architecture is a high-performance packet-switched, interconnect technology for interconnecting chips on a circuit board, and circuit boards to each other using a backplane. This technology is designed specifically for embedded systems, primarily for the networking, communications, and signal processing markets. Serial RapidIO solutions from IDT include switching and bridging products that are ideal for building peer-to-peer multi-processor systems with 100ns latency, low power consumption, reliable packet termination — all with industry-standard based support at up to 20 Gbps per port. IDT's Serial RapidIO solutions are ideal for wireless base station infrastructure, video, server, imaging, military and industrial control applications. Video presented by Barry Wood, Expert Applications Engineer at IDT. To learn more about IDT's rich portfolio of RapidIO switches and bridges, visit http://www.idt.com/go/SRIO.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Introduction to Serial RapidIO® (SRIO) by IDT
Ähnlich wie Introduction to Serial RapidIO® (SRIO) by IDT (20)
Mehr von Integrated Device Technology
Mehr von Integrated Device Technology (8)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Introduction to Serial RapidIO® (SRIO) by IDT
- 1. RapidIO 101 Barry Wood Expert Applications Engineer ©2009 Integrated Device Technology, Inc.
- 2. RapidIO Specification History/Background Date Event 1997 2000, February 2000, June 2005 Mercury Computer and Motorola (Freescale) begin to collaborate on a replacement for the Raceway interconnect RapidIO Trade Association formed RapidIO 1.2 (Parallel PHY) 1 Gbps (LVDS 8/16 lane parallel bus) RapidIO 1.3 (Serial PHY) 3.125 Gbaud (XAUI) 2008 RapidIO 2.0 (Faster) 2013 RapidIO 3.0 (Faster) 2015(?) RapidIO 4.0 (Faster) www.IDT.co Max Speed Per Lane 6.25 Gbaud (OIF CEI) 10.3125 Gbaud (10G-kr, 10G-ab) ??? PAGE 2
- 3. RapidIO Specification Structure System Specs Protocol Specification Logical Layer Part 2 Message Part 1 Logical I/O Transport Layer Physical Layer Part 9 Part 5 Flow Control Part 10 Global Shared Data Streaming Memory Part 3 Transport Part 4 Parallel PHY (LVDS) Part 6 Serial PHY Part 11 Multicast Part 12 VoQ Extensions The RapidIO specification is available at www.rapidio.org www.IDT.co PAGE 3 Annex I HW API System Bringup Annex II Session Mgmt Part 7 Device Interop Part 8 Error Mgmt
- 4. RapidIO Specification Mapped to Devices uProc DSP Switch Switch Transport Physical DSP DSP Logical DSP CS Packet 0 CS CS A B CS Packet 1 CS Packet 2 CS Packet 2 CS www.IDT.co PAGE 4
- 5. Physical Layer: Control Symbols Receive Side “Type 0” Control Symbol Type 0 Identifier Parm 0 Parm 1 Transmit Side “Type 1” Type1 CMD CRC Start-of-packet Stomp End-of-packet Restart-from-retry Link Request Multicast Event No Operation/Ignore Timestamp Calibration Packet Accepted Packet Retry Packet Not Accepted Status VC Status Link Response Timestamp 24, 48, or 64 bits www.IDT.co PAGE 5
- 6. Physical Layer: Reliable Packet Delivery Packet Transfer Rx Tx S ta rt o f P ac ke t Flow Control Error Recovery Rx Tx Rx Tx SO P SOP Packet 1 E n d o f P ac ke t Packet 1 EOP EOP P a ck et A ck R E TR Y te d P a ck et N o t A cc ep RFR Li nk R eq ue st /P or t S ta tu s SOP ) Li nk R e sp (o pt io n al Packet 1 St ar t of Pa ck et Packet 2 St ar t of Pa ck et Packet 3 Packet 1 SOP EOP Packet 1 P a ck e t A ck www.IDT.co EOP PAGE 6
- 7. Physical Layer: Priority and AckIDs Packet Priority • A value from 0 to 3, where 3 is the highest priority • Optional support for Critical Request Flow bit yields a total of 8 priorities • Responses must be higher priority than requests, to avoid deadlock • Under congestion, packets of higher priority may pass packets of lower priority in a RapidIO fabric Acknowledge ID (AckID) ● AckIDs are monotonically increasing sequential values that uniquely identify packets in the transmitted data stream ● AckIDs are found in packets and control symbols ● AckID management ensures reliable packet delivery www.IDT.co PAGE 7
- 8. RapidIO Packet Format Payload: 256 Bytes Max 80 Bytes Physical Transport Layer Layer Header Header Logical Layer Packet Data CRC Header 280 Byte Maximum NOT TO SCALE www.IDT.co PAGE 8 Packet Data CRC
- 9. RapidIO Physical Layer Physical Transport Layer Layer Header Header Logical Layer Packet Data CRC Header 6 Bits 1 2 Bits 1 AckID VC PRIO CRF 2 BYTES www.IDT.co PAGE 9 Packet Data 2 Bits 4 Bits TT FType CRC
- 10. RapidIO Transport Layer Physical Transport Layer Layer Header Header Logical Layer Packet Data CRC Header Packet Data DestID Destination ID Source ID RapidIO packets are routed using Destination IDs Destination IDs are 8,16 or 32 bits in size. Packets can be multicast based on Destination IDs www.IDT.co PAGE 10 Port 0x34 0x35 0x36 0x37 0x38 1 3 5 2 7 CRC
- 11. RapidIO Logical I/O Packet Format Physical Transport Layer Layer Header Header Logical Layer Packet Data CRC Header Packet Data Transaction RapidIO supports up to 66 bits of address, and all transactions required to perform multiprocessing and cache coherency (CC-NUMA). www.IDT.co Size 2 Bytes SrcTID Address PAGE 11 4, 6, or 8 Bytes CRC
- 12. RapidIO Message Packet Format Physical Transport Layer Layer Header Header Logical Layer Packet Data CRC Header Packet Data CRC Msglen SSize Letter 2 Bytes Mailbox MsgSeg Messages: Up to 4KB sent using up to 16 packets. Logical layer responses are sent for every packet. Logical layer “Retry” response sent when no reassembly context is available www.IDT.co PAGE 12
- 13. RapidIO Doorbell Packet Format Physical Transport Layer Layer Header Header Logical Layer Packet Data CRC Header 2 Bytes Rsvd SrcTID 2 Bytes Doorbells indicate one of 64K events using the 2 byte payload Doorbells can be retried just like Messages www.IDT.co PAGE 13
- 14. RapidIO Data Streaming Packet Format Physical Transport Layer Layer Header Header Logical Layer Packet Data CRC Header Data Segment StreamID Seg Ctrl FC Op StreamID CRC Flow Control Class of Svc Packet Data FC Mask •Data Streaming: Up to 64K per transaction, no logical layer responses •Integrated flow control supports XON/XOFF, rate, and credit based algorithms. • Supports hardware virtualization implementations www.IDT.co PAGE 14
- 15. RapidIO System Discovery DSP 0 uProc 2 1 Switch DSP 1 3 5 DSP 3 4 DSP 2 System discovery uses a recursive algorithm to - Discover location and connectivity of all switches and endpoints - Allocate destination IDs to DSPs - Configure switch routing tables Standard system discovery supports two redundant hosts www.IDT.co PAGE 15
- 16. RapidIO for Fault Tolerant Systems Data Processing System Host DSP DSP DSP DSP Switch DSP DSP uProc DSP DSP Switch Redundant System Host uProc Switch Switch • Packets destined for the faulty endpoint must be discarded • Refer to Part 8 Error Management Extensions Section 1.2.4, table 1-1 • Timeouts can also be used to discard packets • Hardware must detect and rapidly notify the System Host of a failure • The hardware must begin discarding packets to prevent system congestion/failure •The System Host must receive notification, then diagnose, isolate and allow replacement of the faulty hardware www.IDT.co PAGE 16
- 17. RapidIO Ecosystem DSP: several products In TCI64xx family Axxia Communications Processor FPGA: Arria and Stratix Family XLS416 family Multicore Processor FPGA: Virtex 4/5/6 families DSP, PowerQUICC & QorIQ multicore FPGA Switches, Bridges & IP CPS and Tsi Family Wireless Baseband Processor DSP Oct22xx Network Processor Octeon 2 family www.IDT.co PowerPC based processors Network Processor WinPath3 460GT PAGE 17
- 18. Transcript ● Hello, and welcome to RapidIO 101. My name is Barry Wood. I'm an expert applications engineer working at IDT. I have contributed to the RapidIO spec for the past ten years, and I've also been the architect of some of IDT's RapidIO parts. Today I wanted to talk with you a little bit about RapidIO. ● Now most of you have probably not heard enough a lot about RapidIO, even though you likely use it every day indirectly. RapidIO is used in a great many of cell phone base stations. So if you use an LTE base station, that base station uses RapidIO technology. It's also likely that if you're using a 3G base station, you're using RapidIO technology. RapidIO is also used largely in military compute, so high-performance mobile compute as well as industrial control and medical imaging. You’ll find that RapidIO excels wherever there are size, weight, and power constraints, and the latest example of that is that RapidIO was selected by NASA and a number of other companies as the next generation Space Center Connect. If RapidIO can meet the size, weight, and power constraints of space, I'm sure it's ideal for your application. ● The RapidIO specification is a layered specification consisting of a logical transport and physical layer. The logical layer defines read/write and messaging semantics for use by RapidIO components. The transport layer defines how RapidIO packets are routed through a RapidIO fabric. And the physical layer defines the electrical encoding and electrical characteristics of RapidIO links. There are also a number of RapidIO specification parts that cut across the different layers. I'm going to talk about two of those today. The first is the RapidIO system bring-out specification, which defines how the RapidIO system is initialized, and the part eight error management specification, which finds the fault-tolerance support for RapidIO systems. The RapidIO specification is available in its entirety from www.rapidio.org. There is no charge. ● This chart shows a little about how the RapidIO specification is mapped to actual devices. The RapidIO ecosystem consists of two kinds of devices: endpoints and switches. Endpoints are devices that originate and process packets. Switches route packages to endpoints. So at the top you can understand that the logical layer specification largely applies to endpoints. In this chart, there is an example of a microprocessor sending a request to a DSP and receiving a response. The transport layer maps largely to RapidIO switch devices. The physical layer specification applies to every RapidIO link. At either end of the link are two link partners, or processing elements. These link partners exchange two kinds of information. The first is packets, and the second are control symbols. The use of control symbols allows RapidIO to guarantee the in-order delivery of packets from an endpoint to their ultimate destination. RapidIO control symbols have a unique capability among interconnect, in that they can be embedded within packets. This gives RapidIO the lowest-latency control path for flow control and error recovery of any interconnect. The transfer of packets is governed by two quantities. The first is the priority of the packet. The second is the acknowledge ID found in the packet, and also carried in control symbols. ● Control symbols carry two kinds of information. The first is information that the transmit side sends to the receiver directly. These are things like start of packet, end of packet, or a multicast event control symbol that signals an event has occurred within the RapidIO network. The other kind of information is information that the receiver is sending back to the transmitter. These are things like packet accepted, so a packet was successfully transferred, packet not accepted, so an error was detected, link response, or time stamp. ● These message sequence charts give some information about how RapidIO control symbols are used to ensure the reliable, in-order delivery of packets in a RapidIO fabric. The chart on the left shows success case RapidIO packet transfer. You'll note that the packet is delimited with a start of packet and terminated with an end of packet control symbol. That packet is then acknowledged. So with every hop through a RapidIO fabric, each link partner ensures that its link partner receives the RapidIO packet successfully before reusing the buffer for that RapidIO packet. You'll also see that packets can be terminated with a start of packet control symbol. So if you're sending many packets back-to-back, you can save some bandwidth by not sending an end of packet, but instead sending start of packet, packet, start of packet, and so forth. The middle message sequence chart shows how RapidIO flow control works. Most RapidIO devices will send packets to the receiver regardless of how many free buffers the receiver has. If the receiver does not have sufficient buffering to accept the packet, the receiver sends back a retry control symbol, indicating the acknowledgment ID of the packet that is being retried. The transmitter then sends a restart from retry control symbol, acknowledging receipt of the retry, and chooses a higher-priority packet to send. The exchange of control symbols usually takes less than 200 nanoseconds on a RapidIO link. A similar mechanism is used for error recovery, but instead of a retry control symbol the receiver sends a packet not accepted control symbol, indicating that a transmission error has been detected. The transmitter sends a link request control symbol requesting the acknowledgement ID of the next packet that should be sent. The link response contains that acknowledgement ID. Once that link response has been received successfully, packet transmission resumes. Again, the error recovery can occur in 300 nanoseconds or less on RapidIO links. This is far faster than the error recovery that Ethernet, with its end-to-end packet timeouts allows. ● This chart contains a little bit more information about priority and acknowledgement IDs. You can peruse that and read it at your leisure. ● This chart has a little bit more information about the packet format of RapidIO. You'll see that, just as it is a layered specification so the packet header is also layered with a physical transport and logical layer header. RapidIO packets longer than 80 bytes have an intermediate CRC in them, which allows a receiving endpoint to ensure the integrity of the transport and logical layer headers before they begin to process the packet. This is just one way that RapidIO was designed to minimize latency and maximize the efficiency of packet transfers between endpoints. ● The physical layer header is two bytes that actually contain a physical transport and logical layer header within them. The packet priority, as well as the acknowledgement ID are encoded in the physical layer header. The transport type bits, or "TT bits", determine the size of the following trans [audio skips] and the F type determines the packet format for the logical layer header which occurs in the packet. ● RapidIO devices are identified using an 8, 16, or 32 bit device ID. Any RapidIO packet contains two device IDs. The first is the destination ID, which is where the packet is being sent to. The second is the source ID, which is where the packet originated from. To route a packet, the destination ID is used to index into a routing table which determines the output port that the switch should send the packet to. Once a packet is received by an endpoint, if the endpoint must create a response for that packet, it simply switches the destination and source ID and sends back the response. I should note that RapidIO also supports multicast, in which case when the switch uses a destination ID to look up the output port, instead of a single port being returned, a bit vector of ports is returned. Every bit in that vector will receive a [audio skips]. ● I mentioned earlier that RapidIO supports read/write as well as messaging semantics. This chart contains some information about the read/write semantics, or how the read/write semantics of RapidIO are implemented. RapidIO supports a variety of read, write, automic, and castroherency operations that support RDMA as well as ccNUMA. ● RapidIO messaging has several different possible implementations. The first confusingly, is named a messaging packet. This chart gives some information about the format of messaging packets. RapidIO doorbells are a much shorter that indicate that an event has occurred in a system. Just like message packets, doorbell packets are designed to minimize the amount of silicon required to successfully receive and process them. For this reason, if there are insufficient resources to accept a doorbell packet at the receiver, the doorbell packet or message packet will cause a logical layer retry to occur. This is different from a physical layer retry, and it allows limited resources of embedded memory to be used exclusively to process RapidIO packets. So RapidIO does not need a lot of SDRAM bandwidth to efficiently and effectively deliver a lot of throughput and guaranteed latency. ● Data streaming packets are another mechanism that is used to support messaging semantics. So while messaging packets only support a 4 kilobyte transfer, data streaming packets support up to 64 kilobytes per transaction. Data streaming packets also support many many more queues than messaging packets. So they are ideal for virtualization. Data streaming packets also support extended header flow control. Extended header flow control was designed to manage quality of service in systems that use client-server kinds of architectures as well as publish-subscribe. Extended header flow control allows a client to communicate the degree that its queues are full to a server, and the server can then respond with either a simple X on X off, rate adjustment, or credit based flow control. This allows the server to very tightly control the quality of service, and hence the user experience that the system is delivering. ● This chart gives some information about the RapidIO system discovery algorithm. It's a very simple recursive algorithm where, for example the microprocessor first determines that it is connected to a switch. Using standard registers, it checks each switch port, what that switch port is connected to. Device IDs are allocated to the devices that are connected, and the switch routing tables are updated. Note that at this point, the memory map of the system does not need to be determined. That is because RapidIO routes packets based on device ID, and not on address. This allows RapidIO to support any system topology. ● RapidIO also has support for fault tolerance. If a RapidIO endpoint fails, or a link to that endpoint fails, a RapidIO switch can be configured to detect that failure within nanoseconds. It can also be configured to discard the packets that are destined for that failed endpoint. This prevents a cascade congestion failure from occurring in a RapidIO system, and allows the system host or the secondary host to diagnose and recover from the fault while the rest of the system continues to operate correctly. ● If you would like more information about RapidIO, please consult any of these companies or of course my own IDT. Thank you very much for your attention, and let's go RapidIO. www.IDT.co PAGE 18
Hinweis der Redaktion
- RapidIO has it’s roots in energy efficient, high performance computing. The protocol was originally designed by Mercury and Freescale as a replacement for Mercury’s “Raceway” proprietary bus, and as a replacement for Freescale’s PowerPC bus. The RapidIO Trade Association was formed in February of 2000, and included telecom and storage OEMs as well as FPGA, processor, and switch companies. The first revision of the specification defined a wide, parallel bus. This did not achieve wide adoption. The next revision defined a serial interconnect based on the XAUI physical layer. This has been wildly successful within telecom, military compute, medical imaging, and industrial applications. Subsequent revisions have repeated this success in these markets. The latest revision, 3.0, supports 10 Gbaud per lane links. Future revisions will be capable of going even faster, tracking the Ethernet physical layer development trajectory.
- RapidIO specification is publicly available from the www.rapidio.org website.. Like many others, it is a layered specification, with logical, transport, and physical layers roughly corresponding to the layers in the ISO OSI stack. The Logical I/O specification describes how address based reads and writes work, as well as special ‘maintenance’ packets used to access RapidIO registers. The Messaging specification, and the Data Streaming specification, describe two different ways to pass messages between RapidIO entities. Messages are widely supported in the RapidIO 1.3 ecosystem, while Data Streaming packets are widely supported in the RapidIO 2.1 ecosystem. The common transport layer specification describes how packets are routed by RapidIO switches. The multicast specification is an extension of the common transport layer which describes how packets may be multicast/broadcast by RapidIO switches. The physical layer defines the nuts and bolts of packet transmission. The physical layer encoding uses 8B/10B “XAUI” encoding for lane speeds up to 6.25 Gbaud, and 64/67B “Interlaken” encoding for speeds of 10.3125 Gbaud and higher. There are a couple of specification sections which cut across multiple protocol layers . These are the interoperability specification, and the Error Management specification.
- This chart shows how the logical, transport and physical layer specifications relate to RapidIO devices. The logical layer protocol describes how endpoints exchange information. In the diagram, the uProc sends a request to a DSP, and the DSP sends a response for that request. Generally, the logical layer is supported by endpoints – those entities which originate or are the ultimate receivers of RapidIO packets. The majority of transport layer requirements only apply to switches, as the transport layer describes how to route packets within a RapidIO fabric. Lastly, the physical layer applies to any two processing elements which are exchanging RapidIO packets on a RapidIO link. As shown in the diagram, a RapidIO link consists of two unidirectional paths. There are two kinds of information which are transferred in each path: Control symbols, which are used to delimit packets, acknowledge packets, and implement hardware error recovery. Control symbols are link specific. With two exceptions, control symbols are not passed from one RapidIo link to another. Packets, which contain the actual information being exchanged. Note that control symbols can be embedded within packets, as shown in the purple Packet 2 in the diagram. This gives RapidIO a great advantage over other protocols, as RapidIO has the best possible control path latency of any protocol. The ability to embed control symbols within packets also allows for low jitter distribution of events using a Multicast Event Control Symbol and Timestamp control symbols. Embedded control symbols also allow for rapid packet acknowledgements and other low latency flow control operations.
- This shows the parts of a RapidIO control symbol. Note that every control symbol actually contains two types of information: ‘Receive Side’, or Type 0, fields are used to send information from ‘A’s Receiver to ‘B’s transmitter, such as receiver buffer status, positive acknowledgement of packet reception, insufficient resources for packet reception, or detected corrupted information. ‘Transmit Side’, or Type 1, fields are used to send information from ‘A’s Transmitter to ‘B’s receiver, such as start of packet, cancel this packet, end of packet, or restarting transmission after error recovery. The packets which are the subject of the ‘Receive Side’ information are identified by a quantity known as an acknowledge ID, or simply an ackID. AckID values are found in the Parm0 field of Receive Side control symbols, and in the first few bits of RapidIO packets. The Link-Request and Link-Response control symbols are used to implement recovery from transmission errors, as shown in the next chart.
- This chart illustrates how control symbols are used to ensure packets are reliably delivered. The leftmost message sequence chart at the left shows successful delivery and acknowledgement of RapidIO packets. Note that the ‘Start of Packet’ control symbol can be used to simultaneously terminate a packet and start another one. The middle message sequence chart illustrates what happens when a packet cannot be received by it’s link partner due to lack of resources. The receiver causes it’s associated transmitter to send a Retry control symbol, which identifies the ackID of the packet which could not be accepted. The transmitter then starts transmission with a Restart-From-Retry control symbol, indicating that it received the Retry control symbol, and then begins transmission of packets. ‘Retries’ are used for ‘receiver based flow control’ at the physical layer. RapidIO also supports transmitter based flow control, which requires the receiver to periodically tell the link partner how many buffers are available to receive packets. The transmitter then only sends wheat it knows the receiver can accept. The rightmost message sequence shows the hardware based error recovery mechanism of RapidIO. In this case, it is not possible to identify the packet which was corrupted, as the ackID value could itself have been the subject of corruption. As a result, when a ‘Packet Not Accepted’ control symbol is received, the transmitter must query the receiver to determine what ackID is expected next. This is done using a Link Request control symbol. The link partner sends a Link Response control symbol identifying the ackID of the packet to be sent next. Packet retransmission then starts again.
- Two physical layer concepts are used to determine RapidIO packet ordering, and affect latency and throughput. The first concept is packet priority. RapidIO supports four packet priorities, numbered 0 through three, with three being the highest. The Critical Request Flow (CRF) bit, found in the physical layer header of all packets, can optionally extend this to 8 different priorities. Requests can be priority 0, 1, or 2. The priority of a response packet must at least one greater than that of the associated request. This avoids deadlocks. The second concept is the virtual channel, which was introduced in the RapidIO 2.0 specification. Nine virtual channels are supported. VC0 is compatible with RapidIO 1.3 and earlier. VC1-8 may have a percentage of link throughput allocated to them, guaranteeing quality of service for a given packet type.
- This is a diagram of a RapidIO packet. Note that the fields are nicely layered, enabling an efficient hardware implementation of logical, transport and physical functions. Each layer mayevolve independently without requiring changes to all layers. We successfully tested this design objective for the protocol when we migrated from the Parallel physical layer spec to the Serial physical layer, and again with every addition to the Logical layer. Note that the physical layer includes two CRC fields. The CRC code in the middle of the packet can be used by endpoints to determine the correctness of all of the information up to that point, so that processing of the packet can begin before the packet is completely received.
- The two byte physical layer header contains a number of fields for the physical, transport, and logical layer. Physical layer fields include the ackID, as well as the priority and Critical Request Flow bits. A Virtual Channel bit allows the priority and CRF fields to be interpreted as a virtual channel number. Virtual Channels enforce minimum bandwidth guarantees for different traffic classes. The “Transport Type” field determines the size of the Transport Layer Header, as described in the next chart. Lastly, the “Format Type” field indicates the logical layer header format.
- RapidIO packets are routed using quantities called Device IDs. There are two device ID values in every RapidIO packet: The Destination Device ID, or destID, and the Source Device ID, or sourceID. Device IDs can be 8,16 or 32 bits in size, on a per-packet basis. The destID and srcID are always the same size. Whenever a RapidIO switch receives a packet, it determines how to route the packet based on the packets destID. The usual mechanism for this is a look up table which is indexed by destID. A similar, but separate, mechanism is used to multicast packets. Where a non-multicast packet is routed to a single port, multicast packets are routed to a bit vector of ports.
- The logical layer header of a RapidIO packet depends upon the type of transaction. The Logical I/O header shown on this page is used for reads and writes. Note that the reads and writes include ‘atomic’ transactions for multprocessor mutual exclusion (‘mutex’) support. The read/write/atomic subtype is determined by the ‘Transaction’, or Ttype, field. The Size field indicates how much packet data is being requested/written. RapidIO supports up to 256 byte payloads for reads and writes. The source transaction ID (SrcTID) field is used to match requests with responses. A response to a request contains the same srcTID as the request. Lastly, the address field can support either 34, 50, or 66 bits of address space. Generally, RapidIO endpoints only support 34 bits of address, as Messaging and Data Streaming transactions can be used to more easily exchange information. The size of the address field is a global system value.
- The diagram above shows the logical layer header for a Message packet. It is possible to send up to 4 Kbytes in a message-based transfer by segmenting the payload into up to sixteen 256 byte payload packets. Every message packet must receive a logical layer response. The response can have one of three status indications: Done – the message segment was successfully received Error – there is an unrecoverable error while receiving this message, so it has been discarded Retry – insufficient reassembly resources exist for this message segment – send the message segment again. The ‘Retry’ response allows hardware implementers to handle the case where all reassembly contexts are occupied and a new request is received. This allows the number of reassembly context resources to be optimized/minimized, allowing lossless messaging with a small silicon footprint.
- The diagram above shows the logical layer header for a Doorbell packet. Doorbell packets are used to send events between RapidIO nodes. Just like Message transfers, the number of queues/entries for Doorbell acceptance can be optimized by hardware. Doorbells which arrive when the queue is full receive a “Retry” response, just like Message packets.
- The last packet type in the overview is the Data Streaming packet type, more commonly known as ‘Type 9’. Type 9 packets support the transfer of up to 64 Kbytes as a single transfer. Each packet has a maximum of 256 bytes of payload. Type 9 packets do not receive a logical layer response,so reassembly resources must be available whenever a Type 9 packet is received. There are two types of Type 9 packet – Data Segment, and Flow Control. The data segment packets contain a class of service/streamID indication which simplifies routing the information to a software/hardware resource for processing. The Flow Control, or extended header, format is used to perform network level flow control for Type 9 packets based on XON/XOFF, rate based, and/or credit based semantics. Note that the physical layer transmit/receive based flow control, in combination with the network layer flow control supported by Type 9 and dedicated Flow Control packets, gives RapidIO the best flow control story in the industry. The bandwidth in a RapidIO link can be used to efficiently deliver the throughput and latency required to meet your performance requirements – however your application defines performance.
- RapidIO system discovery is similar to PCIe bus enumeration, as shown in the numbered steps of the diagram. The processor first finds the switch device, and then checks each switch port to see what is connected there. As each endpoint is found, the endpoint is assigned a device ID. The switches routing tables are updated so that packets can be routed to the endpoint. The RapidIO standard supports system discovery with two redundant hosts. Each host uses a standard RapidIO register to gain exclusive ownership of a device. If there is a collision, the RapidIO host with the smaller locking value backs itself out of the system and waits to be discovered by the winning host If discovery does not occur in a specified time, It is assumed that the winning host has failed and so the losing takes over discovery of the system. Once the winning host has completed discovery, it releases ownership of all devices. The losing host, and all other endpoints in the system, then read the configuration of the system to learn what is connected where.
- This last chart describes the Error Management Extensions for RapidIO. The reliable packet delivery of RapidIO is a good thing, until a fault happens in the system. If packets cannot be delivered, they cause congestion which can lead to a cascade congestion failure of the system. The RapidIO Error Management extensions defines Standard error detection and information capture capabilities A ‘leaky bucket’ mechanism for determining that a link is failing or has failed Standard in-band notification mechanims for errors (maintenance port-write) A flexible reaction to link failure, whose options include packet discard Standard registers to completely isolate the system from a faulty node Support for ‘hot-swap’ – card removal and insertion which does not require system reset or power down. As a result of these standard mechanisms, RapidIO systems can achieve the fault tolerance requirements of many applications.
- The RapidIO Gen 2 ecosystem has grown to encompass many DSP, FPGA, NPU, and processor vendors.