Engineering the CMOS Library E-Book

David Doman

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 754

Veröffentlichungsjahr: 2012

Beschreibung

Shows readers how to gain the competitive edge in the integrated circuit marketplace

This book offers a wholly unique perspective on the digital design kit. It points to hidden value in the safety margins of standard-cell libraries and shows design engineers and managers how to use this knowledge to beat the competition.

Engineering the CMOS Library reveals step by step how the generic, foundry-provided standard-cell library is built, and how to extract value from existing std-cells and EDA tools in order to produce tighter-margined, smaller, faster, less power-hungry, and more yield-producing integrated circuits. It explores all aspects of the digital design kit, including the different views of CMOS std-cell libraries along with coverage of IO libraries, memory compilers, and small analog blocks. Readers will learn:

• How to work with overdesigned std-cell libraries to improve profitability while maintaining safety

• How functions usually found in std-cell libraries cover the design environment, and how to add any missing functions

• How to harness the characterization technique used by vendors to add characterization without having to get it from the vendor

• How to use verification and validation techniques to ensure proper descriptive views and even fix inconsistencies in vendor release views

• How to correct for possible conflicts arising from multiple versions and different vendor sources in any given integrated circuit design

Complete with real-world case studies, examples, and suggestions for further research, Engineering the CMOS Library will help readers become more astute designers.

Leseprobe

CONTENTS

Preface

Acknowledgments

Chapter 1: Introduction

1.1 Adding Project-Specific Functions, Drive Strengths, Views, and Corners

1.2 What Is a DDK?

Chapter 2: Stdcell Libraries

2.1 Lesson from the Real World: Manager’s Perspective and Engineer’s Perspective

2.2 What Is a Stdcell?

2.3 Extended Library Offerings

2.4 Boutique Library Offerings

2.5 Concepts for Further Study

Chapter 3: IO Libraries

3.1 Lesson from the Real World: The Manager’s Perspective and the Engineer’s Perspective

3.2 Extension Capable Architectures versus Function Complete Architectures

3.3 Electrostatic Discharge Considerations

3.4 Concepts for Further Study

Chapter 4: Memory Compilers

4.1 Lesson from the Real World: The Manager’s Perspective and the Engineer’s Perspective

4.2 Single Ports, Dual Ports, and ROM: The Compiler

4.3 Nonvolatile Memories: The Block

4.4 Special-Purpose Memories: The Custom

4.5 Concepts for Further Study

Chapter 5: Other Functions

5.1 Lesson from the Real World: The Manager’s Perspective and the Engineer’s Perspective

5.2 Phase-Locked Loops, Power-On Resets, and Other Small-Scale Integration Analogs

5.3 Low-Power Support Structures

5.4 Stitching Structures

5.5 Hard, Firm, and Soft Boxes

5.6 Concepts for Further Study

Chapter 6: Physical Views

6.1 Lesson from the Real World: The Manager’s Perspective and the Engineer’s Perspective

6.2 Picking an Architecture

6.3 Measuring Density

6.4 The Need and the Way to Work with Fabrication Houses

6.5 Concepts for Further Study

Chapter 7: SPICE

7.1 Lesson from the Real World: The Manager’s Perspective and the Engineer’s Perspective

7.2 Why a Tool More Than 40 Years Old Is Still Useful

7.3 Accuracy, Reality, and Why SPICE Results Must be Viewed with a Wary Eye

7.4 Sufficient Parasitics

7.5 Concepts for Further Study

Chapter 8: Timing Views

8.1 Lesson from the Real World: The Manager’s Perspective and the Engineer’s Perspective

8.2 Performance Limits and Measurement

8.3 Default Versus Conditional Arcs

8.4 Break-Point Optimization

8.5 A Word on Setup and Hold

8.6 Failure Mechanisms and Roll-Off

8.7 Supporting Efficient Synthesis

8.8 Supporting Efficient Timing Closure

8.9 Design Corner Specific Timing Views

8.10 Nonlinear Timing Views are so “Old Hat” . . .

8.11 Concepts for Further Study

Chapter 9: Power Views

9.1 Lesson from the Real World: The Manager’s Perspective and the Engineer’s Perspective

9.2 Timing Arcs Versus Power Arcs

9.3 Static Power

9.4 Real Versus Measured Dynamic Power

9.5 Should Power Be Built as a Monotonic Array?

9.6 Best-Case and Worst-case Power Views Versus Best-Case and Worst-Case Timing Views

9.7 Efficiently Measuring Power

9.8 Concepts for Further Study

Chapter 10: Noise Views

10.1 Lesson from the Real World: The Manager’s Perspective and the Engineer’s Perspective

10.2 Noise Arcs Versus Timing and Power Arcs

10.3 The Easy Part

10.4 The Not-So-Easy Part

10.5 Concepts for Further Study

Chapter 11: Logical Views

11.1 Lesson from the Real World: The Manager’s Perspective and the Engineer’s Perspective

11.2 Consistency Across Simulators

11.3 Consistency with Timing, Power & Noise Views

11.4 Concepts for Further Study

Chapter 12: Test Views

12.1 Lesson from the Real World: The Manager’s Perspective and the Engineer’s Perspective

12.2 Supporting Reachability

12.3 Supporting Observability

12.4 Concepts for Further Study

Chapter 13: Consistency

13.1 Lesson from the Real World: The Manager’s Perspective and the Engineer’s Perspective

13.2 Validating Views across a Library

13.3 Validating Stdcells across a Technology Node

13.4 Validating Libraries across Multiple Technology Nodes

13.5 Concepts for Further Study

Chapter 14: Design for Manufacturability

14.1 Lesson from the Real World: The Manager’s Perspective and the Engineer’s Perspective

14.2 What is DFM?

14.3 Concepts for Further Study

Chapter 15: Validation

15.1 Lesson from the Real World: The Manager’s Perspective and the Engineer’s Perspective

15.2 Quality Levels

15.3 Concepts for Further Study

Chapter 16: Playing with the Physical Design Kit: Usually “At Your Own Risk”

16.1 Lesson from the Real World: The Manager’s Perspective and the Engineer’s Perspective

