Test method and device based on verification configuration file, electronic equipment and medium

Abstract

The invention relates to a test method and device based on a verification configuration file, electronic equipment and a medium. The method comprises the steps of generating a verification configuration file in response to a circuit test request in a UVM verification environment; performing Hash calculation on the verification configuration file to obtain a Hash value as a file name of the verification configuration file; storing the verification configuration file to an archiving directory, and determining a storage path of the verification configuration file; generating a simulation log corresponding to the verification configuration file by using the hash value, the storage path and a rerun command constructed by the hash value; and loading the corresponding verification configuration file by utilizing a rerun command carried in a regression test request and utilizing the simulation log to carry out a regression test. The rerun command and the simulation log in the regression test request are used for loading the configuration file to carry out the regression test, so that the problem debugging and testing efficiency is improved, the reproduction time is shortened, the automatic fusion of random testing and directional testing is realized, and the automatic accumulation of test cases is supported.

Description

Technical Field

[0001] This invention relates to the field of circuit technology, and more specifically to testing methods, apparatus, electronic devices, and media based on verification profiles. Background Technology

[0002] Modern digital IC verification commonly employs the UVM (Universal Verification Methodology) constrained random verification methodology. This method automates test vector generation by defining configuration objects (inherited from uvm_object), constraints, and the randomize() function, offering advantages such as high coverage and a high degree of automation.

[0003] In existing technologies, traditional methods rely on random seeds for reproduction, but these seeds often become invalid under different code versions, compilation options, or tool versions. Each simulation generates a separate configuration file (e.g., config.sv), which lacks standardized naming, is prone to duplication, and is difficult to retrieve. A large number of fixed configuration test cases need to be manually written, making it impossible to automatically accumulate valid configurations discovered in random testing. After a problem is discovered, it is difficult to quickly and accurately reproduce the same configuration, resulting in time-consuming debugging and regression testing. Existing solutions (such as fixed seeds, manual targeted testing, and simple configuration dumping) cannot simultaneously solve the core pain points of reproducibility, deduplication storage, automatic accumulation, and one-click rerun, thus limiting verification efficiency and quality. This invention addresses these shortcomings by providing a novel content-hash-based method for managing verification configuration files and performing regression testing. Summary of the Invention

[0004] The purpose of this application is to provide a test method, apparatus, electronic device and medium based on a verification configuration file, which can improve circuit testing capabilities.

[0005] According to a first aspect of the embodiments of this application, a testing method based on a verification configuration file is provided. The method includes: generating a verification configuration file in response to a circuit test request in a UVM verification environment; performing a hash calculation on the verification configuration file to obtain a hash value as the filename of the verification configuration file; storing the verification configuration file in an archive directory and determining the storage path of the verification configuration file; generating a simulation log corresponding to the verification configuration file using the hash value, the storage path, and a rerun command constructed from the hash value; and loading the corresponding verification configuration file using the simulation log and performing regression testing using the rerun command carried in the regression test request.

[0006] Optionally, in response to a circuit test request in the UVM verification environment, a verification configuration file is generated, including: in response to a circuit test request in the UVM verification environment, determining whether the circuit test request carries a rerun command; if there is no rerun command, generating a verification configuration file by using configuration parameters for constraint randomization; if there is a rerun command, loading the corresponding configuration file using the simulation log where the rerun command is located and performing regression testing.

[0007] Optionally, the verification configuration file is stored in an archive directory, and the storage path of the verification configuration file is determined, including: determining whether there is a file with the same name in the archive directory based on the hash value; if not, the verification configuration file is stored in the archive directory, and the storage path of the verification configuration file is determined; if yes, the storage of the verification configuration file is terminated.

[0008] Optionally, the rerun command carried in the regression test request is determined, and the corresponding verification configuration file is loaded using the simulation log to perform regression testing, including: parsing the received regression test request to obtain the rerun command; parsing the rerun command to obtain the hash value; constructing a storage path from a preset archive directory based on the hash value, and loading the verification configuration file to execute the regression test.

[0009] Optionally, constraint randomization is performed using configuration parameters to generate a verification configuration file, including: defining a configuration object class in the integrated circuit verification environment, which inherits from uvm_object; using the SystemVerilog constraint statement in the configuration object class to define the value range of each verification parameter and their mutual constraint relationships; calling the randomize method of the configuration object to generate random configuration parameter values ​​that satisfy all constraints; and serializing the random configuration parameter values ​​and outputting them as an executable SystemVerilog code file as the verification configuration file.

[0010] Optionally, the random configuration parameter values ​​are serialized and output as an executable SystemVerilog code file as a verification configuration file. This includes: calling the sprint method of the configuration object to serialize all fields of the configuration object and their current values ​​into strings in a standard format; parsing the strings to extract the field names and values ​​from each line; generating corresponding SystemVerilog assignment statements based on the field names and values; and writing the assignment statements into a new SystemVerilog file as a verification configuration file to achieve automatic overwriting of the hardware state space.

[0011] Optionally, a hash calculation is performed on the verification configuration file, including: reading the binary content of the verification configuration file completely in binary mode; performing a hash calculation on the read binary content using the MD5 or SHA-256 algorithm to obtain a hash value of fixed length.

[0012] Optionally, the simulation log corresponding to the verification configuration file is generated using the hash value, storage path, and rerun command constructed from the hash value. This includes: after the integrated circuit simulation tool completes the simulation, opening the simulation log file and navigating to the end of the file; writing the hash value, storage path, and rerun command to the end of the file; and closing and saving the simulation log file.

[0013] Optionally, before generating a verification configuration file in response to a circuit test request in the UVM verification environment, the method further includes: checking during the compilation phase whether the macro LOAD_CFG_FILE is defined; if defined, executing the include to load the verification configuration file specified by the macro value; if not defined, executing the randomize() method of the configuration object and serializing to generate a new verification configuration file.

[0014] According to a second aspect of the embodiments of this application, an electronic device is provided, including a memory and a processor, wherein the memory is used to store a computer program executable by the processor; and the processor is used to execute the computer program in the memory to implement the method described above.

[0015] According to a third aspect of the embodiments of this application, a computer program product is provided, wherein the computer program in the computer program product, when executed, is capable of implementing the above-described method. The computer program product may include a computer-readable storage medium on which the aforementioned computer program is stored, and the executable computer program in the storage medium can be executed by a processor to implement the above-described method.

