Chip verification method and system with software and hardware cooperation

Abstract

The application discloses a kind of hardware and software collaborative chip verification method and system, by being pre-constructed as executable software program that can be called by system command to reference model, the reference model is integrated by multiple levels of sub-reference model, the function of each sub-reference model is consistent with corresponding level submodule in the chip DUT to be measured;Stimulus signal is input to DUT to start verification;When DUT executes to preset stage, signal conversion module converts hardware signal format information of DUT into software readable format, generates software excitation information, and generates calculation result by calling corresponding sub-reference model for simulation calculation through system call command;After the corresponding level module of DUT outputs result, it is converted into software readable format;The calculation result is compared with the DUT output result after format conversion, to verify whether the function of DUT meets the expectation or not.So, the application reduces the integration complexity of reference model and DUT, realizes the efficient conversion of hardware and software format information, improves problem positioning efficiency.

Description

Technical Field

[0001] This invention belongs to the field of chip verification technology, and in particular relates to a hardware and software collaborative chip verification method and system. Background Technology

[0002] Traditional chip verification environments mainly consist of a Design Under Test (DUT) and a Reference Model (RM). During verification, the RM reads the DUT signals in real time and performs behavioral simulations simultaneously. Finally, the outputs of the RM and DUT are compared by a comparison module to determine whether the DUT's functionality meets expectations.

[0003] Traditional memory managers (RMs) typically have two build methods. One is using hardware languages ​​like SystemVerilog, which allows for rapid comparison with the device under test (DUT), but also suffers from long development cycles and low debugging efficiency. The other is using software languages ​​like C / C++, but this requires cross-compilation via tools like DPI to integrate it into the hardware DUT's verification environment, increasing compatibility and compilation complexity. Both build methods require compilation along with the hardware DUT's source code files to complete the integration of the DUT and the RM.

[0004] While the aforementioned verification process is mature, with the increasing complexity of chip design, traditional RM construction methods and RM-DUT interaction and comparison methods are gradually becoming insufficient to meet verification requirements. Traditional RM-DUT communication can only be achieved through fixed data formats such as the integrated DPI interface. However, with the proliferation of application areas, various RMs generated in different languages ​​have emerged. These RMs cannot directly interact with the DUT via traditional DPI or hardware signals, resulting in a lack of flexibility in the current approach. Furthermore, the RM typically functions as a functional "black box," only providing the final result through the comparison module, lacking the recording and comparison of intermediate process data, making it difficult to effectively locate problematic modules.

[0005] Existing patent CN120874706A provides a chip verification method, apparatus, system, device, medium, and program. When verifying chips containing embedded processor cores (or other types of processor cores), it allows verifiers to intuitively observe the software program's running status, thus more conveniently and accurately determining whether the software program's action on the chip's hardware logic achieves the expected function, facilitating the observation of the software's running status. This patent solves the problem of the difficulty in observing the hardware's running status; however, the construction and integration of the reference model still relies on the traditional cross-compilation DPI interface method, which makes it difficult to guarantee development efficiency, and the RM lacks the flexibility to support scenarios with multiple kernel programs.

[0006] A prior patent with publication number CN120874702A proposes a chip verification method, apparatus, device, and storage medium that further decomposes a reference model into sub-models to facilitate comparison of intermediate signals with the sub-modules of the device under test (DUT). While this patent can improve problem localization efficiency, the sub-models in the reference model still rely on the traditional cross-compilation integration method with the DUT. This results in the interaction between the RM and the DUT requiring signal conversion via a DPI interface. As the number of sub-models increases, the overhead caused by the conversion also increases, leading to inefficient interaction between the RM and the DUT.

[0007] Existing patent CN120874704A proposes a multilingual data interaction structure and a chip verification IP and verification system containing it, providing a multilingual interactive verification environment that facilitates interaction between components developed in multiple language environments. While this patent offers an interaction method between the RM and DUT, it relies on API / DPI interface function calls, requiring joint cross-compilation between the RM and DUT, increasing the integration complexity of the RM and DUT, and lacks an efficient intermediate problem localization mechanism.

[0008] In response to the current chip verification process, where the RM and DUT are integrated through cross-compilation and rely on DPI interfaces for interaction, and lack efficient intermediate result comparison, this patent proposes a method and system for joint hardware and software verification.

