A REPORT

ON AUTOMATION OF C MODEL INVOCATION THROUGH SIMULATION TO IMPROVE THE CHIP VERIFICATION ENVIRONMENT
BY

Name of the Student UIKE ABHIJEET HIMMATRAO

ID No. 2004P3PS108

AT

BROADCOM INDIA Pvt. Ltd., Bangalore A Practice School-II station of

BIRLA INSTITUTE OF TECHNOLOGY AND SCIENCE, PILANI

December, 2007

A REPORT ON

AUTOMATION OF C MODEL INVOCATION THROUGH SIMULATION TO IMPROVE THE CHIP VERIFICATION ENVIRONMENT
BY

Name of the Student UIKE ABHIJEET HIMMATRAO

ID No. 2004P3PS108

Discipline BE (EEE)

Prepared in partial fulfillment of the Practice School-II Course BITS GC413

AT

BROADCOM INDIA Pvt. Ltd., Bangalore A Practice School-II station of

BIRLA INSTITUTE OF TECHNOLOGY AND SCIENCE, PILANI

December, 2007
2

BIRLA INSTITUTE OF TECHNOLOGY AND SCIENCE, PILANI

Practice School Division

Station: Broadcom India Pvt. Ltd. Duration: 5 months Date of Submission: 14th Dec, 2007

Centre: Bangalore Date of Start: 4th July, 2007

Title of the Project: AUTOMATION OF C MODEL INVOCATION THROUGH SIMULATION TO IMPROVE THE CHIP VERIFICATION ENVIRONMENT Name: UIKE ABHIJEET HIMMATRAO ID No.: 2004P3PS108 Discipline: B.E.(Hons.) Electrical & Electronics Name of the Expert: Mr. Rajendra Ranmale Name of the PS Faculty: Dr.Sindhu Key Words: Verification, C modeling, RTL synthesis, HDLs, simulation Project Areas: Verification of digital design and architecture using C models, simulations, automation to improve the chip verification environment Designation: Senior Staff, IC Design

Abstract: The report includes the study of the chip verification environment, C
modeling and video encoder used in Set Top Boxes. The main objective of the project was to automatically invoke the C model through the simulation and to compare the output from the two in order to improve the simulation environment used for the chip verification. The C model for the capture block in the Digital Video Interface module of Set Top Box chip was written and tested. Later, the entire C model was migrated from being a separate entity to an integral part of the simulation environment, thus automating the entire process of C model invocation and to test the output results. This project is aimed at improvement in the verification environment that is used for the design of various chips.

Signature of Student

Signature of PS Faculty

Date 3

Date

Acknowledgements
I am thankful to the Dean, Practice School Division, BITS-Pilani for giving me the opportunity to undergo this internship.

I thank Dr.Sindhu, our PS-II instructor for her help and encouragement throughout the project.

I would like to thank Mr.Rajendra Ranmale, Engineer, Sr Staff IC Design, for his support and guidance. It was his help that encouraged me to work harder and harder all throughout this project.

I would also like to thank Mr. Vivek Bhargava, Sr Manager-IC Design Engineering, Broadcom Corporation for selecting me into this group and allowing me to work on this project.

I would like to take this opportunity to thank Mr. Ali Syed Mohammed, Ms. Maulshree Tamhankar, Ms. Nutan and Ms. Chhavi Kishore, my teammates for their continuous guidance and consistent help throughout this project.

BIRLA INSTITUTE OF TECHNOLOGY AND SCIENCE PILANI PRACTICE SCHOOL DIVISION

Response Option sheet

Station : Broadcom India Pvt. Ltd. ID No. & Name: 2004P3PS108 UIKE ABHIJEET HIMMATRAO Title of the Project: AUTOMATION OF C MODEL INVOCATION THROUGH SIMULATION TO IMPROVE THE CHIP VERIFICATION ENVIRONMENT Centre : Bangalore

Code No. 1. 2.

