1

A Survey:System-on-a-Chip Design and Verification

Ali Habibi and Sofiène TaharElectrical & Computer Engineering Department, Concordia University

Montreal, Quebec, CanadaEmail: {habibi, tahar}@ece.concordia.ca

Technical Report

January 2003

Abstract. In this technical report, we survey the state-of-the-art of the design and verifica-tion techniques and methodologies the System on-a-Chip (SoC). The advancement in thehardware area made it possible the integration of a complete yet complex system on a sin-gle chip. Over 10 million gates, integrated together and running a real time optimizedsoftware red crossed classical design techniques. Traditional Regiter Transfer level (RTL)will serve as an assembler language for the new design languages or so called systemlevel languages. A challenge facing the SoC designers is to decide which system level lan-guage we have to use and how the verification task will be accomplished. This report pre-sents the main proposals in defining a system level language and discusses the eventualverification techniques that can be used.

1. Introduction

A decade ago, the EDA industry went progressively from gate level to register-transfer-level abstraction. This is one of the basic reasons why this process gained a great increasein the productivity. Nowadays, an important effort is being spent in order to develop a sys-tem level languages and to define new design and verification methodologies and verifica-tion at this abstraction level.

The reason for all this activity is simple. Register-transfer level (RTL) hardware design istoo low as an abstraction level to start designing multimillion-gate systems (as shown inFigure 1). What is needed is a way to describe an entire system, including embedded soft-ware and analog functions, and formalize a set of constraints and requirements - all farbeyond the capabilities of existing HDLs. VHDL and Verilog both will become theassembly languages of hardware design. Designers and verifiers will write RTL code forthings that are performance-critical, nevertheless, for everything else, they will stop at ahigher level.

By looking at the specifications of embedded systems, particularly for communications,portable and multimedia equipment, we can realize an important and rapid growth in com-plexity making it a requirement System-on-a-Chip (SOC) solutions that generally inte-grate diverse hardware and software. Time-to-market and cost also need to be reducedmore than ever before and backed up by an effective marketing-driven strategy that can

2

meet today's highly competitive and demanding circumstances. To achieve all this, theproduct development process must assure the product specification phase is integratedsmoothly with the product design phase, allowing the customer's demands, marketinggoals and designer expertise, to be evaluated and analyzed at significantly less cost in timeand resources, and to be rapidly incorporated into the final product.

(a) The complexity growth. (b) The scaling of the dimensions.

Figure 1. Hardware Design Evolution [43].

System level languages proposals can be classified into three main classes. First, reusingclassical hardware languages such as extending Verilog to SystemVerilog [30]. Second,readapting software languages and methodologies (C/C++ [44], Java [5], UML [16], etc.).Third, creating new languages specified for system level design (Rosetta [2] for example).

The verification of SoC is a more serious bottelneck in the design cycle. In fact, definingSoC design language and methodology is a matter of time, however, the verification is avery open and ambigous question. Functional verification is consuming an inordinateamount of the design cycle time. Estimates vary, but most analysts and engineers agreethat as much as 70 percent of the design cycle is consumed by functional verification. Inaddition, the quality of these verification efforts has become more important than everbecause the latest silicon processes are now accompanied by higher re-spin costs. Nodoubt, classical random simulation is no more able to handle actual designs. Going furtherin complexity and considering hardware/software systems will be out of the range of thenowadays used simulation based techniques [32].

For intance, the main trends in defining new verification methodologies are considering ahybrid combination of formal, semi-formal and simulation techniques. The first step in

3

this direction was the definition of a standard for assertion languages. Such languages,which let engineers check properties during simulation and formal verification, havebecome crucial for complex chip design. For instance, the Sugar language [4] from IBMwas selected as a standard for this effect. A lot is expected from combining an assertionlanguage such as Sugar with both smart test generation and coverage analysis. This kindof hybrid techniques can offer a partial answer to the question: “Is verification task com-plete?”

This report is divided into three main sections. In Section 2, we introduce the concept of aSystem Level Language. We presented the UML language as a case study to illustrate thedefinition of such a class of languages in the software engineering domain. In Section 3,we consider the main proposals regarding the definition of a hardware system level lan-guage. In Section 4, we classify the main promising verification techniques for SoC veri-fication. Finally, Section 5 concludes the report.

2. System-Level Design

2.1. Problem Statement

Modern electronic systems grow in complexity encouraging combinations of differenttypes of components: microprocessors, DSPs, memories, etc. On the other side, and in thesame time, designers and programmers are asked to meet demands for shorter develop-ment time and lower development cost. Designers agreed that there is no way to meet thisdifficult target expect using higher abstraction levels in the design process, so-called Sys-tem Level Design [45]. System level design, requires system level tools that simulta-neously handle both hardware and software, for modeling, partitioning, verification andsynthesis of the complete system.

The software evolution story is replayed again in the hardware world. Migrating to thesystem level of abstraction introduces a higher order of complexity. To reach the nextlevel of complexity, EDA vendors and analysts are telling designers that another leap isnecessary - from RTL to system-level design. Such a leap implies that an increasingamount of hardware design will be done using C/C++, Java, SuperLog, or other high-levellanguages, while RTL VHDL and Verilog will be relegated to smaller blocks of timing-critical logic.

Nevertheless, a fact is the level of highest abstraction will be the one that survives, andthat is clearly the software domain. Considering the economic reality, this transition willnot be abrupt, but it will occur more as an evolution than a revolution. The most likelytransition will be along the lines that software followed as it evolved from a strict use ofhand-coded assembler in the fifties to extensive use of compilers in the sixties.

The most realistic scenario will start by migrating the non-critical portions of time-to-mar-ket-driven designs to higher levels. Then, progressively over time, more sophisticatedcompiler and synthesis technology augmented by increasing hardware functionality willextend the reach of automatic techniques until only extremely critical portions of highlyperformance-driven designs will be implemented at the register transfer level.

4

Eventually, the software and hardware design will end by getting into a single flow. Opti-mistically, in a few years, the difference, if it will exist, will be a matter of compileroptions ("-software" or "-hardware"). However, to get there, we need at first to define asystem level language.

2.2. Proposed Solutions

The usage of a system level language is a direct result of the way the SoC design processworks [31]. Following the software evolution, the most likely methodology would be topush toward successive refinement, an extremely successful methodology in softwaredevelopment. A possible solution is to define what are the basic requirements for a systemlevel language; intuitively, we would first spend a look to the way software design is actu-ally performed.

No doubts, a short-term solution will come from languages that "push up" from or extendcurrent HDL-based methodologies. We can not omit that languages like SuperLog [46]hold great promise for the next three to four years basically because SuperLog does notrequire a radical shift in methodologies and allows groups to retain legacy code. Thisapproach can be seen as a refinement of the existent languages. Some people defineSuperLog as “Verilog done right”.

The medium-range solutions will likely be C++-based languages that have hardwaredesign capabilities, we mention here SystemC [49] and Cynlib [10] as two promising lan-guages. The revolution can also come from the Java side.

Long-term language solutions will likely come from new languages developed just specif-ically to work at the system level such as Rosetta [2] which promise to make true system-level design a reality.

2.3. Case Study: UML as a Software System Level Languages

Software developers faced the problem of large yet complex projects long time beforetheir hardware counterparts. Dedicated system level languages have been introduced sincethe last 80s. However, the most and widely used solution is the Unified Modeling Lan-guage (UML) [8]. No one can deny that fact is that UML is becoming a lingua franca forsystem level modeling. Nevertheless, an open question is whether UML is rich enough torepresent hardware adequately.

As defined, UML is a vendor and tool-dependent notation for specifying, visualizing, con-structing and documenting software systems. Originally UML was developed by RationalSoftware Corp. and its partners and now under the auspices of the Object ManagementGroup (OMG) [8]. The first yet principle objective of UML was to let software developersdraw diagrams that can be, at least in theory, universally understood. At the time whenUML was born, it was quite early to think about the support of hardware systems. How-ever, the SoC facto made no choice for UML designers to rethink about their language ifthey want to keep it as a "default" system level language.

5

Most hardware companies are keeping an eye on UML. Trying, to cut the road on the soft-ware developers, Cadence as one of the leading EDA companies, for example, is lookingat UML as a possible source of input into the Cadence VCC hardware-software co-designsystem. Moreover, Cadence has joined the OMG as an auditing member and is trackingOMG's real-time analysis and design working group. On the other side, the embeddedsoftware companies are also tracking the UML guest. For instance, Project Technologyhas developed a prototype UML-to-VHDL compiler [16].

