Pre-publication excerpt from The Art of Good Design by Mike Keating (keating@synopsys.com) for review only.

Redistribution by permission only.

Chapter 1: The Challenges of Complex Design

The Problem
As semiconductor technology relentlessly pursues the path described by Moores law, the challenges of SoC design continue to grow dramatically. We are moving from chips with millions of gates to ones with billions of gates. The task of designing such complex systems is daunting. On the other hand, the basic design approach for digital design how we code Verilog or VHDL to describe complex functionality has remained largely unchanged in the last ten years. It is time to explore how to migrate our design methodology forward to meet the challenges of designing highly complex digital systems.

Divide and Conquer

Divide and conquer is the key tool for solving many complex problems. The effective design of complex systems relies on the same principle: the partitioning of the system into appropriately sized components and designing good interfaces between them. This book explores how to apply this fundamental technique to the design of complex hardware, in particular to SOC design. The process of designing complex chips is itself a complex system. In the early days, the IDM (Independent Device Manufacturers) model was common. A single company (such as LSI Logic in the 1980s) could have its own EDA tools, its own process, its own fab, and its own design teams. Today, this complex system has been partitioned into separate subsystems.

Copyright 2009 by Synopsys, Inc. All rights reserved.

Pre-publication excerpt from The Art of Good Design by Mike Keating (keating@synopsys.com) for review only. Redistribution by permission only.

EDA companies develop the tools to do design and provide them to the entire community. In general, design tools are simply too complex for design houses to develop on their own. Similarly, fabs have become too expensive for most semiconductor companies to build and maintain. Instead, independent fab houses such as TSMC, UMC, Chartered, and SMMIC specialize in manufacturing complex chips and in designing and maintaining the latest semiconductor processes. This repartitioning of the chip design process shows the basic principles of divide and conquer in action. When systems become too complex, it is more efficient to divide the system into several smaller components, and have a formalized interface between them. These interfaces are not free. Interfacing to an outside fab house is not trivial: the design files that one delivers to TSMC must meet TSMC's specifications and requirements. It also costs a significant amount of money to build chips at a commercial fab. But as the cost and complexity of fabricating chips rose, the cost of the interface became worthwhile. That is, TSMC (and others) hide the complexity of the manufacturing process from its customers and provide a relatively simple, formalized interface that allows designers to create chips without knowing the details of the manufacturing process. This decoupling effect is the key to good interface design. The partitioning of the system, and the design of good interfaces between its components, results in reducing a large, complex, flat problem into a set of small problems that can be solved locally. It decouples the complexity of one component from the complexity of another. The different tasks involved in digital design have also evolved over the years. In the late 1980s, synthesis was introduced, using tools to provide the optimization of digital circuits. In the 1990s, design reuse became a common methodology as chip designers realized it was more efficient to buy certain common components such as processors and interfaces and focus their design efforts on differentiating blocks. In recent years, the verification of complex IP and SOC designs has become so challenging that specialized verification languages and verification engineers have emerged as key components in the design process. Thus, the process of designing complex chips is continually evolving. At each step, we have addressed the increasing complexity of design by separating different aspects of design, so that each aspect or task can be addressed independently. RTL and synthesis technology allows us to describe circuits independently from a specific technology or library. Design reuse and IP allow us to separate the design and verification of complex blocks from the design of the chip itself. Recent improvements in verification technology have occurred as design and verification have become separate functions in the design team. This book outlines the most advanced techniques for using the divide and conquer as an approach to complex digital design. It also outlines some future directions for further partitioning of the problem, as we address the challenges of tomorrow's chip designs.

Copyright 2009 by Synopsys, Inc. All rights reserved.

Pre-publication excerpt from The Art of Good Design by Mike Keating (keating@synopsys.com) for review only. Redistribution by permission only.

The General Model

In general, then, the design of a complex system consists first of decomposing it into component parts. Figure XX show a cell phone as an example.

