Open side-bar Menu
 Real Talk
Graham Bell
Graham Bell
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

  1. Remember Amdahl’s Law
    • Your core algorithm will scale but the full flow often gives much less e.g. 2-3X improvement
    • Improving your core algorithm makes the full-flow scaling worse and harder to achieve
  2. Design for Deployed Hardware
    • Typical server farms have 2-4 sockets, 4-8 cores per socket, 4-8 GB of memory per CPU core.
    • Most EDA tools are memory limited, so cores are free
    • Don’t waste your time on GPUs or other esoteric hardware.  It makes adoption harder and will not deliver the ROI you are looking for.
  3. Be Deterministic
    • The tool must produce the same result irrespective of the number of cores as customers expect it and becomes impossible to debug
  4. Design for Input/Output
    • Input/Output is the bottleneck
    • Disks have good bandwidth but high-latency that must be managed
  5. Design for Memory
    • Use a multi-threaded memory allocator in your code (malloc)
    • Avoid transfer of ownership in your code
    • Minimize shared memory and global variables
  6. Always be Profiling Your Code’s Performance
    • Identify mutex bottlenecks (locking memory for I/O)
    • Profile user experience of the tool in the field
    • Use a sample-based profiler because they have a low-overhead.

What has been your experience with parallelism in design and tool development? Did you get the speed and throughput improvement you were shooting for?

Related posts:

Tags: , , , , , , ,

One Response to “Parallelism in EDA Software – Blessing or a Curse?”

  1. Larry Lapides says:

    Hi Graham,

    We’re not in the heart of EDA, as we do virtual platform based software development tools. However, last year we released our QuantumLeap product (, which does make use of the multiple cores on the host workstation. We’ve successfully shown acceleration of 2-3x on a quad core host machine, depending on the simulation system characteristics. We’ve also seen continuing performance improvement for as many cores as we’ve gone up to, which is a 16 core machine.


Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

CST Webinar Series

Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy