WO2013017037A1

WO2013017037A1 - Method and system for verifying soc chip

Info

Publication number: WO2013017037A1
Application number: PCT/CN2012/079225
Authority: WO
Inventors: 李新辉
Original assignee: 炬力集成电路设计有限公司
Priority date: 2011-07-29
Filing date: 2012-07-26
Publication date: 2013-02-07
Also published as: WO2013016979A1; CN102902834A; CN102902834B

Abstract

The present invention is applicable in the technical field of chip. Provided in embodiments of the present invention is a method for verifying an SOC chip. The method comprises the following steps: loading a testing procedure; scheduling a corresponding system function from a system interface function library on the basis of the testing procedure, and generating a random event on the basis of the system function and of a maintenance list corresponding to the system function; and verifying the test-awaiting SOC chip on the basis of the random event. The present invention allows the testing procedure compiled by a software engineer to run directly on an existing verification platform, thereby implementing co-verification of software and hardware, while at the same time packages low-level information, thus allowing for convenient use and reuse of verification system.

Description

Method and system for verifying SOC chip

Technical field

The invention belongs to the technical field of chips, and in particular relates to a verification method and system for a SOC chip.

Background technique

After the chip design is completed, verification is required. The main task of verification is to verify the correctness of the design and determine whether the chip meets all design specifications.

The traditional verification method is direct vector test (direct vector Test), direct vector test is a kind of signal level verification. It communicates with the chip to be verified directly at the signal level by creating a fixed scene excitation, and verifies the function of the chip by checking the value and change of the chip pin signal. This verification method requires that the working scene of the chip must be designed in advance, and the verification personnel directly process the very low level signal level information. With this verification method, the verification personnel have a large workload, and some accident scenarios and error handling scenarios cannot be considered and verified one by one, resulting in incomplete verification. When the chip is more complicated and the scale is larger, the verification method of the direct vector test has basically no verification capability. Because it is the signal level verification, the verification platform is directly related to the interface protocol of the chip. The verification platform is very poorly reusable. The original verification platform cannot be reused when the chip is replaced, and a new verification platform must be rebuilt.

In order to overcome the shortcomings of traditional verification methods, the development trend of chip verification is to improve the level of abstraction and perform transaction-level verification.

A representative transaction level verification method is a verification method manual (Verification) Methodology Manual, VMM). The architecture of the VMM verification system is shown in Figure 1. The verification generator operates the constraints in the configurator to constrain the generator to generate test transactions and implements online automatic comparison through an automatic comparator.

After using the VMM verification method, constrained random verification can be implemented (constrained random) Verification, randomization under set constraints to cover normal working scenarios and unexpected working scenarios; coverage driven verification Verification), when the function coverage rate and code coverage reach the target value, stop random verification; fully automatic online comparison, encounter error automatic alarm and stop simulation, save the scene; assertion-based verification (assertion) Based verification).

The VMM verification method realizes the transition of the verification method from the signal level to the transaction level, which facilitates the verification of the data path type chip. However, due to the complicated data interaction and control of the VMM verification method, the method for operating the chip to be verified is quite complicated for the multimedia chip, which is inconvenient to control the simulation process, has low ease of use, and cannot be verified because it cannot be added to the device driver. Complex application scenarios and upgrades to system level verification.

technical problem

The purpose of the embodiments of the present invention is to provide a verification method for a SOC chip, which aims to solve the problem that the prior art is complicated for verification and cannot verify complex application scenarios for the existing verification platform, and cannot implement software and hardware co-verification on the simulation system. The problem.

Technical solution

The embodiment of the present invention is implemented by the method for verifying a SOC chip, and the method includes the following steps:

Load the test program;

Generating a corresponding system function in the system interface function library according to the test program, and generating a random transaction according to the system function and the maintenance list corresponding to the system function;

The SOC chip to be tested is verified according to the random transaction.

An embodiment of the present invention further provides a verification system for a SOC chip, where the system includes:

a loader for loading the test program;

a random transaction generator, configured to invoke a corresponding system function in a system interface function library according to the test program loaded by the loader, and generate a random transaction according to the system function and a maintenance list corresponding to the system function;

And a verification unit, configured to perform verification on the SOC chip to be tested according to the random transaction generated by the random transaction generator.

Beneficial effect

In the embodiment of the present invention, the corresponding system function is called in the system interface function library by the loaded test program, and a random transaction is generated according to the system function and the maintenance list corresponding to the system function, and the SOC chip to be tested is verified according to the random transaction. The test program written by the software engineer can be directly run on the existing verification platform, the verification method is promoted to the system level verification, the software and hardware co-verification is realized, the verification of the complex application scenario is realized, and the low-level information is encapsulated. Makes the verification system easy to use and easy to reuse.

