A verification platform of a multi-channel IO interface IP and a stopping algorithm thereof

Abstract

The application belongs to the technical field of IP verification, and more particularly to a multi-channel IO interface IP verification platform and a stopping algorithm thereof, which comprises an agent module, a reference model, a score board, a global variable pool and a DUT (device under test) module, the agent module is used for simulating external equipment to provide driving data for all channels of IO, simulating CPU function to configure the IP to be tested, and simulating bus function to provide driving data for the bus to be tested; the reference model is used for receiving data from the IN direction and data from the OUT direction, and converting and sending the data to the score board; the score board is used for receiving output data from the reference model and output data from the DUT module, and comparing the two groups of output data; and the DUT module processes the data of the agent module. The application solves the problems in the prior art that the multi-channel IO interface cannot be driven, the data correctness of the IO interface IP cannot be verified, and the stopping time reference cannot be effectively provided.

Description

Technical Field

[0001] This invention belongs to the technical field of IP verification, and more specifically, relates to a verification platform for multi-channel IO interface IP and its stopping algorithm. Background Technology

[0002] Intellectual Property (IP) design is a crucial step in chip design; stable and reliable IP is essential for chip success, and IP verification is the core of IP development. IP verification often requires twice the time compared to IP design to ensure reliability. With the rapid development of integrated circuits, IP complexity has increased accordingly, making verification increasingly difficult.

[0003] Multi-channel I / O interface IPs have multiple channels, each with both input and output data flow directions. Due to the large number of channels, the different transmission directions of each channel, and the numerous combinations, controlling the downtime of the verification platform is particularly important when testing large amounts of data. Traditional verification techniques are difficult to verify such IPs and fail to provide effective simulation downtime references, resulting in a long period of unused runtime for the verification platform.

[0004] Chinese patent document CN109614368A discloses a module verification platform and method for a system-on-a-chip (SoC) IP, including: a virtual CPU, virtual memory, and cmd_agent, data proxy module, and scu_agent, each corresponding to an IP interface and controllable by instructions; different data bus addresses are assigned to the virtual memory, cmd_agent, data proxy module, and scu_agent; the virtual CPU establishes communication with the virtual memory, cmd_agent, data proxy module, and scu_agent respectively through the virtual data bus. However, this invention cannot drive multi-channel I / O interfaces, cannot verify the data correctness of the I / O interface IP, and cannot effectively provide a stop time reference. Summary of the Invention

[0005] The present invention aims to overcome at least one of the defects of the prior art and provide a verification platform for a multi-channel IO interface IP and its stopping algorithm.

[0006] The detailed technical solution of this invention is as follows:

[0007] To address the aforementioned technical problems, this invention provides a verification platform for multi-channel IO interface IP and its stopping algorithm, thereby solving the problems of existing technologies that cannot effectively and efficiently provide simulation stopping time references when test data is large, and cannot support multiple channels.

[0008] To achieve the above objectives, the present invention provides a verification platform for a multi-channel I / O interface IP, comprising: a proxy module, a reference model, a scoreboard, a global variable pool, and a module under test (DUT).

[0009] The proxy module is used to simulate external devices to provide drive data to all channels of IO and transmit it to the module under test (DUT), simulate CPU function to configure the IP under test, and simulate bus function to provide drive data to the bus under test.

[0010] The reference model is used to receive external drive data trans_data1 in the IN direction and internal data dut_data1 in the IN direction, and perform bit conversion on the two data streams to convert them into data with the same bit width and send them to the scoring board; and the reference model receives drive data trans_data2 from the OUT direction and internal data dut_data2 in the OUT direction, and performs bit conversion on the two data streams to convert them into data with the same bit width and send them to the scoring board.

[0011] The scoring board is used to receive two sets of output data from the reference model, compare the two sets of output data, and determine whether they are equal. If they are equal, it proves that the verification is correct. If they are not equal, the number of unequal data is recorded.

[0012] The global variable pool provides global variables for the proxy modules (CPU proxy module, data proxy module, bus proxy module) and stores the changed global variables;

[0013] Furthermore, when different agent modules work simultaneously, the global variable pool can assign different signal identifiers based on the execution progress of different agent modules, such as dut_en, trans_data1_done, trans_data2_done, and dut_data2_rec_done. During multi-channel verification, the global variable pool can assign different global variables to agent modules based on the channel transmission type, which is more convenient and accurate. Storing the changed global variables facilitates the analysis after verification errors.

