Simulation verification method and system based on Vivado tool

Abstract

The invention provides a simulation verification method and system based on a Vivado tool, and the method comprises the following steps: calling an output function of the Vivado tool, and generating a script file of a whole simulation verification project; analyzing the script file, extracting a file list and tool operation parameters of a project, and generating a to-be-compiled file set; on the basis of the to-be-compiled file set, executing one-time full-engineering compiling, and generating a simulation verification executable file; receiving a single-use case name and a simulation parameter input externally, transmitting the single-use case name and the simulation parameter to the simulation verification executable file, running simulation and outputting a simulation verification result corresponding to the single-use case and the simulation parameter; wherein the step of compiling the project is separated from the step of running single-use-case simulation, multiple single-use-case simulation running is supported through one-time compiling, multiple repeated compiling is avoided, and the simulation verification efficiency is improved. The compiling time is greatly shortened, and the flexibility of simulation parameter input is enhanced.

Description

Technical Field

[0001] This application relates to the field of digital circuit verification technology, specifically to a simulation verification method and system based on the Vivado tool. Background Technology

[0002] Vivado is an integrated environment developed by Xilinx, an FPGA manufacturer, specifically for FPGA (Field-Programmable Gate Array) and SoC (System-on-a-Chip) design. It covers the entire design workflow, from design input and synthesis to placement and routing, simulation, and debugging. Vivado has gained widespread application and recognition in the FPGA and SoC design field, providing powerful design capabilities and efficient implementation tools that help shorten time-to-market and improve productivity. Vivado also supports various complementary integrated environments, including simulation and verification tools such as Modelsim, further optimizing the development process.

[0003] However, in actual use of Vivado's integrated simulation verification tools, whether it's Vivado's built-in simulation verification tool or third-party simulation verification tools like Modelsim, traditional simulation verification methods on Vivado tools suffer from low execution efficiency of simulation verification test cases. For an FPGA design project, there are inevitably multiple test cases designed for functional simulation verification. However, using traditional simulation verification methods on Vivado tools requires compiling the entire project before running each simulation verification test case. Compiling the entire project for each test case, with dozens or even hundreds of test cases, involves repetitive processes, consuming significant compilation time. Furthermore, if it's necessary to change certain simulation verification parameters in the simulation verification environment, such as module interface delay time or frequently changing parameters like the number of injected error bits, a new test case must be added for each simulation verification parameter. This increase in test case files significantly increases the size of the simulation verification environment and also increases the total compilation time for all simulation verification test cases. Summary of the Invention

[0004] In view of the above-mentioned defects or deficiencies in the prior art, this application aims to provide a simulation verification method and system based on the Vivado tool.

[0005] Firstly, this application proposes a simulation verification method based on the Vivado tool, comprising the following steps: Generate simulation verification script: Call the output function of the Vivado tool to generate the script file for the entire simulation verification project; Parse the simulation verification script: Parse the script file, extract the project file list and tool running parameters, and generate a set of files to be compiled; Compile the project: Based on the set of files to be compiled, perform a full project compilation to generate an executable file for simulation verification; Run single-use case simulation: Receive the single-use case name and simulation parameters from external input, pass the single-use case name and simulation parameters to the simulation verification executable file, run the simulation and output the simulation verification results of the corresponding single-use case and simulation parameters; The compilation process is separated from the single-case simulation process, allowing multiple single-case simulation runs to be supported by a single compilation, thus avoiding repeated compilation and improving simulation verification efficiency.

[0006] According to the technical solution provided in the embodiments of this application, the process of parsing the simulation verification script specifically includes the following steps: Identify and extract a list of design files from the script file, the list of design files including RTL code files, IP core description files and constraint files; Identify and extract the test platform file list from the script file, the test platform file list including test case files, stimulus generation files and reference model files; The tool's runtime parameters are analyzed and categorized, including compilation options and optimization level settings used during the compilation phase, as well as simulator configuration parameters, runtime library paths, and waveform file recording configurations used during the simulation phase. Based on the extracted file list and the categorized tool runtime parameters, a structured set of files to be compiled is generated, which clearly identifies the compilation order and dependencies of the files.

[0007] According to the technical solution provided in the embodiments of this application, the compilation project specifically includes the following steps: Based on the compilation order and dependencies identified in the set of files to be compiled, the Vivado tool's built-in compilation engine or integrated third-party compilation tools are called sequentially for compilation. During the compilation process, the aforementioned compilation option parameters and optimization level settings are applied to generate intermediate compilation results; Perform a linking operation on all design files and test platform files to generate a unified simulation verification executable file; The simulator configuration parameters and runtime library path information are embedded into the simulation verification executable file to form a simulation environment that can be directly called. Establish a compilation caching mechanism so that when the source file has not been changed, the existing compilation results can be reused directly to avoid repeated compilation.

[0008] According to the technical solution provided in the embodiments of this application, the running of a single use case simulation specifically includes the following steps: Provides a parameter input interface, supporting the receipt of single-use case names and simulation parameters from external input via command-line parameters or independent configuration files; The simulation parameters include timing parameters of the module interface, function mode selection parameters, error injection control parameters, and simulation duration control parameters. The timing parameters include delay time parameters and setup and hold time parameters, and the error injection control parameters include error bit length parameters and error type parameters. The received single-use case name and simulation parameters are passed as runtime parameters to the simulation verification executable file; The simulation verification executable file is invoked, the corresponding test case is loaded according to the single test case name, and the simulation environment is configured by applying the simulation parameters. Monitor the simulation process, record the simulation status in real time, and automatically output the simulation verification results corresponding to the simulation run after the simulation is completed.

