Incremental Design Breakdown

For the past two decades, most designs have been incremental in nature. They heavily leveraged IP used in previous designs, and that IP often was developed by third parties. But there are growing problems with that methodology, especially at advanced nodes where back-end issues and the impact of ‘shift left’ are reducing the savings from reuse.

The value of IP reuse has been well established. “The reuse of building blocks is fundamentally necessary in the design of systems as they become larger and more complex,” says Björn Zeugmann, group manager for the Integrated Sensor Electronics research group at Fraunhofer IIS’ Engineering of Adaptive Systems Division. “In complex designs, not every block can be designed from scratch. The first reason is less time in the design process itself. The second one is the confidence level of the sub-block. A re-used block is better verified than a new one, because more than one designer or team is cross-checking, and in many cases already silicon-proven. Incremental design is the most cost-efficient method with the highest design security, under the condition that the building blocks are well verified and measured.”

But while necessary, they may not be as valuable as in the past. “I support the hypothesis or observation that the benefits from incremental design are going down,” says Stelios Diamantidis, senior director of artificial intelligence solutions at Synopsys. “It’s not breaking down in terms of the effectiveness of the techniques. It’s breaking down in terms of the volume of things that need to happen from version to version, or from platform to derivative, that make it meaningful in productivity and in economic terms. The incremental things have become too many, too interdependent, and they are beginning to look like every optimization.”

The problem is that many aspects of design cannot be encapsulated and isolated. “Designs are getting more modular,” says Sathish Balasubramanian, head of product management and marketing for AMS at Siemens EDA. “When I say getting more modular, I mean you are able to abstract out and create a CPU, for example. That includes anything related to that CPU, all the way from implementation, to how you write your test benches, to functional coverage. If you can keep it modular and isolated, as much as is possible, and if you make incremental changes in the components, that makes your job easier.”

Engineering change orders
Within physical design is the notion of engineering change orders. ECOs are small changes made close to tape-out that limit the impact of the change, and thus the amount of rework necessary.

“An ECO was designed to be very surgical,” says Synopsys’ Diamantidis. “It’s not designed to be a high-volume process. But how can we make the process of ECO more high-volume? AI and machine learning are offering us some solutions in this space. We are trained as engineers to pursue the optimal. When we have a new set of targets, we want to be able to back out and re-optimize. The process of backing out to a certain point and then re-optimizing to a new point is something we haven’t done before. However, machine learning is extremely good at being able to learn, and statistically distribute the usefulness of certain solutions at different points in design evolution. This is a highly dimensional big data problem, and we could develop models that allow us to back the design out to a point, and then re-optimize to a new solution, with high automation, guided by humans. Today it is manually executed by humans, and we run into the productivity bottleneck.”

One such solution is the utilization of high-level synthesis. “In the context of high-level synthesis (HLS), there is a constrained problem set for which it works really well,” says Frank Schirrmeister, senior group director for Solutions & Ecosystem at Cadence. “They even call it an ECO. When you find out that something doesn’t work in implementation, you can quickly make a change, and then rerun the high-level synthesis through to the implementation flow.”

Many of these types of changes are limited to digital design. “In an RF design, the slightest change to your output has a big impact,” says Ian Rippke, system simulation segment manager at Keysight Technologies. “Maybe you find out that your antenna designer couldn’t hit things quite as broadband as you hoped. Now you have a slightly different impedance profile, and that almost necessitates going back through the entire RF design process — quickly, of course, because you’re doing it as an iteration. But there’s not a way to localize the impact of those kinds of changes.”

But even for digital, it is becoming harder to localize those impacts. “Even a simple incremental ECO can look as though it should be pretty small, but it may have many back-end implications, forcing you to run through the entire flow,” says Siemens’ Balasubramanian. “That is very well automated in terms of doing the back-end implementation, but verification is a bottleneck.”

Processor design
Specific areas have developed tools and methodologies that enable incrementality. A prime example is with processor design. Extensible processors include Tensilica, ARC, as well as RISC-V.

