I thought I might help clear up a couple of things that seem to be common threads here:

First let me clarify the comment ” … it would be better to have a truly open flow, ..”.
Lynx is a truly an open flow - there is nothing in the structure or content of Lynx flows that prevent or hinder you from adding in any tools or utilities at all. The flow is defined in ascii files, the scripts are delivered as source code and written in Tcl, but you can use your favorite scripting language too if so desired. Script execution , tool version selection, error checking, and metrics capture amongst other things are all completely user definable.

Adding a bit more light to Steve’s post on 3rd party tools and debugging issues in Lynx …

Third Party Tools
———————
In Lynx a task definition has 2 parts to it as follows:

# 1. Execute a script
<command> <script> <source> <destination>
# 2. Check the logfile using a “egrep like” command
<check> <logile>

For dc this looks like this
dc_shell –f <some_tcl_script> SRC=elaborate DST=compile
check dc_shell.log

The <script> is a filename that you specify in the flow editor as a property of the task box. The SRC and DST variables are defined by how you connect tasks in the flow editor - you can also completely ignore them if you want and have your script decide where to read and write data (but this does kind of bypass a lot of the goodness in being able to define the flow graphically).

The checking is again optional – you can choose to have no checking at all done in which case the subsequent task(s) will always execute even if your script ran into problems.

So how does this map into executing a third part tool?
Simply put, the <program> can be anything and the <script> can be anything. For example I can execute a shell script that invokes any other tool or utility. Here is a real example used in Lynx
tclsh /some_path/run_hercules.tcl SRC=FINISH (no DST since this is just generating a report)
check SRC/hercules.log

As you can see in this example, we are treating Hercules as if it were a third party tool by invoking it through a wrapper script.
The script does not even need to be an EDA tool. How about having a script that munges your data in preparation for some other task to use it (convert netlist format etc), if you really want to stretch this how about a script that invokes your old flow wholesale!

You might note also that this latter example shows that there is really no requirement to “break up” scripts. The granularity of the scripts are really driven by user preference. As a default we prefer shorter tasks to allow easier backtracking in the flow but you can certainly, for example, combine your placement, CTS and route tasks into a single script that does all three operations in one task.

Lynx does use environment variables to define some directories in the system and also provides variables that define technology and library references. It’s not a hard requirement to use them, but a recommendation that allows people to avoid bad practices like hard-coding information into scripts and helps maintain consistency across the flows. Not that we would recommend it, but you can write your script entirely absent any kind of variables if that is your preferred coding style.

Debugging
————-
Debugging can be a difficult task in any design environment, however there are features in Lynx that help you here.
• Interaction – start the tool inside of Lynx and interact with it, query the database, try alternate command sequences etc. Step through the script by cutting and pasting, just like you would when debugging outside of Lynx
• Tracing – Lynx can output a 100% variable free, loops unrolled, if/then resolved script that shows every command that was executed. This will reproduce outside of Lynx the exact command sequence you ran inside of Lynx. The script can then be executed, for example, simply by doing dc_shell –f
• Exporting - While tracing is very useful in some circumstances such as for submitting testcases it is not the complete solution. You may not want something where every variable is removed – maybe you want to be able to take a subset of the flow and use it outside of Lynx – this is where flow export comes into play. You can export subsets of the flow into a portable environment where some variables are still used for library setup etc but it is not Lynx anymore. This is what you use for exporting IP flows outside of Lynx if your end consumer doesn’t have Lynx and you need to deliver either a flow or a completed block to them.

Upgrading
————–

Upgrading any flow mid-design is a challenge (and as Steve correctly noted, avoided by most design teams if at all possible), but Lynx helps here with the notion of global and local scripts and also the extension of this to having company or project specific scripts. By following certain (documented) guidelines, it is certainly feasible to upgrade the flow mid –design, however what we tend to see in our customer base is not wholesale flow upgrading but rather point upgrading of specific scripts to use the latest tool features. Lynx helps here in allowing you on a task by task basis to specify a tool version to be used. It is a simple option to change the tool version and see what happens with a given script. If there are new command line options or features you want to make use of, then you can create a local copy of the script (or take the default one delivered with the new Lynx version and make it local).

One last point – all of this is documented in the Lynx documentation, not much of it is in Solvnet at present but you will begin to see notes appearing in Solvnet over the coming months.

Hope this clears things up a little

Regards
Chris Smith
Synopsys Lynx CAE

Pilot may have been limited when it came to 3rd-party tool support, but the Lynx folks are working hard to make it easy to use non-Synopsys tools with Lynx. Integrating a 3rd-party tool or existing script appears to be very straightforward. I think a few lines of code will suffice. It’s no harder than integrating a new Synopsys tool. The only real requirement is to follow the Lynx environment variables for where your script writes its outputs.

As for upgrades, while it might have been awkward to upgrade Pilot, the Lynx folks appear to have learned their lesson. The variable and file format definitions should be robust enough to remain unchanged across versions. I expect updates to the Lynx GUI(s) will be independent of changes to the task/tool definition files. In any case few projects will make wholesale flow upgrades in mid-project, and in this respect Lynx is no more difficult than any other flow
environment. As you point out it might even be easier because Lynx is now a supported product.

Finally regarding debug, yes it is always difficult debugging something that someone else wrote! The difference here is that all the scripts are available to be modified by the user if necessary. Modularity is a good thing; having many shorter scripts that each do one task makes it easier to concentrate on the flow and pinpoint any problems.

Pete Churchill and I gave a presentation on flow methodology at DAC 2008. Many of our suggestions and recommendations were independently developed by the Pilot (now Lynx) team, thus Lynx seems very familiar. Pete and I hoped that users would come together and agree on an open standard for how to describe tasks and flows: individual modular tasks and the complex flows that result when you chain them together.

In our DAC presentation we described a tool called flowMaker which in Lynx-speak is sort of a poor man’s Runtime Manager. We could modify flowMaker to use the Lynx file syntax. Perhaps Synopsys will open up the variable and file format definitions like they did with SDC? This would enable even more tool/flow development compatible with the Lynx environment. That’s of great benefit to all users.

Thanks for the comment. It’s actually quite a bit more than the reference flows that either Cadence or Synopsys offer. Synopsys makes Lynx consistent with the reference flows (they say that it is incorporated) but adds standard directory structures, flow control, links to revision control (CVS,SVN, etc), and job distribution (LSF, GRD). And then all of the metrics reporting and GUI for managing the flow.

Regarding being open, I don’t think there is anything inherent that prevents 3rd party tools. If Synopsys were to document the interface and methods for implementing third party tools and provide access to 3rd parties to implement and test integration, then I think that would work out well.

Harry

I totally agree with you that it would be better to have a truely open flow, it is limiting the potential user base as you point out.

If it would be open and it would be easy to integrate 3rd party tools, then Lynx would have a good value in itself. Now it appears to be more a copy of Cadence’s Reference Flows/ Design Kits and a promotional base for SNPS tools only.
Obviously and understandably this is in SNPS interest. But it is really limiiting the potential leverage such an integrated design system could have.

Thomas