Integrating high-speed serial I/O: no snap for SOC designers

High-speed-serial-data transfer has ancient roots in the worlds of mass storage and communications. But increasingly, high-speed serial I/O is the method of choice for getting large amounts of data on and off SOCs (systems on chips). System designers are seeing high-speed serial I/O as an alternative to the wide parallel buses that were common on processor chips and SOCs.

“In our DSP space, high-speed serial started out as chip-to-chip interconnect and evolved into use in backplanes,” says Ramesh Kumar, manager of wireless-baseband infrastructure at Texas Instruments. “In basestations, you have lots of data moving around.We saw buses go to 64 bits wide and then to 100 MHz, but this [increase] still wasn’t enough to keep up with the data-flow needs.

“So, several generations ago, we offered high-speed-serial-I/O pins as alternatives alongside the wide buses. Initially, customers looked at the serial links and avoided them because of the apparent difficulties. But that [situation] has changed totally now.”

A version of this evolution has taken place across the SOC industry, as fast data flows move from wide buses to RapidI/O, GbE (Gigabit Ethernet), HDMI (high-definition-multimedia interface), or some other serial standard. The change has the potential to vastly simplify board layout, substantially reduce the energy that data transfers consume within systems, and avoid signal-integrity nightmares. But it is not without challenges of its own for both chip and board designers.

Most often, SOC teams implement a high-speed serial link by licensing and integrating a piece of third-party IP (intellectual property). Even TI’s baseband-chip teams, with their substantial resources, import serial-I/O IP from other teams within the company. Design teams with no high-speed serial-expertise must license third-party IP from outside, making it vital to understand the contents of a technological component such as a PCIe (peripheral-component-interconnect-express) or GbE I/O block.

The first thing to observe about a fast serial-I/O block is that it is not a trivial piece of silicon. For a technology such as PCIe, just the PHY (physical) interface can be large and complex, and it can be a significant power sink (Figure 1). The PHY layer typically contains a local oscillator, a phase-locked loop, and other CDR (clock-data-recovery) circuitry; handcrafted clock and power-distribution networks; and serial-to-parallel-conversion logic. The analog portions of this block operate at the full clock frequency of the data link, which can be 1 to 10 GHz. In addition to the PHY layer, there will normally be a mostly or all-digital-protocol-controller block, a mostly analog-I/O-transceiver block, and often a fourth block of supporting circuitry to provide supervisory functions ranging from power and clock gating, to digital-configuration logic, to a microprocessor interface. The two digital blocks may be synthesizable, but the two mixed-signal blocks are not.

The SERDES (serializer/deserializer) and its associated analog circuitry is normally hard IP. “In some ways, this [situation] makes integration of high-speed I/O simpler,” observes Prasad Subramaniam, eSilicon’s vice president of design technology. “You can apply pretty standard practices for shielding, isolation, and signal integrity and otherwise treat the analog block as a black box.” Whether the I/O-transceiver cells are embedded in the SERDES or separate, you must treat them with care; they can be complex and are distinct from standard-library-I/O cells, but they are also hard IP.

The rest of the interface, including the protocol controller and most supporting circuitry, normally are synthesizable RTL. Thus, the complete package would comprise a few synthesizable pieces and one or more hard, process-specific blocks.

Like any other high-performance mixed-signal IP, high-speed serial-interface blocks require careful selection—perhaps more care in the choice of vendor than in the IP itself. Design managers and IP vendors alike say that the difficulty of integrating high-speed I/O blocks and the success rate both depend heavily on the IP vendor. “When you are talking about something like a PCIe [generation]-2 interface at 5 GHz, ... the IP is running very fast, [and] the receiver is operating on very small margins,” observes Navraj Nandra, director of product marketing at Synopsys. “There are many other issues IP vendors must deal with, as well. They must have a deep understanding of signal-integrity issues and detailed knowledge of link termination for the interface in question. And these high-speed links have to be self-diagnostic: The IP must include sufficient design-for-test provisions.”

Nandra warns that, even with a laundry list of skills to check off, vendor selection and evaluation of a piece of IP cannot be easy tasks. He divides his view of the evaluation process into three areas: For I/O that conforms to an industry standard, he recommends independent compliance testing of test silicon fabricated in the process you intend to use. Nandra emphasizes the importance of not inferring anything from a test chip that works at a different process node or even—when you reach more aggressive geometries—at a different process variant from the same node and foundry. The SERDES is a delicate RF design that porting can easily break.

Second, Nandra suggests getting a test chip in your process that contains both the interface IP and a programmable noise generator. “You want to get a characterization report that describes the IP’s robustness in the presence of digital noise,” he explains.

And, at 65 nm or smaller processes, Nandra says, you should see split-lot test chips in your process. “You need to understand your IP vendor’s test-chip methodology,” he says. “[The vendor] should be able to use the test chips to discuss with you the impact of process variations and voltage variations on the design, so you can address these variations in the layout.” Nandra and others emphasize that the purpose of test chips is not to prove that the IP can work under some ideal set of conditions, but to explore its robustness across the whole range of conditions your design will encounter.

Hemant Shah, product-marketing director at Cadence, goes further. “The only way to feel good about your IP selection is to model the block in the board environment where the chip will be used.” Shah warns that it does no one any good if the IP merely operates correctly on the die in loopback mode—it must exchange data with other chips across the board or backplane.