[0014] The DUT processes the data in the IN direction of the proxy module and the data in the OUT direction of the proxy module.

[0015] The proxy module includes a CPU proxy module, a data proxy module, and a bus proxy module; these are respectively used to configure the DUT, driver and sampling interface data, and driver and sampling bus data.

[0016] Specifically, the CPU proxy module is used to simulate the CPU to generate the register configuration information required by the module under test (DUT), configure the DUT register through BUS1, and transmit the command information cmd0 to the data proxy module and the command information cmd1 to the bus proxy module.

[0017] The data proxy module is used to receive external drive data trans_data1 in the IN direction and simulate external devices sending it to the module under test (DUT), and to receive external drive data trans_data1 sent in the IN direction and transmit it to the reference model; and the data proxy module monitors and receives internal data dut_data2 sent in the OUT direction channel and transmits it to the reference model.

[0018] The bus proxy module is used to monitor and receive the data dut_data1 of the module under test (DUT) in the IN direction and transmit it to the reference model; and the bus proxy module calls the channel through the channel address and receives the driving data trans_data2 from the channel in the OUT direction, and transmits the driving data trans_data2 in the OUT direction to the reference model and the module under test (DUT) according to the command information cmd1.

[0019] The cmd0 includes channel enable information and channel direction information; the cmd1 includes channel enable information, channel direction information, and data information for each output channel.

[0020] This invention also provides a stopping algorithm for a verification platform of a multi-channel IO interface IP, including stopping data transmission in the IN direction, stopping data transmission in the OUT direction, and stopping the verification platform. The specific steps are as follows:

[0021] S1: The CPU proxy module first configures the DUT (Device Under Test) and transmits the configuration information to the data proxy module through the UVM-based config_db mechanism. In addition, the CPU proxy module generates data packet information for each channel in the OUT direction, including length, number of packets, etc., and transmits it to the bus proxy module through the TLM (Transaction Level Modeling) model. After configuring the DUT to be enabled, it sets dut_en to 1.

[0022] S2: The data proxy module _driver in the data proxy module first waits for dut_en to be set to 1, and obtains the register configuration information through the config_db mechanism, mainly the bit width, channel enable, channel direction and other information. Based on the obtained information, it establishes two channel arrays wr_channel_fifo and rd_channel_fifo, which contain the IN direction channel number and the OUT direction channel number respectively.

[0023] S21. Obtain the data item sent through the sequencer, and push the item into n channel FIFOs according to the channel address, denoted as trans_item_q[n];

[0024] S22. Randomly access each channel according to the channel direction category. If it is the IN direction, randomly retrieve a channel number addrx from wr_channel_fifo and check if trans_item_q[addrx] is empty. If it is empty, delete addrx from wr_channel_fifo. If it is not empty, send data in trans_item_q[addrx] according to the interface information of the module under test (DUT) and delete the already sent packets. If it is the OUT direction, randomly poll each OUT channel, monitor the data according to the interface flow control information and send it to the reference model. If each channel is unreadable and is still unreadable after waiting for a specified period, set dut_data2_rec_done to 1; or if rd_channel_fifo is empty, set dut_data2_rec_done to 1.

[0025] S23. This step determines whether the agent should stop: if wr_channel_fifo is not empty, execute steps a and b; if rd_channel_fifo is not empty, execute step c; if both wr_channel_fifo and rd_channel_fifo are empty, and both b and c are satisfied, then the data proxy module ends.

[0026] a. Wait for all items to be sent to be retrieved in S22 and put into trans_item_q;

[0027] b. Once each channel's trans_item_q is empty and the current item has been sent, set trans_data1_done to 1, meaning data transmission in the IN direction stops;

[0028] c. Wait for the step dut_data2_rec_done to be set to 1;

[0029] After the data proxy module completes the above steps S21, S22, and S23, the data proxy module ends.

[0030] S3, The bus agent module executes operations d, e, and f by monitoring the behavior of BUS2:

[0031] d. When the channel is in the OUT direction, the data packet is sent to BUS2 and recorded as driving data trans_data2, and driving data trans_data2 is sent to the reference model; if the packet information of S1 is empty, it is determined that the OUT direction transmission has ended, and trans_data2_done is set to 1, that is, the OUT direction data transmission stops; if the packet information of S1 is not empty, transmission continues.