[0009] During chip verification research, it was found that in existing technologies, to ensure compatibility with hardware DUT integration, software reference models generally require implementation using hardware programming languages ​​such as SystemVerilog / UVM, causing significant inconvenience for software developers. Furthermore, the reference model frequently interacts with the DUT, leading to the overhead of hardware-software interaction caused by cross-compilation in traditional solutions. Finally, the traditional method of simply comparing the final results of the reference model and the DUT is not conducive to locating problematic code in the DUT. Through investigation of existing technical solutions, the main reasons for these shortcomings were found to be: 1. Failure to consider the increasingly complex functions of modern reference models, requiring more efficient software development environments compared to hardware programming styles, such as patent CN120874706A; 2. In existing technical solutions, such as patent CN120874704A, the interaction between the reference model and the DUT mainly relies on signal / variable transmission after integration, failing to consider the increased complexity during the integration process; 3. Lack of efficient comparison of intermediate process data, resulting in verification personnel lacking efficient means to locate problems, such as patent CN120874702A.

[0010] Therefore, there is an urgent need for a method that can effectively solve the above-mentioned technical problems. Summary of the Invention

[0011] To address the issues of high integration complexity between the reference model and the DUT, large interaction overhead, and lack of intermediate problem localization mechanisms in the existing technologies, this invention provides a hardware-software co-processing chip verification method and system. This method reduces the integration complexity between the reference model and the DUT, enables efficient conversion of hardware and software format information, and improves problem localization efficiency through multi-level comparison.

[0012] To achieve the above-mentioned technical effects, on the one hand, the present invention provides a hardware-software co-processing chip verification method, comprising the following steps:

[0013] The reference model is pre-built as an executable software program that can be called by system commands. The reference model is constructed by integrating multiple layers of sub-reference models. The function of each sub-reference model is consistent with the function of the corresponding sub-module in the chip under test (DUT). After the reference model is pre-built, an excitation signal is input to the DUT to start the chip verification process.

[0014] When the DUT reaches a preset stage, the hardware signal format information of the DUT is converted into a software-readable format through the signal conversion module to generate software stimulus information; and the sub-reference model corresponding to the current DUT level is invoked through a system call command, and the software stimulus information is passed to the sub-reference model.

[0015] The invoked sub-reference model performs simulation calculations based on the software stimulus information and generates calculation results;

[0016] After the corresponding layer module in the DUT completes the function output result, the hardware result signal of the DUT is converted into a software readable format by the signal conversion module.

[0017] The comparison module obtains the calculation results of the sub-reference model and the output results of the corresponding level modules in the DUT after format conversion, and compares the two to verify whether the function of the DUT meets expectations.

[0018] Furthermore, the reference model is constructed by integrating multiple layers of sub-reference models. The function of each sub-reference model is to calculate the DUT module at its corresponding layer. After the reference model is integrated, it is converted into an executable software program that can be called by system commands through compilation or scripting language.

[0019] Furthermore, when the DUT reaches a preset stage, it also includes:

[0020] The DUT writes its excitation hardware signals into a hardware excitation data file in a format that includes the DUT module name and signal values;

[0021] Once the hardware stimulus data file is written, a first confirmation file indicating that the data writing is complete is generated. The first confirmation file contains the name and address of the hardware stimulus data file, as well as the address for storing the sub-reference model result file.

[0022] The signal conversion module performs excitation signal conversion by periodically polling to check if the first confirmation file exists.

[0023] Furthermore, the signal conversion module performs excitation signal conversion, specifically including:

[0024] Read the first confirmation file to obtain the name and address of the hardware stimulus data file;

[0025] Based on the name of the hardware stimulus data file, read the DUT module name contained in the hardware stimulus data file;

[0026] Based on the DUT module name, the readable file format of the corresponding sub-reference model is obtained by querying;

[0027] Read the hardware signal values ​​in the hardware stimulus data file and convert them into a readable file format of the corresponding sub-reference model to generate the software stimulus information;

[0028] The sub-reference model corresponding to the DUT module name is invoked, and the converted software stimulus information and the address for storing the sub-reference model result file are provided to the sub-reference model.

[0029] Furthermore, the invoked sub-reference model performs simulation calculations based on the software stimulus information to generate calculation results, specifically including:

[0030] The sub-reference model reads the software excitation information output by the signal conversion module;

[0031] The sub-reference model executes design functions based on the software stimulus information to obtain calculation results;

[0032] The sub-reference model writes the calculation results into a software result data file in a format that includes the sub-reference model name and the calculation results;

[0033] Once the software result data file is written, a second confirmation file is generated to indicate that the data writing is complete, which is used to notify the comparison module to wait for comparison.

