Method and device for verifying and debugging chip algorithm module

Abstract

The invention provides a method and a device for verifying and debugging a chip algorithm module. The consistency of a C language reference model and a simulation waveform can be automatically compared and tracked. The method comprises the following steps: constructing a verification environment and generating an fsdb waveform and a C language reference model executable file with debugging information; generating a GDB command and an fsdbreport command based on the configuration information, extracting a variable value and a signal value, and performing consistency comparison; if the comparison is consistent, ending, otherwise, entering signal tracking; in signal tracking, a PyNPI interface is called to forward track a driving signal and analyze a signal value matching condition in a clock period; and if the corresponding value is not matched, generating a new configuration file and circularly executing the debugging process. According to the technical scheme provided by the invention, the root of the problem can be automatically tracked and quickly positioned at the initial verification stage of the algorithm module, the dynamic addition of comparison nodes is supported, and the manual debugging cost is reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of integrated circuit design verification, and in particular to a method and device for verifying and debugging a chip algorithm module. Background Art

[0002] Chip algorithm modules are application-specific integrated circuits designed specifically for accelerating specific algorithms. Their core goal is to achieve efficient algorithm execution through hardware architecture optimizations (such as parallel computing units, customized data paths, and dedicated memory hierarchies), addressing bottlenecks in computing power, energy efficiency, or latency faced by traditional central processing units (CPUs) or graphics processing units (GPUs). These modules are widely used in AI inference / training, video encoding and decoding, signal processing, and edge computing chips.

[0003] With the increasing complexity of integrated circuit design, more and more chips are using C or C++ to build reference models (i.e., C language reference models, Cmodels) at the algorithm level, and implementing the corresponding functional modules in hardware description language (HDL) at the hardware design level. In the chip verification process, consistency verification between the Cmodel and the design under test (DUT), specifically the designed register-transfer level (RTL), becomes a critical step in ensuring algorithm correctness and hardware implementation consistency. However, in the early stages of project development, discrepancies often exist between the RTL design and the original algorithm model, leading to mismatched calculation results. This often requires time-consuming cross-departmental collaboration among verification, algorithm, and design teams to complete debugging.

[0004] Traditional verification methods typically follow this process: providing identical inputs and configurations for the Cmodel and the DUT RTL, obtaining the DUT's waveform signal file (such as the fsdb (Fast Signal Database) format) through simulation tools, and comparing it with the Cmodel's output to determine if the two outputs are consistent. While this method is straightforward, in actual engineering, multiple calculation steps and conditional branches may exist between input and output. When a comparison fails, debuggers often struggle to quickly locate the root cause by simply comparing the final output. This makes the verification and debugging process extremely cumbersome and time-consuming, and increases the cost of cross-departmental collaboration.

[0005] To solve the above problems, the existing technology has proposed the idea of ​​segmented comparison. Specifically, a common solution is to add intermediate comparison nodes in the design and reference model, and compare the entire verification process in segments to narrow the scope of the problem. For example, Chinese patent application CN202111652085.8 discloses a method of inserting multiple intermediate comparison nodes between the design and the reference model, disassembling the entire design and verifying it segment by segment, breaking the whole into parts, and decomposing the complex verification process into multiple small segments, thereby helping verification personnel to quickly and accurately locate the defect position and improve the efficiency of problem troubleshooting.

[0006] However, the comparison node insertion method adopted by CN202111652085.8 has certain limitations. On the one hand, since the comparison nodes need to be pre-defined in the design and verification environment, the number of segments should not be too many, otherwise it will increase the complexity of implementation; on the other hand, once the verification environment is established, it is difficult to dynamically add new comparison nodes, resulting in the inability to flexibly adjust the inspection range during the debugging process; on the other hand, the comparison process still requires manual analysis of intermediate results, and the degree of automation is low, which affects the verification efficiency. Therefore, when dealing with large-scale, frequently iterated algorithm module verification tasks, the existing technology still faces the difficult problem of balancing efficiency and accuracy.

[0007] Therefore, there is an urgent need for a more efficient and flexible verification method that can automatically track and quickly locate the root cause of the problem in the early stages of algorithm module verification, support dynamic addition of comparison nodes, and reduce manual debugging costs. Summary of the Invention

[0008] In view of this, the present invention provides a method and apparatus for verifying and debugging a chip algorithm module, so as to solve the above-mentioned technical problems in the prior art.

