Someday someone will invent a useful engineering feature that can be plugged into telephone and email systems. Once an engineering project gets within a certain range of being complete, it will completely disconnect marketing so that they will have no way of radioing in feature changes at the last minute. But until that time, you know it’s gonna happen. And then you’re going to have to fight the fight over whether the change is worth it.
Changes can actually come from two directions: new features or the realization that there is a problem with the implementation of the current feature set. In other words, engineering might have made a mistake. So regardless of whether marketing or engineering is responsible for the change, well, to twist an overused truism, change is inevitable. While informally they might be called a nuisance, formally they’re referred to as engineering change orders, or ECOs.
The impact of an ECO can be significant on an SoC design. If masks have already been generated, the cost of a change that affects all layers can be dramatic. Before tape-out, most of the impact is felt in the schedule hit. So whenever such changes arise, a big question is how extensive the change will be, so that the monetary and/or time costs can be weighed against the benefit of the change.
Backend IC design tools already have some ECO capabilities in that you can go in and tweak some connections here and there, reconfiguring how gates and other various elements are connected. The problem is, with designs being done at ever higher levels of abstraction, there may be a lot of work in translating a high-level change specification into the resulting implications for gates. Simply redoing the design at the top and resynthesizing might toss the entire design up in the air, re-optimizing and causing a complete relayout. This means a complete new verification round, new sign-offs, and if masks were already cut, likely a complete new mask set. Attempting to translate a high-level design manually into low-level implications will have more controlled results, but will still take a long time.
A complete design will consist of a number of key elements. Of course, there will be a collection of gates, memory, and other such interconnected cells. But there will also be a clock tree that has hopefully been carefully balanced. Then there are test and diagnostic elements like the scan chain that don’t perform a fundamental part of the required function, but must interact with it to ensure high quality and reliability. And there may be a smattering of spare gates here and there to provide some cushion for changes. As an alternative (or addition) to spare gates, a programmable logic fabric may exist, which can accommodate a wider range of changes.
When some of the design logic is changed, the gate structure will change, with some gates possibly being disconnected and spare gates being engaged, or the programmable fabric being reprogrammed. But the clock tree and scan chain may also be affected. The key is being able to make all of these changes – logic, clock tree, and scan chain – incrementally.
Cadence has recently announced a product called Encounter Conformal ECO Designer that leverages their formal analysis to provide an incremental flow up to the backend, where it will handshake with backend tools. A new netlist is generated from modified RTL, and then the Conformal ECO Designer compares the old netlist with the new one to identify which portions of the design have changed. The new netlist preserves as much as possible from the old netlist, isolating the changes due to the ECO, and delivers that to the backend. The key here is that even though, due to complete resynthesis, the new netlist may look different from the old one in areas that haven’t changed, the equivalence checking can sift out those equivalent modules from the ones that have changed, keeping the old versions of the unchanged logic.
Equivalence checking plays an important role in evaluating the logic, but it’s not sufficient by itself. The clock tree is also preserved, with adjustments being made if necessary, and the scan chain is preserved, with any necessary insertions or deletions made according to changes in the logic.
Spare gates may be used for extra logic, but if the changes result in old logic being decommissioned, then those gates are “recycled” by being put back into the spare gate pool. If a programmable logic fabric is used, then the logic function in the fabric can simply be changed (assuming it remains within the resources of the fabric). These approaches help reduce the chances that a change will exceed the existing resource limits – particularly important if masks have already been cut.
The original low-level file (a DEF file, in Cadence parlance) is used along with the new netlist to perform incremental changes through the backend. While any backend fundamentally can be used, there’s a richer set of interchange with Cadence’s own backend. If masks are already in place, the tool provides the ability to restrict changes to metal-only (if feasible).
A critical factor in this whole approach is quick turnaround. While this is nice in its own right, it also makes it possible to check out the impact of a change before actually committing to the change and without waiting weeks. This should make it easier for management to decide whether the change should be implemented, or perhaps deferred to a next rev or derivative product, or even just abandoned.
Sign-off of the new design can presumably be done much more quickly, since the equivalence checking can establish that prior validations of the old logic remain valid, confining the necessary verification focus to the new logic.
The Conformal ECO Designer product has debugging features integrated, along with a GUI for slogging through any issues that arise, either through a design change or even as revisions to the design are made in the normal development cycle. The ECO tool is clearly envisioned as part of an overall Cadence flow, but it can be used as a stand-alone point tool.
This isn’t quite an end-to-end feedback loop yet, since you have one front-end loop that then feeds the back-end ECO loop. Cadence is working on full integration to provide the ability to implement or evaluate changes in essentially a single step. But steps like this may make it easier to stomach the marketing guy showing up at your cubicle door right before you’re ready to lock down the design.
