9 Veda Tejaswini Development of varification IP of LIN · done by changing testbench parameters or by changing the ... (Universal Serial Bus) ... is implemented as a simple shift

SASTECH Journal 58 Volume 12, Issue 1, April 2013

DEVELOPMENT OF VERIFICATION IP OF LIN

CONTROLLER USING VERIFICATION

METHODOLOGY MANUAL S. N. Rashmi 1, *M. S. Tejaswini 2

1- [Engg.] Student, 2- Assistant Professor Department of Electrical and Electronics Engineering,

M. S. Ramaiah School of Advanced Studies, Bangalore – 58.

*[email protected]

Abstract Verification has become one of the time consuming task in design and verification cycle and hence takes up the

major chunk of the resources. In order to meet the quality of verification which decides the success of the design, verification teams around the world adopt different verification methodologies, which are a systematic way of verifying design with a rich set of standard rules and guidelines. Since the serial communication protocols are preferred means of data communication, application of Verification Methodology Manual (VMM) environment for the verification of LIN controller has tremendous implementation scope.

In the present work, VMM has been followed as the methodology for the development of verification environment and functional verification of LIN controller. VMM Class Library provides the building blocks needed to quickly develop reusable and well-constructed verification components and test environments using SystemVerilog. Few changes are made in the sequences generated and the timing for driving of the control signals for a particular module through minor changes in the code rather than developing all the classes for the verification environment from the scratch. The work introduces a directed stimulus generating testing environment for the design which includes generator, driver, monitor and checker.

Based on the environment created, data packets were generated by the generator and transmitted to the LIN controller. These data packets are transmitted by the transmitter of LIN controller and verified at the receiver in the verification environment.

SASTECH Journal Volume 12, Issue 1, April 2013

59

1. INTRODUCTION

Before any IC is fabricated, it is necessary to verify whether the required functionalities are preserved. Verification engineers have to make sure that before fabrication, all the properties of the IC can be successfully implemented. A primary purpose of functional verification is about finding failures, identifying bugs and correcting before they are mapped into the IC. Verification consumes majority of the effort in the design cycle and is on the critical path in the design flow of multimillion gate Application Specific Integrated Circuits (ASICs). Hence it has become a bottleneck in the design process. Simulation based testing is faster and also provides capability to check all the signals buried under the design. But due to the increasing complexity in design and the concurrency behavior of the design, it has become very difficult to verify the functionality using traditional testbenches. Verification Methodologies are a systematic way of verifying design with a rich set of standard rules and guidelines. It provides the necessary infrastructure to built robust, dependable and complete verification environment. It reduces the verification effort with predefined libraries and makes verification easier by avoiding errors. CDV (Coverage Driven Verification) is combination of automatic test generation, self-checking testbenches, and coverage metrics to significantly reduce the time spent in verifying the design. Using CDV, verification of the design can be thoroughly done by changing testbench parameters or by changing the randomization seed. CDV support both directed as well constrained-random testing.

Fig 1.1 Testbench Components of VMM (System Verilog VMM 1.2, 2012)

Since Verification Methodology Manual developed by Synopsys supports CDV, in this present paper work, the functional verification of LIN controller is carried out. Fig 1.1 shows the components used in VMM based verification.DUT (Design Under Test) describes the design that is intended to be verified which is usually in RTL. Interface serves as link between DUT and the verification environment. A sequence is the series of transaction and

sequencer is used to control the flow of transaction generation. Driver takes the transactions from the sequencer and drives DUT as per the interface signal specifications. Monitor samples DUT signals but does not drive them. Monitors collect coverage information and perform protocol checking. Scoreboard has 2 analysis imports. One is used to for getting the packets from the driver and other from the receiver.

A number of researchers have studied on the verification methodology on different automotive protocols. Zarri et al. presents the architecture of verification components that can be applied in all the different levels and shows how they have been successfully applied to the verification of systems integrating LIN, CAN and Flex Ray protocols. It describes the assessment of the quality of the verification flow, and determining the link with post silicon and on-field testing. Primoz Puhar et al. proposes a three-step design and verification flow based on a reusable testbench. It enables a short design time for a fast-simulating functionally-verified TL (Transaction Level) model, to be used in early software development, and a functionally verified RTL model, ready for hardware implementation. The approach is demonstrated on a USB (Universal Serial Bus) host controller design. Oswaldo Cadena discusses the SystemVerilog implementation of the Open Verification Methodology (OVM) exercised on an 8b/10b RTL open core design to expose the key features of OVM. Emphasis is put onto the actual usage of the verification components rather than a complete verification flow aiming at being of help to readers unfamiliar with OVM seeking to apply the methodology to their own designs. Pan Guoteng et al. describes the design and verification of a MAC controller based on AXI bus, which system architecture integrates original design components and reusable IP cores. It also discusses implementation of Multilevel and reusable verification platform using VMM verification method.