[0009] According to the technical solution provided in the embodiments of this application, the output of simulation verification results specifically includes the following steps: Generate and save a simulation log file, which fully records key events, assertion check results, coverage statistics, and any errors or warnings during the simulation process. According to the preset waveform file recording configuration, a waveform file is generated and saved, which contains the timing variation data of all specified signals; The simulation results are automatically preliminarily analyzed to extract test pass / fail status, functional coverage data, and performance indicators. The input parameters, output results, and related metadata of this simulation are linked and archived to form a traceable simulation verification record; It provides a results aggregation interface, supporting comparative analysis and batch processing of the results of multiple single-use case simulation runs.

[0010] According to the technical solution provided in the embodiments of this application, the compilation caching mechanism is implemented in the following ways: Calculate a hash value for each file to be compiled, which serves as a unique identifier for the file content; Establish a compilation cache database to store the mapping relationship between hash values ​​and corresponding compilation results; Before each compilation, the hash value of the current file is compared with the hash value stored in the cache database to determine whether the source file has been changed; When it is detected that the file has not been changed, the corresponding compilation result is directly retrieved from the cache database, and the compilation process of the file is skipped.

[0011] According to the technical solution provided in the embodiments of this application, the parameter input interface supports at least one of the following input methods: Direct parameter passing from the command line; Dedicated JSON or XML format configuration files; Configure and generate parameter files through a graphical user interface; Test parameters are dynamically obtained from an external test management system.

[0012] According to the technical solution provided in the embodiments of this application, the step of running a single use case simulation further includes simulation resource optimization measures: Dynamically adjust simulation memory allocation based on simulation parameters; Multiple single-use case simulation tasks are executed in parallel to make full use of multi-core processor resources.

[0013] According to the technical solution provided in the embodiments of this application, the method is applicable to at least one of the following scenarios: RTL-level functional verification of FPGA designs; Functional verification of the synthesized netlist; Timing verification after placement and routing; Embedded system hardware and software co-verification.

[0014] Secondly, this application proposes a simulation verification system for implementing the above-described method, comprising: The simulation verification script generation module is used to call the Vivado tool to generate simulation verification scripts; The script parsing module is used to parse the simulation verification script and extract the file list and tool parameters; The project compilation module is used to perform a full project compilation and generate a simulation verification executable file; The single-use case simulation execution module is used to receive the use case name and simulation parameters from external input, run the simulation, and output the results; The modules are connected in sequence to form a complete simulation verification process.

[0015] Compared with the prior art, the beneficial effects of this application are as follows: I. Significantly Reduced Compilation Time and Improved Verification Efficiency: By separating the project compilation step from the single-test case simulation execution step, only one full project compilation is needed to generate the simulation verification executable file, which can then support multiple single-test case simulation runs. This fundamentally solves the problem of repeated compilation caused by "compiling the entire project for each test case" in the background technology. For projects containing dozens to hundreds of test cases, the number of compilations is reduced from N times to 1 time, significantly shortening the overall simulation verification time and improving verification efficiency.

[0016] II. Enhanced Flexibility of Simulation Parameter Input: By receiving the single test case name and simulation parameters from external input and passing them to the simulation verification executable file, dynamic configuration of simulation parameters is achieved. This effectively solves the problem in the background technology that "a test case needs to be added for each simulation verification parameter." Users no longer need to create a large number of test case files for different parameter combinations. They can simply adjust frequently changing parameters such as module interface delay time and the number of injected error bits through the parameter interface, greatly simplifying the test environment configuration.

[0017] III. Optimized Simulation Verification Environment Management: By separating the compilation and simulation processes, repeated compilations due to parameter adjustments are reduced, significantly decreasing the size of the simulation verification environment. Simultaneously, the mechanism based on external parameter input avoids the need to create independent test case files for each parameter combination, reducing the management complexity and storage resource consumption of the simulation verification environment.

[0018] IV. Maintaining good compatibility with existing tools: This invention is optimized based on the existing script generation function and simulation verification process of the Vivado tool, and is fully compatible with the simulation tools that come with Vivado as well as third-party simulation tools such as Modelsim. It does not require changes to the user's existing design habits and tool environment, and is easy to promote and apply in the existing development process.

[0019] V. Support for efficient iterative development: During the FPGA design iteration process, when only test parameters need to be modified or different test cases need to be run, there is no need to recompile the entire project. Verification can be completed quickly directly through the parameter input interface, which greatly accelerates the debugging and verification cycle and helps to shorten the product launch time. Attached Figure Description

[0020] Figure 1 A flowchart illustrating the steps of the simulation verification method based on the Vivado tool provided in this application embodiment; Figure 2 This is a schematic diagram of the structure of a simulation verification system based on the Vivado tool provided in an embodiment of this application. Detailed Implementation

[0021] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0022] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0023] Example 1 As mentioned in the background section, to address the problems in the existing technology, this application proposes a simulation verification method based on the Vivado tool, such as... Figure 1 As shown, it includes the following steps: Generate simulation verification script: Call the output function of the Vivado tool to generate the script file for the entire simulation verification project; Parse the simulation verification script: Parse the script file, extract the project file list and tool running parameters, and generate a set of files to be compiled; Compile the project: Based on the set of files to be compiled, perform a full project compilation to generate an executable file for simulation verification; Run single-use case simulation: Receive the single-use case name and simulation parameters from external input, pass the single-use case name and simulation parameters to the simulation verification executable file, run the simulation and output the simulation verification results of the corresponding single-use case and simulation parameters; The compilation process is separated from the single-case simulation process, allowing multiple single-case simulation runs to be supported by a single compilation, thus avoiding repeated compilation and improving simulation verification efficiency.