[0009] According to one aspect of the present invention, a method for verifying and debugging a chip algorithm module is provided, wherein the method comprises: S1: Prepare the verification test environment, run the test case to generate the fsdb simulation waveform signal file of the test case, and compile the source code of the C language reference model to generate the C language reference model executable file with debugging information; S2: Create and edit a configuration file, which includes configuration information, including the preset signal signal_1, preset variables, and sampling conditions of the fsdb simulation waveform signal; S3: Read the configuration file, generate a GDB debugging command according to the configuration information, call and run the GDB debugging command to execute the C language reference model executable file, thereby obtaining the result value of the preset variable in each calculation and saving it to the GDB log file; S4: Generate an fsdbreport command according to the configuration information, call and run the fsdbreport command, obtain the fsdb result value of the preset signal signal_1 each time the sampling condition takes effect based on the fsdb simulation waveform signal file, and save it to the fsdb log file; S5: Compare the GDB result value with the fsdb result value. If the two are consistent, the method ends. If the two are inconsistent, execute S6. S6: Call the PyNPI interface to compile the register transfer level code file list of the test case; S7: Call the PyNPI lang.trace_driver function interface to obtain the driver signal list signal_list of the original signal signal_c; S8: Traverse the driving signal signal_d in the driving signal list signal_list, call the PyNPIwaveform.sig_hdl_value_at function interface, and track the signal value within n clock cycles in the fsdb simulation waveform signal file forward; S9: Determine whether the driving signal signal_d in the driving signal list signal_list has an equal value to the original signal signal_c within n clock cycles. If an equal value is found, the driving signal signal_d is used as the original signal signal_c and the process returns to S7. If an equal value is not found, S10 is executed. S10: Obtain a driving signal list signal_list of the original signal signal_csignal_c, parse the source code of the C language reference model, and obtain a driving variable list of the preset variables; S11: traverse all combinations of drive signals signal_d and drive variables in the drive signal list signal_list and the drive variable list, generate a new configuration file for each combination, and obtain multiple new configuration files; S12: Select one from multiple new configuration files and return to S3.

[0010] According to another aspect of the present invention, a device for verifying and debugging a chip algorithm module is provided, wherein the device comprises: An initialization module is configured to verify the test environment and run the test case to generate an fsdb simulation waveform signal file of the test case, and compile the source code of the C language reference model to generate a C language reference model executable file with debugging information; The comparison module is used to compare the value of the preset variable with the value of the fsdb simulation waveform signal point by point, including: A comparison configuration module is configured to create a comparison configuration file, where the comparison configuration file includes comparison configuration information; a comparison execution module configured to load a comparison configuration file and execute file comparison, wherein when the sampling conditions of the FSDB simulation waveform signal are known, the file comparison adopts a precise comparison method; when the sampling conditions of the FSDB simulation waveform signal are unknown, the file comparison adopts a fuzzy comparison method; The tracking module is used to automatically track the driving path of the FSDB simulation waveform signal when the comparison is inconsistent, including: A tracing configuration module is configured to create a tracing configuration file, the tracing configuration file including tracing configuration information; The trace execution module is configured to load the trace configuration file and execute signal tracing.

[0011] According to yet another aspect of the present invention, an electronic device is provided, comprising: one or more processors and a memory, wherein the memory is used to store executable instructions; and the one or more processors are configured to implement the above method via the executable instructions.

[0012] According to yet another aspect of the present invention, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the processor executes the above method.

[0013] It can be seen from the above technical solutions that the technical solution provided by the present invention has at least the following advantages: 1. Improve comparison efficiency and accuracy: Use GDB to automatically obtain variable values ​​in Cmodel, and use the fsdbreport tool to extract the corresponding signal values ​​in the fsdb simulation waveform signal file to achieve automated consistency comparison. This eliminates the need to modify the verification environment and supports unlimited check nodes, improving verification efficiency and accuracy. 2. Improve debugging automation and intelligence: Call PyNPI to compile the DUT RTL code, track the drive signal signal_d set corresponding to the signal at the error point in the waveform, use Python to parse the Cmodel source code, and obtain the drive variable set corresponding to the variable at the mismatch point in the Cmodel. Users can flexibly select signal and variable combinations for comparison to quickly locate the root cause of the problem. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The accompanying drawings are used to provide a further understanding of the technical solution of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the technical solution of the present invention, but do not constitute a limitation to the technical solution of the present invention.

[0015] Figure 1 A flow chart showing a method provided by an exemplary embodiment of the present invention is shown; Figure 2 A flow chart showing a method for comparing and tracking a C language reference model with an FSDB simulation waveform signal provided by an exemplary embodiment of the present invention is shown; Figure 3 A schematic diagram of a scene of multiple tracking and comparison in an image processing algorithm module provided by an exemplary embodiment of the present invention is shown; Figure 4 A flowchart of a multi-node comparison method of a C language reference model and an FSDB simulation waveform signal in an image processing algorithm module provided by an exemplary embodiment of the present invention is shown; Figure 5 shows a structural block diagram of a device provided by an exemplary embodiment of the present invention; Figure 6 shows a structural block diagram of a device provided by another exemplary embodiment of the present invention; Figure 7 A structural block diagram of an electronic device provided by an exemplary embodiment of the present invention is shown. DETAILED DESCRIPTION

