Strongest Lynx

I know. I know. I know.

I said that I was going to publish the final post in a 3-part series on Synopsys Lynx last Friday. However, as I put my notes together, I realized how much there is to say. So, I’m breaking up the last post into 3 separate posts: The Strongest Lynx, The Weakest Lynx, and The Missing Lynx (clever, huh?).  First, the Strongest Lynx.

I think that the best way to understand the strengths of Lynx is to consider who is Synopsys’ intended customer for this flow offering. After all, the offering is designed for them. In that regard, since adopting Synopsys Lynx is such a big change in methodology, Synopsys is looking for customers who are already planning some sort of major transition, including:

  • Startup companies who have no design flow to begin with
  • Companies making a significant transition to a new technology node or process (e.g. 90nm => 45nm)
  • Companies expanding their existing design capabilities (e.g. ASIC => COT)
  • Companies moving towards an all Synopsys flow (e.g. vendor consolidation)
  • Companies downsizing their in-house CAD teams

These companies are already committed to some sort of change in design flow, so Synopsys offers them a “buy” alternative to making it in-house. Synopsys Lynx is attractive to the extent that it accelerates that transition process and allows the design teams to be productive faster. In that light, the 3 greatest strength of Lynx seem to be:

1. 75-90% of a working design flow out-of-the-box.

I’m sure methodology experts and tool experts, if given a chance to dig into the Lynx scripts, would find areas to make improvements to the flow.  Nonetheless, I can say from experience managing teams using earlier versions (Tiger, Pilot), that Lynx provides a complete design flow that requires very little customization “out-of-the-box”. It is the same design flow that has evolved from almost 10 years of delivering design services and is being used by Synopsys’ own design services organization, so indeed they “eat their own dog food“. Synopsys says that they are doing more regression testing, which should increase quality. There is documentation and training, and Synopsys offers 1 week of on-site assistance to install and start customizing it.

2. A design flow that optimizes across the various tools.

It’s well understood that smaller process geometries require the various tools in the flow to work together more closely, exchanging data and anticipating what the other tools will do downstream. Synopsys claims to have implemented several such flows in Lynx, particularly highlighting their low-power flow. If this is true, that should result in better results than a point-tool approach.

3.  Ease-of-use features that help average tool users be productive more easily.

Design flows for very small geometries (65nm, 45nm, 32nm) are extremely complex and demand a depth of expertise across all the tools that is difficult to find. As a result, there is a need to simplify the design process and tool usage so “average” design teams can still implement these chips effectively. The Runtime Manager supposedly frees the designer from having to edit makefiles or tcl scripts, allowing control over all the appropriate variables through GUI settings and menus and debug of script errors through the GUI. Similarly, the Management Cockpit promises to provide valuable metrics without digging through log files and reports. If they deliver on these promises, the Runtime Manager and Management Cockpit will make average designers more productive more quickly. I have some doubts, though, especially since these GUIs are brand new and have not had extensive testing. I’d be interested to know if these run as smoothly as advertised or if there are issues getting them to deliver.

In summary, Lynx’s strength is in providing a 75-90% complete Synopsys design flow that optimizes across the tools to increase the design quality and provides graphical capabilities to make the flow easier to use for the average non-tool-expert designer. To my knowledge, none of the other major EDA vendors offer anything similar, either in scope or maturity.

If this sounds like an endorsement, you’ll want to read the next in the series : The Weakest Lynx.

Part 1 – Synopsys Lynx Design System Debuts at SNUG

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

Part 4 –  The Weakest Lynx

Part 5 – The Mising Lynx – The ASIC Cloud

harry the ASIC guy

Tags: , , , ,

One Response to “Strongest Lynx”

  1. John Eaton says:


    I started my career in the 70’s and have seen huge changes in how we design chips. My first couple of decades I used schematic capture systems.

    Todays asic designs are incredible. The size, speed,complexities and schedules are mind numbing. Every couple of years we get a new process that adds new requirements on top of previous ones. Nothing in my experience as an R+D engineer has prepared me for this.

    I have however spent a couple of stints in manufacturing bringing new products up the product ramp. Those experiences have helped me deal with todays asic design issues.

    The traditional R+D methodology is to put together a team of really smart people to create the one prototype and then throw it over the wall to production. That doesn’t work anymore. What works is to design a process that takes input from designers and “builds” a asic maskset in the same manner that you do high volume production.

    Lynx is one such process. You can’t look at it as a R+D tool but rather as a production tool.

    Every piece that is used on a production line has a parts spec that fully describes it and an incoming inspection procedure that tells you how to verify that the part coming in the door met that spec.

    Does lynx have a spec that lists the requirements for the incoming RTL and constraint files? How do you check the rtl to verify that it is correct?
    What do you do if it’s not?

    Does lynx support “Just-in-time” delivery? In production it means that the parts arrive only when they are needed and you don’t store up any WIP
    (work-in-progress) material. That way if there is a problem then there is less rework to deal with.

    In asic design this means when a designer makes a mistake you catch it quickly. It doesn’t take a month to synthesize into a netlist only to be caught by some back end tool. How long does it take you to catch errors?

    John Eaton

Leave a Reply