16.2 Manipulating Models

16.3 Added Unsupported Devices

16.4 Concepts for Further Study

Chapter 17: Tagging and Revisioning

17.1 Lesson from the Real World: The Manager’s Perspective and the Engineer’s Perspective

17.2 Tagging and Time Stamps

17.3 Metadata, Directory Structures, and Pointers

17.4 Concepts for Further Study

Chapter 18: Releasing and Supporting

18.1 Lesson from the Real World: The Manager’s Perspective and the Engineer’s Perspective

18.2 When Is Test Silicon Needed for Verification?

18.3 Sending the Baby Out the Door

18.4 Multiple Quality Levels on the Same Design

18.5 Supporting “Bug Fixes”

18.6 Concepts for Further Study

Chapter 19: Other Topics

19.1 Lesson from the Real World: The Manager’s Perspective and the Engineer’s Perspective

19.2 Supporting High-Speed Design

19.3 Supporting Low-Power Design

19.4 Supporting Third-Party Libraries

19.5 Supporting Black Box Third-Party IP (Intellectual Property) Design

19.6 Supporting Multiple Library Design

19.7 Concepts for Further Study

Chapter 20: Communications

20.1 Manager’s Perspective

20.2 Customer’s Perspective

20.3 Vendor’s Perspective

20.4 Engineer’s Perspective

20.5 Concepts for Further Study

20.6 Conclusions

Appendix I

Appendix II

Appendix III

Appendix IV

Index

Copyright © 2012 by John Wiley & Sons, Inc. All rights reserved.

Published by John Wiley & Sons, Inc., Hoboken, New Jersey

Published simultaneously in Canada

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, [phone], fax [phone], or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, [phone], fax [phone], or online at http://www.wiley.com/go/permission.

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.

For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at [phone], outside the United States at [phone] or fax [phone].

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com.

Library of Congress Cataloging-in-Publication Data:

Doman, David.

Engineering the CMOS library : enhancing digital design kits for competitive silicon / David Doman.

p. cm.

ISBN 978-1-118-24304-6

1. Digital integrated circuits—Design and construction. 2. Metal oxide semiconductors, Complementary. 3. Industrial efficiency. I. Title.

TK7874.65.D66 2012

621.3815—dc23

2011043303

Preface

In many ways, it is correct to view engineering as an inexact science. Yes, as with mathematics and the hard sciences, there is often a need for proofs and exacting arguments. HOWEVER, there is often, also, the need to produce, in a timely manner, just enough. That is to say, there are circumstances when a “sufficient” solution today is better than a “perfect” solution tomorrow. This mind-set is often the case for integrated circuit design, in general, and for stdcell IP design, in particular. As just one example, a classical way of implementing a flip-flop that has the added functionality of both an “asynchronous set” and an “asynchronous reset” is to add just enough circuitry to the flip-flop for each of those two additional functions to operate independently. Doing so assures a minimal sized stdcell in both net-list size and in layout area. However, it means that the flip-flop operates un-tractably when the controls for those two asynchronous functions are operated together. This especially causes issues if the control signals are de-asserted simultaneously. Dependent on the race between the two control signals, operating in a real world parasitic environment, such a flip-flop might settle either into a “set” configuration, or into a “reset” configuration, or into a nonsensical combination of those two states, or even settle into some meta-stable oscillation mode. The “perfect” solution would be to define a flip-flop circuit that assures some a priori tractable resolution in such an event. That means added transistors to the flip-flop design, further meaning that the flip-flop is larger, probably slower, and definitely more power hungry. In addition, while the addition of such circuitry can certainly reduce the chances of the cell going into some improper operation upon the simultaneous removal of both asynchronous signals, it cannot totally eliminate the chance of this occurring. Therefore, since the “perfect design” produces a larger, slower, more power hungry device and one that is doomed to failure anyway, the “sufficient design” is just to use the minimal circuit additions and to note, in a release document, that the flip-flop operation is not guaranteed under such conditions. This assures a smaller, faster design and allows the user of the flip-flop to develop proper control over the signals that operate the two asynchronous functions (or to ignore the warning at the user’s own risk). In other words, the stdcell library designer should trust that the integrated-circuit designer is competent to do his/her job.

While it might be the concerted wish of the integrated-circuit design community that the typical stdcell library (or other IP) offerings that they might be required to use in their design work is of the “perfect” mode, it is far more likely, and even desirable, for those offerings to be of the “sufficient” mode. The knowledge of the existence of the inexactitudes in those “sufficient” mode libraries, the ability to spot where in those libraries such inexactitudes might be, and the ability to take advantage of those inexactitudes in order to produce smaller, faster, cheaper designs, is the underlying cause for the writing of this book. This book is based on personal experience gained while producing stdcell libraries, for multiple companies, both on the integrated-circuit design side and on the IP development side, for technology nodes ranging from 1.25um in the early 1980s to 14nm today. Along with this being a textbook, I believe that it holds grains of wisdom for the integrated-circuit design engineer, the IP or stdcell-library supply engineer, the IP maintenance engineer, the EDA engineer, and the first line managers of all of those realms of engineering. Enjoy.

ACKNOWLEDGMENTS

I gratefully acknowledge the assistance of the many people who have had a hand at allowing me the chance to write this book.

First, I have had the pleasure of knowing Bernard Goodwin, a technical editor, for more than 10 years. I met him as he was finishing the publication of a book written by a co-worker of mine at the time, and I mentioned that I might have an idea for a book. Bernard took the opportunity to challenge me to flesh out the idea. At the time, I little realized that it would take me all of those 10 years to accomplish that fleshing out. Each year, at the Design Automation Conference (DAC), I would make the trip over to the Prentice-Hall booth and tell Bernard that I was still thinking. He never gave up on me. Finally, in November 2009, I decided that I was going to have to start the writing of the book soon or I would never finish and would always look backward wondering why. I contacted Bernard, told him that I was going to send him the first couple of chapters by the end of the year. Based on this, Bernard rounded up a few reviewers and the effort got underway.

