Chip verification method, device, system, apparatus, medium and program

Abstract

This application provides a chip verification method, apparatus, system, device, medium, and program. The verification method includes: simulating a chip, the chip including a program execution module and a memory storage module, the program execution module running a software program, and the program file of the software program being stored in the memory storage module; executing simulation test cases to cause the program execution module to call the program file for processing; monitoring read and write events of the memory storage module during the process of the program execution module calling the program file to track changes in variables of the software program, wherein the memory storage module has a memory area allocated for the variables of the software program; synchronizing and displaying the changes in the variables to reflect the running state of the software program, the running state being used to determine whether the processing of the software program by the program execution module meets the design expectations. The verification method provided by this application implements hardware and software co-simulation verification of the chip.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a chip verification method, apparatus, system, device, medium, and program. Background Technology

[0002] With the rapid development of integrated circuit technology, chip design has become increasingly complex. Many chip designs include embedded processor cores (or other types of processor cores). These processor cores run specific software programs when the chip is working, and work together with other hardware logic within the chip to complete the expected functions. Therefore, for verification personnel, it is necessary to verify the hardware implementation of the processor core, as well as the software programs running on it, together with other hardware logic within the chip, as verification objects.

[0003] Against this backdrop, how to provide a chip verification method that can achieve joint software and hardware simulation verification of the chip has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] In view of this, embodiments of this application provide a chip verification method, apparatus, system, device, medium, and program, which can realize the joint simulation verification of chip software and hardware, allowing verification personnel to intuitively see the running status of the software program, thereby making it easier and more accurate to judge whether the program running module has achieved the expected function in processing the software program.

[0005] To achieve the above objectives, the embodiments of this application provide the following technical solutions.

[0006] In a first aspect, embodiments of this application provide a chip verification method, including:

[0007] The chip is simulated, and the chip includes a program execution module and a memory storage module. The program execution module is used to run software programs, and the program files of the software programs are stored in the memory storage module.

[0008] Execute the simulation test case so that the program execution module calls the program file for processing;

[0009] During the process of the program execution module calling the program file, the read and write events of the memory storage module are monitored to track the changes in the variables of the software program, wherein the memory storage module has a memory area allocated for the variables of the software program;

[0010] The changes in the variables are synchronized and displayed to reflect the running status of the software program. The running status is used to determine whether the processing of the software program by the program running module meets the design expectations.

[0011] Optional, also includes:

[0012] Establish an association between the monitor component and the read / write port of the memory storage module, so as to monitor the read / write events of the memory storage module using the monitor component;

[0013] Define a mirror register for the variable in the monitor component or test platform component. The mirror register for the variable is mapped to the memory area of ​​the variable so that when the value of the variable changes in the memory area of ​​the variable, the changed value is synchronously recorded in the mirror register for the variable.

[0014] Optionally, monitoring the read / write events of the memory storage module to track changes in the variables of the software program includes:

[0015] Based on the association between the monitor component and the read / write port, the monitor component is used to monitor whether there are read / write event signals on the read / write port;

[0016] If a read / write event signal is detected, based on the read / write address of the read / write event corresponding to the read / write event signal, the value of the variable involved in the read / write event is synchronized to the mirror register corresponding to the variable, wherein the read / write address corresponds to the address of the memory region of the variable involved.

[0017] Optionally, defining a mirror register corresponding to the variable in the monitor component or test platform component, so as to synchronously record the changed value of the variable to the mirror register when the value of the variable changes in the memory area of ​​the variable, includes:

[0018] Based on the address rules of the variables in the software program, a mirror register corresponding to the variable is defined in the monitor component or test platform component to add the variables of the software program to the corresponding mirror register.

[0019] Optionally, the variables include variables of various types; different memory regions correspond to address partitions for variables of various types;

[0020] The mirror registers are in array form, and each variable corresponds to an address mirror register and a data mirror register;

[0021] The address rules based on the variables of the software program, defining mirror registers corresponding to the variables in the monitor component or test platform component for adding the variables of the software program to the corresponding mirror registers, include:

[0022] Based on the address partitioning of the various types of variables, a mirror register array of various types of variables is defined in the monitor component or test platform component. The mirror register array of a type of variable includes the address mirror register and data mirror register corresponding to each variable under a type of variable.

[0023] The address mirror register corresponding to the variable is used to associate the address of the variable, and the data mirror register corresponding to the variable is used to synchronize the value of the variable.

[0024] Optional, also includes:

[0025] Use macro definitions for the index IDs of the image register arrays within the monitor or test platform components, represented by strings associated with the variable names.

[0026] Optionally, defining a mirror register corresponding to the variable in the monitor component or test platform component, so as to synchronously record the changed value of the variable to the mirror register when the value of the variable changes in the memory area of ​​the variable, includes:

[0027] Based on the correspondence between specific parameter values ​​and variables, the mirror register corresponding to the variable is defined in the monitor component;

[0028] When the data value of a read / write event is a specific parameter value, the variable value is synchronized in the mirror register corresponding to the variable with the specific parameter value.

