English
How to pick a RapidIO switch
Here are the secrets to selecting the right RapidIO switch--and to picking a vendor that help you with the design process.
By Barry Wood, Tundra
dspdesignline.com (February 20, 2009)
The RapidIO interconnect offers many advantages for embedded systems. It combines high bandwidth with low cost and low power, and it is suitable for both control plane and data plane applications. Successful RapidIO systems use switch-based topologies, so one of the key decisions system designers must make is which switch to use. This article outlines the decision factors that designers should consider, organized by project development phases: system design, implementation, system verification, and system evolution. A last section discusses support services, which impact all stages of project development.
System Design
Designers have many different options for implementing a RapidIO interconnect. RapidIO supports all possible topologies (tree, ring, star, etc.), and different inter-processor communication paradigms (read/write and messaging). To choose the system, the designer must answer questions such as: Does my design work? Is this the best design? Where are the risks with this design? In addition to setting the system design, these questions can impact which switch product, and which switch supplier, is right for your application.
Some basic criteria to consider when selecting a RapidIO switch are performance—including packet latency and throughput—and the amount of power the switch consumes. As a first step, the designer should perform a spreadsheet analysis to compare the latency and throughput against the design requirements. This quickly eliminates any switches that simply will not work in the design. If no switches past this analysis, the designer must find a way to reduce the design requirements.
Often, systems have complex traffic patterns which defy simple spreadsheet analysis. To confirm that the chosen system design will work, and that it is the best one, two approaches may be used: Prototyping, and system modeling. Your switch vendor should be able to support both of these approaches.
By Barry Wood, Tundra
dspdesignline.com (February 20, 2009)
The RapidIO interconnect offers many advantages for embedded systems. It combines high bandwidth with low cost and low power, and it is suitable for both control plane and data plane applications. Successful RapidIO systems use switch-based topologies, so one of the key decisions system designers must make is which switch to use. This article outlines the decision factors that designers should consider, organized by project development phases: system design, implementation, system verification, and system evolution. A last section discusses support services, which impact all stages of project development.
System Design
Designers have many different options for implementing a RapidIO interconnect. RapidIO supports all possible topologies (tree, ring, star, etc.), and different inter-processor communication paradigms (read/write and messaging). To choose the system, the designer must answer questions such as: Does my design work? Is this the best design? Where are the risks with this design? In addition to setting the system design, these questions can impact which switch product, and which switch supplier, is right for your application.
Some basic criteria to consider when selecting a RapidIO switch are performance—including packet latency and throughput—and the amount of power the switch consumes. As a first step, the designer should perform a spreadsheet analysis to compare the latency and throughput against the design requirements. This quickly eliminates any switches that simply will not work in the design. If no switches past this analysis, the designer must find a way to reduce the design requirements.
Often, systems have complex traffic patterns which defy simple spreadsheet analysis. To confirm that the chosen system design will work, and that it is the best one, two approaches may be used: Prototyping, and system modeling. Your switch vendor should be able to support both of these approaches.
|
E-mail This Article | 
|
|
Printer-Friendly Page |
|
||||||
