Practical Chip Design

The question of design intent—information on how the design is intended to behave, as opposed to its structure and implementation—is quietly becoming a central issue in the technologies that surround SoC design. It is becoming clear, as some industry visionaries predicted years ago, that downstream functions such as verification, test, and manufacturing must have some way of interpreting the intent of the design in order to do their jobs. Today perhaps it is a matter of efficiency. Tomorrow it will be a significant factor in life-cycle cost for an SoC. And in the near future, at least for work in advanced processes, it will become a necessary condition for any shipment at all.

The first rumblings along these lines came from the semiconductor equipment industry. Mask-makers and process engineers, deep in their life-or-death struggle against variations, realized that they were spending enormous resources on compensating for variations that simply didn’t matter to the design. The classic case is performing detailed OPC decoration, mask inspection, mask repair, and process tuning to preserve the exact shape of dummy metal objects. In the absence of design intent information, the mask makers and process managers have no way of knowing whether they are working to preserve the pretty but meaningless corners on a blob of metal, or working to control variation in the impedance of a critical RF inductor.

But design intent can be as critical to verification and test as it is to manufacturing. Traditionally, verification engineers learn about design intent in digital circuits primarily through timing constraint files and through circuit description documents. The situation has improved somewhat for designs that make extensive use of embedded assertions, but there are still often times when it is difficult to tell whether a block is misbehaving in a critical manner or a totally irrelevant manner, because it is unclear what the thing is really supposed to do.

Test is becoming an even more serious problem. This came up in a conversation today with Lavi Lev, president and CEO of ATE manufacturer Credence. Lev, as those with long memories will recall, has been an advocate of open standards for communicating design data since his days at Cadence. Perhaps less-known was his eventually futile work to create an open format for design intent at Cadence, so that this data could be created by EDA tools and passed to mask and production engineers.

Now finding himself in the test industry, Lev is once again finding the need for design intent downstream from the chip architects. He points out that two factors—the increasing frequency of operation and increasing complexity—are forcing SoCs to be tested as subsystems rather than as conventional components.

In the short term, that means such techniques as what’s becoming known as BOST: built-OUT self-test. In this approach, the load board on the tester becomes not just an impedance-matching fixture but an emulation of the system in which the SoC is intended to work. The ATE stimulates the chips on the load board, which in turn generate transactions with the SoC, record the results and even perhaps do preliminary analysis. BOST substantially reduces the bandwidth between the SoC and the tester mainframe, substantially reducing the tester cost and helping with test time—all with minimal impact on silicon area. Obviously it’s generating interest in the consumer electronics world.

But BOST requires and understanding of what the SoC is supposed to do in-system. Than means BOST, at least as much as BIST, has to be architected into the design from the beginning, not pasted on by test engineers who have analyzed the structure of the chip without knowing its application.

Another point. A number of people in the test industry have commented, and Lev agrees, that as SoCs become more complex, we will have to introduce a new level of abstraction into the test plan. At some point it no longer matters whether all the functions in the chip are working correctly. Some may be unused, some may be redundant or self-healing, and some may have a wide range of acceptable behavior. What matters is that the completed system works satisfactorily for the end-user.

But that question—does the end product work—cannot be derived from the structure of the SoC design. It can only be determined by comparing the system design intent against the behavior of the full system, whether the latter is physical or partially emulated.

So we are back to needing a means by which SoC architects and designers can communicate design intent beyond the sphere of the design team. Clearly this will need to be done in an open, standardized way. Just as clearly, it may involve abstractions and concepts that we are not currently using, including for example the ability to give imprecise specifications of behavior. There’s a big job here, beyond the reach of any one company short of an IBM or maybe an Intel. But it’s a stealth problem, becoming intractable more rapidly than it is becoming visible. We need to pay attention.