Untitled - OhioLINK ETD Center

Improving Bug Visibility using System-Level Assertions andTransactions

A thesis submitted to the

Division of Research and Advanced Studiesof the Univeristy of Cincinnati

in partial fulfillment of the requirementsfor the degree of

Master of Science

in Computer Engineeringthe School of Electronic and Computing Systemsof the College of Engineering and Applied Science

University of CincinnatiJuly 2013

by

Kristin M. Barber

B.S. Computer EngineeringShawnee State University, Portsmouth, OH

May 2010

Thesis Advisor and Committee Chair: Dr. Carla Purdy

Abstract

The increase in complexity of hardware designs over the last several years has been unprece-

dented. Due to improved process technologies, the ability to integrate a number of macro

components onto a single piece of silicon has enabled the phenomenon known as systems-

on-chip (SoCs). Debugging such a design is cumbersome with traditional signal-level tools

and the problem is exacerbated when the bug is not solely hardware-related but due to an

interaction between hardware and software. As a result of increasing complexity, new design

practices have been adopted to alleviate this burden. These practices rely on a high-level

approach to modeling, known as transaction-level modeling (TLM).

This approach can also be useful to verification engineers; representing information at the

transaction-level instead of the signal-level will provide faster, more intuitive detection of er-

rors. Following this logic, the focus of this work has been to develop a method for abstracting

register-transfer level (RTL) information into a transaction-level view of the system. This

was accomplished by formally defining SoC behavior through finite state automata, creating

a computational model of legal and erroneous activity throughout the system. A debug envi-

ronment is also proposed which creates useful visualizations to represent system-level traffic

and relationships from the results of simulation data applied to this model. Through case

studies the usefulness and effectiveness of the methodology is demonstrated.

i

To my grandparents.

iii

Acknowledgements

I would like to thank my advisor, Dr. Carla Purdy, for her guidance and support. Thank

you to Dr. Wen-Ben Jone and Dr. George Purdy for serving as committee members. I would

also like to thank Dr. Janna Gallaher, Ted Kosan and Dr. Jim Hudson for their inspiration.

Finally, I would like to thank my family and friends. Thank you to my grandfather, Dale, for

your encouragment and to my grandmother, Marilyn, for your never-ending love and support.

iv

Contents

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Organization of Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Background 7

2.1 System-On-Chip Architectures (SoCs) . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Network-On-Chip Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Paradigm Shift: Electronic System Level Design . . . . . . . . . . . . . . . . . 10

2.3.1 Coping with Design Complexity . . . . . . . . . . . . . . . . . . . . . . 12

2.3.2 IP Reuse and Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Transaction-Level Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4.1 Definition of a Transaction . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4.2 SystemC: a Language for ESL . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.3 RTL Complement, Not Replacement . . . . . . . . . . . . . . . . . . . . 19

2.5 Verification Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.5.1 Verification Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5.2 Formal Verification Techniques . . . . . . . . . . . . . . . . . . . . . . . 22

2.5.3 Dynamic (Simulation-Based) Verification Techniques . . . . . . . . . . . 23

2.6 Assertion-Based Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.7 AMBA 2.0 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

v

CONTENTS

2.7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.7.2 Advanced High Performance Bus (AHB) . . . . . . . . . . . . . . . . . . 27

2.7.3 Advanced Peripheral Bus (APB) . . . . . . . . . . . . . . . . . . . . . . 30

3 Related Work 32

3.1 Transactions in Verification: UVM . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2 Post-Silicon Validation: Design for Debug . . . . . . . . . . . . . . . . . . . . . 33

3.3 Formal Specifications for System Behavior . . . . . . . . . . . . . . . . . . . . . 34

4 Overview of the Approach 36

4.1 Communication-Centric Verification . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Event Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3 Forming a Transaction Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5 Implementation Details 41

5.1 Environment Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1.1 Transaction Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1.2 Event Sequencer Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1.3 Transaction Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2 System Under Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.3 Case Study: AMBA AHB Incrementing Burst . . . . . . . . . . . . . . . . . . . 49

5.4 Case Study: Power Management Scenario . . . . . . . . . . . . . . . . . . . . . 51

5.4.1 Power Domain State Transition Sequence . . . . . . . . . . . . . . . . . 51

5.4.2 Property-Checking with Assertions . . . . . . . . . . . . . . . . . . . . . 54

6 Conclusions 56

6.1 Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.2 Suggestions for Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Bibliography 58

vi

CONTENTS

A SingleReadTransaction.java 65

B PSC Register Definitions 68

vii

List of Figures

