An automated verification method for a DSP core operation module

Abstract

The application discloses a kind of automation verification methods of DSP kernel operation module, belong to integrated circuit design verification technical field, the application adopts progressive serial linkage architecture, global parameter is overall planned by configuration and scheduling module, six big sub-modules of core execution module complete whole process work of use case generation, Goldenfile construction, simulation environment generation, simulation scheduling, result comparison, error screening according to serial logic;Goldenfile is built relying on hardware calibration, use case is generated in combination with constraint randomization and exclusive boundary constraint, the result is verified simultaneously by bit-by-bit comparison algorithm, and the cooperation of each link is realized by the standard of unified interface calling rule and data flow. The application realizes the end-to-end automation of DSP kernel operation module verification, improves verification efficiency, coverage and accuracy, reduces reuse cost, and can be widely applied to the research and development process of high-performance DSP chips in industrial control, signal processing and the like.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit design verification technology, specifically to an automated verification method for DSP core operation modules. It is applicable to module-level functional verification, boundary scenario verification, and iterative regression verification of fixed-point / floating-point DSP core operation modules, and can be widely used in the R&D process of high-performance DSP chips in industrial control, signal processing, and other fields. Background Technology

[0002] DSP core verification is a critical step in the integrated circuit design flow. Verification personnel need to embed an iterative regression process of "design-verification-optimization-verification" to support core design optimization through continuous verification feedback. As the complexity of integrated circuits continues to increase, the functional density and computational accuracy of DSP core computing modules have significantly improved, leading to higher requirements for verification efficiency, coverage, and accuracy.

[0003] While the industry has established mature and standardized verification processes, traditional VerilogHDL-based targeted testing and semi-automated script verification remain the mainstream solutions in DSP core computing module verification scenarios. The UVM verification methodologies introduced by some teams also largely follow general frameworks without deep automation customization tailored to the specific characteristics of the computing modules, making it difficult to adapt to the detailed verification needs of DSP core computing modules. Specifically, the following technical pain points exist:

[0004] The verification architecture is fragmented, and the various verification stages lack unified integration. They rely on independent scripts, third-party tools, and manual coordination, which cannot form an end-to-end automated closed loop. This not only results in low verification efficiency but also easily introduces human error and increases the risk of rework.

[0005] It is difficult to balance verification efficiency and coverage. Traditional targeted testing relies on human experience to design test cases, which is prone to leaving verification blind spots. Existing random testing solutions lack dedicated constraint logic for computing modules, which easily generates a large number of invalid test cases, resulting in a waste of resources.

[0006] Verification scripts and test environments are mostly custom-developed for specific modules with fixed bit widths, lacking parameterized adaptation logic, resulting in extremely low reusability across modules and projects and high costs for repeated development.

[0007] The screening of massive test case results relies on manual work, which is cumbersome and prone to missing critical errors. At the same time, it lacks the ability to filter error types, resulting in low efficiency in error location and tracing, which restricts the pace of verification and design iteration.

[0008] When adapting the UVM general framework to verify DSP computing modules, it requires deep customization, which is complex, costly, and heavy, and cannot meet the lightweight automation requirements of computing module-level verification.

[0009] In summary, existing verification schemes lack sufficient automation in the verification of DSP kernel computing modules, failing to meet the core requirements of "high coverage, high automation, high adaptability, and high accuracy," thus becoming a major bottleneck restricting the progress of DSP kernel R&D. Summary of the Invention

[0010] The purpose of this invention is to overcome the shortcomings of the prior art and provide an automated verification method for DSP core computing modules, so as to realize end-to-end automation of DSP core computing module verification, improve verification efficiency, coverage and accuracy, and reduce reuse costs.

[0011] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0012] An automated verification method for a DSP core computing module includes the following steps:

[0013] Step 1, Parameter Configuration and Task Startup: Define the DSP kernel operation module through a text configuration file to verify the core parameters of the entire process. After parsing the core parameters, the configuration and scheduling module issues instructions to trigger the core execution module to start working according to the serial progressive logic. The core parameters include operation type and associated parameters, process global variables, assembly template, and file storage path.