In an optimistic way, people supporting UML consider that this system level language isrich enough to represent any system. They go further and say that designing a SoC inUML will be as simple as taking requirements for the entire system and breaking it downinto big subsystems, then, the last step will be a simple breaking into hardware, softwareand mechanical components.

The People in the EDA busniss look at the problem in a more realistic way. They considerthat UML needs much more work before it can fully support real-time embedded hard-ware [21]. A fact is UML can not represent an "architectural" view with such attributes ashierarchy, structure, connectivity or bus width. No doubt this limitation will make it hardto do any real estimation about the use of UML.

Omitting the technical constraints, a fundamental problem facing UML is the question ofreceptivity. Will hardware engineers move up from block diagrams and schematics to thehigher-level abstraction of UML? The first step was done by software people to upgradeUML to support hardware by adding a causal model offering an automatic conversion ofrequirements into test vectors. However, without a strong collaboration between bothhardware and software plyers there is no way for UML to become a default system levellanguage for SoC.

3. System-on-a-Chip System Level Language

3.1. Requirements

Any language proposing to support system-on-a-chip design must address two importantdesign characteristics. Namely, the integration of information from multiple heteroge-neous sources and the ability to work at high levels of abstraction with incomplete infor-mation [31]. This can be defined as:

- Support for integrating domain specific specifications- Composition of models of computation that describe systems and components- Representation and integration of constraint information- Support for more abstract modeling- Moving up from implementation technology- Support for predictive analysis and verification- Within specific domains- Across multiple domains

6

- Formal semantics is a must- Consistent and continuous design process and exploration of design space from speci-fication design to implementation design- Design reuse, which means not only of component IP but also specification IP and design case IP.

3.2. Extending Existent HDLs: SystemVerilog

A radically revised Verilog [47] language took shape at the International HDL Conferenceas presenters unveiled a language reaching toward much higher levels of abstraction. Sys-temVerilog blends Verilog, C/C++ and Co-Design Automation's SuperLog language tobring unprecedented capabilities to RTL chip designers.

As shown in Figure 2, key additions to SystemVerilog, which is a set of extensions to theIEEE 1364-2001 Verilog Hardware Description Language [30] to aid in the creation andverification of abstract architectural level models, include interfaces that allow moduleconnections at a high level of abstraction; C-language constructs such as globals; and anassertion construct that allows property checking. SystemVerilog includes the synthesiz-able subset of SuperLog, and its assertion capability will likely be derived from the DesignAssertion Subset that Co-Design and Real Intent Corp. recently donated to the Accellerastandards body.

Figure 2. SystemVerilog [27].

With all these enhancements, SystemVerilog may remove some of the impetus from C-language design, at least for register-transfer-level chip designers. The basic intent is to

7

give Verilog a new level of modeling abstraction, and to extend its capability to verifylarge designs.

Interfaces are one of the most significant introductions in SystemVerilog. The IEEE 1364-2001 Verilog spec, Verilog-2001, connects one module to another through module ports,but this is tedious. The new "interface" construct makes it possible to begin a design with-out first establishing all the module interconnections. Usually, interfaces allow the group-ing of connections between modules, and can also contain logic. In other terms, it ispossible to have procedures and other functionality within the interface itself. Also impor-tant is the introduction of global declarations and statements. For now, only module andprimitive names can be global in Verilog. SystemVerilog will allow global variables andfunctions via a new "$root" construct.

Abstract data types are another addition. SystemVerilog borrows the C-language "char"and "int" data types, allowing C/C++ code to be directly used in Verilog models and veri-fication routines. Both are two-state signed variables. Other new constructs include "bit,"a two-state unsigned data type, and "logic," a four-state unsigned data type that claimsmore versatility than the existing "reg" and "net" data types. Other new features includesigned and unsigned modifiers, user-defined types, enumerated types, structures andunions, a "jump" statement and parameterizable data types within modules. SystemVer-ilog also removes any restrictions on module ports, allowing users to pass arrays andstructures through ports.

The slogan of the people supporting Verilog is: "The right solution is to extend whatworks". However, this may face a harsh critisim from people supporting C++ based solu-tions and who advance that Verilog or SystemVerilog or whatever is the Verilog basedname will not offer a short simulation time. The debate is quite hard and the last word willnot be said soon!

3.3. Extending Software Languages

Some optimistic software designers are supporting the establishment of C/C++ [25] oreven Java [29] based languages for future SoC designs. They think that, over time,improvements in automatic methods and increases in hardware functionality will extendthe pieces handled automatically to where whole designs can be implemented by "cc -sili-con". In the near term, however, tools are not going to be good enough and manual refine-ment will be required. This means that the version of the language that will be used mustallow for the expression of hardware at lower levels, not just the algorithmic level.

Mainly reusing existent languages is performed either by extending the language itself (byadding new keywords and constructors) or by defining new libraries allowing the descrip-tion of hardware systems. The most relevant approaches consider either C/C++ or Java. Infollowing, we will put more light on the proposals based on these two languages.

8

3.3.1. C/C++ Based Proposals

Over the past decade, several different projects have undertaken the task of extending C tosupport hardware [25], including SpecC [13] at the University of California, Irvin, Hard-wareC [12], Handel-C [25] at Oxford University (now moved to Embedded SolutionsLtd.), SystemC++ [37] at C Level Design Inc., SystemC [48] at Synopsys Inc., and Cynlib[10] at CynApps.

These variety of projects fall roughly into two complementary categories. One category,exemplified by SpecC, has focused on adding keywords to the basic C language, support-ing hardware description at a high level as a basis for synthesis [13]. The other category,exemplified by SystemC, exploits the extensibility of C++ to provide a basic set of hard-ware primitives that can be easily extended into higher level support [44]. These two com-plementary approaches span all levels of hardware description (algorithmic, modular,cycle-accurate, and RTL levels).

People supporting this approach argue that the best way to do system-level design is witha general-purpose language and that C++ is clearly the best choice. Because it is extend-ible and notions such as concurrency can be easily represented in class libraries. Besides,the object-oriented nature of C++ corresponds perfectly to the HDL hierarchy [51].

The art of applying SoCs to real systems is dominated by software. So it is easy to see whyC/C++-based design languages are rapidly gaining popularity. Many have mistakenlybelieved that such languages, like SystemC, aim to replace hardware-description lan-guages, such as Verilog, for pure hardware design at the register transfer level. But thatholds very little advantage, and the vast majority of companies backing SystemC, includ-ing CoWare, are not trying to replace the Verilog designer.

3.3.1.1. SpecC

The SpecC language is defined as extension of the ANSI-C programming language [15].This language is a formal notation intended for the specification and design of digitalembedded systems including hardware and software. Built on top of the ANSI-C program-ming language, the SpecC language supports concepts essential for embedded systemsdesign, including behavioral and structural hierarchy, concurrency, communication, syn-chronization, state transitions, exception handling and timing [14].

Originally, the SpecC language was developed at University of California, Irvine, withsponsorship from Toshiba, Hitachi and other companies [13]. Based on C, it allows thesame semantics and syntax to be used to represent specifications in a conceptual system,hardware, software, and, most importantly, intermediate specification and informationduring hardware/software co-design stages.

SpecC targets the specification and design of SoCs or embedded systems including soft-ware and hardware whether using fixed platforms, integrating systems from different IPs,or synthesizing system blocks from programming or hardware description languages [24].The SpecC methodology leads designers from an executable specification to an RTLimplementation through a well-defined sequence of steps. Each model is described and

9

guidelines are given for generating these models from executable specifications. SpecC isintended to be used for specification analysis, specification capturing and system co-design as described in Figure 3.

To defend SpecC against C++ proposals and mainly SystemC, when this latter was firstintroduced in 1999, SpecC supporters claim that SystemC is primarily aimed at simula-tion, however, SpecC was developed with synthesis and verification in mind. They alsoconsidered that SystemC targets RTL design, but SpecC is a system-level design languageintended for specification and architectural modeling. Nevertheless, after the release of theversion 2.0 of SystemC, all these argument were broken. In fact, SystemC is nowadayssupporting all System Level Design requirements.

Figure 3. SpecC in the Design Flow[14].

3.3.1.2. HardwareC

Under the same class of C-based languages we find also a language called HardwareC[34]. This is a language that uniformly incorporates both functionality and design con-straints. A HardwareC description is synthesized and optimized by the Hercules and Hebesystem [11], where tradeoffs are made in producing an implementation satisfying the tim-ing and resource constraints that the user has imposed on the design. The resulting imple-mentation is in terms of an interconnection of logic and registers described in a formatcalled the Structural Logic Intermediate Format [33].

