A uvm-based ufs device-side transmission layer verification platform and method

Abstract

The application provides a UVM-based verification platform and method for a UFS device end transmission layer; wherein the verification platform comprises a verification top layer, a test case layer and a verification environment layer; the verification top layer comprises a UTP engine module of a design under test; the test case layer realizes test cases of related functions by starting a plurality of sequences; the verification environment layer comprises a register model, a coverage collector, a score board, a reference model and a verification component; wherein the verification component comprises a UFS_HOST agent component, a data bus agent component and a configuration bus agent component. The verification platform is built based on the UVM verification methodology, has the characteristics of hierarchical structure and high reusability, and can improve the verification efficiency of the UTP engine module of the UFS device end transmission layer.

Description

Technical Field

[0001] This invention relates to the field of chip functional verification, and specifically to a verification platform and method for the UFS device-side transport layer based on UVM. Background Technology

[0002] As integrated circuits continue to evolve towards lighter, smaller, thinner, and lower-power designs, the complexity of chip design is constantly increasing. In modern circuit front-end design workflows, the importance of chip verification is constantly rising. In a chip project, verification work occupies a significant portion of the project development cycle. Traditional verification uses Verilog verification technology, which has poor reusability and randomness, requiring a considerable amount of time to build the platform and test cases. UVM verification technology, due to its object-oriented and constrained randomness characteristics, can improve the efficiency of verification work and enhance the reusability of the verification platform by using UVM verification methods for module-level and chip-level verification.

[0003] UFS (Universal Flash Storage) is a high-performance flash memory protocol. To achieve high-performance and low-power data transmission, the protocol utilizes differential serial multichannel data transmission, full-duplex, asynchronous communication, and command queuing technologies. The protocol introduces a three-layer architecture: the Application Layer (UAP), the Transport Layer (UTP), and the Interconnect Layer (UIC). The Application Layer handles SCSI commands used by UFS, the Transport Layer generates and processes higher-level UFS Protocol Information Unit (UPIU) commands, and the Interconnect Layer handles the connection between the UFS host and the device. In the UFS device chip, a UTP engine module is used to perform the transport layer functions of the protocol; this module is responsible for generating and processing UFS Protocol Information Units (UPIUs).

[0004] The UFS Transport Layer (UTP) is the only protocol layer in the UFS protocol defined by its own protocol; other layers reference other protocols. Therefore, it is necessary to conduct comprehensive and thorough verification of the UFS Transport Layer module. Currently, most commonly used UFS verification schemes utilize Commercial Verification Intellectual Property (VIP) to build verification platforms. Due to commercial confidentiality restrictions and the encryption of the VIP's internal source code, this method suffers from poor operability, inflexibility, and difficulty in further development. Classic verification methods use circuit models or actual circuits to generate stimuli from the device and host sides. However, this method has the problem of difficulty in controlling the generation of stimuli according to different test cases. Summary of the Invention

[0005] Based on the above problems, this invention proposes a verification platform and method for the UFS device-side transport layer based on UVM. This verification platform can help verification engineers to more fully and completely verify the UFS device-side transport layer, improve verification efficiency, and verify functional points that cannot be covered in chip-level verification.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a verification platform for the UFS device-side transport layer based on UVM, comprising a verification top layer, a test case layer, and a verification environment layer;

[0007] The verification top layer includes the UTP engine module of the design under test;

[0008] The test case layer generates corresponding stimulus data for one or more verification function points analyzed based on the UFS protocol and the design specifications of the UTP engine module under test through the calling of multiple test sequences, which is used to generate verification stimulus for the corresponding function points.

[0009] The verification environment layer includes: a register model, a coverage collector, a scoreboard, a reference model, and verification components; wherein, the verification components include: a UFS_HOST proxy component, a data bus proxy component, and a configuration bus proxy component;

[0010] The UFS_HOST proxy component includes: a UFS_HOST driver module, a UFS_HOST monitor module, and a UFS_HOST sequence generator module;

[0011] The data bus proxy component includes: a data bus driver module, a data bus monitor module, and a data bus sequence generator module;

[0012] The configuration bus proxy component includes: a configuration bus driver module, a configuration bus monitor module, and a configuration bus sequence generator module;

[0013] The register model is connected to the configuration bus sequence generator module via a converter;

