Graham is VP of Marketing at Real Intent. He has over 20 years experience in the design automation industry. He has founded startups, brought Nassda to an IPO and previously was Sales and Marketing Director at Internet Business Systems, a web portal company. Graham has a Bachelor of Computer … More »
Parallelism in EDA Software – Blessing or a Curse?
November 20th, 2014 by Graham Bell
To satisfy demands for lower-power and higher performance, the use of multiple CPU cores is a norm in SoC design. The interaction of multiple cores and the surrounding semiconductor IP, presents new challenges to verification. But what about EDA tool providers? How can the use of multple CPUs improve performance and throughput in their tools? What software caveats do they need to be aware to support processing by parallel CPUs? Pranav Ashar, CTO at Real Intent gives his perspective below.
EDA tools must be exploit parallelism to keep up with SoC complexity, or we will be attempting to designing next-generation chips on what effectively will be antique hardware.
A couple of factors have combined to reduce the pace at which parallelism has been adopted in EDA tools. It is common to overlook the latency impact when designing parallel programs that communicate with physical memory. Cache-coherency and memory access latency are often encountered examples that lowers the processing throughput of a tool on a multi-core processor. Fine-grain multi-threading in EDA tools quickly triggers some of these latency bottlenecks – for the typical SoC benchmark, these limits are reached rather rapidly.
It is also challenging to write bug-free multi-threaded programs. Revamping a large existing code base to become multi-threading friendly is a nontrivial re-engineering undertaking. Below, we present a list of Do’s and Don’ts for coding multi-threaded programs courtesy of Guy Maor, an experienced EDA developer.
Multi-process parallelism has become a viable alternative to multi-threading as a result of much lower overheads compared to previous generations of hardware. Also, compared to the multi-threading approach, process-based parallelism triggers fewer latency issues and is easier to ensure correct operation, and has excellent API software libraries available.
There is plenty of low-hanging parallelism available in EDA tools in their front-ends and analysis engines that, with a careful program architecture and data-flow to minimize inter-process copying overheads, can be harnessed with multi-process parallelism. This can be a way to introduce parallelism into an EDA tool in an evolutionary manner.
Even with the known limitations of current multicore architectures, EDA companies must push ahead with parallelizing their software. An 8x speed up on a 32-core processor is better than no speed up at all. It is also one way of determining what the limits are, and where system and software rearchitecting is needed.
Do’s and Don’ts for Developers of Parallel Software by Guy Maor
What has been your experience with parallelism in design and tool development? Did you get the speed and throughput improvement you were shooting for?
One Response to “Parallelism in EDA Software – Blessing or a Curse?”