Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Interface

To bridge or not to bridge: When, why to go PCIe-native

Posted: 03 Sep 2007 ?? ?Print Version ?Bookmark and Share

Keywords:PCIe-native solution? PCI Express connectivity trade-offs? bridge interface?

As the deployment of PCIe-native systems becomes more ubiquitous, many of the commonly used endpoint solutions are being redesigned for PCIe connectivity. These include network interface cards, storage host bus adapters (HBAs), graphics cards, parallel port cards, and a host of other I/O functions that were previously available with PCI and/or PCI Extended (PCI-X) interfaces. However, many of the endpoint chips have not been redesigned as PCIe-native ICs. In fact, for many, there is no plan to ever do so. This article examines the trade-offs associated with the deployment of PCIe endpoint solutions using PCIe-native silicon vs. using PCI (or PCI-X) silicon and adding a PCIe-to-PCI/PCI-X bridge.

These bridges have appeared in the market to allow endpoint designers a quick migration path to PCIe and to create PCI/PCI-X slots on PCIe-native system boards. It was assumed from the outset that these bridges would only have a market until all endpoint solutions were available using PCIe-native silicon. After a few years of having PCIe systems in the marketplace, however, there are still several endpoint solutions that have not been redesigned with native PCIe interfaces.

The trade-offs involved in deciding whether or not to migrate an endpoint chip into PCIe native include the cost of the silicon implementation with PCIe-native vs. the size of the opportunity and the endpoint's performance requirements, and the availability and compatibility of PCIe IP required to develop a PCIe-native solution.

What are the factors that go into deciding whether or not to deploy a bridge? To simplify the discussion, assume that a PCI-X-native solution with sufficient features and bandwidth is already in production, and that the question is whether to use or not that solution with a bridge to PCIe, or to develop a completely new ASIC to replace the PCI-X bus with a PCIe link.

Shorten time-to-market
The two most compelling reasons to use a bridge with an existing PCI/PCI-X solution are time-to-market and development cost. The time-to-market advantage is pretty obvious: Using two existing proven solutions allows the designer to go right into board layout, with the bulk of the development cycle being in the qualification stages. The time-to-market advantage is achieved from the reduced time it takes to execute a new chip design, create the new mask set, and validate and qualify the new silicon. This would ordinarily require a year or more, which is added directly to the development time of the card. A time-to-market delay can result in significant lost revenues, as competing solutions are selected.

In addition, the development cost of the PCIe-native solution can be significant. In fact, it is overwhelming for lower-volume programs that cannot absorb the millions of dollars required for a chip, which includes 2.5Gbps PCIe links.

The need to add a bridge is eliminated when a new ASIC is developed with a PCIe link. The board space and the required pins to support the PCI or PCI-X bus associated with the bridge are also eliminated. The bus interface requires over 100 pins, but this number is reduced to four pins (for a PCIe x1 link or 16 pins for a x4 link). This pin reduction can reduce both the ASIC cost and footprint size.

The demand for a PCIe SCI card would be met by playing a PCle-to-PCI-X bridge in front of an existing SCSI HBA.

Performance considerations
The performance of the solution may be increased or reduced by adding a bridge. The bridge itself introduces latency, which can degrade the throughput for bursty traffic. However, the use of prefetch can increase the throughout, assuming that the PCIe devices can specify the prefetchable address space. This is typically only available in embedded systems.

Creating a SATA RAID storage controller card using PCIe native siliconSATA RAID controller solutions emerged a few years ago, initially with 32bit PCI interfaces. As performance demands increased with SATA-2 drives, 64bit PCI-X interfaces became the norm. When PCIe hit the scene, servers quickly converted over to PCIe, driving a need for a rapid development of PCIe versions of the same RAID controllers. Some RAID card designers inserted PCI-X-to-PCIe bridges to provide the PCIe connection, while others went to work on PCIe-native ASICs to deploy on their new RAID cards. Another did both and phased in the PCIe-native solution after winning some early adopters with bridge-based designs.

Using a PCIe-to-PCI-X bridge to create an SCSI HBAThere was not enough market opportunity for parallel SCSI storage, so there was no business case for creating a PCIe-native SCSI HBA chip. This meant that the demand for a PCIe SCSI card would be met by placing a PCIe-to-PCI-X bridge in front of an existing SCSI HBA. Its benefits were reduced time-to-market and development costs.

Using a reverse-mode PCIe-to-PCI bridge to create PCI connectivity on a graphics card that uses PCIe-native siliconGraphics cards with PCIe-native silicon have been in the market for several years, while few (if any) PCI-native graphics chips have been designed since PCIe emerged. However, a large market still exists for PCI graphics cards because the large installed base of PCI gaming systems need to upgrade their video capability, and limited PCIe slot availability in current systems often forces system integrators to use a PCI slot for graphics.

As a result, recent graphics card designs use PCI-to-PCIe bridges in front of PCIe native graphics chips. This gives PCI-based systems access to the latest GPU features such as DDR2 memory support, 400+MHz engine clocks and dual-link DVI. Not deploying the latest GPU features in PCI-native chips requires GPU manufacturers to use reverse-mode PCIe-to-PCI bridging to get the PCI connectivity required for legacy systems. Reverse-mode bridging is when the upstream port is the PCI side, and the downstream port is the PCIe side. Not all PCIe-to-PCI bridges support reverse mode. The PEX 8111 and PEX 8114 bridges from PLX support both forward and reverse operation.It's never easy for designers to decide whether to use a PCIe bridge or develop PCIe-native solutions. They need to weigh factors such as time-to-market, development and manufacturing costs, performance, connectivity, and feature-set enhancements. Once they have, they'll be in a better position to answer the question of to bridge or not to bridge.

- Steve Moore
Senior Product Marketing Manager
PLX Technology Inc.

Article Comments - To bridge or not to bridge: When, wh...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top