[0029] Optionally, the various types of variables include: static variables, global variables, and temporary variables.

[0030] Optionally, demonstrating the changes in the variable includes:

[0031] Generate and display the waveform of the variable's change, which represents how the variable changes over time;

[0032] And / or, record the changes of the variables in the execution log of the simulation test case and display them.

[0033] Secondly, embodiments of this application provide a chip verification apparatus, comprising:

[0034] A preprocessing module is used to simulate the chip. The chip includes a program execution module and a memory storage module. The program execution module is used to run software programs, and the program files of the software programs are stored in the memory storage module.

[0035] The simulation test case execution module is used to execute simulation test cases so that the program execution module can call the program file for processing.

[0036] A read / write event tracking module is used to monitor the read / write events of the memory storage module during the process of the program running module calling the program file, so as to track the changes of variables in the software program, wherein the memory storage module has a memory area allocated for the variables of the software program;

[0037] The variable change synchronization and display module is used to synchronize and display the changes in the variables to reflect the running status of the software program. The running status is used to determine whether the processing of the software program by the program running module has met the design expectations.

[0038] Thirdly, embodiments of this application provide a chip verification system, including: a test platform, which is run via a simulator;

[0039] The test platform includes: a simulated chip and a verification environment module. The chip includes a program execution module and a memory storage module. The program execution module is used to run software programs, and the program files of the software programs are stored in the memory storage module.

[0040] The verification environment module includes at least a monitor component, used to monitor the read and write events of the memory storage module during the process of the program running module calling the program file, so as to track the changes in variables of the software program.

[0041] Fourthly, embodiments of this application provide a simulation device, including at least one memory and at least one processor, wherein the memory stores one or more computer-executable instructions, and the processor invokes the one or more computer-executable instructions to execute the chip verification method as described in the first aspect above.

[0042] Fifthly, embodiments of this application provide a storage medium that stores one or more computer-executable instructions, which, when executed, implement the chip verification method described in the first aspect above.

[0043] In a sixth aspect, embodiments of this application provide a computer program product including one or more computer-executable instructions, which, when executed, implement the chip verification method as described in the first aspect above.

[0044] As can be seen, the chip verification method provided in this application simulates a chip, which includes a program execution module and a memory storage module. The program execution module runs a software program, and the program file of the software program is stored in the memory storage module. Further, simulation test cases are executed so that the program execution module calls the program file for processing. During the process of the program execution module calling the program file, read and write events of the memory storage module are monitored to track changes in the variables of the software program. The memory storage module has a memory area allocated for the variables of the software program. When a change in a variable is detected, the change is synchronized and displayed to reflect the running state of the software program. This running state is used to determine whether the processing of the software program by the program execution module meets design expectations. In other words, the chip verification method provided in this application can track changes in the variables of the software program by monitoring the read and write events of the memory storage module. Furthermore, by synchronizing and displaying the change in a variable when it is detected, the running state of the software program can be reflected. Therefore, the chip verification method provided in this application embodiment can realize the joint simulation verification of chip software and hardware, so that the verification personnel can intuitively see the running status of the software program, thereby making it easier and more accurate to judge whether the program running module has achieved the expected function in processing the software program. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0046] Figure 1 This is a schematic flowchart of the chip verification method provided in the embodiments of this application;

[0047] Figure 2 This is a schematic diagram showing the correspondence between variable address partitioning and the mirror register array;

[0048] Figure 3 An example diagram of an optional structure of the chip verification apparatus provided in the embodiments of this application;

[0049] Figure 4 This is an example diagram of an optional structure of the chip verification system provided in an embodiment of this application. Detailed Implementation

[0050] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0051] With the rapid development of integrated circuit technology, chip design is becoming increasingly complex, and more and more chip designs include embedded processor cores or other types of processor cores. These processor cores run specific software programs when the chip is working, and work together with other hardware logic within the chip (such as memory, peripheral interfaces, accelerators, etc.) to achieve the expected functions. This tight coupling between hardware and software makes the functional verification of chips face challenges.

[0052] Current chip verification methods primarily rely on hardware simulation techniques, such as VCS (Verilog Compiled Simulator). These tools analyze hardware logic implemented in hardware description languages ​​like Verilog or VHDL, recording signal changes over time and presenting them as waveforms. Users can then graphically view these changes. However, software programs running within embedded processor cores are written in C or machine language. VCS and similar simulation tools cannot directly perceive or record the execution state of these programs. Furthermore, the software's execution logic, data flow, and hardware-software interactions cannot be directly observed and debugged using waveform analysis.

[0053] Therefore, verifying chips containing embedded processor cores (or other types of processor cores) places high demands on verification personnel. They must have a deep understanding of C or assembly language, be able to analyze the execution flow and data flow of software programs, and master the technology of simulation based on hardware simulation platforms, be able to analyze the signal changes and timing relationships of hardware logic. Only by organically combining hardware simulation and software debugging can the functional correctness and performance indicators of the chip be fully and accurately verified, ensuring the quality of verification.