[0014] The coverage collector is connected to the UFS_HOST monitor module, the data bus monitor module, and the configuration bus monitor module, respectively.

[0015] The reference model is connected to the input data acquisition ports of the UFS_HOST monitor module, the data bus monitor module, and the configuration bus monitor module, respectively.

[0016] The scoring board is connected to the output data acquisition ports of the UFS_HOST monitor module, the data bus monitor module, and the configuration bus monitor module, respectively; the scoring board is also connected to the reference model.

[0017] Preferably, the test case layer generates different test cases by configuring different sequences of startup. Different test cases are used to test different verification function points to verify the UTP engine module.

[0018] Preferably, the UFS_HOST driver module is used to convert the UPIU format transaction packets sent by the UFS_HOST sequence generator module into Cport format data, and drive the Cport interface of the UTP engine module; the UFS_HOST monitor module is used to collect the data sent and received on the Cport interface of the UTP engine module, and convert the Cport format data into UPIU data, and encapsulate it into a UPIU format transaction packet.

[0019] Preferably, the reference model is used to simulate the operation of the UTP engine module, simulate the conversion behavior of different data types of UPIU data between the Cport interface and the data bus interface of the UTP engine module at the software level, and generate predicted output results.

[0020] The scoring board is connected to the reference model and the output data acquisition ports of the UFS_HOST monitor module, data bus monitor module and configuration bus monitor module. It places the predicted output results of the reference model and the actual output results of the UTP engine module into the corresponding queues and compares the predicted output results with the actual output results.

[0021] A verification method for the aforementioned UVM-based UFS device-side transport layer verification platform includes the following steps:

[0022] Step 1: Based on the UFS protocol and the design specifications of the UTP engine under test, analyze and verify the functional points, and formulate a verification plan;

[0023] Step 2: Based on the verification plan, design and build the top-level verification layer and various verification environment components, and construct test cases for the test case layer; initialize the verification environment layer and UTP engine module, instantiate each verification component, verify the top-level interface; connect each verification component, and start the verification platform;

[0024] Step 3: The UFS_HOST sequence generator module, data bus sequence generator module, and configuration bus sequence generator module respectively obtain the scheduled transaction class of each sequence and send the transaction class to the corresponding UFS_HOST driver module, data bus driver module, or configuration bus driver module.

[0025] Step 4: The UTP engine module processes the input data to generate the engine module output. The UFS_HOST monitor module, data bus monitor module, and configuration bus monitor module convert the collected data into data packets in transaction format, and then send the corresponding transaction packets to the reference model and scoreboard.

[0026] Step 5: The reference model calculates the input data, converts the data packets according to the data format of the output port, and compares the data packets with the data packets output by the UFS_HOST monitor module, data bus monitor module, and configuration bus monitor module through a scoring board for data consistency comparison.

[0027] Step 6: Based on the functions of the UFS protocol and the UTP engine module, list the corresponding functional points that need to be covered, design a coverage collector, and connect the coverage collector to the UFS_HOST monitor module, the data bus monitor module, and the configuration bus monitor module respectively; run all test cases and generate a coverage report.

[0028] Step 7: Perform regression testing on each test case, collect code coverage and functional coverage data; analyze the coverage report, and add new test cases to cover any uncovered points.

[0029] Preferably, in step one, the functional points include the sending and receiving functions of UPIU data packets for DATA IN, DATA OUT, COMMAND, RESPONSE, READYTO TRANSFER, NOP, TASK MANAGEMENT, QUERY, and REJECT, register read and write functions, and queue management functions for COMMAND, TASK MANAGEMENT, and QUERY operations.

[0030] Preferably, in step five, after the reference model obtains the input data, it simulates the running result of the UTP engine module based on the current module state analyzed by the register model, and the reference model sends the predicted result to the scoring board through the TLM port.

[0031] Preferably, in step six, the coverage function point is the value of the input UPIU data packet and register model, and different coverage groups are set according to different functions; the coverage collector is used to check whether the test cases cover the corresponding values ​​and to confirm whether the functions of the UTP engine module have been fully verified.

[0032] Compared with existing solutions, the beneficial effects of this technical solution are:

[0033] Compared to traditional Verilog and System Verilog verification platforms, the verification platform of this invention features a layered design and utilizes the built-in method library of the UVM verification methodology. This significantly improves the work efficiency of verification personnel. Furthermore, the UVM verification methodology has high reusability, allowing the platform and methods to be used in similar projects, thereby improving the verification efficiency of subsequent projects.

[0034] Compared to using commercial VIPs, the platform construction method of this invention is simple, the process is straightforward, and it is highly operable and scalable. Verification engineers can more clearly understand the platform structure and verification methods, which facilitates project handover.

[0035] Compared to using circuit models to verify the memory control subsystem and the host's interaction with the UTP engine, using UVM proxy modules to drive the stimuli for interaction with the memory control subsystem improves the flexibility of verification, allows for the verification of module boundary conditions, and increases verification coverage.

[0036] By using a reference model and a scoring board, the input data is converted into UPIU transaction packets, and then into predicted output data. The module output data is compared to achieve real-time checking of the consistency of protocol information units, making it easier to locate circuit defects.

[0037] The verification platform of this invention can realize the verification of UFS command queue and full-duplex; it has high reusability, and can be used to verify UTP engine modules with different design structures.

[0038] The verification platform of this invention is built based on the UVM verification methodology and features a hierarchical structure and high reusability, which can improve the verification efficiency of the UTP engine module of the UFS device's transport layer. The verification method uses the UVM methodology to construct directed and constrained random test cases, and the data comparison mechanism is easy to implement. Driven by code coverage and functional coverage, it can improve the accuracy and efficiency of verification. Attached Figure Description

[0039] Figure 1 This is a structural diagram of the verification platform for the UFS device-side transport layer based on UVM of this invention;

[0040] Figure 2 This is a flowchart of the verification method for the verification platform of this invention. Detailed Implementation

[0041] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0042] Example

[0043] This embodiment provides a verification platform for the UFS device-side transport layer based on UVM, such as... Figure 1 It includes the top-level verification layer, the test case layer, and the verification environment layer.

[0044] The top-level verification includes the UTP engine module and interfaces of the design under test. The UTP engine module of the design under test interacts with UNIPRO through the Cport interface, and its function is to convert the data transmitted from the Cport interface into UPIU format data and to convert UPIU format data into Cport interface data.

[0045] The interface is used to enable interaction with the design under test (UTP). After instantiating the UTP and interface at the top level, the interface can be used on the corresponding component by passing the interface handle to the virtual interface of the corresponding component. There are three types of interfaces: Cport interface, data bus interface, and configuration bus interface. The interface acts as a bridge connecting the verification platform and the UTP engine module of the UTP. The platform drives the UTP module by passing parameters of the instantiated interface to the corresponding driver.

[0046] The Cport interface is the interface between the UTP engine module and UNIPRO used for data transfer and response. The data bus interface is the interface between the UTP engine module and the chip system's memory for data transfer.

[0047] The configuration bus interface is used to configure and read the registers of the design under test.

[0048] The UTP engine module of the design under test is the UTP engine module of the UFS device-side transport layer, which includes UPIU data packet transmission function and register configuration function.

[0049] The test case layer generates corresponding stimulus data for one or more verification function points analyzed based on the UFS protocol and the design specifications of the UTP engine under test. This data is generated through the invocation of multiple test sequences to produce verification stimuli for the corresponding function points. Different test cases are generated by configuring the activation of different sequences. These different test cases can be used to test different verification function points, thereby comprehensively verifying the entire device-side UTP engine module and identifying design flaws.

[0050] Furthermore, the test sequences are used to generate stimulus data. Different test sequences are configured to generate different stimuli to verify the module under test, based on different verification function points. The stimulus data includes Cport interface data transmission stimuli, data bus data transmission stimuli, and configuration bus register configuration and read stimuli. A specific sub-sequence can be specified to generate test stimuli using the `uvm_do()` series of macro instructions. A test case needs to start several sub-sequences in a certain order.

[0051] The verification environment layer includes a register model, a coverage collector, a scoreboard, a reference model, and verification components; among which, the verification components include: a UFS_HOST proxy component, a data bus proxy component, and a configuration bus proxy component.

[0052] The register model is a model of the registers of the UTP engine module, and configuration and reading operations of the registers are completed through front-door and back-door access. The register model is connected to the configuration bus sequence generator through a converter.

