Address translation module verification method and device, electronic equipment, storage medium and program product

Abstract

The present disclosure relates to the field of chip verification, and particularly relates to a verification method and device of an address conversion module, an electronic device, a storage medium and a program product. The verification method comprises: generating a verification scenario file of a verification scenario according to an intellectual property (IP) module verification environment and an excitation of the address conversion module in the verification scenario, wherein the verification scenario file at least indicates configuration information and reference information of the verification scenario; and performing verification of the address conversion module based on a system on chip (SoC) verification environment and the verification scenario file. The verification method of the present disclosure enables system-level verification and module-level verification of the address conversion module to reuse the same verification scenario file, without manual configuration, thereby improving configuration accuracy and verification efficiency, and being applicable to verification of large-scale complex scenarios.

Description

Technical Field

[0001] This disclosure relates to the field of chip verification, and in particular to a verification method, apparatus, electronic device, storage medium, and program product for an address translation module. Background Technology

[0002] Chip verification is a critical step in ensuring that the chip's functions and performance meet design requirements. Typically, module-level verification is performed first, followed by system-level verification after the module-level verification is passed. This layered and hierarchical approach ensures the functional correctness, performance compliance, and reliability of the chip design, gradually identifying various defects from basic functional modules to complex system integration, and ultimately ensuring that the chip can stably meet application requirements after mass production and delivery.

[0003] The Address Mapping Translation (AMT) module is a hardware module on a System-on-Chip (SoC). Its core function is to optimize the address mapping efficiency of the SoC's Network-on-Chip (NoC), supporting address hashing, interleaving, memory channel selection, and access priority control based on Quality of Service (QoS). Existing technologies, after completing module-level verification of the AMT, require manual adjustment of the configuration related to the AMT during system-level verification, reducing configuration accuracy and verification efficiency, making it difficult to apply to large-scale, complex verification scenarios. Summary of the Invention

[0004] In view of this, this disclosure proposes a verification method, apparatus, electronic device, storage medium, and program product for an address translation module. The verification method of this disclosure enables the reuse of the same verification scenario file for system-level and module-level verification of the address translation module, eliminating the need for manual configuration, improving configuration accuracy and verification efficiency, and can be applied to verification of large-scale, complex scenarios.

[0005] According to one aspect of this disclosure, a verification method for an address translation module is provided, the method comprising: generating a verification scenario file for the verification scenario based on an intellectual property (IP) module verification environment and the excitation of the address translation module in a verification scenario, wherein the verification scenario file at least indicates configuration information and reference information of the verification scenario; and performing verification of the address translation module based on the system-on-chip (SoC) verification environment and the verification scenario file.

[0006] In one possible implementation, the verification of the address translation module based on the SoC verification environment and the verification scenario file includes: inputting reference information corresponding to the verification scenario into the SoC reference model to obtain a reference value of the address translation result of the address translation module; determining the output value of the address translation result of the address translation module according to the configuration information corresponding to the verification scenario; and determining whether the verification of the verification scenario passes based on a comparison between the reference value and the output value.

[0007] In one possible implementation, determining whether the verification of the verification scenario passes based on a comparison between the reference value and the output value includes: determining that the verification of the verification scenario passes when the reference value and the output value are consistent; and determining that the verification of the verification scenario fails when the reference value and the output value are inconsistent.

[0008] In one possible implementation, the method further includes: constructing a component for outputting the verification scenario file, the component being configured to: determine multiple variables used for verifying the address translation module based on the code of the address translation module, encapsulate the multiple variables into a class; and constrain the multiple variables in the class for the verification scenario to generate the verification scenario file.

[0009] In one possible implementation, the component is further configured to detect whether any abnormal operation occurs during the generation process of the verification scenario file.

[0010] In one possible implementation, the method further includes: defining the format of the verification scenario file; providing the calling interface function used by the address transformation module to perform address transformation; formatting and verifying the configuration information and reference information; creating the verification scenario file, and writing the formatted and verified configuration information and reference information into the verification scenario file.

[0011] In one possible implementation, the intellectual property (IP) module verification environment is a verification environment for IP modules, and the SoC verification environment includes multiple IP modules and interconnection channels between the multiple IP modules.

[0012] In one possible implementation, the verification scenario includes multiple different verification scenarios, wherein the verification scenario is associated with at least one or more of the following: the hardware structure of the address translation module, the constraints for generating the verification scenario file, the hashing method of the address translation module, the interleaving enable granularity of the address translation module, and the test requirements.

[0013] In one possible implementation, the verification scenario file includes a file based on a first programming language and a file based on a second programming language corresponding to the verification scenario, wherein the file based on the first programming language indicates the configuration information and the file based on the second programming language indicates the reference information.

