Mark Waller, VP of Engineering at Pulsic, just published a great article on design constraints on the chipdesignmag.com Web site. (See “It’s Time for Standard Design Constraints for Custom Design”.) Design constraints go by another name in the EDA360 vision, which uses the phrase “design intent” rather than constraints. In fact, Waller’s article says as much:
“Design constraints are ancillary data that express design intent, both on the macro and micro levels.”
Waller then continues with an excellent rationale and a concise reason for developing a standard way of describing design intent:
“Custom designers use design constraints to ensure design intent – such as the circuit’s target frequency or the current load for a particular net – is considered at every phase of the design process. Without design constraints, a design’s function or performance might be unknowingly changed and/or impacted negatively by alterations during the design process.”
He then puts his finger precisely on the pain point:
“Currently, design constraints are conveyed through the design using ad-hoc manual methods that vary from design team to design team, and might include something as formal as spreadsheets or scripts, but might be as informal as handwritten notes. Some custom design automation tools offer formats for entering design constraints. However, these formats are proprietary and apply only to the design phase the particular tool handles.
These ad-hoc, often manual methods for design-constraint management are both slow and vulnerable to errors.”
This explanation is precisely why the EDA360 vision calls for incorporating design intent into a sharable database accessible to all design tools in the chain—something that EDA360 strongly favors. The ad hoc methods for expressing design intent tend to use Microsoft Office products such as Word and Excel, which results in a scattering of design documents across the multiple hard drives of a design team’s members. That makes no sense, but it’s the method so many teams have independently evolved. As an industry, we can do better. We must. The stakes are just too high.
As Waller points out, there are efforts underway to create standardized representations for design intent. Unfortunately, the standardization effort Waller mentions, which is occurring under the IPL Alliance, strongly connects standards for representing design intent with the development of universal PDKs. The two are not really connected. Both are standards, but one need not be connected to the other. Without trying to start a pie fight, I’ll point out that Cadence is also participating in an effort to standardize methods of expressing design intent—through the Si2 standards organization (www.si2.org). The Common Power Format (CPF) is an early example of that work.
Si2 also has a PDK standardization effort underway, but it’s a separate effort called the OpenPDK Coalition. (Daniel Nenni wrote about this effort on SemiWiki with his article “Steve Jobs’ 5 Minute Anti Open Systems Rant and Si2!”)
The distinction between the two approaches may seem small at first blush, but it isn’t. Bonding two standards together that need not be closely connected has a way of encumbering both standards.
One thing almost everyone can agree on right now is that we all need a better way to express and share design intent.
(Note: You can read more about the Cadence position on interoperable PDKs in Richard Goering’s interview with John Stabenow.)