UVM-based iomux verification method, verification platform and related device

Abstract

The application provides an IOMUX verification method based on UVM, a verification platform and related equipment. The method is applied to an IOMUX verification platform connected with a chip to be tested. The method comprises the following steps: based on a preset script, a configuration table file of the chip to be tested is analyzed to construct a plurality of components in a UVM verification environment; the plurality of components are instantiated to capture a plurality of monitoring signals of an IOMUX module in the chip to be tested, and the plurality of monitoring signals are compared with generated expected results, and IOMUX verification of the chip to be tested is realized according to a comparison result. In the application, the configuration table file of the chip to be tested can be analyzed through a script to generate and instantiate the plurality of components in the UVM verification environment, the UVM framework is combined with the script, the construction process of the verification environment is simplified, and the automatic verification process of the IOMUX module is realized, so that manual intervention can be effectively reduced and the verification speed can be accelerated.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the field of integrated circuit design verification, and in particular to an IOMUX verification method based on UVM, a verification platform and related equipment. BACKGROUND

[0002] In integrated circuit design, the IOMUX (input / output multiplexer) module is a key component in the SoC (system on chip), responsible for managing the signal transmission between the external pins (PAD) of the chip and the internal logic. The traditional IOMUX verification method usually relies on manually writing test stimuli and monitoring scripts. This approach is not only time-consuming and laborious, but also prone to errors, and it is difficult to cover complex IOMUX configuration scenarios. Especially in modern SoC design, the function of IOMUX module is becoming more and more complex, involving a large number of register configurations, signal mapping and timing requirements. The traditional method is difficult to ensure the comprehensiveness and accuracy of verification. In addition, with the increase of chip size, the verification workload of IOMUX module also increases exponentially, bringing great challenges to verification engineers. SUMMARY

[0003] The embodiments of the present application provide an IOMUX verification method based on UVM, which can combine UVM framework with scripts, simplify the building process of verification environment, and realize the automatic verification process of IOMUX module, thereby effectively reducing manual intervention and accelerating the verification speed.

[0004] To achieve the above purpose, a first aspect of the embodiments of the present application provides an IOMUX verification method based on UVM applied to an IOMUX verification platform, the IOMUX verification platform is connected with a chip under test, and the method comprises: analyzing a configuration table file of the chip under test based on a preset script to construct a plurality of components in a UVM verification environment; instantiating the plurality of components to capture a plurality of monitoring signals of an IOMUX module in the chip under test, and comparing the plurality of monitoring signals with generated expected results, and realizing IOMUX verification of the chip under test according to the comparison result.

[0005] In some embodiments, the plurality of components comprises 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 configured to capture a plurality of monitoring signals of an IOMUX module; the Agent class is configured 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 configured to generate an expected result; the Scoreboard class is configured to compare the plurality of monitoring signals with the generated expected result to obtain a comparison result; the Environment class is configured to instantiate the Agent class, the Reference_Model class, and the Scoreboard class; the Configuration class is configured to configure a plurality of components of the Environment; and the base_test class is configured to instantiate the Environment class and the Configuration class to implement IOMUX verification of the chip under test according to the comparison result.

[0006] In some embodiments, the plurality of components are instantiated to capture a plurality of monitoring signals of an IOMUX module in the chip under test, comprising: instantiating a plurality of virtual interfaces in a 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 timing of the monitoring signals based on a clock block in each of the virtual interfaces; and passing the plurality of virtual interfaces to a plurality of components in a UVM environment to access and operate the plurality of monitoring signals based on the plurality of components in the UVM environment.

[0007] In some embodiments, the plurality of components are instantiated to capture a plurality of monitoring signals of an IOMUX module in the chip under test, comprising: instantiating a plurality of virtual interfaces in a 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 timing of the monitoring signals based on a clock block in each of the virtual interfaces; and passing the plurality of virtual interfaces to a plurality of components in a UVM environment to access and operate the plurality of monitoring signals based on the plurality of components in the UVM environment.

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

