A UVM-based NFC tag chip verification system

Abstract

This application provides an NFC tag chip verification system based on UVM, including a UVM platform, a reader, and an NFC tag chip. The UVM platform outputs each first verification event data on the main path of the verification event data set to the reader one by one. When the reader performs simulation verification on the NFC tag chip based on each first verification event data, if the first verification event data is preset node task data, it obtains the state configuration parameters after the reader executes the preset node task data, thus obtaining multiple state configuration parameters. After the reader completes the simulation verification of the NFC tag chip based on each first verification event data on the main path, the UVM platform outputs the selected target state configuration parameters and several second verification event data on the corresponding branch path to the reader one by one. This allows the reader to start simulation verification of the NFC tag chip based on the target state configuration parameters and several second verification event data, which can reduce the simulation verification time.

Description

Technical Field

[0001] This application relates to the field of simulation verification technology, specifically to an NFC tag chip verification system based on UVM. Background Technology

[0002] Simulation verification is a verification operation used to check whether the functions of a target to be verified are executed correctly. Since the target to be verified has multiple functions requiring simulation verification, multiple verification event data need to be sent to the target sequentially to complete the simulation verification. However, some verification event data may have two or more subsequent verification event data points. Therefore, existing technologies require repeatedly outputting some already simulated verification event data to the target before outputting the unsimulated verification event data to the reader for simulation verification. Repeatedly outputting already simulated verification event data to the target for simulation verification wastes a significant amount of time, resulting in a very high time cost for the complete simulation verification of the target. 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 tag chip simulation verification and save the time cost required for complete simulation verification.

[0004] A first aspect of this application provides a UVM-based NFC tag chip verification system, comprising: a UVM platform, a reader, and an NFC tag chip.

[0005] The UVM platform acquires a set of verification event data; the set of verification event data is in a tree-like relationship, including a main path and several branch paths, the main path including multiple first verification event data; each branch path including several 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 can perform simulation verification of the NFC tag chip according to each of the first verification event data in sequence.

[0007] When performing simulation verification based on 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 of the reader after executing 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 based on each of the first verification event data of the main path, the UVM platform outputs the selected target state configuration parameters and several second verification event data on the corresponding branch path to the reader one by one, so that the reader performs simulation verification of the NFC tag chip in sequence based on the several second verification event data.

[0009] After the reader sequentially performs simulation verification on the NFC tag chip based on 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 several second verification event data on the corresponding branch path to the reader one by one, so that the reader sequentially performs simulation verification on the NFC tag chip based on the several second verification event data until all verification event data in the verification event data set has been simulated and verified.

[0010] Compared to related technologies, the UVM platform of this application can output verification event data to the reader, allowing the reader to sequentially perform simulation verification on the NFC tag chip based on the received verification event data. If the verification event data is preset node task data, the platform obtains the state configuration parameters after the reader executes the preset node task data, thus obtaining multiple state configuration parameters corresponding to each preset node task data. After the reader completes the simulation verification based on the verification event data of the current path, the platform outputs the target state configuration parameter selected from the multiple state configuration parameters and the corresponding verification event data on the branch path to the reader, enabling the reader to perform simulation verification on the NFC tag chip based on the verification event data on the branch path, until all verification event data in the verification event data set has been simulated and verified. When the reader needs to perform simulation verification on the NFC tag chip based on the verification event data on the branch path, it can directly output the target state configuration parameters to the reader, allowing the reader to start the simulation verification from the target state configuration parameters. This eliminates the need to repeatedly output some already simulated and verified verification event data to the reader, effectively reducing the time consumption of tag chip simulation verification and saving the time cost required for complete simulation verification.

[0011] To provide a clearer understanding of this application, the specific embodiments of this application will be described below in conjunction with the accompanying drawings. Attached Figure Description

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

[0013] Figure 2 This is a schematic diagram of a UVM platform according to an embodiment of this application.

[0014] Figure 3 This is a schematic diagram showing the connection between the register model of the UVM platform and the reader in one embodiment of this application.

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

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0017] It should be understood that the described embodiments are merely some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of the embodiments of this application.

[0018] In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. In the description of this application, it should be understood that the terms "first," "second," "third," etc., are used only to distinguish similar objects and are not necessarily used to describe a specific order or sequence, nor should they be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances. The singular forms "a," "the," and "the" used in this application and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise. The word "if" as used herein can be interpreted as "when," "when," or "in response to determination."

[0019] Furthermore, in the description of this application, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0020] Please see Figure 1This is a schematic diagram of an NFC tag chip 103 verification system based on UVM according to an embodiment of this application. The UVM-based NFC tag chip 103 verification system includes: a UVM platform 101, a reader 102, and an NFC tag chip 103. The UVM platform 101 is a simulation verification platform built based on UVM (Universal Verification Methodology). The UVM platform 101 is connected to both the reader 102 and the NFC tag chip 103, with the reader 102 connected to the NFC tag chip 103.

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

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