[0016] The beneficial effects of this application are as follows: by generating a verification configuration file in response to a circuit test request and performing hash calculation in the UVM verification environment, the uniqueness and reproducibility of the configuration are ensured; storing it in the archive directory and deduplicating it reduces storage costs and improves retrieval efficiency; generating simulation logs to record hash values, storage paths, and rerun commands establishes a complete traceability chain; and finally, using the rerun command in the regression test request and the simulation log to load the configuration file for regression testing improves the efficiency of problem debugging and testing, such as reducing the reproduction time from several hours to several minutes, realizing the automatic integration of random testing and targeted testing, and supporting the automatic accumulation of test cases. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating a testing method based on a verification configuration file provided in an embodiment of this disclosure.

[0018] Figure 2 This is a flowchart illustrating the verification configuration file generation method provided in an embodiment of this disclosure.

[0019] Figure 3This is a schematic flowchart illustrating the file storage method provided in an embodiment of the present disclosure.

[0020] Figure 4 This is a flowchart illustrating the regression testing method provided in an embodiment of this disclosure.

[0021] Figure 5 This is a flowchart illustrating the verification configuration file generation method provided in an embodiment of this disclosure.

[0022] Figure 6 The diagram shown is a flowchart illustrating a verification configuration file generation method according to an embodiment of this disclosure.

[0023] Figure 7 This is a flowchart illustrating the hash calculation method provided in an embodiment of the present disclosure.

[0024] Figure 8 This is a flowchart illustrating the simulation log generation method provided in an embodiment of this disclosure.

[0025] Figure 9 This is a schematic diagram of the structure of a test device based on a verification configuration file, as proposed in an embodiment of this application.

[0026] Figure 10 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0027] Unless otherwise defined, the technical or scientific terms used in this specification and claims shall have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains. Specific embodiments of the invention will be described below with reference to the accompanying drawings. It should be noted that, in order to provide a concise description, this specification cannot provide a detailed description of all features of the actual embodiments. Without departing from the spirit and scope of the invention, those skilled in the art can make modifications and substitutions to the embodiments of the invention, and the resulting embodiments are also within the protection scope of the invention.

[0028] The implementation process of this solution will be explained below through specific embodiments.

[0029] like Figure 1 This is a flowchart illustrating a testing method based on a verification configuration file provided in an embodiment of this disclosure. Figure 1 As shown, the method includes: Step 101: Generate a verification configuration file in response to a circuit test request in the UVM verification environment.