[0016] Various exemplary embodiments of the present invention will be described in detail below with reference to the accompanying drawings. The description of the exemplary embodiments is merely illustrative and is not intended to limit the invention, its application, or use. The present invention can be implemented in many different forms and is not limited to the embodiments described herein. These embodiments are provided to make this disclosure thorough and complete and to fully convey the scope of the invention to those skilled in the art.

[0017] Unless explicitly stated, if the number of an element is not specifically limited, the element may be one or more. The term "plurality" means two or more, the term "based on" should be interpreted as "based at least in part on," and the terms "and / or" and "at least one of..." encompass any and all possible combinations of the listed items. Furthermore, terms such as "first," "second," and the like are for descriptive purposes only and do not indicate or imply relative importance or implicitly specify the number of the technical features being referred to.

[0018] Please refer to Figure 1 , which shows a flow chart of a method provided by an exemplary embodiment of the present invention.

[0019] The method for verifying and debugging a chip algorithm module provided by the present invention includes: S1: Prepare the verification test environment, run the test case to generate the test case's fsdb waveform signal file, and compile the C language reference model source code to generate a C language reference model executable file with debugging information; S2: Create and edit a configuration file, which includes configuration information, including the preset signal signal_1, preset variables, and sampling conditions of the fsdb simulation waveform signal; S3: Read the configuration file, generate GDB debugging commands according to the configuration information, call and run the GDB debugging commands to execute the C language reference model executable file, thereby obtaining the result values ​​of the preset variables in each calculation and saving them to the GDB log file gdb_log; S4: Generate an fsdbreport command according to the configuration information, call and run the fsdbreport command, obtain the fsdb result value of the preset signal signal_1 each time the sampling condition takes effect based on the fsdb simulation waveform signal file, and save it to the fsdb log file fsdb_log; S5: Compare the GDB result value in gdb_log with the fsdb result value in fsdb_log. If they are consistent, the process ends. If they are inconsistent, the process goes to S6. S6: Call the PyNPI interface to compile the register transfer level code file list of the test case; S7: Call the PyNPI lang.trace_driver function interface to obtain the driver signal list signal_list of the original signal (current waveform signal) signal_c; S8: Traverse the driving signal signal_d in the driving signal list signal_list, call the PyNPIwaveform.sig_hdl_value_at function interface, and track the signal value within n clock cycles in the fsdb simulation waveform signal file forward; S9: Determine whether the driving signal signal_d in the driving signal list signal_list has an equal value to the original signal within n clock cycles (i.e., within the time period [T0-n, T0]). If an equal value is found, the driving signal signal_d is used as the original signal signal_c, and the process returns to S7. If an equal value is not found, the process proceeds to S10. S10: Obtain a driving signal list signal_list of the original signal signal_c, parse the source code of the C language reference model, and obtain a driving variable list of preset variables (in an exemplary embodiment, the preset variables are variable names in the source code file of the C language reference model, and the preset signal signal_1 is a signal name in the fsdb simulation waveform signal); S11: traverse all combinations of drive signals signal_d and drive variables in the drive signal list signal_list and the drive variable list, generate a new configuration file for each combination, and obtain multiple new configuration files; S12: Select one from multiple new configuration files and return to S3.

[0020] In addition to being used for verification of algorithm modules or algorithm chips, the method provided by the present invention can also be used in other types of scenarios that require precise comparison between Cmodel and DUT.

[0021] The effective sampling conditions refer to the waveform signal sampling conditions (e.g., sampling on the rising edge of the clock signal) included in the configuration file during step S2. For example, for the read channel signal of the AXI protocol, the conditions for sampling read data are rvalid = 1 and rready = 1. In other words, read data is valid only when both handshake signals are 1. For the AXI protocol, the effective sampling conditions are: the clock signal clk is on the rising edge, and rvalid = 1 and rready = 1.

[0022] The waveform signal file is in fsdb format. Compiling the source code of the C language reference model to generate a C language reference model file with debugging information means using the "-g option" of the GCC compiler to compile the C language reference model (Cmodel). The "-g option" is a debugging option that means generating debugging information (such as variable names, function names, source code line numbers, etc.) during compilation and embedding this debugging information into the generated executable file. The C language reference model executable file compiled with the "-g option" can be recognized by the GNU Debugger (GDB) and supports: (1) pausing execution at a specific code line or function to inspect variable values; (2) tracing code logic line by line; and (3) directly outputting the real-time value of a specified variable.

[0023] Among them, the fsdbreport command is a command line tool in the Synopsys Verdi debugging tool chain, which is mainly used to parse, count or generate reports from data in fsdb waveform signal files.

