INTRODUCTION

1.1 General

Verification is the single biggest challenge in the design of system-on-chip (SoC) devices and reusable IP blocks. Traditional verification methods struggle to keep pace with the ever-increasing size and complexity of designs. The only way to address this problem is to adopt a reuse-oriented, coverage-driven verification methodology built on the rich semantic support of a standard language.

Despite the introduction of successive new verification technologies, the challenges associated with verifying complex SoCs and IP persist. The gap between design capability and verification confidence continues to widen. Repeated studies have shown that half to two-thirds of all SoCs fail at first silicon, with functional bugs a major reason. The ability to buck this trend can be a competitive advantage, saving millions of dollars in engineering charges and sales that would be lost due to late market entry.

1.2 Verification

Verification is done in two ways : standalone and chip level verification. Standalone verification is done for checking the basic functionality of the module (for example register read/write tests). Almost all the modules, interact with one or more cores. There are several corner cases which are not thought of by the designer. In order to attain maximum functional coverage, random verification is used. Functional coverage is the term which is used to determine if all the states in the design are exercised in proper sequence.

Chip level verification is done to verify the interconnectivity and interaction of the module at SoC level. Proper working and functioning of the module as a part of the whole chip, is tested. Full functional verification requires a Micro Operating System (MOS), which is capable of feeding inputs (stimulus) to the design and reading the outputs and verifying it against the specifications at RTL level and later on at post-layout level both for the timing and functionality.

Traditional verification relies on directed tests, in which the testbench contains code to explicitly create scenarios, provide stimulus to the design, and check (manually or with self-checks) results at the end of simulation.

SystemVerilog provides a vast array of language capabilities for describing complex verification environments, including constrained-random stimulus generation, object-oriented programming, multi-threaded capabilities, inter-process communication and synchronization, and functional coverage. These features allow users to develop testbenches that automate the generation of various scenarios for verification.

SystemVerilog Assertions (SVA) is a part of SystemVerilog and is being used in the verification of designs. To deploy SVA, guidelines need to be established which define where assertions should be added. The guidelines should also specify who writes the assertions, how they are controlled and how to ensure there are a sufficient number of assertions for each design.

Coverage is used as a guide for directing verification resources by identifying tested and untested portions of the design. Coverage is a metric for evaluating the progress of a verification project in order to reduce the number of simulation cycles spent in verifying a design.

During my internship in Freescale Semiconductors India Pvt. Ltd , I was assigned ‘Development of a Unit Level TestBench for System Reset Controller using SystemVerilog’ . It is a very critical step in the design flow since it takes care of all the possible reset conditions and if any reset condition is left unconsidered then it would propagate down the entire design flow and the full chip will not be able to function properly and get hung on occurrence of such conditions. Standalone verification was done. Directed testcases were used to check the code and functionality coverage of the module. The use of directed testcases made the verification process lengthy which in turn used a lot of resources and verification time. In addition all the reset scenarios were not checked which led to a low coverage . These drawbacks were overcome in this project by shifting from Verilog to System Verilog. With the use of System Verilog Assertions, all possible reset sequences were verified which enhanced the code as well as functional coverage of the System Reset Controller module. These assertions were finally integrated in the testbench and made an integral part of it.

DIRECTED AND RANDOMIZED TESTCASES

Testcases are the stimuli provided in the testbench environment for the verification purpose. The way the testcases are written play a major role in the verification of the module. These testcases decide whether all the functionalities of the module are checked, whether all the corner cases are verified and the coverage achieved.

The testcases are broadly divided in two types : directed and constraint-based randomized. But there are situations when both directed and randomized testcases are used.

2.1 Directed testcases

Directed tests are tests in which the testbench contains code to explicitly create scenarios, provide stimulus to the design, and check (manually or with self-checks) results at the end of simulation. Directed testbenches may also use a limited amount of randomization, often by creating random data values rather than simply filling in each data element with a predetermined value. The directed test approach works fairly well for small designs, but a typical SoC design requires thousands of test cases. Even assuming an optimistic development cycle of three days to create and debug each test, a team of ten verification engineers (also an optimistic assumption) would take over a year to complete all the tests. The only way to improve verification productivity is reducing the time it takes to create working tests.

2.2 Constraints-based randomized testcases