Response Options A new course can be designed out of this project The project can help modification of the course content of some of the existing Courses

Course No.(s) & Name NO NO

3.

The project can be used directly in some of the existing Compulsory Discipline Courses (CDC)/Discipline Courses Other than Compulsory (DCOC)/ Emerging Area (EA) etc. Courses

NO

4.

The project can be used in preparatory courses like Analysis and Application Oriented Courses (AAOC)/ Engineering Science (ES)/ Technical Art (TA) and Core Courses

NO

5.

This project cannot come under any of the abovementioned options as it relates to the professional work of the host organization.

YES

Signature of Student

Signature of Faculty

TABLE OF CONTENTS Acknowledgements..4 1. Introduction ..................................................................................................................... 7 2. Basic Definitions and Terms used .................................................................................. 8 2.1 Set Top Box .............................................................................................................. 8 2.2 LCD (Liquid Crystal Display) .................................................................................. 8 2.3 Motion Blur............................................................................................................... 8 2.4 ASIC (Application Specific Integrated Circuit) ....................................................... 8 2.5 HDL (Hardware Descriptive Language) ................................................................... 8 2.6 Testbench .................................................................................................................. 8 2.7 Simulation ................................................................................................................. 9 2.8 Functional Verification ............................................................................................. 9 2.9 RTL ........................................................................................................................... 9 2.10 EDA (Electronic Design Automation) .................................................................... 9 2.11 RDB (Register Data Base) ...................................................................................... 9 3. Simulation Environment ............................................................................................... 10 3.1 Environment Hierarchy........................................................................................... 11 3.2 Snapshot .................................................................................................................. 12 3.3 Work ....................................................................................................................... 12 3.4 Hierarchy of the sim directory ................................................................................ 12 4. bcsim Simulation Script ................................................................................................ 14 4.1 How is bcsim used? ................................................................................................. 15 5. The C Model ................................................................................................................. 17 6. What is Motion Blur?.................................................................................................... 17 7. Logic Beneath Capture and Feeder Block .................................................................... 18 7.1. 30 bit data compression ........................................................................................ 20 7.2. 18 bit data compression ......................................................................................... 21 8. Automation of C model Invocation .............................................................................. 22 8.1 Need of automation ................................................................................................. 22 8.2 Constraints .............................................................................................................. 22 8.3 Working of C Model Automation ........................................................................... 23 9. Conclusion .................................................................................................................... 29 References: ........................................................................................................................ 29

1. Introduction
The project deals with the verification of Set Top Box chips and the environment that takes care of the verification of various digital chips. There are various approaches pursued in order to verify a chip under design. Simulation, C modeling, Emulation are various ways of verification of the chip under design. Initial part of this project was to study aforesaid methodologies in depth. Later part of the project covers the development of the C model for one of the modules of the chip i.e. the capture and feeder block. Final part of the project is related to the modification of the simulation environment which looks after the verification of the given chip by running the testbenches. Lastly, the project touches upon the transfer of the entire automation task from verilog side to C side, in order to make the task portable for the later stage of verification, which is emulation. The entire project was done as a part of the development of a Set Top Box chip design but its utility extends to other chips under design as well. The Set Top Box being designed has a special feature to remove the occurrence of the Motion Blur that is a very common phenomenon in LCD televisions, that is where the chip will be used in. The simulation environment is the same for almost all the chips under design. So, the modification done in the environment for set top box will also be useful for other chips under design.

2. Basic Definitions and Terms used

2.1 Set Top Box
It is a device that connects a television and an external source of signal, turning the signal into content which is then displayed on the television screen.

2.2 LCD (Liquid Crystal Display)

LCDs utilize two sheets of polarizing material with a liquid crystal solution between them. An electric current passed through the liquid causes the crystals to align so that light cannot pass through them. Each crystal, therefore, is like a shutter, either allowing light to pass through or blocking the light.

2.3 Motion Blur

Motion blur is the apparent streaking of rapidly moving objects in a still image or a sequence of images such as a movie or animation.

