NFC tag chip verification system based on UVM

Abstract

The invention provides an NFC tag chip verification system based on a UVM. The NFC tag chip verification system comprises a UVM platform, a reader and an NFC tag chip. The UVM platform outputs the first verification event data on the main path of the verification event data set to the reader one by one, and when the reader carries out simulation verification on the NFC tag chip according to the first verification event data, if the first verification event data is preset node task data, the first verification event data is the preset node task data; obtaining state configuration parameters after the reader executes the preset node task data, and obtaining a plurality of state configuration parameters; after the reader completes simulation verification on the NFC tag chip according to the first verification event data of the main path, the UVM platform outputs selected target state configuration parameters and a plurality of second verification event data on the corresponding branch paths to the reader one by one and outputs the selected target state configuration parameters and the second verification event data to the reader; and the reader performs simulation verification on the NFC tag chip according to the target state configuration parameter and the plurality of second verification event data, so that the time consumption of simulation verification can be reduced.

Description

Technical Field

[0001] The present application relates to the field of simulation verification technology, and in particular to an NFC tag chip verification system based on UVM. Background Art

[0002] Simulation verification is a verification operation used to check whether the functions of the target to be verified are executed normally. Since the target to be verified has multiple functions that need to be simulated and verified, multiple verification event data need to be sent to the target to be verified in sequence to complete the simulation verification. However, there are two or more verification event data in the next node of some verification event data. Therefore, the prior art needs to complete the simulation verification completely, and some verification event data that have been simulated and verified need to be output to the target to be verified many times before the verification event data that has not been simulated and verified can be output to the reader for simulation verification. However, outputting the verification event data that has been simulated and verified to the target to be verified for repeated simulation verification will waste a lot of time, resulting in a huge time cost for the complete simulation verification of the target to be verified. Summary of the invention

[0003] The purpose of this application is to overcome the shortcomings and deficiencies in the prior art and provide an NFC tag chip verification system based on UVM, which can reduce the time consumption of simulation verification of the tag chip and save the time cost required for complete simulation verification.

[0004] The first aspect of the embodiment of the present application provides a UVM-based NFC tag chip verification system, including: a UVM platform, a reader and an NFC tag chip:

[0005] The UVM platform acquires a verification event data set; the verification event data set is in a tree-like relationship, the verification event data set includes a main path and a plurality of branch paths, the main path includes a plurality of first verification event data; each of the branch paths includes a plurality of second verification event data;

[0006] The UVM platform outputs each of the first verification event data on the main path to the reader one by one, so that the reader performs simulation verification on the NFC tag chip according to each of the first verification event data in turn;

[0007] When performing simulation verification according to each of the first verification event data, if the first verification event data is preset node task data, the UVM platform obtains the state configuration parameters after the reader executes the preset node task data, and obtains multiple state configuration parameters corresponding to each preset node task data; the preset node task data is the first verification event data of the next node including the first verification event data and at least one second verification event data;

[0008] After the reader completes the simulation verification of the NFC tag chip according to each of the first verification event data of the main path, the UVM platform outputs the selected target state configuration parameters and the corresponding plurality of second verification event data on the branch path to the reader one by one, so that the reader performs simulation verification on the NFC tag chip according to the plurality of second verification event data in turn;

[0009] After the reader simulates and verifies the NFC tag chip according to the several second verification event data on the branch path corresponding to the target state configuration parameters in turn, the UVM platform obtains the newly selected target state configuration parameters, and repeatedly outputs the newly selected target state configuration parameters and the several second verification event data on the corresponding branch path to the reader one by one, so that the reader simulates and verifies the NFC tag chip according to the several second verification event data in turn until all the verification event data in the verification event data set are simulated and verified.