[0034] Furthermore, it also includes a DUT result file generation step that is parallel to the step of performing simulation calculations based on the software stimulus information by the called sub-reference model and generating calculation results. The DUT result file generation step includes:

[0035] After the corresponding layer module in the DUT completes its function, the result is written into the hardware result data file in a format that includes the DUT module name, signal value, and software result data file address.

[0036] Once the hardware result data file is written, a third confirmation file indicating that the data writing is complete is generated, which is used to notify the signal conversion module to perform result signal conversion.

[0037] Furthermore, the signal conversion module converts the hardware result signal of the DUT into a software-readable format, including:

[0038] The signal conversion module periodically polls to check if the third confirmation document exists;

[0039] When the existence of the third confirmation file is detected, the third confirmation file is read to obtain the name and address of the hardware result data file;

[0040] Based on the name of the hardware result data file, read the DUT module name and hardware signal value contained in the hardware result data file;

[0041] Convert the hardware signal values ​​into a software-readable format;

[0042] The signal conversion module calls the comparison module and provides the conversion information, DUT module name, and software result data file address to the comparison module.

[0043] Furthermore, the calculation results of the sub-reference model and the output results of the corresponding hierarchical modules in the DUT after format conversion are obtained through the comparison module, and the two are compared, specifically including:

[0044] The comparison module periodically checks whether the software result data file exists based on the address of the software result data file.

[0045] When the existence of the software result data file is detected, the software result data file is read to obtain the calculation result of the sub-reference model;

[0046] Based on the sub-reference model name in the software result data file, query the pre-set comparison rules corresponding to the sub-reference model;

[0047] The comparison module compares the calculation result with the converted output result of the corresponding level module in the DUT according to the comparison rules.

[0048] If the comparison results are inconsistent, an error message is reported; if the comparison results are consistent, the verification process continues or is interrupted.

[0049] Furthermore, the software-readable format includes a plain string format or a JSON file format.

[0050] On the other hand, the present invention also provides a chip verification system for implementing the above-described hardware and software co-operation, comprising a chip under test (DUT), an excitation input module, a reference module, a signal conversion module, and a comparison module; wherein:

[0051] The reference model is pre-built as an executable software program that can be called by system commands. The reference model is constructed by integrating multiple layers of sub-reference models, and the function of each sub-reference model is consistent with the function of the corresponding sub-module in the DUT.

[0052] The stimulus input module is used to convert test cases into signal information, generate input stimulus signal values, and load them into the input interface of the DUT;

[0053] The DUT is used to start functional simulation after receiving the excitation signal, and write hardware signal information into the hardware data file when it reaches the preset stage.

[0054] The signal conversion module is used to convert the hardware signal format information of the DUT into a software-readable format, and to convert the hardware result signal of the DUT into a software-readable format.

[0055] The comparison module is used to obtain the calculation results of the sub-reference model and the output results of the corresponding layer modules in the DUT after format conversion by the signal conversion module, and compare the two to verify whether the function of the DUT meets expectations.

[0056] The hardware-software co-processing chip verification method and system described in this invention introduces a novel integration method for the reference model and the DUT. The reference model is invoked via system calls, allowing for independent development of the reference model and DUT in their respective software and hardware environments, eliminating compatibility concerns associated with traditional integration methods. Furthermore, a new interaction method between the reference model and the DUT is designed. The DUT continues to use signal variables for simulation, while the reference model interacts with the DUT via file reading and writing, avoiding the overhead of complex cross-compilation in traditional techniques. A new comparison mechanism is also designed, allowing the reference model to record intermediate results and compare them with the DUT's intermediate results during critical steps. If an error occurs, the simulation is interrupted, and the problem location is indicated, improving the efficiency of problem localization. Attached Figure Description

[0057] Figure 1 A flowchart illustrating the steps of the hardware-software co-operated chip verification method provided in an embodiment of the present invention;

[0058] Figure 2 A flowchart illustrating the signal conversion module of the hardware-software co-operated chip verification method provided in an embodiment of the present invention during the excitation conversion stage;

[0059] Figure 3 A flowchart illustrating the signal conversion module of the hardware-software co-operated chip verification method provided in an embodiment of the present invention during the result conversion stage;

[0060] Figure 4 A flowchart illustrating the operation of the comparison module in the hardware-software co-operated chip verification method according to an embodiment of the present invention;