Constraints-based randomized testcases are the ones which are built by randomizing into the types of scenarios that are created, not just in the data values that get generated, additional tests are much more likely to hit corner cases and thereby find more design bugs. This way the number of testcases are also reduced leading to reduction in verification time.

figure 2.1 constraint based randomized and directed approach

In figure 2.1 , with the directed approach, the amount of time required to generate new tests is relatively constant, so the verified functionality improves roughly linearly over time. With a constrained-random verification environment, there is an up-front cost that must be invested before the first test can be run. This investment entails building into the verification environment the ability to parameterize and constrain the relevant portions of the test such that future tests can be easily derived.

SYSTEM VERILOG

SystemVerilog is a combined Hardware Description Language and Hardware Verification Language based on extensions to Verilog thereby providing a single platform for both design and verification. SystemVerilog is Verilog incorporated with the features of C++ which makes it very powerful hardware language. Some key features are

· C type data types like int, typedef, struct, union, enum.

· Dynamic data types : struct, classes, dynamic queues, dynamic arrays.

· Enhanced flow control like, foreach, return, break, continue.

· Supports interfaces parameterized as well as non-parameterized

· Supports final, program and multiple clocking blocks

· Classes for object oriented programming.

· Supports randomization with constraints

· Assertions & Coverage.

· Supports Direct programming interface

· Supports semaphores and mailboxes

3.1 Data types

SystemVerilog supports all the data types of Verilog as well as of C. It contains a new general purpose data type ‘logic’ which can be used for a majority of variables . Wire types are only required for multiply-driven buses. Two state ( 0 ,1 ) can be freely mixed with four state logic ( 0,1 , ,x , z ). It provides more control over time values.

3.2 Dynamic data types

It provides easier definition and control of large data sets using packed , unpacked arrays and structures. Dynamic arrays are useful for contiguous data which varies in size during simulation. Associative arrays are ideal for unbounded or sparse data sets. Queues add manipulation methods to data sets.

3.3 Flow controls

It supports C like conditional control flows like while, if_else , case etc as well as unconditional control flows like break, continue ,etc thereby simplifying the design as well as verification codes.

3.4 Interfaces

Interfaces simplify the design block communication by allowing a number of signals represented as a single block , reducing the amount of code and promotes reuse. The design becomes much more readable. Tasks and functions defined inside an interface encapsulates the communications protocols between the modules.

3.5 Verification blocks

The simulation statistics can be summarized with a ‘final’ block. Verification blocks clearly separate verification from design codes and program blocks. It avoids race problems with driving stimulus. It clearly separates functionality and timing with clocking blocks. Timing behaviour can easily be changed by modifying clocking blocks.

3.6 Object oriented programming

The C++ ‘classes’ form an integral part of SystemVerilog . Class based features like constructors ( for initialization ) , inheritance ( single as well as multilevel for deriving features of base class ), encapsulation ( wrapping data members and functions together), data abstraction ( information hiding ) and polymorphism ( function overloading ) make SystemVerilog stronger than verilog.

3.7 Randomization

This feature can generate large amount of stimulus data from compact code, can run longer simulations for more stimulus ,better quality and can hit more number of corner cases. Control randomization through constraints creates legal stimulus ,explores area of interest and conditionally switches between modes of operation.

3.8 Assertions

SystemVerilog has features to specify assertions of a system. An assertion specifies a behavior of the system. Assertion-based verification is of most use to design and verification engineers who are responsible for the RTL design of digital blocks.

3.9 Coverage

It is a measure used in software testing. It describes the degree to which the source code and functionality of a program has been tested. The use of coverage is extended to the field of digital hardware, the contemporary design methodology of which relies on Hardware description languages.

3.10 Direct programming interface

Its is a new light weight C programming interface. This helps in calling C based routines directly from SystemVerilog without the overhead associated. It will also export of SystemVerilog tasks and functions.

3.11 Semaphores , mailboxes ,event triggers

Semaphores are multi purpose synchronization mechanism with built-in blocking synchronisation. Mailboxes are offering powerful ,multitype first in first out operations with built-in blocking synchronization. They are communication mechanisms that allow messages to be exchanged between processes.

This project of designing unit level test bench is mainly centered around class based features, randomization with constraints , assertions and coverages.

ASSERTIONS

