IOMUX verification method based on UVM, verification platform and related equipment

Abstract

The invention provides an IOMUX verification method and platform based on a UVM and related equipment, the method is applied to the IOMUX verification platform, the IOMUX verification platform is connected with a to-be-tested chip, and the method comprises the following steps: analyzing a configuration table file of the to-be-tested chip based on a preset script to construct a plurality of components in a UVM verification environment; the method comprises the following steps: analyzing a configuration table file of a to-be-tested chip through a script, instantiating a plurality of components to capture a plurality of monitoring signals of an IOMUX module in the to-be-tested chip, comparing the plurality of monitoring signals with a generated expected result, and realizing IOMUX verification of the to-be-tested chip according to a comparison result. According to the method, a plurality of components in the UVM verification environment are generated and instantiated, and the UVM framework is combined with the script, so that the establishment process of the verification environment is simplified, the automatic verification process of the IOMUX module is realized, manual intervention can be effectively reduced, and the verification speed is increased.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of integrated circuit design verification, and in particular to a UVM-based IOMUX verification method, verification platform, and related equipment. Background Art

[0002] In integrated circuit design, the IOMUX (input / output multiplexer) module is a key component in the system-on-chip (SoC), responsible for managing the signal transmission between the chip's external pins (PAD) and internal logic. Traditional IOMUX verification methods usually rely on manually writing test stimulus and monitoring scripts, which is not only time-consuming and labor-intensive, but also prone to errors and difficult to cover complex IOMUX configuration scenarios. Especially in modern SoC design, the functions of IOMUX modules are becoming more and more complex, involving a large number of register configurations, signal mappings, and timing requirements. Traditional methods are difficult to ensure the comprehensiveness and accuracy of verification. In addition, as the chip scale increases, the verification workload of the IOMUX module also grows exponentially, bringing huge challenges to verification engineers. Summary of the invention

[0003] The embodiment of the present application provides an IOMUX verification method based on UVM, which can combine the UVM framework with the script, simplify the process of setting up the verification environment, and realize the automated verification process of the IOMUX module, thereby effectively reducing manual intervention and speeding up the verification speed.

[0004] To achieve the above-mentioned purpose, a first aspect of an embodiment of the present application provides an IOMUX verification method based on UVM applied to an IOMUX verification platform, wherein the IOMUX verification platform is connected to a chip to be tested, and the method comprises: parsing a configuration table file of the chip to be tested based on a preset script to construct multiple components in a UVM verification environment; instantiating the multiple components to capture multiple monitoring signals of the IOMUX module in the chip to be tested, and comparing the multiple monitoring signals with the generated expected results, and implementing IOMUX verification of the chip to be tested according to the comparison results.

[0005] In some embodiments, the multiple components include a virtual interface, a Transaction class, a Driver class, a Monitor class, an Agent class, a Reference_Model class, a Scoreboard class, an Environment class, a Configuration class, and a base_test class; wherein the virtual interface is used to capture multiple monitoring signals of the IOMUX module; the Agent class is used to instantiate the Transaction class, the Driver class, and the Monitor class to obtain the multiple monitoring signals from the virtual interface; the Reference_Model class is used to generate expected results; the Scoreboard class is used to compare the multiple monitoring signals with the generated expected results to obtain comparison results; the Environment class is used to instantiate the Agent class, the Reference_Model class, and the Scoreboard class; the Configuration class is used to configure multiple components of the Environment; the base_test class is used to instantiate the Environment class and the Configuration class to implement IOMUX verification of the chip under test according to the comparison results.

[0006] In some embodiments, the instantiation of the multiple components to capture multiple monitoring signals of the IOMUX module in the chip under test includes: instantiating multiple virtual interfaces in the top-level module of the chip under test, each of the virtual interfaces corresponding to the monitoring signals of one or more pins of the chip under test; connecting the name and path information of each of the monitoring signals to the corresponding virtual interface, and ensuring the correct timing of the monitoring signals based on the clock block in each of the virtual interfaces; passing the multiple virtual interfaces to multiple components in the UVM environment to access and operate the multiple monitoring signals based on the multiple components in the UVM environment.

[0007] In some embodiments, the acquiring of the plurality of monitoring signals based on the plurality of components in the UVM environment comprises: instantiating a Transaction class, a Driver class and a Monitor class through the Agent class; generating a test stimulus through the Transaction class; transmitting the test stimulus to the pin of the chip under test through the Driver class and generating a drive signal; and acquiring, through the Monitor class, the monitoring signal generated by the pin of the chip under test according to the test stimulus in response to the drive signal.

[0008] In some embodiments, comparing the multiple monitoring signals with the generated expected results includes: instantiating the Reference_Model class and the Scoreboard class through the Environment class; obtaining the monitoring signals from the monitor class through the Reference_Model class, and generating corresponding expected results according to the number of pins and register configuration of the chip under test; comparing the monitoring signals obtained by the monitor class with the expected results through the Scoreboard class to obtain comparison results.

[0009] In some embodiments, the instantiation of the Transaction class, the Driver class and the Monitor class through the Agent class includes: respectively instantiating the Transaction class, the Driver class and the Monitor class of the IOMUX module and the AMBA module in the chip under test through the Agent class; connecting the Transaction class data corresponding to the Monitor class of the IOMUX module to the Reference_Model class and the Scoreboard class through a broadcast mechanism; connecting the Transaction class data corresponding to the Monitor class of the AMBA module to the Reference_Model class, and connecting the Transaction class data returned by the Reference_Model class to the Scoreboard class.

