WO2013016979A1 - 一种soc芯片的验证方法及系统 - Google Patents

一种soc芯片的验证方法及系统 Download PDF

Info

Publication number
WO2013016979A1
WO2013016979A1 PCT/CN2012/076895 CN2012076895W WO2013016979A1 WO 2013016979 A1 WO2013016979 A1 WO 2013016979A1 CN 2012076895 W CN2012076895 W CN 2012076895W WO 2013016979 A1 WO2013016979 A1 WO 2013016979A1
Authority
WO
WIPO (PCT)
Prior art keywords
random
transaction
test
tested
function
Prior art date
Application number
PCT/CN2012/076895
Other languages
English (en)
French (fr)
Inventor
李新辉
Original Assignee
炬力集成电路设计有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 炬力集成电路设计有限公司 filed Critical 炬力集成电路设计有限公司
Publication of WO2013016979A1 publication Critical patent/WO2013016979A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/33—Design verification, e.g. functional simulation or model checking

Definitions

  • the invention belongs to the technical field of chips, and in particular relates to a verification method and system for a SOC chip.
  • 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.
  • 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.
  • a representative transaction level verification method is a verification method manual (Verification) Methodology Manual, VMM).
  • VMM Verification Methodology Manual
  • 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.
  • 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.
  • 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 are possible.
  • 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.
  • the embodiment of the present invention is implemented by the method for verifying a SOC chip, and the method includes the following steps:
  • the test chip 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 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;
  • a verification unit configured to verify the test chip according to the random transaction generated by the random transaction generator.
  • the embodiment of the invention calls the corresponding system function in the system interface function library through the loaded test program, generates a random transaction according to the system function and the maintenance list corresponding to the system function, and verifies the test chip 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.
  • FIG. 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.
  • Embodiment 3 is a flowchart of a test program development provided by Embodiment 1 of the present invention.
  • FIG. 4 is a flowchart of an implementation of a method for generating a random transaction according to Embodiment 2 of the present invention.
  • FIG. 5 is a flowchart of an implementation of an example of generating a test transaction according to Embodiment 2 of the present invention.
  • FIG. 6 is a flowchart of an implementation of a method for generating a random transaction according to Embodiment 3 of the present invention.
  • FIG. 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.
  • FIG. 8 is a flowchart of an implementation of a method for generating a random transaction according to Embodiment 4 of the present invention.
  • FIG. 9 is a flowchart of an implementation of generating a random number or a random sequence provided by Embodiment 4 of the present invention.
  • FIG. 10 is a verification structural diagram of a SOC chip according to Embodiment 5 of the present invention.
  • FIG. 11 is a verification structural diagram of a SOC chip according to Embodiment 6 of the present invention.
  • FIG. 12 is a verification structural diagram of a SOC chip according to Embodiment 7 of the present invention.
  • FIG. 13 is a structural diagram of a random device configuration operation unit according to Embodiment 7 of the present invention.
  • FIG. 14 is a structural diagram of a random IO operation unit according to Embodiment 7 of the present invention.
  • FIG. 15 is a structural diagram of a random sequence operation unit according to Embodiment 7 of the present invention.
  • FIG. 16 is a flowchart of a verification process of a SOC chip according to Embodiment 8 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 test chip is verified according to the random transaction. .
  • 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:
  • step S201 the test program is loaded.
  • test program can implement the following functions:
  • test program may be a driver or an application, for example, may include a main program and an interrupt service program, etc., wherein
  • the interrupt service routine can be a function of the form:
  • the pid is the test device number
  • the port is the interrupt port number
  • 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 interrupt generated by the "hardware”, that is, the device to be tested is called a "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:
  • pid is the test device number
  • source_id is the interrupt source number, used to indicate the identity of the caller
  • port_id is the interrupt port number
  • test program may be a standard c/c++ program.
  • a standard c/c++ compiler may be used, and the test program may exist in the form of a test library.
  • 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.
  • 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.
  • 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.
  • DPI Direct Programming Interface
  • EDA Electronic design Automation
  • 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.
  • the random transaction may include a random test transaction, a random IO operation transaction, and/or a random sequence operation transaction.
  • 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:
  • 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:
  • 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.
  • the semaphore function is used to access protected resources, and the semaphore list is manipulated when the semaphore is manipulated.
  • the IO function is used to directly access the function of the device under test through the port address of the device.
  • synchronization between IO operations is required to ensure that their execution order is correct. This order is guaranteed by the IO list.
  • the IO operation at the head of the list is completed first. After the subsequent operations, the following are some IO function operation functions:
  • the shared data function places the shared data in a common data list for use by each thread.
  • 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.
  • Void delay_t double delay_time
  • the current thread is blocking a simulation time
  • the randomization function is used to randomize the configuration of the device to be tested.
  • the random function 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.
  • the device configuration list to be tested is searched, and the corresponding device to be tested is found. And the corresponding device configuration to be tested is loaded, and the random constraint description therein is used to generate a random transaction.
  • the maintenance list may include a plurality of different lists.
  • 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, and the randomization function corresponds to the random sequence table and the device configuration list to be tested.
  • the event list indicates that notification and synchronization are performed in the simulation system when an event that satisfies a certain condition occurs.
  • 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.
  • Test program test The device to be tested may be implemented by accessing the registers of the device under test.
  • the IO list maintains these operations in chronological order, synchronizes the IO operations, ensures the legality of the operation, and synchronizes the test program.
  • the test program can access the device to be tested through the IO function.
  • 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.
  • 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.
  • 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.
  • 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.
  • the device configuration list to be tested saves all the device 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 device to be tested. When the device under test is operated, the corresponding device to be tested is searched from the device configuration list to be tested and the corresponding device to be tested is configured to generate a random test transaction.
  • step S103 the test chip is verified according to the random transaction described above.
  • 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 test chip is verified according to the random transaction.
  • 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.
  • 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:
  • step S401 in the device configuration list to be tested, the device configuration to be tested corresponding to the device to be tested is searched for.
  • each device to be tested has a device configuration to be tested, and the device configuration to be tested includes a register image of the device to be tested and a constraint expression of the device to be tested, and the register image specifically includes the name and address of the register.
  • 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 device to be tested, specifically:
  • 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.
  • the constraint expression of the device to be tested defines the range of random parameters of the device 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.
  • step S402 a class object corresponding to the test transaction is generated according to the device configuration to be tested.
  • the register image and the constraint expression of the device to be tested are determined by the device configuration to be tested, and the class object corresponding to the test transaction is established according to the device configuration to be tested, and the register image and the constraint expression are used as class objects. a member of.
  • step S403 the above-mentioned class objects are randomized.
  • step S404 a test transaction is generated based on a random result of the class object.
  • 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.
  • the device to be tested is searched through the device configuration list to be tested. And loading the corresponding device configuration to be tested, obtaining a register image and a constraint expression through the device configuration to be tested, and the register image specifically includes parameters such as a name, an address, a bit width, a default value, a current value, a previous value, and the like of the device register to be tested.
  • Configure the constraint expression set the properties of the class object, and use the above parameters and the data in the random sequence table as the members of the pre-constructed class object.
  • the constraint method calls the random method of the class object to randomize the class object, and solves the class object.
  • the random result after the completion of the class object is random, the combined result is combined to generate a test transaction, and the test transaction is sent to the subsequent transaction processor, and then driven by the bus driver to the device to be tested.
  • At least one device to be tested may be configured according to the type of the device to be tested, and specifically may include a device configuration to be tested, a device configuration to be tested 2, a device configuration to be tested N, where N is a natural number.
  • the value of the number N of devices to be tested may be determined according to actual needs, and is not limited to the present invention.
  • the random transaction is made transparent and automatic by the device 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.
  • 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:
  • step S601 a random parameter that needs to be randomized in the random IO function is determined.
  • step S602 the random value of the random parameter is generated in chronological order by the IO list.
  • step S603 a random IO operation transaction is generated according to the random value of the random parameter.
  • 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.
  • 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.
  • 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:
  • step S801 parameters of a random number or a random sequence required by the test program are determined.
  • 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.
  • step S803 the calculated random number or random sequence is returned to the test program and stored in the random sequence table.
  • 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.
  • 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.
  • 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.
  • the test main program is loaded and When the device 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. After the execution of the interrupt service program is completed, the test main program continues. carried out.
  • 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.
  • the verification unit 103 verifies the test chip.
  • 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 device configuration to be tested corresponding to the device to be tested in the device configuration list to be tested.
  • the device to be tested configuration includes a register image of the device to be tested and a constraint expression of the device to be tested, and the register image specifically includes a register name, an address, a bit width, a default configuration value, and a current configuration. Value and previous configuration value, the constraint expression defines the range of random parameters of the device to be tested
  • the class object generating unit generates a class object corresponding to the test transaction according to the device 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.
  • 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.
  • 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.
  • 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.
  • 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 above system function and the maintenance list corresponding to the system function, and the test chip is processed according to the random transaction.
  • the verification is performed so that the test program written by the software engineer can be directly run on the existing verification platform, and the software and hardware co-verification is realized.
  • 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.
  • 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)
  • 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
  • the DPI interface of the corresponding system may include a main program DPI interface 111 and an interrupt program DPI interface 112.
  • the test main program when the device to be tested has no interrupt generated, the test main program is executed, and when the device 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 the interrupt manager. 114 for priority management and interrupt nesting management.
  • 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 device configuration list to be tested.
  • 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.
  • 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 lookup module 131 searches the device configuration list 127 to be tested for the device configuration to be tested corresponding to the device to be tested, and loads the device configuration to be tested corresponding to the device to be tested.
  • the device configuration to be tested may include a register image of the device to be tested and a constraint expression of the device to be tested, and the register image specifically includes a register name, an address, a bit width, a default configuration value, a current configuration value, and For the previous configuration value, the above constraint expression defines the range of random parameters of the device to be tested.
  • the class object generation module 132 Based on the device configuration to be tested found 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.
  • 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.
  • the IO operation generation module 143 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.
  • 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.
  • FIG. 16 shows a verification process of the SOC chip provided in Embodiment 8 of the present invention:
  • the hardware engineer or the verification engineer extracts a device under test configuration (device under test configuration) describing the device characteristics according to the hardware design specification. Dut_cfg).
  • 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).
  • current popular verification methodology eg, VMM
  • 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.
  • test program written in c/c++ as a test file.
  • the test program can be a driver or an application.
  • the verification engineer or software engineer will compile the test file into a test library file using the standard c/c++ compiler.
  • the verification engineer compiles the verification system with the EDA simulator.
  • the verification engineer runs the verification system with time as a random seed.
  • 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 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.
  • the randomized transaction becomes transparent and automatic through the device configuration to be tested. 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.
  • the storage medium may be a read only memory, a magnetic disk or an optical disk or the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明适用于芯片技术领域，本发明实施例提供了一种SOC芯片的验证方法，所述方法包括下述步骤：加载测试程序；根据所述测试程序在系统接口函数库中调用相应的系统函数，根据所述系统函数，及所述系统函数对应的维护列表，生成随机事务；根据所述随机事务，对待测试芯片进行验证。本发明使得软件工程师编写的测试程序可以直接在现有的验证平台上运行，实现了软硬件协同验证，同时把低层信息进行封装，使得验证系统便于使用，且易于复用。