HardwareC attempts to satisfy the requirements stated above. As its name suggests, it isbased on the syntax of the C programming language. The language has its own hardwaresemantics, and differs from the C programming language in many respects. In particular,numerous enhancements are made to increase the expressive power of the language, aswell as to facilitate hardware description [34]. The major features of HardwareC are thefollowing:

10

•Both procedural and declarative semantics - Designs can be described in HardwareCeither as a sequence of operations and/or as a structural interconnection of compo-nents.

•Processes and interprocess communication - HardwareC models hardware as a set ofconcurrent processes that interact with each other through either port passing or mes-sage passing mechanisms. This permits the modeling of concurrency at the functionallevel.

•Unbound and bound calls - An unbound call invokes the functionality correspondingto a called model. In addition, HardwareC supports bound call that allows thedesigner to constrain the implementation by explicitly specifying the particularinstance of the called model used to implement the call, i.e. bind the call to aninstance.

•Template models - HardwareC allows a single description to be used for a group ofsimilar behaviors through the use of template models. A template model is a modelthat takes in addition to its formal parameters one or more integer parameters, e.g. anadder template that describes all adders of any given size.

•Varying degrees of parallelism - For imperative semantic models, HardwareC offersthe designer the ability to adjust the degree of parallelism in a given design throughthe use of sequential ([ ]), data-parallel (f g), and parallel (< >) groupings of opera-tions.

•Constraint specification - Timing constraints are supported through tagging of state-ments, where lower and upper bounds are imposed on the time separation betweenthe tags. Resource constraints limit the number and binding of operations toresources in the final implementation.

As any real system a SoC is no more than a number of entities and objects interactingtogether. This is the reason for the limitation of the C-based proposals. By reference tosoftware design, languages that can be used at the system level have to be preferablyobject-oriented. This is the reason why nowadays more mature proposals are based onC++. In this report we will discuss mainly two C++ based proposals: Cynlib and Sys-temC.

3.3.1.3. Cynlib

Cynlib provides the vocabulary for hardware modeling in C++. It is a set of C++ classeswhich implement many of the features found in the Verilog and VHDL hardware descrip-tion languages. It is considered as a "Verilog-dialect" of C++, but it is more correct to saythat it is a class library that implements many of the Verilog semantic features. The pur-pose of this library is to create a C++ environment in which both hardware and testingenvironment can be modeled and simulated [10].

Cynlib supports the development of hardware in a C/C++ environment. To do this, Cynlibextends the capabilities of C/C++ by supplying the following features, Concurrent Execu-tion Model, Cycle-Based, Modules, Ports, Threads, Deferred Assignments, Two-state datavalues, Multiple clocks and Debugging support.

11

By using Cynlib to model at the highest levels of abstraction and throughout the designprocess, any problems (bugs) with the algorithm or implementation will get fixed as earlyas possible. For example, it is much easier to isolate, debug and fix a protocol error at thealgorithmic level than it is at the register-transfer level. In the worst case, fixing the RTLcould be as time-consuming as adding or removing states from the finite state machineand reworking the data path. Of course, this is assuming that the bug can be easily identi-fied as a protocol error in the first place.

Another advantage of design with Cynlib and Cynthesizer [22] is that designers can usethe object-oriented features of C++ to produce a more natural and understandable repre-sentation of the design. The most obvious application is the use of C++ classes as high-level data structures. Using high-level data structures where appropriate provides a lesserror-prone approach to design. Cynthesizer's ability to transform object-oriented featuresof C++ (such as classes) to Verilog or VHDL allows designers to maintain the usage ofthese features throughout the design process.

Finally, adopting C++ as a design language promotes a unified flow between hardwareand software designers. Most system and algorithm developers have been working in C++for years. By using Cynlib C++ to describe hardware, we get into a situation where thealgorithm, the software, the hardware and the testbench are all written in the same estab-lished language. The complete Forte chain is illustrated in Figure 4.

.

Figure 4. Cynapp Proposal [22].

12

3.3.1.4. SystemC

SystemC [49] is also among a group of design languages and extensions being proposed toraise the abstraction level for hardware verification. It is expacted to make a strongereffect in the area of architecture, the co-design and integration of hardware and software[41]. The reason lies partly in the deliberate choice to extend a software language withnonproprietary extensions to describe hardware and system-level modeling. However,SystemC is merely a language, so a greater part of the reason for any success in this area isthe availability of supporting tools and methodologies proved to cut design cycles at suchleading companies as Fujitsu, Matsushita, Sony and STMicroelectronics.

SystemC comes to fill a gap between traditional HDLs and software-development meth-ods based on C/C++. Developed and managed by leading EDA and electronics compa-nies, SystemC comprises C++ class libraries and a simulation kernel used for creatingbehavioral- and register-transfer-level designs. Combined with commercial synthesistools, SystemC can provide the common development environment needed to supportsoftware engineers working in C/C++ and hardware engineers working in HDLs such asVerilog or VHDL.

Designers have started to create virtual platforms of their SoC designs in C or SystemC forgood reasons. First, they can provide an early simulation platform for the system integra-tion that executes much faster than HDL-based co-verification. Second, they can verifythe architecture at an early stage of the design process, testing different hardware-softwarepartitions and evaluating the effects of architectural decisions before implementation.After all, by the time they are coding in RTL, the hardware architecture is established andthere is little room for flexibility. Third, they can start work on derivative or next-genera-tion designs by reusing the platform before the first-generation design is complete [48].

Simulating in C or SystemC avoids the need to use the Verilog Program Language Inter-face (PLI) [47] or VHDL Foreign Language Interface (FLI), both of which are used tohook C-based models or testbenches to HDL simulations. By converting to C, a singleexecutable code can be used hence there is no need for a PLI or FLI, which becomes realbottlenecks in large simulations.

Virtual platforms can, and should, be used at various abstraction levels, starting with avery simple functional description and then refining towards implementation. As each part(that includes hardware or software) of the design is refined, it can be tested in the contextof the entire system. Often, parts of the design that did not interface with the new blockbeing tested can be run at higher levels of abstraction to speed simulations.

The main question: will SystemC primarily be used by the small number of systemdesigners already working in C/C++ or by the much larger number of RTL chip designersusing VHDL or Verilog? The latter group has so far shown a lot of skepticism about C-language design and has warmed more to SystemVerilog and then SuperLog as a way ofmoving up in abstraction.

The next question: why wouldl system designers benefit from system? There are alreadySystemC tools that help automate the transition from C to HDLs. The best argument,

13

probably, is that SystemC models of intellectual-property (IP) blocks can be exchangedwith other companies, while proprietary C models generally cannot.

The point that may often be missed is that C/C++ language design is already in wide-spread use today. It is being used by many major electronics manufacturers, particularly inEurope, for system-level modeling and silicon intellectual property (IP) design. In thissense, C language design is an old methodology, not a new one.

Most of these companies, however, use their own proprietary C/C++ class libraries, mak-ing IP exchange very difficult. That's where SystemC comes in. One standardized librarywill allow companies to mix and match C language IP from different sources. SystemC isreally about IP modeling, not forcing RTL designers into a new methodology.

C language models can also help speed RTL simulation. It has always been possible tobring in C language models through the Verilog programming language interface (PLI),but some vendors are looking at more efficient ways to create this link. C/C++ languageapproaches to testbench generation, such as Cadence Design Systems' TestBuilder library,may also appeal to some designers.

New releases of Cadence Design Systems Inc.'s Signal Processing Worksystem (SPW)software and Axys Design Automation Inc.'s MaxSim Developer Suite increase supportfor SystemC. Designers are now allowed to add custom blocks using SystemC usingSPW. The tight connection SPW 4.8 has with SystemC 2.0 - through a Block Wizard -accelerates reuse of models written in an industry-standard modeling language, as well asmodels customers have written in SPW. Cadence will also announce that it is donating itsTestbuilder class libraries to the Open SystemC Initiative to encourage testbench reuse.

Mentor Graphics Corp. has also added a C language interface to its Seamless hardware/software co-verification environment that lets designers use mixed C/C++ and HDLdescriptions for hardware. The interface, called C-Bridge, will be included with Seamlessversion 4.3, which is to be released in late March 2003. HDL simulation users today canbring in C code through the Verilog programming language interface (PLI) or VHDL for-eign language interface (FLI), but C-Bridge supports faster performance and a higher levelof abstraction. The interface supports abstract reads and writes for bus connections, butcan still be cycle-accurate. C-Bridge provides an applications programming interface(API). To use it, designers adapt their C language models to read and write through theAPI. They instantiate the models in Seamless, where they're dynamically loaded intoinstruction-set simulation (ISS). However, C-Bridge provides its own source-level debug-ging environment rather than using the ISS debugger. C-Bridge imposes no limitations onC language code, and can be used with SystemC version 2.0 models.