[0023] The verification event data set is set by the user and is a collection of verification event data that drives the reader 102 to simulate and verify the operation of various functions. A verification event data can be an instruction used to drive the reader 102 to simulate the operation of a function, or it can be an event code used to drive the reader 102 to simulate the operation of a function.

[0024] In the tree-structured set of verification event data, there are multiple branch paths. For a branch path connected to the main path, the first second verification event data of that branch path is associated with a first verification event data of the main path. That is, the first second verification event data of that branch path belongs to the next node of the first verification event data. During simulation verification, the reader 102 must perform simulation verification of the first verification event data before it can perform simulation verification of the first second verification event data of that 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.

[0026] Specifically, the UVM platform 101 will only output the next first verification event data to the reader 102 after it detects that the reader 102 has performed simulation verification based on the latest output first verification event data.

[0027] S3: When performing simulation verification based on 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 pre-set by the user based on the first verification event data of the next node, which includes first verification event data and at least one second verification event data. Multiple preset node task data sets are also possible. It should be noted that the status configuration parameters after the reader 102 executes the preset node task data are prerequisites for the reader 102 to perform simulation verification of the first and 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 several second verification event data on the corresponding branch path to the reader 102 one by one, so that the reader 102 performs simulation verification of the NFC tag chip 103 according to the several second verification event data in sequence.

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

[0031] S5: After the reader 102 completes the simulation verification of the NFC tag chip 103 according to the 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 second verification event data on the corresponding branch path to the reader 102 one by one, so that the reader 102 performs simulation verification of the NFC tag chip 103 according to the second verification event data in sequence until all verification event data in the verification event data set has been simulated and verified.

[0032] After the simulation 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. This allows the reader 102 to obtain the state configuration parameters after executing the preset node task data, so that the reader 102 can immediately perform simulation verification on the second verification event data on the new branch path corresponding to the target state configuration parameters, which can save simulation verification time.

[0033] Compared to related technologies, the UVM platform 101 of this application can output verification event data to the reader 102, so that the reader 102 can perform simulation verification on the NFC tag chip 103 according to the received verification event data. If the verification event data is preset node task data, the platform can obtain the state configuration parameters after the reader 102 executes the preset node task data, so as to obtain multiple state configuration parameters corresponding to each preset node task data. After the reader 102 completes the simulation verification according to the verification event data of the current path, the platform can output the target state configuration parameters selected from the multiple state configuration parameters and the verification event data on the corresponding branch path to the reader 102, so that the reader 102 can perform simulation verification on the NFC tag chip 103 according to the verification event data on the branch path, until all verification event data in the verification event data set has been simulated and verified. When the reader 102 needs to perform simulation verification of the verification event data on the branch path to the NFC tag chip 103, it can directly output the target state configuration parameters to the reader 102, so that the reader 102 can start from the target state configuration parameters to perform simulation verification of the verification event data on the branch path. This eliminates the need to output some already simulated verification event data to the reader 102 multiple times, which can effectively reduce the time consumption of the tag chip simulation verification and save the time cost required for complete simulation verification.

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

[0035] S31: The UVM platform 101 acquires the task verification waveform after the reader 102 performs simulation verification on the NFC tag chip 103 by executing the preset node task data, 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, or it can be the waveform value that reflects the task verification waveform; while the preset verification waveform corresponding to the preset node task data is set by the user in advance. The preset verification waveform can be the waveform result or the 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 status configuration parameters.

[0038] When both the task verification waveform and the preset verification waveform are 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. This is beneficial for obtaining state configuration parameters that do not affect the simulation verification result of the second verification time data, thereby improving the accuracy of the simulation verification.

[0040] In a feasible embodiment, step S31: After the UVM platform 101 acquires 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, it 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, data that is abnormal in the simulation verification of the preset node task data can be displayed in 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. 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, so as to prevent the real-time configuration parameters with abnormal simulation verification results from affecting the accuracy of the simulation verification result of the second verification time data.

[0044] Please see Figure 2In one feasible embodiment, the UVM platform 101 includes a state configuration memory. The state configuration memory primarily stores configuration information of the reader 102 operating in a specific state, allowing modification of the reader 102's configuration information via a backdoor. This enables the reader 102 to jump to a desired specific state, such as skipping steps like power-on reset, configuring the initial register, bus mode, and ISO / IEC 14443A protocol configuration, thereby significantly reducing simulation time. Currently, the state configuration memory can store state configuration parameters for the reader 102, such as pending card transmission, anti-collision waiting, and improved Miller encoding transmission. This allows the reader 102 to directly communicate with the NFC tag, improving simulation verification speed and enabling rapid development of NFC tag environmental tests and application scenarios.

