editorial

Struggling toward a New Methodology for Deep-Submicron Design Creating a practical methodology for complex IC design based on reusable IP requires tight integration of design tools. Unfortunately, that's a good way off. by Jonah McLeod

The current era of rapid product obsolescence doesn't exempt the methodology used to design complex chips. The history of the design automation industry is filled with one wave of design methods displacing the one that came before: schematic capture giving way to HDLs, hardware prototypes supplanted by simulators. In each advance in method, the designer is being further abstracted from the fundamental building block of the circuit, the individual transistor.

This abstraction is reaching a new level in reusable intellectual property, and it's arrived much faster than previous ones. Just as the individual transistor gave way to ASIC library of TTL SSI and MSI, to be supplanted in turn by the ASIC library, the ASIC library is now giving way to complete reusable logic blocks. Just when designers had constructed well-understood design methodologies for developing ASICs, now they're having to change to accommodate large blocks of reusable logic.

In their book Reuse Methodology Manual, Michael Keating and Pierre Bricaud describe the existing ASIC design methodology as the waterfall model: System architects with application expertise, create an algorithm that is passed onto HDL experts, who convert the algorithm into code and synthesize it into logic, which is then passed on to layout engineers, who turn the netlist into transistors on an IC. Messrs. Keating and Bricaud state that this process works well on designs of some 100,000 gates and implemented in a 0.5-µm process technology.

However, designs of a million gates or more implemented in a 0.35-µm process technology and below will demand what they call a spiral development model. In this approach, a team of designers concurrently perform hardware design, software design, physical layout, and timing analysis. Those who can swiftly adopt this new methodology will succeed; those who don't are likely to fall out not only of the mainstream of high-end ASIC design, but of their markets as well.

The new methodology makes some fundamental assumptions about next-generation complex ASICs. It assumes that they're built around a microprocessor or DSP (or both) and that a large part of the final system is defined by the software running on these processors. Software implies that the system will have a program stored in memory embedded on the IC. Another assumption is that in most cases the system will contain a block for transforming data--graphics or communications--received from some external source. Finally, it assumes an I/O subsystem for communicating on and off chip as well as a datapath to perform some processing of the data.

Now, consider the problems associated with building such a complex circuit with the new design methodology that Keating and Bricaud propose. The software and hardware specification of the system must be done concurrently and cooperatively, not to mention proceeding in lock step with one another. The design tools to perform these functions are available from Synopsys--it acquired the Eagle Design tools with the acquisition of Viewlogic--and Mentor Graphics with its Seamless Co-Verification Environment.

In the new methodology, physical and timing specifications--chip area, power, and clock tree, along with I/O timing and clock frequency--are likewise being developed in parallel with the hardware and software specifications. Analysis tools, like those from Epic--now part of Synopsys--Pearl from Cadence, and Star-RC and Star-Power from Avanti, are critical to making this part of the methodology work.

For the near future, this methodology will fail because it lacks a tight integration between tools and different designers in the design flow: Algorithms are thrown over the wall to HDL designers, who throw netlists over the wall to layout engineers. More importantly, the necessary point tools are supplied by different vendors, with the links between them still the Unix scripts of old.

Indeed, these tools have their own database, and the loose links between tools are prohibiting the tight integration needed for deep-submicron designs. The process is further complicated by reusable blocks. Each block is implemented in its own design flow, which invariably differs from the flow used by the designer who wants to reuse the block.

It seems to me that solving this problem of a next-generation design flow will be absolutely critical to the increase in design productivity. Up to now, no vendor has the solution, nor is there a de facto methodology emerging from the design community. Do you agree?

To voice an opinion on this or any Integrated System Design article, please email your message to miker@isdmag.com.

integrated system design  January 1999