Is history repeating itself?
PCI Express has become a mainstream PC technology that has quickly supplanted parallel PCI and AGP in the PC platform, much as parallel PCI displaced ISA and VLB busses over a decade ago. And now, history is about to repeat itself in the embedded industry – only, with a twist.
Parallel PCI was first introduced in the mid 90's by Intel in order to provide a high-speed peripheral pipe into their increasingly faster PC processor. Earlier processor busses, including the ISA bus, required only simple interfaces that could be glued together with TTL devices and some small PLDs. PCI, on the other hand, required a "bridge" to handle the more complex protocol and tight timing that the spec demanded in order to achieve significantly higher throughput. Graphics chip makers, such as ATI and Nvidia, were among the first to embrace the high bandwidth that PCI enabled and incorporated the interface directly on their GPUs. Other common PC peripherals such as disk controllers and Ethernet were serviced by silicon with native PCI interfaces.
With the momentum around PCI created by the PC industry, it was inevitable that embedded systems would embrace the technology. The diversity of requirements in the embedded market created the need for bridging solutions that could enable PCI in non-PC systems. Thus, the PCI-to-local bus bridge was introduced by companies like PLX Technologies, V3 Semiconductor (QuickLogic), AMCC, and Tundra. This helped to fuel the transition away from proprietary embedded systems buses to PCI as the single most ubiquitous interconnect technology of embedded systems.
The introduction of PCI Express has seeded another transition. Again, the move to PCI Express is driven by Intel and the insatiable appetite of the PC processor for higher data rates than legacy PCI can accommodate. Quixotic attempts, like PCI-X, to beef up parallel PCI to meet the challenge have had lackluster success and will represent only a blip in history compared to the impact of PCI Express.
The transition to PCI Express in the embedded industry is well underway. Much of this requirement is being serviced by legacy PCI bridges. Much of the pain associated with the original transition to parallel PCI was software as PCI imposes a discipline for system resource discovery, enumeration, and driver interaction. For PCI Express, compatibility with legacy PCI has ensured that the software transition bottleneck has been mitigated. Consequently, the transition to PCI Express can be as simple as slapping a legacy bridge onto an existing design and you're done. For many applications, where the legacy PCI bus isn't a performance bottleneck, this approach will be adequate. While the additional cost, area, and power of the legacy bridge is an obvious drawback, the simplicity of the solution is compelling.
Real-time video capture: No more dropped frames?
Video has become one of the 'killer apps' for PCI Express due to the high bandwidth of high-definition (HD) content, especially when uncompressed. With features such as simultaneous transmit/receive, virtual channels, and scalability of link width, PCI Express is certainly up to the task of HD video. The advantages of PCI Express cannot be realized when legacy PCI to PCI Express bridges are in the signal path. Take the case of HD video including 1080p60. The raw data rate for 1080p60 video is:
Bitrate = 1080 (vertical lines) x 1920 (horizontal pixels) x 24 (bits per pixel) x 60 frames per second = 2.99 Gb/s (373 MB/s)
For 32 bits per pixel, this increases to 3.98 Gb/s (498 MB/s)
Considering that video typically includes audio and other metadata, the bandwidth requirements increase still further. If we compare this to the peak raw bandwidth of PCI/PCI-X, we have:
- PCI 32 bits, 33 MHZ = 132 MB/s
- PCI/PCI-X 64 bits, 66 MHZ = 528 MB/s
While a 64-bit, 66 MHz PCI/PCI-X bus has sufficient bandwidth in theory, in practice it is tenuous even at 24 bits- per-pixel. This is due to the overheads of PCI and PCI-X that prohibit them from achieving anywhere close to their theoretical peak bandwidth in real systems. Typically, there can be a 30 percent overhead (a little lower for PCI-X) resulting in a usable bandwidth of 370 MB/s. This is on the edge of the requirement for 1080p60/24BPP video and provides no margin.
Another factor to consider is that conditions in the system, such as virtual memory spill/fill to disk, may create periods of latency where data flow is restricted for a few milliseconds. This creates the need to "catch up" after such an event. Unless there is sufficient additional bandwidth, then it may be impossible to catch up before another such event thus resulting in frames of video being dropped.
By contrast, a four-lane PCI Express link provides about twice the bandwidth of a 64-bit, 66 MHz PCI/PCI-X bus. Unlike legacy PCI, data can move in both directions simultaneously. This doubles the bandwidth again for applications that operate full duplex. With that much additional bandwidth, a four-lane PCI Express video capture solution can ensure continuous capture.
PCI Express provides the bandwidth and performance features to enable a new level of performance for applications such as video capture. At the same time, 1080p50/60 video equipment is invading both broadcast studios and living rooms. What are the options available to implement an application like video capture over PCI Express?
Non-ASIC options for implementing PCI Express
For common PC applications, such as Gigabit Ethernet, RAID/SATA, 3D graphics accelerators, etc., there are cost-effective, off-the-shelf ASIC solutions. However, when dedicated solutions aren't available, the choices are less clear. The main solutions are as follows:
- Custom ASIC: For cost and time-to-market reasons, this solution is out of reach except in applications that ship in very high volume.
- Legacy Bridge: This option provides quick time-to-market by simply attaching a PCI Express-to-PCI bridge to an existing legacy PCI design. However, the legacy PCI bus becomes a bottleneck. For cost-sensitive applications, the legacy bridge is an extra cost. If performance is not as important, then this option may be acceptable.
- FPGA: Implementing PCIe in an FPGA requires high-speed SerDes capability, which can be expensive. Also, the FPGA option is a time-consuming endeavor requiring the system designer to purchase IP, integrate the IP with the PHY and application logic, close timing in the FPGA, undertake a lengthy verification task, and compliance-test the result. Also, there are system issues to consider when using FPGAs such as "live at power-up" and firmware upgrade limitations (see description below).
- FPGA with an external PIPE PHY: Using a dedicated PIPE PHY chip together with a lower cost FPGA, where the SerDes capability is not present, may provide a lower cost alternative. However, for four-lane (or larger) PCIe solutions, the pin count of a PIPE PHY is significant. This, in combination with the relatively large transaction/link layer IP required for even basic operation, excludes the smaller "low cost" devices. Also, the PIPE PHY solution doesn't solve any of the lengthy development cycle issues associated with PCI Express.
- Application-Specific Standard Products: ASSPs, such as the Gennum GN4124 local-bus endpoint bridge, can provide all of the PCI Express endpoint functions (PHY, link layer, transaction layer etc.) to enable a simple interface to a custom endpoint application. Similar to the traditional local bus bridges that eased the implementation of the original PCI bus in embedded systems.
The remainder of this article will focus on the last three options...
|