DRAWINGS

1 is a structural diagram of a prior art VMM verification platform provided by the present invention;

FIG. 2 is a flowchart of an implementation of a method for verifying a SOC chip according to Embodiment 1 of the present invention.

3 is a flowchart of a test program development provided by Embodiment 1 of the present invention;

4 is a flowchart of an implementation of a method for generating a random transaction according to Embodiment 2 of the present invention;

5 is a flowchart of an implementation of an example of generating a test transaction according to Embodiment 2 of the present invention;

6 is a flowchart of an implementation of a method for generating a random transaction according to Embodiment 3 of the present invention;

7 is a flowchart of an implementation of an implementation example of generating an IO operation transaction according to Embodiment 3 of the present invention;

8 is a flowchart of an implementation of a method for generating a random transaction according to Embodiment 4 of the present invention;

9 is a flowchart of an implementation of generating a random number or a random sequence provided by Embodiment 4 of the present invention;

10 is a verification structural diagram of a SOC chip according to Embodiment 5 of the present invention;

11 is a verification structural diagram of a SOC chip according to Embodiment 6 of the present invention;

12 is a verification structural diagram of a SOC chip according to Embodiment 7 of the present invention;

13 is a structural diagram of a random device configuration operation unit according to Embodiment 7 of the present invention;

14 is a structural diagram of a random IO operation unit according to Embodiment 7 of the present invention;

15 is a structural diagram of a random sequence operation unit according to Embodiment 7 of the present invention;

16 is a flowchart of a verification process of a SOC chip according to Embodiment 8 of the present invention.

Embodiments of the invention

The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It is understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

In the embodiment of the present invention, the corresponding system function is called in the system interface function library by using the loaded test program, and a random transaction is generated according to the system function and the maintenance list corresponding to the system function, and the SOC chip to be tested is performed according to the random transaction. verification.

In order to facilitate the description of the technical solution of the present invention, the following description will be made by way of specific embodiments:

Embodiment 1

FIG. 2 is a flowchart showing an implementation of a verification method of a SOC chip according to Embodiment 1 of the present invention, which is described in detail as follows:

In step S201, the test program is loaded.

In the embodiment of the present invention, the test program can implement the following functions:

(1) Control the flow of the verification system.

(2) Obtain and change the status of the verification system.

(3) Operate and access the chip to be tested.

(4) Generate random test transactions to test the chip.

(5) Other standard C/C++ operations.

In the embodiment of the present invention, the test program may be a driver or an application, for example, may include a main program and an interrupt service program, etc., wherein

1. The interrupt service routine can be a function of the form:

Int isr(int pid, int source, int Port); Any function with the above form can be registered with the system to become an interrupt service routine.

2. The way the interrupt service program is registered in the main test program can call the following functions:

Int register_isr(int pid, int port, isr_pt Isr);

The pid is the test device number, the port is the interrupt port number, and isr is the function to be registered. ? 3. The form of the interrupt can be divided into a soft interrupt and a hard interrupt. The "hardware", that is, the interrupt issued by the SOC chip to be tested is called "hard interrupt", and the test program can also issue an interrupt to the system, which is called "soft interrupt".

A soft interrupt is issued by calling the following function:

Assert_irq(int pid, int source_id, int port_id)

Where pid is the test device number, source_id is the interrupt source number, used to indicate the identity of the caller, and port_id is the interrupt port number.

In the embodiment of the present invention, there may be multiple test programs, and the test program may be a standard c/c++ program. In this case, a standard c/c++ compiler may be used, and the test program may exist in the form of a test library. For example, it can be compiled into a test library file by gcc, etc. The development process of the test library can adopt the development process shown in Figure 3. In the development process, according to the c/c++ library file, the test main program and the interrupt service program are respectively developed, and the test main program and the interrupt service program are compiled by gcc. As a target file, all target files are packaged to generate a test library.

In the embodiment of the present invention, a direct programming interface (Direct Programming Interface) , DPI) load test program, through the DPI interface, C / C + + program can call EDA (Electronic design Automation) language domain functions, and EDA language domain can also call C / C + + language domain functions, when the test program contains the main program and interrupt service program, the DPI interface can also have two corresponding, corresponding to the main program and interrupt Service program.

In step S202, the corresponding system function is called in the system interface function library according to the test program, and a random transaction is generated according to the system function and the maintenance list corresponding to the system function.

In an embodiment of the invention, the random transaction may include a random test transaction, a random IO operation transaction, and/or a random sequence operation transaction.

In the embodiment of the present invention, a corresponding system function is invoked in a system function library, and the system function may specifically include any combination of a control function, an event function, an IO function, a semaphore function, a shared data function, a thread function, or a randomization function. ,among them:

