Tlm-driven Design Preview

8/11/2019 Tlm-driven Design Preview

1/20


2/20


3/20

i i i

Table of Contents

Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii

The Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

How the Book is Structured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiii

Moving to a New Level of Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Limitations and Challenges Resulting from RTL-driven Flows . . . . . . . . . . . . . . . . . . . . . . . . . .xvi

The Essential Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv

CHAPTER 1: Solution Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1The Process Today . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Separation of Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12

Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14

ESL and where TLM Fits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17

Mixed Control and Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19

Design Team Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20

Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23

Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25

CHAPTER 2: Languages for Transaction Level Design and Verication . . . . . . . . . . . . . . . . 2-1Language Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Languages for Hardware Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

Languages for Verication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20

SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27

Language Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28

CHAPTER 3: Overview of the Cadence TLM-Driven Designand Verication Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Design and Verication Technologies Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13

Pure Functional Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22


4/20

www.cadence.comiv

TLM-Driven Design and Verication Methodology

Functional Virtual Prototype-Ready Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23

HLS-Ready Levels of Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29

Creating RTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-39

CHAPTER 4: High-level Synthesis Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1Dening Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

High-level Synthesis Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4

Future Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29

CHAPTER 5: Using the Cadence C-to-Silicon Compiler to Solve Real Problems . . . . . . . . . . 5-1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Preparing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

Synthesis Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4

Pipelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20

Control Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27

Incremental Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-31

The Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-37

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-38

CHAPTER 6: Verication Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Metric-Driven Verication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3

UVM Testbenches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12Regression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29

Hardware/Software Co-Verication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29

Hardware Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-31

Verication Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-33

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-34

CHAPTER 7: TLM-Driven Verication Flow in Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

Verication Planning for Multiple Abstraction Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3Developing Multi-Level Verication IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11

Verication of IP across Abstraction Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16

Extending UVM for Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-33

Verication across Integration Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-37

The Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-45

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-45


5/20

Table of Contents

v

APPENDIX A: SystemC Synthesizable Subset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

C/C++. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-1

Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .G-1Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .G-1

Denitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .G-4

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .I-1


6/20


7/20

vii

How the Book is StructuredTis book is published in both electronic and print formats. Copious links have been used in theelectronic version to help you navigate through the information and to ensure that all conceptsare adequately dened. Tis should also help you to locate the pieces of the methodology of mostinterest to you. Here are brief explanations of the contents of each chapter.

Chapter 1, Solution Attributes , explores the processes and methodologies used today for thedesign and verication of complex digital systems. Te problems they create are highlighted, aswell as the impacts these problems have on quality, time to market, predictability of closure, etc.From this basis, a set of requirements is formed for new development processes, as higher levelsof abstraction are used for modeling . In particular, it is shown how the adoption of ransaction -Level Modeling ( LM) will directly improve many of the metrics that are used to measure theefficiency and effectiveness of a development team.

Chapter 2, Languages for Transaction Level Design and Verication , describes the differentlanguages used to specify the design and to construct the verication environment. Becausethe activities of design and verication are very different, it would be impossible to construct a

ransaction-Level Modeling ( LM)-driven Design and Verication methodology using a singlelanguage. Te very nature of the high-level synthesis (HLS) process accepts as input a design inC, C++, or SystemC and produces as output a design in Verilog; so there are two languages at aminimum. Tis chapter provides a basic understanding of the languages and interfaces necessaryto build the LM design and verication ow described in this book.

Chapter 3, Introduction to the Cadence TLM Design and Verication Methodology ,introduces the main concepts of the Cadence LM-driven design and verication methodology.First, it is demonstrated how some of the concepts introduced in Chapter 1 can be turned intopractice; then, the tasks are described that must be performed at each stage of the ow. Teremainder of the chapter shows how the ow accomplishes each of those tasks and provides thebackground necessary to understand how to implement such a ow conceptually. Subsequentchapters provide additional details regarding ow implementation.


8/20

www.cadence.comvi i i


Chapter 4, High-level Synthesis Fundamentals , frees designers from tedious and error-prone operations, allowing them to concentrate on the higher-level decision-making process.Nonetheless, it delivers the best results only when employed by designers who understand gooddesign and implementation practices.

Using simple examples, this chapter illustrates the concepts behind high-level synthesis . Tefocus will be on the types of transformations that can be made during the LM to R L synthesisprocessgenerally referred to as micro-architectural transformations. Te discussion will coverboth the transformations that the tools make and those that designers make to improve theeffectiveness of the tool and to achieve better Quality of Results (QoR).