[0014] According to another aspect of this disclosure, a verification apparatus for an address translation module is provided. The apparatus includes: a first verification module, configured to generate a verification scenario file for the verification scenario based on an intellectual property (IP) module verification environment and the excitation of the address translation module in a verification scenario, wherein the verification scenario file at least indicates configuration information and reference information of the verification scenario; and a second verification module, configured to perform verification of the address translation module based on a system-on-a-chip (SoC) verification environment and the verification scenario file.

[0015] In one possible implementation, the verification of the address translation module based on the SoC verification environment and the verification scenario file includes: inputting reference information corresponding to the verification scenario into the SoC reference model to obtain a reference value of the address translation result of the address translation module; determining the output value of the address translation result of the address translation module according to the configuration information corresponding to the verification scenario; and determining whether the verification of the verification scenario passes based on a comparison between the reference value and the output value.

[0016] In one possible implementation, determining whether the verification of the verification scenario passes based on a comparison between the reference value and the output value includes: determining that the verification of the verification scenario passes when the reference value and the output value are consistent; and determining that the verification of the verification scenario fails when the reference value and the output value are inconsistent.

[0017] In one possible implementation, the apparatus is used to construct a component for outputting the verification scenario file, the component being configured to: determine multiple variables used for verifying the address translation module based on the code of the address translation module, encapsulate the multiple variables into a class; and constrain the multiple variables in the class for the verification scenario to generate the verification scenario file.

[0018] In one possible implementation, the component is further configured to detect whether any abnormal operation occurs during the generation process of the verification scenario file.

[0019] In one possible implementation, the apparatus is further configured to: define the format of the verification scenario file; provide the calling interface function used by the address transformation module to perform address transformation; format and verify the configuration information and reference information; create the verification scenario file, and write the formatted and verified configuration information and reference information into the verification scenario file.

[0020] In one possible implementation, the intellectual property (IP) module verification environment is a verification environment for IP modules, and the SoC verification environment includes multiple IP modules and interconnection channels between the multiple IP modules.

[0021] In one possible implementation, the verification scenario includes multiple different verification scenarios, wherein the verification scenario is associated with at least one or more of the following: the hardware structure of the address translation module, the constraints for generating the verification scenario file, the hashing method of the address translation module, the interleaving enable granularity of the address translation module, and the test requirements.

[0022] In one possible implementation, the verification scenario file includes a file based on a first programming language and a file based on a second programming language corresponding to the verification scenario, wherein the file based on the first programming language indicates the configuration information and the file based on the second programming language indicates the reference information.

[0023] According to another aspect of this disclosure, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the above-described method.

[0024] According to another aspect of this disclosure, a non-volatile computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the above-described method.

[0025] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the above-described method.

[0026] According to the verification method of the address translation module in this disclosure, a verification scenario file is generated based on the IP module verification environment and the stimulus of the address translation module in the verification scenario. The verification scenario file at least indicates the configuration information and reference information of the verification scenario. Verification of the address translation module is performed based on the system-on-chip (SoC) verification environment and the verification scenario file. This method enables the reuse of the same verification scenario file for system-level and module-level verification of the address translation module, eliminating the need for manual configuration, improving configuration accuracy and verification efficiency, and can be applied to verification of large-scale complex scenarios.

[0027] The verification method disclosed in this embodiment addresses the problems of low scenario reusability, high environment setup costs, difficulty in simulating complex and diverse scenarios, and difficulty in locating simulation failures in traditional verification strategies. It enables rapid generation of diverse stimuli for SoCs, comprehensively simulates various complex scenarios, and covers various operating states of address translation modules in large-scale SoCs, making verification more thorough and ensuring the stability of the chip architecture under different operating conditions. It solves problems such as syntax errors, logical loopholes, incomplete scenario coverage, and incorrect parameter configuration that easily occur when manually writing verification test cases / scenario code. This method can quickly reuse module-level verification scenarios for system-level verification, and can quickly identify problems in the address translation module and provide feedback to the design team. It also solves the problem of difficulty in locating scenario errors (rather than insufficient scenario quantity) caused by limited scenario generation methods in large-scale SoC chip verification.

[0028] Design teams can adjust and optimize chip designs in a timely manner based on verification results, reducing the time cost of repeated verification and modification. Compared with traditional verification methods, this significantly shortens the chip design-to-mass production cycle, accelerates chip launch, and enhances the company's competitiveness in the market.

[0029] The verification method of this disclosure standardizes the design of verification scenario files during the module-level verification stage, allowing the verification scenario files produced in the module-level verification stage to be directly reused in the system-level verification stage. This establishes a scenario reuse link between module-level and system-level verification, avoiding the duplication of similar scenario writing in the system-level verification stage, while ensuring the compatibility, configurability, and traceability of the verification scenario files. It retains the integrity of the scenarios produced in the module-level verification stage while adapting to the bus topology, address mapping, and multi-module concurrency characteristics of the system-on-a-chip (SoC). This significantly reduces the development cost and cycle time of SoC verification, ensures the consistency and correctness of the address translation module function at the SoC level, improves the coverage and effectiveness of SoC system-level scenarios, and optimizes the management and traceability of SoC verification.