Description

一种SOC芯片的验证方法及系统 技术领域
本发明属于芯片技术领域，尤其涉及一种SOC芯片的验证方法及系统。
 背景技术
芯片设计完成后需要进行验证，验证的主要任务是验证设计的正确性，确定芯片是否符合所有的设计规范。
传统的验证方法是直接向量测试(direct vector test)，直接向量测试是一种信号级验证，通过制造固定场景的激励直接在信号级上与待验证芯片进行通信，通过检查芯片引脚信号的值和变化来验证芯片的功能。这种验证方法要求必须事先设计出芯片的工作场景，验证人员直接处理非常低层次的信号级信息。采用这种验证方法，验证人员工作量很大，并且一些意外场景、错误处理场景不可能一一考虑和验证到，而导致验证不全面。当芯片比较复杂、规模比较大时，直接向量测试的验证方法基本没有验证能力。由于是信号级的验证，验证平台直接与芯片的接口协议相关，验证平台重用性很差，芯片换代时原有的验证平台基本不可以重复使用，必须重新搭建新的验证平台。
为了克服传统验证方法的缺点，芯片验证的发展趋势是提高抽象层次，进行事务级的验证。
代表性的事务级(transaction level)验证方法是验证方法手册（Verification Methodology Manual，VMM)。VMM验证系统的架构如图1所示，通过验证人员操作配置器中的约束条件来约束产生器产生测试事务，并通过自动比较器实现了在线自动比较。
采用VMM验证方法后，可以实现受约束的随机验证(constrained random verification)，在设定的约束条件下进行随机，以覆盖正常工作场景和意外工作场景；覆盖率驱动验证(coverage driven verification)，当功能覆盖率、代码覆盖率达目标值以后停止随机验证；全自动在线比较，遇到错误自动报警并停止仿真，保存现场；基于断言的验证(assertion based verification)。
VMM验证方法实现了验证方法从信号级向事务级的转变，方便了数据通路类型芯片的验证。但由于VMM验证方法的数据交互和控制比较复杂，对多媒体芯片来说，操作待验证芯片的方法相当复杂，不方便控制仿真流程，易用性低，而且因为其无法加入设备驱动，故无法验证复杂的应用场景和升级成系统级验证。
 技术问题
本发明实施例的目的在于提供一种SOC芯片的验证方法，旨在解决现有技术对于现有验证平台，验证操作复杂，且无法验证复杂的应用场景，无法在仿真系统上实现软硬件协同验证的问题。
 技术解决方案