“There is a methodology designed to re-use components, but modified to meet your workload,” says Cadence’s Schirrmeister. “The requirements are imposed by the workload. This is the domain where you deliberately say, ‘If I add these five instructions, then I need to store less, and I can get to a completely different implementation of the algorithm. I can get to a completely different implementation requiring different memories, or a smaller memory, or have a more low-power optimized version of your design because you get that implementation optimized for that workload.'”

In some cases, it starts with a dedicated high-level language targeting the hardware. “We have HLS that is domain-specific, and it is intended for the design of CPUs,” says Zdeněk Přikryl, CTO at Codasip. “It enables us to capture information about the instructions, about the pipeline, about how it’s connected together, how multiplication or division is implemented, and so on. In one recent example, we started with the RISC-V baseline and then played with different combinations of extensions. We were able to generate simulators, RTL, and we could profile that. We could see the impact of a change on performance, size, or memory footprint. Then we explored custom extension and defined some new instructions. The problem is contained.”

At a time when domain-specific designs are a differentiator, being able to customize processors is critical. “Everyone wants something slightly different when it comes to processors,” says Simon Davidmann, founder and CEO of Imperas Software. “Knowing this, Tensilica and ARC made sure they had a methodology that enabled many variants around a processor architecture. Today, with RISC-V, OpenHW is taking the same approach. They provide a complete environment around their cores, so that if you want to make a change, you can verify that you didn’t break anything else. Sure, you still have to add the verification for the bits you changed, but the problem has been contained.”

Analog difficulties
Another kind of incremental design may not change anything in the design. Instead, it may retarget an existing design to a different process node, or be applicable to a different market segment. “This is getting more common in the analog world,” says Balasubramanian. “The same design can be targeted toward a seven-sigma or five-sigma requirement based on the vertical application space. When they re-target, or do an incremental design where there is a change in the underlying technology or the process technology, that’s a whole different ballgame. It affects the entire design cycle.”

Analog always has had problems. “There are huge differences between the analog world and the digital world, and then there is mixed signal in between,” says Schirrmeister. “In the pure analog world, you do some IP reuse, but it’s more at the foundational level of what the person knows — how to lay out transistors and so forth. And that’s really where the experience kicks in.”

Digital assist can help. “I see a lot of digital circuitry being incorporated into analog IP,” says Balasubramanian. “For example, I’ve seen digital calibration circuits being part of the PLL circuitry, or the clocking circuitry, where they’re actually building in some handling of variability. Now they can tweak the analog using the digital circuits. This means they get the right analog behavior by design. The design has a wider range of operation and is more flexible, if and when they need to tweak any of the parameters.”

Part of the problem for analog is that process technology is optimized for digital. Could you change the underlying process rather than change the design? “Analog devices have been constrained in terms of scaling,” says Robert Mears, CTO for Atomera. “A typical 5 volt transistor, in most implementations, will probably have a gate length of somewhere between 0.5 and 0.6 microns. It’s a little bit difficult to scale beyond that and still keep reliability for those devices. By going to an asymmetric architecture, we can distinguish the source and drain side doping profile. And then, holding those doping profiles in place as you scale the gate length, we’ve been able to scale the gate length down to a 0.25 micron. That’s a factor of two, and therefore a factor of two in terms of higher current and lower resistance, etc.”

Jeff Lewis, vice president for business development at Atomera, provides some additional details. “You can epitaxially grow the silicon and the film together to create these layers of MST. This is going to increase the drive strength of any transistor (see figure 1). Within the footprint of a device, without changing the litho or anything else, you can get a better PPA operating point. You may decide to take that as is, take the higher drive current, which will make the circuit faster. Other people may want to use it to reduce the cost by shrinking the transistors until the drive currents match to make a denser platform at any node. Or you can reduce the power, which could be interesting for some IoT applications, by lowering the supply voltage until the drive currents match — or some retuning and combination all three.”

Fig. 1: Changing the process to enable design reuse. Source: Atomera.