Chapter 5, Using C-to-Silicon to Solve Real Problems , focuses on the Cadence C-to-SiliconCompiler, explaining not only how to use it, but also how to write effective input descriptions tohelp you get the best possible results. Te compiler is demonstrated using three designsrangingfrom small example circuits that demonstrate certain types of features to a realistic design thatutilizes the methodology described in this book. Tese examples show only a small set of thefeatures of the tool. As such, the results do not reect the best possible results that you could get

from the full capabilities of the C-to-Silicon Compiler.Chapter 6, Verication Fundamentals , introduces a number of verication concepts that havebeen proven, over the course of many years, to deliver consistent and high quality R L designs,while minimizing the chance of bug escapes and keeping total verication costs under control.Tese concepts are constantly being improved and extended to handle the growing size andcomplexity of todays systems.

Tis chapter introduces the concepts of verication planning, the use of the Universal VericationMethodology (UVM) , and a Metric-Driven Verication (MDV) closure process. It is importantthat you fully understood these concepts before learning about the extensions that enable themto be applied to transaction-level designs.

Chapter 7, Verication Flow in Action , takes an in-depth look at the verication aspects of theLM-driven design and verication methodology. Examples are used to illustrate how a Metric-

Driven Verication (MDV) environment can be applied across multiple levels of abstraction forthe verication of design IP blocks.

Te methodology starts with the creation of a multi-level verication plan . Te verication planis extended and rened as architectural and micro-architectural implementation decisions aremade. Te verication methodology is implemented using a Universal Verication Methodology(UVM) library extended for the multi-language and multi-level capabilities necessary toimplement such a ow, including the incorporation of hardware acceleration.

Appendix A, SystemC Synthesizable Subset , While most constructs of C, C++ and SystemCare supported by the Cadence C-to-Silicon Compiler, to produce hardware implementations,there are some restrictions in the way in which code can be written. In addition there are onlycertain aspects of LM that are supported. Tese restrictions will be described in this appendix.In addition it will include a number of tips and tricks that can help you ensure that you will getthe best quality of results from the high-level synthesis process.


9/20

ix

PrefaceTe enormous complexity of systems being designed today shows that Moores law whichpredicted roughly a doubling of the number of transistors that can be placed on a chip everytwo yearsremains in effect. While some have predicted the end of this technology productivitytrend, studies suggest it will hold true for some time to come.

Te International echnology Roadmap for Semiconductors ( I RS) is an organization thatprovides many projections for factors that inuence the design, verication and fabrication ofsemiconductors. Te I RS recently released its 2008 update , which provides projections for thecomplexity trends in many product areas. One of the most dynamic areas is consumer portabledesigns, as shown in Figure 11.

Figure 1: ITRS 2008 Consumer Portable Design Complexity Trends.

1 Image enhanced and republished with permission from the Semiconductor Industry Association. The InternationalTechnology Roadmap for Semiconductors, 2009 Edition. SEMATECH:Austin, TX, 2009.


10/20

www.cadence.comx


Keeping pace with this phenomenal growth in complexity will require commensurate increasesin engineering productivity. Notably, design and verication must keep pace with potentialincreases in chip sizes and corresponding increases in functionality and product features.Unfortunately, productivity has not managed to keep pace in recent years.

Figure 2: Productivity trends

Looking at Figure 22, which comes from the same I RS report, it is easy to see why it has becomeincreasingly difficult to design the innovative logic that keeps a system differentiated from thecommodity marketplace. Tis diagram shows how hardware design productivity has remained

considerably ahead of so ware productivity, yet has lagged the growth of raw technologycapabilities. In other words, since 1981, designers have had trouble designing enough logic toll all of the silicon real estate available for transistors. Te chart also shows that around 1997the gap began to widen. In fact, only by placing more memory on a chip, increasing IntellectualProperty (IP) re-use, and incorporating third-party IP has the number of gates per day kept upwith the previous productivity trend.

While hardware design productivity clearly needs to improve, circumstantial evidence suggeststhat design quality is suffering as well. Back in 2002 and 2004, Collett International conductedstudies revealing an increasing rate of bug escapes, and while no gures have been publishedsince then, informal polls tend to show there have been no improvements. Costs associated with