本发明实施例是这样实现的，一种SOC芯片的验证方法，所述方法包括下述步骤：
加载测试程序；
根据所述测试程序在系统接口函数库中调用相应的系统函数，根据所述系统函数，及所述系统函数对应的维护列表，生成随机事务；
根据所述随机事务，对待测试芯片进行验证。
本发明实施例还提供了一种SOC芯片的验证系统，所述系统包括：
加载器，用于加载测试程序；
随机事务产生器，用于根据所述加载器加载的测试程序在系统接口函数库中调用相应的系统函数，根据所述系统函数，及所述系统函数对应的维护列表，生成随机事务；
验证单元，用于根据所述随机事务产生器产生的随机事务，对待测试芯片进行验证。
 有益效果
本发明实施例通过加载的测试程序在系统接口函数库中调用相应的系统函数，根据系统函数，及系统函数对应的维护列表，生成随机事务，根据随机事务，对待测试芯片进行验证。使得软件工程师编写的测试程序可以直接在现有的验证平台上运行，将验证方法提升为系统级验证，实现了软硬件协同验证，实现了复杂应用场景的验证，同时通过把低层信息进行封装，使得验证系统便于使用，且易于复用。
 附图说明
图1是本发明提供的现有技术的VMM验证平台的结构图；
图2是本发明实施例一提供的SOC芯片的验证方法的实现流程图。
图3是本发明实施例一提供的测试程序开发的流程图；
图4是本发明实施例二提供的生成随机事务的方法的实现流程图；
图5是本发明实施例二提供的生成测试事务的实现示例的实现流程图；
图6是本发明实施例三提供的生成随机事务的方法的实现流程图；
图7是本发明实施例三提供的生成IO操作事务的实现示例的实现流程图；
图8是本发明实施例四提供的生成随机事务的方法的实现流程图；
图9是本发明实施例四提供的生成随机数或者随机序列实现示例的实现流程图；
图10是本发明实施例五提供的SOC芯片的验证结构图；
图11是本发明实施例六提供的SOC芯片的验证结构图；
图12是本发明实施例七提供的SOC芯片的验证结构图；
图13是本发明实施例七提供的随机器件配置操作单元的结构图；
图14是本发明实施例七提供的随机IO操作单元的结构图；
图15是本发明实施例七提供的随机序列操作单元的结构图；
图16是本发明实施例八提供的SOC芯片的验证过程的流程图。
 本发明的实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
