Just Go with the Design Flow



By Dean ~ February 4th, 2009. Filed under: Industry.

Design flows have been top of stack in my mind lately.  This is partly because we’re exploring how our system level design flow integrates with various implementation flows.  It’s also because some recent posts have caught my attention.  My friend, Saranyan Vigraham from Qualcomm, wrote an article recently for Embedded.com where he touches on how the mainstream semiconductor companies integrate tools into their proprietary flows.  Then, I saw Paul McLellan‘s post — “Ferrari vs Formula-1” — on his EDA Graffiti blog.  Mr. McLellan suggests that the big EDA companies will continue to develop proprietary flows to cover the spectrum of design and implementation.

Now, I always get more than a tad nervous when I disagree with Mr. McLellan, but this time I find myself in that position.  I do not believe that proprietary “walled garden” flows from the leading EDA vendors will actually address the full range of problems for the broad spectrum of their customers.  Further, I don’t think that these proprietary flows will be particularly helpful to the vendors themselves.  This path seems, to me at least, like the vendors saying, “We are the jacks of all trades, and you’re going to be locked into our flows, so it doesn’t matter if we’re masters of none.”  While some customers may accept this, I strongly believe that the majority will continue to need specific best-of-breed tools for specific challenges.  Unfortunately, I am also very skeptical regarding whether the vendors can pull off a completely integrated top-to-bottom flow.  I was quite unpleasantly reminded of Mentor’s 8.0/Falcon Framework nightmare by Daniel Payne‘s comment on the Ferrari vs Formula-1 post.

“Mentor did at one time start from scratch to create an integrated flow and called it Falcon or 8.0 – what a financial and technological letdown. It is what knocked the former number 1 EDA company into it’s present number 3 position. They tried to make an integrated, but closed design flow. Today, we want integrated but open design flows. Mentor has since given up on Falcon and instead offers excellent point tools and subflows. Live and learn.”

While I think that very poor organizational and structural decisions were actually the primary contributors to the Falcon disaster, Mr. Payne’s point is well taken

Looking forward, I see the evolution of flows being driven by a handful of different stakeholders.  Of course, the big EDA companies will do their best.  I predict that foundries will become highly incented to see to the development of flows that target their processes and that big semiconductor companies will continue to use their considerable internal CAD resources to build their own flows out of the best tools that they can acquire, or develop.  These last two constituencies will use their collective power as significant customers to force tool vendors to support standard interfaces / information exchange formats.  This, in turn, will allow for a new breed of systems integration (design flow integration?) organizations that will use open frameworks (perhaps something akin to Eclipse) to provide complete flow solutions tailored to specific customers and market segments.

At some point in the not to distant future, these systems integrators will provide complete solutions that incorporate the point tools best suited to a particular situation.  When this happens, they will be among the dominant forces in the market.  One could even argue that an organization like eSilicon is already sort of a flavor of what is to come.

Of course managing the data as it moves (bi-directionally) through the flow so that no critical semantic information is lost is really the critical challenge.

 

——————————
Technorati Tags:  , , , , ,

Comments are closed.