[0053] Furthermore, front-door access performs read and write operations on the registers inside the UTP engine module through the configuration bus. Back-door access, on the other hand, performs access operations on the registers inside the UTP engine module without using the configuration bus.

[0054] Furthermore, the converter is used to implement data conversion between the register model and the configuration bus agent component, and includes the following two key points. First, it implements the data mapping in the uvm_reg_bus_op transaction class and the configuration bus transaction class respectively; second, it implements the two functions reg2bus() and bus2reg(). These two functions specifically implement the data conversion between the two transaction classes. The function names indicate their conversion direction, and the verification technicians need to specifically define these two functions.

[0055] The reference model is used to simulate the operation of the UTP engine module, simulate the conversion behavior of different data types of UPIU data between the Cport interface and the data bus interface at the software level, and generate predicted output results.

[0056] Furthermore, during the UFS_HOST proxy component's UPIU sending process, the reference model converts the input data collected by the Cport interface into data output by the data bus proxy component; during the UFS_HOST proxy component's UPIU receiving process, the reference model converts the input data of the data bus proxy component into output data of the Cport interface.

[0057] The scoring board is connected to the reference model and the output data acquisition ports of the UFS_HOST monitor module, data bus monitor module and configuration bus monitor module. It places the predicted output results of the reference model and the actual output results of the UTP engine module into the corresponding queues and compares the predicted output results with the actual output results.

[0058] The coverage collector collects functional coverage data using functional coverage groups and corresponding sampling functions. It collects the values ​​that have appeared in the data and the changes in those values. In this scheme, the coverage collector samples the transaction packets collected by each monitor. Based on the UFS protocol and the functional points of the UTP engine module under test, the coverage groups and coverage points to be collected are specified, and the sample() function is used to complete the functional coverage collection. In the early stages of verification, the coverage groups can be left uninstantiated to ensure better resource utilization; instantiation and enabling sampling are considered only in the later stages of verification when functional coverage collection is required.

[0059] The UFS_HOST proxy component encapsulates the UFS_HOST driver module, the UFS_HOST monitor module, and the UFS_HOST sequence generator module. The UFS_HOST sequence generator module receives UFS_HOST transaction packets sent via the UFS_HOST sequence generator. The UFS_HOST driver module, connected to the UFS_HOST sequence generator module, requests the UFS_HOST sequence generator to send UFS_HOST transaction packets, driving the Cport interface to generate stimuli. The UFS_HOST monitor, connected to the Cport interface, collects data from the Cport interface.

[0060] Furthermore, the UFS_HOST sequence generator module and the UFS_HOST driver module communicate through a TLM port specifically defined by UVM. TLM communication is a transaction-based communication method. The UFS_HOST driver module is the request initiator, and the UFS_HOST sequence generator module is the request responder.

[0061] Furthermore, the UFS_HOST driver module is connected to the Cport interface, and the top-level Cport interface is passed to the UFS_HOST driver module via parameter passing in the top-level layer. The UFS_HOST driver module includes a converter that converts UPIU data format transaction packets into the signal format of the Cport interface and generates the corresponding stimulus for the Cport interface.

[0062] Furthermore, the UFS_HOST monitor module is connected to the Cport interface, and the Cport interface of the verification top layer is passed to the UFS_HOST monitor module through parameter passing in the verification top layer. The UFS_HOST monitor module includes a converter that converts the signal data of the Cport interface into UPIU data transaction packets and collects the corresponding stimuli of the Cport interface.

[0063] The data bus proxy component encapsulates a data bus driver module, a data bus monitor module, and a data bus sequence generator module. The data bus sequence generator module receives data bus transaction packets sent from the data bus sequence generator. The data bus driver module, connected to the data bus sequence generator module, requests the data bus sequence generator to send data bus transaction packets, driving the data bus interface to generate stimuli. The data bus monitor module, connected to the data bus interface, collects data from the data bus interface.

[0064] Furthermore, the data bus sequence generator module and the data bus driver module communicate through a TLM port specifically defined by UVM. TLM communication is a transaction-based communication method. The data bus driver module is the request initiator, and the data bus sequence generator module is the request responder.

[0065] Furthermore, the data bus driver module is connected to the data bus interface, and the data bus interface of the verification top layer is passed to the data bus driver module through parameter passing in the verification top layer.