[0009] In some embodiments, the instantiating the Transaction class, the Driver class and the Monitor class by the Agent class comprises: instantiating the Transaction class, the Driver class and the Monitor class of the IOMUX module and the AMBA module in the chip under test by the Agent class respectively; connecting the Transaction class data corresponding to the Monitor class of the IOMUX module to the Reference_Model class and the Scoreboard class by 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 comprises a register table and an IO table, and the parsing the configuration table file of the chip under test based on a preset script to construct a plurality of components in a UVM verification environment comprises: 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 to obtain register information and IOMUX mapping information of the chip under test, and constructing a plurality of components in the UVM verification environment according to the register information and the IOMUX mapping information.

[0011] To achieve the above object, a second aspect of the embodiment of the present application provides an IOMUX verification platform based on UVM, which is connected with a chip to be tested, and comprises: a script analysis module, configured to analyze a configuration table file of the chip to be tested based on a preset script, so as to construct a plurality of components in a UVM verification environment; and a verification environment module, configured to instantiate the plurality of components, so as to capture a plurality of monitoring signals of an IOMUX module in the chip to be tested, compare the plurality of monitoring signals with expected results generated, and implement IOMUX verification of the chip to be tested according to a comparison result.

[0012] To achieve the above object, a third aspect of the embodiment of the present application provides an electronic device, comprising: at least one processor; at least one memory configured to store at least one program; and the at least one program is executed by the at least one processor to implement the IOMUX verification method based on UVM according to any one of the first aspect.

[0013] To achieve the above object, a fourth aspect of the embodiment of the present application provides a computer readable storage medium, which stores computer executable instructions, and the computer executable instructions are configured to implement the IOMUX verification method based on UVM according to any one of the first aspect.

[0014] The embodiment of the present application provides an IOMUX verification method, a verification platform and related devices based on UVM, which at least has the following beneficial effects: the IOMUX verification method based on UVM is applied to an IOMUX verification platform, the IOMUX verification platform is connected with a chip to be tested, and the method comprises: analyzing a configuration table file of the chip to be tested based on a preset script, so as to construct a plurality of components in a UVM verification environment; instantiating the plurality of components, so as to capture a plurality of monitoring signals of an IOMUX module in the chip to be tested, compare the plurality of monitoring signals with expected results generated, and implement IOMUX verification of the chip to be tested according to a comparison result; and it can be understood that the present application can analyze the configuration table file of the chip to be tested through a script, generate and instantiate a plurality of components in a UVM verification environment, combine a UVM framework with a script, simplify a building process of a verification environment, and implement an automatic verification process of the IOMUX module, so as to effectively reduce manual intervention and accelerate verification speed. BRIEF DESCRIPTION OF DRAWINGS

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

[0016] Figure 2 In the IOMUX verification method based on UVM provided by an embodiment of the present application, a structure diagram of a verification environment module;

[0017] Figure 3 The method flow chart for capturing multiple monitoring signals in the UVM-based IOMUX verification method provided by an embodiment of the present application is provided.

[0018] Figure 4 The method flow chart for capturing multiple monitoring signals in the UVM-based IOMUX verification method provided by an embodiment of the present application is provided.

[0019] Figure 5 The method flow chart for comparison in the UVM-based IOMUX verification method provided by an embodiment of the present application is provided.

[0020] Figure 6 The structural schematic diagram of the script analysis module in the UVM-based IOMUX verification method provided by an embodiment of the present application is provided.

[0021] Figure 7 The method flow chart for constructing multiple components in the UVM verification environment in the UVM-based IOMUX verification method provided by an embodiment of the present application is provided.

[0022] Figure 8 The structural schematic diagram of the electronic device provided by an embodiment of the present application is provided. DETAILED DESCRIPTION

