Archive for March, 2009

The Weakest Lynx

Thursday, March 26th, 2009

Earlier this week I wrote about the strengths of the new Synopsys Lynx flow offering. Today, the weakest Lynx.

1. Limited 3rd-Party Tool Support.

Synopsys states that Lynx is “flexible and inherently configurable to readily incorporate 3rd-party technology”. And it is true that they have done nothing to prevent you from incorporating 3rd-party tools. They also have done little to help you incorporate these tools. In most cases, incorporating 3rd party tools means digging in to understand the guts of how Lynx works. That means getting down and dirty with makefiles and tcl scripts and mimicking all the special behavior of the standard Lynx scripts for Synopsys tools. For instance, here are a few of the things you might need to do:

  • Break up your tcl scripts into several tcl scripts in separate directories for the project and block
  • Access special Lynx environmental variables by name in your makefiles and TCL scripts
  • Have your tool output special SNPS_INFO messages formatted for the metrics GUI to parse out of the log file
  • Update your scripts for new versions of Lynx if any of these formats have changed.

If you are motivated, I’m sure you can hack through the scripts and figure it out. However, to my knowledge (I looked in Solvnet, correct me if I am wrong) there is no application note that clearly documents the steps needed and the relevant files, variables, and message formats to use.

It’s not surprising that Synopsys does not want to make this too easy. One goal of offering the Lynx flow is to encourage the use of an all Synopsys tool flow. If it were truly a wide open flow with easy addition of 3rd-party tools, then there would be less of a hook to use Synopsys tools. (Personally, I disagree with this approach and think Synopsys would be better off offering a truly open flow, but that’s the next post).

As a result, Lynx will be used only by customers using a predominantly Synopsys tool flow. I think that is OK by Synopsys. They’d rather sell a few less Lynx licenses rather than support the use of 3rd-party tools. Unfortunately for designers using other tools, Lynx does not currently have that much to offer.

2. Lynx Is Difficult To Upgrade

One of the complaints of Lynx‘s predecessors is that it is not easy to upgrade from version to version. That is because it is a set of template scripts, not an installed flow. What do I mean?

When you create a project using Lynx, a set of template scripts are copied from a central area and configured for you based on your input. Let’s call this V1.0. As you go through the design process, you customize the flow by changing settings in the GUI, which in turn changes the local scripts that you copied from the central area. Now, let’s say that you want to upgrade to V1.1 because there are some bug fixes or new capabilities you need to use. You can’t do that easily. You have 2 alternatives:

  1. Create a new project using v1.1 and try to replicate any customizations from the v1.0 project in the v1.1 project. I hope you kept good notes.
  2. Diff the new scripts and the old scripts and then update your version 1.0 scripts to manually upgrade to v1.1.

Admittedly, Synopsys provides release notes that identify what has changed and that will help with approach #2. And they try to avoid making gratuitous variable name changes. Even then, the upgrade process is error-prone and manual. In most cases, for any one project, customers will just stick with the version of Lynx that they started with in order to avoid this mess. Then they’ll upgrade between projects. That negates the benefit of having a flow that is always “up-to-date”.

In my humble opinion, a better way to architect the flow would have been to have a set of global scripts that are untouchable and a set of local scripts that can be customized to override or supplement the global scripts. In that case, a new version of Lynx would replace the global scripts, but the local scripts, where all the customization is done, could remain unchanged.

3. Debugging Is Difficult

Have you ever tried to debug a set of scripts that someone else wrote? Even worse, scripts that are broken up into multiple scripts in multiple directories. Even worse, by looking at log files that do not echo directly what commands were executed. Even worse, you were told you never had to worry about the scripts in the first place. And worst of all, when you called for support, nobody knew what you were talking about.

That is what debugging was like in Pilot, Lynx’s most recent predecessor.

I’ve been told that Synopsys has tried to address these issues in Lynx. They now have a switch that will echo the commands to the log files. The Runtime Manager can supposedly locate the errors in the log files and correlate them to the scripts. And now that Lynx is a supported product, Support Center and ACs should know how to help. Still, I’d like to see it to believe it. From what I understand, many of these features are still a bit flakey and almost all the Synopsys consultants, the largest user base for the flow, do not use the new GUIs yet.


In summary, Lynx’s main weakness is that it was not originally architected as a forward compatible, open flow for novice tools users, which is what it is being positioned as. In fact, it started out as a set of scripts written by Avanti tool experts for Avanti tool experts to use with Avanti tools. Synopsys has done a lot to try to morph the flow into something that allows 3rd-party tools, upgrades more easily, and eases debug, but the inherent architecture limits what can be done.

So, what should have been added to make Lynx better? You’ll want to read the next in the series: The Missing Lynx.

Part 1 – Synopsys Lynx Design System Debuts at SNUG

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

Part 3 –  Strongest Lynx

Part 5 – The Mising Lynx – The ASIC Cloud

harry the ASIC guy