The literature reveals the importance of verification of serial protocol controllers and quality of the verification using different verification methodologies. Since the serial communication protocols are preferred means of data communication, application of VMM environment for the verification of LIN controller has tremendous implementation scope. In the current work, verification environment for the LIN controller is created using VMM.

2. LIN DESCRIPTION This paper discusses the implementation and

verification of LIN controller. The LIN controller functions in a manner very similar to a UART. The controller handles all of the serialization, bit-level timing, frame packing, checksum generation and validation, parity generation and validation, and ensures and validates the consistency of the LIN frames.

2.1 Block Diagram of Lin Controller

Fig 2.1 shows the developed top level block diagram of LIN Controller. It contains 4 bit address line and 8 bit data input. Fig 2.2 gives a block diagram of the overall design of the LIN controller. Each functional block has a

SASTECH Journal Volume 12, Issue 1, April 2013

60

corresponding synthesizable VHDL file. Totally there are 8 sub blocks they are as follows Configuration Registers, Core state machine, Transmitter, Receiver, Clock Divider, Majority Sampler, Parity Generator, Checksum generator.

Fig 2.1 Top Level Block Diagram of LIN Controller

Fig 2.2 Block Diagram for the LIN Controller and CPU Interface (Xilinx, 2007)

The configuration register block handles the bulk of the CPU interface, and mediates the setting and clearing of various status and configuration registers. The core state machine handles all bit timing operations, sets or resets various status registers, and interrupts the CPU when appropriate. The core state machine is primarily composed of two state machines, the master and the slave. There should only be one master active in any single LIN network. The master task handles all bus arbitration. The slave task is responsible for sending the data portion of a frame. The clock divider divides the system clock down to the internal clock "bitclk_x16" with a configurable 16-bit divisor. The majority sampler samples the incoming bit stream at 16x the current bit rate. It outputs the majority of the last 16 samples. The checksum generator maintains a resettable accumulator,

an 8-bit input, a "strobe" to latch and add a new value, and an 8-bit output containing the check byte. The parity generator is a simple combinational circuit that takes a 6-bit input and outputs two parity bits PR0 and PR1. The receiver is implemented as a simple shift register with a parallel output and an asynchronous reset. The transmitter module is implemented as a simple shift register with a parallel input and a strobe to load a new input.

3. DESIGN OF VERIFICATION ARCHITECTURE

In this paper, the VMM verification methodology is

used to build a scalable layered verification platform based System Verilog and sufficient test cases are designed for the DUT to cover all possible boundary conditions. The block diagram for the VMM based verification environment for LIN controller is shown in the fig 3.1. The components of architecture are: Generator, Monitor, Driver, Checker and DUT. Generator generates the 8 bit data input to the LIN controller. The generated data are driven to the DUT by Driver. Checker at the transmission side are provided with a copy of the generated data for further comparison. Interface is used to connect DUT to the testbench I/O ports. After DUT processes these signals to the Checker, it is monitored by the Monitor and passed on to the Checker. The data in the transmitter and receiver Checker are compared, if both are same, then functionality of LIN controller is said to be verified.

Fig 3.1 Block diagram of VMM based verification environment

3.1. Implementation of Verification Architecture

Fig 3.2 shows the flow chart of verification flow for verifying the LIN Controller using Verification Methodology Manual. It includes the addition of stage inputs to the interface. The important stage in creating verification architecture is to bring up the interface consisting of inputs and outputs. Next step is to generate the input signals; generator generates the 8 bit data input. These signals have been driven to the DUT by the Driver for further processing. The output signals coming out from the DUT have been monitored by the monitor. The checker at transmission and reception side compares the data. If both the data are same, then functionality of LIN Controller is said to be verified.

SASTECH Journal Volume 12, Issue 1, April 2013

61

Fig 3.2 Verification flow for verifying LIN Controller

3.2 Design Under Test This describes the design that is intended to be verified.