[0023] In order to make the purpose, technical scheme and advantages of the present application more clear, the present application is further described in detail below in combination with the 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 flow chart, in some cases, the steps shown or described can be performed in a different order from the module division in the system or the order in the flow chart. The terms first, second, etc. in the specification and claims and the above drawings are used to distinguish similar objects, and do not necessarily describe a specific order or sequence.

[0025] In addition, unless otherwise explicitly specified and limited, the term "connection / connected" should be understood broadly, for example, it can be a fixed connection or a movable connection, or a detachable connection or a non-detachable connection, or an integral connection; it can be a mechanical connection, or an electrical connection or can communicate with each other; it can be directly connected, or indirectly connected through an intermediate medium.

[0026] In the description of the embodiments of the present application, the description of the terms "one embodiment", "another embodiment" or "certain embodiments", "in the above embodiment" and the like means that the specific features, structures, materials or characteristics described in connection with the embodiments or examples are contained in at least two embodiments or embodiments of the present disclosure. In the present disclosure, the illustrative description of the above terms does not necessarily refer to the same embodiment or embodiment. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described can be performed in an order different from that in the flowchart.

[0027] In integrated circuit design, IOMUX (input / output multiplexer) module is a key component in SoC (system on chip), responsible for managing the signal transmission between the external pins (PAD) of the chip and the internal logic. The traditional IOMUX verification method usually relies on manually writing test stimuli and monitoring scripts. This way not only consumes time and effort, but also is prone to errors, and is difficult to cover complex IOMUX configuration scenarios. Especially in modern SoC design, the function of IOMUX module is becoming more and more complex, involving a large number of register configurations, signal mapping and timing requirements, and the traditional method is difficult to ensure the comprehensiveness and accuracy of verification. In addition, with the increase of chip size, the verification workload of IOMUX module also increases exponentially, bringing great challenges to verification engineers.

[0028] Based on this, the embodiments of the present application provide an IOMUX verification method based on UVM, which can combine UVM framework with scripts, simplify the building process of the verification environment, and realize the automatic verification process of the IOMUX module, thereby effectively reducing manual intervention and accelerating the verification speed.

[0029] The embodiments of the present application will be further described below with reference to the accompanying drawings.

[0030] Reference Figure 1 , Figure 1 The method flowchart of the IOMUX verification method based on UVM provided by an embodiment of the present application; the first aspect of the 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 with a chip to be tested, and the method comprises:

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

[0032] In step S120 , 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.

[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 the system on chip (SoC). In the present application, the platform can be built through the 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 configuration of the IOMUX module.

[0035] It is understandable that, contrast step S110, in traditional verification method, the building of verification environment usually relies on manually writing code, which is not only time-consuming and laborious, but also prone to errors. In order to improve efficiency and ensure consistency, the application introduces a preset script, for automating 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 the file describing the IOMUX module configuration information of the chip to be tested, usually stored in Excel, CSV or XML format, these files can include the information such as the name of the PAD pin of the IOMUX module, path, register configuration, function selection, etc., by parsing the configuration table file, the 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, the Driver class and the Monitor class to obtain a plurality of monitoring signals from a virtual interface;

[0039] The Reference_Model class is used to generate expected results;

[0040] The Scoreboard class is used to compare the plurality of monitoring signals with the generated expected results to obtain a comparison result;

[0041] The Environment class is used to instantiate the Agent class, the Reference_Model class and the Scoreboard class;

[0042] The Configuration class is used to configure a plurality of components of the Environment;

[0043] 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.

[0044] It can be understood that, after the automatic construction of the verification environment is completed, the plurality of generated components are instantiated in contrast to step S120. The instantiation process is to convert the abstract component code into a specific object so as to be used in the verification process. Each component has its specific function, and cooperates together to complete the verification of the IOMUX module. The specific process can include:

[0045] Through the instantiated virtual interface, the verification platform can capture a plurality of 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) for simulating the setup and hold time of signal driving.

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