[0030] In practical applications, in the UVM verification environment, in response to circuit test requests (generally, these requests are made by the user or problems are discovered during the experiment (e.g., during simulation), it is determined whether the circuit test request carries a rerun command. If no rerun command is included, the configuration parameters are used to generate a verification configuration file through constraint randomization. For example, a configuration object class is defined in the integrated circuit verification environment, which inherits from uvm_object; the SystemVerilog constraint statement is used in this configuration object class to define the value range of each verification parameter and their mutual constraints; the randomize() method of the configuration object is called to generate random configuration parameter values ​​that satisfy all constraints; the random configuration parameter values ​​are serialized and output as an executable SystemVerilog code file as the verification configuration file. For example, the sprint() method of the configuration object can be called to serialize all fields of the configuration object and their current values ​​into a standard format string; the string is parsed to extract the field name and field value from each line; the corresponding SystemVerilog assignment statement is generated based on the field name and field value; and the assignment statement is written to a new SystemVerilog file as the verification configuration file. This step automates the generation of verification configuration files, ensures coverage of random tests, and provides a foundation for subsequent hash calculations and storage.

[0031] It's important to note that a UVM (Universal Verification Methodology) environment refers to an integrated circuit functional verification framework based on the Universal Verification Methodology. It's a standardized methodology for building reusable and scalable testbenches to verify the functional correctness of digital IC, ASIC, or SoC designs. This environment typically includes multiple reusable verification components (such as agent, driver, monitor, sequencer, and scoreboard), implemented in SystemVerilog, with defined default configurations to suit specific application scenarios.

[0032] Step 102: Perform a hash calculation on the verification configuration file to obtain a hash value, which is then used as the filename of the verification configuration file.

[0033] The entire binary content of the verification configuration file is read in binary mode. The read binary content is then hashed using either MD5 or SHA-256 algorithms to obtain a fixed-length hash value, which is used as the filename of the verification configuration file. For example, the hashlib.md5() function in a Python script can be used to calculate a 32-character hexadecimal hash value. This step ensures the unique identifier of the verification configuration file (i.e., the filename), unaffected by code version or environment, thus implementing content addressing technology.

[0034] Step 103: Store the verification configuration file in the archive directory and determine the storage path of the verification configuration file.

[0035] The system checks if a file with the same filename exists in the archive directory based on its hash value. If no filename exists, the verification configuration file is stored in the archive directory, and its storage path is determined. If a filename exists, storage of the verification configuration file is terminated because there is no need to store it again. For example, Python's `os.path.exists()` function checks if a file with the hash value already exists in the archive directory. If not, `shutil.copy2()` is used to copy and store the file, constructing the storage path as a combination of the archive directory and the hash value (e.g., `archive_dir / hash_value`). This step automatically removes duplicates, saves storage space, and provides path information for subsequent log generation and loading.

[0036] In an optional implementation, the content addressing technology described in steps 102 and 103 of the figure is specifically implemented at the software level as follows: First, in a Python or other scripting environment, file I / O operations are used to read the contents of the verification configuration file in binary mode, ensuring consistency across operating systems (such as Windows and Linux) and avoiding hash differences caused by possible encoding conversions in text mode. Specifically, a software module (such as the compute_config_hash function) opens the file path and reads the complete byte stream as the input data stream. Then, a standard hash library (such as hashlib.md5 or hashlib.sha256) is called to perform a one-way hash operation on the byte stream, generating a fixed-length (128 bits for MD5, 256 bits for SHA-256) hash digest as a unique content identifier. This hash value is directly used as the storage address: a filename is constructed in the archive directory (such as archive_dir + ' / ' + hash_value), and the existence of a file with the same name is checked through file system APIs (such as os.path.exists and shutil.copy2). If it does not exist, the original file is atomically copied to achieve content-level deduplication. This software significantly improves the efficiency of computer storage systems: in large-scale verification projects, content addressing avoids redundant file accumulation, reduces disk I / O operations by 30%-50%, and improves retrieval speed (O(1) time complexity for file location). Furthermore, this mechanism integrates seamlessly with the UVM framework, passing hash paths via the +define macro during the compilation phase, supporting dynamic loading without modifying the verification code. This solves the technical bottleneck of unreproducible configuration in traditional verification environments, providing a concrete improvement to computer functionality.

[0037] Step 104: Use the hash value, storage path, and rerun command constructed from the hash value to generate the simulation log corresponding to the verification configuration file.

[0038] After the integrated circuit simulation tool completes the simulation, open the simulation log file and navigate to the end of the file. Write the hash value, storage path, and rerun command at the end of the file. Close and save the simulation log file. The rerun command is constructed from the hash value, for example, in the format "-cfg [hash value]". For instance, you can use Python's `open()` function in append mode ('a') to write to the log, formatted as a hash value, storage path (e.g., ` / proj / verification / archive / [hash value]`) enclosed in separators, along with the rerun command. This step establishes traceable configuration information, allowing users to intuitively obtain necessary details from the log to support subsequent regression testing.

[0039] Step 105: Use the rerun command carried in the regression test request to load the corresponding verification configuration file using the simulation log to perform regression testing.

[0040] The regression test request mentioned here can be a user-submitted request or an automatically triggered regression test request when a problem occurs during testing. The received regression test request is parsed to obtain the rerun command; the rerun command is used to find the hash value and storage path of the verification configuration file in the simulation log; the corresponding verification configuration file is loaded based on the hash value and storage path to execute the regression test. For example, the user copies the rerun command (e.g., -cfg3a5) from the previous simulation log and includes it in the regression test request; after parsing, the argparse library is used to process the command-line arguments, constructing +define+LOAD_CFG_FILE=[storage path] and passing it to the simulator; the verification configuration file is loaded at compile time via the include directive to achieve accurate reproduction. This step enables configuration reuse and fast regression, supporting batch testing, such as traversing hash value files in the archive directory.

[0041] Based on the publicly available solutions described above, by generating verification configuration files in response to circuit test requests and performing hash calculations in the UVM verification environment, the uniqueness and reproducibility of the configuration are ensured; storing them in the archive directory and deduplicating them reduces storage costs and improves retrieval efficiency; generating simulation logs to record hash values, storage paths, and rerun commands establishes a complete traceability chain; finally, using the rerun commands in the regression test request and the simulation logs to load the configuration files for regression testing improves problem debugging and testing efficiency, for example, reducing reproduction time from several hours to several minutes, achieving automatic integration of random and targeted testing, and supporting automatic accumulation of test cases.

[0042] In one or more embodiments of this disclosure, such as Figure 2 This is a flowchart illustrating the verification configuration file generation method provided in an embodiment of this disclosure. Figure 2 As shown, step 101, generating a verification configuration file in response to a circuit test request in the UVM verification environment, includes: step 201, in response to a circuit test request in the UVM verification environment, determining whether the circuit test request carries a rerun command; step 202, if there is no rerun command, generating the verification configuration file using constraint randomization based on configuration parameters; step 203, if there is a rerun command, loading the corresponding configuration file using the simulation log where the rerun command is located to perform regression testing.

[0043] Specifically, upon receiving a circuit test request, a command-line argument parsing tool (such as Python's argparse library) checks for the presence of a specific parameter flag, such as "-cfg" followed by a hash value. This flag identifies the rerun command. This step is the starting point for the branch in the verification configuration file generation process, ensuring that the appropriate configuration source is selected based on the request type. For example, the `parse_config_args` function parses command-line arguments; if the "-cfg" parameter is detected, it indicates the presence of a rerun command; otherwise, it indicates a new test mode. This mechanism enables flexible switching of the verification process, avoiding unnecessary random generation overhead.

[0044] If no command rerun is performed, a configuration object class is defined in the UVM verification environment, inheriting from `uvm_object`. Within this configuration object class, SystemVerilog's `constraint` statement defines the value ranges of each verification parameter and their inter-constraint relationships. The `randomize()` method of the configuration object is called to generate random configuration parameter values ​​that satisfy all constraints. These random configuration parameter values ​​are then serialized and output as an executable SystemVerilog code file as the verification configuration file. For example, in the random mode of the `CFG_RAND` macro, `m_cfg.randomize()` is called to generate the configuration, and then the parameters are serialized using UVM's `sprint()` method via the `export_config()` function. After parsing, assignment statements are generated and written to the `config.sv` file. This step utilizes constraint randomization technology to automatically explore test scenarios, improve coverage, and simultaneously provide a newly generated verification configuration file for subsequent hash calculations and storage.

[0045] If a rerun command is available, extract the command (e.g., "-cfg [hash value]") from the simulation log, parse the command to obtain the hash value, construct a storage path based on the hash value and a preset archive directory, and include the verification configuration file during compilation using a conditional compilation mechanism (e.g., +define +LOAD_CFG_FILE=[storage path]), thus loading the configuration and executing regression tests. For example, in the log information recorded by the append_hash_to_log function, the user can copy the rerun command from the end of the log; then process the command in parse_config_args, dynamically construct the compilation definition and pass it to the simulator to ensure accurate reproduction of historical configurations. This step supports rapid problem reproduction and batch regression testing, such as traversing hash value files in the archive directory for testing.

[0046] Based on the above-mentioned publicly available solution, by responding to circuit test requests in the UVM verification environment to determine whether a rerun command is carried, seamless branching switching between the new test mode and the regression test mode is achieved. If there is no rerun command, the configuration parameters are used to generate a verification configuration file through constraint randomization, ensuring high coverage and automation of random testing. If there is a rerun command, the simulation log containing the rerun command is used to load the corresponding verification configuration file for regression testing, reducing reproduction costs, realizing the automatic fusion of random testing and targeted testing, and establishing a traceable chain of configuration.

[0047] In one or more embodiments of this disclosure, such as Figure 3 This is a flowchart illustrating a file storage method provided in an embodiment of this disclosure. Figure 3 As shown, storing the verification configuration file in the archive directory and determining the storage path of the verification configuration file includes: Step 301: Determining whether there is a file with the same name in the archive directory based on the hash value. Step 302: If not, storing the verification configuration file in the archive directory and determining the storage path of the verification configuration file. Step 303: If yes, terminating the storage of the verification configuration file.

[0048] Using the hash value as a potential filename, a file system checking tool queries the archive directory to see if a file with that hash value already exists. This step performs content-level duplicate detection, ensuring that only unique configurations are stored. For example, in the `archive_config_by_hash` function, after calculating the hash value using `compute_config_hash`, `archive_file = os.path.join(archive_dir, hash_value)` is constructed, and then `os.path.exists(archive_file)` is used to check if a file with the same name exists, thus avoiding redundant storage.

[0049] If the determination result indicates that there is no filename with the same name in the archive directory, the verification configuration file is copied to the archive directory, and the storage path is defined as a combination of the archive directory path and the hash value. This step completes the actual archiving of the configuration and generates path information that can be used for subsequent loading. For example, if os.path.exists(archive_file) returns False, shutil.copy2(config_file_path, archive_file) is used to copy the configuration file, and the returned hash_value is used as a component of the path. The storage path is such as archive_dir / hash_value, supporting centralized configuration repository management.

[0050] If the determination result indicates that the same filename already exists in the archive directory, no copying operation is performed, and the storage process ends directly. However, the existing hash value can still be returned to support subsequent steps such as log recording. This step prevents the accumulation of duplicate files and optimizes storage resource usage. For example, in the `archive_config_by_hash` function, if `os.path.exists(archive_file)` returns `True`, the `shutil.copy2` operation is not performed; only the `hash_value` is returned, ensuring that verification configuration files with the same content are stored only once, thus implementing an automatic deduplication mechanism.

[0051] As mentioned above, automatic deduplication technology leverages the uniqueness of hash values ​​to check if a file with the same name already exists in the archive directory before storing the verification configuration file, achieving content-level deduplication. In the specific software implementation, the hash value is first calculated, and then `os.path.exists(archive_dir + ' / ' + hash_value)` is used to query the file system. If the file does not exist, it is atomically copied using `shutil.copy2()`; if it exists, the copying is skipped, and the existing hash value is returned directly. This mechanism ensures that the same configuration is stored only once, saving disk space. Example: In the `archive_config_by_hash` function, `hash_value = compute_config_hash(config_file_path); archive_file = os.path.join(archive_dir, hash_value); if not os.path.exists(archive_file):shutil.copy2(config_file_path, archive_file)`. This supports centralized configuration libraries and is suitable for multi-user sharing scenarios. Compared to existing technologies, such as simple dump configurations or manual copying solutions, the lack of an automatic deduplication mechanism leads to directory chaos and wasted storage (e.g., duplicate files account for 40% of total storage). Automatic deduplication solves these shortcomings. Experiments show that in 1000 simulations, the deduplication rate reaches 40%, I / O operations are reduced by 30%, and management is simplified without manual intervention, thus improving the efficiency of large-scale verification projects.

[0052] Based on the publicly available solution, automatic deduplication detection of the verification configuration file is achieved by determining whether there is a file with the same name in the archive directory based on the hash value. If not, the verification configuration file is stored in the archive directory and the storage path of the verification configuration file is determined, ensuring reliable archiving of the unique configuration. If so, the storage of the verification configuration file is terminated, avoiding redundant storage, thereby significantly reducing storage costs and improving storage efficiency.

[0053] In one or more embodiments of this disclosure, such as Figure 4 This is a schematic flowchart of the regression testing method provided in an embodiment of this disclosure. Figure 4 As shown, the rerun command carried in the regression test request is determined, and the corresponding verification configuration file is loaded using the simulation log to perform regression testing, including: Step 401: Parsing the received regression test request to obtain the rerun command. Step 402: Parsing the rerun command to obtain the hash value. Step 403: Constructing a storage path from a preset archive directory based on the hash value, and loading the verification configuration file to execute the regression test.

[0054] In practical applications, upon receiving a regression test request (usually triggered by a user or automatically triggered when an error occurs during testing), a parameter parsing tool is used to scan the command-line arguments in the request, identifying and extracting the portion containing the rerun command, such as detecting the "-cfg" flag and its following value. This step ensures that the command information used for configuration reproduction is accurately isolated from the request. For example, in the `parse_config_args` function, `argparse.ArgumentParser` is used to parse the command-line arguments; if the '-cfg' parameter is detected, its value is extracted as the rerun command, supporting parameter pass-through and compatibility with other compilation options.

[0055] The extracted rerun commands undergo string processing or parameter splitting to directly extract the embedded hash values, such as separating the hash value string from "-cfg [hash value]". This step converts the commands into actionable configuration identifiers, ensuring the accuracy of subsequent loading. For example, in the `parse_config_args` function, `args.cfg` is parsed to obtain the hash value, and then the existence of the corresponding file is verified. If it does not exist, the process exits, ensuring the validity of the hash value.

[0056] The complete storage path is formed by concatenating the hash value with a preset archive directory (such as the path specified by the environment variable CONFIG_ARCHIVE_DIR); the existence of the file under the path is checked, and if it exists, the path is passed through the compilation definition, and the verification configuration file is loaded in the simulation environment to execute the test. This step enables rapid configuration reproduction and supports batch or targeted regression testing. For example, in the parse_config_args function, config_file = os.path.join(archive_dir, args.cfg) is constructed, and then +define+LOAD_CFG_FILE=[config_file] is generated and passed to the simulator; in the loading mode of the CFG_RAND macro, the verification configuration file is included through the include directive to achieve accurate reproduction and support scenarios such as traversing hash values ​​in batch regression scripts.

[0057] As can be seen from the above-mentioned publicly available solution, by parsing the received regression test request to obtain the rerun command, the accuracy of request processing is ensured; parsing the rerun command to obtain the hash value provides a quick extraction of the configuration identifier; based on the hash value, a storage path is constructed from the preset archive directory, and the verification configuration file is loaded to execute the regression test, realizing one-click reproduction of the configuration and efficient regression, which greatly improves the efficiency of problem debugging.

[0058] In one or more embodiments of this disclosure, such as Figure 5 This is a flowchart illustrating the verification configuration file generation method provided in an embodiment of this disclosure. Figure 5 As shown, the verification configuration file is generated by constraint randomization using configuration parameters, including: Step 501: Defining a configuration object class in the integrated circuit verification environment, which inherits from uvm_object. Step 502: Using the SystemVerilog constraint statement in the configuration object class to define the value range of each verification parameter and their mutual constraint relationships. Step 503: Calling the randomize() method of the configuration object to generate random configuration parameter values ​​that satisfy all constraints. Step 504: Serializing the random configuration parameter values ​​and outputting them as an executable SystemVerilog code file as the verification configuration file.

[0059] In the integrated circuit verification environment, configuration object classes are created using the SystemVerilog language, and standard UVM framework functionalities such as field registration and serialization support are utilized by inheriting from uvm_object. This step provides the infrastructure for subsequent constraint definition and randomization. For example, the env_config class inherits from uvm_object and uses the uvm_object_utils_begin macro to register fields such as data_width and addr_width, ensuring that configuration parameters are randomizable and serializable.

[0060] Add a `constraint` block to the configuration object class to specify the randomization range, distribution weights, and dependencies between parameters for each validation parameter (such as integer, bit width, or enumeration type). For example, the `constraint` statement ensures that the sum of certain parameters does not exceed a specific value. This step guides the randomization process to generate valid test configurations and avoids invalid combinations. For instance, defining fields such as `rand`, `int`, and `data_width` in the configuration object class and using the `constraint` statement to define their value ranges and inter-constraint relationships supports the core mechanism of constrained randomization.

[0061] After instantiating the configuration object, its `randomize()` method is called. This method automatically solves for and assigns random values ​​that meet the conditions to each validation parameter based on predefined constraint statements. If the solution fails, an error is reported. This step achieves automated random generation of configurations, improving test coverage. For example, in the random mode of the `CFG_RAND` macro, calling `if(!m_cfg.randomize()) `uvm_fatal...` generates random configuration parameter values ​​that meet the constraints, ensuring the validity and diversity of the configuration.

[0062] The serialization mechanism provided by UVM converts all parameter values ​​of the configuration object into string format, then parses and generates SystemVerilog assignment statements, which are written to a file to form directly includeable code. This step transforms random configuration into a persistent file, supporting subsequent reuse and archiving. For example, in the `export_config()` function, `this.sprint()` is called to serialize the configuration object, and after parsing the output, an assignment statement such as `m_cfg.data_width = 32;` is generated and written to the `config.sv` file as a verification configuration file, achieving automatic export.

[0063] Based on the publicly available solution described above, a configuration object class is defined in the integrated circuit verification environment. This class inherits from uvm_object and provides a standard UVM-compatible structure. The `constraint` statement in SystemVerilog is used in this configuration object class to define the value range of each verification parameter and their inter-constraint relationships, ensuring effective guidance for randomization. The `randomize()` method of the configuration object is called to generate random configuration parameter values ​​that satisfy all constraints, achieving high-coverage automated testing. The random configuration parameter values ​​are serialized and output as an executable SystemVerilog code file as the verification configuration file, supporting configuration persistence and reuse.

[0064] In one or more embodiments of this disclosure, such as Figure 6 The diagram illustrates a flowchart of a verification configuration file generation method according to an embodiment of this disclosure. The step of serializing the random configuration parameter values ​​and outputting them as an executable SystemVerilog code file as the verification configuration file includes: Step 601: Calling the `sprint()` method of the configuration object to serialize all fields of the configuration object and their current values ​​into a standard format string. Step 602: Parsing the string and extracting the field names and values ​​from each line. Step 603: Generating corresponding SystemVerilog assignment statements based on the field names and values. Step 604: Writing the assignment statements into a new SystemVerilog file as the verification configuration file to achieve automatic overwriting of the hardware state space.

[0065] In practical applications, after the configuration object is instantiated and randomized, its `sprint()` method is called. This method is a standard function provided by the UVM framework, used to convert all registered fields and their values ​​of the object into a printable string format, typically output in tabular or key-value pair form. This step achieves the initial serialization of configuration parameters, facilitating subsequent parsing. For example, in the `export_config()` function, the temporary log file `temp_config.log` is first opened, and then `$fwrite(temp_log, this.sprint())` is called to serialize the configuration object into a standard format string, skipping the header information printed by UVM to extract the pure field data.

[0066] The serialized string is scanned line by line, using string matching or formatted reading methods to separate field names (such as parameter names) and corresponding field values ​​(such as specific numerical values ​​or statuses) from each line. This step ensures accurate extraction of parameter information and avoids errors from manual encoding. For example, in the `export_config()` function, `temp_config.log` is reopened for reading, and the header is skipped using `repeat (HEADER_LINES) $fgets(line, temp_log)`. Then, a `while (!$feof(temp_log))` loop and `$fscanf(temp_log, "%s %` are used to read the data. The function s %s", param_name, param_value) parses each line and extracts the field name and field value.

[0067] For each extracted field name and value, a SystemVerilog-compatible assignment expression is constructed, such as "m_cfg.[field name] = [field value];", to form an executable code snippet. This step transforms abstract parameters into actual code, allowing direct loading in the validation environment. For example, in the export_config() function, $fwrite(cfg_file, "m_cfg.%s = %s;\n", param_name, param_value) generates assignment statements based on the extracted data, ensuring that the generated code is applicable to any configuration class that inherits from uvm_object.

[0068] All generated assignment statements are enclosed in a begin...end block and written to a SystemVerilog file named config.sv or another specified name. This file can be directly loaded via the include directive, thus automatically overwriting the state space in hardware verification. This step completes the persistent output of the configuration, supporting subsequent reuse and regression testing. For example, in the export_config() function, a file header such as " / / Auto-generated configuration\nbegin\n" is written first, then all assignment statements are appended, and finally "end\n" is written and the file is closed, achieving automatic overwriting of the hardware state space, such as the statement m_cfg.data_width = 32; in the example.

[0069] In one or more embodiments of this disclosure, by calling the sprint() method of the configuration object, all fields of the configuration object and their current values ​​are serialized into a standard format string, achieving efficient initial data conversion; parsing the string and extracting the field names and values ​​from each line ensures accurate parameter capture; generating corresponding SystemVerilog assignment statements based on the field names and values ​​automates the code building process; and writing the assignment statements into a new SystemVerilog file as the verification configuration file enables automatic overwriting of the hardware state space, avoiding manual coding errors and improving verification efficiency.

[0070] The following conditional compilation mechanism enables a unified switch between random generation and file loading: (a) During the compilation phase, it checks whether the macro LOAD_CFG_FILE is defined; (b) If LOAD_CFG_FILE is defined, it executes include "the file path specified by LOAD_CFG_FILE" to directly load the pre-stored verification configuration file; (c) If LOAD_CFG_FILE is not defined, it executes the randomize() method of the configuration object and the serialization generation process in sequence to automatically generate a new verification configuration file; thus, it achieves seamless switching between the two modes and accurate reproduction of hardware verification parameters without modifying any verification code.

[0071] In practical applications, during the SystemVerilog compilation process, conditional compilation directives (such as `ifdef`) are used to check whether the macro `LOAD_CFG_FILE` is defined via compilation options (such as `+define`). This macro indicates whether the configuration source is file loading or random generation. This step serves as the entry point for the switching mechanism, ensuring that the configuration generation mode is dynamically determined based on external parameters. For example, the `CFG_RAND` macro uses the `ifdef LOAD_CFG_FILE` directive to check for the macro's existence during the compilation phase, thereby enabling flexible determination of the configuration source.

[0072] If the macro LOAD_CFG_FILE is already defined (usually carrying a file path), the include directive is used to directly include the verification configuration file from the specified path into the code, loading the pre-stored configuration without randomization. This step supports the reproduction of historical configurations, avoiding the overhead of regenerating the configuration. For example, in the CFG_RAND macro loading mode, executing `include "LOAD_CFG_FILE"` directly loads the verification configuration file from the archive directory, such as archive_dir / hash_value, supporting a one-click rerun mechanism.

[0073] If the macro LOAD_CFG_FILE is not defined, the randomize() method of the configuration object is first called to generate random configuration parameter values ​​based on the constraint statement. Then, the serialization process is executed (such as calling sprint() to parse and generate assignment statements), and finally, a new verification configuration file is output. This step realizes the automated generation of random test configurations, supporting improved coverage. For example, in the random mode of the CFG_RAND macro, if(!m_cfg.randomize()) `uvm_fatal... then m_cfg.export_config() is called to generate a config.sv file as a new verification configuration file through serialization.

[0074] Based on the publicly available solution, dynamic detection of the configuration mode is achieved by checking whether the macro LOAD_CFG_FILE is defined during the compilation phase. If LOAD_CFG_FILE is defined, the `include "file path specified by LOAD_CFG_FILE"` method is executed to directly load the pre-stored verification configuration file, ensuring rapid reproduction of historical configurations. If LOAD_CFG_FILE is not defined, the randomize() method of the configuration object is executed sequentially to serialize and generate a new verification configuration file, supporting the coverage advantage of random testing. Thus, seamless switching between the two modes and accurate reproduction of hardware verification parameters are achieved without modifying any verification code.

[0075] In one or more embodiments of this disclosure, such as Figure 7 This is a flowchart illustrating the hash calculation method provided in an embodiment of this disclosure. Figure 7 As shown, hashing the verification configuration file includes: Step 701: Reading the complete binary content of the verification configuration file in binary mode. Step 702: Performing a hash operation on the read binary content using either MD5 or SHA-256 algorithms to obtain a fixed-length hash value.

[0076] In practical applications, before calculating the hash, the verification configuration file is opened in binary mode ('rb') using a file read function. This ensures that the content remains unchanged across platforms due to line break conversions or encoding differences, guaranteeing that the same configuration produces identical hash results on different operating systems or environments. For example, in the `compute_config_hash` function, the binary content of the verification configuration file is read completely in binary mode using `with open(config_file_path, 'rb') as f: file_content = f.read()`, avoiding platform dependencies that might be introduced by text mode.

[0077] The read complete binary data is input into a hash algorithm to calculate a fixed-length digest value (MD5 is 128 bits (16 bytes), outputting 32 hexadecimal characters; SHA-256 is 256 bits (32 bytes), outputting 64 hexadecimal characters). This value uniquely corresponds to the file content; if the file content is exactly the same, the hash value will be the same, and vice versa. This step implements content-based addressing. For example, in the same function, `hash_value = hashlib.md5(file_content).hexdigest()` can be used to perform an MD5 hash operation on the read binary content to obtain a fixed-length hash value. Alternatively, `hashlib.sha256()` can be used for a more secure hash calculation.

[0078] Based on the above-mentioned publicly available solution, by fully reading the binary content of the verification configuration file in binary mode, the cross-platform consistency and stability of hash calculation are ensured, and misjudgments caused by differences in text encoding or newline characters are avoided. The read binary content is hashed using MD5 or SHA-256 algorithms to obtain a fixed-length hash value, which realizes true content addressing identification, making the configuration identifier completely independent of code version, random seed, and compilation environment.

[0079] In one or more embodiments of this disclosure, such as Figure 8 This is a flowchart illustrating the simulation log generation method provided in this embodiment. The method generates a simulation log corresponding to the verification configuration file using a hash value, a storage path, and a rerun command constructed from the hash value. The steps include: Step 801: After the integrated circuit simulation tool completes the simulation, open the simulation log file for this simulation and navigate to the end of the file. Step 802: Write the hash value, storage path, and rerun command to the end of the file. Step 803: Close and save the simulation log file.

[0080] In practical applications, after the entire simulation process is completed, the simulation log file generated by the current simulation is immediately opened in append mode. This automatically positions the write position at the end of the file, ensuring that the original log content is completely preserved and is not overwritten or truncated. For example, the append_hash_to_log function uses this append method to open the simulation log file, ensuring that each write is appended to the existing log.

[0081] Write the following information in a clear and readable format: a separator line, the hash value itself, the complete storage path of the verification configuration file, and the rerun command directly constructed from the hash value (typically in the form of "-cfg hash value"). Include necessary explanatory text so that engineers can easily identify and copy it. For example, first write a set of prominent separator lines and a title, then write the hash value, the complete storage path in the archive directory, and the complete rerun command prompt, thus forming a standardized traceability information block.

[0082] After writing the above information, close the file to ensure that all appended content is correctly flushed and permanently saved to disk. For example, the simulation log file can be finally saved by automatically closing the file handle after file operations are completed.

[0083] Based on the publicly available solutions described above, the simulation log file is immediately opened and appended to the end of the file after the integrated circuit simulation tool completes the simulation, ensuring the continuity and integrity of the log. Writing the hash value, storage path, and rerun command to the end of the file provides intuitive and standardized traceability information. Closing and saving the simulation log file ensures that the traceability information is permanently retained. For example, by simply opening any simulation log (e.g., in the case of a verification error), the recorded rerun command can be directly copied for one-click accurate reproduction, eliminating the need to remember or search for other information. This significantly shortens the time for problem localization and regression testing, establishing a complete closed-loop traceability chain from problem discovery to configuration reproduction, and significantly improving debugging efficiency, regression testing efficiency, and team collaboration.

[0084] In one or more embodiments of this disclosure, before generating a verification configuration file in response to a circuit test request in the UVM verification environment, the method further includes: checking whether the macro LOAD_CFG_FILE is defined during the compilation phase; if it is defined, executing the include macro value to load the verification configuration file; if it is not defined, executing the randomize() method of the configuration object and serializing it to generate a new verification configuration file.

[0085] During the SystemVerilog compilation process, conditional compilation directives (such as `ifdef`) are used to check whether the macro `LOAD_CFG_FILE` is defined via compilation options (such as `+define`). This macro indicates whether the configuration source is file loading or random generation. This step serves as a mechanism for switching configuration generation modes, ensuring that the configuration source is dynamically determined based on external parameters. For example, the `CFG_RAND` macro uses the `ifdef LOAD_CFG_FILE` directive to check for its existence during the compilation phase, thus enabling flexible determination of the configuration source.

[0086] If the macro LOAD_CFG_FILE is already defined (usually carrying a file path as its value), the include directive is used to directly include the verification configuration file specified by the macro value into the code, thus loading the pre-stored configuration without randomization. This step supports the reproduction of historical configurations, avoiding the overhead of regenerating the configuration. For example, in the CFG_RAND macro loading mode, executing `include "LOAD_CFG_FILE"` directly loads the verification configuration file from the archive directory, such as archive_dir / hash_value, supporting a one-click rerun mechanism.

[0087] If the macro LOAD_CFG_FILE is not defined, the randomize() method of the configuration object is first called to generate random configuration parameter values ​​based on the constraint statement. Then, the serialization process is executed (such as calling sprint() to parse and generate assignment statements), and finally, a new verification configuration file is output. This step automates the generation of random test configurations, supporting improved coverage. For example, in the random mode of the CFG_RAND macro, if(!m_cfg.randomize()) `uvm_fatal... then m_cfg.export_config() is called to generate a config.sv file as the new verification configuration file through serialization.

[0088] Based on the publicly available solutions described above, dynamic detection of configuration modes is achieved by checking whether the macro LOAD_CFG_FILE is defined during the compilation phase. If it is defined, the verification configuration file specified by the macro value is loaded via include, ensuring rapid reproduction of historical configurations. If it is not defined, the randomize() method of the configuration object is executed and a new verification configuration file is serialized, supporting the coverage advantage of random tests. For example, it maintains code consistency in the verification environment, achieves seamless switching between random generation and file loading, reduces maintenance costs, and integrates random and targeted tests.

[0089] Following the same approach, this application also proposes a testing device based on a verification configuration file. For example... Figure 9 This is a schematic diagram of a testing device based on a verification configuration file, as proposed in an embodiment of this application. Figure 9 As can be seen, the device includes: The first generation module 91 is used to generate a verification configuration file in response to a circuit test request in the UVM verification environment.

[0090] The calculation module 92 is used to perform a hash calculation on the verification configuration file and obtain a hash value as the file name of the verification configuration file.

[0091] The determination module 93 is used to store the verification configuration file to the archive directory and determine the storage path of the verification configuration file.

[0092] The second generation module 94 is used to generate the simulation log corresponding to the verification configuration file using the hash value, the storage path, and the rerun command constructed from the hash value.

[0093] Test module 95 is used to perform regression testing by loading the corresponding verification configuration file using the simulation log and the rerun command carried in the regression test request.

[0094] The first generation module 91 is used to respond to the circuit test request in the UVM verification environment, determine whether the circuit test request carries a rerun command; if there is no rerun command, it uses the configuration parameters to perform constraint randomization to generate a verification configuration file; if there is a rerun command, it uses the simulation log where the rerun command is located to load the corresponding configuration file for regression testing.

[0095] The determination module 93 is used to determine whether there is a file with the same name in the archive directory based on the hash value; if not, the verification configuration file is stored in the archive directory and the storage path of the verification configuration file is determined; if yes, the storage of the verification configuration file is terminated.

[0096] The determination module 93 is used to parse the received regression test request to obtain the rerun command; parse the rerun command to obtain the hash value; construct the storage path from the preset archive directory based on the hash value, and load the verification configuration file to execute the regression test.

[0097] The second generation module 94 is used to define a configuration object class in the integrated circuit verification environment. This class inherits from uvm_object. In this configuration object class, the systemVerilog constraint statement is used to define the value range of each verification parameter and their mutual constraint relationship. The randomize method of the configuration object is called to generate random configuration parameter values ​​that satisfy all constraints. The random configuration parameter values ​​are serialized and output as an executable SystemVerilog code file as the verification configuration file.

[0098] The second generation module 94 is used to call the sprint method of the configuration object to serialize all fields of the configuration object and their current values ​​into a standard format string; parse the string to extract the field name and field value in each line; generate the corresponding SystemVerilog assignment statement based on the field name and field value; and write the assignment statement into a new SystemVerilog file as a verification configuration file to achieve automatic overwriting of the hardware state space.

[0099] The calculation module 92 is used to read the binary content of the verification configuration file in binary mode; and to perform a hash operation on the read binary content using the MD5 or SHA-256 algorithm to obtain a hash value of fixed length.

[0100] The second generation module 94 is used to open the simulation log file and position itself at the end of the file after the integrated circuit simulation tool completes the simulation; write the hash value, storage path and rerun command at the end of the file; and close and save the simulation log file.

[0101] Embodiments of this application also propose an electronic device, including a processor and a memory; the memory is used to store a computer program executable by the processor; the processor is used to execute the computer program in the memory to implement the test method based on the verification profile described in any of the above embodiments.

[0102] Embodiments of this application also propose a computer-readable storage medium that, when an executable computer program in the storage medium is executed by a processor, enables the testing method based on a verification configuration file as described in any of the above embodiments.

[0103] Regarding the apparatus in the above embodiments, the specific manner in which the processor performs the operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0104] Figure 10 This is a block diagram illustrating an electronic device according to an exemplary embodiment. For example, electronic device 900 may be provided as a server. (Refer to...) Figure 10 The device 900 includes a processing component 922, which further includes one or more processors, and memory resources represented by memory 932 for storing instructions, such as application programs, that can be executed by the processing component 922. The application programs stored in memory 932 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 922 is configured to execute instructions to perform the aforementioned test methods based on a verification profile.

[0105] Device 900 may also include a power supply component 926 configured to perform power management of device 900, a wired or wireless network interface 950 configured to connect device 900 to a network, and an input / output (I / O) interface 958. Device 900 can operate on an operating system stored in memory 932, such as Windows Server™, MacOS X™, Unix™, Linux™, FreeBSD™, or similar.

[0106] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 932 including instructions, which can be executed by a processing component 922 of the device 900 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0107] In this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The term "multiple" refers to two or more unless otherwise expressly defined.