After I delivered these first two chapters, Bernard took them to the reviewers: Thomas Dillinger, Faizul Alum, Don Bouldin, and especially Charles Dancak. Their reviews, although sometimes painful to read, were of incredible value to me. I have taken their advice and made many changes as a result. In my opinion, this book is the better because of their advice. Hence, second to Bernard, I would like to thank these four gentlemen.

Third, and most important, I should like to thank my wife, Susan, for putting up with me during my engineering career. She always listened to me explain, repeatedly, how the experiences that I was having at the various companies I worked at would be good fodder for an engineering book. Further, she listened to me as I lamented at not working on that very same book for the past 10 years. Finally, she stood by me as I decided to push through the effort. Susan, I could not do this without you.

Finally, I thank the senior-level management at my last company for giving me the time to write this book and the incentive to get off the starting line and actually do it.

Bernard, Thomas, Faizul, Don, Charles, Susan, and everybody else whom I have forgotten, thank you!

CHAPTER 1

INTRODUCTION

In a positive sense, this book is about gaining a competitive edge in the integrated circuit marketplace. What it will suggest to the reader is that there is unrecognized value hidden in the safety-net margins that exist in the various descriptive views of any piece of intellectual property. This hidden value, which might be useful on any given integrated circuit design, can normally be left “on the table.” However, this hidden value can and should be used by the aggressive design engineer (or manager) to beat market competitors. The pages ahead will reveal how the typical design house can enhance the performance, reduce the power, and improve the density of standard-cell logic. It will show how to add value to the generic, foundry-provided standard-cell library that many companies use “out of the box.” It will identify low-risk opportunities where aggressive designers and managers can shave off margin from overdesigned standard cells.

However, the other side of the preceding is also true. That is to say, this is a dangerous book. The reason it is dangerous is that no engineer or manager has ever been fired because of not following the herd and either accomplished or failed to accomplish exactly what any other engineer or manager accomplished or failed to accomplish. The not-so-hidden message of this book is that by breaking from the herd and attempting to use that safety net margin, wherever it is found, the results, when successful, will reap market benefit. The dangerous downside of this activity, however, is the risk of taking a little too much of the perceived margin and actually forcing a failure on silicon. The cost of such aggressiveness could easily be career limitations. Now, before you put this book back down, let me point out that taking advantage of such margin is not a new idea. In fact, it is rather old and it used to be rather common for the design engineer to take advantage of it. It used to be called “adding value” by not doing it the same way as everybody else. However, over time, as the cost of development of integrated circuits and the market cost of failure of those integrated circuits have increased, this concept has been replaced by “how not to mess up” by doing it the same way as everybody else. The result is that most integrated circuits are now designed in an extremely conservative manner.

About twenty years ago, as of the writing of this book, I was working for a microprocessor design company in the data communications integrated circuit design center. At that time, the design center was working on some Fiber Distributed Data Interface (FDDI) devices. During the development of some of those integrated circuits, I was asked if it was possible to decrease the cost by reducing the number of layers that the router that was being used on that particular design could use. Specifically, the design center was using a near-first-generation sea-of-gates router, and I was asked if it were possible to route the design as a channeled route using the sea-of-gates router that was available. I told the design manager that I could do channeled routing with the sea-of-gates router but that the sea-of-gates router was not a channeled router. My answer perplexed the design manager until I told him that you can use a wrench to hammer a nail into a wall, but that does not make a wrench a hammer.

The preceding illustration is what this book is basically about. Too often in the current world of integrated circuit design, we look for the perfect hammer in order to drive the perfect nail into the perfect wall exactly as the hammer and nail and wall manufacturer has instructed us. This is the previously mentioned safe “I won’t mess up” follow-the-herd method of integrated circuit design. However, doing that will mean your results will be exactly like the results of the competing design center that set up shop down the block. This book is about looking for the ways of using the tools that we have in creative ways. It is about using the wrench because the hammer is too expensive. It is also about using the hammer—but in ways that the design center down the block will not.

What this book is not about is device physics. You will not find any physics-based or electronics-based equation anywhere in it. There is no consideration herein about ion currents or oxide thickness. There already are more than enough books available on all of those subjects (and others as well). Rather, this book explores the everyday considerations of the library design and support engineer. That library design and support engineer may be in a specific library function in a separate organization or be a design engineer who is integrated within the design center that is using the library that is under consideration and is doing exploration of the library as an additional function to his or her regular design activities. This book is meant to be used as an instigator of thought. As mentioned, there are no physics or electronics equations in this book (although there are a few Boolean logic equations). Indeed, I have taken the tack of explaining in either words or illustrations as opposed to hard physics. An outcome of this book should be that design centers might push technologies and libraries in ways that the fabrication houses might be nervous about but that would (or should or could) be covered sufficiently through the validation and verification efforts of the design centers to be rendered viable.

A digital design kit, sometimes referred to as a DDK, is a collection of small-scale functions together with the various views that describe these functions for various process, design, and test (and other) tools. They are used by design-center engineers to design modern application-specific integrated circuits (ASICs) that can be processed successfully in the external fabrication house that supplied the original digital design kit.

In a sense, a DDK can be thought of as a collection of various bricks, each brick different, together with an assortment of descriptions of each type of brick that allows them to be placed together in such a manner as to further allow somebody to build a structure. Another way of looking at a digital design kit is as an alphabet, together with the rules of usage of this alphabet for word and sentence construction that allow somebody to write a book. In either of these two cases, the bricks or the alphabets, if you can keep your supply separate from those available to anybody else, then you can build either a unique structure or better book. Otherwise, if you can somehow adjust your bricks or alphabet in a manner not available to others, you can still build the better structure or write the better book.

For some design centers—those that belong to companies that have their own fabrication facilities—these DDKs can be viewed as private in-house tools that are not available to design centers for competing companies. This is good because it allows the company to adjust the fabrication and hence the views of the digital design kit in ways that generate a competitive advantage for their designs over those of competing companies. For many or even most companies around today, however, this is not the case. These “fabrication-less” companies subcontract the processing of their designs to external fabrication houses and have no real control of the processing at the external fabrication houses and must accept the process “as is”—unless they are willing to pay significant pricing and significant time and engineering resources to convince the external fabrication house that it is worth their time and effort and cost to allow special handling of the design centers designs. As a result, few such design centers are willing to expend the energy to do so. Hence, the DDK they use to do their designs is the same DDK that the next design center down the street is using. These design centers end up using the digital design kit “straight out of the cellophane” with no adjustments.