[0045] After obtaining multiple state configuration parameters corresponding to each preset node task data, the step includes: storing the multiple state configuration parameters in a state configuration memory.

[0046] 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. That is, as follows... Figure 2-3 As shown, Figure 2 The state configuration memory (State) is connected to the register model (reg_model). Figure 3 The register model (reg_model) in the system establishes a connection with the reader 102 through a backdoor access. Step S4: The step of the UVM platform 101 outputting the selected target state configuration parameters to the reader 102 includes:

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

[0048] Among them, the UVM platform 101 can directly obtain the data stored in the status configuration memory to display multiple status 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 output it 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 a backdoor, there is no need to establish an additional connection between the state configuration memory and the reader 102, saving the time spent by the user in connecting the UVM platform 101 and the reader 102. Moreover, the state configuration memory can send 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 output of the target state configuration parameters by the state configuration memory to the register model is also beneficial for the UVM platform 101 to simulate 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 one feasible embodiment, the verification event data stored in the verification event data set includes device verification event data and interaction verification event data.

[0052] Specifically, 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 functions of the reader 102 based on the device verification event data; the device functions include at least: card finding 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 based on the interactive verification event data; the interactive function includes at least: the reader 102 reading the tag information of the NFC tag chip 103 and 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 NFC Tag is shown. The step of reader 102 simulating and verifying the interaction function between reader 102 and NFC tag chip 103 based on the interaction verification event data includes: after reader 102 interacts with NFC tag chip 103 based on the interaction verification event data, obtaining result information from reader 102 and tag information from NFC tag chip 103; if the result information is the same as the tag information, it is determined that the simulation verification of reader 102 corresponding to the interaction verification event data is normal; if the result information is different from the tag information, it is determined that the simulation verification of reader 102 corresponding to the interaction verification event data is abnormal.

[0055] In this embodiment, the functions that the reader 102 can operate independently are simulated and verified based on the device verification event data. Based on the interaction verification event data, combined with the NFC tag chip 103, the functions that the reader 102 needs to operate through information interaction are simulated and verified, which can more comprehensively simulate and verify the reader 102.

[0056] The following describes the component modules for simulation verification design of the UVM platform in this application:

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

[0058] The static components include the `run_test()` method, the virtual interface module, the clock generation module, and the EEPROM memory module. The `run_test()` method, located in `uvm_root`, serves as the entry point for the entire verification system. It executes specific test cases by setting `UVM_TESTNAME="test_name"`. This system uses test cases uniformly named `case`, such as `case1`, `case2`, and so on, up to `casen`. The virtual interface module manages the signal connection between the DUT (Device Under Test, primarily NFC chips) and the verification system, including demodulating data, modulating data, enabling signals, clock signals, and reset signals, ensuring communication between static and dynamic components through this interface. The clock generation module generates the clock signals required by the platform and connects them to the virtual interface module for use by the DUT, drivers, and monitoring modules. The EEPROM module simulates memory behavior, storing configuration information, recording state changes, and processing read / write commands.

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

[0060] The `case` module, also derived from `uvm_test`, is responsible for creating transaction classes such as carrier count, command transmission, and data writing, including the acquisition and retrieval of verification time data sets. The `case` module can also start all components by instantiating `ENV`. The `cfg` module contains all the fixed parameters of the device under test, improving code readability and maintainability. The `ENV` module, derived from `uvm_env`, is responsible for defining and instantiating all components, including the reference model, proxy module, and result comparison module, and describing the connections between them. The proxy module contains a driver, input monitoring module, and sequence generator, allowing users to generate transactions that drive and monitor the device under test. The sequence generator acts as a bridge between the sequence and the driver. The driver module is responsible for converting abstract transactions into concrete excitation signals and implementing functions such as CRC16 checksums. The input monitoring module monitors the modulation signal and restores the signal to data packets before sending it to the result comparison module. The reference model simulates the behavior of the device under test based on the transaction classes generated by the test cases, generating 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 match, the driver is notified to continue sending new transactions; otherwise, an error is reported and the verification process is stopped.

[0061] When the `run_test()` method is called, the UVM testing platform starts. UVM uses a string defining the name of the test to be executed as an input parameter and builds the corresponding test through the UVM factory mechanism. Then, by calling the `build` method of the `test` class, the UVM structure enters its respective build phase. In this phase, the configuration of the testing platform components is prepared, with virtual interfaces assigned to the relevant testing platform interfaces. Objects used to store test configuration data are added to the UVM configuration database. Next comes the next level of build, which retrieves the corresponding configuration data and builds and configures based on it. After the `build` phase is complete, the `connect` phase begins execution, establishing connections between internal components. Unlike the top-down approach of the `build` phase, the `connect` phase proceeds bottom-up, starting from the lowest-level nodes of the testing platform and ending at the top level. Other phases following the `connect` phase continue to run until all phases are completed, at which point control is returned to the `test` module.

