CN116306398A - Verification platform of multi-channel IO interface IP and stopping algorithm thereof - Google Patents

Abstract

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

Description

Verification platform of multi-channel IO interface IP and stopping algorithm thereof

Technical Field

The invention belongs to the technical field of IP verification, and particularly relates to a verification platform of a multichannel IO interface IP and a stopping algorithm thereof.

Background

IP (Intellectual Property) design is an important link in the chip design process, stable and reliable IP is a guarantee of chip success, and IP verification is a core link of IP development. Compared with the IP design, the IP design usually needs to take 2 times of time to perform IP verification, so that the reliability of the IP is ensured. With the rapid development of integrated circuits, the complexity of IP increases and verification becomes more and more difficult.

The multi-channel IO interface IP is provided with a plurality of channels, and two data flows of input and output are respectively provided. Because the number of the channels is large, the transmission directions of the channels are different, the combination is various, and the control of the stop time of the verification platform is particularly important when testing a large amount of data. Conventional verification techniques have significant difficulty in verifying such IPs and fail to provide an effective simulated downtime reference, making verification platforms ineffective for longer runs.

The invention of Chinese patent document CN109614368A discloses a module verification platform and method of a system-on-chip IP, comprising the following steps: virtual CPU, virtual memory, and cmd_agent, data agent module, and scu_agent that can be controlled by instructions and respectively correspond to IP interfaces; allocating different data bus addresses for the virtual memory, the cmd_agent, the data agent module and the scu_agent; the virtual CPU establishes communication with the virtual memory, the cmd_agent, the data agent module and the scu_agent through a virtual data bus. However, the method cannot drive the multichannel IO interface, cannot verify the data correctness of the IO interface IP and cannot effectively provide a stop time reference.

Disclosure of Invention

The invention aims to overcome at least one defect of the prior art and provides a verification platform of a multi-channel IO interface IP and a stopping algorithm thereof.

The detailed technical scheme of the invention is as follows:

the invention provides a verification platform of a multi-channel IO interface IP and a stopping algorithm thereof, which aims to solve the problems that simulation stopping time reference cannot be provided effectively and efficiently and a plurality of channels cannot be supported when test data are large in the prior art.

In order to achieve the above object, the present invention provides a verification platform for a multi-channel IO interface IP, including: the system comprises an agent module, a reference model, a score board, a global variable pool and a module DUT to be tested;

the proxy module is used for simulating external equipment to provide driving data for all channels of IO and transmitting the driving data to the module DUT to be tested, simulating the CPU function to configure the IP to be tested, and simulating the bus function to provide driving data for the bus to be tested;

the reference model is used for receiving external driving data trans_data1 IN an IN direction and internal data dur_data1 IN the IN direction, performing bit conversion on the two paths of data, converting the two paths of data into data with the same bit width, and transmitting the data to the score board; the reference model receives driving data trans_data2 from the OUT direction and internal data dur_data2 from the OUT direction, performs bit conversion on the two paths of data, converts the two paths of data into data with the same bit width and sends the data to the score board;

the scoring board is used for receiving two paths of output data from the reference model, comparing the two paths of output data, judging whether the two paths of output data are equal, if so, proving that the verification is correct, and if not, recording the number of unequal data;

the global variable pool provides global variables for agent modules (CPU agent modules, data agent modules and bus agent modules) and stores the changed global variables;

further, when different proxy modules work simultaneously, the global variable pool can be identified by different signals according to the execution progress of the different proxy modules, such as the dut_en, the trans_data1_done, the trans_data2_done and the dut_data2_rec_done; when the multi-channel verification is performed, the global variable pool can endow the agent module with different global variables according to the channel transmission type, so that the agent module is more convenient and accurate, and the storage of the changed global variables is convenient for analysis after verification errors;

the DUT processes the data IN the IN direction IN the proxy module and processes the data IN the OUT direction IN the proxy module.

The agent module comprises a CPU agent module, a data agent module and a bus agent module; the device is respectively used for configuring the DUT, the driving and sampling interface data and the driving and sampling bus data of the module to be tested;

specifically, the CPU proxy module is used for simulating the CPU to generate register configuration information required by the DUT of the module to be tested, configuring the DUT register of the module to be tested through the BUS1, transmitting command information cmd0 to the data proxy module, and transmitting command information cmd1 to the BUS proxy module;

