Posts Tagged ‘open source’

Synopsys Lynx Design System Debuts at SNUG

Monday, March 16th, 2009

Lynx Design Flow

This morning at the Synopsys Users Group (SNUG) Conference in San Jose, Aart DeGeus will be announcing Synopsys‘ latest generation of design flow / environment / system called Lynx. This is a big deal for Synopsys for a variety of reasons.  It’s also of particular interest to me for 3 reasons:

  1. First, when I was a program manager at Synopsys, I managed several projects that used previous generations of Lynx and was closely involved with the introduction of the most recent predecessor of Lynx, known as Pilot.
  2. Second, I have written about and believe in the importance of having an industry standard interoperable design system to enable collaboration.
  3. Third, I still keep in touch with some members of the flow team at Synopsys who developed and will support Lynx, so it’s good to see what they have come out with.

Given this full disclosure, you might be wondering if my opinion is objective. Probably not entirely. But those at Synopsys who worked with me in regards to flows can tell you that I was often a rather vocal critic. I know about the strengths and I also know the warts. So don’t expect this to be a sales pitch for Lynx, but as honest an assessment as I would have given internally were I still at Synopsys.

There’s a lot to cover, so I’m going to break this up into 3 5 separate posts over the course of the next 2 weeks. Today I’ll cover some of the history of flows at Synopsys and how they got to the Lynx flow that they have today. Wednesday I’ll cover what I consider the important nuts and bolts of Lynx, particularly what is new and exciting. Friday Next week, I’ll give my opinions as to what I like and don’t like and what can be made even better.

Since I won’t be covering nuts and bolts until Wednesday, I’ll include at the end of this post some links (no pun intended) to the requisite gratuitous shiny marketing collateral from Synopsys. Please take a look … I’m sure they spent a lot of money having it produced.


A (not so) Brief History of Flows At Synopsys


The development of standardized tool flows dates back at least 12 years to the days when Synopsys was mainly a synthesis company. Some consultants in the professional services group decided that their life would be easier if they could standardize the synthesis scripts that they brought out to customers to do consulting work. The Synopsys Design Environment (SDE) was a set of Make, Perl, and Design Compiler scripts that implemented a hierarchical “compile-characterize-recompile” synthesis methodology. Although it was used extensively by those who created the scripts and some others, it never caught on broadly and no replacement came about for some time.


In 2000, Synopsys acquired a small design services company based in Austin called The Silicon Group (TSG). Primarily acquired to implement turnkey design services to GDSII (this was prior to the acquisition of Avanti), TSG had developed an internal tool flow to standardize and automate the use of the Avanti tools. This “Bamboo” flow was the genesis of Lynx.


After Synopsys acquired Avanti in 2002, Synopsys Professional Services ramped up on its backend design services to GDSII, causing a broad deployment of the Bamboo flow across the organization. Renamed TIGER (for Tool InteGration EnviRonment), this flow was originally optional for design teams to use on consulting engagements, then became “strongly encouraged” and finally “mandatory” for any turnkey projects.

As you might expect, as a flow that originated in another company and was being required by management, TIGER met with some resistance. There were certainly aspects of TIGER that could be (and have been) improved, but primarily there was the predictable “not-invented-here” resistance and “I’m doing fine, just leave me be”. I managed several projects that used TIGER and it usually took 2-4 weeks for a new consultant to get familiar enough with the flow to stop complaining. After that however, he would usually start to feel comfortable and by the end of the project, would be a TIGER advocate.

As a project manager, the biggest benefit was standardization. A project could hit the ground running without the need for the team to arm wrestle over what design flow to use and then to develop it. If I needed more consultants to help suddenly, I knew they would also be able to hit the ground running as far as the design flow was concerned. Over time, various aspects of TIGER became part of the vernacular and culture (e.g. I’m at the “syn” step), making communication that much more efficient.


In 2005, I became involved in an effort to introduce TIGER as a complete “service offering” to Synopsys customers. As you can imagine, there was a lot that had to be done before taking to market scriptware that was previously used internally, and this took over a year. Scripts had to be brought to a higher level of quality and a regression suite created to ensure that the flow ran properly across a wide variety of designs and libraries. A support organization within professional services was created solely to support customers using the flow. A metrics GUI was created to allow design and runtime metrics to be viewed graphically and reports created. Eventually, a flow editor was created to allow customers to modify flows without editing makefiles.

