Multicore reshapes EDA landscape

Among established EDA providers, the advent of multicore processors is a cause for both celebration and concern.

The good news is that multicore platforms will provide much-needed compute power as transistor counts soar at 65nm and below. But legacy applications could prove difficult or even impossible to parallelize. That could force expensive software rewrites, delay tools for the 65nm and 45nm nodes, and shift market momentum to a new generation of EDA startups.

Multicore/multiprocessor operation is a requirement for 65nm and 45nm design tools, said Gary Smith, chief analyst at Gary Smith EDA. If an EDA application is inherently parallel, he said, adding multicore capability is usually a straightforward update. Otherwise, "it is a fairly major rewrite, often taking three years to do. A lot of tools are in the middle of that process now, which explains why we are two years late on the 65/45nm tools. This is a big problem for the EDA incumbents."

All of the largest EDA vendors—Cadence Design Systems Inc., Synopsys Inc., Mentor Graphics Corp. and Magma Design Automation Inc.—acknowledge that multicore support will be essential in the future, and all claim some multithreading and multicore capabilities today.

And some recent tools have supported multiprocessing out of the chute. Sierra Design Automation Inc.'s Olympus-SoC, a netlist-to-GDSII suite introduced last year, was architected from the start for multithreading and supports Linux-based multicore CPUs today.

Network or multicore?
Leveraging multiple CPUs is nothing new in the EDA landscape. Some applications, particularly for functional and physical verification, use distributed processing over "farms" of networked workstations, potentially harnessing the power of dozens or hundreds of CPUs. Some of those applications have adopted multithreading to take advantage of workstations with multiple CPUs.

A few multithreaded applications, such as Mentor Graphics' Calibre DRC physical verification tool, claim to run equally well on distributed networks, multiple-CPU workstations and multicore CPUs. Calibre DRC product manager Michael White noted that customers are now placing dual- and quad-core CPU-based workstations in compute farms, combining both distributed networks and multicore CPUs.

If a workload can be easily partitioned, a distributed network will work, said Ted Vucurevich, Cadence chief technology officer. But if time response is important, he said, a more tightly coupled, multicore environment may be needed.

"The difficulty with distributed processing," said John Croix, Nascentric Inc. chief technology officer, "is that the latency between processors is so great." Latency can be reduced with a workstation that contains multiple, single CPU chips, but the bus is a limiting factor. The greatest speed benefits come from multicore processors on the same die, even though there's little difference between multiple-CPU architectures and multicore architectures from a software implementation standpoint, Croix said.

Since Xoomsys Inc.'s XoomCKT product can support either distributed networks or multicore CPUs, the startup's CEO Raul Camposano takes a balanced view. Multicore CPUs, he said, communicate quickly but offer limited bandwidth for memory access. Networked CPUs communicate more slowly, with more latency, but they have their own memory and cache, so they can provide memory access with more bandwidth. For now, multicore CPUs are limited to only a few processors, while networks can scale into the hundreds or thousands.

Massimo Sivilotti, chief scientist at Tanner EDA, noted that "affordable" multicore platforms are now available with AMD Opteron and Intel Core Duo workstations. Multicore processors are better suited than distributed networks for tightly coupled numerical problems such as analog circuit simulation, he said.

While only selected applications support distributed processing, multicore support may eventually be widespread. "The computing paradigm is changing from scalar to multicore. You're going to see the EDA software industry move along with that," said Eric Filseth, corporate VP at Cadence.

The hitch is that programming for multicore architectures is hard, and trying to adapt legacy applications may prove fruitless. Usually, multicore programming involves the use of threads to distribute work and coordinate responses. "From a software point of view, in particular in EDA, many algorithms are inherently sequential and show only limited gains when multithreaded. They will need to be rewritten," said Camposano.

'Likely to be a disaster'
"Any attempt to explicitly create complex software—and most EDA software programs are among the most complex out there—that uses threading is likely to be a disaster," said Ammol Mathur, chief architect at Calypto Design Systems Inc. "There is poor support for threading from debuggers and tools, and explicit multithreading can create extremely hard-to-debug race conditions and nondeterministic behavior."

Trying to thread existing EDA software is a "losing proposition" that will, at best, work with three or four processors, said CLK Design Automation Inc. CEO Isadore Katz. "It really requires a ground-up development project to build a threaded architecture," he said. "It's hard. It really is rocket science."

Graham Bell, director of marketing at statistical timing newcomer Extreme DA, said memory and data management will be a challenge in adapting EDA software to multicore CPUs. "Coding styles that employ global variables and don't separate data and execution make the rewrite task difficult, if not impossible," he said.

If the workload isn't partitioned properly, said Croix, the communications overhead can swamp any gains brought about by parallelism.

Nascentric's AuSim MT, a fast Spice simulator for multicore platforms, was designed from the start to be multithreading. The company used object-oriented programming with "almost a pathological observance of coding guidelines," Croix said.

AuSim MT is measured on two SRAM vendor designs.

Not just for startups
Large EDA vendors acknowledge multicore's challenges but say they are making good progress. Mentor Graphics, in fact, believes it has one of the earliest multithreaded EDA products with Calibre. Multicore, said John Ferguson, Calibre technical marketing manager, "is where the market is going to go, and we believe we are ahead of the curve in deploying products that take advantage of that type of architecture."

"If you're not doing multicore, you're out," said John Lee, general manager of Magma's physical verification business unit. "Intel and AMD are no longer upping clock cycles—they're adding more cores. If you can't leverage that, you're only taking advantage of one-half or one-fourth of the silicon on the chip."

Rather than add multithreading, Magma has brought out what it calls a streaming data flow-based architecture for Quartz DRC, a recent physical verification offering that has supported distributed processing from the start.

Cadence applications that support multithreading include Encounter RTL Compiler global synthesis, First Encounter, Space-Based Router, NanoRoute and Chip Optimizer. It doesn't matter to the applications whether they're running on multiple-CPU workstations or multicore CPUs, said Vucurevich. Most can also run over distributed networks.

Various applications within Synopsys' Galaxy IC implementation platform use multithreading, partitioning, parallel processing or distributed processing, said Hasmukh Ranjan, senior director of IT at Synopsys. The PrimeTime timing analyzer, for instance, can use parallel processing across multiple CPUs to analyze different timing and signal integrity corners. The HSpice circuit simulator has multithreaded capability.

- Richard Goering
EE Times