[0030] Other features and aspects of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0031] The accompanying drawings, which are included in and form part of this specification, illustrate exemplary embodiments, features, and aspects of this disclosure together with the specification and serve to explain the principles of this disclosure.

[0032] Figure 1 An exemplary application scenario of the verification method of the address translation module according to an embodiment of the present disclosure is shown.

[0033] Figure 2A schematic diagram illustrating the flow of a verification method for an address translation module according to an embodiment of the present disclosure is shown.

[0034] Figure 3 This diagram illustrates the verification process of an address translation module based on a system-on-a-chip (SoC) verification environment and verification scenario file, according to an embodiment of this disclosure.

[0035] Figure 4 This diagram illustrates the interaction between the IP module verification environment and the SoC verification environment of the address translation module according to an embodiment of the present disclosure.

[0036] Figure 5 A schematic diagram showing the structure of a verification device for an address translation module according to an embodiment of the present disclosure is provided.

[0037] Figure 6 A block diagram of an electronic device 1900 according to an embodiment of the present disclosure is shown. Detailed Implementation

[0038] Various exemplary embodiments, features, and aspects of this disclosure will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0039] As used herein, the terms “comprising,” “including,” “having,” or variations thereof are open-ended and include one or more of the stated features, integrals, elements, steps, components, or functions, but do not exclude the presence or addition of one or more other features, integrals, elements, steps, components, functions, or groups thereof.

[0040] When an element is referred to as “connected,” “coupled,” “responding,” or a variation thereof relative to another element, it may be directly connected, coupled, or responding to another element, or there may be an intermediate element present.

[0041] Although the terms first, second, third, etc., may be used herein to describe various elements / operations, these elements / operations should not be limited by these terms. These terms are only used to distinguish one element / operation from another. Therefore, without departing from the teachings of the inventive concept, a first element / operation in some embodiments may be referred to as a second element / operation in other embodiments.

[0042] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0043] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0044] It should be noted that all information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this application are with the consent of the user or with the full consent of all parties, and the collection, use and processing of the relevant data shall comply with the relevant laws, regulations and standards of the relevant regions.

[0045] The configuration process for AMT is divided into three parts: "basic control configuration", "hash configuration", and "extended function configuration".

[0046] 1. Basic control configuration, including the following steps:

[0047] Log identifier: Prints the "AMT configuration started" log, indicating that module configuration has started.

[0048] Read old configuration: If broadcast mode is not enabled, read the old configuration value of the AMT base address stored in the register. If the read fails (reading 0), return an error directly.

[0049] Print old configuration: Outputs the old configuration value of AMT in hexadecimal format for easy comparison of configuration changes before and after.

[0050] The core control configuration (executed only when the amt_enable signal is true) compares the new configuration value with the old configuration value, and updates the register storing the old configuration value only when they are inconsistent, avoiding redundant write operations. The parameters to be compared include:

[0051] Interleaving: Controls whether addresses are interleaved across channels, which can improve bandwidth. Old configuration values ​​are stored in the AMT_ITLV_ENABLE field and can be updated using the field setting function (set_field_value).

[0052] Double Data Rate (DDR) mode selection: can switch between DDR4 and DDR5 modes, and the old configuration value is stored in the AMT_DDR_MODE field.

[0053] DDR Channel Selection: Specifies the DDR physical channel to use. The old configuration value is stored in the AMT_DDR_CH field.

[0054] Interleaving mode selection: Specifies the interleaving mode to use.

[0055] 2. Hash configuration, including the following steps:

[0056] Channel hash configuration: Its core function is to distribute address mapping and avoid congestion in a single channel.

[0057] Address Hash Configuration: Similar to Channel Hash Configuration, it is used to optimize the mapping from addresses to physical storage.

[0058] 3. Configure extended functions, such as virtual address mode, access attribute overriding (port / cachate / QoS), DDR channel disabling and remapping, outstanding limit for incomplete transactions, etc.

[0059] The traditional verification strategy for address translation modules is as follows: During the system-level verification phase, the core configuration parameters are inherited from the module-level verification phase. For different scenarios, the configuration of the address translation module is manually adjusted to adapt to the SoC's system-level address space, bus protocol, and resource constraints. This upgrades the "module-level configuration" of the address translation module to a "system-schedulable configuration," ensuring that the functional performance of the address translation module under system-level verification is consistent with that under module-level verification. Its disadvantages are as follows:

[0060] First, the verification environment has low reusability and high setup cost: The goal of module-level verification is to "exhaustively explore the functional boundaries of a single module," therefore, the verification environment for module-level verification (Intellectual Property (IP) module verification environment) is highly customized. The core goal of system-level verification, however, is to "verify the system-level behavior of interconnected multi-modules." This requires the system-level verification environment (SoC verification environment) to have global collaborative capabilities. Therefore, components in the IP module verification environment (used for scene generation, etc.) and files output by the IP module verification environment (including configuration information, etc.) are difficult to directly adapt to the SoC verification environment, resulting in low reusability. A significant amount of manpower is required to set up the SoC verification environment and adjust the configuration of the address translation module within it. However, the configuration adjustment methods differ across scenarios. Relying entirely on manual adjustments will increase workload and increase the possibility of configuration errors, while also affecting the accuracy of the files provided for system-level verification.

[0061] Second, it is difficult to simulate complex and diverse scenarios: In large-scale SoCs, the address translation module operates in a variety of complex scenarios. For example, in the case of data transmission between chips, the address translation module needs to translate the address of its own chip to the address of another chip. Traditional verification strategies have limited methods for generating scenarios, making it difficult to accurately simulate these complex scenarios. This results in potential problems of the chip under special conditions not being fully detected, and the reliability and stability of the chip architecture in actual operation cannot be fully verified.

[0062] Third, problem localization is difficult: In the verification of large-scale SoCs, the traditional verification strategies have limited means of generating scenarios, which may lead to errors such as logical contradictions, constraint conflicts or disconnection from the behavior of real systems. This makes it impossible to accurately verify the function of modules, and may result in misjudgment or omission of problems, making problem localization difficult.

[0063] In view of this, this disclosure proposes a verification method, apparatus, electronic device, storage medium, and program product for an address translation module. The verification method of this disclosure enables the reuse of the same verification scenario file for system-level and module-level verification of the address translation module, eliminating the need for manual configuration, improving configuration accuracy and verification efficiency, and can be applied to verification of large-scale, complex scenarios.

[0064] Furthermore, the verification method of this disclosure can simulate complex and diverse scenarios, quickly locate problems, overcome the shortcomings of existing verification methods such as low verification efficiency, poor accuracy, and incomplete scenario coverage, achieve more comprehensive and accurate verification, ensure the reliability and stability of the chip in complex working environments, and accelerate the chip verification iteration cycle.

[0065] Figure 1 An exemplary application scenario of the verification method of the address translation module according to an embodiment of the present disclosure is shown.

[0066] like Figure 1 As shown, the verification platform includes an IP module verification environment 100 and a SoC verification environment 200. The verification of the address translation module includes a module-level verification stage and a system-level verification stage. The processor executes the verification method of this embodiment, first performing module-level verification on the address translation module in the module-level verification stage, and then performing system-level verification on the address translation module in the system-level verification stage.

[0067] Figure 2 A schematic diagram illustrating the flow of a verification method for an address translation module according to an embodiment of the present disclosure is shown.

[0068] like Figure 2 As shown, in one possible implementation, the address translation method includes steps S21 and S22.

[0069] Step S21: Based on the verification environment of the intellectual property IP module and the excitation of the address transformation module in the verification scenario, generate a verification scenario file for the verification scenario, wherein the verification scenario file at least indicates the configuration information and reference information of the verification scenario.

[0070] Step S22: Verify the address translation module based on the SoC verification environment and verification scenario file.

[0071] For example, stimuli for the address translation module in the verification scenario can be pre-generated in the IP module verification environment. If there are multiple verification scenarios, stimuli for each scenario are generated separately. The stimuli can indicate the configuration information of the verification scenario, including scenario type, parameters, status, etc., such as hash mode, DDR size, and PCIe mode. This disclosure does not limit the generation method or specific content of the stimuli.

[0072] Step S21 is a step performed during the module-level verification phase, which includes generating a verification scenario file based on the IP module verification environment and the stimulus of the address translation module in the verification scenario. The verification scenario file at least indicates the configuration information and reference information of the verification scenario, where the reference information is the address translation result when the address translation module is functioning normally, which can be used for data comparison.

[0073] In one example, when generating the verification scenario file, the stimulus can be input into the IP module verification environment, and the IP module verification environment can output the verification scenario file. This disclosure does not limit the execution details of step S21. Exemplary implementations of step S21 are given below.

[0074] Step S22, performed during the system-level verification phase, includes verifying the address translation module based on the on-chip system (SoC) verification environment and verification scenario file. In other words, the verification scenario file obtained during the module-level verification phase is reused to complete the system-level verification of the address translation module.

[0075] In one example, when verifying the address translation module, a verification scenario file can be input into the SoC verification environment, and the SoC verification environment can output the verification results. This disclosure does not limit the execution details of step S22. Exemplary implementations of step S22 are given below.