There are advantages for having common views and tools, such as the ability to hire workers already familiar with such tools and views. However, the real result of this is that if two or more such companies decide to do the same sort of design for the same market while using the same digital design kit, they tend to produce nearly the same design. This is further forced because most design centers use the same Engineering Design Automation (EDA) tools or at least very similar ones. Yes, there may be Input-Output Structure (IO) order differences, perhaps scan-chain differences, and the embedded software might have been written somewhat differently, but these are all secondary to the fact that the two or more competing designs will be all roughly the same size, have the same cost to produce, and have the same power, all assuming they have the same features. The companies are then forced to compete in the market on price margin alone.

Now from the external fabrication house’s point of view, it is advantageous to force common design practices across the ASIC design industry. These houses have developed business models that allow them to operate profitably by accepting ASIC designs that are produced by design centers that used their DDKs. These business models basically say that if the design customer used the digital design kit “as is” and the EDA tools in conjunction with these digital design kit files (assuming the design works), then the design will come out of the external fabrication house working or the external fabrication house will pay for it. Conversely, if the design customer decides to not use the digital design kit “as prescribed by the external fabrication house” but instead uses it with some changes and the resulting design does not work, then it is the design customer’s fault and the external fabrication house has no fiduciary responsibility. Clearly, it is the external fabrication house’s best interest to have solid DDKs. How can they do this? The easiest way is to allow margin in the various views of the kit, in effect making those views “bulletproof.” Worst-case timing views are slightly slower, and best-case timing views are slightly better than expected. Worst-case power and best-case power views are guard banded. Similarly, for logical views, the external fabrication houses do not allow proper simulation of some actual although nonstandard functionality. In the end, view after view is a little worse performance or a little less functionality per model than would otherwise be expected. They are all “margined” to one degree or another.

However, this added margin is precisely what the design-center customer wants to have removed or, at a minimum, transformed. This removal would allow the design-center customer to compete in the market not on price margin alone, but on power, performance, or size, the first two of which can be viewed as feature additions and the last of which enables profitability even in a price-margin-alone environment. The transformation of the margin from something that is decreed by the fabrication house into something that can be controlled and potentially proportioned by the design-center manager allows judgment calls to be made. If there is no performance or area penalty, for instance, then such margin additions could be added back into the calculation without harming its competitive position in the marketplace. Contrarily, if the penalty is too large, it can be at least partially minimized to the extent required to allow sufficient cost-margin savings, again allowing the resulting finished device to be cost competitive in that same marketplace.

This book describes areas where the margins in the views can be found and how to determine their extent and how extensively these margins can be safely removed.

Wait, you might be thinking. I just said that actually doing this “margin removal” (or any “margin transformation”) could cause the fiduciary burden to be shifted to the design-center customer. Yes, that is true. However, in the perspective of the business model of the design-center customer, the extent of the risk may be worth it. This is not a technical decision, but rather a financial decision. Control of that financial decision, as determined by the amount of margin removal that is being considered, is thus moved to the realm of the design-center manager. This book should give the designer-center manager that knowledge needed to make those decisions.

One additional comment: just because a little medicine might be good for you, more is not necessarily better. That dictum is also true in engineering. Use this book at your own risk. Many of the techniques on margin reduction listed herein are as dangerous as they may sound, and proper caution needs to be taken when partaking in many of them, otherwise the design center that you support may start to produce nothing more than expensive sand.

Now, before going to much further, I do have one apology to the reader. As I review this book, I find that I often use “negative language” (for instance, “if one doesn’t do something, and as a result, something doesn’t happen, then . . . .”). I apologize. Nearly three decades in developing CMOS logic libraries, where the common function always involved an inversion (or NOT function) has trained my mind to think in that manner. I hope, however, that the average reader involved in the industry does not find this “negative” language any more awkward than I do.

1.1 ADDING PROJECT-SPECIFIC FUNCTIONS, DRIVE STRENGTHS, VIEWS, AND CORNERS

Beyond what the previous section says about margin removal (or margin adjustment), this book has a second goal: to allow adding items to a digital design kit in order to personalize it.

A specific digital design kit probably comes from the external fabrication house with three sets of timing and power views (abbreviated as PVT for “process corner, voltage corner, temperature corner”). These three PVT probably correspond to one worst-case processing corner, one best-case processing corner, and one typical processing corner. If the design center has a different market niche that requires a different set of voltages of operation or environmental temperatures, or if it is willing to accept slightly less or slightly more processing variation, then it has to pay the external fabrication house perhaps several hundred thousand dollars to generate and support such new PVT timing or power views. This book should allow the design center the knowledge of what it takes to make such a PVT characterization on its own. With that knowledge, the design center should be better equipped to make the decision whether to buy a new PVT from the external fabrication house, “make” it internally (with the business benefits but support cost of doing so), or “reengineer” the market decision such that it becomes unnecessary.

A specific digital design kit will have a limited number of logical functions, although that number might be very extensive. If the design center has identified some special function that is not easily built by the logical functions present, it might choose to add that function by means of a custom design. The external fabrication house may have the ability, assuming that the design center goes forward with the design, to say that the fiduciary responsibility for the design moves to the design center if this new function does not work but remains if the fault is the result of some other part not being modified by the design center. This may seem bad for the design center, but it is the model of many of them. These centers have specific “special functions or logic” that they have used repeatedly in the past. These special functions or logic are considered to be a competitive advantage for those design centers with such logic. They are in business specifically because they have such functional or logic blocks. This book tells the design center how they can better add such functionality within the external fabrication house’s DDK framework.

A design center may determine that it can build a smaller, faster, or less-power-consuming design if it had access to the functions supported by the digital design kit, but it requires a slightly larger or slightly smaller version of a function (in terms of area of performance or power). If this slightly adjusted cell is a larger version of one that is already present, then the design center might be tempted to parallel up multiple copies of the function. If the slight adjustment is to make it smaller, actual trimming of transistor widths might become needed. This book will discuss the possible means of doing so safely.

