Early Development of UVM based Verification Environment of Image Signal Processing Designs using TLM Reference Model of RTL

With semiconductor industry trend of smaller the better, from an idea to a final product, more innovation on product portfolio and yet remaining competitive and profitable are few criteria which are culminating into pressure and need for more and more innovation for CAD flow, process management and project execution cycle. Project schedules are very tight and to achieve first silicon success is key for projects. This necessitates quicker verification with better coverage matrix. Quicker Verification requires early development of the verification environment with wider test vectors without waiting for RTL to be available. In this paper, we are presenting a novel approach of early development of reusable multi-language verification flow, by addressing four major activities of verification like Early creation of Executable Specification, Early creation of Verification Environment, Early development of test vectors and Better and increased Re-use of blocks. Although this paper focuses on early development of UVM based Verification Environment of Image Signal Processing designs using TLM Reference Model of RTL, same concept can be extended for non-image signal processing designs. Main Keywords are SystemVerilog, SystemC, Transaction Level Modeling, Universal Verification Methodology (UVM), Processor model, Universal Verification Component (UVC), Reference Model.


INTRODUCTION
Image signal processors (ISP) address different markets, including high-end smartphones, security/surveillance, gaming, automotive and medical applications. The use of industry standard interfaces and rich set of APIs makes the integration Image signal processing algorithms are developed and evaluated using C/Python models before RTL implementation. Once the algorithm is finalized, C/Python models are used as a golden reference model for the IP development. To maximize re-use of design effort, the common bus protocols are defined for internal register and data transfers.  Vol. 5, No. 2, 2014 78 | P a g e www.ijacsa.thesai.org A combination of such configurable image signal processing IP modules are integrated together to satisfy a wide range of complex image signal processing SoCs [1].

SystemL
In Verification Environment of Image Signal Processing design as shown in figure 1, Host interface path is used to do programming of configurable blocks using SystemVerilog UVM based test cases. UVM_REG register and memory model [20] is used to model registers and memories of DUT. DUT registers are written/read via control bus (AXI3 Bus here) UVC. RTL control bus interface acts as target and control bus UVC acts as initiator. The target control interface of the ISP RTL is driven by control bus UVC (configured as initiator).After register programming is done, image data(random/user-defined) is driven to the data bus interface by the data bus UVC and the same data is also driven to the reference model. Output of the ISP RTL is received by the receiver/monitor of the data bus UVC. Scoreboard compares the output of RTL and reference model and gives the status saying whether the both output matches or not.
'C' test cases are used for programming of RTL registers/memories via CPU interface. C test cases control the SystemVerilog Data Bus UVC using Virtual Register Interface (VRI) [15], [18]. VRI layer is a virtual layer over verification components to make it controllable from embedded software. It gives flexibility to Verification Environment users to use the Verification IPs without knowing SystemVerilog.
Generally, development of Verification Environment for verification of designs is started after availability of the RTL. Thus, significant time is spent for setup and debugging of verification environment after release of RTL which results in delay in start and completion of verification of the designs. It is required to find ways to start developing the Verification Environment much before the arrival of the RTL so that when RTL is available, Verification Environment can be easily plug and play and verification of the designs can be started quickly. Use of TLM reference model of RTL for development of Verification Environment much before arrival of RTL proves to be good solution for the above mentioned problem. This paper is focusing on early development of UVM based Verification Environment of Image Signal Processing designs using TLM Reference Model of RTL before availability of the RTL. Early development of Verification Environment of Image Signal Processing designs is described in detail in Section II.

A. Modeling of ISP designs
A loosely timed high level model of the ISP block is generated at algorithmic functional level using C/C++/SystemC and with TLM-2 interface. The purpose of this model generation is to use this as a reference model. We may say it as a "Golden Reference Model" or "Executable Functional Specification" of the ISP designs. From functional and structural perspective this model can be divided in two major spaces.
First space -the algorithmic computational part, is mainly responsible for image processing using various algorithms involved for image manipulation from the incoming image stream data.
The second spacea TLM interface, is responsible for all kinds of communication to external IPs and other system blocks.
Register interface of this model is generated using IP-XACT tools. And algorithmic part is manually implemented.

