An HDLC automatic verification environment generation method and device and a storage medium

Abstract

This invention provides a method, apparatus, and storage medium for generating an HDLC automatic verification environment. The apparatus includes: a configuration information module for setting basic HDLC configuration parameters and calling generation functions of UVM components; an HDLC parsing module for reading the top-level DUT file specified in the configuration information module, extracting the interface signals and parameters of the DUT, and generating interface files, macro definition parameter files, and DUT instantiation files; a verification environment building module, which includes multiple sub-modules for generating different UVM components and constructing a UVM verification environment architecture containing the required UVM components; a simulation running module for compiling and simulating test cases based on the constructed UVM verification environment architecture; and a script running module including multiple script files that execute multiple running instructions.

Description

Technical Field

[0001] This invention belongs to the technical field of integrated circuit verification methods, and particularly relates to a method, apparatus and storage medium for generating an HDLC automatic verification environment. Background Technology

[0002] In the field of integrated circuit design, with the continuous evolution of process technology and the increasing complexity of application requirements, the integration density and functional complexity of chips are growing exponentially. Against this backdrop, functional verification has become a crucial part of the integrated circuit design process. Its core objective is to comprehensively identify and fix design defects before tape-out manufacturing, ensuring the correctness of chip functions, the stability of performance, and the reliability of the product.

[0003] The quality of verification work directly determines the first-time tape-out success rate and time-to-market of chips. Therefore, building an efficient and complete verification environment has become a key task in chip R&D.

[0004] High-Level Data Link Control (HDLC) is a bit-oriented data link layer communication protocol widely used in communications, industrial control, aerospace telemetry and control, and other fields due to its efficient frame structure, reliable error control, and transparent transmission characteristics. In chip designs that include HDLC protocol processing modules, thorough and accurate verification of these modules is fundamental to ensuring the correctness of the entire system's communication functions.

[0005] Currently, the setup of a verification environment for the HDLC protocol module mainly relies on the following two methods: (1) Manually write test platform code Verification engineers manually write verification components such as stimulus generators, drivers, monitors, reference models, and scoreboards, based on the HDLC protocol specification and the interface signals of the design under test (DUT), and organize them into a complete test platform. This approach has significant drawbacks: firstly, as HDLC protocol application scenarios become more complex (e.g., supporting multiple frame formats, variable window sizes, multi-link aggregation, etc.), the workload of manually writing code increases dramatically, significantly lengthening the verification cycle; secondly, manual operation is highly susceptible to introducing signal connection errors and parameter mismatches, requiring repeated debugging of the verification environment itself, severely impacting verification efficiency.

[0006] (2) Semi-automated tools based on general verification methodology Some existing technologies employ standardized methodologies such as UVM (Universal Verification Methodology) and generate some verification components through scripts or templates. However, these tools are mostly customized for specific design scenarios, lacking flexibility. When the parameters of the HDLC module (such as data bit width, address field length, clock frequency) or the interface protocol version change, it often requires extensive modifications to the generation script or even rebuilding the environment. Furthermore, existing tools have insufficient coverage of HDLC protocol features. For example, they struggle to automatically generate corresponding verification components for complex scenarios such as abnormal combinations of S-frames (monitoring frames) and U-frames (unnumbered frames), timer timeout retransmissions, and window flow control, making it difficult to guarantee verification completeness.

[0007] In summary, existing HDLC verification environment setup methods and tools generally suffer from low setup efficiency, poor reusability, and incomplete protocol feature coverage, making it difficult to meet the current IC design verification needs of rapid iteration and diverse scenarios. Therefore, there is an urgent need for an automated HDLC verification environment generation method and device that can automatically and quickly build HDLC verification environments, possesses high flexibility and scalability, and comprehensively covers HDLC protocol features. Summary of the Invention

[0008] This invention provides a method and apparatus for generating an automatic HDLC verification environment, which has high flexibility and scalability.

[0009] Other objects and advantages of the present invention can be further understood from the technical features disclosed herein.

[0010] To achieve one, some, or all of the above objectives or other objectives, the present invention provides an HDLC automatic verification environment generation device, comprising: a configuration information module, which sets HDLC basic configuration parameters and calls the generation function of UVM components; the generation function of UVM components is used to add or remove corresponding UVM components; an HDLC parsing module, which reads the top-level file of the DUT specified in the configuration information module, extracts the interface signals and parameters of the DUT, and automatically generates interface files, macro definition parameter files, and DUT instantiation files based on the extraction results; a verification environment building module, which includes multiple sub-modules for generating different UVM components, and calls script files in the script execution module to build a UVM verification environment architecture containing the required UVM components based on the addition or removal of UVM components set in the configuration information module; a simulation execution module, which compiles and simulates test cases based on the completed UVM verification environment architecture, calls the performance monitoring script in the script execution module, and collects test data of test cases in real time; the script execution module includes multiple script files, which respectively execute: the parsing instructions of the HDLC parsing module, the building instructions of the verification environment building module, and the execution instructions of the simulation execution module.

[0011] The configuration information module includes an hdlc_config configuration module and a UVM component configuration module. The hdlc_config configuration module defines the basic configuration parameters of HDLC and stores the core parameters input by the user. The basic configuration parameters of HDLC include the test platform generation path, the HDLC DUT top-level file path, and the interface signal task switch. The UVM component configuration module calls the generation function of the UVM component based on actual test requirements.

[0012] The HDLC parsing module calls the HDLC parsing script in the script execution module. The HDLC parsing script uses Python's re library to write regular expressions, which are text matching rules. Based on the regular expressions, the HDLC parsing script performs syntax analysis and signal recognition on the content of the top-level file of the DUT, performs text matching, and extracts HDLC interface signals and parameters.

[0013] The HDLC parsing module includes a macro definition generation module, an interface signal generation module, and an instantiation generation module. The macro definition generation module extracts parameters from the DUT top-level file, generates a standardized macro definition file, and applies the generated macro definition file to the DUT and UVM verification environment. The interface signal generation module extracts interface signals from the DUT top-level file, generates a UVM verification environment interface signal definition file, and applies the generated UVM verification environment interface signal definition file to the DUT and UVM verification environment. The instantiation generation module extracts interface signals from the DUT top-level file, generates instantiated DUT call code snippets, which include DUT module instantiation statements and port connection statements. These DUT call code snippets are used in the top-level module of the UVM verification environment to enable the DUT to be called in the UVM verification environment.

[0014] The verification environment setup module includes a uvm_object generation module, a uvm_component generation module, and other component generation modules. The uvm_object generation module calls the corresponding script files of the script execution module, defines the basic attributes and methods of uvm_object based on the UVM specification, and generates a template for uvm_object class components. Then, based on the uvm_object class component template, it generates uvm_object class components including uvm_sequence_item files and config files. The uvm_component generation module calls the corresponding script files of the script execution module to define the basic cycle functions of uvm_component. The system also includes communication interfaces and data processing logic frameworks between components, generating templates for uvm_component class components, and then generating uvm_component class components including sequencer, agent, env, and scoreboard components based on the templates. The other component generation modules call the corresponding script files of the script execution module to generate templates for the corresponding components based on the functions and roles of tb_top, test_top, driver, monitor, sequence, and testcase components in the UVM verification environment, and then generate the corresponding components based on the generated templates.

[0015] The performance monitoring script collects test case execution time and resource utilization in real time, and executes commands for waveform viewing, coverage collection, and simulation file clearing to obtain test process data and result information; based on the data collected by the performance monitoring script, the parameters of the configuration information module are modified.

