Design tools that interact with both design and process databases are becoming increasingly common as we move deeper into the world of design-for-manufacturing (DfM.) So far, most of the discussion in the industry has been about how we will import enough foundry data into the design tool chain to empower DfM tools. But the recent relationship announcement involving Blaze DFM and TSMC raises the other side of the question: are there times when a DfM tool is properly a foundry tool and not a design tool?

The new relationship involves what TSMC is calling a Power-Trim Service. In effect, you send them a design, along with your sign-off timing slack numbers, and TSMC will for a fee reduce the leakage-generated power consumption of your design by anywhere from 20 to 30 percent (typical, of course) while you sleep, without altering the netlist. (Well, without restructuring it. See below.) The service will be offered on selected process variants from 90 to 45 nm, and will be applied to digital nets only, for reasons that will be obvious in a moment. Power reductions should be applicable even if the design is already using aggressive power-management techniques, and the customer will not have to license the Blaze DFM tool.

So how does this magic work? Once the design data are inside the foundry, TSMC will apply the Blaze tool. The tool inspects each non-analog and non-memory net for positive timing slack. If it finds enough slack on a net, the tool begins to marginally increases the gate lengths of the transistors on the net—not by substituting high-threshold transistors from the dual-threshold library, but by making subtle suggestions to the OPC tool about decoration of the polygons in the gate region, leading to an increase the effective length of the printed gate on the silicon. Because it is done with the OPC tool, this change is accomplished without altering the GDS-II layout.

The longer gate length, of course, both slows the transistor down and decreases the sub-threshold leakage current. (How this lengthening impacts gate leakage and junction leakage are not as obvious, so things could get more complex with 45 nm and smaller poly-gate processes.) The task continues until all the excess timing slack up to the guard band has been absorbed. The result is that the tool manages to do away with enough sub-threshold current to achieve the stated static power reduction in most cases, according to Blaze.

Nice. But is this a DfM tool, or is it a foundry tool? We are accustomed to think of leakage-reduction tools as in the EDA space. But the business model strongly suggests that this is an exception.

One way to look at the question may be to follow not the money, but the data files. The Blaze tool requires the design GDS-II, the netlist, and the timing files. But it also requires a great deal of information from the process engineers. The tool makes "rather conservative" changes to gate length, according to Blaze CEO Jacob Jacobsson. But it still has to make those changes by interacting with the foundry's OPC tool. And the foundry has to set and verify the limits of just how much the gate length can be fudged, and has to provide the resulting timing models. For instance, you can't make the gate so long that you significantly disturb the strain-engineering structures that go over or around the gate or under the channel. That is a great deal of work that is specific to a particular set of transistors in a particular process variant. "Hence, the close relationship with TSMC," Jacobsson observed. "It takes a lot of real silicon to validate what we are doing."

Observing the amount of data that has to be exchanged between the tool and the design team, and between the tool and the foundry, may be a good way of predicting who is going to end up running the tool. In the case of OPC tools, it's an open-and-shut case. The vast majority of the tool's information is coming from the foundry's process data collection. In the case of a power tool that simply chooses high- or low-threshold transistors, very little data comes from the foundry—just the two transistor models—and that data is relatively static. In this case, the interactions are weighted more toward the foundry side.

This metric has interesting implications for the future. What are the implications for cell design, which TSMC has already chosen to absorb? How will we end up classifying process-aware place-and-route tools? As process variations drive us from rule-based to model-based place and route, will those tools migrate into the foundry, even though there is at this stage still considerable interaction with the design team? For that matter, what about the hypothetical process-aware synthesis tools?