bug escapes grow considerably as you progress through the development ow, and escalate at aneven higher rate once implemented in silicon. More importantly, bugs found in the marketplacehave even higher costs than the huge costs to x them physically, as they can seriously damage acompanys reputation.

As a consequence, many companies complain that their verication costs are out of control. Infact, verication has now become the largest cost in the development process.

2 Image enhanced and republished with permission from the Semiconductor Industry Association. The InternationalTechnology Roadmap for Semiconductors, 2009 Edition. SEMATECH:Austin, TX, 2009.


11/20

Preface

xi

In addition to causing a rise in verication costs, increasing complexity actually introduces bugsby making it harder to comprehend everything going on in a system. Tis situation will worsenconsiderably with the increased levels of concurrency used in the systems being designed today,compared with those of just a few years ago.

Te solution to these problems requires raising the level of abstraction for both the design and verication processes. Tis will have the effect of removing unnecessary detail, which aids incomprehensionand increased comprehension leads to fewer errors, lower risk and an increasein quality.

In addition, tools that operate at higher levels of abstraction tend to increase productivity in manyways. For simulation, the rate of execution is higher, meaning that substantially more cycles canbe executed in the same amount of time, or that considerably longer vector sets can be used toexercise designs in ways they could not be exercised before. Within the design process, higherabstraction not only means much higher productivity (e.g., gates per day), but also the abilityto explore a greater number of different implementations, leading to better quality, smaller size,or higher performance. Higher abstraction also allows designers to more thoroughly examine

and optimize power consumption.So higher levels of abstraction promises more, better, faster . What more can you ask for?

MOVING TO A NEW LEVEL OF ABSTRACTIONRegister-transfer level (R L) ows are now more than 20 years old, and, as such, are strainingto meet the demands of most product teams. When designs are sourced and veried at the Rlevel, IP reuse becomes difficult, functional verication becomes lengthy and cumbersome, andarchitectural decisions are non-conrmable prior to R L verication. With increasing pressureon todays System on Chip (SoC ) and Application Specic Integrated Circuit (ASIC ) designteams to deliver more complex and aggressive designs within less timeas well as the need to getdesigns right on the rst pass (due to the high cost of re-spins and missing market windows)many companies today are looking to move to a level of abstraction beyond R L to get a much-needed boost in design productivity.

Te consensus is that the next level of abstraction should be based on ransaction -Level Modeling( LM). By creating LM IP as their golden source, design teams can ease IP creation and reuse,spend less time and effort on functional verication, and introduce fewer bugs. Tis reducesdesign iterations because LM verication is much faster than R L verication, and architectural choices can now be veried well before R L verication. Furthermore, compared with R Lmodels, transaction-level models can be used more easily for hardware/so ware co-verication ,

and as part of a virtual platform for early so ware development. All of these advantages add upto dramatically increased designer productivity.

For communication between blocksone of the most simulation-cycle intensive aspects of mostdesignstransaction-level modeling uses function calls, rather than signals or wires, for inter-module communications. LM lets designers analyze transactions such as reads or writes ratherthan worrying about the underlying logic implementation and timing. SystemC is considered thebest language standard for developing reusable, interoperable LM IP. Moreover, because it is


12/20

www.cadence.comxi i


based on C++, SystemC allows full reuse of arithmetic C language functions. Te Open SystemCInitiative (OSCI) has dened several abstraction levels for LM models, including the untimedprogrammers view (PV), loosely timed (L ), and approximately timed (A ).

Tis book describes a comprehensive SystemC LM-driven IP design and verication solutionincluding methodology guidelines, high-level synthesis, and LM-aware verication basedon Cadence productsthat will help designers transition to a LM-driven design and verication ow.

Tis preface describes the key challenges that demand a change from R L as the entry pointfor design and verication IP. It outlines the LM-driven solution needed to overcome todaysdesign and verication challenges, and cites its advantages.

LIMITATIONS AND CHALLENGES RESULTING FROM RTL-DRIVEN FLOWS

