Methods and apparatus for verifying and debugging chip algorithm modules

Abstract

This invention provides a method and apparatus for verifying and debugging chip algorithm modules, capable of automatically comparing and tracing the consistency between a C language reference model and simulation waveforms. The method includes: constructing a verification environment and generating fsdb waveforms and an executable file of the C language reference model with debugging information; generating GDB and fsdbreport commands based on configuration information, extracting variable values ​​and signal values, and performing consistency comparisons; if a match is found, the process ends; otherwise, signal tracing begins; during signal tracing, the PyNPI interface is called to trace the driving signals forward and analyze the signal value matching within the clock cycle; if no matching value is found, a new configuration file is generated and the debugging process is executed cyclically. The technical solution provided by this invention can automatically trace and quickly locate the root cause of problems in the early stages of algorithm module verification, supports dynamically adding comparison nodes, and reduces manual debugging costs.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit design verification technology, and in particular to a method and apparatus for verifying and debugging chip algorithm modules. Background Technology

[0002] Chip algorithm modules refer to application-specific integrated circuit (ASIC) modules specifically designed to accelerate specific algorithms. Their core objective is to achieve efficient algorithm execution through hardware architecture optimization (such as parallel computing units, customized data paths, and dedicated memory layers), overcoming the bottlenecks in computing power, energy efficiency, or latency of traditional central processing units (CPUs) or graphics processing units (GPUs). These modules are widely used in AI inference / training, video encoding / decoding, signal processing, and edge computing chips.

[0003] As the complexity of integrated circuit design continues to increase, more and more chips are using C or C++ languages ​​to build reference models (i.e., C language reference models, Cmodels) at the algorithm level, and implementing corresponding functional modules using Hardware Description Languages ​​(HDLs) at the hardware design level. In the chip verification process, verifying the consistency between the Cmodel and the Design under Test (DUT), i.e., the designed Register-transfer Level (RTL), becomes a crucial step in ensuring the correctness of the algorithm and the consistency of the hardware implementation. 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 typically requires significant time and cross-departmental collaboration between the verification, algorithm, and design teams to complete the debugging process.

[0004] Traditional verification methods typically employ the following process: providing the same inputs and configurations for both the Cmodel and the DUT RTL, obtaining the DUT's waveform signal file (such as fsdb (Fast Signal Database) format) through simulation tools, and comparing it with the Cmodel's output to determine if the outputs are consistent. While this method is intuitive, in practical engineering, there may be multiple calculation steps and conditional branches between the input and output. When a comparison fails, debugging personnel often struggle to quickly pinpoint the root cause of the problem by relying solely on the final output comparison. This results in an extremely cumbersome and time-consuming verification and debugging process, leading to high costs associated with cross-departmental collaboration.

[0005] To address the aforementioned issues, existing technologies have proposed a segmented comparison approach. Specifically, a common solution is to add intermediate comparison nodes between the design and the reference model, dividing the entire verification process into segments to narrow down the scope of the problem. For example, Chinese patent application CN202111652085.8 discloses a method that inserts multiple intermediate comparison nodes between the design and the reference model, breaking down the entire design into segments for verification. This breaks down the complex verification process into smaller segments, helping verification personnel quickly and accurately locate defects and improving problem-solving efficiency.

[0006] However, the alignment node insertion method adopted in CN202111652085.8 has certain limitations. On the one hand, since alignment nodes need to be predefined in the design and verification environment, the number of segments should not be too large, otherwise it will increase the implementation complexity. On the other hand, once the verification environment is established, it is difficult to dynamically add new alignment nodes, resulting in an inflexible adjustment of the inspection scope during debugging. Furthermore, the alignment process still requires manual analysis of intermediate results, resulting in a low degree of automation and impacting verification efficiency. Therefore, existing technologies still face the challenge of balancing efficiency and accuracy when dealing with large-scale, frequently iterating algorithm module verification tasks.

