As systems-on-chips move into next-big-thing markets like autonomous vehicles or the Internet of Things (IoT), SoC designers are facing new kinds of requirements—environmental, life-cycle, reliability, and security, for example—completely foreign to their experience in consumer or communications applications. These requirements, in turn, are changing the way SoC developers must evaluate and integrate intellectual property (IP). And more than ever, developers’ IP decisions are directly affecting the success of their customers, the system developers—through issues that might never appear on an SoC data sheet. Papers at this month’s Design & Reuse IP/SoC Conference shone a spotlight on some of these hidden issues.
Figure 1. Many efforts contribute to achieving long operating life for an SoC.
The system architectures of cars and other vehicles are entering into a fundamental transformation. A block diagram of today’s car shows clusters of single-function micro controller units (MCUs)—as many as hundreds of them—each connected to its local sensors and actuators, and tied to the rest of the vehicle through a bewildering web of industry-standard and proprietary busses and point-to-point links. This tangle gives no one processor a clear view of the entire state of the vehicle. It reduces the opportunity for redundancy or error recovery. And—of more immediate concern to auto manufacturers—this approach entails very significant cost and weight for cabling.
The future will be different. “Starting with premium brands like BMW and Jaguar, the architecture is evolving to a single Ethernet backbone,” said OmniPhy CTO Claude Gauthier. “Initially this will be based on 100 Mb IEEE 802.3 bw or 1 Gb 802.3 bp: industrial/automotive profiles running over a single twisted pair.”
This change will spell the end for many of those little MCUs. Instead we will see mixed-signal SoCs fusing sensor data and controlling actuators, blending local processing with support from a central electronic control unit. At the heart of the system will be a heterogeneous multicore SoC reminiscent of the CPU chips in servers.
None of these SoCs represents a new architectural challenge. But creating these chips for a car will be a new experience for an SoC design team that has not previously served the automotive industry: a full-immersion class in a world previously dominated by small automotive-grade MCUs and mixed-signal components.
“This is a different market,” Gauthier warned. “Qualification times are very long, yet changes in specifications happen very fast. We are still in the realm of speculative standards.”
Many of the issues in that long qualification process should spur new discussions between the SoC design team and their IP vendors. Obviously there will be new functions, like that 802.3 bw Ethernet interface. But there will also be new temperature ranges, new reliability requirements, and new quality regimens, like AEC Q100.
Q100 is a set of stress tests designed around known IC failure modes, intended to estimate the failure rate of chips over the extended product life demanded by the auto industry. Many of the tests focus on failure modes in packaging. But some study die-aging issues of direct concern to SoC developers.
Specific tests in this category include checks for electromigration, time-dependent dielectric breakdown, hot-carrier injection, negative-bias temperature instability, and stress migration. Passing these tests will require the SoC’s foundry to get Q100 qualification for a process variant. But it will also require IP vendors to ensure that their designs on the Q100-qualified version of the process can also pass the tests. Since non-infotainment automotive is an emerging market for SoCs, odds are that even silicon-proven IP cores have never been through Q100 examination in silicon built on a Q100-qualified process.
AEC Q100 explores the potential for hardware failures in an SoC. But there is another aspect of reliability of increasing interest to automotive designers: design errors. Functional safety standards such as ISO 26262 attempt to mandate use of formally-verified or field-proven components and software. Consequently, automotive SoC users increasingly are asking just how the SoC designers did their design verification. And that curiosity is turning up a rather embarrassing issue.
The problem arises in how SoC design teams verify the IP they use. There is a bit of a dilemma.
On one hand, designers may want, and automotive customers may demand, the highest possible level of verification coverage. On the other hand, thorough simulation of an SoC design may be impossible. There may not be adequate verification results on third-party IP blocks, or sufficient information to include them in full-chip simulations. The integration process may introduce problems not visible at block level. But the fully-integrated SoC may be too large for useful simulation, especially during software integration, when the simulation model has to be fast enough to execute code.
All these issues contribute to the growing interest in FPGA-based emulation. In principle, a team can whip together an FPGA board with the needed I/O, load in the SoC logic design, and do verification runs—from functional to cycle-accurate—at nearly real-time speed.
But in a cautionary paper, Atos engineer Huy-Nam Nguyen warned that FPGA prototyping held its own challenges. Nguyen focused on two specific issues. First, FPGA prototypes have limited controllability and observability compared to simulators. Consequently it is wise, Nguyen said, to design the prototype with particular stages of verification in mind. And even so, turn-around time from proposing a test to understanding the results can be quite long.
The second issue is more fundamental. Porting IP to the FPGA at the very least requires active assistance from the IP developer. Often, this porting effort becomes a design in its own right, diverting resources from the SoC design, and diverging structurally and even functionally from the original IP. On occasion, moving the IP to the FPGA may simply prove impractical.
Nguyen cited a recent example of a third-party PCI Express® (PCIe®) core in an SoC design. The core was a Gen3 x16 implementation. But when translated into FPGA programmable fabric, there was only room and speed enough for a Gen1 x1 core. Using this version would have changed the entire traffic flow in the design, Nguyen said. So the team decided to use the native hard PCIe in the FPGA, and to not verify the IP vendor’s core design at all. Hence the SoC team delivered to the systems designers a chip in which at least one major IP core had never been verified in the design.
Test is another issue. As Silabtech CEO Sujoy Chakravarty put it, “The automotive industry wants a crazy level of design-for-test coverage.” A test design the IP vendor feels to be perfectly adequate may be rejected in a system design review by an automotive customer.
These points offer an important warning. Even if your SoC vendor uses silicon-proven IP, and even if the chip receives thorough verification, it may still not meet the requirements for critical automotive applications. This is a challenge that military contractors have lived with for years, as they tried to employ commercial off-the-shelf components in military-grade systems. But it may come as a rude surprise to many of today’s system design teams, as they seek to apply their areas of expertise to a suddenly-interested automotive market.
Even though most IoT applications will require nothing like the reliability and safety standards of the auto industry, the IoT will have its own ways of uncovering issues with IP. Many of them involve the stringent energy-consumption restrictions under which the IoTs must operate.
The closer you get to the outside edge of the IoT, the more tenuous becomes access to energy. Wall warts give way to tiny batteries, and batteries to energy-scavenging. Energy conservation becomes obsessive. Low-voltage operation is a given, even into the near-threshold range of 0.5-0.4V, where the basic rules of circuit design start to change. Duty cycles get stretched, as designers aim for long quiescent periods at near-zero power punctuated by tiny bursts of activity. All these strategies have implications for the SoC developer’s IP decisions.
Like the pursuit of automotive-grade reliability, the quest for low-voltage operation begins at the foundry, with new, ultra-low-voltage process variants and libraries. At the conference, Globalfoundries director of design engineering Gerd Teepe described efforts to use the adjustable body bias of a fully-depleted silicon-on-insulator (FDSoI) 22 nm process to reach 0.4 V operation with minimal performance loss. On paper, Teepe said, a 22 nm FDSoI device powered at 0.4 V could operate at just 8% of the power of a standard-voltage chip.
Operating a FDSoI chip in this range requires not only significant body bias, but new cell libraries as well. The extent of these changes became clearer in another paper, in which TSMC technical manager Marco Vrouwe described the program to take his organization’s new 16 nm compact FinFET (ffc) process to 0.4 V operation. Vrouwe said several factors came into play. One is that voltages so close to threshold amplify the effects of both supply-voltage variations and process variations. Another is that in this range, the distribution of process variations is skewed, requiring changes to the algorithms in timing tools.
In the end, Vrouwe said, it was necessary to perform a sort of triage on TSMC’s 16 ffc libraries. Some cells behave well at 0.4 V. Others require redesign to tolerate the greater variations. Still other cells could not be desensitized, and were removed from the low-voltage libraries.
New libraries and process corners raise an obvious question for SoC developers. Do they just use existing soft IP in the new environment and hope that it actually gets synthesized into working circuitry at 0.4 V? Or do they insist on silicon validation at the new process and voltage? Which choice the chip developer makes will have great importance to system designers.
The demand for energy conservation also influences IP integration. For instance, if a block is going to operate at low voltage, it will be significantly more sensitive to IR drop on power rails, and potentially to substrate coupling. Problems here would not be detected by normal IP verification. Other decisions external to the IP block can also cause failure, especially for hard IP, according to Silabtech’s Chakravarty. If the block is power-gated—as it is likely to be in low duty-cycle designs—will the switch transistors on the power rails work with the existing IP? How about muxes to I/O pins?
There will also be a need for entirely new kinds of IP. Olivier Thomas, project leader at CEA-LETI’s Silicon Impulse unit, described the IP his organization has for the unique issues at the edge of the IoT.
To cope with the increased impact of variations, Silicon Impulse has developed a body-bias controller block. This bit of IP monitors process variations, operating voltage, die temperature, and in some cases timing slack during operation of the chip, and dynamically adjusts voltage and frequency. There are also sensing cells, energy-harvesting blocks, and processors optimized to work efficiently in very-low-duty-cycle bursts. “We aim to get power consumption down to picoWatts during waiting periods, and microWatts during sensing operations,” Thomas said.
These new sorts of IP will be necessary for many IoT endpoints. But initially they will be relatively unproven. How the SoC vendor deals with the uncertainties they create will influence both the performance and the reliability of IoT systems—often, systems assembled by application experts with no visibility of the chip designers’ choices.
The opening of driver-assistance and autonomous-vehicle markets to complex SoCs is creating new requirements for extended temperature range, long-term reliability, and functional safety. The edge of the IoT is demanding new operating voltages, new modes, and aggressive new energy-saving functions.
All of these needs require SoC designers to consider IP choices they may not have focused on before—choices that involve parametric and side-channel characteristics of the IP blocks rather than the logic function or timing. What the chip designers decide will impact the quality—even the acceptability—of the systems into which the SoCs will go. It is time for system designers to insert themselves into some of the IP decisions.