[0054] One hardware-software joint debugging scheme involves obtaining the address of the software instruction being executed by the hardware at the moment the waveform corresponding to the hardware logic is running, and then finding the corresponding software function or code statement based on that address. This scheme can present the correspondence between the address of the instruction executed by the hardware and the software code file, function, or code statement in various forms; and based on the address of the instruction executed by the hardware displayed at a certain moment on the waveform, find the software file, function, or code statement corresponding to that address; and then analyze the actual operating state of the hardware under test after the software code function or statement is applied to the hardware under test at that specific moment on the waveform.

[0055] However, the aforementioned hardware-software joint debugging scheme can only establish the call relationship between the waveform of the hardware under test system at a certain moment and the software function or statement code. It reveals the software function or statement corresponding to the currently executed software instruction, and the order in which these functions or statements are called during program execution. Further analysis of the correctness of the software function or statement's functionality relies solely on manual analysis of the semantic logic of the software code itself, and on experience to determine whether the software's implementation achieves the expected hardware behavior. In other words, this scheme cannot specifically display the addresses and parameter values ​​and changes of the software code's internal variables, nor can it establish or display the specific relationship between the addresses and parameters of the software code's internal variables and the signals of the hardware under test system. Therefore, it cannot determine whether the software program's action on the chip's hardware logic achieves the expected function.

[0056] Furthermore, since data within software programs cannot be displayed as intuitively as hardware logic signals through waveforms, if it is necessary to trace the addresses or parameters of software program variables during verification, verification personnel or developers often need to develop temporary scripts or C language code on the software program under test to write the software data to be traced into specific registers provided by the hardware logic to the software program. Only then can the software data be traced in the hardware waveform through the signals of those hardware registers. However, if temporary scripts or code are to be developed, due to different projects or different debugging requirements within the same project, each new debugging requires tedious manual coding. Moreover, if it is necessary to trace the value of a variable in the software program at different locations during program execution, write operation code needs to be added to the context of each function or statement at the desired location in the software code to write the desired software data into the registers provided by the hardware, which increases the workload and makes it easy to miss. In addition, after debugging, the temporary scripts or code added for debugging need to be deleted, which is inconvenient for version maintenance.

[0057] In view of this, the present application provides a chip verification method that can realize the joint simulation verification of the chip's hardware and software, allowing verification personnel to intuitively see the running status of the software program, thereby making it easier and more accurate to judge whether the software program's action on the hardware logic on the chip achieves the expected function.

[0058] like Figure 1 As shown, Figure 1 This is a schematic flowchart of the chip verification method provided in the embodiments of this application. The verification method includes the following steps.

[0059] Step S101: Simulate the chip, which includes a program execution module and a memory storage module. The program execution module is used to run software programs, and the program files of the software programs are stored in the memory storage module.

[0060] Before executing simulation test cases, preprocessing operations are required to build a simulation environment that meets the simulation verification requirements. Specifically, the chip is simulated first. The chip includes a program execution module and a memory storage module. The program execution module may include the hardware logic module of the processor core embedded in the chip, other hardware logic modules that interact with the processor core, etc.

[0061] In this embodiment, the program execution module and memory storage module on the chip can be implemented using a hardware description language (HDL) such as Verilog or VHDL. The program execution module may include: a hardware logic module of the processor core embedded in the chip described in Verilog, and one or more other hardware logic modules on the chip. The simulation process of the program execution module may include defining the above-mentioned hardware logic modules and describing the module behavior using HDL. The memory storage module may include a storage medium for storing software programs. The simulation of the memory storage module can simulate memory read and write operations, including defining memory types and writing memory models.

[0062] The program execution module can be used to run software programs, and the program files of the software programs are stored in the memory storage module. Before executing simulation test cases, the program files of the software programs to be verified need to be stored in the memory storage module.

[0063] Specifically, the software program that the processor core needs to run is first compiled into a corresponding file format that can be programmed or stored in a storage medium. After compilation, a program file corresponding to the software program is generated. This type of file data corresponds to the machine language instructions that the processor can execute. Then, on a hardware simulation platform based on the processor core hardware processing logic and other hardware logic in the chip, the aforementioned program file that can be programmed or stored in the storage medium is stored in the storage medium. The storage medium is the memory space allocated by the simulation platform to the memory storage module used for simulation. Thus, through the above process, the program file of the software program to be verified can be stored in the memory storage module. The storage medium may include read-only memory (ROM) or static random-access memory (SRAM), etc.

[0064] Furthermore, embodiments of this application can build a simulation platform, such as a chip simulation platform based on VCS (Verilog Compiled Simulator) and UVM (Universal Verification Methodology). The chip simulation platform includes: a test bench, a device under test (DUT), a verification environment module, scripts for compiling software programs, etc.

[0065] The verification environment module can be the uvm_env component. uvm_env is an important component, serving as the top-level container of the testing platform. It is used to build the verification environment and organize and manage all components within the testing platform.

[0066] The device under test (DUT) may include: a program execution module of the simulated chip, a software program to be executed by the program execution module, and one or more other hardware logic modules on the simulated chip. The program file of the software program is generated by compiling the software program to be executed by the processor using the script used to compile the software program, and the program file is stored in the memory storage module of the simulated chip. In this embodiment, the definition of the DUT can be completed during the above preprocessing process.

