Embedded Systems Design Europe - November 2007 - (Page 28) wireless Comparison of components required for each implementation. The shaded areas represent non-optimal approaches. Components Video over wireless USB Video over IP Video over UWB Host functions required Device functions required Uses native PC video path Table 1 UWB + CPU MIPS + software driver UWB + GPU + wireless USB stack No UWB + encoder + IP stack UWB + decoder + CPU + IP stack Yes UWB with light video compression UWB with light video compression Yes the UWB chip on the host to the UWB chip on the device, as shown on Figure 3. However, because video must be sent using USB protocol, special software is required to capture and send video data over the USB bus. This configuration software has several negative effects. First, the system can’t use the video rendered by the integrated GPU. Second, the CPU is burdened with special software to send graphics data to the remote decoder/GPU. The result is both slower video and system performance because fewer CPU MIPS are available for running normal applications and I/O. Third, system cost is not optimal because the integrated GPU isn’t used. Finally, the USB protocol overhead and latency introduced by sending video over USB means that significantly less bandwidth is available for remote graphics, which further limits performance. Note that, since the PC’s high-performance GPU is not used in this topology, 3D graphics will not render, effectively making the system unusable for gaming and other applications. A unique additional decoder/GPU is required on the device side to display graphics. This IC can be thought of as a remote GPU that performs the functions of the idle and unused integrated host-side GPU. Because additional ICs are needed, extra cost, complexity, and memory are also added to support this approach. In the Video over IP approach shown in Figure 4, an additional encoder chip on the host side interfaces to the GPU to compress and encode video before it’s input into the UWB transmitter. A matching decoder chip is needed on the device side, among other requirements. Additional CPU and memory chips are also required on the device side to implement an IP stack and perform housekeeping for the display decoder, thereby increasing the complexity and the number of ICs on the device side. For the display, Video over IP is unnatural compared with a traditional video display architecture. The Video over IP approach is significantly more complex, power hungry, and costly compared with either a wired or Video over UWB approach. Considering the number of additional ICs required for some of these architectures, developing a system that optimizes the number of components is a complex problem to solve. Video over UWB with light-compression algorithms is one technology that’s reduced the number of components, as shown in Table 1. When so many additional components are required, primary concerns include component size and cost. It’s easy to see with the previous examples that the impact on those areas can be significant. Analyses of the bills of material have shown a greater than 20% increase in total system cost with the Video over wireless USB and Video over IP approaches versus the Video over UWB option. In addition to the architectural differences, a thorough benchmarking study using digital-video benchmarking software reveals differences such as CPU load, latency, performance, and bandwidth efficiency among the various approaches. CPU load is an important consideration, especially if multiple applications are running simultaneously or if the user is running CPU-intensive applications such as a media player. The performance differences in this area are quite telling. Comparing the three approaches, the Video over UWB Summary for the three wireless digital-video implementations. The shaded areas are non-optimal approaches. Function Video over UWB Video over wireless USB Video over IP Host CPU load Refresh rate Capable of movie playback Capable of game play Host side cost Device side cost Latency Video protocol complexity Video BW efficiency Table 2 Zero 60 Hz Yes, without exception Yes, without exception Low, uses existing PC GPU Low, uses existing PC GPU Low Low High High (up to 100%) Varies with CPU load No, unless in small windows with reduced frame rates No, not capable of 3D graphics Low, software driver Medium, requires low-end GPU High Medium Very low Some (up to 20%) Varies, 30 Hz typical Yes Yes, with significant latency High, additional HW encoder High, additional HW decoder + CPU High High Medium 28 NOVEMBER – DECEMBER 2007 | embedded systems design europe | www.embedded.com/europe 026-027-028-029_ESDE.indd 28 6/11/07 17:23:10 http://www.embedded.com/europe
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.