ANAHEIM, Calif. — With the proliferation of multicore processors, many vendors of EDA software have rolled out multithreading capabilities for their tools. Nonetheless, one question raised last week at the Design Automation Conference was: is multithreading really the most effective way to exploit multicore systems?

At the 45-nanometer node, IC designs have exceeded the one hundred million gate mark. Such designs can break current IC CAD tools designed to operate on a single processor computer. This has forced EDA vendors to develop tools inherently capable of parallel processing.

Until now, parallel processing has relied on threading. Threading, however, tends to show its limits at four processors, and EDA vendors may have to come with alternative methods for IC CAD tools, according to experts attending DAC.

"Threads are dead, proclaimed Gary Smith, chief analyst for Gary Smith EDA. "It is a short-term solution to a long-term problem. Threads will only give you two or three years. Library- or model-based concurrency is the best mid-term approach. However, EDA vendors interviewed by EE Times at DAC painted a more-nuanced picture of the future of multithreading and multiprocessing. They made arguments for pursuing incremental multithreading but seemed more at loss when things hinged on how to efficiently exploit hundreds of processors.

Graham Bell, marketing counsel for EDA startup Extreme DA Corp. (Santa Clara, Calif.), declared: "We have not seen the limits to multithreading in the timing analysis area. We see good scaling for three or four process threads. We get to see difficulties beyond that but they are not dramatic.

Extreme DA offers GoldTime, a multithreaded static and statistical timing analyzer. With GoldTime, Bell explained, Extreme DA has applied fine-grained multithreading technique based on ThreadWave, a netlist partitioning algorithm. "Because of our unique architecture, we have a small memory footprint. We have not seen the end of taking advantage of multithreading.

For applications with a fine-grain parallelism, Luc Burgun, CEO of Emulation and Verification Engineering SA (Palaiseau, France), said multithreading is one of the most generic way to exploit multicore processors even though it had been originally developed to create some virtual parallelism on uniprocessor architectures.

He added: "On the other hand, multithread-based programs can also be quite difficult to debug since they break the sequential nature of the software execution and you may easily end up having non-deterministic behavior and a lot of headaches.

According to Burgun, multiprocessing remains the "easiest and safest way to exploit multicore. He said he expects some interesting initiatives to arise from parallel computing experts to facilitate multicore programming. "From that standpoint, CUDA (Compute Unified Device Architecture) looks very promising, noted Burgun.

Simon Davidmann, president and CEO of Imperas Ltd. (Thame, England), delivered a similar message. "Multithreading is not the best way to exploit multicore resources. For some areas, it might be okay, but in terms of simulation, it is not.

Steve Smith, senior director of product platform marketing at Synopsys Inc. (Mountain View, Calif.), said delivering high-performance software was not only about multithreading. "Within each tool, there are different algorithms. When looking at each tool, we profile the product to see the largest benefits to multithreading. Multithreading is not always applicable. If not, we do partitioning. As processor vendors move the computer industry to 8 and 16 cores, there will be a need for a hybrid type of applications, asserted Smith, suggesting a combination of multithreading and partitioning.

To illustrate the point, Smith gave the example of Synopsys' HSpice circuit simulator. "HSpice has been broadly used by our customers. This is typically the tool you do not want to start from scratch. HSpice is broken into two pieces, noted Smith. "Last year, we multithreaded the model evaluation piece, and it gave a good speedup. Then, in March, we introduced an HSpice multithreaded matrix solver. We want to make sure our customers are not impacted, so we do it [multithreading] piece by piece.

Another trend Synopsys is investigating, Smith continued, is pipelining. This technique is an enterprise-level activity and really needs the IT department to be involved. Pipelining collapses multiple tasks, such as optical proximity correction (OPC) and mask data preparation, into a single dataflow.

In 2007 Magma Design Automation Inc. (San Jose, Calif.) unveiled a similar alternative to multithreading by introducing a streaming dataflow-based architecture for its Quartz-DRC design rule checker. Thomas Kutzschebauch, senior director of product engineering at Magma, claimed that multithreading provides a less fine-grained parallel processing capability than Magma's dataflow architecture.

Speaking at a panel session on "Re-inventing EDA with many-core processors , Anirudh Devgan, vice president and general manager for the custom design business unit at Magma, highlighted that Magma's multicore strategy is focused on massive parallelism. He declared: "Four-CPU boxes are just the beginning of a trend, and EDA software has to work on large (over 32) CPUs. Parallelism offers the opportunity to redefine EDA productivity and value. But just parallelism is not enough since parallelizing an "inefficient algorithm is a waste of hardware. Devgan's conclusion was that EDA tools have to be productive, integrated and massively parallel.

As Gary Smith unveiled his own ÔWhat's Hot at DAC' list, he expressed doubts about C being the final and best language for multicore programming. In this regard Smith stands apart from many pragmatists in the EDA and embedded industries who firmly repeat that several million C programmers cannot be wrong. The rules of human inertia and business mean that technology must develop to accommodate the C programmers, the pragmatists argue.

Nonetheless, Smith cited the identification of a new embedded software language as one of the top ten issues for 2008 and said it was clear that "a concurrent language will have to be in place by 2015. The absence of such a development would give rise to a widening performance gap that would make hardware improvements pointless as the software would fail to exploit them.

Magma's Kutzschebauch, Bell at Extreme DA and Smith at Synopsys did not deny that C is not the best language for programming parallel processing machines. "We will change language over time, stated Joachim Kunkel, vice president and general manager of the solutions group at Synopsys. "We are likely to see a new language appear but it takes time. It is more an educational thing.

However the pragmatists point out that reworking legacy code would remain a big issue, and writing original code for multicore platforms is also non-trivial. Davidmann at Imperas asserted that "the biggest challenge is not writing, reworking or porting code, but verifying that the code works correctly, and when it doesn't, figuring out how to fix it. Parallel processing exponentially increases the opportunities for failure.

Traditionally, software developers think sequentially and now that has to change, he said. Chip design teams have been writing parallel HDL for 20 years, so it is doable, though it will take much effort and new tool generations to assist software teams in this task.

With single processor platforms and serial code, Davidmann said functional verification meant running real data and directed tests aimed at specific pieces of functionality. He added: "Debug worked as a single window within a GNU project debugger. With parallel processing, running data and directed tests to reduce bugs does not provide sufficient coverage of the code. New tools for debug, verification and analysis are needed to enable effective production of software code. Simplified development

Imperas is introducing products for verification, debug and analysis of embedded software for heterogeneous multicore platforms, said Davidmann. "These tools have been designed to help software development teams deliver better quality code in a shorter period of time.

To simplify the software development process and help with the legacy code, Burgun said EVE's customers can validate their software running on the RTL design emulated in ZeBu that behaves as a fast cycle-accurate model of the hardware design. For instance, he continued, some of EVE's customers can run their firmware and software six months prior to tape-out. They can check the porting of the legacy code on the new hardware very early and trace integration bugs all the way to the source, whether in software or in hardware. When the engineering samples come back from fab, 99 percent of the software is already validated and up and running. So, Burgun claimed, "ZeBu minimizes the number of re-spins for the chip and drastically reduces the bring-up time for the software.

This story appeared in the EE Times Europe print edition covering June 16 - July 6, 2008. European residents who wish to receive regular copies of EE Times Europe, subscribe here.

See other stories from this issue here.

You can download a digital edition of the latest EE Times Europe print edition here.