[0067] Step S102: Execute the simulation test case so that the program execution module calls the program file for processing.

[0068] After completing the construction of the simulation platform, simulation test cases are executed based on the simulation platform. In specific implementation, the file data of the program file in the storage medium, i.e. the instruction content, can be read according to the simulated program execution module.

[0069] In this embodiment of the application, during the process of compiling and generating the program file, the compiled file also includes a disassembly file with the suffix .dis. The content of the disassembly file is a list of assembly instruction addresses and instruction contents after the software program is compiled, which corresponds one-to-one with the program source code written in C language. That is, the mapping relationship is: assembly language instruction <-> C language source code.

[0070] Therefore, when reading the instruction content in the program file, it is possible to determine which instruction of the software program is being executed based on the disassembled file, and the function or statement of the software program corresponding to the instruction can be associated with the disassembled file.

[0071] Furthermore, after reading the instruction content in the program file, the program execution module, such as the hardware logic module of the processor core embedded in the chip, can parse and execute the corresponding instructions according to the instruction set corresponding to the processor; wherein, the instruction execution process includes: allocating stack space for the program's variable operators according to the program's preset rules, and sending read / write or control signals from the simulated hardware logic module to other hardware logic modules on the simulated chip.

[0072] Step S103: During the process of the program running module calling the program file, the read and write events of the memory storage module are monitored to track the changes in the variables of the software program, wherein the memory storage module has a memory area allocated for the variables of the software program.

[0073] In this embodiment, the stack space allocated for the instruction during instruction execution is a dynamically allocated memory region during program runtime, corresponding to the SRAM or other memory space on the simulated chip, and there is a mapping relationship between the two. Therefore, the data exchange between the program and the SRAM during execution can be observed from the simulated read / write port signals of the memory space, such as the SRAM. Thus, by tracking and analyzing the read / write events of the SRAM read / write port, the variables of the software program can be tracked and recorded.

[0074] In an optional implementation, during the process of the program execution module calling the program file, the read and write events of the memory storage module can be monitored to track the changes in the variables of the software program. By observing the changes in these variables, it can be determined whether the processing of the software program by the program execution module has achieved the expected function.

[0075] The following section details the method for tracking variables by monitoring the read and write ports of the simulated memory storage module.

[0076] In this embodiment, the uvm_env component may include: a monitor component, which can be used to monitor the interface of the DUT and collect transactions for further analysis; a driver component, which is used to simulate external stimuli and control the input signals of the DUT; a scoreboard component, which is used to check whether the output of the DUT meets expectations; and a reference model component, which is used to simulate the ideal behavior of the DUT and generate the expected output. These components can be written in the SystemVerilog language, similar to the hardware logic language Verilog.

[0077] The monitor component can be connected to the read / write port of the simulated memory storage module through an interface, and the variables on the read / write port can be displayed intuitively by waveform. Therefore, in this embodiment, the monitor component can be used to track the read / write event signals of the memory storage module, such as the read / write control signal, address signal, and write data and read data signals of SRAM.

[0078] In an optional implementation, before using the monitor component to monitor the read and write events of the memory storage module, it is necessary to first establish the association between the monitor component and the read and write ports of the memory storage module. Also, the monitor component or test platform component defines the mirror register corresponding to the variable. The mirror register corresponding to the variable has a mapping relationship with the memory area of ​​the variable. Thus, when the value of the variable changes in the memory area of ​​the variable, the changed value of the variable can be synchronously recorded in the mirror register corresponding to the variable.

[0079] When monitoring changes in variables within a software program, it's necessary to simultaneously record these changes to facilitate subsequent display and reflect the program's operational status. Therefore, this can be achieved by defining mirror registers for the variables within the monitor or test platform component, allowing the mirror registers to record and reflect the current variable values.

[0080] Furthermore, after establishing the association between the ports and defining the mirror register, the monitor component can be used to monitor whether there is a read / write event signal on the read / write port based on the association between the monitor component and the read / write port. If a read / write event signal is detected, the value of the variable involved in the read / write event is synchronized to the mirror register corresponding to the variable based on the read / write address of the read / write event corresponding to the read / write event signal. The read / write address corresponds to the address of the memory region of the variable involved.

[0081] In the embodiments of this application, when defining the mirror register corresponding to the variable in the monitor component or test platform component, it is necessary to implement the mapping between the data in the software program and the mirror register array in the monitor component or test platform component based on the corresponding synchronization rules, so as to ensure the consistency, predictability and verifiability of mirror register operation.

[0082] In one optional example, address allocation principles can be used to map data within the software program to mirrored register arrays in the monitor or test platform components.

[0083] In an optional implementation, the step of defining a mirror register corresponding to the variable in the monitor component or test platform component so as to synchronously record the changed value of the variable to the mirror register corresponding to the variable when the value of the variable changes in the memory area of ​​the variable may include: defining a mirror register corresponding to the variable in the monitor component or test platform component based on the address rules of the variable of the software program so as to add the variable of the software program to the corresponding mirror register.