[0010] In some embodiments, the configuration table file includes a register table and an IO table, and the configuration table file of the chip to be tested is parsed based on a preset script to build multiple components in the UVM verification environment, including: creating a basic script for parsing the table file; creating a register parsing script and an IO parsing script based on the basic script; creating a top-level script, and importing the register parsing script and the IO parsing script into the top-level script as modules respectively; parsing the register table and the IO table based on the top-level script, obtaining the register information and IOMUX mapping information of the chip to be tested, and building multiple components in the UVM verification environment according to the register information and the IOMUX mapping information.

[0011] To achieve the above-mentioned purpose, the second aspect of an embodiment of the present application provides an IOMUX verification platform based on UVM, the IOMUX verification platform is connected to the chip to be tested, and the IOMUX verification platform includes: a script parsing module, which is used to parse the configuration table file of the chip to be tested based on a preset script to construct multiple components in the UVM verification environment; a verification environment module, which is used to instantiate the multiple components to capture multiple monitoring signals of the IOMUX module in the chip to be tested, and compare the multiple monitoring signals with the generated expected results, and implement IOMUX verification of the chip to be tested according to the comparison results.

[0012] To achieve the above-mentioned purpose, a third aspect of an embodiment of the present application provides an electronic device, comprising: at least one processor; at least one memory for storing at least one program; when at least one of the programs is executed by at least one of the processors, an IOMUX verification method based on UVM as described in any one of the first aspects is implemented.

[0013] To achieve the above-mentioned purpose, a fourth aspect of an embodiment of the present application provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are used to execute the UVM-based IOMUX verification method as described in any one of the first aspects.

[0014] The embodiments of the present application provide an IOMUX verification method, verification platform and related equipment based on UVM, which at least include the following beneficial effects: the IOMUX verification method based on UVM is applied to the IOMUX verification platform, and the IOMUX verification platform is connected to the chip to be tested, and the method includes: parsing the configuration table file of the chip to be tested based on a preset script to build multiple components in the UVM verification environment; instantiating multiple components to capture multiple monitoring signals of the IOMUX module in the chip to be tested, and comparing the multiple monitoring signals with the generated expected results, and realizing the IOMUX verification of the chip to be tested according to the comparison results; wherein, it can be understood that the present application can parse the configuration table file of the chip to be tested through a script, generate and instantiate multiple components in the UVM verification environment, combine the UVM framework with the script, simplify the process of building the verification environment, and realize the automated verification process of the IOMUX module, which can effectively reduce manual intervention and speed up the verification speed. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 A method flow chart of an IOMUX verification method based on UVM provided by an embodiment of the present application;

[0016] Figure 2 A schematic diagram of the structure of a verification environment module in a UVM-based IOMUX verification method provided in an embodiment of the present application;

[0017] Figure 3 A flow chart of a method for capturing multiple monitoring signals in a UVM-based IOMUX verification method provided in an embodiment of the present application;

[0018] Figure 4 A flowchart of a method for obtaining multiple monitoring signals in a UVM-based IOMUX verification method provided in an embodiment of the present application;

[0019] Figure 5 A flowchart of a method for comparison in a UVM-based IOMUX verification method provided in an embodiment of the present application;

[0020] Figure 6 A schematic diagram of the structure of a script parsing module in a UVM-based IOMUX verification method provided in an embodiment of the present application;

[0021] Figure 7 A method flow chart of constructing multiple components in a UVM verification environment in a UVM-based IOMUX verification method provided in an embodiment of the present application;

[0022] Figure 8 A schematic diagram of the structure of an electronic device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0023] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0024] In some embodiments, although the functional modules are divided in the system schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the system or the order in the flowchart. The terms first, second, etc. in the specification, claims and the above drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0025] In addition, unless otherwise clearly specified and limited, the term "connected" should be understood in a broad sense. For example, it can be a fixed connection or a movable connection, a detachable connection or a non-detachable connection, or an integral connection; it can be a mechanical connection, an electrical connection, or the two can communicate with each other; it can be a direct connection or an indirect connection through an intermediate medium.

[0026] In the description of the embodiments of the present application, the description of reference terms "one embodiment / implementation", "another embodiment / implementation" or "certain embodiments / implementations", "in the above embodiments / implementations", etc. means that the specific features, structures, materials or characteristics described in combination with the implementation or example are included in at least two embodiments or implementations disclosed in the present application. In the disclosure of this application, the schematic representation of the above terms does not necessarily refer to the same embodiment or implementation. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in an order different from that in the flowchart.

[0027] In integrated circuit design, the IOMUX (input / output multiplexer) module is a key component in the system-on-chip (SoC), responsible for managing the signal transmission between the chip's external pins (PAD) and internal logic. Traditional IOMUX verification methods usually rely on manually writing test stimulus and monitoring scripts, which is not only time-consuming and labor-intensive, but also prone to errors and difficult to cover complex IOMUX configuration scenarios. Especially in modern SoC design, the functions of IOMUX modules are becoming more and more complex, involving a large number of register configurations, signal mappings, and timing requirements. Traditional methods are difficult to ensure the comprehensiveness and accuracy of verification. In addition, as the chip scale increases, the verification workload of the IOMUX module also grows exponentially, bringing huge challenges to verification engineers.

[0028] Based on this, an embodiment of the present application provides an IOMUX verification method based on UVM, which can combine the UVM framework with the script, simplify the process of setting up the verification environment, and realize the automated verification process of the IOMUX module, thereby effectively reducing manual intervention and speeding up the verification speed.

[0029] The embodiments of the present application are further described below in conjunction with the accompanying drawings.

[0030] refer to Figure 1 , Figure 1 A method flow chart of an IOMUX verification method based on UVM provided in an embodiment of the present application; A first aspect of an embodiment of the present application provides an IOMUX verification method based on UVM applied to an IOMUX verification platform, the IOMUX verification platform is connected to a chip to be tested, and the method includes:

[0031] Step S110, parsing the configuration table file of the chip to be tested based on a preset script to construct multiple components in the UVM verification environment;

[0032] Step S120, instantiating multiple components to capture multiple monitoring signals of the IOMUX module in the chip under test, and comparing the multiple monitoring signals with the generated expected results, and implementing IOMUX verification of the chip under test according to the comparison results.

[0033] Among them, it can be understood that the present application can parse the configuration table file of the chip to be tested through a script, generate and instantiate multiple components in the UVM verification environment, combine the UVM framework with the script, simplify the process of setting up the verification environment, and realize the automated verification process of the IOMUX module, which can effectively reduce manual intervention and speed up the verification speed.

[0034] In some embodiments, the IOMUX (Input / Output Multiplier) verification platform is an automated test environment for verifying the functions of the IOMUX module in a system on chip (SoC). In the present application, the platform can be built through a UVM (Universal Verification Methodology) framework, connected to the chip to be tested, and is responsible for generating test stimuli, capturing actual signals, comparing expected results, and outputting a verification report, thereby being able to comprehensively monitor and verify the input and output signals and register configurations of the IOMUX module.

[0035] It is understandable that, in contrast to step S110, in traditional verification methods, the construction of verification environment usually relies on manually written code, which is not only time-consuming and laborious, but also prone to errors. In order to improve efficiency and ensure consistency, the present application introduces a preset script, which is used to automatically parse the configuration table file of the chip to be tested, and automatically generates each component in the UVM verification environment according to the parsing result; wherein, the configuration table file is a file describing the configuration information of the chip to be tested IOMUX module, usually stored in Excel, CSV or XML format, and these files can include the name of the PAD pin of the IOMUX module, path, register configuration, function selection and other information, by parsing the configuration table file, the present application can automatically generate each component code in the UVM verification environment, reduce the workload of manual configuration, and ensure the consistency and accuracy of the verification environment.

[0036] In some embodiments, the plurality of components include a virtual interface, a transaction class, a driver class, a monitor class, an agent class, a reference_model class, a scoreboard class, an environment class, a configuration class, and a base_test class;

[0037] Among them, the virtual interface is used to capture multiple monitoring signals of the IOMUX module;

[0038] The Agent class is used to instantiate the Transaction class, Driver class, and Monitor class to obtain multiple monitoring signals from the virtual interface;

[0039] Reference_Model class, used to generate expected results;

[0040] Scoreboard class, used to compare multiple monitoring signals with the generated expected results to obtain comparison results;

[0041] Envi ronment class, used to instantiate Agent class, Reference_Model class and Scoreboard class;

[0042] Configuration class, used to configure multiple components of the Environment;

[0043] The base_test class is used to instantiate the Environment class and Configuration class to implement IOMUX verification of the chip under test based on the comparison results.

[0044] It can be understood that, compared with step S120, after completing the automated construction of the verification environment, the generated multiple components are instantiated. The instantiation process is to convert the abstract component code into a specific object for use in the verification process. Each component has its specific function and works together to complete the verification of the IOMUX module. The specific process may include:

[0045] Through the instantiated virtual interface, the verification platform can capture multiple monitoring signals of the IOMUX module in real time. Each virtual interface corresponds to one or more PAD signals and contains a clock block (c lockingb lock) to simulate the setup and hold time of the signal driver;

[0046] The Monitor class is responsible for real-time monitoring of signal changes on the PAD, recording the behavior of the PAD at each rising edge of the clock, and storing the captured data in a dynamic array. For register access transactions on the AMBA bus, the Monitor class also parses the register address, data, control signal and other information.

[0047] Generate the expected PAD behavior based on the register configuration and PAD quantity through the Reference_Model class, obtain the actual PAD signal from the Monitor class, and generate the corresponding expected results based on the register configuration. These expected results serve as the reference standard for verification and are used for subsequent comparisons.

[0048] The Scoreboard class compares the actual PAD signal captured by the Monitor class with the expected result generated by the Reference_Model class to obtain a comparison result. If the two are consistent, it means that the IOMUX module is working properly; if they are inconsistent, a warning is issued or marked as a failure to help developers quickly locate the problem.

[0049] The base_test class is responsible for starting the entire verification process and executing specific test cases. It outputs the final verification report based on the comparison results of the Scoreboard class, indicating whether the IOMUX module has passed the verification.

[0050] In summary, the present application can instantiate multiple components so that the verification platform can capture the monitoring signals of the IOMUX module in real time and compare them with the expected results, thereby realizing comprehensive verification of the IOMUX module functions, which not only improves the coverage and accuracy of the verification, but also simplifies the verification process and shortens the product development cycle.

[0051] refer to Figure 2 , Figure 2 A schematic diagram of the structure of the verification environment module in the UVM-based IOMUX verification method provided in one embodiment of the present application; in some embodiments, such as Figure 2 As shown in the figure, multiple components are instantiated and integrated into the verification environment. These components include: Agent of AMBA module and Agent of IOMUX module, Sequencer, Driver, Monitor, Reference_Model and Scoreboard. These components are connected to the chip under test (DUT, Device Under Test) through the virtual interface (Virtua l_Interface). Correspondingly, the specific explanations of multiple components are as follows:

[0052] In some embodiments, a virtual interface can simulate the behavior of a hardware interface in a verification environment, allowing verification components (such as Driver and Monitor classes) to interact with the physical pins of the chip under test, capture and drive signals; in this application, the virtual interface is used to capture multiple monitoring signals of the IOMUX module to ensure that the input, output and enable signals of the IOMUX module can be fully monitored. Each virtual interface corresponds to one or more PAD signals and includes a clock block (clock lock) for simulating the setup and hold time of the signal drive.