[0076] This disclosure does not limit the content and format of the verification scenario file, as long as the verification scenario file can indicate the configuration information and reference information of the verification scenario and can be directly reused in the system-level verification stage.

[0077] According to the verification method of the address translation module in this disclosure, a verification scenario file is generated based on the IP module verification environment and the stimulus of the address translation module in the verification scenario. The verification scenario file at least indicates the configuration information and reference information of the verification scenario. Verification of the address translation module is performed based on the system-on-chip (SoC) verification environment and the verification scenario file. This method enables the reuse of the same verification scenario file for system-level and module-level verification of the address translation module, eliminating the need for manual configuration, improving configuration accuracy and verification efficiency, and can be applied to verification of large-scale complex scenarios.

[0078] In one possible implementation, the intellectual property (IP) module verification environment is a verification environment for IP modules. The SoC verification environment includes multiple IP modules and interconnection channels between the multiple IP modules.

[0079] The IP module verification environment is used at the module level to verify the internal functionality of the IP modules. The SoC verification environment, on the other hand, verifies the internal functionality of the IP modules and the communication between them, ensuring they function correctly. Therefore, the SoC verification environment includes multiple IP modules and the interconnection channels between them.

[0080] In one possible implementation, the verification scenario includes multiple different verification scenarios, wherein the verification scenario is associated with at least one or more of the following: the hardware structure of the address translation module, the constraints for generating the verification scenario file, the hashing method of the address translation module, the interleaving enable granularity of the address translation module, and the test requirements.

[0081] The purpose of designing verification scenarios is to verify the address translation module. Therefore, verification scenarios can be related to at least one of the following: the hardware structure of the address translation module, its hashing method, and the interleaving enable granularity. The address translation module includes multiple functions, and the purpose of designing verification scenarios may be to verify only some of these functions; therefore, verification scenarios can be related to test requirements. Verification scenario files must be generated and used during the verification process; therefore, verification scenarios can be related to the constraints used to generate these files.

[0082] In this way, more accurate and comprehensive verification scenarios can be constructed.

[0083] The verification method of this disclosure can simulate complex and diverse verification scenarios, quickly locate problems, overcome the shortcomings of existing verification methods such as low verification efficiency, poor accuracy, and incomplete scenario coverage, achieve more comprehensive and accurate verification, ensure the reliability and stability of chips in complex working environments, and accelerate the chip verification iteration cycle.

[0084] In one possible implementation, the verification method also includes:

[0085] Construct a component for outputting the verification scenario file. The component is configured to: determine multiple variables used to verify the address transformation module based on the address transformation module code, encapsulate the multiple variables into a class; and constrain the multiple variables in the class for the verification scenario to generate the verification scenario file.

[0086] For example, a component for outputting verification scenario files can be constructed within the IP module verification environment. This component can determine multiple variables used for verifying the address translation module based on its code, encapsulating these variables into classes to avoid information fragmentation. These variables may include enabling information, hashing methods, and interleaved enabling granularity. While the same variables may be used in different scenarios, the constraints on these variables differ across scenarios, resulting in potentially different values ​​for the same variable in different scenarios.

[0087] Classes can be inherited and reused. For each scenario, components can constrain multiple variables in a class to generate a validation scenario file, which can also be inherited and reused.

[0088] This disclosure does not limit the implementation details of the components, as long as the components can achieve the above functions.

[0089] In one possible implementation, the verification scenario file includes a file based on a first programming language and a file based on a second programming language corresponding to the verification scenario, wherein the file based on the first programming language indicates configuration information and the file based on the second programming language indicates reference information.

[0090] In one example, the verification scenario files include files based on a first programming language and files based on a second programming language, corresponding to the verification scenario. The file based on the first programming language indicates configuration information, and the file based on the second programming language indicates reference information. This disclosure does not limit the specific types of the first and second programming languages. For example, the first programming language can be C, and the file based on the first programming language can be a C file. The second programming language can be SV, and the file based on the second programming language can be an SV file. Those skilled in the art will understand that in practical applications, the number of verification scenario files and the corresponding programming language types can be set according to the languages ​​and verification methods supported by the SoC verification environment.

[0091] The SoC verification environment uses an SoC reference model for verification. The SV file is an stimulus file in SV language, recording reference information and serving as input to the SoC reference model. The SoC reference model is a model with SoC functionality, simulated based on SoC code. The C file is a C language firmware file, recording configuration information for the verification scenario. Each verification scenario corresponds to one SV file and one C file.

[0092] In one possible implementation, the verification method includes:

[0093] Define the format of the verification scenario file;

[0094] Provides the calling interface functions used by the address translation module for address translation;

[0095] Format and validate the configuration and reference information;