The phone contains a printed circuit board with a (small) number of key chips. The complex chips (SoCs) consist of a number of subsystems. Each subsystem consists of a number of IP. Each IP in turn consists of a number of subsystems or layers, and each subsystem consists of a number of modules. The module is the leaf level of this hierarchy. This is where the detailed design is done. It consists of HDL code describing the detailed function of the design. Note then that there are multiple levels of design: Product design (the cell phone) PC board design SoC design IP design

At each level of design, we decompose the design problem into a set of components. For instance, at the SoC design level, we define the functional units of the design and the IP we will use for each functional unit. Then we must compose these units into the system

Copyright 2009 by Synopsys, Inc. All rights reserved.

Pre-publication excerpt from The Art of Good Design by Mike Keating (keating@synopsys.com) for review only. Redistribution by permission only.

itself. That is, we need to decide how to connect the IP together (at the SoC design level) or how to connect the modules together (at the IP design level). At every level of design, this composition function consists of designing the interfaces between units. The design of these interfaces is one of the key elements in controlling the complexity of the design. For a good design, the design units (modules, IP, or chips) must be designed to have interfaces that isolate the complexity of the unit from the rest of the system. We will talk much more about this throughout the book. The general paradigm then is shown in figure XX.

Rule of 7
At any level of hierarchy, the number of blocks in the design is not arbitrary. In the 1950s, two psychologists (XX) published a paper called "The Magic Number Seven Plus and Minus Two". In this paper, they demonstrated that the human mind can hold seven objects (plus and minus two) at any one time. This is why telephone numbers (at least in the United States) are seven digits. We can remember seven digit phone numbers. We cannot remember 12 digit phone numbers. Similarly in any design, we can at any one time understand a design of up to seven to nine blocks.

Copyright 2009 by Synopsys, Inc. All rights reserved.

Pre-publication excerpt from The Art of Good Design by Mike Keating (keating@synopsys.com) for review only. Redistribution by permission only.

Compare the two block diagrams in figure XX. In the diagram on the left we see only five or six high-level components. It is easy to understand the major components of the system and how they are related to each other. In the diagram on the right, much more detail is shown. This makes it significantly more difficult to understand the general functions. When we look at the diagram on the right we tend to focus in on one subsystem the time, and try to understand what it does. Then we look at the larger diagram in front look at the general, high-level functionality.

This is a common problem in design. To design effectively, we need at any one time to be looking at only a small number of design objects. By doing so, we can think effectively about the (sub)system we are designing.

Tightly Coupled vs. Loosely Coupled Systems

Once we have partitioned the system or design into an appropriate number of design units, the key step is to design the interfaces between them. In general, systems can be considered to be one of two types, based on what kind of interfaces they have: tightly coupled or loosely coupled. Tightly coupled systems have interfaces that essentially connect the elements of the system into one single, flat unit.

Copyright 2009 by Synopsys, Inc. All rights reserved.

Pre-publication excerpt from The Art of Good Design by Mike Keating (keating@synopsys.com) for review only. Redistribution by permission only.

One example of a tightly coupled system is the weather. In 1961, Edward Lorenz (XX) was doing computer modeling of weather systems. He decided to take a short cut, and entered .506 for one variable, where earlier he had used .506127. The result was a totally different weather pattern. Later, he published a paper describing this surprising effect. The title was Does the flap of a butterflys wings in Brazil set off a tornado in Texas? His key discovery was that small, local effects can have large, global effects on the weather. This is typical of a tightly coupled system. Local causes can have global effects and local problems can become global problems. In SoC design, a tightly coupled system is one where the interfaces between units create such tight interaction between the units that they essentially become a single flat design. Thus, a change to any unit in the design may require changes to all the other units in the design. Also, fixing a bug in anyone unit may require significant changes to other units. A loosely coupled system, on the other hand, uses interfaces to isolate the different units in the design. An example of a loosely coupled system is a home video system.

Copyright 2009 by Synopsys, Inc. All rights reserved.

Pre-publication excerpt from The Art of Good Design by Mike Keating (keating@synopsys.com) for review only. Redistribution by permission only.