[0047] The Reference_Model class generates 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. These expected results serve as a reference standard for verification and are used for subsequent comparison.

[0048] The actual PAD signal captured by the Monitor class is compared with the expected result generated by the Reference_Model class through the Scoreboard class to obtain a comparison result. If the two are consistent, it indicates that the IOMUX module is working properly. If they are not consistent, a warning is issued or marked as failed 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 a final verification report according to the comparison result of the Scoreboard class, indicating whether the IOMUX module has passed the verification.

[0050] In summary, the present application can instantiate multiple components to enable the verification platform to capture the monitoring signal of the IOMUX module in real time and compare it with the expected result, thereby achieving comprehensive verification of the IOMUX module function. This not only improves the coverage and accuracy of the verification, but also simplifies the verification process and shortens the product development cycle.

[0051] Reference Figure 2 , Figure 2 In an embodiment of the present application, the structure of the verification environment module is provided. In some embodiments, as shown in Figure 2 , it can be seen that multiple components are instantiated and integrated into the verification environment. These components include: Agent and IOMUX module Agent of AMBA module, Sequencer, Driver, Monitor, Reference_Model, and Scoreboard. These components are connected to the DUT (DeviceUnderTest) through virtual interfaces (Virtual_Interface). Correspondingly, the specific explanations of the multiple components are as follows:

[0052] In some embodiments, the virtual interface (Virtual_Interface) can simulate the behavior of the hardware interface in the verification environment, allowing verification components (such as the Driver class and the Monitor class) to interact with the physical pins of the DUT to capture and drive signals. In the present application, the virtual interface is used to capture multiple monitoring signals of the IOMUX module to ensure comprehensive monitoring of the input, output, and enable signals of the IOMUX module. Each virtual interface corresponds to one or more PAD signals and contains a clock block (clocking_block) for simulating the setup and hold time of signal driving.

[0053] It can be understood that the application integrates the monitoring signal path and the 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, which allows other environmental components to directly obtain the signal behavior through the number, facilitating subsequent real-time comparison

[0054] In some embodiments, the Transaction class is a data packet class in UVM for encapsulating 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 pass information between verification components; in the present application, the Transaction class is used to encapsulate test stimulus and monitoring data of PAD signals, which can contain two types of variables: a string for storing signal names and a dynamic array for storing data to be sent or captured, with a default size of 32 bits, but which can be adjusted as needed.

[0055] It can be understood that through the Transaction class, the application allows users to customize the size of the stimulus data, and provides flexibility in data transmission through the transmission of random single-bit dynamic arrays. The unconstrained dynamic array will automatically allocate 32 spaces and randomize the single-bit array in it, ensuring that the data will not be completely randomized to 0 or 1.

[0056] In some embodiments, the Dr iver class is a component in UVM for driving test stimulus to the chip under test, responsible for converting the data in the Transaction class into actual signal driving and transmitting it to the pins of the chip under test; in the present application, the Dr iver class obtains the Transaction class from the environment and drives the data in it to the PAD of the IOMUX module on each clock rising edge, while driving the monitoring enable signal to prompt the Mon itor class to start working.

[0057] It can be understood that in the driver design, the randomized data of the transact ion and the signal to be driven are obtained, and serial driving is performed according to the space size of the dynamic array, while the enable signal is driven to prompt the monitor to start working.

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

[0059] It can be understood that the present application instantiates the same number of monitors as the number of interfaces in the environment, each monitor corresponding 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, facilitating subsequent comparison.

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

[0061] In some embodiments, the Reference_Model class is a component in UVM for simulating the ideal behavior of the chip under test; in this application, the Reference_Model class can obtain the actual PAD signal from the Monitor class, and generate the corresponding expected result according to the register configuration, which is used to compare with the actual captured PAD signal to determine whether the function of the IOMUX module is correct.