[0024] Specifically, Vivado refers to the integrated design environment (IDE) developed by Xilinx, specifically designed for the design, synthesis, placement and routing, simulation, and debugging of FPGAs (Field-Programmable Gate Arrays) and SoCs (System-on-a-Chip). It supports hardware description languages ​​(such as Verilog and VHDL) and High-Level Synthesis (HLS), and has built-in simulation, analysis, and verification capabilities. Simulation verification scripts are script files (usually in TCL or Python format) automatically generated by Vivado, containing a list of project files, compilation options, simulation parameters, and execution commands. These scripts guide simulation tools (such as Vivado's built-in simulator or third-party tools like ModelSim) through the compilation and simulation process. Parsing simulation verification scripts involves performing syntax and structural analysis on the script files, extracting key information (such as file paths and parameter settings), and converting it into structured data for subsequent processing. The parsing process may involve regular expression matching, keyword identification, and dependency analysis. Compilation engineering: This refers to converting design files (such as RTL code, IP cores) and test platform files (such as test cases, stimulus generation modules) into executable files or intermediate code using compilation tools. The compilation process includes syntax checking, optimization, and linking, generating simulation executable files (such as simulation models or binary files). Running single-test-case simulation: This refers to executing simulations for a single test case (i.e., a specific functional scenario or boundary condition), configuring the simulation environment through input parameters (such as timing delays, error injection), running the simulation executable file, and outputting results (such as logs, waveform files). Simulation verification efficiency: This refers to the ability to reduce time overhead and resource consumption during simulation, including compilation time, runtime time, and parameter configuration flexibility. This method improves overall efficiency by separating the compilation and runtime steps, avoiding repeated compilation.

[0025] Step Implementation Description: Generating the Simulation Verification Script: In the Vivado tool, users can invoke the "Export Simulation Script" function through the graphical interface or command line. Vivado will automatically generate a script file (e.g., simulate.tcl) based on the current project settings (such as design files, IP core configuration, simulation settings). This script contains complete simulation flow commands, such as file compilation order, simulator options (such as time precision, optimization level), and waveform recording settings. Users can select the "Export Simulation Script" option through Vivado's "Tools" menu, specifying the output path and format (e.g., for ModelSim or Vivado simulators). After the script is generated, the system will save the file for subsequent parsing. Parsing the Simulation Verification Script: The generated script file is read using a custom parsing module (such as Python or TCL scripts). The parsing process first identifies key parts of the script, such as: File List: RTL files (e.g., .v, .sv), test platform files (e.g., testbench.sv), and constraint files (e.g., .xdc) are extracted by searching for add_file or source commands. Tool runtime parameters: Extract compilation options (e.g., -O2 for optimization level), simulation parameters (e.g., +define +DEBUG for macro definition), and library paths (e.g., $env(XILINX_VIVADO) / lib). After parsing, a structured set of files to be compiled (e.g., JSON or XML format) is generated, clearly defining the dependencies between files (e.g., top-level modules must compile their sub-modules first). This can be achieved by constructing a dependency graph to ensure the correct compilation order. Project compilation: Based on the parsed set of files to be compiled, Vivado's compilation engine (e.g., xsim or integrated third-party tools) is invoked to perform a full project compilation. The compilation process includes: sequentially compiling each file: based on dependencies, the underlying modules are compiled first, followed by the top-level test platform. Applying optimization parameters: for example, using -O2 to optimize code and reduce simulation time. Linking all modules: generating a unified simulation executable file (e.g., simv or .exe), which contains the executable model of the entire project. After compilation, the executable file is saved to a specified directory; subsequent simulation runs directly call this file without recompiling. Enter the single-case name (e.g., test_case1) and simulation parameters (e.g., delay time = 10ns) via the command-line interface or configuration file. These parameters are then passed to the simulation executable.

[0026] In a preferred embodiment, the parsing of the simulation verification script specifically includes the following steps: Identify and extract a list of design files from the script file, the list of design files including RTL code files, IP core description files and constraint files; Identify and extract the test platform file list from the script file, the test platform file list including test case files, stimulus generation files and reference model files; The tool's runtime parameters are analyzed and categorized, including compilation options and optimization level settings used during the compilation phase, as well as simulator configuration parameters, runtime library paths, and waveform file recording configurations used during the simulation phase. Based on the extracted file list and the categorized tool runtime parameters, a structured set of files to be compiled is generated, which clearly identifies the compilation order and dependencies of the files.

[0027] Specifically, the parser identifies and extracts a list of design files: It scans simulation scripts (such as TCL scripts) for commands that add design files, such as `add_files` or `read_verilog`. For example, in a script generated by Vivado, the command `add_files {source / design.v}` adds an RTL file. The parser uses regular expressions (such as ` / add_files\s+\{([^}]+)\} / `) to extract file paths and identify file types: RTL code files (extensions like .v, .sv, etc.), IP core description files (.xci), and constraint files (.xdc). These files are stored in a list and labeled "design files". Similarly, the parser identifies and extracts a list of testbench files: it searches for testbench-related commands, such as `add_files` for test files or specific testbench declarations. Test case files (e.g., tb_top.sv) typically contain the main test module; stimulus generation files (e.g., stimulus.sv) are responsible for generating clock, reset, and input signals; reference model files (e.g., ref_model.v) implement the golden reference logic for output comparison. The parser categorizes these files by keywords (e.g., testbench or stimulus) or file naming conventions (e.g., *_tb.*) and stores them in the "Test Platform Files" list. The parser also categorizes tool runtime parameters: it analyzes compilation and simulation commands in the script and extracts parameters such as: compilation options (e.g., -O2 indicates optimization level 2, -g enables debug information), simulator configuration parameters (e.g., -timescale 1ns / 1ps sets the time unit, +define +DEBUG defines compile-time macros), and runtime library paths (e.g., -L xil_defaultlib specifies the library name, or $env(XILINX_VIVADO) / data / verilog / src sets the library path). Waveform file recording configuration: For example, `-wdb` specifies the waveform file format (such as VCD or FSDB), and `-waveform` sets the recording signal range. These parameters are categorized as "compilation parameters" or "simulation parameters" and stored as key-value pairs for later use. Generating a structured set of files to be compiled: Based on the extracted file list and parameters, the parser constructs a structured set (such as a JSON object). This set includes: File entries: Each file contains the path, type, dependent modules (identified by parsing module instantiation statements), and compilation order (e.g., lower-level modules take precedence). Parameter groups: Compilation parameters and simulation parameters are stored separately and associated with their corresponding files.

[0028] In a preferred embodiment, the compilation process specifically includes the following steps: Based on the compilation order and dependencies identified in the set of files to be compiled, the Vivado tool's built-in compilation engine or integrated third-party compilation tools are called sequentially for compilation. During the compilation process, the aforementioned compilation option parameters and optimization level settings are applied to generate intermediate compilation results; Perform a linking operation on all design files and test platform files to generate a unified simulation verification executable file; The simulator configuration parameters and runtime library path information are embedded into the simulation verification executable file to form a simulation environment that can be directly called. Establish a compilation caching mechanism so that when the source file has not been changed, the existing compilation results can be reused directly to avoid repeated compilation.

[0029] The compilation phase first determines the compilation order based on the parsed file dependencies. The system then calls the compilation tools sequentially, from the underlying modules to the top-level testing platform. This process can choose to use Vivado's built-in compilation engine or integrated third-party compilation tools to ensure that each type of source file receives correct compilation processing. When compiling each file, the system applies the compilation options and optimization level settings obtained from the parsing phase. These parameters directly affect the quality and performance of the generated intermediate code, achieving an optimal balance between compilation speed and code optimization.

[0030] After compiling all files individually, the system enters the linking phase. The linker integrates the intermediate results generated by each independent compilation into a unified simulation verification executable file. This process resolves symbolic references and linking issues between modules, forming a complete simulation model. Simultaneously, key simulation configuration parameters, such as time precision settings and library file paths, are embedded into the generated executable file, making the final simulation executable a self-contained simulation environment and reducing runtime dependencies on external configurations.

[0031] To further improve efficiency, this method also establishes an intelligent compilation caching mechanism. The system calculates a unique identifier for each source file and generates feature values ​​based on the file content as the basis for change detection. These feature values ​​and their corresponding compilation results are stored in a dedicated cache database. Before each compilation, the system compares the current file's feature values ​​with the cached records to determine if the file has changed. For unchanged files, the previous compilation results are directly reused, skipping the repeated compilation process. This mechanism is particularly suitable for iterative development scenarios; when only some files are modified, it can significantly reduce the compilation scope and improve overall efficiency.

[0032] The technical benefits of this compilation scheme are reflected on multiple levels. Dependency-based sequential compilation ensures the correctness of the compilation process and avoids linking errors caused by improper compilation order. Parametric compilation allows users to adjust optimization strategies according to different needs, balancing compilation speed and simulation performance. Unified linking operations simplify simulation environment configuration and improve ease of use. Most notably, the compilation caching mechanism brings significant efficiency improvements. In the later stages of engineering development, when most core modules tend to stabilize, this mechanism can avoid a large number of unnecessary recompilations, reducing compilation time to a fraction of that of traditional methods. From a technical principle perspective, this compilation scheme integrates advanced concepts such as incremental compilation, dependency management, and cache optimization. Through intelligent resource reuse and process optimization, it provides strong technical support for rapid iterative verification of large-scale FPGA designs.

[0033] In a preferred embodiment, the process of running a single-use case simulation specifically includes the following steps: Provides a parameter input interface, supporting the receipt of single-use case names and simulation parameters from external input via command-line parameters or independent configuration files; The simulation parameters include timing parameters of the module interface, function mode selection parameters, error injection control parameters, and simulation duration control parameters. The timing parameters include delay time parameters and setup and hold time parameters, and the error injection control parameters include error bit length parameters and error type parameters. The received single-use case name and simulation parameters are passed as runtime parameters to the simulation verification executable file; The simulation verification executable file is invoked, the corresponding test case is loaded according to the single test case name, and the simulation environment is configured by applying the simulation parameters. Monitor the simulation process, record the simulation status in real time, and automatically output the simulation verification results corresponding to the simulation run after the simulation is completed.

[0034] Specifically, a flexible and efficient parameterized testing framework was constructed. The core of this framework is a diverse parameter input interface, supporting multiple methods for receiving user-inputted test parameters, including direct command-line transmission, independent configuration files, and graphical interfaces. These parameters cover key aspects of simulation verification: timing parameters control the delay characteristics and setup / hold time requirements of interface signals; functional mode parameters select different operating modes; fault injection parameters define the types and scope of faults introduced during testing; and simulation duration parameters control the test runtime. This design allows users to quickly configure various test scenarios without modifying the source code.

[0035] The parameter passing mechanism is a key element in enabling flexible testing. The system converts received test parameters into a format recognizable by the simulator and provides them to the pre-compiled simulation executable file via a runtime parameter passing mechanism. Within the simulation executable file, the testing platform reads these runtime parameters through a specific parameter interface and dynamically adjusts the testing environment accordingly. For example, it loads the corresponding test sequence based on the input test case name, configures interface behavior according to specified timing parameters, or activates the corresponding error generation module based on error injection parameters. This design separates test logic from test data, greatly enhancing testing flexibility.

[0036] The status monitoring and result output during simulation constitute another important component of the framework. The system tracks the operational status in real time during simulation execution, recording key events and anomalies. Upon completion of the simulation, it automatically generates result files corresponding to that run, including a log file detailing the simulation process and waveform files saving signal timing changes. All these outputs are correlated with the input test parameters, ensuring the traceability of each test run.

[0037] This parametric simulation approach offers significant technical advantages. First, it greatly improves test case reusability; the same test platform can cover multiple test scenarios with different parameter configurations, reducing the amount of test code that needs maintenance. Second, the runtime parameter passing mechanism avoids the need to recompile the project for each parameter combination, resulting in an order-of-magnitude improvement in test iteration speed. Furthermore, the standardized parameter interface facilitates automated test execution and is suitable for integration into continuous integration processes. From a technical perspective, this method embodies the advanced concept of data-driven testing, separating test logic from test data, maximizing test coverage through parametric configuration, while maintaining the efficiency and maintainability of the testing process, providing an ideal solution for the comprehensive verification of complex FPGA designs.

[0038] In a preferred embodiment, the output simulation verification result specifically includes the following steps: Generate and save a simulation log file, which fully records key events, assertion check results, coverage statistics, and any errors or warnings during the simulation process. According to the preset waveform file recording configuration, a waveform file is generated and saved, which contains the timing variation data of all specified signals; The simulation results are automatically preliminarily analyzed to extract test pass / fail status, functional coverage data, and performance indicators. The input parameters, output results, and related metadata of this simulation are linked and archived to form a traceable simulation verification record; It provides a results aggregation interface, supporting comparative analysis and batch processing of the results of multiple single-use case simulation runs.

[0039] Specifically, a complete verification result management system was constructed. This system begins with the generation and saving of multiple types of result files. The simulation log file records the complete process information of the test run, including the occurrence time of key events, the status of assertion checks, coverage statistics analysis, and various warnings and error messages. Simultaneously, based on the preset waveform recording configuration, the system generates waveform files containing signal timing change data. These files provide intuitive visualization for subsequent debugging and analysis. These two types of result files record the entire simulation execution from different dimensions, forming complementary verification evidence.

[0040] Based on the generated basic results files, the system performs automated preliminary analysis. A dedicated analysis module parses simulation logs and coverage data, extracting key verification metrics, including test pass / fail status, functional coverage achievement, and simulation performance parameters. This automated analysis quickly locates problems, assesses verification progress, and provides engineers with immediate quality feedback. More importantly, the system establishes a rigorous results traceability mechanism, linking and archiving the input parameters, output results, and related metadata of each simulation run. This metadata includes simulation environment information, tool versions, and run timestamps, collectively forming a complete verification record.

[0041] To support the management of large-scale validation activities, this method also provides a powerful results aggregation interface. This interface supports centralized management and comparative analysis of results from multiple simulation runs, allowing users to easily compare test results under different parameter configurations, identify coverage trends, or perform batch processing of results. This integrated results management approach greatly simplifies the workload of regression testing and validation progress tracking.

[0042] The technical value of this results processing solution is reflected in several aspects. Complete results recording ensures the traceability of the verification process, facilitating debugging and reproduction of problems. Automated analysis reduces the workload of manual results processing and improves verification efficiency. Results association and archiving provide complete evidence for quality audits, supporting compliance requirements in the development process. The results aggregation interface enables the team to grasp the verification status from a macro perspective and make data-driven decisions. From a technical principle perspective, this solution applies advanced technologies such as data management, automated analysis, and visualization. Through a systematic results processing workflow, it transforms raw simulation output into valuable verification intelligence, providing a reliable quality assurance system for the development of high-quality FPGA products.

[0043] In a preferred embodiment, the compilation caching mechanism is implemented in the following way: Calculate a hash value for each file to be compiled, which serves as a unique identifier for the file content; Establish a compilation cache database to store the mapping relationship between hash values ​​and corresponding compilation results; Before each compilation, the hash value of the current file is compared with the hash value stored in the cache database to determine whether the source file has been changed; When it is detected that the file has not been changed, the corresponding compilation result is directly retrieved from the cache database, and the compilation process of the file is skipped.

[0044] Specifically, the core of this caching mechanism lies in uniquely identifying the content of each file by calculating its hash value. The hash value calculation uses a standard algorithm to operate on the entire file content, generating a fixed-length digital fingerprint. Any minor change in content will result in a significant change in the hash value, thus ensuring the accuracy of the identification. The system establishes a dedicated compilation cache database to store the mapping relationship between hash values ​​and corresponding compilation results. This database persistently stores the output of each successful compilation and its corresponding source file characteristic values.

[0045] Before each compilation begins, the system executes an intelligent change detection process. First, it calculates the hash value of all files to be compiled, then compares the result with the historical records stored in the cache database. If the current hash value of a file matches the hash value recorded in the database, it is determined that the source file has not changed since the last compilation, and the cache reuse mechanism is triggered. The system directly retrieves the complete compilation result for that file from the cache database, including intermediate compilation files and related dependency information, completely skipping the actual compilation process for that file. Only when the file hash value changes or the corresponding record is not found in the cache will the system initiate the actual compilation process, and update the relevant record in the cache database upon successful compilation.

[0046] This caching mechanism is remarkably effective. In large FPGA projects, only a few files often change during design iterations, yet traditional methods require recompiling the entire project. This mechanism, through precise content identification and result reuse, strictly limits the compilation scope to the changed files, making subsequent compilation time proportional to the scope of changes, rather than the project size. Especially in scenarios like regression testing that require multiple simulation runs, the caching mechanism avoids a large amount of repetitive compilation work, and the overall compilation efficiency improvement becomes increasingly significant with the number of test cases. From a technical perspective, this mechanism is based on incremental compilation and persistent caching theories in software engineering. By establishing a precise mapping between source content and compilation results, it achieves intelligent reuse of compilation output. This design not only significantly reduces the waste of computing resources but also ensures the reliability of compilation results, as the same source file always corresponds to the same compilation result, eliminating the inconsistency risks that may be introduced by repeated compilation.

[0047] In a preferred embodiment, the parameter input interface supports at least one of the following input methods: Direct parameter passing from the command line; Dedicated JSON or XML format configuration files; Configure and generate parameter files through a graphical user interface; Test parameters are dynamically obtained from an external test management system.

[0048] Specifically, diverse parameter passing mechanisms are provided to adapt to different use cases and user preferences. The most basic input method is direct parameter passing via command line. Users can directly append test parameters when executing simulation commands. This method is simple and straightforward, suitable for rapid testing and integration with automated scripts. Parameters are identified by specific prefixes, allowing the simulator to recognize and parse these command-line parameters, converting them into internal configuration information. For complex parameter configuration needs, the system supports dedicated configuration file formats, including structured JSON and standardized XML formats. These configuration files employ a hierarchical data organization method, clearly expressing the correlation and grouping relationships between parameters, making them particularly suitable for complex test scenarios with a large number of parameters and nested relationships.

[0049] To further lower the barrier to entry, the system also offers a graphical user interface (GUI) configuration method. Users can set various simulation parameters through intuitive interface elements such as text boxes, drop-down menus, and checkboxes, and the system will automatically generate the corresponding parameter configuration files. This method greatly simplifies the parameter configuration process, reduces the possibility of manual input errors, and is particularly suitable for users unfamiliar with command-line operations. In state-of-the-art integrated application scenarios, the system also supports dynamically obtaining test parameters from external test management systems. This mechanism achieves deep integration between the simulation environment and the test management platform, allowing for centralized management and version control of test parameters, which are automatically distributed upon simulation startup, providing a solid foundation for large-scale automated testing and continuous integration processes.

[0050] The technological advantage of this diverse input interface lies in its superior adaptability and flexibility. Different users can choose the most suitable parameter input method according to their specific needs: developers may prefer direct command-line modification during debugging, test engineers tend to use structured configuration files when verifying the system, and a system-integrated dynamic acquisition method is used in automated testing environments. These multiple methods are not mutually exclusive and can be used in combination; for example, a configuration file base can be generated through a graphical interface, and then local adjustments can be made using command-line parameters. From a technical perspective, this design embodies the idea of ​​interface diversity and unified processing. While providing multiple interaction methods externally, it employs a unified parameter parsing and management mechanism internally, ensuring that parameters input through any method are consistently processed and correctly applied. This architecture satisfies the personalized needs of different users while maintaining the system's internal simplicity and maintainability.

[0051] In a preferred embodiment, the step of running a single-use case simulation further includes simulation resource optimization measures: Dynamically adjust simulation memory allocation based on simulation parameters; Multiple single-use case simulation tasks are executed in parallel to make full use of multi-core processor resources.

[0052] Specifically, this implementation introduces advanced simulation resource optimization measures based on single-use case simulation, aiming to maximize the utilization of available hardware resources and improve simulation throughput. The first optimization measure is to dynamically adjust simulation memory allocation based on simulation parameters. Before starting the simulation, the system analyzes the parameter characteristics of the current test case, including simulation duration, number of signals, waveform recording range, etc., and estimates memory requirements based on this information and dynamically allocates the corresponding memory space. For test cases with dense signals and long simulation times, the system allocates a larger memory pool to reduce runtime memory allocation overhead; while for simple and fast tests, a streamlined memory configuration is used to avoid resource waste. This intelligent memory management not only improves memory usage efficiency but also reduces performance degradation caused by insufficient memory or frequent allocation during simulation.

[0053] The second key optimization is the parallel execution of multiple single-use case simulation tasks. The system can detect the host machine's multi-core processor resources and intelligently allocate independent test cases to different processor cores for simultaneous execution. Each simulation task executes in an independent process space, without interference, but shares the same pre-compiled simulation executable file. The system establishes a task scheduling mechanism, monitors the status of each simulation process, and coordinates their access to shared resources such as disk I / O, ensuring stability and efficiency during parallel execution. For test cases with dependencies, the system can identify these dependencies and arrange the execution order appropriately, while for completely independent test cases, it fully leverages the advantages of parallel processing.

[0054] The technical effects of these resource optimization measures are remarkable. Dynamic memory allocation ensures that simulation tasks receive just the right amount of resource support, avoiding performance bottlenecks caused by resource shortages while preventing waste caused by over-allocation of resources. Parallel execution directly correlates simulation throughput with the number of processor cores, and in modern computing environments where multi-core processors are prevalent, it can improve simulation efficiency by several times. Especially in regression verification scenarios that require executing a large number of test cases, traditional serial execution methods may take hours or even days, while parallel processing can reduce this time to a fraction of the original time. From a technical principle perspective, these optimizations are based on computing resource management and task scheduling theories, fully tapping the hardware potential through intelligent resource allocation and task parallelization. This optimization not only considers the full utilization of computing resources but also takes into account the balanced use of system resources such as memory and disk I / O, ensuring that system stability is maintained while improving efficiency.

[0055] In a preferred embodiment, the method is applicable to at least one of the following scenarios: RTL-level functional verification of FPGA designs; Functional verification of the synthesized netlist; Timing verification after placement and routing; Embedded system hardware and software co-verification.

[0056] Specifically, the broad applicability of this simulation verification method is clarified, covering several key stages of FPGA design verification. In RTL-level functional verification scenarios, this method is used to verify the logical correctness of the hardware description code. Designers verify whether the RTL code strictly adheres to design specifications by writing test cases and assertions, capturing logical errors and boundary condition issues in the code. This stage of verification is the most fundamental and crucial, enabling early detection of design defects and preventing problems from flowing into subsequent stages. In the functional verification stage of the post-synthesis netlist, this method is used to confirm whether the netlist circuit generated by the synthesis tool maintains consistent functional behavior with the RTL code. Although the circuit structure has been transformed from a behavioral description to a gate-level implementation, functional characteristics must remain consistent. Verification at this stage ensures that the synthesis process does not introduce functional deviations.

[0057] In the timing verification phase, this method is applied to design verification after placement and routing. This phase not only focuses on functional correctness but also emphasizes verifying whether the circuit meets timing requirements. By loading the netlist generated after placement and routing, which contains actual delay information, and combining it with specific timing parameter settings, the method verifies whether the circuit can operate correctly under various operating conditions. This phase can identify timing violations such as setup and hold times, ensuring that the design can run stably in actual hardware. In embedded system hardware-software co-verification scenarios, this method supports simultaneous verification of the hardware design and the software program running on it. By simulating the processor core and executing software code, combined with hardware simulation, the correctness of the hardware-software interface and the overall system functionality are verified. This end-to-end verification is crucial for the development of complex embedded systems.

[0058] The value of this widely applicable technology lies in providing a consistent verification methodology to support the entire FPGA development process. Design teams no longer need to learn and use different tools and methods for each verification stage; the unified verification process reduces learning costs and improves efficiency. From a technical principle perspective, this method is based on the idea of ​​separation of abstraction levels and concerns. Although the specific content and objectives of different verification stages vary, the core verification methodology remains consistent. RTL verification focuses on behavioral correctness, post-synthesis verification ensures conversion fidelity, timing verification focuses on timing compliance, and hardware-software co-verification emphasizes overall functionality. This method, through flexible parameter configuration and a unified process framework, adapts to these different verification needs. This consistency not only improves verification efficiency but also enhances the comparability and traceability of results at each verification stage, providing end-to-end quality assurance for complex FPGA projects.

[0059] In summary, in this application, if Figure 2As shown, it includes a Vivado simulation verification script generation module, a script parsing module, a project compilation module, and a single-case simulation verification execution module. The Vivado simulation verification script generation module calls the Vivado tool's output simulation verification script function to generate the simulation verification script for the entire project. The script parsing module parses the compilation and simulation scripts for the entire project, including file lists, tool running parameters, etc., and generates the compilation files for the overall simulation verification project. The project compilation module receives the file to be compiled, completes the compilation of the file, and generates a simulation verification executable file. The single-use case simulation execution module parses the input single-use case name and simulation parameters, passes them to the simulation verification executable file, completes the execution of the simulation verification executable file, and outputs the simulation verification results (including but not limited to log files and waveform files) for the corresponding single-use case name and simulation parameters. This achieves the following effects: This invention is based on the Vivado tool, which has a wide range of applications and high reliability. This invention reduces the number of compilations for the overall simulation verification project, shortening the simulation verification cycle. It adds input interfaces for single-use case names and simulation parameters, improving the flexibility of simulation verification execution. It can efficiently and flexibly complete the simulation verification process.

[0060] Example 2 This embodiment proposes a simulation verification system for implementing the method described in Embodiment 1, including: The simulation verification script generation module is used to call the Vivado tool to generate simulation verification scripts; The script parsing module is used to parse the simulation verification script and extract the file list and tool parameters; The project compilation module is used to perform a full project compilation and generate a simulation verification executable file; The single-use case simulation execution module is used to receive the use case name and simulation parameters from external input, run the simulation, and output the results; The modules are connected in sequence to form a complete simulation verification process.

[0061] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. The above descriptions are only preferred embodiments of this application. It should be noted that due to the limitations of written expression, while there are objectively infinite specific structures, those skilled in the art can make several improvements, modifications, or changes without departing from the principles of this invention, and can also combine the above technical features in an appropriate manner. These improvements, modifications, changes, or combinations, or the direct application of the inventive concept and technical solution to other situations without modification, should all be considered within the scope of protection of this application.

Claims

1. A simulation verification method based on the Vivado tool, characterized in that, Includes the following steps: Generate simulation verification script: Call the output function of the Vivado tool to generate the script file for the entire simulation verification project; Parse the simulation verification script: Parse the script file, extract the project file list and tool running parameters, and generate a set of files to be compiled; Compile the project: Based on the set of files to be compiled, perform a full project compilation to generate an executable file for simulation verification; Run single-use case simulation: Receive the single-use case name and simulation parameters from external input, pass the single-use case name and simulation parameters to the simulation verification executable file, run the simulation and output the simulation verification results of the corresponding single-use case and simulation parameters; The compilation process is separated from the single-case simulation process, allowing multiple single-case simulation runs to be supported by a single compilation, thus avoiding repeated compilation and improving simulation verification efficiency.

2. The simulation verification method based on the Vivado tool according to claim 1, characterized in that: The analysis simulation verification script specifically includes the following steps: Identify and extract a list of design files from the script file, the list of design files including RTL code files, IP core description files and constraint files; Identify and extract the test platform file list from the script file, the test platform file list including test case files, stimulus generation files and reference model files; The tool's runtime parameters are analyzed and categorized, including compilation options and optimization level settings used during the compilation phase, as well as simulator configuration parameters, runtime library paths, and waveform file recording configurations used during the simulation phase. Based on the extracted file list and the categorized tool runtime parameters, a structured set of files to be compiled is generated, which clearly identifies the compilation order and dependencies of the files.

3. The simulation verification method based on the Vivado tool according to claim 2, characterized in that: The compilation project specifically includes the following steps: Based on the compilation order and dependencies identified in the set of files to be compiled, the Vivado tool's built-in compilation engine or integrated third-party compilation tools are called sequentially for compilation. During the compilation process, the aforementioned compilation option parameters and optimization level settings are applied to generate intermediate compilation results; Perform a linking operation on all design files and test platform files to generate a unified simulation verification executable file; The simulator configuration parameters and runtime library path information are embedded into the simulation verification executable file to form a simulation environment that can be directly called. Establish a compilation caching mechanism so that when the source file has not been changed, the existing compilation results can be reused directly to avoid repeated compilation.

4. The simulation verification method based on the Vivado tool according to claim 1, characterized in that: The process of running a single-use case simulation specifically includes the following steps: Provides a parameter input interface, supporting the receipt of single-use case names and simulation parameters from external input via command-line parameters or independent configuration files; The simulation parameters include timing parameters of the module interface, function mode selection parameters, error injection control parameters, and simulation duration control parameters. The timing parameters include delay time parameters and setup and hold time parameters, and the error injection control parameters include error bit length parameters and error type parameters. The received single-use case name and simulation parameters are passed as runtime parameters to the simulation verification executable file; The simulation verification executable file is invoked, the corresponding test case is loaded according to the single test case name, and the simulation environment is configured by applying the simulation parameters. Monitor the simulation process, record the simulation status in real time, and automatically output the simulation verification results corresponding to the simulation run after the simulation is completed.

5. The simulation verification method based on the Vivado tool according to claim 1, characterized in that: The output simulation verification results specifically include the following steps: Generate and save a simulation log file, which fully records key events, assertion check results, coverage statistics, and any errors or warnings during the simulation process. According to the preset waveform file recording configuration, a waveform file is generated and saved, which contains the timing variation data of all specified signals; The simulation results are automatically preliminarily analyzed to extract test pass / fail status, functional coverage data, and performance indicators. The input parameters, output results, and related metadata of this simulation are linked and archived to form a traceable simulation verification record; It provides a results aggregation interface, supporting comparative analysis and batch processing of the results of multiple single-use case simulation runs.

6. The simulation verification method based on the Vivado tool according to claim 3, characterized in that: The compilation caching mechanism is implemented in the following way: Calculate a hash value for each file to be compiled, which serves as a unique identifier for the file content; Establish a compilation cache database to store the mapping relationship between hash values ​​and corresponding compilation results; Before each compilation, the hash value of the current file is compared with the hash value stored in the cache database to determine whether the source file has been changed; When it is detected that the file has not been changed, the corresponding compilation result is directly retrieved from the cache database, and the compilation process of the file is skipped.

7. The simulation verification method based on the Vivado tool according to claim 4, characterized in that: The parameter input interface supports at least one of the following input methods: Direct parameter passing from the command line; Dedicated JSON or XML format configuration files; Configure and generate parameter files through a graphical user interface; Test parameters are dynamically obtained from an external test management system.

8. The simulation verification method based on the Vivado tool according to claim 1, characterized in that: The single-use case simulation step also includes simulation resource optimization measures: Dynamically adjust simulation memory allocation based on simulation parameters; Multiple single-use case simulation tasks are executed in parallel to make full use of multi-core processor resources.

9. The simulation verification method based on the Vivado tool according to claim 1, characterized in that: The method is applicable to at least one of the following scenarios: RTL-level functional verification of FPGA designs; Functional verification of the synthesized netlist; Timing verification after placement and routing; Embedded system hardware and software co-verification.

10. A simulation verification system for implementing the method of any one of claims 1-9, characterized in that, include: The simulation verification script generation module is used to call the Vivado tool to generate simulation verification scripts; The script parsing module is used to parse the simulation verification script and extract the file list and tool parameters; The project compilation module is used to perform a full project compilation and generate a simulation verification executable file; The single-use case simulation execution module is used to receive the use case name and simulation parameters from external input, run the simulation, and output the results; The modules are connected in sequence to form a complete simulation verification process.

Images