[0032] e. Monitor the data dut_data1 entering in the IN direction based on the behavior of BUS2 and send it to the reference model;

[0033] f. Wait for trans_data2_done, trans_data1_done, and dut_data2_rec_done to be enabled. If enabled, monitor BUS2 for idle data cycles and then stop the bus proxy module.

[0034] The verification platform stops after the bus proxy module and data proxy module stop, and the scoring board completes the data verification and outputs the verification result, using the above stopping algorithm.

[0035] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0036] (1) The present invention provides a verification platform for a multi-channel IO interface IP. Compared with the traditional verification platform, the number of channels and the direction of channels can be configured. The configuration information is transmitted to the verification platform, and the verification platform can generate test vectors according to the actual configuration, which greatly improves the reusability of the verification components, improves the verification efficiency, reduces the verification complexity, and proposes a global variable pool that can assign different global variables to the proxy module according to the channel transmission type, which is more convenient and accurate. Storing the changed global variables is convenient for the analysis after verification errors.

[0037] (2) The present invention provides a stopping algorithm for a multi-channel IO interface IP verification platform. By stopping the data transmission in the IN direction, stopping the data transmission in the OUT direction, and stopping the verification platform, the verification time is shortened under the premise that the verification of each channel is completed, and the verification efficiency is improved. By stopping the operation of the data proxy module and the bus proxy module respectively, the verification platform is stopped, which further enhances the efficiency and accuracy of the verification platform. Attached Figure Description

[0038] Figure 1 This is the framework and flowchart of the multi-channel IO interface IP verification platform in Embodiment 1 of the present invention.

[0039] Figure 2 This is a diagram of the multi-channel I / O interface IP framework in Embodiment 1 of the present invention. Detailed Implementation

[0040] The present disclosure will be further described below with reference to the accompanying drawings and embodiments.

[0041] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of this disclosure. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0042] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this disclosure. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms “comprising” and / or “including” are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0043] Where there is no conflict, the embodiments and features described herein can be combined with each other.

[0044] Example 1

[0045] This embodiment provides a verification platform for a multi-channel I / O interface IP, and its channel I / O interface IP framework diagram is as follows. Figure 2 The diagram shows a multi-channel I / O interface IP framework including BUS1, Channel 1, Channel 2, ..., Channel n, and BUS2. BUS1 is used by the CPU to configure the DUT registers and can be a bus that supports protocols such as APB and AHB, connected to the CPU proxy module of the verification platform. Channel x (i.e., any one of Channels 1 to n) is the interface between the IP and external devices, providing input / output data channels. Each channel supports both input and output modes and is connected to the data proxy module of the verification platform. BUS2 is the data transmission channel between the IP and the chip's internal processing unit, supporting bus protocols such as AHB and AXI, and is connected to the bus proxy module.

[0046] A verification platform for multi-channel I / O interface IP, such as Figure 1 As shown, it includes: proxy module, reference model, scoreboard, global variable pool, and DUT (Device Under Test).

[0047] The proxy module is used to simulate external devices providing drive data or acquisition interface data to all channels of IO (i.e., IN and OUT directions) and transmitting it to the DUT (Device Under Test). It also simulates CPU functionality to configure the IP under test and bus functionality to provide drive data and acquisition interface data to the bus under test. The proxy module includes a CPU proxy module, a data proxy module, and a bus proxy module.

[0048] The CPU agent module is encapsulated using cpu_agent, the data agent module is encapsulated using data_agent, and the bus agent module is encapsulated using bus_agent.

[0049] The reference model is Figure 1 The ref model in; the scoreboard is Figure 1 The scoreboard in the context of global variable pools; Figure 1 In global_var.

[0050] The ref model, serving as a reference model, receives external drive data trans_data1 from the IN direction and internal data dut_data1 monitored by the bus_agent in the IN direction, and performs bit conversion on the two data streams to convert them into data of the same bit width before sending them to the scoreboard. Similarly, the ref model receives drive data trans_data2 from the bus_agent in the OUT direction and internal data dut_data2 monitored by the data_agent in the OUT direction, and performs bit conversion on the two data streams to convert them into data of the same bit width before sending them to the scoreboard. The fact that trans_data1 and trans_data2 are trans_data type data, and dut_data1 and dut_data2 are dut_data type data, is common knowledge in the art.