[0014] Step 2, Test Case Generation: The test case generation module automatically generates test cases with randomized constraint logic and dedicated constraint logic of the DSP kernel operation module, which are based on the randomized constraint logic and the dedicated constraint logic of the DSP kernel operation module. After deduplication, the standardized test data file is output and pushed to the Goldenfile construction module and the configurable simulation environment generation module. The dedicated constraint logic includes IEEE754 floating-point standard constraints and fixed-point operation overflow boundary conditions.

[0015] Step 3: Construction of Hardware Calibration Goldenfile: The Goldenfile construction module reads the test data file, automatically generates an assembly / C file adapted to the compiler software, controls the development board to execute test cases through the compiler software, extracts the standard hardware results after the development board's calculations, generates a TXT format Goldenfile after data verification and format standardization, and stores it in the specified folder of the simulation environment according to preset rules.

[0016] Step 4: Configurable simulation environment generation and simulation execution: The configurable simulation environment generation module automatically generates Testbench, Filelist, and Makefile based on the configuration file parameters and the interface information of the computing module; the simulation scheduling module calls the simulation tool through a script, loads the above files to start batch simulation, outputs the simulation result file in a standard format, and saves the logs.

[0017] Step 5, High-precision result comparison and log analysis: The high-precision result comparison and log analysis module uses a bit-by-bit comparison algorithm to verify the consistency between the simulation result file and the Goldenfile. If a data difference is detected, it is determined that the calculation module is abnormal. At the same time, the module establishes a mapping relationship between the error location and the test case, analyzes the flag register to determine the error type, and generates a structured log containing exception details.

[0018] Step 6, Error Test Case Locking and Classification: The error test case locking and type filtering module parses the structured log, automatically locks error test cases from a massive number of test cases, classifies error types according to preset rules, and generates a table containing error test case details, error type classification, and corresponding signal characteristics;

[0019] Step 7, Closed-loop iterative optimization: Designers debug and modify the RTL design code based on the table, and verification personnel supplement targeted test cases based on the error analysis results. The above automated verification process is restarted until no error test cases are detected, forming a closed loop of "design-verification-optimization-re-verification".

[0020] As a further technical solution of the present invention: the text configuration file mentioned in step 1 adopts a format that can be stably parsed, supports server-side scripting integration and batch verification requirements, and can flexibly modify configuration items according to actual verification logic, hardware environment and tool characteristics.

[0021] As a further technical solution of the present invention: the Goldenfile mentioned in step 3 is uniquely associated with the corresponding test data file, and the construction process relies on a dedicated data export script tool to complete the hardware result extraction, with zero human intervention throughout the process.

[0022] As a further technical solution of the present invention: the simulation scheduling module in step 4 constructs a lightweight simulation task scheduling system, supports the orderly management of multi-task parallel simulation, and records the execution results through a dual mechanism of terminal output and log retention during the simulation process.

[0023] As a further technical solution of the present invention: the DSP kernel operation module includes a fixed-point operation module and a floating-point operation module, and the method is adapted to the module-level functional verification, boundary scene verification and iterative regression verification of DSP kernel operation modules with different bit widths and sign attributes.

[0024] An automated verification architecture for a DSP kernel computing module that implements the above method includes a configuration and scheduling module and a core execution module. The configuration and scheduling module and the core execution module achieve instruction and data interaction through unified interface call rules and data flow standards.

[0025] The configuration and scheduling module includes a text configuration file parsing unit and a verification task scheduling unit. It adopts a text configuration file driven mode to parse the core parameters of the entire verification process, issue verification task instructions, and schedule the collaborative operation of various sub-modules of the core execution module.

[0026] The core execution module includes a test case generation module, a Goldenfile construction module, a configurable simulation environment generation module, a simulation scheduling module, a high-precision result comparison and log analysis module, and an error test case locking and type filtering module, all of which use scripts as the underlying execution carrier to complete the fully automated execution and analysis traceability of the DSP kernel computing module verification process.

[0027] As a further technical solution of the present invention: the test case generation module uses Python script as the execution core, has a built-in test case deduplication mechanism, and the output format and field column order are preset by the configuration file, which can be flexibly adjusted according to the verification needs of different modules.