On the business side, there was a lot of discussion on how to offer this flow. There were those, myself included, who advocated to make it available as “open source”. Personally, my feeling was that hundreds of customer designers can maintain and enhance the flow better and at less cost than a handful of Synopsys flow developers. And once adopted broadly, this flow would become the de facto standard, and Synopsys would benefit greatly from that leadership position. There were downsides to that approach, however, and in the end the “Synopsys Pilot Design Environment” debuted just before SNUG 2006 as a “service offering”.

With the move to outside customers, several new concerns arose:

  1. Customers wanted support for non-Synopsys tools, most notably Mentor’s Calibre which enjoyed a dominant market share. Pilot allowed for 3rd party tools to be added to the flow, but it was up to the customer to do so.
  2. Despite the GUIs that were developed, there was still a fair amount of Make and Perl knowledge that the designer needed to be really effective, especially for debug. Many customer engineers did not feel compfortable with the intracacies of these scripting languages.
  3. There was confusion with other Synopsys methodologies offered by the Synopsys business units and application consultants (e.g. Recommended Astro Methodology) and by Synopsys partners (TSMC and ARM reference Flow). How were they different? Why were some free and Pilot a service offering?
  4. Customers resisted getting “locked-in” to an “all Synopsys” flow and forgoing (for some time at least) the best-of-breed approach.

Despite these concerns, it seems that Pilot has gotten a fair amount of deployment, largely by companies going through some sort of major transition (e.g. moving to a new process node, moving from ASIC to COT, consolidating on Synopsys tools). Although I am no longer with Synopsys, my estimate is that there are probably about 2 dozen or so companies using Pilot in some fashion, mostly with some degree of customization for their particular needs.


Lynx is the next in the series of design flow offering from Synopsys. As with the others, it attempts to incrementally address issues and concerns with Pilot and to add new capabilities to increase adoption. In short, Lynx is intended to be a full-fledged product, supported through normal channels (support center and applications consultants).

(Note: I have not seen Lynx yet in action, so the following is based on Synopsys claims).

Among the key aspects of Lynx, as I’ve been told, are:

  • A runtime manager GUI has been added that supposedly frees designers from ever having to see or edit a makefile or perl script. It also allows debugging of errors and more configuration control.
  • Synopsys has migrated the metrics reporting to be web-based and hence accessible to any internet device (e.g. iPhone). The metrics can now cut across several projects instead of just one. And the GUI has been improved.
  • The GUIs in general are supposedly the same style as other Synopsys tools.
  • A much larger set of regressions run at Synopsys which should translate in better quality. Also, due to this regression automation, Synopsys claims they can release a version of Lynx concurrent with a new tool release. With Pilot, there was a 3 month lag.
  • Automated and semi-automated tapeout checks based on a set of internal guidelines that Synopsys has used for years on turnkey backend design projects.
  • Rather than having several competing methodologies and flows, Synopsys has decided to put all its eggs in the Lynx basket. This should result in greater focus and support to customers of Lynx.

My understanding is that Lynx will be sold as a perpetual site license with a separate user license for each user. Synopsys would not share the pricing with me, but I have strong reason to believe it is close to other mid-level Synopsys products.


If you want to access more information on Lynx, here are the “links” to go to:

Official Synopsys Lynx Webpage

Brief Lynx Video

Also, if you are at SNUG this week, you can get more info on Lynx at the following:

I very much regret not being able to go to SNUG this week. So I’d like to ask a favor. Please be my eyes and ears. If you attend the keynote or any of the Lynx related events, please post a comment with your thoughts here on this blog post. If you have thoughts on other aspects of SNUG, and you use Twitter, then please use the Twitter #SNUG hashtag in your tweets and I’ll feel like I’m there.

Part 2 - Lynx Design System? - It’s The Flow, Stupid!

Part 3 -  Strongest Lynx

Part 4 -  The Weakest Lynx

Part 5 - The Mising Lynx - The ASIC Cloud

harry the ASIC guy

One + One = ??? - What Would You Pay?

Wednesday, July 2nd, 2008

One of the shortest but most relevant exchanges during the Cadence analyst call concerning the Mentor acquisition was an exchange between Sterling Autry of JP Morgan and Kevin Palatnik, CFO of Cadence.