本发明实施例通过上述加载的测试程序在系统接口函数库中调用相应的系统函数，根据上述系统函数，及上述系统函数对应的维护列表，生成随机事务，根据上述随机事务，对待测试芯片进行验证。
为了便于说明本发明的技术方案，下面通过具体实施例来进行说明：
实施例一
图2示出了本发明实施例一提供的SOC芯片的验证方法的实现流程图，详述如下：
在步骤S201中，加载测试程序。
在本发明实施例中，测试程序可以实现以下功能：
(1) 控制验证系统的流程。
(2) 取得和改变验证系统的状态。
(3) 操作、访问待测芯片。
(4) 产生随机测试事务来测试芯片。
(5) 其他标准C/C++能完成的操作。
在本发明实施例中，测试程序可以为驱动程序或者应用程序，例如，可以包括主程序和中断服务程序等，其中，
1、中断服务程序可以是具有以下形式的函数：
int isr(int pid, int source，int port)；凡具有以上形式的函数，均可以向系统注册，成为中断服务程序。
2、中断服务程序在主测试程序中的注册的方式，可以调用以下函数：
int register_isr(int pid, int port, isr_pt isr)；
其中的pid是测试器件编号，port是中断端口编号，isr即为欲注册的函数。? 3、中断的形式可以分为软中断和硬中断，由“硬件”即待测试器件发出的中断称为“硬中断”，而测试程序亦可向系统发出中断，称为“软中断”。
调用下列函数即发出软中断：
assert_irq(int pid, int source_id, int port_id)
其中，pid是测试器件编号，source_id是中断源编号，用于表明调用者身份，port_id则是中断端口编号。
在本发明实施例中，测试程序可以有多个，测试程序可以是标准的c/c++程序，此时，可以使用标准的c/c++编译器，而且测试程序可以以测试程序库的形式存在，例如，可以通过gcc等编译成测试程序库文件 ，测试程序库的开发流程可以采用如图3所示的开发流程，在开发过程中，根据c/c++库文件，分别开发测试主程序和中断服务程序，测试主程序和中断服务程序经过gcc编译成目标文件，所有目标文件经过打包生成测试程序库。
在本发明实施例中，可以通过直接编程接口(Direct Programming Interface ，DPI)加载测试程序，通过DPI接口，C/C++程序可以调用EDA（Electronic design automation）语言域的函数，而EDA语言域也可以调用C/C++语言域的函数，当测试程序包含主程序和中断服务程序时，DPI接口也可以相应的有两个，分别对应主程序和中断服务程序。
在步骤S202中，根据测试程序在系统接口函数库中调用相应的系统函数，根据系统函数，及系统函数对应的维护列表，生成随机事务。
在本发明实施例中，随机事务可以包括随机测试事务、随机IO操作事务和/或随机序列操作事务。
在本发明实施例中，在系统函数库中调用相应的系统函数，系统函数具体可以包括控制函数、事件函数、IO函数、信号量函数、共享数据函数、线程函数或者随机化函数中的任意组合，其中：
(1) 控制函数
控制函数用于控制验证系统的运行，如暂停仿真，继续仿真，取得仿真时间，获得仿真系统当前状态，改变系统状态等，具体可以采用：
sim_finish()；// 结束仿真
sim_stop()；//暂停仿真
double get_time()； //取得当前仿真时间
(2) 事件函数
事件函数用于测试线程之间的同步，其中，事件的发生或同步会操作相应的事件列表，
int event_create()；// 创建一个事件列表项，返回事件编号
void event_trigger(int event_id)；// 触发事件，通常在某仿真条件发生后触发
void event_sync(int event_id, int sync_type)；// 同步到事件，在事件发生之前阻塞线程
(3) 信号量函数
信号量函数用于访问受保护的资源，操作信号量时会操作信号量列表。
int semaphore_create(int key_count)；// 创建一个信号量表项，返回信号量编号
void semaphore_get(int semaphore_id, int key_count)；// 申请信号量，若信号时不足则阻塞直到有足够的信号量。在访问资源前申请。
void semaphore_put(int semaphore_id, int key_count)；// 释放信号量，访问完资源后应释放信号量以使其他线程能访问资源。
(3) IO函数
IO函数用于通过器件的端口地址直接访问待测试器件的函数，当支持多线程时，各IO操作之间还需要进行同步以确保它们的执行顺序是正确的，这个顺序是由IO列表来保证的，处于列表头的IO操作先完成，后续操作继后，以下为一些IO函数操作函数：
void io_write(int pid, int address, int op_size, int data, int mask)； // 写器件
int io_read(int pid, int address, int op_size)； // 读器件
void io_burst_write(int pid,int address,int op_size,int burst_type,int *data,int *mask)； // 以迸发方式写器件
void io_burst_read(int pid, int address,int op_size,int burst_type,int *data)；// 以迸发方式读器件
void io_random_transfer(int pid, int start_address, int end_address, int op_size,int op, int burst_type, int ntests)； // 对器件进行随机访问
(4) 共享数据函数
当需要在测试程序各线程之间进行数据共享时，共享数据函数会将共享数据放在通用数据列表中以供各线程使用。
void scfg_create_reg(char *reg_name, int init_value)； // 创建一个表项
void scfg_set_reg(char *reg_name, int value)；// 设置一个共享项
int scfg_get_reg(char *reg_name)；// 读取一个共享项
void scfg_wait_reg(char *reg_name, int exp_value, int mask)；// 等待直到共享项的值为指定值
void scfg_wait_reg_created(char *reg_name)； // 等待直到共享项被创建
void scfg_wait_reg_write(char *reg_name)； // 等待直到共享项的值被设置
void scfg_wait_reg_read(char *reg_name)； // 等待直到共享项的值被读取
void scfg_wait_reg_change(char *reg_name)； // 等待直到共享项的值改变
void scfg_wait_reg_not(char *reg_name, int exp_value, int mask)； // 等待直到共享项的值不为指定值
void scfg_wait_reg_less(char *reg_name, int exp_value)；// 等待直到共享项的值小于指定值
void scfg_wait_reg_larger(char *reg_name, int exp_value)；// 等待直到共享项的值大于指定值
(5) 线程函数
线程函数用于产生多线程，并可以在线程之间进行同步，取消等操作，线程列表保存了当前正在执行的线程以及它们的状态。
int io_fork (int (*io_func)(), int total_args, ...)； // 以并行线程方式执行函数，返回线程编号
void io_sync(int schedule_id)； // 同步，阻塞直到指定编号的线程执行完
void io_flush(int pid)； //同步，阻塞直到指定的主器件把所有IO操作做完
void io_nop(int pid)；//等待指定主器件的上一个IO操作完成
void delay_t(double delay_time)；// 当前线程阻塞一段仿真时间
void delay_clock(int pid, int clock_cycles)；// 当前线程阻塞一定时钟周期
void sim_pause(int pause_id)；// 当前线程暂停
void sim_resume(int pause_id)； // 继续执行被暂停的线程
（6）随机化函数
随机化函数用于随机化待测试器件的配置，执行随机化函数时，一方面随机函数产生一个随机序列并存入随机序列表，一方面查询待测试器件配置列表，查找到对应的待测试器件并把对应的待测试器件配置加载进来，将其中的随机约束描述用于产生随机事务。
int randc(int max, int min)；// 从范围[min, max]中取得一个不重复的随机整数
int randc_array(int *ResultArray, int ArraySize, int max, int min)；// 从范围[min, max]中取得ArraySize个不重复的随机整数
int randcase(weight_0, ...)； // 从后续分支中随机取一条分支执行，分支的权重分别为weight_0， weight_1， ... weight_N。
void cfg_rand_regs(int pid, char *cfg_name, ...)；// 随机化待测试器件寄存器以获得随机配置值
void cfg_set_rand_mask(int pid, char *cfg_name, char *reg_name, int rand_mask)；// 为待测试器件寄存器设置随机掩码，确保不需要随机化的寄存器保持原有的值
void cfg_flush_regs(int pid, char *cfg_name, char *reg_name...)；// 将随机好的寄存器值通过系统总线写到待测试器件(DUT)
在本发明实施例中，维护列表可以包括多个不同的列表，具体为不同的系统函数可以与不同的列表进行对应，例如，事件函数对应事件列表，IO函数对应IO列表，信号量函数对应信号量列表，共享数据函数对应通用数据列表，线程函数对应线程列表，随机化函数对应随机序列表及待测试器件配置列表。
1. 事件列表(event table)
事件列表表示当满足某条件的事件发生了，在仿真系统中进行通知和同步。当仿真系统的某处发生了某事件，就可以声明事件并将事件放入事件列表，仿真系统的其它地方就可以以此事件为触发条件执行处理程序。各线程可通过事件函数操作事件。
2. IO列表(IO table)
测试程序测试待测试器件可能要通过访问待测试器件的寄存器来实现，IO列表将这些操作按时间先后顺序进行维护，实现IO操作同步，保证操作的合法性，同时也对测试程序进行了同步。
测试程序可以通过IO函数来访问待测试器件。
3. 信号量列表(semaphore table)
当多个线程需要访问同一资源时，需要保证访问的互斥性。信号量(semaphore)就是保证互斥性的一种方法。每种资源对应若干个信号量；线程访问资源时需要先申请信号量，若信号量不足，则线程被阻塞，直到获得足够的信号量才解阻塞，访问到资源，最后释放信号量以使其他线程能访问资源。各线程可通过信号量函数操作信号量。
4. 通用数据列表(universal data table)
通用数据列表保存了通用用途的数据，可供仿真系统各线程共享，各线程可通过共享数据函数访问通用数据。
5. 线程列表(scheduled thread table)
测试程序可以用线程函数操作线程，测试程序可以引发多条同时执行的子线程，通过线程列表维护这些子线程，以保证线程的执行顺序是符合预期的，同时也是可控制的，例如，可在其他线程等待某线程完成，杀死某线程，引发子线程等。
6. 随机序列表(random sequence table)
随机序列表用于维护随机序列，使得随机序列产生过程对测试程序来说是透明的，程序员不必关心具体的实现过程，测试程序可以通过随机化函数获取随机序列。
7. 待测试器件配置列表(device under test configuration table),
待测试器件配置列表保存了当前系统的所有待测试器件配置文件(device under test configuration, dut_cfg)的清单。每个dut_cfg文件对应一个待测试器件。在操作待测器件时，从待测试器件配置列表中查找对应的待测试器件并将对应的待测试器件配置以产生随机测试事务。
在步骤S103中，根据上述随机事务，对待测试芯片进行验证。
本发明实施例通过上述加载的测试程序在系统接口函数库中调用相应的系统函数，根据上述系统函数，及上述系统函数对应的维护列表，生成随机事务，根据上述随机事务，对待测试芯片进行验证，使得软件工程师编写的测试程序可以直接在现有的验证平台上运行，实现了软硬件协同验证，同时通过把低层信息进行封装，使得验证系统便于使用，且易于复用。
实施例二
图4示出了本发明实施二提供的当随机事务为随机测试事务时，根据系统函数，及系统函数对应的维护列表，生成随机事务的方法的实现的流程图，详述如下：
在步骤S401中，在待测试器件配置列表中，查找与上述待测试器件对应的待测试器件配置。
在本发明实施例中，每个待测试器件都有一个待测试器件配置，待测试器件配置包括待测试器件的寄存器映像和待测试器件的约束表达式，上述寄存器映像具体包括寄存器的名称、地址、位宽、默认配置值、当前配置值及前一次配置值，上述约束表达式限定待测试器件的随机参数的范围，具体为：
1、待测器件的寄存器映像，包括寄存器的名称，地址，位宽，默认值，前一次配置值，当前配置值等。
2、待测试器件的约束表达式，约束表达式限定待测试器件的随机参数的范围，随机化时这些表达式将会被满足。如当前配置与前一次配置需满足的逻辑关系，两个寄存器需满足的逻辑关系，寄存器的值的合法范围等。
在步骤S402中，根据上述待测试器件配置，生成与测试事务对应的类对象。
在本发明实施例中，通过待测试器件配置确定待测试器件的寄存器映像及约束表达式，并根据待测试器件配置建立与测试事务对应的类对象，且将寄存器映像及约束表达式作为类对象的成员。
在步骤S403中，对上述类对象进行随机。
在步骤S404中，根据对所述类对象进行随机的结果，生成测试事务。
为了便于理解，以下以一个具体实现示例对本发明实施例的方法进行说明，但不以本实现示例为限，具体请参阅图5，系统函数调用时，通过待测试器件配置列表查找待测试器件，并加载对应的待测试器件配置，通过待测试器件配置获取寄存器映像及约束表达式，寄存器映像具体包括待测试器件寄存器的名称、地址、位宽、默认值、当前值、前一次值等参数及配置约束表达式，同时设置类对象的属性，将上述参数以及随机序列表中的数据作为事先建构的类对象的成员，解约束服务器调用类对象的随机方法对类对象进行随机，解出类对象的随机结果，完成类对象随机后，将解出的结果组合生成测试事务，测试事务产生以后被送到后续的事务处理器，再由总线驱动器驱动到待测试器件。
本发明实施例中，可以根据待测式器件的类型的不同设置至少1个待测试器件配置，具体可以包括待测试器件配置1、待测试器件配置2、……待测试器件配置N，其中，N为自然数，具体待测试器件配置数目N的取值可以根据实际的需要确定，在次不用以限制本发明。
在本发明实施例中，通过待测试器件配置使产生随机事务变得透明、自动，编写测试程序时不必考虑测试向量的覆盖率，也不必考虑测试向量是怎样产生的。通过自动对随机事务进行随机化，保证验证随机、全面和自动化。
实施例三
图6示出了本发明实施三提供的当随机事务为随机IO操作事务时，根据系统函数，及系统函数对应的维护列表，生成随机事务的方法的实现流程图，详述如下：
在步骤S601中，确定随机IO函数中需要随机化的随机参数。
在步骤S602中，通过IO列表，按时间先后顺序产生上述随机参数的随机值。
在步骤S603中，根据上述随机参数的随机值，生成随机IO操作事务。
为了便于理解，以下以一个具体实现示例对本发明实施例的方法进行说明，但不以本实现示例为限，具体请参阅图7，当随机事务为随机IO操作事务时，根据随机IO函数的参数，确定哪些参数是可以被随机的，哪些是固定的，其中，被随机的可以是操作地址， 操作数，迸发方式，操作方式等，然后，通过IO列表，按时间先后顺序取出地址和地址随机掩码、操作数和操作数随机掩码、操作方式和操作方式随机掩码以及迸发方式和迸发方式掩码，当需要随机时，调用系统随机函数，获得地址、操作数、操作方式及迸发方式等随机参数的随
实施例四
图8示出了本发明实施四提供的当随机事务为随机序列操作事务时，根据系统函数，及系统函数对应的维护列表，生成随机事务的方法的实现流程图，详述如下：
在步骤S801中，确定测试程序需要的随机数或者随机序列的参数。
在步骤S802中，根据随机序列表及上述参数，计算测试程序需要的随机数或者随机序列。
在步骤S803中，将计算出的随机数或者随机序列返回给测试程序，并保存在随机序列表中。
为了便于理解，以下以一个具体实现示例对本发明实施例的方法进行说明，但不以本实现示例为限，具体请参阅图9，在本实现示例中，测试程序需要获取满足特定条件的随机数或随机数序列。根据随机序列表中的已知的值，及上述参数，包括调用的系统函数中的已知的值、权重和范围使用数学运算的方法计算出符合条件的数或数组返回给测试程序，并结果保存在随机序列表中以待下次使，同时可以删除随机序列表中时间最早的项，以保持随机序列表的项数为固定值。
实施例五
图10示出了本发明实施例五提供的SOC芯片的验证系统的结构，为了便于理解，仅示出了相关部分的结构。
本发明实施例的系统的结构具体包括加载器101、随机事务产生器102及验证单元103，其中：
加载器101加载测试程序。
在本发明实施例中，加载器101加载测试程序，具体可以对测试函数库中的测试主程序或者测试中断服务程序进行加载并运行，当待测试器件没有中断产生时，则加载测试主程序并运行；而当待测试器件发出中断请求时，则加载中断服务程序并运行，此时，测试主程序被挂起暂停执行，转而执行中断服务程序，中断服务程序执行完成后，测试主程序继续执行。
随机事务产生器102根据上述加载器101加载的测试程序在系统接口函数库中调用相应的系统函数，根据上述系统函数，及上述系统函数对应的维护列表，生成随机事务。
根据上述随机事务产生器102产生的随机事务，验证单元103对待测试芯片进行验证。
当随机事务为随机测试事务时，所述随机事务产生器102包括器件查找单元、类对象生成单元、类对象随机单元和测试事务生成单元，具体为：
器件查找单元在待测试器件配置列表中，查找与所述待测试器件对应的待测试器件配置。
在本发明实施例中，所述待测试器件配置包括待测试器件的寄存器映像和待测试器件的约束表达式，所述寄存器映像具体包括寄存器的名称、地址、位宽、默认配置值、当前配置值及前一次配置值，所述约束表达式限定待测试器件的随机参数的范围
根据所述器件查找单元查找的待测试器件配置，类对象生成单元生成与测试事务对应的类对象。
类对象随机单元对所述类对象生成单元生成的类对象进行随机。
根据所述类对象随机单元对类对象进行随机的结果，测试事务生成单元生成测试事务。
当随机事务为随机IO操作事务时，所述随机事务产生器102包括随机参数确定单元、随机值生成单元和IO操作生成单元，具体为：
随机参数确定单元确定随机IO函数中需要随机化的随机参数。
通过IO列表，随机值生成单元按时间先后顺序产生所述随机参数确定单元确定随机参数的随机值。
根据所述随机值生成单元生成的随机参数的随机值，IO操作生成单元生成随机IO操作事务。
当随机事务为随机序列操作事务时，所述随机事务产生器102包括随机序列确定单元、随机序列确定单元、计算单元和返回单元，具体为：
随机序列确定单元确定测试程序需要的随机数或者随机序列的参数。
根据随机序列表及所述随机序列确定单元确定的参数，计算单元计算测试程序需要的随机数或者随机序列。
返回单元将所述计算单元计算出的随机数或者随机序列返回给测试程序，并保存在随机序列表中。
本发明实施例通过加载器加载测试程序，并在系统接口函数库中调用相应的系统函数，根据上述系统函数，及上述系统函数对应的维护列表，生成随机事务，根据上述随机事务，对待测试芯片进行验证，使得软件工程师编写的测试程序可以直接在现有的验证平台上运行，实现了软硬件协同验证。
实施例六
图11示出了本发明实施例六提供的SOC芯片验证系统的结构，为了便于理解，仅示出了相关部分的结构。
在本发明实施例中，可以通过直接编程接口(Direct Programming Interface ，DPI)启动加载器，并将加载的测试程序加载至仿真系统，通过DPI接口，C/C++程序可以调用EDA（Electronic design automation）语言域的函数，而EDA语言域也可以调用C/C++语言域的函数。
其中，测试程序可以包含主程序和中断服务程序，相应的系统的DPI接口可以包括主程序DPI接口111和中断程序DPI接口112。
在本发明实施例中，当待测试器件没有中断产生时，执行测试主程序，当待测试器件发出中断请求时，执行中断服务程序，当有多个中断请求到来时，系统可以包括中断管理器114进行优先级管理和中断嵌套管理。
实施例七
图12示出了本发明实施例七提供的SOC芯片验证系统的结构，为了便于理解，仅示出了相关部分的结构。
随机事务产生器在系统接口函数库125中调用的相应的系统函数，系统函数具体包括：控制函数、事件函数、IO函数、信号量函数、共享数据函数、线程函数或者随机化函数。
统函数操作相应的维护列表126，维护列表种类具体包括：事件列表、IO列表、信号量列表、通用数据列表、线程列表、随机序列表和待测试器件配置列表。
在本发明实施例中，随机事务产生器128包括随机器件配置操作单元1281、随机IO操作单元1282和/或随机序列操作单元1283。
其中，图13示出了随机器件配置操作单元的具体包括器件查找模块131、类对象生成模块132、类对象随机模块133及测试事务生成模块134，其中：
器件查找模块131在待测试器件配置列表127中，查找与上述待测试器件对应的待测试器件配置，并加载与待测试器件对应的待测试器件配置。
在本发明实施例中，待测试器件配置可以包括待测试器件的寄存器映像和待测试器件的约束表达式，上述寄存器映像具体包括寄存器的名称、地址、位宽、默认配置值、当前配置值及前一次配置值，上述约束表达式限定待测试器件的随机参数的范围。
根据上述器件查找模块131查找的待测试器件配置，类对象生成模块132生成与测试事务对应的类对象。
类对象随机模块133对上述类对象生成模块132生成的类对象进行随机。
在本发明实施例中，类对象随机模块131调用相应的类对象的随机方法，对类对象进行随机。
根据上述类对象随机模块133对类对象进行随机的结果，测试事务生成模块134生成测试事务。
图14示出了上述随机IO操作单元的具体结构：
随机参数确定模块141确定随机IO函数中需要随机化的随机参数。
随机值生成模块142通过维护列表126中的IO列表，按时间先后顺序产生随机参数确定模块确定随机参数的随机值。
根据随机值生成模块142生成的随机参数的随机值，IO操作生成模块143生成随机IO操作事务。
图15示出了上述随机序列操作单元的具体结构：
随机序列确定模块151确定测试程序需要的随机数或者随机序列的参数。
根据维护列表126中的随机序列表及随机序列确定模块151确定的参数，计算模块152计算测试程序需要的随机数或者随机序列。
返回模块153将计算模块计算出的随机数或者随机序列返回给测试程序，并保存在随机序列表中。
实施例八
图16示出了本发明实施例八提供的SOC芯片的验证过程：
(1) 硬件工程师设计好待测试器件(device under test, DUT)，提供寄存器-传输级代码(Register Transfer Level Code ，RTL)
(2) 硬件工程师或验证工程师根据硬件设计规格书提取出描述器件特性的待测试器件配置约束文件(device under test configuration, dut_cfg)。
(3) 验证工程师根据当前流行的验证方法学（例如VMM）准备好验证系统其他部件如事务处理器、总线驱动器、监视器、自动比较器等。
(4) 验证工程师将上述DUT、dut_cfg、本发明的部件以及验证平台其他部件连接成验证系统。
(5) 验证工程师或软件工程师准备好以c/c++语言编写的测试程序作为测试文件，例如，测试程序可以为驱动程序或者应用程序。
(6) 验证工程师或软件工程师将测试文件，用标准c/c++编译器编译成测试程序库文件。
(7) 验证工程师用EDA仿真器编译验证系统。
(8) 验证工程师以时间作为随机种子(random seed)运行验证系统。
(9) 仿真开始后，主控制器通过加载器将测试程序库文件装载进验证系统并运行。
(10) 验证系统运行期间可能会发现硬件逻辑行为、性能等与硬件设计规格书定义不一致的缺陷(bug)，这时,自动比较器暂停验证系统,记录下随机种子并导出仿真波形，交由验证工程师、硬件工程师共同调试；使用相同的随机种子重新运行验证系统可以重现缺陷场景，方便调试。硬件工程师更改设计后，验证工程师重新编译验证系统。
(11) 若验证系统运行期间未发现硬件缺陷，验证系统运行直到当前测试函数完成。
(12) 当前测试函数完成后，检查DUT代码覆盖率。
(13) 若未达到设定的覆盖率目标，则重复8~12步重新进行下一次随机仿真，直到代码覆盖率达到预定目标时结束仿真。
综上上述，本发明实施例通过上述加载的测试程序在系统接口函数库中调用相应的系统函数，根据上述系统函数，及上述系统函数对应的维护列表，生成随机事务，根据上述随机事务，对待测试芯片进行验证。，使得软件工程师编写的测试程序可以直接在现有的验证平台上运行，实现了软硬件协同验证，同时通过把低层信息进行封装，使得验证系统便于使用，且易于复用。
此外，通过待测试器件配置使产生随机事务变得透明、自动，编写测试程序时不必考虑测试向量的覆盖率，也不必考虑测试向量是怎样产生的。通过自动对随机事务进行随机化，保证验证随机、全面和自动化。
值得注意的是，上述系统所包括的各个单元只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。
另外，本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件完成，相应的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (13)

  1. 一种SOC芯片的验证方法，其特征在于，所述方法包括下述步骤：
    加载测试程序；
    根据所述测试程序在系统接口函数库中调用相应的系统函数，根据所述系统函数，及所述系统函数对应的维护列表，生成随机事务；
    根据所述随机事务，对待测试芯片进行验证。
  2. 如权利要求1所述的方法，其特征在于，当随机事务为随机测试事务时，所述根据所述系统函数，及所述系统函数对应的维护列表，生成随机事务的步骤具体为：
    在待测试器件配置列表中，查找与所述待测试器件对应的待测试器件配置；
    根据所述待测试器件配置，生成与测试事务对应的类对象；
    对所述类对象进行随机；
    根据对所述类对象进行随机的结果，生成测试事务。
  3. 如权利要求2所述的方法，其特征在于，所述待测试器件配置包括待测试器件的寄存器映像和待测试器件的约束表达式，所述寄存器映像具体包括寄存器的名称、地址、位宽、默认配置值、当前配置值及前一次配置值，所述约束表达式限定待测试器件的随机参数的范围。
  4. 如权利要求1所述的方法，其特征在于，当随机事务为随机IO操作事务时，所述根据所述系统函数，及所述系统函数对应的维护列表，生成随机事务的步骤具体为：
    确定随机IO函数中需要随机化的随机参数；
    通过IO列表，按时间先后顺序产生所述随机参数的随机值；
    根据所述随机参数的随机值，生成随机IO操作事务。
  5. 如权利要求1所述的方法，其特征在于，当随机事务为随机序列操作事务时，所述根据所述系统函数，及所述系统函数对应的维护列表，生成随机事务的步骤具体为：
    确定测试程序需要的随机数或者随机序列的参数；
    根据随机序列表及所述参数，计算测试程序需要的随机数或者随机序列；
    将所述计算出的随机数或者随机序列返回给测试程序，并保存在随机序列表中。
  6. 如权利要求1所述的方法，其特征在于，所述测试程序包括测试主程序和测试中断服务程序；
    当待测试器件没有中断产生时，执行测试主程序；
    当待测试器件发出中断请求时，执行中断服务程序。
  7. 一种SOC芯片的验证系统，其特征在于，所述系统包括：
    加载器，用于加载测试程序；
    随机事务产生器，用于根据所述加载器加载的测试程序在系统接口函数库中调用相应的系统函数，根据所述系统函数，及所述系统函数对应的维护列表，生成随机事务；
    验证单元，用于根据所述随机事务产生器产生的随机事务，对待测试芯片进行验证。
  8. 如权利要求7所述的系统，其特征在于，当随机事务为随机测试事务时，所述随机事务产生器包括：
    器件查找单元，用于在待测试器件配置列表中，查找与所述待测试器件对应的待测试器件配置；
    类对象生成单元，根据所述器件查找单元查找的待测试器件配置，生成与测试事务对应的类对象；
    类对象随机单元，用于对所述类对象生成单元生成的类对象进行随机；
    测试事务生成单元，用于根据所述类对象随机单元对类对象进行随机的结果，生成测试事务。
  9. 如权利要求8所述的系统，其特征在于，所述待测试器件配置包括待测试器件的寄存器映像和待测试器件的约束表达式，所述寄存器映像具体包括寄存器的名称、地址、位宽、默认配置值、当前配置值及前一次配置值，所述约束表达式限定待测试器件的随机参数的范围。
  10. 如权利要求7所述的系统，其特征在于，当随机事务为随机IO操作事务时，所述随机事务产生器包括：
    随机参数确定单元，用于确定随机IO函数中需要随机化的随机参数；
    随机值生成单元，用于通过IO列表，按时间先后顺序产生所述随机参数确定单元确定随机参数的随机值；
    IO操作生成单元，用于根据所述随机值生成单元生成的随机参数的随机值，生成随机IO操作事务。
  11. 如权利要求7所述的系统，其特征在于，当随机事务为随机序列操作事务时，所述随机事务产生器包括：
    随机序列确定单元，用于确定测试程序需要的随机数或者随机序列的参数；
    计算单元，用于根据随机序列表及所述随机序列确定单元确定的参数，计算测试程序需要的随机数或者随机序列；
    返回单元，用于将所述计算单元计算出的随机数或者随机序列返回给测试程序，并保存在随机序列表中。
  12. 如权利要求7所述的系统，其特征在于，所述测试程序包括测试主程序和测试中断服务程序。
  13. 如权利要求7所述的系统，其特征在于，所述系统还包括中断管理器，用于当有多个中断请求到来时，进行优先级管理和中断嵌套管理。