SystemC in one of the most important players as a future SoC design and verification lan-guage. The big interest given by the major companies in the SoC design and verificationfields to SystemC is quite a good proof for that. The debate is being concentrated on eithergoing for SystemVerilog (and then SuperLog) or for SystemC. For instance, bothapproaches are coexisting together; they eventually could play together in the future.

14

3.3.2. Java-Based Proposals

While there has been some discussion about the potential of Java as a system-level lan-guage or high-level hardware description language (HDL), LavaLogic [5] may be the firstcommercial EDA provider to bring that option into contemporary design systems. Thecompany's Java-to-RTL compiler is an "architectural synthesis" tool that turns Java intosynthesizable HDL code. LavaLogic is offering a tool that will take high-level Javadescriptions down to gate-level net-lists, starting with FPGAs [29]. The architecture of theLavalogic solution is given in Figure 5.

According to Java advocates, Java appears to be the purest language to solve the produc-tivity problems currently at hand. They also claim that the language can express high-levelconcepts with far less code than today's HDLs, yet offer more support for concurrencythan C or C++.

Specifically, LavaLogic advances that the code required for a functional description inJava is typically one-tenth that required for Verilog. Java simulation models are 100 to1,000 times faster. This is what the company advised however no rigorous proof was doneuntil now regarding this point.

Figure 5. Lavalogic Java Based Proposal [5].

15

The main point all Java advocates stressed in comparing their approach to those C/C++ isthe concurrency. In fact, a classical problem with C and C++ is their inherent inability toexpress concurrency. In Java, in contrast, concurrency can be explicitly invoked withthreads. Nevertheless, this unique criteria for comparison is not enough to balance thechoice C/C++ to Java. Java can be classified as the "next best" choice after C++, since itdoes not support templates or operator overloading, resulting in a need for numerous pro-cedure calls.

3.4. Developing a new Language

3.4.1. SuperLog and SystemVerilog

SuperLog [46] is a Verilog superset that includes constructs from the C programming lan-guage Because of its Verilog compatibility, it has earned good reviews from chip design-ers in such forums as the E-Mail Synopsys User's Group, where some designers haveexpressed considerable skepticism about C language hardware design. SuperLog holds agreat promise for the next three to four years. It is the case mainly because SuperLog doesnot require a radical shift in methodologies and allows groups to retain legacy code.

SuperLog combines the simplicity of Verilog and the power of C, and augments the mixwith a wealth of verification and system features [20]. Realizing that there is no point inhaving a language without being able to do something with it, ex Co-Design (boughtrecently by Synopsys) also offers a suite of simulation tools making it ready for industrialapplications.

Figure 6. From Verilog to SupeLog [36].

For now we have Verilog 2001 at the lower end of the sophistication spectrum ("jolly nicebut lacking a lot of features") and SuperLog at the other end ("incredibly powerful, but asyet falling well short of industry-wide support"). This is where Accellera reenters the pic-ture. By working with Co-design and others to come up with a common meeting ground,which is SystemVerilog 3.0, Figure 6.

16

Figure 7. SuperLog Description [36].

The great advantage for SystemVerilog 3.0 from most people's perspective is that itincludes things like assertions and extended synthesis capabilities, and it is an Accellerastandard, so it will quickly gain widespread adoption. The advantage for Co-Design is thatit's a step along the way to transmogrifying the Verilog everyone is using into SuperLog.

Actually Figure 6 is somehow simplifief, because there could be a number of intermediatesteps before SystemVerilog 3.0 evolves into SuperLog. Figure 7 displays how Co-Designexpects SuperLog to be.

SuperLog, as described in Figure 7, retains most of the features of Verilog and VHDL,including support for hierarchy, events, timing, concurrency and multivalued logic. It alsoborrows useful features familiar from software-programming languages such as C andJava, including support for dynamic processes, recursion, arrays and pointers. It includessupport for communicating processes with interfaces, protocol definition, state machinesand queuing [9].

In a certain way as defined, SuperLog is a smart idea to deal with system level design. Infact, SuperLog utilizes the power of C with the simplicity of Verilog to provide the rightbalance for productive design.

3.4.2. Rosetta

Now in the final stages of development by the Accellera standards organization, Rosettarepresents a unique approach to system-level design. It provides one language that letsusers describe behavior and constraints for nearly all engineering domains, including ana-log, digital, software, microfluidics and mechanical [2]. The declarative Rosetta languagepreceedes, but does not replace, implementation languages like Verilog, VHDL and C.

17

Launched in 1997 with Defense Advanced Research Projects Agency (Darpa) funding,Edaptive started working on system-level design before Rosetta was developed. The con-cept was to develop innovative products for designers of large and complex computingsystems, especially mixed technology systems.

Rosetta is not designed to take the place of other languages, it tries to coordinate them.Rosetta is introduced to fill one "hole" in present capability --- the definition, capture, andverification of constraints and requirements on high level systems and their components. Itprovides language support for defining and combining models from multiple domainsusing multiple-domain semantics. In addition, it supports modeling and analysis at levelsof abstraction much higher than those of current RTL-based languages. Its semantics areformally defined and it is highly extensible to support the adaptation to emerging systems.

Rosetta allows modeling at high levels of abstraction, modeling of heterogeneous systemsand support for model composition. By allowing the user to define and compose models, itallows flexibility and heterogeneity in design modeling and supports meaningful integra-tion of models representing all aspects of system design. Furthermore, Rosetta's formalsemantics provide an unambiguous means for defining and composing models. Finally,the default Rosetta syntax provides a user-friendly mechanism designed to be comfortablefor today's existing HDL user base [1].

Figure 8. Facet Modeling Concept in Rosetta [52].

The Rosetta design methodology is based on the facet-modeling concept (Figure 8). Afacet is a model of a component or system that provides information specific to a domainof interest. To support heterogeneity in designs, each facet may use a different domainmodel to provide domain-specific vocabulary and semantics. Facets are written to definevarious system aspects and are then assembled to provide complete models of compo-nents, component aggregations and systems.

The definition of facets is achieved by directly defining model properties or by combiningpreviously defined facets. The former technique allows users to choose a specification

18

domain and specify properties that must hold in that domain. The latter technique allowsusers to select several models and compose a system model that consists of elements fromeach facet domain. The abstract semantics of Rosetta are based on this specification andcombination of models representing information from various design domains. The syntaxof Rosetta facets is designed to be familiar to engineers using existing hardware descrip-tion languages. What makes the facet model different than traditional HDL approaches isthe identification of specific domains.

A primary difficulty in addressing the system-on-chip problem is combining informationfrom multiple domains within a single design activity. The domain concept allows this byenabling each model to refer to a base set of concepts that supports definition of informa-tion in one particular design area. For example, in a trigger specification the continuousdomain provides the concepts of time, instantaneous change, ordering and state. Such con-cepts are important to continuous-time modeling, but may not be important when model-ing power consumption or area.

The Rosetta semantic model is important because it reflects how system engineers cur-rently tackle their problems. The syntax makes the semantics approachable. But the realcontribution of Rosetta is the semantics of designing and composing component models.Through the use of domains, users are provided with design vocabulary specific to theirdomain of expertise rather than forcing the domain expert to work in a language that is toogeneral or otherwise unsuitable for his or her needs.

Heterogeneity in system design not only emerges when defining multiple facets of thesame system, but also when describing systems structurally by combining components.VHDL provides a structural definition capability that is mimicked in the Rosetta seman-tics using a concept called relabeling. When one facet is included in another, an instanceof that facet is created by relabeling or renaming the facet. Facet parameters are used asports and channel data types used to model communication between components.

Like single components, Rosetta systems may include component models from multipledesign domains. Thus, Rosetta provides a mechanism for defining and understanding sys-tems comprised of components from analog, digital, mechanical and optical domains inthe same semantic framework. Furthermore, users may define new specification domainsto extend Rosetta to address new domains and new modeling techniques for existing ones.Such a capability is extremely important for the future of any potential system-design lan-guage.

Unfortunately, it is not sufficient to simply model domain-specific information in isola-tion. Cross-domain interaction is the root cause of many systems failures and difficultdesign problems. System-level design requires understanding the collective behavior ofinterconnected components from different design domains, not simply the component-level behaviors. Further, interaction also occurs between different models at the compo-nent level. Rosetta provides methodologies for explicitly modeling and evaluating suchinteractions by describing how definitions from individual domains affect each other.

