Methodology and Code Reuse in the Verification of SOCs

Click Icon for a PDF version of this document.

Introduction
The ever-competitive market pushes semiconductor IC designs to be packaged on larger dies, incorporating more functionality. In order to achieve the 'time-to-market' targets, semiconductor companies incorporate important blocks and cores, developed and verified by other companies, into their chips. This reuse of outsourced intellectual properties (IP) into a larger IC design thus led to the creation of System-on-Chip (SOC) designs. The resulting SOC complexity, cost and increased probability of errors raised the importance of verification [2,6]. Every stage of the IC design flow requires a certain degree of verification, which, in turn, contributes to the overall chip cost and quality. Obviously the detection of RTL errors in SOCs minimizes the cost of fixing them at the later stages.

The verification of SOCs involves heavy simulations of large amounts of data, extending the RTL debug cycle [5]. Synopsys developed a set of workbenches to provide for the verification of ASIC design compliance to the ATM, SDH and SONET standards [3]. By providing standard library modules and ready-to-use testbenches, Synopsys offers an easy-to-use verification framework but does not address the problem of speeding up the SOC simulation cycles. C-based testbenches offer effective solutions to boost the simulation and emulation performance [5]. However, the lack of a flexible verification environment with code reuse across projects keeps the verification costs high.

Sun Microsystems developed an object-oriented approach to the verification of complex ASICs using C++ [7]. The described verification system is based on a framework developed with the goal of being extensible and reusable. However, the proposed testbench reusability is limited. Synopsys offers a specialized verification language called Vera [1]. Vera extends the level of abstraction of such languages like C++ and Java to model and verify hardware. A set of tools developed around Vera leverages the development of verification testbenches that may contain a mixture of Vera, HDL and C/C++ code. Nevertheless, the Vera-C interface is not straightforward and implies some limitations to the C code complexity. In addition, mastering Vera requires special training and practice, which affects time to market and therefore product cost.

This paper discusses a verification framework and methodology exploited in verification projects of SOCs. The verification system is based on a communication bridge between the verification C code and HDL languages like HDL and Verilog [4].

Our approach to verification provides for:

• reusability of verification code and methodology;
• scalability for any size SOCs;
• hardware/software co-simulation support;
• lower verification costs.-both initial costs, incremental cost per user and life cycle support costs

Verification system overview
Figure 1 shows the general structure of the verification system. The SOC under test (SUT) is described using an HDL language. User tests are written in C, individually compiled and linked to a set of libraries. The workbench libraries contain application routines created to perform specific data manipulations. For instance, the ATM workbench libraries include:

• ATM adaptation layer library containing AAL0, AAL2, AAL5 segmentation and reassembly routines;
• ATM layer library providing for the programming of cell streams with predefined QoS parameters, insertion of OAM and idle cells, etc.
• Physical layer library with routines to perform CRC calculation, scrambling/descrambling, error insertion, cell delineation and IMA traffic processing.

The service libraries usually contain routines to support all stages of the verification system development. This includes routines for error reporting, printing different types of debug messages, generating pseudo-random numbers, sorting and shuffling data arrays, handling input and output databases, statistics reporting and simulation control.

The project efficiency layer routines are project dependent and designed to increase the abstraction level of test C code. The efficiency routines facilitate:

• setting up the project control structures, SUT registers, ports, connections and input/output databases;
• programming the verification system transactors and SUT interfaces.

The transport layer provides for concurrent transactor-based communications between C and HDL domains. The transport software (TestBenchPlus in this system) supports the:

• ability to create/add any type of interface with large data transfers;
• repeatability of hardware simulations;
• scalability and mobility of the verification system;
• migration from unit to system verification, providing high levels of controllability and observability.

The user interface is a set of Make and Perl scripts to support:

• compiling C and HDL code;
• building tests;
• passing test parameters;
• interactive and batch simulations;
• regression testing.

The user interface can also include any user-friendly GUI interface for visual support. In the next section the implementation of the testbench design for the verification of telecommunication SOCs is described.

Testbench design
The testbench design is based on the classical approach to the verification of finite state machines: set the SUT to a known state, apply input stimuli and observe the output data. The SUT is determined to be fault-free if the responses collected from the SUT outputs match the expected data. The verification environment consists of three main domains: C, HDL and the bridge layer. Every domain is dedicated to perform a set of specific data manipulation functions.

The input data traffic is generated in the C domain as packets of bytes. The input packets stored in the input database are accessed by transactors. The transactors are able to perform data transformations on or, if needed, insert errors into the input packets.

Once the packets are generated, they are transferred to the HDL domain and then applied to the SUT inputs. The collected data is passed back to the C domain where the data recovery and comparison are performed. The HDL domain part designed for verification purposes is kept as minimal as possible.

The bridge part of the testbench represents a set of C and HDL functions designed to support concurrent data transfers between C and HDL.

A: Testbench Implementation
Figure 2 shows the testbench implementation. The SUT model is described in HDL. There are four types of transactors, which are distinguished by their roles in the system: simulation control (SimControl), microprocessor, generator and collector transactors.

