AXI bus monitor verification system, method, electronic device and storage medium

Abstract

This application provides an Axi bus monitor verification system, method, electronic device, and storage medium. The verification system includes a module to be verified, a data interaction module, and a verification judgment module. The module to be verified can detect the level of the data transmission channel between the master and slave devices in the data interaction module, and then, when the handshake feedback channel between the slave and master devices is high, it counts the response time of the slave device feeding back the target data to the master device. The verification judgment module can obtain expected information corresponding to the verification information output by the module to be verified, and compare the verification information and the expected information when the module to be verified outputs verification information to determine whether the anti-hang-up function of the module to be verified is operating normally. This enables the verification of the anti-hang-up function of the module to be verified, which is beneficial for maintaining the normal operation of the chip equipped with the module to be verified.

Description

Technical Field

[0001] This application belongs to the field of chip verification technology, and in particular relates to an AXI bus monitor verification system, method, electronic device and storage medium. Background Technology

[0002] In a chip, master and slave devices can exchange data via a data transmission channel based on the AXI (Advanced eXtensible Interface) protocol. However, during data transmission, the operating status of either the master or slave device can cause transmission anomalies. For example, if the master device is reading data from the slave device while the slave device is busy, it may be difficult to promptly send feedback to the master, causing the AXI bus to hang and ultimately leading to a malfunction in the chip system.

[0003] Therefore, during the chip design process, a monitor can be set up to monitor the status of the data transmission channel to determine whether there is an AXI bus hang. If an AXI bus hang is found, an exception message can be generated in a timely manner or the monitor can assist the master and slave devices in resolving the AXI bus hang issue.

[0004] Because the monitor needs to monitor a large number of data channels and is used to maintain the normal operation of the chip, the monitor design needs to be verified to ensure the normal operation of the monitor and thus maintain the normal operation of the chip. Summary of the Invention

[0005] This application provides an Axi bus monitor verification system, method, electronic device, and storage medium to address the lack of suitable verification methods for the anti-hang-up function of monitors in chips.

[0006] In a first aspect, this application provides an Axi bus monitor verification system, comprising: a module to be verified, a data interaction module, and a verification judgment module; the data interaction module includes a master device and a slave device connected based on a data transmission channel; the data transmission channel between the master device and the slave device includes at least a handshake request channel, a handshake feedback channel, and a data feedback channel.

[0007] The module to be verified is configured to: start a counter when it is detected that the levels corresponding to the handshake request channel and the handshake feedback channel are both high; the high level corresponding to the handshake request channel is used to indicate that the master device has sent a handshake request command to the slave device; the high level corresponding to the handshake feedback channel is used to indicate that the slave device has fed back a confirmation handshake command to the master device;

[0008] If the level of the data feedback channel is detected to be pulled high, the counter is stopped;

[0009] If the data response time of the slave device, as represented by the count value of the counter, is greater than a time threshold, then verification information is generated; and the verification information is sent to the verification judgment module; the verification information includes at least a verification interruption result and a verification timestamp; the verification interruption result is used to represent the data feedback status between the master device and the slave device; the verification timestamp is used to represent the time when the verification interruption result was generated;

[0010] The verification and judgment module is configured as follows:

[0011] Obtain the expected information corresponding to the module to be verified; the expected information includes the expected interruption result and the expected timestamp.

[0012] If the expected interruption result is the same as the verification interruption result, and the expected timestamp is the same as the verification timestamp, then a first report information is generated to characterize that the module to be verified has passed the verification.

[0013] If the expected interruption result differs from the verification interruption result, and / or the expected timestamp differs from the verification timestamp, then a second report is generated to characterize that the module to be verified has failed verification.

[0014] In some feasible embodiments, the handshake request channel includes a read handshake request channel; the handshake feedback channel includes a read handshake feedback channel; the data feedback channel includes a read data feedback channel; and the module to be verified includes at least a read detection port connected to the read handshake request channel, the read handshake feedback channel, and the read data feedback channel.

[0015] During the data read interaction process between the master device and the slave device, the module to be verified is configured as follows:

[0016] If the read handshake request channel and the read handshake feedback channel are both detected to be at a high level through the read detection port, start the counter;

[0017] If the level of the read data feedback channel is detected to be pulled high, the counter is stopped;

[0018] If the count value of the counter, representing the read data response time of the slave device, is greater than a time threshold, then verification information is generated.

[0019] In some feasible embodiments, the handshake request channel includes a write handshake request channel; the handshake feedback channel includes a write handshake feedback channel; the data feedback channel includes a write data feedback channel; and the module to be verified includes at least a write detection port connected to the write handshake request channel, the write data feedback channel, and the write data feedback channel.

[0020] During the write data interaction process between the master device and the slave device, the module to be verified is configured as follows:

[0021] If the write handshake request channel and the write handshake feedback channel are both detected to be at a high level through the write detection port, start the counter;

[0022] If the level of the write data feedback channel is detected to be pulled high, the counter is stopped;

[0023] If the write data response time of the slave device, as represented by the counter's count value, is greater than a time threshold, then verification information is generated.

[0024] In some feasible embodiments, the verification and judgment module includes a reference model and a scoreboard; the reference model includes at least a model detection port connected to the handshake request channel, the handshake feedback channel, and the data feedback channel;

[0025] The scoreboard is configured to: acquire the expected information generated by the reference model based on the data interaction process performed by the master device and the slave device;

[0026] If the expected interruption result is the same as the verification interruption result, and the expected timestamp is the same as the verification timestamp, then a first report information is generated to characterize that the module to be verified has passed the verification.

[0027] If the expected interruption result differs from the verification interruption result, and / or the expected timestamp differs from the verification timestamp, then a second report is generated to characterize that the module to be verified has failed verification.

[0028] In some feasible embodiments, a verification information relay port is also included;

[0029] The module to be verified executes the sending of the verification information to the verification judgment module, specifically configured to send the verification information to the scoring board through the verification information relay port.

[0030] In some feasible embodiments, it also includes: a configuration module;

[0031] The configuration module is configured to: generate configuration information in response to a configuration information write command; the configuration information includes at least the time threshold or the counter's count threshold;

[0032] The module to be verified is further configured to: Before the master device and the slave device perform the data interaction process, the module to be verified is configured to:

[0033] The configuration information is obtained from the configuration module.

[0034] In some feasible embodiments, the verification of the interrupt result includes at least the read interrupt result, the write interrupt result, and the overall interrupt result;

[0035] When the data response time of the slave device, as represented by the counter's count value, is greater than a time threshold, and the module to be verified is generated, it is further configured to:

[0036] Perform a bitwise OR operation on the read interrupt result and the write interrupt result to obtain the overall interrupt result;

[0037] The verification information is generated based on the read interrupt result, the write interrupt result, and the overall interrupt result.

[0038] The verification information is sent to the verification judgment module.

[0039] Secondly, this application provides an Axi bus monitor verification method, which can be applied to the Axi bus monitor verification system described in the first aspect. The verification method includes:

[0040] When the levels corresponding to both the handshake request channel and the handshake feedback channel are detected to be high, a counter is started; the high level corresponding to the handshake request channel indicates that the master device has sent a handshake request command to the slave device; the high level corresponding to the handshake feedback channel indicates that the slave device has sent a confirmation handshake command back to the master device.

[0041] If the level of the data feedback channel is detected to be pulled high, the counter is stopped;

[0042] If the data response time of the slave device, as represented by the count value of the counter, is greater than a time threshold, then verification information is generated; and the verification information is sent to the verification judgment module; the verification information includes at least a verification interruption result and a verification timestamp; the verification interruption result is used to represent the data feedback status between the master device and the slave device; the verification timestamp is used to represent the time when the verification interruption result was generated;

[0043] Obtain the expected information corresponding to the verification information; the expected information includes the expected interruption result and the expected timestamp.

[0044] If the expected interruption result is the same as the verification interruption result, and the expected timestamp is the same as the verification timestamp, then a first report information is generated to characterize the verification as passed.

[0045] If the expected interruption result differs from the verification interruption result, and / or the expected timestamp differs from the verification timestamp, a second report is generated to characterize the verification failure.

[0046] Thirdly, this application provides an electronic device including a processor and a memory communicatively connected to the processor. The memory stores instructions executable by the processor to cause the processor to perform the steps of the verification method in the second aspect.

[0047] Fourthly, this application provides a computer-readable storage medium including at least one computer instruction for causing a computer to perform the steps of the verification method in the second aspect.

[0048] As described above, this application provides an Axi bus monitor verification system, method, electronic device, and storage medium. The verification system includes a module to be verified, a data interaction module, and a verification judgment module. The module to be verified can detect the level of the data transmission channel between the master and slave devices in the data interaction module, and then, when the handshake feedback channel between the slave and master devices is high, it calculates the response time of the slave device feeding back the target data to the master device. The verification judgment module can acquire expected information corresponding to the verification information output by the module to be verified, and compare the verification information and expected information when the module to be verified outputs verification information to determine whether the anti-hangover function of the module to be verified is operating normally. This enables the verification of the anti-hangover function of the module to be verified, which is beneficial for maintaining the normal operation of the chip equipped with the module to be verified. Attached Figure Description

[0049] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0050] Figure 1 A schematic diagram of the monitor's working principle provided in the embodiments of this application;

[0051] Figure 2 This is a structural diagram of the monitor anti-hook function verification system provided in the embodiments of this application;