[0096] Create a verification scenario file and write the formatted and verified configuration information and reference information into the verification scenario file.

[0097] For example, in order to enable the verification scenario files to be directly reused by the SoC verification environment, the following method was designed to generate the verification scenario files.

[0098] The format of the validation scenario file can be defined. As mentioned above, the definable validation scenario file includes files based on a first programming language and files based on a second programming language. The settings for the first and second programming languages ​​have been described above and will not be repeated here.

[0099] The system can provide the API call functions used by the address translation module for address translation. In this case, the IP module verification environment and the SoC verification environment only depend on the declaration of the API call functions; modifications within the address translation module will not affect the verification environment.

[0100] It can format and validate configuration information and reference information to determine whether the format of configuration information and reference information meets the validation requirements and whether it is valid.

[0101] You can create a verification scenario file and write the configuration and reference information that has passed formatting and verification into the verification scenario file.

[0102] In one example, when constructing a component to generate a verification scenario file, the component may include a configuration layer, an interface layer, a data processing layer, and a file operation layer. The configuration layer can be used to define the format of the scenario file. The interface layer can be used to provide the calling interface functions used by the address translation module for address translation. The data processing layer can be used to format and validate configuration and reference information. The file operation layer can be used to create the verification scenario file, writing the formatted and validated configuration and reference information into the verification scenario file.

[0103] In one possible implementation, the component is also configured to detect whether any abnormal operations occur during the generation process of the verification scenario file.

[0104] For example, the component can also be used to detect whether any abnormalities occur during the generation process of the verification scenario file (such as insufficient access permissions, a full disk, etc.). For instance, the component includes an exception handling layer to detect any abnormal operations during the generation process of the verification scenario file. When an abnormal operation is detected, it is reported to prevent the verification process from being interrupted. Furthermore, exception handling functionality can be added based on possible exceptions. In this case, if a handleable exception is detected, it can be handled directly without reporting.

[0105] This disclosure does not limit the functionality of the components. For example, the components can also be configured to perform other file operations (which can be implemented by the file operation layer), such as closing scene files, handling file permissions, and overwriting file data. The requirement is that the components can output reusable verification scene files based on the configuration and reference information.

[0106] In one possible implementation, step S22 includes:

[0107] Input the reference information corresponding to the verification scenario into the SoC reference model to obtain the reference value of the address transformation result of the address transformation module;

[0108] The output value of the address transformation result of the address transformation module is determined based on the configuration information corresponding to the verification scenario;

[0109] The verification of the scenario is determined by comparing the reference value and the output value.

[0110] Figure 3 This diagram illustrates the verification process of an address translation module based on a system-on-a-chip (SoC) verification environment and verification scenario file, according to an embodiment of this disclosure.

[0111] like Figure 3 As shown, step S22 includes steps S221-S223.

[0112] In step S221, the reference information corresponding to the verification scenario is input into the SoC reference model to obtain the reference value of the address transformation result of the address transformation module. The reference information is directly parsed, called, and executed by the SoC reference model, and the SoC reference model can output the reference value of the address transformation result of the address transformation module based on the reference information.

[0113] In step S222, the output value of the address transformation result of the address transformation module is determined according to the configuration information corresponding to the verification scenario. For example, a verification scenario can be generated according to the configuration information corresponding to the verification scenario, the address transformation can be completed in the verification scenario, and the output value of the address transformation result of the address transformation module can be obtained.

[0114] If the address translation module functions normally, the output value and the reference value should be consistent. Therefore, step S223 can be executed to determine whether the verification of the verification scenario passes based on the comparison between the reference value and the output value.

[0115] This approach enables a seamless connection between the IP module verification environment and the SoC reference model for stimulus / verification.

[0116] In one possible implementation, step S223 includes:

[0117] If the reference value and the output value are consistent, the verification of the verification scenario is considered successful.

[0118] If the reference value and the output value are inconsistent, the verification of the verification scenario is determined to have failed.

[0119] If the reference value and the output value are the same, the verification scenario has passed. If the reference value and the output value are different, the verification scenario has failed.

[0120] Figure 4 This diagram illustrates the interaction between the IP module verification environment and the SoC verification environment of the address translation module according to an embodiment of the present disclosure.

[0121] like Figure 4 As shown, in the IP module verification environment 100, configuration information and reference information are input to component 101, and component outputs verification scenario files to SoC verification environment 200. The verification scenario files include file c1 based on the first programming language and file sv1 based on the second programming language.

[0122] In the SoC verification environment 200, reference model 201 can obtain reference value 31 of the address translation result of the address translation module based on file sv1. Based on file c1, verification scenario 202 can be generated in the SoC verification environment 200. Address translation is performed in verification scenario 202, and output value 32 of the address translation result of the address translation module is obtained. Comparing the reference value 31 and the output value 32 determines the verification result 40, which indicates whether the address translation module has passed verification.