19

Finally, no one can deny that Rosetta, as defined, is too close to VHDL. On the other handa question is why to complicate the design procedure by bridging between multiple func-tional languages? The single approach can solve most system-on-chip design problemsand complicating the problem too much is not the way industry is supposed to work!

4. SoC Verification

As system-on-chip designs become a driving force in electronics systems, current verifica-tion techniques are falling behind at an increasing rate. A verification methodology thatintegrates separate but key technologies is needed to keep up with the explosive complex-ity of SoC designs [32].

A SoC verification methodology must address many more issues than were prevalent evena couple years ago, in particular the integration of purchased and in-house IPs into newdesigns, the coupling of embedded software into the design, and the verification flow fromcore to system. Several key concepts are important to understand, including the transitionfrom core to system verification, the re-use and integration of multiple sources of cores,and the support needed to optimize core re-use.

There are two major problem areas with SoC verification today that keep the verificationas a true bottleneck: IP core verification, and the System Level Verification (SLV).

The verification of today's IP cores tends to be inward focused. For example, the verifica-tion of a PCI IP core would test the bus modes and address space. This verification is use-ful, and helps provide information on the core functionality to the IP integrator. However,all this verification does not help a great deal at the system level, when the PCI core isconnected to the rest of the system. How should the software team write drivers involvingthis IP core? What if the core needs modification? Will there be any architectural issuesthat arise when it's too late to change the core? All these make IP use, and reuse, challeng-ing.

One effective technique for SLV is to use pre-defined verification IP. These can take twoforms:

•Verrification Components (VCs). These are generally stand-alone verification build-ing blocks that are based on industry standards, and that can be plugged into a verifi-cation environment and provide "instant-on" validation. They ideally incorporatemonitors and protocol checkers, bring-up tests, efficiency routines, and sometimes astandard conformance suite, and are designed for use at the block level up to the sys-tem level with no modification. An example is a 1-Gigabit Ethernet verification com-ponent.

•Verification Platforms (VPs). These are generally an integration of multiple verifica-tion components, specific data generators, score-boarding mechanisms, and a high-level verification suite that are targeted at a specific domain application. An exampleis a Storage Area Networking verification platform, which includes Fiber Channel,Gigabit Ethernet, and PCI VCs, a packet generator and scoreboard, and iSCSI sup-port.

20

4.1. Transactional Based Verification

Functional testing of system-on-chip software is difficult, especially when mature hard-ware does not exist yet [18]. A similar situation holds true for SoC-based devices whosebehavior is a function of many factors interacting in complex ways. Testing each featureor subsystem separately is not enough to ensure correct operation, and testing for all possi-ble factor combinations is infeasible [7].

Testing SoC-based devices, with a focus on software functionality, is inherently difficult.Testing SoC-based devices under construction only makes things worse, adding hardwareand software immaturity issues, typically compounded by limited availability of testdevices.

SoC and multi-chip system developers can no longer rely on traditional simulation tools,testbenches, and methodologies, but must augment these approaches to enhance verifica-tion productivity and to achieve quality and time-to-market goals [23]. This has created aserious need for a change in verification methodology. The industry must raise the verifi-cation bar to the next level of abstraction - transactions - to ensure that designers and veri-fication engineers have the tools and methodologies that give them a higher degree ofconfidence in their designs [35].

A transaction is a single conceptual transfer of high-level data or control. It is defined byits begin time, end time, and all the relevant information associated with the transaction.This information is stored with the transaction as its attributes.

For example, the relevant information (or attributes) of a Read transaction includesaddress and data. Transactions can be as simple as a memory Read/Write or as complex asthe transfer of an entire structured data packet through a communication channel. Trans-action-Based Verification (TBV) enables the use of transactions at each phase of the veri-fication cycle. The transaction level is the level at which the intended functionality of thedesign is specified and, therefore, the level at which the design can be verified in a mosteffective way. Raising the level of abstraction from signals to transactions facilitates thecreation of tests, the debugging process, and the measurement of functional coverage.

While the design operates at the signal level with ones and zeros, a transaction-basedmethodology allows a hardware designer to create tests in a more intuitive way. Systemarchitects do not start out thinking about the relationship between the enable signal and theaddress bus. They start their design by thinking about what kind of data flows through thesystem and how and where it is stored. TBV is a natural extension of this high-level designprocess.

The typical verification process is comprised of three phases: test creation, design debug-ging, and functional coverage analysis. Each of these phases must be abstracted to transac-tions to take full advantage of the benefits of transaction-level verification.

Some companies have adopted transaction-based test development to verify their designs.In the Verilog world, tasks are used to implement transactions. In the VHDL world, proce-dures are used to implement transactions.

21

Although this is acceptable for basic tests, it has too many limitations when creating com-plex data structures, complex test scenarios, and dynamic test creation. High-level verifi-cation (HLV) languages, such as TestBuilder (C++), Vera, E, and others were developedto address these complicated issues.

A significant amount of time is spent debugging verification tests, which is an area thatcan greatly benefit from the use of transactions. The benefits come from the quick identifi-cation of transactions in the waveform tool by design and verification engineers withoutwading through low-level signal details.

Today users have to write massive testbenches to shake out easy bugs. Using assertionsallows users to shake out bugs early in the process, so verification engineers can focus oncorner-case bugs-the areas where they think they are really going to have problems with adesign. Assertion-based technology has thus far been slow to catch on, but that it willbecome a critical element as designs-and, thus, functional verification-become more com-plex.

To this end, Cadence has folded into its Verification Cockpit a package that addsadvanced features to its NC-Sim simulation offerings, along with support for Sugar 2.0and static-checking capabilities. The new assertion capability lets users capture specifica-tions, requirements and assumptions as assertions, then verify the assertions staticallyusing the tool's new static-check capabilities.

4.2. Code Coverage Analysis

Coverage has become a key technology in the pursuit of efficient and accurate verificationof large designs [32]. The easiest form of coverage to introduce into a verification method-ology is register transfer level (RTL) coverage. Tools are available that, given an existingRTL design and a set of vectors, will provide valuable information. Apart from learning touse the tool and spending some time understanding the reports, RTL coverage does notfundamentally change the existing methodology and therefore can be added to any designproject [19].

Figure 9. Semi-Formal approach: Hybrid Model Checking and Simulation Solution.

22

The basic idea behind RTL coverage is that, if the designer wrote a line of RTL, it wasmeant to be useful for something. While the tool does not know what for (a limitation thatwe will discuss later), it can correctly identify problems when a line was not used for any-thing at all.

RTL coverage users should heed one major warning: it is tempting, whenever the toolfinds one case that was not covered, to add some vectors to cover it. While doing so willquickly increase the coverage results to whatever management asks for, it is the wrongapproach from a methodology standpoint.

Often overlooked, the first limitation of RTL coverage tools is that they do not know any-thing about what the design is supposed to do. Therefore, the tools can only report prob-lems in the RTL code that has been written. There is no way for them to detect that somecode is missing. This simple fact means that RTL coverage will never find more than halfof any design's bugs. Some bugs are due to incorrectly written RTL, while some bugs aredue to RTL that is simply not there.

The second limitation of RTL coverage is the lack of a built-in formal engine. An expres-sion coverage tool would see no problem in reporting that certain combinations of theexpression inputs were not covered, even though by construction, they are mutually exclu-sive and therefore formally unreachable [39]. This "spurious" reporting adds to the confu-sion and limits the effectiveness of coverage. Constant propagation and effective deadcode detection would also benefit from such an analysis.

Functional coverage analysis is used to determine if verification testing has exercised allof the required design functionality. Functional coverage exploration can be as simple asdetermining if a specific transaction occurred, such as a Read or Write to the RAM, or ascomplicated as a sequence of transactions, such as back-to-back Reads of the sameaddress in the RAM.

Functional coverage is being a hot topic these days because companies need more thanever needed before to be able to determine when verification is complete. Functional cov-erage refers to a metric that defines this completeness. Many companies are stating func-tional coverage will be an important component of their next-generation verificationmethodologies.

Verification metrics are a set of numbers used to determine how much design functional-ity the verification suite has exercised. Functional metrics and structural metrics are thetwo major classifications in verification metrics.

Functional metrics refers to metrics that create reports on the measurement of functional-ity exercised in the design. This class has the best correlation to functionality defects. Forexample, a defect is found if required functionality, such as the execution of a multiplyinstruction in a processor, is exercised and it fails. Functional metrics is difficult to imple-ment because the verification engineer must extract the list of functionality to be searchedfor, and devise a means of proving that the functionality was exercised. This work is donein an ad-hoc manner today.