[0052] Figure 3 A flowchart illustrating the verification process for the monitor anti-hook function provided in this application embodiment;

[0053] Figure 4 A flowchart illustrating the judgment process when generating verification information for the module to be verified provided in this embodiment of the application.

[0054] Figure 5A flowchart illustrating the judgment process for determining verification information and expected information using a scoreboard, as provided in this embodiment of the application.

[0055] Figure 6 A flowchart illustrating the judgment process of the module to be verified in an embodiment of this application when the master device and the slave device perform read data interaction.

[0056] Figure 7 The flowchart illustrates the judgment process of the module to be verified in this application embodiment when the master device and slave device perform write data interaction. Detailed Implementation

[0057] The embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described below do not represent all embodiments consistent with this application. They are merely examples of systems and methods consistent with some aspects of this application as detailed in the claims.

[0058] During chip operation, the master and slave devices within the chip can interact via the AXI bus (Advanced Dextensible Interface). For example, the master device can read data from or write data to the slave device via the AXI bus. During this interaction, the slave device may be in a busy or abnormal state, causing excessive time to respond to the master's read or write requests, potentially leading to a bus hang. This AXI bus hang can easily cause a system-wide chip freeze.

[0059] Therefore, during chip design, a monitor can be designed to monitor the data interaction between the master and slave devices through its anti-hang-up function. This prevents communication anomalies in participating devices from causing AXI bus hang-ups and leading to systemic chip freezes. Taking the data reading process between the master and slave devices as an example, the monitor can report hang-up status and hang-up time to the master device if the slave device fails to provide data feedback for an extended period. This allows the master device to pause the current data reading interaction process, reducing the risk of systemic chip freezes due to AXI bus hang-ups.

[0060] like Figure 1 As shown, the monitor can connect to the data interaction channel between the master and slave devices via a preset port, such as the handshake channel or data transmission channel between the master and slave devices. In this way, the monitor can obtain information about the interaction between the master and slave devices and determine whether there is an AXI bus hang between them based on the slave device's response to requests initiated by the master device.

[0061] Monitors can characterize the data interaction status between master and slave devices by outputting different interrupt information. Therefore, during chip design, monitors also need to be verified to determine whether their anti-hangover function design is appropriate, thereby improving the stability of the chip during operation. In other words, a comprehensive verification of the monitor's anti-hangover function is required.

[0062] like Figure 2 and Figure 3 As shown, this application provides an Axi bus monitor verification system to comprehensively verify the monitor's anti-hang-up function. The verification system includes a module to be verified, a data interaction module, and a verification judgment module. The data interaction module includes a master device and a slave device connected via a data transmission channel. The data transmission channel between the master device and the slave device includes at least a handshake request channel, a handshake feedback channel, and a data feedback channel.

[0063] In some embodiments, the module to be verified can be a monitor with anti-hook functionality. Both the master and slave devices in the data interaction module can be VIP components based on the UVM (Universal Verification Methodology) environment. By configuring the VIP components, they can have the same functions as the master and slave devices, facilitating the simulation of the monitor's anti-hook operation scenario. The VIP components used to simulate the master and slave devices can be denoted as axi_mst_if and axi_slv_if, respectively.

[0064] The verification and judgment module can include components such as the scoreboard (scrb, scoreboard) and reference model (ref, reference model) integrated into the UVM environment. Furthermore, the verification and judgment module can compare the verification information output by the module to be verified with the pre-set expected information to determine whether the monitor's anti-hook function is operating normally.

[0065] In some embodiments, the data interaction module can be set in the amba_env layer of the UVM environment. That is, the amba_env layer is used to simulate the data interaction between master and slave devices in the chip, providing a data source for verifying the anti-hangover function of the monitor. The verification and judgment module can be set in the env layer of the UVM environment, so that the verification and judgment module can obtain data from the module to be verified and the data generated in the amba_env layer.

[0066] In addition, the UVM environment may also include a test layer for providing test cases and configuration information, and a top layer for providing the components, interfaces, component connection methods, and interface connection methods required for verification.

[0067] In this way, after building an Axi bus monitor verification system based on the UVM environment, the master device and slave device can be stimulated to perform data interaction through pre-prepared test cases, thereby realizing the verification of the module to be verified.

[0068] like Figure 4 As shown, in some embodiments, when the master and slave devices in the verification environment perform data interaction, the module to be verified is configured as follows:

[0069] When the level corresponding to both the handshake request channel and the handshake feedback channel is detected to be high, a counter is started; the high level corresponding to the handshake request channel indicates that the master device has sent a handshake request command to the slave device; the high level corresponding to the handshake feedback channel indicates that the slave device has sent a confirmation handshake command back to the master device.

[0070] If the level of the data feedback channel is detected to be pulled high, the counter is stopped.