2.4 ASIC (Application Specific Integrated Circuit)

It is an integrated circuit (IC) customized for a particular use, rather than intended for general-purpose use. For example, a chip designed solely to run a cell phone is an ASIC.

2.5 HDL (Hardware Descriptive Language)

Its a language that can describe the circuit's operation, its design and orga nization, and tests to verify its operation by means of simulation. A Hardware Description Language (HDL) is a standard text-based expression of the temporal behavior and/or (spatial) circuit structure of an electronic system. In contrast to a software programming language, an HDLs syntax and semantics include explicit notations for expressing time and concurrency which are the primary attributes of hardware.

2.6 Testbench
It refers to simulation code used to create a predetermined input sequence to a design, then optionally to observe the response. 8

2.7 Simulation
A computer simulation, a computer model or a computational model is a computer program, or network of computers, that attempts to simulate an abstract model of a particular system.

2.8 Functional Verification

Functional verification, in electronic design automation, is the task of verifying that the logic design conforms to specification.

2.9 RTL
In integrated circuit design, Register Transfer Level (RTL) description is a way of describing the operation of a synchronous digital circuit. In RTL design, a circuit's behavior is defined in terms of the flow of signals (or transfer of data) between hardware registers, and the logical operations performed on those signals.

2.10 EDA (Electronic Design Automation)

It is the category of tools for designing and producing electronic systems ranging from printed circuit boards (PCBs) to integrated circuits.

2.11 RDB (Register Data Base)

It is used for automated support for the stages of cores development and enables rapid generation of documentation.

3. Simulation Environment
It is the environment developed for designing and verifying various chips by writing testbenches. The main philosophy behind the bench is to create an environment that provides the needed flexibility for a large-scale integration effort. The project is based on the environment used for the design and the verification of the Digital Video Chips used in LCD TVs and Set Top Boxes.

The various features of the simulation environment are: Adding the universal use of RDB to program registers, Providing infrastructure to support writing tests that can be merged with other tests for end-to-end functional testing, Providing an infrastructure and methodology for writing tests in such a manner that they can be easily promoted from the core level to the top level for whole chip testing.

A uniform arbitrated host access method is included that operates independent of host controller selection and allows programming threads to be seamlessly interleaved with no intervention on behalf of the test developer. Testbench models are able to be optionally accessed by using a transaction based protocol that allows for model documentation in RDB, arbitration for all shared resources, and ability to control models via transactions from C based tests. Memory allocation tasks are also available so simulation threads can dynamically allocate a buffer in DRAM to ensure that a particular thread does not collide with another execution thread when tests are later combined for end-to-end testing.

10

3.1 Environment Hierarchy

The simulation environment is based on UNIX platform. Following is the hierarchy of the directories of this environment. The environment is developed in such a manner that every developer can work on the same project without interfering with any other developer. Each user works in his own area allotted to him. When the task he is working on, is tested and verified, he releases the final copy into the main area which can be accessed by everyone else. If something goes wrong, the environment offers the facility of retrieving the older view. The environment takes snapshots of the phases of the design and stores it, so that one can go back and start from there, in case some new design poses problems or does not meet the anticipated results.

Project_1

snapshot gallery

work

cvsroot repository

$USER

Project_1

Project_1

Project_1

design

sim

design

sim

design

sim

Figure 1 Hierarchy of the Simulation Environment

11

3.2 Snapshot
The gallery is the public view of the design. It is regressed before being released into the public view, so there is always a stable set of files available for simulation. The gallery does not necessarily contain the latest release of a file; it rather contains the latest release of a working set of files. The gallery is kept at /projects/<CHIP>/<REV>/snapshot/<chip_rev>.

3.3 Work
Each user will have a work directory at /projects/<CHIP>/<REV>/work/$USER. The chip project will be checked out in this directory using a tool called treeconfig. Every user will have the same directory structure for their work directory: /projects/<CHIP>/<REV>/work/$USER/<chip_rev>.