[0066] Furthermore, the data bus monitor module is connected to the data bus interface, and in the verification top layer, the data bus interface of the verification top layer is passed to the data bus monitor module through parameter passing, and the corresponding stimulus of the data bus interface is collected.

[0067] The configuration bus proxy component encapsulates a configuration bus driver module, a configuration bus monitor module, and a configuration bus sequence generator module. The configuration bus sequence generator module receives configuration bus transaction packets sent by the configuration bus sequence generator. The configuration bus driver module, connected to the configuration bus sequence generator module, requests the configuration bus sequence generator module to send configuration bus transaction packets, driving the configuration bus interface to generate stimuli. The configuration bus monitor module, connected to the configuration bus interface, collects data from the configuration bus interface.

[0068] Furthermore, the configuration bus sequence generator module and the configuration bus driver module communicate through a TLM port specifically defined by UVM. TLM communication is a transaction-based communication method. The configuration bus driver module is the request initiator, and the configuration bus sequence generator module is the request responder.

[0069] Furthermore, the configuration bus driver module is connected to the configuration bus interface, and the configuration bus interface of the verification top layer is passed to the configuration bus driver module through parameter passing in the verification top layer.

[0070] Furthermore, the configuration bus monitor module is connected to the configuration bus interface, and in the verification top layer, the configuration bus interface of the verification top layer is passed to the configuration bus monitor module through parameter passing, and the corresponding stimulus of the configuration bus interface is collected.

[0071] Figure 2 The flowchart of the verification method of the verification platform for the UFS device-side transport layer based on UVM in this invention example is as follows:

[0072] Step 1: Based on the UFS protocol and the design specifications of the UTP engine under test, extract the verification function points and formulate a verification plan.

[0073] Specifically, the UFS protocol is JESD220E, and the basic function of the UTP engine under test is to encode and decode UPIU data packets.

[0074] Furthermore, based on the division of function points, the extracted function points include the UPIU data packet sending and receiving functions of DATA IN, DATA OUT, COMMAND, RESPONSE, READY TO TRANSFER, NOP, TASK MANAGEMENT, QUERY, and REJECT; register read and write functions; queue management functions of COMMAND, TASK MANAGEMENT, and QUERY operations; and interrupt functions.

[0075] Furthermore, frequently used functions are encapsulated into sub-sequences, which can be called by other sequences to prepare for the construction of test cases.

[0076] Step 2: Based on the verification plan, design and build the top-level verification layer and each verification component, and build test cases for the test case layer; initialize the verification environment layer and UTP engine module, instantiate each verification component, verify the top-level interface; connect each verification component, and start the verification platform.

[0077] Furthermore, the test cases require multiple sequences to be started in a certain order, and the test cases can cover one or more functional points. Several test cases complete the coverage of the verification functional points of the UTP engine module.

[0078] Furthermore, based on the corresponding interface timing, the corresponding interface proxy and its included driver, monitor, and sequence generator components are designed. System Verilog modeling is performed on the behavior of the UTP engine module under test, and a reference model is designed. A scoreboard for comparing expected and actual outputs is designed. The registers of the UTP engine module are modeled using a register model.

[0079] Furthermore, after connecting the various components of the platform, the platform is started using the run_test statement.

[0080] Step 3: Each sequence sends the corresponding transaction class to the corresponding UFS_HOST sequence generator module, data bus sequence generator module, or configuration bus sequence generator module. The corresponding UFS_HOST driver module, data bus driver module, or configuration bus driver module requests the transaction packet from its respective sequence generator module and drives the interface activation based on the information in the transaction packet.

[0081] Step four: The UTP engine module processes the input data to generate corresponding outputs. The UFS_HOST monitor module, data bus monitor module, and configuration bus monitor module convert the collected data into data packets in transaction format. The input and output data are collected separately, and the corresponding transaction packets are sent to the reference model and the scoreboard respectively.

[0082] Furthermore, the monitor samples the input and output data from the corresponding interface to prepare for data comparison.

[0083] Specifically, the input data includes data written to the Cport RX interface and data read from the data bus.

[0084] Specifically, the output data includes data written to the Cport TX interface and data written out of the data bus.

[0085] Step 5: The reference model calculates the input data and the current register configuration, parses the UPIU data packet corresponding to the current data, converts the data packet according to the data format of the output port, and compares the data packets with the data packets output by the UFS_HOST monitor module, data bus monitor module and configuration bus monitor module through the scoring board for data consistency comparison.