About 27 minutes into the conference call, Sterling Autry asked why Cadence was estimating only $50M in operating income benefit considering Mentor’s operating income in 2007 was $120M. Indeed, $1.6B to acquire $50M in income seems like a poor deal indeed.

Kevin Palatnik’s response included the following, “the industry has had a history, from a customer perspective, of trying to get more and include features and not pay for it. So I think we just have to be able to demonstrate value to the customers. So I think, in the short term, I think, there is always the customers asking for the combination and not paying for it.”

The crux of the issue is simple math: 1 + 1 = ??? …how much will Cadence-Mentor be able to charge for their combined products?  If  1+1 > 1.5, then the combined company will be in pretty good shape.  If 1 + 1 < 1.5, then it will be difficult to “extract the value” of the acquisition. In that case, expect lots of layoffs, products being scrapped, and products being sold off.

From my experience, Kevin Palatnik is only partially correct that “the industry has had a history, from a customer perspective, of trying to get more and include features and not pay for it”. When I started with Synopsys in 1992, their flagship tool was Design Compiler. Synopsys added new features and voila…DC-Expert.  Then DC-Ultra. Now DC-Graphical. Each one sold at a premium to the predecessor and customers would pay for the upgrades.

But not without voicing their displeasure, both privately and also publicly on places like ESNUG. It often seemed arbitrary and self-serving to customers what Synopsys deemed an “update” (covered by their tool support) and what they deemed an “upgrade”.  And they felt they were being nickel-and-dimed.

On the other hand, people need to eat, and the EDA tool developers are no exception. They do not work for free. It seems unique to the EDA industry, that customers expect, once they buy a tool, to get any and all improvements to the product for free. This is not the case when I buy MS Office or most any other desktop application, but it is definitely a reality in EDA.

To add to the confusion, I can now download almost any desktop application I need for free as open-source (e.g. Open Office), or use it for free online (e.g. Google Docs), and get access to upgrades for free as well. This has changed customer expectations dramatically.

I’d like to know what you (EDA vendors and customers) think about this:

  1. Should customers pay more for EDA tool enhancements or should they be part of the tool “support”?
  2. How do you decide what is an “update” and what is an “upgrade”?

harry the ASIC guy

OSU - Open Source University

Monday, April 7th, 2008

Below is a video presentation that was given in 2006 by Rice University Engineering Professor Richard Baraniuk at the TED conference in Monterey, CA. Professor Baraniuk is founder of Connexions, a free, open-source, global clearinghouse of course materials that allows teachers to quickly “create, rip, mix and burn” coursework — without fear of copyright violations. Think of it as Napster for education. I think this is well worth 18 minutes of our time, since we all have an interest in education for ourselves, our children, and our peers. When you’re done, a challenge.

Now for the challenge … I’d like you to consider what this approach would do for the ASIC Intellectual Property industry, if we could all collaborate to create, rip, mix, and burn design IP under user friendly legal terms such as Creative Commons.

What do you think?

harry the ASIC guy

What the heck am I getting myself into???

Sunday, March 30th, 2008

As a veteran ASIC designer … EDA applications engineer … consultant … project manager … biz dev manager … I’ve played a variety of key roles in the development of dozens of complex ASICs and SoCs. I’ve seen the industry from many perspectives … technical, managerial, financial … and I’ve seen what it takes to be successful and how little it takes to fail.

But, what fascinates me the most is the people. It’s the reason I left a desk job doing hands-on design at TRW to become an applications engineer at Synopsys working with people. And with the advent of new internet technologies (Open Source, Web2.0 …) the people are becoming even more important as they find new ways to work together and support each other. And turn the industry on it’s head.

Still, I don’t hear much about the people aspects of ASIC design from EDA vendors or trade publications … it doesn’t sell tools or subscriptions. And I don’t read much from the other industry blogs, many of them excellent for sure, as they focus more narrowly on rapidly evolving EDA technologies like verification.

For this reason, I started … to share my insights into the people aspects of ASIC engineering for those who, like me, feel they are under-valued. I hope you find these insights to be thought-provoking and of practical value and I welcome your insights and comments. After all, several thousand heads are better than one :-)

harry the ASIC guy