Some common analog problems have sought a different solution. “The design of a SerDes is ahead of the more general analog and RF side because at least there’s a modeling standard,” says Keysight’s Rippke. “You can build an IBIS model, or an IBIS-AMI model, which captures a fair bit of the effect of what’s going on inside. But it still doesn’t change the fact that any small tweak to that work of art, which was the previous generation, constitutes almost an entire entirely new design. We see this in memory when moving from DDR4 to DDR5. It’s not just a matter of increasing the data rates and sticking with the same chip and module structure. You are back to the drawing board. People know what the framework needs to look like, the inputs, the outputs, and what type of eye diagrams you want to get. But what’s inside that model becomes a fundamental challenge for reuse.”

Isolation
Another way to increase the effectiveness of reuse is to increase isolation. “Chiplets are naturally pushing us into this whole idea of well-established control points from which we can optimize forward,” says Diamantidis. “This paradigm doesn’t only apply to the silicon. It also applies to systems design.”

There is a lot to learn from the system development process. “You find these natural levels of IP reuse, because these things are fixed,” says Schirrmeister. “Some people don’t call it design anymore. They call the blocks ‘entities’. You may have three performance versions of a processor, different memories, and I am plugging these together. There are still system-level issues I have to deal with, because suddenly things like the software that deals with power bring-up may not work in certain configurations of design entities. That’s adding a whole new layer of complexity, because now you have the physical constraint of a chiplet.”

Chiplets add their own complexities. “In the system world, the idea of IP reuse really comes down to having validated models, and this expands into the chiplet situation, as well,” says Rippke. “A chiplet that’s going to eventually mate to the rest of that design in a heterogeneous integration process has to be characterized enough so the people who are consuming it can get reasonable results out their simulations and understand the performance — both the capabilities and the limitations. They can’t necessarily give away all their IP in the form of full-circuit schematics or netlist, or even full data sets. There is a fantastic opportunity for enhancing the modeling process of these different types of circuits or ICs.”

This is playing out right now with the introduction of the UCIe standard. “This relates to the creation of modular architectures,” says Balasubramanian. “It helps by creating a standard at a higher abstraction, with functionality contained in a chiplet. For an incremental design, it may be tied to a particular chiplet in an SoC. The verification, or any changes that needs to happen, are very self-contained. This is the way to improve the throughput in terms of semiconductor design going forward. But there is a downside. It is not an optimum. Anytime you use an abstraction or modular architecture, it is never optimal compared to an integrated architecture.”

Design for incrementality
When it is known that there are likely to be many design variants, or that an incremental approach will be used in the future, there are some methodologies that help maximize the benefits. “Most of our customers build product lines that are based on a derivative strategy,” says Diamantidis. “That derivative strategy will basically spin anywhere from a couple to maybe 10 or 20 chips. They will all have a similar architecture, but will select different features, different operating conditions for different markets. The question becomes, instead of becoming really good at incrementally changing an optimized design, how can we take a step back and create designs that are more explorable and optimizable across a spectrum of conditions and for different targets very quickly and effectively. In other words, build it into the original design. How can it be built into the RTL, and even the constraints, or floor plans, the physical aspects, so we can leverage the variability?”

To do this we may have to learn from adjacent fields. “At the board level, there are some interesting things that are being done in the RF and microwave space,” says Rippke. “Companies that have a whole family of products might have some internal best practices where they work with specific footprints, or they work with certain general configurations. Then when a slight change is needed, you have a methodology built up to work with those types of changes or adjustments. It still necessitates an awful lot of re-simulation and redesign, because you can’t necessarily drop in a new transmission line. But at least having that common bounding condition helps an organization. These methodologies are unique to individual companies. It is not something that’s getting passed around the industry, like a standard, like an IBIS AMI modeling standard. There’s no open consortium for board models.”

Conclusion
IP reuse is not going away because there is a huge amount of domain expertise often integrated into an IP block. The value of that reuse is not diminishing, in fact it may well be going up. The problem is that the back end increasingly is being impacted by unintended couplings that are causing an increasing amount of global analysis to be performed. The industry does not have the models or methodologies in place to properly handle this.

While some progress is being made in terms of design incrementality, the problem of incrementality in verification is a topic unto itself and that will be examined in a future story.