[0016] The UVM verification environment generated by the verification environment building module adopts a dual-top-level architecture, including: The Test_top component, serving as the top-level verification logic, carries the core logic of the UVM verification environment, including the Env component and the Hdlc_cfg configuration object. The Hdlc_cfg configuration object loads parameters from the configuration information module into the various components within the Env component; The Tb_top component, serving as the top-level hardware instantiation component, implements hardware signal interaction between the UVM verification environment and the DUT. The Env component is the top-level container of the UVM verification environment, internally including: The Tx_agent component, containing a Sequencer component, a Driver component, and a Monitor component. The Sequencer component generates an HDLC test sequence based on the parameters of the Hdlc_cfg configuration object. The Driver component converts the test sequence into hardware signals and drives the DUT through the interface. The Monitor component monitors the excitation signals and collects transmitted data. The Rx_agent component, which includes the Monitor component, is used to monitor the output signals of the DUT through the interface, parse the HDLC response frames, and collect data from the receiving end. The Scoreboard component is used to receive the transmitted data from the Tx_agent component and the received data from the Rx_agent component, perform data integrity comparison, protocol compliance comparison, and timing consistency comparison, and generate a verification result report.

[0017] Another technical solution of the present invention provides a method for generating an automatic HDLC verification environment. This method is based on the aforementioned automatic HDLC verification environment generation device and includes the following steps: Step 1: Edit the configuration information module, user-defined verification core parameters, including the DUT top-level file path, test platform generation directory, and UVM component configuration; Step 2: Execute the script execution command to start the script execution module; Step 3: Enter the HDLC parsing stage, read the DUT top-level file through the HDLC parsing module, extract interface signals, macro definition parameters, and the instantiation code of the DUT in the test platform, detect and process files with the same name, and output the parsing result file; Step 4: Build the verification environment, combine the configuration information and parsing results to generate a complete UVM verification environment, detect existing components and generate only missing components; Step 5: Simulate and run test cases, call the simulator to compile the verification environment code, execute the test cases and synchronously collect waveforms, functional coverage, and simulation logs, and output the verification results.

[0018] In step three, it checks whether a file with the same name as the parsing result file exists in the simulation directory; if it exists, the existing file is renamed to a backup file with a timestamp, and then a new parsing result file is output; if it does not exist, the parsing result file is generated directly. In step four, it checks whether the UVM component already exists in the simulation directory; if it exists, only the missing component is generated; if it does not exist, all configuration components are generated.

[0019] Another technical solution of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the automatic verification environment generation method described above.

[0020] Compared with existing technologies, the main advantages of this invention include: 1. Users only need to complete simple settings in the configuration information module, and a complete UVM-based HDLC verification environment can be generated with one click through the script execution module. This significantly reduces the manual coding workload of the test platform and effectively shortens the verification environment construction cycle. After the corresponding script file executes the command, the device automatically completes the entire process of HDLC parsing, environment setup, and test case execution without manual intervention, thereby significantly improving verification efficiency and accelerating the overall progress of IC design. 2. The configuration information module supports flexible settings for parameters such as the test platform generation path, UVM component composition, and interface signal enable status. Users can customize the verification environment architecture according to actual test requirements. When the application scenario or the functional requirements of the target HDLC module change, only the configuration file needs to be modified to quickly generate an adapted verification environment, greatly improving the versatility and scalability of the device and effectively reducing repetitive R&D costs. 3. The HDLC parsing module uses regular expression matching to accurately extract DUT interface signal definitions and parameter declarations, generating corresponding interface files and macro definition files to ensure the consistency of signal connections and parameter constraints of the DUT in the verification environment. The verification environment setup module constructs a stable dual-top-level UVM verification architecture (Tb_top hardware layer and Test_top test layer), instantiating standard verification components such as Agent, Scoreboard, and Coverage components based on the UVM component library, effectively avoiding cross-clock domain competition risks and improving the stability and reliability of the verification environment. The simulation running module, combined with coverage statistics and performance monitoring, achieves comprehensive and accurate verification of the HDLC module's functions. It automatically parses the DUT's top-level files to generate verification resources, eliminating wiring errors introduced by manual operation and ensuring the correct instantiation and operation of the DUT in the environment. The generated test cases comprehensively cover protocol characteristics such as frame structure, CRC check, and address fields based on the HDLC protocol specification. Combined with the UVM standardized verification process and constraint random stimulus technology, it can promptly detect functional defects of the module under various operating conditions, thereby effectively improving the verification quality of the HDLC module and reducing the risks of actual product application.

[0021] To make the above and other objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the specific embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram of an HDLC automatic verification environment generation device provided by the present invention.

[0024] Figure 2 for Figure 1 Interaction diagram between various modules.

[0025] Figure 3 This is a schematic diagram of an HDLC automatic verification environment generation method according to the present invention.

[0026] Figure 4 This is a structural diagram of the HDLC verification environment built by the verification environment building module of the present invention. Detailed Implementation

[0027] The foregoing and other technical contents, features, and effects of the present invention will be clearly presented in the following detailed description of a preferred embodiment with reference to the accompanying drawings. The directional terms mentioned in the following embodiments, such as up, down, left, right, front, or back, are merely for reference to the accompanying drawings. Therefore, the directional terms used are for illustrative purposes and not for limiting the present invention.

[0028] Example 1 Example 1 provides an HDLC automatic verification environment generation device, including: a configuration information module for setting HDLC basic configuration parameters and calling the generation function of the UVM component; the generation function of the UVM component is used to add or remove the corresponding UVM component; The HDLC parsing module reads the top-level DUT file specified in the configuration information module, extracts the interface signals and parameters of the DUT, and automatically generates interface files, macro definition parameter files, and DUT instantiation files based on the extraction results. The verification environment setup module contains multiple sub-modules for generating different UVM components. Based on the addition or removal of UVM components set in the configuration information module, it calls the script files in the script execution module to build a UVM verification environment architecture containing the required UVM components. The simulation execution module, based on the completed UVM verification environment architecture, compiles and simulates test cases, calls the performance monitoring script in the script execution module, and collects test data of test cases in real time. The script execution module includes multiple script files, which execute the parsing instructions of the HDLC parsing module, the setup instructions of the verification environment setup module, and the execution instructions of the simulation execution module, respectively.

[0029] The HDLC automatic verification environment generation device provided in Example 1 only requires simple settings in the configuration information module, and can generate a complete UVM-based HDLC verification environment with one click through the script execution module, which significantly reduces the manual coding workload of the test platform and effectively shortens the verification environment construction cycle.

[0030] The following section provides a detailed explanation of the HDLC automatic verification environment generation device provided in Embodiment 1, in conjunction with the accompanying drawings.

[0031] like Figure 1 As shown, the HDLC automatic verification environment generation device of this application includes a configuration information module, an HDLC parsing module, a verification environment building module, a simulation running module, and a script running module.

[0032] The configuration information module includes the hdlc_config configuration module and the UVM component configuration module. The hdlc_config module defines the basic HDLC configuration parameters, including the test platform generation path (testbench path), the HDLC DUT top-level file path (used to inform the DHLC parsing module of the path to read the DUT file), and interface signal task switches (essentially a boolean status flag used to declare whether a task is executed). The configuration information module stores the core parameters input by the user, providing the basic configuration basis for subsequent operations.

[0033] The UVM component configuration module is used for component customization of the UVM verification framework. It allows users to configure the relevant parameters of the generation function that calls the UVM component based on actual testing needs, so as to add or remove the corresponding components.

[0034] UVM components are the core building blocks of the UVM verification methodology and serve as the base class for all verification environment hardware structure elements. UVM components are nested to form a tree hierarchy, and components communicate with each other at the transaction level through TLM ports.