3.4 Hierarchy of the sim directory

sim

test_lib

logs

global

Makefile

waves

<test_group>

sample_tests

bench

vlib

cmdapi

clib

include

Figure 2 Hierarchy of the sim Directory

12

The sim directory is the cockpit of the simulation environment. From the sim directory, the user will launch tests, examine waveforms, and verify the logfile results. The tests themselves are stored in a test library located under <chip_rev>/sim/test_lib.

Waveforms are recorded in the <chip_rev>/sim/waves directory, and logfiles are recorded in the <chip_rev>/sim/logs directory.

The sim directory also contains the project Makefile that is used by the bcsim script. The Makefile includes other makefile in the <chip_rev>/lib/make directory (chip_path.mk, analog_path.mk and testbench_path.mk etc).

Verilog bench files are kept in <chip_rev>/sim/global/bench and bench library in globa/vlib, cmd_api.

Project specified TB-C library are kept in <chip_rev>/sim/global/clib and global/include.

The test_lib directory stores a library of test groups. Each test group requires a core specific name, generally <core>_tests. However, some cores may need multiple test groups, in which case it is permissible to have <core>_<test type 1>_tests and <core>_<test type n>_tests directories.

13

4. bcsim Simulation Script

bcsim is a simulation script designed to run the NC-Verilog tools (ncvlog, ncelab, ncsim, etc.) in a design environment that uses UNIX make to handle builds. Here are it's major features: BCU 1.0 C/C++/System Verilog environment support Handles C build, HDL Build (Verilog or VHDL) and invocation of all Cadence NC tools needed to run simulation All sims may be run from a single directory (usually the sim/ directory). Simulations can be run from testcode directory with all output going to local directory Multiple simulations with different configurations can be run from the same directory simultaneously. An arbitrary number of sims can use the same elaboration snapshot. Default operation is to simulate RTL. Gate, stub or other representations of a block can be swapped using command line options or globally specified, predefined configurations. SDF simulation is supported. Waveform (fsbd) and power activity is activated using command line plusargs. TB2.0 C/C++/Verilog support for legacy cores.

14

4.1 How is bcsim used?

Basic bcsim operation for User's and Developers When bcsim is invoked, this is what it does: 1. Reads in command line args 2. Reads one configuration file 3. Configures the test environment based on the command line options and the configuration file(s). 4. Calls gmake to build various files: 1. Compiles and links any C code 2. Prepares the chip for compile. Normally this generates a verilog file list for all of the files that make up the chip using another script called vf. 3. Compiles the chip. This normally calls ncvlog -f using the verilog file list. 4. Prepares the test bench for compile. Normally this generates a verilog file list for all of the files that make up the test using vf. This can be skipped and a static vf_file list can be specified that allows for variable expansion and argument parsing. 5. Calls gmake to compile the test. 5. Elaborates the test. 6. Runs the simulation. 7. All info is provided in a single log file separated into chapters for easy viewing and parsing using a log file filter program such as chklogs. 8. Reports are consolidated in a single report file separated into chapters for easy viewing. Reporting functionality is fairly new, at this point, the only report that is generated is a setup/hold violation summary report that is automatically generated when an sdf gate sim is run.

15

Command: bcsim -cfg xyz test_lib/xyz_test/tb_reg.c

bcsim Perl Script Setup and Configuration 1. Read and check command line options 2. Open log file 3. Search for configuration file(s) 4. Read configuration file(s) 5. Configure environment based on 1-4 log file Command Used Configuration info Compile Log Compile Chip and Test HDL/C 1. Creates database directory and starts populating with setup files 2. Optional prebuilds, makedirs and other setup operations 3. C Setup, C build and C link using gmake 4. Generate verilog/vhdl file lists using gmake 5. Compile verilog/vhdl files using gmake 6. Elaborate Entire Design and write snapshot Elaborate Log NCSIM HDL log C simulation log

Configuration FIle (bcsim.cfg)

