Automation of C model invocation through simulation to improve chip verification environment

8/14/2019 Automation of C model invocation through simulation to improve chip verification environment

1/29

1

A REPORT

ON

AUTOMATION OF C MODEL INVOCATIONTHROUGH SIMULATION TO IMPROVE THE CHIP

VERIFICATION ENVIRONMENT

BY

Name of the Student ID No.

UIKE ABHIJEET HIMMATRAO 2004P3PS108

AT

BROADCOM INDIA Pvt. Ltd., Bangalore

A Practice School-II station of

BIRLA INSTITUTE OF TECHNOLOGY AND SCIENCE,

PILANI

December, 2007


2/29

2

A REPORT

ON

AUTOMATION OF C MODEL INVOCATIONTHROUGH SIMULATION TO IMPROVE THE CHIP

VERIFICATION ENVIRONMENT

BY

Name of the Student ID No. Discipline

UIKE ABHIJEET HIMMATRAO 2004P3PS108 BE (EEE)

Prepared in partial fulfillment of thePractice School-II Course

BITS GC413

AT

BROADCOM INDIA Pvt. Ltd., Bangalore

A Practice School-II station of

BIRLA INSTITUTE OF TECHNOLOGY AND SCIENCE,

PILANIDecember, 2007


3/29

3

BIRLA INSTITUTE OF TECHNOLOGY AND SCIENCE, PILANIPractice School Division

Station: Broadcom India Pvt. Ltd. Centre: Bangalore

Duration: 5 months Date of Start: 4th

July, 2007Date of Submission: 14thDec, 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 Designation: Senior Staff, IC Design

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

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 Date


4/29

4

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.


5/29

5

BIRLA INSTITUTE OF TECHNOLOGY AND SCIENCE

PILANI

PRACTICE SCHOOL DIVISION

Response Opti on sheet

Station :Broadcom India Pvt. Ltd. Centre :Bangalore

ID No. & Name:2004P3PS108 UIKE ABHIJEET HIMMATRAO

Title of the Project:AUTOMATION OF C MODEL INVOCATION THROUGH

SIMULATION TO IMPROVE THE CHIP VERIFICATION ENVIRONMENT

Code No. Response Options Course No.(s) & Name

1. A new course can be designed out of this project NO

2. The project can help modification of the course

content of some of the existing Courses

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 above-

mentioned options as it relates to the professional

work of the host organization.

YES

Signature of Student Signature of Faculty


6/29

6

TABLE OF CONTENTS

Acknowledgements..4

1. Introduction ..................................................................................................................... 72. Basic Definitions and Terms used .................................................................................. 8

2.1 Set Top Box .............................................................................................................. 8

2.2 LCD (Liquid Crystal Display) .................................................................................. 82.3 Motion Blur ............................................................................................................... 82.4 ASIC (Application Specific Integrated Circuit) ....................................................... 82.5 HDL (Hardware Descriptive Language) ................................................................... 82.6 Testbench .................................................................................................................. 82.7 Simulation ................................................................................................................. 92.8 Functional Verification ............................................................................................. 92.9 RTL ........................................................................................................................... 92.10 EDA (Electronic Design Automation) .................................................................... 92.11 RDB (Register Data Base) ...................................................................................... 9

3. Simulation Environment ............................................................................................... 10

3.1 Environment Hierarchy ........................................................................................... 113.2 Snapshot .................................................................................................................. 123.3 Work ....................................................................................................................... 123.4 Hierarchy of the sim directory ................................................................................ 12

4. bcsimSimulation Script ................................................................................................ 144.1 How is bcsimused? ................................................................................................. 15

5. The C Model ................................................................................................................. 176. What is Motion Blur?.................................................................................................... 177. Logic Beneath Capture and Feeder Block .................................................................... 18

7.1. 30 bit data compression ........................................................................................ 207.2. 18 bit data compression ......................................................................................... 21

8. Automation of C model Invocation .............................................................................. 228.1 Need of automation ................................................................................................. 228.2 Constraints .............................................................................................................. 228.3 Working of C Model Automation ........................................................................... 23

9. Conclusion .................................................................................................................... 29References: ........................................................................................................................ 29


7/29

7

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.


8/29

8

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.


9/29

9

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.


10/29

10

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 optionallyaccessed 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.


11/29

11

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.

snapshotgallery

work cvsroot

repository

$USER

design sim

Project_1

design simdesign sim

Project_1 Project_1

Project_1

snapshotgallery

work cvsroot

repository

$USER

design sim

Project_1

design simdesign sim

Project_1 Project_1

Project_1

Figure 1 Hierarchy of the Simulation Environment


12/29

12

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///snapshot/.

3.3 Work

Each user will have a work directory at /projects///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///work/$USER/.

3.4 Hierarchy of the sim directory

test_lib logs global waves

sim

sample_tests bench vlib cmdapi

Makefile

clib include

Figure 2 Hierarchy of the sim Directory


13/29