[0024] The PyNPI (Python Native Programming Interface) is a Python API provided by the Synopsys Verdi debug platform. It allows users to interact directly with Verdi through Python scripts, enabling automated waveform analysis, debugging, and data processing. The PyNPI lang.trace_driver function is used to trace and record the driver signal signal_d. The PyNPI waveform.sig_hdl_value_at function is used to retrieve the value of a signal at a specific time point from an fsdb waveform signal file. Furthermore, GDB debugging commands are used for the GNU debugger and can be used to control program execution, view and modify memory and registers, set breakpoints, analyze crashes, and perform other debugging operations.

[0025] In an exemplary embodiment, the configuration file is in JSON format.

[0026] In an exemplary embodiment, the configuration information includes the C language reference model executable file path, the source code path of the C language reference model, the register transfer level code file list of the test case, the waveform signal file path, the variable name to be tracked and its line number in the source code, the signal name in the waveform signal file, the sampling conditions and signal path, etc.

[0027] Please refer to Figure 2 , which shows a flow chart of a method for comparing and tracking a C language reference model and an FSDB simulation waveform signal provided by an exemplary embodiment of the present invention.

[0028] Specifically, the following steps are included: (1) Use the "-g option" of the GCC compiler to compile the C language reference model to generate a C language reference model executable program file that supports GDB debugging; (2) Run the simulation verification test case and configure the simulation tool to generate the fsdb simulation waveform signal file; (3) During the test case execution, if there is an error in the comparison check between the C language reference model and the register transfer level code of the test case, the signal name of the RTL error signal and the variable name of the C language reference model can be obtained. Based on this information, a JSON format configuration file can be constructed according to the above method; (4) Open the GUI interface and load the JSON format configuration file, run the comparison function, and the comparison result should show an error; (5) Run the tracking function and select the signal and variable combination for the next step of tracking and comparison; (6) If the selected signal and variable combination matches (i.e., the waveform signal is completely consistent with the cmodel variable value), then other possible combinations are selected to continue tracking until the source of the error is found; (7) Save and summarize the configuration files on all calculation paths during the tracking process. The next time you debug, you can directly load the file to quickly eliminate the errors in the current path.

[0029] Please refer to Figure 3 , which shows a schematic diagram of a scene of multiple tracking and comparison in an image processing algorithm module provided by an exemplary embodiment of the present invention.

[0030] This embodiment focuses on debugging scenarios that require both multi-node comparison and automated tracking.

[0031] from Figure 3 It can be seen that: At time Tn: the signal output value of the fsdb waveform is X, which is inconsistent with the output value of Cmodel; Start the first trace: Execute steps S6 to S11 above. Since the output results of the four nodes 8T, 9T, 10T, and 11T are all X, and the input of node 8T is Y, which is inconsistent with the output value, the calculation unit of node 8T is the end point of the first trace (this is equivalent to the output of the module from node 8T to node 12T in this waveform, and the signal value does not change. That is, at time Tn-4, the output of node 8T is X, and at time Tn, the output of node 12T is also X. Therefore, the intermediate nodes 9T, 10T, and 11T will not introduce errors). End of the first trace: At time Tn-4, the value of node 8T is X, the node input value is offset_gain and the output of node 7T. Comparing offset_gain in the waveform with offset_gain in Cmodel, it is found that the signal value in the waveform is consistent with the variable value in Cmodel, indicating that there is no error introduced here and the comparison passes; Second trace: The output value of node 7T at time Tn-5 is Y, which is inconsistent with the Cmodel. Comparing the configuration parameter offset, it is consistent with the Cmodel, indicating that the offset signal of node 7T does not introduce errors. Third trace: The output value of the 6T node at time Tn-6 is Z2, which is inconsistent with the Cmodel. Comparing the lcl gain parameter with the output of the previous 5T node, it is found that the RTL in the output of the 5T node is consistent with the Cmodel, while the value of the lcl gain parameter in the waveform is inconsistent with the Cmodel, indicating that the error comes from the lcl gain parameter of 6T. At this time, the root cause of the error is found.

[0032] Please refer to Figure 4, which shows a flowchart of a multi-node comparison method between a C language reference model and an FSDB simulation waveform signal in an image processing algorithm module provided by an exemplary embodiment of the present invention.

[0033] Specifically, the following steps are included: (1) Use the "-g option" of the GCC compiler to compile the C language reference model to generate a C language reference model executable program file that supports GDB debugging; (2) Run the simulation verification test case and configure the simulation tool to generate the fsdb simulation waveform signal file; (3) During the test case execution, if there is an error in the comparison check between the C language reference model and the register transfer level code of the test case, a JSON format configuration file with multiple comparison nodes is created. The number of nodes is unlimited. (4) Open the GUI interface and load the JSON format configuration file to run the comparison function; (5) If it is found that the comparisons before a certain node Tn are all correct, but the comparisons after the node Tn are wrong, it can be concluded that the calculation of the Tn node is wrong; (6) Reference Figure 2 The method for handling errors in the illustrated embodiment continues to track.