[0062] Each scenario instantiates an environment module, which further instantiates a scoreboard and master / slave agents. The system includes one master agent and one slave agent, allowing for selection of the appropriate agent for testing based on specific needs. Test cases focus on common commands such as read, write, write then read, wait then read, and wait then write. Sequence items and interface data and address widths are parameterized, providing good system flexibility. While the driver module presents the greatest challenge due to differences in operation sequences and signals across various reader protocols, relatively general functionality can be achieved through scenarios using the ISO / IEC 14443A protocol.

[0063] The verification process involves configuring registers in the reader to generate request commands, thereby enabling data transmission with the NFC tag chip. Configuring certain registers allows the reader to interact with the tag (send commands). Test cases are written in a sequence generator, which generates specific stimulus data by constraining transaction packet addresses and data variables, directing the register configuration so that the reader sends request commands, and the NFC tag chip responds upon receiving a valid request command.

[0064] Finally, regression testing is used to collect code coverage and functional coverage, completing the verification process. Regression testing is an important verification method to ensure that fixing design defects does not introduce new problems and maintains the validity of previously passed test cases. Regression testing is conducted throughout the entire chip verification process. Even after code coverage and functional coverage meet design requirements, regression testing must continue for a period of time, and the verification phase can only be considered complete when all regression tests have passed.

[0065] Regression testing is performed to collect code coverage and functional coverage. Code coverage encompasses several aspects, such as line coverage, jump coverage, state machine coverage, condition coverage, and branch coverage, which together measure the execution performance of the code on the device being tested. This coverage data is typically generated automatically using automation tools.

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

[0067] The device embodiments described above are merely illustrative. The components described as separate parts may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without any inventive effort.

[0068] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0069] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function selected in one or more boxes.

[0070] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function selected in one or more boxes.

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

[0072] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0073] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0074] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0075] The above are merely 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 modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all 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 set of verification event data; the set of verification event data is in a tree-like relationship, including a main path and several branch paths, the main path including multiple first verification event data; each branch path including several 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 can perform simulation verification of the NFC tag chip according to each of the first verification event data in sequence. When performing simulation verification based on 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, which includes first verification event data and at least one second verification event data. After the reader completes the simulation verification of the NFC tag chip based on each of the first verification event data of the main path, the UVM platform outputs the selected target state configuration parameters and several second verification event data on the corresponding branch path to the reader one by one, so that the reader performs simulation verification of the NFC tag chip in sequence based on the several second verification event data. After the reader sequentially completes the simulation verification of the NFC tag chip based on 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 several second verification event data on the corresponding branch path to the reader one by one, so that the reader sequentially performs simulation verification of the NFC tag chip based on the several second verification event data until all verification event data in the verification event data set has been simulated and verified.

2. The UVM-based NFC tag chip verification system according to claim 1, characterized in that, If the first verification event data is preset node task data, the UVM platform obtains the status configuration parameters after the reader executes the preset node task data, and obtains multiple status configuration parameters corresponding to each preset node task data, including: The UVM platform obtains the task verification waveform after the reader executes the preset node task data to simulate and verify the NFC tag chip, as well as the 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 of the reader after executing the preset node task data, which are the status configuration parameters.

3. The UVM-based NFC tag chip verification system according to claim 2, characterized in that, After the UVM platform acquires 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 UVM-based NFC tag chip verification system according to claim 1, characterized in that, The UVM platform includes a state configuration memory; after obtaining multiple state configuration parameters corresponding to the task data of each preset node, the steps include: The plurality of state configuration parameters are stored in the state configuration memory.

5. The UVM-based NFC tag chip verification system 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 includes: The UVM platform displays the plurality of 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 output it to the reader through the register model.

6. The UVM-based NFC tag chip verification system according to any one of claims 1-5, characterized in that, The verification event data set stores verification event data including 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 reader's device functions based on the device verification event data. The device functions include at least: card-finding wake-up function 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 interaction function between the reader and the NFC tag chip based on the interactive verification event data; the interactive function includes at least: the reader's function of reading tag information from the NFC tag chip and the reader's function of writing tag information to the NFC tag chip.

7. The UVM-based NFC tag chip verification system according to claim 6, characterized in that, The steps of simulating and verifying the interaction function between the reader and the NFC tag chip based on the interaction verification event data include: After the reader interacts with the NFC tag chip based on the interactive verification event data, the reader obtains the result information and the 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 interactive verification event data corresponding to the reader is normal; if the result information is different from the tag information, it is determined that the simulation verification of the interactive verification event data corresponding to the reader is abnormal.

Images