(1) Control function

The control function is used to control the operation of the verification system, such as suspending the simulation, continuing the simulation, obtaining the simulation time, obtaining the current state of the simulation system, changing the system state, etc., specifically:

Sim_finish();// End simulation

Sim_stop();//Pause simulation

Double get_time(); //Get the current simulation time

(2) event function

The event function is used to test the synchronization between threads, where the occurrence or synchronization of the event will operate on the corresponding event list.

Int event_create();// Create an event list item, return the event number

Void event_trigger(int event_id);// Trigger event, usually triggered after a simulation condition occurs

Void event_sync(int event_id, int sync_type);// Synchronize to an event, blocking the thread before the event occurs

(3) semaphore function

The semaphore function is used to access protected resources, and the semaphore list is manipulated when the semaphore is manipulated.

Int semaphore_create(int key_count);// Create a semaphore entry and return the semaphore number

Void semaphore_get(int semaphore_id, int Key_count);// Request semaphore, if the signal is insufficient, block until there is enough semaphore. Apply before accessing resources.

Void semaphore_put(int semaphore_id, int Key_count);// Release the semaphore, after the resource is accessed, the semaphore should be released to enable other threads to access the resource.

(4) IO function

The IO function is used to directly access the function of the SOC chip to be tested through the port address of the device. When multi-threading is supported, synchronization between IO operations is also required to ensure that their execution order is correct. This order is from the IO list. Assured, the IO operation at the head of the list is completed first, and the subsequent operations are followed by the following IO function operation functions:

Void io_write(int pid, int address, int op_size, Int data, int mask); // write device

Int io_read(int pid, int address, int op_size); // Read device

Void io_burst_write(int pid, int address, int Op_size, int burst_type, int *data, int *mask); // write the device in bursts

Void io_burst_read(int pid, int address, int Op_size, int burst_type, int *data) ;// read the device in burst mode

Void io_random_transfer(int pid, int start_address, Int end_address, int op_size, int op, int burst_type, int ntests); Random access to the device

(5) shared data function

When data sharing between threads of the test program is required, the shared data function places the shared data in a common data list for use by each thread.

Void scfg_create_reg(char *reg_name, int Init_value); // Create an entry

Void scfg_set_reg(char *reg_name, int value);// Set up a shared item

Int scfg_get_reg(char *reg_name);// Read a shared item

Void scfg_wait_reg(char *reg_name, int exp_value, Int mask);// Wait until the value of the shared item is the specified value

Void scfg_wait_reg_created(char *reg_name); // Wait until the shared item is created

Void scfg_wait_reg_write(char *reg_name); // Wait until the value of the shared item is set

Void scfg_wait_reg_read(char *reg_name); // Wait until the value of the shared item is read

Void scfg_wait_reg_change(char *reg_name); // Wait until the value of the shared item changes

Void scfg_wait_reg_not(char *reg_name, int Exp_value, int mask); // wait until the value of the shared item is not the specified value

Void scfg_wait_reg_less(char *reg_name, int Exp_value);// Wait until the value of the shared item is less than the specified value

Void scfg_wait_reg_larger(char *reg_name, int Exp_value);// Wait until the value of the shared item is greater than the specified value

(6) Thread function

Thread functions are used to generate multiple threads, and can be synchronized, canceled, etc. between threads. The thread list holds the currently executing threads and their state.

Int io_fork (int (*io_func)(), int total_args, ...); // execute the function in parallel thread, return the thread number

Void io_sync(int schedule_id); // Synchronize, block until the specified number of threads finish

Void io_flush(int pid); //Sync, block until the specified master completes all IO operations

Void io_nop(int pid);//waiting the completion of the last IO operation of the specified master

Void delay_t(double delay_time);// The current thread is blocking a simulation time

Void delay_clock(int pid, int clock_cycles);// Current thread blocks for a certain clock cycle

Void sim_pause(int pause_id);// current thread paused

Void sim_resume(int pause_id); // Continue executing the suspended thread

(7) Randomization function

The randomization function is used to randomize the configuration of the SOC chip to be tested. When the randomization function is executed, on the one hand, the random function generates a random sequence and stores it in the random sequence table. On the one hand, the SOC chip configuration list to be tested is searched, and the corresponding waiting list is found. The SOC chip is tested and the corresponding SOC chip configuration to be tested is loaded, and the random constraint description therein is used to generate a random transaction.

Int randc(int max, int min);// From the range [min, Get a random integer that is not repeated in max]

Int randc_array(int *ResultArray, int ArraySize, Int max, int min);// Get ArraySize non-repeating random integers from the range [min, max]