[0034] Please refer to Figure 5 , which shows a structural block diagram of a device provided by an exemplary embodiment of the present invention.

[0035] The present invention also provides a device for verifying and debugging chip algorithm modules, which can realize automatic tracking and comparison of C language reference models and simulation waveforms.

[0036] The device for verifying and debugging a chip algorithm module provided by the present invention includes: An initialization module is configured to verify the test environment and run the test case to generate an fsdb simulation waveform signal file of the test case, and compile the source code of the C language reference model to generate a C language reference model executable file with debugging information; The comparison module is used to compare the value of the preset variable with the value of the fsdb simulation waveform signal point by point, including: A comparison configuration module is configured to create a comparison configuration file, where the comparison configuration file includes comparison configuration information; a comparison execution module configured to load a comparison configuration file and execute file comparison, wherein when the sampling conditions of the FSDB simulation waveform signal are known, the file comparison adopts a precise comparison method; when the sampling conditions of the FSDB simulation waveform signal are unknown, the file comparison adopts a fuzzy comparison method; The tracking module is used to automatically track the driving path of the FSDB simulation waveform signal when the comparison is inconsistent, including: A tracing configuration module is configured to create a tracing configuration file, the tracing configuration file including tracing configuration information; The trace execution module is configured to load the trace configuration file and execute signal tracing.

[0037] In an exemplary embodiment, the apparatus provided by the present invention further includes a graphical user interface (GUI) module. The GUI module may utilize a QT framework and is configured to load and edit comparison and tracking configuration files, control the comparison and tracking process, and display the running progress and log files.

[0038] In an exemplary embodiment, the comparison configuration information includes the C language reference model executable file path, the C language reference model source code path, the fsdb simulation waveform signal file path, the C language reference model variable name to be compared, the location and number of repetitions of the C language reference model debug breakpoint, whether the C language reference model variable name is an array and the array dimension, the waveform signal name to be compared and the signal level, the sampling conditions of the waveform signal to be compared, the sampling start and end time, whether the waveform signal to be compared is an array and the array dimension. In the C language reference model, the specified variable name can be an array, including a one-dimensional array, a two-dimensional array, etc., in which case the array dimension needs to be specified. For example, the two-dimensional array int matrix[3][4] has a dimension of 2.

[0039] In an exemplary embodiment, the tracing configuration information includes the C language reference model executable file path, the source code path of the C language reference model, the fsdb simulation waveform signal file path, the module name of the test case in the verification environment, the C language reference model variable name, function name and file name to be traced, the fsdb simulation waveform signal name and signal hierarchy to be traced, the expected value fsdb_exp of the fsdb simulation waveform signal, the time point to start tracing, the clock cycle of the traced signal, and the number of clock cycles to be traced forward trace_cycles.

[0040] In an exemplary embodiment, the precise comparison method includes: Parse the comparison configuration file, generate GDB debugging commands based on the comparison configuration information, call and run the GDB debugging commands, repeat multiple times at the debugging breakpoints, obtain the GDB result values ​​of the preset variables at each calculation, and save them to the GDB log file; Generate the fsdbreport command based on the comparison configuration information, call and run the fsdbreport command, obtain the fsdb result value of the preset signal signal_1 when each sampling condition takes effect, and save it to the fsdb log file; Accurately compare the result values ​​in the GDB log file and the fsdb log file, and count information such as the number of errors and error locations.

[0041] Debug breakpoints can be set based on specific circumstances. After setting a debug breakpoint in the GDB debug command, the program will stop each time it reaches the breakpoint, and the GDB result values ​​of the preset variables at that time will be printed. The number of repetitions can also be set based on specific circumstances. For example, setting the number of repetitions to 1000 means that after the program reaches this debug breakpoint 1000 times, it will exit debugging and obtain the GDB result values ​​of the preset variables for the first 1000 times of running to the debug breakpoint.

[0042] In an exemplary embodiment, the fuzzy comparison method includes: When the nth GDB result value is inconsistent with the nth fsdb result value, the nth GDB result value is compared with the (n-1)th or (n+1)th fsdb result value.

[0043] In one exemplary embodiment, signal tracking includes: Parse the trace configuration file, call the PyNPI interface, and compile the register transfer level code file list; Call the PyNPI trace_dirver2 function interface to obtain the driving signal list signal_list of the waveform signal to be traced; Traverse the driving signal signal_d in the driving signal list signal_list, call the PyNPIwaveform.sig_hdl_value_at function interface, and track the signal value within n clock cycles forward; Determine whether the driving signal signal_d in the driving signal list signal_list is equal to the expected value fsdb_exp of the fsdb simulation waveform signal within n clock cycles. If the value is equal, continue tracing until the driving signal signal_d in the driving signal list signal_list no longer matches the same value within the number of clock cycles to be traced forward, trace_cycles (i.e., [T - trace_cycles, T]). Parse the source code of the C language reference model and find the driver variable list CList of the specified variable in the specified function. The specified function and the specified variable are obtained from the variable name and function name of the C language reference model to be traced. Traverse all combinations of drive signals signal_d and drive variables in the drive signal list signal_list and the drive variable list CList, generate a new configuration file for each combination and feed it back to the user for selection and execution.