This is generally RTL description in any of the HDL (Verilog, VHDL and System Verilog).This completely describes the functionality of the design as well the features to be verified. The DUT contains the design of LIN controller. Totally there are 8 sub blocks, they are: transmitter, receiver, parity generator, majority sampler, LIN transceiver, divider, core state machine, configuration registers, checksum generator and top level LIN controller module. All these blocks are encapsulated in DUT.

3.3 Interface

Fig 3.3 Interface block of LIN controller

Interface serves as the actual link between the design-under-verification and the verification environment. It is a SystemVerilog interface. The interface describes the pin-

level description of the DUT. An interface is basically a bundle of nets or wires. In Verilog, different modules are connected through module ports. This is not productive for large modules or complex designs as manually connecting hundreds of ports is not an easy task. This is prone to error. This also demands the detailed knowledge of all the pins. It is required to change the pin connection in the interface on changing the design features. But these problems can be overcome by using interface. Interface can also be used to connect the DUT to other sub-modules or components. The interface of LIN controller is shown in the Figure 3.3. Here the Interface list outs all the port connections of LIN controller module as shown in the figure 3.3.The interface is used to encapsulate all the communication between the top level modules. 3.4 Wrapper

Fig 3.4 Wrapper of LIN controller

Since the design is in VHDL and testbench environment is in System Verilog, in order to connect the wrapper has been created. Fig 3.4 shows the wrapper of LIN controller.

3.5 Generator

A generator is the series of transaction and is used

to control the flow of transaction generation. A generator is extended from vmm_generator class. vmm_generator does the generation of this sequence of transaction. Driver (extension of vmm_driver) takes the transactions from generator and processes the packets of data or drives them to other component or to the DUT.

SASTECH Journal Volume 12, Issue 1, April 2013

62

Fig 3.5 Implementation of generator

Fig 3.5 shows the implementation of the generator module. Generator is mainly used to generate the 8bit data to the LIN controller module which is sent to rxd pin. 3.6 Checker

Checker has been implemented by extending vmm_checker. Checker has to analysis imports. One has been used for getting the packets from the driver and other from the receiver .Then the packets are compared and if they do not match, then error has been asserted. Checker has been implemented to verify whether the data packets which are sent and received are same in the LIN controller module.

Fig 3.6 Implementation of checker at receiver

Fig 3.6 shows the implementation of the checker. The 8 bit data which is generated by the generator are stored in to the transmit register which is read by rxd pin of the LIN controller. These signals are processed by DUT and sent to the receiver end. At the receiver end txd pin reads the data and it stores in to the receive register. Now the data present in the transmit and receive registers are compared. If both the data are same log file generates the report “test case passed” else it generates “test case is failed”.

3.7 Monitor

Monitor samples DUT signals but does not drive

them. Monitors collect coverage information and perform protocol checking. Even though reusable drivers and

sequencers drive bus traffic, they are not used for coverage and checking. Monitor does the following: Extracts signal information from a bus and translates the information into a transaction that can be made available to other components and to the test writer and Performs checking and coverage. Checking typically consists of protocol and data checkers to verify that the DUT Output meets the protocol specification. Coverage is collected in the monitor. It is implemented by extending the vmm_monitor class and an instance has been created in the environment for hooking it up with DUT signals.

Fig 3.7 Monitor of LIN controller

Fig 3.7 shows the Monitor of LIN controller. It monitors the DUT signals at the receiver end of the LIN controller.

3.8 Agent Agent is the top level module. It contains all the components of the testbench such as Generator, checker, monitor, and wrapper. 3.9 Environment

Environment class is used to implement verification environments in VMM. It is extension on vmm_env class. The testbench simulation needs some systematic flow like building the components, connection the components, starting the components etc. vmm_env base class has methods formalize the simulation steps. All the methods inside environment class have been declared virtual. Virtual interface has been created in the environment and all other virtual functions of environment class have been extended.

4. RESULTS AND DISCUSSIONS

The proposed verification methodology has been implemented on LIN controller and the results are discussed in subsequent sections. 4. 1 Verification of Top Module of LIN controller

SASTECH Journal Volume 12, Issue 1, April 2013

63

The verification of top level LIN module has been carried out by developing the test bench architecture using VMM which contains components like interface, checkers, monitors, generators and DUT. The main scenarios that have to be verified include verifying receiving path and transmission path of LIN Controller.

Read operation

The data packets that have to transmit have been generated by the generator. Fig 4.1 shows the simulation of the transmitted data packets.

Fig 4.1 Simulation of transmitted data packets

Fig 4.2 shows the log file report of the transmission operation. The data packets transmitted are 4A, 55, 93 and E5.