[0051] The scoreboard serves as a scoring board, which receives ref_data and DUT_data from the ref model, compares the two sets of data to determine if they are equal, and if they are equal, proves that the verification is correct; if they are not equal, records the number of unequal data.

[0052] The global variable pool is Figure 1 In the global_var, the global variable pool provides global variables for the proxy module and stores the changed global variables. The global variables include, but are not limited to, dut_en, trans_data1_done, trans_data2_done, and dut_data2_rec_done.

[0053] The DUT processes the data in the IN direction of the proxy module; and processes the data in the OUT direction of the proxy module.

[0054] Furthermore, when the proxy module transmits data with different channels, the global variable pool can assign values ​​to different variables according to the state of different proxy modules.

[0055] The agent module includes a CPU agent module (cpu_agent), a data agent module (data_agent), and a bus agent module (bus_agent);

[0056] The cpu_agent is used to simulate the CPU to generate the register configuration information required by the DUT. The configuration information is configured through BUS1 to configure the DUT registers, and some command information cmd0 is passed to data_agent, and some command information cmd1 is passed to bus_agent. cmd0 includes channel enable information and channel direction information; cmd1 includes channel enable information, channel direction information, and data information of each output channel.

[0057] The data_agent is used to receive external drive data trans_data1 in the IN direction and simulate external devices sending it to the module under test (DUT), and to receive external drive data trans_data1 sent from the IN direction channel and transmit it to the refmodel; and the data_agent monitors and receives internal data dut_data2 sent from the OUT direction channel and transmits it to the refmodel, such as... Figure 1 As shown.

[0058] The bus_agent is used to monitor and receive internal data dut_data1 in the IN direction and transmit it to the ref model; and, the bus_agent calls the channel through the channel address and receives the drive data trans_data2 from the channel, and transmits the drive data trans_data2 in the OUT direction to the ref model and the DUT according to the command information cmd1; Figure 1 As shown.

[0059] The module under test (DUT) processes the external drive data trans_data1 in the IN direction of data_agent to obtain dut_data1 and transmits it to bus_agent; and processes the drive data trans_data2 in the OUT direction of bus_agent to obtain dut_data2 and transmits it to data_agent.

[0060] The following are the processing procedures for the IN and OUT directions:

[0061] For the IN direction, i.e., data is transmitted from the data proxy module to the bus proxy module; the data proxy module receives external drive data trans_data1 from the channel and provides data to the reference model and the DUT through the drive channel address; the DUT processes the data according to the configuration information of the CPU proxy module to obtain dut_data1; the bus proxy module monitors and receives the data in the IN direction, i.e., receives dut_data1 and transmits it to the reference model; at this time, the reference model performs bit conversion on the two data streams (external drive data trans_data1 and dut_data1) to convert them into data with the same bit width and sends them to the scoring board; the scoring board compares the two sets of output data to determine whether they are equal. If they are equal, it proves that the verification is correct; if they are not equal, it records the number of unequal data.

[0062] For the OUT direction, i.e., data is transmitted from the bus proxy module to the data proxy module; the bus proxy module calls a certain channel and receives the driver data trans_data2 from the channel, and then provides data to the reference model and the DUT through the driver bus address; the DUT processes the data according to the configuration information of the CPU proxy module to obtain dut_data2; the data proxy module monitors and receives the data in the OUT direction, i.e., receives dut_data2, and transmits it to the reference model; at this time, the reference model performs bit conversion on the two data streams (driver data trans_data2, dut_data2), converting them into data with the same bit width and sending them to the scoring board; the scoring board compares the above two sets of output data to determine whether they are equal. If they are equal, it proves that the verification is correct; if they are not equal, it records the number of unequal data.

[0063] The CPU proxy module is used to simulate the CPU to generate the register configuration information required by the DUT (Device Under Test). It configures the DUT registers through BUS1 and transmits the command information cmd0 to the data proxy module and the command information cmd1 to the bus proxy module. The global variable pool provides global variables for the proxy modules (CPU proxy module, data proxy module, and bus proxy module) and stores the changed global variables.

[0064] This embodiment also provides a stopping algorithm for a verification platform of a multi-channel IO interface IP, including stopping data transmission in the IN direction, stopping data transmission in the OUT direction, and stopping the verification platform.

