Structures with a degree of repetitiveness or regularity of cells can be migrated more efficiently than others and, as we will discuss, it is relatively easy to maintain a clear cell identity through the migration process. This means we know exactly which polygons make up a certain cell before and after it is migrated, and the migrated cell is as clearly a building block within the layout of the regular arrays before and after the migration process as, for example, a brick in wall of bricks. This maintenance of identity is generally referred to as hierarchy maintenance. Repetition does not mean all cells have to be identical. There can be several groups of different cells, but all of the cells within each of the group have to be identical as illustrated in Figure 2.15. Some obvious examples are memory arrays, FIFO “arrays,” the repetitive one-bit data path cells or a mixture of these or any other structure with sufficient regularity to be advantageous to maintain through the migration process.

As Figure 2.I5 suggests, the blocks making up the cell array and the repetitive pieces in the driver and sensing sections surrounding the memory will not be migrated as a “sea of cells,” but the individual cells will be migrated. The layout will then be put back together like Lego blocks.

Fig. 2.15 Migration of Regular Layout Structures

The software recognizes repetitive cells, which means where one cell ends and the next begins. It then places cutting lines accordingly between them. After the migration of each of the various cells, the array will then be put back together again with abutment. In fact, even hand-designed cells, as in memory core cells, can be fitted to the peripheral cells by the migration software. All of this can be done automatically by the software, although human intervention is occasionally necessary to find the best cut lines and often beneficial.

When we previously mentioned three basic steps in migration, human intervention is included in the second part of the setup phase for “trial and error.” To evaluate the migrated design, critical path information and statistical data will be used, as previously discussed concerning the number of geometries being pushed to the process design rule limits.

Because of the very efficient way of handling large array data by migrating the very small individual cells in each group of repetitive cells, very large structures can be migrated in this way very rapidly. The interactive process for finding the best possible cut lines may be the most time-consuming but ultimately very beneficial, and it has to done only once in the initial setup phase.

When discussing the process of migrating regular structures, we took advantage of a very important concept in Hard IP migration:

The maintenance of hierarchy in the physical layout through the migration process.

Maintaining the hierarchy of the source layout through the migration steps is a very challenging migration engineering problem. It means that we will still know after the migration the association of every single polygon in the layout with the block it was part of before the migration. Of course, the degree of difficulty varies considerably from one layout to another. We have seen that it was quite simple for the regular arrays discussed above. But to be completely accurate, it should be stated that, while we maintained the hierarchy of the array structure, any hierarchy inside any of the cells of the array is still lost after the migration. In other words, hierarchy no longer exists within the cells after the migration. The cells themselves are flat. So what is hierarchy maintenance in layout and migration engineering? And what are the various degrees of hierarchy maintenance?

What hierarchy maintenance or its loss means can be easily explained when migrating a regular structure such as a memory. Before we migrate a memory layout, we “know” just exactly what parts in the layout are the memory cells, what parts are the sense amps and the other drivers. In this big “sea of polygons” in the layout database, memory cells are arranged in a nicely regular array with a clearly defined position in the layout, with clearly defined boundaries between them and the polygons that belong to them. We know how to identify these parts because we placed them 011 the chip with function-specific means. If we now migrate a memory as discussed above by taking advantage of the regularity, this regularity is maintained and the association of the polygons with each cell remains intact. This is, of course, the maintenance of a rather shallow hierarchy. When we discuss the migration of a chip, we will achieve a higher level of hierarchy maintenance.

In contrast to any hierarchy maintenance, in flat migration we migrate an entire memory as one block “in one scoop,” as opposed to benefiting from the regularity as discussed above, After the migration, we still know where the cells are located after the migration process. After all, the cells are “boxed in,” and they can't go anywhere. However, the polygons in each cell have moved to compact the layout according to the new process design rules. Boundaries between cells are 110 longer sharply defined and some polygons near the boundary of a cell before migration may have moved across the straight line boundary that existed before the migration between memory cells.

Such polygons now look like they belong to a different cell than before migration. We can no longer associate every single polygon of a certain xy memory cell before migration to that same migrated cell x'y', because we can not keep track of each polygon through the migration process. In fact by migrating a memory cell array flatly, we have declared that the boundaries between cells are no longer significant. We no longer keep track of them. The layout of the entire memory resembles a sea of unidentifiable polygons, only the entire array now has an identity. And we can no longer deal with cells in any consecutive work on the array such as verification. We have to deal with a solid memory block.

Since a picture is worth a thousand words, we show in Figure 2.16 how hierarchy can be lost in a more complicated layout.
On the left side of Figure 2.16, we have a layout with several sizable interconnected blocks that constitute a chip. Each one of these blocks, A, B, C and D fulfills a very specific function. Every polygon in each of these blocks is assigned to its appropriate block by a design specification. Although the blocks overlap and polygons from one functional block are in the middle of polygons from another functional block via the initial specification, each polygon “belongs” to the respective block.

Fig. 2.16 Too Intermingled for Hierarchy Maintenance?

If the blocks in Figure 2.16 did not overlap, it would be easy to migrate them one at a time and maintain their identity and one level of hierarchy. We will show this in Figure 2.19 when we migrate a chip. Since they do overlap we get what we see on the right side of Figure 2.16 with retargeting, using a traditional compaction engine. The resulting layout is completely flat.

However if migration software can assign and remember the association of each and every polygon edge with a certain functional block, any level of hierarchy can be preserved through migration. The latest migration software technology allows this kind of association, which will be discussed later. For now, we assume that the migration software can maintain hierarchy in regular structures, as we have seen in Figure 2.15.

The concept of hierarchy maintenance in any regular array is easy to understand and can always be maintained if desired. Of course, the situation depicted on the left side of Figure 2.16 is particularly challenging in terms of hierarchy maintenance, and it does not occur very commonly in reality. However, it is a good example for graphically illustrating how difficult it may be to maintain hierarchy in a layout. Hierarchy maintenance is particularly critical to layout verification and verification in general within manageable limits.