[0044] It should be understood that Figure 5 The apparatus shown in the figure may correspond to the method described above in this specification. Thus, the operations, features, and advantages described above for the method are also applicable to the apparatus provided by the present invention and the modules included therein, and the operations, features, and advantages described above for the apparatus and the modules included therein are also applicable to the method provided by the present invention. For the sake of brevity, certain operations, features, and advantages will not be described in detail.

[0045] While specific functions have been discussed above with reference to specific modules, it should be noted that the functions of each module in the technical solution of the present invention may also be implemented as multiple modules, and / or at least some functions of multiple modules may be combined into a single module for implementation. The manner in which a specific module in the technical solution of the present invention performs an action includes the specific module itself performing the action, or being called or otherwise accessed by the specific module to perform the action (or performing the action in conjunction with the specific module). Therefore, the specific module that performs the action may include the specific module itself that performs the action and / or another module that is called or otherwise accessed by the specific module to perform the action.

[0046] Please refer to Figure 6 , which shows a structural block diagram of a device provided by another exemplary embodiment of the present invention.

[0047] In this embodiment, the device includes the algorithm module RTL to be tested, the algorithm Cmodel source code, the JSON configuration file, the GUI interface and interactive interface, and the underlying Python code.

[0048] Among them, the algorithm module RTL includes a configuration register group and various modules for implementing mathematical calculations; the algorithm Cmodel source code, implemented in C or C++ language, includes an input configuration file and various functions for implementing mathematical calculations; the JSON configuration file includes the compiled Cmodel file path, Cmodel source code file path, RTL file list, fsdb waveform file path, variable names to be tracked and their line numbers in the Cmodel source code file, signal names in the fsdb waveform, sampling conditions and signal paths, and other information.

[0049] The GUI interface and interactive interface include a file display and editing window for displaying and editing JSON configuration files, function buttons for triggering the comparison and tracing functions of Python code, and a display window for displaying the running log.

[0050] The underlying Python code is used to call GDB and Synopsys Verdi pynpi programming interfaces to implement the comparison and tracking functions of Cmodel and waveform files.

[0051] In addition to the above technical solutions, the present invention also provides an electronic device, which includes one or more processors and a memory for storing executable instructions. The one or more processors are configured to implement the above method via executable instructions. The present invention also provides a computer-readable storage medium, which stores a computer program, and when the computer program is executed by the processor, the processor executes the above method. In the following part of this specification, Figure 7 To describe illustrative examples of the aforementioned electronic device and computer-readable storage medium.

[0052] Figure 7 An example configuration of an electronic device 300 that can be used to implement the methods described herein is shown. The technical solutions of the present invention can also be implemented in whole or in part by electronic device 300 or similar devices / systems. Electronic device 300 can be a variety of different types of devices. Examples of electronic devices 300 include, but are not limited to, desktop computers, server computers, laptop or netbook computers, mobile devices, wearable devices, entertainment devices, televisions or other display devices, and automotive computers.

[0053] The electronic device 300 may include at least one processor 302, memory 304, communication interface(s) 309, a display device 301, other input / output (I / O) devices 310, and one or more mass storage devices 303, all capable of communicating with each other via a system bus 311 or other appropriate connections.

[0054] The processor 302 may be a single or multiple processing units, all of which may include a single or multiple computing units or multiple cores. The processor 302 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any device that manipulates signals based on operational instructions. Among other capabilities, the processor 302 may be configured to retrieve and execute computer-readable instructions stored in the memory 304, mass storage device 303, or other computer-readable media, such as program code of an operating system 305, application programs 306, or other programs 307.

[0055] Memory 304 and mass storage device 303 are examples of computer-readable storage media for storing instructions that are executed by processor 302 to implement the various functions described above. For example, memory 304 may generally include both volatile memory and non-volatile memory. In addition, mass storage device 303 may generally include a hard drive, a solid-state drive, removable media, including external and removable drives, memory cards, flash memory, floppy disks, optical disks, storage arrays, network attached storage, storage area networks, etc. Memory 304 and mass storage device 303 may be collectively referred to as memory or computer-readable storage media in the present invention and may be non-transitory media capable of storing computer-readable, processor-executable program instructions as computer program code that may be executed by processor 302 as a specific machine configured to implement the operations and functions described in the examples of the present invention.

[0056] A plurality of programs may be stored on the mass storage device 303. These programs include an operating system 305, one or more application programs 306, other programs 307, and program data 308, and they may be loaded into the memory 304 for execution. Examples of such applications or program modules may include, for example, computer program logic (e.g., computer program code or instructions) for implementing the following components / functions: the methods provided by the present invention (including any suitable steps of the methods) and / or other embodiments described herein.

