5.2.2 CHALLENGES IN MAINTAINING LAYOUT HIERARCHY
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
5.2.3 PROS AND CONS OF MAINTAINING HIERARCHY IN MIGRATION
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.
- 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
- 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.
- Hierarchy makes big designs manageable. Flat designs and,
therefore, flat compaction, yields very large databases.
- 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
- 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.
- 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
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.
- Hierarchical designs are larger than flat designs because every
cell master has to fit its worst instance.
- 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.
- 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.
- 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”.
- 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.
- 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.
- 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.
5.3 THE S-O-C MIXING AND MATCHING IN RETARGETING
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:
- 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.
- 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.
- 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
- 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 .
- 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.
- 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.