[0035] The HDLC parsing module includes a macro definition generation module, an interface signal generation module, and an instantiation generation module. Based on configuration resources, the HDLC parsing module extracts the top-level file of the HDLC DUT and decomposes it into multiple reusable verification resources, which are used to generate interface signal definition files, macro definition files, and instantiation code snippets.

[0036] The macro definition generation module extracts parameters from the top-level file of the DUT, generates a standardized macro definition file, and applies the generated macro definition file to the DUT and UVM verification environment to unify the constraint parameters of the verification environment and the DUT.

[0037] The interface signal generation module extracts the interface signals from the top-level file of the DUT, generates the UVM verification environment interface signal definition file, and applies the generated UVM verification environment interface signal definition file to the DUT and the UVM verification environment to ensure the signal interaction matching between the UVM verification environment and the DUT.

[0038] The interface signals extracted from the top-level file of the DUT by the instantiation generation module are used to generate an instantiated DUT call code snippet. The DUT call code snippet includes DUT module instantiation statements and port connection statements. The DUT call code snippet is used in the top-level module of the UVM verification environment to realize the calling of the DUT in the UVM verification environment.

[0039] The HDLC parsing module parses the top-level file of the DUT by calling the HDLC parsing script in the script execution module. (A script is a computer program used to automate repetitive tasks or extend system functions. The code is plain text, written based on the functions to be implemented, and executed line by line by the interpreter.) The HDLC parsing script uses Python's re library to write regular expressions, which are text matching rules. Based on the regular expressions, the HDLC parsing script performs syntax analysis and signal recognition on the content of the top-level file of the DUT, performs text matching, and extracts HDLC interface signals, macro file definition parameters, and instantiation code of the DUT in the test platform.

[0040] The following explanation uses a Python script to parse the contents of the top-level file of the DUT (Verilog / SystemVerilog module code) and extract interface signals and parameters as an example. The part after the # in each code snippet is an explanation of the code.

[0041] def extract_interface_signals(module_code, list_code): # Interface signal extraction function. After calling the parameter extraction function, it extracts the direction (input / output / inout), bit width, and signal name from the DUT port and generates a logic declaration; params = extract_parameters(list_code); # Extract the parameter list for later replacement of parameters in the bit width; port_pattern = re.compile( ; # Define port matching regular expression; r'\b(input|output|inout)\b\s*' #direction; #Group 1: Port direction (required); r'(?:reg|logic|wire)?\s*' #type; #Optional type: reg / logic / wire (non-capturing); r'((?:\[.*?\]\s*)*)' #width; #Group 2: bit width (e.g., [7:0], [DATA_W:0]); r'([^=,;\)\n]+)' #the last bit; #Group 3: Signal Group (Core); r'[^,;\)]*' #signal list; #ignore default values / suffixes; r'(?=[,\);\n])', #end signal; #end assertion symbol; re.IGNORECASE | re.DOTALL); # Match bit width individually (compatible with complex declarations); width_pattern=r'^\s*(?:input|output|inout|wire|reg|logic)(?:\s+(?:input|output|inout|wire|reg|logic))*\s*((?:\[\s*[^]]+\s*\])+)\s+\w+'; # Independently matches the complete bit width (handles multi-segment bit widths and mixed type declarations); if the bit width is matched, it is extracted; otherwise, the bit width is None; logic_ports=[ ]; all_ports=[ ]; for match in port_pattern.finditer(module_code): # Match ports line by line / segment by segment, get the start / end position of each port, and extract the matching content; start_pos = match.start(); # The starting position (index) of the matched string in module_code; end_pos = match.end(); # The end position (index) of the matched string in module_code; match_content = module_code[start_pos:end_pos]; # Slice the matched string from the original module code using the start and end positions; #print(f"match_content : {match_content}"); `width_match = re.search(width_pattern, match_content);` searches the extracted segment using the regular expression `width_pattern` (matching the width of square brackets, such as `[7:0]`, `[WIDTH-1:0]`), and `re.search` returns the first match; if no match is found, it returns `None`. if width_match: result = width_match.group(1); else: result = None; #print(f"result = {result}"); #Resolve basic port information; direction = match.group(1).lower(); # Convert direction to lowercase (input / output / inout); width = match.group(2).strip() if match.group(2) else None; # Bit width; signal_group = match.group(3).strip(); # Signal group (multiple signals); #split signals; #split signal groups (processes commas within the bit width); signals = re.split(r',\s*(?![^\[\]]*\])',signal_group); # Split multiple signals by commas, ignoring commas within the bit width (e.g., [A,B:C] will not be incorrectly split); for signal in signals:signal = signal.strip(); if not signal: Continue; signal_name = re.sub(r'\s*(?:\[.*?\])+\s*$','',signal).strip(); # Remove the bit width at the end of the signal (e.g., data[7:0]→data); #print(f"signal_name={signal_name}"); declaration="logic" if result:; # Generate logic declaration code; result = replace_param_in_width(result, params); # Replace the parameter in the width; declaration += f"{result}"; declaration+=f"{signal_name};" logic_ports.append(declaration); # Call replace_param_in_width (an implicit function in the code) to replace the parameter in the bit width with the actual value; generate a standardized logic declaration (Verilog / SV verification platform standard format); all_ports.append({"direction":direction,"signal_name":signal_name}); # Store as a dictionary list for easy later use (direction + signal name); logic_declaration='\n'.join(logic_ports) return logic_declaration, all_ports; # Concatenate all logic declarations as a string, return: formatted code + structured port information; def extract_parameters(content): # Parameter name extractor, extracts all parameter names and values ​​from the #(...) parameter list of the DUT, and returns parameter key-value pairs; return param_name.

[0042] The verification environment setup module includes the uvm_object generation module, the uvm_component generation module, and other component generation modules. Based on the addition or removal of UVM components set in the configuration information module, it calls the script files in the script execution module to build the UVM verification environment architecture containing the required UVM components.

[0043] The `uvm_object` class is the most basic class in UVM, used to encapsulate data, and typically corresponds to transaction or configuration objects. The `uvm_component` class is the base class for all validation components in UVM, possessing a hierarchical structure and participating in building the skeleton of the validation platform.

[0044] The uvm_object generation module calls the corresponding script file of the script execution module, defines the basic attributes and methods of uvm_object based on the UVM specification, and generates a template of uvm_object class component; then, based on the template of uvm_object class component, it generates uvm_object class component including uvm_sequence_item file and config file.

[0045] The uvm_component generation module calls the corresponding script file of the script execution module to define the basic lifecycle functions of uvm_component, as well as the communication interface and data processing logic framework between components, generate a template of uvm_component class components, and then generate uvm_component class components including sequencer component, agent component, env component, and scoreboard component based on the template of uvm_component class components.

[0046] Other component generation modules call the corresponding script files of the script execution module, and generate templates for the corresponding components based on the functions and roles of the tb_top, test_top, driver, monitor, sequence, and testcase components in the UVM verification environment. Then, they generate the corresponding components based on the generated templates.

[0047] The following explanation uses the uvm_object generation module and the corresponding script file code called by the uvm_component generation module as examples. The part after the # in each code is an explanation of the code.