[0028] As a further technical solution of the present invention: the Goldenfile building module uses a Python script chain as its execution core, and its core feature is to build a comparison benchmark based on hardware calibration data, and to use the hardware calculation results of the development board as the only data source for Goldenfile construction, thereby avoiding the theoretical deviation of pure software simulation.

[0029] As a further technical solution of the present invention: the configurable simulation environment generation module is based on parameterized script automation technology, refers to the modular process concept of the UVM verification framework and does not introduce additional framework dependencies, realizes the automated generation of customized verification environment, and reduces the customization cost of verification of computing modules.

[0030] As a further technical solution of the present invention: the error test case locking and type filtering module takes customized analysis scripts as its core, automatically completes the screening of massive test case results, error test case locking and type classification, and transforms scattered error information into accurate design and debugging feedback content.

[0031] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0032] Architectural innovation enables end-to-end closed-loop automation: Constructing a lightweight automated verification system with a complete closed loop of "configuration-execution-analysis-optimization", adopting a progressive serial linkage architecture, and connecting scattered scripts, tools and files through unified interface call rules and data flow standards, breaking the fragmentation dilemma of the existing verification architecture, realizing end-to-end automation, shortening the verification cycle by more than 60%, and adapting to the needs of server-side interfaceless automated deployment and batch verification.

[0033] Strong parameterization and adaptation capabilities, low reuse cost: By adopting text configuration file-driven + parameterized script technology, it can adapt to DSP kernel operation modules with different operation types, bit widths and sign attributes by modifying the configuration file. There is no need to modify the script and test environment in full. The cross-module and cross-project reuse rate is increased by more than 80%, which greatly reduces the cost of repeated development and customization.

[0034] Verification coverage and accuracy are both improved: The test case generation mechanism of "constraint randomization + operation module-specific boundary constraints" is adopted to achieve full coverage of both normal and special boundary scenarios, achieving 100% coverage of functional points while reducing redundant test cases; Goldenfile is built based on hardware calibration of the development board, and the result verification is completed by combining bit-by-bit comparison algorithm to avoid theoretical deviations of pure software simulation and significantly improve verification accuracy.

[0035] Efficient error tracing and improved iteration pace: Structured logs are generated through high-precision result comparison and flag analysis. Customized analysis scripts enable automatic identification and classification of error test cases, replacing manual massive screening work. This provides designers with accurate debugging feedback and establishes an efficient link between "verification screening and design debugging", improving overall verification and iteration efficiency by more than 50%.

[0036] Lightweight and easy to implement, with good scalability: Developed based on Python / Bash scripts, existing mainstream compilers and simulation tools, it eliminates the redundant dependencies of the UVM framework, takes into account the advantages of modularity and ease of use, and can be quickly compatible with existing verification processes without the need for additional tool costs; at the same time, based on the architecture design, it supports the expansion of functional modules and can adapt to the verification needs of future high-performance DSP chips. Attached Figure Description

[0037] Fig. 1 This is a module connection diagram of the automated verification architecture of the DSP kernel computing module of the present invention;

[0038] Fig. 2 This is a data flow diagram of the automated verification method for the DSP kernel computing module of the present invention. Detailed Implementation

[0039] The technical solutions in the embodiments of the present invention will be clearly and completely described below. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0040] like Figs. 1-2As shown, addressing the shortcomings of existing mature verification processes (including the UVM general framework) in lightweight automation and scenario-based adaptation for DSP kernel computing module verification, this paper proposes a fully closed-loop lightweight automated verification system based on "progressive serial linkage + scripted execution carrier + rule-based collaboration." This system integrates the modular approach of the UVM verification methodology, encompassing "test case generation - environment setup - simulation execution - result comparison - analysis and traceability." By connecting multiple scripts and tools through unified interface call rules and file flow standards, it achieves efficient automation upgrades to the core verification stages of the computing module. This system is complementary and adaptable to the UVM framework, meeting the full-scenario verification needs of fixed-point / floating-point computing modules. The core technical solution is as follows:

[0041] 1. Overall Architecture