Therein lies a problem. Good tools exist for modeling the operation of high-speed-I/O pins with extracted board parameters, but the tools often lack good models. (See sidebar “Signal integrity for SOC designers.”) “Vendors will often offer you IBIS [I/O-buffer-information-specification] models,” says Subramaniam, “but they are minimally useful. Some IP vendors offer encrypted Spice models.”

Those models help a little more, Subramaniam says, but they are still not enough to give you an idea of how a piece of serial-I/O IP will work with a package and board. For one thing, Spice’s designers never intended it for this application and certainly not at these frequencies. For another, Shah points out, “Transistor-level models can be accurate, but, in practical terms, you can run them for only a few hundred bits of data transfer. That’s nowhere near enough to get an idea of bit-error rate, which is a critical parameter.”

Cadence has tried to attack this problem with an extension of the IBIS standard to provide for executable models that can accurately represent interfaces at these speeds. The company has proposed the extension to the IBIS committee, and Shah says that at least a couple of IP vendors are now shipping executable models they base on the proposal. But the idea still has a long way to go before achieving wide acceptance.

Another approach is to get S-parameter models of the package from the package vendor, and extract S parameters for the intended board design, and then hand this data back to the IP vendor and let the vendor characterize its own IP on its internal tools. That approach requires a certain amount of trust.

Subramaniam argues that the most practical approach is to get test silicon from the IP vendor—in your process—put it into your package on your board, and measure it. Synopsys has tried to shorten this approach by providing test silicon in what it considers a worst-case wire-bond package (Figure 2) on the assumption that if the die works at the end of great loops of wire, it will work anywhere. “There’s 5 nH on some of those wires,” Nandra says.

Another important factor in IP-vendor selection is that your chosen vendor will be your partner during the integration process. And it will be a process.

“This is a critical mixed-signal-IP block,” Nandra says. “You will want IP that is designed for worst-case placement on the floorplan. You will want documentation on the kind of guard rings, separate power supplies and grounds, and clock sources it will require. You will want rules and guidelines. Even so, support from the vendor is essential.”

Subraminiam emphasizes that many SERDES designs require extremely clean clock signals. This situation probably holds truer with higher bandwidth interfaces. “Each SERDES design has its own requirements,” he says. “Often, they require special, custom-designed clock-buffer cells in the clock-distribution network. These [cells] should come with the IP.”

Routing becomes an exercise in signal-integrity analysis. “The big problems come when you are using multiple channels on one die,” Subramaniam says. “You must do extensive simulation of the die/package/board combination. And placement, routing, and supply provisioning all become factors in signal integrity.” Subramaniam says that eSilicon has developed its own simulation tool to deal with the problem.

As the integration process moves forward, dividing up the noise margin among the various sources becomes something of an art. Often, IP vendors give specifications on allowable supply noise. But they may not indicate how much margin their specification leaves for the rest of the system. If you use up too much with poor signal-integrity design on the die, you can have a surprise at the chip level. “You can end up needing a package that costs more than the die,” Subramaniam warns.

All of this advice is great if you know in advance the details of the system environment. But more often, you don’t know. What if you can’t be sure about the package type or the board design? Programmability comes in handy in this scenario.

The I/O buffers on many high-speed serial blocks provide programmable pre-emphasis on the transmitter side and equalization on the receiver side, so the block can adjust to a range of environments. Perhaps the worst-case scenario for programmability would be FPGAs with on-chip serial interfaces. A single design must handle a small range of packages, a large range of interface standards, and a huge range of application scenarios.

Altera’s design team focuses on these conditions. “We’ve found that it’s easy to make a transceiver that mostly works,” says Misha Burich, senior vice president for R&D. “But what you need is a robust design that leaves the margin to the customers rather than using it up internally.” To cover the range of applications, Altera designs its own I/O cells with programmable pre-emphasis and adaptive equalization. “It’s very special technology compared to our general-purpose I/O cells,” Burich says. The Altera team also makes huge investments in modeling, simulation, and test chips. “We typically have two iterations of test chips for the I/Os,” Burich says.

So, you spend a lot of time evaluating IP vendors, verifying that real test silicon works in your environment, and then working with the vendor to integrate the blocks following all the integration guidelines. At that point, what are your chances of success?

“If this is your first silicon at a new node, with proven IP, you have a good chance of success,” says Subramaniam, “but not 100%. Not every design will be production-worthy on the first try, irrespective of the history of the IP.”

For that reason, Subramaniam recommends an additional step: evaluating the IP not just to fit your application and its production history, but for its flexibility. “Look for a high level of software programmability. Look for good access for test and debug, and the ability to change all the settings on the critical circuits,” he says. “To some extent, the more you can adjust things, the more you can avoid repair. And, just in case, look at the IP’s internal routing to see how much the design can be altered with changes to just one or two mask layers.”

For many SOC designers, high-speed-serial I/O is here to stay and probably to proliferate around the periphery of their die. Understanding the risks, the integration problems, and the flexibility that the chip user will need to meet package-cost goals and adapt to the board design is vital. Awareness of these factors is not only essential to design, but also necessary to properly evaluate the IP during the selection process. Even so, the most important steps may be measuring test chips in a realistic environment and making the IP work in an unanticipated environment. It’s an uncertain art, but it is an art, not just a gamble.