The generator transactors provide for the:

• generation of input data in the SUT interface format;
• emulation of the correct SUT interface signaling;
• introduction of errors.

The collector type transactors are designed to:

• collect the output data in the SUT output format;
• provide for the correct output interface signaling;
• detect and report interface signaling violations.

The main purpose of using the microprocessor transactor is to emulate the interface between the SUT and host microprocessor. The microprocessor transactor is used to write and read the internal SUT registers and perform service functions after receiving device interrupts.

The SimControl transactor is implemented to perform the following set of functions:

• monitoring transactor states and global time counters;
• enabling, disabling or shutting down generator and collector transactors;
• generating a global start signal for system transactors;
• passing interrupt signals from the C domain to any transactor in the system.

B: Transactors
Transactor operations can be initiated by either C or the HDL domain. Each transactor design has two parts: C part (C side) and HDL part (SUT side), communicating together with the help of the bridge routines. The SUT side of a C-initiated transactor constantly polls the C domain, asking if there are any jobs available for its execution. On the contrary, the V side of a HDL-initiated transactor asks for data only when it needs to perform more data processing. The testbench transactors, except the C-initiated SimControl transactor, are all HDL-initiated.

Test structure
Tests are written in C using a unified structure, which consists of the following parts.

1. Test initialization part.
This part contains system initialization routines to set default values to the test control structures. Besides, there can be a number of set/reset statements for the test-specific parameters, like the total number and types of ATM cells generated for each SUT port.

2. System port specification part.
In this part the SUT ports are specified. Normally ports are associated with transactors. Each port can be set as a source or destination. A source/destination port is attached to a generator/collector type transactor.

3. Connection specification part.
The test connections are determined as a path between two ports, one of which is a source and another of which is a destination. ATM cells traveling from the source to destination are assigned a unique combination of VPI and VCI numbers. In the case of AAL packets, each packet gets a unique connection identification number.

4. Data traffic generation part.
In this part ATM or AAL packets are generated and stored in the system databases.

5. Transactor registration part.
All of the transactors must be registered and recognized by the transport layer in order to establish the correct connections between the C and V transactor sides. After this the HDL simulator is started.

6. SUT register map initialization part.
The SUT registers are set up with the help of the microprocessor transactor. Once the internal SUT registers are set up, the SimControl transactor fires a start signal to all of the generator and collector transactors.

7. Simulation monitoring part.
In this part the test enters a while loop in which it monitors events happening in the verification system, and makes a decision on when to terminate the simulation.

8. End of test part.
The test statistics are gathered and analyzed at the end of the test. As a result, the decision indicating whether the test passed or failed is made.

Verification reuse -a customer experience
This section describes a SOC verification project carried out by Zaiq Technologies for one of its customers. The customer has been developing an SOC to transmit voice and data traffic over ATM networks. These chips are characterized by high complexity and increased functional capability incorporating several cores. The verification quality and methods of each IP core differ from vendor to vendor. As a result, the importance of system verification becomes critical.

A: Device Overview
Figure 3 shows the device block diagram. The device terminates a variety of low-speed physical link protocols via an integrated FRAMER core. The physical layer processing (PHY) block is designed from a set of external IPs. The ATM cell traffic carried over the PHY links may be treated as an ATM UNI, or combined along with other links associated with an ATM IMA group. The PHY unit communicates with the Framer using the chip internal serial interface. The ATM layer functions are provided by a modified version of the internally developed IP (ATM block).

A UTOPIA-2 interface is used to provide effective communication between both the PHY-ATM layers and ATM-AAL layers. The AAL engine is designed in-house to pro-vide for the mapping of the ATM-SDUs into an AAL-SDU via segmentation/reassembly, CPCS and SSCS services. The AAL block accommodates AAL2 channels or AAL5 virtual connections. The AAL-SDU is formatted and transferred to the destination using either packet or cell-based delivery through the system interface. Communication control with the IC blocks is accomplished through a 32-bit microprocessor IP core interface.

B: System Verification Development
The verification team was formed and put on the project in an early stage when the chip specification and interface descriptions were defined. The verification challenge was in the complexity of the overall system, which was designed to process a large variety of data traffic.

The verification system was developed from the following major components:

• standard workbench and service libraries;
• standard script libraries;
• the AAL layer C library developed by a third party;
• standard testbench design approach;
• standard transactor design methodology.

A significant effort was made by the verification team to create and debug the project top efficiency layer routines. These routines were designed to increase the abstraction level of the verification tasks.

The FRAMER, PHY and ATM macros were modified by the design team to meet the chip requirements. For instance, the PHY FPGA implementation was changed into ASIC. The FRAMER block had a number of modifications to enhance its functionality. As a result, the verification plan was developed, taking into account the importance of the basic verification of the device blocks and correct block intercommunications at the system level.

The microprocessor, UTOPIA Master and Slave transactors were reused in the project with minor modifications. The Span Line, Switch and System interface transactors were designed for the project according to the transactor design methodology. In addition, collector type transactors were added to the internal serial interface, increasing the verification observability.