[0071] If the data response time of the slave device, as represented by the count value of the counter, is greater than a time threshold, then verification information is generated; and the verification information is sent to the verification judgment module; the verification information includes at least a verification interruption result and a verification timestamp; the verification interruption result is used to represent the data feedback status between the master device and the slave device; the verification timestamp is used to represent the time when the verification interruption result was generated.

[0072] The module to be verified can connect to the handshake request channel, handshake feedback channel, and data feedback channel via preset ports. This allows the module to obtain the interaction status between the master and slave devices during data exchange. Essentially, when the master device sends a data exchange command to the slave device, it can first send a handshake command to determine if the slave device can currently perform the data exchange action. Thus, when the master device sends a handshake request command to the slave device, the module to be verified can detect the change in the voltage level of the handshake request channel from low to high. Similarly, when the slave device sends a confirmation handshake command to the master device via the handshake feedback channel, the voltage level of the corresponding channel will also change from low to high. After sending a confirmation handshake command to the master device, the slave device can then send data back to the master device via the data feedback channel.

[0073] Therefore, in some embodiments, the module to be verified is configured to statistically analyze the response time of the slave device starting to feed data back to the master device when the level corresponding to the handshake feedback channel becomes high, in order to determine whether there is a hangup in the data feedback channel. Specifically, the module to be verified can use a counter to count the response time of the slave device and combine this with a time threshold to determine whether there is a hangup in the data feedback channel.

[0074] In some embodiments, the module under test determines whether the slave device is feeding data back to the master device by detecting whether the level of the data feedback channel changes from low to high. The module under test can stop the counter's counting function when it detects that the data feedback channel has been pulled high. Furthermore, it can also generate interrupt information to indicate that the current data request is running normally.

[0075] In other embodiments, when the time represented by the counter value exceeds a time threshold, the module to be verified generates verification information including a verification interruption result and a verification timestamp. This verification information indicates a hangup in the data feedback channel. The verification interruption result represents the hangup state, while the verification timestamp represents the output time of the verification interruption result. Therefore, the verification judgment can determine whether the anti-hangup function of the module to be verified is operating normally based on both the verification interruption result output by the module and the output time of the verification interruption result.

[0076] It is understandable that after generating the verification information, the module to be verified can send the verification information to the verification judgment module, which will then compare the verification information with the expected information.

[0077] like Figure 5 As shown, the verification and judgment module is configured as follows:

[0078] Obtain the expected information corresponding to the module to be verified; the expected information includes the expected interruption result and the expected timestamp.

[0079] If the expected interruption result is the same as the verification interruption result, and the expected timestamp is the same as the verification timestamp, then a first report information is generated to characterize that the module to be verified has passed the verification.

[0080] If the expected interruption result differs from the verification interruption result, and / or the expected timestamp differs from the verification timestamp, then a second report is generated to characterize that the module to be verified has failed verification.

[0081] In some embodiments, the verification judgment module can obtain expected information corresponding to the verification information, and determine whether the anti-hangover function of the module to be verified is operating normally by comparing the expected information with the verification information. For example, when the expected interruption result is the same as the verification interruption result, and the expected timestamp is the same as the verification timestamp, a first report information can be generated to characterize that the module to be verified has passed the verification.

[0082] For example, if either of these two judgments differs, a second report can be generated to indicate that the module to be verified has failed verification.

[0083] Understandably, when judging the interrupt result, the expected interrupt result and the verification interrupt result can be determined based on the specific interrupt bit and its corresponding value. Furthermore, the judgment logic of the verification module can be adjusted according to actual needs to adapt to the specific verification scenario of the anti-hangover function.

[0084] like Figure 6 As shown, the handshake request channel between the master and slave devices can include a read handshake request channel (arval id), and the handshake feedback channel can include a read handshake feedback channel (arready). The read data feedback channel includes a read data feedback channel (rvalid). Therefore, the module to be verified must at least include a read detection port connected to the read handshake request channel, the read handshake feedback channel, and the read data feedback channel. Furthermore, the module to be verified can also be connected to the read response ready channel (rready) between the master and slave devices via the read detection port. It is understood that the slave device can only send data feedback to the master device when the read response ready channel is high. Therefore, during the read data interaction process between the master and slave devices, the module to be verified is configured as follows:

[0085] If the read handshake request channel and the read handshake feedback channel are both detected to be at a high level through the read detection port, the counter is started.

[0086] If the level of the read data feedback channel is detected to be pulled high, the counter is stopped.

[0087] If the count value of the counter, representing the read data response time of the slave device, is greater than a time threshold, then verification information is generated.