[0065] S1: cpu_agent first configures the DUT (Device Under Test) module and transmits the configuration information to data_agent through the UVM-based config_db mechanism; in addition, cpu_agent generates data packet information for each channel in the OUT direction, including length, number of packets, etc., and transmits it to bus_agent through the TLM (Transaction Level Modeling) model; after configuring the DUT module to be enabled, it sets dut_en to 1;

[0066] S2: The `data_agent_driver` in `data_agent` first waits for `dut_en` to be enabled. It then obtains register configuration information via the `config_db` mechanism, mainly including bit width, channel enable, and channel direction. Based on this information, it creates two channel arrays, `wr_channel_fifo` and `rd_channel_fifo`, containing the IN and OUT channel numbers respectively. Then, it divides the work into three processes:

[0067] S21 retrieves the data item sent through the sequencer and pushes the item into n channel FIFOs according to the channel address, denoted as trans_item_q[n];

[0068] S22 randomly accesses each channel according to the channel direction category. If it is the IN direction, it randomly retrieves a channel number addrx from wr_channel_fifo and checks whether trans_item_q[addrx] is empty. If it is empty, it deletes addrx from wr_channel_fifo. If it is not empty, it sends data in trans_item_q[addrx] according to the interface information of the module under test (DUT) and deletes the already sent packets. If it is the OUT direction, it randomly polls each OUT channel, monitors data according to the interface flow control information and sends it to the ref model. If none of the channels are readable, it waits for a specified period and if they are still unreadable, it sets dut_data2_rec_done to 1; or if rd_channel_fifo is empty, it sets dut_data2_rec_done to 1.

[0069] S23 This process determines the termination of the agent: if wr_channel_fifo is not empty, execute steps a and b; if rd_channel_fifo is not empty, execute step c; if both wr_channel_fifo and rd_channel_fifo are empty, and both b and c are satisfied, then the data proxy module terminates.

[0070] Wait for all items to be sent to be retrieved in S22 and put into trans_item_q;

[0071] b. Once each channel's trans_item_q is empty and the current item has been sent, set trans_data1_done to 1, meaning data transmission in the IN direction stops;

[0072] c. Wait for the step dut_data2_rec_done to be set to 1.

[0073] S3: bus_agent executes operations d, e, and f by monitoring the behavior of BUS2.

[0074] d. When the channel is in the OUT direction, the data packet is sent to BUS2 and recorded as driving data trans_data2, and driving data trans_data2 is sent to the ref model; if the packet information of S1 is empty, it is determined that the OUT direction transmission has ended, and trans_data2_done is set to 1, that is, the OUT direction data transmission stops; if the packet information of S1 is not empty, transmission continues.

[0075] e. Monitor the data dut_data1 entering in the IN direction based on the behavior of BUS2, and send it to the ref model;

[0076] f. Wait for trans_data2_done, trans_data1_done, and dut_data2_rec_done to be enabled. If enabled, monitor BUS2 for idle data cycles and then stop the bus proxy module.

[0077] The verification platform stops after the bus proxy module and data proxy module stop, and the scoring board completes the data verification and outputs the verification result, using the above stopping algorithm.

[0078] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the technical solutions of the present invention, and are not intended to limit the specific implementation of the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the claims of the present invention should be included within the protection scope of the claims of the present invention.

Claims

