I would give Lynx a much stronger chance of success, both because of the high quality of the developers, their knowledge and access to the tool suite and that they are well integrated into Synopsys AE, and R&D organization so they have access to tons of tool and design expertise. They regular run Lynx on serv

Lynx is also test and revise Lynx during the software development process so at time of release it is designed and tested to work at the time of release. For TSMC any qualification suites would typically be run post-release and may take several service pack releases to work out the bugs and the thing may never converge on a set of multi-vendor tool releases.

I can anticipate both the positive and negative side of a TSMC provided automated flow.

on the positive side there would be a clear reference on which corners and library conditions and DRC decks to run to be “qualified” for hand-off. This creates a baseline and puts an obligation on TSMC to run it and have some experience with the collateral.

On the good side it places responsibility on TSMC for ensuring it works and getting the kinks out of the integration of tools and libraries. So at a minimum there might be one definitive ‘reference’ flow which the PE side of the foundry would be willing to sign-off. It will also make it clear what the real requirements are and give a reality check for them on how the requirements impact a realistic tool flow.

First question ask your TSMC product engineer if he will sign-off on a result from the flow without further conditions. ? I have seen many TSMC ‘research efforts’ which are not deployed, nor accepted by the production side.

A big question is about QA and performance on real designs. As we all know its a big challenge for individual EDA tools to release with QA, and when you combine a bunch of tools in a chain with possible options at each step you get a exponential or factorial increase in the number of coverage points. What type of designs are going through the system ? Then the classic problem is if they find a problem with EDA vendor’s A’s tool Y version X whether they can share the testcase to reproduce and get a bug fix.

A second big question is about version control and combination of version tracking ? Which version of libraries work with with versions of software, and who has responsiblity to track all of these ?

I would be interested to hear how many of TSMC’s clients actually sign-off with all the corners as they are configured in the automated flow ? From what I have heard the margins and number of corners are overly conservative and would result in a non-competitive offering. Most of the guys at 40nm have customized their own flow based on their own discoveries and negotiation of sign-off conditions with the foundry.

Open source is the way to go and would create a lot of innovation between EDA/foundries and ASIC customers.

Here we have EDA and the largest foundry creating an immediate overlap and inherent conflict between nearly simultaneous announcements of similar capabilities. I can see that TSMC would like to control and enable a multi-vendor solution, and I can also see that Synopsys would like to control and restrict to single tool vendor yet multiple asic library. So the obvious solution is both multi-tool and multi-foundry yet no one has the business incentive to create such a solution except the fabless customers themselves. So maybe FSA should sponsor an initiative ?

BTW, Lynx as Open Source EDA would be an interesting idea.