[0088] In some embodiments, after receiving a stimulus, the master device in the verification environment can send a read handshake request to the slave device to initiate a read data interaction process. Upon receiving the read handshake request, the slave device will send a confirmation handshake command back to the master device via the read feedback channel. During the process of the master device sending the read handshake request to the slave device and the slave device sending the confirmation handshake command back to the master device, the voltage levels of both the read handshake request channel and the read handshake feedback channel will be pulled high from a low level. Furthermore, after sending the confirmation handshake command back to the master device, the slave device will send data back to the master device via the read data feedback channel.

[0089] In this way, the module under test can start a counter to count after detecting that the level corresponding to the read feedback channel has been pulled high, and can also detect the level status of the read data feedback channel through the read detection port connected to the read data feedback channel. When the time represented by the counter value is less than or equal to the time threshold, the module under test can detect that the level status of the read data feedback channel has been pulled high, and can then stop the counter counting operation, indicating that the data interaction between the master device and the slave device is normal. Furthermore, after stopping the counter counting operation, the module under test can initialize the counter so that it can be used for subsequent monitoring. Additionally, counters can be set for all channels that need to be monitored, achieving comprehensive anti-hangover function verification.

[0090] When the counter's count value represents a time exceeding a time threshold, it indicates a hangup in the read data feedback channel between the master and slave devices. In this case, the module to be verified will immediately generate verification information and send it to the verification judgment module. The verification judgment module will then use the interrupt result and timestamp to determine whether the anti-hangup function of the module to be verified is functioning correctly.

[0091] In other embodiments, test cases can be adjusted according to verification requirements, enabling the module under test to monitor other channels between the master and slave devices. The verification judgment module then uses the interrupt results and timestamps output by the module under test based on the monitoring process of these other channels to determine whether the module under test can properly perform anti-hangover functions on those other channels. This comprehensively verifies whether the monitor's anti-hangover function can operate normally. These other functions include, but are not limited to, read handshake request channels, read handshake feedback channels, and read response ready channels.

[0092] like Figure 7 As shown, the handshake request channel between the master device and the slave device can also include a write handshake request channel (awval id), and the handshake feedback channel can also include a write handshake feedback channel (awready). The data feedback channel can also include a write data feedback channel (bvalid). Thus, the module to be verified can also include a write detection port connected to the write handshake request channel, the write handshake feedback channel, and the write data feedback channel. Furthermore, the module to be verified can also connect to the write response ready channel (bready) through the write detection port to monitor the write response status of the master device. Therefore, when the master device and the slave device perform the write data interaction process, the module to be verified is configured as follows:

[0093] During the write data interaction process between the master device and the slave device, the module to be verified is configured as follows:

[0094] If the write handshake request channel and the write handshake feedback channel are both detected to be at a high level through the write detection port, the counter is started.

[0095] If the level of the write data feedback channel is detected to be pulled high, the counter is stopped.

[0096] If the write data response time of the master device, as represented by the counter's count value, is greater than a time threshold, then verification information is generated.

[0097] In some embodiments, the master device in the verification environment can send a write handshake request command to the slave device via a write handshake request channel after receiving a stimulus, in order to simulate the write data interaction process in the slave device's chip. After receiving the write handshake request command, the slave device can send a write handshake confirmation command back to the master device via a write handshake feedback channel. Furthermore, during the interaction between the write handshake request command and the write handshake confirmation command, the module under test can detect that the levels of the write handshake request channel and the write handshake feedback channel are pulled high. And, when the levels of both the write handshake request channel and the write handshake feedback channel are pulled high, the module under test can start a counter to track the write response time of the master device.

[0098] In this way, when the master device writes data to the slave device through the write data feedback channel, the module to be verified can detect the corresponding level state of the write data feedback channel through the write detection port connected to the write data feedback channel. Then, by combining the write response time of the slave device represented by the counter value with the time threshold, it can determine whether there is a hangup phenomenon in the write data feedback channel.

[0099] For example, if the module to be verified detects that the write data feedback channel level has been pulled high within a time period less than or equal to a time threshold, the counter can be stopped. In this case, there is no hangup in the write data feedback channel.

[0100] For example, when the write response time of the slave device, represented by the count value, exceeds the time threshold, the module to be verified immediately outputs verification information including the verification interruption result and the verification timestamp, and sends the verification information to the verification judgment module, which then determines whether the anti-hangover function of the module to be verified is operating normally based on the verification information.

[0101] Understandably, the response time can be determined by adjusting the counter's timing frequency and the number of counts. The timing frequency can be determined based on the clock cycle provided in the verification environment.

[0102] like Figure 2As shown, the verification and judgment module can include a reference model and a scoring board. The reference model is an ideal model built based on components and interfaces provided in the UVM environment to simulate the module to be verified. The reference model can monitor the various channels between the master and slave devices and output the expected values ​​corresponding to the verification scenario in a timely manner. That is, the reference model includes at least model detection ports connected to the handshake request channel, handshake feedback channel, and data feedback channel. These model detection ports can be further subdivided into ports connected to the read handshake request channel, read handshake feedback channel, read data feedback channel, write handshake request channel, write handshake feedback channel, and write data feedback channel, so that the reference model can comprehensively monitor the status of each channel between the master and slave devices in the verification environment.