B. Testing of Executable Spec only
To test the TLM ISP model, an environment is developed using Python (an open source scripting language) and Synopsys Pa-Virtualizer Tool Chain.
The test environment has following major components: A suitable TLM sub-system is designed. This TLM subsystem consists of various models namely; ISP functional model, AXI BFM, configurable clock generators model, configurable reset generator model, memory model, configurable interconnect etc. All these are pure SystemC models. AXI BFM is provided to interact with other part of the world.
ISP RTL block needs exhaustive verification, which is possible only when the RTL is ready. But, development of RTL design takes time, which means verification of RTL design can't be possible before it becomes available. To shorten this sequential activity, functional model of ISP is used to prepare the early verification environment.
A SystemVerilog test bench wrapper is created over SystemC/TLM ISP sub-system. This SystemVerilog test bench interface with the RTL verification environment.

D. Virtual Platform Sub-system
When all components of platform are in TLM/C, means C/C++ are used as modeling language; we call it a Pure Virtual platform. In typical verification environment, generally all verification components are not only TLM based but also of different verification languages thus making it a Multilanguage heterogeneous simulation environment. For developing early verification environment, TLM based subsystem is developed which consists of every block in TLM/C. This TLM based Sub-system is model of RTL.
In the above mentioned RTL verification environment, a processor model is used which enables us to early develop 'C' test cases for programming of RTL registers/memories via CPU interface. The challenge is to keep the verification environment independent of "C" test cases. We don't wish to compile every time whenever there is change in application code. To be able to achieve this, a sub-system is designed which consists of models of bus interfaces, like AXI BFM, a "generic" processor model, model of memory, etc. an independent "C" program/test case is written to do all the programming and configuration, which in turn runs on processor model of this sub-system. This sub-system is active element in programming phase, but becomes passive once the programming is complete.
Virtual platform sub-system can be represented in following block diagram.

E. Virtual Register Interface (VRI)
Today, most of the embedded test infrastructure uses some adhoc mechanism like "shared memory" or synchronization mechanism for controlling simple Bus functional models (BFMs) from embedded software.
In order to provide full controllability to the "C" test developer over these verification components, a virtual register interface layer is created over these verification environments which provides the access to the sequences of these verification environment to the embedded software enabling configuration and control of these verification environments to provide the same exhaustive verification at SoC Level. This approach addresses the following aspects of verification at SoC Level:

F. Flow used for Design Verification
Much before arrival of RTL, C/Python model of image signal processor designs is developed for algorithm evaluation. Then, TLM/SystemC model of the design is created from C/Python model. After proper exhaustive validation of the model with required test vectors, the model qualifies as an Executable Golden Model or Executable Specification means a 'living' benchmark for design specification. Enabling the use of TLM Model as DUT expedites development and better proofing of the verification environment with wider test vectors without waiting for RTL to be available.
Standard 'interfaces' are used to enable the reuse of verification components. In addition to standard method of bus-interface or signals level connectivity, UVM Multi-Language Open Architecture is used to connect System Verilog TLM port directly to SystemC TLM port which gives advantage of better simulation speed and better development/debug cycle in addition of clean, better and easy connectivity/integration of blocks. Presence of TLM components gives us flexibility to make backdoor direct access to the DUT registers and memories.  In both above cases, control/data flows across both TLM and bus interface boundaries. This method enhances the chances of re-using different already existing blocks in flow. IP-XACT based tools are also used for automatically configuring the environment for various designs.
By the time RTL arrives, complete verification environment and test-vectors are ready with sufficient sanctity, thus eliminating the number of verification environment issues which may arise when actual RTL verification is started. When RTL arrives, the TLM/SystemC model is simply replaced with RTL block with reuse of maximum of other verification components. This enhances the rapid/regress testing of design immediately. Also same C test cases can be run on actual core.