EDA exists because it was too expensive for semiconductor companies to develop and maintain tools, but they must continue to be part of the innovation cycle.
Why is it taking so long for machine learning to have an impact within EDA? Most of the time when I talk to the experts within the field I hear about why designs are so different from other machine learning applications, and I know that is true. Many of you reading this may not be aware that I was a developer of EDA tools for more than 35 years before I ended up writing about them. One of the big challenges was, and remains today, speeding up simulation. Many companies have invested lots of money into that area and come up with disappointing results – both for the users and for their investors. The problem is the randomness of activity in a design.
One tool that I was involved with was the first RTL simulator – Hilo. As a young college grad, one of my tasks was to port that simulator to the plethora of computer architectures that existed at that time. Mainframes, minicomputers, early CAD workstations – they all used different processors and ran different operating systems. The first step in porting involved a questionnaire that we sent to the manufacturer of the system. Based on the answers, we knew how to prepare the source code to make the port easier. We also knew the approximate performance that the port would have. It usually came down to the cache architecture – how would they handle random access to large amounts of memory.
Random is the key word there. I often have wondered when simulator data structures were built, if the memory could be organized more like the traffic flow in the design. But I am sure if it had been worth the effort, someone would have done it.
But not all data within EDA is so unstructured. Trace data, which is essential for functional verification and debug is very structured. It is time-based, and a lot of it is very regular. In fact, it’s almost 30 years after I started to build what would now be called a machine learning system. The idea was to scan large amounts of trace data over multiple runs and look for patterns and anomalies in those patterns. While the system met with a certain amount of success, they consumed too much processing power, and back then we were limited to single-processor architectures.
EDA has been slow in finding ways to fully capture parallel processing. A lot of that goes back to the randomness, but I think a significant part of it is that EDA is being squeezed. As Wally Rhines, CEO of Mentor, a Siemens Business, has said at many trade shows, EDA revenues are a fairly constant percentage of semiconductor sales. But EDA today has to invest those dollars in many more areas than they did just a few years ago. Each new technology is a significant investment for them. Plus, they are attempting to move up in abstraction, encompass a larger view of the systems and keep up with necessary capacity increases.
Parallelization is often difficult. In preparing my recent article on debug, Preeti Gupta from ANSYS explained the challenge in this manner. “If I am doing a dictionary search and look for the name Brian in the dictionary, I could divide the dictionary into 500 sections and send a section to each of 500 different machines, get the answers and add them together. You lose no accuracy because the search on one is independent of the search on the others. When we think about EDA problems, what happens is the one path feeds another and another and they are sequenced. The output of any flop impacts the input of the other. So how can you parallelize such a highly correlated problem space? That is the challenge.”
I agree that it is a challenge, but there is a lot of data available that could use industry-standard machine learning and big data. Perhaps the industry is scared that by providing access to all of the data, in a form that industry standard tools can use, that it could put power back in the hands of the users and they will lose some level of control. What is more likely is that users will start to do this and then find out, as they did in the past, that it is not cost-efficient for every one of them to make the investment themselves, and they will ask the EDA companies to take over their work and commercialize it.
It is a cycle, but it has to start by giving users the ability to create new solutions by themselves. EDA has to open up the data and trust their customers. Semiconductor companies can, and should, be part of the EDA innovation cycle.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Event based (or spice) simulation is obviously hard to parallelize (because events ripple through), but even that is possible if the design is partitionable in some way ie sections that are independent of each other logically OR separated by state eg at a clocked flop boundary.
For cycle based simulation the partitioning at flops is already done, what lies between is compiled down to C and just run as a program. So separate blocks could run on separate cores and exchange the results at the clock boundaries.
Obviously this all gets harder with more clock domains, but it is still possible.
At the extreme, this becomes the Cadence emulation box where you have a huge array of small processors. When you have less than the number requires, it then becomes a load balancing problem. The total speed up is governed by the slowest block of logic. The economics for it often don’t work out because it takes many machine to get a fairly modest total speedup.
Maybe you bleeding-edge guys think there’s something new required. Me, all I need is capability without more cost. But that doesn’t suit these revenue munching behemoths at all.
Like, it would be great if I could farm out N*PVT Monte Carlo SPICE iterations to N, P, V or T machines. The solution speed of a single SPICE simulation doesn’t matter here – not when I am prevented from 50 or 150 or 450 machines parallel by a single simulator “key” for the seat cost. We are forced into sequential solution for profit.
What “we” need is open source front to back capability and PDKs to match.
Too bad about the state of open source transistor and polygon level verification.
One shot, 4 kills. Sounds good to me. I have come to hate them all after 3 decades of user-abuse (fiscal and mental).
The EDA companies are hardly behemoths compared to the industry they support. They are also hardly the most profitable either. They, as with all companies, attempt to get a fair value for the productivity they provide. SPICE is available as open source, so you could take a copy and adapt it to your needs yourself. I think you would find it to be a very slow and very expensive way to solve your problem.
The EDA marketplace is small. The problems are complex.
Not only do you have to solve the electrical calculations but you have to optimize for performance and parallelize the algorithm. How much time are you willing to spend to solve these problems and how much would that cost? How much are you willing to bet that your simulator is giving you the right answers, a tape out or two (before your company goes bankrupt)?
Very big companies can afford to write and verify their own simulation solutions but this gives them a competitive and economic edge which they are not about to share.
EDA companies are not greedy SOB’s, they have to pay their engineers and make a profit for their shareholders. If you want to risk your next chip on “free” simulation or verification software, you may find it much more expensive.
Hi Brian,
Your posts are really nice.
I recently joined a leading EDA company here in Mountain View, CA. I was wondering if you have any materials/videos/white papers on some basic EDA concepts. Things that I am particularly interested in are what drives the EDA market, is there any particular semi chip that drives the EDA tool, leading edge chips driving more vs. the trailing edge, how frequently the customers upgrade the tools? etc. Any materials would be highly appreciated.
Best regards,
Poulami Chakraborty