A design center might use an EDA tool that is not supported by views delivered from the external fabrication house. Although this book will not explain how to develop such views, it will give the design center the knowledge of how to ensure that design-center–generated views are consistent with the views that are delivered by the external fabrication house. It will also describe the efforts needed to deliver and support such views across multiple designs and view and tool updates.

The bottom line is that even though some people see the DDK as cast in stone, the design center that is willing to extend or adjust such kits can deliver better designs (i.e., cheaper to produce, test, or support). These designs will allow those design centers to compete in their chosen markets on more than just commodity (i.e., price-margin) techniques. This book will allow the engineers and managers of those design centers additional degrees of freedom in making the decisions to extend and adjust such digital design kits.

1.2 WHAT IS A DDK?

A digital design kit is a collection of physical views of certain functions that a fabrication house is capable of processing at a given technology node. Coupled to this are the other physical (read place and route) views as well as the logical, temporal, power, noise, and test views that represent these various functions for (usually some, maybe most) of the various engineering design automation tools available on the market. Moreover, the typical DDK release will be for what has become known as a “Frankenstein” flow, with Cadence logical and LEF (library exchange format) views and Synopsys timing, power, and noise views and supported in the physical design kit (PDK), by Mentor verification decks, although there are exceptions to each instance, with Cadence, Synopsys, and Mentor being “the big three” EDA companies. These views are supplied by a fabrication house where any resultant design that uses these supplied cells and views will be processed. Some of these views can be adjusted, assuming knowledgeable guidance, with a fair amount of impunity from the fabrication house, while other views are touched with less impunity, even by the design-center experts. These views differ from and need to remain consistent with the decks and views in the PDK that also comes from the fabrication house.

More specifically, at the very minimum, a DDK will contain the following.

Graphical Database System Stream-file format (GDS) (physical), which are views of one or more standard cell (stdcell) libraries, usually including IO-specific libraries, which can be used on designs that are destined to be processed in a particular fabrication house. These views are a binary format, viewable in any one of several GDS viewers. ASCII based human readable formats of GDS can be created through various EDA tools.Gate-level SPICE (simulation program with integrated circuit emphasis) netlist of each cell in the various libraries, SPICE being a cross between a physical view (which it represents) and a simulatable view, which is one of its two major purposes, and a verification source, which is its other major purpose. SPICE is ASCII based and easily human readable.Some further physical representation (possibly a physical LEF, an ASCII-based and human-readable description of the place and router pertinent parts of the GDS). This further physical representation is used by automatic place and route tools, in conjunction with a logical LEF, usually part of the PDK that contains information on layer definitions that the router can use during design place and route.Timing, power, and noise views, which are typically but not necessarily referred to as liberty files, a name that comes from the extension that is most often used (“lib”) on versions of these ASCII files that were originally purely for Synopsys tools. Being ASCII, they are easily readable. More so, most liberty writers tend to output highly structured versions of the format, which further aids human understanding on reading. The Backus-Naur Format (BNF) for these files have since been “open sourced”—that is, they can usually be read and understood by most EDA timing tools. One aside: Synopsys has not frozen the BNF for its liberty files and thus care must be taken with every new Synopsys release in order to keep previous versions of liberty files from becoming antiquated.Logical and test views, typically being slightly adjusted versions of the same logical format, but with one geared toward aiding logical simulations and the other geared to representing actual internal nodes of a stdcell (or IO) function that allows for accurate tracking of “reachability and observability” for internal fault tracking. These views may come in one or both of two major logical tool formats (Cadence’s open-source VERILOG file or IEEE’s open-source VHDL format). They are both ASCII based and human readable.There may be other views, especially white papers, verification or validation documentation, and release-tracking documents, all in some form of human-readable format.Sometimes other, more EDA-tool-specific views can also be included.

Along with the preceding major views, support for special tools may be added to a DDK release by a fabrication house. These tools can include RAM/ROM memory compilers. Once installed on a system, RAM/ROM memory compilers, at the press of a few buttons, automatically generate all of the preceding formats for a specific RAM/ROM configuration supported by the fabrication house. The timing, power, and noise view is initially a machine-estimated version. Typical fabrication-house vendors, however, offer the option of characterizing the specific RAM/ROM in order to allow cleaner design closure of a design that uses that specific RAM/ROM, and these fabrication house usually offer this either free or for a small fee.

The reason that RAM/ROM compilers exist as opposed to a long list of usable RAM and ROM instances is that there is such a larger list of possible combined number of words, bits, and column-multiplexer (MUX) instances that could be chosen by design teams, all of which would therefore otherwise need to be supported.

Finally, there may be certain specific circuits (or analog subcircuit pieces, such as various layer resistors of multilayer capacitors or diode or PNP or NPN structures that can be used to build analog function in the particular technology node and in the specific fabrication house). Some of these, which are dependent on the technology node, will be custom and uneditable or only marginally editable structures (the more complex and deep the technology node, the more likely that this is so). Some will be just Boolean layer definitions. Most will have rather pared-down subsets of the previously mentioned views, just enough to allow some amount of simulation (usually in SPICE) and design-level verification (including netlist capability).

Now how extensive can any of the preceding be edited? It depends on the technology node and the desire of the design center. Deeper technology nodes will tend to have stricter requirements for the physical views than higher technology nodes. The real reason for this is that as geometries get smaller, they tend to go from drawn silicon shapes being transferred to the mask through lithographic treatments such as serifs at corners of polygons through optical-proximity correct techniques, through phase shifting, and to exact set widths and spaces. For the deepest technologies, what is drawn on the mask can bear little visible relation with what is desired on silicon. In those instances, the operative order is “Don’t touch.” Trust that the fabrication house understands better than the design team what certain polygons need to be, where they need to be, and why they need to be. However, for the higher nodes, even those in the 90-nanometer range, which includes some phase-shifted mask and some strong optical-proximity correction, it is worth pursuing with the fabrication house when a question on a physical view arises. For higher technology nodes than that, there is a good chance that you can find optimizations that the fabrication house has left “on the table.” In addition, it is highly advantageous at these higher technology nodes to attempt to do just that. The reasoning is that these nodes have been “in the marketplace” for such a long time that every design house that wants to compete in a market will have access to the same generic package. Assuming that all design centers make the same decision on technology node (which is a valid assumption given that they would be privilege to the same marketing information), they will produce roughly the same size product in the same rough timeline. This means that the design centers will be competing on price alone. Having a “pushed” technology might just be the edge needed to undercut the opposition in such an environment. As far as the logical and timing views are concerned, we will discuss them later in the book, but even at the deepest technology nodes the fabrication house has generated “loose” views that a design team can beat and thereby find additional margin over the competition.