[0042] This verification process centers on a collaborative closed loop of "configuration-execution-analysis-optimization," employing a progressive, serial linkage architecture. It integrates tool and file linkage standards as core supporting features, connecting various tools and different file types through unified interface call rules and data flow standards, integrating a set of functional modules into an organic whole. The architecture relies on configuration and scheduling modules to incorporate scattered Python scripts, Bash scripts, simulation tools, and data files into a process-oriented schedule. Each functional module executes collaboratively in a progressive sequence, achieving iterative optimization through closed-loop logic. Simultaneously, two unified standards (script calling tool specifications and data flow standards) ensure seamless logical connections and data flow at each stage, providing a rule-based basis for end-to-end collaboration. Overall, it possesses excellent scalability, configurability, and reusability.

[0043] The configuration and scheduling module, with its core consisting of a text configuration file parsing unit and a verification task scheduling unit, adopts a text-based configuration file-driven model to adapt to server-side automated deployment scenarios. The text configuration file defines the core parameters of the entire verification process (operation types and associated parameters (including bit width, symbol attributes, etc.), process global variables (including file flow rules, data format standards), Goldenfile, assembly templates required for environment setup program generation, file storage paths, etc.), initiates verification tasks, schedules various functional modules to operate collaboratively and progressively according to the process, and finally outputs a table containing different error types for kernel designers to reference and debug, adapting to server-side scripted integration and batch verification requirements.

[0044] The core execution module consists of six modules and is the core execution carrier of the process. It receives configuration instructions in a sequential and progressive manner and completes core tasks such as test case generation, comparison file construction, simulation environment setup, simulation execution, result comparison, and error screening in turn. It undertakes the automated execution and analysis traceability functions of the entire verification process.

[0045] 2. Detailed Design of Core Modules

[0046] The core execution module comprises six modules, using scripts as the underlying execution carrier and relying on a unified linkage standard to achieve fully automated collaboration in a sequential and progressive process. The functions of each module are as follows:

[0047] Test case generation module: Utilizing Python scripts as the execution core, this module leverages constraint randomization logic and embedded computational scenario constraint logic to automatically generate test cases for fixed-point / floating-point arithmetic scenarios. The script incorporates core logic such as IEEE 754 floating-point standard constraints and fixed-point arithmetic overflow boundary conditions. It can generate two types of test case sets through configuration parameters: random combination test cases of regular numerical values ​​(covering different ranges of regular numerical combinations) and combination test cases of boundary extreme values ​​and special values ​​(including scenarios such as maximum / minimum values, zero-value intersections, and overflow triggers, adaptable to both signed and unsigned arithmetic). It also integrates a test case deduplication mechanism. The output format and field column order are preset by the configuration file and can be flexibly adjusted according to the verification needs of different modules. It supports generating files of various specifications. Leveraging the flexible adaptability of configuration-driven design, it accurately matches the differentiated data call requirements of subsequent modules, ensuring compatibility and smoothness of data interaction throughout the entire process.

[0048] The Goldenfile building block uses a Python script chain as its execution core. Its core feature is "building a comparison benchmark based on hardware calibration data." By binding the hardware results from the development board, it ensures the accuracy of the comparison file and avoids theoretical deviations caused by pure software simulation. The process strictly follows the unified rules set by the architecture: ① Read the test data file output by the test case generation module and automatically generate an assembly / C file adapted to the compiler software; ② Control the development board to run test cases through the compiler software, and efficiently extract the standard results after the development board's calculations using a dedicated data export script tool developed by collaborators (this is the core hardware calibration step, serving as the sole data source for Goldenfile construction); ③ Perform data verification and format standardization on the extracted hardware results, remove abnormal data, and generate a TXT format Goldenfile according to the corresponding rules, with the name consistent with the corresponding test data file; ④ Store the Goldenfile in a designated folder in the simulation environment for automatic retrieval by the subsequent high-precision result comparison module to complete the comparison, achieving zero manual intervention throughout the entire process. This hardware calibration feature gives the comparison benchmark hardware-level authority, accurately matching the stringent accuracy requirements of fixed-point / floating-point arithmetic modules.

