In traditional migration, whether we like it or not, a migrated layout ends up flat if there is no regularity in the source layout, such as a layout for random logic, or if blocks overlap. Nothing is lost from the random logic block since there was no hierarchy in the source layout. We may or may not lose the hierarchy of layout with overlapping regions, depending on how we proceed.

In Figure 2.17 of Chapter 2 and the center of and below Figure 5.1, we can see what the overlap-induced flat migration yields. The postmigration layout will be flat. The top part of Figure 5.1 illustrates how a regular array is migrated by preserving the identity of each cell. At the top in Figure 5.1, blocks A and B are migrated as individual blocks. They maintain their identity.

In the center of Figure 5.1, we show how blocks A and B share some empty space. The resulting compacted layout for a flat migration will be denser than if it were done hierarchically. This gain in density comes at the expense of the loss of hierarchy. The blocks in the array are no longer identifiable as such.

Fig. 5.1 Contrasting Hierarchical Versus Flat Migration of a Regular Array

The layout at the top has become a flat sea of polygons as symbolically suggested at the bottom in Figure 5.1. This kind of one- or two-level hierarchy maintenance is fine for a regular array as long as the cells of the array are not too large. However, many designs do not have such regularity. They do not have nice straight-line “functional boundaries” that allow identification of functional entities in a layout by nicely shaped rectangles. They may be a completely random arrangement of polygons. Such layouts look much more complicated than even the overlapping ones in Figure 2.17.

With the latest compaction engines on the market, such “generic” layouts can be migrated while maintaining as many levels of the hierarchy as desired. However, we all know that there is no such thing as a free lunch. Given the choice of migrating hierarchically, migrating hierarchically versus flat has both advantages and disadvantages.


There are many reasons why hierarchy and its maintenance are important. We will briefly list some of the reasons, some of which are layout-migration-specific. However, hierarchy maintenance also has a price and sometimes the price may be too high.

First, let's look at the positive aspects of keeping the hierarchy of a design.

All the reasons listed are based on surveys of compaction users.

Some of the reasons given are generic, others are more user-specific. However, all of them are well founded.

  1. Hierarchy means that the details of repetitive cells exist in the database only once, through the design flow. It saves disk space, loading time and run time. Example: A memory cell repeated 1,000,000 times.
  2. Hierarchy allows structured design work. Every block can be designed and characterized separately, enabling partitioning of the chip design into tasks to be done by different designers, and in parallel to improve time-to-market. Also, partitioning allows the use of “building blocks” to be used for various projects.
  3. Hierarchy makes big designs manageable. Flat designs and, therefore, flat compaction, yields very large databases.
  4. Verification: Hierarchical DRC and LVS are only possible after hierarchical migration. Though flat LVS/DRC is always an option, hierarchical verification has become very desirable because of the huge designs.
  5. Maintaining hierarchy allows the use of the same timing verification approach before and after migration. It allows a better “apples to apples” comparison than if the hierarchy were to be lost.
  6. Psychology of habit. As one user put it: “Although a design can be migrated flat and verified flat with no loss of accuracy or reliability, designers prefer a hierarchical design. They consider it to be more reliable because IP to be reused has always been hierarchical.”

In addition to giving up density when migrating hierarchically, hierarchy maintenance has its negative aspects, as well. Accordingly, these aspects need to be weighed against the positive aspects.

  1. Hierarchical designs are larger than flat designs because every cell master has to fit its worst instance.
  2. Performance optimization: Any optimization you do on the electrical side -be it for speed, power consumption or signal integrity- will be suboptimal on hierarchical designs. Ideally, you'd like to tune each transistor and signal to its exact load and environment, something that is only possible for flat designs.
  3. Hierarchical compaction is very compute-intensive and requires a lot of RAM to run. Clearly, in the spectrum from fully hierarchical to cell-based hierarchy maintenance to flat migration, the trade-offs need to be examined. For flat migration, the relationship between compute time and size is not exactly linear, but it is much more so than it is for hierarchical compaction.
  4. After a flat compaction, timing verification can be done on “critical nets” only. For the rest, one should rely on proper design. This way, no full verification of the compacted design is attempted. Extraction for flat designs can be done for gates and for the routing, then after back-annotation, timing analysis can be performed as for hierarchical layouts. Doing these steps hierarchically just seems to be much more “comfortable”.
  5. Hierarchical analysis and design needs to be supported by EDA tools. This is not always the case. It may, in fact, be one of the limiting factors in choosing how hierarchically one wants to work.
  6. Hierarchical migration may require too much setup time for migration to be performed. Sometimes it is more convenient to migrate flat if the resulting difficulties with verification can be handled.
  7. For hierarchical layouts, a lot of characterization is needed. This characterization depends on the partitioning and the granularity in the hierarchy. In other words, for standard cell designs, the cell units need to be characterized. For memories, they are the memory cells. For full custom, larger blocks can be used in the hierarchy. Once characterized, the characterized blocks can be further used in hierarchy. So, every unit and block needs to have its verification and characterization environment. There is a link between the methodology and tools used, and the preferred hierarchical structure of the design, working in parallel.

The S-o-C scenario for IP reuse has already been mentioned in Chapters 1 and 2.

This is such an obvious scenario and yet it is still done only on a relatively limited scale.
Of course, this is not easy to do, considering the many different parameters to consider if we want to mix and match chips from different manufacturers, mix Hard IP and Soft IP, and even throw in some analog capabilities. However, considering the large amount of available IP, the tremendous need for productivity improvements, and the fact that, by using the latest processes, several single chip designs can now fit onto one chip, there are certainly abundant good reasons to explore this approach further. Also, some of the challenges are similar to what has been done with PCBs for a long time, just more difficult.

Some of the advantages of S-o-C are:

  1. Some of the more significant reliability problems with VLSI-based systems come from interconnects between the chips and with chips interconnecting inside the package. With S-o-C, the total number of external interconnects will be reduced significantly.
  2. One of the biggest penalties in speed in VLSI-based systems comes from getting on and off the chip. Besides, timing is difficult to determine accurately. This can be minimized for S-o-C.
  3. The higher the level of S-o-C integration, the more chips can be placed into fewer packages, the more compact VLSI solutions become with the obvious tremendous systems design potential. Savings would also be substantial because packages are expensive.

Some of the challenges of a higher level of VLSI chip integration are:

  1. With that many chips being that close together, eliminating the power generated is a substantial difficulty. This power generated on the chip will also introduce temperature and potential gradients not previously present on the individual chips. This can lead to problems for digital circuits and total failure for analog circuits in the S-o-C solution. Excessive power generation and excessive IR drops may be the single, most significant challenge to S-o-C solutions, as they would otherwise be possible, combining retargeting of various technologies combined with Soft IP reuse [10].
  2. Access to the individual chips is becoming much more difficult, making an already difficult problem—testing—even more difficult. This problem needs to be addressed and it can be. Scan circuitry (boundary scan) around the individual chips will need to be considered. However, as mentioned before, the test vector suites that already exist for Hard IP retargeted chips in the package can be reused.
  3. When placing chips that have been manufactured using a broad range of processes onto one chip, they will all have to work together in a single process. Therefore, the performance of some of these chips is going to change much more dramatically than others. This will require careful timing analysis. The voltage levels also change, requiring a careful analysis of the interface question and possible design of interface circuits. This is a substantially more difficult challenge than placing many chips on a PCB.