Although the DVD player, the set-top box, and the TV set are all very complex systems, the interface between them effectively isolates this complexity. The HDMI cable that connects the set-top box to the LCD display isolates the complexity of the set-top box from the display. The display does not need to understand anything about the internal behavior of the set-top box. All it has to do is understand the signals coming over the HDMI cable. More importantly, if the set-top box breaks, I can still use the DVD player. Local bugs or defects in the set-top box do not become global problems for the entire system. There are significant advantages to loosely coupled systems. But there are advantages to tightly coupled systems as well. Tightly coupled systems can be more efficient. This is one of the reasons they occur in nature so often. It is also one of the reasons why many design teams prefer to do place and route flat. The characteristics of a tightly coupled system are: they can be more efficient than loosely coupled systems they allow for global optimization less planning is required they are harder to analyze local problems can become global problems they can result in emergent behavior that is, big surprises Characteristics of a loosely coupled system are: they are more robust they support the design of larger systems they are easier to analyze

Copyright 2009 by Synopsys, Inc. All rights reserved.

Pre-publication excerpt from The Art of Good Design by Mike Keating (keating@synopsys.com) for review only. Redistribution by permission only.

local problems remain local they require more design and planning effort they produce more predictable results

One comment on the emergent behavior. The academic discipline of complex systems theory has devoted a lot of effort in studying naturally occurring tightly coupled systems. They study complex systems in biology, sociology, economics, and political science. They have found that complex (tightly coupled) systems frequently exhibit surprising and unpredictable behavior. This seems to result from the fact that it is not possible to analyze tightly coupled complex systems by decomposing them into components and analyzing the behavior of individual components. So much of the behavior of these complex systems resides in the interfaces, that any analysis of the system requires an analysis of the entire system as a flat entity. In highly complex systems, it becomes impossible to come up with a simple model that can be analyzed in simulated and get accurate results. One classic example of this is an anthill. The behavior of an individual ant is extremely simple. But an entire colony of ants can exhibit quite complex behavior, including complex strategies to locate and acquire food, complex strategies for defending the colony against invaders, and in extraordinary circumstances even moving the entire colony. There is no way one can predict this kind of behavior from an analysis of the individual ant. See (XX and XX) for more details. The lesson for designers of SOC's is that tightly coupled systems are much more likely to exhibit unexpected behaviors than loosely coupled systems. In particular, tightly coupled hardware systems are more likely to fail in unexpected and catastrophic ways than loosely coupled systems. Thus, one of the keys to the good design of SOC's is to make sure that they are loosely coupled systems.

The Challenge of Verification

One of the biggest challenges in digital design today is achieving functional correctness. As designs become larger and more complex, the challenge of functional verification has become extremely difficult. In particular, a number of new, sophisticated verification techniques have been added to the engineer's toolbox: constrained random testing, assertion-based testing, and formal verification. Unfortunately, these new techniques merely extend the previous trend in verification. We know that with more effort (and more sophisticated tools) we can find more bugs. But we have no useful model for how to find all of them.

Copyright 2009 by Synopsys, Inc. All rights reserved.

Pre-publication excerpt from The Art of Good Design by Mike Keating (keating@synopsys.com) for review only. Redistribution by permission only.

A quantitative analysis is compelling. There is little reliable data for bug rates in RTL code, but there is a very large amount of data on software quality. Since in both cases we are using code as a means of design, it is likely that we can extrapolate some useful information from the software quality studies. One software study (XX) shows that during coding, designers inject approximately 1 defect for every 10 lines of code. The process of compiling, reviewing, analyzing, and testing the code reduces this rate. For typical new code that has been well tested, a remaining defect rate of six to seven defects per thousand lines of code (KLOC) is common. The very best code from the most sophisticated teams can achieve one defect per KLOC (XX). With multiple uses in multiple products, and with extensive customer usage, this defect rate can be driven even lower. But as far as this author knows, no one has reported a defect rate significantly below .1 defect per KLOC in any large software program. It is likely that hardware teams commonly achieve the same kind of defect rate is the very best software teams. One reason for this is that hardware teams typically invest significantly more resources in verification and software teams do. But all the evidence indicates that any code base design of significant size will still have residual effects even after the most rigorous testing effort. As we build more and more complex chips, even very low defect rates such as .1 defect per KLOC can be a major problem. In fact, functional bugs are the largest single cause of chip respins (XX). For example: Consider a 50 million gate design. This corresponds to approximately 10 million lines of code. At .1 defect per KLOC, this means that the chip is likely to ship with 5000 defects.