CHAPTER 2

STDCELL LIBRARIES

2.1 LESSON FROM THE REAL WORLD: MANAGER’S PERSPECTIVE AND ENGINEER’S PERSPECTIVE

Back when all logic design was accomplished by generating hand-designed schematics, it used to be said that once you became familiar enough with a certain logic designer’s style, you could tell which schematics where done by that person versus which were done by other logic designers. In effect, just as is the case with classical painters and their paintings, each designer had a brush stroke that was all his or her own. Each logic designer was an artist in the field of logic design, admittedly some more than others.

Although the ability to see this artistry in an Register Transfer Language (RTL) netlist might be lessened because of the structural requirements of the RTL combined with the design-center restrictions on techniques, it is still sometimes observable in the resultant synthesized netlist that came from the original RTL. A netlist from some designers will have a different ratio of inverters to flip-flops or a different mix of Boolean functions or any of a number of other telltale fingerprints that would allow the seasoned observer to say one netlist was produced by one logic designer while somebody else produced another—that is, if the stdcell library is rich enough to allow such subtleties to arise.

A couple of years ago, a design center asked why I produced such large stdcell libraries. Typically, that design center would purchase a 350–450 cell library and be relatively happy. My usual deliveries were 650–850 cells. There were so many that the design team was lost in the details and could not figure out which cells they would remove. Because they had experience with successful using previous and much smaller libraries, they knew that my offering was redundant overkill. They specifically asked me, as their supplier, if I could pare the offering down to just those typical stdcells that would be commonly needed. Because I had previously guaranteed that no complex stdcell function in my offering could be done in a smaller, faster, or less-power-consuming fashion by combining two or more other functions (with the possible exceptions of the full-adder and half-adder functions that I mention later in this chapter), I told them that the stdcell set was minimal. It was just more exhaustive in terms of functions than most commercial offerings. Because they had previous experience with a “more compact” library, I was told to prove it. We took a dozen or so functional RTL blocks that the design center had used over several previous technology nodes and proposed to test my hypothesis by synthesizing with a subset of the library picked by the design-center manager and again using a full set of my functions. We would look at synthesis time and resultant gate area as a function of performance for each RTL block. For block after block and frequency target after frequency target, the two versions of the library produced netlist that where within a percent or two of each other, sometimes with the pared-down library producing the better and sometimes the full library producing the better of the two. In most cases, the pared-down library would reach timing closure in minutes whereas the full library took two or three times as long. As the performance target kept getting greater, the sizes of the resultant netlist would hit asymptotic performance limits as illustrated in Figure 2.1.

FIGURE 2.1 Showing the Asymptotic Nature of Performance Limits of Libraries and Technologies. For many applications that do not stretch the limits of a library’s abilities, the ability of the library to achieve closure (in terms of time or density or power) is not significantly different from any other library. Only at the extreme edges of the ability of libraries do they show dramatic differences during design closure. Typically, such extreme limits are not nearly the same limits of other libraries designed for other design goals, although they are shown here to be nearly coincident.

Typically, these asymptotes were within a percent or two of each other for a given block for the two versions of the library. It looked as if the pared-down library was just as effective as the larger full version, and the synthesis time was half or less for the pared-down version as opposed to the full version. It should be noted that as these asymptotes were approached, the “time to closure gap” tended to close, but this was faint praise for the full library if there was no real benefit until the very edge of the performance envelop was hit. I held my ground, but the design center was about to force me to give them what I knew to be an inferior stdcell library offering. Then we started the exercise of synthesizing a complex communication channel. It had both complex state machines and some significant arithmetic logic units in it, but these were not overly complicated as compared with many modern designs. The full library synthesized the netlist across the performance targets chosen in anywhere from 25% to 40% the time that the pared-down library did. The full-library asymptote was about 15% higher than the pared-down version. In addition, the netlists for the full library were on average 85% the area, at the same performance, as the pared-down library results. We had met the RTL writer whose output needed the full-library offering.

The bottom line—you will not need much of the following function list for your designs—that is, unless you do need them. In addition, you will not know a priori when you will run up against that need.

2.2 WHAT IS A STDCELL?

Standard cells, or stdcells for short, are the building blocks of the modern ASIC world. They can be thought of as the alphabet that allows the ASIC designer (or ASIC design team) to write the novel (that is, design the ASIC). They consist of several simple (in general) functions, usually in various strengths, that can be (potentially repeatedly) connected together in a network and then patterned on a piece of silicon, such that the result is a desired functional integrated circuit. Digital design kit (DDK) vendors, most often representing fabrication houses, usually offer them in a family of several hundred of the various functions and strengths. A sample of a synthesized circuit and a corresponding layout representation of a few stdcell are shown in Figure 2.2. Note that the relative areas of the various elements in the placed row of are valid, NANDs and NORs are larger than INV (the NOT in the example), and FLIP_FLOPs (relative sizes DFF in example) are larger still.

FIGURE 2.2 A Small Circuit of Stdcells and a Possible Layout of Same in a Single Row. Note that the relative sizes of the rectangles that represent the actual physical views of the various elements in the circuit are fairly close to actual ratios for those functions. Also note that the cells are not necessarily placed in any given order similar to the logic circuit.

The actual choosing of which stdcells in a family to use in a design and the actual placing of these at various locations on a piece of silicon, both of which can be done manually, is usually done by software provided by various engineering design automation (EDA) vendors.* These various software tools, as mentioned in the previous chapter, work with representative aspects of the various stdcell that are pertinent to the particular software’s requirements in order to perform properly their specific function.