[0061] Figure 5 This is a schematic diagram of the system flow of the hardware-software co-operated chip verification method provided in an embodiment of the present invention;

[0062] Figure 6 This is a schematic diagram of the hardware and software collaborative chip verification system provided in another embodiment of the present invention. Detailed Implementation

[0063] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0064] It should be noted that references to "an embodiment," "embodiment," "example embodiment," etc., in this specification refer to the described embodiment including specific features, structures, or characteristics, but not every embodiment must include these specific features, structures, or characteristics. Furthermore, such expressions do not refer to the same embodiment. Moreover, when describing specific features, structures, or characteristics in conjunction with embodiments, whether or not explicitly described, it is indicated that incorporating such features, structures, or characteristics into other embodiments is within the knowledge of those skilled in the art.

[0065] Furthermore, certain terms are used in the specification and subsequent claims to refer to specific components or parts. Those skilled in the art will understand that manufacturers may use different names or terms to refer to the same component or part. This specification and subsequent claims do not distinguish components or parts by differences in name, but rather by differences in function.

[0066] In the traditional chip verification process, the reference model is usually integrated into the chip verification environment. By reading the signal information in the chip under test (DUT), chip behavior simulation is performed synchronously with the DUT. Finally, the DUT's functionality is judged by comparing whether the final output results of the RM and the DUT are consistent.

[0067] Traditional methods of interaction and comparison between the reference model (RM) and the device under test (DUT) are insufficient to meet the increasingly complex needs of chip design. RM and DUT are typically developed separately using software and hardware environments, resulting in high integration complexity; simply comparing the final results is insufficient for effectively locating problematic modules. Therefore, this invention proposes a software-hardware co-processing chip verification method and system. Through a reference model and DUT integration method, the DUT can invoke relevant functions of the reference model via system calls, significantly reducing the integration difficulty. A software-hardware interactive signal conversion module enables efficient interaction between the software-readable format information of the reference model and the hardware signal format information of the DUT. This invention also employs a multi-level comparison module, which can compare the simulation results of the reference model and the DUT at different levels in real time, improving the efficiency of designers in identifying and resolving problems.

[0068] To enable those skilled in the art to reproduce and implement the present invention, the hardware-software co-operated chip verification method and system will be described in detail below with reference to the accompanying drawings and specific embodiments. These embodiments are specific illustrations of the present invention, and their descriptions are helpful in understanding the present invention, but should not be construed as limiting the present invention.

[0069] Figure 1This invention illustrates a hardware-software co-processing chip verification method according to an embodiment of the present invention, which includes the following steps:

[0070] S101: The reference model is pre-built into an executable software program that can be called by system commands. The reference model is constructed by integrating multiple layers of sub-reference models. The function of each sub-reference model is consistent with the function of the corresponding sub-module in the chip under test (DUT). After the reference model is pre-built, an excitation signal is input to the DUT to start the chip verification process.

[0071] like Figure 5 As shown, the construction of the reference model involves the integration of multiple levels of sub-reference models (sub_RM). The function of each sub-reference model is consistent with the function of its corresponding level of sub-DUT module (sub_DUT). After the integration of the reference models is complete, they can be converted into executable software programs through methods including but not limited to joint compilation or scripting languages, which can be invoked by system commands. After the DUT and reference model are constructed, test cases are executed using simulation tools. The stimulus input module converts the test cases into signal information, generates input stimulus signal values, and loads them into the DUT's input interface. Upon receiving the stimulus signals, the sub-DUT modules at each level perform simulations according to their functions, initiating the chip verification process. The software readable format in this embodiment includes, but is not limited to, ordinary string format or JSON file format.

[0072] S102: When the DUT reaches a preset stage, the signal conversion module converts the hardware signal format information of the DUT into a software-readable format to generate software stimulus information; and through a system call command, it calls the sub-reference model corresponding to the current DUT level and passes the software stimulus information to the sub-reference model; after the DUT obtains the stimulus signal in this embodiment, it begins to execute the expected function. Specifically, at the DUT level specified by the designer, the signal conversion module converts the signal format information into a software-readable format, and at the same time, it calls the reference model through system commands to extract the software-readable format information and perform corresponding simulation calculations; specifically, the signal conversion module can convert the hardware signal format into a software-readable format according to the reading format of the reference model; the hardware signal format is generally a bit type variable, or the format of signal variables in other hardware languages.