[0053] It is understandable that the present application integrates the monitoring signal path and name string in the interface design, dynamically instantiates the corresponding number of interfaces according to the number of monitoring signals, and assigns a unique number to each signal in the top-level design. This design allows other environmental components to directly obtain signal behavior through the number, which is convenient for subsequent real-time comparison.

[0054] In some embodiments, the Transaction class is a data packet class in UVM used to encapsulate test stimulus and response data, which can contain any type of data, such as signal name, bit width, value, etc., and is usually used to transfer information between verification components; in the present application, the Transaction class is used to encapsulate test stimulus and PAD signal monitoring data, and can contain two types of variables: strings are used to store signal names, and dynamic arrays are used to store data to be sent or captured. The default size is 32 bits, but it can be adjusted as needed.

[0055] It is understandable that, through the Transaction class, this application allows users to customize the size of the stimulus data, and provides flexibility in data transmission by sending random single-bit dynamic arrays. Unconstrained dynamic arrays will automatically open up 32 spaces and randomize the single-bit arrays therein to ensure that the data will not be randomized to 0 or 1.

[0056] In some embodiments, the Driver class is a component in UVM used to drive the test stimulus to the chip under test, and is responsible for converting the data in the Transaction class into actual signal drive and transmitting it to the pins of the chip under test; in this application, the Driver class obtains the Transaction class from the environment, and drives the data therein to the PAD of the IOMUX module at each rising edge of the clock, and at the same time drives the monitoring enable signal to prompt the Monitor class to start working.

[0057] It can be understood that in the driver design, by obtaining the randomized data of the transaction and the signal to be driven, and serially driving according to the space size of the dynamic array, the enable signal is driven at the same time to prompt the monitor to start working.

[0058] In some embodiments, the Monitor class is a component in UVM used to monitor the signal behavior of the chip under test in real time. It is responsible for capturing signal changes on the PAD and storing the captured data in a dynamic array for subsequent analysis. In the present application, after the monitoring enable signal is activated, the Monitor class records the behavior of the PAD at each rising edge of the clock and stores the captured data in a dynamic array. For register access transactions on the AMBA bus, the Monitor class will also parse the register address, data, control signal and other information.

[0059] It is understandable that the present application instantiates an equal number of monitors according to the number of interfaces in the environment, each monitor corresponds to an interface, and is passed in the top-level design. When the monitoring enable signal is turned on, multiple monitors monitor the signal behavior in real time until the monitoring enable signal is turned off, and the monitoring data and name string are stored in the transaction for subsequent comparison.

[0060] In some embodiments, the Agent class is a component in UVM used to integrate the Driver class, the Monitor class, and the Sequencer class. In the present application, the Agent class is used to instantiate the Transaction class, the Driver class, and the Monitor class, and obtain multiple monitoring signals from the virtual interface. The Agent class can be divided into the Agent of the IOMUX module and the Agent of the AMBA module, which are responsible for the verification of the IOMUX module and the AMBA bus respectively.

[0061] In some embodiments, the Reference_Mode 1 class is a component in UVM used to simulate the ideal behavior of the chip under test; in the present application, the Reference_Mode 1 class can obtain the actual PAD signal from the Monitor class and generate corresponding expected results according to the register configuration. These expected results are used to compare with the actually captured PAD signal to determine whether the function of the IOMUX module is correct.

[0062] It can be understood that in the reference_mode 1 design, the present application imitates the IO connection behavior and connects the data obtained by the monitor and the data configured by the register to the reference_mode 1. The model writes corresponding functions according to the number of PADs, each function returns the transaction corresponding to the current PAD, and passes it to the scoreboard to ensure that it fully meets the design requirements of IOMUX.

[0063] In some embodiments, the Scoreboard class is a component in UVM used to compare actual signal data with expected results; in the present application, the Scoreboard class compares the actual PAD signal captured by the Monitor class with the expected result generated by the Reference_Model class to obtain a comparison result. If the two are consistent, it means that the IOMUX module is working properly; if they are inconsistent, a warning is issued or marked as failed to help developers quickly locate the problem.

[0064] It is understandable that the main purpose of scoreboard is to compare PAD data with the data returned by reference_mode l. The PAD transaction captured by monitor is sent directly to scoreboard. If the PAD transaction is consistent with the transaction data returned by reference_mode l, it is considered to have passed; if the transaction name string is consistent, a warning is issued, indicating that the register configuration behavior is in an unsupported state; other behaviors are considered to have failed.

[0065] In some embodiments, the Environment class is the top-level container in UVM for managing all verification components; in the present application, the Environment class instantiates the Agent class, Reference_Model class, and Scoreboard class of the IOMUX module and the AMBA module to form a complete verification environment. The Environment class is also responsible for managing the data flow and communication mechanism between these components.

[0066] In some embodiments, the Configuration class is a component in UVM for configuring the default parameters of the verification environment; in this application, the Configuration class configures the default values ​​of the verification environment to ensure the flexibility and scalability of the verification environment. Through the Configuration class, users can flexibly adjust the settings of the verification environment to adapt to different test requirements.

[0067] In some embodiments, the base_test class is the top-level test class in UVM used to start the entire verification process; in this application, the base_test class instantiates the Environment class and the Configuration class to start the entire verification process. The base_test class is the basis of all test cases and is responsible for initializing the verification environment and executing specific test steps.