Makefile sim/Makefile
lib/make/proj.mk lib/make/tb_c.mk lib/make/ncsim.mk

Database Directory file lists bcsim output configuration files

Vf Perl Script

Simulate Invoke C/HDL Simulator

File-listing Input
Directories from proj.mk File lists from vf_lists/

Cleanup 1. Remove temporary files 2. Close log file 3. Kill processes 4. Report run-time stats

NC setup files NC simulation binary

Figure 3 bcsim operation Flow diagram

The primary bcsim output is a log file that contains configuration, compile, elaboration, HDL simulation and C simulation information. The C log information may be separated from the rest of the log for more concise test bench error reporting.

16

5. The C Model
The C model imitates the functional behavioral of the chip under design. It contains the same sub blocks as of the intended chip would have. It is much faster in generating output values from a c model than the simulation environment. It has some major disadvantages though, like it does not imitate the concurrent behavior of elements in the model under design which is inherent characteristic of the actual hardware. C model is basically used for functional verification of the design. Outputs generated from the C model and simulation outputs are compared and verification is carried out.

6. What is Motion Blur?

LCDs essentially hold the current image for a little long as compared to conventional CRTs. We refer to this as a zero-hold-characteristic. CRTs, on the other hand, work by exciting phosphors which emit light but do so for only short impulsive duration which quickly decays back to darkness.

Figure 4 Response of CRT vs LCD

Due to zero-hold-characteristic of LCDs, the phenomenon of motion blur occurs. Above figure illustrates this concept. The dotted portion indicates the smearing of the image. One can think of this as a continuous version of the case of ghosting. The following module is being developed in order to tackle this problem of motion blur. Writing the codes for the capture and feeder blocks initial was part of my project. The details of the 17

blocks being the confidential property of Broadcom, can not be disclosed, but logic implemented by me has been stated in this report.

32 bit bus Video signal In First Motion Blur Reduction Block Capture Block Feeder Block Second Motion Blur Reduction Block Digital video Formatting Block

Video signal Out In standard format to Television Set

Figure 5 DVI module to reduce motion blur in LCD TV set

7. Logic Beneath Capture and Feeder Block

The function of the Capture block is to compress the data and send it over the transmission bus and Feeder block at the other end of the bus decompresses the data and retrieves the original data.

Lets first find why is it important to compress the data. Consider, an analogical example. Say, a school having 5 sections each with 40 students is organizing a trip. Management has to hire buses for them all. Given that each bus a maximum capacity of 50 people, if management thinks of hiring one bus for each section, 5 buses will be required to accommodate all the students. Though, as it can be easily pointed out that if management hires only 4 buses and properly divides students in the group of 50 each, all students can be accommodated with maximum efficiency. The only concern before the management would be to ensure that after reaching at the destinations, all students would be able to be grouped back according to sections.

Similar concept of the bus has been used in data transfer inside electronic devices. Here, in the set top box chip, for which the above mentioned modules will be used, a 32-bitwide bus is used for the data transfer. The bus is shared between various components of the chip, on time sharing basis. Its programmers responsibility to make optimal use of 18

the bus and make it available to other blocks as soon as possible for their operation. The constraint before me was to reduce the number of cycles required during the transmission of 30 bit data or 18 bit data, without losing the sequence of data or any part of the data itself.

The data available is either 30 bit (for full band width mode) or 18 bit (for reduced band width mode). The bus available is a 32 bit wide bus. So mathematically speaking, for every 30 bit or 18 bit data packet sent over the bus, we used to waste 2 bits (32-30) or 14 bits (32-18) respectively. For a typical sample of 4,80,000 data packets each of width 30 bits, when sent over 32-bit-wide bus, the code written under this project could save 6.25% of machine cycles. In case of 18 bit data of same sample size, 43.75% of the machine cycles required during data transmission can be saved.

19

7.1. 30 bit data compression