[0062] It can be understood that in the reference_mode l design, the data obtained by the monitor and the data configured by the register are connected to the reference_mode l. The model writes corresponding functions according to the number of PADs, each function returns the transact ion corresponding to the current PAD, and passes it to the scoreboard, ensuring that it fully meets the design requirements of IOMUX.

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

[0064] It can be understood that the main purpose of the scoreboard is to compare the PAD data and the data returned by the reference_model. The PAD transaction captured by the monitor is directly sent to the scoreboard. If the PAD transaction is consistent with the transaction data returned by the reference_model, it is considered to be 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 fail.

[0065] In some embodiments, the Environment class is a top-level container in UVM for managing all verification components; in this application, the Environment class instantiates the Agent class, the Reference_Model class and the Scoreboard class of the IOMUX module and the AMBA module, forming 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, ensuring 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 testing needs.

[0067] In some embodiments, the base_test class is a top-level test class in UVM for starting 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, responsible for initializing the verification environment and executing specific test steps.

[0068] Based on the specific explanation of the above plurality of components, corresponding to step S120, the Monitor component is responsible for real-time monitoring of the signals 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, and the Monitor stores the captured data to realize the acquisition of the monitored signals; the Reference_Model generates the expected PAD behavior according to the configuration information, the Reference_Model of the IOMUX module uses the configuration information and the register configuration to generate the expected PAD signal sequence, and 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 the Reference_Model, if the two are consistent, it means that the IOMUX module works normally; if not, it is marked as a failure; finally, the Base_Test starts the entire verification process, and outputs the final verification report according to the comparison result of the Scoreboard, if all signals meet the expected result, the verification passes; otherwise, the verification fails, and detailed error information is provided.

[0069] Wherein, the Agent of the AMBA module and the Agent of the IOMUX module are both instantiated, AMBA (Advanced Microcontroller Bus Architecture) is used to connect processors, memories 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 signals of the IOMUX module, that is, the behavior of the input / output port.

[0070] Reference Figure 3 , Figure 3 The method flow chart for capturing a plurality of monitoring signals in the UVM-based IOMUX verification method provided by an embodiment of the application; in some embodiments, a plurality of components are instantiated to capture a plurality of monitoring signals of the IOMUX module in the chip under test, comprising:

[0071] Step S310, instantiating a plurality of virtual interfaces in the top module of the chip under test, each virtual interface corresponding to one or more pin monitoring signals 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 based on the clock block in each virtual interface;

[0073] In step S330 , the multiple virtual interfaces are delivered 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 the behavior of hardware interface in UVM, allows verification component (such as Driver class and Monitor class) to interact with the physical pins of chip under test, grabs and drives signal, in the top module of chip under test, can pass through instantiating multiple virtual interfaces, each virtual interface corresponds to one or more PADs (pins). This can ensure that all inputs, outputs and enable signals of IOMUX module can be fully monitored, and each virtual interface can correspond to one or more PADs, adapt to different IOMUX configuration scenarios, and enhance the flexibility of 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 lock) for simulating the establishment and holding time of signal driving, ensuring that the timing of the monitoring signal is correct, the clock block is also used for capturing and driving the synchronization signal, ensuring that the timing relationship of the signal meets the design requirements, and then after multiple virtual interfaces are passed to each component (such as Agent class, Driver class, Monitor class etc.) in the UVM environment, these components can be enabled to access and operate the monitoring signal.

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

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

[0078] Step S420: Generate a test stimulus through the Transaction class; transmit the test stimulus to the pin of the chip under test through the Driver class and generate a drive signal;