[0068] Based on the specific explanation of the above-mentioned multiple components, corresponding to step S120, the Monitor component is responsible for real-time monitoring of the signal of the IOMUX module. The Monitor of the IOMUX module captures the signal changes of the IOMUX module in real time through the Virtual_Interface of the IOMUX module. The Monitor stores the captured data to obtain the monitoring signal; Reference_Mode l generates the expected PAD behavior according to the configuration information. The Reference_Mode l of the IOMUX module uses the configuration information and register configuration to generate the expected PAD signal sequence. The Scoreboard is responsible for comparing the actual signal with the expected result. The Scoreboard of the IOMUX module receives the actual signal data from the Monitor and compares it with the expected result generated by Reference_Mode l. If the two are consistent, it means that the IOMUX module is working normally; if they are inconsistent, it is marked as failed; finally, the Base_Test starts the entire verification process and outputs the final verification report according to the comparison results of the Scoreboard. If all signals meet the expected results, the verification passes; otherwise, the verification fails and provides detailed error information.

[0069] Among them, the Agent of the AMBA module and the Agent of the IOMUX module will both be instantiated. AMBA (Advanced Microcontroller Bus Architecture) is used to connect the processor, memory and other peripherals. The Agent of the AMBA module is mainly used to monitor the register access transactions sent to the IOMUX module through the AMBA bus, such as read and write operations; the Agent of the IOMUX module is mainly used to monitor the PAD signal of the IOMUX module, that is, the behavior of the input / output port.

[0070] refer to Figure 3 , Figure 3 A method flow chart for capturing multiple monitoring signals in a UVM-based IOMUX verification method provided in an embodiment of the present application; in some embodiments, multiple components are instantiated to capture multiple monitoring signals of an IOMUX module in a chip to be tested, including:

[0071] Step S310, instantiating multiple virtual interfaces in the top-level module of the chip under test, each virtual interface corresponding to the monitoring signal of one or more pins of the chip under test;

[0072] Step S320, connecting the name and path information of each monitoring signal to the corresponding virtual interface, and ensuring the timing of the monitoring signal is correct based on the clock block in each virtual interface;

[0073] Step S330 , delivering the multiple virtual interfaces to the multiple components in the UVM environment, so as to access and operate the multiple monitoring signals based on the multiple components in the UVM environment.

[0074] Wherein, virtual interface is the abstract interface for simulating hardware interface behavior in UVM, allows verification component (such as Driver class and Monitor class) to interact with the physical pins of the chip under test, grabs and drives signals, in the top module of the chip under test, multiple virtual interfaces can be instantiated, and each virtual interface corresponds to one or more PADs (pins). This ensures that all inputs, outputs and enable signals of the IOMUX module can be fully monitored, and each virtual interface can correspond to one or more PADs, adapts to different IOMUX configuration scenarios, and enhances the flexibility of the verification environment.

[0075] In some embodiments, the name and path information of each monitoring signal are connected to the corresponding virtual interface to ensure that the verification platform can accurately identify and capture the signal changes on each PAD. Each virtual interface includes a clock block (clocking block) for simulating the establishment and holding time of the signal drive to ensure that the timing of the monitoring signal is correct. The clock block is also used to capture and drive the synchronization signal to ensure that the timing relationship of the signal meets the design requirements. After multiple virtual interfaces are passed to various components (such as Agent class, Driver class, Monitor class, etc.) in the UVM environment, these components can access and operate the monitoring signals.

[0076] refer to Figure 4 , Figure 4 A method flow chart for obtaining multiple monitoring signals in a UVM-based IOMUX verification method provided in an embodiment of the present application; in some embodiments, obtaining multiple monitoring signals based on multiple components in a UVM environment includes:

[0077] Step S410, instantiate the Transaction class, Driver class and Monitor class through the Agent class;

[0078] Step S420, generating a test stimulus through the Transaction class; transmitting the test stimulus to the pin of the chip under test through the Driver class, and generating a drive signal;

[0079] Step S430: obtaining, through the Monitor class, a monitoring signal generated by the pin of the chip under test according to the test stimulus in response to the driving signal.

[0080] In some embodiments, the Agent class is used to instantiate the Transaction class, Driver class, and Monitor class, and corresponding Agents are created for the IOMUX module and the AMBA module. This ensures that the verification of the IOMUX module and the AMBA module can be performed independently, while being able to interact when needed; further, the Transaction class is used to encapsulate the data structure of the test stimulus, generate the test stimulus through the Sequencer class, and pass it to the Driver class. The Driver class is responsible for converting the test stimulus in the Transaction class into an actual signal drive and transmitting it to the pins of the chip to be tested. At each rising edge of the clock, the Driver class drives the signal on the PAD according to the data in the Transaction class and generates a drive signal.

[0081] In some embodiments, the Monitor class is responsible for monitoring the signal changes on the PAD in real time. When the Driver class sends the driving signal, the Monitor class will respond to these signals, capture the actual signal changes on the PAD, and store the captured data in a dynamic array. The signal data captured by the Monitor class will be passed to the Reference_Model class and the Scoreboard class through the broadcast mechanism for subsequent comparison and verification. It can be understood that the Monitor class can capture the signal changes on the PAD in real time, ensuring that the verification platform can obtain the actual PAD behavior in a timely manner, avoiding verification errors caused by delays.

[0082] refer to Figure 5 , Figure 5 A flowchart of a method for comparison in a UVM-based IOMUX verification method provided in an embodiment of the present application; in some embodiments, a plurality of monitoring signals are compared with the generated expected results, including:

[0083] Step S510, instantiate the Reference_Model class and the Scoreboard class through the Environment class;

[0084] Step S520, obtaining a monitoring signal from the monitor class through the Reference_Model class, and generating a corresponding expected result according to the number of pins and register configuration of the chip to be tested;

[0085] Step S530: Compare the monitoring signal obtained by the monitor class with the expected result through the Scoreboard class to obtain a comparison result.