Copyright 2009 by Synopsys, Inc. All rights reserved.

Pre-publication excerpt from The Art of Good Design by Mike Keating (keating@synopsys.com) for review only. Redistribution by permission only.

There are two primary strategies for improving the situation: reduce the number of lines of code lower the defect rate per thousand lines of code In this book, we will discuss design techniques for implementing both of these strategies by raising the level of abstraction in design.

The Pursuit of Simplicity

One key element in lowering the defect rate in RTL code is to make the code easier to understand. Even today, the most powerful verification tool in our toolbox is the human mind. Consistently, studies indicate the design reviews and code reviews are the most productive means of detecting bugs(XX). Today, most RTL code has been written with the primary goal of making it easy for the compiler (synthesis tool) to produce good results. However, this has often resulted in code that is difficult to understand. All of us have written code, only to come back to it months later and find that we have no idea what the code actually does. Unfortunately, code that is difficult to understand is also difficult to review and for humans to detect bugs. One of the goals of this book is to describe some techniques for simplifying RTL designs (by minimizing the state space) and to simplify the way this design is represented in the code itself. Whether we are building houses, bridges, networks, or complex chips, as the systems we build become more complex, their basic structure needs to become simpler and more regular.

The Changing Landscape of Design

Another reason for this pursuit of simplicity is that chip design has changed in a fundamental way over the last decade. A dozen years ago, it was possible for a single senior engineer to understand every aspect of the chip -- the overall architecture, what each module does, and how software interacts with it. In a finite amount of time, a single reviewer could read all of the RTL for a chip. Those days are gone. Today an SoC consists of many pieces of IP, often purchased from third-party IP providers. It also requires large amounts of software, from low-level drivers to high-level applications. The RTL for a complicated piece of the IP may be as large as an entire chip was just a few years ago. As result, no one engineer completely understands every aspect of an SOC design. No single human being could read all of the RTL for such a design. The design, verification, and debug a complex chip now requires an entire network of engineers. Copyright 2009 by Synopsys, Inc. All rights reserved. 10

Pre-publication excerpt from The Art of Good Design by Mike Keating (keating@synopsys.com) for review only. Redistribution by permission only.

As a side effect, during verification and debug, engineers are constantly dealing with code that they did not write, in which they may never have looked at before. They may not be experts on the bus protocols used on the chip or the interface protocols used in the I/O for the chip. Another way to look at this paradigm shift is this: in previous generations of design, chips were designed by teams of engineers. Now they are designed by a network of engineers. Managing this network is much more complex than managing a team. In this new model for chip design, there is a premium on simplicity: a simple, regular architecture, robust IP's that are easy to integrate, and code that is easy to read and understand.

Structure of This Book

Chapter 2 gives a brief overview of techniques for simplifying designs. Chapter 3 gives a detailed example of how to re-factor an RTL design to make it significantly less complex. It uses a control dominated design as the example. Chapter 4 discusses in more detail the concept of state space, and how to minimize it. Chapter 5 describes how the techniques described in previous chapters can simplify and improve verification. Chapter 6 gives another detailed example of simplifying code, this time with a data path intensive design. Chapter 7 describes how the design of module interfaces affects the complexity of the design. Chapter 8 continues the discussion in Chapter 7, and extends it to the IP and system level; it describes how to measure and minimize complexity of complete designs. Chapter 9 discusses the question of what techniques we can use with todays tools and languages, and what extensions we need to make in order to meet the needs of tomorrows designs. Chapter 10 describes the opportunities and challenges in using untimed models as synthesizable, executable specifications. Extensive examples are provided in XX.

Copyright 2009 by Synopsys, Inc. All rights reserved.

11