Synopsys tries to organize its efforts in EDA multiprocessing

It’s hard to imagine a set of applications that need computing resources more than the chain of EDA tools for a 65 nm chip design. (OK, searching for extraterrestrials, maybe, but the economics are a bit different there.) And yet, unlike some other massive applications such as finite-element analysis or Web searching, the majority of EDA applications are blessed by neither embarrassingly parallel data structures nor obviously parallelizable algorithms. Progress has been made on exploiting data parallelism on simulations, and on parallelizing some specific algorithms such as matrix inversions. But these are special cases. No single, sweeping initiative has unleashed massively-parallel computing on the EDA world. Yet as data sets and processing loads escalate faster than the dollar/Euro exchange rate, something must be done.

Synopsys has decided to take a pragmatic approach. Given that no sweeping, dramatic solution seems feasible, the company has attempted to group all of its individual efforts—some of them of long standing—into a single initiative, so that they can at least be coordinated. The initiative will include bringing in assistance from outside, in the form of parallelizing compilers and algorithmic advice from such experts as Intel and AMD—who have a lot invested in the transition to multicore computing. And it will involve coordinating for the first time the many prior parallelizing projects done in various Synopsys groups.

A couple of examples might be helpful. First, there is HSPICE for multicore processors. According to Geoffrey Ying, director of marketing on the project, there are two major computing chunks in HSPICE: model evaluation and a matrix solver. The two operate largely sequentially with respect to each other, but each can be parallelized, and Synopsys has done so. Work on the model evaluation algorithm has been going on for some time, Ying says, but the matrix solver work is fresh.

Interestingly, parallelizing these two codes resulted in rather tightly-coupled threads in each case. This, according to Ying, makes the performance of the multithreaded code very dependent on the speed of the link between the processors. Hence the parallelized HSPICE is really intended for single-machine multithreading, with several multi-core CPUs on one motherboard. Crossing backplanes or optical networks is not the best use of the approach.

In contrast, the company has taken an entirely different approach to parallelizing another huge processing load, the flow that starts with GDS-II and performs optical proximity correction and the early stages of mask data preparation. Here the workload is huge not so much because of the complexity of the algorithms—although the move to model-based OPC is causing nightmares, one suspects—but because of the sheer size of the data files: terabytes.

Accordingly, the company has taken a rather different approach to this part of the problem—an approach they call the Proteus Pipeline. They have found a way not to heavily parallelize each task, but to pipeline the entire set of tasks, so that the enormous data sets flow through a server farm, creating very high CPU utilization and spreading out mass storage utilization. “Our customers typically dedicate tens of CPUs to this stage of the EDA flow,” explains Synopsys group director for manufacturing products Tracy Weed. “Large customers may use thousands of CPUs. We needed an approach that was scalable across such a range.”

So Synopsys, rather than trying to force very different problems into one solution, is trying to coordinate many different solutions across a varied product line. Proteus, not Procustus, if you will.