[0049] Configurable simulation environment generation module: Based on parameterized script automation technology, it automatically generates customized verification environments. It can automatically adapt to the instantiation requirements of different modules according to the module interfaces and preset parameters defined in the configuration file, accurately generating corresponding Testbench, Filelist, and Makefile. The design references the modular process concept of the UVM verification framework, without introducing additional framework dependencies. The core uses scripts to connect the modules at each stage, significantly reducing the customization cost of computation module verification through a lightweight script-based design.

[0050] Simulation Scheduling Module: Utilizing Bash scripts as the core execution carrier, this module constructs a lightweight simulation task scheduling system. By linking scripts across various stages, it achieves orderly management of multi-task parallel simulations. The module strictly adheres to the tool invocation specifications defined in the architecture, triggering simulation tools through commands and efficiently connecting the simulation needs of multiple modules and scenarios. During simulation, execution results are synchronously recorded through a dual mechanism of terminal output and log retention. Log files are generated in a unified format to ensure traceability and verifiability of results, providing a data source for subsequent result comparison modules.

[0051] The high-precision result comparison and log analysis module employs a high-precision bit-by-bit comparison algorithm combined with automatic log parsing logic to construct a rigorous result consistency verification mechanism. Adaptable to batch simulation verification scenarios, it achieves automated and accurate comparison of simulation results with the Goldenfile. The module pre-sets a "completely consistent result" criterion. Once a data discrepancy is detected, it immediately and accurately pinpoints an anomaly in the computation module. Simultaneously, it associates this with previously generated test cases, establishing a precise mapping between the error location and the test cases, quickly identifying the target test case causing the anomaly. Through comparison and analysis of the flag registers, the error type can be indirectly determined, and structured logs are generated synchronously. The log content includes details of the abnormal test cases, corresponding flag status, and error location information, providing accurate and complete data support for subsequent error case identification and classification modules.

[0052] Error Test Case Identification and Type Filtering Module: Its core is a customized analysis script specifically designed to solve the challenge of screening massive test case results. Based on the structured logs generated earlier, it automatically identifies target test cases with errors from a large number of test case results. Simultaneously, it filters and categorizes error types according to preset rules, generating a table containing "error test case details, error type classification, and corresponding signal characteristics." This transforms scattered error information into precise feedback content, directly providing it to designers for debugging and modification, significantly reducing manual screening costs and improving the efficiency of the "verification-debugging" process.

[0053] 3. Module connection relationships and data flow

[0054] Each module, script, and tool interacts and schedules commands through the tool and file linkage standards defined in the architecture, forming a complete verification loop. Specific connections, data flows, and corresponding relationships are as follows: Fig. 1 As shown.

[0055] The core execution module operates in a sequential and progressive manner, following the logic of "test case generation → Goldenfile construction → simulation environment generation → simulation scheduling → result comparison → error screening". Each sub-module achieves data and instruction connection through unified architectural rules, and tools are called by corresponding modules as needed, forming a collaborative system of "module-tool-data".

[0056] Data flow direction as follows Fig. 2 As shown:

[0057] 1. The text configuration file parsing unit of the configuration and scheduling module reads the parameters, and the task scheduling unit issues instructions to trigger the start of work of each functional unit of the core execution module. The configuration file serves as the parameter benchmark for the entire process.

[0058] 2. The test case generation module generates test data files and pushes them synchronously to the Goldenfile build module and the configurable simulation environment generation module to ensure that the data comes from the same source.

[0059] 3. The Goldenfile building module calls the compiler software through unified architectural rules, generates Goldenfile based on the hardware results of the development board, stores it according to the preset rules in the configuration file, and provides it for use by the high-precision result comparison module.

[0060] 4. After generating Testbench, Filelist, and Makefile, the simulation environment generation module triggers the simulation scheduling module according to the calling rules set by the architecture, calls the simulation tool to start the simulation according to unified parameters, and outputs the simulation results to the preset path in a standard format.

[0061] 5. The high-precision result comparison module reads the simulation result file and Goldenfile, generates a structured log file, and pushes it to the error test case locking and type filtering module according to the architecture rules. This module automatically screens a large number of test case results through analysis scripts, locks the error test cases, completes the error type classification, and outputs a table for designers to debug and modify, providing auxiliary support for designers to debug.