[0086] It can be understood that the complete verification environment is formed by instantiating the Reference_Model class and the Scoreboard class through the Environment class. The Environment class is also responsible for managing the data flow and communication mechanism between these components. The Reference_Model class generates the expected PAD behavior according to the register configuration and the number of PADs, obtains the actual PAD signal from the Monitor class, and generates the corresponding expected result according to the register configuration. The Scoreboard class compares the actual PAD signal captured by the Monitor class with the expected result generated by the Reference_Model class to obtain the comparison result. If the two are consistent, it means that the IOMUX module is working properly; if they are inconsistent, a warning is issued or marked as a failure to help developers quickly locate the problem.

[0087] In some embodiments, the Transaction class, Driver class and Monitor class are instantiated through the Agent class, including: the Transaction class, Driver class and Monitor class of the IOMUX module and the AMBA module in the chip to be tested are respectively instantiated through the Agent class; the Transaction class data corresponding to the Monitor class of the IOMUX module is connected to the Reference_Model class and the Scoreboard class through the broadcast mechanism; the Transaction class data corresponding to the Monitor class of the AMBA module is connected to the Reference_Model class, and the Transaction class data returned by the Reference_Model class is connected to the Scoreboard class; it can be understood that the verification of the IOMUX module and the AMBA module is independent to ensure the functional correctness of each module. At the same time, through the collaborative work of the Reference_Model class and the Scoreboard class, the verification platform can comprehensively verify the impact of the register configuration on the PAD behavior; in addition, through the broadcast mechanism, the PAD signal captured by the Monitor class of the IOMUX module can be transmitted to multiple components at the same time, ensuring the efficiency and coordination of the verification process.

[0088] refer to Figure 6 , Figure 6A schematic diagram of the structure of the script parsing module in the UVM-based IOMUX verification method provided in one embodiment of the present application; wherein ParseExce l.pm is a basic script for processing Excel files, and the script is initialized by passing the Excel file name to the variable $Workbook and the worksheet name to $Worksheet, and a specific cell $cel is located by specifying the row number $row and the column number $col, and a value access function is called to obtain its value from $cel.

[0089] ParseReg.pm is a register parsing script. It imports ParseExce l.pm as a module and stores it in the variable $Excel. It uses the range of the register row as the key of the array $Reg[] and the number of registers as the number of keys. By specifying the key value, it gets the name, offset address and bit width of the register, which are stored in $reg_name, $reg_addr and $reg_width respectively. It uses the number of register fields under the register as the number of keys of the array $func_reg[] and each row as the range obtained by the key. By specifying the key value, it gets the name, bit width, readable and writable status and default value of the register field, which are stored in $func_reg_name, $size, $access and $reset_value respectively.

[0090] ParseIO.pm is an IO parsing script. It imports ParseExce l.pm as a module and stores it in the variable $Excel. It uses the range of the rows where the PAD is located as the key of the array $PAD[] and the number of PADs as the number of keys. By specifying the key value, it gets the name of the PAD and stores it in $pad_name. It uses the number of funct ions under each PAD as the number of keys in the array $func_se l[] and the column where each funct ion is located as the range of keys. By specifying the key value, it gets the input, output, enable signal name and ID of the funct ion and stores them in $input_name, $output_name, $oen_name and $id respectively.

[0091] Top.pm is the top-level script. It imports ParseReg.pm and ParseIO.pm as modules and stores them in variables $ParseReg and $ParseIO. It matches the domain name of the register script with the signal name of the IO table. After a successful match, it obtains the register-related information of the signal and the mapping information on the IOMUX. Based on the information obtained, it automatically generates the verification environment and test stimulus files.

[0092] “Generate verification environment components” is the process of finally generating verification environment components based on the analysis results of all the above steps.

[0093] like Figure 6 As shown in the figure, the whole process demonstrates how to extract register and IO information from the Excel table and use it to automatically generate verification environment components.

[0094] refer to Figure 7 , Figure 7 In the UVM-based IOMUX verification method provided in one embodiment of the present application, a method flow chart of constructing multiple components in a UVM verification environment; in some embodiments, the configuration table file includes a register table and an IO table, and the configuration table file of the chip to be tested is parsed based on a preset script to construct multiple components in the UVM verification environment, including:

[0095] Step S710, creating a basic script for parsing a table file;

[0096] Step S720, creating a register parsing script and an IO parsing script based on the basic script;

[0097] Step S730, creating a top-level script, and importing the register parsing script and the IO parsing script into the top-level script as modules respectively;

[0098] Step S740, parsing the register table and the IO table based on the top-level script, obtaining the register information and the IOMUX mapping information of the chip to be tested, and constructing multiple components in the UVM verification environment according to the register information and the IOMUX mapping information.

[0099] correspond Figure 6 In some embodiments, the configuration table file includes a register table and an IO table. By automatically parsing these table files, multiple components in the UVM verification environment can be automatically generated. The following are detailed steps and their explanations:

[0100] Step S710: The basic script ParseExce l.pm is used to handle the parsing of Excel files. The script is initialized by passing the Excel file name to the variable $Workbook and the worksheet name to $Worksheet. The specific cell $cel is located by specifying the row number $row and the column number $col. The value-getting function is called to obtain the value from $cel, thereby realizing the reading of data in each cell of the Excel file.

[0101] Step S720: register parsing script ParseReg.pm, imports ParseExce l.pm as a module, stores it in the variable $Exce l, uses the range of the row where the register is located as the key of the array $Reg[], and the number of registers as the number of keys. By specifying the key value, the name, offset address and bit width of the register are obtained, and stored in $reg_name, $reg_addr and $reg_width respectively. The number of register fields under the register is used as the number of keys of the array $func_reg[], and each row is the range obtained by the key. By specifying the key value, the name, bit width, readable and writable status and default value of the register field are obtained, and stored in $func_reg_name, $size, $access and $reset_value respectively, thereby realizing the parsing of the register table.