[0010] Relative to the related art, the UVM platform of the present application can output verification event data to the reader, so that the reader can perform simulation verification on the NFC tag chip according to the received verification event data in turn, if the verification event data is preset node task data, obtain the state configuration parameters after the reader executes the preset node task data, to obtain multiple state configuration parameters corresponding to each preset node task data, and then after the reader completes the simulation verification according to the verification event data of the current path, the target state configuration parameters selected from the multiple state configuration parameters and the verification event data on the corresponding branch path are output to the reader, so that the reader performs simulation verification on the NFC tag chip according to the verification event data on the branch path, until all the verification event data in the verification event data set are simulated and verified. When the reader needs to perform simulation verification on the verification event data on the branch path for the NFC tag chip, the target state configuration parameters can be directly output to the reader, so that the reader performs simulation verification on the verification event data on the branch path from the target state configuration parameters, without repeatedly outputting some verification event data that have been simulated and verified to the reader, which can effectively reduce the time consumption of simulation verification of the tag chip and save the time cost required for complete simulation verification.

[0011] In order to provide a clearer understanding of the present application, the specific implementation of the present application will be described below in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 This is a connection diagram of a UVM-based NFC tag chip verification system according to an embodiment of the present application.

[0013] Figure 2A schematic diagram of a UVM platform according to an embodiment of the present application.

[0014] Figure 3 A schematic diagram of the connection between the register model of the UVM platform and the reader according to an embodiment of the present application.

[0015] 100. Simulation verification system; 101. UVM platform; 102. Reader; 103. NFC tag chip. DETAILED DESCRIPTION

[0016] In order to make the objectives, technical solutions and advantages of the present application more clear, the embodiments of the present application will be further described in detail below with reference to the accompanying drawings.

[0017] It should be clear that the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the embodiments of the present application.

[0018] When the following description relates to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. In the description of the present application, it should be understood that the terms "first", "second", "third", etc. are only used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence, nor can they be understood as indicating or implying relative importance. For those of ordinary skill in the art, the specific meanings of the above terms in the present application can be understood according to the specific circumstances. The singular forms of "a", "said" and "the" used in the present application and the appended claims are also intended to include the majority form, unless the context clearly indicates other meanings. The words "if" / "if" used herein can be interpreted as "at the time of" or "when" or "in response to determination".

[0019] In addition, in the description of this application, unless otherwise specified, "plurality" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the associated objects are in an "or" relationship.

[0020] See also Figure 1, which is a schematic diagram of the NFC tag chip 103 verification system based on UVM of an embodiment of the present application, the NFC tag chip 103 verification system based on UVM of an embodiment of the present application includes: UVM platform 101, reader 102 and NFC tag chip 103. Wherein, UVM platform 101 is a simulation verification platform built based on UVM (Universal Verification Methodology). UVM platform 101 is connected to reader 102 and NFC tag chip 103 respectively, and reader 102 is connected to NFC tag chip 103.

[0021] The UVM-based NFC tag chip 103 verification system of this embodiment is used to perform the following:

[0022] S1: The UVM platform 101 obtains a verification event data set; the verification event data set is in a tree-like relationship, the verification event data set includes a main path and a plurality of branch paths, the main path includes a plurality of first verification event data; each of the branch paths includes a plurality of second verification event data.

[0023] The verification event data set is set by the user and is a set of verification event data for driving the reader 102 to simulate verification of each function operation. A verification event data can be an instruction for driving the reader 102 to simulate a function operation, or an event code for driving the reader 102 to simulate a function operation.

[0024] In the verification event data set in a tree-like relationship, there are multiple branch paths. Among them, for the branch path connected to the main path, the first second verification event data of the branch path is associated with a first verification event data of the main path, that is, the first second verification event data of the branch path belongs to the next node of the first verification event data. When performing simulation verification, the reader 102 needs to perform simulation verification of the first verification event data before performing simulation verification of the first second verification event data of the branch path.

[0025] S2: The UVM platform 101 outputs each of the first verification event data on the main path to the reader 102 one by one, so that the reader 102 performs simulation verification on the NFC tag chip 103 according to each of the first verification event data in turn.

[0026] Specifically, the UVM platform 101 outputs the next first verification event data to the reader 102 only after it detects that the reader 102 performs simulation verification according to the latest output first verification event data.

