Synopsys Lynx Design System Debuts at SNUG

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

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...

Tags: , , , ,

4 Responses to “Synopsys Lynx Design System Debuts at SNUG”

  1. Jeremy Ralph Says:

    Great to learn about the new Lynx especially from your perspective as a former insider.

    I think this is a good step forward. This will allow the engineering teams to focus more on their core competencies rather than scripting infrastructure. It is a tough problem though, since every case is different.

    Having worked with some crazy flow scripting environments at Intel, for everything from front-end thought synthesis, I’m a bit weary of any flow that can do it all for all possible cases. There is a lot of custom stuff that happens in scripting environments… also there is a big concern with converting incumbent scripting and vendor lock-in.

    Hence, I have some questions:
    How extensible is it? Can it work with compute-farms and load balancing? In what language does it get extended? Perl and Make are nasty languages especially after getting used to ant and java based scripting. At previous employers our scripting used to integrate with our source control system to do version dependency management of the SoC hierarchy… can that be integrated? For example, chipY uses version 1.1.4 of the UART, but chipZ uses version 1.1.9 of the UART and the build process takes care of all this.

    Maybe Synopsys is interested in integrating support for a web-based register automation tool named SpectaReg for capturing register spec and auto-gen of code… :-)

    Seriously though, looking forward to learning more about Lynx. It sounds like something that is long overdue.

  2. harry Says:

    Hi Jeremy,

    I spent some time consulting to Intel in Chandler, AZ as did one of the Synopsys members of the flow team. As I recall, Intel’s objective was to hire very junior engineers and so they developed a flow that was very easy to run in that all the tool expertise resided in the flow. It was easy, that is, until something did not run and you had to debug. Then it was impossible :-)

    Regarding your questions:

    1) Lynx works with both LSF and GRD and may work with other job queuing software. At Synopsys, it resides on Synopsys’ compute farm called DesignSphere which has hundreds of CPUs.
    2) The extensibility is mainly in adding new or swapping out existing pieces of the flow. To do that, you need to know Make, and perl. Once that piece of the flow is in place, however, the person using the flow does not need to know either. If this were done today, I think Python might be the language of choice.
    3) As for version management, Lynx does not natively implement source control management but integrates with existing source control like RCS, CVS, SVN. They feel that customers have their own preferences and they would rather sit on top of revision control than replace it.

    As for SpectaReg, I think you exist earlier in the flow. Lynx is basically RTL2GDSII, so you could add a step in the flow to create code. Might be worth talking to them :-)

    harry

  3. devanshu Says:

    Hi Harry,

    As a PnR engineer, I liked following things “specifically” about lynx:

    - Looks like a mature GUI, with synopsys famillier stuff..
    - Making Parallel flows, just by drag - drop and connect them. It gives a great flexibilty to designer. I think thats quite good about lynx.The same customization in Makefile based flows, becomes error prone and limited in features.
    - Management cockpit, which gives a comprehensive report collection for managers, even in absence of the design engineers.

    - dev.

  4. Control Your IC Design Flow — Voom, Inc. Says:

    […] to existing flows. Use and learn from the TSMC Reference Flow or Synopsys Lynx Design System. I can help you with the Voom […]

Leave a Reply