[0073] In this embodiment, the simulation environment of the hardware DUT can call the functions of the reference model at an appropriate stage according to the design requirements through system command invocation. The reference model does not need to be integrated into the DUT hardware environment as a whole, and there is no need to consider the compatibility of the software and hardware environments. This realizes that the software reference model and the hardware DUT can be developed independently, reducing the integration difficulty.

[0074] S103: The called sub-reference model performs simulation calculations based on the software stimulus information and generates calculation results; that is, the called sub-reference model obtains the reference result values ​​at the corresponding DUT level through simulation calculations, and then provides the values ​​to the comparison module.

[0075] S104: After the corresponding layer module in the DUT completes the function output result, the hardware result signal of the DUT is converted into a software readable format through the signal conversion module;

[0076] The signal conversion module in this embodiment can convert the software-readable format information of the software reference model to the hardware signal format information of the hardware DUT. After the DUT calls the reference model through system calls, the reference model performs calculations and judgments based on the output information of the DUT. At this time, the signal conversion module of the software-hardware interaction can convert the hardware signal information of the DUT into software-readable format information for the reference model to read and parse. When the reference model completes the information processing, it outputs the processed information in a software-readable format. At this time, the signal conversion module of the software-hardware interaction can convert the software-readable format information back into hardware signal information and input it into the DUT for the next step of functional simulation. The signal conversion module can perform efficient signal conversion between the reference model and the DUT, satisfying the information interaction between the reference model and the DUT.

[0077] S105: The comparison module obtains the calculation results of the sub-reference model and the output results of the corresponding level modules in the DUT after format conversion, and compares the two to verify whether the function of the DUT meets expectations. The comparison module can retain intermediate results of multiple levels in the simulation verification through the reference model and compare them with the corresponding DUT levels. The multi-level comparison mechanism can compare the simulation results of the reference model and the DUT at different levels in real time during the simulation process. If unexpected comparison results occur during the process, the comparison module can terminate the simulation and report the error in a timely manner according to user needs, or record the error and continue the simulation. In this way, problems in the simulation process can be recorded and reported in real time, improving the efficiency of designers in discovering and solving problems.

[0078] The comparison process generally involves comparing whether the values ​​are equal, and also includes some comparison methods based on certain rules set by the designers. If the simulation output signal values ​​of each level module in the DUT are consistent with the output values ​​of the corresponding sub-reference model, or conform to the designers' rules, then the DUT verification is confirmed to be successful. Otherwise, the DUT verification is confirmed to be faulty. The comparison module will report information such as the location of the faulty DUT, the faulty result, and the expected result to help the designers locate the problem.

[0079] Preferably, when the DUT reaches a preset stage, it further includes:

[0080] The DUT writes its excitation hardware signals into a hardware excitation data file in a format containing the DUT module name and signal values. Once the hardware excitation data file is written, a first confirmation file indicating completion is generated. This first confirmation file contains the name and address of the hardware excitation data file, as well as the address for storing the sub-reference model result file. The signal conversion module periodically polls to check if the first confirmation file exists to perform excitation signal conversion. Specifically, when a sub-DUT verification process reaches a stage preset by the designer, the sub-DUT writes its excitation hardware signals into a hardware excitation data file (hw_input_data) in the format {sub_DUT module name, signal value (hw_fmt)}. After the excitation data is written, a file indicating completion (the first confirmation file) is created, containing the name and address (hw_input_data_addr) of the hw_input_data file and the address sw_output_data_addr for storing the sub-RM result file. This notifies the signal conversion module to perform excitation signal conversion.

[0081] The data format written to the hardware stimulus data file in this embodiment is not limited to the above-mentioned {module name, signal value} format. It can also include data formats such as {signal value, module name}, {module name, signal value, timestamp}, and other data formats that can establish an association between DUT modules and their corresponding signal values. That is, this embodiment does not impose any restrictions on this. Similarly, the writing format of the hardware result data file and the software result data file can also adopt a similar flexible data organization form, as long as the correspondence between modules and result data can be realized.

[0082] See Figure 2 In an optional implementation, the signal conversion module performs excitation signal conversion, and the specific process is as follows:

[0083] S201: The signal conversion module periodically polls to check if the first confirmation file exists; if it exists, proceed to the next step S202; otherwise, continue the periodic check.

[0084] S202: Read the first confirmation file to obtain the name and address of the hardware stimulus data file, and then execute step S203;

[0085] S203: Based on the name of the hardware stimulus data file, read the DUT module name contained in the hardware stimulus data file, and then execute step S204;

