5.1.2 CAN ANALOG DESIGNS BE SUCCESSFULLY MIGRATED?

Considering all the constraints to be satisfied, analog migration seems difficult. In addition to the apparent difficulties, analog design is a somewhat specialized, not too common skill. Furthermore, one would expect a reasonable level of skepticism to using migration on analog designs. After all, there has been a rather common resistance to using hi-tech EDA-type tools for analog in general, especially for layout. This is partly justified because analog design is tricky and partly because tool design has not received as much attention as tool design for digital design.

Of course, it is true that analog has never been mainstream like digital technology and that it is more delicate than digital. In fact, there is a strong trend towards replacing analog with digital wherever possible. So there are technical and psychological obstacles to overcome. Whatever the arguments, analog is almost always needed in conjunction with digital. We shall try to make an objective assessment of the realistic chances of successful analog migration.

5.1.3 A PRACTICAL VIEW OF ANALOG MIGRATION

Since analog functions in VLSI chips can not generally be avoided, we will explore some compromise approaches to migrate mixed signal designs. But first we will summarize the key issues to keep in mind:

  1. Maintain symmetry, locally and globally.
  2. Maintain electrical matching (same loads, size, relative position, orientation). Since matching is key, one should look at components and devices in pairs.
  3. Keep elements on isotherms (same distance from heat sources) and equipotential lines (same distance from significant current sources or sinks).
  4. Similar arguments concerning serious noise sources. One needs to very seriously look at cross-coupling and the resulting loss of signal integrity.
  5. Keep interconnects symmetrical.

We mention many of the above caution flags not so much because of retargeting. They are part of the basic principles of careful, knowledgeable mixed signal or analog VLSI circuit design. In fact, a legitimate question that comes to mind is: Just how feasible is mixed signal VLSI design, irrespective of migration? We all know it can be done and can be done well. We also know that relatively few people are really good at it.

The following are possible approaches to analog migration:

  1. One can always take a minimalist approach to using migration since no less than ninety percent of a chip will generally be digital. Accordingly, one can use the “keep out” or “don't touch” approach to the analog part of a circuit, migrate the digital part as usual, and just substitute the analog part with a new analog layout created by manual design.
  2. One can use less process-dependent (parameterizable) analog circuits. Such circuits have been designed using tools like GDT (for old-timers who were around back then). Of course, such circuits can address some of the problems, but not all of them.
  3. Apply a linear shrink or a “creative linear shrink” by scaling some parameters differently than others and then fixing remaining problems by hand. The positive aspects of a linear or optical shrink are that it does not disturb the symmetries and proportionality relationships. The negative aspects of a linear or optical shrink are that the new design rules are not a scaling of the old design rules. Finally, layout features will not be on a grid after a linear shrink.
  4. Do a proportional compaction. This will keep the symmetries and changes proportional while keeping all layout features on grid.
  5. Develop an analog compaction engine that allows for specification of the major analog constraints stated above. This would be the most elegant solution, but there seems to be nothing like that on the horizon. Until analog plays a more dominant role and there is promise of a big market for such a product, there may not be sufficient motivation.

In fact, the need for a sufficiently large market for analog compaction is probably the most problematic issue. Some efforts do exist but, so far, they have not gone much beyond the university level. At a time when compaction of digital circuits seems ahead of its time, it is doubtful that anybody will invest heavily in analog compaction.

5.2 HIERARCHY IN HARD IP MIGRATION

In many design disciplines, hierarchy plays a key role in managing complexity. Of course, hierarchy and hierarchy maintenance mean different things in different design disciplines. We will now discuss what hierarchy and hierarchy maintenance mean for Hard IP migration, creation or optimization.

Maintaining hierarchy in Hard IP migration has been a serious challenge for many years and is one of the hotly debated issues in Hard IP reuse. Most users want to maintain all levels in the layout during hierarchy migration, at least that is the initial demand when approaching a possible migration project, even though there are pros and cons to maintaining all levels of a layout hierarchy. In fact, the number of levels of hierarchy one eventually wishes to maintain will often (and indeed should) become an intelligent trade-off between the pros and cons to be discussed below.

In the discussions to follow, we will differentiate between what has been possible in hierarchy maintenance up to now (we will call it “traditional migration”), and what is just around the corner (we will call it “fully hierarchical migration”). We will discuss both, and the reasons are simple. Both the fully hierarchical and the traditional migration have and will continue to have justified areas of application. Two to three levels of hierarchy could be maintained for traditional migration. Only in early 2000, has the technology advanced to the point where maintaining any number of hierarchical levels has become possible.

Before we discuss details, we need to review what hierarchy and hierarchy maintenance mean in physical layout.

5.2.1 HIERARCHY MAINTENANCE IN LAYOUTS

