|
Accommodating Change
Cadence Announces a Front-End ECO Tool (Bryon Moyer)
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. [more]
|
