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-1
The 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-24
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25
CHAPTER 2: Languages for Transaction Level Design and Verication . . . . . . . . . . . . . . . . 2-1
Language 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 Design
and Verication Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Design and Verication Technologies Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Pure Functional Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22
www. cadence. com i v
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-1
Dening 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-12
Regression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 inAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Verication Planning for Multiple AbstractionLevels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Developing 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
Table of Contents
v
APPENDIX A: SystemC Synthesizable Subset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
C/C++. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .G-1
Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .G-1
Denitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .G-4
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .I-1
vi i
How the Book is Structured
Tis book is published in both electronic and print formats. Copious links have been used in the
electronic version to help you navigate through the information and to ensure that all concepts
are adequately defned. Tis should also help you to locate the pieces of the methodology of most
interest to you. Here are brief explanations of the contents of each chapter.
Chapter 1, Solution Attributes, explores the processes and methodologies used today for the
design and verifcation of complex digital systems. Te problems they create are highlighted, as
well 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 levels
of abstraction are used for modeling. In particular, it is shown how the adoption of Transaction-
Level Modeling (TLM) will directly improve many of the metrics that are used to measure the
efciency and efectiveness of a development team.
Chapter 2, Languages for Transaction Level Design and Verication, describes the diferent
languages used to specify the design and to construct the verifcation environment. Because
the activities of design and verifcation are very diferent, it would be impossible to construct a
Transaction-Level Modeling (TLM)-driven Design and Verifcation methodology using a single
language. Te very nature of the high-level synthesis (HLS) process accepts as input a design in
C, C++, or SystemC and produces as output a design in Verilog; so there are two languages at a
minimum. Tis chapter provides a basic understanding of the languages and interfaces necessary
to build the TLM design and verifcation fow described in this book.
Chapter 3, Introduction to the Cadence TLM Design and Verication Methodology,
introduces the main concepts of the Cadence TLM-driven design and verifcation methodology.
First, it is demonstrated how some of the concepts introduced in Chapter 1 can be turned into
practice; then, the tasks are described that must be performed at each stage of the fow. Te
remainder of the chapter shows how the fow accomplishes each of those tasks and provides the
background necessary to understand how to implement such a fow conceptually. Subsequent
chapters provide additional details regarding fow implementation.
www. cadence. com vi i i
TLM-Driven Design and Verication Methodology
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 good
design and implementation practices.
Using simple examples, this chapter illustrates the concepts behind high-level synthesis. Te
focus will be on the types of transformations that can be made during the TLM to RTL synthesis
processgenerally referred to as micro-architectural transformations. Te discussion will cover
both the transformations that the tools make and those that designers make to improve the
efectiveness 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-Silicon
Compiler, explaining not only how to use it, but also how to write efective input descriptions to
help you get the best possible results. Te compiler is demonstrated using three designsranging
from small example circuits that demonstrate certain types of features to a realistic design that
utilizes the methodology described in this book. Tese examples show only a small set of the
features of the tool. As such, the results do not refect 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 verifcation concepts that have
been proven, over the course of many years, to deliver consistent and high quality RTL designs,
while minimizing the chance of bug escapes and keeping total verifcation costs under control.
Tese concepts are constantly being improved and extended to handle the growing size and
complexity of todays systems.
Tis chapter introduces the concepts of verifcation planning, the use of the Universal Verifcation
Methodology (UVM), and a Metric-Driven Verifcation (MDV) closure process. It is important
that you fully understood these concepts before learning about the extensions that enable them
to be applied to transaction-level designs.
Chapter 7, Verication Flow in Action, takes an in-depth look at the verifcation aspects of the
TLM-driven design and verifcation methodology. Examples are used to illustrate how a Metric-
Driven Verifcation (MDV) environment can be applied across multiple levels of abstraction for
the verifcation of design IP blocks.
Te methodology starts with the creation of a multi-level verifcation plan. Te verifcation plan
is extended and refned as architectural and micro-architectural implementation decisions are
made. Te verifcation methodology is implemented using a Universal Verifcation Methodology
(UVM) library extended for the multi-language and multi-level capabilities necessary to
implement such a fow, including the incorporation of hardware acceleration.
Appendix A, SystemC Synthesizable Subset, While most constructs of C, C++ and SystemC
are 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 only
certain aspects of TLM 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 get
the best quality of results from the high-level synthesis process.
i x
Preface
Te enormous complexity of systems being designed today shows that Moores lawwhich
predicted roughly a doubling of the number of transistors that can be placed on a chip every
two yearsremains in efect. While some have predicted the end of this technology productivity
trend, studies suggest it will hold true for some time to come.
Te International Technology Roadmap for Semiconductors (ITRS) is an organization that
provides many projections for factors that infuence the design, verifcation and fabrication of
semiconductors. Te ITRS recently released its 2008 update, which provides projections for the
complexity trends in many product areas. One of the most dynamic areas is consumer portable
designs, as shown in Figure 1
1
.
Figure 1: ITRS 2008 Consumer Portable Design Complexity Trends.
1 Image enhanced and republished with permission from the Semiconductor Industry Association. The International
Technology Roadmap for Semiconductors, 2009 Edition. SEMATECH:Austin, TX, 2009.
www. cadence. com x
TLM-Driven Design and Verication Methodology
Keeping pace with this phenomenal growth in complexity will require commensurate increases
in engineering productivity. Notably, design and verifcation must keep pace with potential
increases 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 2
2
, which comes from the same ITRS report, it is easy to see why it has become
increasingly difcult to design the innovative logic that keeps a system diferentiated from the
commodity marketplace. Tis diagram shows how hardware design productivity has remained
considerably ahead of sofware productivity, yet has lagged the growth of raw technology
capabilities. In other words, since 1981, designers have had trouble designing enough logic to
fll all of the silicon real estate available for transistors. Te chart also shows that around 1997
the gap began to widen. In fact, only by placing more memory on a chip, increasing Intellectual
Property (IP) re-use, and incorporating third-party IP has the number of gates per day kept up
with the previous productivity trend.
While hardware design productivity clearly needs to improve, circumstantial evidence suggests
that design quality is sufering as well. Back in 2002 and 2004, Collett International conducted
studies revealing an increasing rate of bug escapes, and while no fgures have been published
since then, informal polls tend to show there have been no improvements. Costs associated with
bug escapes grow considerably as you progress through the development fow, and escalate at an
even higher rate once implemented in silicon. More importantly, bugs found in the marketplace
have even higher costs than the huge costs to fx them physically, as they can seriously damage a
companys reputation.
As a consequence, many companies complain that their verifcation costs are out of control. In
fact, verifcation has now become the largest cost in the development process.
2 Image enhanced and republished with permission from the Semiconductor Industry Association. The International
Technology Roadmap for Semiconductors, 2009 Edition. SEMATECH:Austin, TX, 2009.
Preface
xi
In addition to causing a rise in verifcation costs, increasing complexity actually introduces bugs
by making it harder to comprehend everything going on in a system. Tis situation will worsen
considerably 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
verifcation processes. Tis will have the efect of removing unnecessary detail, which aids in
comprehensionand increased comprehension leads to fewer errors, lower risk and an increase
in quality.
In addition, tools that operate at higher levels of abstraction tend to increase productivity in many
ways. For simulation, the rate of execution is higher, meaning that substantially more cycles can
be executed in the same amount of time, or that considerably longer vector sets can be used to
exercise designs in ways they could not be exercised before. Within the design process, higher
abstraction not only means much higher productivity (e.g., gates per day), but also the ability
to explore a greater number of diferent 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 ABSTRACTION
Register-transfer level (RTL) fows are now more than 20 years old, and, as such, are straining
to meet the demands of most product teams. When designs are sourced and verifed at the RT
level, IP reuse becomes difcult, functional verifcation becomes lengthy and cumbersome, and
architectural decisions are non-confrmable prior to RTL verifcation. With increasing pressure
on todays System on Chip (SoC) and Application Specifc Integrated Circuit (ASIC) design
teams to deliver more complex and aggressive designs within less timeas well as the need to get
designs right on the frst 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 RTL to get a much-
needed boost in design productivity.
Te consensus is that the next level of abstraction should be based on Transaction-Level Modeling
(TLM). By creating TLM IP as their golden source, design teams can ease IP creation and reuse,
spend less time and efort on functional verifcation, and introduce fewer bugs. Tis reduces
design iterations because TLM verifcation is much faster than RTL verifcation, and architectural
choices can now be verifed well before RTL verifcation. Furthermore, compared with RTL
models, transaction-level models can be used more easily for hardware/sofware co-verifcation,
and as part of a virtual platform for early sofware development. All of these advantages add up
to dramatically increased designer productivity.
For communication between blocksone of the most simulation-cycle intensive aspects of most
designstransaction-level modeling uses function calls, rather than signals or wires, for inter-
module communications. TLM lets designers analyze transactions such as reads or writes rather
than worrying about the underlying logic implementation and timing. SystemC is considered the
best language standard for developing reusable, interoperable TLM IP. Moreover, because it is
www. cadence. com xi i
TLM-Driven Design and Verication Methodology
based on C++, SystemC allows full reuse of arithmetic C language functions. Te Open SystemC
Initiative (OSCI) has defned several abstraction levels for TLM models, including the untimed
programmers view (PV), loosely timed (LT), and approximately timed (AT).
Tis book describes a comprehensive SystemC TLM-driven IP design and verifcation solution
including methodology guidelines, high-level synthesis, and TLM-aware verifcation based
on Cadence productsthat will help designers transition to a TLM-driven design and
verifcation fow.
Tis preface describes the key challenges that demand a change from RTL as the entry point
for design and verifcation IP. It outlines the TLM-driven solution needed to overcome todays
design and verifcation challenges, and cites its advantages.
LIMITATIONS AND CHALLENGES RESULTING FROM RTL-
DRIVEN FLOWS
At the Register-Transfer Level, the structure of Finite State Machines (FSM) is fully described.
Tis means that when writing RTL, you must commit to micro-architectural details, such as
memory structures, pipelines, control states, or Arithmetic Logic Units (ALU) used in the
resulting implementation. Tis results in fewer reusable design descriptions, since the structure
of fnite state machines depends signifcantly on the implementation requirements of the design.
When the same design is used for another project with diferent implementation requirements
such as with a new technology node, or with a higher clock speed, for exampleyou must ofen
modify the structure of the state machines, which results in quite a few changes in many parts
of the RTL descriptions. Tis causes the design and verifcation process to be longer and more
complex than necessary.
While TLM is sometimes used in todays fows, current RTL-based fows require the manual
entry of design intent twice: once at the system level, and again at the RT level (Figure 3). Tis is
a cumbersome and error-prone process. Architecture is not verifed until RTL is generated, and
retargeting IP comes at a high cost. A true TLM-driven design and verifcation fow (Figure 3,
right-hand side) ofers an automated path from a single expression of design intent.
Another major problem with an RTL-driven design methodology is that design teams do not
know if an architecture can actually be implemented until they create RTL and run verifcation to
determine if goals were met. Because RTL is inherently a direct representation of the architecture,
most RTL designers are forced to explore functional correctness, architecture, and design goals
simultaneously. Te result is a lengthy cycle that begins with making an architectural decision and
ends with verifying the functionality. Ofen, design and verifcation teams discover functional
bugs that require fxes to the architecture, which requires restarting the entire cycle with
each bug.
Preface
xi i i
Figure 3: An RTL-based ow requires manual design intent entry twice. A TLM-based ow, in
contrast, provides an automated path to implementation.
Reusing Design IP at RTL Restricts Architectural Flexibility
In todays SoCs, as much as 90 percent of the IP blocks may be reused from previous projects.
But reuse is difcult when the golden-source for the IP is an implementation at the RT level. Te
target system application may difer signifcantly, implying new design goals for the SoC that can
be met only by re-architecting, not by simple reuse. Retargeting to diferent micro-architectures
is difcult, error-prone work. For example, RTL designers may need to re-partition the design
into new RTL blocks, change the number of pipeline stages, or create a new memory architecture,
because all of these micro-architectural details have been fxed and pre-determined in the old IP.
RTL Functional Verication Time is Growing Faster than the
Available Throughput of Todays Technology
Functional verifcation has become the primary bottleneck in many SoC projects. Much of the
verifcation efort invested at the system level is lost when RTL functional verifcation begins.
While techniques such as verifcation planning and metric-driven verifcation allow design teams
to handle many of todays verifcation challenges, time constraints and increasing gate counts are
making verifcation much more difcult. Te time required for RTL functional verifcation can
grow exponentially with the size of designs. Tis is due to the need to verify corner cases resulting
from interacting modes and the many hardware and sofware confgurations with which the IP
must be tested.
www. cadence. com xi v
TLM-Driven Design and Verication Methodology
RTL logic is cycle accurate and involves many more lines of code than a TLM description of the
same functionality. When RTL models are simulated, the simulator must examine every event
or clock cycle, even if nothing signifcant is happening at the protocol level. Te simulator thus
burns a lot of compute cycles on micro-architectural detail that could be postponed until afer the
architecture is committed. TLM simulation is done at a higher level of abstraction, is performed
earlier, and provides higher performance.
THE ESSENTIAL SOLUTION
A TLM-driven design and verifcation fow addresses these challenges by making it possible to
describe IP at the functional level, and then to verify the functional behavior of transactions in a
fast simulation. Key advantages of a TLM fow 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/sofware co-verifcation
Ability to incorporate models into the virtual platform
Architectural verifcation before RTL generation
Reuse of TLM verifcation IP in RTL verifcation
IP reuse without micro-architectural redesign
Engineering Change Orders (ECOs) handled at the functional level, which enables producing
RTL models with minimal changes.
Used in conjunction with High-Level Synthesis (HLS) for micro-architectural exploration and
refnement, as well as to generate synthesizable RTL code, a TLM-based fow raises the level of
abstraction for design capture.
Tis is the frst major shif in abstraction since designers moved to RTL. Experience with
previous shifs in abstraction level suggests that an order-of-magnitude improvement in designer
productivity may be possible as indicated in Figure 4.
Preface
xv
Figure 4: A TLM-based ow with HLS could bring about an order of magnitude improvement
in designer productivity.
Specifc attributes and advantages of a TLM-driven design and verifcation fow are described in
the following sections.
Creating TLM as Golden SourceFaster IP Creation and
Design IP Reuse
Unlike RTL, TLM does not describe any micro-architectural details of the resulting
implementation. Tis absence of detail greatly enhances the reusability of TLM designs across
multiple projects with diferent requirements, since the same TLM IP can be retargeted to RTL
code with diferent micro-architectures. Also, the higher level of abstraction requires fewer lines
of code, making it easier to correctly create the functionality.
Developing and maintaining TLM as the golden source for an IP block requires high-level
synthesis and verifcation solutions that produce the necessary quality of results and verify the
correctness, with no need to hand-edit the RTL or gate-level design. Tis enables the design team
to make all decisions within the TLM environment.
With Cadence C-to-Silicon Compiler high-level synthesis technology, for example, designers
can specify area, timing, and power constraints in a side fle separately from the golden source.
It is thus possible to change micro-architectural characteristics, such as the number of pipeline
stages, and still retain the reusability of the original TLM model. In an RTL IP block, in contrast,
the number of pipeline stages would be fxed.
www. cadence. com xvi
TLM-Driven Design and Verication Methodology
SystemC is the best standard for describing transaction-level designs with a link to implementation
and ofers the best opportunities for reusability. It models hardware concurrency and describes
both timed and untimed behavior for processes, pins, threads, and control logic. Te TLM 1.0
and 2.0 standards provide the ability to create interoperable IP models. Ultimately, qualifed
libraries of synthesizable TLM IP, together with a standard (or de facto) subset of synthesizable
TLM, will be needed.
Functional Verication of TLM IP Offsets the Verication
Throughput Explosion
Verifcation of TLM IP has many advantages over RTL verifcation. First, simulation runs
fasterperhaps an order of magnitude or more compared with RTL simulation. Tis allows the
verifcation of many more functional use cases. Also, debugging at the TLM level of abstraction is
easier and faster than RTL debugging due to easier comprehension of system state and a reduction
in unnecessary details that can obscure the underlying cause of problems.
By coding at a higher level, TLM IP requires fewer lines of code, and thus has fewer bugs.
Functional bugs are detected and resolved earlier in the design cycle. Te total verifcation efort
can thus be greatly reduced.
It is easier to identify and understand bugs at the abstract TLM level, and it is easier to fx bugs at
this level, because there are fewer details. A TLM fow makes it possible to verify each concern at
the most appropriate level of abstractionfor example, TLM for functionality, and signal-level
verifcation for the implementation of interfaces afer they have been fully refned.
Te TLM verifcation fow begins with algorithmic functional verifcation, which allows functional
validation with sofware, and proceeds to TLM functional verifcation (Figure 5). Following
compilation with the C-to-Silicon Compiler, designers can move on to micro-architectural
RTL verifcation and RTL-to-gates equivalence checking. In addition to supporting untimed
modeling, which allows very fast simulation, TLM also allows designers to make refnements that
progressively include micro-architectural details and refne timing accuracy. Figure 5 lists the
types of hardware and sofware verifcation that can be performed at each of the corresponding
stages of the design fow.
Hardware/Software Co-Verication and Early Software
Development
TLM models are at a sufciently high level of abstraction, and execute quickly enough, to make
hardware/sofware co-simulation practical. Designers can co-simulate embedded sofware
with TLM hardware models to check for hardware/sofware dependencies and to begin early
debugging of hardware-dependent sofware. Technologies, such as constrained-random stimulus
and coverage of hardware/sofware interactions, can be applied.
Virtual platforms used for early sofware development and debugging may include subsystems
comprised of SystemC TLM models. Because of their fast execution, models developed for
hardware design creation can also be used to accelerate sofware design.
Preface
xvi i
Figure 5: TLM verication ow (left) and verication requirements
for each stage (right)
Supporting Combined TLM and RTL Verication
At the SoC level, mixed TLM and RTL functional verifcation is required for two reasons: (1)
because of the reuse of a large amount of legacy RTL IP and (2) because it will still be necessary
to perform detailed RTL functional verifcation for portions of the design, due to functionality
created to support the implementation that contributes to the system-level functionality. Tus,
some verifcation tasks will still be done only at RTL. Tis includes micro-architectural structural
verifcation for such attributes as memory access sequences, state transition coverage or error
detection, and correction logic. Communication protocol compliance may also need to be
verifed at both the signal and cycle-accurate levels.
Mixed TLM/RTL verifcation is facilitated when verifcation artifactsincluding verifcation
plans (vPlans), UVM Verifcation Components (UVC), testbenches, sequences, tests, checks,
and coverageare all available and reusable across abstraction levels unifed within a Universal
Verifcation Methodology (UVM) framework. Functional verifcation planning and management
across both TLM and RTL lets teams track and control verifcation at each level in a mixed-
level design and combine the results as needed, ensuring overall quality. Tus, the verifcation
environment works best when it supports multiple levels of abstraction and multiple use modes.
www. cadence. com xvi i i
TLM-Driven Design and Verication Methodology
Te Universal Verifcation Methodology (UVM) is an industry-standard verifcation library and
methodology developed by Accellera. Te UVM is based on the Open Verifcation Methodology
(OVM) and will gradually supersede it. For the purpose of this book, we will refer to the UVM, as
the 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 TLM. Currently, the UVM methodology description is being extended to show
how TLM and RTL models can be combined in a comprehensive regression solution. Tis will
facilitate the creation of Verifcation IP (VIP) that works in a multi-language, mixed TLM/RTL
verifcation environment and can also be used with a hardware emulation/acceleration solution.
A multi-level functional verifcation testbench is based on transactions, and when it is connected
to RTL-based IP, buses, or interfaces, a transactor is needed to translate between the transaction-
level domain and the pin-accurate RTL domain. Similarly, transactors are needed to connect
TLM IP blocks to buses or interfaces on RTL IP blocks. A TLM-based methodology must
consider how these transactors operate in order to gain the maximum benefts of mixed TLM/
RTL verifcation. Some transactors may be commercially available, while others are proprietary,
created by the project team and managed as verifcation library components.
Many projects are implementing TLM for new IP only, gradually building up a library of TLM
IP, whereas other teams are embracing a TLM methodology for all major IP blocks in mission-
critical projects. Eventually, SoCs will emerge in which all IP golden source is at the TLM level.
In these cases, benefts of quality, productivity, and ease of debugging will be more pronounced
than with mixed TLM/RTL projects. Tis makes it possible to achieve SoC TLM functional
verifcation, including SoC-level architectural analysis and optimization.
Reusing VIP from TLM through RTL Verication
VIP reuse has now become main stream because the time required to create high-quality
verifcation environments ofen exceeds the time needed to create the design IP itself. Te wide
employment of standard protocols has driven the development of a fast-growing commercial
VIP market. Today, most of this VIP is at the Register-Transfer Level. TLM-enabled VIP will also
be needed, but it must be reusable for mixed TLM/RTL functional verifcation.
RTL functional verifcation is dominated by advanced testbenches that use constrained-random
stimulus generation. TLM-enabled VIP should be operable in testbenches for TLM, mixed TLM/
RTL, accelerated verifcation, and RTL functional verifcation. Tat same VIP must allow the
application of metric-driven verifcation as customers apply coverage metrics at all levels of
verifcation abstraction. Finally, supporting embedded sofware and directed tests is necessary
for verifcation teams who work closely with architects and sofware engineering teams.
Accelerators are seeing increased usage for system-level verifcation that includes one or more
modules at the RT level; therefore, VIP must be equally applicable to these environments. Tis
requires transaction-level interfaces that can serve as a bridge between sofware simulation,
hardware acceleration, and testbenches.
Preface
xi x
Incremental Design Renement from Algorithm to
Micro-Architecture
Te TLM-driven design and verifcation fow has several distinct phases, including algorithm,
architecture, and micro-architecture phases and refnement transitions between those phases
(Figure 6). Te frst phase, algorithm design and verifcation, may involve C++ or a product
such as MATrix LABoratory (MATLAB) or Simulink from Te Mathworks. Designers defne
a verifcation plan, which will be used throughout the entire verifcation fow, and complete
initial sections that concentrate on key algorithmic features, verifcation of input/output (I/O)
functionality, and the stimulus sequences for key use cases.
Moving to phase two (the architecture level), designers use a transaction-level modeling
methodology to defne the architecture and interface protocols. Tey reuse and expand the
verifcation plan and verifcation environment according to a multi-level verifcation methodology,
to address key architecture and interface protocol features. Tis requires the creation of additional
stimuli, checks, assertions, and coverage
In a fnal transition to phase three (the micro-architecture level), following synthesis with the
C-to-Silicon Compiler, designers again extend and enhance the verifcation plan to cover micro-
architectural detail in the stimuli, checks, assertions and coverage.
Figure 6: A TLM-driven IP design and verication ow encompasses algorithmic,
architectural, and micro-architectural verication
www. cadence. com xx
TLM-Driven Design and Verication Methodology
The Methodology
TLM-driven design and verifcation will ultimately enable TLM to replace RTL as the golden
source for most design components. Te advantages are compellingmuch faster design and
verifcation times, easier IP reuse, and fewer bugs. Designer productivity will take the biggest
jump since the advent of RTL design. But the transition will not occur overnight. Te adoption
of TLM-driven design and verifcation will occur one IP block at a time as new IP is created.
And some design components will be best designed directly in RTL. Tus, it must be possible to
combine new TLM IP with legacy RTL IP in design and verifcation 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 fow based on these principles
and decide if they would beneft from the adoption of such a methodology.
Te fow will be described using a number of examples to demonstrate various aspects of the
methodology. In addition, since this methodology is still evolving, regular updates to this book
will be made available as additional pieces of the methodology are defned, refned, and improved.
Cadence can also supply a wide range of additional materials to help with adoption, including
the 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 Times. May 22nd 2009 http://bits.blogs.nytimes.
com/2009/05/22/counting-down-to-the-end-of-moores-law/