[0084] In the embodiments of this application, the variables may include variables of various types, and different memory regions correspond to address partitions of various types of variables; wherein, the various types of variables may include: static variables, global variables, and temporary variables.

[0085] In specific implementation, during the execution of the above instructions, the allocation of stack space for the program's variable operators according to the program's preset rules refers to the address partitioning of temporary variables, global variables, and static variables in the memory space (e.g., SRAM) preset by the software program, with different memory regions corresponding to address partitions of different types of variables.

[0086] Furthermore, in the embodiments of this application, the mirror register can be in the form of an array, and one variable corresponds to an address mirror register and a data mirror register.

[0087] In an optional implementation, based on the address partitioning of the various types of variables, a mirror register array of various types of variables is defined in the monitor component or test platform component. The mirror register array of a type of variable includes the address mirror register and the data mirror register corresponding to each variable under that type of variable. The address mirror register corresponding to the variable is used to associate the address of the variable, and the data mirror register corresponding to the variable is used to synchronize the variable value.

[0088] Specifically, in this embodiment of the application, register arrays for storing addresses and data can be defined in the monitor component or test platform component according to the rules for static and global variables defined in the code. The registers corresponding to the elements in these two arrays serve as the addresses and values ​​of the mirror registers of the aforementioned static or global variables, thereby adding the information of the static and global variables to be tracked to the monitor component or test platform component. When a read / write event occurs, if the address of the memory space is equal to the address of the aforementioned static or global variable, the mirror register in the monitor component can make a synchronous change, thereby recording the change in the value of the aforementioned static or global variable.

[0089] In an optional example, the format of the mirror register variable array defined in the monitor component or test platform component is as follows: reg[31:0]sram_addr[index], reg[31:0]sram_data[index], where sram_addr[index] represents the address in the mirror register array corresponding to the register variable reg[31:0], and sram_data[index] represents the data in the mirror register array corresponding to the register variable reg[31:0].

[0090] In this embodiment, the monitor component or test platform component also needs to perform initialization processing on the sram_addr[index] and sram_data[index] arrays. The initialization rules can be based on the address partitioning of temporary variables, global variables, and static variables in the memory space as preset by the software program.

[0091] In an optional example, such as Figure 2 As shown, Figure 2 This is a schematic diagram showing the correspondence between variable address partitioning and mirror register arrays. The first m mirror register arrays in the monitor component (including sram_addr[0], sram_data[0] to sram_addr[m], sram_data[m]) correspond to memory space such as the global variable area of ​​the software program stored in SRAM. The mirror register arrays from m+1 to n (including sram_addr[m+1], sram_data[m+1] to sram_addr[n], sram_data[n]) correspond to the variable area inside the function (such as static variables or temporary variables).

[0092] In an optional implementation, the index ID of the mirror register array within the monitor component or test platform component can be defined using macros. This can be represented by a string associated with the variable name, which can improve code readability and reusability. For example, if the global variable Config1 inside the software program is defined as "define CONFIG10" within the monitor component or test platform component, then sram_addr[CONFIG1] and sram_data[CONFIG1] represent the address and data of the global variable Config1 inside the software program.

[0093] In another alternative example, the write parameter principle can be used to map data within the software program to the mirror register array in the monitor component or test platform component.

[0094] In an optional implementation, the step of defining a mirror register corresponding to the variable in the monitor component or test platform component so as to synchronously record the changed value of the variable to the mirror register corresponding to the variable when the value of the variable changes in the memory area of ​​the variable may include: defining a mirror register corresponding to the variable in the monitor component based on the correspondence between a specific parameter value and the variable; and synchronizing the variable value in the mirror register corresponding to the variable corresponding to the specific parameter value when the data value of the read / write event is a specific parameter value.

[0095] In other words, when a read or write event occurs, if the written or read data in the memory space (such as SRAM) is equal to a specific parameter value configured in the software program, it can be inferred which variable in the software program is being read or written by the current read or write event. Thus, a mirror register is allocated to correspond to the variable inside this software program, and the corresponding variable value is recorded.

[0096] Therefore, in the embodiments of this application, the mapping between data in the software program and register arrays in the monitor component or test platform component can be achieved through address allocation principles or write parameter principles.

[0097] In other embodiments, other synchronization principles may be employed to achieve the mapping between data within the software program and register arrays in the monitor component or test platform component.

[0098] Step S104: Synchronize and display the changes in the variables to reflect the running status of the software program. The running status is used to determine whether the processing of the software program by the program running module meets the design expectations.

[0099] When the value of the variable changes in the mirror register corresponding to the variable, various different methods can be used to display the changes in the variable to reflect the running status of the software program. This allows verification personnel to more intuitively observe and judge whether the processing of the software program by the program running module has achieved the expected function, that is, to judge whether the software program's action on the hardware logic on the chip has achieved the expected function.

[0100] In an optional implementation, the way to display the changes in the variable may include: generating and displaying a waveform of the variable's changes, the waveform representing how the variable changes over time; and / or recording and displaying the changes in the variable in the execution log of the simulation test case.