[0057] Although Figure 7 304 of the electronic device 300, but the modular operating system 305, application programs 306, other programs 307, and program data 308, or portions thereof, may be implemented using any form of computer-readable media accessible by the electronic device 300. Here, a computer-readable medium may be any available computer-readable storage medium or communication medium accessible to a computer. Communication media include media such as communication signals for transmitting computer-readable instructions, data structures, program modules, or other data from one system to another. Communication media may include guided transmission media and wireless media capable of propagating energy waves. Computer-readable instructions, data structures, program modules, or other data may be embodied as, for example, modulated data signals in a wireless medium.

[0058] For example, computer-readable storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. For example, computer-readable storage media include, but are not limited to, volatile memory, such as random access memory (RAM, DRAM, SRAM); and non-volatile memory, such as flash memory, various read-only memories (ROM, PROM, EPROM, EEPROM), magnetic and ferromagnetic / ferroelectric memories (MRAM, FeRAM); and magnetic and optical storage devices (hard disks, magnetic tapes, CDs, DVDs); or other known media or later developed media capable of storing computer-readable information / data for use by a computer system.

[0059] One or more communication interfaces 309 are used to exchange data with other devices, such as via a network, direct connection, or the like. This communication interface can be one or more of the following: any type of network interface, wired or wireless (e.g., WLAN) interface, Wi-MAX interface, Ethernet interface, USB interface, cellular network interface, Bluetooth interface, NFC interface, or the like. Communication interface 309 can facilitate communication within a variety of network and protocol types, including wired and wireless networks, the Internet, and the like. Communication interface 309 can also provide communication with external storage devices (not shown), such as storage arrays, network-attached storage, storage area networks, and the like.

[0060] In some examples, a display device 301 such as a monitor may be included for displaying information and images to a user. Other I / O devices 310 may be devices that receive user input and provide output to the user, and may include touch / gesture input devices, cameras, keyboards, remote controls, mice, audio input / output devices, etc.

[0061] The technical solutions described in the present invention can be supported by these various configurations of the electronic device 300 and are not limited to the specific examples of the technical solutions described in the present invention. The illustrations and descriptions of the present invention in the foregoing text and the accompanying drawings are not restrictive. It is obvious to those skilled in the art that the present invention is not limited to the details of the above exemplary embodiments, and the present invention can also be implemented in other specific forms without departing from the spirit or basic characteristics of the present invention. Therefore, the scope of protection claimed by the present invention is defined by the claims rather than the above description, and all changes that fall within the meaning and scope of the equivalent elements of the claims are included in the scope of protection of the present invention.

Claims

1. A method for verifying and debugging a chip algorithm module, characterized in that: The method comprises: S1: Prepare a verification test environment, run a test case to generate an fsdb simulation waveform signal file of the test case, and compile the source code of the C language reference model to generate a C language reference model executable file with debugging information; S2: Create and edit a configuration file, wherein the configuration file includes configuration information, wherein the configuration information includes a preset signal signal_1, preset variables, and sampling conditions of the fsdb simulation waveform signal; S3: reading the configuration file, generating a GDB debugging command according to the configuration information, calling and running the GDB debugging command to execute the C language reference model executable file, thereby obtaining the GDB result value of the preset variable in each calculation, and saving it to a GDB log file; S4: Generate an fsdbreport command according to the configuration information, call and run the fsdbreport command, obtain the fsdb result value of the preset signal signal_1 each time the sampling condition takes effect based on the fsdb simulation waveform signal file, and save it to the fsdb log file; S5: Compare the GDB result value with the fsdb result value, and if the two are consistent, end the method; if the two are inconsistent, execute S6; S6: calling the PyNPI interface to compile the register transfer level code file list of the test case; S7: Call the PyNPI lang.trace_driver function interface to obtain the driver signal list signal_list of the original signal signal_c; S8: traverse the drive signal signal_d in the drive signal list signal_list, call the PyNPIwaveform.sig_hdl_value_at function interface, and trace forward the signal value within n clock cycles in the fsdb simulation waveform signal file; S9: Determine whether the driving signal signal_d in the driving signal list signal_list has an equal value to the original signal signal_c within the n clock cycles. If an equal value is found, use the driving signal signal_d as the original signal signal_c and return to S7. If an equal value is not found, execute S10. S10: Obtain a driving signal list signal_list of the original signal signal_csignal_c, parse the source code of the C language reference model, and obtain a driving variable list of the preset variables; S11: traverse all combinations of driving signals signal_d and driving variables in the driving signal list signal_list and the driving variable list, generate a new configuration file for each combination, and obtain multiple new configuration files; S12: Select one from the multiple new configuration files, and return to S3.