At the Register- ransfer Level, the structure of Finite State Machines (FSM) is fully described.Tis means that when writing R L, you must commit to micro-architectural details, such asmemory structures, pipelines, control states, or Arithmetic Logic Units (ALU) used in theresulting implementation. Tis results in fewer reusable design descriptions, since the structureof nite state machines depends signicantly on the implementation requirements of the design.When the same design is used for another project with different implementation requirementssuch as with a new technology node, or with a higher clock speed, for exampleyou must o enmodify the structure of the state machines, which results in quite a few changes in many partsof the R L descriptions. Tis causes the design and verication process to be longer and morecomplex than necessary.

While LM is sometimes used in todays ows, current R L-based ows require the manualentry of design intent twice: once at the system level, and again at the R level ( Figure 3). Tis isa cumbersome and error-prone process. Architecture is not veried until R L is generated, andretargeting IP comes at a high cost. A true LM-driven design and verication ow ( Figure 3,right-hand side) offers an automated path from a single expression of design intent.

Another major problem with an R L-driven design methodology is that design teams do notknow if an architecture can actually be implemented until they create R L and run verication todetermine if goals were met. Because R L is inherently a direct representation of the architecture,most R L designers are forced to explore functional correctness, architecture, and design goalssimultaneously. Te result is a lengthy cycle that begins with making an architectural decision andends with verifying the functionality. O en, design and verication teams discover functionalbugs that require xes to the architecture, which requires restarting the entire cycle witheach bug.


13/20

Preface

xi i i

Figure 3: An RTL-based ow requires manual design intent entry twice. A TLM-based ow, incontrast, provides an automated path to implementation.

Reusing Design IP at RTL Restricts Architectural FlexibilityIn todays SoCs, as much as 90 percent of the IP blocks may be reused from previous projects.But reuse is difficult when the golden-source for the IP is an implementation at the R level. Tetarget system application may differ signicantly, implying new design goals for the SoC that can

be met only by re-architecting, not by simple reuse. Retargeting to different micro-architecturesis difficult, error-prone work. For example, R L designers may need to re-partition the designinto new R L blocks, change the number of pipeline stages, or create a new memory architecture,because all of these micro-architectural details have been xed and pre-determined in the old IP.

RTL Functional Verication Time is Growing Faster than theAvailable Throughput of Todays TechnologyFunctional verication has become the primary bottleneck in many SoC projects. Much of the verication effort invested at the system level is lost when R L functional verication begins.While techniques such as verication planning and metric-driven verication allow design teamsto handle many of todays verication challenges, time constraints and increasing gate counts aremaking verication much more difficult. Te time required for R L functional verication cangrow exponentially with the size of designs. Tis is due to the need to verify corner cases resultingfrom interacting modes and the many hardware and so ware congurations with which the IPmust be tested.


14/20

www.cadence.comxiv


R L logic is cycle accurate and involves many more lines of code than a LM description of thesame functionality. When R L models are simulated, the simulator must examine every eventor clock cycle, even if nothing signicant is happening at the protocol level. Te simulator thusburns a lot of compute cycles on micro-architectural detail that could be postponed until a er thearchitecture is committed. LM simulation is done at a higher level of abstraction, is performed

earlier, and provides higher performance.

THE ESSENTIAL SOLUTIONA LM-driven design and verication ow addresses these challenges by making it possible todescribe IP at the functional level, and then to verify the functional behavior of transactions in afast simulation. Key advantages of a LM ow include:

Much faster creation of designs

Reduced number of lines of code in the golden source

Fewer bugs Easier expression of design intent, which is needed only once

Faster simulation and debugging

Earlier power estimations

Support for hardware/so ware co-verication

Ability to incorporate models into the virtual platform

Architectural verication before R L generation

Reuse of LM verication IP in R L verication

IP reuse without micro-architectural redesign

Engineering Change Orders (ECOs ) handled at the functional level, which enables producingR L models with minimal changes.

Used in conjunction with High-Level Synthesis (HLS) for micro-architectural exploration andrenement, as well as to generate synthesizable R L code, a LM-based ow raises the level ofabstraction for design capture.

Tis is the rst major shi in abstraction since designers moved to R L. Experience withprevious shi s in abstraction level suggests that an order-of-magnitude improvement in designerproductivity may be possible as indicated in Figure 4.


15/20

Preface

xv

Figure 4: A TLM-based ow with HLS could bring about an order of magnitude improvementin designer productivity.

Specic attributes and advantages of a LM-driven design and verication ow are described inthe following sections.

Creating TLM as Golden Source Faster IP Creation andDesign IP ReuseUnlike R L, LM does not describe any micro-architectural details of the resulting