[0101] By using the two methods described above, it is possible to obtain the changes in internal software variables at any point during waveform execution within the monitoring component, transforming the internal software variable changes that cannot be displayed intuitively into numerical information that can be seen intuitively from the waveform or logs.

[0102] In the simulation log of the test cases, the processor can read the address of the instruction stored in the storage medium, and use a scripting language to find the corresponding C language source code content from the disassembled file. The source code content displayed in the disassembled file includes the file name and line number of the source code. Then, the file name and line number of the source code content are stored in a string, and the string is printed to the test case execution log. At the same time, through the monitor component or test platform component, the variables in the analyzed C language code can be synchronously printed to the corresponding instructions, so that the verifier can obtain the waveform of the variables corresponding to the C language function or statement at any time.

[0103] As can be seen, the chip verification method provided in this application simulates a chip, which includes a program execution module and a memory storage module. The program execution module runs a software program, and the program file of the software program is stored in the memory storage module. Further, simulation test cases are executed so that the program execution module calls the program file for processing. During the process of the program execution module calling the program file, read and write events of the memory storage module are monitored to track changes in the variables of the software program. The memory storage module has a memory area allocated for the variables of the software program. When a change in a variable is detected, the change is synchronized and displayed to reflect the running state of the software program. This running state is used to determine whether the processing of the software program by the program execution module meets design expectations. In other words, the chip verification method provided in this application can track changes in the variables of the software program by monitoring the read and write events of the memory storage module. Furthermore, by synchronizing and displaying the change in a variable when it is detected, the running state of the software program can be reflected. Therefore, the chip verification method provided in this application embodiment can realize the joint simulation verification of chip software and hardware, so that the verification personnel can intuitively see the running status of the software program, thereby making it easier and more accurate to judge whether the program running module has achieved the expected function in processing the software program.

[0104] In a further optional implementation, based on the chip verification method provided in the embodiments of this application, the embodiments of this application also provide a chip verification device. The chip verification device described below can be referred to in correspondence with the chip verification method described above. In an optional implementation, Figure 3 This is an example diagram of an optional structure of the chip verification apparatus provided in an embodiment of this application. (Refer to...) Figure 3 The device may include:

[0105] The preprocessing module 301 is used to simulate the chip. The chip includes a program execution module and a memory storage module. The program execution module is used to run a software program, and the program file of the software program is stored in the memory storage module.

[0106] The simulation test case execution module 302 is used to execute simulation test cases so that the program execution module can call the program file for processing;

[0107] The read / write event tracking module 303 is used to monitor the read / write events of the memory storage module during the process of the program running module calling the program file, so as to track the changes of variables in the software program, wherein the memory storage module has a memory area allocated for the variables of the software program;

[0108] The variable change synchronization and display module 304 is used to synchronize and display the variable changes to reflect the running status of the software program. The running status is used to determine whether the processing of the software program by the program running module has met the design expectations.

[0109] In an optional implementation, the chip verification apparatus further includes:

[0110] The association establishment module is used to establish the association between the monitor component and the read / write port of the memory storage module, so as to use the monitor component to monitor the read / write events of the memory storage module.

[0111] The mirror register definition module is used to define mirror registers corresponding to variables in the monitor component or test platform component. The mirror registers corresponding to variables are mapped to the memory area of ​​variables so that when the value of a variable changes in the memory area of ​​the variable, the changed value of the variable is synchronously recorded in the mirror registers corresponding to the variable.

[0112] In an optional implementation, the read / write event tracking module 303 is used to monitor the read / write events of the memory storage module to track changes in the variables of the software program, including:

[0113] Based on the association between the monitor component and the read / write port, the monitor component is used to monitor whether there are read / write event signals on the read / write port;

[0114] If a read / write event signal is detected, based on the read / write address of the read / write event corresponding to the read / write event signal, the value of the variable involved in the read / write event is synchronized to the mirror register corresponding to the variable, wherein the read / write address corresponds to the address of the memory region of the variable involved.

[0115] In an optional implementation, the mirror register definition module is used to define mirror registers corresponding to variables in the monitor component or test platform component, so that when the value of a variable changes in its memory area, the changed value is synchronously recorded to the corresponding mirror register, including:

[0116] Based on the address rules of the variables in the software program, a mirror register corresponding to the variable is defined in the monitor component or test platform component to add the variables of the software program to the corresponding mirror register.

[0117] In an optional implementation, the variables include variables of various types; different memory regions correspond to address partitions for variables of various types;

[0118] The mirror registers are in array form, and each variable corresponds to an address mirror register and a data mirror register;

[0119] The mirror register definition module is used to define mirror registers corresponding to variables in the monitor component or test platform component based on the address rules of the variables in the software program, for adding the variables of the software program to the corresponding mirror registers, including:

[0120] Based on the address partitioning of the various types of variables, a mirror register array of various types of variables is defined in the monitor component or test platform component. The mirror register array of a type of variable includes the address mirror register and data mirror register corresponding to each variable under a type of variable.