Int randcase(weight_0, ...); // A branch is randomly taken from the subsequent branches, and the weights of the branches are weight_0, weight_1, ... weight_N.

Void cfg_rand_regs(int pid, char *cfg_name, ...);// Randomize the SOC chip registers to be tested to obtain random configuration values

Void cfg_set_rand_mask(int pid, char *cfg_name, Char *reg_name, int rand_mask);// Set a random mask for the SOC chip registers to be tested, ensuring that registers that do not need to be randomized retain the original values

Void cfg_flush_regs(int pid, char *cfg_name, char *reg_name...);// Write random random register values to the SOC chip (DUT) to be tested via the system bus

In the embodiment of the present invention, the maintenance list may include a plurality of different lists. Specifically, different system functions may correspond to different lists, for example, an event function corresponding event list, an IO function corresponding to an IO list, and a semaphore function corresponding signal. The quantity list, the shared data function corresponds to the general data list, the thread function corresponds to the thread list, the randomization function corresponds to the random sequence table and the SOC chip configuration list to be tested.

1. event table

The event list indicates that notification and synchronization are performed in the simulation system when an event that satisfies a certain condition occurs. When an event occurs somewhere in the simulation system, the event can be declared and placed in the event list, and the event can be executed as a trigger condition elsewhere in the simulation system. Each thread can manipulate events through event functions.

2. IO list (IO table)

Test program test The SOC chip to be tested may be realized by accessing the register of the SOC chip to be tested. The IO list maintains these operations in chronological order, realizes the synchronization of IO operations, ensures the legality of the operation, and also performs the test procedure. Synchronize.

The test program can access the SOC chip to be tested through the IO function.

3. Semaphore table

When multiple threads need to access the same resource, you need to guarantee the mutual exclusion of access. A semaphore is a way to guarantee mutual exclusion. Each resource corresponds to several semaphores; when a thread accesses a resource, it needs to apply for a semaphore first. If the semaphore is insufficient, the thread is blocked until a sufficient semaphore is obtained to unblock, access the resource, and finally release the semaphore to make the other Threads can access resources. Each thread can manipulate the semaphore through a semaphore function.

4. Universal data table (universal data table)

The common data list holds general-purpose data that can be shared by each thread of the simulation system, and each thread can access the common data through the shared data function.

5. Threaded list (scheduled thread table)

The test program can use the thread function to operate the thread. The test program can trigger multiple child threads that are executed at the same time. These thread threads are maintained through the thread list to ensure that the thread execution order is in accordance with expectations and is also controllable. For example, Other threads wait for a thread to complete, kill a thread, raise a child thread, and so on.

6. Random sequence table

The random sequence table is used to maintain the random sequence, so that the random sequence generation process is transparent to the test program, the programmer does not have to care about the specific implementation process, and the test program can obtain the random sequence through the randomization function.

7. SOC chip configuration list to be tested (device under test configuration Table),

The SOC chip configuration list to be tested saves all the SOC chip configuration files to be tested of the current system (device under Test configuration, A list of dut_cfg). Each dut_cfg file corresponds to a SOC chip to be tested. When the device under test is operated, the corresponding SOC chip to be tested is searched from the SOC chip configuration list to be tested and the corresponding SOC chip to be tested is configured to generate a random test transaction.

In step S103, the SOC chip to be tested is verified according to the random transaction described above.

In the embodiment of the present invention, the corresponding system function is called in the system interface function library by using the loaded test program, and a random transaction is generated according to the system function and the maintenance list corresponding to the system function, and the SOC chip to be tested is performed according to the random transaction. Verification enables test programs written by software engineers to run directly on existing verification platforms, enabling hardware and software co-verification, and by encapsulating low-level information, making the verification system easy to use and easy to reuse.

Embodiment 2

FIG. 4 is a flowchart showing an implementation of a method for generating a random transaction according to a system function and a maintenance list corresponding to a system function when a random transaction is a random test transaction according to Embodiment 2 of the present invention, which is described in detail as follows:

In step S401, in the SOC chip configuration list to be tested, the SOC chip configuration to be tested corresponding to the SOC chip to be tested is searched for.

In the embodiment of the present invention, each SOC chip to be tested has a SOC chip configuration to be tested, and the SOC chip configuration to be tested includes a register image of the SOC chip to be tested and a constraint expression of the SOC chip to be tested, and the register image specifically includes The name, address, bit width, default configuration value, current configuration value, and previous configuration value of the register, the constraint expression defines a range of random parameters of the SOC chip to be tested, specifically:

1. The register image of the device under test, including the register name, address, bit width, default value, previous configuration value, current configuration value, and so on.