the data agent module is used for receiving external driving data trans_data1 IN the IN direction, simulating external equipment to send to the module DUT to be tested and receiving external driving data trans_data1 sent IN the IN direction and transmitting to the reference model; the data agent module monitors and receives internal data dur_data2 sent by the OUT direction channel and transmits the internal data dur_data2 to the reference model;

the bus agent module is used for monitoring and receiving data dur_data1 of the module DUT to be tested IN the IN direction and transmitting the data dur_data1 to the reference model; the bus agent module receives driving data trans_data2 from the OUT direction channel through a channel address calling channel, and transmits the driving data trans_data2 in the OUT direction to a reference model and a module DUT to be tested according to command information cmd 1;

the cmd0 comprises channel enabling information and channel direction information; the cmd1 includes channel enabling information, channel direction information, and data information of each output channel.

The invention also provides a stopping algorithm of the verification platform of the multi-channel IO interface IP, which comprises the following specific steps of stopping the data transmission IN the IN direction, stopping the data transmission IN the OUT direction and stopping the verification platform:

s1: the CPU proxy module firstly configures a DUT (device under test) of the module to be tested, and transmits configuration information to the data proxy module through a config_db mechanism based on UVM; in addition, the CPU proxy module generates data packet information of each channel in the OUT direction, including information such as length, packet number and the like, and transmits the data packet information to the bus proxy module through a TLM (Transaction Level Modeling ) model; after the DUT (device under test) is configured, setting the dut_en to 1;

s2: the method comprises the steps that a data agent module_driver IN a data agent module firstly waits for the dut_en to be set 1, acquires register configuration information mainly including information such as bit width, channel enabling, channel direction and the like through a config_db mechanism, and establishes two channel arrays according to the acquired information to respectively comprise an IN-direction channel number and an OUT-direction channel number;

s21, acquiring data item sent by a sequencer, and pressing the item into n channel FIFOs according to channel addresses, wherein the item is expressed as trans_item_q [ n ];

s22, randomly accessing each channel according to the channel direction category, and if the channel is IN the IN direction, randomly taking out a certain channel number addrx from the wr_channel_fifo, and checking whether trans_item_q [ addrx ] is empty; if the data is empty, the addrx is deleted from the wr_channel_fifo, if the data is not empty, the data is sent in the trans_item_q [ addrx ] according to the DUT interface information of the module to be tested, and the sent packet is deleted; if the channel is in the OUT direction, randomly polling each OUT channel, carrying OUT monitoring data according to interface flow control information, sending the monitoring data to a reference model, and if all the channels are unreadable and remain unreadable after waiting for a specified period, setting the dut_data2_rec_done to be 1; or rd_channel_fifo is empty, set the dur_data2_rec_done to 1;

s23, judging the stopping of the agent: and if the wr_channel_fifo is not empty, executing a and b, if the rd_channel_fifo is not empty, executing c, and if the wr_channel_fifo and the rd_channel_fifo are both empty, and simultaneously satisfying b and c and ending the data proxy module:

a. waiting for S22 to acquire all the items to be sent and putting the items into trans_item_q;

b. setting the trans_data1_done to 1, namely stopping transmitting data IN the IN direction until each channel trans_item_q is empty and the current item is transmitted;

c. waiting for step dur_data2_rec_done to set 1;

the data agent module finishes the steps S21, S22 and S23, and the data agent module is finished;

s3, the BUS agent module executes operations d, e and f by monitoring the behaviors of the BUS 2:

d. when the channel is in the OUT direction, sending the data packet to BUS2 to be recorded as driving data trans_data2, and sending the driving data trans_data2 to the reference model; judging that the sending of the OUT direction is finished according to the fact that the packet information of the S1 is empty, and setting the trans_data2_done to 1, namely stopping sending data in the OUT direction; if the packet information according to the S1 is not empty, continuing to transmit; the method comprises the steps of carrying out a first treatment on the surface of the

e. Monitoring IN-direction data due_data1 according to the behavior of BUS2, and sending the data to a reference model;

f. waiting for the trans_data2_done, trans_data1_done, and dutdata2_rec_done to be enabled, and stopping the BUS agent module after the monitoring BUS2 is idle for a specified data period.

After the bus agent module and the data agent module are stopped by the stopping algorithm, and the scoreboard stops the verification platform after finishing data verification and outputting a verification result.

Compared with the prior art, the invention has the beneficial effects that:

(1) Compared with the traditional verification platform, the verification platform for the multi-channel IO interface IP can be used for configuring the number and the direction of the channels, configuration information of the channel can be transmitted into the verification platform, the verification platform can generate test vectors according to actual configuration, the reusability of verification components is greatly improved, the verification efficiency is improved, the verification complexity is reduced, and a global variable pool is provided, different global variables can be endowed to the proxy module according to channel transmission types, so that the analysis after verification errors is facilitated by storing the changed global variables, and the system is more convenient and accurate.

(2) According to the stopping algorithm of the multi-channel IO interface IP verification platform, provided by the invention, the verification time is shortened on the premise of finishing verification of each channel by stopping the data transmission IN the IN direction, the data transmission IN the OUT direction and the verification platform, the verification efficiency is improved, and the verification platform is stopped by stopping the operation of the data agent module and the bus agent module respectively, so that the efficiency and the accuracy of the verification platform are further enhanced.

Drawings

Fig. 1 is a frame and a flowchart of a multi-channel IO interface IP verification platform according to embodiment 1 of the present invention.

Fig. 2 is an IP frame diagram of a multi-channel IO interface in embodiment 1 of the present invention.

Detailed Description

The disclosure is further described below with reference to the drawings and examples.

It should be noted that the following detailed description is exemplary and is intended to provide further explanation of the present disclosure. Unless defined otherwise, 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 belongs.

It is noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of exemplary embodiments in accordance with the present disclosure. As used herein, the singular is also intended to include the plural unless the context clearly indicates otherwise, and furthermore, it is to be understood that the terms "comprises" and/or "comprising" when used in this specification are taken to specify the presence of stated features, steps, operations, devices, components, and/or combinations thereof.

Embodiments of the present disclosure and features of embodiments may be combined with each other without conflict.

Example 1

The embodiment provides a verification platform for a multi-channel IO interface IP, wherein a channel IO interface IP frame diagram is shown in fig. 2: the system comprises a BUS1, a channel 1 and a channel 2, wherein the BUS1 is used for a CPU to configure a DUT register of a module to be tested, and can be a BUS meeting protocols such as apb, ahb and the like, and is connected with a CPU proxy module of a verification platform; the channel x (namely any one of the channels 1 to n) is an interface of the IP and the external equipment, provides input and output data channels, and each channel supports two modes of input and output and is connected with a data agent module of the verification platform; BUS2 is a transmission data channel of the IP and the chip internal processing unit, and can support a BUS protocol such as ahb \axi and the like, and is connected with a BUS agent module.

As shown in fig. 1, the verification platform of the multi-channel IO interface IP includes: the system comprises an agent module, a reference model, a score board, a global variable pool and a module DUT to be tested;

the proxy module is used for simulating external equipment to provide driving data or collecting interface data for all channels of IO (namely IN direction and OUT direction) and transmitting the driving data or the collecting interface data to the module DUT to be tested, the simulation CPU function is used for configuring IP to be tested, and the simulation bus function is used for providing driving data and collecting interface data for the bus to be tested; the agent module comprises a CPU agent module, a data agent module and a bus agent module:

the CPU agent module is packaged by adopting a cpu_agent, the data agent module is packaged by adopting a data_agent, and the bus agent module is packaged by adopting a bus_agent;

the reference model is ref model in fig. 1; the score board is a score board in fig. 1; the global variable pool is global_var in fig. 1.

The ref model is used as a reference model, receives external driving data trans_data1 from an IN direction and internal data dur_data1 monitored by a bus_agent IN the IN direction, performs bit conversion on two paths of data, converts the two paths of data into data with the same bit width, and sends the data to a scoreboard; the ref model receives driving data trans_data2 of the bus_agent from the OUT direction and internal data dur_data2 of which the OUT direction is monitored by the data_agent, performs bit conversion on the two paths of data, converts the two paths of data into data with the same bit width and sends the data to a scoreboard; the trans_data1 and trans_data2 are trans_data type data, and the dutjdata1 and dutjdata2 are dutjdata type data, which are common knowledge in the art.

The scoreboard is used as a scoreboard and has the functions of receiving ref_data and DUT_data from a ref model, comparing and judging whether the two groups of data are equal, if so, proving that the verification is correct, and if not, recording the number of unequal data.

The global variable pool is global_var in fig. 1, and provides global variables for the agent module and stores the changed global variables, wherein the global variables include but are not limited to, dut_en, trans_data1_done, trans_data2_done, and dut_data2_rec_done;

the DUT processes the data IN the IN direction IN the proxy module; and processing the data in the OUT direction in the proxy module.