[0086] S204: Based on the DUT module name, query to obtain the readable file format of the corresponding sub-reference model, and then execute step S205;

[0087] S205: Read the hardware signal values ​​(hw_fmt) in the hardware stimulus data file, convert them into the readable file format (sw_fmt) of the corresponding sub-reference model, and generate the software stimulus information;

[0088] S206: Call the sub-reference model corresponding to the DUT module name, and provide the converted software stimulus information (sw_fmt) and the address (sw_output_data_addr) for storing the sub-reference model result file to the sub-reference model.

[0089] Furthermore, the invoked sub-reference model performs simulation calculations based on the software stimulus information to generate calculation results, specifically including:

[0090] The sub-reference model reads the software stimulus information output by the signal conversion module; executes the design function according to the software stimulus information to obtain the calculation result; writes the calculation result into a software result data file in a format including the sub-reference model name and the calculation result; when the software result data file is finished writing, a second confirmation file indicating that the data writing is complete is generated to notify the comparison module to wait for comparison. Specifically, after sub_RM is called, it begins to read the readable format information sw_fmt output by the signal conversion module, executes the design function, and finally outputs the calculation result, writing it into the file sw_output_data in the format {sub_RM name, calculation result}. When the data writing is complete, a file indicating that the data writing is complete is written, containing the name and address (sw_output_data_addr) of the sub_RM result data file sw_output_data, and simultaneously notifies the comparison module to wait for comparison.

[0091] Preferably, the method further includes a step of generating a DUT result file in parallel with step S103, wherein the step of generating the DUT result file includes:

[0092] After the corresponding module in the DUT completes its function, it writes the result to the hardware result data file in a format containing the DUT module name, signal value, and software result data file address. Once the hardware result data file is written, a third confirmation file indicating data writing completion is generated to notify the signal conversion module to perform result signal conversion. That is, the sub_DUT's function execution process is parallel to the sub_RM. After the sub_DUT completes its corresponding function and obtains the result, it writes the result to the hardware result data file (hw_output_data) in the format {sub_DUT module name, signal value (hw_fmt), sw_output_data_addr}. After the excitation data is written, a file indicating data writing completion is created, containing the name and address (hw_output_data_addr) of the hw_output_data file, to notify the signal conversion module to perform result signal conversion.

[0093] See Figure 3 In an optional implementation, the signal conversion module converts the hardware result signal of the DUT into a software-readable format, including:

[0094] S301: The signal conversion module periodically polls to check if the third confirmation file exists; if it exists, step S302 is executed; otherwise, the periodic check continues.

[0095] S302: When the existence of a third confirmation file is detected, read the third confirmation file to obtain the name and address (hw_output_data_addr) of the hardware result data file; execute step S303;

[0096] S303: Based on the name of the hardware result data file, read the DUT module name and hardware signal value (hw_fmt) contained in the hardware result data file; execute step S304;

[0097] S304: Convert the hardware signal value (hw_fmt) into a software-readable format, that is, convert it into a file format readable by the comparison module (sw_fmt); proceed to step S305;

[0098] S305: The signal conversion module calls the comparison module and provides the conversion information (sw_fmt information), DUT module name, and software result data file address (sw_output_data_addr) to the comparison module.

[0099] See Figure 4In an optional implementation, the calculation results of the sub-reference model and the output results of the corresponding hierarchical modules in the DUT after format conversion are obtained through a comparison module, and the two are compared. The specific process is as follows:

[0100] S401: The comparison module periodically checks whether the software result data file exists based on the address of the software result data file; specifically, the comparison module periodically checks whether the result data file hw_output_data of sub_RM exists in sw_output_data_addr. If it does, step S402 is executed; otherwise, the periodic check continues.

[0101] S402: When the existence of the software result data file is detected, the software result data file is read to obtain the calculation result of the sub-reference model; that is, the comparison module reads sw_output_data through sw_output_data_addr to obtain sub_RM result data and executes step S403.

[0102] S403: Based on the sub-reference model name in the software result data file, query the pre-set alignment rule of the corresponding sub-reference model; specifically, the alignment module reads the sub_RM name and sub_RM calculation result, queries the pre-set alignment rule cmp_rule of the corresponding sub_RM, and executes step S404.

[0103] S404: The comparison module compares the calculation results with the output results of the corresponding level modules in the DUT after conversion according to the comparison rules. Specifically, the comparison conversion module compares the sub_RM calculation results with the sw_fmt information converted from sub_DUT according to cmp_rule. If they are consistent, step S406 is executed; otherwise, step S405 is executed.