2. The constraint expression of the SOC chip to be tested, the constraint expression defines the range of random parameters of the SOC chip to be tested, and these expressions will be satisfied when randomized. For example, the logical relationship between the current configuration and the previous configuration, the logical relationship that the two registers must satisfy, the legal range of the value of the register, and the like.

In step S402, a class object corresponding to the test transaction is generated according to the SOC chip configuration to be tested.

In the embodiment of the present invention, the register image and the constraint expression of the SOC chip to be tested are determined by the SOC chip configuration to be tested, and the class object corresponding to the test transaction is established according to the SOC chip configuration to be tested, and the register image and the constraint expression are set. As a member of a class object.

In step S403, the above-mentioned class objects are randomized.

In step S404, a test transaction is generated based on a random result of the class object.

For ease of understanding, the method of the embodiment of the present invention is described below with a specific implementation example, but is not limited to the implementation example. For details, refer to FIG. 5, when the system function is called, the SOC chip to be tested is searched for the SOC to be tested. The chip is loaded with the corresponding SOC chip configuration to be tested, and the register image and the constraint expression are obtained through the SOC chip configuration to be tested. The register image specifically includes the name, address, bit width, default value, current value, and front of the SOC chip register to be tested. First-value parameters and configuration constraint expressions, and set the properties of the class object, the above parameters and the data in the random sequence table are used as members of the pre-constructed class object, and the random method of the constraint server calling the class object randomly randomizes the class object. Solve the random result of the class object. After the class object is randomized, the result of the solution is combined to generate a test transaction. After the test transaction is generated, it is sent to the subsequent transaction processor, and then driven by the bus driver to the SOC chip to be tested.

In the embodiment of the present invention, at least one SOC chip configuration to be tested may be set according to the type of the device to be tested, and specifically may include a SOC chip configuration to be tested, a SOC chip configuration to be tested 2, a SOC chip configuration to be tested. N, where N is a natural number, and the value of the number N of SOC chip configurations to be tested may be determined according to actual needs, and is not limited to limit the present invention.

In the embodiment of the present invention, the random transaction is made transparent and automatic by the SOC chip configuration to be tested, and the test vector is not required to be considered when writing the test program, and it is not necessary to consider how the test vector is generated. Randomize randomized transactions to ensure random, comprehensive, and automated verification.

Embodiment 3

FIG. 6 is a flowchart showing an implementation of a method for generating a random transaction according to a system function and a maintenance list corresponding to a system function when a random transaction is a random IO operation transaction according to Embodiment 3 of the present invention, which is described in detail as follows:

In step S601, a random parameter that needs to be randomized in the random IO function is determined.

In step S602, the random value of the random parameter is generated in chronological order by the IO list.

In step S603, a random IO operation transaction is generated according to the random value of the random parameter.

For ease of understanding, the method of the embodiment of the present invention is described below with a specific implementation example, but is not limited to the implementation example. For details, refer to FIG. 7. When the random transaction is a random IO operation transaction, according to the parameters of the random IO function. , to determine which parameters can be random and which are fixed, wherein the random one can be the operation address, Operands, burst mode, operation mode, etc. Then, through the IO list, the address and address random mask, the operand and operand random mask, the operation mode and the operation mode random mask, and the burst mode and burst are taken out in chronological order. Mode mask, when random is required, call the system random function to obtain the random parameters such as address, operand, operation mode and burst mode.

Embodiment 4

FIG. 8 is a flowchart showing an implementation of a method for generating a random transaction according to a system function and a maintenance list corresponding to a system function when a random transaction is a random sequence operation transaction according to Embodiment 4 of the present invention, which is described in detail as follows:

In step S801, parameters of a random number or a random sequence required by the test program are determined.

In step S802, a random number or a random sequence required by the test program is calculated according to the random sequence table and the above parameters.

In step S803, the calculated random number or random sequence is returned to the test program and stored in the random sequence table.

For ease of understanding, the method of the embodiment of the present invention is described below with a specific implementation example, but is not limited to the implementation example. For details, please refer to FIG. 9. In this implementation example, the test program needs to obtain a random number that satisfies a specific condition. Or a sequence of random numbers. Calculate the qualified number or array to the test program based on the known values in the random sequence table, and the above parameters, including the known values, weights, and ranges in the called system function. It is saved in the random sequence table for the next time, and the time-critical item in the random sequence table can be deleted to keep the number of items in the random sequence table as a fixed value.

Embodiment 5

FIG. 10 shows the structure of a verification system of a SOC chip according to Embodiment 5 of the present invention, and for the sake of easy understanding, only the structure of the relevant portion is shown.

The structure of the system of the embodiment of the present invention specifically includes a loader 101, a random transaction generator 102, and a verification unit 103, where:

The loader 101 loads the test program.

In the embodiment of the present invention, the loader 101 loads the test program, and specifically loads and runs the test main program or the test interrupt service program in the test function library. When the SOC chip to be tested is not interrupted, the test main program is loaded. And running; and when the SOC chip to be tested issues an interrupt request, the interrupt service program is loaded and runs. At this time, the test main program is suspended and suspended, and the interrupt service program is executed, and after the execution of the interrupt service program is completed, the test main The program continues to execute.

The random transaction generator 102 calls a corresponding system function in the system interface function library according to the test program loaded by the loader 101, and generates a random transaction according to the system function and the maintenance list corresponding to the system function.

Based on the random transaction generated by the random transaction generator 102 described above, the verification unit 103 verifies the SOC chip to be tested.

When the random transaction is a random test transaction, the random transaction generator 102 includes a device lookup unit, a class object generation unit, a class object random unit, and a test transaction generation unit, specifically:

The device search unit searches for a SOC chip configuration to be tested corresponding to the SOC chip to be tested in the SOC chip configuration list to be tested.

In the embodiment of the present invention, the SOC chip to be tested includes a register image of the SOC chip to be tested and a constraint expression of the SOC chip to be tested, and the register image specifically includes a register name, an address, a bit width, and a default configuration value. The current configuration value and the previous configuration value, the constraint expression defines a range of random parameters of the SOC chip to be tested

The class object generating unit generates a class object corresponding to the test transaction according to the SOC chip configuration to be tested that is searched by the device search unit.

The class object random unit randomizes the class object generated by the class object generating unit.

The test transaction generation unit generates a test transaction according to the random result of the class object random unit on the class object.

When the random transaction is a random IO operation transaction, the random transaction generator 102 includes a random parameter determining unit, a random value generating unit, and an IO operation generating unit, specifically:

The random parameter determination unit determines a random parameter that needs to be randomized in the random IO function.

Through the IO list, the random value generating unit generates, in chronological order, the random parameter determining unit to determine a random value of the random parameter.

The IO operation generation unit generates a random IO operation transaction based on the random value of the random parameter generated by the random value generation unit.

When the random transaction is a random sequence operation transaction, the random transaction generator 102 includes a random sequence determining unit, a random sequence determining unit, a calculating unit, and a returning unit, specifically:

The random sequence determining unit determines a random number or a parameter of the random sequence required by the test program.

The calculation unit calculates a random number or a random sequence required by the test program according to the random sequence table and the parameters determined by the random sequence determining unit.

The return unit returns the random number or random sequence calculated by the calculation unit to the test program, and saves it in the random sequence table.

In the embodiment of the present invention, the test program is loaded by the loader, and the corresponding system function is called in the system interface function library, and a random transaction is generated according to the system function and the maintenance list corresponding to the system function, and the SOC is tested according to the random transaction. The chip is verified, so that the test program written by the software engineer can run directly on the existing verification platform, and the software and hardware co-verification is realized.

Embodiment 6

FIG. 11 shows the structure of a SOC chip verification system provided by Embodiment 6 of the present invention. For ease of understanding, only the structure of the relevant portion is shown.

In the embodiment of the present invention, a direct programming interface (Direct Programming Interface) , DPI) boot loader, and load the loaded test program into the simulation system, through the DPI interface, C / C + + program can call EDA (Electronic design Automation) A function of a language domain, and an EDA language domain can also call a function of a C/C++ language domain.

The test program may include a main program and an interrupt service program, and the DPI interface of the corresponding system may include a main program DPI interface 111 and an interrupt program DPI interface 112.

In the embodiment of the present invention, when the SOC chip to be tested is not interrupted, the test main program is executed, and when the SOC chip to be tested issues an interrupt request, the interrupt service program is executed, and when a plurality of interrupt requests arrive, the system may include an interrupt. The manager 114 performs priority management and interrupt nesting management.

Example 7

FIG. 12 shows the structure of a SOC chip verification system provided in Embodiment 7 of the present invention, and for the sake of easy understanding, only the structure of the relevant portion is shown.

The corresponding system function invoked by the random transaction generator in the system interface function library 125, the system function specifically includes: a control function, an event function, an IO function, a semaphore function, a shared data function, a thread function, or a randomization function.

The system function operates the corresponding maintenance list 126. The maintenance list includes: an event list, an IO list, a semaphore list, a general data list, a thread list, a random sequence table, and a SOC chip configuration list to be tested.

In the embodiment of the present invention, the random transaction generator 128 includes a random device configuration operation unit 1281, a random IO operation unit 1282, and/or a random sequence operation unit 1283.