Further, when the proxy module performs data transmission with different channels, the global variable pool can assign values to different variables according to the states of different proxy modules.

The agent modules comprise a CPU agent module (cpu_agent), a data agent module (data_agent) and a bus agent module (bus_agent);

the CPU_agent is used for simulating register configuration information required by a CPU to generate a module DUT to be tested, configuring a module DUT register to be tested through the BUS1, transmitting partial command information cmd0 to the data_agent, and transmitting partial command information cmd1 to the bus_agent; the cmd0 comprises channel enabling information and channel direction information; the cmd1 includes channel enabling information, channel direction information, and data information of each output channel.

The data_agent is used for receiving external driving data trans_data1 IN an IN direction, simulating external equipment to send to a module DUT to be tested and receiving external driving data trans_data1 sent by an IN direction channel and transmitting to a ref model; and the data_agent monitors and receives the internal data dur_data2 sent by the OUT direction channel and transmits the internal data dur_data2 to the ref model, as shown in FIG. 1.

The bus_agent is used for monitoring and receiving internal data due_data1 IN the IN direction and transmitting the internal data due_data1 to the ref model; the bus agent calls a channel through a channel address and receives driving data trans_data2 from the channel, and according to command information cmd1, the bus agent transmits the driving data trans_data2 in the OUT direction to a ref model and a module DUT to be tested; as shown in fig. 1.

The DUT performs test processing on external driving data trans_data1 IN the IN direction IN the data_agent to obtain the dutdata1 and transmits the dutdata1 to the bus_agent; and performing test processing on the driving data trans_data2 in the OUT direction in the bus_agent to obtain the dur_data2, and transmitting the dur_data2 to the data_agent.

The following is the processing flow of the IN direction and the OUT direction:

for the IN direction, i.e., from the data agent to the bus agent; the data agent module receives external driving data trans_data1 from the channel and provides data for the reference model and the DUT (device under test) through the address of the driving channel; the DUT (device under test) processes the data according to the configuration information of the CPU proxy module to obtain the dur_data1; the bus agent module monitors and receives the data IN the IN direction, namely, the data of the dut_data1 is received and transmitted to the reference model; at this time, the reference model performs bit conversion on two paths of data (external driving data trans_data1 and dur_data1), converts the two paths of data into data with the same bit width and sends the data to the score board; the scoring board compares the two groups of output data, judges whether the two groups of output data are equal, if so, the scoring board proves that the verification is correct, and if not, the scoring board records the number of the unequal data;

for the OUT direction, i.e., from the bus agent to the data agent; the bus agent module calls a certain channel and receives driving data trans_data2 from the channel, and then provides data for a reference model and a DUT (device under test) through a driving bus address; the DUT (device under test) processes the data according to the configuration information of the CPU proxy module to obtain the dur_data2; the data agent module monitors and receives data in the OUT direction, namely, the data agent module receives the dut_data2 and transmits the data to the reference model; at this time, the reference model performs bit conversion on two paths of data (drive data trans_data2 and dur_data2), converts the two paths of data into data with the same bit width and sends the data to the score board; the scoring board compares the two groups of output data, judges whether the two groups of output data are equal, if so, the scoring board proves that the verification is correct, and if not, the scoring board records the number of the unequal data;

the CPU proxy module is used for simulating the CPU to generate register configuration information required by the DUT of the module to be tested, configuring the register of the DUT of the module to be tested through the BUS1, transmitting command information cmd0 to the data proxy module, and transmitting the command information cmd1 to the BUS proxy module; the global variable pool provides global variables for the agent modules (CPU agent module, data agent module and bus agent module) and stores the changed global variables.

The embodiment also provides a stopping algorithm of the verification platform of the multi-channel IO interface IP, which comprises stopping the data transmission IN the IN direction, stopping the data transmission IN the OUT direction and stopping the verification platform.

S1: firstly, configuring a to-be-tested module DUT by a cpu_agent, and transmitting configuration information to a data_agent through a config_db mechanism based on UVM; in addition, the cpu_agent generates data packet information of each channel in the OUT direction, including information such as length, packet number and the like, and transmits the data packet information to the bus_agent through a TLM (Transaction Level Modeling ) model; after the DUT (device under test) is configured, setting the dut_en to 1;

s2: the data_agent_driver IN the data_agent waits for the dut_en to be enabled first, acquires register configuration information, mainly including information of bit width, channel enabling, channel direction and the like, and establishes two channel arrays, namely wr_channel_fifo and rd_channel_fifo, respectively including an IN-direction channel number and an OUT-direction channel number according to the acquired information. Then the operation is performed by three processes:

s21, acquiring data item sent by a sequencer, and pressing the item into n channel FIFOs according to channel addresses, wherein the item is expressed as trans_item_q [ n ];

s22, randomly accessing each channel according to the channel direction category, and if the channel is IN the IN direction, randomly taking out a certain channel number addrx from the wr_channel_fifo, and checking whether trans_item_q [ addrx ] is empty; if the address is empty, deleting the addrx from the wr_channel_fifo; if not, transmitting data according to DUT interface information of the module to be tested in the trans_item_q [ addrx ] and deleting the transmitted packet; if the channel is in the OUT direction, randomly polling each OUT channel, carrying OUT monitoring data according to interface flow control information, sending the monitoring data to a ref model, if all the channels are unreadable, waiting for a specified period and still being unreadable, and setting the dut_data2_rec_done to be 1; or rd_channel_fifo is empty, set the dur_data2_rec_done to 1;

s23 the process determines that the agent is stopped: and if the wr_channel_fifo is not empty, executing a and b, if the rd_channel_fifo is not empty, executing c, and if the wr_channel_fifo and the rd_channel_fifo are both empty, and simultaneously satisfying b and c and ending the data proxy module:

waiting for S22 to acquire all the items to be sent and putting the items into trans_item_q;

b. setting the trans_data1_done to 1, namely stopping transmitting data IN the IN direction until each channel trans_item_q is empty and the current item is transmitted;

c. wait for step dur_data2_rec_done to set 1.

S3: bus_agent performs operations d, e, f by monitoring the behavior of BUS 2:

d. when the channel is in the OUT direction, the data packet is sent to BUS2 and recorded as driving data trans_data2, and the driving data trans_data2 is sent to a ref model; judging that the sending of the OUT direction is finished according to the fact that the packet information of the S1 is empty, and setting the trans_data2_done to 1, namely stopping sending data in the OUT direction; if the packet information according to the S1 is not empty, continuing to transmit; the method comprises the steps of carrying out a first treatment on the surface of the

e. Monitoring IN-direction data dur_data1 according to the behavior of BUS2, and sending the data to a ref model;

f. waiting for the trans_data2_done, trans_data1_done, and dutdata2_rec_done to be enabled, and stopping the BUS agent module after the monitoring BUS2 is idle for a specified data period.

After the bus agent module and the data agent module are stopped by the stopping algorithm, and the scoreboard stops the verification platform after finishing data verification and outputting a verification result.

It should be understood that the foregoing examples of the present invention are merely illustrative of the present invention and are not intended to limit the present invention to the specific embodiments thereof. Any modification, equivalent replacement, improvement, etc. that comes within the spirit and principle of the claims of the present invention should be included in the protection scope of the claims of the present invention.

Claims (6)

1. The verification platform of the multi-channel IO interface IP is characterized by comprising an agent module, a reference model, a score board, a global variable pool and a module DUT to be tested;

the proxy module is used for simulating external equipment to provide driving data for all channels of IO and transmitting the driving data to the module DUT to be tested, simulating the CPU function to configure the IP to be tested, and simulating the bus function to provide driving data for the bus to be tested;

the reference model is used for receiving external driving data IN the IN direction and internal data IN the IN direction, performing bit conversion on the two paths of data, converting the two paths of data into data with the same bit width, and transmitting the data to the score board; the reference model receives driving data from the OUT direction and internal data from the OUT direction, performs bit conversion on the two paths of data, converts the two paths of data into data with the same bit width, and sends the data to the score board;

the scoring board is used for receiving two paths of output data from the reference model, comparing the two paths of output data, judging whether the two paths of output data are equal, if so, proving that the verification is correct, and if not, recording the number of unequal data;

the global variable pool provides global variables for the agent module and stores the changed global variables;

the DUT processes the data IN the IN direction IN the proxy module; and processing the data in the OUT direction in the proxy module.

2. The authentication platform of the multi-channel IO interface IP of claim 1, wherein the proxy module includes a CPU proxy module, a data proxy module, a bus proxy module;

the CPU agent module is used for simulating the CPU to generate register configuration information required by the DUT of the module to be tested, configuring the DUT register of the module to be tested through the BUS1, transmitting command information cmd0 to the data agent module, and transmitting command information cmd1 to the BUS agent module;