1. A verification platform for a multi-lane IO interface IP, characterized in that, The agent module, the reference model, the score board, the global variable pool, and the DUT; The agent module is configured to simulate external devices to provide driving data to all channels of the IO and transmit the driving data to the DUT, simulate CPU functions to configure the IP under test, and simulate bus functions to provide driving data for the bus under test; The reference model is configured to receive external driving data in the IN direction and internal data in the IN direction, perform bit conversion on the two-way data, convert the data into data of the same bit width, and send the data to the score board; and the reference model is configured to receive driving data in the OUT direction and internal data in the OUT direction, perform bit conversion on the two-way data, convert the data into data of the same bit width, and send the data to the score board; The score board is configured to receive two-way output data from the reference model, compare the two sets of output data, determine whether the two sets of output data are equal, and if the two sets of output data are equal, prove that the verification is correct, and if the two sets of output data are not equal, record the number of unequal data; The global variable pool is configured to provide global variables for the agent module and store changed global variables; The DUT is configured to process data in the IN direction of the agent module and process data in the OUT direction of the agent module; The agent module includes a CPU agent module, a data agent module, and a bus agent module; The CPU agent module is configured to simulate a CPU to generate register configuration information required by the DUT, configure the DUT register through the BUS1, transmit command information cmd0 to the data agent module, and transmit command information cmd1 to the bus agent module; The cmd0 includes channel enable information and channel direction information; and the cmd1 includes channel enable information, channel direction information, and data information of an output channel; The data agent module is configured to receive external driving data trans_data1 in the IN direction and simulate external devices to transmit the driving data to the DUT and the reference model; and the data agent module is configured to monitor and receive internal data dut_data2 transmitted by the channel in the OUT direction and transmit the internal data to the reference model; The bus agent module is configured to monitor and receive internal data dut_data1 in the IN direction and transmit the internal data to the reference model; and the bus agent module is configured to call a channel through a channel address, receive driving data trans_data2 from the channel in the OUT direction, and transmit the driving data to the reference model and the DUT; The global variable pool provides global variables for the CPU agent module, the data agent module, and the bus agent module, and the global variables include dut_en, trans_data1_done, trans_data2_done, and dut_data2_rec_done.

2. A stopping algorithm for a verification platform of a multi-channel IO interface IP as claimed in claim 1, characterized in that, The verification platform is stopped, and the specific steps are as follows: S1: the CPU agent module firstly configures the DUT, and transmits the configuration information to the data agent module through the config_db mechanism based on UVM; in addition, the CPU agent module generates the data packet information of each channel in the OUT direction, including the length and the number of packets, and transmits the information to the bus agent module through the TLM model; after the DUT is enabled after the configuration, the dut_en is set to 1; S2: the data agent module_driver in the data agent module firstly waits for the dut_en to be set to 1, obtains the register configuration information including the bit width, the channel enablement and the channel direction information through the config_db mechanism, establishes two channel arrays wr_channel_fifo and rd_channel_fifo according to the obtained information, and the two channel arrays respectively contain the IN direction channel number and the OUT direction channel number, and ends the data agent module according to the two channel arrays; S3: the bus agent module executes operations d, e and f by monitoring the behavior of BUS2: d. when the channel is in the OUT direction, the data packet is sent to BUS2 and is recorded as the driving data trans_data2, and the driving data trans_data2 is sent to the reference model; according to the packet information of S1, if it is empty, it is judged that the OUT direction sending is ended, and the trans_data2_done is set to 1, that is, the OUT direction sending data is stopped; if the packet information of S1 is not empty, the sending is continued; e. the internal data dut_data1 in the IN direction is monitored according to BUS2, and is sent to the reference model; f. the trans_data2_done, the trans_data1_done and the dut_data2_rec_done are enabled, and the bus agent module is stopped after the BUS2 is monitored to be idle for a specified data period.

3. The stopping algorithm of a verification platform of a multi-channel IO interface IP according to claim 2, wherein, The S2 specifically includes: S21, the data item sent through the sequencer is obtained, and the item is pressed into n channel FIFOs according to the channel address, and is recorded as trans_item_q[n]; S22, each channel is randomly accessed according to the channel direction category, if it is in the IN direction, a channel number addrx is randomly taken out from the wr_channel_fifo, and whether trans_item_q[addrx] is empty is checked; if it is empty, the addrx is deleted from the wr_channel_fifo; if it is not empty, the data is sent in trans_item_q[addrx] according to the DUT interface information, and the sent packet is deleted; if it is in the OUT direction, each OUT channel is randomly polled, the data is monitored according to the interface flow control information and is sent to the reference model; if all the channels are not readable, and after waiting for a specified period, they are still not readable, the dut_data2_rec_done is set to 1; or the rd_channel_fifo is empty, the dut_data2_rec_done is set to 1; S23, judging the stop of the agent: if wr_channel_fifo is not empty, execute a and b; if rd_channel_fifo is not empty, execute c; if wr_channel_fifo and rd_channel_fifo are both empty, and b and c are both satisfied, end the data agent module a. wait for all the items to be sent in S22 to be put into trans_item_q; b. until each channel trans_item_q is empty and the current item is sent, set trans_data1_done to 1, i.e. stop sending data in the IN direction; c. wait for dut_data2_rec_done to be set to 1; After the bus agent module and the data agent module are stopped, and the score board checks the data and outputs the checking result, the verification platform is stopped.

Images