[0062] 6. Based on the error analysis results, guide the supplementary design of use cases for uncovered scenarios, drive iterative optimization of the verification process, and solidify the effectiveness and coverage depth of the complete verification loop.

[0063] Example

[0064] To more clearly illustrate the technical solution of this invention, the automated verification process is described in detail below using a verification scenario of the DSP core's 16-bit fixed-point addition module. This embodiment uses a hardware development board as the base platform and a Linux CentOS 7 system as the script execution environment, ensuring that those skilled in the art can reproduce this solution based on the following description.

[0065] This embodiment focuses on a 16-bit fixed-point signed addition module, verifying its basic functional correctness, overflow boundary handling capability, and data precision consistency. The entire process relies on this workflow to achieve end-to-end automated closed-loop operation. The specific steps are as follows:

[0066] 1. Parameter configuration and task startup

[0067] Load the preset text configuration file, which uses JSON key-value pair format to define the core parameters of the entire process, ensuring that the script can be parsed stably. The core configuration items are as follows:

[0068] / / Calculation parameter configuration

[0069] "op_sel" = "1'b0" / / Operation type: addition

[0070] "src1_sign" = "1'b1" / / Signed mode: Signed

[0071] "src2_sign" = "1'b1"

[0072] / / Simulation register configuration

[0073] "ADD16_Reg1" = "1'b1"

[0074] "ADD16_state_Reg" = "1'b1"

[0075] / / Goldenfile configuration

[0076] "asm_text" = " MOV Reg1, #0x{op1}\n

[0077] MOV Reg2, #0x{op2}\n

[0078] MOV Reg3, #0\n

[0079] PUSH Reg3\n

[0080] POP state_Reg\n

[0081] ADD Reg1, Reg2\n " / / Assembly file parameters

[0082] This document only lists the core configuration items. Other adaptability configuration items (such as tool runtime parameters, file names, file directories, etc.) can be flexibly set according to the actual verification logic, hardware environment, and tool characteristics. After the text parsing unit of the configuration and scheduling module reads the above parameters, it issues collaborative instructions through a Bash script to trigger each sub-module of the core execution module to start working in a serial manner. The configuration file serves as the parameter benchmark throughout the process and supports batch modification and reuse.

[0083] 2. Test Cases and Goldenfile Generation

[0084] ① The test case generation module is executed based on a Python script, calling the built-in constraint randomization logic and combining it with the 16-bit fixed-point addition-specific constraints (signed range -32768~32767, unsigned range 0~65535, overflow trigger condition is that the result exceeds the corresponding range). It generates two types of test case sets: one is a random combination of regular numerical test cases (covering random combinations of regular numerical values ​​in different intervals), and the other is a combination of boundary extreme values ​​and special values ​​(covering special scenario combinations such as maximum and minimum values, zero value intersections, positive and negative boundaries). There are tens of thousands of valid test cases in total. After removing duplicate data, the test data file in TXT format (named ADD16_input.txt) is output. The format is preset according to the configuration file to ensure compatibility with subsequent module calls.

[0085] ② The Goldenfile building module synchronously reads the aforementioned test data file and automatically generates an assembly file (named add_16bit_asm) adapted to the compiler software using a Python script. The assembly code contains logic for loading test cases, executing computation instructions, and storing results. Subsequently, the compiler software is called through unified architecture rules to establish a communication connection with the development board. The assembly file is downloaded to the development board and executed. Relying on a dedicated data export script, the standard result data after the development board's computation is extracted. After removing invalid data from hardware execution, a TXT format Goldenfile (named ADD16_golden_output.txt) is generated in the order corresponding to the test data file and stored in a preset path, uniquely associated with the test data file through a filename prefix.

[0086] 3. Simulation Environment Construction and Execution

[0087] ① The configurable simulation environment generation module is based on parameterized Python scripts. According to the interface information defined in the configuration file and obtained from the corresponding 16-bit fixed-point addition module RTL code, it automatically generates three types of core files: Testbench (named add16_tb.v), which includes logic such as module instantiation, test case reading, and simulation clock generation; Filelist, which lists the design files and Testbench file paths required for simulation; and Makefile, which defines the simulation tool's simulation compilation, execution instructions, and parameters.

