Using RapidIO® Technology as a System-Level Fabric
- Created on Saturday, 01 September 2007
Both Serial RapidIO and Ethernet are being used as a backplane interconnect technology in a wide range of embedded applications. Many suppliers support both standards and let designers choose to work with whichever interconnect they feel is best. This neutral position provides interesting insights into both of these technologies. From a high-level point of view, it seems as if these two technologies are in stiff competition with each other. While Ethernet is certainly the incumbent technology, Serial RapidIO has had a huge uptake in adoption over the past year, with more silicon vendors supporting the standard than was originally anticipated.
Even for those applications where native Serial RapidIO processor interfaces seem to be limited, efficient bridging silicon to those interfaces that are supported is readily available. While it appears that this might be a neck-and-neck race between the two technologies, the reality is that nothing is more sacred in design than adopting the appropriate technology for an application. In other words, the number of design wins isn’t so much a factor of deciding which interconnect to use as a system-level fabric as it is deciding which performs the best for the job at hand.
From this perspective, Ethernet and RapidIO aren’t really in competition with each other, despite how they may seem to be pitted against each other by different vendors in the marketplace. In reality, the two standards don’t really compete with each other. Ethernet was designed to connect computers and it just isn’t an appropriate standard to transfer data chip-to-chip. While the argument of Ethernet’s high volumes and economies of scale applies to LAN and WAN applications, the features and higher layer protocols required for system-level fabrics comprise a completely different ecosystem with considerably lower volumes and higher costs. Additionally, Ethernet’s switching capabilities are overkill for point-to-point links and needlessly increase system complexity, latency, and cost in these applications.