[0121] The address mirror register corresponding to the variable is used to associate the address of the variable, and the data mirror register corresponding to the variable is used to synchronize the value of the variable.

[0122] In an optional implementation, the mirror register definition module is also used for:

[0123] Use macro definitions for the index IDs of the image register arrays within the monitor or test platform components, represented by strings associated with the variable names.

[0124] In an optional implementation, the mirror register definition module is used to define mirror registers corresponding to variables in the monitor component or test platform component, so that when the value of a variable changes in its memory area, the changed value is synchronously recorded to the corresponding mirror register, including:

[0125] Based on the correspondence between specific parameter values ​​and variables, the mirror register corresponding to the variable is defined in the monitor component;

[0126] When the data value of a read / write event is a specific parameter value, the variable value is synchronized in the mirror register corresponding to the variable with the specific parameter value.

[0127] In an optional implementation, the various types of variables include: static variables, global variables, and temporary variables.

[0128] In an optional implementation, the variable change synchronization and display module 304, used to display the variable change status, includes:

[0129] Generate and display the waveform of the variable's change, which represents how the variable changes over time;

[0130] And / or, record the changes of the variables in the execution log of the simulation test case and display them.

[0131] In a further optional implementation, this application embodiment also provides a chip verification system. In an optional implementation, Figure 4 This is an example diagram of an optional structure of the chip verification system provided in an embodiment of this application. (Refer to...) Figure 4The chip verification system may include: a test platform 400, which runs via a simulator;

[0132] The test platform 400 includes: a simulated chip 410 and a verification environment module 420. The chip 410 includes a program running module and a memory storage module 411. The program running module is used to run software programs, and the program files of the software programs are stored in the memory storage module 411.

[0133] The verification environment module 420 includes at least a monitor component 421, which is used to monitor the read and write events of the memory storage module 411 during the process of the program running module calling the program file, so as to track the changes in variables of the software program.

[0134] In the optional implementation, combined Figure 4 As shown, the simulated program execution module may include the simulated embedded processor core 412, and other simulated hardware logic modules 1 to n within the chip; the simulated chip 410 also includes simulated bus control logic 413, which is used to coordinate the communication between the various simulated modules.

[0135] In an optional implementation, the verification environment module 420 may also include other simulation components 422 to 42n, such as: a driver component for simulating external stimuli and controlling the input signals of the DUT; a scoreboard component for checking whether the output of the DUT meets expectations; and a reference model component for simulating the ideal behavior of the DUT and generating the expected output, etc.

[0136] In a further optional implementation, this application embodiment also provides a simulation device, including at least one memory and at least one processor, wherein the memory stores one or more computer-executable instructions, and the processor invokes the one or more computer-executable instructions to execute the chip verification method as described in the foregoing embodiments.

[0137] In a further optional implementation, this application embodiment also provides a storage medium that stores one or more computer-executable instructions, which, when executed, implement the chip verification method as described in the foregoing embodiments.

[0138] In a further optional implementation, this application embodiment also provides a computer program product, including one or more computer-executable instructions, which, when executed, implement the chip verification method as described in the foregoing embodiments.

[0139] The foregoing describes multiple embodiment schemes provided by the embodiments of this application. The optional methods described in each embodiment scheme can be combined and cross-referenced with each other without conflict, thereby extending to a variety of possible embodiment schemes. These can all be considered as the embodiment schemes disclosed and published by the embodiments of this application.

[0140] While the embodiments disclosed above are described in this application, this application is not limited thereto. Any person skilled in the art can make various modifications and alterations without departing from the spirit and scope of this application; therefore, the scope of protection of this application should be determined by the scope defined in the claims.

Claims

1. A chip verification method, characterized in that, include: The chip is simulated, and the chip includes a program execution module and a memory storage module. The program execution module is used to run software programs, and the program files of the software programs are stored in the memory storage module. Execute the simulation test case so that the program execution module calls the program file for processing; During the process of the program execution module calling the program file, the read and write events of the memory storage module are monitored to track the changes in the variables of the software program, wherein the memory storage module has a memory area allocated for the variables of the software program; The changes in the variables are synchronized and displayed to reflect the running status of the software program. The running status is used to determine whether the processing of the software program by the program running module meets the design expectations. The monitor component is associated with the read / write port of the memory storage module. The monitor component or test platform component defines a mirror register for the variable, and the mirror register maps to the memory region of the variable. Monitoring the read / write events of the memory storage module to track changes in the software program's variables includes: Based on the aforementioned relationship, a monitor component is used to monitor whether read / write event signals exist at the read / write port; If a read / write event signal is detected, based on the read / write address of the read / write event, the value of the variable whose memory region has changed is synchronized to a mirror register that has a mapping relationship with the memory region of the variable, wherein the read / write address corresponds to the address of the memory region of the variable whose value has changed.

2. The chip verification method according to claim 1, characterized in that, Also includes: Establish an association between the monitor component and the read / write port of the memory storage module, so as to monitor the read / write events of the memory storage module using the monitor component; Define a mirror register for the variable in the monitor component or test platform component. The mirror register for the variable is mapped to the memory area of ​​the variable so that when the value of the variable changes in the memory area of ​​the variable, the changed value is synchronously recorded in the mirror register for the variable.