[0086] Furthermore, after acquiring the input data, the reference model can simulate the module's operating results based on the current module state analyzed by the register model. The reference model sends the predicted results to the scoring board via the TLM port.

[0087] Furthermore, the output of the UTP engine module is the decoding and encoding of UPIU. Decoding involves converting the UPIU data received from the Cport RX interface and outputting it to the corresponding address space via the data bus. Encoding involves reading the UPIU data from the corresponding address space and converting it into Cport TX data for output. The output data is sent to the scoring board via the TLM port.

[0088] Furthermore, the scoring board includes two processes: one for obtaining the predicted output result from the TLM port and storing the predicted output result in the expected result queue, and the other for obtaining the actual output result from the TLM port and putting the actual output result into the actual result queue.

[0089] Furthermore, when the scoring board obtains the actual output result, it searches the predicted output result queue to find a matching predicted output result. If no matching predicted output result is found, it means that the module's output does not have a corresponding reference model output, and this error is recorded. If a matching predicted output result is found, a data packet comparison is performed. If the comparison matches, the function is correct; if the comparison does not match, an error message is printed for analysis of the error cause.

[0090] Specifically, the matching is performed by matching the output data through data such as LUN, TASK TAG, and IID in the UPIU data packet.

[0091] Step Six: Based on the functions of the UFS protocol and the UTP engine module, list the corresponding functional points that need to be covered, specify the data coverage range for each coverage point, and set up corresponding functional point coverage groups for the same group of functional points. Connect the coverage acquisition module to the UFS_HOST monitor module, data bus monitor module, and configuration bus monitor module respectively. A coverage file will be generated at the end of each test case. Merge all coverage files to generate a coverage report.

[0092] Specifically, the covered function points are user-defined function points of interest. In this example, the covered function points are the values ​​of the input UPIU data packets and registers. Different coverage groups can be set according to different functions. The function coverage collector is used to check whether the test cases cover the corresponding values ​​and to confirm whether the functions of the UTP engine module have been fully verified.

[0093] Step 7: Perform regression testing on each test case and collect code coverage and functional coverage data. Analyze the coverage report and add new test cases to cover any uncovered points.

[0094] Specifically, the regression test is the process of re-verifying the already validated design after each modification of the RTL code due to design flaws and updates.

[0095] Furthermore, the test cases include directed test cases and constrained random test cases. The directed test cases are used to cover basic functionalities and functionalities of interest, while the constrained random test cases are used to improve verification coverage.

[0096] Furthermore, by analyzing code coverage and functional coverage, uncovered functionalities and code can be identified. The verification plan needs to be updated, and new test cases added to cover these uncovered areas until code coverage and functional coverage meet the required standards.

[0097] The above embodiments are preferred embodiments of the present invention, but the embodiments of the present invention are not limited to the above embodiments. Any changes, modifications, substitutions, combinations, or simplifications made without departing from the spirit and principle of the present invention shall be considered equivalent substitutions and shall be included within the protection scope of the present invention.

Claims

1. A verification method for the transport layer of a UFS device based on UVM, characterized in that: Includes the following steps: Step 1: Based on the UFS protocol and the design specifications of the UTP engine under test, analyze and verify the functional points, and formulate a verification plan; Step 2: Based on the verification plan, design and build the top-level verification layer and each verification component; construct test cases for the test case layer; initialize the verification environment layer and UTP engine module; instantiate each verification component; verify the top-level interface; connect each verification component; and start the verification platform. Step 3: The UFS_HOST sequence generator module, data bus sequence generator module, and configuration bus sequence generator module respectively obtain the scheduled transaction class of each sequence and send the transaction class to the corresponding UFS_HOST driver module, data bus driver module, or configuration bus driver module. Step 4: The UTP engine module processes the input data to generate the engine module output. The UFS_HOST monitor module, data bus monitor module, and configuration bus monitor module convert the collected data into data packets in transaction format, and then send the corresponding transaction packets to the reference model and scoreboard. Step 5: The reference model calculates the input data, converts the data packets according to the data format of the output port, and compares the data packets with the data packets output by the UFS_HOST monitor module, data bus monitor module, and configuration bus monitor module through a scoring board for data consistency comparison. Step 6: Based on the functions of the UFS protocol and the UTP engine module, list the corresponding functional points that need to be covered, design a coverage collector, and connect the coverage collector to the UFS_HOST monitor module, the data bus monitor module, and the configuration bus monitor module respectively; run all test cases and generate a coverage report. Step 7: Perform regression testing on each test case and collect code coverage and functional coverage data. Analyze the coverage report and add new test cases to cover the uncovered points.

