CN112069074A - RFID tag chip verification device based on UVM - Google Patents
RFID tag chip verification device based on UVM Download PDFInfo
- Publication number
- CN112069074A CN112069074A CN202010935322.0A CN202010935322A CN112069074A CN 112069074 A CN112069074 A CN 112069074A CN 202010935322 A CN202010935322 A CN 202010935322A CN 112069074 A CN112069074 A CN 112069074A
- Authority
- CN
- China
- Prior art keywords
- module
- driver
- test
- dut
- uvm
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Tests Of Electronic Circuits (AREA)
Abstract
The invention relates to a UVM-based RFID tag chip verification device, which comprises a static component: the device comprises a virtual interface module, a run _ test () calling method, a clock generating module, a DUT (device under test) of the RFID tag and an EEPROM (electrically erasable programmable read-only memory) module. The dynamic component comprises a base _ test module, a my _ case module, an ENV module, a CONFIGURATION module, an agent module, a scoreboard module, a reference module, a driver module and a monitor module. The invention adopts UVM methodology, so that the verification efficiency is higher, the verification level is clear, and the verification efficiency and the credibility are improved by generating different test cases and a large number of randomized tests.
Description
Technical Field
The invention belongs to the field of chip verification. And more particularly to a digital system verification method for tag chips.
Background
With the complex functions of the high-frequency or ultrahigh-frequency RFID tag chip digital system module, the difficulty in protocol implementation and verification is increased, and the verification work becomes an important link in the tag chip design.
The traditional verification method needs a large amount of directional excitation, and the verification efficiency is low due to artificial detection of waveform verification. The invention builds a brand-new label chip digital Verification system based on UVM (Universal Verification method), completes the RTL function Verification of the label chip and effectively solves many defects of the traditional Verification method.
Disclosure of Invention
Fig. 2 is a diagram of a UVM-based RFID tag chip verification tree architecture, which can be classified into static components and dynamic components according to a broad category:
the static components include a call run _ test () method, a virtual interface module, a clock generation module, a DUT for an RFID tag, and an EEPROM memory module.
Further, calling run _ test () method in the initial block is an entry of the entire authentication apparatus. It is a function in uvm _ root. When the simulation command is executed, the test case is executed by UVM _ TESTNAME ═ test _ name ". In the invention, the uniform test case name my _ case is used, and the same file my _ case. When the test environment is operated each time, each different test case is copied to the fixed directory, and the test device can be operated by using the same set of test script.
Further, the virtual interface module includes all signals that the DUT is connected to the authentication device. Including signals to demodulate data, modulate data, demodulate enable, modulate enable, clock, reset, etc. Since direct communication between the static and dynamic components is not possible, a virtual interface module is required to enable communication of the test apparatus (dynamic component) with the DUT (static component). It is independent from each module, so that the influence of frequent change of module interface on the module is reduced.
Further, the clock generation module is used for generating a series of clock signals used in the RFID system and is connected to the virtual interface module. The DUT in the static module, the driver of the dynamic module and the input monitoring module are all connected to the clock signal through the virtual clock module.
Further, the DUT of the RFID tag is a tag design module and is a module to be tested for a verification module. In the invention, all input and output signals of the DUT are connected to the virtual interface module, and then the input demodulation signal of the DUT is connected with the output signal of the driver through the virtual interface module, and the output modulation signal of the DUT is connected with the input monitoring (monitor) module.
Further, the EEPROM module stores configuration information that needs to be obtained when various DUTs are powered on, information that needs to be recorded when powered off, and data operations in the read-write command. The EEPROM module simulates the erasing and reading behaviors of an actual EEPROM and performs data interaction with a DUT.
The dynamic component is a key component of the verification system and comprises a base _ test module, a my _ case module, an ENV module, a CONFIGURATION module, an agent module, a scoreboard module, a reference module, a driver module and a monitor module.
Further, the base _ test block is derived from uvm _ test. Called by the static component run _ test. It contains ENV and CONFIGURATION modules. And simultaneously transmitting all CONFIGURATION parameters in the CONFIGURATION module into the agent in a CONFIGURATION mode of uvm _ config _ db.
Further, the my _ case module is derived from base _ test. The base _ test module is derived from UVM _ test, so all test cases are derived from UVM _ test in the UVM platform verification. In the test case, Transaction types transactions required for framing, such as the number of carriers, send commands, write data, and the like, are generated. In the test case my _ case, instantiation of all components is realized by instantiating ENV, so the Transaction class Transaction is synchronously sent to the reference module, the driver module and the monitor module.
The CONFIGURATION is a base class. It contains all the curing parameters required in the RFID tag design and does not require randomization. May be invoked by all components in the ENV. The module is mainly used for increasing the readability and the easy modification of the verification platform code.
The ENV module is derived from uvm _ ENV, which defines all the components. By instantiating the ENV, instantiation of all components is achieved. In the authentication apparatus, the components instantiated by the ENV include a reference model (reference), an agent module (agent) and a result comparison module (scoreboard), wherein the agent module comprises a driver, an input monitoring module and a Sequencer (Sequencer). The ENV module also describes the connection relationships between the various components: the output array of the input monitoring module in the agent module is connected to the result comparison module (scoreboard); the output array of the reference model (reference) is connected to the result comparison module (scoreboard); the transaction classes of the driver modules in the agent module are linked into a reference model (reference).
The agent module comprises a driver, an input monitoring module and a sequence generator. The agent module contains all modules of the same protocol type, with the purpose of providing an authentication component that allows the user to generate drivers and monitor DUT transactions (monitors). At the same time, the driver module connects the transaction class to the input monitor module (monitor).
The Sequencer (Sequencer) of the agent module, which communicates between the sequence and the drive, acts as a bridge. Upon receiving a request from the driver (driver), the sequencer transmits the Transaction class (Transaction) in the test case to the driver (driver).
The driver module is used for converting the abstract transaction class sent by the sequence generator into actual excitation. The signal generated by the driver module simulates the demodulated signal and generates a specific frame format based on the transaction class. The driver module functions include generating a header (sof), generating a frame content (payload), CRC16 verification, random number reading, data encryption, generating a trailer (eof), and error format injection. In the invention, a CRC check and encryption module of a driver module is generated by directly calling a C + + function in a DPI mode.
And the input monitoring module (monitor) is used for monitoring a modulation signal connected with the RFID to-be-detected label in the virtual interface. In the invention, the transaction class comprises parameters of a modulation mode and transmits the parameters to the DUT to be tested through a demodulation signal. The input monitoring module (monitor) restores the modulation signal of the DUT (device under test) to a data packet, and sends the data packet to the scoreboard module after detecting the CRC16 without error.
The reference model (reference) is a behavior model for simulating the DUT (device under test) of the tag to be tested according to the transaction class generated by the test case. In the invention, the behavior model of the tag generates three responses according to the protocol: no response, a successful response, or a failed response. In the invention, no response means that the modulation signal has no 01 jump, so 8 bits are all 1 instead of being stored in scoreboard; in the invention, successful response refers to correct reply to the protocol command and possibly accompanies read-write operation to the EEPROM; in the invention, the failure response means that the transmitted demodulation signal has error injection or the command format does not support. All three response replies are sent to the scoreboard module in packet form for comparison with the packet generated by the monitor.
The result comparison (scoreboard) module is a module that compares results. And comparing whether the output data of the input monitoring monitor module is consistent with the reference model (reference). If the result is consistent, the driver is informed to send the next Transaction class (Transaction); if the comparison fails, UVM _ ERROR is reported, and the verification process is stopped.
An RFID tag chip verification device based on UVM comprises the following steps:
1. the verification device is set up as shown in figure 1. Initializing the verification device and generating a system clock signal.
2. A reset signal is sent in the driver to reset the verification device and the DUT to be tested.
3. The driver sends a request to a sequencer (sequencer) to obtain the transaction class, which obtains the transaction class from the test case and sends it to the driver. And then the transaction class is sent to the reference model and the input monitoring module through the verification device.
4. The driver generates a frame signal according to the transaction class and sends the signal to the virtual interface; and simultaneously sending an indication signal to the input monitoring module.
5. When the DUT successfully receives the frame signal sent by the driver, it sends a correct response reply as required by the protocol. And after the input monitoring module receives the indication signal sent by the driver, the input monitoring module starts to search the modulation signal. The input monitoring module searches the modulation signal successfully according to the configuration in the transaction class in the time specified by the protocol, and then transmits the received data packet to the result comparison module through the interface.
6. The reference model module obtains the transaction class from the driver, obtains an expected response that the tag RFID should give according to the transaction parameter configuration, and transmits the response value to the result comparison module.
7. The result comparison module compares the two arrays of the input monitoring module and the reference model, and if the results are consistent, the result comparison module informs the driver to send a next request to the sequencer to acquire a new transaction class; if the results are not consistent, an error is reported, and the simulation is stopped.
The invention brings several benefits to the digital verification of the tag chip:
1. the traversal of the corner case is increased by using a randomization test in the test case.
2. The structure and the function of the driver, the reference model, the input monitoring module, the result comparison module and other modules are clear, and the platform is built flexibly.
3. The virtual interface module reduces the connection work among the modules, and can be flexibly applied only by defining the signal name in the virtual interface module.
4. The error frame injection mechanism is more convenient.
UVM's Direct Program Interface (DPI) enables system verilog language to interact with C + + language implementations. Some complex C + + language encryption algorithms can be directly imported for use.
The verification system and the verification method can verify single commands, verify specific and random command streams and automatically check verification results.
Drawings
Fig. 1 is a diagram of an exemplary UVM-based RFID tag verification platform architecture according to the present invention.
Fig. 2 is a circuit diagram illustrating an exemplary UVM-based RFID tag authentication function according to the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is further described in detail based on the ISO/IEC 15693 protocol with reference to the accompanying drawings and examples. The specific embodiments described herein are merely illustrative of the invention and are not intended to be limiting.
As shown in fig. 2, the clock generation module generates a clock (13.56Mhz) and sends the clock to a virtual interface module (virtual interface). Sv in the verify top level module (top _ tb. sv), the clock in the virtual interface module is connected to the clock input terminal at the top level of the DUT. The driver and the input monitor module may call the clock signal in the virtual interface module.
As shown in FIG. 2, the test case generates a required Transaction class (Transaction), which includes parameters required for framing, such as vcd2vicc _ data _ code, select _ flag, uid _ en, cmd _ code, afi _ flag, dsfid _ en, and the like. The transaction class is sent to the driver (driver) through the sequence (sequence) and the sequence generator (sequence), and the driver sends the transaction class to the input monitoring module (monitor) and the reference model (reference model). The factorary mechanism in the transaction classes can store all the transaction classes in the memory for being called by each subsequent module component; the transaction class module remains unchanged during run-time until the new transaction class overwrites the old transaction class; and generating constraint ranges of all parameters in the transaction type module according to design requirements, and if the test case does not set a specific value for the transaction type, using a certain random value in the constraint range as a parameter of a subsequent module.
As shown in fig. 2, the driver (driver) receives the transaction class configuration value, the clock of the virtual module and the DPI function of C + + from the sequencer (sequencer). Depending on the parameter configuration, such as device type, transmission rate, command, frame format, CRC check type and error injection, etc., the driver generates a corresponding modulated signal, which is coupled into the virtual interface module.
As shown in fig. 2, the input monitoring module (monitor) receives the transaction class configuration value transmitted by the driver (driver), the clock of the virtual module, and the indication signal sent by the driver (driver). The driver (driver) sends an indication signal to tell the detection module that the modulation signal has been sent, the input monitoring module (monitor) starts to search for the frame header according to the transaction type configuration (such as receiving rate, carrier number and command, etc.), and a timeout counter counts synchronously. The label outputs corresponding modulation signals according to the parameter requirements of the test case, for example, the modulation signals in the ISO15693 protocol include four subcarrier decoding algorithms with different rates, namely, single carrier low rate, single carrier high rate, double carrier low rate and double carrier high rate. When the required frame header (sof) is monitored, the input monitoring module (monitor) puts the received data payload into the dynamic array, and the monitor pushes the dynamic array into the scoreboard until the frame tail (eof) is monitored and the crc check is confirmed to be correct. If the header signal is not received within the time specified by the protocol, a timeout signal is generated, and 8 bits of all 1 data are pushed into the scoreboard to indicate that the modulation signal is not received.
As shown in fig. 2, the reference model (reference) receives the Transaction class configuration value (Transaction) transmitted by the driver (driver), generates response data corresponding to the tag, and pushes the response data to the scoreboard.
As shown in fig. 2, the result comparing module (scoreboard) receives the data from monitor and reference, and if they are equal, informs the driver to send the next sequence; if not, the operation is stopped, and an error report is generated for debug.
As shown in fig. 2, the virtual interface module mainly includes a clock signal generated by the clock module, a demodulation signal of the driver, a demodulation enable signal, a modulation signal of the module to be tested, and a modulation enable signal of the module to be tested.
As shown in fig. 2, the Memory is a global variable, and generally consists of two major parts, namely a user operable area and a configuration area, and the size of the Memory is determined according to the actual tag design. Various types of information strongly related to the tag, such as user information (uid) and a password, transmitted from a driver (driver) are stored in the allocation area in the Memory. The reference model (reference) module also accesses the user operation area of the Memory when receiving a read or write operation.
Because the UVM has a complete verification device structure, the structure of the built platform is very clear.
The above description is only for the specific embodiments of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present invention, and all the changes or substitutions should be covered within the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the appended claims.
Claims (2)
1. The utility model provides a RFID label chip verifying attachment based on UVM which characterized in that: the static component comprises a run _ test () calling method, a virtual interface module, a clock generating module, a DUT module of the RFID tag and an EEPROM memory module; the dynamic components include a base _ test module, a my _ case module, an Environment (ENV) module, a CONFIGURATION module, an agent module, a result comparison (scoreboard) module, a reference model (reference) module, a driver module, and an input monitor module.
The static components include a call run _ test () method, a virtual interface module, a clock generation module, a DUT for an RFID tag, and an EEPROM memory module.
The call run _ test () method in the initial block is the entry to the entire authentication apparatus. It is a function in uvm _ root. When the simulation command is executed, the test case is executed by UVM _ TESTNAME ═ test _ name ". In the invention, the uniform test case name my _ case is used, and the same file my _ case. When the test environment is operated each time, each different test case is copied to the fixed directory, and the test device can be operated by using the same set of test script.
The virtual interface module contains all signals that the DUT is connected to the verification device. Including signals to demodulate data, modulate data, demodulate enable, modulate enable, clock, reset, etc. Since direct communication between the static and dynamic components is not possible, a virtual interface module is required to enable communication of the test apparatus (dynamic component) with the DUT (static component). It is independent from each module, so that the influence of frequent change of module interface on the module is reduced.
The clock generation module is used for generating a series of clock signals used in the RFID system and is connected to the virtual interface module. The DUT in the static module, the driver of the dynamic module and the input monitoring module are all connected to the clock signal through the virtual clock module.
The DUT of the RFID tag is a tag design module and is a module to be tested for a verification module. In the invention, all input and output signals of the DUT are connected to the virtual interface module, and then the input demodulation signal of the DUT is connected with the output signal of the driver through the virtual interface module, and the output modulation signal of the DUT is connected with the input monitoring (monitor) module.
The EEPROM module stores configuration information required to be obtained when various DUTs are powered on, information required to be recorded when the DUTs are powered off and data operation in a read-write command. The EEPROM module simulates the erasing and reading behaviors of an actual EEPROM and performs data interaction with a DUT.
The dynamic component is a key component of the verification system and comprises a base _ test module, a my _ case module, an ENV module, a CONFIGURATION module, an agent module, a scoreboard module, a reference module, a driver module and a monitor module.
The base _ test block is derived from uvm _ test. Called by the static component run _ test. It contains ENV and CONFIGURATION modules. And simultaneously transmitting all CONFIGURATION parameters in the CONFIGURATION module into the agent in a CONFIGURATION mode of uvm _ config _ db.
The my _ case module is derived from base _ test. The base _ test module is derived from UVM _ test, so all test cases are derived from UVM _ test in the UVM platform verification. In the test case, Transaction types transactions required for framing, such as the number of carriers, send commands, write data, and the like, are generated. In the test case my _ case, instantiation of all components is realized by instantiating ENV, so the Transaction class Transaction is synchronously sent to the reference module, the driver module and the monitor module.
The CONFIGURATION is a base class. It contains all the curing parameters required in the RFID tag design and does not require randomization. May be invoked by all components in the ENV. The module is mainly used for increasing the readability and the easy modification of the code of the verification device.
The ENV module is derived from uvm _ ENV, which defines all the components. By instantiating the ENV, instantiation of all components is achieved. In the authentication apparatus, the components instantiated by the ENV include a reference model (reference), an agent module (agent) and a result comparison module (scoreboard), wherein the agent module comprises a driver, an input monitoring module and a Sequencer (Sequencer). The ENV module also describes the connection relationships between the various components: the output array of the input monitoring module in the agent module is connected to the result comparison module (scoreboard); the output array of the reference model (reference) is connected to the result comparison module (scoreboard); the transaction classes of the driver modules in the agent module are linked into a reference model (reference).
The agent module comprises a driver, an input monitoring module and a sequence generator. The agent module contains all modules of the same protocol type, with the purpose of providing an authentication component that allows the user to generate drivers and monitor DUT transactions (monitors). At the same time, the driver module connects the transaction class to the input monitor module (monitor).
The Sequencer (Sequencer) of the agent module, which communicates between the sequence and the drive, acts as a bridge. Upon receiving a request from the driver (driver), the sequencer transmits the Transaction class (Transaction) in the test case to the driver (driver).
The driver module is used for converting the abstract transaction class sent by the sequence generator into actual excitation. The signal generated by the driver module simulates the demodulated signal and generates a specific frame format based on the transaction class. The driver module functions include generating a header (sof), generating a frame content (payload), CRC16 verification, random number reading, data encryption, generating a trailer (eof), and error format injection. In the invention, a CRC check and encryption module of a driver module is generated by directly calling a C + + function in a DPI mode.
And the input monitoring module (monitor) is used for monitoring a modulation signal connected with the RFID to-be-detected label in the virtual interface. In the invention, the transaction class comprises parameters of a modulation mode and transmits the parameters to the DUT to be tested through a demodulation signal. The input monitoring module (monitor) restores the modulation signal of the DUT (device under test) to a data packet, and sends the data packet to the scoreboard module after detecting the CRC16 without error.
The reference model (reference) is a behavior model for simulating the DUT (device under test) of the tag to be tested according to the transaction class generated by the test case. In the invention, the behavior model of the tag generates three responses according to the protocol: no response, a successful response, or a failed response. In the invention, no response means that the modulation signal has no 01 jump, so 8 bits are all 1 instead of being stored in scoreboard; in the invention, successful response refers to correct reply to the protocol command and possibly accompanies read-write operation to the EEPROM; in the invention, the failure response means that the transmitted demodulation signal has error injection or the command format does not support. All three response replies are sent to the scoreboard module in packet form for comparison with the packet generated by the monitor.
The result comparison (scoreboard) module is a module that compares results. And comparing whether the output data of the input monitoring monitor module is consistent with the reference model (reference). If the result is consistent, the driver is informed to send the next Transaction class (Transaction); if the comparison fails, UVM _ ERROR is reported, and the verification process is stopped.
2. An RFID tag chip verification device based on UVM comprises the following steps:
1) the verification device is set up as shown in figure 1. Initializing the verification device and generating a system clock signal.
2) A reset signal is sent in the driver to reset the verification device and the DUT to be tested.
3) The driver sends a request to a sequencer (sequencer) to obtain the transaction class, which obtains the transaction class from the test case and sends it to the driver. And then the transaction class is sent to the reference model and the input monitoring module through the verification device.
4) The driver generates a frame signal according to the transaction class and sends the signal to the virtual interface; and simultaneously sending an indication signal to the input monitoring module.
5) When the DUT successfully receives the frame signal sent by the driver, it sends a correct response reply as required by the protocol. And after the input monitoring module receives the indication signal sent by the driver, the input monitoring module starts to search the modulation signal. The input monitoring module searches the modulation signal successfully according to the configuration in the transaction class in the time specified by the protocol, and then transmits the received data packet to the result comparison module through the interface.
6) The reference model module obtains the transaction class from the driver, obtains an expected response that the tag RFID should give according to the transaction parameter configuration, and transmits the response value to the result comparison module.
7) The result comparison module compares the two arrays of the input monitoring module and the reference model, and if the results are consistent, the result comparison module informs the driver to send a next request to the sequencer to acquire a new transaction class; if the results are not consistent, an error is reported, and the simulation is stopped.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010935322.0A CN112069074A (en) | 2020-09-10 | 2020-09-10 | RFID tag chip verification device based on UVM |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010935322.0A CN112069074A (en) | 2020-09-10 | 2020-09-10 | RFID tag chip verification device based on UVM |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112069074A true CN112069074A (en) | 2020-12-11 |
Family
ID=73664360
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010935322.0A Withdrawn CN112069074A (en) | 2020-09-10 | 2020-09-10 | RFID tag chip verification device based on UVM |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112069074A (en) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114330625A (en) * | 2021-11-18 | 2022-04-12 | 北京智芯微电子科技有限公司 | Passive radio frequency tag verification system and control method thereof |
| CN114676011A (en) * | 2022-05-30 | 2022-06-28 | 芯耀辉科技有限公司 | Data verification method, related equipment and storage medium |
| CN116306409A (en) * | 2023-05-22 | 2023-06-23 | 南京芯驰半导体科技有限公司 | Chip verification method, device, equipment and storage medium |
| CN116306388A (en) * | 2023-05-23 | 2023-06-23 | 苇创微电子(上海)有限公司 | Automatic UVM verification platform free of path connection and construction method thereof |
| CN117332742A (en) * | 2023-12-01 | 2024-01-02 | 芯动微电子科技(武汉)有限公司 | Simulation verification method and device for chip design stage |
| CN117389818A (en) * | 2023-12-12 | 2024-01-12 | 牛芯半导体(深圳)有限公司 | Verification method and device applied to UVM verification platform |
-
2020
- 2020-09-10 CN CN202010935322.0A patent/CN112069074A/en not_active Withdrawn
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114330625A (en) * | 2021-11-18 | 2022-04-12 | 北京智芯微电子科技有限公司 | Passive radio frequency tag verification system and control method thereof |
| CN114330625B (en) * | 2021-11-18 | 2024-01-23 | 北京智芯微电子科技有限公司 | Passive radio frequency tag verification system and control method thereof |
| CN114676011A (en) * | 2022-05-30 | 2022-06-28 | 芯耀辉科技有限公司 | Data verification method, related equipment and storage medium |
| CN116306409A (en) * | 2023-05-22 | 2023-06-23 | 南京芯驰半导体科技有限公司 | Chip verification method, device, equipment and storage medium |
| CN116306409B (en) * | 2023-05-22 | 2023-08-08 | 南京芯驰半导体科技有限公司 | Chip verification method, device, equipment and storage medium |
| CN116306388A (en) * | 2023-05-23 | 2023-06-23 | 苇创微电子(上海)有限公司 | Automatic UVM verification platform free of path connection and construction method thereof |
| CN117332742A (en) * | 2023-12-01 | 2024-01-02 | 芯动微电子科技(武汉)有限公司 | Simulation verification method and device for chip design stage |
| CN117332742B (en) * | 2023-12-01 | 2024-02-23 | 芯动微电子科技(武汉)有限公司 | Simulation verification method and device for chip design stage |
| CN117389818A (en) * | 2023-12-12 | 2024-01-12 | 牛芯半导体(深圳)有限公司 | Verification method and device applied to UVM verification platform |
| CN117389818B (en) * | 2023-12-12 | 2024-03-29 | 牛芯半导体(深圳)有限公司 | Verification method and device applied to UVM verification platform |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112069074A (en) | RFID tag chip verification device based on UVM | |
| US7225357B2 (en) | SDIO card development system | |
| CN113127338A (en) | Firmware testing method, server and computer readable storage medium | |
| CN100444127C (en) | System and method for testing software | |
| CN106952838B (en) | Special RFID parallel wafer test system and verification method | |
| CN110502442A (en) | Dynamic parameter method of calibration, device, equipment and storage medium | |
| CN113901754B (en) | FPGA-based Ethernet MACIP board-level verification structure and method | |
| CN112749523B (en) | Verification platform and method of image reconstruction module based on UVM | |
| CN113407393A (en) | Chip verification method, terminal device, verification platform and storage medium | |
| CN112084802B (en) | RFID tag chip verification system | |
| CN104765671A (en) | Method for verifying uart module by using reusable hierarchical verification platform | |
| CN107832176A (en) | Hard disk pressure automatic test approach and system under a kind of Windows | |
| CN114218882A (en) | SoC chip inspection method, device and related equipment | |
| CN109408099A (en) | Remote FPGA firmware code updating system, method and medium | |
| CN202404912U (en) | Neural network test module and test system of smart card chip memory | |
| CN116663490A (en) | Verification method, platform, device and medium of asynchronous memory chip | |
| CN116306479A (en) | UVM-based Ethernet PHY universal verification platform and verification method | |
| CN101206613A (en) | High speed basic input/output system debug card | |
| CN113160875B (en) | Chip test system and test method | |
| CN113409873B (en) | System, method and executing device for testing erasing interference | |
| CN112000579A (en) | Software interface testing method, system, equipment and medium | |
| CN112698995B (en) | Serial port information positioning method, device and system | |
| CN108630283A (en) | Test device and method for automatically recording memory redundancy page mistake address | |
| CN111143144B (en) | Chip verification method and verification platform with error injection and portability | |
| US20060013294A1 (en) | Repeat digital message transmission between a microprocessor monitoring circuit and an analyzing tool |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| WW01 | Invention patent application withdrawn after publication |
Application publication date: 20201211 |
|
| WW01 | Invention patent application withdrawn after publication |