Assertions are, quite simply, expressions of design intent. As architects write chip and system specifications, they make many assumptions about the functionality. As designers write RTL, they develop implementation-level beliefs on how the design should operate and expectations about how neighbouring blocks will communicate. Verification engineers document intended and unintended design behavior as part of developing a test plan.

All of the different elements of design intent can be captured with assertions, starting very early in the project schedule. The traditional test plan is replaced by a more comprehensive verification plan identifying which assertions should be written.

Assertion-based verification is the technique of creating assertions early in the development process and leveraging them throughout the verification effort. Ideally, the designers place assertions in the RTL code for every block. Some of these assertions will involve only the inputs and outputs of the block, while others will involve internal design structures.

Assertions that reference only the block I/O are often called "black-box" since they do not directly relate to the internal implementation. Assertions that specify behavior from the inputs to the outputs are termed "end-to-end" since they relate the expected results on the outputs to the values on the inputs. Assertions that reference internal data structures are "white-box" since they are tied to the specific RTL implementation.

Output assertions check that the results from the block agree with what is expected by other blocks receiving the output signals. Conversely, input assertions represent the range of inputs for which the block is designed, serving to screen out illegal inputs from other blocks

A bug buried deep inside a block can take literally thousands of cycles to propagate its effects to the chip output and be detected in the testbench. If an assertion catches this bug at its source, diagnosis time is reduced from hours or even days down to minutes. Further, assertions sometimes detect bugs that would have been missed by the testbench, perhaps because the simulation test stopped before bug effects reached the outputs.

4.1 Building blocks of assertions

Like designs coded using hardware description languages (HDLs), assertions are best described hierarchically. This promotes ease of coding, ease of understanding, and reuse, among other things. The hierarchy is illustrated in Figure 4.1 using SVA terminology. At the lowest level, boolean expressions of design objects (signals) are created and become the building-block "components" of sequences. Sequences, in turn, become the building blocks of properties. At the top of the hierarchy, directives indicate what to do with the properties.

Assertions can also be written at a later stage and separate from the design description itself. The ability to describe assertions outside of the design description also decreases the barriers to entry for design and verification teams by allowing the newer assertion methodology to be applied to existing or older designs without disrupting existing design code.

4.2 Advantages of using assertions

While a special-purpose assertion language provides the obvious benefits of conciseness, from a methodology point of view assertions also provide many additional and equally important benefits, including:

· Assertions provide a powerful mechanism to add observability and testing into a verification environment. The assertion can be "hooked up" to the points of the design targeted for "probing."

· Assertions are coded at a higher level of abstraction than the design.; specification rather than Implementation. The specification can then be checked automatically by dynamic or static (formal) verification tools.

· Assertion languages provide flexibility; the code can be in-lined with the implementation or external. This enables assertion methodologies to be easily adopted, so as to work "out-of-the-box" with existing flows.

· Assertions provide an ideal mechanism for IP delivery. They can be delivered as part of the IP so users can ensure correctness when integrating the IP into their system. In addition, assertions can be used to provide a quality metric for the IP in terms of coverage.

· Simple hookup and interaction between assertions and the testbench without special interfaces.

· Customization and control of messaging and error severity levels.

· Ability to interact with Verilog and C functions.

· Avoidance of mismatching results between simulation and formal evaluations with clearly defined scheduling semantics.

· Ability to improve verification performance by eliminating assertion co-simulation overhead and reusing simulation optimization algorithms.

· Has in-built checker library

4.3 Writing assertions

SystemVerilog has its own assertion specification language. Assertions are useful for verifying properties of a design that manifest themselves over time. Assertions are applied in following ways :

4.3.1 Assertions running on single clock

property reset_source_memory_repair ;

@ (posedge clk)

$rose ( reset_source ) |=> read_tab ##1 memory_repair ## 2 ! memory_repair ;

endproperty

a_reset_source_memory_repair : assert property ( reset_source_memory_repair );

In the above example when the reset_source makes a transition from 0 to 1 on the rising edge of the clock , read_tab goes high after one clock cycle. After a delay of one clock cycle memory_repair signals goes high and remain high for another two cycles and then goes low. ‘|=>’ is the implication operator used to after assertion is triggered . ‘##’ is used to give clock cycle delays.