The device verification tests were split into four main categories: FRAMER-PHY, ATM, AAL and system tests. The corresponding device configurations were created to speed up the test simulations. All of the tests started to be developed almost in parallel, except the system tests. After the completion of the block verification, the system tests were run. The quality of each test was estimated by using the vendor-provided RTL code coverage software. The verification environment was enhanced by providing support for the gate-level verification using RTL tests.

C: Verification Results
The project proved that there are no designs without problems. Helping to find and eliminate these problems was the main goal which, in our opinion, was achieved. Different types of errors identified during the chip verification are described below.

Architectural errors. These errors appeared during the system verification when two or more IP cores were inter-faced to each other. Most commonly the errors were caused by different lengths of address or data buses between blocks. For instance, the ATM and PHY cores communicate using a UTOPIA-2 interface. The ATM master was polling more addresses while the PHY slave was not designed to serve that number of links. As a result, the PHY block was sending cells to the ATM links, which were not initialized.

Specification errors. During the SOC verification these errors were detected when the system blocks were tested together in different operation modes. It was discovered that some block operation modes were not compatible with the other blocks. Another common source of the specification errors was a different interpretation or misinterpretation of telecommunication standards.

Interface errors were the major contributors to the bug-tracking statistics in the early stage of the project. For example, the microprocessor bus interface, which is sup-posed to support the communication of the microprocessor with the system blocks, did not work properly in the beginning. To speed up the simulation and locate the microprocessor bus problems, the microprocessor was substituted by the microprocessor transactor. Each system block was verified with the microprocessor transactor, revealing a number of bus signaling problems.

Design errors. The design errors in the RTL code took the overall lead. As Table 1 shows, 58% of all RTL errors was detected in the AAL block. This is due to the fact that it was the only block designed during the project. The original implementation of the FRAMER core was tested partly by the verification team in the previous project. This speeded up the FRAMER delivery to the project. The ATM core had minimal changes and was reused a number of times in other customer chips. Despite this, 11% of all RTL errors was attributed to the FRAMER and ATM macros. The PHY core had a number of changes compared with the original core. Its original design implementation was changed from FPGA to ASIC. As a consequence, the total number of PHY core errors reached 25%. Another 6% of the errors was contributed by the SOC control logic. Taking into account a large number of block RTL errors, the test-bench's ability to support both the block-level and system-level verification without changing the test code was an important advantage. Once the RTL problem was fixed at the block level, the tests were rerun using the system configuration.

Test environment errors. Test environment problems were caused mostly by errors in the project efficiency routines and some transactor implementations used across different device configurations.

Block Name	Design Errors
FRAMER	8%
PHY	25%
ATM	3%
AAL	58%
Control	6%

Conclusions
In this paper the framework for verification of SOCs was presented. It was shown that the described verification system provides for the verification methodology and code reuse, decreasing the SOC verification costs. The verification methodology and code incorporate the following reusable system elements, which are transferable across projects with minimal effort: user inter-face, verification environment structure, testbench and transactor design, test writing methodology.

The development of new standards and interfaces drives the development of new chips. As a result, it is impossible to implement an entirely reusable verification system. The verification framework described in this paper provides for the development of verification testbenches with almost infinite functional abilities due to its scalability and expendability. According to our experience, the testbench design process was concentrated mostly on 1) the project efficiency layer development to support a high level of abstraction in writing test cases; 2) the designing and testing of new interface transactors.

In order to increase the efficiency of the verification system development, the project managers must find a proper balance between team members with software and hardware background. If the project requires more effort in the verification system development, then the proportion of software to hardware engineers should be balanced accordingly. When the verification system is stable, then writing test code and running tests become simple.

Zaiq Technologies
www.zaiqtech.com
info@zaiqtech.com

Acknowledgments
We would like to thank Andy Meyer and Bob Fredieu for their valuable comments and contributions to this paper.

References
[1] D. Chapiro, "Testbench vs. High-Level Languages for Verification", Computer Design's Electronic Systems: Technology & Design, May 1999.

[2] S. Dey, E. J. Marinissen, Y. Zorian, "Testing System Chips: Methodologies and Experiences", Integrated System Design (ISD), pp. 36-48, Sept. 1999.

[3] D. McDysan, D. L. Spohn, "ATM Theory and Application", McGraw-Hill, Signature Edition, 1998.

[4] A. Meyer, "A Loosely Coupled C/Verilog Environment for System Level Verification", Proc. of IVC/VIUF, pp. 274-279, 1998.

[5] M. Newman, "Test Benches in C Speed Verification by Unifying Emulation and Simulation", Integrated System Design (ISD), pp. 34-40, Nov. 1999.

[6] K. Ruparel, "SOC Test: the Devil is in the Details of Integration/Implementation", Proc. of Int. Test Conference, pp. 1143, 1998.

[7] P. Whittemore, G. Dearth, "Object-Oriented Approach to Verification", Proc. of 1st Synopsys Users Group Conference, SNUG'99, Section FC-1, Oct. 7-8, 1999.

Back To Top

Home | About Us | Solutions | Innovation | Jobs@Zaiq |News | Partners | Site Map | Contact Us