[0027] S3: When performing simulation verification according to each of the first verification event data, if the first verification event data is preset node task data, the UVM platform 101 obtains the state configuration parameters after the reader 102 executes the preset node task data, and obtains multiple state configuration parameters corresponding to each preset node task data; the preset node task data is the first verification event data of the next node including the first verification event data and at least one second verification event data.

[0028] The preset node task data can be preset by the user according to the first verification event data of the next node including the first verification event data and at least one second verification event data, and the preset node task data can be multiple. It should be noted that the state configuration parameters after the reader 102 executes the preset node task data are the preconditions for the reader 102 to simulate and verify the first verification event data and the second verification event data of the next node.

[0029] S4: After the reader 102 completes the simulation verification of the NFC tag chip 103 according to each of the first verification event data of the main path, the UVM platform 101 outputs the selected target state configuration parameters and the corresponding plurality of second verification event data on the branch path to the reader 102 one by one, so that the reader 102 performs simulation verification on the NFC tag chip 103 according to the plurality of second verification event data in turn.

[0030] After the simulation and verification of each first verification event data of the main path is completed, the selected target state configuration parameters are output to the reader 102, so that the reader 102 can obtain the state configuration parameters after executing the preset node task data, so that the reader 102 can immediately simulate and verify the second verification event data on the branch path corresponding to the target state configuration parameters, which can save the simulation and verification time.

[0031] S5: After the reader 102 completes the simulation verification of the NFC tag chip 103 according to the several second verification event data on the branch path corresponding to the target state configuration parameters, the UVM platform 101 obtains the newly selected target state configuration parameters, and repeatedly outputs the newly selected target state configuration parameters and the several second verification event data on the corresponding branch path to the reader 102 one by one, so that the reader 102 simulates and verifies the NFC tag chip 103 according to the several second verification event data in turn until all the verification event data in the verification event data set are simulated and verified.

[0032] After the simulation and verification of each second verification event data of the current branch path is completed, the newly selected target state configuration parameters are output to the reader 102, so that the reader 102 can obtain the state configuration parameters after executing the preset node task data, so that the reader 102 can immediately simulate and verify the second verification event data on the new branch path corresponding to the target state configuration parameters, which can save the simulation and verification time.

[0033] Compared with the related art, the UVM platform 101 of the present application can output verification event data to the reader 102, so that the reader 102 simulates and verifies the NFC tag chip 103 according to the received verification event data in turn. If the verification event data is preset node task data, the state configuration parameters after the reader 102 executes the preset node task data are obtained to obtain multiple state configuration parameters corresponding to each preset node task data, and then after the reader 102 completes the simulation verification according to the verification event data of the current path, the target state configuration parameters selected from the multiple state configuration parameters and the verification event data on the corresponding branch path are output to the reader 102, so that the reader 102 simulates and verifies the NFC tag chip 103 according to the verification event data on the branch path until all the verification event data in the verification event data set are simulated and verified. When the reader 102 needs to simulate and verify the verification event data on the branch path for the NFC tag chip 103, the target state configuration parameters can be directly output to the reader 102, so that the reader 102 can simulate and verify the verification event data on the branch path starting from the target state configuration parameters. There is no need to output some already simulated and verified verification event data to the reader 102 multiple times, which can effectively reduce the time consumption of the simulation verification of the tag chip and save the time cost required for the complete simulation verification.

[0034] In a feasible embodiment, S3: if the first verification event data is preset node task data, the UVM platform 101 obtains the state configuration parameters after the reader 102 executes the preset node task data, and obtains multiple state configuration parameters corresponding to each preset node task data, including:

[0035] S31: The UVM platform 101 obtains the task verification waveform after the reader 102 executes the preset node task data to simulate and verify the NFC tag chip 103, and the preset verification waveform corresponding to the preset node task data.

[0036] Among them, the task verification waveform refers to the waveform result monitored by the UVM platform 101 after the reader 102 executes the preset node task data, and it can also be the waveform value that reflects the task verification waveform; and the preset verification waveform corresponding to the preset node task data is pre-set by the user, and the preset verification waveform can be a waveform result or a waveform value that reflects the waveform result.