[0108] The above description of the embodiments is intended to enable those skilled in the art to understand and apply this application. It will be apparent to those skilled in the art that various modifications can be easily made to these embodiments, and the general principles described herein can be applied to other embodiments without creative effort. Therefore, this application is not limited to the embodiments described herein, and any improvements and modifications made by those skilled in the art based on the disclosure of this application without departing from the scope and spirit of this application are within the scope of this application.

Claims

1. A testing method based on a verification configuration file, characterized in that, The method includes: Generate verification configuration files in response to circuit test requests in the UVM verification environment; Perform a hash calculation on the verification configuration file, and use the hash value as the filename of the verification configuration file; Store the verification configuration file in the archive directory and determine the storage path of the verification configuration file; The simulation log corresponding to the verification configuration file is generated using the hash value, the storage path, and the rerun command constructed from the hash value. Using the rerun command carried in the regression test request, the corresponding verification configuration file is loaded using the simulation log to perform regression testing.

2. The testing method based on a verification configuration file according to claim 1, characterized in that, In the UVM verification environment, a verification configuration file is generated in response to a circuit test request, including: In the UVM verification environment, in response to a circuit test request, determine whether the circuit test request carries a rerun command; If the rerun command is not available, the verification configuration file is generated using constraint randomization based on the configuration parameters. If the rerun command is available, the corresponding configuration file is loaded using the simulation log containing the rerun command to perform regression testing.

