Why has IC physical design become commoditized? As time scales shrink and complexity increases, physical design cycles rely more on verification. A comprehensive set of rules need time to develop, and the technology changes occur simultaneously with the design. What’s needed is agility to repeat the design cycle quickly as new rules are invented.
https://si2.org/wp-content/uploads/2016/04/agility.jpg 310 310 Phillip Isenhart https://si2.org/wp-content/uploads/2016/03/si2_xpt-rgb-no-TM-copy-hue-300x230-2-300x230.png Phillip Isenhart2016-04-14 02:46:132016-04-14 02:46:22Design Agility: The Solution to EDA Commoditization
By Marshall Tiner
Director, Production Standards
In a recent article, Randy Smith, vice president of Marketing for Sonics, pinpointed a problem confronting the EDA industry.
“The difference between IP and EDA doesn’t matter much anymore. It is all about design acceleration. “Where can we make a difference?” he added.
“The physical design flow has been commoditized at this point. It is hard to come up with anything that will make a big enough difference that you can add value. For system-level design, there is still plenty of room, but you will have to come up with some smart ideas.”
Moore says Moore’s law is “dead.” Can we bet on technology not progressing? Or do we become agile and embrace the coming changes?
This problem is not unique to the EDA industry. It occurred in semiconductor manufacturing, computing and even
in software. It starts with new technology that rapidly improves over time, leading to cost competition and then commoditization. However, in every case, one important solution in these other industries had one similarity: standardization.
Semiconductor manufacturing went from high-volume, low mix to more complex high-mix, low-volume. Autonomously functioning agile manufacturing cells or modules were developed. The leverage point was standardization. Anything standardized could be reused, thus reducing costs.
Computers shrank from room-sized machines down to systems that were invisible to the human eye. With the free, standardized Linux platform we now reuse computers that run collectively as a “cloud.”
Software evolved from huge programs to collections of smaller, object-oriented languages that are easily shared and reused (yes, a type of standard). Programs can be quickly created using others as a foundation.
How does this apply to EDA? The total physical design cycle must be shortened to match current needs. We can’t redevelop entire checking decks between design passes as new rules are defined. Maybe we need a faster means of implementing new rules.
How can the EDA industry attain the agility it needs to grow? The answer again focuses partially on a standard, one that supports agile rule checking-Si2 OpenAccess. Our oaScript, an extension to OpenAccess, allows writing rule checks quickly in a variety of languages, including perl, python, ruby and tcl.
Why restrict the rule authorship to EDA? Spread it around and do it faster. What if the technology team could code the rules? Or the physical designer? Or enlist the program manager who set that ridiculous release date in the first place.
So, why not join the Si2 OpenAccess Coalition and use your company’s vote to drive the future the way you want it? Showcase and contribute some of your best “glue” code. Hear other solutions from the rest of the IC design community.