[0104] S405: If the comparison results are inconsistent, report an error message;

[0105] S406: If the comparison results are consistent, continue the verification process or interrupt it.

[0106] Finally, when all layers of the DUT have completed the comparison or simulation as expected by the designer, the verification process ends. The designer can then analyze and locate the problems reported by the comparison modules.

[0107] Figure 6This invention illustrates a hardware-software co-operated chip verification system 100 according to another embodiment of the present invention. The system 100 is used to implement the method described in the above embodiments and includes a chip under test (DUT) 10, an excitation input module 20, a reference module 30, a signal conversion module 40, and a comparison module 50; wherein:

[0108] The reference model 30 is pre-built as an executable software program that can be called by system commands. The reference model 30 is constructed by integrating multiple layers of sub-reference models, each with a function consistent with the corresponding sub-module in the DUT 10. The stimulus input module 20 converts test cases into signal information, generates input stimulus signal values, and loads them into the input interface of the DUT 10. The DUT 10 receives the stimulus signal and begins functional simulation, writing hardware signal information into a hardware data file when it reaches a preset stage. The signal conversion module 40 converts the DUT... The hardware signal format information of DUT10 is converted into a software-readable format, and the hardware result signal of DUT10 is converted into a software-readable format; the signal conversion module 40 is the module that implements the hardware and software signal conversion function; the comparison module 50 is used to obtain the calculation result of the sub-reference model and the output result of the corresponding layer module in DUT10 after format conversion by the signal conversion module 40, and compare the two to verify whether the function of DUT10 meets expectations; the comparison module 50 is the module that implements the comparison between reference model 30 and DUT10 and can locate problems.

[0109] The specific implementation and operation process of each module in the system 100 described in this embodiment can be understood by referring to the relevant descriptions in the foregoing method embodiments, and all of them can achieve the functions and effects achieved by the corresponding method steps. For the sake of simplicity and to avoid repetition, they will not be described again here.

[0110] In summary, the hardware-software co-processing chip verification method provided by this invention pre-constructs the reference model as an independent software program that can be called by system commands, enabling the reference model and the DUT to be developed independently in software and hardware environments respectively, without the need for traditional cross-compilation integration, effectively reducing integration complexity. A signal conversion module converts the DUT hardware signal format to a software-readable format, and uses file read / write and periodic polling to achieve information exchange between hardware and software, replacing the traditional DPI interface-dependent interaction method, reducing interaction overhead and improving flexibility. Furthermore, a comparison module compares intermediate results of the reference model and the DUT at multiple levels, and can report the error location, error result, and expected result when errors are found, achieving precise problem localization during chip verification and improving verification and debugging efficiency. Thus, this invention meets the increasingly complex chip verification needs and has strong engineering application value.

[0111] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of the present invention is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0112] Of course, the present invention may have other various embodiments. Without departing from the spirit and essence of the present invention, those skilled in the art can make various corresponding changes and modifications according to the present invention, but these corresponding changes and modifications should all fall within the protection scope of the appended claims.

Claims

1. A hardware-software co-processing chip verification method, characterized in that, The steps include the following: The reference model is pre-built as an executable software program that can be called by system commands. The reference model is constructed by integrating multiple layers of sub-reference models. The function of each sub-reference model is consistent with the function of the corresponding sub-module in the chip under test (DUT). After the reference model is pre-built, an excitation signal is input to the DUT to start the chip verification process; When the DUT reaches a preset stage, the hardware signal format information of the DUT is converted into a software-readable format through the signal conversion module to generate software stimulus information; and the sub-reference model corresponding to the current DUT level is invoked through a system call command, and the software stimulus information is passed to the sub-reference model. The invoked sub-reference model performs simulation calculations based on the software stimulus information and generates calculation results; After the corresponding layer module in the DUT completes the function output result, the hardware result signal of the DUT is converted into a software readable format by the signal conversion module. The comparison module obtains the calculation results of the sub-reference model and the output results of the corresponding level modules in the DUT after format conversion, and compares the two to verify whether the function of the DUT meets expectations.

2. The method according to claim 1, characterized in that, The reference model is constructed by integrating multiple layers of sub-reference models. The function of each sub-reference model is to compute the DUT module at its corresponding layer. After the reference model is integrated, it is converted into an executable software program that can be called by system commands through compilation or scripting language.