[0102] Step S730: The IO parsing script ParseIO.pm imports ParseExce l.pm as a module and stores it in the variable $Exce l. It uses the range of the rows where the PAD is located as the key of the array $PAD[] and the number of PADs as the number of keys. By specifying the key value, it obtains the name of the PAD and stores it in $pad_name. It uses the number of funct ions under each PAD as the number of keys of the array $func_sel[] and the column where each funct ion is located as the range for key acquisition. By specifying the key value, it obtains the input, output, enable signal name and ID of the funct ion and stores them in $input_name, $output_name, $oen_name and $id respectively, thereby realizing the parsing of the IO table.

[0103] Step S740: Create a top-level script Top.pm, which is responsible for coordinating the entire parsing and generation process, import ParseReg.pm and ParseIO.pm as modules, store them in variables $ParseReg and $ParseIO, and then match the register information with the IO information, and generate various components in the UVM verification environment according to the matching results.

[0104] It can be understood that Top.pm can automatically call ParseReg.pm and ParseIO.pm, and generate a UVM verification environment based on the parsing results, reducing the workload of manual configuration and improving verification efficiency. Among them, Top.pm automatically generates multiple components in the UVM verification environment, which may include: virtual interface, Transactions class, Driver class, Monitor class: used to monitor signal changes on the PAD in real time, Agent class, Reference_Model class, Scoreboard class, Environment class, Configuration class and base_test class to improve the construction efficiency of the verification environment and simplify the verification process.

[0105] In summary, the present application simplifies the construction process of the verification environment and improves efficiency by automatically generating verification environments and test cases through scripts. It also parses the register table and mapping relationship table of IOMUX through scripts, automatically generates the corresponding interface, monitor and reference_mode l, and matches the domain name of the register table with the signal name of the mapping relationship table to generate cases or other components, which can effectively shorten the time for constructing the verification environment.

[0106] To achieve the above-mentioned purpose, the second aspect of the embodiment of the present application provides an IOMUX verification platform based on UVM, the IOMUX verification platform is connected to the chip to be tested, and the IOMUX verification platform includes: a script parsing module, which is used to parse the configuration table file of the chip to be tested based on a preset script to construct multiple components in the UVM verification environment; a verification environment module, which is used to instantiate multiple components to capture multiple monitoring signals of the IOMUX module in the chip to be tested, and compare the multiple monitoring signals with the generated expected results, and implement IOMUX verification of the chip to be tested according to the comparison results.

[0107] It can be understood that by applying the UVM-based IOMUX verification method, the IOMUX verification platform can connect the signal to the corresponding interface in an automated manner to achieve comprehensive monitoring of the signal; by capturing the signal data through the monitoring file (monitor) and passing it to the behavioral model (reference_model) and the scoreboard (scoreboard), the automatic collection and comparison of the results are achieved; in addition, the introduction of the driver file (driver) makes the driving of signals and data more convenient, and further automates the IOMUX inspection process; in addition, the application also provides an intelligent script solution, which can automatically generate a verification platform according to the IOMUX-related table files, significantly improving the efficiency and accuracy of the verification. Through the above technical solution, the application can ensure that the chip IOMUX meets strict performance and reliability requirements during the design and verification process.

[0108] refer to Figure 8 , Figure 8 The electronic device provided in one embodiment of the present application includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the UVM-based IOMUX verification method of any of the above embodiments is implemented. For example, the above-described Figure 1 Steps S110 to S120 of the method, Figure 3 Steps S310 to S330 of the method, Figure 4 Steps S410 to S430 of the method, Figure 5 Steps S510 to S530 of the method, Figure 7 The method comprises steps S710 to S740.

[0109] The electronic device 800 of the embodiment of the present application includes one or more processors 810 and a memory 820. Figure 8 In the figure, a processor 810 and a memory 820 are taken as an example.

[0110] The processor 810 and the memory 820 may be connected via a bus or other means. Figure 8 The example of connecting through bus is taken in the following.

[0111] The memory 820, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer executable programs. In addition, the memory 820 may include a high-speed random access memory, and may also include a non-transitory memory, such as at least one disk storage device, a flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 820 may optionally include a memory 820 remotely disposed relative to the processor 810, and these remote memories may be connected to the electronic device 800 via a network. At the same time, examples of the above-mentioned network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0112] In some embodiments, when the processor executes the computer program, the UVM-based IOMUX verification method of any one of the above embodiments is executed at a preset interval.

[0113] Those skilled in the art will understand that Figure 8 The device structure shown in the figure does not constitute a limitation on the electronic device 800, and may include more or less components than those shown in the figure, or combine certain components, or arrange the components differently.

[0114] exist Figure 8 In the electronic device 800 shown, the processor 810 can be used to call the UVM-based IOMUX verification method stored in the memory 820, so as to implement the UVM-based IOMUX verification method.

[0115] Based on the hardware structure of the above-mentioned electronic device 800, various embodiments of the UVM-based IOMUX verification device of the present application are proposed. At the same time, the non-transient software program and instructions required to implement the UVM-based IOMUX verification method of the above-mentioned embodiment are stored in the memory. When executed by the processor, the UVM-based IOMUX verification method of the above-mentioned embodiment is executed.

[0116] The embodiment of the present application also provides a computer-readable storage medium, which stores computer-executable instructions, which are used to execute the above-mentioned UVM-based IOMUX verification method, and can enable the above-mentioned one or more processors to execute the UVM-based IOMUX verification method of any of the above-mentioned embodiments, for example, to execute the above-mentioned Figure 1 Steps S110 to S120 of the method, Figure 3 Steps S310 to S330 of the method, Figure 4 Steps S410 to S430 of the method, Figure 5 Steps S510 to S530 of the method, Figure 7 The method comprises steps S710 to S740.