implementation. Tis absence of detail greatly enhances the reusability of LM designs acrossmultiple projects with different requirements, since the same LM IP can be retargeted to R Lcode with different micro-architectures. Also, the higher level of abstraction requires fewer linesof code, making it easier to correctly create the functionality.

Developing and maintaining LM as the golden source for an IP block requires high-levelsynthesis and verication solutions that produce the necessary quality of results and verify thecorrectness, with no need to hand-edit the R L or gate-level design. Tis enables the design teamto make all decisions within the LM environment.

With Cadence C-to-Silicon Compiler high-level synthesis technology, for example, designerscan specify area, timing, and power constraints in a side le separately from the golden source.It is thus possible to change micro-architectural characteristics, such as the number of pipelinestages, and still retain the reusability of the original LM model. In an R L IP block, in contrast,the number of pipeline stages would be xed.


16/20

www.cadence.comxvi


SystemC is the best standard for describing transaction-level designs with a link to implementationand offers the best opportunities for reusability. It models hardware concurrency and describesboth timed and untimed behavior for processes, pins, threads, and control logic. Te LM 1.0and 2.0 standards provide the ability to create interoperable IP models. Ultimately, qualiedlibraries of synthesizable LM IP, together with a standard (or de facto) subset of synthesizable

LM, will be needed.

Functional Verication of TLM IP Offsets the VericationThroughput ExplosionVerication of LM IP has many advantages over R L verication. First, simulation runsfasterperhaps an order of magnitude or more compared with R L simulation. Tis allows the verication of many more functional use cases. Also, debugging at the LM level of abstraction iseasier and faster than R L debugging due to easier comprehension of system state and a reductionin unnecessary details that can obscure the underlying cause of problems.

By coding at a higher level, LM IP requires fewer lines of code, and thus has fewer bugs.Functional bugs are detected and resolved earlier in the design cycle. Te total verication effortcan thus be greatly reduced.

It is easier to identify and understand bugs at the abstract LM level, and it is easier to x bugs atthis level, because there are fewer details. A LM ow makes it possible to verify each concern atthe most appropriate level of abstractionfor example, LM for functionality, and signal-level verication for the implementation of interfaces a er they have been fully rened.

Te LM verication ow begins with algorithmic functional verication, which allows functional validation with so ware, and proceeds to LM functional verication ( Figure 5). Followingcompilation with the C-to-Silicon Compiler, designers can move on to micro-architectural

R L verication and R L-to-gates equivalence checking . In addition to supporting untimedmodeling, which allows very fast simulation, LM also allows designers to make renements thatprogressively include micro-architectural details and rene timing accuracy. Figure 5 lists thetypes of hardware and so ware verication that can be performed at each of the correspondingstages of the design ow.

Hardware/Software Co-Verication and Early SoftwareDevelopment

LM models are at a sufficiently high level of abstraction, and execute quickly enough, to makehardware/so ware co-simulation practical. Designers can co-simulate embedded so ware

with LM hardware models to check for hardware/so ware dependencies and to begin earlydebugging of hardware-dependent so ware. echnologies, such as constrained-random stimulusand coverage of hardware/so ware interactions, can be applied.

Virtual platforms used for early so ware development and debugging may include subsystemscomprised of SystemC LM models. Because of their fast execution, models developed forhardware design creation can also be used to accelerate so ware design.


17/20

Preface

xvii

Figure 5: TLM verication ow (left) and verication requirementsfor each stage (right)

Supporting Combined TLM and RTL VericationAt the SoC level, mixed LM and R L functional verication is required for two reasons: (1)because of the reuse of a large amount of legacy R L IP and (2) because it will still be necessaryto perform detailed R L functional verication for portions of the design, due to functionalitycreated to support the implementation that contributes to the system-level functionality. Tus,some verication tasks will still be done only at R L. Tis includes micro-architectural structural verication for such attributes as memory access sequences, state transition coverage or errordetection, and correction logic. Communication protocol compliance may also need to be veried at both the signal and cycle-accurate levels.

Mixed LM/R L verication is facilitated when verication artifactsincluding verication