PCT/CN2012/076895 2011-07-29 2012-06-14 一种soc芯片的验证方法及系统 WO2013016979A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201110217229.7 2011-07-29
CN201110217229.7A CN102902834B (zh) 2011-07-29 2011-07-29 一种soc芯片的验证方法及系统

Publications (1)

Publication Number Publication Date
WO2013016979A1 true WO2013016979A1 (zh) 2013-02-07

Family

ID=47575065

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/CN2012/076895 WO2013016979A1 (zh) 2011-07-29 2012-06-14 一种soc芯片的验证方法及系统
PCT/CN2012/079225 WO2013017037A1 (zh) 2011-07-29 2012-07-26 一种soc芯片的验证方法及系统

Family Applications After (1)

Application Number Title Priority Date Filing Date
PCT/CN2012/079225 WO2013017037A1 (zh) 2011-07-29 2012-07-26 一种soc芯片的验证方法及系统

Country Status (2)

Country Link
CN (1) CN102902834B (zh)
WO (2) WO2013016979A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111579959A (zh) * 2019-02-15 2020-08-25 深圳市汇顶科技股份有限公司 芯片验证方法、装置及存储介质
CN113254296A (zh) * 2021-06-25 2021-08-13 上海励驰半导体有限公司 芯片slt测试的软件实现方法及系统

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140134016A (ko) 2013-05-13 2014-11-21 현대모비스 주식회사 통합형 제동시스템
CN104392066A (zh) * 2014-12-11 2015-03-04 浪潮电子信息产业股份有限公司 一种基于SystemVerilog的随机验证平台和方法
CN104767737A (zh) * 2015-03-23 2015-07-08 贵阳朗玛信息技术股份有限公司 插入式事务管理器及其应用方法
CN105301480A (zh) * 2015-11-19 2016-02-03 四川和芯微电子股份有限公司 Soc芯片的测试方法
CN105573750A (zh) * 2015-12-11 2016-05-11 中国航空工业集团公司西安航空计算技术研究所 一种基于嵌入式处理器的SoC验证软件设计平台
CN105760638B (zh) * 2016-04-28 2018-11-06 福州瑞芯微电子股份有限公司 一种加快soc芯片仿真的方法
CN105975664B (zh) * 2016-04-28 2019-01-18 福州瑞芯微电子股份有限公司 一种芯片功耗评估平台的评估方法
CN106708023A (zh) * 2017-01-19 2017-05-24 延锋伟世通电子科技（上海）有限公司 多平台兼容测试系统及其工作方法
CN107016165B (zh) * 2017-03-09 2020-10-20 记忆科技(深圳)有限公司 一种SoC自动化随机验证的方法
CN107256354A (zh) * 2017-06-08 2017-10-17 北京深瞐科技有限公司 硬件架构的验证方法及装置
CN107797846B (zh) * 2017-09-26 2020-07-14 记忆科技(深圳)有限公司 一种Soc芯片验证方法
CN108681500B (zh) * 2018-04-28 2021-09-07 格兰菲智能科技有限公司 具有事务记录能力的系统和事务记录方法
CN109361378B (zh) * 2018-09-25 2022-05-24 瑞芯微电子股份有限公司 Soc芯片异步时钟的验证平台和验证方法
CN109558753B (zh) * 2018-11-01 2021-02-09 北京中电华大电子设计有限责任公司 一种安全芯片多模块组合验证方法
CN109270439A (zh) * 2018-11-05 2019-01-25 郑州云海信息技术有限公司 一种芯片测试方法、装置、设备及介质
CN113168364A (zh) * 2018-12-06 2021-07-23 华为技术有限公司 一种芯片验证方法和装置
CN109783298A (zh) * 2019-01-18 2019-05-21 上海磐启微电子有限公司 一种流程灵活可控的软硬件协同SoC验证方法
CN109857609B (zh) * 2019-01-24 2022-07-19 上海磐启微电子有限公司 一种基于RAM交互的软硬件协同SoC验证方法
CN110865971B (zh) * 2019-10-30 2023-04-07 南京杰思微电子技术有限公司 Soc芯片的验证系统及其方法
CN111400979A (zh) * 2020-03-24 2020-07-10 杭州博雅鸿图视频技术有限公司 Soc的仿真方法、系统、电子设备及存储介质
CN111858109B (zh) * 2020-07-22 2024-09-13 中国第一汽车股份有限公司 互斥逻辑的验证方法、装置、设备及存储介质
CN112506517B (zh) * 2020-11-30 2024-09-06 飞腾信息技术有限公司 一种裸机系统级激励交叉编译系统及编译方法
CN112566005B (zh) * 2021-02-25 2021-07-16 易兆微电子(杭州)股份有限公司 一种音频芯片的测试方法、装置、电子设备和存储介质
CN113326027B (zh) * 2021-05-12 2022-05-10 上海安畅网络科技股份有限公司 一种领域驱动设计战术建模方法
CN113407408B (zh) * 2021-06-11 2024-01-26 海光信息技术股份有限公司 数据传输规则验证方法、装置、设备和存储介质
JP2023001992A (ja) * 2021-06-22 2023-01-10 キオクシア株式会社 集積回路検証装置、集積回路検証方法、及び集積回路検証プログラム
CN114756474B (zh) * 2022-04-27 2023-07-21 苏州睿芯集成电路科技有限公司 一种cpu验证中随机向量的生成方法、装置以及电子设备
CN115168241B (zh) * 2022-09-08 2022-11-29 济南新语软件科技有限公司 一种基于组合功能覆盖率的测试方法和系统
CN118536445B (zh) * 2024-07-15 2024-09-20 深圳鲲云信息科技有限公司 一种用于芯片仿真的方法和计算设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6249893B1 (en) * 1998-10-30 2001-06-19 Advantest Corp. Method and structure for testing embedded cores based system-on-a-chip
CN1369714A (zh) * 2001-07-18 2002-09-18 中国人民解放军第二炮兵工程学院技术开发中心 大规模集成电路边界扫描测试系统
CN101515301A (zh) * 2008-02-23 2009-08-26 炬力集成电路设计有限公司 一种片上系统芯片验证的方法和装置
CN102129407A (zh) * 2011-03-09 2011-07-20 中国人民解放军国防科学技术大学 双精度simd部件芯片级验证测试激励自动生成方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8108745B2 (en) * 2009-08-20 2012-01-31 Honeywell International Inc. On-device constrained random verification for device development
CN101763451B (zh) * 2010-01-01 2012-07-18 江苏华丽网络工程有限公司 大规模网络芯片验证平台的建立方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6249893B1 (en) * 1998-10-30 2001-06-19 Advantest Corp. Method and structure for testing embedded cores based system-on-a-chip
CN1369714A (zh) * 2001-07-18 2002-09-18 中国人民解放军第二炮兵工程学院技术开发中心 大规模集成电路边界扫描测试系统
CN101515301A (zh) * 2008-02-23 2009-08-26 炬力集成电路设计有限公司 一种片上系统芯片验证的方法和装置
CN102129407A (zh) * 2011-03-09 2011-07-20 中国人民解放军国防科学技术大学 双精度simd部件芯片级验证测试激励自动生成方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111579959A (zh) * 2019-02-15 2020-08-25 深圳市汇顶科技股份有限公司 芯片验证方法、装置及存储介质
CN113254296A (zh) * 2021-06-25 2021-08-13 上海励驰半导体有限公司 芯片slt测试的软件实现方法及系统