13

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 /sim/test_lib.

Waveforms are recorded in the /sim/waves directory, and logfiles are

recorded in the /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 /lib/make directory (chip_path.mk,

analog_path.mk and testbench_path.mk etc).

Verilog bench files are kept in /sim/global/bench and bench library in

globa/vlib, cmd_api.

Project specified TB-C library are kept in /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 _tests. However, some cores may need multiple test

groups, in which case it is permissible to have __tests and

__tests directories.


14/29

14

4. bcsimSimulation 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 samedirectory 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.


15/29

15

4.1 How is bcsimused?

Basic bcsim operation for User's and Developers

When bcsim is invoked, this is what it does:

1. Reads in command line args2. Reads one configuration file3. 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 code2. 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 viewingand parsing using a log file filter program such as chklogs.

8. Reports are consolidated in a single report file separated into chapters for easyviewing. 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.


16/29

16

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

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

Simulate

Invoke C/HDL Simulator

Cleanup1. Remove temporary files

2. Close log file

3. Kill processes

4. Report run-time stats

Configuration

FIle

(bcsim.cfg)

Makefile

sim/Makefile

lib/make/proj.mk

lib/make/ncsim.mk

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

log file

Command Used

Configuration info

Compile Log

Elaborate Log

NCSIM HDL log

C simulation log

Vf

Perl Script

Database

Directory

file lists

bcsim output

configuration files

NC setup files

NC simulation

binary

lib/make/tb_c.mk

File-listing Input

File lists from

vf_lists/

Directories from

proj.mk

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.


17/29

17

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


18/29

18

blocks being the confidential property of Broadcom, can not be disclosed, but logic

implemented by me has been stated in this report.

First Motion Blur

Reduction BlockCapture Block

Second Motion Blur

Reduction Block

Digital video

Formatting BlockFeeder Block

32 bit bus

Video signal In

Video signal Out

In standard format

to Television Set

First Motion Blur

Reduction BlockCapture Block

Second Motion Blur

Reduction Block

Digital video

Formatting BlockFeeder Block

32 bit bus

Video signal In

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-bit-

wide 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


19/29

19

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.


20/29

20

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

No of bits from

nth sample

No of bits from

(n+1)th samplen and n+1

01 30 02 01 & 02

02 28 04 02 & 03

03 26 06 03 & 04

04 24 08 04 & 05

05 22 10 05 & 06

06 20 12 06 & 07

07 18 14 07 & 08

08 16 16 08 & 09

09 14 18 09 & 10

10 12 20 10 & 11

11 10 22 11 & 12

12 08 24 12 & 13

13 06 26 13 & 14

14 04 28 14 & 15

15 02 30 15 & 16

16 30 02 17 & 18

17 28 04 18 & 19

18 26 06 19 & 20

19 24 08 20 & 21


21/29

21

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

No of bits from

nth sample

No of bits from

(n+1)th sample

No of bits from

(n+2)th sample

n, n+1 and

n+2

01 18 14 00 01 & 02

02 04 18 10 02 & 03 & 04

03 08 18 06 04 & 05 & 06

04 12 18 02 06 & 07 & 08

05 16 16 00 08 & 09

06 02 18 12 09 & 10 & 11

07 16 18 08 11 & 12 & 13

08 10 18 04 13 & 14 & 15

09 14 18 00 15 & 16

10 18 14 00 17 & 18

11 04 18 10 18 & 19 & 20

12 08 18 06 20 & 21 & 22

13 12 18 02 22 & 23 & 24

14 16 16 00 24 & 25

15 02 18 12 25 & 26 & 27

16 06 18 08 27 & 28 & 29

17 10 18 04 29 & 30 & 31

18 14 18 00 31 & 3219 18 14 00 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.


22/29

22

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 Cmodel would be available much before the simulation dumped its outputs.


23/29

23

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 -dTB_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.


24/29

24

-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: cap.c

PATH: /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


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


25/29

25

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: mbr_dvi_path.c


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


vec_tests/common/c_model/*.c

DESCRIPTION:

aforesaid files have been modified while translating the c model independence into

simulation dependent behavior

FILENAME: tb_480p_dvip_656b_bvb_input.c


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


26/29

26

FILENAME: vec_model_inst.inc


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: vec_init.c


vec_tests/common/vec_init.c

DESCRIPTION:

c_model files have been declared herein this file

FILENAME: taskPaths.cfg


vec_tests/common/taskPaths.cfg

DESCRIPTION:

the c_model path is added is here so that it also gets compiled during simulation

FILENAME: bcsim.cfg


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.


27/29

27

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


28/29

28

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.


29/29

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 Poynton2. Video Demystified by Keith jack

3. www.wikipedia.org

4. DVT new testbench user guide

5. Programmable VEC architecture documentation

6. Broadcom Intranet

Automation of C model invocation through simulation to improve chip verification environment

Documents

Transcript of Automation of C model invocation through simulation to improve chip verification environment