2. The verification method for the UFS device-side transport layer based on UVM as described in claim 1, characterized in that: In step one, the functionalities include sending and receiving UPIU data packets for DATA IN, DATA OUT, COMMAND, RESPONSE, READY TO TRANSFER, NOP, TASKMANAGEMENT, QUERY, and REJECT; register read / write functions; and queue management functions for COMMAND, TASK MANAGEMENT, and QUERY operations.

3. The verification method for the UFS device-side transport layer based on UVM as described in claim 1, characterized in that: In step five, after the reference model obtains the input data, it simulates the running result of the UTP engine module based on the current module state analyzed by the register model. The reference model then sends the predicted result to the scoring board through the TLM port.

4. The verification method for the UFS device-side transport layer based on UVM as described in claim 1, characterized in that: In step six, the functional points that need to be covered are the values ​​of the input UPIU data packets and register models. Different coverage groups are set according to different functions. The coverage collector is used to check whether the test cases cover the corresponding values ​​and to confirm whether the functions of the UTP engine module have been fully verified.

5. A verification platform for the UFS device-side transport layer based on UVM, characterized in that: The verification method for the UFS device-side transport layer based on UVM as described in claim 1; the verification platform for the UFS device-side transport layer based on UVM includes a verification top layer, a test case layer, and a verification environment layer; The verification top layer includes the UTP engine module of the design under test; The test case layer generates corresponding stimulus data for one or more verification function points analyzed based on the UFS protocol and the design specifications of the UTP engine module under test through the invocation of multiple test sequences, which is used to generate verification stimulus for the corresponding function points. The verification environment layer includes: a register model, a coverage collector, a scoreboard, a reference model, and verification components; wherein, the verification components include: a UFS_HOST proxy component, a data bus proxy component, and a configuration bus proxy component; The UFS_HOST proxy component includes: a UFS_HOST driver module, a UFS_HOST monitor module, and a UFS_HOST sequence generator module; The data bus proxy component includes: a data bus driver module, a data bus monitor module, and a data bus sequence generator module; The configuration bus proxy component includes: a configuration bus driver module, a configuration bus monitor module, and a configuration bus sequence generator module; The register model is connected to the configuration bus sequence generator module via a converter; The coverage collector is connected to the UFS_HOST monitor module, the data bus monitor module, and the configuration bus monitor module, respectively. The reference model is connected to the input data acquisition ports of the UFS_HOST monitor module, the data bus monitor module, and the configuration bus monitor module, respectively. The scoring board is connected to the output data acquisition ports of the UFS_HOST monitor module, the data bus monitor module, and the configuration bus monitor module, respectively; the scoring board is also connected to the reference model.

6. The verification platform for the UFS device-side transport layer based on UVM as described in claim 5, characterized in that: The test case layer generates different test cases by configuring different sequences of startup. Different test cases are used to test different verification function points to verify the UTP engine module.

7. The verification platform for the UFS device-side transport layer based on UVM as described in claim 5, characterized in that: The UFS_HOST driver module is used to convert the UPIU format transaction packets sent by the UFS_HOST sequence generator module into Cport format data and drive the Cport interface of the UTP engine module; the UFS_HOST monitor module is used to collect the data sent and received on the Cport interface of the UTP engine module, convert the Cport format data into UPIU data, and encapsulate it into a UPIU format transaction packet.

8. The verification platform for the UFS device-side transport layer based on UVM as described in claim 5, characterized in that: The reference model is used to simulate the operation of the UTP engine module, simulate the conversion behavior of different data types of UPIU data between the Cport interface and the data bus interface of the UTP engine module at the software level, and generate predicted output results. The scoring board is connected to the reference model and the output data acquisition ports of the UFS_HOST monitor module, data bus monitor module and configuration bus monitor module. It places the predicted output results of the reference model and the actual output results of the UTP engine module into the corresponding queues and compares the predicted output results with the actual output results.

Images