Also Published As

Publication number Publication date
WO2013017037A1 (zh) 2013-02-07
CN102902834B (zh) 2015-12-09
CN102902834A (zh) 2013-01-30

Similar Documents

Publication Publication Date Title
WO2013016979A1 (zh) 一种soc芯片的验证方法及系统
US7950002B2 (en) Testing a software product by initiating a breakpoint and executing a probe routine
WO2020218870A1 (en) Electronic apparatus and method for controlling thereof
WO2019100638A1 (zh) 数据同步方法、装置、设备及存储介质
US7676355B1 (en) Method and apparatus for providing protected intellectual property
WO2015106497A1 (zh) 一种基于当前vcpu调度状态的动态中断均衡映射方法
US20140282431A1 (en) Native code profiler framework
WO2018076868A1 (zh) 一种数据同步方法、装置、系统、存储介质和服务器
WO2021118125A1 (ko) 안드로이드 어플리케이션에 의해 실행 가능한 보안 컨테이너 구축 장치, 방법 및 그 프로그램이 기록된 컴퓨터로 읽을 수 있는 기록매체
US20110138349A1 (en) Automated Digital Circuit Design Tool That Reduces or Eliminates Adverse Timing Constraints Due To An Inherent Clock Signal Skew, and Applications Thereof
Iskander et al. High-level abstractions and modular debugging for FPGA design validation
Wahler et al. Dynamic software updates for real-time systems
WO2015161645A1 (zh) 一种多媒体内容更改检测方法、装置及资源传播系统
WO2019024543A1 (zh) 代码生成方法、装置、代码生成器及可读存储介质
WO2019168265A1 (ko) 전자 장치, 전자 장치의 태스크 처리 방법 및 컴퓨터 판독 가능 매체
WO2018236141A1 (ko) 크래시 리포트 그룹핑 방법, 서버 및 컴퓨터 프로그램
WO2017035785A1 (zh) 一种内存泄漏的定位方法和装置
US10929584B1 (en) Environmental modification testing for design correctness with formal verification
WO2015119361A1 (ko) 클라우드 스트리밍 서비스 시스템, 클라우드 스트리밍 서비스 제공 방법 및 이를 위한 장치
WO2014135052A1 (zh) 一种高性能微处理器寄存器及其内存地址弹性保护方法
WO2016153288A9 (ko) 가상 클러스터 관리 시스템 및 이를 제어하기 위한 방법
Zhu et al. A timing verification framework for AUTOSAR OS component development based on real-time maude
WO2019200721A1 (zh) Sdk 兼容性检测方法、装置、设备及可读存储介质
Zhou et al. Save the Bruised Striver: A Reliable Live Patching Framework for Protecting Real-World PLCs
WO2016023509A1 (zh) 呈现文件的方法和文件呈现装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12820825

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12820825

Country of ref document: EP

Kind code of ref document: A1