Accelerating multi-corner multi-mode sign-off using the Lynx Design System

Semtech Corporation is a leading supplier of analog and mixed-signal semiconductor platforms for high-end consumer, computing, communications and industrial applications. Although the manufacturing processes we use may be mainstream, our designs definitely are not. They rely upon a dense mix of analog and digital functions, implemented at low power and low cost, and can only be achieved using advanced design tools.

Time-to-market (TTM) pressure means that we also need effective design management; most technical issues can be overcome given enough time, but our job is to do so quickly enough to meet our market windows. This is especially true when we want to produce multiple variants of an IC quickly and at low design cost.

Some say that you shouldn’t expect different results when you keep using the same practices. To improve our efficiency, we therefore decided to move to a complete Synopsys RTL to GDSII flow, supported by the Lynx Design System.

The first chip that we implemented with Lynx was a ‘Big A, little d’ design, consisting of three mixed-signal hard macros tied together at the top level of the design hierarchy with digital logic. Each hard macro included a mix of analog and digital functions. One of the hard macros was instantiated multiple times, and it was so densely packed that it was at the limits of routability. The other two hard macros were each used once. The project targeted a deep submicron process.

The multi-corner multi-mode challenge

One of the key challenges of this design was ensuring that we could achieve timing closure for each of the 306 scenarios that our foundry recommended that we should check.

Why so many scenarios? The chip had eight operating modes: two mission modes, boundary scan, scan shift, stuck-at capture, transition fault capture, two memory BIST modes, and a physical implementation mode, for a total of nine. The foundry advised us to check five operating conditions with five extraction corners to meet the marketing specifications for the product.

The combination of five operating conditions with five extraction corners translated into 17 operating condition/extraction pairs – because one operating condition and one extraction were paired together. Nine operating modes multiplied by 17 operating condition/extraction pairs gave us 153 scenarios.

Concern about the impact of on-chip variation on set-up and hold times meant we had to run these scenarios twice, with different derate factors for each, leading to the overall total of 306 scenarios.

Managing this many scenarios was one of the reasons we moved to Lynx. Without access to an off-the-shelf comprehensive environment to manage a large number of scenarios, it could take weeks just to set up the tools and develop a flow to run all those scenarios and manage all their output files.

In practice, this means that TTM pressure can ‘force’ you to cut corners. This can lead to products not meeting their requirements, causing costly re-spins. That is a risk that the team did not want to take.

The Lynx Design System provided the infrastructure that enabled us to check all scenarios we wanted to, helping the team meet its TTM goal with the right level of sign-off certainty.

Applying the latest tools

One of the key attractions of Lynx is that it provides proven methodologies for using the Synopsys tools and running multi-scenario timing closure, with most of the best tool options and switches already set.

The challenge in such a multi-scenario design is to have an environment that can manage all the scenarios, and deal with the reports and logs. If we do not have that, then building the design environment becomes another project in itself – and if it goes wrong, fixing it could become yet another project.

The fact of the matter is that IC development toolchains offer a lot of ‘knobs’ for us to play with, but without scripts defining a recommended set-up, one can spend a lot of time exploring the options. With Lynx, the included flows and scripts offered a good starting point for our design right out of the box.

The other advantage of being provided with prepared flows and scripts is that they give us a way to start using new features of the tools as they emerge. Synopsys is constantly upgrading tools such IC Compiler with features that are relevant to our work on established process nodes, such as new routing approaches, and Lynx’s packaged scripts and flows help introduce those capabilities to our design team.

Customizing the design flow

Along with needing better tools to do our design, and a better management environment in which to do it, we want to share and re-use what we learned about setting up the tools and the design environment as effectively as possible. In practice, this means two things: being able to port any modifications we make to Lynx to new versions as they are released and being able to port modifications to Lynx from one project to other, potentially concurrent, projects.

Lynx is delivered with source code, so the customizations we make can end up modifying files that were not created by us. Synopsys is also constantly testing the tools for robustness, constantly fixing issues and adding improvements, so when we modify things, we need be able to port our current customizations to the next release of Lynx.

We have been managing this using best practices borrowed from the software development community, such as the third-party code management techniques supported by modern revision control systems. This has been very effective.

For example, after the first project described above concluded, we started four concurrent IC development projects. These were based on an older process and we wanted to ensure all four projects could benefit from any improvements that we made to our design flow and expressed in Lynx.

In this case, the key information we wanted to share effectively was held in technology files for our target process. Lynx supports ‘technology plug-ins’ – a set of files which bundle together data from the foundry, such as the physical and logical libraries – so that it can be accessed by Lynx.

We had to write our own plug-in for the process we were using, and used the revision control system to share updates and enhancements to that plug-in with the four new concurrent projects. This meant we could develop and validate the plug-in at the same time on all four designs, safe in the knowledge that we had a good way to keep everything in sync.

Outcomes

Using Lynx is enabling us to focus our attention on getting our designs out the door in time to meet their market windows.

For example, when we first tried to close timing on the 306 scenarios of the deep submicron chip, the Lynx runtime manager became unresponsive. But Synopsys was able to get an application engineer on site within hours, set up a conference call with one of its Lynx specialists, and deliver a workaround inside half a day. If we had been using our own design-management scheme, fixing it could have been an issue especially if the originator of the system was not available. Such situations could affect design schedules.

We’ve also been able to use Lynx to explore design options. For example, we used the path-based analysis of Synopsys’ PrimeTime tool to reduce some of the pessimism about path delay assumed by traditional static timing analysis.

PrimeTime’s path-based analysis shows that, although a traditional analysis suggests a path is failing timing requirements, it is actually meeting them. This can prevent a design being disturbed when larger cells are introduced to meet timing, increasing area unnecessarily. In our densest designs, such over-design can modify the layout and disturb the already sensitive routing.

Having a design management environment such as Lynx and the evolving capabilities of the Synopsys tools enables us to explore the fine line that exists between a timing-closed design and one in which timing closure is compromised.

In the case of the deep submicron chip with which we first used Lynx, after closing timing on all the recommended scenarios to ensure that the design was right, we taped out. When the chips came back from the foundry, they worked as expected.

For us, running the latest versions of Synopsys tools such as PrimeTime and IC Compiler within the Lynx design environment helped us deliver our designs within the TTM constraints. We were able to improve our quality of results by using advanced features of the toolchain to develop better designs, and comprehensive multi-corner, multi-mode analysis to prove the designs thoroughly before tape-out. And we were able to improve design efficiency by adapting Lynx to our needs while sharing those adaptations efficiently for other designs.

Author

Vincent Rowley has 17 years of experience in integrated circuit, FPGA, system on a chip and embedded systems development. He is a senior digital designer at Semtech Canada Corporation (Gennum Products Group) where he works on mixed-signal devices. Prior to joining Semtech, Vincent was a system architect at Pleora Technologies and a recognized industry expert in the field of high-performance video over IP. He served as Vice Chair of the Automated Imaging Association’s GigE Vision Standard committee and was an active member of the European Machine Vision Association’s GenlCam Standard committee. Vincent also performed digital ASIC design at Catena Networks, now Ciena Corporation, and digital and analog custom IC development at HexaVision Technologies, now Adept Technology. Vincent holds a BSc in electrical engineering from Laval University in Québec City, Canada.