[0079] Step S430: Obtain, 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 Transaction class, the Driver class and the Monitor class are respectively instantiated by the Agent class, and the corresponding Agents are respectively created for the IOMUX module and the AMBA module. In this way, the verification of the IOMUX module and the AMBA module can be independently carried out, while the interaction can be carried out when needed; further, the Transaction class is used to encapsulate the data structure of the test stimulus, the test stimulus is generated by the Sequencer class and is transmitted to the Driver class, and the Driver class is responsible for converting the test stimulus in the Transaction class into an actual signal drive and transmitting it to the pin of the chip under test. On each clock rising edge, 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 real-time monitoring of the signal change on the PAD. After the Driver class sends the drive signal, the Monitor class responds to these signals, captures the actual signal change on the PAD, and stores the captured data in a dynamic array. The signal data captured by the Monitor class is transmitted to the Reference_Model class and the Scoreboard class through a broadcast mechanism, so as to be compared and verified subsequently; it can be understood that the Monitor class can capture the signal change on the PAD in real time, so as to ensure that the verification platform can obtain the actual PAD behavior in time and avoid verification errors caused by delay

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

[0083] In step S510, the Reference_Model class and the Scoreboard class are instantiated by the Environment class.

[0084] In step S520, the Reference_Model class obtains the monitored signals from the Monitor class and generates corresponding expected results according to the pin number and the register configuration of the chip under test.

[0085] In step S530, the Scoreboard class compares the monitored signals obtained by the Monitor class with the expected results to obtain a comparison result.

[0086] It can be understood that the Reference_Mode l class and the Scoreboard class are instantiated through the Environment class to form a complete verification environment, and the Environment class is also responsible for managing the data flow and communication mechanism between the components, the Reference_Mode l 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_Mode l class to obtain a comparison result. If they are consistent, it means that the IOMUX module works normally; if they are not consistent, a warning is issued or marked as failed to help developers quickly locate the problem.

[0087] In some embodiments, the Transaction class, the Driver class and the Monitor class are instantiated through the Agent class, including: the Transaction class, the Driver class and the Monitor class of the IOMUX module and the AMBA module in the chip under test are instantiated through the Agent class respectively; the data of the Transaction class corresponding to the Monitor class of the IOMUX module is connected to the Reference_Mode l class and the Scoreboard class through a broadcast mechanism; the data of the Transaction class corresponding to the Monitor class of the AMBA module is connected to the Reference_Mode l class, and the Transaction class data returned by the Reference_Mode l class is connected to the Scoreboard class; it can be understood that the verification of the IOMUX module and the AMBA module is independent, which ensures the correctness of the function of each module, at the same time, through the cooperative work of the Reference_Mode l class and the Scoreboard class, the verification platform can comprehensively verify the influence 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, which ensures the efficiency and cooperation of the verification process.

[0088] Reference Figure 6 , Figure 6In the UVM-based IOMUX verification method provided by an embodiment of the present application, a structural schematic diagram of a script analysis module is shown in the figure; wherein, ParseExce l.pm is a basic script, used for processing an Exce l file, the script is initialized by passing the Exce l file name to variable $Workbook and the worksheet name to $Worksheet, a specific cell $ce l l is located by specifying the row number $row and the column number $co l, and a value obtaining function is called to obtain the value of the $ce l l.

[0089] ParseReg.pm is a register analysis script, which imports ParseExce l.pm as a module and stores in variable $Exce l, takes the range of the row where the register is located as the key of array $Reg[], takes the number of registers as the number of keys, obtains the register name, offset address and bit width by specifying the key value, and stores them in $reg_name, $reg_addr and $reg_width respectively, takes the number of register fields under the register as the number of keys of array $func_reg[], takes the range obtained by each line as the key, obtains the register field name, bit width, readable and writable state and default value by specifying the key value, and stores them in $func_reg_name, $s ize, $access and $reset_va l ue respectively.

[0090] ParseIO.pm is an IO analysis script, which imports ParseExce l.pm as a module and stores in variable $Excel, takes the range of the row where the PAD is located as the key of array $PAD[], takes the number of PADs as the number of keys, obtains the PAD name by specifying the key value and stores it in $pad_name, takes the number of functions under each PAD as the number of keys of array $func_se l[], takes the column where each function is located as the range obtained by the key, obtains the input, output, enable signal name and ID of the function by specifying the key value, and stores them in $input_name, $output_name, $oen_name and $id respectively.