1.1 An illustration of Moore’s Law [1] . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Canonical hardware view of SoC [2] . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 A multimedia MPSoC [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Relative delay comparison of wires vs. process technology [3] . . . . . . . . . . 11

2.4 An example of a (mesh type) NoC interconnect fabric [3] . . . . . . . . . . . . 11

2.5 Designer productivity gap [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.6 ESL design flow for MPSoCs [3] . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.7 Model classes and their granularity [4] . . . . . . . . . . . . . . . . . . . . . . . 16

2.8 Timing points in bus transactions [5] . . . . . . . . . . . . . . . . . . . . . . . . 17

2.9 System modeling graph [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.10 SystemC components [7] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.11 SystemC interfaces [7] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.12 Testbench for 2-input AND gate [8] . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.13 PSL example expression [9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.14 A typical AMBA system [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.15 AHB multiplexer interconnection scheme [10] . . . . . . . . . . . . . . . . . . . 27

2.16 Basic data transfer on AHB bus [10] . . . . . . . . . . . . . . . . . . . . . . . . 29

2.17 Example of a four-beat incrementing burst [10] . . . . . . . . . . . . . . . . . . 30

2.18 State diagram representing activity of the APB bus [10] . . . . . . . . . . . . . 31

4.1 Process to capture an AMBA request event . . . . . . . . . . . . . . . . . . . . 38

viii

LIST OF FIGURES

4.2 Anatomy of an AMBA AHB single read automaton . . . . . . . . . . . . . . . . 39

5.1 UML diagram of the major components of the TLMDebugger . . . . . . . . . . 43

5.2 UML class diagram showing the inheritance of TransactionDefinition . . 43

5.3 Generic automaton modeling a transaction sequence . . . . . . . . . . . . . . . 44

5.4 Archetype of TransactionDefinition’s canTransition() method . . 45

5.5 EventOracle’s activate() method . . . . . . . . . . . . . . . . . . . . . 48

5.6 TransactionBuilder’s run() method . . . . . . . . . . . . . . . . . . . 48

5.7 System Under Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.8 AMBA AHB Incrementing Burst Automaton . . . . . . . . . . . . . . . . . . . 50

5.9 Debug environment highlighting burst transaction . . . . . . . . . . . . . . . . 50

5.10 Power domain transition automaton . . . . . . . . . . . . . . . . . . . . . . . . 53

5.11 Debug environment highlighting power domain transition . . . . . . . . . . . . 54

5.12 Debug environment highlighting power domain transition with error . . . . . . 55

B.1 PTSTAT Register Definition [11] . . . . . . . . . . . . . . . . . . . . . . . . . . 68

B.2 EPCPR Register Definition [11] . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

B.3 PTCMD Register Definition [11] . . . . . . . . . . . . . . . . . . . . . . . . . . 69

B.4 PDCTLn Register Definition [11] . . . . . . . . . . . . . . . . . . . . . . . . . . 69

ix

List of Tables

5.1 Power domain by module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

x

Chapter 1

Introduction

Over the last 40 years, Moore’s Law has proven to be remarkably accurate [12]. Moore’s Law

alleges that the number of transistors in an integrated circuit will double approximately every

two years; this prediction is corroborated by the growing degree of integration in every tech-

nology generation since and illustrated in Figure 1.1. Starting with the Intel 4004 single-chip

CPU introduced in 1971 with 2300 transistors, on-die device counts have grown by six orders

of magnitude to over 2.3 billion in the 2010 Intel Xeon Nehalem-EX. This rapid increase in

functional density has led to the proliferation of richly-integrated substrates in the form of

chip multi-processors and systems-on-chip (SoCs).

Increasing transistor densities have also led to unprecedented processing capabilities, de-

sign complexity and verification efforts. While design sizes have grown exponentially over time,

verification complexity has been growing hyper-exponentially since the number of states that

must be verified is exponential in the size of the design. The size of the verification team and

effort typically outweighs that of the design team by two-to-one. Verification of an advanced

SoC at the time of this writing potentially involves tens of millions of lines of register-transfer

level (RTL) and testbench code, multiple (10 or more) protocols on a single chip, hundreds of

thousands of assertions, tens or hundreds of power domains and over a terabyte of coverage

data to analyze.

Functional verification is widely acknowledged as a major bottleneck in today’s SoC design

1

Chapter 1. Introduction 1.1. Motivation

methodology. In spite of extensive efforts in functional verification, many SoC designs fail at

the very first use as a result of functional errors. Some studies estimate verification costs to be

as high as 70% of the total design cost. What was once a major challenge for single-processor

SoCs is today a showstopper for heterogeneous, multi-core SoC architectures. System-level

modeling and verification techniques are a promising approach to capture as many bugs as

possible in the early stages of a design and thereby drastically reduce the overall verification

effort, accelerating the time-to-market. The challenge is to increase designer and verification

engineer productivity to keep pace with Moore’s law.

Figure 1.1: An illustration of Moore’s Law [1]

1.1 Motivation

The task of debugging large embedded SoC platforms poses a novel challenge for the design

team or engineer employing a traditional RTL-based approach. A substantial amount of effort

is spent analyzing cycle-by-cycle waveform visualization by hand in an attempt to identify the

system-level transactions corrupted by logical errors. This level of detail is simply inadequate

2

Chapter 1. Introduction 1.1. Motivation

for the evolving scope of the problem [13, 14, 15, 16, 17].

Debugging RTL code in complex embedded systems can produce a forest of data. Typ-

ically, RTL is the starting point and workhorse for design implementation because the tool

flow from RTL to silicon is mature, proven and supported by abundant EDA tools for back-

end realization [18]. RTL’s strength at the design implementation level is also the reason

for its unsuitability and unwieldiness in the context of verification, generating a plethora of

waveforms that require debug analysis [18]. RTL languages were designed for the creation of

models that are accurate by sequence, cycle, and timing; thereby making the process of logic

synthesis relatively straightforward. This detail, however, has undesirable side effects when it

comes to verification stages producing literally billions of waveforms and making holistic anal-

ysis difficult. Device debug is centered on a fundamental understanding of its behavior, with

inter-block communication being a key aspect of overall functional operation. Understanding

bus interaction at the signal level, given the complexity of modern bus protocols, is time

consuming due to the intense nature of signal activity, which hides essential information [18].

SoCs today look very different from those of the early 2000s. They incorporate more

features and functionality, with many discrete components being replaced by programmable

counterparts in an effort to offset the cost of silicon errors with a software patch as opposed

to a metal spin. The increasing degree of programmability and blending of hardware and

software in today’s SoCs exacerbates the need for improved verification practices and tech-

nologies. As today’s SoCs comprise multiple programmable processors that interact through

concurrent programmable interconnects, their behavior is very complex, and designing hard-

ware and software which is correct at the first implementation has become quite difficult.

Incremental improvements to todays tools will not be sufficient to deliver an order of magni-

tude boost to verification productivity, given the complexity of todays designs.

Rising development costs provide another impetus for creating improved tools, since ver-

ification accounts for about half of a system’s development effort [19]. According to the US

National Institute of Standards and Technology, increased testing and more effective debug-

ging could trim one-third of nearly $60 billion that bugs cost the country each year [20].

3

Chapter 1. Introduction 1.2. Goals

Innovations in verification, particularly with respect to debug, are essential.

A relatively new concept to the digital design flow, transaction level modeling, proposes a

solution to many of the limitations hampering effective debug of contemporary SoCs. Moving

to the transaction level allows the designer to separate out important elements of a design

and focus on them [13]. This approach ensures that design behaviour is made clearer, thereby

increasing the probability that problems will be detected early and decreasing the overall

debug time [13].

Debug must be conducted at a system level, where the computation threads and com-

munication threads interact. Transactions are the result of processor instructions that cause

activity on the interconnect and other IP blocks such as memories. Transactions therefore

are a natural interface between computation and communication [21]. Transactions are ideal

for debug analysis, as they allow for it to be performed at an abstract yet meaningful level,

revealing an otherwise obstructed view of system activity and increasing comprehension.

1.2 Goals

The goal of this thesis is to introduce a method by which expected system-level functionality

in terms of transactions can be rigorously defined, primarily for the purpose of aiding sys-

tem behavior comprehension and secondarily as a self-checking mechanism in the context of

verification. These definitions will ideally serve to expedite the identificaton of error sources,

decreasing the overall debug effort.

Transaction definitions under this method take the form of finite state automata, with

transition conditions dependent on functional unit and interconnect specifications. The in-

vocation of a state transition is also a convenient point to instrument self-checking using an

assertion-based approach. A verification engineer would enumerate the set of correct and

legal actions for each operation of interest in the system and encode these into a finite state

automaton. These automata together form a model of recognized behavior and error condi-

tions that can be used to resurrect a system-level perspective of the design under test from

4

Chapter 1. Introduction 1.3. Organization of Thesis

signal-level data produced during simulations.

Innovations in pre-silicon debug are generally aimed at improving understanding of the

complete breadth of system activity through enlightening visualizations. A debug solution

would not be complete without a means by which the information can be presented in an

intuitive and instructive fashion. Therefore, this thesis also presents an example debug envi-

ronment to illustrate how these transaction definitions can be used to enable more effective

analysis. The debug environment contains an underlying event sequencer engine, responsible

for coordination of state transitions, along with a graphical front-end displaying the temporal

flow of events, relationships between events, and annotations for assertion violations provid-

ing automated error detection. The environment also incorporates several auxillary features,

such as synchronization of memory and configuration registers, to expedite the localization of

interesting points.

The difficulty of system-on-chip verification is partially due to the continued increase in

functional density, but equally exacerbated by the increase in module programmability. A

programmable module is defined by two distinct factions, its hardware and firmware. For a

programmable module, it now becomes essential to verify not only that the hardware which

executes the firmware is functionally correct, but also that the firmware itself is behaving as

expected and satisfying intent as per the module’s specification. The functionality of a pro-

grammable module generally encompasses the cooperation of its partitioned control between

hardware and software. This solution aims to ease the verification of hardware/software co-

design by providing constructs which flexibly adapt to describe high-level features of a system

and are hardware/software agnostic.

1.3 Organization of Thesis

The remainder of this thesis is organized into the following chapters:

• Chapter 2 gives an overview of state-of-the-art system-on-chip and related architec-

tures, linking them to the paradigm shift in design and verification methodologies. A

5

Chapter 1. Introduction 1.3. Organization of Thesis

detailed explanation of transaction-level modeling is given. Verification fundamentals

and assertion-based verification are reviewed and the AMBA 2.0 protocol is described.

• Chapter 3 discusses previous research in transaction-level modeling in both verification

and validation. Assertion-based debug solutions are reviewed, as well as research in

formal specifications for system functionality.

• Chapter 4 describes the testbench mechanics necessary for event extraction and ex-

plains how finite state automata can be used to formally define system-level functionality.

• Chapter 5 provides a description of the author’s implementation of system-level as-

sertions and transaction formation from RTL simulation data. The set of components

used to create and evaluate formal models of transaction sequences is discussed. The

debug environment and system-on-chip architecture used for context in deploying this

method are also described. Finally, a protocol and system-level transaction use case are

presented as examples.

• Chapter 6 summarizes the contributions of this work and concludes this thesis. Future

directions of research with respect to this solution are proposed.

6

Chapter 2

Background

This chapter contains the background information necessary to understand the study and so-

lutions proposed in this work. System-On-Chip architectures and their successor, Networks-

On-Chip, are examined in detail. Next, the recent paradigm shift in design and verification

methodolody is explained along with a description of transaction-level modeling and a sum-

mary of verification fundamentals. Finally, an overview of the AMBA 2.0 protocol is given.

2.1 System-On-Chip Architectures (SoCs)

The continued improvements in silicon technology have led to increasing levels of component

integration with each passing technology generation [22, 23]. Technology scaling has enabled

a reduction in transistor size, allowing more transistors to be integrated into the same area.

This increase in transistor counts has created the possibility for what are known as systems-on-

chip (SoCs); an integrated circuit designed for complete system functionality, incorporating an

ensemble of heterogeneous processing and computational units [2]. A system-on-chip provides

general-purpose computing capabilities along with highly specialized functions tailored to a

particular design domain. Figure 2.1 shows a trivial example of the standard organization

for current system-on-chip architectures, while Figure 2.2 shows a contemporary MPSoC

(multiple processor system-on-chip) design targeting the multi-media platform domain.

SoCs are typically composed of several programmable processors, various levels of on-chip

7

Chapter 2. Background 2.2. Network-On-Chip Architectures

caching and shared memory, external interfaces (e.g. off-chip memory), hardware coprocessors

(e.g. Digital Signal Processors (DSPs) and Graphics Processing Units (GPUs)), dedicated

peripherals (e.g. timers and interrupt controllers) and an on-chip communication architecture

that serves as the interconnection fabric for communication between the components [1].

The communication architecture for a particular SoC can take many forms, depending

on the performance, power and cost constraints of the application. Depending on these

constraints, design exploration will begin to determine the topology and protocol parameters

which best satisfy them. The topology of the communication architecture refers to how the

buses are interconnected together, and how the various components are mapped to each of

the buses. Bus topologies include the shared bus, hierarchical shared bus, ring bus, ad-hoc

bus and the crossbar bus. The protocol parameters refer to arbitration schemes, bus widths,

bus clock frequencies, buffer sizes and burst transfer sizes [3].

2.2 Network-On-Chip Architectures

The dual forces of advances in technology and an insatiable demand for convergent com-

puting devices have fueled the need for complex chips that incorporate multiple processors

(MPSoCs). Although bus-based topologies are attractive due to their simplicity and suitable

performance, they are reaching limits in terms of the number of components they are able

to support [24]. As the number of projected processing cores per chip moves from tens to

hundreds, a global bus will be unable to scale with the increasing demand and will become

an unacceptable bottleneck. The communication architecture of such a system must also be

capable of supporting the quality of service needs associated with MPSoCs, such as multiple

modes of operation and varying levels of real-time response [25].

Besides congestion concerns for MPSoC bus-based topologies, there are also significant

technological issues. The power consumption of a wire will be proportional to the length of

the wire and its switching frequency. Hence, global wires will consume significantly more

power than small, local wires. Chips with a centralized interconnection system will consume

more energy for the same task than chips with a distributed interconnection system [26]. In

8

Chapter 2. Background 2.2. Network-On-Chip Architectures

Figure 2.1: Canonical hardware view of SoC [2]

Figure 2.2: A multimedia MPSoC [3]

9

Chapter 2. Background 2.3. Paradigm Shift: Electronic System Level Design

addition, deep sub-micron transistor scaling has several unfortunate side-effects, necessitating

a communication fabric capable of providing reliable, deterministic communication between

the cores on a chip. These side-effects include large wire delays – depicted in Figure 2.3 –

on long interconnects due to capacitive coupling effects, greater probability of transmission

errors due to crosstalk noise, and non-determinism due to process, die and temperature vari-

ations [27, 28].

In response to these challenges, network-on-chip communication architectures were pro-

posed. Networks-on-chip (NoCs) utilize an approach which applies networking theory and

methods to on-chip communication. NoCs use packets to route data from the source to the

destination component, via a network fabric that consists of switches and interconnection

links [3]. Data is packetized according to an adapted version of the Open Systems Intercon-

nection (OSI) (ISO/IEC 7498-1) [29] protocol stack and dispatched using distributed routing

algorithms to minimize congestion.

NoCs tackle issues of variability and determinism with their regular, controlled struc-

ture and inherent ability to handle synchronization [24]. An example of a (mesh type) NoC

interconnect fabric is shown in Figure 2.4.

2.3 Paradigm Shift: Electronic System Level Design

The continuing improvements in silicon technology provide great opportunities; the avail-

ability of such a large number of devices on a chip enables new ways of realizing system

functionality using combinations of hardware and software.

Unfortunately, these advances have also created the infamous designer-productivity gap.

As can be seen from Figure 2.5, progress in silicon technology is far outstripping our ability

to effectively utilize these transistors for working designs in a reasonable amount of time.

As product lifetimes continue to shrink, time-to-market becomes a key design constraint [3].

The quest for higher productivity involves a combination of abstraction and reuse [22].

10


Figure 2.3: Relative delay comparison of wires vs. process technology [3]

Figure 2.4: An example of a (mesh type) NoC interconnect fabric [3]

11


Figure 2.5: Designer productivity gap [3]

2.3.1 Coping with Design Complexity

Since the advent of the digital integrated circuit, the electronic design community has been

replacing implementation specific details with higher-level abstractions in order to cut down

complexity and increase productivity. Circuits were replaced with gates and gates were later

replaced by register-transfer data flow; these representations are then transformed into silicon

by a combination of automated and manual means.

Since the integrated circuit has become an integrated system, a new abstraction is nec-

essary to harmonize the representation of both hardware and software [22]. System-on-chip

complexity has pushed the need for once again altering the abstraction level at which digital

designs are represented to acheive an intermediate level of abstraction between paper specifi-

cation and RTL models [2]. Instead of the classical approach where separate teams work on

various incoherent models, SoC design neccesitates an expanded space, linking all phases of

the design through a centralized methodology.

This leads to the concept of Electronic System Level (ESL) [30], a generic term for a set

of abstractions which are adequate for the design representation of SoCs. It complies with

the need for hardware and software codesign, while building upon legacy hardware design

representation [22]. An illustration of the ESL design flow and various levels of abstraction

12


can be seen in Figure 2.6.

Figure 2.6: ESL design flow for MPSoCs [3]

2.3.2 IP Reuse and Integration

The electronics industry has entered the era of billion-gate chips. Demands for powerful,

convergent products and today’s silicon technology have moved SoCs from leading edge to

mainstream design practice. As chips have changed, so has the way they are designed. De-

signing chips by writing all of the RTL modules from scratch, integrating RTL blocks into a

top-level design, and doing flat synthesis followed by placement no longer works for complex

designs [8].

Design reuse – the use of pre-designed and pre-verified Intellectual Property (IP) – is now

the cornerstone of SoC design [27]. It is the only methodology that allows contemporary

billion-gate chips to be designed at an acceptable cost and quality. Without reuse, the elec-

tronics industry will simply not be able to keep pace with the challenge of delivering devices

that consumers expect. A reuse-based methodology for system-on-chip design has become

13

Chapter 2. Background 2.4. Transaction-Level Modeling

essential.

The main pre-requisite for creating SoC designs is a set of reusable IP blocks that sup-

port plug-and-play integration. IP blocks are the highest-level building blocks of an SoC. A

library of reusable blocks with various timing, area, and power configurations is the key to

SoC success, as it allows mix-and-match of different IP blocks so that the SoC integrator can

apply tradeoffs. An effective block-based design methodology requires an extensive library of

reusable blocks [31]. The developers of these blocks must, in turn, employ a design method-

ology that consistently produces reusable blocks [2]. The process of creating a reusable IP

block, however, differs from the traditional application-specific integrated circuit (ASIC) de-

sign approach. The requirements are different and more complex, and distinct in a number

of ways. The bar is high, and many semiconductor companies struggle with the challenge of

creating true IP for internal reuse, while dealing with the realities of getting the chips out on

schedule and under budget. There have been wholesale changes in the design flow to fully

enable reusable design since the developer must anticipate all of the applications in which the

IP block may be used during development [31].

The heart of any SoC design is arguably the communication infrastructure. In general,

the performance of the SoC design depends heavily upon the efficiency of its bus structure.

Besides meeting performance goals, on-chip buses must provide a well-defined environment for

integrating reusable blocks from a variety of sources. Success relies on the ability to connect

existing components reliably, in a plug-and-play fashion [24]. In the early days of reuse-based

design, the wide variety of buses presented a major problem [2]. The solution to this problem

is clearly to have a standard bus, allowing reusable blocks to be developed with a single in-

terface that will allow it to be used in a wide variety of chips. Such standards include ARM’s

AMBA, IBM’s CoreConnect and OpenCores’s Wishbone protocols [32, 28].

2.4 Transaction-Level Modeling

One particular ESL technique is transaction-level modeling (TLM). Transaction-level mod-

eling is a high-level approach to modeling digital systems where details of communication

14


among modules are partitioned from the details of the implementation of the functional units

or of the communication architecture [33]. Low-level details about pins, wires and waveforms

of the information exchange are encapsulated such that emphasis is placed on the functional-

ity of the data transfers – what data are transferred to and from what locations – rather than

the actual implementation (protocol) used for the transfer [33]. TLM highlights the concept

of separating communication from computation within a system [34].

TLM platforms serve as a unique reference for software and architecture teams to conduct

early software development and architectural analysis. The notion of a ”model of computa-

tion” is fundamental to system-level design [35] and also to understanding TLM. A modeling

language provides a model of computation by supplying support for time and data abstrac-

tion [8].

The time abstraction in a simulator refers to how often the entire design state is consistent.

In RTL models, every net must be consistent after every change. Cycle-accurate abstraction

requires the design only to be consistent on the clock edges, eliminating all events that occur

between clock edges. In a transaction-level model, the design state must be consistent at the

end of each transaction, each of which might span many clock cycles [8].

Data refers to the objects communicated between components. Data in an RTL model

is represented by individual bits passed via nets between components. In transaction-level

models, data is in the form of transactions, heterogeneous structures that contain arbitrary

collections of elements [8].

2.4.1 Definition of a Transaction

It is meaningful to define exactly what a transaction is in the context of modeling digital

systems. A transaction can be loosely defined as a single transfer of control or data between

two entities. In a bus-based design, reads and writes on a bus can be considered transactions.

In a packet-based communication system, sending a packet is a transaction [8]. A transaction

can be viewed as nothing more than a container of data transferred between a system master

and at least one system slave, possibly with the help of other system components, over a period

15


of time [5]. It is the data transfer or synchronization between two modules at an instant or

event determined by the hardware/software system specification [34]. Transactions represent

system level behaviors and are made up of sequences of related events [36]. TLM allows a

wide variety of modeling styles and abstractions; it is not clearly defined in the literature.

Transactions can be formed at various boundaries and levels of abstraction (granularity)

with respect to the model’s timing fidelity. This thesis focuses on a granularity of data and

arbitration handling similar to that outlined in the work of Schirner and Domer [4], which

classifies abstraction levels according to the timing points of on-chip communication protocols.

Schirner and Domer define three levels of granularity applicable to any bus protocol, as can

be seen in Figure 2.7. A more precise illustration demonstrating this type of protocol-level

abstraction is shown in Figure 2.8, along with a taxonomy of all possible timing accuracies

in Figure 2.9. To see an example application of these definitions, consider the high timing

fidelity case in Figure 2.8. This case is cycle-accurate since all of the significant events relating

to the protocol are captured.

Figure 2.7: Model classes and their granularity [4]

16


Figure 2.8: Timing points in bus transactions [5]

Figure 2.9: System modeling graph [6]

17


2.4.2 SystemC: a Language for ESL

SystemC is an enabler for the ESL design flow. Strictly speaking, it is a C++ class library

capable of satisfying the requirements imposed by ESL and TLM [7]. SystemC implements

the structures necessary for hardware modeling by providing constructs that enable concepts

of time, hardware data types, hierarchy and structure, communications and concurrency. A

SystemC model contains one or more modules, which can contain instances of other modules.

Communication among modules and simulation processes is accomplished through various

combinations of ports, interfaces, and channels. A summary of SystemC components is given

in Figure 2.10.

A language for ESL model development needs to support TLM concepts, such as easy

substitution of one communication implementation for another as well as the separation of

communication and computation; this separation is accomplished through the use of inter-

faces. By using interfaces to connect channels, we can implement modules independent of the

implementation details of the communication channels [7]. Recall from object-oriented pro-

gramming that an interface specifies a group of methods defining some behavior for an object

without tying that behavior to any implementation. An interface defines a set of methods

that a class must implement [37]. Interfaces form the heart of the transaction-level modeling

standard [38].

Interface classes are used to declare the access methods that channels provide. Channels

are used to implement the access methods declared within interfaces. Together, interfaces and

channels provide a powerful and very flexible way to model communication and synchroniza-

tion within systems [33]. To see an example of an interface’s ability to separate communication

from computation, consider Figure 2.11. The modules depicted in this figure can easily have

the primitive FIFO channel swapped for another channel (in this case, Big bus chan) without

having to change the defintions of the modules themselves – all that matters is that both

channels implement the same interface [7].

SystemC transaction-level models use software function calls to model the communication

between blocks in a system. This is in contrast to hardware RTL and gate-level models,

18

Chapter 2. Background 2.5. Verification Fundamentals

which use signals to model the communication between blocks. For example, a transaction-

level model would represent a burst read or write transaction using a single function call,

with an object representing the burst request and another object representing the burst re-

sponse [39]. An RTL hardware description language (HDL) model would represent such a

burst read or write transaction via a series of signal assignments and signal read operations

occuring on the wires of a bus [39].

2.4.3 RTL Complement, Not Replacement

Although initiating the design process using a high-level ESL model as the entry point has

offered many productivity gains, there is no established methodology for automatic synthesis

of ESL to RTL1. The advantages of the ESL design flow are to allow for earlier software

development by providing an executable specification, architectural exploration and reuse as

verification ”golden” reference models. Once the architecture and on-chip protocol have been

selected, RTL development will begin and can then be synthesized to a gate-level description

according to traditional design flows and used for fabrication.

ESL is a complement to RTL, but not a replacement. RTL still prevails as a necessity

due to technical limitations and for design confidence. The ESL methodology was developed

to lighten the burden of design teams facing the increasing complexity of digital systems;

however, as RTL remains a pivotal aspect of the design process today, a similar change in the

nature and methods of verification is also required [3, 40].

2.5 Verification Fundamentals

The remainder of this thesis focuses on verification practices of digital systems, particularly

those in response to the changing computing landscape. Therefore, an overview of verification

fundamentals is useful and will be provided in this section.

1The area of ESL to RTL synthesis has gained attention and significant research effort [34].

19


Figure 2.10: SystemC components [7]

Figure 2.11: SystemC interfaces [7]

20


2.5.1 Verification Principles

Functionally verifying a design means comparing the designer’s intent with observed behavior

to determine their equivalence. To tell if a design works, you must compare it with some

known reference that represents the designer’s intent. Every testbench has some kind of

reference model and a means to compare the function of the deisgn with the reference [8].

Verifying a design involves answering two questions: does it work and are we done yet?

The first question comes from the essential idea of verification already mentioned; it asks if the

design matches the intent. The second question asks if we have satisfactorily compared the

design and intent to conclude whether the design does indeed match the intent. Are-we-done

questions are also called functional coverage questions, questions that relate to whether the

design is sufficiently covered by the test suite in terms of design function [8]. To illustrate

these concepts, let’s consider how to verify one of the most fundamental devices in a digital

electronic system – the AND gate.

Assume there is a model of a 2-input AND gate, such as that pictured in Figure 2.12,

and also that the chosen verification technique is simulation. In order to determine that this

model functions correctly, we will need to monitor its output under a variety of inputs. Since

the number of possible input combinations is tractable, it is possible to exhaustively apply all

inputs in accordance with the AND gate’s truth table. It is then reasonable to conclude that

the verification of this gate can stop when all rows of the truth table have been tested and

have been shown to work properly.

Common industry estimates are that functional verification takes approximately 70% of

the total effort on a project, and that the verification process is the single largest issue [41].

This estimate becomes plausible when considering the completeness criteria for verification, or

rather, that most designs may never be fully tested. This is mostly due to the impracticality

of running a complete test. Today, the usual verification method to discover design errors is

simulation. The implementation is expressed in terms of a hardware description language like

Verilog or VHDL, which can be simulated. Input patterns are created which reflect typical and

critical execution traces. By simulation runs, it is possible to decide whether the resulting

21


output sequences violate the specification. Any reasonably sized design is far too large to

examine completely. Ideally, one would want to see that all possible stimuli are checked in

all possible states of the design. However, unlike the 2-input AND gate used previously as

an example, it is impossible to exhaustively excerise all possible combinations due to limits

in space and time. Even a tiny design, with only a few hundred registers will have more

states (2100) than one can ever verify, since the number of necessary input sequences increases

exponentially with the number of inputs and the number of circuit states. As a consequence,

the number of stimuli has to be reduced and design errors remain potentially undetected [41].

As mentioned, verification involves analysis and reasoning on a computer model of the

system before it is manufactured. A model is a simplification of another entity, which can be

a physical thing or another model. The model contains exactly those characteristics and

properties of the modeled entity that are relevant for a given task and are described in

languages [42]. The techniques for verifying design models can be classified into two groups:

dynamic (simulation) based methods and formal methods [43, 44].

2.5.2 Formal Verification Techniques

Formal verification techniques use mathematical formulations to verify designs [45]. The

key difference from simulation based verification is the absence of a test pattern. The formal

verification process either compares two different models of the design or shows that a property

is satisfied on the model. In either case the answer from the formal verification analysis is

valid for all scenarios. This is starkly contrasted with the nature of simulation-based methods,

which fail to ever fully verify a design due to the impossibility of applying every test pattern.

This is also arguably the strongest point of formal methods; they can provide absolute answers

to verification problems. However, most formal techniques involve converting the model to

some abstract mathematical reprsentation or form, which may not always be feasible [43].

In the design industry, there are three primary types of formal verification. Equivalence

checking establishes whether two models will give the same result under all possible inputs.

This is particularly useful in checking the correctness of synthesis and optimization steps.

22


Model checking takes a formal representation of both the model and a given property and

checks if the property is satisfied. The properties are temporal in nature, in other words

they define the behavior of the system over time. These properties are written as formulas in

temporal logic and the model checker tries to prove or disprove each formula. Theorem proving

attempts to prove properties under some methematical logic by using deductive reasoning.

Theorem proving is appliable to almost any domain of problems and hence is very versatile,

but it is also extremely hard to create automated solutions for theorem proving [43].

2.5.3 Dynamic (Simulation-Based) Verification Techniques

In simulation-based verification methods, the specification must be checked for a set of proper-

ties. These properties are expressed as pairs of stimulus and expected behavior. The stimulus

forms the input to the implementation model being simulated and the expected behavior is

checked by monitoring the output of the simulated model.

The application of inputs, or what is better known as stimulus, is conventionally an auto-

mated procedure. This procedure requires auxillary components for the testbench: a stimulus

generator and scoreboard as shown in Figure 2.12. The stimulus generator generates meaning-

ful stimulus for the design under test (DUT) under some given constraints (directed, random,

constrianed), while the scoreboard embodies the reference model. The scoreboard observes

the inputs and outputs of the DUT, performs the same function as the DUT except at a

higher-level of abstraction, and determines whether the DUT and reference match [8].

Figure 2.12: Testbench for 2-input AND gate [8]

Although simulation may seem too time consuming and less trustworthy than formal

23

Chapter 2. Background 2.6. Assertion-Based Verification

methods, it is still the predominant technique for verification. There are practical reasons

for this, the most pressing being that formal verification often forces the designer to comply

with certain rules in modeling so that the model can be easily converted to its mathematical

formulation. Secondly, simulation is the only approach which scales reasonably with the

design.

2.6 Assertion-Based Verification

Assertion-Based Verification (ABV) is emerging as the predominant method for hardware

verification [9]. Assertions are high-level statements built on boolean and temporal logic that

are added to a design in order to specify how a circuit should behave. In a general sense, an

assertion is an expression that, if false, indicates an error. In hardware design, assertions are

statements about specific functional characteristics or properties that are expected to hold

for the design. If the stimulus violates the expressed behavior, an error message is reported.

Assertions are statements of design assumptions or design intent; they express the golden

rules to which the implementation is compared. To this end, assertions can be seen as a

formal and executable documentation language, free of the ambiguities inherent to natural

language specifications [9]. The ABV methodology is based on the fact that the observation

of an assertion failure helps to identify design errors, which are then used as a starting point

for the debugging process [9].

Assertion-based verification embodies property-checking techniques. An example of a

property is the proposition that only a single tri-state driver on the design’s memory bus is

enabled at a time [46]. It can then be asserted that the property must hold and this assertion

can be checked using a dynamic (simulation) or static (formal) verification tool [46]. Asser-

tions are sprinkled throughout a design by the use of hardware assertion languages which

specify RTL user-defined properties. The main hardware assertion languages are SystemVer-

ilog Assertions (SVA) [47, 48] and the Property Specification Language (PSL) [49], both of

which are standardized by IEEE as standards 1800–2005 and 1850–2005, respectively. Asser-

tion languages allow the specification of expressions that do not lend themselves directly to

24

Chapter 2. Background 2.7. AMBA 2.0 Protocol

hardware implementations. Such languages allow complex temporal relations between signals

to be stated in a compact and elegant form [9]. For example, the following statement expresses

a certain specification that is to be respected by a bus arbiter [9].

When the request signal goes from low to high in two consecutive cycles, then the grant signal

must be asserted in at most five cycles and the request signal must remain high until this grant is

received, unless a reset occurs.

Figure 2.13 represents the same specification, expressed using a PSL assertion:

Figure 2.13: PSL example expression [9]

Assertions are beneficial to the debug process because they provide internal test points

within a design and simplify the diagnosis and detection of bugs by localizing the occurrence

of errors.

2.7 AMBA 2.0 Protocol

The Advanced Microprocessor Bus Architecture (AMBA) communication protocol developed

by ARM, Inc. is later referenced in this thesis for illustrative purposes as the chosen com-

munication architecture for an example system used to demonstrate the solutions proposed.

An overview of the protocol including bus types relevant to this work will be provided in this

section.

2.7.1 Overview

Since the early 1990s, several on-chip bus-based communication architecture standards have

been proposed to handle the communiation needs of emerging SoC designs. AMBA version

25


2.0 is one of the most widely used on-chip communication standards today. The goal of this

standard is to provide a flexible high-performance bus architecture specification that is tech-

nology independent, takes up minimal silicon area, and encourages IP reuse across designs [3].

AMBA employs a hierarchical bus topology – this architecture consists of several shared

busses interconnected by bridges to form a hierarchy. Bus bridges are directional components

to connect bus segments [32]. Different levels of hierarchy correspond to the varying commu-

nication bandwidth requirements of SoC components. Such topologies typically offer large

throughput improvements due to decreased load per bus, and the potential for transactions

to proceed in parallel on different busses [25]. The AMBA bus is typically composed of two

segments, the advanced high-performance bus (AHB) and the advanced peripheral bus (APB)

as depicted in Figure 2.14.

Figure 2.14: A typical AMBA system [10]

The AHB is a high-performance bus meant to connect high bandwidth, high clock fre-

quency components such as microprocessors, off-chip interfaces and on-chip memory blocks.

Conversely, the APB is a low complexity bus optimized for low power operation; and meant

for high-latency, low bandwidth peripheral components such as timers, UARTS, etc [10]. The

AMBA AHB bus typically acts as a backbone bus that provides a high bandwidth interface

between the components involved in a majority of the transfers. The bridge component on

26


the high performance bus is used to interface to the lower bandwidth APB bus, to which most

of the low bandwidth peripherals are connected. The AMBA specification [10] is described

at the architectural level of granularity and does not provide any information about the elec-

trical characterisitics of the bus, which are dependent on the selected manufacturing process

technology. The specification does, however, define all the signals, transfer modes, structural

configuration, and other bus protocol details for the busses.

Figure 2.15: AHB multiplexer interconnection scheme [10]

2.7.2 Advanced High Performance Bus (AHB)

The AHB can be used to connect multiple master components. It supports high-performance

data transfer features such as pipelined operations, burst mode transfers and split transac-

tions. Since the AMBA specification restricts all its on-chip busses to a non-tristate imple-

mentation, the AHB has separate data busses for reads and writes. The AHB makes use of a

central multiplexer-based interconnection scheme, along with centralized arbiter and decoder

27


modules to manage data transfers. The masters on the bus drive their address signals and

control signals whenever they want to perform a transfer, and the aribiter determines which

of the masters will have its address, control and possibly write data signals routed to all of

the slaves on the bus. The decoder is used to decode the destination slave address, select

the appropriate slave to recieve the data transfer request, and route back the response (and

possibly read data) signals to the masters. This multiplexer interconnection scheme is shown

in Figure 2.15.

Figure 2.16 shows a basic data transfer on the AHB bus. An AHB transfer consists of

an address phase that lasts for a single cycle, and a data phase that can require one or more

cycles. It is possible that the slave can require more than one cycle to provide a response to

the master; this could be because the slave needs one or more cycles to read the requested

data or to write the data. In such cases, the slave can introduce wait cycles by lowering the

HREADY signal to indicate to the master that additional time is required to complete the

transaction. Since the address and data phases of a transfer occur in separate cycles, it is

possible to overlap the address phase of one transfer with the data phase of another transfer

in the same clock period, pipelining the operation of the AHB bus.

28


Figure 2.16: Basic data transfer on AHB bus [10]

In addition to the address and data phases, an arbitration phase is necessary for all data

transfers if there is more than one master connected to a bus. The arbitration phase ensures

that only one master gains access to the bus and proceeds with its data transfer at any given

point of time. Whenever a master needs to initiate a read or write data transfer, it asserts

the HBUSREQ signal to the arbiter requesting it for access to the AHB bus. The arbiter

samples the HBUSREQ signals from all the masters and uses its arbitration policy to decide

which master will be granted access to the bus. Once the arbitration scheme selects a master,

the arbiter drives the HGRANT signal to the corresponding master, indicating it has been

granted access and can proceed with its transaction.

Such a large overhead for a single transfer can limit the performance on the bus. To

alleviate this overhead, the AHB bus supports burst data transfers that only need to arbitrate

once at the beginning of the transaction for transferring multiple data items. The AHB

bus supports several different burst modes as well as split transactions, please refer to the

specification for details. Figure 2.17 shows an example of a four-beat incrementing burst.

29


Figure 2.17: Example of a four-beat incrementing burst [10]

2.7.3 Advanced Peripheral Bus (APB)

The APB bus standard defines a bus that is optimized for reduced interface complexity and

low power consumption. This bus is meant to interface with the AHB bus via a bridge. The

APB allows only non-pipelined data transfers, and has only a single master – the bridge that

connects the AHB to the APB bus. Typically, the APB bus operates at a much lower clock

frequency, helping to reduce power consumption.

The IDLE state is the default state, in which the APB bus remains when there are no

transfer requests from the AHB bus. When a transfer request arrives from the AHB bus via

the AHB-APB bridge, the APB bus moves to the SETUP state and asserts the appropriate

slave select signal to select the slave on the APB bus that is required to participate in the

transfer. The APB bus moves to the ENABLE state on the next rising edge of the clock

and asserts the PENABLE signal to indicate that the transfer is ready to be performed.

This state also lasts for one cycle, after which it can go back to the SETUP state if another

30


transfer follows the current transfer or to the IDLE state if no further transfers are required.

Figure 2.18 depicts a state diagram that represents the activity on the APB bus.

Figure 2.18: State diagram representing activity of the APB bus [10]

31

Chapter 3

Related Work

The goal of this thesis is to provide a means for specifying system-level assertions; accompa-

nied by an automated solution for presenting violations – and all design activity – from an

intuitive perspective, using transactions, to enhance the debug process. The goal of increasing

productivity by abstracting waveforms and auxillary data into transactions has been used in

other areas of verification and will be discussed in the first section of this chapter. Assertion

checkers have also been explored in previous work for verification and validation and will be

presented in section two. Section three reviews previous solutions that aim to improve formal

specifications of system functionality.

3.1 Transactions in Verification: UVM

Verification environments today look quite different from those of the 1990s and early 2000s.

Historically, verification environments have been somewhat of an ad-hoc cludge consisting of

some higher-level reference model (usually C++), testbench and directed stimulus. To ad-

dress the design and verification productivity gap, verification environments went through a

standardization make-over instituted by leaders in the EDA industry [50].

As a result of the SoC paradigm, it became clear that, in order to cope with the rise in

design complexity, reusable, vendor-agnostic verification components aiming to abstract stim-

ulus data into manageable and understandable units were necessary. The road to the adoption

32

Chapter 3. Related Work 3.2. Post-Silicon Validation: Design for Debug

of such a methodology has seen several candidates, such as the Verification Methodology Man-

ual (VMM) and the Open Verification Methodology (OVM), but has finally converged into

what is referred to as the Universal Verifcation Methodology (UVM) [50], which is supported

universally across the EDA industry and by all commercial simulators.

UVM is a verification methodology that codifies the best practices for efficient and exhaus-

tive verification [50]. A UVM testbench is composed of reusable components and organized

into layers, facilitating abstraction at distinct boundaries [8]. The bottom-most layer is the

DUT, an RTL device with pin-level interfaces. Above that is a layer of transactors (drivers

and monitors), devices that convert between the transaction-level and pin-level domains [8].

Driving the verification environment is done with sequences. Sequences are a series of trans-

actions grouped together to represent a protocol-specific scenario.

Most commercial debuggers in the semiconductor industry support transaction-level de-

bugging, but this implementation is tightly coupled to the verification environment’s adop-

tation of UVM and as a result is generally constrained to transactions describing protocol

compliance [51, 52, 53].

3.2 Post-Silicon Validation: Design for Debug

In-circuit debugging techniques have also begun to adapt the concepts of transaction-level

modeling and assertions for their needs. In the past, developers debugged embedded systems

by attaching tools such as logic analyzers and oscilloscopes to the printed circuit board’s

external interfaces. With increased integration and the introduction of SoCs, convenient in-

terfaces such as the system bus moved on-chip, leaving no connection for external tools and

rendering engineers blind to the SoC internal state [54].

Debugging silicon is difficult because the engineer’s ability to observe the chip’s interior is

limited. Several chip-debugging techniques exist, including the use of probe needles and elec-

tron beam probing; however, the decreasing feature size and multiple metal layers in modern

process technologies make debugging techniques based on visual inspection or direct physical

contact more difficult [55]. To meet accessibility and controllability needs, a chip design must

33

Chapter 3. Related Work 3.3. Formal Specifications for System Behavior

undergo certain modifications and additions prior to tape-out. This process is referred to as

designing for debug (DFD) [56, 55]. Several debug architectures and methodologies have been

proposed using in-circuit assertion-checking hardware and transaction-level modeling to ease

the debug effort [57].

DAFCA proposed a reconfigurable infrastructure for SoCs to support at-speed in-system

functional debug using a signal probe network and monitor [58]. The monitors can be dy-

namically configured with assertions and also to recognize specific events occuring in the SoC

and to use these events to initiate appropriate debug activities such as triggering [58].

Gao and Cheng proposed a technique, Time-Multiplexed Assertion Checking (TMAC),

which implements a large population of assertion checkers to monitor a chips internal prop-

erties in a sequential and round-robin fashion for bug detection and isolation [56].

Goossens et. al designed a modular debug architecture based on NOCs, monitors, and

a dedicated high-speed event-distribution broadcast interconnect that is sensitive to certain

events and stops the SoC on conditions when these events occur. Manufacturing test scan

chains and test access ports (TAP) are re-used for configuration of the architecture and debug

data read-out of NOC and IP state [21].

Gharehbaghi and Fujita developed a methodology for increasing debug ability by extract-

ing transaction sequences at run-time using on-chip circuits and storing them in a trace buffer.

The on-chip infrastructure identifies transactions based on a set of patterns defined by the

TDPSL language also introduced by the authors. TDPSL differs from SVA or PSL because

it allows for transaction-level concepts [59].

3.3 Formal Specifications for System Behavior

The quality of verification depends on the precision in specifying the interaction between

blocks in an SoC [60]. As a result, several solutions have been proposed to improve the qual-

ity with which system specifications are expressed.

Gadkari, Ramesh and Parekhji introduce a visual specification language called CESC

(Clocked-Event Sequence Chart), designed to specify interaction scenarios in SoCs using Mes-

34

Chapter 3. Related Work 3.3. Formal Specifications for System Behavior

sage Sequence Charts (MSCs) [60]. CESC is a visual language, designed to specify formally

and clearly the interaction behaviors in hardware-software with multiple clocks. It has rig-

orous formal semantics based upon partial order relations on events and timed traces along

the lines of synchronous languages. It also contains compositional constructs for building

large specifications from smaller ones. CESC, being event and agent-oriented, contains better

suited information for specifying system-level interactions as compared to traditional medi-

ums such as timing diagrams [60].

Bunker and Gopalakrishnan propose an amelioration to MSC for specification, live se-

quence charts. They confirm the suitability of graphical languages for specifying hardware

protocol standards [61]. Live sequence charts allow the user to specify certain aspects of the

system as required or optional, provide a construct known as a coregion to denote a series of

messages that are not required to be ordered, and introduce an element known as unbounded

multiplicity.

Lin et. al introduce the concept of using finite state machine models to describe protocol

specifications [62]. The topic of protocol representation using transition diagrams is further

detailed in the earlier work of Danthine [63] and additionally in the work of Bochmann [64].

D’silva, Ramesh and Sowmya present a finite state machine framework for modeling commu-

nication aspects of on-chip bus architectures [65].

Kedalagudde proposes several extensions to the Unified Modeling Language (UML) [66]

for describing dynamic behavior of embedded systems. These extensions allow UML to act

as a complete system specification by adding additional state information and including the

state of an object as an element in sequence diagrams [67].

35

Chapter 4

Overview of the Approach

This chapter presents an overview of the approach taken by the author in formally defining

correct system behavior with transactions. The first section is a review of the importance and

applicability in using transactions for debug. The second section describes how system events

can be distilled during a simulation into a trace file and the testbench augmentations necessary

to implement this procedure. The third section then discusses how transaction sequences are

formed from these discrete events and assertion-checking applied during sequence formation,

giving the capability to describe and verify complete system-level use case scenarios within

an SoC automatically.

4.1 Communication-Centric Verification

As a result of systems-on-chip design focusing on IP reuse, systems-on-chip verification is

focused on the communication and synchronization of IP blocks [21]. Debugging IP blocks

by themselves is not enough, because the complexity of the SoC increasingly resides in the

interactions between the IP blocks. Therefore, debug must be conducted at a higher, system

level. Transactions are the result of processor instructions (such as load and store) that

cause activity on the interconnect and other IP blocks such as memory [21, 68]. Transactions

are a fundamental concept for system-level debug. Recall from Chapter 2 that transactions

represent system level behaviors and are made up of sequences of related events.

36

Chapter 4. Overview of the Approach 4.2. Event Extraction

The solution presented in this thesis extracts events from existing RTL by creating watch

points around event relevant signals and managing a trace of all event activity during a

simulation. This procedure is further discussed in the next section.

4.2 Event Extraction

The first step in event extraction is determining the timing fidelity required to capture all

pertinent activity for each sequence, as outlined in Chapter 2. In this solution, we allow the

user flexibility in the fidelity with which a use case is specified. That is, depending on the

scenario and detail desired, a use case may be specified to depict system functionality from the

granularity of the hardware protocol, involving actual bus cycles, or from the granularity of

the programmer’s view, as single transfers of data and control. Therefore, the timing fidelity

for this solution will be cycle accurate, meaning all significant events relating to the on-chip

communication protocol will be captured, in order to retain this flexibility.

An event is the consequence of some observable change in the system state bounded

by time. As an example, we will examine a common event associated with communication

infrastructures, the request event. Recall that an SoC architecture contains masters, slaves

and a communication medium. Using the AMBA AHB and APB busses discussed in Chapter

2 as reference, we will assume that a master residing on an AHB bus intends to request data

from a slave on an APB bus. The beginning of a request event in this scenario can be observed

as the assertion of the master’s HBUSREQx signal and the completion can be observed as

the assertion of the HGRANTx signal for that master by the arbitration unit.

Once an inventory of events is collected and the timing points bounding each are identified,

it is now possible to track the occurrence of events from within an RTL simulation and

record these to a trace file. One way to accomplish this is by creating processes sensitive to

signals which cause events. When a signal changes value, if this value is associated with an

event of interest, this can be logged. Figure 4.1 illustrates this concept by demonstrating a

process for capturing AMBA request events. In this way, we can create a chronological list

of events. Logging is possible using the Verilog $display system task or the SystemVerilog

37

Chapter 4. Overview of the Approach 4.3. Forming a Transaction Sequence

Direct Programming Interface (DPI) which allows for communication with C (or any other

foreign language) routines [48].

Figure 4.1: Process to capture an AMBA request event

4.3 Forming a Transaction Sequence

A transaction is a sequence of related events. Illuminating a transaction sequence from a

collection of events begins with encoding the sequence as a finite state automaton. The first

step of this process is to identify the states that compose a given sequence. The second step

is to infer properties from functional unit and protocol specifications which dictate transition

functions between these states. The illustration in Figure 4.2 is one example of such an

automaton, describing the expected behavior for an AMBA AHB single read request.

38


Figure 4.2: Anatomy of an AMBA AHB single read automaton

The AMBA AHB protocol defines a successfully completed single read request as having at

least two phases, the address phase and the data phase, with optional wait phases introduced

by the slave if additional time is necessary to complete the transfer. The address phase is

where the request and associated attributes, such as the TRANSTYPE, are asserted. The

data phase encompasses the response from the slave for the requested transfer.

Each state of the automaton corresponds to one of the phases in the transfer sequence.

Transition functions for moving from one state to the next are aligned with expected bus

signals for each attribute significant to that state in the transfer. In this example, a transition

from the START state to the READ state would be initiated if the input to the automaton (an

event) has its DIRECTION attribute set to perform a read transfer request, its TRANSTYPE

39


attribute set to NONSEQ and its BURST attribute set to SINGLE. This packet of attributes

is in accordance with the protocol specification for the commencing of a read transfer.

It is also often necessary to retain attributes from events which have been evaluated and

store them for reference later in future evaluations. Such an action can also be seen on the

START to READ state transition, where the event’s address attribute is stored into a variable

called ADDR. This is necessary because transitioning from the READ state to any adjacent

state requires the requested address of the event initiating the transfer to match that of the

event responding to and completing the transfer. As a result, both the READ to WAIT and

READ to DATA transitions check the equality of the event they are evaluating against the

address value stored in ADDR by the START to READ transition as shown in Figure 4.2.

This is a simple example, but all automata are modeled under this same set of principles.

State transitions are also meaningful points to instrument assertion facilities for various

types of property-checking. Transitions within these models correlate to changes in the system

state; it is important to verify that these changes agree with the overall system configuration

and that no known violations have occurred. The debug environment proposed in the next

chapter maintains a global view of system memory that can be updated with the data for

each successful write transfer evaluated and used for consistency checks. For example, once

the single read request automaton has transitioned to its final state, an assertion can be made

that the data returned by the slave for this request match the existing data in the memory

as seen by the environment in accordance with the last write to that same address.

40

Chapter 5

Implementation Details

This chapter presents a detailed discussion of the author’s implementation of finite state au-

tomata for describing correct and erroneous system behavior. This solution is presented in

the context of a supplementary debug environment containing an event sequencer engine for

event distribution control and evaluation amongst the various automaton defined. The debug

environment was designed to help assess the capability of this method in facilitating the debug

process.

The overall goal of this work is to improve bug visibility by presenting traffic and its con-

sequences on system state in an intuitive and less restrictive fashion. This was accomplished

by using the environment to apply the results of the system behavioral models and project

them into a visual representation of activity in terms of transactions. The implementation is

an extensible, object-oriented approach written in Java.

5.1 Environment Components

This section describes each of the major components in the debug environment proposed.

For the remainder of this thesis, the debug environment will be referred to by its for-

mal name, TLMDebugger. Figure 5.1 shows the environment’s components and their re-

lationships in the form of a UML class diagram 1. Figure 5.2 shows the inheritance of the

1Definitions for the constructs used in this diagram can be found in the book Learning UML [66]

41

Chapter 5. Implementation Details 5.1. Environment Components

TransactionDefinition class.

The TLMDebugger class is the main locus of control and instantiates all the facilities for

automaton sequencing and display management with the EventOracle and ViewManager

classes, respectively. These and their sub-components will be discussed in the following sec-

tions.

5.1.1 Transaction Definitions

The TransactionDefinition class is the base class from which all definitions describing

various system behaviors must inherit in order to be used with the event sequencer, now

referred to by its class name, EventOracle. A TransactionDefinition models an au-

tomaton by mapping the set of states for the automaton to State objects (See Appendix A).

The State class contains information about the state, such as whether or not it is an

accept state, as well as directives for the EventOracle to alter its operation. For example,

a State can indicate whether the event causing the transition will also apply to other trans-

action sequences and should continue to be offered to subsequent automata for evaluation.

Transition functions between these states are then modeled by the canTransition()

method. Recall that a deterministic finite state automaton is a 5-tuple, (Q,Σ, δ, q0, F ) where:

1. Q is a finite set of states

2. Σ is a finite set called the alphabet

3. δ : Q× Σ→ Q is the transition function

4. q0 ∈ Q is the start state

5. F ⊆ Q is the set of accept states

In the context of a TransactionDefinition, the alphabet corresponds to event prop-

erties (such as its TRANSTYPE or HRESP). Transition functions are typically qualified by

unique properties of the event being evaluated but also by cross constraints from past events.

Let us consider a generic, hypothetical example in which a tranaction sequence has:

42


Figure 5.1: UML diagram of the major components of the TLMDebugger

Figure 5.2: UML class diagram showing the inheritance of TransactionDefinition

43


1. A set of states, Q = (A,B,C,D)

2. An alphabet (set of properties), Σ = (p0, p1, p2, y, z)

3. A start state, q0 = A

4. A set of accept states, F = (D)

The automaton for this transaction sequence is depicted in Figure 5.3.

Figure 5.3: Generic automaton modeling a transaction sequence

In this example sequence, assume states A,B and C have a unique constraint on property

p0 of the evaluated input (event), state B has a cross constraint on property p1 of the input

validated by state A and state C has a cross constraint on property p2 of the input validated

by state B. The pseudocode for the canTransition() method of this transaction sequence

is given in Figure 5.4.

44


function canTransition(Event evt)

valid← false

if currentState = A and evt.p0 = p0 then

currentState← B

y ← evt.p1

valid← true

else if currentState = B and evt.p0 = p0 and evt.p1 = y then

currentState← C

z ← evt.p2

valid← true

else if currentState = C and evt.p0 = p0 and evt.p2 = z then

currentState← D

valid← true

end if

end function

Figure 5.4: Archetype of TransactionDefinition’s canTransition() method

A TransactionDefinition also populates an internal list of all events which resulted

in a positive evaluation. Optionally, supplemental event properties meaningful to the evalua-

tion can be drawn out and stored to assist property-checking.

5.1.2 Event Sequencer Engine

The EventOracle class can be viewed as an event sequencing engine, orchestrating the ad-

vancement of all automata defined for a system in tandem. The EventOracle is the sole

facilitator of event traffic procured through Parsers passed along by the TLMDebugger.

Using this method requires each module within the modeled system-on-chip to have its own

trace file describing traffic originating from and destined for that module. Each module within

the system will be bound to its own Parser within the debug environment. A trace file is

45


expected to follow some regular structure in which event information can be dissected by

the Parser and used to form Event objects. Recall that a system-on-chip architecture will

have both masters and slaves; therfore the debug environment supports both MasterParsers

and SlaveParsers, emitting MasterEvents and SlaveEvents, respectively.

The activate() method kicks off event creation, distribution and logistics. Each Parser’s

getNext() method is succcessively called to obtain all of the Events described in its trace

file. The Events are then sorted according to their timestamps, producing a chronological

list of system activity across modules. Each Event is then sequentially removed from the

head of the list and dispensed to the TransactionBuilder and StorageModels which

manage transaction synthesis and a temporally consistent model of memory and configuration

registers, respectively. The pseduocode for the activate() method is given in Figure 5.5.

If an event applies to multiple TransactionDefinitions the EventOracle will con-

tinue to call the TransactionBuilder with the Event until it has been seen by all required

candidates.

46

Chapter 5. Implementation Details 5.2. System Under Test

5.1.3 Transaction Builder

The TransactionBuilder class is responsible for transaction construction by offering

events to automata for evaluation in an organized manner. The TransactionBuilder

manages a queue of pending automata which have already transitioned from their start state

and are awaiting the acquisition of subsequent events forcing traversal into an accept state.

A queue of dormant automata is also proctored. These dormant automata exist to act as a

blueprint for all definitions in the system.

Events will be evaluated by the queue of pending automata first, and if no match is

found will then continue to be evaluated by each automaton defined in the blueprint queue

until a match is found and causes a start state transition. If an event causes a transition out of

the start state for an autamaton, that automaton will then be placed into the pending queue

and a new definition will be placed into the blueprint queue to fill the void. If an event is

found not to cause any transitions in either queue, an error is flagged by the EventOracle.

Once all Events have been processed, each automaton remaining in the pending queue will

cause an error to be flagged indicating that it was unable to complete. The pseudocode for

this heuristic is given in Figure 5.6.

5.2 System Under Test

An assessment of this method using the proposed debug environment is presented in the re-

maining sections of this chapter. An example system-on-chip architecture adapted from the

Texas Instruments’ Digital-Media series (TMS320DM6446) is used for illustrative purposes

and to provide context [11].

The proposed system-on-chip architecture employs an AMBA hierarchical bus structure

consisting of separate AHB and APB busses communicating over a bridge. The AHB bus

is responsible for servicing several high-performance functional units including three CPUs,

a dedicated DSP core, DMA engine, high-speed SDRAM, global interrupt controller (GIC),

video display engine, 2D engine and a power-sleep controller (PSC). The APB bus is respon-

sible for servicing low-power components including UART, I2C and SPI modules. There are

47

Chapter 5. Implementation Details 5.2. System Under Test

function activateready ← {}for all p ∈ Parsers do

ready ← p.getNext()end forwhile ready 6= ∅ do

earliest ← ready[0]memories.update(earliest)registers.update(earliest)transaction ← builder.run(earliest)while ¬ earliest.taken and transaction 6= null do

builder.run(earliest)end whileif ¬ transaction then

reportError(earliest)end iffor all p ∈ Parsers do

ready ← p.getNext()end for

end whileend function

Figure 5.5: EventOracle’s activate() method

function run(Event evt)for all open ∈ pendingQueue do

if open.canTransition(evt) thenif open.isComplete() then

pendingQueue.remove(open)return

end ifend if

end forfor all candidate ∈ blueprintQueue do

if candidate.canTransition(evt) thenblueprintQueue.remove(candidate)blueprintQueue.add(candidate.newBluePrint())pendingQueue.add(candidate)return

end ifend for

end function

Figure 5.6: TransactionBuilder’s run() method

48

Chapter 5. Implementation Details 5.3. Case Study: AMBA AHB Incrementing Burst

three power domains defined for this system, the power domain of each module is designated

by module color in Figure 5.7.

Figure 5.7: System Under Test

5.3 Case Study: AMBA AHB Incrementing Burst

The first case study examined is the AMBA AHB incrementing burst transaction. Four, eight

and sixteen beat bursts are defined in the AMBA AHB protocol, as well as undefined length

bursts.

Incrementing bursts access sequential locations and the address of each transfer in the

burst is just an increment of the previous address. The first transfer is the start of the burst

and is therefore nonsequential. The remaining transfers are labeled as sequential with in-

cremental addresses until the number of beats specified is reached or the transfer type is no

longer indicated as sequential. This is depicted in Figure 5.8. The steps for mapping this

definition to an automaton follow the same basic guidelines discussed in Chapter 4. Figure 5.9

shows the result of a successful burst captured and illuminated within the debug environment.

49

Chapter 5. Implementation Details 5.3. Case Study: AMBA AHB Incrementing Burst

Figure 5.8: AMBA AHB Incrementing Burst Automaton

Figure 5.9: Debug environment highlighting burst transaction

50

Chapter 5. Implementation Details 5.4. Case Study: Power Management Scenario

5.4 Case Study: Power Management Scenario

The benefit of this methodology is most pronounced when used for capturing system-wide

behavior composed of both hardware and software interactions. In contrast to other pre-

silicon solutions introduced in Chapter 3, this methodology is powerful because it supports

a seamless integration of high-level constructs to flexibly describe system behavior from a

hardware/software co-design perspective. These constructs are demonstrated in this section

using the architecture’s software-controllable power-on/off feature as an example.

The system under test includes three separate power domains and multiple separate mod-

ules, as shown in Figure 5.7 and summarized in Table 5.1. Each power domain can be in

either the ON or the OFF state. In other words, each power domain can be powered-down in-

denpendently of the rest of the SoC to conserve power when certain functions are not needed.

The power and sleep controller (PSC) is responsible for managing transitions of system power

on/off and provides a software interface to controlling each power domain [11]. There are

several registers which play a key role in PSC operation, these include PTSTAT and PTCMD

(See Appendix B).

Power Domains

0 CPU0

CPU1

CPU2

1 DSP

2D

VDE

2 UART

I2C

SPI

Table 5.1: Power domain by module

5.4.1 Power Domain State Transition Sequence

This section describes the basic procedure for transitioning the state of a power domain and is

graphically depicted in Figure 5.10. The procedure is as follows (n corresponds to the power

domain) [11]:

51


1. Software waits for the GOSTAT[n] bit in the PTSTAT to clear. This indicates if there

are any pending transitions.

2. Software sets the NEXT bit in PDCTLn to indicate an ON (1) or OFF (0) transition

is desired.

3. Software sets the GO[n] bit in PTCMD to initiate the transition.

4. PSC sets the EPC bit in EPCPR, indicating to software it is ready for the transition.

5. PSC waits for software to set (on) or clear (off) the EPCGOOD bit in PDCTLn, indi-

cating that power has been applied or removed. PSC proceeds with the transition once

software writes this bit.

6. Software waits for the GOSTAT[n] bit in PTSTAT to clear. The domain is safely in the

new state once this has cleared.

Figure 5.11 shows the result of applying the automaton representation of this definition

to incoming event traffic. Also, note that after a successful power domain transition has been

captured, the register values in the status window have been updated accordingly and are

synchronized with the environment cursor. This scenario is realistic and represents a large

percentage of inter-module communication in modern SoCs where configuration registers are

used for synchronization purposes.

52


Figure 5.10: Power domain transition automaton

53


Figure 5.11: Debug environment highlighting power domain transition

5.4.2 Property-Checking with Assertions

During a change in system state, or the transition of an automaton from one state to another,

it is often useful to verify that certain properties do not violate any known constraints or in-

consistencies. An assertion, as discussed in Chapter 2, is an expression describing functional

characteristics or properties expected to hold for a design. The failure of an assertion is there-

fore indicative of an error. Assertions can be used to automatically verify that constraints on

various properties of a design are upheld.

The automaton in Figure 5.10 provides several examples of such assertions which are

meaningful to the transition of a power domain. For instance, in order for this automaton to

transition from the START state to the NEXT state, it is necessary that software wait until

the GOSTAT[n] bit in the PTSTAT register is cleared, indicating that it is safe to begin a new

transition. In order to check that this constraint is upheld, an assertion is created affirming

that any event indicating a write to the NEXT bit of the PDCTLn register be preceded by the

54


clearing of GOSTAT[n]. If the GOSTAT[n] bit is not cleared and the NEXT bit of PDCTLn

is set this indicates an error and will be communicated to relevant components within the

debug environment. The implementations of assertions in this solution are simply methods

which perform equivalency checks and are called from TranscationDefinitions when

an invocation of the canTransition() method evaluates to true.

Figure 5.12 is similar to Figure 5.11, except that in this case a successful power domain

transition was not captured. Errors are represented by triangular shapes in the top channel

of the debug environment. Taking a look at the error message displayed, it is evident this

transaction sequence was not completed, since the final event to complete the sequence was

never received. The automaton representing this transaction sequence is stuck in the SUC-

CESS state and waiting for an event which would cause a transition into the FIN state.

Errors collected during automaton evaluations are annotated onto the debug environment’s

graphical front-end as a means of automated checking.

Figure 5.12: Debug environment highlighting power domain transition with error

55

Chapter 6

Conclusions

6.1 Summary of Contributions

This research addressed verification challenges facing the semiconductor industry in the era

of billion-gate multi-processor systems-on-chip, with an emphasis on pre-silicon debug. A

methodology was proposed to illuminate a system perspective of traffic from signal data.

This methodology is based on the philosophy and principles of transaction-level modeling.

The methodology includes an explanation of testbench mechanics necessary for event ex-

traction during RTL simulations, as well as a procedure to form transactions from discrete

events by mapping system behavior into formal, computational descriptions using finite state

automata. Assertion-based property-checking facilities are also integrated into the model

as callbacks to automaton transition functions. Applying extracted events to these models

provides visibility into the system state for a given simulation, ideally expediting the identi-

fication of error sources and reducing the amount of manual inspection.

A debug environment was introduced in order to assess and provide context for the

methodology, which includes a concrete implementation technique for model realization, mech-

anisms enabling synchronized model execution, and a visual projection of system state from

model evaluation results. Case studies were presented using an illustrative system-on-chip

architecture to showcase the capacity with which transaction sequences may be described at

various functional granularities. The ability to integrate property-checking into the models

56

Chapter 6. Conclusions 6.2. Suggestions for Future Work

with the use of assertions was also described.

6.2 Suggestions for Future Work

This research assessed the applicability of the proposed methodology using a hypothetical

system with a hierarchical bus structure. It would be meaningful if this analysis were extended

to include more complex bus structures, such as a system containing a network-on-chip or the

AMBA AXI protocol, which allows for transactions with out-of-order completion.

57

Bibliography

[1] M. Flynn and W. Luk, Computer System Design: System-on-Chip. Wiley, 2011.

[2] M. Keating and P. Bricaud, Reuse Methodology Manual for System-on-a-Chip Designs.

Springer, 2002.

[3] S. Pasricha and N. Dutt, On-Chip Communication Architectures: System on Chip Inter-

connect. Morgan Kaufmann, 2008.

[4] G. Schirner and R. Domer, “Quantitative analysis of the speed/accuracy trade-off in

transaction level modeling,” ACM Transactions on Embedded Computing Systems, vol. 8,

no. 1, pp. 4:1–4:29, 2009.

[5] M. Burton, J. Aldis, R. Gunzel, and W. Klingauf, “Transaction level modelling: A

reflection on what tlm is and how tlms may be classified,” in Proceedings of the Forum

on Specification and Design Languages, 2007, pp. 92–97.

[6] L. Cai and D. Gajski, “Transaction level modeling: an overview,” in First

IEEE/ACM/IFIP International Conference on Hardware/Software Codesign and Sys-

tem Synthesis. New York, NY, USA: ACM, 2003, pp. 19–24.

[7] D. Black, J. Donovan, B. Bunton, and A. Keist, SystemC: From the Ground Up.

Springer, 2009.

[8] M. Glasser, Open Verification Methodology Cookbook. Springer, 2009.

[9] M. Boule and Z. Zilic, Generating Hardware Assertion Checkers. Springer, 2008.

58

Bibliography Bibliography

[10] AMBA Specification Rev. 2.0, ARM Limited, 1999. [Online]. Available: www.arm.com

[Accessed: 07/19/2013]

[11] TMS320DM644x DMSoC Reference Manual, Texas Instruments. [Online]. Available:

www.ti.com [Accessed: 06/25/2013]

[12] G. Moore, “Cramming more components onto integrated circuits,” Proceedings of the

IEEE, vol. 86, no. 1, pp. 82–85, 1998.

[13] Y. Hsu, “Step back to see more [transaction level SoC debugging and verification],”

Electronics Systems and Software, vol. 2, no. 6, pp. 16–19, 2004.

[14] Y.-C. Hsu, “Maximizing full-chip simulation signal visibility for efficient debug,” in In-

ternational Symposium on VLSI Design, Automation and Test, 2007, pp. 1–5.

[15] P. Mishra, Z. Zilic, and S. Shukla, “Guest editors’ introduction: Multicore SoC validation

with transaction-level models,” IEEE Design and Test, vol. 28, no. 3, pp. 6–9, 2011.

[16] G. Funchal, “Comparison of embedded system models: From signals to transactions,”

Master’s thesis, Universite Joseph Fourier, 2007.

[17] D. Brahme, S. Cox, J. Gallo, M. Glasser, W. Grundmann, C. Ip, W. Paulsen, J. Pierce,

J. Rose, D. Shea et al., “The transaction-based verification methodology,” Cadence De-

sign Systems, Inc, 2000.

[18] B. Tabbara and K. Hashmi, “Transaction level modeling: verification leaps forward,” in

EDA Tech Forum ELS SystemC, 2005, pp. 14–17.

[19] International Technology Roadmap for Semiconductors. Semiconductor Industry

Association. [Online]. Available: www.itrs.net/reports.html [Accessed: 07/19/2013]

[20] U.S. Dept. of Commerce, “The economic impacts of inadequate infrastructure for software

testing,” National Institute of Standards and Technology, Tech. Rep. RTI-7007.011US,

May 2002.

59


[21] K. Goossens, B. Vermeulen, R. v. Steeden, and M. Bennebroek, “Transaction-based

communication-centric debug,” in Proceedings of the First International Symposium on

Networks-on-Chip. Washington, DC, USA: IEEE Computer Society, 2007, pp. 95–106.

[22] S. Rigo, R. Azevedo, and L. Santos, Electronic System Level Design : an Open-Source

Approach. Springer, 2011.

[23] G. Kornaros, Multi-Core Embedded Systems. CRC Press, 2010.

[24] L. Benini and G. De Micheli, “Networks on chips: A new SoC paradigm,” Computer,

vol. 35, no. 1, pp. 70–78, 2002.

[25] A. Jerraya and W. Wolf, Multiprocessor Systems-On-Chips. Morgan Kaufmann, 2004.

[26] M. Sgroi, M. Sheets, A. Mihal, K. Keutzer, S. Malik, J. Rabaey, and A. Sangiovanni-

Vincentelli, “Addressing the system-on-a-chip interconnect woes through communication-

based design,” in Proceedings of the 38th annual Design Automation Conference. New

York: ACM, 2001, pp. 667–672.

[27] K. Keutzer, A. Newton, J. Rabaey, and A. Sangiovanni-Vincentelli, “System-level de-

sign: orthogonalization of concerns and platform-based design,” IEEE Transactions on

Computer-Aided Design of Integrated Circuits and Systems, vol. 19, no. 12, pp. 1523–

1543, 2000.

[28] J. Nurmi, H. Tenhunen, J. Isoaho, and A. Jantsch, Interconnect-Centric Design for Ad-

vanced SoC and NoC. Springer, 2004.

[29] H. Zimmermann, “Osi reference model – the iso model of architecture for open systems

interconnection,” IEEE Transactions on Communications, vol. 28, no. 4, pp. 425–432,

1980.

[30] B. Bailey, G. Martin, and A. Piziali, ESL Design and Verification: a Prescription for

Electronic System-Level Methodology. Morgan Kaufmann, 2007.

60


[31] R. Saleh, S. Wilton, S. Mirabbasi, A. Hu, M. Greenstreet, G. Lemieux, P. Pande,

C. Grecu, and A. Ivanov, “System-on-chip: Reuse and integration,” Proceedings of the

IEEE, vol. 94, no. 6, pp. 1050–1069, 2006.

[32] P. Schaumont, A Practical Introduction to hardware/software Codesign. Springer, 2010.

[33] T. Grotker, System Design with SystemC. Springer, 2002.

[34] F. Ghenassia, Transaction-Level Modeling with SystemC: TLM Concepts and Applica-

tions for Embedded Systems. Springer, 2005.

[35] S. Edwards, L. Lavagno, E. Lee, and A. Sangiovanni-Vincentelli, “Design of embedded

systems: formal models, validation, and synthesis,” Proceedings of the IEEE, vol. 85,

no. 3, pp. 366–390, 1997.

[36] E. Singerman, Y. Abarbanel, and S. Baartmans, “Transaction based pre-to-post silicon

validation,” in Proceedings of the 48th Design Automation Conference. New York, NY,

USA: ACM, 2011, pp. 564–568.

[37] R. Johnson, R. Helm, J. Vlissides, and E. Gamma, Design Patterns: Elements of Reusable

Object-Oriented Software. Addison-Wesley, 1995.

[38] A. Rose, S. Swan, J. Pierce, J. Fernandez et al., “Transaction level modeling in systemc,”

Open SystemC Initiative, vol. 1, no. 1.297, 2005.

[39] S. Swan, “Systemc transaction level models and rtl verification,” in Proceedings of the

43rd annual Design Automation Conference. New York, NY, USA: ACM, 2006, pp.

90–92.

[40] M. A. Kochte, C. G. Zoellin, M. E. Imhof, R. S. Khaligh, M. Radetzki, H.-J. Wunderlich,

S. Di Carlo, and P. Prinetto, “Test exploration and validation using transaction level

models,” in Proceedings of the Conference on Design, Automation and Test in Europe.

3001 Leuven, Belgium, Belgium: European Design and Automation Association, 2009,

pp. 1250–1253.

61


[41] A. Meyer, Principles of Functional Verification. Newnes, 2003.

[42] P. Marwedel, Embedded System Design: Embedded Systems Foundations of Cyber-

Physical Systems. Springer, 2011.

[43] D. Gajski, S. Abdi, A. Gerstlauer, and G. Schirner, Embedded System Design: Modeling,

Synthesis and Verification. Springer, 2009.

[44] H. B. Carter and S. Hemmady, Metric-Driven Design Verification: An Engineer’s and

Executive’s Guide to First Pass Success. Springer, 2007.

[45] T. Kropf, Introduction to Formal Hardware Verification. Springer-Verlag, 1999.

[46] H. D. Foster, A. C. Krolnik, and D. J. Lacey, Assertion-Based Design. Springer, 2004.

[47] S. Vijayaraghavan and M. Ramanathan, A Practical Guide for SystemVerilog Assertions.

Springer, 2005.

[48] C. Spear, SystemVerilog for Verification: a Guide to Learning the Testbench Language

Features. Springer, 2008.

[49] “IEEE Standard for Property Specification Language (PSL),” IEEE Std 1850-2010 (Re-

vision of IEEE Std 1850-2005), pp. 1–182, 2010.

[50] S. Rosenberg and K. A. Meade, A Practical Guide to Adopting the Universal Verification

Methodology (UVM). Cadence Design Systems, 2010.

[51] VCS User Guide, Synopsys, Inc. [Online]. Available: www.synopsys.com [Accessed:

05/10/2013]

[52] Simvision User Guide, Cadence, Inc. [Online]. Available: www.cadence.com [Accessed:

05/10/2013]

[53] Questa User Guide, Mentor Graphics, Inc. [Online]. Available: www.mentor.com

[Accessed: 05/10/2013]

62


[54] A. Mayer, H. Siebert, and K. McDonald-Maier, “Boosting debugging support for complex

systems on chip,” Computer, vol. 40, no. 4, pp. 76–81, 2007.

[55] B. Vermeulen and S. Goel, “Design for debug: catching design errors in digital chips,”

IEEE Design and Test, vol. 19, no. 3, pp. 35–43, 2002.

[56] M. Gao and K.-T. Cheng, “A case study of time-multiplexed assertion checking for

post-silicon debugging,” in IEEE International High Level Design Validation and Test

Workshop, 2010, pp. 90–96.

[57] P. Fogarty, C. Macnamee, and D. Heffernan, “On-chip support for software verification

and debug in multi-core embedded systems,” IET Software, vol. 7, no. 1, pp. 56–64, 2013.

[58] M. Abramovici, P. Bradley, K. Dwarakanath, P. Levin, G. Memmi, and D. Miller, “A re-

configurable design-for-debug infrastructure for SoCs,” in Proceedings of the 43rd annual

Design Automation Conference. New York, NY, USA: ACM, 2006, pp. 7–12.

[59] A. Gharehbaghi and M. Fujita, “Transaction-based debugging of system-on-chips with

patterns,” in Proceedings of the 2009 IEEE international conference on Computer Design.

Piscataway, NJ, USA: IEEE Press, 2009, pp. 186–192.

[60] A. A. Gadkari, S. Ramesh, and R. A. Parekhji, “Cesc: a visual formalism for specification

and verification of SoCs,” in Proceedings of the 14th ACM Great Lakes symposium on

VLSI. New York, NY, USA: ACM, 2004, pp. 354–357.

[61] A. Bunker and G. Gopalakrishnan, “Using live sequence charts for hardware protocol

specification and compliance verification,” in Proceedings of the Sixth IEEE International

High-Level Design Validation and Test Workshop, 2001, pp. 95–100.

[62] H.-M. Lin, C.-C. Yen, C.-H. Shih, and J.-Y. Jou, “On compliance test of on-chip bus for

SoC,” in Proceedings of the 2004 Asia and South Pacific Design Automation Conference.

Piscataway, NJ, USA: IEEE Press, 2004, pp. 328–333.

[63] A. Danthine, “Protocol representation with finite-state models,” IEEE Transactions on

Communications, vol. 28, no. 4, pp. 632–643, 1980.

63


[64] G. Bochmann, “A general transition model for protocols and communication services,”

IEEE Transactions on Communications, vol. 28, no. 4, pp. 643–650, 1980.

[65] V. D’silva, S. Ramesh, and A. Sowmya, “Synchronous protocol automata: a framework

for modelling and verification of SoC communication architectures,” in Proceedings of

the Conference on Design, Automation and Test in Europe, vol. 1, 2004, pp. 390–395.

[66] S. S. Alhir, Learning UML. O’Reilly, 2003.

[67] M. D. Kedalagudde, “Adding extensions to uml dynamic models for better embedded

system design,” Master’s thesis, University of Cincinnati, Cincinnati, 2012.

[68] P. Rashinkar, P. Paterson, and L. Singh, System-on-a-Chip Verification - Methodology

and Techniques. Springer, 2000.

64

Appendix A

SingleReadTransaction.java

//////////////////////////////////////

//Author : Kristin M. Barber

//Date : 03/25/2013

//Description : This class describes the behavior of an AMBA single read transaction

// in the form of a finite state automaton.

//////////////////////////////////////

public class SingleReadTransaction extends TransactionDefinition {

private State startState;

private State readState;

private State dataState;

public SingleReadTransaction() {

this.startState = new State("START");

this.readState = new State("READ").setErrorMessage("No return data");

this.dataState = new State("CPLD").setEndState();

this.currentState = startState;

}

public boolean isValid(Event evt) {

65

Appendix A. SingleReadTransaction.java

if (evt instanceof MasterEvent) {

MasterEvent mevt = (MasterEvent) evt;

if (currentState == startState &&

mevt.getTransType() == TRANSTYPE.NONSEQ &&

mevt.getBurstType() == BURST.SINGLE &&

mevt.getDirection() == DIRECTION.READ) {

ADD TO VIEW(VIEW.BASIC TRANSFER, this, mevt);

currentState = readState;

this.address = mevt.getAddress();

return true;

}

}

else if (evt instanceof SlaveEvent) {

SlaveEvent sevt = (SlaveEvent) evt;

if(currentState == readState &&

sevt.getResponseType() == RESPTYPE.OKAY &&

sevt.getAddress() == this.address) {

ADD TO VIEW(VIEW.BASIC TRANSFER, this, sevt);

currentState = dataState;

return true;

}

}

return false;

}

public boolean isComplete() {

return currentState.isEndState();

}

}

66

Appendix A. SingleReadTransaction.java

67

Appendix B

PSC Register Definitions

Figure B.1: PTSTAT Register Definition [11]

Figure B.2: EPCPR Register Definition [11]

68

Appendix B. PSC Register Definitions

Figure B.3: PTCMD Register Definition [11]

Figure B.4: PDCTLn Register Definition [11]

69

Documents

Untitled - OhioLINK ETD Center