23

Structural metrics refers to metrics that create reports on structural issues, such as whichlines of code or which states in a state machine have been exercised. The types of metricsthat fall into this class are code coverage (statement, branch, path, expression, toggle cov-erage) and state machine coverage. This class has a weaker correlation to functionalitydefects. For example, if an entire regression suite of tests is executed, and findings showthat lines of code used to implement the multiply instruction of a processor were not exe-cuted, further investigation is required to determine if a defect was found. Structural met-rics, however, are easier to implement because it requires no additional effort by theverification engineer except execution of a code coverage tool.

Nowadays, structural metrics, such as code coverage, are getting more interest. A fact is,these metrics are relatevely easy to implement and interpret. However, increasing designcomplexity has made the use of structural metrics alone inadequate; therefore, addingfunctional metrics for future designs is becoming a must.

Coming from the software side, code coverage metrics provide a structural coverage viewof design verification. Structure refers to components of the design such as lines of code,variables, and states. Metrics tell a verification engineer which structure (line, variable,state) of the design was exercised.

Functional coverage metrics provides a functional view of verification completeness,which is more desirable than a structural view. Historically, functional coverage metricshave been harder to use because it requires the verification engineer to decide which func-tionality should be checked and then determine if that functionality was exercised. Sched-ules usually do not include time to create the design knowledge and measurement methodsneeded for this coverage. For this reason, many engineers perform manual functional cov-erage. This involves manually reviewing the results of a test to determine the functionalityexercised. Manual review can mean looking at signals in a waveform viewer. This time-consuming and sometimes error-prone process usually occurs only a small number oftimes, sometimes only once. Generally, manual functional coverage is not done when adesign changes due to bug fixes or feature creep (additional features added during thedevelopment cycle). It is assumed that despite a slight change in functionality, overallcoverage remains the same.

Functional coverage is the good methodology to test designs exhaustly but never beingable to answer the question is verification complete? Traditionally, this metric has notbeen used because of the historic difficulty in implementing it. The two most complexissues are defining tests that execute the desired functionality and collecting the functionalcoverage data to determine the metric. Advances in directed randomization technologyaddress the issue of creating tests. The development of tools to capture and analyze trans-action-based information addresses the collecting, analysis and determination of the met-ric. The combination of these two advancements will reduce the complexity ofimplementing functional coverage metrics.

The Accellera organization was considering four languages for the job of beign a standardfor system and properties specification: Temporal e from Verisity, CBV from Motorola,Sugar from IBM and ForSpec from Intel. Sugar was selected and therefore will serve as a

24

standarad for model checkers in the future. A details description about Sugar is given inthe coming paragraphs.

4.3. Formal Verification

Two main formal verfication techniques are used in the EDA industry. The first is theequivalence checking which refers mainly to a comparison of an RTL version of thedesign to its gate-level equivalent, or the comparison of two gate-level netlists. The othertechnique is model checking [42] which concerned with properties verification mainly atthe RTL level.