[0123] The verification method disclosed in this embodiment addresses the problems of low scenario reusability, high environment setup costs, difficulty in simulating complex and diverse scenarios, and difficulty in locating simulation failures in traditional verification strategies. It enables rapid generation of diverse stimuli for SoCs, comprehensively simulates various complex scenarios, and covers various operating states of address translation modules in large-scale SoCs, making verification more thorough and ensuring the stability of the chip architecture under different operating conditions. It solves problems such as syntax errors, logical loopholes, incomplete scenario coverage, and incorrect parameter configuration that easily occur when manually writing verification test cases / scenario code. This method can quickly reuse module-level verification scenarios for system-level verification, and can quickly identify problems in the address translation module and provide feedback to the design team. It also solves the problem of difficulty in locating scenario errors (rather than insufficient scenario quantity) caused by limited scenario generation methods in large-scale SoC chip verification.

[0124] Design teams can adjust and optimize chip designs in a timely manner based on verification results, reducing the time cost of repeated verification and modification. Compared with traditional verification methods, this significantly shortens the chip design-to-mass production cycle, accelerates chip launch, and enhances the company's competitiveness in the market.

[0125] The verification method of this disclosure standardizes the design of verification scenario files during the module-level verification stage, allowing the verification scenario files produced in the module-level verification stage to be directly reused in the system-level verification stage. This establishes a scenario reuse link between module-level and system-level verification, avoiding the duplication of similar scenario writing in the system-level verification stage, while ensuring the compatibility, configurability, and traceability of the verification scenario files. It retains the integrity of the scenarios produced in the module-level verification stage while adapting to the bus topology, address mapping, and multi-module concurrency characteristics of the system-on-a-chip (SoC). This significantly reduces the development cost and cycle time of SoC verification, ensures the consistency and correctness of the address translation module function at the SoC level, improves the coverage and effectiveness of SoC system-level scenarios, and optimizes the management and traceability of SoC verification.

[0126] This disclosure also proposes a verification device for an address translation module. Figure 5 A schematic diagram showing the structure of a verification device for an address translation module according to an embodiment of the present disclosure is provided.

[0127] like Figure 5 As shown, in one possible implementation, the device includes:

[0128] The first verification module 41 is used to generate a verification scenario file for the verification scenario based on the verification environment of the intellectual property (IP) module and the stimulus of the address transformation module in the verification scenario, wherein the verification scenario file at least indicates the configuration information and reference information of the verification scenario;

[0129] The second verification module 42 is used to perform verification of the address translation module based on the system-on-chip (SoC) verification environment and the verification scenario file.

[0130] In one possible implementation, the verification of the address translation module based on the SoC verification environment and the verification scenario file includes: inputting reference information corresponding to the verification scenario into the SoC reference model to obtain a reference value of the address translation result of the address translation module; determining the output value of the address translation result of the address translation module according to the configuration information corresponding to the verification scenario; and determining whether the verification of the verification scenario passes based on a comparison between the reference value and the output value.

[0131] In one possible implementation, determining whether the verification of the verification scenario passes based on a comparison between the reference value and the output value includes: determining that the verification of the verification scenario passes when the reference value and the output value are consistent; and determining that the verification of the verification scenario fails when the reference value and the output value are inconsistent.

[0132] In one possible implementation, the apparatus is used to construct a component for outputting the verification scenario file, the component being configured to: determine multiple variables used for verifying the address translation module based on the code of the address translation module, encapsulate the multiple variables into a class; and constrain the multiple variables in the class for the verification scenario to generate the verification scenario file.

[0133] In one possible implementation, the component is further configured to detect whether any abnormal operation occurs during the generation process of the verification scenario file.

[0134] In one possible implementation, the apparatus is further configured to: define the format of the verification scenario file; provide the calling interface function used by the address transformation module to perform address transformation; format and verify the configuration information and reference information; create the verification scenario file, and write the formatted and verified configuration information and reference information into the verification scenario file.

[0135] In one possible implementation, the intellectual property (IP) module verification environment is a verification environment for IP modules, and the SoC verification environment includes multiple IP modules and interconnection channels between the multiple IP modules.

[0136] In one possible implementation, the verification scenario includes multiple different verification scenarios, wherein the verification scenario is associated with at least one or more of the following: the hardware structure of the address translation module, the constraints for generating the verification scenario file, the hashing method of the address translation module, the interleaving enable granularity of the address translation module, and the test requirements.

[0137] In one possible implementation, the verification scenario file includes a file based on a first programming language and a file based on a second programming language corresponding to the verification scenario, wherein the file based on the first programming language indicates the configuration information and the file based on the second programming language indicates the reference information.