In a block diagram, schematic or similar descriptions of a VLSI chip, blocks are clearly recognized by their symbols. The hierarchy of the design is evident. At the highest level, for instance, we have CPUs, controllers, memory arrays. As we traverse the hierarchy from top to bottom, the next level may be memory cells, registers, etc. Going even lower, there are gates and finally transistors and other components. Looking at the proper description in the hierarchy of diagrams, we can also see what is inside these functional blocks.

Thus the hierarchical representation in an electronic or different system shows what parts in the system belong together functionally and at various levels of abstraction.

In the physical layout of a chip, the same principles apply. During the IC layout of a chip or a smaller functional block, depending on the design approach and the functionality required, entities are placed on the silicon in a building block fashion, suggesting a similar kind of modularity as we see in a block diagram or schematic. Thus, even in physical layout, pieces that belong together functionally are placed together physically. There are, therefore, physical boundaries in the layout identifying functional entities, although they are generally much less easily identifiable in a layout than in a block diagram.

In a memory array or any other regular structure, it is easy to see where one cell ends and the next begins. In designs based on standard cells or designs where entire CPU or controller blocks are placed on a chip, the boundaries are also easily identifiable. For random logic without hierarchy, it is very difficult to do the same.

There are many reasons, some of them psychological, why designers want to be able to identify which physical pieces belong functionally to which major parts. Just as hierarchy is critical to design as well as synthesis, verification and simulation of a design, hierarchy maintenance can be very helpful for the verification of a physical layout. Some of the verification tasks to be done on a chip can be done modularly as in the case of functional simulation of a major part in a block diagram.

So, what about maintaining this modularity, generally referred to as hierarchy, when migrating a chip? As we have discussed, this hierarchy can easily get lost when we push around polygons, as is done in compaction. Of course, dealing with hierarchy in a layout may be cutting at the boundaries, as we have shown before, also in terms of maintaining links with data describing physical features in a layout. Either approach will maintain some hierarchy. Maintaining any level of hierarchy during migration means knowing which pieces of the silicon belong to which functional blocks.

So, full knowledge and maintenance of a hierarchy means knowing this association down to the polygon level. After all, it is the association of each and every one of these polygons within the blocks that creates an identifiable function, however small it may be. The polygons of a functional entity logically belong together.

The hierarchy of the design is evident. When we look at the proper description in the hierarchy of diagrams, we also reveal what is inside these functional blocks.

The difference between the design phase and the migration phase is that, initially, during the design phase, each of these polygons is assigned to a certain functional block through links in the description of the design like a layout-description language, schematic, block diagram, etc. As long as this link is maintained, we have a layout that still has the hierarchical information in it.

For the migration phase, one may start out with just a GDS2-type database of polygons. Unfortunately, GDS2 drops all connectivity and properties data of a design, leaving only polygons. Fortunately, more recent physical layout databases do maintain connectivity and property data. To maintain the hierarchy, these links need to be maintained in the migration process. Thus to maintain the hierarchy, we need to “keep track” of the assignment of every polygon to the functional block to which it belongs even after any changes to the layout and migration of the block to a different process.
Having described what hierarchy and hierarchy maintenance mean in somewhat abstract terms, let us demonstrate with actual layout structures what this means for traditional migration and then for a fully hierarchical migration now available.
In terms of traditional migration, we discussed in Chapter 2 how regularity in layouts Such as arrays can be used to maintain some hierarchy in the array structure. We did this by migrating an entire array by taking a single cell out of an array, migrating it by itself and then tiling the array back together. The migrated cell will still be as identifiable in the migrated array as it was in the original array. Maintaining the identity of these repetitive cells is generally referred to as maintaining a single level of the hierarchy of the array.

A single level of hierarchy can be preserved even for a collection of much larger blocks. The identity of the large blocks among the many can be maintained. However, with a single level of hierarchy maintenance, the inside of the repetitive cell and the inside of the various blocks have changed. The inside of the repetitive cell and the various blocks are now a flat sea of polygons from the layout point of view. Also, while tiling together an array of memory cells is straightforward, putting a number of big blocks back together as a chip, especially with the routing in between, may be challenging at times.

In terms of fully hierarchical migration, the data inside the repetitive cells and the large blocks is not flat. Thus, for large blocks especially, the individual functional blocks inside the block are still identifiable and can be worked with individually. Does this suggest why all this hierarchy maintenance is so important?
We will discuss some of these hierarchy issues when we look at the many pros and cons of hierarchy maintenance. For now, just to render all these abstract arguments somewhat concrete, recognizing a block in a layout in its entirety and as a separable part from the rest of the layout allows for analysis and verification on this block without mixing everything up with the rest of the layout. For fully hierarchical migration in a large block consisting, for instance, of an ALU, some registers, and some control logic, we can analyze and verify each one of these smaller entities. This cuts a large layout into manageably sized pieces.