Practical Chip Design

During a panel discussion on the challenges of designing advanced SoCs yesterday, one of the rarely-mentioned issues in the chip design cycle momentarily crept into the spotlight. Bringing up the silicon—a delicate and time-consuming task that tends to get little thought from the EDA community and often only belated afterthought by chip designers—emerged as a potential threat to engineering schedules as chips become more complex. As this is exactly the topic of a feature article in our 21 June issue of EDN, the discussion had my attention from the outset.

The topic was raised by the one SoC design manager on the panel, Microsoft Xbox engineering manager Srinivas Nori. “Beyond tape-out, you still need tight cooperation between the people bringing up the silicon, the IP providers and the foundry,” Nori said. “If the chip isn’t working, the IP blocks and the process aren’t black boxes any more—you have to be able to get inside them to find out what’s going on.”

Rob Aitken, R/D Fellow at ARM, joined in from his own perspective. “You need to prepare for debug. Think of it as insurance: you invest silicon area and time to use DfM tools to reduce your design risk. In the same way, you invest area and time in putting debug and diagnostic circuitry on the chip.”

Aitken went on to tell of one hapless engineer who was called in at the end of a project to bring up a piece of essentially inert silicon. The lead designer had left the group, and there were no apparent provisions for observing or controlling the chip during the debug process. So there was essentially nothing he could do—the task was impossible. And he was receiving daily calls from a VP asking when the chip would be ready.

Aitken observed that such experiences tended to encourage design teams to try putting diagnostic hardware into their designs next time. “And once they put it in, they never take it out again,” he concluded.

Conversation in the panel moved on to other topics, but the debug challenge quickly resurfaced. In the context of IP reuse, Nori made a plea for the inclusion of diagnostic hardware in every third-party IP block. Going further, he asked that the IP industry establish a standard for diagnostic functions and a diagnostic interface in each IP block, much the way the chip industry long ago accepted the JTAG standard for discrete digital ICs.

Nandan Nayampally, CPU product manager at ARM, at that point joined in the discussion. “We see debug as a key technology,” he declared. “It’s not just about the CPU—in these super-complex multiprocessor SoCs it needs to extend beyond the CPU to the rest of the system. In particular, when you have a cluster of CPU cores on the chip, just establishing coherency is a serious challenge—we need diagnostic hardware with a standard protocol to make these chips debuggable. That is not such a problem within one organization, but extending it the third-party IP vendors who make very different kinds of functions is harder. It would be hard, I think, to get a consensus that includes memory IP vendors, for instance.”

Nayampally probably is being realistic about the difficulty of establishing a standard diagnostic interface and protocol. But there is a great deal at stake in terms of schedule risk. Nori, for instance, explained earlier in the panel that Microsoft planned several generations of graphics controller chips for its Xbox 360 at the outset of the program. The overall profitability of the Xbox was calculated based on the appearance of new cost-reduced silicon at intervals. Any significant slip as the Microsoft engineering team ported the design to successive process nodes would impact the profitability of the entire product line.

To me, creating the consensus for a diagnostic interface and protocol sounds like a job for the VSIA. Not only has the organization successfully brought IP vendors together before, it has done so on contentious issues that required the vendors to take risks in exchange for intangible rewards. In this case the risk—adding hardware to the IP block and agreeing to use an industry-standard debug protocol—could result in very tangible rewards, for the IP vendor, the chip designers and, let us mention, the foundry that will end up selling wafers only after the silicon is working.