[0091] Top.pm is a top-level script, which imports ParseReg.pm and ParseIO.pm as modules and stores them in variables $ParseReg and $ParseIO, matches the field name of the register script and the signal name of the IO table, obtains the register related information of the signal and the mapping information on the IOMUX after successful matching, and automatically generates a verification environment and a test excitation file according to the obtained information.

[0092] The "generate verification environment components" is a process of finally generating verification environment components based on the analysis results of all the above steps.

[0093] As shown in Figure 6 , the whole flow shows how to extract register and IO information from Excel table and use it for the process of automatically generating verification environment components.

[0094] Referring to Figure 7 , Figure 7 In the UVM-based IOMUX verification method provided by an embodiment of the present application, a method flowchart for constructing multiple components in a UVM verification environment is provided. In some embodiments, the configuration table file includes a register table and an IO table. Based on a preset script, the configuration table file of the chip under test is parsed to construct multiple components in the UVM verification environment, including:

[0095] Step S710, a basic script for parsing the table file is created;

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

[0097] Step S730, a top-level script is created, and the register parsing script and the IO parsing script are imported into the top-level script as modules;

[0098] Step S740, based on the top-level script, the register table and the IO table are parsed to obtain the register information and the IOMUX mapping information of the chip under test, and multiple components in the UVM verification environment are constructed according to the register information and the IOMUX mapping information.

[0099] Corresponding 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 the detailed steps and their explanations:

[0100] Step S710: The basic script ParseExcel.pm is used to process the parsing of Excel files. The script is initialized by passing the Excel file name to the variable $Workbook and the worksheet name to the $Worksheet. By specifying the row number $row and the column number $co l, a specific cell $ce l l is located. The value function is called to obtain the value of $ce l l from $ce l l, and the data in each cell of the Excel file is read.

[0101] Step S720: the register parsing script ParseReg.pm imports the ParseExcel.pm as a module, stores it in the variable $Excel, takes the range of the line where the register is located as the key of the array $Reg[], takes the number of registers as the number of keys, and obtains the name, offset address and bit width of the register by specifying the key value, and stores them in $reg_name, $reg_addr and $reg_width respectively. The number of register fields under the register is taken as the number of keys of the array $func_reg[], and each line is taken as the range of the key obtained. The name, bit width, read-write status and default value of the register field are obtained by specifying the key value, and are stored in $func_reg_name, $size, $access and $reset_value respectively. Thus, the parsing of the register table is realized.

[0102] Step S730: the IO parsing script ParseIO.pm imports the ParseExcel.pm as a module, stores it in the variable $Excel, takes the range of the line where the PAD is located as the key of the array $PAD[], takes the number of PADs as the number of keys, and obtains the name of the PAD by specifying the key value, and stores it in $pad_name. The number of functions under each PAD is taken as the number of keys of the array $func_sel[], and the column where each function is located is taken as the range of the key obtained. The input, output, enable signal name and ID of the function are obtained by specifying the key value, and are stored in $input_name, $output_name, $oen_name and $id respectively. Thus, the parsing of the IO table is realized.

[0103] Step S740: the top-level script Top.pm is created, which is responsible for coordinating the entire parsing and generation process. The ParseReg.pm and ParseIO.pm are imported as modules and stored in the variables $ParseReg and $ParseIO respectively. Thus, the register information and IO information can be matched, and the components in the UVM verification environment can be generated according to the matching result.

[0104] It can be understood that Top.pm can automatically call ParseReg.pm and ParseIO.pm, and generate a UVM verification environment according to a parsing result, thereby reducing a workload of manual configuration and improving verification efficiency. The Top.pm automatically generates a plurality of components in the UVM verification environment, which can 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, so as to improve the construction efficiency of the verification environment and simplify the verification process.