3. The testing method based on a verification configuration file according to claim 1, characterized in that, The step of storing the verification configuration file to the archive directory and determining the storage path of the verification configuration file includes: Based on the hash value, determine whether there is a file with the same name in the archive directory; If not, the verification configuration file is stored in the archive directory, and the storage path of the verification configuration file is determined. If so, then the storage of the verification configuration file will be terminated.

4. The testing method based on a verification configuration file according to claim 1, characterized in that, The determination of the rerun command carried in the regression test request, and the use of the simulation log to load the corresponding verification configuration file for regression testing, includes: The received regression test request is parsed to obtain the rerun command; Parse the rerun command to obtain the hash value; Based on the hash value, a storage path is constructed from a preset archive directory, and the verification configuration file is loaded to perform regression testing.

5. The testing method based on a verification configuration file according to claim 2, characterized in that, The step of generating the verification configuration file by constraining randomization using configuration parameters includes: Define a configuration object class in the integrated circuit verification environment, which inherits from uvm_object; In this configuration object class, the SystemVerilog constraint statement is used to define the value range of each verification parameter and their mutual constraints. Call the randomize method of the configuration object to generate random configuration parameter values ​​that satisfy all constraints; The random configuration parameter values ​​are serialized and output as an executable SystemVerilog code file as the verification configuration file.

