Guidelines for Successful IP Integration and Tapeout

Introduction

The increasing size and complexity of modern silicon systems results in a growing need for reusable and pre-verified third-party IP, such as embedded memories, processor cores, high-speed interfaces and analog IP. Incorporating these components into a single chip can be a challenge due to the variety of different IP, the increasingly difficult design rules for modern processes, and the limitations of the existing stream-out layer numbering system.

This article discusses best design practices and methodologies that help ensure the successful integration of 3rd party IP into next-generation, complex system-on-chip designs, and enables designers to achieve a successful path to tapeout.

Data Consistency

Ensuring that everyone in the design team is using a common, consistent set of source data is frequently overlooked. A typical design might use five or six different standard-cell libraries, two or more pad libraries, many memories from one or more vendors, a range of interface IP blocks, and in-house macros such as processor cores and analog modules (Figure 1). Good data management involves tracking of release versions, scripted flows for building tool-specific databases, and careful checking of results. Here are some tips, which will be further discussed in the following sections:

• Different tools use different views of the original data. For example, the physical layout of an IP block is often supplied as a GDS file, however this needs to be converted into a database format suitable for place and route tools. During tapeout, the place & route tool writes a full-chip GDS containing this IP.
• Tip: Apply good design practices to ensure that no information is lost during the translation process.
• Different library data is used by different tools at different stages of the flow. The location from which data is loaded needs to be specified somewhere, maybe in a script, in a configuration file, or stored inside the design database.
• Tip: Be sure that a consistent, coherent set of data is used, i.e. that all tools reference the correct version of the IP data, and stored or cached references are forcibly updated when a new version is installed.
• Physical signoff tools use rule sets to check that designs are manufacturable and functionally correct. Some third-party IP requires specific option configurations in order to satisfy these signoff checks, and these configurations need to be valid when applied at the chip level.
• Tip: Identify as early as possible a single, common set of rules and options for full-chip verification, and apply them to all blocks in addition to the top-level.
• Hard-coded ROM programming is often only finalized near the end of the project, and may be delivered just days before tapeout.
• Tip: Ensure that procedures are in place to pick up this new data during stream-out, and ensure that model (schematic/source) netlists are updated to incorporate the new coding.

Methodologies to Ensure IP Integration Success

This section explores several methods that Synopsys Professional Services uses to help address challenges involved with IP integration.

Library QA Checking

Quality assurance checking of incoming IP can be performed to different degrees, but a minimum set of checks should include running full design rule checking (DRC) and layout versus schematic (LVS) checks on the data, in addition to some general library checking commands within the layout tools. Ideally these DRC/LVS checks should be run on the supplied GDS, and also on a GDS file generated from the IP library database using the same stream-out options as for the final tapeout. This gives the additional assurance that the quality and integrity has not been compromised during the format translation, particularly as a result of any layer-mapping operations or other transformations.

Many IP blocks will require specific options to be set in the runset files, and these may conflict with those for other IP blocks.

Tip: At an early stage, start building a single runset file that will work for all of the IP, which can then be used during signoff. Other options may also need to be customized to satisfy good design practices, such as setting case sensitivity.

Layout vs. Layout Checking

Layout versus layout (LVL) allows two GDS files to be compared (XOR or NOT) on a layer-by-layer basis (see Figure 2). This is extremely useful for validating IP blocks in the streamed-out GDS against their original (golden) GDS data. This ensures that nothing has been corrupted in the block and confirms that the specified IP version has been implemented.

This can be invaluable where ROMs are concerned, since an essential part of any tapeout checklist should be to confirm that the correct ROM code is used.

Tip: Do not simply rely upon LVS checks because they check the layout against the schematic, and any error in referencing the wrong ROM layout during stream-out is likely to also result in the wrong ROM schematic being used for LVS, which will then fail to flag a violation.

Physical verifications tools like IC Validator also offer a layout integrity management system. The principle is that a database of checksums for pre-validated IP layouts is created and subsequent design databases are validated against this database as part of physical verification. The effect is very similar to running LVL, except that the golden reference is now the checksum database, and more informed reporting is possible.

Common Library Reference Data

It is important to ensure that a common set of references is used for linking cell and IP libraries, and that references to the different views of the same IP are consistent. Since each IP has several data files associated with it (timing models, netlists, layout data, schematic views, etc.) the files must all be accessed from the same base location. Human error is minimized by confining all of the references into a single shared configuration file that is carefully maintained and checked (see Figure 3). The use of common path variables within this file further reduces the risk of error. In addition, a revision control system can be used to synchronize this file between users, while also allowing for local differences during the development stages of a project. 

Documentation

One of the most important, yet often overlooked, sources of information to the layout engineer is the set of integration notes for the various IP blocks that will be incorporated into the chip. In many cases, these are provided as PDF data books, however they may also be simple text documents or release notes.

Tip: It is vital to ensure that all delivered documentation is retained, and is scanned for important integration requirements, guidelines, or tips.

Obvious things to look for are ESD requirements, guard-bands, blockages and other place/route rules. However, less than obvious are the recommended settings for physical verification tool rule sets, results from the vendor’s own verification tests (including DRC waivers), and specific layer usage and mapping requirements. This is all highly useful information that helps ensure a trouble-free integration.

Physical Implementation and Verification

It is usual to run, at the minimum, DRC and LVS at the chip level as part of the physical verification checks. DRC ensures that the design is manufacturable based on a runset provided by the foundry, while LVS checks that the layout matches the schematic (or source) data both physically and functionally.

DRC Checks

Library QA checks help ensure that the IP blocks are consistent and can be validated independently, but when the IP is integrated into an SoC there are many other factors to consider. Chip-level DRC checks include additional rules that are only enabled in full-chip mode, but might be impacted by IP placement or proximity to other structures. Early chip-level DRC checking is a must, and in the worst case scenario of an IP having to be re-built, the turnaround time could run into several weeks, or even months. This can, and does, happen!

LVS Checks

LVS checks are the final part in the verification process and should provide a high degree of confidence in the functional correctness of the physical database. However, LVS checks will not detect a poor implementation and cannot differentiate, for example, between a good ground bonding scheme and an ineffective one. During the library QA stage, the LVS runset is configured to run as optimally as possible, but even so it is highly likely that extraction errors will still be reported.

Tip: Be prepared with the knowledge to discern the real issues from the false, and to provide justification for any waivers.

When using multiple IP blocks from the same vendor, there can be an issue whereby LVS checks wrongly equate layout blocks in one IP with schematic views in another. Usually this happens when the blocks have very similar names, which can happen when the IP shares common, generic, modules with just a few differences between them. These types of issues require some skill to resolve, and are certainly not the kind of problem to be faced under the pressures of a looming tapeout!

Design Reviews

Even the best documentation doesn’t give 100% confidence in the IP implementation, especially for functions like interface blocks that require ESD protection, noise immunity and separate power supplies, etc.

Tip: Review the layout with the IP block support team who can call upon a wealth of experience in such matters and ensure that nothing has been overlooked. They are the experts and their help should form an integral part of your support package. 

Conclusion

This article has only touched on some important parts of physical integration and signoff. Much of what has been covered reflects good design practice followed by Synopsys Professional Services. If we are responsible for signing off a design, we should be asking ourselves questions like, “How confident do we feel?” “How do these results prove our design really will work?” and “What other checks should we have considered?”

We cannot eliminate human error, yet human input is what differentiates one product from the next. There is always risk in building chips, but with good management and sturdy design practices we can manage the risk and head towards tapeout with confidence.