[0105] To sum up, the application automatically generates a verification environment and a test case through a script, simplifies the construction process of the verification environment, improves the efficiency, and parses a register table and a mapping relationship table of the IOMUX through the script, automatically generates corresponding interface, monitor and reference_model, and matches a domain name of the register table and a signal name of the mapping relationship table, to generate a case or other components, which can effectively shorten the construction time of the verification environment.

[0106] To achieve the above object, a second aspect of the embodiment of the application provides an IOMUX verification platform based on UVM. The IOMUX verification platform is connected with a chip under test. The IOMUX verification platform comprises: a script parsing module, configured to parse a configuration table file of the chip under test based on a preset script, so as to construct a plurality of components in a UVM verification environment; and a verification environment module, configured to instantiate the plurality of components, so as to capture a plurality of monitoring signals of an IOMUX module in the chip under test, compare the plurality of monitoring signals with generated expected results, and realize IOMUX verification of the chip under test according to a comparison result.

[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 signal data through the monitoring file (monitor) and passing it to the behavioral level model (reference_model l) 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, further automating 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 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 This is a structural diagram of an electronic device provided in an embodiment of the present application. The electronic device 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 Method 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 bus connection is taken as an example.

[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 can include a high-speed random access memory, and can also include a non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state memory device. In some embodiments, the memory 820 can optionally include a memory 820 disposed remotely with respect to the processor 810, which can be connected to the electronic device 800 through a network, and examples of the above 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, the processor executes the computer program according to the preset interval time to execute the UVM-based IOMUX verification method of any one of the above embodiments.

[0113] Those skilled in the art can understand that, Figure 8 The device structure shown in the above description is not a limitation on the electronic device 800, and can include more or fewer components than shown, or combine certain components, or different component arrangements.

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

[0115] Based on the hardware structure of the above electronic device 800, various embodiments of the UVM-based IOMUX verification device of the present application are proposed, and the non-transitory software programs and instructions required to realize the UVM-based IOMUX verification method of the above embodiments are stored in the memory, and when executed by the processor, the UVM-based IOMUX verification method of the above embodiments is executed.

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

[0117] The apparatus embodiments described above are merely illustrative, wherein the units described as separate components can or can not be physically separate, i.e., can be located in one place, or can be distributed to multiple network nodes. Part or all of the modules can be selected according to actual needs to achieve the purpose of the embodiment.

[0118] Those skilled in the art can understand that all or some steps in the method disclosed above can be implemented as software, firmware, hardware and appropriate combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, a digital signal processor or a microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software can be distributed on a computer readable medium, which can include a computer readable storage medium (or non-transitory medium) and a communication medium (or transitory 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 storage of information such as computer readable instructions, data structures, program modules or other data. The computer readable storage medium includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. In addition, it is known to those skilled in the art that communication media generally includes computer readable instructions, data structures, program modules or other data in modulated data signals such as carrier waves or other transport mechanisms, and can include any information delivery medium.

[0119] The above is a specific description of the preferred embodiments of the present application, but the present application is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or replacements without departing from the spirit of the present application, and these equivalent modifications or replacements 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; Instantiating the 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; The configuration table file includes a register table and an IO table. 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: 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 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.

2. the IOMUX verification method based on UVM according to claim 1, is characterized in that, 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 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, is 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 a plurality of components in a UVM environment, so as to access and operate a 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, is characterized in that, The accessing and operating 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 drive 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, is 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 corresponding expected results according to the number of pins and register configuration of the chip under test; 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, is characterized in that, The instantiation of the Transaction class, the Driver class, and the Monitor class through the Agent class includes: The Transaction class, Driver class and Monitor class of the IOMUX module and 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. 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 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 for instantiating 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; The configuration table file includes a register table and an IO table. 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: 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 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. 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 6 is implemented.

9. 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 6.

Images