[0037] S32: If the task verification waveform is the same as the preset verification waveform, the UVM platform 101 determines the real-time configuration parameters after the reader 102 executes the preset node task data, which are the state configuration parameters.

[0038] Among them, when the task verification waveform and the preset verification waveform are both waveform results, the task verification waveform can be directly compared with the preset verification waveform. When the preset verification waveform is a waveform value, the waveform value of the task verification waveform can be obtained and then compared with the waveform value of the preset verification waveform.

[0039] In this embodiment, when the task verification waveform is the same as the preset verification waveform, it indicates that the simulation verification result of the reader 102 executing the preset node task data is normal, and the real-time configuration parameters after the reader 102 executes the preset node task data are valid and can be used as state configuration parameters, which is conducive to obtaining state configuration parameters that do not affect the simulation verification results of the second verification time data, thereby improving the accuracy of the simulation verification.

[0040] In a feasible embodiment, the S31: after the UVM platform 101 obtains the task verification waveform of the reader 102 executing the preset node task data and the preset verification waveform corresponding to the preset node task data, includes:

[0041] S33: If the task verification waveform is different from the preset verification waveform, the UVM platform 101 determines that the preset node task data simulation verification is abnormal.

[0042] Among them, the data of the preset node task data simulation verification abnormality can be displayed on the display interface of the UVM platform 101 in the form of an error.

[0043] In this embodiment, when the task verification waveform is different from the preset verification waveform, it indicates that the simulation verification result of the reader 102 executing the preset node task data is abnormal, and the real-time configuration parameters after the reader 102 executes the preset node task data are invalid and cannot be used as status configuration parameters to prevent the real-time configuration parameters with abnormal simulation verification results from affecting the accuracy of the simulation verification results of the second verification time data.

[0044] See also Figure 2In a feasible embodiment, the UVM platform 101 includes a state configuration memory (State). The state configuration memory (State) is mainly used to store the configuration information of the reader 102 working in a certain state, so as to modify the configuration information of the reader 102 through backdoor access, so that it jumps to the required specific state, such as skipping the steps of power-on reset, configuring the initial register, bus mode and ISO / IEC 14443A protocol configuration, thereby reducing a large amount of simulation time. At present, the state configuration memory (State) can store the state configuration parameters such as the wake-up card to be sent by the reader 102, anti-collision waiting and improved Miller coding sending, so that the reader 102 and the NFC tag can be directly communicated directly, so as to improve the speed of simulation verification, and the environmental test and application scenario of the NFC tag can be quickly written.

[0045] After the step of obtaining a plurality of state configuration parameters corresponding to each preset node task data, the method further comprises: storing the plurality of state configuration parameters in a state configuration memory.

[0046] Wherein, the UVM platform 101 includes a register model, the state configuration memory is connected to the register model, and the register model is connected to the reader 102. Figure 2-3 As shown, Figure 2 The state configuration memory (State) in is connected to the register model (reg_model), Figure 3 The register model (reg_model) in the UVM platform 101 is connected to the reader 102 (Reader) through backdoor access. The step S4: the UVM platform 101 outputs the selected target state configuration parameters to the reader 102, including:

[0047] S41: The UVM platform 101 displays the multiple state configuration parameters stored in the state configuration memory.

[0048] The UVM platform 101 may directly obtain data stored in the state configuration memory to display multiple state configuration parameters.

[0049] S42: The UVM platform 101 determines the selected state configuration parameter as the target state configuration parameter, and sends the target state configuration parameter from the state configuration memory to the register model, so as to be output to the reader 102 through the register model.

[0050] In a feasible embodiment, since the register model of the UVM platform 101 can establish a connection with the reader 102 through backdoor access, there is no need to additionally establish a connection relationship between the state configuration memory and the reader 102, which saves the time spent by the user to connect the UVM platform 101 and the reader 102, and the state configuration memory sends the target state configuration parameters to the reader 102 through the register model, which can improve the security of the state configuration memory storing the state configuration parameters. At the same time, since the register model can provide environmental simulation data for other modules in the UVM platform 101, the state configuration memory outputs the target state configuration parameters to the register model, which is also conducive to the UVM platform 101 simulating the state of the reader 102 according to the target state configuration parameters, so as to cooperate with the reader 102 to complete the simulation verification.