[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 problems in the early stages of algorithm module verification, support the dynamic addition of comparison nodes, and reduce the cost of manual debugging. Summary of the Invention

[0008] In view of this, the present invention provides a method and apparatus for chip algorithm module verification and debugging 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 includes:

[0010] S1: Prepare the verification test environment and run the test cases to generate the fsdb simulation waveform signal files for the test cases. Compile the source code of the C language reference model to generate the C language reference model executable file with debugging information.

[0011] S2: Create and edit the configuration file, which includes configuration information, including the preset signal_1, preset variables, and sampling conditions for the fsdb simulation waveform signal;

[0012] S3: Read the configuration file, generate GDB debugging commands based on 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 preset variables in each calculation and saving them to the GDB log file;

[0013] S4: Generate the fsdbreport command based on 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;

[0014] S5: Compare the GDB result value with the fsdb result value. If they match, the method ends; otherwise, execute S6.

[0015] S6: Call the PyNPI interface to compile the list of register transfer level code files for the test cases;

[0016] S7: Call the PyNPI lang.trace_driver function interface to obtain the driver signal list signal_list of the original signal signal_c;

[0017] 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 the signal value in the fsdb simulation waveform signal file over n clock cycles.

[0018] S9: Determine whether the driving signal signal_d in the driving signal list signal_list has the same value as the original signal signal_c within n clock cycles. If an equal value is found, use the driving signal signal_d as the original signal signal_c and return to execute S7. If no equal value is found, execute S10.

[0019] S10: Obtain the driving signal list of the original signal signal_c, parse the source code of the C language reference model, and obtain the driving variable list of the preset variables.

[0020] S11: Traverse the drive signal list signal_list and the drive variable list for all combinations of drive signals signal_d and drive variables, generate a new configuration file for each combination, and obtain multiple new configuration files;

[0021] S12: Select one of several new profiles and return to S3.

[0022] According to another aspect of the present invention, an apparatus for verifying and debugging a chip algorithm module is provided, wherein the apparatus comprises:

[0023] The initial module is configured to verify the test environment and run test cases to generate fsdb simulation waveform signal files for the test cases, and compile the source code of the C language reference model to generate an executable file of the C language reference model with debugging information;

[0024] The comparison module is used to compare the values ​​of preset variables with the values ​​of the fsdb simulation waveform signal point by point, including:

[0025] The comparison configuration module is configured to create a comparison configuration file, which includes comparison configuration information.

[0026] The comparison execution module is configured to load the comparison configuration file and perform file comparison. 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.

[0027] The tracking module, used to automatically trace the drive path of the FSDB simulated waveform signal forward when discrepancies arise, includes:

[0028] The tracing configuration module is configured to create tracing configuration files, which include tracing configuration information.

[0029] The tracing execution module is configured to load the tracing configuration file and perform signal tracing.

[0030] According to 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; the one or more processors are configured to implement the above-described method via the executable instructions.

[0031] According to another aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, causes the processor to perform the method described above.

[0032] As can be seen from the above technical solutions, the technical solutions provided by the present invention have at least the following advantages:

[0033] 1. Improve comparison efficiency and accuracy: By using GDB to automatically obtain variable values ​​in Cmodel and combining it with the fsdbreport tool to extract the corresponding signal values ​​in the fsdb simulation waveform signal file, automated consistency comparison is achieved without modifying the verification environment and supports unlimited check nodes, thus improving verification efficiency and accuracy.

[0034] 2. Enhance the automation and intelligence of debugging: Compile the DUT RTL code using PyNPI, trace the set of driving signals signal_d corresponding to the error points in the waveform, parse the Cmodel source code using Python, obtain the set of driving variables corresponding to the mismatch points in the Cmodel, and allow users to flexibly select combinations of signals and variables for comparison to quickly locate the root cause of the problem. Attached Figure Description

[0035] The accompanying drawings are provided to further understand the technical solutions of the present invention and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the technical solutions of the present invention, but do not constitute a limitation on the technical solutions of the present invention.

[0036] Figure 1 A flowchart illustrating the method provided by an exemplary embodiment of the present invention is shown;

[0037] Figure 2 A flowchart illustrating 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.

[0038] Figure 3 This illustration shows a scenario of multiple tracking and comparisons in the image processing algorithm module provided by an exemplary embodiment of the present invention;

[0039] Figure 4 The flowchart illustrates a method for multi-node comparison 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.

[0040] Figure 5 A structural block diagram of the apparatus provided by an exemplary embodiment of the present invention is shown;

[0041] Figure 6 A structural block diagram of an apparatus provided by another exemplary embodiment of the present invention is shown;

[0042] Figure 7 A structural block diagram of an electronic device provided by an exemplary embodiment of the present invention is shown. Detailed Implementation

[0043] Various exemplary embodiments of the present invention will now be described in detail with reference to the accompanying drawings. The descriptions of the exemplary embodiments are merely illustrative and are not intended to limit the invention or its application or use in any way. The invention can be implemented in many different forms and is not limited to the embodiments described herein. These embodiments are provided so that the invention will be thorough and complete, and will fully express the scope of the invention to those skilled in the art.

[0044] Unless explicitly stated otherwise, an element may be one or more unless otherwise specified. The terms “multiple / several” mean two or more, the term “based on” should be interpreted as “at least partially based on,” and the terms “and / or” and “at least one of…” cover any one of the listed items and all possible combinations thereof. Furthermore, expressions such as “first,” “second,” etc., are for descriptive purposes only and do not indicate or imply their relative importance or implicitly specify the number of technical features indicated.

[0045] Please refer to Figure 1 The diagram illustrates a flowchart of a method provided by an exemplary embodiment of the present invention.

[0046] The method for chip algorithm module verification and debugging provided by this invention includes:

[0047] S1: Prepare the verification test environment and run the test cases to generate the fsdb waveform signal files of the test cases. Compile the source code of the C language reference model to generate the C language reference model executable file with debugging information.

[0048] S2: Create and edit the configuration file, which includes configuration information, including the preset signal_1, preset variables, and sampling conditions for the fsdb simulation waveform signal;

[0049] S3: Read the configuration file, generate GDB debugging commands based on 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 preset variables in each calculation and saving them to the GDB log file gdb_log;

[0050] S4: Generate the fsdbreport command based on 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;

[0051] S5: Compare the GDB result value in gdb_log with the fsdb result value in fsdb_log. If they match, the process ends; otherwise, execute S6.

[0052] S6: Call the PyNPI interface to compile the list of register transfer level code files for the test cases;

[0053] S7: Call the PyNPI lang.trace_driver function interface to obtain the original signal (current waveform signal) signal_c's driver signal list signal_list;

[0054] 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 the signal value in the fsdb simulation waveform signal file over n clock cycles.

[0055] S9: Determine whether the driving signal signal_d in the driving signal list signal_list has an equal value with 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 execute S7. If no equal value is found, the process executes S10.

[0056] S10: Obtain the driving signal list signal_list of the original signal signal_c, parse the source code of the C language reference model, and obtain the driving variable list of the preset variables (in an exemplary embodiment, the preset variables are the variable names 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).

[0057] S11: Traverse the drive signal list signal_list and the drive variable list for all combinations of drive signals signal_d and drive variables, generate a new configuration file for each combination, and obtain multiple new configuration files;

[0058] S12: Select one of several new profiles and return to S3.

[0059] The method provided by this invention can be used not only for algorithm module or algorithm-based chip verification, but also for other types of scenarios that require precise comparison between the Cmodel and the DUT.

[0060] The sampling condition taking effect refers to the waveform signal sampling conditions (such as sampling at 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 condition for sampling read data is that rvalid=1 and rready=1, that is, the read data is valid only when both of these handshake signals are 1. Therefore, taking the AXI protocol as an example, the sampling condition taking effect is: the clock signal clk is at the rising edge, and rvalid=1 and rready=1.

[0061] 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 compiling the C language reference model (Cmodel) using the "-g option" of the GCC compiler. The "-g option" is a debugging option that indicates that debugging information (such as variable names, function names, source code line numbers, etc.) is generated during compilation and can be embedded into the generated executable file. The C language reference model executable file compiled with the "-g option" can be recognized and supported by the GNU Debugger (GDB): (1) pausing execution at a specific line of code or function to check variable values; (2) tracing code logic line by line; (3) directly outputting the real-time value of a specified variable.

[0062] The fsdbreport command is a command-line tool in the Synopsys Verdi debugging toolchain, primarily used to parse, analyze, or generate reports from fsdb waveform signal files.

[0063] The PyNPI (Python Native Programming Interface) is a Python API provided by the Synopsys Verdi debugging platform. It allows users to interact directly with Verdi via 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 file. Additionally, GDB debugging commands are used with the GNU debugger, enabling operations such as controlling program execution, viewing and modifying memory / registers, setting breakpoints, and analyzing crashes.

[0064] In one exemplary embodiment, the configuration file is in JSON format.

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

[0066] Please refer to Figure 2 The diagram illustrates a flowchart of 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.

[0067] Specifically, it includes the following steps:

[0068] (1) Compile the C language reference model using the "-g option" of the GCC compiler to generate an executable program file of the C language reference model that supports GDB debugging;

[0069] (2) Run the test cases for simulation verification and configure the simulation tool to generate the fsdb simulation waveform signal file;

[0070] (3) If an error occurs during the test case execution, the error signal name of the RTL 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 method described above.

[0071] (4) Open the GUI interface and load the JSON format configuration file, run the comparison function, and an error should appear in the comparison result at this time;

[0072] (5) Run the tracking function and select the signal and variable combination for the next tracking and comparison;

[0073] (6) If the selected combination of signals and variables passes the comparison (i.e. the waveform signal is completely consistent with the cmodel variable value), then select other possible combinations to continue tracing until the source of the error is found;

[0074] (7) Save and summarize the configuration files on all calculation paths during the tracing process. When debugging next time, you can directly load the file to quickly eliminate errors in the current path.

[0075] Please refer to Figure 3 This illustration shows a scenario of multiple tracking and comparison in the image processing algorithm module provided by an exemplary embodiment of the present invention.

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

[0077] from Figure 3 From this, we can know that:

[0078] At time Tn: The signal output value of the fsdb waveform is X, which is inconsistent with the output value of Cmodel;

[0079] The first tracing begins: Steps S6-S11 are executed. Since the outputs of nodes 8T, 9T, 10T, and 11T are all X, while the input of node 8T is Y, which is inconsistent with the output value, the computation unit of node 8T is the endpoint of the first tracing (equivalent to the signal value not changing from the output of node 8T to node 12T in this waveform. 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, intermediate nodes 9T, 10T, and 11T will not introduce errors).

[0080] First tracking complete: 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 the Cmodel, it is found that the signal value in the waveform is consistent with the variable value in the Cmodel, which means that no error was introduced here, and the comparison is successful.

[0081] Second tracking: The output value of node 7T at time Tn-5 is Y, which is inconsistent with Cmodel. However, the configuration parameter offset is consistent with Cmodel, indicating that the offset signal of node 7T did not introduce an error.

[0082] Third tracing: 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 was found that the RTL in the output of the 5T node is consistent with the Cmodel, but the value of the lcl gain parameter in the waveform is inconsistent with the Cmodel. This indicates that the error comes from the lcl gain parameter of the 6T node, and the root cause of the error is found.

[0083] Please refer to Figure 4 The diagram illustrates 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.

[0084] Specifically, it includes the following steps:

[0085] (1) Compile the C language reference model using the "-g option" of the GCC compiler to generate an executable program file of the C language reference model that supports GDB debugging;

[0086] (2) Run the test cases for simulation verification and configure the simulation tool to generate the fsdb simulation waveform signal file;

[0087] (3) If an error occurs during the comparison check of the register transfer level code between the C language reference model and the test case during the test case execution, a JSON format configuration file for multiple comparison nodes will be created, with no limit on the number of nodes;

[0088] (4) Open the GUI interface and load the JSON format configuration file, then run the comparison function;

[0089] (5) If it is found that all the comparisons before a certain node Tn are correct, but the comparisons after the node Tn are incorrect, then it can be concluded that the calculation of node Tn is incorrect.

[0090] (6) Reference Figure 2 The error handling method in the illustrated embodiment will continue to be tracked.

[0091] Please refer to Figure 5 The diagram illustrates a structural block diagram of the apparatus provided by an exemplary embodiment of the present invention.

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

[0093] The apparatus for chip algorithm module verification and debugging provided by this invention includes:

[0094] The initial module is configured to verify the test environment and run test cases to generate fsdb simulation waveform signal files for the test cases, and compile the source code of the C language reference model to generate an executable file of the C language reference model with debugging information;

[0095] The comparison module is used to compare the values ​​of preset variables with the values ​​of the fsdb simulation waveform signal point by point, including:

[0096] The comparison configuration module is configured to create a comparison configuration file, which includes comparison configuration information.

[0097] The comparison execution module is configured to load the comparison configuration file and perform file comparison. 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.

[0098] The tracking module, used to automatically trace the drive path of the FSDB simulated waveform signal forward when discrepancies arise, includes:

[0099] The tracing configuration module is configured to create tracing configuration files, which include tracing configuration information.

[0100] The tracing execution module is configured to load the tracing configuration file and perform signal tracing.

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

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

[0103] In an exemplary embodiment, the tracing 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 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 level to be traced, the expected value of the fsdb simulation waveform signal fsdb_exp, the start time of tracing, the clock cycle of the traced signal, and the number of clock cycles to be traced forward traced (trace_cycles).

[0104] In one exemplary embodiment, the precise comparison method includes:

[0105] The configuration file is parsed and compared. Based on the comparison configuration information, a GDB debugging command is generated, which is then called and run. The GDB debugging command is repeated multiple times at the debugging breakpoint to obtain the GDB result value of the preset variable in each calculation and save it to the GDB log file.

[0106] The fsdbreport command is generated based on the comparison configuration information. The fsdbreport command is called and run to obtain the fsdb result value of the preset signal_1 when the sampling conditions are effective each time, and save it to the fsdb log file.

[0107] It accurately compares the result values ​​in the GDB log file and the fsdb log file, and counts information such as the number of errors and the location of errors.

[0108] Debug breakpoints can be set according to specific needs. After setting a breakpoint in the GDB debugging command, the program will stop each time it reaches the breakpoint, and the GDB result value of the preset variable at that calculation will be printed. The number of repetitions can also be set according to specific needs. For example, setting the number of repetitions to 1000 means that the program will exit debugging after running to this breakpoint 1000 times, and the GDB result values ​​of the preset variable at the breakpoint in the first 1000 runs can be obtained.

[0109] In one exemplary embodiment, the fuzzy comparison method includes:

[0110] 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.

[0111] In one exemplary embodiment, signal tracking includes:

[0112] Parse the tracing configuration file, call the PyNPI interface, and compile the list of register transfer level code files;

[0113] Call the PyNPI trace_driver2 function interface to obtain the list of driving signals of the waveform signal to be traced, signal_list;

[0114] Iterate through the drive signal list signal_list and the drive signal signal_d in the PyNPIwaveform.sig_hdl_value_at function interface to trace the signal value over n clock cycles.

[0115] Determine if the drive signal signal_d in the drive signal list signal_list has an equal value to the expected value fsdb_exp of the fsdb simulation waveform signal within n clock cycles. If an equal value is found, continue tracing until the drive signal signal_d in the drive signal list signal_list no longer has an equal value within the number of clock cycles to be traced forward (i.e., [T-trace_cycles, T]).

[0116] Parse the source code of the C language reference model to find the driver variable list CList of the specified variable within 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.

[0117] Iterate through all combinations of driver signals (signal_d) and driver variables in the driver signal list (signal_list) and driver variable list (CList), generate a new configuration file for each combination, and provide feedback to the user for selection and execution.

[0118] It should be understood that Figure 5 The apparatus shown can be correlated with the methods described above in this specification. Therefore, the operations, features, and advantages described above for the methods are also applicable to the apparatus and its included modules provided by this invention, and the operations, features, and advantages described above for the apparatus and its included modules are also applicable to the methods provided by this invention. For the sake of brevity, some operations, features, and advantages will not be repeated.

[0119] Although 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 this invention can also be implemented by multiple modules, and / or at least some functions of multiple modules can be combined into a single module. The manner in which a specific module performs an action in the technical solution of this invention includes the specific module itself performing the action, or the specific module calling or otherwise accessing and performing the action (or combining with the specific module to perform the action). Therefore, the specific module performing the action may include the specific module itself performing the action and / or another module that the specific module calls or otherwise accesses and performs the action.

[0120] Please refer to Figure 6 This illustrates a structural block diagram of an apparatus provided by another exemplary embodiment of the present invention.

[0121] 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.

[0122] The algorithm module RTL includes a configuration register set and various modules for implementing mathematical calculations; the algorithm Cmodel source code, implemented in C or C++, includes an input configuration file and various functions for implementing mathematical calculations; and the JSON configuration file includes the path to the compiled Cmodel file, the path to the Cmodel source code file, a list of RTL files, the path to the fsdb waveform file, the names of the variables to be tracked and their line numbers in the Cmodel source code file, the signal names in the fsdb waveform, sampling conditions, and signal paths, etc.

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

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

[0125] In addition to the above-described technical solutions, the present invention also provides an electronic device comprising one or more processors and a memory for storing executable instructions. The one or more processors are configured to implement the above-described method via executable instructions. The present invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, causes the processor to perform the above-described method. In the following sections of this specification, [further details will be provided]. Figure 7 Illustrative examples are provided to describe the aforementioned electronic devices and computer-readable storage media.

[0126] Figure 7 An example configuration of an electronic device 300 that can be used to implement the methods described in this invention is shown. The technical solutions of this invention can also be implemented wholly or at least partially by the electronic device 300 or similar devices / systems. The electronic device 300 can be of various different types. Examples of the electronic device 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, automotive computers, etc.

[0127] Electronic device 300 may include at least one processor 302, memory 304, multiple communication interfaces 309, display device 301, other input / output (I / O) devices 310, and one or more mass storage devices 303 capable of communicating with each other via system bus 311 or other suitable connection.

[0128] Processor 302 may be one or more processing units, and all processing units may include one or more computing units or multiple cores. 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 operating instructions. Among other capabilities, processor 302 may be configured to fetch and execute computer-readable instructions stored in memory 304, mass storage device 303, or other computer-readable media, such as program code of operating system 305, application program 306, or other program 307.

[0129] Memory 304 and mass storage device 303 are examples of computer-readable storage media for storing instructions executed by processor 302 to perform the various functions described above. For example, memory 304 can generally include both volatile and non-volatile memory. Furthermore, mass storage device 303 can generally include hard disk drives, solid-state drives, 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 can both be collectively referred to as memory or computer-readable storage media in this invention, and can be non-transitory media capable of storing computer-readable, processor-executable program instructions as computer program code, which can be executed by processor 302 as a specific machine configured to perform the operations and functions described in the examples of this invention.

[0130] Multiple programs can be stored on mass storage device 303. These programs include operating system 305, one or more application programs 306, other programs 307, and program data 308, and they can be loaded into memory 304 for execution. Examples of such application programs 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 method) and / or other embodiments described in the present invention.

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

[0132] For example, computer-readable storage media may include volatile and non-volatile, removable and non-removable media implemented by any method or technology for storing 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 memories such as random access memory (RAM, DRAM, SRAM); and non-volatile memories 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 those developed hereafter capable of storing computer-readable information / data for use by a computer system.

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

[0134] In some examples, a display device 301, such as a monitor, may be included for displaying information and images to the 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.

[0135] The technical solutions described in this invention can be supported by various configurations of the electronic device 300, and are not limited to the specific examples of the technical solutions described in this invention. The foregoing description and illustrations of this invention are not restrictive. It will be apparent to those skilled in the art that this invention is not limited to the details of the exemplary embodiments described above, and that this invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the scope of protection claimed by this invention is defined by the claims rather than the foregoing description, and all variations falling within the meaning and scope of equivalents of the claims are covered within the scope of protection of this invention.

Claims

1. A method for verifying and debugging chip algorithm modules, characterized in that, The method includes: S1: Prepare the verification test environment and run the test cases to generate the fsdb simulation waveform signal file of the test cases. 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 the configuration file, which includes configuration information, including the preset signal_1, preset variables, and sampling conditions for the fsdb simulation waveform signal; S3: Read the configuration file, generate a GDB debugging command based on the configuration information, call and run 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 the GDB log file; S4: Generate the fsdbreport command according to the configuration information, call and run the fsdbreport command, obtain the fsdb result value of the preset signal signal_1 when the sampling condition takes effect each time 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 they are the same, the method ends. If they are not the same, proceed to S6. S6: Call the PyNPI interface to compile the list of register transfer level code files for the test cases; 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 the signal value in the fsdb simulation waveform signal file over n clock cycles. S9: Determine whether the driving signal signal_d in the driving signal list signal_list has an equal value with 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 execute S7. If no equal value is found, execute S10. S10: Obtain the driving signal list signal_list of the original signal signal_c, parse the source code of the C language reference model, and obtain the driving variable list of the preset variable; S11: Traverse the drive signal list signal_list and all combinations of drive signals signal_d and drive variables in the drive variable list, and generate a new configuration file for each combination to obtain multiple new configuration files; S12: Select one of 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 executable file path of the C language reference model, the source code path of the C language reference model, the list of register transfer level code files for the test cases, the path of the fsdb simulation waveform signal file, the name of the variable to be tracked and its line number in the source code, the signal name, sampling conditions and signal path in the waveform signal file, etc.

4. An apparatus for verifying and debugging chip algorithm modules, characterized in that, The device includes: The initial module is configured to verify the test environment and run test cases to generate the fsdb simulation waveform signal files of the test cases, and compile the source code of the C language reference model to generate the C language reference model executable file with debugging information; The comparison module is used to compare the values ​​of preset variables with the values ​​of the fsdb simulation waveform signal point by point, including: The comparison configuration module is configured to create a comparison configuration file, which includes comparison configuration information. The comparison execution module is configured to load the comparison configuration file and perform file comparison. 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, used to automatically trace the drive path of the fsdb simulated waveform signal forward when discrepancies are found, includes: The tracking configuration module is configured to create a tracking configuration file, which includes tracking configuration information. The tracing execution module is configured to load the tracing configuration file and perform signal tracing. The precise comparison methods include: The comparison configuration file is parsed, a GDB debugging command is generated based on the comparison configuration information, the GDB debugging command is called and run, and the process is repeated multiple times at the debugging breakpoint to obtain the GDB result value of the preset variable in each calculation and save it to the GDB log file. The fsdbreport command is generated based on the comparison configuration information, the fsdbreport command is called and run, the fsdb result value of the preset signal_1 is obtained when the sampling condition takes effect each time, and saved to the fsdb log file; The results values ​​in the GDB log file and the fsdb log file are accurately compared, and information such as the number of errors and the location of errors is statistically analyzed. Furthermore, 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.

5. The apparatus 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 running process and log files.

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

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

8. The apparatus according to claim 7, characterized in that, The signal tracking includes: Parse the tracing configuration file, call the PyNPI interface, and compile the register transfer level code file list; Call the PyNPI trace_driver2 function interface to obtain the list of driving signals of the waveform signal to be traced, signal_list; Iterate through the drive signal signal_d in the drive signal list signal_list, and call the PyNPIwaveform.sig_hdl_value_at function interface to trace the signal value forward n clock cycles; Determine whether the drive signal signal_d in the drive signal list signal_list has the same value as the expected value of the fsdb simulation waveform signal within the n clock cycles. If an equal value is found, continue tracking until the drive signal signal_d in the drive signal list signal_list no longer has an equal value within the number of clock cycles to be tracked forward. Parse the source code of the C language reference model to find the list of driving variables of a specified variable within a 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. Iterate through the drive signal list signal_list and the drive variable list for all combinations of drive signals signal_d and drive variables, generate a new configuration file for each combination, and provide feedback to the user for selection and execution.

9. An electronic device, characterized in that, The electronic device includes: one or more processors; Memory, which is used to store 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.

10. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, causes the processor to perform the method of any one of claims 1 to 3.

Images