Since DAC we have heard a lot about physical verification tools claiming they can read the Calibre(R) SVRF/TVF syntax natively. This blog explores why competitive EDA companies are trying to use Calibre SVRF/TVF, the challenges involved, and the risks to customers.
Why Do Competing PV Products Want to Use Calibre SVRF?
Calibre is a primary sign-off standard at all the major foundries and IDMs, and the majority of fabless and “fab-lite” companies world wide. Calibre is usually the first physical verification (PV) tool used during process development at the foundries and IDMs, and consequently is the first deck available to customers. Because it is first down the learning curve, it invariably is the most mature and stable, and it generally serves as the reference for what “correct” means for other PV tools. Competing PV tools must convince the ecosystem to write upwards of tens of thousands of operations per deck in their native syntax, and then perform the tedious and error-prone operation of comparing that deck to the Calibre standard. This makes life tough for Calibre competitors. It would be “nirvana” if they could just read the Calibre deck directly—they wouldn’t be so far behind, and would have a better chance of getting the right answers. But is it really that simple?
Is SVRF Direct Read Viable?
This blog will not address the proprietary and confidential nature of Mentor’s IP in SVRF/TVF. It is the Lawyers’ job to run that issue to ground.
Instead, let’s talk about the technical issues involved. Mentor’s SVRF/TVF syntaxes were developed with the Calibre platform in mind and the behavior and accuracy of the language is validated quarterly with over 12,400 test cases, which are constantly being extended and refined. This is extremely important because SVRF/TVF has very rich functionality with thousands of available operations and options. In addition, Calibre R&D regularly develops new functionality accessible via new SVRF/TVF operations for which there is no competing equivalent (Equation-Based DRC is an example that comes to mind). In order to read an SVRF/TVF deck, a competitor would have to create a “work around” capability using simpler and limited operations, which could produce inaccurate results. Given the rapidly expanding functionality of Calibre and the SVRF syntax, it is not realistic for a competitor to create, validate and maintain a comprehensive one-to-one mapping of SVRF/TVF. Since the accuracy of verification relies on Calibre decks that use its full functionality, a compromise solution will leave the user trying to figure out which checks are lacking, and how to code missing or inaccurate checks properly. Usually, the most difficult checks are the ones that use the latest Calibre functionality, so that puts customers in a pretty difficult position. Customers should be wary. Claims of comprehensive direct read and translation are just that—claims—unless they are supported and validated through the active participation of Mentor and the foundries.
What Do the Foundries Think?
As noted above, Calibre running SVRF/TVF is a standard defining what is correct for PV based upon multiple certification efforts at all the major foundries. Foundries validate the accuracy of decks defined in SVRF/TVF running Calibre software against their regression test suites and their IP. They do NOT validate the results or accuracy of other competitive EDA tools using Calibre SVRF/TVF decks, nor do they want their customers to use this un-certified combination. Major foundries have even added language in the Calibre deck header file that, among other things, states that Calibre decks are only to be used with Calibre software. Why? Because PV is the hand-off of responsibility from the customer to the foundry. The foundry needs to have complete assurance that all checks were made and dispositioned properly prior to accepting the design. Whether the claim is via direct read or a translator, trying to use Calibre SVRF/TVF decks with other PV software essentially means using an uncertified solution.
Is It Worth the Risk to Your Tape Outs?
If you have been convinced to use a PV tool other than Calibre that “reads” or “translates” SVRF/TVF, you might as well not run DRC at all, at least it would be easier to debug the PV errors! But seriously, what is your risk exposure? Can you truly trust the results? How can you quantify the risk of errors missed by an uncertified solution? Will the foundry take responsibility for incorrect verification results?
Even if the foundry has agreed to re-verify the design on their side with their sign-off tool (Calibre) prior to tape out, there is still a delay should an error be found. In the worst case, if the chip has errors that prevent manufacture, you might completely miss a market window. Either way, it will be difficult to explain why you submitted a design that was not signed off per the procedures you contractually agreed to.
Moreover, will the PV tool supplier that convinced you to take a non-standard approach be there for you long term? The cost of developing, maintaining, and certifying Calibre decks for multiple process nodes at multiple fabs, is substantial for both Mentor and our foundry partners. We make this investment because we are committed to the long term success of our mutual customers. If a competitive supplier is not willing to make the same investment in their own language syntax and decks, do they have a business model that will enable them to be there for you in the future?
All this suggests that a strategy based on directly reading Calibre SVRF/TVF decks, or using a translator, is not an optimum PV solution for customers, is not supported by the industry, and is not worth the risk to your tape out.