This paper describes SoCBase-VL, which is a C/C++
based integrated framework for SoC functional verification.
It has a layered architecture which provides easier testbench
description, automatic verification of bus interfaces
and seamless testbench migration. This framework does not
require verification engineers to learn other verification
languages as long as they have sufficient knowledge on
both C/C++ and SystemC. We have confirmed its usefulness
by applying it to a TFT-LCD Controller verification

Chae, Soo-Ik

Park, Sanggyu

SNU Open Repository and Archive

A C/C++-based Functional Verification Framework  using the SystemC Verification Library  Sanggyu Park and Soo-Ik Chae Center for SoC Design Technology, School of Electrical Engineering and Computer Science Seoul National University, SEOUL, KOREA{sanggyu, chae}@sdgroup.snu.ac.kr Abstract This paper describes SoCBase-VL, which is a C/C++ based integrated framework for SoC functional verification. It has a layered architecture which provides easier test-bench description, automatic verification of bus interfaces and seamless testbench migration. This framework does not require verification engineers to learn other verification languages as long as they have sufficient knowledge on both C/C++ and SystemC. We have confirmed its useful-ness by applying it to a TFT-LCD Controller verification.  1 IntroductionIn the dynamic verification, a set of stimuli is applied to a design and then, its responses are compared to the corre-sponding correct outputs to check its equivalence or cor-rectness. This verification approach requires a testbench that generates stimuli and checks correct outputs. Thus, the quality of verification depends on the quality of the test-bench. As the designs are getting more complex, however, the difficulty of authoring the testbenches is continuously growing even more rapidly.  The difficulties related to the testbench design can be summarized as follows: As the number of the state in a component increases linearly, the number of test cases increases exponen-tially. Therefore, manual enumeration of each test case is not feasible. Several models for a component may be required at different abstraction levels. A testbench for each model should be re-designed to verify the model.  Describing a testbench often requires a deep and thor-ough understanding on domain-specific knowledge. e.g. Bus Specification.  A quantitative measure of the quality of verification is needed. Otherwise, the quality of verification tends to depend on that of verification engineers.  To alleviate those problems, many researchers and EDA vendors offer tools for testbench authoring [1-5]. The Sys-temC Verification Library (SCV) is an extension of Sys-temC for easier testbench authoring which provides con-strained randomization and transaction level tracing[1]. SoCBase-VL is another extension of the SCV, which ad-ditionally provides a layered architecture for easier test-bench description, seamless testbench migration, and an automatic verification of bus interfaces. It also provides the Coverage Monitor Modeling Library (CML) for functional coverage monitoring.  In this paper, we explain our layered testbench architec-ture in Section 2 and the CML in Section 3. In Section 4, we briefly introduce how to use our framework through a practical example. The summary and future works are given in Section 5. 2 C/C++-based Layered Testbench A H/W component (or a system) can have several ab-straction level models: transaction level model, RT-level model, FPGA prototype and Silicon. We propose a layered testbench architecture, depicted in Fig. 1, by which a single testbench description can be used for verification of all models without manual modification.  Fig 1. Layered testbench architectureA verification task (v-task) is a software program that generates stimuli to a design and validates its responses. It is a C/C++ program described in Verification Task Pro-gramming Interface (VTPI), which is a set of functions and Design(TLM)TransactorDesign(RTL)Design(RTL)ISSVPOSDesign(FPGA/Silicon)FPGA/SiliconVPOStVPOS SystemC/SCVtVPOSSystemCSystemCHDL SimulatorPCBHDL Simulator(b) TLM verification (c) Transactor drivenRTL verification(d) Processor drivenRTL verification(e) Emulation/Prototype verificationVerification TaskVTPItVPOSTransactorSystemC/SCVDesignVPOSProcessorModel(a) Layered TestbenchArchitectureAuthorized licensed use limited to: Seoul National University. Downloaded on November 11, 2009 at 00:22 from IEEE Xplore.  Restrictions apply. macros for v-task description. A v-task is a software pro-gram and some execution methods are needed to execute it. There are two kinds of execution methods: the processor model and the transactor. The conceptual roles of both methods are identical, but their implementations are differ-ent. To abstract out details of the execution methods, we developed a verification-purpose light OS kernel (VPOS) and its transaction level version, tVPOS. The VPOS pro-vides just the basic OS functions such as multi-tasking, memory management and interrupt handling. A v-task can be run on a processor model with the help of the VPOS or on the transactors with the help of the tVPOS, as shown in Fig 1(a).  A transactor is an abstraction adapter that translates a transaction function call into the bus signal activities, and vice versa. In our framework, we added into the transactor an important feature for the automation of the bus-level verification. The augmented transactor has two internal layers: a protocol layer and a signal layer, as shown in Fig. 2.Fig 2. Internal layers of the augmented transactor In the protocol layer, read (or write) function calls are translated into a sequence of transfers. Although a v-task can explicitly select the transfer type of each transfer, it also allows the transactor to select each transfer types ran-domly. In contrast, for the processor-driven testbench, bus-related parameters are ignored. Therefore, the v-task, which invokes the transactor, can control and accelerate the veri-fication of the bus interface. This layer also checks protocol rules and provides the bus protocol coverage information. Because the protocol layer of the augmented transactor abstracts out the bus-level details, the v-task can be easily described without any bus-level details. Moreover, v-tasks of a component can be reused for verifying the same com-ponent with a different bus protocol. The signal layer of the transactor translates each transfer to the bus signal activities and converts an abstract data types to a signal-level data type. For example, the integer type is converted into the std_logic_vector type in this layer. In the augmented transactor depicted in Fig. 2, the I/O sig-nals in the RT-level design can be relayed to and from the v-task only though the signal layer. This feature enables the v-task to validate I/O signals which are not bus related.  Because a v-task can control the random behavior of its transactors, the verification engineer can set them to gener-ate only simple transfers at the early verification stage, and then, change it to generate more complex transfers on later stages. Through this approach, we can easily localize the bugs related to the bus interface.  3 Coverage Monitor Modeling Library We developed the Coverage monitor Modeling Library (CML), which is a C/C++ class library for functional cov-erage monitor description. Fig. 3 is a part of an AHB slave coverage monitor described using the CML. cov_value NONSEQ, SEQ,IDLE, BUSY; cov_value BYTE, HALF, WORD; cov_literal HTRANS = IDLE|BUSY|NONSEQ|SEQ; cov_literal HSIZE = BYTE | HALF | WORD; cov_expr expr1 = (HSEL[0] == TRUE) & (HTRANS == NONSEQ)            & (HREADY[0]==TRUE) & (HWRITE[0] == HWRITE.all()) &          (HRESP[1] == HRESP_OKAY); cov_expr expr2 = HTRANS[0] == (NONSEQ | SEQ) cov_expr expr3 = HTRANS[0] == (NONSEQ + SEQ) cov_sampler NOWAIT; if(HREADY == TRUE) { NOWAIT = HTRANS; … } expr4 <<= NOWAIT; (1) (2) (3) (4) (5) (6) (7) (8) (9) (10)(11)Fig 3. CML-based Coverage Monitor In CML, five object types are defined: the coverage value, the coverage literal, the coverage expression, the sampler, and the coverage monitor. A coverage value repre-sents a value of a state in the design and a coverage literal represents a state in the design. A set of coverage values must be assigned to a coverage literal. As in the expression (3), HTRANS can have any value among IDLE, BUSY, NONSEQ and SEQ. A coverage expression is a formal representation that defines multiple functional covers with coverage literals, coverage values and coverage operators which are listed in Table 1.  Table 1. Coverage operator Left Op. Right Meaning VA | VB VA or VBVA + VB VA or VB, respectably L[k] == VA If the value of L[k] is VA then hit L[k] != VA If the value of L[k] isn’t VA then hit L[k] >,<>=,<=VA If the value of L[k] is {greater, smaller, equalor greater, equal or smaller } than VA thencoverage hit EA &= EB If the EA and EB is true then hit EA += EB Merge the EB into EAVA : Value A    L[k] : Literal[k]     EA : Expression A The notation of literal[k] represents the value at time k.For example, the expression (6) reports a coverage hit when the current value of HREADY is ‘FALSE’ and the next-time value is ‘TRUE’. Note that the function of   ‘+’ operator is somewhat special in defining the functional for(...) {    // processing 1    ahb->write(addr, size, data);    // processing 2    io->read(value);    if(result is invalid){         //report error    } }Signal LayerProtocol LayerFunction CallFunction CallBus SignalBus InterfaceDesignData TypeConversionTransaction RandomizationProtocol Rule CheckingProtocol Coverage MonitoringVerification Task 1I/O SignalTransactorAuthorized licensed use limited to: Seoul National University. Downloaded on November 11, 2009 at 00:22 from IEEE Xplore.  Restrictions apply. covers. Expression (7) defines one functional cover which reports a hit when the value of HTRANS is NONSEQ or SEQ. Meanwhile, expression (8) defines two functional covers: one for a hit when the value of HTRANS is NONSEQ and the other for a hit when the value of HTRANS is SEQ.  To analyze each coverage expression, a set of history of the literals needs to be stored. A sampler is an object that stores the literal values cycle by cycle. Expression (9-10) defines a sampler that stores the literal values only when the current value of HREADY is TRUE. A coverage ex-pressions must be linked to a sampler with an operator ‘<<=’ as shown in (11). A coverage monitor is a collection of these objects that provides several common methods for user interface.  4 TFT LCD Controller Verification In this section, we present a TFT LCD Controller verifi-cation example to show the effectiveness of our framework.  The basic operation flow of the TFT LCD Controller is as follows: 1) The AHB slave interface receives mode set-up commands and configures the operation mode. 2) The AHB master interface reads in image data and stores those into FIFO. 3) The timing controller retrieves pixel data from FIFO and drives TFT LCD controller outputs. The TFT LCD controller has six parameters such as color for-mat selections, bit inversion mode, and endianness. There-fore, it has a total of 64 operation modes to be verified.  The testbench architecture for the TFT LCD controller verification is illustrated in Fig. 4. The AHB slave interface of the TFT LCD Controller is connected to the v-task with a AHB slave transactor. And the AHB master interface is connected to the verification memory with a AHB master transactor. The TFT LCD controller output is connected to a SystemC panel model that receives the output stream of the TFT LCD controller and stores it to the verification memory. The v-task contains a C behavior model of the TFT LCD controller, and its six parameters are randomly selected and configured. The v-task compares the output of the RT-level model stored in the verification memory with the results of behavior model to validate the behavior.   From this test environment, we could verify the RT-level model of the TFT LCD controller thoroughly. Especially, the bus interfaces are verified without any manual descrip-tion. The verification quality was reported with the AHB coverage monitors described in the CML. These monitors are reusable for other verification works.  The v-task can be compiled with the compiler for the embedded processors such as ARM processors, and it can be run on those proces-sor models with the VPOS.  With this feature, we could verify the TFT-LCD control-ler integrated in a FPGA prototype that includes an embed-ded processor by adding a hardware circuit that stores the output of the TFT-LCD controller into the memory.  Fig 4. TFT-LCD Controller Testbench 5 Summary and Future Works In this paper, we proposed an integrated framework with a layered architecture of the testbenches, which provides seamless testbench migration with a verification purpose operating system, the capability of precise and concise functional coverage monitor description, bus-level verifica-tion automation, and high-level testbench description power. Although each technique in the proposed frame-work is widely used, it provides a unified C/C++ and Sys-temC based framework. Our work on the verification framework is not finished yet and still on-going. Although the current version of the framework does not support software verification issues, we have a plan to enhance the VPOS for HdS verification. We also need to support the transactor-driven testbench in the emulation level by devel-oping a more flexible emulation system in the future..  References [1] Verisity, Inc. “Invisible Specman Developer’s Guide Version 4.0.5”, http://www.verisity.com[2] Synopsys, Inc. “OpenVera Language Reference Man-ual”, http://www.open-vera.com, Apr, 2003. [3] OSCI, “SystemC Verification Standard Specification Version 1.0e”, http://www.systemc.org, May, 2003.  [4] Cadence. “TestBuilder User Guide”, Aug, 2003.  [5] ARM LTD, “AMBA Compliance Testbench User Guides”, http://www.arm.com, Feb, 2003.  AHB Master InterfaceAHB Slave InterfaceTFT-LCDControllerTimingControllerTFT-LCD Panel I/OFIFOControl BusData BusAHB MasterTransactorAHB SlaveTransactor Verification MemoryVerificationTaskTransaction Level TestbenchRT Level TestbenchTFT-LCDPanel ModelRTG RTSRTG RTSAuthorized licensed use limited to: Seoul National University. Downloaded on November 11, 2009 at 00:22 from IEEE Xplore.  Restrictions apply. 

A C/C++-based functional verification framework using the SystemC verification library_

https://s-space.snu.ac.kr/bitstream/10371/62282/1/%5b2005%5dA%20C_C%2b%2b%20based%20functional%20verification%20framework%20using%20the%20SystemC%20verification%20library.pdf

A C/C++-based functional verification framework using the SystemC verification library_

Abstract

Similar works

Full text

Available Versions

SNU Open Repository and Archive