Multithreading threatens to unravel beyond 45 nm

Tag : hardware tools

Anaheim, Calif. -- EDA vendors have struggled to meet the challengeof multicore IC design by rolling out multithreading capabilitiesfor their tools. Nonetheless, a nagging question cropped up at theDesign Automation Conference (DAC) here: Is multithreading reallythe best way to exploit multicore systems effectively?
"Threads are dead," asserted Gary Smith, founder and chief analystfor Gary Smith EDA. "It is a short-term solution to a long-termproblem."
At the 45-nanometer node, more and more designs reach and exceedthe 100 million-gate mark. These designs break current IC CAD tools, forcing EDA vendors to develop products capable of parallelprocessing.
Until now, parallel processing has relied on threading. Threading,however, tends to show its limits at four processors, and EDAvendors may have to come up with new ways of attacking the problem.
"Threads will only give you two or three years," Smith said."Library- or model-based concurrency is the best midterm approach."
EDA vendors interviewed at DAC painted a more-nuanced picture ofthe future of multithreading.
"We have not seen the limits to multithreading in thetiming-analysis area," said Graham Bell, marketing counsel for EDAstartup Extreme DA (Santa Clara, Calif.). "We see good scaling forthree or four process threads. We get to see difficulties beyondthat, but they are not dramatic."
With Extreme DA's GoldTime, a multithreaded static and statisticaltiming analyzer, the company has applied a fine-grainedmultithreading technique based on ThreadWave, anetlist-partitioning algorithm. "Because of our uniquearchitecture, we have a small memory footprint," Bell said. "Wehave not seen the end of taking advantage of multithreading."
For applications with a fine-grained parallelism, multithreading isone of the most generic ways to exploit multicores, said LucBurgun, CEO of Emulation and Verification Engineering (EVE) SA(Palaiseau, France). "On the other hand, multithread-based programscan also be quite difficult to debug." That's because they "breakthe sequential nature of the software execution, and you may easilyend up having nondeterministic behavior and a lot of headaches."
According to Burgun, multiprocess remains the "easiest and safestway to exploit multicore." He said he expects some interestinginitiatives to arise from parallel-computing experts to facilitatemulticore programming. "From that standpoint, Cuda [theNvidia-developed Compute Unified Device Architecture] looks verypromising," Burgun said.
Simon Davidmann, President and CEO of Imperas Ltd. (Thame, U.K.),delivered a similar message. "Multithreading is not the best way toexploit multicore resources," he said. "For some areas, it might beOK, but in terms of simulation, it is not."
Multithreading is not the only trick up Synopsys Inc.'s sleeve,said Steve Smith, senior director of product platform marketing atthe Mountain View, Calif., company. "Within each tool, there aredifferent algorithms. When looking at each tool, we profile theproduct to see the largest benefits to multithreading," he said."Multithreading is not always applicable. If not, we dopartitioning."
As chip makers move to eight and 16 cores, a hybrid approach will beneeded, asserted Smith, suggesting a combination of multithreadingand partitioning.
To illustrate the point, Smith cited a host of Synopsys' multicoresolutions in the area of multithreading, notably in the company'sHSpice circuit simulator. "HSpice has been broadly used by our customers. This istypically the tool you do not want to start from scratch," he said.
HSpice multithreading has come in stages, noted Smith. "Last year,we multithreaded the model-evaluation piece, and it gave a goodspeedup. Then, in March, we introduced the HSpice multithreadedmatrix solver. We want to make sure our customers are not impacted,and we do it [multithreading] piece by piece," he said.
Another trend Synopsys is investigating, Smith continued, ispipelining. This technique--an enterprise-level activity, since itdemands the involvement of IT--collapses multiple tasks, such asoptical proximity correction and mask-data preparation, into asingle pipeline.
Last year, Magma Design Automation Inc. (San Jose, Calif.) unveiledan alternative to multithreading, using a streaming-data-flow-based architecture for its Quartz-DRC design rule checker. Multithreading provides aless-fine-grained parallel-processing capability than Magma's dataflow architecture, said Thomas Kutzschebauch, senior director ofproduct engineering at Magma.
Magma's multicore strategy is focused on massive parallelism,Anirudh Devgan, vice president and general manager of the CustomDesign Business Unit, said at a DAC panel session on reinventingEDA with "manycore" processors.
"Four CPU boxes are just the beginning of a trend, and EDA software has towork on large CPUs [with more than 32 cores]", he said."Parallelism offers an opportunity to redefine EDA productivity andvalue. But just parallelism is not enough, since parallelizing aninefficient algorithm is a waste of hardware."
Devgan's conclusion was that tools have to be productive,integrated and massively parallel.
Seeing beyond C
As he unveiled "Trends and What's Hot at DAC," analyst Gary Smithexpressed doubts about C as the ultimate language for multicore programming. He cited theidentification of a new embedded-software language as one of thetop 10 issues facing the industry this year, and asserted that "aconcurrent language will have to be in place by 2015."
EDA executives including Kutzschebauch at Magma, Bell at Extreme DAand Smith at Synopsys did not debate the point. "We will changelanguage over time," stated Joachim Kunkel, vice president andgeneral manager of the Solutions Group at Synopsys. "We are likelyto see a new language appear, but it takes time. It is more aneducational thing."
On the software side, meanwhile, reworking the legacy code is a bigissue, and writing new code for multicore platforms is just asdifficult. Nonetheless, Davidmann at Imperas held that "the biggestchallenge is not writing, reworking or porting code, but verifyingthat the code works correctly, and when it doesn't, figuring outhow to fix it. Parallel processing exponentially increases theopportunities for failure."
Traditionally, Davidmann said, software developers thinksequentially. Now, that has to change. Chip design teams have beenwriting parallel HDL for 20 years, so it's doable--though it willtake much effort and new tool generations to assist software teamsin this task.
With single-processor platforms and serial code, functionalverification meant running real data and tests directed to specificpieces of functionality, Davidmann said. "Debug worked as a singlewindow within a GNU project debugger."
But with parallel processing, "running data and directed tests toreduce bugs does not provide sufficient coverage of the code," hesaid. "New tools for debug, verification and analysis are needed toenable effective production of software code."
Davidmann said Imperas is announcing products for verification,debug and analysis of embedded software for heterogeneous multicoreplatforms. "These tools have been designed to help softwaredevelopment teams deliver better-quality code in a shorter periodof time," he said.
To simplify the software development process and help with thelegacy code, Burgun of EVE said customers can validate theirsoftware running on the RTL design emulated in EVE's ZeBu. Itbehaves as a fast, cycle-accurate model of the hardware design.
For instance, he continued, some EVE customers can run their firmware and software six months prior to tapeout. They can check theporting of the legacy code on the new hardware very early and traceintegration bugs all the way to the source, whether in software orin hardware. When the engineering samples come back from the fab,99 percent of the software is already validated and up and running.
Thus, "ZeBu minimizes the number of respins for the chip anddrastically reduces the bring-up time for the software," Burgunsaid.