TSMC Challenges Lynx With Flow Of Their Own

About a month and a half ago, I wrote a 5 part series of blog posts on the newly introduced Lynx Design System from Synopsys:

One key feature, the inclusion of pre-qualified technology and node specific libraries in the flow, was something I had pushed for when I was previously involved with Lynx (then called Pilot). These libraries would have made Lynx into a complete out-of-the-box foundry and node specific design kit … no technology specific worries. Indeed, everyone thought that it was a good idea and would have happened had it not been for resistance from the foundries that were approached. Alas!

In the months before the announcement of Lynx, I heard that Synopsys had finally cracked that nut and that foundry libraries would be part of Lynx after all. Whilst speaking to Synopsys about Lynx in preparation for my posts, I asked whether this was the case. Given my expectations, I was rather surprised when I was told that no foundry libraries would be included as part of Lynx or as an option.

The explanation was that it proved too difficult to handle the many options that customers used. High Vt and low Vt. Regular and low power process. IO and RAM libraries from multiple vendors like ARM and Virage. Indeed, this was a very reasonable explanation to me since my experience was that all chips used some special libraries along the way. How could one QA a set of libraries for all the combinations? So, I left it at that. Besides, Synopsys offered a script that would build the Lynx node from the DesignWare TSMC Foundry Libraries.

Two weeks ago, at the TSMC Technology Symposium in San Jose, TSMC announced their own Integrated Sign-off Flow that competes with the Lynx flow, this one including their libraries. Now it seems to make sense. TSMC may  have backed out of providing libraries to Synopsys to use with Lynx since they were cooking up a flow offering of their own. I don’t know this to be a fact, but I think it’s a reasonable explanation.

So, besides the libraries, how does the TSMC flow compare to the Synopsys Lynx flow? I’m glad you asked. Here are the salient details of the TSMC offering:

  • Complete RTL to GDSII flow much like Lynx
  • Node and process specific optimizations
  • Uses multiple EDA vendors’ tools  (Synopsys mostly, but also Cadence, Mentor, and Azuro)
  • Available only for TSMC 65nm process node (at this time)
  • No cost (at least to early adopters … the press release is unclear whether TSMC will charge in the future)
  • And of course, libraries are included.

In comparison to Synopsys’ Lynx Design System, there were some notable features missing from the announcement:

  • No mention of anything like a Management Cockpit or Runtime Manager
  • No mention of how this was going to be supported
  • No mention of any chips or customers that have been through the flow

To be fair, just because these were not mentioned, does not mean that they are really missing, I have not seen a demo of the flow or spoken to TSMC (you know how to reach me) and that would help a lot in evaluating how this compares to Lynx. Still, from what I know, I’d like to give you my initial assessment of the strength of these offerings.

TSMC Integrated Signoff Flow

  • The flow includes EDA tools from multiple vendors. There is an assumption that TSMC has created a best-of-breed flow by picking the tool that performed each step in the flow the best and making all the tools work together. Synopsys will claim that their tools are all best-of-breed and that other tools can be easily integrated. But, TSMC’s flow comes that way with no additional work required. (Of course, you still need to go buy those other tools).
  • Integrated libraries, as I’ve described above. Unfortunately if you are using any 3rd party libraries, you’ll need to integrate them yourself it seems.
  • Node and process specific optimizations should provide an extra boost in quality of results.
  • Free (at least for now)

Synopsys Lynx Design System

  • You can use the flow with any foundry or technology node. A big advantage unless you are set on TSMC 65nm (which a lot of people are).
  • Other libraries and tools are easier to integrate into the flow I would think. It’s not clear whether TSMC even supports hacking the flow for other nodes.
  • Support from the Synopsys field and support center. Recall, this is now a full fledged product. Presumably, the price customers pay for Lynx will fund the support costs. If there is no cost for the TSMC flow, how will they fund supporting it? Perhaps they will take on the cost to get the silicon business, but that’s a business decision I am not privy to. And don’t underestimate the support effort. This is much like a flow that ASIC vendors (TI, Motorola/Freescale, LSI Logic), not foundries, would have offered. They had whole teams developing and QA’ing their flows. And then they would be tied to a specific set of tool releases and frozen.
  • Runtime Manager and Management Cockpit. Nice to have features.
  • Been used to create real chips before. As I’d said, the core flow in Lynx dates back almost 10 years and has been updated continuously. It’s not clear what is the genesis of the new TSMC flow. Is it a derivative of the TSMC reference flows? Is it something that has been used to create chips? Again, I don’t know, but I’ve got to give Synopsys the nod in terms of “production proven”.

So, what do I recommend. Well, if you are not going to TSMC 65 nm with TSMC standard cell libraries, then there is not much reason to look at the TSMC flow. However, if you are using the technology that TSMC currently supports, the appeal of a turnkey, optimized, and FREE flow is pretty strong. I’d at least do my due diligence and look at the TSMC flow. It might help you get better pricing from TSMC.

If anyone out there has actually seen or touched the TSMC flow, please add a comment below. Everyone would love to know what you think first hand.
harry the ASIC guy

Tags: , , , , ,

2 Responses to “TSMC Challenges Lynx With Flow Of Their Own”

  1. John Busco says:

    I haven’t seen the TSMC Integrated Sign Off flow, but it sounds like a “reference flow on steroids”, since it includes the libraries and perhaps more detailed scripts and settings. As you’ve pointed out, it’s missing that whole flow management aspect of Lynx. I’m certainly interested to go through TSMC’s flow and see if I learn anything new.

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

  2. Well it sounds a bit like reference flow warmed over. If you can find a customer who is using it in production I would be real surprised.

    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 ?

Leave a Reply