[0103] The scoring board can be used to compare the verification information output by the module to be verified with the expected information output by the reference model, thereby determining whether the anti-hangover function of the module to be verified is functioning normally. In some embodiments, the scoring board is configured as follows:

[0104] Obtain the desired information generated by the reference model based on the data interaction process performed by the master device and the slave device.

[0105] If the expected interruption result is the same as the verification interruption result, and the expected timestamp is the same as the verification timestamp, then a first report information is generated to characterize that the module to be verified has passed the verification.

[0106] If the expected interruption result differs from the verification interruption result, and / or the expected timestamp differs from the verification timestamp, then a second report is generated to characterize that the module to be verified has failed verification.

[0107] In some embodiments, the scoring board can acquire the expected information output by the reference model and the verification information output by the module to be verified. Furthermore, the scoring board can compare the expected interruption result and the verification interruption result, as well as the expected timestamp and the verification timestamp.

[0108] For example, if the expected interruption result and the verification interruption result are the same, and the expected timestamp and the verification timestamp are the same, it means that the anti-hangover function of the module to be verified is operating normally, and the scoreboard can generate the first report information and output it.

[0109] For example, if the expected interruption result and the verified interruption result are different, or if the expected timestamp and the verified timestamp are different, it indicates that the anti-hangover function of the module to be verified is malfunctioning, and the scoreboard can then generate and output a second report.

[0110] It should be noted that the verification timestamp represents the time when the module under test generates the verification interruption result. Therefore, the response speed of the anti-hangover function of the module under test can be verified based on the verification timestamp. Thus, even if the expected interruption result and the verification interruption result are the same, but the expected timestamp and the verification timestamp are different, the anti-hangover function of the module under test is still considered to be malfunctioning. The verification timestamp can be denoted as tmr_cnt.

[0111] Similarly, even if the expected timestamp and the verification timestamp are the same, but the verification interruption result is different from the expected interruption result, the anti-hangover function of the module to be verified is still considered to be abnormal.

[0112] like Figure 2 As shown, the verification environment also includes a verification information relay port. The interrupt output port of the module to be verified can be connected to the verification information relay port, and then the verification information can be sent to the scoring board through the verification information relay port. In this way, the transfer of output data from the module to be verified can be realized with the help of the verification information relay port.

[0113] In some embodiments, the time threshold can be denoted as time_out, and the time threshold can be pre-configured according to verification requirements. That is, the verification system also includes a configuration module for configuring the time threshold.

[0114] The configuration module is configured as follows:

[0115] In response to a configuration information write command, configuration information is generated; the configuration information includes at least the time threshold or the counter's count threshold.

[0116] The module to be verified is further configured to: Before the master device and the slave device perform the data interaction process, the module to be verified is configured to:

[0117] The configuration information is obtained from the configuration module.

[0118] In some embodiments, the configuration module can be integrated into the test layer, where a time threshold or a counter's counting threshold can be configured. Specifically, the time threshold can be replaced with a counting threshold, and the scoring board uses this threshold to determine whether the expected timestamp and the verification timestamp are the same. Comparison using the counting threshold is essentially a comparison of time.

[0119] Understandably, the counting threshold or time threshold can be adjusted in advance based on the actual verification scenario. For example, in a verification environment that simulates many data interaction transactions, the time threshold can be set larger to adapt to the actual interaction state between the master and slave devices. Conversely, in a verification environment that simulates few data interaction transactions, the time threshold can be set smaller.

[0120] In this way, both the module to be verified and the reference model can obtain the time threshold or count threshold from the configuration module before running, so as to monitor the status of each channel between the master device and the slave device in the verification environment according to the time threshold or count threshold.

[0121] In some embodiments, the verification interrupt result may include the initial read interrupt (rd_int_raw) and the masked read interrupt (rd_int_sts) corresponding to the read data feedback channel, and the initial write interrupt (wr_int_raw) and the masked write interrupt (wr_int_sts) corresponding to the write data feedback channel, as well as the overall interrupt status (wr_int_sts|rd_int_sts). This allows for a comprehensive comparison of these interrupts to determine the operational status of the anti-hangover function of the module under test. Specifically, when the data response time of the slave device, represented by the counter value, exceeds a time threshold, the module under test is further configured to generate verification information as follows:

[0122] Perform a bitwise OR operation on the read interrupt result and the write interrupt result to obtain the overall interrupt result;

[0123] The verification information is generated based on the read interrupt result, the write interrupt result, and the overall interrupt result.

[0124] The verification information is sent to the verification judgment module.

