The critical need for expressing design intent within EDA

Mark Waller, VP of Engineering at Pulsic, just published a great article on design constraints on the 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 ( 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.)


About sleibson2

EDA360 Evangelist and Marketing Director at Cadence Design Systems (blog at
This entry was posted in Design Intent, EDA360, Silicon Realization. Bookmark the permalink.

2 Responses to The critical need for expressing design intent within EDA

  1. Grant Martin says:

    Somewhat ironically, one of the motivating factors something like 14 years ago in the first SLDL (System Level Design Language) meetings – one held in Dallas sponsored by TI (Steve Schultz, now head of SI2! It is indeed a small world) in something like 1996 or 1997……… was to find a way to express design constraints that would propagate from the highest system levels down through implementation. Some of that thinking eventually led to the “Rosetta” system level design language which still has declarative aspects that could be used to express constraints – see their web site at
    Perry Alexander also wrote a book about Rosetta in 2007 – see
    However, this work is only moving very slowly. It is interesting to see the theme come up again in a different form.

  2. sleibson2 says:

    Thanks for adding that, Grant! I hope to write more on high-level constraints after I return from DATE.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s