Renesas 可提供高性能、低功耗、低延迟的 RapidIO 交换机系列产品，是每串行链路高达 6.25 Gbaud 的对等多处理器嵌入式系统的理想选择。 Renesas 的 RapidIO 交换机具有低功耗、低延迟等特点，并具备业内领先的互操作性、可配置性和每端口功率。 目前，Renesas 正在销售适用于无线、视频、军事和工业应用的第五代 RapidIO 交换机，可同时支持 RapidIO 1.3 和 2.1 标准。

RapidIO 交换机是用于芯片对芯片、板对板和机箱对机箱链路的 3G 和 4G 无线基站的基础，其中包括可实现开箱即用布线的 S-RIO 协议的安全加密/解密。 该全套产品使移动宽带的普及成为现实。 Renesas RapidIO 可将高清晰度实时成像、视频和电话会议系统带到人们的生活中。 在军事和嵌入式计算中，Renesas RapidIO 的可靠性和耐用性在战场上得到了充分证实，它使导弹更安全，并使原始设备制造商 (OEM) 能够在战斗机至舰载电子设备等任何应用中部署复杂的多处理器系统。

RapidIO 是在对等网络中连接嵌入式处理器集群的理想选择。到目前为止，采用其他嵌入式互连的系统尚无法实现这一点，这种系统需要多个处理器，并且必须在处理器间交换大量数据，具有可靠的低延迟性能，无协议终止的软件管理费用。

Renesas 的交换机产品组合包括各种功能丰富的产品，可涵盖全部所需的端口数量和带宽要求。 凭借 Renesas 的 Tsi 和 CPS 交换机组合系列产品，我们可提供业内最全面的 RapidIO 交换机系列。 下载 Renesas S-RIO Switch Feature Comparison Chart (PDF)，了解 CPS 和 Tsi RapidIO 器件的详细比较情况。

接口&连接

产品选型表

    Processing table
    器件号
    Throughput (Gbps)
    Cut Through Latency (ns)
    RapidIO Lanes
    Ports (#)
    Multicast Masks (#)
    Individual Port Shutdown
    On-Die Scope
    Packet Trace/Mirror/Filter
    Prog Rec Equal per Port
    S-RIO Specification
    80HCPS1432
    RapidIO Switch    		 160 100 32 14 40 Yes No Yes Yes 2.1
    80HCPS1616
    RapidIO Switch    		 80 100 16 16 40 Yes No Yes Yes 2.1
    80HCPS1848
    RapidIO Switch    		 240 100 48 18 40 Yes No Yes Yes 2.1
    80HSPS1616
    RapidIO Switch    		 80 100 16 16 40 Yes No Yes Yes 2.1
    RXS1632
    16-Port, 32-Lane, 400 Gbps, 10xN RapidIO Switch    		 400 100 32 16 256 Yes Yes No Yes 3.2
    RXS2448
    24-Port, 48-Lane, 600 Gbps, 10xN RapidIO Switch    		 600 100 48 24 256 Yes Yes No Yes 3.2
    Parametric Table tips

    Tips for Using This Parametric Table:

    • Hide Filters button in header: Collapse or expands filters
    • Column sort buttons in header: Sort Column alphabetically / numerically descending or ascending
    • Reset button in header: Reset all filters to the page default
    • Full Screen button in header: Expand the table to full screen view (user must close out of full screen before they can interact with rest of page)
    • Export button in header: Export the filtered results of the table to an Excel document
    • Filter parts search bar in header: Type to filter table results by part number
    • Hide column button in column headers: Select to hide columns in table
    • AND / OR toggle switches in header: Toggles the logic of this particular filter to be “AND” or “OR” logic for filtering results
    • Multiselect checkboxes at beginning of each row in table: Select these checkboxes to compare products against each other
    • Document icon next to product name in row: View the featured document for this product
    • Chip icon next to the right of the document icon in row: View the block diagram for this product
    • Cart icon to the right of the chip icon: Indicates that samples are available for this product

    视频和培训

    Introduction to Serial RapidIO® (SRIO) by IDT

    Description

    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.

     

    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.
     
    Video List