[0048] The script file code called by the uvm_object generation module is as follows: def gen_uvm_object(classname, ; # Function definition; parent="uvm_object", member_dict=None, interface_dict=None, config_class_dict=None, transaction_type=None, analysis_port_dict=None, analysis_fifo_dict=None, port_connect_dict=None): ifndef_guard=f"__{classname.upper()}__"; # Generate the ifndef macro name; # Generate template string. Use f"""\""" to create a multi-line formatted string. {variable name} will be replaced with the actual value. This is a template of the NVM class. template=f"""\; {file_header}; `ifndef {ifndef_guard}; # This macro has not been defined; `define {ifndef_guard}; # Define it (header file protection);` `include "uvm_macros.svh"; # Includes UVM macro definitions (such as `uvm_object_utils);` import uvm_pkg::*; # Import the UVM package; `class {classname} extends {parent};` # Defines a class that inherits from its parent class. / / rand bit[31:0] data; # Template for illustrating member variable syntax; / / rand bit[31:0] pload; #rand indicates random variation; / / constraint cstrt{{;#A template illustrating constraint syntax; / / data>= 10; / / data<= 100; / / pload.size>= 50; / / pload.size<= 1000; / / }}; `uvm_object_utils({classname}); #UVM utility macro, automatically registers classes to the factory; extern function new(string name = "{classname}"); # Declare a constructor function; endclass / / {classname}; # End of class; function {classname}::new(string name = "{classname}"); # Constructor implementation; super.new(name); # Call the parent class constructor; Endfunction; `endif / / {ifndef_guard}; # End header file protection;` """ return template; # The function returns the generated complete Verilog code string; if_name_=="__main__":; # If this function is executed directly; file_path="uvm_object_demo.sv"; # Output filename; template = gen_uvm_object(classname="mb_obj"); # Call the function to generate a template with the class name mb_obj; with open(file_path, 'w') as file: # Open the file in write mode; file.write(template); # Writes the generated content to a file.

[0049] The corresponding script file code called by the uvm_component generation module is as follows: def gen_uvm_component(classname, ; # Function signature; parent="uvm_component", file_header="", member_dict=None, interface_dict=None, config_class_dict=None, transaction_type=None, analysis_port_dict=None, analysis_fifo_dict=None, port_connect_dict=None): ifndef_guard = f"_{classname.upper()}_"; # Generate header file protection macro name; transaction_decl = ""; # Handle parameterized parent class; if transaction_type is not None: # If transaction_type is passed in; parent += f"# ({transaction_type})"; # The parent class will become uvm_component; membet_declaration=""; # Member variable declaration; membet_instantiation = ""; # Instantiate member variable; if (membet_dict is not None) and (len(membet_dict)>0): # Checks if membet_dict is not None (it was indeed passed in) and is not an empty dictionary. The internal logic is executed only if both conditions are met. for instname, member in membet_dict.items(): # Iterate through the dictionary, getting the instance name (instname) and member object (member) in each loop. membet_declaration += ""*4 + f"{member.classname} {instname};\n"; # Generate member variable declaration; membet_instantiation += ""*4 + f"{instname} = {member.classname}::type_id::create("{instname}",this);\n"; # Generate UVM factory instantiation statement; interface_declaration = ""; #Declare virtual interface; interface_get = ""; # Retrieves the interface from config_db; # The generated code attempts to obtain the virtual interface from uvm_config_db; if it fails, an error is reported. if (interface_dict is not None) and (len(interface_dict)>0): # Checks if interface_dict is neither None nor an empty dictionary; internal code will only execute if an interface configuration has actually been passed in. for instname, member in interface_dict.items(): # Iterate through each interface item, getting the instance name (instname) and member object (member) each time; interface_declaration += "" * 4 + f"virtual {member.classname}{instname};\n"; # Generates the member variable declaration of the class; interface_get+="" * 4 + f"if (!uvm_config_db#(virtual{member.classname})::get(this,"","{instname}",{instname})) begin\n"; # Generate code to retrieve the interface from the global configuration database; interface_get += ""*8+f"uvm_report_eror(get_full_name(), $sformatf("uvm_config_db cannot get {instname}({member.classname})."),UVM_LOW)\n"; # Print error message when retrieval fails; interface_get += ""*4+f"end\n"; # Generates end, closing the above if statement block; config_class_declaration = ""; # Configuration class declaration; config_class_get = ""; # Retrieve configuration from config_db; if (config_class_dict is not None) and (len(config_class_dict)>0): for instname, member in config_class_dict.items(): config_class_declaration += "" * 4 + f"{member.classname}{instname};\n"; config_class_get +=""* 4 + f"if (!uvm_config_db#({member.classname})::get(this,"","{instname}",{instname})) begin\n"; config_class_get += "" * 8 + f"uvm_report_eror(get_full_name(), $sformatf("uvm_config_db cannot get {instname}({member.classname})."),UVM_LOW)\n"; config_class_get += "" * 4 + f"end\n"; # Generate analysis_port related code; analysis_port_declaration = ""; # Declaration; analysis_port_instantiation = ""; # Instantiate; analysis_port_example = ""; # Example usage; The component broadcasts the transaction to all connected subscribers via write(). if (analysis_port_dict is not None) and (len(analysis_port_dict)>0): # Check if port_dict is neither None nor an empty dictionary; for portname, port_transaction_type in analysis_port_dict.items(): # Iterate through the dictionary, returning a pair of key and value for each transaction; analysis_port_declaration += "" * 4 + f"uvm_analysis_port #({port_transaction_type}) {portname};\n"; # Generate the port member variable declaration code; analysis_port_instantiation += "" * 4 + f"{portname} = new("{portname}",this);\n"; # Generate the instantiation code for the port; analysis_port_example += ""*4 +f"{port_transaction_type} tr;\n"; # Generate a local transaction variable; analysis_port_example += ""*4 + f"tr = new("tr");\n"; # Instantiate the transaction object; analysis_port_example += ""*4 + f"{portname}.write(tr);\n"; # Call the port's write() method to broadcast the transaction; # Generate analysis FIFO related code. FIFO is used by the receiver to temporarily store received transactions. analysis_fifo_declaration = ""; # Clear the value, prepare to receive the FIFO member variable declaration code; analysis_fifo_instantiation = ""; # Clear the value, preparing to receive the FIFO instantiation code; analysis_fifo_example = ""; # Clear the value, prepare to receive example code for using FIFO; if (analysis_fifo_dict is not None) and (len(analysis_fifo_dict)>0): # Determine if the user has passed in a fifo dictionary and if the dictionary contains content; proceed only if both conditions are met. for fifoname, port_transaction_type in analysis_fifo_dict.items(): # Iterate through the dictionary; analysis_fifo_declaration += "" * 4 + f"uvm_tlm_analysis_fifo #({port_transaction_type}) {fifoname};\n"# Generates the fifo declaration; analysis_fifo_instantiation+=""*4+f"{fifoname}=new("{fifoname}",this);\n"; # Generate FIFO instantiation; analysis_fifo_example+=""*4+f"{port_transaction_type} tr;\n";# Generate receiver variables; analysis_fifo_example+=""*4+f"{fifoname}.get(tr);\n"; # Retrieve data from fifo; # Generate port connection code; port_connect = "" if (port_connect_dict is not None) and (len(port_connect_dict)>0): for initiator, target in port_connect_dict.items(): port_connect += "" * 4 + f"{initiator}.connect({target});\n" #Assemble the final template; template=f"""\; # Assign a value to the template; {file_header}; # Insert file header comment; `ifndef {ifndef_guard}; `define {ifndef_guard}; `include "uvm_macros.svh"; # Include the UVM macro definition file;` import uvm_pkg::*; # Import the UVM package; `class{classname} extends {parent};` # Class declaration; #Member variable area; {interface_declaration}; {config_class_declaration}; {membet_declaration}; {analysis_port_declaration}; {analysis_fifo_declaration}; / / integer fp0; # Declare a file pointer if file operations are needed; `uvm_component_utils({classname}); # Automatically register the class in the UVM factory; extern function new(string name = "{classname}", uvm_component parent= null); # Constructor declaration; extern virtual function void build_phase(uvm_phase phase); # Build phase: Get configuration and instantiate sub-components; extern virtual function void connect_phase(uvm_phase phase); # connect phase, connects to the port; #The following are other phases reserved by UVM, and these phases are not generated by default; / / extern virtual function void end_of_elaboration_phase(uvm_phasephase); / / extern virtual function void start_of_simulation_phase(uvm_phasephase); / / extern virtual task reset_phase(uvm_phase phase); / / extern virtual task configure_phase(uvm_phase phase); extern virtual task main_phase(uvm_phase phase); / / extern virtual task shutdown_phase(uvm_phase phase); endclass / / {classname}; # End of class; function {classname}::new(string name = "{classname}", uvm_componentparent=null); # Constructor; #build_phase creation; super.new(name, parent); Endfunction; function void {classname}::build_phase(uvm_phase phase); super.build_phase(phase); # Call the parent class build_phase; {interface_get};#uvm_config_dbGet virtual interface; {config_class_get}; #uvm_config_db retrieves the configuration object; {membet_instantiation}; # Instantiate the child component using the factory; {analysis_port_instantiation}; # Instantiate the port; {analysis_fifo_instantiation}; # Instantiate fifo; Endfunction; #port_connect expands to a port connection statement; function void {classname}::connect_phase(uvm_phase phase); super.connect_phase(phase); {port_connect}; Endfunction; #main_phase is the running phase; task {classname}::main_phase(uvm_phase phase); super.main_phase(phase); / / uvm_report_info(get_full_name(),$sformatf("This is an infomessage."),UVM_MEDIUM); / / uvm_report_error(get_full_name(),$sformatf("This is an errormessage."),UVM_LOW); / / uvm_report_warning(get_full_name(),$sformatf("This is a warningmessage."),UVM_LOW); / / uvm_report_fatal(get_full_name(),$sformatf("This is a fatalmessage."),UVM_LOW); {analysis_port_example}; # Generate a sending example; {analysis_fifo_example}; # Generate a receiver example; / / fp0 = $fopen("fp0.txt","w");# Open the file; / / fdisplay(fp0,$formatf("data=%0d",32)); / / with line wrap; #Write with line wrap; / / fwrite(fp0, $sformatf("data=%0d",32")); / / without line wrap; #Write without line wrap; / / fclose(fp0); # Close the file; Endtask; `endif / / {ifndef_guard};` """; #Return and write to a file; when run directly, it generates a minimal UVM component file. return template; if_name__="__main__": file_path = "uvm_component_demo.sv"; template = gen_uvm_component(classname="mb_comp"); with open(file_path, 'w') as file: file.write(template).

[0050] The UVM verification environment generated by the verification environment setup module in this application is as follows: Figure 4 As shown, a dual top-level architecture is adopted, including the Test_top component and the Tb_top component. The Test_top component and the Tb_top component can be used to separate the verification logic from the hardware instantiation. The Test_top component focuses on the verification logic (UVM component, test case control) and is responsible for organizing software logic such as stimulus generation, data monitoring, and result evaluation. The Tb_top component focuses on hardware instantiation (clock, reset, DUT connection) and realizes the hardware signal interaction between the DUT and the verification logic.

[0051] The Test_top component, serving as the top layer of the verification logic, carries the core logic of the UVM verification environment. It includes the Env component and the Hdlc_cfg configuration object (the configuration file for the entire verification environment). The Hdlc_cfg configuration object loads the parameters of the configuration information module into the Env component (such as HDLC frame type, window mechanism, timeout threshold, digital segment configuration, coverage acquisition switch, etc.) and controls the excitation type of the Tx_agent component and the comparison rules of the Scoreboard component.

[0052] The Env component is the top-level container for the UVM validation environment, and it includes: The Tx_agent component includes a Sequencer component, a Driver component, and a Monitor component. The Sequencer component generates an HDLC test sequence based on the parameters of the Hdlc_cfg configuration object. The Driver component converts the test sequence into hardware signals and drives the DUT through an interface. The Monitor component monitors the excitation signals and collects and transmits data. The Rx_agent component, which includes the Monitor component, is used to monitor the output signal of the DUT through the interface, parse the HDLC response frame, and collect data from the receiving end. The Scoreboard component is used to receive data sent by the Tx_agent component and data received by the Rx_agent component, perform data integrity comparison (such as whether the HDLC frame payload is consistent), protocol compliance comparison (such as whether the address field and control field conform to the HDLC specification), and timing consistency comparison (such as whether the response timeout and frame interval meet the requirements), and generate a verification result report (pass / fail, coverage data).

[0053] The Tx_agent, Rx_agent, and Scoreboard components work together to achieve a closed-loop verification process of stimulus transmission → signal monitoring → result evaluation.

[0054] The Tb_top component, as the top-level hardware instantiation component, enables hardware signal interaction between the UVM verification environment and the DUT. The Hdlc_interface, acting as the signal bridge between Test_top and the DUT, defines the hardware interfaces of the HDLC protocol (such as the serial data input interface tx_data, the parallel data output interface rx_data, the clock interface clk, and the reset interface rst_n), ensuring that the stimuli sent by the Tx_agent.Driver component and the monitoring by the Rx_agent.Monitor component are accurately mapped to the DUT pins.

[0055] Clk_gen (clock generation module) generates the clock signal for the HDLC protocol (e.g., a 100MHz serial clock), and Rst_gen (reset signal generation module) generates the reset signal (e.g., system power-on reset, manual reset), providing the basic hardware environment for the DUT. The DUT (HDLC) is the target object for verification in this invention. It interacts with the verification environment through Hdlc_interface, receives the stimulus from the Tx_agent component, and outputs a response to the Rx_agent component, completing the closed loop of the verification of the module under test.

[0056] The specific workflow of the verification environment is as follows: After the test case is started, the Hdlc_cfg configuration object loads the parameters of the configuration information module and passes them to each component in the Env; the Tx_agent.Sequencer component generates HDLC test sequences according to the configuration, the Driver component converts them into hardware signals and injects them into the DUT through Hdlc_interface; the Tx_agent.Monitor component monitors the transmitted stimuli, and the Rx_agent.Monitor component monitors the DUT response; the Scoreboard component compares the transmitted and received data and outputs the verification results.

[0057] The simulation execution module, based on the established UVM verification environment architecture, analyzes, compiles, and simulates test cases by calling relevant EDA tool commands and executing corresponding script files from the script execution module. It calls the simulator (VCS) to compile the verification environment code (including UVM components and DUT parsing files), executes test cases, and simultaneously collects waveforms (.vcd files), functional coverage (.ucdb files), and simulation logs. Finally, it outputs the verification results, including test case pass / fail status, coverage data (such as protocol field coverage), and key timing metrics (such as frame response time). It also outputs waveform files and error logs to provide a basis for verification environment optimization, thus concluding a single verification process.

[0058] The simulation execution module executes the corresponding script file of the script execution module. The following is an example of the script file code called. This code is used to explain how the simulation execution module performs analysis, compilation and simulation operations on test cases.

[0059] def create_tb_filelist(sim_cfg, testcase_path, workdir_path): copy_file(src_path=testcase_path, dst_path=workdir_path+" / .") testcase_fullname = filepath_to_fullname(testcase_path) testcase_path_workdir = r". / " + testcase_fullname + "\n" tb_filelist_fullname = filepath_to_fullname(sim_cfg.tb_filelist_path) tb_filelist_path_workdir = workdir_path + r" / " + tb_filelist_fullname copy_file(src_path=sim_cfg.tb_filelist_path, dst_path=tb_filelist_path_workdir) replace_in_file(filepath=tb_filelist_path_workdir, old_string=sim_cfg.tb_filelist_testcase_placeholder, new_string=testcase_path_workdir) def get_template_run_sim(sim_cfg, testcase_path): tb_filelist_path_workdir = r". / " + filepath_to_fullname(sim_cfg.tb_filelist_path); dut_filelist_path_workdir = r". / " + filepath_to_fullname(sim_cfg.dut_filelist_path) testcase_name,_ = filepath_to_filename_and_extension(testcase_path) tc_fullname = filepath_to_fullname(testcase_path) template_run_sim = f""" import sys; sys.path.append("{sim_cfg.toolkit_home}") import os import argparse from config.sim_config import SIM_config_project from utils.base import step_decorator from utils.base import filepath_to_filename_and_extension from utils.base import list_and_select from utils.base import check_error from utils.base import check_exist_and_backup # block-0: define SIM config workdir class SIM_config_workdir(SIM_config_project): def __init__(self): super().__init__() # workdir setting self.tc_fullname = r"{tc_fullname}" self.testcase_name = r"{testcase_name}" self.ntb_random_seed = {sim_cfg.ntb_random_seed} self.time_stamp = {sim_cfg.time_stamp} self.sim_cleanup_files = {sim_cfg.sim_cleanup_files} self.tb_filelist_path = "{tb_filelist_path_workdir}" self.dut_filelist_path = "{dut_filelist_path_workdir}" # Timescale for simulation self.timescale = r"{sim_cfg.timescale}" # Include directories self.incdir = {sim_cfg.incdir} # Waveform dump options self.wave_en = {sim_cfg.wave_en} # 1: download fsdb, 0: don'tdownload fsdb. self.wave_opts = r"{sim_cfg.wave_opts}" # Coverage analysis options self.coverage_en = {sim_cfg.coverage_en} self.coverage_home = r"{sim_cfg.coverage_home}" self.coverage_opts_base=f"-cm line+cond+fsm+tgl+branch+assert -covg_cont_on_error" self.coverage_opts = f"-cm line+cond+fsm+tgl+branch+assert -cm_dir{{self.coverage_home}} / {{self.time_stamp}} / {{self.testcase_name}}.vdb" # Simulation profiling options self.simprofile_en = {sim_cfg.simprofile_en} self.simprofile_opts = "{sim_cfg.simprofile_opts}" #Regression option self.regress_en = {sim_cfg.regress_en} # block-1: vcs compile and simulate # 1-1: Analysis @step_decorator def vcs_analysis(config): incdir_str = "" for incdir in config.incdir: incdir_str += f"+incdir+{{incdir}} " cmd1 = (f"vlogan -full64 -sverilog +v2k -debug_access+all -debug_region+cell+encrypt " + f"-kdb -lca -diag timescale=-timescale{{config.timescale}} " + f"+define+UVM_PACKER_MAX_BYTES=1500000 " + f"+define+UVM_DISABLE_AUTO_ITEM_RECORDING " + f"+libext+.{{config.libext}} -y {{config.libext_path}} -error={{config.error_opts}} -ntb_opts {{config.ntb_opts}} -v") cmd2 = (f"{{cmd1}} " + f"+incdir+{{config.uvm_home}} {{config.uvm_home}} / uvm.sv " +; f"{{incdir_str}} -f {{config.dut_filelist_path}} -f {{config.tb_filelist_path}} " + f"-l vcs_analysis.log") os.system(cmd1) os.system(cmd2) analysis_err = check_error("vcs_analysis.log") return analysis_err # 1-2: Elaboration @step_decorator def vcs_elaboration(config): if config.simprofile_en == 1: simprofile = "-simprofile" else: simprofile = "" if config.coverage_en == 1: coverage_opts = config.coverage_opts else: coverage_opts = "" top_all = "" for top in config.top: top_all += top + " " cmd=(f"vcs {{coverage_opts}} -full64 -sverilog -debug_access+all +notimingcheck -diag timescale " + f"-xprop={{config.xprop_mode}} " + f"+no_notifier +nospecify -kdb -lca -vpi -ntb_opts {{config.ntb_opts}} -error={{config.error_opts}} " + f"-top {{top_all}} {{simprofile}} -l vcs_elab.log -o simv -V") os.system(cmd) elaboration_err = check_error("vcs_elab.log") return elaboration_err # 1-3: Simulation @step_decorator def vcs_simulation(config): if config.simprofile_en == 1: simprofile_opts = f"-simprofile {{config.simprofile_opts}}" else: simprofile_opts = "" if config.coverage_en == 1: coverage_opts_base = config.coverage_opts_base else: coverage_opts_base="" cmd = (f". / simv {{coverage_opts_base}} {{config.wave_opts}}"+f"+UVM_TESTNAME={{config.testcase_name}}+UVM_VERBOSITY={{config.UVM_VERBOSITY}}"+f"{{simprofile_opts}}+ntb_random_seed={{config.ntb_random_seed}}-lvcs_sim.log"); os.system(cmd) simulation_err = check_error("vcs_sim.log") return simulation_err # block-2: clean workspace @step_decorator def clean_vcs_misc(config): os.system("rm -rf AN.DB") os.system("rm -rf work.lib++") os.system("rm -rf csrc") os.system("rm -rf simv") os.system("rm -rf simv.daidir") os.system("rm -rf ucli.key") os.system("rm -rf vc_hdrs.h") os.system("rm -rf verdi_config_file") os.system("rm -rf novas*") os.system("rm -rf verdiLog") os.system("rm -rf profileReport*") os.system("rm -rf simprofile_dir*") @step_decorator def clean_log(config): os.system("rm -rf vcs_analysis.log") os.system("rm -rf vcs_elab.log") os.system("rm -rf vcs_sim.log") # os.system("rm -rf run.log") os.system("rm -rf xprop.log") os.system("rm -rf unifiedInference.log") @step_decorator def clean_wave(config): os.system("rm -rf *.fsdb") os.system("rm -rf *.vf") @step_decorator def clean_specified(config): for item in config.sim_cleanup_files: os.system(f"rm -rf {{item}}") # block-3: check wave @step_decorator def waveform(config): os.system(f"verdi -dbdir sim.daidir -ssf test_top.vf") # block-4: refresh @step_decorator def refresh_macros(config): check_exist_and_backup("tb_macros.svh") os.system(f"cp {{config.tb_home}} / 01_top / tb_macros.svh . / ") @step_decorator def refresh_testcase(config): filepath = f". / {tc_fullname}" check_exist_and_backup(filepath) os.system(f"cp {testcase_path} . / ") # block-5: check code coverage @step_decorator def check_code_coverage(config): os.system(f"verdi -cov -covdir {{config.coverage_home}} / {{config.time_stamp}} / {{config.testcase_name}}.vdb") # block-6: main function def main_all(config): clean_vcs_misc(config) clean_log(config) clean_wave(config) clean_specified(config) analysis_err = vcs_analysis(config) if analysis_err>0: print(f"******************Oops! AnalysisFailed!*****************************") sys.exit(1) elaboration_err=vcs_elaboration(config) if elaboration_err>0: print(f"******************Oops! Elaboration Failed!**************************") sys.exit(1) simulation_err = vcs_simulation(config) if simulation_err>0: print(f"******************Oops! SimulationFailed!***************************") sys.exit(1) def main_debug(config): operation_list = ["vcs_analysis","vcs_elaboration","vcs_simulation","waveform","refresh_macros","refresh_testcase","check_code_coverage","clean_all","clean_vcs_misc","clean_log","clean_wave","clean_specified"] operation_selected = list_and_select(operation_list) for operation in operation_selected: if operation == "vcs_analysis": vcs_analysis(config) if operation == "vcs_elaboration": vcs_elaboration(config) if operation == "vcs_simulation": vcs_simulation(config) if operation == "waveform": waveform(config) if operation == "refresh_macros": refresh_macros(config) if operation == "refresh_testcase": refresh_testcase(config) if operation == "check_code_coverage": check_code_coverage(config) if operation == "clean_all": clean_vcs_misc(config) clean_log(config) clean_wave(config) clean_specified(config) elif operation == "clean_vcs_misc": clean_vcs_misc(config) elif operation == "clean_log": clean_log(config) elif operation == "clean_wave": clean_wave(config) elif operation == "clean_specified": clean_specified(config) if __name__ == "__main__": parser = argparse.ArgumentParser(description="Script for runningsimulation.") parser.add_argument("-d", "--debug", action='store_true', help="Choose function to run.") args = parser.parse_args() config = SIM_config_workdir() if args.debug: main_debug(config) else: main_all(config); """; return get_template_run_sim def create_sim_workdir(sim_cfg, testcase_path_list): testcase_workdir_list = [] for testcase_path in testcase_path_list: testcase_name, _ = filepath_to_filename_and_extension(testcase_path); workdir_name = sim_cfg.sim_pre + testcase_name + "_" + sim_cfg.time_stamp workdir_path = f"{sim_cfg.sim_home} / {workdir_name}" testcase_workdir_list.append(workdir_path) mkdir(workdir_path) create_tb_filelist(sim_cfg, testcase_path, workdir_path) copy_file(src_path=sim_cfg.dut_filelist_path, dst_path=workdir_path +r" / ") for path in sim_cfg.sim_required_files_path: copy_file(src_path=path, dst_path=workdir_path + r" / .") template_run_sim = get_template_run_sim(sim_cfg, testcase_path) run_sim_path = workdir_path + " / run_sim.py" write_file(filepath=run_sim_path, content=template_run_sim) return testcase_workdir_list. The explanation of the above code is as follows: The script file described above uses a higher-level function to automatically set up the simulation environment (directory, files, configuration) and generate a run_sim.py file. Enter the working directory and run python run_sim.py, which will automatically execute all commands for VCS compilation, linking, and simulation.

[0060] The execution process includes step 1: clean up the environment; step 2: compile and analyze (vlogan); step 3: link (elab); step 4: simulate (simv).

[0061] Step 1: Clean the environment: Entry point: main_all (config) -- Fully automated process; def main_all(config): clean_vcs_misc(config) # Clean up old files; clean_log(config); clean_wave(config); analysis_err = vcs_analysis(config) # [Step 1: Compile]; elaboration_err = vcs_elaboration(config) # [Step 2: Link]; simulation_err = vcs_simulation(config) # [Step 3: Simulation]; Step 2. Compilation and analysis; Compile -- vcs_analysis(); Execute the VCS compilation command vlogan: vlogan -full64 -sverilog -debug_access+all ... \; +incdir+$uvm_home $uvm_home / uvm.sv \-f dut_filelist.f -f tb_filelist.f \-l vcs_analysis.log; Compile DUT, TB, and UVM libraries; Read all Verilog / SV files in filelist; Output log: vcs_analysis.log.

[0062] Step 3: Link --vcs_elaboration(); Execute the VCS link command: vcs -coverage...-top test_top...-o simv; Link the compiled files into an executable simulation file simv; Configure the top module, coverage, and debug mode; Output log: vcs_elab.log; Step 4: Simulation -- vcs_simulation(); Execute the simulation command . / simv: . / simv+UVM_TESTNAME=test_case\; +UVM_VERBOSITY=UVM_LOW\; +ntb_random_seed=0\-lvcs_sim.log; Start the simulation; Pass in the UVM use case name, random seed, and verbosity; Output waveforms, coverage, and simulation logs.

[0063] Each step in the above process checks the logs for errors and exits directly after an error message is displayed.

[0064] The simulation execution module calls the performance monitoring script in the script execution module to collect test data from test cases in real time. The collected test data includes test case execution time and resource utilization data. The script can also perform functions such as waveform viewing (calling waveform viewing tool commands), coverage collection (calling coverage collection tool commands), and simulation file cleanup (deleting temporary simulation files).

[0065] Based on the data collected by the performance monitoring script, the parameters of the configuration information module are modified. The corresponding script file of the script execution module reads the updated configuration file and flexibly optimizes the verification environment through iterative optimization.

[0066] For example, based on the test results, the parameters of the test cases in the configuration information module can be adjusted to improve test efficiency and coverage.

[0067] The script execution module serves as the startup entry point for the entire device. By executing the corresponding Python script execution instructions, users can trigger the configuration information module, HDLC parsing module, verification environment setup module, and simulation execution module to perform their respective operations in sequence, thereby automating the entire process of HDLC automatic verification environment from configuration to generation and testing.

[0068] like Figure 2 The diagram showing the interaction relationships between the modules illustrates how, in the HDLC automatic verification environment generation device, the five modules collaborate through clearly defined data and control flows: The script execution module, acting as the device's entry point, first instantiates the configuration class in the configuration information module to obtain user-preset basic parameters. The configuration information module then passes the DUT-related configurations to the HDLC parsing module. Based on the configuration, the HDLC parsing module parses the data and outputs interface signal definitions, macro parameter files, and instantiated templates to the verification environment building module. Simultaneously, the configuration information module provides UVM component configurations to the verification environment building module, which then outputs a complete UVM verification environment to the simulation execution module.

[0069] The script execution module triggers the HDLC parsing module's parsing action by executing parsing instructions; based on the parsing results, the script execution module executes setup instructions to call the verification environment setup module to generate the UVM architecture; finally, the script execution module executes run instructions to start the simulation execution module and executes test cases based on the generated verification environment.

[0070] In the code snippets illustrated above, there are lines of code that are commented out with "#" or " / / ", such as the code snippet "#print(f"match_content : {match_content}")" that parses the content of the top-level DUT file.

[0071] The commented-out code in the above code snippet is commonly used in the verification process. Commenting out the corresponding code in the code snippet makes it easy to copy and paste later. During verification, verifiers will fill in a portion of the code based on the IP address at the locations of the commented-out code snippets. The format of the fill-in code is the same as the commented-out code. It's also understandable that there are two commenting methods in the above code—using "#" or " / / "—because Python and SystemVerilog have different commenting syntax.

[0072] Example 2 Example 2 provides a method for generating an automatic HDLC verification environment, which is based on an automatic HDLC verification environment generation device described in Example 1.

[0073] like Figure 3 As shown, a method for generating an HDLC automated verification environment includes the following steps: Step 1: Edit the configuration information module, where users define the core verification parameters, including the DUT top-level file path, the test platform generation directory, and UVM component configuration.

[0074] Step 2: Execute the script execution command to start the script execution module; Step 3: Enter the HDLC parsing stage. The HDLC parsing module reads the top-level file of the DUT, extracts interface signals, macro definition parameters, and instantiation code of the DUT in the test platform, detects and processes files with the same name, and outputs the parsing result file.

[0075] To preserve the parsing records and prevent existing files from being overwritten when generating new files, it is necessary to check if a file with the same name as the parsing result file exists in the simulation directory. If it does, back up the existing file (e.g., rename the old interface file to xxx_backup202507021535.sv) and then output the parsing result file; if it does not exist, generate the parsing result file directly.

[0076] The parsed result file includes the interface definition file (hdlc_interface.sv), the macro definition file (tb_macros.svh), and the DUT instantiation template (dut_connect.incl).

[0077] Step 4: Build a verification environment. Combine the configuration information and parsing results to generate a complete UVM verification environment, detect existing components and generate only the missing components.

[0078] To avoid repeatedly generating existing components (such as driver / monitor components that already exist in the project iteration, so only the coverage component needs to be added, and there is no need to regenerate the driver / monitor components), and to improve efficiency, it is necessary to check whether the UVM component already exists in the simulation directory.

[0079] If the missing components exist, only the missing components will be generated (e.g., if the tx_agent component already exists and the rx_agent component needs to be added, only the rx_agent component-related files will be generated); if the missing components do not exist, all configuration components will be generated (e.g., during the initial setup).

[0080] Step 5: Simulate and run test cases, call the simulator to compile and verify the environment code, execute test cases and synchronously collect waveforms, functional coverage and simulation logs, and output the verification results.

[0081] If optimization is needed (such as adjusting configuration or adding test cases), you can return to the configuration information editing module to restart the process and form an iterative closed loop.

[0082] Example 3 Embodiment 3 provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the automatic verification environment generation method described in Embodiment 2.

[0083] The above provides a detailed description of the HDLC automatic verification environment generation method, apparatus, and storage medium provided by the present invention. Specific examples have been used to illustrate the structure and working principle of the invention. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of the present invention. It should be noted that those skilled in the art can make various improvements and modifications to the present invention without departing from its principles, and these improvements and modifications also fall within the scope of protection of the claims of the present invention.

Claims

1. An HDLC auto-verification environment generation apparatus, characterized by comprising: include: The configuration information module sets the basic configuration parameters for HDLC and calls the generation function of the UVM component; The generation function of the UVM component is used to increase or decrease the corresponding UVM component; The HDLC parsing module reads the top-level DUT file specified in the configuration information module, extracts the interface signals and parameters of the DUT, and automatically generates interface files, macro definition parameter files, and DUT instantiation files based on the extraction results. The verification environment setup module contains multiple sub-modules for generating different UVM components. Based on the addition or removal of UVM components set in the configuration information module, it calls the script files in the script execution module to build a UVM verification environment architecture containing the required UVM components. The simulation execution module, based on the completed UVM verification environment architecture, compiles and simulates test cases, calls the performance monitoring script in the script execution module, and collects test data of test cases in real time. The script execution module includes multiple script files, which execute the parsing instructions of the HDLC parsing module, the setup instructions of the verification environment setup module, and the execution instructions of the simulation execution module, respectively.

2. The HDLC automatic verification environment generation apparatus according to claim 1, wherein The configuration information module includes the hdlc_config configuration module and the UVM component configuration module; The hdlc_config configuration module defines the basic configuration parameters of HDLC and stores the core parameters input by the user. The basic configuration parameters of HDLC include the test platform generation path, the HDLC DUT top-level file path, and the interface signal task switch. The UVM component configuration module calls the UVM component generation function based on actual testing requirements.

3. The HDLC auto-verification environment generation apparatus according to claim 1, wherein The HDLC parsing module calls the HDLC parsing script in the script execution module. The HDLC parsing script uses Python's re library to write regular expressions, which are text matching rules. Based on the regular expressions, the HDLC parsing script performs syntax analysis and signal recognition on the content of the top-level file of the DUT, performs text matching, and extracts HDLC interface signals and parameters.

4. The HDLC auto-verification environment generation apparatus according to claim 3, wherein The HDLC parsing module includes a macro definition generation module, an interface signal generation module, and an instantiation generation module. The macro definition generation module extracts parameters from the top-level file of the DUT, generates a standardized macro definition file, and applies the generated macro definition file to the DUT and UVM verification environment. The interface signal generation module extracts the interface signals from the top-level file of the DUT, generates a UVM verification environment interface signal definition file, and applies the generated UVM verification environment interface signal definition file to the DUT and the UVM verification environment. The instantiation generation module extracts interface signals from the top-level file of the DUT and generates instantiated DUT call code snippets. The DUT call code snippets include DUT module instantiation statements and port connection statements. The DUT call code snippets are used in the top-level module of the UVM verification environment to realize the calling of the DUT in the UVM verification environment.

5. The HDLC auto-verification environment generation apparatus according to claim 1, wherein, The verification environment setup module includes a uvm_object generation module, a uvm_component generation module, and other component generation modules; The uvm_object generation module calls the corresponding script file of the script execution module, defines the basic attributes and methods of uvm_object based on the UVM specification, and generates a template of uvm_object class component; then, based on the template of uvm_object class component, it generates uvm_object class component including uvm_sequence_item file and config file. The uvm_component generation module calls the corresponding script file of the script execution module to define the basic lifecycle function of uvm_component, as well as the communication interface and data processing logic framework between components, to generate a template of uvm_component class components, and then generates uvm_component class components including sequencer component, agent component, env component, and scoreboard component based on the template of uvm_component class components. The other component generation module calls the corresponding script file of the script execution module, generates templates for the corresponding components based on the functions and roles of the tb_top component, test_top component, driver component, monitor component, sequence component and testcase component in the UVM verification environment, and then generates the corresponding components based on the generated templates.

6. The HDLC auto-verification environment generation apparatus according to claim 1, wherein, The performance monitoring script collects test case execution time and resource utilization in real time, and executes commands for waveform viewing, coverage collection, and simulation file clearing to obtain test process data and result information. Based on the data collected by the performance monitoring script, the parameters of the configuration information module are modified.

7. The HDLC automatic verification environment generation device according to claim 1, characterized in that, The UVM verification environment generated by the verification environment building module adopts a dual top-level architecture, including: The Test_top component, as the top layer of the verification logic, is used to carry the core logic of the UVM verification environment: it includes the Env component and the Hdlc_cfg configuration object. The Hdlc_cfg configuration object loads the parameters of the configuration information module into each component within the Env component. The Tb_top component, as the top-level hardware instantiation component, enables hardware signal interaction between the UVM verification environment and the DUT; The Env component is the top-level container of the UVM verification environment, and its internal components include: The Tx_agent component includes a Sequencer component, a Driver component, and a Monitor component. The Sequencer component generates an HDLC test sequence based on the parameters of the Hdlc_cfg configuration object. The Driver component converts the test sequence into hardware signals and drives the DUT through an interface. The Monitor component monitors the excitation signals and collects and transmits data. The Rx_agent component, which includes the Monitor component, is used to monitor the output signal of the DUT through the interface, parse the HDLC response frame, and collect data from the receiving end. The Scoreboard component is used to receive data sent by the Tx_agent component and received data by the Rx_agent component, perform data integrity comparison, protocol compliance comparison, and timing consistency comparison, and generate a verification result report.

8. A method for generating an HDLC automatic verification environment, said method being implemented based on an HDLC automatic verification environment generation apparatus according to any one of claims 1-7, characterized in that, Includes the following steps: Step 1: Edit the configuration information module, where users define the core verification parameters, including the DUT top-level file path, the test platform generation directory, and UVM component configuration; Step 2: Execute the script execution command to start the script execution module; Step 3: Enter the HDLC parsing stage. The HDLC parsing module reads the top-level file of the DUT, extracts interface signals, macro definition parameters and instantiation code of the DUT in the test platform, detects and processes files with the same name, and outputs the parsing result file. Step 4: Build a verification environment. Combine the configuration information and parsing results to generate a complete UVM verification environment, detect existing components and generate only the missing components. Step 5: Simulate and run test cases, call the simulator to compile and verify the environment code, execute test cases and synchronously collect waveforms, functional coverage and simulation logs, and output the verification results.

9. The method for generating an HDLC automatic verification environment according to claim 8, characterized in that, In step three, it is checked whether there is a file with the same name as the parsing result file in the simulation directory; if it exists, the existing file is renamed to a backup file with a timestamp, and then a new parsing result file is output. If it does not exist, the parsing result file will be generated directly; In step four, it is checked whether the UVM component already exists in the simulation directory; if it exists, only the missing component is generated; if it does not exist, all configuration components are generated.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of an automatic verification environment generation method according to any one of claims 8-9.

Images