6. The testing method based on a verification configuration file according to claim 5, characterized in that, The step of serializing the random configuration parameter values ​​and outputting them as an executable SystemVerilog code file as the verification configuration file includes: Call the sprint method of the configuration object to serialize all fields of the configuration object and their current values ​​into a standard format string; Parse the string and extract the field names and values ​​from each row; Generate corresponding SystemVerilog assignment statements based on the field names and field values; Write the assignment statement into a new SystemVerilog file as the verification configuration file.

7. The testing method based on a verification configuration file according to claim 1, characterized in that, The hash calculation of the verification configuration file includes: Read the complete binary content of the verification configuration file in binary mode; The read binary content is hashed using either MD5 or SHA-256 algorithms to obtain a hash value of fixed length.

8. The testing method based on a verification configuration file according to claim 1, characterized in that, The step of generating the simulation log corresponding to the verification configuration file using the hash value, the storage path, and the rerun command constructed from the hash value includes: After the integrated circuit simulation tool completes the simulation, open the simulation log file and navigate to the end of the file; Write the hash value, the storage path, and the rerun command at the end of the file; Close and save the simulation log file.

9. The method according to claim 1, characterized in that, Before generating a verification configuration file in response to a circuit test request in the UVM verification environment, the following is also included: During the compilation phase, check whether the macro LOAD_CFG_FILE is defined; If defined, the verification configuration file specified by the include load macro value will be executed; If not defined, the randomize() method of the configuration object is executed and a new verification configuration file is generated by serialization.

10. A test apparatus based on a verification configuration file, suitable for integrated circuit functional verification environments, characterized in that, include: The first generation module is used to generate a verification configuration file in response to a circuit test request in the UVM verification environment. The calculation module is used to perform a hash calculation on the verification configuration file and obtain a hash value as the file name of the verification configuration file; The determination module is used to store the verification configuration file to the archive directory and determine the storage path of the verification configuration file; The second generation module is used to generate simulation logs corresponding to the verification configuration file using the hash value, the storage path, and the rerun command constructed from the hash value. The testing module is used to perform regression testing by loading the corresponding verification configuration file using the simulation logs and the rerun command carried in the regression test request.

11. An electronic device comprising a processor and a memory, the memory storing at least one instruction, at least one program, code set, or instruction set, the at least one instruction, at least one program, code set, or instruction set being loaded and executed by the processor to implement the method according to any one of claims 1 to 9.

12. A computer program product, characterized in that, When the computer program is executed, it can implement the method of any one of claims 1 to 9.

Images