[0125] It is understandable that the overall interrupt status = wr_int_sts|rd_int_sts, meaning the overall interrupt result is the result of a bitwise OR operation between the masked read interrupt and the masked write interrupt. The overall interrupt result reflects the overall operating status of the monitor's anti-hangover function. The module to be verified can send each verification interrupt result to the scoring board through the interrupt output port, or send the integrated verification information to the scoring board.

[0126] In this way, the scoring board can comprehensively compare the anti-hangover function operation status of the module under test when a hangover occurs in the channel between the master device and the slave device.

[0127] In some embodiments, an Axi bus monitor verification method is provided, which can be applied to an Axi bus monitor verification system in a system-type embodiment. The verification method includes:

[0128] When the levels corresponding to both the handshake request channel and the handshake feedback channel are detected to be high, a counter is started; the high level corresponding to the handshake request channel indicates that the master device has sent a handshake request command to the slave device; the high level corresponding to the handshake feedback channel indicates that the slave device has sent a confirmation handshake command back to the master device.

[0129] If the level of the data feedback channel is detected to be pulled high, the counter is stopped;

[0130] If the data response time of the slave device, as represented by the count value of the counter, is greater than a time threshold, then verification information is generated; and the verification information is sent to the verification judgment module; the verification information includes at least a verification interruption result and a verification timestamp; the verification interruption result is used to represent the data feedback status between the master device and the slave device; the verification timestamp is used to represent the time when the verification interruption result was generated;

[0131] Obtain the expected information corresponding to the verification information; the expected information includes the expected interruption result and the expected timestamp.

[0132] If the expected interruption result is the same as the verification interruption result, and the expected timestamp is the same as the verification timestamp, then a first report information is generated to characterize the verification as passed.

[0133] If the expected interruption result differs from the verification interruption result, and / or the expected timestamp differs from the verification timestamp, a second report is generated to characterize the verification failure.

[0134] In some embodiments, an electronic device is provided, comprising a processor and a memory communicatively connected to the processor. The memory stores instructions executable by the processor to cause the processor to perform steps of the verification method in the method-like embodiments.

[0135] In some embodiments, a computer-readable storage medium is provided, the computer-readable storage medium including at least one computer instruction, the at least one computer instruction being used to cause a computer to perform the steps of the verification method in the method class embodiment.

[0136] This application provides an Axi bus monitor verification system, method, electronic device, and storage medium. The verification system includes a module to be verified, a data interaction module, and a verification judgment module. The module to be verified can detect the level of the data transmission channel between the master and slave devices in the data interaction module, and then, when the handshake feedback channel between the slave and master devices is high, it counts the response time of the slave device feeding back the target data to the master device. The verification judgment module can obtain expected information corresponding to the verification information output by the module to be verified, and compare the verification information and the expected information when the module to be verified outputs verification information to determine whether the anti-hang-up function of the module to be verified is operating normally. This enables the verification of the anti-hang-up function of the module to be verified, which is beneficial for maintaining the normal operation of the chip equipped with the module to be verified.

[0137] Similar parts between the embodiments provided in this application can be referred to mutually. The specific implementation methods provided above are only a few examples under the overall concept of this application and do not constitute a limitation on the scope of protection of this application. For those skilled in the art, any other implementation methods extended from the solution of this application without creative effort shall fall within the scope of protection of this application.

Claims

1. An AXI bus monitor verification system, characterized in that, include: Module to be verified, data interaction module, verification judgment module; The data interaction module includes a master device and a slave device connected via a data transmission channel; The data transmission channel between the master device and the slave device includes at least a handshake request channel, a handshake feedback channel, and a data feedback channel; The module to be verified is configured to start a counter when it is detected that the levels corresponding to the handshake request channel and the handshake feedback channel are both high; the high level corresponding to the handshake request channel is used to indicate that the master device has sent a handshake request command to the slave device. The high level corresponding to the handshake feedback channel is used to indicate that the slave device has sent a confirmation handshake command to the master device. If the level of the data feedback channel is detected to be pulled high, the counter is stopped; If the data response time of the slave device, as represented by the counter's count value, is greater than a time threshold, then verification information is generated; and the verification information is sent to the verification judgment module; the verification information includes at least a verification interruption result and a verification timestamp. The verification interruption result is used to characterize the data feedback status between the master device and the slave device; the verification timestamp is used to characterize the time when the verification interruption result was generated; The verification and judgment module is configured as follows: Obtain the expected information corresponding to the module to be verified; the expected information includes the expected interruption result and the expected timestamp. If the expected interruption result is the same as the verification interruption result, and the expected timestamp is the same as the verification timestamp, then a first report information is generated to characterize that the module to be verified has passed the verification. If the expected interruption result differs from the verification interruption result, and / or the expected timestamp differs from the verification timestamp, then a second report is generated to characterize that the module to be verified has failed verification.