13 shows that the random device configuration operation unit specifically includes a device lookup module 131, a class object generation module 132, a class object random module 133, and a test transaction generation module 134, wherein:

The device search module 131 searches the SOC chip configuration list 127 to be tested for the SOC chip configuration to be tested corresponding to the SOC chip to be tested, and loads the SOC chip configuration to be tested corresponding to the SOC chip to be tested.

In the embodiment of the present invention, the SOC chip configuration to be tested may include a register image of the SOC chip to be tested and a constraint expression of the SOC chip to be tested, where the register image specifically includes a register name, an address, a bit width, a default configuration value, and a current The configuration value and the previous configuration value, the constraint expression defines a range of random parameters of the SOC chip to be tested.

Based on the SOC chip configuration to be tested, which is searched by the device lookup module 131, the class object generation module 132 generates a class object corresponding to the test transaction.

The class object random module 133 randomizes the class object generated by the class object generation module 132 described above.

In the embodiment of the present invention, the class object random module 131 calls a random method of the corresponding class object, and randomizes the class object.

The test transaction generation module 134 generates a test transaction based on the random result of the class object random module 133 described above.

Figure 14 shows the specific structure of the above random IO operation unit:

The random parameter determination module 141 determines random parameters that need to be randomized in the random IO function.

The random value generation module 142 generates the random value of the random parameter by the random parameter determination module in chronological order by maintaining the IO list in the list 126.

Based on the random value of the random parameter generated by the random value generation module 142, the IO operation generation module 143 generates a random IO operation transaction.

Figure 15 shows the specific structure of the above random sequence operation unit:

The random sequence determination module 151 determines the random number or parameters of the random sequence required by the test program.

Based on the random sequence table in the maintenance list 126 and the parameters determined by the random sequence determination module 151, the calculation module 152 calculates the random number or random sequence required by the test program.

The return module 153 returns the random number or random sequence calculated by the calculation module to the test program and saves it in the random sequence table.

Example eight

FIG. 16 shows a verification process of the SOC chip provided in Embodiment 8 of the present invention:

(1) The hardware engineer designed the SOC chip to be tested (device under test, DUT), providing Register Transfer Level Code (RTL)

(2) The hardware engineer or the verification engineer extracts the device under test configuration (device under test configuration) to describe the device characteristics according to the hardware design specification. Dut_cfg).

(3) The verification engineer is ready to verify other components of the system, such as transaction processors, bus drivers, monitors, automatic comparators, etc., according to current popular verification methodology (eg, VMM).

(4) The verification engineer connects the above DUT, dut_cfg, the components of the present invention, and other components of the verification platform into a verification system.

(5) A verification engineer or software engineer prepares a test program written in c/c++ as a test file. For example, the test program can be a driver or an application.

(6) The verification engineer or software engineer will compile the test file into a test library file using the standard c/c++ compiler.

(7) The verification engineer compiles the verification system with the EDA simulator.

(8) The verification engineer runs the verification system with time as a random seed.

(9) After the simulation starts, the main controller loads the test library file into the verification system and runs it through the loader.

(10) During the verification system operation, hardware logic, performance, etc. may be found to be inconsistent with the definition of the hardware design specification. At this time, the automatic comparator suspends the verification system, records the random seed and exports the simulation waveform to the verification engineer. Hardware engineers can debug together; re-run the verification system with the same random seed to reproduce the defect scenario and facilitate debugging. After the hardware engineer changes the design, the verification engineer recompiles the verification system.

(11) If the hardware defect is not found during the verification system operation, verify that the system is running until the current test function is completed.

(12) After the current test function is completed, check the DUT code coverage.

(13) If the set coverage target is not reached, repeat the next random simulation from 8 to 12 steps until the code coverage reaches the predetermined target.

In summary, the embodiment of the present invention invokes a corresponding system function in the system interface function library by using the loaded test program, generates a random transaction according to the system function and the maintenance list corresponding to the system function, and treats according to the random transaction. Test the SOC chip for verification. The test program written by the software engineer can run directly on the existing verification platform, realizes the software and hardware co-verification, and at the same time, the low-level information is encapsulated, so that the verification system is convenient to use and easy to reuse.

In addition, through the SOC chip configuration to be tested, the random transaction is made transparent and automatic. It is not necessary to consider the coverage of the test vector when writing the test program, and it is not necessary to consider how the test vector is generated. Randomize randomized transactions to ensure random, comprehensive, and automated verification.

It should be noted that the units included in the above system are only divided according to functional logic, but are not limited to the above divisions, as long as the corresponding functions can be implemented; in addition, the specific names of the functional units are only for convenience. They are distinguished from each other and are not intended to limit the scope of protection of the present invention.