3. The chip verification method according to claim 1, characterized in that, The step of defining a mirror register corresponding to a variable in the monitor component or test platform component, so as to synchronously record the changed value of the variable to the corresponding mirror register when the value of the variable changes in the memory area of ​​the variable, includes: Based on the address rules of the variables in the software program, a mirror register corresponding to the variable is defined in the monitor component or test platform component to add the variables of the software program to the corresponding mirror register.

4. The chip verification method according to claim 3, characterized in that, The variables include variables of various types; different memory regions correspond to address partitions for variables of various types. The mirror registers are in array form, and each variable corresponds to an address mirror register and a data mirror register; The address rules based on the variables of the software program, defining mirror registers corresponding to the variables in the monitor component or test platform component for adding the variables of the software program to the corresponding mirror registers, include: Based on the address partitioning of the various types of variables, a mirror register array of various types of variables is defined in the monitor component or test platform component. The mirror register array of a type of variable includes the address mirror register and data mirror register corresponding to each variable under a type of variable. The address mirror register corresponding to the variable is used to associate the address of the variable, and the data mirror register corresponding to the variable is used to synchronize the value of the variable.

5. The chip verification method according to claim 4, characterized in that, Also includes: Use macro definitions for the index IDs of the image register arrays within the monitor or test platform components, represented by strings associated with the variable names.

6. The chip verification method according to claim 2, characterized in that, The step of defining a mirror register corresponding to a variable in the monitor component or test platform component, so as to synchronously record the changed value of the variable to the corresponding mirror register when the value of the variable changes in the memory area of ​​the variable, includes: Based on the correspondence between specific parameter values ​​and variables, the mirror register corresponding to the variable is defined in the monitor component; When the data value of a read / write event is a specific parameter value, the variable value is synchronized in the mirror register corresponding to the variable with the specific parameter value.

7. The chip verification method according to claim 4, characterized in that, The various types of variables include: static variables, global variables, and temporary variables.

8. The chip verification method according to claim 1, characterized in that, The demonstration of the changes in the variables includes: Generate and display the waveform of the variable's change, which represents how the variable changes over time; And / or, record the changes of the variables in the execution log of the simulation test case and display them.

9. A chip verification device, characterized in that, include: A preprocessing module is used to simulate the chip. The chip includes a program execution module and a memory storage module. The program execution module is used to run software programs, and the program files of the software programs are stored in the memory storage module. The simulation test case execution module is used to execute simulation test cases so that the program execution module can call the program file for processing. A read / write event tracking module is used to monitor the read / write events of the memory storage module during the process of the program running module calling the program file, so as to track the changes of variables in the software program, wherein the memory storage module has a memory area allocated for the variables of the software program; The variable change synchronization and display module is used to synchronize and display the changes of the variables to reflect the running status of the software program. The running status is used to determine whether the processing of the software program by the program running module has met the design expectations. The monitor component is associated with the read / write port of the memory storage module. The monitor component or test platform component defines a mirror register for the variable, and the mirror register maps to the memory region of the variable. Monitoring the read / write events of the memory storage module to track changes in the software program's variables includes: Based on the aforementioned relationship, a monitor component is used to monitor whether read / write event signals exist at the read / write port; If a read / write event signal is detected, based on the read / write address of the read / write event, the value of the variable whose memory region has changed is synchronized to a mirror register that has a mapping relationship with the memory region of the variable, wherein the read / write address corresponds to the address of the memory region of the variable whose value has changed.

10. A chip verification system, characterized in that, include: The test platform is run via a simulator; The test platform includes: a simulated chip and a verification environment module. The chip includes a program execution module and a memory storage module. The program execution module is used to run software programs, and the program files of the software programs are stored in the memory storage module. The verification environment module includes at least a monitor component, used to monitor the read and write events of the memory storage module during the process of the program running module calling the program file, so as to track the changes in variables of the software program; The monitor component is associated with the read / write port of the memory storage module. The monitor component or test platform component defines a mirror register for the variable, and the mirror register maps to the memory region of the variable. Monitoring the read / write events of the memory storage module to track changes in the software program's variables includes: Based on the aforementioned relationship, a monitor component is used to monitor whether read / write event signals exist at the read / write port; If a read / write event signal is detected, based on the read / write address of the read / write event, the value of the variable whose memory region has changed is synchronized to a mirror register that has a mapping relationship with the memory region of the variable, wherein the read / write address corresponds to the address of the memory region of the variable whose value has changed.

11. A simulation device, characterized in that, It includes at least one memory and at least one processor, the memory storing one or more computer-executable instructions, and the processor invoking the one or more computer-executable instructions to perform the chip verification method as described in any one of claims 1-8.

12. A storage medium, characterized in that, The storage medium stores one or more computer-executable instructions, which, when executed, implement the chip verification method as described in any one of claims 1-8.

13. A computer program product, characterized in that, It includes one or more computer-executable instructions, which, when executed, implement the chip verification method as described in any one of claims 1-8.

Images