Another type of placeable family structures that can be used to design and build integrated circuits (gate-array cells) exists and there is a continued market for them (field-programmable gate arrays), but they remain a niche market and will not be covered in this text.

Before we investigate the subject any deeper, it will be beneficial to understand that the actual stdcell layouts, as represented by the various rectangles in Figure 2.2, are DDK view. Although most DDK views are ASCII based (English readable), the layout is graphical. As an example of what a typical layout may look like, the inverter (the NOT in the figure) might resemble something like that shown in Figure 2.3. The clear rectangle surrounding the shapes in the figure can be described as the stdcell outline. Although there may be shapes associated with the stdcell that extend beyond the rectangle (such as the NWELL), that rectangle represents the regular placeable structure of the stdcell. Such rectangles (or cell outlines or boundaries) are of consistent height (or multiples thereof) and consistent width (or multiples thereof). Other, more complicated stdcells will have more P-channel and N-channel transistors within their cell boundaries, but those cell boundaries will always be of given multiples of the basic stdcell boundary height and width. This feature allows them to “stack” in both the horizontal and vertical grid on a chip during place and route.

FIGURE 2.3 Inverter (NOT) Circuit. The INV circuit given in Figure 3.6 might be arranged as above. The P-channel transistor at the top of the circuit is produced by the polysilicon crossing the P-doped active at the top of the cartoon. The N-channel transistor is produced by the polysilicon crossing the N-doped active at the bottom of the cartoon. It should be noted that the NWELL in which the P-channel transistor sits requires a connection to the power rail (or to some other voltage in one of the low-power applications mentioned later in the book), and the substrate in which the N-channel transistor sits requires a connection to the ground rail. Some technology nodes allow for such connections within the stdcell, and some technology nodes allow them outside of the stdcell.

2.2.1 Combinational Functions

2.2.1.1 Single Stage

The leading EDA synthesis tool over the last two decades, Synopsys’s Design Compiler, requires at least one storage element, one inverting element, one combining element, and one tri-stating element (even if the RTL does not need a tri-state function) to be in the stdcell library so that the tool can properly synthesize the netlist. The combining and inverting element could be combined as a NAND function or a NOR function. Therefore, the smallest stdcell offering, as illustrated in Figure 2.4, must contain a flip-flop, a tri-state, and a NAND or NOR.

FIGURE 2.4 Minimum Set of Functions Required in a Synthesis Offering. Any logical function can be built with various combinations of NAND (or NOR) gates. The storage element and the tri-state element are further required by the industry standard synthesis tool.

Such stdcell offerings can be artificially built either by removing other elements in a more extant library offering or by adding the tokens “Don’t touch” and “Don’t use” to them. These are Synopsys constructs that prevent stdcells that are present in a Synopsys liberty file from being modified after the fact (the “Don’t touch” construct), or instantiated before the fact (the “Don’t use” construct), in a synthesized netlist, and then to watch Design Compiler synthesize some representative (for your design environment) circuits. The results of an experiment, doing just as described previously for a four-bit adder circuit, has been added in Appendix I. However, no viable stdcell library on the market contains just these three elements.

Instead, most stdcell offerings on the market today contain 300–400 elements representing 3–4 drive strengths for somewhere in the realm of 70–80 different combinational logical functions (and a set of sequential storage elements). These numbers, however, can be widely variable in some offerings. Some libraries offer more than 1,000 elements, a half-dozen drive strengths, or 120 or more logical functions singly or in combination. In addition, many current stdcell library offerings contain high-performance or low-power options that either are their own separate sublibraries or are part of the offering as a whole. These can be “high-Threshold Voltage (Vt)” (slower, less-power-hungry versions of the library elements) and “low-Threshold Voltage (Vt)” (hotter but faster versions). Some of these versions are designed so that they can be used intermingled with cells of the same basic architecture but of different Vt. Further discussion of this is offered later in the book.

In addition, most currently offered stdcell libraries contain circuits that are designed to lower dynamic and static power loss. Examples of the first are clock-gating cells. These are cells that a designer can insert into a clock tree in order to gate a clock that drives some of the flip-flops of a design to an off position. Doing so allows the flip-flops to hold their data without repeatedly needing to burn power when an unneeded clock pulse occurs. In addition, the clock tree itself will not burn dynamic power when turned inactive. These clock-gating cells come in four basic families, and Synopsys’s Design Compiler has been able to handle them correctly. Examples of stdcell library elements that are designed to minimize static power, along with the high-Vt cells already mentioned, include some more esoteric elements such as various versions “state retention” flip-flops. Such flop-flops have small “master latch” sections, either in the place of or in addition to, the normal master-latch section (or small “slave latch” sections either in place of or addition to the normal slave-latch section, dependent on where the particular company plans on doing the low-power state retention) of the flip-flop master–slave circuit. These smaller master-latch or slave-latch flip-flops have some manner of an alternate power or ground supply driving these parts of the circuit. Such cells allow the power or ground to be reduced or removed from the vast portion of a circuit while the power remains active to the small state-retention master latch. This, in turn, allows power to be greatly diminished in designs that have sections that do not get used often but require instant recovery of their previous state when needed. These cells will be further described later as well. Note that some companies have invested seriously in such designs at a high level as previously described. That is why I have kept the description at such a level. At any rate, please protect yourself if you decide to produce such cells by doing a patent search on your particular version. By the way, some companies adjust the oxide thickness or the Vt of one or the other of the latches in order to get some of the benefits that a normal master-latch or slave-latch state-retention flip-flop without impinging on designs patented by other companies. In addition, voltage or frequency stdcell elements will be discussed later. These stdcells are designed to function over larger lower ranges of voltage of the power rail, albeit slower. Because power is a function of the square of the voltage, lowering the voltage rail in parts of the circuit that do not need to perform “as fast as possible” allows reduced power without harmful performance impact. All of these cells will be discussed shortly.