4.3.2 Assertions running on multi clocks

property jtag_reset_source ;

@ (posedge clk1)

$rose ( jtag_reset )

##1

@ ( posedge clk2)

(## 1 reset_start ) |=>

@ ( negedge clk3 )

( sequence1 ##2 sequence 2);

endproperty

a_jtag_reset_source : assert property ( jtag_reset_source );

In the above example when the jtag_reset makes a transition from 0 to 1 on the rising edge of the clock1 , after a delay of one clock cycle and a delay of one posedge of clock2, reset_start should be high, then only assertion is triggered. Then at the negedge of clock3, sequence should be high and after two negedge delay of clock3 sequence 2 should be high.

4.3.3 Assertions with first match of the sequence

property reset_first_match;

@ ( negedge clock)

$rose ( read_tab) |=> first_match ( signal1 & ! signal2);

endproperty

a_reset_first_match : assert property ( reset_first_match )

$display ( “ assertion passed “);

else

$display (“ assertion failed”);

In the above example , whenever read_tab rises at the falling edge of clock , assertion is passed for the first match when signal1 is high and signal2 is low. Then a message is also displayed. When this assertion fail ,the message is displayed that assertion has failed.

Assertions can used with operators such as not , and ,or ,intersect ,etc. These operators make assertions more powerful without costing its simplicity in coding and implementation.

4.4 Local variables in sequence

Sequences specify temporal relationships between signals. However, to describe some complex behaviors, it is also necessary to be able to save values explicitly at some point in a sequence so it can be referenced later in the sequence. Consider a sequence such as "when data goes into a pipeline, it will come out between 3 and 5 clocks later, and will be incremented by one." The valid signal marks when data goes into the pipeline, and 3 to 5 clocks later, the output of the pipeline will be equal to the input data incremented by one.

Capturing the sequence-specific data directly in the sequence eliminates the need for the user to write a separate state machine or other auxiliary code to capture the data, and eliminates the need of having to correlate this auxiliary code to each execution attempt of the sequence. It also avoids the problem of having to tell other tools that the auxiliary code is not really part of the design, thus simplifying the tool usage flow as well.

In this project , assertions used are mainly on single clock and multiclock cycles besides using operators like and ,or ,not, intersect , first_match ,etc.

COVERAGE

Functional verification comprises a large portion of the resources required to design and validate a complex system. Often, the validation must be comprehensive without redundant effort. To minimize wasted effort, coverage is used as a guide for directing verification resources by identifying tested and untested portions of the design.

Coverage is defined as the percentage of verification objectives that have been met. It is used as a metric for evaluating the progress of a verification project in order to reduce the number of simulation cycles spent in verifying a design. Coverage metrics also are an indicator of when verification is thorough enough to tape out. Coverage provides more than a simple yes/no answer; incremental improvement in coverage metrics helps to assess verification progress and thoroughness, leading to the point at which the development team has the confidence to tape out the design. In fact, coverage is so critical that most advanced, automated approaches implement coverage-driven verification, in which coverage metrics guide each step of the process.

Broadly speaking, there are two types of coverage metrics: those that can be automatically extracted from the design code, such as code coverage, and those that are user-specified in order to tie the verification environment to the design intent or functionality. The latter form is referred to as functional coverage.

5.1 Code Coverage

Code coverage, in its many forms (line coverage, toggle coverage, expression coverage), is typically an automated process that tells how many lines of code have been executed (line coverage), which paths through the code and expressions have been executed (path coverage), which single-bit variables have had the values 0 or 1 (toggle coverage), and which states and transitions in a state machine have been visited (FSM coverage). There is no need to write any extra HDL code. The tool instruments your design automatically by analyzing the source code and adding hidden code to gather statistics. Then run all the tests, and the code coverage tool creates a database. Many simulators include a code coverage tool.

A post-processing tool converts the database into a readable form. The end result is a measure of how much your tests exercise the design code. Code coverage is primarily concerned with analyzing the design code, not the testbench. Untested design code could conceal a hardware bug, or may be just redundant code. Code coverage measures how thoroughly your tests exercised the implementation of the design specification, and not the verification plan. Therefore cent percent code coverage doesn’t guarantee that the design is bug free.

5.2 Functional coverage

Functional coverage is a user-defined metric that measures how much of the design specification, as enumerated by features in the test plan, has been exercised. It can be used to measure whether interesting scenarios, corner cases, specification invariants, or other applicable design conditions captured as features of the test plan have been observed,validated, and tested.

The key aspects of functional coverage are as follows:

· It is user-specified and is not automatically inferred from the design.

· It is based on the design specification (i.e., its intent) and is thus independent of the actual design code or its structure.

Because it is fully specified by the user, functional coverage requires more up-front effort (someone has to write the coverage model). Functional coverage also requires a more structured approach to verification. Although functional coverage can shorten the overall verification effort and yield higher quality designs, its shortcomings can impede its adoption. The SystemVerilog functional coverage extensions address these shortcomings by providing language constructs for easy specification of functional coverage models. This specification can be efficiently executed by the SystemVerilog simulation engine, thus enabling coverage data manipulation and analysis tools that speed up the development of high-quality tests. The improved set of tests can exercise more corner cases and required scenarios, without redundant work.

The SystemVerilog functional coverage constructs enable the following:

· Coverage of variables and expressions, as well as cross coverage between them

· Automatic as well as user-defined coverage bins

· Associate bins with sets of values, transitions, or cross products

· Filtering conditions at multiple levels

· Events and sequences to automatically trigger coverage sampling

· Procedural activation and query of coverage

· Optional directives to control and regulate coverage

Coverage points define conditions that must be exercised for complete verification; assertions specify behavior that must hold for the design to operate correctly. A common language works well due to the similar nature of these two types of specification.

Coverage points can express very specific corner-case conditions with long setup sequences. Composite functional coverage across the entire test suite is most valuable, since it provides a measure of verification progress and is an important factor in deciding when to tape out the design. As with assertions, functional coverage points should be included in the verification plan from the earliest phases of the SOC project. Architects, designers, and verification engineers should all contribute to this process. As the coverage points are written in the RTL, links can be placed in the plan. This allows coverage results to be reported back against the original plan, clearly showing what verification work remains to be done.

SystemVerilog also provide sophisticated constructs for higher-level functional coverage typically included in the testbench code rather than in the RTL. Verification confidence can often be improved further by using cross-coverage techniques to measure combinations of coverage metrics. Important functional coverage and cross-coverage points should be identified early in the project, preferably included in the written verification plan. The process of filling the holes identified by the full range of coverage metrics is the heart of the coverage-driven verification process. By definition, when 100% coverage across all metrics is achieved then the verification confidence should be high enough to tape out. SystemVerilog provides cover properties for lower-level coverage points, cover groups for tracking higher-level values, and support for cross-coverage.

The first part of the process entails setting up the testbench environment. Generally no chip-level or system-level testing is possible until this environment is established. However, if designers are coding RTL in parallel they may be running block-level directed tests or formal analysis during this period.

Once the verification environment is ready, the development team can start to run constrained-random tests and hit the first set of coverage points. At this point the tests are typically quite broad, generating a wide range of behavior for the design. As the number of uncovered points dwindles, more analysis is usually needed to fill the holes. Verification engineers tend to focus on particular corner-case coverage points and carefully vary constraints and parameters to generate tests that hit these points.

Directed tests can play a role in a coverage-driven verification environment. Although constrained-random testing is the primary method, it may be easier to write a directed test to fill a particular coverage hole than to automatically generate a test using constrained-random techniques. The goal is to reach 100% of the defined coverage metrics by any appropriate methods.

5.3 Writing Coverage

· Define a coverage model with ‘covergroup’

· A clocking event specifies the coverage sample point

· Variables to be tracked are defined with ‘coverpoint’

· Instantiate the coverage model in the design using ‘new’

· Multiple instances of the group can be created in different contexts

· Coverpoints are tracked during simulation and results displayed

For example,

module test_example;

logic clk;

logic [2:0] opcode ;

logic [ 7:0] address;

covergroup cg1 @ ( posedge clk );

c1 : coverpoint opcode;

c2 : coverpoint address;

endgroup : cg1

cg1 cover_inst = new ( );

endmodule

5.3.1 Defining Bins

Values of coverpoint variables are tracked in bins . By default SystemVerilog will automatically create bins. However bins can also be explicitly defined with a name and a set of values. Bins can be scalar or vectors ( array of bins ).

For single coverpoint variable . one can create

· A separate bin for each value in a given range list

· A single bin for all values in the range list

· A fixed number of bins for a set of values in the range list

· A default bin for remaining values

For example,

logic [4:0] var ;

ce : coverpoint var

{

bins a[] = { [ 0:1 ], 6 }; // 3 bins a[0] ,a[1], a[6]

bins b = { 2, 3 } ; // 1 bin for 2, 3

bins fixed[2] = { [9: 15 ] ; // 2 bins – fixed[1] ={ 9,10,11}

- fixed[2] ={ 12,13,14,15}

bins c = default; // 1 bin for 4, 5,7,8

}

5.4 Cross Coverage

· Tracks the values of two or more objects

· Crosses can be applied to coverpoints within the covergroup , variables which are visible in the scope or a combination of both.

For example ,

logic [ 1:0 ] vector_a ,vector_b;

covergroup cg @ ( posedge clk );

c1 : coverpoint vector_a;

c2 : coverpoint vector_b;

crossab : cross c1, c2;

endgroup : cg

In the above example crossab tracks of values of vector_a and vector_b together. In this example automatically 16 bins are created due to cross coverage .

In this project, covergroups , explicit bins and covergroups have been used to calculate the coverage for all relevant registers and resets

SYSTEM RESET CONTROLLER

The full chip consists of two core processors : ARM and DSP cores. ARM processor is a 32-bit RISC processor architecture developed by ARM Limited that is widely used in a number of embedded designs. Because of their power saving features, ARM CPUs are dominant in the mobile electronics market, where low power consumption is a critical design. Due to powerful indexed addressing and high pipelining depth because of fixed instruction width , it operates at a very high frequency thereby reducing the processing time. It handles all of the housekeeping chores for the keypad (for mobile systems ) and display, deals with command and control signaling with the base station and also coordinates the rest of the functions on the board.

DSP (digital signal processor) is a highly customized processor designed to perform signal-manipulation calculations at high speed. It is designed specifically for digital signal processing, generally in real-time computing.

System Reset Controller is a module on the full chip which receives and handles reset requests from all reset sources. It resets the appropriate domains based upon the reset sources and the nature of reset. It informs the ARM and DSP cores about the internal or external booting. It controls the clock monitors for the different clocks of the chip.

6.1 Different reset sources

6.1.1 Hard Reset

It is the process of either pressing the reset button on device or pressing and holding the reset button for a few seconds. This is called a hard reset because the user is physically pressing the button instead of resetting the device through software.

6.1.2 Power- on- Reset

It is critical to the device because logic in all clock domains must be placed in a benign state following the deassertion of the reset sequence. The power-on reset also controls entry and exit from a power-down state for various power domains within the processor. If memory repair operation is not bypassed , then it takes place. Memory operation is required only when there is any fault in the row or column of the associated memory . Every memory bank has some redundancies so that faulty memory column or row can be linked to the new redundant memory line.

6.1.3 Clocking resets

All reset sequences occur on the posedge or negedge of clock .There are clocks going to ARM core and DSP core processors as well as other modules on the chip. If any of the lower or higher frequency clocks is not present during any of the operation of the chip , the related module resets sequences start.

6.1.4 Watchdog Timer reset

A watchdog timer is a computer hardware timing device that triggers a system reset if the main program, due to some fault condition, such as a hang, neglects to regularly service the watchdog (writing a “service pulse” to it, also referred to as “petting the dog” or "kicking the watchdog"). The intention is to bring the system back from the hung state into normal operation.

Watchdog timers may be more complex, attempting to save debug information onto a persistent medium; i.e. information useful for debugging the problem that caused the fault. In this case a second, simpler, watchdog timer ensures that if the first watchdog timer does not report completion of its information saving task within a certain amount of time, the system will reset with or without the information saved. The most common use of watchdog timers is in embedded systems, where this specialized timer is often a built-in unit of a microcontroller.

Watchdog timers may also trigger control systems to move into a safety state, such as turning off motors, high-voltage electrical outputs, and other potentially dangerous subsystems until the fault is cleared.

6.1.5 JTAG resets

JTAG ( Joint Test Action Group ) interface enables on-chip debugging. It allows resetting of the Embedded-ICE (in-circuit emulator) bug hardware independent of resetting the microcontoller core and peripherals. This can be done by software or manually.

6.2 Types of Resets

6.2.1 Category I

In this type of reset , the full chip is reset .Memory repair operation , if required ,takes place during this caetory of reset. Power-on-reset belongs to this category.

6.2.2 Category II

In this type of reset , the related modules only go in reset states not the full chip. Most of the reset sources like JTAG reset , Watchdog reset ,etc fall in this category.

6.3 Design setup

Testbench is an effective verification environment which aids in the development of a single chip and is imperative for creating multiple systems-on-chip. Assertions and monitors integrated in the testbench help it to achieve its functionality. Testcases act as stimulus to the verification. If there are any errors found during verification then the error is fixed in the design. This process is repeated until there are no errors found in the design.

6.4 Design Implementation

The design of unit level testbench involves the following steps

· Identifying previous testcases

· Create classes having module’s registers as elements

· Write plan for randomizing reset sources

· Review of the randomization plan

· Create and implement new constraints-randomized testcase

· Write assertion based verification plan

· Review of assertion verification plan

· Run testcases and assertions

· Evaluate coverage

· Integrate the assertions in the testbench

6.4.1 Identification of testcases

Testcases will be identified by reviewing what was done on previous projects, reviewing the specifications, and requesting input from knowledgeable individuals. All three input sources are crucial to identifying all required testcases. Previous projects will provide information regarding what should have been done that wasn’t immediately obvious at the start of the project. Specifications, particularly high-quality ones, detail all of the functional features and operation details necessary to identify required tests. Finally, input from design and other disciplines are absolutely mandatory to identify areas that need to be tested because of vague areas in the specification, prior experience, and familiarity with the weaker portions of the block.

6.4.2 Create classes with registers as elements

First the register descriptions in the mif format in the configuration file are converted into forest format using Assertion Based Verilog Modeling ( a Freescale tool for internal use only ) .Then a PERL script is used to convert this forest format registers mapping into SystemVerilog classes with registers of the module as elements. The member variables of these elements are randomized using SystemVerilog features.

6.4.3 Write plan for randomizing reset sources

The testcases made for the previous projects are directed ones. So they cover targeted corner cases thereby reducing the robustness of the system. Writing a plan reduces the implementation time of the randomization of reset sources.

6.4.4 Review of the randomization plan

Reviewing a plan is an important step as it eliminates the errors which may have cropped in due to manual error or insufficient data provided in the configuration specification file. Besides, the feedback from the review team helps in implementation in a better way leading to a simpler and robust test case.

6.4.5 Implement new constraints-randomized testcase

Using randomized reset sources reduce not only the number of testcases but also verification time apart from checking for all possible corner cases. Using SytemVerilog class based feature and randomization functions, the reset sources are randomized. Constraints based randomization eliminates the known invalid inputs thereby saving the resources.

6.4.6 Write assertion based verification plan

After writing the constraints-randomized testcase , it is necessary to verify the working of the testcase which can be done by checking the dump file of the signals in the simulator. But our main aim is to incorporate assertions in the testbench and for this , an assertion based verification plan is made based on the functionality of the module as given in the configuration specification file.

6.4.7 Review of assertions verification plan

As discussed earlier, reviewing a plan is an important step as it eliminates the errors which may have cropped in due to manual error or insufficient data provided in the configuration specification file. Further it helps in incorporating the assertions which might have been missed in the assertion plan due to insufficient data about the functionality provided in the specification file. This all inputs from the review team helps in implementation the assertions with sufficient ease and accuracy.

6.4.8 Run new randomized testcase and assertions

All implemented test case and assertions are made to run in the testbench environment. The verification engineer is completely familiar with the stimulus produced but testcases and the specifications at this point, so it should be completely clear what the failure means even if they can not identify the root cause. Assertions help in detecting the functional faults in the design. Resolution of the failure is then assigned to the design team to correct the design flaw.

6.4.9 Evaluate coverage

Functional and/or code coverage metrics are gathered on the stimulus running to identify holes. Coverage holes are then added as testcases, stimulus is developed for them, reviewed, run and coverage is then re-evaluated. This constraint-based randomization has increased the coverage to cent percent.

6.4.10 Integrate the assertions in the testbench

The assertions once verified and implemented are then incorporated in the testbench and are made an integral part of it. These assertions are automatically executed whenever any testcase is run in the testbench environment. This reduces the verification time of the module.

 

CONCLUSION

Verification consumes most of the total resources in a typical chip design cycle. Chip design flow requires verification at each level of abstraction beginning from architecture to silicon prototyping. The challenge for engineers here is to verify specification adherence for multiple abstractions. The verification process depends on various parameters such as the Hardware Description Language used, the methodology employed, and the complexity of system-on-chips in terms of size, functionality and application.

In this project “ Development of unit level testbench using SystemVerilog “ , SystemVerilog has been used which has made the verification process much simpler and more robust by the use of its randomization and class based features. The randomization has reduced the number of directed testcases to nearly one-tenth in addition to covering more number of corner cases. The incorporation of assertions in the testbench has further reduced the verification time and more functionalities of the module can be checked covering all the corner cases which wasnot possible earlier. This new testbench is reusable and can be used for the verification of future reset modules designed in the company. Besides saving resources, this will help in faster tape out of the fully functional chips.

APPENDIX

A. TOOLS USED

A.1 NC Verilog:

The Cadence NC-Verilog simulator is a Verilog digital logic simulator that combines the high-performance of native compiled code simulation with the accuracy, flexibility, and debugging capabilities of event-driven simulation. The NC-Verilog simulator is based on Cadence s Interleaved Native Compiled Code Architecture (INCA).

A.2 VCS:

VCS is a high-performance, high-capacity Verilog ® simulator that incorporates advanced, high-level abstraction verification technologies into a single open native platform. VCS enables you to analyze, compile, and simulate Verilog design descriptions. It also provides you with a set of simulation and debugging features to validate your design. These features provide capabilities for source-level debugging and simulation result viewing. VCS supports all levels of design descriptions, but is optimized for the behavioral and register transfer levels.

A.2.1 DVE

Discovery Visualization Environment (DVE) the new graphical debugging environment. You can use DVE to trace signals of interest while viewing annotated values in the source code or schematic diagrams. You can also compare waveforms, extract specific signal information, and generate testbenches based on waveform outputs.

A.3 UNIX

UNIX a reliable timesharing operating system. Bell Labs developed a system that provided a work environment described as "of unusual simplicity, power, and elegance". Unix is more flexible and can be installed on many different types of machines, including main-frame computers, supercomputers and micro-computers. It is more stable and does not go down as often as Windows does, therefore requires less administration and maintenance. It has greater built-in security and permissions features than Windows. Unix possesses much greater processing power than Windows.

A.4 CLEARCASE

Rational ClearCase is a software tool for revision control (configuration management ) of source code and other software development assets. It is developed by the Rational Software division of IBM. ClearCase forms the base of version control for many large and medium sized businesses and can handle projects with hundreds or thousands of developers, but the price is quite steep for smaller companies. Objects under version control in ClearCase are stored with their histories in repositories called VOBs (Versioned Object Base).

A.5 FRAMEMAKER

Adobe FrameMaker is a desktop publishing (DTP) and word processing application that is popular for large documents. It is produced by Adobe Systems. It has two ways of approaching documents: structured and unstructured.

B. SYSTEM ON CHIP

System on Chip or SOC, refers to the integration of all the necessary electronic circuits of diverse functions onto a single chip, to come up with a complete electronic system that performs the more complex but more useful final product function. Thus, instead of building an electronic product by assembling various chips and components on a circuit board, SOC technology will allow all of these parts to be fabricated together on a single chip, which can function as the final product itself.

For instance, an SOC for electronic control of an automobile's suspension system will have the following distinct parts: 1) an accelerometer for detecting the car's motion; 2) an ADC for converting the accelerometer's analog output into digital data; 3) a digital signal processor for analyzing the digital data; 4) and an output driver system for controlling the mechanical behavior of the suspension system. In an SOC, all of these functionally individual circuits will be contained on a single integrated circuit.

System-on-a-Chip (SOC) must not be confused with System-in-a-Package (SIP), which is a device that consists of multiple individually fabricated chips that make up a complete electronic system housed in a single package. Thus, SIP pertains to an advanced type of packaging technology, while SOC deals with microchip fabrication technology.

B.1 SOC Design Flow