the data agent module is used for receiving external driving data trans_data1 IN the IN direction and simulating external equipment to send to the module DUT to be tested and the reference model; the data agent module monitors and receives internal data dur_data2 sent by the OUT direction channel and transmits the internal data dur_data2 to the reference model;

the bus agent module is used for monitoring and receiving internal data due_data1 IN the IN direction and transmitting the internal data due_data1 to the reference model; and the bus agent module calls the channel through the channel address, receives the driving data trans_data2 from the channel in the OUT direction, and transmits the driving data trans_data2 to the reference model and the module DUT to be tested.

3. The platform of claim 2, wherein the global variable pool provides global variables for the CPU agent module, the data agent module, and the bus agent module, respectively, the global variables including dur_en, trans_data1_done, trans_data2_done, and dur_data2_rec_done.

4. The platform for verifying a multi-channel IO interface IP of claim 2, wherein cmd0 includes channel enable information, channel direction information; the cmd1 includes channel enabling information, channel direction information, and data information of an output channel.

5. A stopping algorithm of the verification platform of the multi-channel IO interface IP as claimed IN any one of claims 1 to 4, comprising the steps of IN direction data transmission stop, OUT direction data transmission stop, verification platform stop:

s1: the CPU proxy module firstly configures a DUT (device under test) of the module to be tested, and transmits configuration information to the data proxy module through a config_db mechanism based on UVM; in addition, the CPU proxy module generates data packet information of each channel in the OUT direction, including length and packet number information, and transmits the data packet information to the bus proxy module through the TLM model; after the DUT (device under test) is configured, setting the dut_en to 1;

s2: the method comprises the steps that a data agent module_driver IN a data agent module firstly waits for the dut_en to be set 1, acquires register configuration information comprising bit width, channel enabling and channel direction information through a config_db mechanism, establishes two channel arrays as wr_channel_fifo and rd_channel_fifo according to the acquired information, respectively comprises an IN direction channel number and an OUT direction channel number, and ends the data agent module according to the two channel arrays;

s3: the BUS agent module performs operations d, e, f by monitoring the behavior of BUS 2:

d. when the channel is in the OUT direction, sending the data packet to BUS2 to be recorded as driving data trans_data2, and sending the driving data trans_data2 to the reference model; judging that the sending of the OUT direction is finished according to the fact that the packet information of the S1 is empty, and setting the trans_data2_done to 1, namely stopping sending data in the OUT direction; if the packet information according to the S1 is not empty, continuing to transmit;

e. monitoring internal data dur_data1 IN the IN direction according to the BUS2 and sending the internal data dur_data1 to a reference model;

f. waiting for the trans_data2_done, trans_data1_done, and dutdata2_rec_done to be enabled, and stopping the BUS agent module after the monitoring BUS2 is idle for a specified data period.

6. The stopping algorithm of the verification platform of the multi-channel IO interface IP of claim 4, wherein S2 specifically includes:

s21, acquiring data item sent by a sequencer, and pressing the item into n channel FIFOs according to channel addresses, wherein the item is expressed as trans_item_q [ n ];

s22, randomly accessing each channel according to the channel direction category, and if the channel is IN the IN direction, randomly taking out a certain channel number addrx from the wr_channel_fifo, and checking whether trans_item_q [ addrx ] is empty;

if the address is empty, deleting the addrx from the wr_channel_fifo; if not, transmitting data according to DUT interface information of the module to be tested in the trans_item_q [ addrx ] and deleting the transmitted packet;

if the direction is the OUT direction, randomly polling each OUT channel, monitoring data according to interface flow control information, and sending the data to a reference model;

if all channels are unreadable and remain unreadable after waiting for a specified period, setting the dut_data2_rec_done to 1; or rd_channel_fifo is empty, set the dur_data2_rec_done to 1;

s23, judging the stopping of the agent: if wr_channel_fifo is not empty, executing a and b; c is executed if rd_channel_fifo is not null; if the wr_channel_fifo and the rd_channel_fifo are both empty, and the b and c re-ending data proxy module is simultaneously satisfied

a. Waiting for S22 to acquire all the items to be sent and putting the items into trans_item_q;

b. setting the trans_data1_done to 1, namely stopping transmitting data IN the IN direction until each channel trans_item_q is empty and the current item is transmitted;

c. waiting for step dur_data2_rec_done to set 1;

and after the bus agent module and the data agent module are stopped, stopping the verification platform when the score board finishes data verification and outputs a verification result.

Images