Ever since IC design complexity has become a bigger and bigger challenge, one approach to higher design productivity has been to describe intent at a higher and higher level of abstraction. Higher levels of abstraction coupled with modular and hierarchical thinking have been cornerstones for managing the increasing complexity of VLSI circuits and system designs. Unfortunately, as a basic rule, the higher the level of abstraction, the greater the distance of the description from the details of physical implementation. From the point of view of design methodology, this is of course part of the strategy, since the higher the level of abstraction, the less cluttered the thinking. The price for this higher level of abstraction is a lack of control over physical aspects of the chip.

Even for DSM technologies, this functional thinking works fine to achieve one design objective, a functionally correct design. However, it does not help to achieve the desired timing aspects of the chip. With DSM, physical aspects of the layout are so important for the desired performance of the chip that it is a serious challenge to the behavioral level of design methodologies, it is a major challenge to keep a close connection between high-level design methodologies (the front-end) and the physical implementation of the design (the back-end).

As we compare Hard and Soft IP reuse, the degree of linkage between the front-end and the back-end will be the key. In fact, Hard IP is the back-end since it is in GDS2 or a different physical layout format. Soft IP is based on a high-level software description of an existing design and has difficulties predicting or controlling the performance of the back-end. However, both approaches, Soft IP and Hard IP, are important for a successful IP reuse strategy. They both have distinct advantages and disadvantages. Soft IP keeps the complexity manageable. Hard IP deals with the details of the physical design. Together, they present a certain continuity from the high-level behavioral description to the physical layout of a chip.

We later show how to combine the Soft and the Hard IP methodologies to win at both ends. In combining the two, we can leave at least part of the detailed timing requirements, timing refinement, to an optimization phase, using the Hard IP methodology. We discuss this optimization phase in Chapter 3.

Combining Soft IP principles with Hard IP optimization, we can more easily achieve the design requirements and lower the risk factors, such as with an accurate prediction of the time-to-market, performance and costs.

It might be helpful to look at Soft IP versus Hard IP as follows:

All Soft IP eventually becomes Hard IP.
Soft IP is front-end. Hard IP is back-end.

Soft IP and Hard IP methodologies may act as complementary partners. However, the link between front-end and the physical implementation needs to be closely monitored anyway. A floorplan that is incorrect in terms of timing can not be rectified with postlayout steps. There is a limit to the degree of postlayout manipulations, although compaction can fix large timing discrepancies lo achieve timing closure.

As chip design ventures deeper and deeper into the submicron territory, interconnects will increasingly determine the time behavior of a chip. Interconnect design will affect signal integrity through cross-coupling, increased power consumption through capacitive loading and perhaps through inductive effects on circuit performance.

While the transistors (referred to as active elements) do all the work, interconnects (the passive elements), which do nothing but carry the information from transistor to transistor, will control the timing.

In Chapter 7, we compare chip design from scratch with Soft IP and Hard IP reuse. We make this comparison by looking at design flows. It is already clear that layout information such as floorplanning and placement have to be largely known. Even a rough estimate of chip timing makes sense. Clearly, one key goal for high-level descriptions of design intent is to create as much coupling as possible between the front-end and the back end, such as timing driven floorplanning, placement, routing.

Simply put: The front-end, the Soft IP methodology, has to take care of the “big factors” for timing. The back-end, the Hard IP methodology, will take care of the “small factors,” the optimization of the timing. That is why integration of the two methodologies is of utmost importance.


The idea of moving existing chips lo newer technologies can be extended to combining several of them in one chip. Normally, working silicon chips that are part of the inventory of a company has been laid out in technologies based on many different design rule sets. These chips represent what was possible to place on one chip at the time they were designed. Through migration they will all be laid out according to a common design rule set. With the smaller minimum critical layout dimensions and the increase in the maximum chip size still resulting in acceptable yields today, several of these “old” working silicon chips now fit on a single chip. This, of course, is a perfect S-o-C scenario as is illustrated in Figure 1.2, a very powerful way to address today's design productivity crisis.

Fig. 1.2 The S - o-C System Design Becomes Reality

For the migration of several blocks or chips onto one chip, there is the S-o-C approach as shown in Figure 1.2, where the various components need to be interconnected on the new chip. We have to go through floorplanning and routing steps once the blocks to be migrated arc all placed on the new piece of silicon. Of course, the new chip might contain only some blocks that are reused through migration, while other blocks are new designs.

While the preservation of the relative timing discussed before still applies to each block migrated, the dominance of interconnects for timing of the new S-o-C solution due to inter-block routing will require a completely new timing analysis of the S-o-C solution. However, nothing has been lost in migration since timing existed only for the individual blocks before being migrated, and not for the fully integrated chip with the combination of all these blocks that is about to emerge.