Model checkers are the most adequate formal technique to be used at the system leveldesign. Classicaly, model checkers accept the RTL for a design block and a set of proper-ties associated with that block (for instance, "Signals A and B must never be low at thesame time". The model checker then exhaustively analyzes the design to check if theseproperties are true in every possible case.

With this technique there are no corner cases, because the model checker examines 100%of the state space without having to simulate anything. However, this does mean thatmodel checking is typically used for small portions of the design only, because the statespace increases exponentially with complex properties and onr quickly runs into a "statespace explosion.

Figure 10. Using Model Checking for SoC Verfication.

For instance, there is no “new” model checkers adapted for system level design of the SoCdomain. The main reason for that is the classical poblem of state explosion related to thiskind of tools. Nevertheless, what is interesting about these techniques is the definition ofhiereachical verification allowing the use of the checkers for small design portions asdescribed in Figure 10.

The most relevant progress for the future use of model checkers for SoC verification is theselection of the Sugar [27] language as a new standard for formal properties and systems

25

specification. In the coming two paragraphs, we will put more light on Sugar as a standardand also on one of its relevant concurent OpenVera [28].

4.4. Properties Specification Languages

Accellera's VFV was originally looking at four proposals - Intel's ForSpec, IBM's Sugar,Verisity's "e" language, and Motorola's CBV. But none of them met the committee's orig-inal requirements. Each company came back with proposed revisions, and the choice wasnarrowed to Sugar and CBV. The final vote was a 10 to 4 in favor of Sugar. Synopsys andIntel, which remain on the VFV committee, voted in favor of CBV [26].

The Accellera organization has selected Sugar, IBM's formal specification language, as astandard that it would drive assertion-based verfication. The choice puts Sugar againstOpenVera 2.0 (an open-source language from Synopsys Inc. and Intel Corp.)

Both languages let designers write properties and check assertions in simulation or formalverification, and both seek to end the proliferation of proprietary assertion languages. Yetthe two proposals are dividing the EDA industry into two camps: a large group of vendors,including Cadence Design Systems Inc., supporting Accellera's decision, while a smallergroup has signed on to support OpenVera 2.0.

Assertions allow designers to check properties, such as sequences of events that shouldoccur in a given order. ForSpec provides syntax that lets designers describe complexsequences and clocking styles, and employ asynchronous resets.

Basically, assertions are created to describe design specifications. They can describeundesirable behaviors or specific behaviors that are required to complete a test plan. Theycan then be checked in either dynamic simulation or formal verification.

4.4.1. Sugar

Sugar [26] was developed at IBM's Haifa Research Laboratory, and has been used formore than eight years inside IBM. According to IBM, the Sugar language is described as"a declarative formal property specification language combining rigorous formal seman-tics with an easy to use style." Sugar did not require an advanced degree in formal verifi-cation, yet had solid mathematical underpinnings.

Sugar is a language for the formal specification of hardware. It can be used to describeproperties that are required to hold of the design under verification. It is also possible touse Sugar for the specification of the system [17]. A Sugar specification can be used asinput to a formal verification tool, such as a model checker or a theorem prover, which canautomatically determine whether a design obeys its Sugar specification. A Sugar specifi-cation can also be used to automatically generate simulation checkers, which can then beused to check the design "informally" using simulation.

The structure of Sugar consists of four layers [4]:

26

•The Boolean layer is comprised of boolean expressions. For instance, A is a booleanexpression, having the value 1 when signal A is high, and 0 when signal A is low.Sugar interprets a high signal as 1, and a low signal as 0, independent of whether thesignal is active-high or active-low.

•The temporal layer consists of temporal properties which describe the relationshipsbetween boolean expressions over time. For instance, always (req -> next ack) is atemporal property expressing the fact that whenever (always) signal req is asserted,then (->) at the next cycle (next), signal ack is asserted.

•The verification layer consists of directives which describe how the temporal proper-ties should be used by the verification tool. For instance, “assert always (req -> nextack)” is a verification directive that tells the tool to verify that the property always(req -> next ack) olds. Other verication directives include an instruction to assume,rather than verify, that a particular temporal property holds, or to specify coveragecriteria for a simulation tool. The verification layer also provides a means to groupSugar statements into verification units.

•The modeling layer provides a means to model behavior of design inputs, and todeclare and give behavior to auxiliary signals and variables. The modeling layer isalso used to give names to properties and other entities from the temporal layer.Sugar comes in three flavors, corresponding to the hardware description languagesVerilog and VHDL, and to the language EDL [17], the environment description lan-guage of IBM's RuleBase model checker. The flavor determines the syntax of theboolean and modeling layers. In all three flavors, the temporal layer and the verifica-tion layer are identical.

4.4.2. OpenVera-Forespec Proposal

OpenVera-Forespec proposal was advanced by Synopsys Inc. and Intel Corp as a candi-date for an industry-standard assertion language. The proposal was denoted as OpenVera2.0 [38], which includes Intel's ForSpec property language [4]. This quite strong proposalwas rejected because it was very formal and too complicated for engineers to use it!

OpenVera 2.0 is based on OpenVera 1.0 [40] and ForSpec. OpenVera 1.0 is an open-source verification language managed by Synopsys which already had an assertion capa-bility for simulation. With the addition of ForSpec, OpenVera 2.0 supports formal verifi-cation tools as well. The whole concept in this combination was to have one language thatsupports both simulation and formal verification. ForSpec is a formal-property languageused primarily by systems architects.

But the main additions to the previous version of Vera are new constructs and operatorsthat support formal verification tools. In addition to formal operators, ForSpec bringsdirectives such as "assume," "restrict," "model" and "assert" that are aimed at formal veri-fication tools. An "assume-guarantee" construct lets assertions be used as module-levelproperties become monitors at higher levels of hierarchy [6].

The OpenVera Assertion (OVA) [6] language was developed to describe accurately andconcisely temporal behaviors that span multiple cycles and modules of the device under

27

test. HDLs, such as Verilog and VHDL, were designed to model hardware behavior onsingle cycle transitions with procedural features. Such an execution model is not sufficientto efficiently specify multi-cycle temporal functions. With OVA, users can easily andintuitively express input/output behavior, bus protocols and other complex relationships ofthe design. Assertions captured with OVA are typically 3-5 times more concise thanHDLs, enabling significant improvement in time spent writing and debugging assertions.

In contrast to four levels structure of Sugar, the OpenVera 2.0 language is broken downinto five main sections or levels. The first level is called Context and is used to help anddefine the scope of the assertions, and the sampling time used. The next level, Directive, isused to specify what properties are to be monitored or checked. The third level consists ofBoolean Expressions. The fourth level contains Event Expressions that describe temporalsequences. The last level is Formula Expressions, which are useful to describe how tem-poral sequences must occur in relation to one another.

Sugar and Open Vera 2.0 have two common layers: the Boolean and Temporal layers.This forms the core of the assertion language. The difference lies in the other layers. OpenVera 2.0 focuess on the detailed structure of the properties allowing the user to interactdeeply with the assertions which inquires a certain degree of knowledge in formal verfica-tion. Sugar went for two additional layers serving for the “formatting” of the propertiesand simplifying the interaction with the user.

In summary, whatever language used, Open Vera 2.0 or Sugar, assertions provide an evo-lutionary mechanism to greatly improve the productivity and confidence in the verifica-tion of complex SoCs.

4.5. Hybrid Verification Techniques

Simulation is no more able to meet the verification challenges faced by IC design teams,further innovations are needed. Today's high-performance simulation farms must be com-plemented with advanced verification technologies [50]. Leading design teams are com-plementing simulation with innovative tool technologies such as advanced testbenchautomation, assertion driven verification, coverage analysis and formal techniques.

However, HDL simulation is still at the heart of verification and these advanced technolo-gies need to work and interact very efficiently with HDL simulation. Synergistic integra-tion of all these technologies in a unified platform to create higher automation is calledhybrid verification. Hybrid verification is supposed to be enough smart to enable higherproductivity, performance and quality, resulting in higher confidence in verification, aswell as reduction of overall time spent in verification. A structure of a possible proposal isgiven in Figure 11.

28

Figure 11. Hybrid Verification.

Higher abstraction Hardware Verification Languages (HVLs) have already been proven tospeed the development of the verification environment and go above and beyond HDLs orhomegrown tools to improve verification productivity [42]. HVLs help to create highquality tests faster.

Creating testbenches to verify designs requires dynamic and high-level data structures,such as C/C++ classes and other inter-process communication constructs such as "events","semaphores" and "mailboxes." The OpenVera HVL is an intuitive, easy-to-learn lan-guage that combines the familiarity and strengths of Verilog, C++ and Java, with addi-tional constructs targeted at functional verification, making it ideal for developingtestbenches, assertions and properties [53].

Assertions are higher abstraction mechanisms that concisely capture design specification.They drive dynamic simulation and formal analysis to pinpoint bugs faster. They are auseful way to represent design specifications that are readable and reusable by multipletools in the verification flow. HDL simulation tools use assertions to dynamically run"checkers" and "monitors" during simulation. Dynamic simulation of assertions allows fordetecting bugs, whether simulating with random or directed tests. Functional coveragetools analyze simulation activity and provide information on coverage of functional testplans by reporting on coverage of assertions. Semi-formal tools use assertions to automat-ically generate tests to increase verification coverage. Assertions are also used as proper-ties that formal analysis engines can use to exhaustively analyze and prove or disprove,greatly enhancing verification confidence.

Many design teams today integrate the higher-level data structures provided by C/C++ ina Verilog verification environment using the Verilog Programming Language Interface(PLI), but are confronted with the complexity of writing and maintaining PLI routines.VCS DirectC, for example, provides the ability to easily mix Verilog and C/C++ con-

29

structs without the need of a PLI. Users can use C/C++ to define high-level algorithms andthen call these C/C++ functions directly in Verilog code.

With concurrent modules of DirectC, existing C models can be brought and mixed withVerilog constructs of "timing", "concurrency" and "port interfaces". With direct dataexchange between C/C++ and Verilog, DirectC provides the best possible performance.DirectC has been successfully used in a wide range of designs such as microprocessor,image compression and networking applications.

Synopsys has donated the DirectC/C-API to Accellera for standardization in SystemVer-ilog. A standard C-API provides ease-of-use, higher performance and tighter integrationof C/C++ within the Verilog HDL. DirectC will extend SystemVerilog, and make it easyto use higher abstraction C/C++ models within Verilog. It allows much faster simulationof design models at a higher level of abstraction, while staying within the existing RTLverification and implementation methodology. Similar to the standardization of the ValueChange Dump (VCD) file format created by third-party debug and analysis companies astandard Coverage API will accelerate the development of third-party tools and applica-tions that will use coverage information to enhance verification quality and productivity.

5. Conclusions

SoC design and verfication is an open project initiated a debate between hardware andsoftware communities. The real issues for embedded chip design are increasingly embed-ded software issues. Three main trends are proposed to design of SoC. The software basedmethodologies see that basing everything from the HDL approach is starting from thewrong point. On the other side, the hardware designers are looking into upgrading Verilogto support system level design requirements. They think that the best is to go for what itworks. The third group is supporting redefining new language redesigned from scartch forsystem level design. Nevertheless, this last approach is facing very hard criticism becausemost of the designers see that the idea of a grand unified language is fundamentallyflawed. The best choice will be to have multiple languages targeting specific areas. Theselanguages will be easier to learn than a grand language and they will also be easier fortools to parse.

Whatever the syntax looks like C, Verilog, VHDL or UML, most options share a commongoal: to transit functional design from the minutiae of Boolean logic, wiring and assemblycode up to the level of the designer's issues. Thus, functionality becomes modeled as anarchitectural interaction of behaviors, protocols and channels. This is great, except thatmost languages handle only digital functionality and cannot comprehend trade-offs ofpower, timing, packaging or cost.

There are also shortcomings with today's methodology in the face of the growing use ofSoCs. Individual designs that were once an entire system are now blocks in an SoC. Theassociated verification strategy with many of these blocks was not designed to scale up toa higher integration level. If the methodology does not permit easy integration of block-level verification code into a system-level SoC environment, then the project verificationwill become a major bottleneck to the entire system.

30

The successful SoC verification methodology must be able to integrate multiple in-houseor third-party IP cores, effectively migrate testing from the block to the system-level tomaximally leverage testing, integrate software such as drivers and diagnostics, debug, andprovide for the adoption of HDL acceleration and formal verification.

It is important to understand that SoC verification does not imply a homogeneous environ-ment. There are lots of tools and methods out there. IP comes from many sources, internaland external. A solid verification methodology must be able to incorporate verificationcode from a number of sources, tools, languages, and methods. A successful methodologyis a collection of tools integrated in an open and documented platform. The most effectiveway to improve the quality of results, shorten the development time, and decrease costs iswith a careful, consistent verification methodology used throughout the project!

The ideal scenario is to achieve comprehensive validation without redundant effort. Cov-erage metrics helps approximate this ideal by acting as heuristic measures that quantifyverification completeness, and identifying inadequately exercised design aspects andguiding input stimulus generation. A fact is, simulation is no more single player in the ver-ification of hardware designs. The hybrid approach, mainly based on property checkersand smart test generation, is being set a default for SoC verification.

References

[1] P. Alexander and D. Barton, “A Tutorial Introduction to Rosetta,” Hardware DescriptionLanguages Conference (HDLCon'01), San Jose, CA., March 2001.

[2] P. Alexander, R. Kamath and D. Barton, “System Specification in Rosetta”, presented at the IEEEEngineering of Computer Based Systems Symposium, Nashville, Edinburgh, UK, April 2000.

[3] R. Armoni, L. Fix, A. Flaisher, R. Gerth, B. Ginsburg, T. Kanza, A. Landver, S. Mador-Haim, E.Singerman, A. Tiemeyer, M.Y. Vardi, and Y. Zbar, “The ForSpec temporal logic: A new temporalproperty-specification language”, Tools and Algorithms for the Construction and Analysis ofSystems (TACAS’02), LNCS, Springer-Verlag, 2002.

[4] I. Beer, S. Ben-David, C. Eisner, D. Fisman, A. Gringauze, and Y. Rodeh. “The temporal logicsugar” . Computer-Aided Verification (CAV’00), volume 2102 of Lecture Notes in ComputerScience, pages 363-367, Springer-Verlag, 2001.

[5] P. Bellows and B. Hutchings, “JHDL - An HDL for Reconfigurable Systems”, IEEE Symposiumon FPGAs for Custom Computing Machines, IEEE Computer Society Pres",Los Alamitos, CA, pp.175-184, 1998.

[6] J. Bergeron and D. Simmons, “Exploiting the Power of Vera: Creating Useful Class Libraries”Technical Report, Qualis Design Corporation, 2000.

[7] P. Bergmann and M.A. Horowitz. “Improving coverage analysis and test generation for largedesigns”. IEEE Int. Conf. for CAD, pp. 580-584, 1999.

[8] G. Booch, J. Rumbaugh, and I. Jacobson, “The Unified Modeling Language User Guide”, Addison-Wesley, 1999.

[9] Co-design Automation, “SuperLog Tutorial: A Practical Approach to System Verification andHardware Design”. HDL Conference, Santa Clara, CA, USA, February 2001.

31

[10] CynApps, Inc. ”Cynlib: A C++ Library for Hardware Description Reference Manual”. SantaClara, CA, USA, 1999.

[11] G. De Micheli and D. C. Ku, “HERCULES - A System for High-Level Synthesis”, The 25th DesignAutomation Conference, Anaheim, CA, June 1988.

[12] G. De Micheli, “Hardware Synthesis from C/C++ models”, Proceedings of the conference onDesign, automation and test in Europe, Munich, Germany, pp. 80, 1999.

[13] R. Domer, “System-level Modeling and Design with the SpecC Language”, Ph.D. ThesisUniversity of Dortmund, 2000.

[14] R. Domer, D. D. Gajski, A. Gerstlauer, S. Zhao and J. Zhu, “SpecC: Specification Language andMethodology”, Kluwer Academic Publishers, 2000.

[15] R. Domer, J. Zhu and D. Gajski, “The SpecC Language Reference Manual”, Technical Report,Department of Information and Computer Science, University of California, Irvine, 1998.

[16] D B. P. Douglass, “Real-Time UML”, Addison-Wesley, 2000.[17] C. Eisner amd D. Fisman, “Sugar 2.0 tutorial explains language basics”, EE Design, May 2002.[18] A. Evens, A. Siburt, G. Vrchoknik, T. Brown, M. Dufresne, G. Hall, T. Ho and Y. Liu, “Functional

Verification of Large ASICS”, ACM/IEEE Design Automation Conference, 1998.[19] F. Fallah, P. Ashar, and S. Devadas, “Simulation vector generation from hdl descriptions for

observability enhanced-statement coverage”, Design Automation Conference, pp. 666-671, 1999.[20] P. L. Flake and Simon J. Davidmann, “SuperLog, a unified design language for system-on-chip”,

Asia and South Pacific Design Automation Conference (ASP-DAC), pp. 583 -586, 2000.[21] J. Floch, “Using UML for architectural design of SDL systems”, SINTEF Telecom and

Informatics, 2000.[22] Forte Design Systems, “Cynlib Language Reference Manual Release 1.4.0”.[23] P. Frey, R. Radhakrishnan, H. Carter, P. Alexander and P. Wilsey, “A Formal Specification and

Verification Framework for Time Warp Based Parallel Simulation”, IEEE Transactions onSoftware Engineering, January 2002.

[24] A. Gerstlauer, R. Domer J. Peng and D. D. Gajski, “System Design: A Practical Guide withSpecC”, Kluwer Academic Publishers, 2001.

[25] A. Ghosh, J. Kunkel and S. Liao, “Hardware Synthesis from C/C++”, Design, Automation andTest in Europe, pp.382-383, March 99.

[26] R. Goering, “Accellera picks IBM’s formal property language as standard”, EE Times, April 2002.[27] R. Goering, “Next-generation Verilog rises to higher abstraction levels”, EE Times, March 2002.[28] F. I. Haque, K A. Kahn, J. Michelson, “The Art of Verification with Vera”, Verification Central,

2001.[29] B. Hutchings and B. Nelson, “Using General-Purpose Programming Languages for FPGA

Design”, Design Automation Conference, pp. 561-566, June 2000.[30] IEEE Std. 1364-2001, IEEE Standard for Verilog Hardware Description Language 2001. ISBN 0-

7381-2827-9. IEEE Product No. SH94921-TBR.[31] A.A. Jerraya, M. Romdhani, Ph. Le Marrec, F. Hessel, P. Coste, C. Valderrama, G. F. Marchioro,

J.M. Daveau,and N.-E. Zergainoh, “Multi-language Specification for System Design andCodesign”, System Level Synthesis, Kluwer Academic Publishers, 1999.

[32] M. Kantrowitz and L. Noack, “I'm Dome Simulating: Now What? Verification Coverage Analysisand Correctness Checking of the DECchip21164 Alpha Microprocessor”. ACM/IEEE DesignAutomation Conference, 1996.

[33] D. C. Ku, G. De Micheli, “High-level Synthesis and Optimization Strategies in Hercules/Hebe”,EuroASIC Conference, Paris, France, May 1990.

[34] D.C. Ku and G. DeMicheli. “Hardware C - a language for hardware design.Technical Report”,Computer Systems Lab, Stanford University, August 1988.

32

[35] M. Kudlugi, S. Hassoun, C. Selvidge and D. Pryor, “A Transaction-Based Unified Simulation/Emulation Architecture for Functional Verification”, Design Automation Conference, pp. 623-628,2001.

[36] C. Maxfield, “A plethora of languages”, EE Design, August 2001.[37] M. Meixner, J. Becker, Th. Hollstein, M. Glesner, “Object Oriented Specification Approach for

Synthesis of Hardware-/Software Systems”, GI/ITG/GMM Workshop Methoden undBeschreibungsprachen zur Modellierung und Verifikation von Schaltungen und Systemen, 1999.

[38] M. Mohtashemi and Azita Mofidian, “Verification Intellectual Property (IP) ModelingArchitecture”, Guide to Structured Development Using OpenVera, 2002.

[39] D. Moundanos, J. A. Abraham, and Y. V. Hoskote. “Abstraction techniques for validationcoverage analysis and test generation”, IEEE Trans. Computers, vol. 47, no. 1, pp. 2-14, January1998.

[40] “OpenVera 1.0”, Language Reference Manual, March 2001.[41] P. R. Panda, “SystemC A modeling platform supporting multiple design abstractions”,

International Symposium on Systems Synthesis, pp. 75-80, 2001.[42] P. C. Pixley, “Integrating model checking into the semiconductor design flow”, Computer Design's

Electronic Systems journal, pp. 67-74, March 1999.[43] R. Otten, P. Stravers, “Challenges in Physical Chip Design”, International Conference on

Computer Aided Design (ICCAD), pp. 84-91, 2000.[44] R. Roth and D. Ramanathan. “A High-Level Hardware Design Methodology Using C++”, 4th

High Level Design Validation and Test Workshop, San Diego, pp 73-80, 1999.[45] S. E. Schultz, “The New System-Level Design Language”, Integrated System Design, July 1998.[46] SuperLog website: http://www.SuperLog.org.[47] S. Sutherland, “The Verilog PLI Handbook”, Kluwer Academic Publishers, 1999.[48] S. Swan, “An Introduction to System Level Modeling in SystemC 2.0. Open SystemC

Initiative (OSCI)”, Cadence Design Systems, Inc. May 2001.[49] SystemC website: http://www.SystemC.org.[50] D. Van Campenhout, H. Al-Asaad, J. P. Hayes, T. Mudge, and R. B. Brown. “High-level design

verification of microprocessors via error modeling”, ACM Trans. Design Automation ofElectronic Systems, 3(4):581-599, October 1998.

[51] S. Vernalde, P. Schaumont, I. Bolsens, “ An Object Oriented Programming Approach for HardwareDesign”, IEEE Computer Society Workshop on VLSI'99, Orlando, April 1999.

[52] E. E. Villarreal and Don S. Batory, “Rosetta: A Generator of Data Language Compilers”,Symposium on Software Reusability, Boston, Massachusetts, pp. 146-156, 1997.

[53] J. Yuan, K. Schultz, C. Pixley, H. Miller, and A. Aziz, “Automatic Vector Generation UsingConstraints and Biasing”, Journal of Electronic Testing: Theory and Applications, pp. 107-120,2000.