Meeting Today’s Challenges For LVS

Find root causes of early full-chip LVS issues faster.

popularity

At least one thing is for certain in semiconductor development: bigger and more complex designs put lots of pressure on electronic design automation (EDA) tools and methodologies. Yesterday’s chip is today’s IP block, and entire racks of electronics are being packed into system-on-chip (SoC) devices. EDA tools must evolve constantly in order to keep pace with size and complexity while meeting ever-shrinking project schedules.

One of the earliest EDA applications, layout-versus-schematic (LVS) checking, is no exception. As soon as netlists and layout files were computerized, designers wanted to ensure that they matched. Any deviation due to manual layout or improper use of automatic place and route tools can compromise chip functionality. Today’s huge SoC designs, schedule pressure, and advanced technology nodes are all driving the need for more efficient physical verification flows, in which LVS is a key component. Traditional tools and methods are not sufficient.

There are several key requirements for a modern LVS solution. Naturally, any tool must be able to handle the size and complexity of the largest designs. Any form of partial analysis runs the risk of missing bugs that could cause a very expensive chip turn. The project team must know for sure that the design has been properly implemented at the physical level. However, complete analysis cannot require unbounded time. The project must meet its time-to-market (TTM) goals to keep the end product competitive.

The key to meeting the TTM requirement is to “shift left” LVS and the entire physical verification process. This entails starting LVS as early in the chip development schedule as possible. Waiting until the complete SoC has been routed before running LVS is no longer acceptable. The development team must run LVS seamlessly and cleanly as they proceed through the design of macros, blocks, and intellectual property (IP) components.

Many issues can be detected locally, within a block or subsystem, without having the context of the complete chip. Finding and fixing these issues early accelerates the physical verification process and makes future runs at higher levels of hierarchy much cleaner. LVS analysis at the local level should be of signoff quality in order to avoid unpleasant surprises during full-chip signoff late in the project.

Block-level LVS signoff reduces the amount of preparation work needed for full-chip analysis, which can also be shifted left. It is not necessary or desirable to wait until the end of the project to run full-chip LVS; the team can start as soon as the bulk of the SoC is assembled. Since the physical verification process occurs in parallel with final chip assembly, the LVS runs must be efficient so that they do not delay design completion.

Historically, full-chip LVS has been a highly iterative process, with each run consuming multiple days. The effort to debug errors, fix the design, and rerun LVS for each iteration is time consuming and resource intensive. Many chip project schedules have slipped due to delays in LVS signoff. A wide variety of issues tend to arise as the blocks are merged into an assembled chip, including:

  • Macro/IP out of sync
  • Mismatched technology or library
  • Integration errors in the top hierarchical design
  • Interface pin alignment errors
  • Top-level shorts

Designers need a fast and automated way to find root causes for such issues found in early full-chip LVS runs. By swiftly detecting design problems, the turnaround time for each debug/fix/reroute cycle is reduced dramatically. This enables more frequent and shorter iterations and leads to earlier LVS signoff. The solution must be able to run in parallel on multiple compute resources to make both early and final signoff LVS runs more efficient.

Even after the chip has been laid out successfully and all violations resolved, changes can occur before tapeout. These might be due to an engineering change order (ECO) or to last-minute updates to macros or IP blocks. In such cases, LVS must be able to check these changes without a full-chip rerun for every change. Only a final full LVS run for signoff is required.

Synopsys provides a robust, modern LVS solution that is faster and smarter than traditional tools, improving productivity, performance, and debugging. Synopsys IC Validator physical verification is a comprehensive and high-performance signoff solution that improves productivity at all process nodes. It includes Explorer LVS technology, the industry’s first modern LVS solution for the SoC era.

Although it can be run anytime during signoff preparation, the maximum benefit of Explorer LVS is achieved when running right after initial full chip integration. Unexpected violations are often detected at this stage, requiring long and tedious run/debug/fix/rerun iterations with traditional LVS tools. With Explorer LVS, any critical issues can be detected quickly and efficiently.

Explorer LVS is entirely complementary with full LVS. Typically, full LVS runs on blocks/macros/IP after floorplanning and place-and-route to detect issues early in the project. As soon as the pieces are assembled into a full chip, Explorer LVS provides short runtimes and intuitive debug to clean up the design before final signoff with full LVS. If last-minute updates happen, Explorer LVS ensures that the integrity of the design has not been compromised.

Measures on actual customer designs show that Explorer LVS runs up to 30X faster and consumes up to 30X less memory as compared to full LVS. This solution provides a fast and automated way to find root causes of early full-chip LVS issues with much shorter iterations. SoC designers can tape out earlier with full confidence that all LVS issues have been detected and fixed.

For more detailed information, a white paper is available.



Leave a Reply


(Note: This name will be displayed publicly)