datasheets.com EBN.com EDN.com EETimes.com Embedded.com PlanetAnalog.com TechOnline.com   UBM Tech
UBM Tech

Hierarchical physical design—issues and methodologies

-July 12, 2013

In IC physical design, there is a tendency to focus on the synthesis and layout tasks, and to not give much consideration to the chip finishing tasks, at least not until the more pressing matters of timing closure and power analysis are in hand.  This can be a dangerous practice to follow, and for large hierarchical designs there is a significant risk that issues identified during top-level finishing could require flow modifications at the block level, causing blocks to be re-opened and schedules to slip.  Also, there is the wider issue of consistency across the blocks of library versions, flows, tools, and procedures, particularly where different parts of the design are farmed out to different design team members. 

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 1 Large designs are split into smaller physical blocks, which are instantiated as macrons at a higher level in the hierarchy.


Figure 2 A typical design might use several libraries of standard cells, pads, memories, or other IP.
Data consistency

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:
  1. 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?
  2. 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?
  3. 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.

Loading comments...

Write a Comment

To comment please Log In