CEDA’s DAFW 2016: Romance Novel v. Non-Fiction v. Classic Rock

Last week on Friday and Saturday, the IEEE Council on EDA hosted a 2-day workshop to discuss the future of design automation. Mentor Graphics provided the venue – a large conference room in their Fremont/Silicon Valley campus – and workshop leaders, UCSD Prof. Andrew Kahng, UCSD Prof. Farinaz Koushanfa, and Intel alum/CEDA President Shishpal Rawat provided the welcome.

Over the two days, a group of 50+ attendees – representing a wide cross-section of academics and industry experts – launched into conversations that were lively, energized, at times contentious, and completely engrossing. Put simply, there was no better place on the face of the globe on October 21st and 22nd where tech junkies were more intellectually challenged and entertained than at the Design Automation Futures Workshop in Fremont.

What made the workshop so compelling? For this, their inaugural DAFW, CEDA chose to address neuromorphic computing – the ultimate hotness related to machine learning, with a lot of promise for future applications. It doesn’t get any more design futures, or futuristic, than this.

And, what is neuromorphic computing? To answer that question we need a taxonomy of terms, and a completely separate blog, which will be coming next week.

This week, however, the only issue this blog will address is Saturday morning at DAFW when Google threw down a romance novel/wish list of EDA tools they’d like to have for future chip design, and Synopsys pushed back with a non-fiction/reality list of what EDA tools actually exist or will actually be developed.

It was a fantastic clash of titans – albeit the combatants were courteous and collegial – debating the possible versus the probable within EDA.

Speaking on behalf of Google was long-time EDA veteran Richard Ho, founder of O-In Design Automation [bought by Mentor in 2004], who now heads up the design team at Google for their TPU – tensor processing unit – which is specifically targeted at machine-learning algorithms and, per Ho, provides server-farm compute platforms for 100+ development teams at Google.

Ho said, “Machine learning is now critical and includes far more than just voice recognition, facial recognition, or self-driving cars. [Hence], Google is now a machine-learning company, not a search engine company, and our vast army of software engineers are now ML programmers, not C++ programmers.

“However, Google faces a success-disaster scenario – our ability to scale our data centers to meet the need for ML algorithms may be compromised [by] the slowing of Moore’s law.”

He went on to define a tensor – a multi-variable vector – as a compute construct that needs custom ASICs to deal with their application to machine learning.

The results of developing these ASICs, Ho said, “will yield an order of magnitude improvement in performance per watt for ML workloads. Essentially equivalent to a 10x improvement on Moore’s Law.”

Designing this hardware, he added, “requires rapid implementation and deployment, and very fast design cycles for ASICs and systems.”

Ho then issued the proverbial call for the EDA industry to hurry up and provide Google’s leading-edge design teams with the tools and features they need.

His list included:

– A rapid system exploration framework
– High-level synthesis
– Hardware-software co-design tools
– Ability to use hardware construction languages and domain specific languages
– Rapid response to changing feature requests, changes in specs
– Enhancements for performance bottlenecks
– Design starts with unit tests to guide implementation
–  Test-driven development
– Accelerated system verification
– Verification tools to demonstrate end-to-end functional correctness ala Agile SW development
– Parallel work on functional verification and physical design
– Power, performance, area estimates early and often
– Improved simulation technology
– Ability to share and analyze all potential designs simultaneously, in real time
– Ability to balance critical paths in the design flow
– Ability to respond to elastic resource allocations by engaging with cloud compute companies
– Data mining across silos within company
– Data analysis tools to extract insight from raw data
– Last but not least, great code quality

An inspiring laundry list, indeed. And one, by the way, that has been issued in one form or another for at least 15 years by every panel of tools users at every conference where EDA tool vendors are in the audience.

Speaking of tool vendors: Appearing on behalf of Synopsys on Saturday morning at DAFW was another long-time EDA veteran, Patrick Groeneveld [formerly CTO at Magma, purchased by Synopsys in 2012].

Known for his no-nonsense abilities to discern hype from fact, Groeneveld addressed square-on the commercial realities of developing electronic system design tools for a user community eager for better, faster, smarter, newer.

Unfortunately, if there is no market or too small of a market for this stuff, EDA tools just aren’t going to be developed was Groeneveld’s underlying thesis. If there’s insufficient commercial incentive, it’s not going to get done.

And, similar to Richard Ho, Groeneveld also had a list to prove his point. His parsed his discussion between recipes for success and recipes for disaster for EDA tool developers, and in so doing provided an interesting compare/contrast to Ho’s list.

* Recipes for success in EDA tool development

– Homogeneous objects
– Low-level components
– Uniform methodology
– Strong abstractions
– Analysis tools
– Sequential
– Stepwise refinement
– High-value customers
– Mainstream market

* Recipes for disaster in EDA tool development

– Heterogeneous objects
– High-level components
– Specialized methods
– No abstractions
– Synthesis tools
– Parallel
– Iterative
– Many customers
– Niche markets

One can draw at least two, not-unrelated conclusions from Groeneveld’s list. One, the EDA companies are not trying hard enough to meet customer demands; and two, leading-edge customers need to develop their own tools if they insist on pushing the envelope.

Interestingly, neither of these conclusions are cutting-edge or new, and neither are they completely accurate, of course. Instead, they represent the same complaints and threats that have been bandied about for a generation within the EDA tool vendor and tool user communities. Nothing new here at all.

Draw your own conclusions about this particular clash of titans, but know that no design futures are going to emerge if the world awaits daring, commercially risky offerings from the EDA tool vendors. On the other hand, the tools the vendors do supply are pretty darn sophisticated.

The EDA vendors truly like their customers and want to help, but they also need to be sure those customers read a lot more non-fiction than romance novels – that they understand the limitations of what can be done by the evolutionary developers within the tool community.

The EDA vendors also need to be sure their customers listen to a lot of classic rock. Because really – speaking in terms that tools vendors hope their customers can understand – nobody said it better than The Stones:

You can’t always get what you want.
You can’t always get what you want.
You can’t always get what you want.
But if you try sometimes, well you just might find,
You get what you need.

**************

Tags: Andrew Kahng, DAFW 2016, Design Automation Futures Workshop, Farinaz Koushanfa, Google, IEEE CEDA, Intel, Machine Learning, Magma, Mentor Graphics, O-In Design Automation, Patrick Groeneveld, Richard Ho, Shishpal Rawat, Synopsys, The Rolling Stones, UC San Diego

This entry was posted on Wednesday, October 26th, 2016 at 6:00 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.