[0051] In a feasible embodiment, the verification event data stored in the verification event data set includes device verification event data and interaction verification event data.

[0052] Among them, when outputting verification event data to the reader 102, if the first verification event data or the second verification event data output to the reader 102 is device verification event data, the reader 102 performs simulation verification of the device function of the reader 102 according to the device verification event data; the device function at least includes: card searching and wake-up of the reader 102 and anti-collision function of the reader 102.

[0053] If the first verification event data or the second verification event data output to the reader 102 is interactive verification event data, the reader 102 performs simulation verification of the interactive function between the reader 102 and the NFC tag chip 103 according to the interactive verification event data; the interactive function at least includes: a reading function of the reader 102 reading the tag information of the NFC tag chip 103, and a writing function of the reader 102 writing the tag information of the NFC tag chip 103.

[0054] Among them, the NFC tag chip 103 can be Figure 2 The step of simulating and verifying the interactive function between the reader 102 and the NFC tag chip 103 according to the interactive verification event data comprises: after the reader 102 performs information interaction with the NFC tag chip 103 according to the interactive verification event data, obtaining result information of the reader 102 and tag information of the NFC tag chip 103; if the result information is the same as the tag information, determining that the simulation verification of the reader 102 corresponding to the interactive verification event data is normal; if the result information is different from the tag information, determining that the simulation verification of the reader 102 corresponding to the interactive verification event data is abnormal.

[0055] In this embodiment, the functions that the reader 102 can run independently are simulated and verified based on the device verification event data, and the functions that the reader 102 needs to run through information interaction are simulated and verified in combination with the NFC tag chip 103 based on the interaction verification event data, so that the reader 102 can be simulated and verified more comprehensively.

[0056] Below, the component modules of the UVM platform for simulation verification design of this application are described:

[0057] The UVM platform of this application integrates static components and dynamic components:

[0058] The static components include calling the run_test() method, the virtual interface module, the clock generation module, and the EEPROM memory module. The run_test() method is the entry point of the entire verification system. It is located in uvm_root and executes a specific test case by setting UVM_TESTNAME = "test_name". In this system, test cases named case are uniformly used, such as case1, case2 to casen, etc. The virtual interface module is responsible for managing the signal connection between the DUT (device to be tested, mainly NFC chip) and the verification system, including demodulation data, modulation data, enable signal, clock and reset signal, etc., to ensure that the static components and dynamic components can communicate through this interface. The clock generation module is responsible for generating the clock signal required by the platform and connecting it to the virtual interface module for use by the DUT, driver and monitoring module. The EEPROM module is used to simulate the behavior of the memory, save configuration information, record state changes, and process read and write commands.

[0059] Dynamic components are the core of the verification system, including test module, case module, environment (ENV) module, cfg module, agent module, scoreboard module, reference model (reference) module, driver module and input monitoring (monitor) module. The test module is derived from uvm_test and contains ENV and cfg modules, passing configuration parameters to the agent through the uvm_config_db mechanism.

[0060] The case module is also derived from uvm_test and is responsible for creating transaction classes such as the number of carriers, sending commands, and writing data, including the acquisition and call of the verification time data set. The case module can also start all components by instantiating ENV. The cfg module contains all the fixed parameters of the device to be tested, which improves the readability and maintainability of the code. The ENV module is derived from uvm_env and is responsible for defining and instantiating all components, including the reference model, the agent module, and the result comparison module, and describing the connection relationship between them. The agent module contains the driver, the input monitoring module, and the sequencer, allowing users to generate transactions to drive and monitor the device to be tested. The sequencer acts as a bridge between the sequence and the driver. The driver module is responsible for converting abstract transactions into specific stimulus signals and implementing functions such as CRC16 verification. The input monitoring module is responsible for monitoring the modulated signal and restoring the signal to a data packet and sending it to the result comparison module. The reference model simulates the behavior of the device to be tested based on the transaction class generated by the test case and generates the expected response. The result comparison module is responsible for comparing the output data of the input monitoring module with the response of the reference model. If they are consistent, the driver is notified to continue sending new transactions. Otherwise, an error is reported and the verification process is stopped.