[0138] In some embodiments, the functions or modules of the apparatus provided in this disclosure can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0139] This disclosure also provides an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the above method.

[0140] This disclosure also provides a non-volatile computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0141] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method.

[0142] Figure 6 A block diagram of an electronic device 1900 according to an embodiment of the present disclosure is shown. For example, the electronic device 1900 may be provided as a server or a terminal device. (Refer to...) Figure 6 The electronic device 1900 includes a processing component 1922, which further includes one or more processors, and memory resources represented by memory 1932 for storing instructions, such as application programs, that can be executed by the processing component 1922. The application programs stored in memory 1932 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 1922 is configured to execute instructions to perform the methods described above.

[0143] Electronic device 1900 may also include a power supply component 1926 configured to perform power management of electronic device 1900, a wired or wireless network interface 1950 configured to connect electronic device 1900 to a network, and an input / output interface 1958 (I / O interface). Electronic device 1900 can operate on an operating system, such as Windows Server, stored in memory 1932. TM Mac OS X TM Unix TM Linux TM FreeBSD TM Or similar.

[0144] In an exemplary embodiment, a non-volatile computer-readable storage medium is also provided, such as a memory 1932 including computer program instructions that can be executed by a processing component 1922 of an electronic device 1900 to perform the above-described method.

[0145] Computer-readable storage media can be tangible devices capable of holding and storing programs / instructions used by instruction execution devices. Computer-readable storage media can be, for example—but not limited to—electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination of the foregoing. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0146] The computer program (or computer-readable program instructions) described herein can be downloaded from a computer-readable storage medium to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage medium in the respective computing / processing device.

[0147] The computer program (or computer program instructions) used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions to implement various aspects of this disclosure.

[0148] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0149] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0150] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0151] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0152] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A verification method for an address translation module, characterized in that, The method includes: Based on the IP module verification environment and the stimulus of the address translation module in the verification scenario, a verification scenario file for the verification scenario is generated, wherein the verification scenario file at least indicates the configuration information and reference information of the verification scenario; The verification of the address translation module is performed based on the system-on-chip (SoC) verification environment and the verification scenario file.

2. The method according to claim 1, characterized in that, The verification of the address translation module based on the SoC verification environment and the verification scenario file includes: The reference information corresponding to the verification scenario is input into the SoC reference model to obtain the reference value of the address transformation result of the address transformation module; The output value of the address transformation result of the address transformation module is determined based on the configuration information corresponding to the verification scenario; The verification of the verification scenario is determined based on the comparison between the reference value and the output value.

3. The method according to claim 2, characterized in that, Determining whether the verification of the verification scenario passes based on a comparison between the reference value and the output value includes: When the reference value and the output value are consistent, the verification of the verification scenario is determined to be successful. When the reference value and the output value are inconsistent, it is determined that the verification of the verification scenario has failed.

4. The method according to claim 1, characterized in that, Also includes: A component for outputting the verification scenario file is constructed. The component is configured to: determine multiple variables used to verify the address transformation module based on the code of the address transformation module, encapsulate the multiple variables into a class; and constrain the multiple variables in the class for the verification scenario to generate the verification scenario file.

5. The method according to claim 4, characterized in that, The component is also configured to: Detect whether any abnormal operations occur during the generation process of the verification scenario file.

6. The method according to claim 1, characterized in that, Also includes: Define the format of the verification scenario file; Provide the calling interface functions used by the address translation module to perform address translation; The configuration information and reference information are formatted and verified; Create the verification scenario file and write the configuration information and reference information that have passed formatting and verification into the verification scenario file.

7. The method according to claim 1, characterized in that, The intellectual property IP module verification environment is a verification environment for IP modules. The SoC verification environment includes multiple IP modules and interconnection channels between multiple IP modules.

8. The method according to claim 1, characterized in that, The verification scenario includes multiple different verification scenarios, wherein the verification scenario is associated with at least one or more of the following: the hardware structure of the address translation module, the constraints for generating the verification scenario file, the hashing method of the address translation module, the interleaving enable granularity of the address translation module, and the test requirements.

9. The method according to claim 1, characterized in that, The verification scenario file includes a file based on a first programming language and a file based on a second programming language corresponding to the verification scenario, wherein the file based on the first programming language indicates the configuration information and the file based on the second programming language indicates the reference information.

10. A verification device for an address translation module, characterized in that, The device includes: The first verification module is used to generate a verification scenario file for the verification scenario based on the verification environment of the intellectual property (IP) module and the stimulus of the address translation module in the verification scenario, wherein the verification scenario file at least indicates the configuration information and reference information of the verification scenario; The second verification module is used to perform verification of the address translation module based on the SoC verification environment and the verification scenario file.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 9.

12. A non-volatile computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

Images