First, however, a discussion of combinational functions is in order. These various functions can be split into several different classes of logic. In CMOS technology, the basic logical function is an inversion. All single-combining operations always involve an inversion. One can logically combine two or more signals by AND (all inputs to such a function need to be high for the output to be high) or OR (any of the inputs to such a logic function can be high and the output is high). Slightly more complexly, one can use Boolean AND/OR or OR/AND signals as they combine in the CMOS logical function, but in any case this combination signal gets inverted as it leaves that logic function. To prevent that from happening, invert the resultant inverted signal (giving a double inversion, which is not similar to a double negative). Hence, the most basic functions in CMOS, as shown in Figure 2.5, are the INVERTER, the NAND (inverted AND), and the NOR (inverted OR). Note that the NAND and NOR symbols and circuits in the figure combine two incoming signals. The actual number of such inputs can be greater than two, subject only to the following discussion on stack height.

FIGURE 2.5 Basic CMOS Functionality (Symbols). Note that each is an inverting function, which is a primary characteristic of basic CMOS logic.

These three functions, viewed as P-channel transistor and N-channel transistor circuits, are shown in Figure 2.6. Note that many stdcell libraries, for convention, have signal names that occur earlier in the alphabet and represent signals that connect to transistors that are stackwise closer to the output and further from the power Voltage Drain Drain (VDD) and ground Voltage Source Source (GND) rails. This was of value when hand-drawn schematics were the prevailing practice because of the assumption that transistors closer to the output would switch faster. This is problematic in more-complex Boolean functions because P-channel transistors may be electronically nearer to the output whereas N-channel transistors are electronically farther away or vice versa. In addition, this practice has been rendered archaic by modern synthesis techniques that allow automated choosing of which functionally equivalent stdcell input to connect to which signal.

FIGURE 2.6 Basic CMOS Functionality (Circuits). Note the pattern of parallel P-channel and serial N-channel transistors for NAND logic and parallel N-channel and serial P-channel transistors in NOR logic. All further complexities in CMOS logic are based on various combinations of these patterns.

As already alluded to, the number of signals that are being combined in a logic function is limited by the number of transistors that can be stacked between a power or ground rail and the output. Stacking too many will not allow sufficient gate drain potential to allow the transistors to properly turn on or off completely (or efficiently). In addition, as stack reaches the edge of this potential, the last transistor out will tend to become an extremely slow transitioning timing arc. The CMOS physics showing this is not complicated and is covered extensively in any basic CMOS design text. For modern deep submicron technologies, a three stack (as many as three transistors between a rail and an output) is typically the most that can be handled. This limits the number of functions that can be handled. Note that for the lowest power designs, this becomes two-stack, further limiting the logic list. This will be further discussed in the low power support section of this book. Based on the preceding discussion, the number of basic one-stage (one combining logic circuit from any input to any output), two-stack, or three-stack functions can be limited to those shown in Table 2.1.

TABLE 2.1 Basic One-, Two-, and Three-Stack CMOS Functions. These can be accomplished using single-stage implementation of either the basic NAND or basic NOR pattern.

NameFunctionNoteINVA_NAND2(AB)_NAND3(ABC)_3 stackNOR2(A + B)_NOR3(A + B + C)_3 stackAOI21(AB + C)_AOI22(AB + CD)_Can be used as a decoded MUX.AOI211(AB + C + D)_3 stackAOI221(AB + CD + E)_3 stackAOI222(AB + CD + EF)_3 stackAOI31(ABC + D)_3 stackAOI32(ABC + DE)_3 stackAOI33(ABC + DEF)_3 stackAOI311(ABC + D + E)_3 stackAOI321(ABC + DE + F)_3 stackAOI322(ABC + DE + FG)_3 stackAOI331(ABC + DEF + G)_3 stackAOI332(ABC + DEF + GH)_3 stackAOI333(ABC + DEF + GHI)_3 stackOAI21((A + B)C)_OAI22((A + B)(C + D))_OAI211((A + B)CD)_3 stackOAI221((A + B)(C + D)E)_3 stackOAI222((A + B)(C + D)(E + F))_3 stackOAI31((A + B + C)D)_3 stackOAI32((A + B + C)(D + E))_3 stackOAI33((A + B + C)(D + E + F))_3 stackOAI311((A + B + C)DE)_3 stackOAI321((A + B + C)(D + E)F)_3 stackOAI322((A + B + C)(D + E)(F + G))_3 stackOAI331((A + B + C)(D + E + F)G)_3 stackOAI332((A + B + C)(D + E + F)(G + H))_3 stackOAI333((A + B + C)(D + E + F)(G + H + J))_3 stackTBUFEA_ if EN=1 and EN_=0, tri-state if EN=0 and EN_=1, undefined otherwiseAdmittedly, can be used as an open-source or an open-drain function as well, depending on other combinations of en and en_; rarely seen as stand alone in a commercially available library.

Note the severe reduction that would result in available functions in Table 2.1 if three stacks were removed for the lowest power designs.

In addition, two simple functions are sometimes added to a list such as the previous one. These are the two-of-three majority vote function, sometimes known as the MAJ3 function; and the three-of-five majority vote function, sometimes known as the MAJ5 function. The first can be implemented using an AOI222 or an OAI222 (see following analysis) or a cross of the two functions, but the second can only be done using the combination. These are listed in Table 2.2.

TABLE 2.2 Two Special Yet Simple Two- and Three-Stack CMOS Functions That Demonstrate the Boolean Flexibility of the Technology. These are special cross combinations of both the basic NAND pattern and basic NOR pattern as explained in the text.

NameFunctionNoteMAJ3(AB + BC + AC)_Multiple implementationsMAJ5(ABC + ABD + ABE + ACD + ACE + ADE + BCD + BCE + BDE + CDE)_Only one valid implementation in 3 stack.

A demonstration might be required for the cited MAJ5. First, consider a simpler example: the MAJ3 previously mentioned. As given, the equation for the MAJ3 is (AB + AC + BC)_, and it can be implemented with an AOI222. However, (A + B)(A + C)(B + C)_ can be reduced to (AB + AC + BC)_ through simple Boolean equivalents:

Hence, the MAJ3 can be done with an OAI222 just as well as the mentioned AOI222. These two implementations are given in Figure 2.7.

FIGURE 2.7