3. The method according to claim 1, characterized in that, When the DUT reaches a preset stage, it also includes: The DUT writes its excitation hardware signals into a hardware excitation data file in a format that includes the DUT module name and signal values; Once the hardware stimulus data file is written, a first confirmation file indicating that the data writing is complete is generated. The first confirmation file contains the name and address of the hardware stimulus data file, as well as the address for storing the sub-reference model result file. The signal conversion module performs excitation signal conversion by periodically polling to check if the first confirmation file exists.

4. The method according to claim 3, characterized in that, The signal conversion module performs excitation signal conversion, specifically including: Read the first confirmation file to obtain the name and address of the hardware stimulus data file; Based on the name of the hardware stimulus data file, read the DUT module name contained in the hardware stimulus data file; Based on the DUT module name, the readable file format of the corresponding sub-reference model is obtained by querying; Read the hardware signal values ​​in the hardware stimulus data file and convert them into a readable file format of the corresponding sub-reference model to generate the software stimulus information; The sub-reference model corresponding to the DUT module name is invoked, and the converted software stimulus information and the address for storing the sub-reference model result file are provided to the sub-reference model.

5. The method according to claim 4, characterized in that, The invoked sub-reference model performs simulation calculations based on the software stimulus information to generate calculation results, specifically including: The sub-reference model reads the software excitation information output by the signal conversion module; The sub-reference model executes design functions based on the software stimulus information to obtain calculation results; The sub-reference model writes the calculation results into a software result data file in a format that includes the sub-reference model name and the calculation results; Once the software result data file is written, a second confirmation file is generated to indicate that the data writing is complete, which is used to notify the comparison module to wait for comparison.

6. The method according to claim 5, characterized in that, It also includes a DUT result file generation step that is parallel to the step of performing simulation calculations based on the software stimulus information by the called sub-reference model and generating calculation results. The DUT result file generation step includes: After the corresponding layer module in the DUT completes its function, the result is written into the hardware result data file in a format that includes the DUT module name, signal value, and software result data file address. Once the hardware result data file is written, a third confirmation file indicating that the data writing is complete is generated, which is used to notify the signal conversion module to perform result signal conversion.

7. The method according to claim 6, characterized in that, The signal conversion module converts the hardware result signal of the DUT into a software-readable format, including: The signal conversion module periodically polls to check if the third confirmation document exists; When the existence of the third confirmation file is detected, the third confirmation file is read to obtain the name and address of the hardware result data file; Based on the name of the hardware result data file, read the DUT module name and hardware signal value contained in the hardware result data file; Convert the hardware signal values ​​into a software-readable format; The signal conversion module calls the comparison module and provides the conversion information, DUT module name, and software result data file address to the comparison module.

8. The method according to claim 7, characterized in that, The comparison module obtains the calculation results of the sub-reference model and the output results of the corresponding hierarchical modules in the DUT after format conversion, and compares the two, specifically including: The comparison module periodically checks whether the software result data file exists based on the address of the software result data file. When the existence of the software result data file is detected, the software result data file is read to obtain the calculation result of the sub-reference model; Based on the sub-reference model name in the software result data file, query the pre-set comparison rules corresponding to the sub-reference model; The comparison module compares the calculation result with the converted output result of the corresponding level module in the DUT according to the comparison rules. If the comparison results are inconsistent, an error message is reported; if the comparison results are consistent, the verification process continues or is interrupted.

9. The method according to claim 1, characterized in that, The software-readable format includes plain string format or JSON file format.

10. A chip verification system for implementing the software-hardware co-operation method as described in any one of claims 1 to 9, characterized in that, It includes a chip under test (DUT), an excitation input module, a reference module, a signal conversion module, and a comparison module; among which: The reference model is pre-built as an executable software program that can be called by system commands. The reference model is constructed by integrating multiple layers of sub-reference models, and the function of each sub-reference model is consistent with the function of the corresponding sub-module in the DUT. The stimulus input module is used to convert test cases into signal information, generate input stimulus signal values, and load them into the input interface of the DUT; The DUT is used to start functional simulation after receiving the excitation signal, and write hardware signal information into the hardware data file when it reaches the preset stage. The signal conversion module is used to convert the hardware signal format information of the DUT into a software-readable format, and to convert the hardware result signal of the DUT into a software-readable format. The comparison module is used to obtain the calculation results of the sub-reference model and the output results of the corresponding layer modules in the DUT after format conversion by the signal conversion module, and compare the two to verify whether the function of the DUT meets expectations.

Images