plans (vPlans), UVM Verication Components (UVC), testbenches , sequences, tests, checks,and coverageare all available and reusable across abstraction levels unied within a UniversalVerication Methodology (UVM) framework. Functional verication planning and managementacross both LM and R L lets teams track and control verication at each level in a mixed-level design and combine the results as needed, ensuring overall quality. Tus, the vericationenvironment works best when it supports multiple levels of abstraction and multiple use modes.


18/20

www.cadence.comxvi i i


Te Universal Verication Methodology (UVM) is an industry-standard verication library andmethodology developed by Accellera. Te UVM is based on the Open Verication Methodology(OVM) and will gradually supersede it. For the purpose of this book, we will refer to the UVM, asthe transition is already in progress. Both the OVM and the UVM, originally for SystemVerilog,have been extended to support multiple languages, including e and SystemC. Te UVM library

also supports LM. Currently, the UVM methodology description is being extended to showhow LM and R L models can be combined in a comprehensive regression solution. Tis willfacilitate the creation of Verication IP (VIP) that works in a multi-language, mixed LM/R L verication environment and can also be used with a hardware emulation/acceleration solution.

A multi-level functional verication testbench is based on transactions, and when it is connectedto R L-based IP, buses, or interfaces, a transactor is needed to translate between the transaction-level domain and the pin-accurate R L domain. Similarly, transactors are needed to connect

LM IP blocks to buses or interfaces on R L IP blocks. A LM-based methodology mustconsider how these transactors operate in order to gain the maximum benets of mixed LM/R L verication. Some transactors may be commercially available, while others are proprietary,

created by the project team and managed as verication library components.Many projects are implementing LM for new IP only, gradually building up a library of LMIP, whereas other teams are embracing a LM methodology for all major IP blocks in mission-critical projects. Eventually, SoCs will emerge in which all IP golden source is at the LM level.In these cases, benets of quality, productivity, and ease of debugging will be more pronouncedthan with mixed LM/R L projects. Tis makes it possible to achieve SoC LM functional verication, including SoC-level architectural analysis and optimization.

Reusing VIP from TLM through RTL VericationVIP reuse has now become main stream because the time required to create high-quality

verication environments o en exceeds the time needed to create the design IP itself. Te wideemployment of standard protocols has driven the development of a fast-growing commercialVIP market. oday, most of this VIP is at the Register- ransfer Level. LM-enabled VIP will alsobe needed, but it must be reusable for mixed LM/R L functional verication.

R L functional verication is dominated by advanced testbenches that use constrained-randomstimulus generation. LM-enabled VIP should be operable in testbenches for LM, mixed LM/R L, accelerated verication, and R L functional verication. Tat same VIP must allow theapplication of metric-driven verication as customers apply coverage metrics at all levels of verication abstraction. Finally, supporting embedded so ware and directed tests is necessaryfor verication teams who work closely with architects and so ware engineering teams.

Accelerators are seeing increased usage for system-level verication that includes one or moremodules at the R level; therefore, VIP must be equally applicable to these environments. Tisrequires transaction-level interfaces that can serve as a bridge between so ware simulation,hardware acceleration, and testbenches.


19/20


20/20


The MethodologyLM-driven design and verication will ultimately enable LM to replace R L as the golden

source for most design components. Te advantages are compellingmuch faster design and verication times, easier IP reuse, and fewer bugs. Designer productivity will take the biggest jump since the advent of R L design. But the transition will not occur overnight. Te adoptionof LM-driven design and verication will occur one IP block at a time as new IP is created.And some design components will be best designed directly in R L. Tus, it must be possible tocombine new LM IP with legacy R L IP in design and verication environments.

Te methodology just described will be detailed in the various chapters that make up this book.At the end of the book, designers should understand a suggested ow based on these principlesand decide if they would benet from the adoption of such a methodology.

Te ow will be described using a number of examples to demonstrate various aspects of themethodology. In addition, since this methodology is still evolving, regular updates to this bookwill be made available as additional pieces of the methodology are dened, rened, and improved.Cadence can also supply a wide range of additional materials to help with adoption, includingthe full cookbook, workshops, and tested examples.

REFERENCES[1] Wikipedia entry for Moores Law http://en.wikipedia.org/wiki/Moore%27s_law

[2] Counting Down to the End of Moores Law. Te New York imes. May 22nd 2009 http://bits.blogs.nytimes.com/2009/05/22/counting-down-to-the-end-of-moores-law/

Documents

Tlm-driven Design Preview