[0088] ② The simulation scheduling module calls the simulation tool through a Bash script, reads the Makefile file mentioned above to start the simulation, loads all files specified in the Filelist during the compilation phase, and runs two types of test case execution modes in sequence during the execution phase (test cases with combinations of boundary extreme values ​​and special values ​​are executed independently, and test cases with random combinations of regular values ​​are executed in batches and continuously). The execution results are synchronously output to the terminal and the structured log file. The simulation result file (named ADD16_result.txt) is stored in a preset path in a standard format for subsequent comparison module calls.

[0089] 4. Result comparison and error screening

[0090] ① The high-precision result comparison and log analysis module reads the simulation result file and Goldenfile, and performs consistency verification using a bit-by-bit comparison algorithm. The default is "completely consistent results" as the sole criterion; if data discrepancies exist, the module is directly identified as malfunctioning. Simultaneously, the module associates the test case file, establishing a mapping between error locations and corresponding test cases. By comparing the DSP core flag register status in the simulation results, the error type is indirectly determined.

[0091] ② Generate a structured log file (named ADD16_differences.log), which includes basic simulation information, total number of test cases executed, error test case number, corresponding flag status and error location, providing complete data support for error screening.

[0092] ③ The error test case locking and type filtering module uses a customized Python analysis script to parse the above structured logs and automatically lock abnormal test cases (assuming that 80 overflow error test cases and 200 calculation result error test cases are detected in this embodiment). The module classifies the errors according to their types and generates an Excel spreadsheet (named ADD16result.xlsx). The spreadsheet fields include "error test case number, operand A, operand B, simulation result, standard result, and flag status", which are directly provided to the designers for debugging and modification.

[0093] 5. Iterative optimization

[0094] Based on the error table above, designers locate design flaws in the arithmetic module (such as omissions in overflow judgment logic or carry errors in the arithmetic circuit). After modifying the code, verification personnel supplement targeted test cases (for the fixed error scenarios and related scenarios) through the configuration and scheduling module, restart the automated verification process, and continue until no error test cases are detected, forming a closed-loop iteration of "design-verification-optimization-re-verification" to solidify the depth of verification coverage and the reliability of results.

[0095] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the invention. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, it is intended that all variations falling within the meaning and scope of equivalents of the claims be included within the present invention.

[0096] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This way of describing the specification is only for clarity. Those skilled in the art should regard the specification as a whole, and the technical solutions in each embodiment have been appropriately combined to form other embodiments that are easy for those skilled in the art to understand.

Claims

1. An automated verification method for a DSP core computing module, characterized in that, Includes the following steps: Step 1, Parameter Configuration and Task Startup: Define the DSP kernel operation module through a text configuration file to verify the core parameters of the entire process. After parsing the core parameters, the configuration and scheduling module issues instructions to trigger the core execution module to start working according to the serial progressive logic. The core parameters include operation type and associated parameters, process global variables, assembly template, and file storage path. Step 2, Test Case Generation: The test case generation module automatically generates test cases with randomized constraint logic and dedicated constraint logic of the DSP kernel operation module, which are based on the randomized constraint logic and the dedicated constraint logic of the DSP kernel operation module. After deduplication, the standardized test data file is output and pushed to the Goldenfile construction module and the configurable simulation environment generation module. The dedicated constraint logic includes IEEE754 floating-point standard constraints and fixed-point operation overflow boundary conditions. Step 3: Construction of Hardware Calibration Goldenfile: The Goldenfile construction module reads the test data file, automatically generates an assembly / C file adapted to the compiler software, controls the development board to execute test cases through the compiler software, extracts the standard hardware results after the development board's calculations, generates a TXT format Goldenfile after data verification and format standardization, and stores it in the specified folder of the simulation environment according to preset rules. Step 4: Configurable simulation environment generation and simulation execution: The configurable simulation environment generation module automatically generates Testbench, Filelist, and Makefile based on the configuration file parameters and the interface information of the computing module; the simulation scheduling module calls the simulation tool through a script, loads the above files to start batch simulation, outputs the simulation result file in a standard format, and saves the logs. Step 5, High-precision result comparison and log analysis: The high-precision result comparison and log analysis module uses a bit-by-bit comparison algorithm to verify the consistency between the simulation result file and the Goldenfile. If a data difference is detected, it is determined that the calculation module is abnormal. At the same time, the module establishes a mapping relationship between the error location and the test case, analyzes the flag register to determine the error type, and generates a structured log containing exception details. Step 6, Error Test Case Locking and Classification: The error test case locking and type filtering module parses the structured log, automatically locks error test cases from a massive number of test cases, classifies error types according to preset rules, and generates a table containing error test case details, error type classification, and corresponding signal characteristics; Step 7, Closed-loop iterative optimization: Designers debug and modify the RTL design code based on the table, and verifiers supplement targeted test cases based on the error analysis results. The above automated verification process is restarted until no error test cases are detected, forming a closed loop of "design-verification-optimization-re-verification".