2. The method according to claim 1, characterized in that The preset variable is the variable name in the source code file of the C language reference model, and the preset signal signal_1 is the signal name in the fsdb simulation waveform signal.

3. The method according to claim 1, characterized in that The configuration information includes the C language reference model executable file path, the C language reference model source code path, the register transfer level code file list of the test case, the fsdb simulation waveform signal file path, the variable name to be tracked and its line number in the source code, the signal name in the waveform signal file, the sampling conditions and signal path, etc.

4. A device for verifying and debugging a chip algorithm module, characterized in that: The device comprises: An initialization module is configured to verify the test environment and run the test case to generate an fsdb simulation waveform signal file of the test case, and compile the source code of the C language reference model to generate a C language reference model executable file with debugging information; The comparison module is used to compare the value of the preset variable with the value of the fsdb simulation waveform signal point by point, including: A comparison configuration module is configured to create a comparison configuration file, wherein the comparison configuration file includes comparison configuration information; a comparison execution module configured to load the comparison configuration file and perform file comparison, wherein when the sampling conditions of the FSDB simulation waveform signal are known, the file comparison adopts a precise comparison method; when the sampling conditions of the FSDB simulation waveform signal are unknown, the file comparison adopts a fuzzy comparison method; A tracking module, used for automatically tracking the driving path of the fsdb simulation waveform signal forward when the comparison is inconsistent, including: a tracing configuration module configured to create a tracing configuration file, wherein the tracing configuration file includes tracing configuration information; The tracing execution module is configured to load the tracing configuration file and execute signal tracing.

5. The device according to claim 4, characterized in that Also includes: The graphical user interface module is configured to load and edit the comparison configuration file and the tracking configuration file, control the comparison and tracking operation process, and display the operation process and log files.

6. The device according to claim 4, characterized in that The comparison configuration information includes: The C language reference model executable file path, the C language reference model source code path, the fsdb simulation waveform signal file path, the C language reference model variable name to be compared, the location and number of repetitions of the C language reference model debugging breakpoint, whether the C language reference model variable name is an array and the array dimension, the waveform signal name and signal hierarchy to be compared, the sampling conditions of the waveform signal to be compared, the sampling start and end time, whether the waveform signal to be compared is an array and the array dimension.

7. The device according to claim 4, characterized in that The tracking configuration information includes: The C language reference model executable file path, the source code path of the C language reference model, the fsdb simulation waveform signal file path, the module name of the test case in the verification environment, the C language reference model variable name, function name and file name to be traced, the fsdb simulation waveform signal name and signal hierarchy to be traced, the expected value of the fsdb simulation waveform signal, the time point to start tracing, the clock cycle of the traced signal, and the number of clock cycles to be traced forward.

8. The device according to claim 4, characterized in that The precise comparison method includes: Parsing the comparison configuration file, generating a GDB debugging command according to the comparison configuration information, calling and running the GDB debugging command, repeating multiple times at the debugging breakpoint, obtaining the GDB result value of the preset variable at each calculation, and saving it to a GDB log file; Generate an fsdbreport command according to the comparison configuration information, call and run the fsdbreport command, obtain the fsdb result value of the preset signal signal_1 when each sampling condition takes effect, and save it to the fsdb log file; Accurately compare the result values ​​in the GDB log file and the fsdb log file, and count information such as the number of errors and error locations.

9. The device according to claim 4, characterized in that The fuzzy comparison method includes: When the nth GDB result value is inconsistent with the nth fsdb result value, the nth GDB result value is compared with the (n-1)th or (n+1)th fsdb result value.

10. The device according to claim 7, characterized in that The signal tracking includes: Parse the trace configuration file, call the PyNPI interface, and compile the register transfer level code file list; Call the PyNPI trace_dirver2 function interface to obtain the driving signal list signal_list of the waveform signal to be traced; Traverse the drive signal signal_d in the drive signal list signal_list, call the PyNPIwaveform.sig_hdl_value_at function interface, and track the signal value within n clock cycles forward; Determine whether the driving signal signal_d in the driving signal list signal_list has an equal value to the expected value of the fsdb simulation waveform signal within the n clock cycles, and if the equal value is matched, continue tracking until the driving signal signal_d in the driving signal list signal_list no longer has an equal value within the number of clock cycles to be tracked forward; Parsing the source code of the C language reference model to find a list of driver variables of a specified variable in a specified function, where the specified function and the specified variable are obtained from the variable name and function name of the C language reference model to be traced; Traverse all combinations of drive signals signal_d and drive variables in the drive signal list signal_list and the drive variable list, generate a new configuration file for each combination and feed it back to the user for selection and execution.

11. An electronic device, characterized in that: The electronic device comprises: one or more processors; a memory for storing executable instructions; The one or more processors are configured to implement the method of any one of claims 1 to 3 via the executable instructions. 12 . A computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the processor is caused to perform the method according to claim 1 .

Images