Hierarchical physical design—issues and methodologies
In this paper, we will examine some of the issues and methodologies encountered during the finishing and physical signoff stages, and discuss how some of the risks can be mitigated by forward planning and careful data management based on successful experiences of Synopsys Professional Services design consultants implementing large designs. We will also look at additional methods that can be used to give a high degree of confidence in the integrity and manufacturability of a large hierarchical design.
Hierarchical physical designs
For large designs, there are advantages to be gained from splitting the physical design process into manageable chunks, or blocks, that are then combined together at a higher level of hierarchy to form a larger composite block, or the top-level (Figure 1). This physical partitioning of the design is different from the logical hierarchy imposed by the structuring of HDL languages, although it will usually follow the same boundaries such that there is a mapping between logical and physical hierarchy. The partitioning of the design into physical blocks does require a good understanding of functionality, data flow and hierarchical design methodology, but is not itself a subject for discussion here. We are going to examine what happens towards the end of the flow when these blocks are brought back together and integrated into the final chip design, in preparation for tapeout.
Figure 2 A typical design might use several libraries of standard cells, pads, memories, or other IP.
One aspect of hierarchical design that can be easily overlooked is data consistency, i.e., ensuring that everyone and everything is using a common, consistent set of source data. A typical design might use five or six different standard-cell libraries, two or more pad libraries, many memories from more than one vendor, assorted third-party IP blocks, and in-house macros that may be separately built, such as processor cores and analog modules (Figure 2). Good data management would involve tracking of release versions, scripted flows for building tool-specific databases, and careful checking or results. Here are some pitfalls to watch out for:
- 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 tape-out, the place & route tool will write a full-chip GDS containing this IP, but how can we be sure that nothing has been 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. How can we 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?
- Hard-coded ROM programming is often only finalized near the end of the project, and may be delivered just days before tapeout. We need to be absolutely sure that this new data gets picked up during stream-out, and model (schematic/source) netlists are also updated to incorporate the new coding.