In order to make a single 32 bit data packet, we need data from two consecutive 30 bit data packets. The number of bits to be taken from first packet and second packet keep on varying. There are following combinations possible.

32-bit-data packet serial number 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

No of bits from nth sample 30 28 26 24 22 20 18 16 14 12 10 08 06 04 02 30 28 26 24

No of bits from (n+1)th sample 02 04 06 08 10 12 14 16 18 20 22 24 26 28 30 02 04 06 08

n and n+1 01 & 02 02 & 03 03 & 04 04 & 05 05 & 06 06 & 07 07 & 08 08 & 09 09 & 10 10 & 11 11 & 12 12 & 13 13 & 14 14 & 15 15 & 16 17 & 18 18 & 19 19 & 20 20 & 21

20

7.2. 18 bit data compression

In case of compressing 18 bit data so as to send it on 32 bit bus, the logic gets more complicated as in order to form a 32 bit data packet, data bits are required to be fetched from three consecutive 18 bits data packets, unlike 30 bit case, which required the data to be fetched from only two data packets.

32-bit-data packet number 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

No of bits from nth sample 18 04 08 12 16 02 16 10 14 18 04 08 12 16 02 06 10 14 18

No of bits from (n+1)th sample 14 18 18 18 16 18 18 18 18 14 18 18 18 16 18 18 18 18 14

No of bits from (n+2)th sample 00 10 06 02 00 12 08 04 00 00 10 06 02 00 12 08 04 00 00

n, n+1 and n+2 01 & 02 02 & 03 & 04 04 & 05 & 06 06 & 07 & 08 08 & 09 09 & 10 & 11 11 & 12 & 13 13 & 14 & 15 15 & 16 17 & 18 18 & 19 & 20 20 & 21 & 22 22 & 23 & 24 24 & 25 25 & 26 & 27 27 & 28 & 29 29 & 30 & 31 31 & 32 33 & 34

The data compressed is sent over the 32-bit-wide bus. At the receiver end, it has to be again obtained back in the original form. This task is accomplished by feeder function which behaves in inverse manner of capture block. 21

8. Automation of C model Invocation

The main objective of this project is to automate the process of the C model invoking.

8.1 Need of automation

C model imitates the behavior of the chip design but can not show the concurrency in nature of the blocks of the design. That is why, we go for simulation. Previously, after the simulation was run, the log file used to be taken and the register values used to be extracted from it manually. Thereafter, someone would write cfg (configuration) file and then the C model would be run manually with src file and cfg file as its inputs. Later, someone would manually compare the output of the files generated from C model and RTL simulation. It was time consuming as a normal simulation can take more than 6 hours to dump (RTL engineers term for generating outputs) the desired outputs. As far as time consumed and manpower used was concerned, this method was quite inefficient.

8.2 Constraints
C model was a separate single entity and was manually run like any other normal C project via a Makefile. For the automatic operation, call was supposed to be made from the simulation environment to C model, so the entire C model was required to be migrated from its normal position to somewhere in the simulation environment, wherefrom it could be accessed by other parts of the simulation environment. The scope of the project included the modification of the Simulation environment itself which is used for chip designing. The other constraint was to obtain the outputs of the C model, which is the C-Side into Verilog-Side of the environment. The outputs were to be checked on generation of each output packet from the simulation environment as the C model would be available much before the simulation dumped its outputs.

22

8.3 Working of C Model Automation

There are two sides of the simulation environment. One is C side and other one is verilog side. The automation task mainly dealt with communicating between the two.

The inputs required for the C model to run are the cfg file and the src file. cfg file is the configuration file which contains the paths of all the other files which are to be read as inputs and written as outputs. The modular structure of any system allows us to find the errors easily and debug thereafter. So, for a given design, outputs are generated from each of the separate block and is tested sequentially. The simulation is run with bsub utility on UNIX platform. bsub is short for submission of batch job to LSF i.e. Load Sharing Facility. The job is submitted to the queue and server runs it. The documentation for the entire simulation is dumped in the log. The log file keeps on getting written during the run time of the simulation. The outputs are generated in area specified by the programs. A typical bsub command would look like this:

bsub -q blr-M4dv -R opteron bcsim test_lib/bvn_tests/vec_tests/tb_480p_dvip_656b_bvb_input/tb_480p_dvip_656b_bvb_inp ut.c test_lib/bvn_tests/vec_tests/common/sys.v -d use_vdecs_top_stub -d TB_FUNCTIONAL_TEST_MODE_0 -d use_vdec_pri_stub -d use_vdec_sec_stub -stub all -nostub video_encoder -d norammessages -chiptop video_encoder -d TB_CORE_HAS_RBUS_INTERFACE -d TB_CMD_API_HOST_IS_GISB -d VEC_BENCH -d CORE_BENCH -d DUMP_DVI_MOD_DATA -d COMPARE_C +dump_all -q blr-M4dv specifies the server queue to which one wishes the job to be submitted bcsim is the script that takes care of the entire simulation test_lib//sys.v and test_lib/./*.c are the testbench files with their complete addresses. 23

-d specifies various arguments which determine the modes in which the simulation is to be run in. -d COMPARE_C option was added under this project which invokes the C model automatically and starts the comparison between C model output and simulation output. Typically a simulation would run for 5-6 hours on the main server and dump the output files all throughout this span. +dump_all is the option that enables you to actually view the timing diagrams of simulation on a waveform viewer Simvision which is an integrated part of the simulation environment.

The files and folders modified or written under this project are as follows.

FILENAME: PATH:

cap.c /projects/BCM3573/A0/work/abhijee/bcm3573_a0/sim/test_lib/bvn_tests/

vec_tests/common/c_model/cap.c DESCRIPTION: takes either 30 bit or 18 bit input and compresses the bits into 32 bit format in order to make it efficient while transferring the data over 32 bit wide bus

FOLDERNAME: c_model PATH: /projects/BCM3573/A0/work/abhijee/bcm3573_a0/sim/test_lib/bvn_tests/

vec_tests/common/c_model/ DESCRIPTION: it contains all the c model files all the src files that are generated during the simulation automatically are also stored in this area. All the cfg files which are generated during simulations automatically are also kept in this area

FOLDERNAME: rtl_output PATH: /projects/BCM3573/A0/work/abhijee/bcm3573_a0/sim/ppms/rtl_output

DESCRIPTION: the output files generated from simulation are now stored in this area instead of sim area which was the case previously 24

FOLDERNAME: rtl_output PATH: /projects/BCM3573/A0/work/abhijee/bcm3573_a0/sim/ppms/rtl_output

DESCRIPTION: the output files generated from C model are now stored in this area instead of sim area which was the case previously

FILENAME: PATH:

mbr_dvi_path.c /projects/BCM3573/A0/work/abhijee/bcm3573_a0/sim/test_lib/bvn_tests/

vec_tests/common/c_model/cap.c DESCRIPTION: it contains the function gen_cfg function which is responsible for the generation of cfg file during simulation for feeding it to C model. It also contains a function mbr_dvi_path which is called in order to run the entire c model from testname.c

FILENAMES:

bvn_dither_alg.c, dither_alg.c, mbr1.c, pairingNmux.c, utils.c, dtg.c,

mbr2.c, test_1ch_dither.c, dvfMBR.c, test_3ch_dither.c, csc.c PATH: /projects/BCM3573/A0/work/abhijee/bcm3573_a0/sim/test_lib/bvn_tests/