In addition, those skilled in the art can understand that all or part of the steps of implementing the foregoing embodiments may be performed by a program to instruct related hardware, and the corresponding program may be stored in a computer readable storage medium, as mentioned above. The storage medium may be a read only memory, a magnetic disk or an optical disk or the like.

The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the protection of the present invention. Within the scope.

Claims

A method for verifying a SOC chip, characterized in that the method comprises the following steps:

Load the test program;

Generating a corresponding system function in the system interface function library according to the test program, and generating a random transaction according to the system function and the maintenance list corresponding to the system function;

The SOC chip to be tested is verified according to the random transaction.
The method according to claim 1, wherein when the random transaction is a random test transaction, the step of generating a random transaction according to the system function and the maintenance list corresponding to the system function is specifically:

In the SOC chip configuration list to be tested, searching for a SOC chip configuration to be tested corresponding to the SOC chip to be tested;

Generating a class object corresponding to the test transaction according to the SOC chip configuration to be tested;

Randomizing the class objects;

A test transaction is generated based on a random result of the class object.
The method of claim 2, wherein the SOC chip configuration to be tested comprises a register image of the SOC chip to be tested and a constraint expression of the SOC chip to be tested, the register image specifically including a register name, an address, The bit width, the default configuration value, the current configuration value, and the previous configuration value, the constraint expression defines a range of random parameters of the SOC chip to be tested.
The method according to claim 1, wherein when the random transaction is a random IO operation transaction, the step of generating a random transaction according to the system function and the maintenance list corresponding to the system function is specifically:

Determining random parameters that need to be randomized in a random IO function;

Generating, by the IO list, random values of the random parameters in chronological order;

A random IO operation transaction is generated based on the random value of the random parameter.
The method according to claim 1, wherein when the random transaction is a random sequence operation transaction, the step of generating a random transaction according to the system function and the maintenance list corresponding to the system function is specifically:

Determining the parameters of the random number or random sequence required by the test program;

Calculating a random number or a random sequence required by the test program according to the random sequence table and the parameters;

The calculated random number or random sequence is returned to the test program and saved in the random sequence table.
The method of claim 1 wherein said test program comprises a test main program and a test interrupt service program;

When the SOC chip to be tested is not interrupted, the test main program is executed;

When the SOC chip to be tested issues an interrupt request, the interrupt service routine is executed.
A verification system for a SOC chip, characterized in that the system comprises:

a loader for loading the test program;

a random transaction generator, configured to invoke a corresponding system function in a system interface function library according to the test program loaded by the loader, and generate a random transaction according to the system function and a maintenance list corresponding to the system function;

And a verification unit, configured to perform verification on the SOC chip to be tested according to the random transaction generated by the random transaction generator.
The system of claim 7 wherein when the random transaction is a random test transaction, the random transaction generator comprises:

a device search unit, configured to search for a SOC chip to be tested corresponding to the SOC chip to be tested in the SOC chip configuration list to be tested;

a class object generating unit, configured to generate a class object corresponding to the test transaction according to the SOC chip configuration to be tested searched by the device searching unit;

a class object random unit for randomly classifying the class object generated by the class object generating unit;

The test transaction generating unit is configured to generate a test transaction according to the random result of the class object random unit to the class object.
The system of claim 8, wherein the SOC chip configuration to be tested comprises a register image of the SOC chip to be tested and a constraint expression of the SOC chip to be tested, the register image specifically including a register name, an address, The bit width, the default configuration value, the current configuration value, and the previous configuration value, the constraint expression defines a range of random parameters of the SOC chip to be tested.
The system of claim 7 wherein when the random transaction is a random IO operation transaction, the random transaction generator comprises:

a random parameter determining unit, configured to determine a random parameter in the random IO function that needs to be randomized;

a random value generating unit, configured to generate, by using an IO list, the random parameter determining unit in a chronological order to determine a random value of the random parameter;

The IO operation generating unit is configured to generate a random IO operation transaction according to the random value of the random parameter generated by the random value generating unit.
The system of claim 7 wherein when the random transaction is a random sequence operation transaction, the random transaction generator comprises:

a random sequence determining unit for determining a random number or a parameter of a random sequence required by the test program;

a calculating unit, configured to calculate a random number or a random sequence required by the test program according to the random sequence table and the parameter determined by the random sequence determining unit;

And returning a unit, for returning the random number or the random sequence calculated by the calculating unit to the test program, and saving in the random sequence table.
The system of claim 7 wherein said test program comprises a test main program and a test interrupt service program.
The system of claim 7 wherein said system further comprises an interrupt manager for prioritizing and interrupting nested management when a plurality of interrupt requests arrive.