2. The automated verification method for the DSP kernel operation module according to claim 1, characterized in that, The text configuration file mentioned in step 1 adopts a stable parsing format, supports server-side scripting integration and batch verification requirements, and allows for flexible modification of configuration items according to actual verification logic, hardware environment and tool characteristics.

3. The automated verification method for the DSP kernel operation module according to claim 1, characterized in that, In step 3, Goldenfile is uniquely associated with the corresponding test data file. The construction process relies on a dedicated data export script tool to extract hardware results, with zero human intervention throughout.

4. The automated verification method for the DSP kernel operation module according to claim 1, characterized in that, The simulation scheduling module described in step 4 constructs a lightweight simulation task scheduling system, which supports the orderly management of multi-task parallel simulation. The simulation process records the execution results through a dual mechanism of terminal output and log retention.

5. The automated verification method for the DSP kernel operation module according to claim 1, characterized in that, The DSP kernel operation module includes a fixed-point operation module and a floating-point operation module. The method is adapted to the module-level functional verification, boundary scenario verification, and iterative regression verification of DSP kernel operation modules with different bit widths and sign attributes.

6. An automated verification architecture for a DSP kernel computing module implementing the method of any one of claims 1-5, characterized in that, It includes a configuration and scheduling module and a core execution module. The configuration and scheduling module and the core execution module realize instruction and data interaction through unified interface call rules and data flow standards. The configuration and scheduling module includes a text configuration file parsing unit and a verification task scheduling unit. It adopts a text configuration file driven mode to parse the core parameters of the entire verification process, issue verification task instructions, and schedule the collaborative operation of various sub-modules of the core execution module. The core execution module includes a test case generation module, a Goldenfile construction module, a configurable simulation environment generation module, a simulation scheduling module, a high-precision result comparison and log analysis module, and an error test case locking and type filtering module, all of which use scripts as the underlying execution carrier to complete the fully automated execution and analysis traceability of the DSP kernel computing module verification process.

7. The automated verification architecture for the DSP kernel computing module according to claim 6, characterized in that, The test case generation module uses Python scripts as its execution core, has a built-in test case deduplication mechanism, and its output format and field column order are preset by the configuration file, which can be flexibly adjusted according to the verification needs of different modules.

8. The automated verification architecture for the DSP kernel computing module according to claim 6, characterized in that, The Goldenfile building module uses a Python script chain as its execution core. Its core feature is to build a comparison benchmark based on hardware calibration data and use the hardware calculation results of the development board as the sole data source for Goldenfile construction, thus avoiding theoretical deviations from pure software simulation.

9. The automated verification architecture for the DSP kernel computing module according to claim 6, characterized in that, The configurable simulation environment generation module is based on parametric script automation technology, references the modular process concept of the UVM verification framework, and does not introduce additional framework dependencies, thereby realizing the automated generation of customized verification environments and reducing the customization cost of computation module verification.

10. The automated verification architecture for the DSP kernel computing module according to claim 6, characterized in that, The error test case locking and type filtering module uses customized analysis scripts as its core to automatically screen massive test case results, lock error test cases, and classify types, transforming scattered error information into precise design and debugging feedback.

Images