vec_tests/common/c_model/*.c DESCRIPTION: aforesaid files have been modified while translating the c model independence into simulation dependent behavior

FILENAME: PATH:

tb_480p_dvip_656b_bvb_input.c /projects/BCM3573/A0/work/abhijee/bcm3573_a0/sim/test_lib/bvn_tests/

vec_tests/tb_480p_dvip_656b_bvb_input/tb_480p_dvip_656b_bvb_input.c DESCRIPTION: sim_5 parallel thread is added which takes care of generating the cfg file and src file during simulation

25

FILENAME: PATH:

vec_model_inst.inc /projects/BCM3573/A0/work/abhijee/bcm3573_a0/sim/test_lib/bvn_tests/

vec_tests/common/vec_model_inst.inc DESCRIPTION: looks after the simulation outputs and starts comparing the C model output with the simulated one on each dvi_clk asserted high

FILENAME: PATH:

vec_init.c /projects/BCM3573/A0/work/abhijee/bcm3573_a0/sim/test_lib/bvn_tests/

vec_tests/common/vec_init.c DESCRIPTION: c_model files have been declared herein this file

FILENAME: PATH:

taskPaths.cfg /projects/BCM3573/A0/work/abhijee/bcm3573_a0/sim/test_lib/bvn_tests/

vec_tests/common/taskPaths.cfg DESCRIPTION: the c_model path is added is here so that it also gets compiled during simulation

FILENAME: PATH:

bcsim.cfg /projects/BCM3573/A0/work/abhijee/bcm3573_a0/sim/test_lib/bvn_tests/

vec_tests/tb_480p_dvip_656b_bvb_input/bcsim.cfg DESCRIPTION: following new simopts are added which are required during the generation of cfg file $simopts .= " +sample_count=450450"; $simopts .= " +pic_X_size=720"; $simopts .= " +pic_Y_size=480";

The details of these files can not be disclosed as it has become the part of Broadcoms Confidential Intellectual Property but the logic developed during this project is included in this report with due permission from Broadcom Authorities. 26

The following is the flow diagram for the automaton task.

Figure 6 Automation of C Model Invocation

When the simulation is run with d COMPARE_C option enabled, the simulation environment starts compiling the files of design specified. Then it executes the files in sequence. When testname.c (e.g.tb_480p_dvip_656b_bvb_input.c) file is executed. The newly added sim_5 (a parallel thread) starts execution. A parallel thread is something that runs concurrently with other thread, unlike the sequential nature of any normal C program block. Parallel thread sim_5 starts reading the log file which is continuously generated during the simulation. Environment dumps the register addresses and their values into the log file. As soon as sim_5 encounters a statement ALL VEC REGISTERS ARE PROGRAMMED in the log file, it opens a new file, called src file and writes the extracted the register settings into it from log file. Thereafter, sim_5 calls mbr_dvi_path.c file which generates a configuration file that is the input for the C model. Once the cfg file is generated, sim_5 makes the second call to mbr_dvi_path.c in order to start running of the C model. The C mdoel is much faster in comparison with the simulation and dumps the outputs in the predetermined area. This 27

was the running of C model and next task is to compare the C model outputs with simulated ones. The control now is on the Verilog side. A verilog file vec_model_inst.inc, which takes care of dumping outputs of the simulation comes into picture. It monitors the timing signals continuously. As soon as the simulation starts generating DVF output, which normally takes 30 minutes(appprox) , it copies the entire C model output into the memory allotted to verilog side. Then, it starts comparing each simulated output with corresponding C model output on every i_dvi_accept signal asserted high. The message saying whether the two samples matched or mismatched is sent to log files. This way the entire procedure is carried out.

28

9. Conclusion
The C model is always useful for testing architectural behavior and verifying the actual design outputs. It is easier to design C model and the outputs generated by it are also very fast in comparison with the simulated output. The outputs of the C model are compared with that of simulation and the design is verified. The manual comparison needed time and individual human resource. The automation of this task helps to minimize the element of possible human error. It also helps to maximize the efficiency of system. The manual operation is no more required in the process of running C model. The technical human resource can be used in some another critical task which needs attention.

References:
1. Digital Video and HDTV Algorithms and Interfaces by Charles Poynton 2. Video Demystified by Keith jack 3. www.wikipedia.org 4. DVT new testbench user guide 5. Programmable VEC architecture documentation 6. Broadcom Intranet

29