As we all know, the physical portion of the digital integrated circuit design process --placement, routing, clock tree insertion, power routing, extraction, timing, signal integrity, and so on -- is becoming a nightmare with today's humongous ICs. One big problem is that, in the majority of design environments, there are multiple tools from disparate vendors with custom scripts and "micro tools" used to stitch them all together and patch any holes in the flow. This typically results in a sequential methodology, which in turn results in downstream processes causing changes that make you have to loop back and redo things over, and over, and ... you get the idea.

Another big problem is capacity limitations in tools, which prevent them from handling multi-million gate designs in their entirety. The solution is to partition the design into blocks, place and route the individual blocks, and then stitch them all together at the end, which is where your problems really begin. According to a recent study by Collett International Research, these problems mean that over 50% of designs require four or more place-and-route iterations and over 50% of designs require two or more silicon spins. The end result, as reported by the engineering management software company Numetrics Management Systems, is that 85% of all chip design projects that actually make it into volume production miss their target schedules.

This is obviously a bit of a downer -- something has to be done -- but what? The answer according to Monterey is system-driven physical design, which means (a) having a completely integrated suite of physical design tools from system level to GDSII and (b) simultaneously performing all of the steps associated with physical design on the entire chip or block.

Like many things, this sounds wonderful if you say it quickly, but then you start to noodle on it and you end up thinking "but how can this be possible?" For example, it's easy to say "all of the tools are running simultaneously," but then we come to consider just what this implies: clock tree insertion running simultaneously with the placement and routing engines, which are themselves working simultaneously with the extraction, timing analysis, and signal integrity engines. The mind boggles. And we want to do all of this on a multi-million gate design?

It makes your eyes water just thinking about this sort of thing. My knee-jerk reaction was "pull the other one, it's got bells on it!" But wait! Monterey has come up with a truly cunning solution that appears to be the answer to life, the universe, and everything (at least everything to do with physical design). Yes, you guessed it already, the answer is "Global and simultaneous optimization coupled with continuous model refinement." (This is obviously a bit of a mouthful, so I'll take it upon myself to come up with a catchy name ... let's call it GASOCWCMR -- pronounced "gass-oh-quick-mer" -- for short!)

GASOCWCMR
As usual, there really isn't enough room in a small column like this to do justice to a ferociously sophisticated piece of software engineering (which I'm told has taken 300 person-years of development time to bring it to market). Thus, the following will, of necessity, be a simplified version of the whole story. We'll start with Monterey's physical implementation system: Dolphin. This little rascal treats all aspects of the physical design simultaneously and is said to be able to take a multi-million gate netlist to GDSII in a single pass! The following figure illustrates Dolphin's key sub-systems.

Dolphin physical design system

Placement is timing-driven; routing is gridded and gridless shape-based; signal integrity includes cross-talk noise, IR-drop, and electromigration; logic optimization includes timing fixes and area recovery; timing includes full-chip static timing analysis and crosstalk delay analysis; clock includes clock tree construction and balancing with or without useful skew; extract features full 2.5D extraction; and power includes automated power routing.

The trick here is that all of these subsystems work simultaneously. You know what it's like to work in a sequential manner. You place the design and are ready to route it, but when you come to insert the clock tree you run into problems and have to regress. In the case of Dolphin, everything happens at the same time, so the clock trees are implemented during place and route. Similarly, the power grid is being developed at the same time as IR-drop analysis is being performed, and so forth.

But once again we come to the question, how can you have all of these implementation engines running simultaneously on a multi-million gate design and hope to see any results while you are still young enough to appreciate them? This is where the full cunning of Monterey's global optimization and continuous model refinement approach is revealed. Dolphin starts off by dividing the chip into four quadrants (called "bins") and then it performs a full chip physical implementation using any available information.

Dolphin "bins"

Obviously the information is somewhat sketchy at this stage, so everything is modeled only to the appropriate level of abstraction, and Dolphin concentrates on making global design decisions. Since Dolphin is making only high-level decisions and using extremely simple models at this stage, this level of analysis can be performed very quickly. Of course the resulting physical implementation is somewhat simplistic ("this block is in this quadrant"), but it provides a starting point.

Next, Dolphin increases the number of bins, and uses the results from the first realization to perform a new full-chip physical implementation. By this time there is more information available, so the models used can be more sophisticated, which means that this pass will be computationally more expensive. On the other hand, this pass doesn't have to deal with everything, because all of the up-front, high-level decisions have already been established by the previous pass, so it doesn't take as much time and effort as you might otherwise expect.

And so it goes, with Dolphin increasing the number of bins and refining the analysis until the final implementation is reached (the total number of bins/iterations depends on the size of the final chip). With regard to the continuous model refinement, let's consider one of the routing connections as an example. In the first pass, Dolphin has only high-level statistical information as to the general route/location of each connection, so a lumped capacitance (C) model is most appropriate.

As the number of bins increases, the routing of the connection becomes more deterministic, and Dolphin can start making "guesstimates" such as "this connection will probably require three buffers which statistically will appear somewhere around here, here, and here." As the connection becomes more deterministic, Dolphin progresses from a lumped C model to a lumped RC model to a distributed (2D) RC model and, eventually, to a full 2.5D extraction model.

Having an estimate as to the number of buffers and their approximate positions has ripple-on effects with regard to placement, routing, static timing analysis, signal integrity, logic optimization, clock tree synthesis, power design, and so forth, all of which are being performed at the same time.

It may sound crazy, but it works! Monterey's system-driven physical design has been successfully used on 20-million-plus gate designs, and its extraction results and signal integrity analysis are so good that they are already accepted as being of sign-off quality by some of Monterey's key customers.

Of course I've only touched on Dolphin's capabilities here, and I should point out that Dolphin itself is part of a larger offering that includes the IC Wizard Hierarchical Design Planning Tool and the Sonar Physical Prototyping Tool. You can find out more about all of these little rapscallions at Monterey's web site. As for myself, I'm well impressed with what I've seen and I'm prepared to agree with Monterey's claims that they've turned the design flow on its head. The idea of performing a high-level full-chip physical implementation with just four quadrants and then continuously refining this to a detailed implementation would never have struck me in a thousand years, but once you've see it you slap your forehead and say "of course, what a good idea!"

So this one certainly gets an official "Cool Beans" from me. Until next time, have a good one!

Clive (Max) Maxfield is president of Techbites Interactive, a marketing consultancy firm specializing in high-tech. Author of Bebop to the Boolean Boogie (An Unconventional Guide to Electronics) and co-author of EDA: Where Electronics Begins, Max was once referred to as a "semiconductor design expert" by someone famous who wasn't prompted, coerced, or remunerated in any way.