Posts Tagged ‘SNUG’

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

SDE

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.

Bamboo

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.

TIGER

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.

Pilot

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

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

** FREE ** Conferences

Friday, January 23rd, 2009

How much would you pay to be in the audience for some of the most thought provoking conference presentations from some of the greatest minds in the world. Here’s your ticket.

It’s FREE … completely FREE.

No registration. No airplanes. No hotels. No rental car.

While you sit at home, on a Sunday afternoon, drinking a beer.

Of course, nothing can completely replace the face to face interaction at a real conference. But in these “hard times” and with the technologies like flip cameras making video ubiquitous, it’s a damn good alternative.

It should be interesting to see what comes of DVCon, SNUG, and DAC this year in this regard. My prediction is that you will see an explosion of coverage. Videos (authorized and pirated) of presentations and floor and suite demos and interviews on flip cameras. Blog posts. Twitter feeds with customer hashtags.

What do you think?

harry the ASIC guy

My Favorite SNUG Presentation

Monday, April 14th, 2008

I spoke in previous posts about Aart DeGeus’ keynote address and the VMM/OVM controversy at SNUG 2008 San Jose. In this post, I’d like to share my thoughts about my favorite presentation at SNUG, what made it so compelling, and what lessons we can take away as presenters.

Michael Keating, Synopsys Fellow and co-author of the Reuse Methodology Manual and Low Power Methodology Manual, presented a Tuesday afternoon (right after lunch!) Vision Session entitled “The Future of Low Power”. If you can access this presentation, great. Even better, Synopsys recorded the presentation and will hopefully make it generally available on their Website, much like a similar talk at the 2007 ARM Developers’ Conference.

So, what made this presentation so special compared to the others? Mike followed some of the basic rules of great presentations:

  1. Be Relevent – Design for low power and functional verification are the top issues facing designers in the next 5-10 years. There are new techniques and methodologies in play and also new science (even nanotech). This made for a topic that had a lot of interest to all ASIC designers.
  2. Know Your Stuff – It was obvious that Michael was personally very experienced in the technology of which he spoke. It would have been equally obvious had the case been otherwise.
  3. Relax – Easier said than done when addressing hundreds of your customers and peers. Michael seemed very at ease and that probably helped him to focus on the message.
  4. Talk Like a Real Person – It felt the same speaking to Mike up-front after his presentation than it did listening to him deliver his presentation. The audience was comfortable with his conversational style of presentation and that gave him a lot of credibility (compared to over-the-top marketing pitches).
  5. Use Visuals to Aid Your Message – This is the key point I wish to make. The slides were not the message and did not contain the message, as is too often common in PowerPoint presentations. How often do we see slides that have bullets that the presenter will read, hence making him superfluous? Instead, Mike delivered his message talking to the audience and the slides served to support and reinforce his message.
  6. Make Room for the Audience – Ideally, impromptu audience interaction allows the audience to be part of the discussion and to stay more connected. The constraints of the presentation … a large hall with hundreds of attendees … did not allow for that kind of interactivity during the presentation. So, Mike allowed plenty of time at the end for questions and comments and he welcomed them, even if dissenting opinions were expressed.

So…what was a great presentation that you attended, at SNUG or elsewhere? … What are your top presentation tips or presentation no-nos? … Your pet peeves?

harry the ASIC guy

Next Post: What do Airbags and Global Warming Have in Common?