[0061] The UVM testbench starts when the run_test() method is called. UVM uses a string that defines the name of the test to be executed as an input parameter and builds the corresponding test through the UVM factory mechanism. The UVM structure then enters its respective build phase by calling the build method of the test class. In this phase, the configuration of the testbench components is prepared, where virtual interfaces are assigned to the relevant testbench interfaces. Objects used to hold the test configuration data are added to the UVM configuration database. This is followed by the next level of construction, which retrieves the corresponding configuration data and builds and configures based on this configuration data. After the build phase is completed, the connect phase will begin, which completes the connection between internal components. In contrast to the top-down approach of the build phase, the connect phase is carried out in a bottom-up manner, starting from the bottom nodes of the testbench and ending at the top level. The other phases after the connect phase continue to run until all phases are completed, at which time control is passed back to the test module.

[0062] Each scenario instantiates an environment module, which further instantiates the scoreboard and master / slave agents. A master agent and a slave agent are developed in the system, and the appropriate agent can be selected for testing based on specific needs. The test cases focus on common commands such as read, write, write then read, wait then read, and wait then write. The sequence items and the data and address width of the interface are parameterized, giving the system good flexibility. Although the driver module is the most challenging due to the differences in operation sequences and signals in different reader protocols, more general functions can be achieved by adopting scenarios of the ISO / IEC 14443A protocol.

[0063] The verification process involves configuring the registers in the reader to generate a request command, which in turn transmits data to the NFC tag chip. Some registers are configured to enable the reader to exchange data with the tag (send commands). Test cases are written in the sequencer to constrain the transaction packet address and data variables, generate specific stimulus data, and configure the registers in a targeted manner so that the reader sends a request command and the NFC tag chip responds after receiving a valid request command.

[0064] Finally, the code coverage and functional coverage are collected through regression testing to complete the verification work. Regression testing is an important verification method to ensure that after fixing the defects in the design, no new problems are introduced and the validity of the previously passed test cases is maintained. Regression testing runs through the entire chip verification process. After the code coverage and functional coverage meet the design requirements, regression testing still needs to be maintained for a period of time, and only when all regression tests are passed can the verification phase be marked as over.

[0065] Regression testing is performed to collect code coverage and functional coverage. Code coverage covers multiple aspects, such as line coverage, jump coverage, state machine coverage, condition coverage, and branch coverage, which together measure the execution of the code of the device to be tested by the test cases. These coverage data are usually automatically generated using automation tools.

[0066] Functional coverage focuses on evaluating the coverage of specified functional points by test cases during the verification process, indicating which functions have been verified and which have not been verified, thereby providing a quantitative indicator of the progress of functional verification.

[0067] The device embodiments described above are merely illustrative, wherein the components described as separate parts may or may not be physically separated, and the parts displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present application. Ordinary technicians in this field can understand and implement it without creative work.

[0068] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0069] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific way, so that the instructions stored in the computer-readable memory produce a product including an instruction device, which implements the function selected in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 function selected in a box or multiple boxes.

[0070] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 steps for the function selected in a box or multiple boxes.

[0071] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0072] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0073] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0074] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0075] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included within the scope of the claims of the present application.

Claims