[0117] The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separated, that is, they may be located in one place or distributed on multiple network nodes. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0118] It will be appreciated by those skilled in the art that all or some of the steps and systems in the disclosed method above may be implemented as software, firmware, hardware and appropriate combinations thereof. Some physical components or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor or a microprocessor, or may be implemented as hardware, or may be implemented as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer-readable storage medium (or a non-transitory medium) and a communication medium (or a temporary medium). As known to those skilled in the art, the term computer-readable storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules or other data). Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD to ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, disk storage or other magnetic storage devices, or any other medium that may be used to store desired information and may be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0119] The above is a specific description of the preferred implementation of the present application, but the present application is not limited to the above implementation mode. Technical personnel familiar with the field can also make various equivalent modifications or substitutions without violating the spirit of the present application. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present application.

Claims

1. A UVM-based IOMUX verification method, characterized in that: Applied to an IOMUX verification platform, the IOMUX verification platform is connected to a chip to be tested, and the method includes: Parse the configuration table file of the chip to be tested based on a preset script to build multiple components in a UVM verification environment; The multiple components are instantiated to capture multiple monitoring signals of the IOMUX module in the chip under test, and the multiple monitoring signals are compared with the generated expected results, and the IOMUX verification of the chip under test is implemented according to the comparison results.

2. The IOMUX verification method based on UVM according to claim 1, wherein The plurality of components include a virtual interface, a Transaction class, a Driver class, a Monitor class, an Agent class, a Reference_Model class, a Scoreboard class, an Environment class, a Configuration class, and a base_test class; in, The virtual interface is used to capture multiple monitoring signals of the IOMUX module; The Agent class is used to instantiate the Transaction class, the Driver class and the Monitor class to obtain the plurality of monitoring signals from the virtual interface; The Reference_Model class is used to generate the expected results; The Scoreboard class is used to compare the plurality of monitoring signals with the generated expected results to obtain a comparison result; The Environment class is used to instantiate the Agent class, the Reference_Model class and the Scoreboard class; The Configuration class is used to configure multiple components of the Environment; The base_test class is used to instantiate the Environment class and the Configuration class to implement IOMUX verification of the chip under test according to the comparison result.

3. The IOMUX verification method based on UVM according to claim 2, characterized in that, The instantiating of the multiple components to capture multiple monitoring signals of the IOMUX module in the chip under test includes: Instantiating a plurality of the virtual interfaces in the top-level module of the chip under test, each of the virtual interfaces corresponding to the monitoring signal of one or more pins of the chip under test; Connecting the name and path information of each monitoring signal to the corresponding virtual interface, and ensuring the correct timing of the monitoring signal based on the clock block in each virtual interface; The plurality of virtual interfaces are delivered to the plurality of components in the UVM environment, so as to access and operate the plurality of monitoring signals based on the plurality of components in the UVM environment.

4. The IOMUX verification method based on UVM according to claim 3, wherein The acquiring of the plurality of monitoring signals based on the plurality of components in the UVM environment comprises: Instantiate the Transaction class, Driver class and Monitor class through the Agent class; Generate test incentives through the Transaction class; The test stimulus is transmitted to the pin of the chip under test through the Driver class, and a driving signal is generated; The monitoring signal generated by the pin of the chip under test according to the test stimulus is obtained in response to the driving signal through the Monitor class.

5. The IOMUX verification method based on UVM according to claim 2, characterized in that, The comparing the plurality of monitoring signals with the generated expected results comprises: Instantiate the Reference_Model class and the Scoreboard class through the Environment class; Obtain the monitoring signal from the monitor class through the Reference_Model class, and generate a corresponding expected result according to the number of pins and register configuration of the chip to be tested; The monitoring signal obtained by the monitor class is compared with the expected result through the Scoreboard class to obtain a comparison result.

6. The IOMUX verification method based on UVM according to claim 4, characterized in that, The instantiation of the Transaction class, the Driver class and the Monitor class through the Agent class includes: The Transaction class, the Driver class and the Monitor class of the IOMUX module and the AMBA module in the chip under test are respectively instantiated through the Agent class; Connect the Transaction class data corresponding to the Monitor class of the IOMUX module to the Reference_Model class and the Scoreboard class through a broadcast mechanism; The Transaction class data corresponding to the Monitor class of the AMBA module is connected to the Reference_Model class, and the Transaction class data returned by the Reference_Model class is connected to the Scoreboard class.

7. The IOMUX verification method based on UVM according to claim 1, characterized in that, The configuration table file includes a register table and an IO table, and the configuration table file of the chip to be tested is parsed based on a preset script to construct multiple components in a UVM verification environment, including: Create a basic script for parsing table files; Create a register parsing script and an IO parsing script based on the basic script; Create a top-level script, and import the register parsing script and the IO parsing script into the top-level script as modules respectively; The register table and the IO table are parsed based on the top-level script to obtain the register information and the IOMUX mapping information of the chip to be tested, and multiple components in the UVM verification environment are constructed according to the register information and the IOMUX mapping information.

8. A UVM-based IOMUX verification platform, characterized in that: The IOMUX verification platform is connected to the chip to be tested, and the IOMUX verification platform includes: A script parsing module, used for parsing the configuration table file of the chip to be tested based on a preset script to construct multiple components in a UVM verification environment; The verification environment module is used to instantiate the multiple components to capture multiple monitoring signals of the IOMUX module in the chip under test, and compare the multiple monitoring signals with the generated expected results, and implement IOMUX verification of the chip under test according to the comparison results.

9. An electronic device, characterized in that: include: at least one processor; at least one memory for storing at least one program; When at least one of the programs is executed by at least one of the processors, the UVM-based IOMUX verification method according to any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are used to execute the UVM-based IOMUX verification method according to any one of claims 1 to 7.

Images