Fig 4.2 Log file of transmitted data

8 bit data packets are generated and it is stored in to the transmit register and it has been read by the txd pin of the LIN controller module. Write operation

The data packets received have been read by rxd pin of LIN controller and data packets are stored in the receive register. Fig 4.3 shows the simulation of received data packets. The data packets received are 4A, 55, 93 and E5 which is same as the data packets transmitted hence the functionality of LIN controller is verified.

Fig 4.3 Simulation of received data packets

Fig 4.4 shows the log file of received data. Received data packets are 4A, 55, 93 and E5 which is same as transmitted data hence functionality of LIN controller is verified.

Fig 4.4 Log file of received data

The following are the test scenarios identified for read and write scenarios

Read scenario: This scenario verifies read operation with respect to

data and addr controlled by the control signals sel , r_n , w_n Write scenario: This scenario verifies write operation with respect to

data and addr controlled by the control bits sel , r_n , w_n

Based on the test cases and scenarios explained the above test scenarios has to be verified so as to satisfy the functionality of the LIN controller. The transmit and receive operations and proceeding are cross verified from the log file and simulation results obtained which in turn satisfies the functionality of LIN controller. 4.2 Simulation results obtained for verification of LIN Controller

Fig 4.5 shows the simulation result obtained. It can be seen that during read operation txd pin is enabled and sel=0. During this operation the data packets have been stored in to the transmit register and then read by txd pin. The data transmitted is 4A, 55, 93 and E5. During write operation rxd pin has been enabled and sel=0.During this operation, the 8 bit data packets have been read by rxd pin and stored in to the receive register. Received data packets are 4A, 55, 93 and E5 which is same as the transmitted data packets hence LIN controller’s functionality is verified completely.

Transmitted data = 4A, 55, 93, E5

SASTECH Journal Volume 12, Issue 1, April 2013

64

Fig 4.5 Simulation result of transmitter and receiver

Fig 4.6 Log files report

Fig 4.6 shows the log file report of the transmitted data and received data. It is seen in that data packets sent are 4A, 55, 93 and E5 and the received data packets are 4A, 55, 93 and E5. Since both the data packets are same functionality of LIN controller is verified.

5. CONCLUSIONS The design implementation flow and verification methodology adopted for verifying LIN controller has been verified. Test scenarios were identified based on LIN controllers’ specification and functionality. An environment has been developed using VMM base classes which contains various standard components of VMM architecture like Generator, Monitor, Agent, checker, scoreboard, interface and LIN controller DUT units. Functional verification has been carried out for the implemented design using Mentor Graphics ModelSim 6.2C by passing the 8 bit data packets at the input in order to verify the read and write transfers. The data packets which were sent at the input side were received

serially at the output side which is observed in the simulation waveforms. Both the data packets at input and output were same hence entire functionality of the design is verified.

6. REFERENCES Accellera Organization (2004) “SystemVerilog 3.1a Language Reference Manual Retrieved on 20th sep 2012 Abhishek Shetty (2012) “System Verilog Verification Methodology Manual (VMM 1.2)” San Francisco, CA Spring 2012 Janick Bergeron (2005) “ Verification Methodology Manual for SystemVerilog”. New York: Springer Chris Spear (2008) “SystemVerilog for Verification - A Guide to Learning the Testbench Language Features. New York: Springer Janick Bergeron (2005) “ Verification Methodology Manual for SystemVerilog. New York: Springer G. Zarri, F. Colucci, F. Dupuis, R. Mariani, M. Pasquariello, G. Risaliti (2007) “On the Verification of Automotive Protocols ”. Torino,Italia Pan Guoteng, Luo Li, Ou Guodong, Fu Qingchao, Bai Han (2013) “Design and Verification of a MAC Controller Based on AXI Bus ” 2013 Third International Conference. Changsha, Hunan, China Primoz Puhar, Andrej Zemva (2009) “Functional verification of a USB host controller” 11th Euromicro conference Oswaldo Cadenas, Elías Todorovich (2010) “Experiences Applying ovm 2.0 to an 8b/10b RTL Design” University of Reading RG6 6AY, UK Tae-Yoon Moonl, Suk-Hyun Sec, Jin-Ho Kiml (2007)“Gateway System with Diagnostic Function for LIN, CAN and FlexRay” International Conference on Control, Automation and Systems 2007 Oct. 17-20, 2007 in COEX, Seoul, Korea

Received data = 4A, 55, 93, E5

Transmitted data = 4A, 55, 93, E5