1. A UVM-based NFC tag chip verification system, characterized in that: include: UVM platform, reader and NFC tag chip; The UVM platform acquires a verification event data set; the verification event data set is in a tree-like relationship, the verification event data set includes a main path and a plurality of branch paths, the main path includes a plurality of first verification event data; each of the branch paths includes a plurality of second verification event data; The UVM platform outputs each of the first verification event data on the main path to the reader one by one, so that the reader performs simulation verification on the NFC tag chip according to each of the first verification event data in turn; When performing simulation verification according to each of the first verification event data, if the first verification event data is preset node task data, the UVM platform obtains the state configuration parameters after the reader executes the preset node task data, and obtains multiple state configuration parameters corresponding to each preset node task data; The preset node task data is first verification event data of the next node including first verification event data and at least one second verification event data; After the reader completes the simulation verification of the NFC tag chip according to each of the first verification event data of the main path, the UVM platform outputs the selected target state configuration parameters and the corresponding plurality of second verification event data on the branch path to the reader one by one, so that the reader performs simulation verification on the NFC tag chip according to the plurality of second verification event data in turn; After the reader completes simulation verification of the NFC tag chip according to the several second verification event data on the branch path corresponding to the target state configuration parameters, the UVM platform obtains the newly selected target state configuration parameters, and repeatedly outputs the newly selected target state configuration parameters and the several second verification event data on the corresponding branch path to the reader one by one, so that the reader simulates and verifies the NFC tag chip according to the several second verification event data in turn until all the verification event data in the verification event data set are simulated and verified.

2. The NFC tag chip verification system based on UVM according to claim 1, characterized in that, If the first verification event data is preset node task data, the UVM platform obtains the state configuration parameters after the reader executes the preset node task data, and obtains multiple state configuration parameters corresponding to each preset node task data, including: The UVM platform obtains a task verification waveform after the reader executes the preset node task data to simulate and verify the NFC tag chip, and a preset verification waveform corresponding to the preset node task data; If the task verification waveform is the same as the preset verification waveform, the UVM platform determines the real-time configuration parameters after the reader executes the preset node task data, which are the state configuration parameters.

3. The NFC tag chip verification system based on UVM according to claim 2, characterized in that, After the UVM platform obtains the task verification waveform of the reader executing the preset node task data and the preset verification waveform corresponding to the preset node task data, it includes: If the task verification waveform is different from the preset verification waveform, the UVM platform determines that the preset node task data simulation verification is abnormal.

4. The NFC tag chip verification system based on UVM according to claim 1, characterized in that, The UVM platform includes a state configuration memory; after the step of obtaining a plurality of state configuration parameters corresponding to each preset node task data, the method includes: The plurality of state configuration parameters are stored in a state configuration memory.

5. The NFC tag chip verification system based on UVM according to claim 4, characterized in that, The UVM platform includes a register model, the state configuration memory is connected to the register model, and the register model is connected to the reader; The step of the UVM platform outputting the selected target state configuration parameters to the reader comprises: The UVM platform displays the multiple state configuration parameters stored in the state configuration memory; The UVM platform determines the selected state configuration parameter as the target state configuration parameter, and sends the target state configuration parameter from the state configuration memory to the register model, so as to be output to the reader through the register model.

6. The UVM-based NFC tag chip verification system according to any one of claims 1 to 5, characterized in that: The verification event data stored in the verification event data set includes device verification event data and interaction verification event data; If the first verification event data or the second verification event data output to the reader is device verification event data, the reader performs simulation verification of the device function of the reader according to the device verification event data; The functions of the device include at least: card search and wake-up of the reader and anti-collision function of the reader; If the first verification event data or the second verification event data output to the reader is interactive verification event data, the reader performs simulation verification of the interactive function between the reader and the NFC tag chip according to the interactive verification event data; the interactive function at least includes: a reading function of the reader reading the tag information of the NFC tag chip, and a writing function of the reader writing the tag information of the NFC tag chip.

7. The NFC tag chip verification system based on UVM according to claim 6, characterized in that, The step of the reader performing simulation verification of the interaction function between the reader and the NFC tag chip according to the interaction verification event data includes: After the reader interacts with the NFC tag chip according to the interactive verification event data, obtaining result information of the reader and tag information of the NFC tag chip; If the result information is the same as the tag information, it is determined that the simulation verification of the reader corresponding to the interactive verification event data is normal; if the result information is different from the tag information, it is determined that the simulation verification of the reader corresponding to the interactive verification event data is abnormal.

Images