2. The AXI bus monitor verification system according to claim 1, characterized in that, The handshake request channel includes a read handshake request channel; the handshake feedback channel includes a read handshake feedback channel. The data feedback channel includes a read data feedback channel; The module to be verified includes at least a read detection port connected to the read handshake request channel, the read handshake feedback channel, and the read data feedback channel; During the data read interaction process between the master device and the slave device, the module to be verified is configured as follows: If the read handshake request channel and the read handshake feedback channel are both detected to be at a high level through the read detection port, start the counter; If the level of the read data feedback channel is detected to be pulled high, the counter is stopped; If the count value of the counter, representing the read data response time of the slave device, is greater than a time threshold, then verification information is generated.

3. The AXI bus monitor verification system according to claim 1, characterized in that, The handshake request channel includes a write handshake request channel; the handshake feedback channel includes a write handshake feedback channel; and the data feedback channel includes a write data feedback channel. The module to be verified includes at least a write detection port connected to the write handshake request channel, the write data feedback channel, and the write data feedback channel; During the write data interaction process between the master device and the slave device, the module to be verified is configured as follows: If the write handshake request channel and the write handshake feedback channel are both detected to be at a high level through the write detection port, start the counter; If the level of the write data feedback channel is detected to be pulled high, the counter is stopped; If the write data response time of the slave device, as represented by the counter's count value, is greater than a time threshold, then verification information is generated.

4. The AXI bus monitor verification system according to claim 1, characterized in that, The verification and judgment module includes a reference model and a scoring board; the reference model includes at least a model detection port connected to the handshake request channel, the handshake feedback channel, and the data feedback channel; The scoreboard is configured to: acquire the expected information generated by the reference model based on the data interaction process performed by the master device and the slave device; If the expected interruption result is the same as the verification interruption result, and the expected timestamp is the same as the verification timestamp, then a first report information is generated to characterize that the module to be verified has passed the verification. If the expected interruption result differs from the verification interruption result, and / or the expected timestamp differs from the verification timestamp, then a second report is generated to characterize that the module to be verified has failed verification.

5. The AXI bus monitor verification system according to claim 4, characterized in that, It also includes a verification information relay port; The module to be verified executes the sending of the verification information to the verification judgment module, specifically configured to send the verification information to the scoring board through the verification information relay port.

6. The AXI bus monitor verification system according to claim 1, characterized in that, Also includes: Configuration module; The configuration module is configured to: generate configuration information in response to a configuration information write command; the configuration information includes at least the time threshold or the counter's count threshold; The module to be verified is further configured to: Before the master device and the slave device perform the data interaction process, the module to be verified is configured to: The configuration information is obtained from the configuration module.

7. The AXI bus monitor verification system according to claim 1, characterized in that, The verification interruption results include at least the read interruption results, the write interruption results, and the overall interruption results; When the data response time of the slave device, as represented by the counter value, is greater than a time threshold, and the module to be verified is generated, it is further configured to: Perform a bitwise OR operation on the read interrupt result and the write interrupt result to obtain the overall interrupt result; The verification information is generated based on the read interrupt result, the write interrupt result, and the overall interrupt result. The verification information is sent to the verification judgment module.

8. An Axi bus monitor verification method, characterized in that, The verification method is applied to the Axi bus monitor verification system according to any one of claims 1-7; the verification method includes: When the levels corresponding to both the handshake request channel and the handshake feedback channel are detected to be high, a counter is started; the high level corresponding to the handshake request channel indicates that the master device has sent a handshake request command to the slave device; the high level corresponding to the handshake feedback channel indicates that the slave device has sent a confirmation handshake command back to the master device. If the level of the data feedback channel is detected to be pulled high, the counter is stopped; If the data response time of the slave device, as represented by the count value of the counter, is greater than a time threshold, then verification information is generated; and the verification information is sent to the verification judgment module; the verification information includes at least a verification interruption result and a verification timestamp; the verification interruption result is used to represent the data feedback status between the master device and the slave device; the verification timestamp is used to represent the time when the verification interruption result was generated; Obtain the expected information corresponding to the verification information; the expected information includes the expected interruption result and the expected timestamp. If the expected interruption result is the same as the verification interruption result, and the expected timestamp is the same as the verification timestamp, then a first report information is generated to characterize the verification as passed. If the expected interruption result differs from the verification interruption result, and / or the expected timestamp differs from the verification timestamp, a second report is generated to characterize the verification failure.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores instructions that can be executed by the processor to cause the processor to perform the steps of the method described in claim 8.

10. A computer-readable storage medium, characterized in that, include: The computer-readable storage medium includes at least one computer instruction for causing a computer to perform the steps of the method as described in claim 8.

Images