Deadlock test method, deadlock test device, deadlock test system and related equipment

Abstract

The embodiment of the invention provides a deadlock test method, device and system and related equipment, and the method comprises the steps: selecting two pieces of master equipment as first master equipment and second master equipment, and selecting two pieces of slave equipment as first slave equipment and second slave equipment; a first type of test transaction is sent from the first master device to the first slave device, the first type of test transaction is sent from the second master device to the second slave device, and to-be-tested write data in the first type of test transaction is greater than or equal to a first preset length; within a preset time interval, starting transmission of the second type of test transactions from the first master device to the second slave device, and starting transmission of the second type of test transactions from the second master device to the first slave device; and determining whether deadlock is generated or not based on the data received by the first slave device and the second slave device. According to the embodiment of the invention, whether the bus architecture has the defect of causing deadlock or not can be determined in a chip design stage.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of chip testing technology, and in particular to a deadlock testing method, device, system and related equipment. Background Art

[0002] In a computing device, a master device and a slave device perform data transmission based on a bus architecture, wherein the master device and the slave device usually need to transmit and receive data in sequence.

[0003] However, as the chip integration scale becomes larger and larger, the master device and slave device in the computing device are also larger and larger, and the corresponding bus architecture is also more and more complex. Among them, when there are design defects in the bus architecture, deadlock may occur.

[0004] Therefore, how to test whether the bus architecture has defects that cause deadlock during the chip design stage is a technical problem that technical personnel in this field urgently need to solve. Summary of the invention

[0005] In view of this, embodiments of the present invention provide a deadlock testing method, apparatus, system and related equipment to test whether a bus architecture has defects that cause deadlock during the chip design stage.

[0006] To achieve the above objectives, the embodiments of the present invention provide the following technical solutions.

[0007] In a first aspect, an embodiment of the present invention provides a deadlock test method for testing a design to be tested, wherein the design to be tested includes a bus architecture, and a plurality of master devices and slave devices connected in the bus architecture; the method includes:

[0008] Select two master devices connected to the bus architecture as the first master device and the second master device, and select two slave devices connected to the bus architecture as the first slave device and the second slave device;

[0009] Sending a first type of test transaction from a first master device to a first slave device, and sending a first type of test transaction from a second master device to a second slave device, wherein the first type of test transaction includes a write command to be tested and write data to be tested, and the write data to be tested in the first type of test transaction is greater than or equal to a first preset length;

[0010] Initiate transmission of a second type of test transaction from the first master device to the second slave device, and initiate transmission of a second type of test transaction from the second master device to the first slave device within a preset time interval of sending the first type of test transaction, wherein the second type of test transaction includes a write command to be tested and write data to be tested, and the write data to be tested in the second type of test transaction is less than or equal to a second preset length; the second preset length is less than the first preset length, and the preset time interval is less than a transmission time of the write data to be tested of the first type of test transaction;

[0011] Based on the data received from the first slave device and the second slave device, it is determined whether a deadlock occurs.

[0012] Optionally, the method further includes:

[0013] Sending a first type of test transaction from the first master device to the second slave device, and sending the first type of test transaction from the second master device to the first slave device;

[0014] Initiate transmission of a second type of test transaction from the first master device to the first slave device, and initiate transmission of a second type of test transaction from the second master device to the second slave device, within a preset time interval of sending the first type of test transaction;

[0015] Again based on the data received from the first slave device and the second slave device, it is determined whether a deadlock occurs.

[0016] Optionally, the selecting two master devices connected to the bus architecture as the first master device and the second master device, and selecting two slave devices connected to the bus architecture as the first slave device and the second slave device, respectively, includes:

[0017] Randomly name the two master devices as a first master device and a second master device respectively;

[0018] The remote slave device of the first master device is named as the first slave device, and the other slave device is named as the second slave device; or the remote slave device of the second master device is named as the first slave device, and the other slave device is named as the second slave device.

[0019] Optionally, the first type test transaction is a pre-constructed first type test stimulus, and the sending of the first type test transaction from the first master device to the first slave device, and the sending of the first type test transaction from the second master device to the second slave device, are specifically:

[0020] The verification component based on the verification platform controls the first master device to send a first type of test stimulus to the first slave device, and controls the second master device to send the first type of test stimulus to the second slave device.

[0021] Optionally, the initiating transmission of the second type of test transaction from the first master device to the second slave device is specifically, transmitting the write command to be tested of the second type of test transaction from the first master device to the second slave device; the initiating transmission of the second type of test transaction from the second master device to the first slave device is specifically, transmitting the write command to be tested of the second type of test transaction from the second master device to the first slave device.

[0022] Optionally, the second type test transaction is a pre-constructed second type test stimulus, and the initiating transmission of the second type test transaction from the first master device to the second slave device, and initiating transmission of the second type test transaction from the second master device to the first slave device, is specifically:

[0023] The verification component based on the verification platform controls the first master device to send the write command to be tested in the second type of test stimulus to the second slave device, and controls the second master device to send the write command to be tested in the second type of test stimulus to the first slave device.

[0024] Optionally, the determining whether a deadlock occurs based on the data received by the first slave device and the second slave device is specifically:

[0025] Determine whether the first slave device and the second slave device successfully receive the test write data. If so, no deadlock occurs. If not, a deadlock occurs.

[0026] Optionally, the first preset length is 256 burst lengths, and the second preset length is 5 burst lengths; the preset time interval is less than or equal to 1 clock cycle.

[0027] Optionally, after the step of selecting two master devices connected to the bus architecture as the first master device and the second master device, and selecting two slave devices connected to the bus architecture as the first slave device and the second slave device, the step of sending a first type of test transaction from the first master device to the first slave device, and sending a first type of test transaction from the second master device to the second slave device is repeated, until the step of again receiving data based on the first slave device and the second slave device is met, until a preset condition is met;

[0028] The preset conditions are:

[0029] Confirming that a deadlock occurs in the step of determining whether a deadlock occurs based on the data received from the first slave device and the second slave device or in the step of determining whether a deadlock occurs again based on the data received from the first slave device and the second slave device;

[0030] or,

[0031] No deadlock occurs, and the first type of test transaction is sent from the first master device to the first slave device, and the first type of test transaction is sent from the second master device to the second slave device, until the step of again receiving data based on the first slave device and the second slave device is repeated a preset number of times.

[0032] Optionally, before the step of selecting two master devices connected to the bus architecture as the first master device and the second master device, and selecting two slave devices connected to the bus architecture as the first slave device and the second slave device, the step further includes:

[0033] Constructing a test sequence table, wherein the test sequence table is used to indicate the test sequence of the test schemes composed of different master devices and slave devices, wherein at least one of the master devices or the slave devices is different in different test schemes;

[0034] The step of selecting two master devices connected to the bus architecture as the first master device and the second master device, and selecting two slave devices connected to the bus architecture as the first slave device and the second slave device, specifically, selecting the master device and the slave device in the corresponding test plan based on the order in the test sequence table.

[0035] In a second aspect, an embodiment of the present invention provides a deadlock test device for testing a design to be tested, wherein the design to be tested includes a bus architecture, and a plurality of master devices and slave devices connected to the bus architecture; the device includes:

[0036] A device selection module, used to select two master devices connected to the bus architecture as the first master device and the second master device, and select two slave devices connected to the bus architecture as the first slave device and the second slave device;

[0037] A test module, configured to send a first type of test transaction from a first master device to a first slave device, and to send a first type of test transaction from a second master device to a second slave device, wherein the first type of test transaction includes a write command to be tested and write data to be tested, and the write data to be tested in the first type of test transaction is greater than or equal to a first preset length; and, within a preset time interval for sending the first type of test transaction, initiate transmission of a second type of test transaction from the first master device to the second slave device, and initiate transmission of a second type of test transaction from the second master device to the first slave device, wherein the second type of test transaction includes a write command to be tested and write data to be tested, and the write data to be tested in the second type of test transaction is less than or equal to a second preset length; the second preset length is less than the first preset length, and the preset time interval is less than the transmission time of the write data to be tested of the first type of test transaction;

[0038] The deadlock confirmation module is used to determine whether a deadlock occurs based on the data received by the first slave device and the second slave device.

[0039] Optionally, the deadlock testing device further includes:

[0040] A sequence table construction module, used to construct a test sequence table, wherein the test sequence table is used to indicate the test sequence of the test schemes composed of different master devices and slave devices, wherein at least one of the master devices or the slave devices is different in different test schemes;

[0041] The device selection module is used to select two master devices connected to the bus architecture as the first master device and the second master device, and select two slave devices connected to the bus architecture as the first slave device and the second slave device. Specifically, based on the order in the test sequence table, the master device and the slave device in the corresponding test plan are selected.

[0042] In a third aspect, an embodiment of the present invention provides a chip verification system, wherein the chip verification system is configured to execute the deadlock test method as described in the first aspect above.

[0043] In a fourth aspect, an embodiment of the present invention provides a computer device comprising at least one memory and at least one processor; the memory stores one or more computer executable instructions, and the processor calls the one or more computer executable instructions to execute the deadlock testing method as described in the first aspect above.

[0044] In a fifth aspect, an embodiment of the present invention provides a storage medium, wherein the storage medium stores one or more computer executable instructions, and the one or more computer executable instructions are used to execute the deadlock testing method as described in the first aspect above.

[0045] In a sixth aspect, an embodiment of the present invention provides a computer program product, comprising one or more computer executable instructions, wherein the one or more computer executable instructions, when executed, implement the deadlock testing method as described in the first aspect above.

[0046] The embodiment of the present invention provides a deadlock test method, device, system and related equipment, wherein the method is used to test a design to be tested, wherein the design to be tested includes a bus architecture, and a plurality of master devices and slave devices connected to the bus architecture; wherein the method includes: selecting two master devices connected to the bus architecture as a first master device and a second master device, and selecting two slave devices connected to the bus architecture as a first slave device and a second slave device; sending a first type of test transaction from the first master device to the first slave device, and sending a first type of test transaction from the second master device to the second slave device, wherein the first type of test transaction includes a write command to be tested and write data to be tested, and the write data to be tested in the first type of test transaction The test write data is greater than or equal to a first preset length; within a preset time interval of sending the first type of test transaction, the transmission of the second type of test transaction from the first master device to the second slave device is initiated, and the transmission of the second type of test transaction from the second master device to the first slave device is initiated, wherein the second type of test transaction includes a write command to be tested and write data to be tested, and the write data to be tested in the second type of test transaction is less than or equal to a second preset length; the second preset length is less than the first preset length, and the preset time interval is less than the transmission time of the write data to be tested of the first type of test transaction; based on the data received from the first slave device and the second slave device, it is determined whether a deadlock occurs.

[0047] It can be seen that the deadlock test method in the embodiment of the present invention utilizes data communication between two master devices and two slave devices in a bus architecture to simulate a scenario where a deadlock may occur. At the same time, by first sending a first type of test transaction with a larger write data to be tested based on a path from the first master device to the first slave device and a path from the second master device to the second slave device, respectively, a larger data delay is provided for the prior data transmission to induce a deadlock. Thereafter, within a preset time interval for sending the first type of test transaction, a second type of test transaction with a smaller write data to be tested is sent from the path from the first master device to the second slave device and the path from the second master device to the first slave device, respectively, wherein the preset time interval is less than the transmission time of the write data to be tested of the first type of test transaction, thereby sending the second type of test transaction with a smaller write data to be tested within a smaller time interval, simulating a scenario that may occur when a later command arrives at the slave device before a previous command, thereby determining whether the design to be tested will cause a deadlock, and then determining whether the bus architecture has a defect that causes deadlock in the chip design stage, providing support for eliminating deadlock defects in the chip design stage. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0049] Figure 1 A schematic diagram of a deadlock scenario;

[0050] Figure 2 An optional structural diagram of the design to be tested provided by an embodiment of the present invention;

[0051] Figure 3 An optional flow chart of a deadlock testing method provided by an embodiment of the present invention;

[0052] Figure 4 An optional flowchart of step S110 provided in an embodiment of the present invention;

[0053] Figure 5 An optional flow chart of step S120 provided in an embodiment of the present invention;

[0054] Figure 6 to Figure 7 An optional flowchart of step S130 provided in an embodiment of the present invention;

[0055] Figure 8 Another optional flow chart of the deadlock testing method provided by an embodiment of the present invention;

[0056] Fig. 9 An optional block diagram of a deadlock testing device provided by an embodiment of the present invention;

[0057] Fig.10 Another optional block diagram of the deadlock testing device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0058] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0059] As described in the background technology, in the process of data transmission based on a bus architecture, when there are design defects in the bus architecture, a deadlock may occur, that is, two groups of master devices and slave devices (one master device and one slave device form a group) that cross-transmit data will experience data blockage in a short period of time, thereby interrupting the data transmission process of the two groups of master devices and slave devices.

[0060] It is understandable that deadlock is an extremely serious problem in the process of data transmission based on the bus architecture. It will make the bus bridge between the two sets of master devices and slave devices that are deadlocked in the bus architecture unable to continue to send and receive any data, seriously affecting the overall data access throughput of the system, and even causing the entire chip to malfunction.

[0061] However, deadlock is an occasional situation in a specific scenario. In the bus architecture, the defects that cause deadlock are very hidden and do not affect normal data access. Accordingly, when performing data transmission tests, if collision tests are performed through random use cases, it will be very difficult to knock out the deadlock scenario due to the randomness of the use cases and the limitations of the use case constraints.

[0062] After studying the deadlock scenario, the inventor believes that the main factors that cause deadlock include the order of data transmission and the different delays that may be caused by data transmission on different paths. That is, in the data transmission process of two groups of master devices and slave devices that cross-transmit data, on the slave device side, the previous command that should have been received first is transmitted to the slave device later than the subsequent command that should have been received later, while the previous data that should have been received first is transmitted to the slave device in sequence before the subsequent data that should have been received later. Based on the order of commands, the slave device can only receive the subsequent data of the subsequent command first, which causes the slave device interface to be blocked by the previous data; at the same time, on the master device side, the subsequent data transmission will be blocked due to the delay in receiving the response message of the completion of the previous data transmission.

[0063] Specifically, the inventor believes that the specific scenario in which the deadlock occurs is as follows:

[0064] refer to Figure 1 A schematic diagram of a deadlock scenario is shown, including a bus architecture, and master devices a and b, as well as slave devices c and d connected to the bus architecture, wherein master device a performs data transmission based on bus bridge a in the bus architecture, and master device b performs data transmission based on bus bridge b in the bus architecture.

[0065] The bus architecture can, for example, be based on the AXI (Advanced eXtensible Interface) bus protocol for data transmission. The AXI bus protocol is a widely used interface protocol in large-scale integrated circuit design and is used as a data exchange interface protocol between various modules of the chip. In other examples, the bus architecture can also be based on other protocols for data transmission, which is not specifically limited in this application.

[0066] Among them, the bus architecture can adopt a transmission mechanism that separates data from addresses, and perform data interaction through multiple independent channels. The multiple channels may include, for example, a write address channel (AW), a write data channel (W), a write response channel (B), a read address channel (AR), and a read data channel (R). During the data transmission process, the master device needs to transmit data based on a preset order so that the slave device determines the corresponding relationship between the data received by each channel based on the receiving order.

[0067] For example, when transmitting multiple transactions for data writing, the write commands and write data belonging to the corresponding transactions will be sent from the master device to the slave device in sequence based on the write address channel and the write data channel. Correspondingly, the slave device will determine the write commands and write data belonging to the same transaction in sequence based on the order of the write commands and write data transmitted in the write address channel and the write data channel.

[0068] It should be noted that the master device only sends data in sequence to the same slave device. When it is sent to different slave devices, it can start the command transmission of a new transaction based on the "Outstanding" mechanism before receiving the final response of the previous transaction.

[0069] In a possible scenario, the master device a can successively send write command 1a and write data 1b belonging to transaction 1 to the slave device d, and send write command 2a and write data 2b belonging to transaction 2 to the slave device c. Accordingly, the write command channel of the bus bridge a first transmits the write command 1a, and the write data channel first transmits the write data 1b. At the same time, the master device b successively sends write command 3a and write data 3b belonging to transaction 3 to the slave device c, and sends write command 4a and write data 4b belonging to transaction 4 to the slave device d. Accordingly, the write command channel of the bus bridge b first transmits the write command 3a, and the write data channel first transmits the write data 3b.

[0070] Since the master device a issues different transactions to different slave devices, it can issue the write command 2a of transaction 2 when transaction 1 has not sent back a response message indicating the completion of the transaction. Similarly, the master device b can issue the write command 4a of transaction 4 when transaction 3 has not sent back a response message indicating the completion of the transaction.

[0071] However, under the influence of the delay of the data transmission path of the remote device, if the write command channel of the slave device c first receives the write command 2a of transaction 2, and the write data channel of the bus bridge a is occupied by the write data 1b of transaction 1, it cannot transmit the write data 2b of transaction 2; correspondingly, the write command channel of the slave device d first receives the write command 4a of transaction 4, and the write data channel of the bus bridge b is occupied by the write data 3b of transaction 3, so it cannot transmit the write data 4b of transaction 4. At this time, the slave device lacks the write data corresponding to the write command, is blocked and waiting, and cannot execute.

[0072] At the same time, in this scenario, the master device a cannot receive the transaction completion response message of transaction 1, and thus cannot send write data 2b in sequence, which further makes it impossible for the slave device c to receive write data 2b; correspondingly, the master device b cannot receive the transaction completion response message of transaction 3, and thus cannot send write data 4b in sequence, which further makes it impossible for the slave device b to receive write data 4b.

[0073] In the above scenario, a deadlock occurs. In view of this, the inventor believes that the design under test can be tested in combination with the scenario in which the deadlock occurs and the cause of the deadlock, so as to test whether the bus architecture has defects that cause deadlock during the chip design stage, thereby providing support for eliminating deadlock defects during the chip design stage.

[0074] Below, reference Figure 2 and Figure 3 For a detailed description of the deadlock test solution provided in this application, refer to Figure 2 An optional structural diagram of a design to be tested is shown, wherein the design to be tested includes a bus architecture, and a plurality of master devices and slave devices connected in the bus architecture.

[0075] Among them, the bus architecture is a specific bus arrangement arranged in a computing device, and the bus architecture may include multiple bus bridge (Internconnect) connections, and different bus bridge connections may also include multi-layer bus bridge cascades. The master device and the slave device may be IP (Intellectual Property) modules in the design to be tested. In an optional example, the bus structure may be transmitted based on the AXI (Advanced eXtensible Interface) bus protocol.

[0076] exist Figure 2In the figure, an example is shown in which a master device corresponds to a bus bridge for input / output, wherein the master device can issue a test transaction to the slave device through the bus bridge in the bus structure. It can be understood that due to reasons such as link construction, bus cascading and delays of different links, the time when the master device's commands are sent to different slave devices and the time when the master device's data are sent to different slave devices may be different, thereby causing the bus architecture to have the possibility of deadlock.

[0077] Specifically, Figure 3 An optional flow chart of a deadlock test method provided by an embodiment of the present invention is shown as an example. Figure 3 As shown, the deadlock test method may include:

[0078] Step S100: Select two master devices connected to the bus architecture as a first master device and a second master device, and select two slave devices connected to the bus architecture as a first slave device and a second slave device.

[0079] The master device and the slave device to be tested are determined by selecting the first master device, the second master device, the first slave device and the second slave device, so that the corresponding test method is executed based on the master device to be tested.

[0080] Among them, the master device and the slave device are named to distinguish different devices, so as to distinguish the paths between the devices during the test process, so as to determine the sending order of the transactions corresponding to the different devices during the test process.

[0081] It is understandable that in a bus architecture, there are usually multiple master devices and multiple slave devices, and in the selection step, the master device and the slave device can be selected in sequence based on a preset order, or the master device and the slave device can be randomly selected based on a preset mechanism. It should be noted that in the selection process, different selection schemes can repeat some devices, that is, in one selection scheme, for example, master device a and master device b, slave device c and slave device d are selected, and in another selection scheme, master device a and master device b, slave device c and slave device e can be selected.

[0082] Regarding the naming of each master device and slave device, in an optional example, each master device and slave device can be randomly named, or can be named based on the relationship between the transmission path lengths of the master device and the slave device. Specifically, the two master devices can be randomly named as the first master device and the second master device, and then the remote slave device of the first master device can be named as the first slave device, and the other slave device can be named as the second slave device; or the remote slave device of the second master device can be named as the first slave device, and the other slave device can be named as the second slave device. Among them, the remote slave device is the slave device with the longer transmission path among the two slave devices.

[0083] It can be understood that under the above naming rule, the slave device that first receives the first type of test transaction may be a remote device, which may result in a larger transmission delay and may be more likely to induce a deadlock.

[0084] Continue to refer Figure 3 , executing step S110, sending a first type test transaction from the first master device to the first slave device, and sending a first type test transaction from the second master device to the second slave device.

[0085] The test transaction is sent from the master device to the slave device to implement the corresponding test.

[0086] Among them, the first type of test transaction is a test transaction used to generate a data transmission delay to induce a deadlock. Accordingly, the first type of test transaction includes a write command to be tested and write data to be tested. Combined with the above analysis, it can be seen that if a deadlock occurs, the write data to be tested at this time should have the effect of blocking the write data channel. Therefore, in an embodiment of the present invention, in the first type of test transaction, the write data to be tested is greater than or equal to the first preset length, that is, the write data to be tested has a larger length. In a specific example, the first preset length is 256 burst lengths, and accordingly, the length of the write data to be tested in the first type of test transaction can be a data packet greater than or equal to 256 burst lengths (Burst Length).

[0087] It should be noted that the first type of test transaction is only used to refer to a test transaction of a specific type. Accordingly, in this step, both the first master device and the second master device send a first type of test transaction of the specific type, but it does not mean that the test transaction sent by the first master device and the second master device is the same test transaction. In an optional example, the first type of test transaction sent by the first master device and the second master device can be the same test transaction or different test transactions, and the present invention does not make specific limitations here.

[0088] In a specific example, refer to Figure 4 In the optional flow diagram of step S110 shown in FIG. 1 , the first bus bridge Int_1 transmits information of the first master device MASTER_1, and the second bus bridge Int_2 transmits information of the second master device MASTER_2 as an example. In this step, the first bus bridge Int_1 corresponding to the first master device MASTER_1 may issue the first type of test transaction Tr1 (wherein, Figure 4AW1 indicates the test write command of the first type test transaction Tr1 issued by the first master device, W1 indicates the test write data of the first type test transaction Tr1 issued by the first master device, and AW1 and W1 are transmitted based on different transmission channels), and the first type test transaction Tr2 is issued through the second bus bridge Int_2 corresponding to the second master device MASTER_2 (wherein, Figure 4 AW2 indicates the test write command of the first type test transaction Tr2 issued by the second master device, W2 indicates the test write data of the first type test transaction Tr2 issued by the second master device, and AW2 and W2 are transmitted based on different transmission channels), and the first master device and the second master device can issue the first type test transaction at the same time (TIME0 is used in the figure to indicate the time when the first type test transaction is issued).

[0089] In an optional implementation, the deadlock test scheme may be implemented based on a verification platform, and the corresponding test transaction may be a test stimulus constructed in advance. Accordingly, the first type of test transaction may be a pre-constructed first type of test stimulus.

[0090] Furthermore, this step can control the corresponding master device to issue a test transaction based on the verification component of the verification platform (e.g., the AXI_UVC component of the UVC platform, which usually includes interface AXI protocol driver, monitoring signal and other functions). That is, the verification component of the verification platform can be used to control the first master device to send a first type of test stimulus to the first slave device, and control the second master device to send a first type of test stimulus to the second slave device.

[0091] Continue to refer Figure 3 , execute step S120, within a preset time interval of sending the first type of test transaction, start the transmission of the second type of test transaction from the first master device to the second slave device, and start the transmission of the second type of test transaction from the second master device to the first slave device.

[0092] The response time of the first type of test transaction refers to the time period from when the device sends back a response message to the master device after the first type of test transaction is completed. The preset time interval is less than the transmission time of the test write data to be tested of the first type of test transaction, and is used to issue a subsequent command in a time interval as short as possible, thereby simulating a scenario in which the subsequent command arrives at the slave device before the prior command. In a further example, the preset time interval may be less than or equal to 1 clock cycle.

[0093] The second type of test transaction is a test transaction used to induce the current subsequent command to arrive at the slave device before the previous command, so as to induce the generation of deadlock. Accordingly, the second type of test transaction includes a write command to be tested and write data to be tested. Among them, the write data to be tested is used to ensure the integrity of the test transaction, so it is not necessary to include too much data. Accordingly, the write data to be tested in the second type of test transaction can be less than or equal to the second preset length, and the second preset length is less than the first preset length. In a specific example, the second preset length is 5 burst lengths, and the length of the write data to be tested in the second type of test transaction can be a data packet less than or equal to 5 burst lengths (Burst Length). In a preferred example, the write data to be tested in the second type of test transaction can be 1 burst length.

[0094] It should be noted that the second type of test transaction is only used to refer to a test transaction of a specific type. Accordingly, in this step, both the first master device and the second master device send a second type of test transaction of the specific type, but it does not mean that the test transaction sent by the first master device and the second master device is the same test transaction. In an optional example, the second type of test transaction sent by the first master device and the second master device can be the same test transaction or different test transactions, and the present invention does not make specific limitations on this.

[0095] Among them, initiating the transmission of the second type of test transaction from the first master device to the second slave device may specifically be transmitting a write command to be tested from the first master device to the second slave device; correspondingly, initiating the transmission of the second type of test transaction from the second master device to the first slave device may specifically be transmitting a write command to be tested from the second master device to the first slave device.

[0096] In a specific example, refer to Figure 5 The optional flow chart of step S120 shown in FIG. 1 is a flow chart of an optional flow chart of step S120. In this step, the first bus bridge Int_1 corresponding to the first master device MASTER_1 may start the second type test transaction Tr3 (wherein, Figure 5 AW3 indicates the test write command of the second type test transaction Tr3 issued by the first master device, W3 indicates the test write data of the second type test transaction Tr3 issued by the first master device, and AW3 and W3 are transmitted based on different transmission channels), through the second bus bridge Int_2 corresponding to the second master device MASTER_1, wherein the second type test transaction Tr4 (wherein, Figure 5AW4 indicates the test write command of the second type test transaction Tr4 issued by the second master device, W4 indicates the test write data of the second type test transaction Tr4 issued by the second master device, and AW4 and W4 are transmitted based on different transmission channels), and the first master device and the second master device can simultaneously issue the second type test transaction (TIME1 in the figure indicates the time when the second type test transaction is issued).

[0097] In an optional implementation, when the deadlock test scheme is implemented based on a verification platform, the second type of test transaction can be a pre-constructed second type of test stimulus. Accordingly, this step controls the corresponding master device to issue a test transaction based on the verification component of the verification platform (for example, the AXI_UVC component of the UVC platform, where UVC is the Universal Verification Component). That is, the first master device can be controlled based on the verification component of the verification platform to send the write command to be tested in the second type of test stimulus to the second slave device, and the second master device can be controlled to send the write command to be tested in the second type of test stimulus to the first slave device.

[0098] Continue to refer Figure 3 , execute step S130, and determine whether a deadlock occurs based on the data received from the first slave device and the second slave device.

[0099] Based on the sending of the aforementioned test transaction, if a deadlock occurs, the first slave device and the second slave device cannot successfully receive the test write data of any test transaction, including the test write data in the first type test transaction and the second type test transaction. Accordingly, based on the data received by the first slave device and the second slave device, it can be determined whether the test write data is successfully received, and then whether a deadlock occurs.

[0100] Specifically, this step may be: determining whether the first slave device and the second slave device successfully receive the test write data, if so, no deadlock occurs, if not, a deadlock occurs.

[0101] In a specific example, refer to Figure 6 to Figure 7 is an optional flow chart of step S130. Figure 6 In the example, for the first master device, the test write command AW1 of the first type test transaction Tr1 and the test write command AW3 of the second type test transaction Tr3 issued by the first master device will transmit the corresponding information through different transmission paths; similarly, for the second master device, the test write command AW2 of the first type test transaction Tr2 and the test write command AW4 of the second type test transaction Tr4 issued by the second master device will also transmit the corresponding information through different transmission paths. Figure 7If the test write command AW3 of the second type test transaction Tr3 issued by the first master device reaches the second slave device earlier than the test write command AW2 of the first type test transaction Tr2 issued by the second master device, and the test write command AW4 of the second type test transaction Tr4 issued by the second master device reaches the second slave device earlier than the test write command AW1 of the first type test transaction Tr1 issued by the first master device, a deadlock will occur.

[0102] It can be seen that in the embodiment of the present invention, by simulating the deadlock scenario, it is determined whether there are defects in the bus architecture that may cause deadlock.

[0103] In a further example, in order to comprehensively test the design under test, the two main devices may be further alternated and then the corresponding test may be performed again. Figure 8 Another optional flow chart of the deadlock test method shown in FIG. 1 , the deadlock test method may further include:

[0104] Step S200: sending a first type of test transaction from the first master device to the second slave device, and sending the first type of test transaction from the second master device to the first slave device;

[0105] In step S110, the first master device sends a first type test transaction to the first slave device, and the second master device sends a first type test transaction to the second slave device. This step is further performed by the first master device sending the first type test transaction to the second slave device, and the second master device sending the first type test transaction to the first slave device.

[0106] The inventors believe that the cause of deadlock mainly lies in the order of data transmission and the different delays that may be caused by data transmission on different paths. Therefore, after the aforementioned test of the corresponding paths, different paths can be tested again after the master device is switched, so as to further perform deadlock testing and more comprehensively confirm whether there are defects in the bus architecture that may cause deadlock.

[0107] The first master device and the second master device may simultaneously issue the first type test transaction.

[0108] In an optional implementation, when the deadlock test scheme is implemented based on a verification platform, a verification component based on the verification platform (for example, the AXI_UVC component of the UVC platform) controls the corresponding master device to issue a test transaction. Specifically, the verification component based on the verification platform controls the first master device to send a first type of test stimulus to the second slave device, and controls the second master device to send a first type of test stimulus to the first slave device.

[0109] The first type of test transaction and its issuing process may further refer to the description in step S110, which will not be described in detail in the present invention.

[0110] Step S210: within a preset time interval of sending the first type test transaction, start transmitting the second type test transaction from the first master device to the first slave device, and start transmitting the second type test transaction from the second master device to the second slave device;

[0111] In step S120, the transmission of the second type of test transaction from the first master device to the second slave device is initiated, and the transmission of the second type of test transaction from the second master device to the first slave device is initiated. This step further initiates the sending of the first type of test transaction from the first master device to the first slave device, and initiates the transmission of the second type of test transaction from the second master device to the second slave device.

[0112] In view of the above reasons, by testing different paths again after the master device is switched, a further deadlock test is performed to more comprehensively confirm whether there are defects in the bus architecture that may cause deadlock.

[0113] Among them, initiating the transmission of the second type of test transaction from the first master device to the first slave device may specifically be transmitting a write command to be tested from the first master device to the first slave device; correspondingly, initiating the transmission of the second type of test transaction from the second master device to the second slave device may specifically be transmitting a write command to be tested from the second master device to the second slave device.

[0114] The first master device and the second master device may simultaneously issue the second type test transaction.

[0115] In an optional implementation, when the deadlock test scheme is implemented based on a verification platform, the verification component based on the verification platform (for example, the AXI_UVC component of the UVC platform) controls the corresponding master device to issue a test transaction. Specifically, the verification component based on the verification platform controls the first master device to send a write command to be tested in a second type of test stimulus to the first slave device, and controls the second master device to send a write command to be tested in the second type of test stimulus to the second slave device.

[0116] The preset time interval, the second type of test transaction and the issuance process thereof may further refer to the description in step S120, and the present invention will not elaborate on them herein.

[0117] Step S220: Determine whether a deadlock occurs again based on the data received by the first slave device and the second slave device.

[0118] It is understandable that if a deadlock occurs, the first slave device and the second slave device cannot successfully receive the test write data of any test transaction, including the test write data in the first type test transaction and the second type test transaction. Accordingly, based on the data received by the first slave device and the second slave device, it can be determined whether the test write data is successfully received, and then whether a deadlock occurs.

[0119] Specifically, this step may be: determining whether the first slave device and the second slave device successfully receive the test write data, if so, no deadlock occurs, if not, a deadlock occurs.

[0120] In a further example of the present invention, the above steps S110 to S130 or step S220 may be further repeatedly executed until a preset condition is met, thereby confirming whether the design to be tested has defects through multiple targeted test collisions.

[0121] The preset condition may be, for example, that a deadlock is confirmed in step S130 or step S220, or that no deadlock is generated, and steps S110 to S220 are repeated for a preset number of times. The preset number of times may be, for example, an integer greater than or equal to 2, such as 10, 20, 30, 50, etc. It is understandable that the greater the number of predictions, the greater the credibility of the corresponding test result.

[0122] In a further example, the deadlock test method is repeatedly executed based on different master devices or slave devices. Accordingly, in step S100, the master device and the slave device only need to be selected according to the predicted mechanism.

[0123] In an optional test scheme, the deadlock test method can be repeatedly executed based on a preset scheme. For example, a test sequence table can be first constructed, and the test sequence table is used to indicate the test sequence of the test schemes composed of different master devices and slave devices, and the test sequence table can cover all testable schemes in the design to be tested. Accordingly, in step S100, the master device and the slave device in the corresponding test scheme can be selected based on the order in the test sequence table. It can be understood that in the test sequence table, at least one of the master devices or the slave devices is different in different test schemes.

[0124] It can be seen that in the embodiment of the present invention, the test is performed based on the test sequence table, so as to more comprehensively determine whether there are defects in the bus architecture that may cause deadlock.

[0125] The deadlock test device provided by the embodiment of the present invention is introduced below. The device content described below can be regarded as a chip verification system or computer equipment, which is a functional module required to implement the deadlock test method provided by the embodiment of the present invention. The deadlock test device is used to test the design to be tested, wherein the design to be tested includes a bus architecture, and multiple master devices and slave devices connected to the bus architecture. The device content described below can be referenced to the method content described above.

[0126] Fig. 9 FIG. 2 shows an optional block diagram of a deadlock test device provided by an embodiment of the present invention. Fig. 9 As shown, the device may include:

[0127] The device selection module 300 is used to select two master devices connected to the bus architecture as the first master device and the second master device, and select two slave devices connected to the bus architecture as the first slave device and the second slave device;

[0128] A test module 310 is configured to send a first type of test transaction from a first master device to a first slave device, and to send a first type of test transaction from a second master device to a second slave device, wherein the first type of test transaction includes a write command to be tested and write data to be tested, and the write data to be tested in the first type of test transaction is greater than or equal to a first preset length; and, within a preset time interval for sending the first type of test transaction, initiate transmission of a second type of test transaction from the first master device to the second slave device, and initiate transmission of a second type of test transaction from the second master device to the first slave device, wherein the second type of test transaction includes a write command to be tested and write data to be tested, and the write data to be tested in the second type of test transaction is less than or equal to a second preset length; the second preset length is less than the first preset length, and the preset time interval is less than the transmission time of the write data to be tested of the first type of test transaction;

[0129] The deadlock confirmation module 320 is used to determine whether a deadlock occurs based on the data received from the first slave device and the second slave device.

[0130] In some embodiments, the testing module 310 is further used to:

[0131] Sending a first type of test transaction from the first master device to the second slave device, and sending the first type of test transaction from the second master device to the first slave device;

[0132] Initiate transmission of a second type of test transaction from the first master device to the first slave device, and initiate transmission of a second type of test transaction from the second master device to the second slave device, within a preset time interval of sending the first type of test transaction;

[0133] The deadlock confirmation module 320 is further configured to determine whether a deadlock occurs based on the data received from the first slave device and the second slave device.

[0134] In some embodiments, the device selection module 300 is used to select two master devices connected to the bus architecture as the first master device and the second master device, and select two slave devices connected to the bus architecture as the first slave device and the second slave device, including:

[0135] Randomly name the two master devices as a first master device and a second master device respectively;

[0136] The remote slave device of the first master device is named as the first slave device, and the other slave device is named as the second slave device; or the remote slave device of the second master device is named as the first slave device, and the other slave device is named as the second slave device.

[0137] In some embodiments, the first type of test transaction is a pre-constructed first type of test stimulus, and the test module 310 is used to send the first type of test transaction from the first master device to the first slave device, and send the first type of test transaction from the second master device to the second slave device, specifically:

[0138] The verification component based on the verification platform controls the first master device to send a first type of test stimulus to the first slave device, and controls the second master device to send the first type of test stimulus to the second slave device.

[0139] In some embodiments, the test module 310 is used to initiate the transmission of a second type of test transaction from a first master device to a second slave device, specifically, to transmit a write command to be tested of the second type of test transaction from the first master device to the second slave device; the test module 310 is used to initiate the transmission of a second type of test transaction from the second master device to the first slave device, specifically, to transmit a write command to be tested of the second type of test transaction from the second master device to the first slave device.

[0140] In some embodiments, the second type of test transaction is a pre-constructed second type of test stimulus, and the test module 310 is used to initiate transmission of the second type of test transaction from the first master device to the second slave device, and initiate transmission of the second type of test transaction from the second master device to the first slave device, specifically:

[0141] The verification component based on the verification platform controls the first master device to send the write command to be tested in the second type of test stimulus to the second slave device, and controls the second master device to send the write command to be tested in the second type of test stimulus to the first slave device.

[0142] In some embodiments, the deadlock confirmation module 320 is used to determine whether a deadlock occurs based on the data received from the first slave device and the second slave device, specifically:

[0143] Determine whether the first slave device and the second slave device successfully receive the test write data. If so, no deadlock occurs. If not, a deadlock occurs.

[0144] In some embodiments, the first preset length is 256 burst lengths, the second preset length is 5 burst lengths; and the preset time interval is less than or equal to 1 clock cycle.

[0145] In some embodiments, the device selection module 300 is used to select two master devices connected to the bus architecture as the first master device and the second master device, and select two slave devices connected to the bus architecture as the first slave device and the second slave device, respectively. After that, the test module 310 is used to repeatedly perform the steps of sending a first type of test transaction from the first master device to the first slave device, and sending a first type of test transaction from the second master device to the second slave device, until the step of again performing the steps of receiving data based on the first slave device and the second slave device, until a preset condition is met;

[0146] Wherein, the preset conditions are:

[0147] The deadlock confirmation module 320 is used to confirm that a deadlock occurs in the step of determining whether a deadlock occurs based on the data received from the first slave device and the second slave device or in the step of determining whether a deadlock occurs again based on the data received from the first slave device and the second slave device;

[0148] or,

[0149] No deadlock occurs, and the first type of test transaction is sent from the first master device to the first slave device, and the first type of test transaction is sent from the second master device to the second slave device, until the step of again receiving data based on the first slave device and the second slave device is repeated a preset number of times.

[0150] In some embodiments, reference Fig.10 Another optional block diagram of the deadlock test device provided by an embodiment of the present invention is shown, and the deadlock test device also includes:

[0151] A sequence table construction module 330 is used to construct a test sequence table, wherein the test sequence table is used to indicate the test sequence of the test schemes composed of different master devices and slave devices, wherein at least one of the master devices or the slave devices is different in different test schemes;

[0152] The device selection module 300 is used to select two master devices connected to the bus architecture as the first master device and the second master device, and select two slave devices connected to the bus architecture as the first slave device and the second slave device. Specifically, based on the order in the test sequence table, the master device and the slave device in the corresponding test plan are selected.

[0153] An embodiment of the present invention further provides a chip verification system. In some embodiments, the chip verification system may be configured to execute the deadlock test method provided by the embodiment of the present invention.

[0154] An embodiment of the present invention also provides a computer device, which may include: at least one memory and at least one processor; the memory stores one or more computer executable instructions, and the processor calls the one or more computer executable instructions to execute the deadlock testing method provided by the embodiment of the present invention.

[0155] An embodiment of the present invention provides a storage medium, wherein the storage medium stores one or more computer executable instructions, and the one or more computer executable instructions are used to execute the above-mentioned deadlock test method.

[0156] An embodiment of the present invention provides a computer program product, including one or more computer executable instructions, wherein the one or more computer executable instructions implement the above-mentioned deadlock testing method when executed.

[0157] The above describes multiple implementation schemes provided by the embodiments of the present invention. The various optional methods introduced in the implementation schemes can be combined and cross-referenced with each other without conflict, thereby extending a variety of possible implementation schemes, which can all be considered as implementation schemes disclosed and open in the embodiments of the present invention.

[0158] Although the embodiments of the present invention are disclosed above, the present invention is not limited thereto. Any person skilled in the art can make various changes and modifications without departing from the spirit and scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the scope defined by the claims.

Claims

1. A deadlock testing method, characterized in that: For testing a design to be tested, wherein the design to be tested includes a bus architecture, and a plurality of master devices and slave devices connected in the bus architecture; the method includes: Select two master devices connected to the bus architecture as the first master device and the second master device, and select two slave devices connected to the bus architecture as the first slave device and the second slave device; Sending a first type of test transaction from a first master device to a first slave device, and sending a first type of test transaction from a second master device to a second slave device, wherein the first type of test transaction includes a write command to be tested and write data to be tested, and the write data to be tested in the first type of test transaction is greater than or equal to a first preset length; Initiate transmission of a second type of test transaction from the first master device to the second slave device, and initiate transmission of a second type of test transaction from the second master device to the first slave device within a preset time interval of sending the first type of test transaction, wherein the second type of test transaction includes a write command to be tested and write data to be tested, and the write data to be tested in the second type of test transaction is less than or equal to a second preset length; the second preset length is less than the first preset length, and the preset time interval is less than a transmission time of the write data to be tested of the first type of test transaction; Based on the data received from the first slave device and the second slave device, it is determined whether a deadlock occurs.

2. The method according to claim 1, characterized in that Also includes: Sending a first type of test transaction from the first master device to the second slave device, and sending the first type of test transaction from the second master device to the first slave device; Initiate transmission of a second type of test transaction from the first master device to the first slave device, and initiate transmission of a second type of test transaction from the second master device to the second slave device, within a preset time interval of sending the first type of test transaction; Again based on the data received from the first slave device and the second slave device, it is determined whether a deadlock occurs.

3. The method according to claim 1, characterized in that The method of selecting two master devices connected to the bus architecture as a first master device and a second master device, and selecting two slave devices connected to the bus architecture as a first slave device and a second slave device, comprises: Randomly name the two master devices as a first master device and a second master device respectively; The remote slave device of the first master device is named as the first slave device, and the other slave device is named as the second slave device; or the remote slave device of the second master device is named as the first slave device, and the other slave device is named as the second slave device.

4. The method according to any one of claims 1 to 3, characterized in that: The first type of test transaction is a pre-constructed first type of test stimulus, and the first type of test transaction is sent from the first master device to the first slave device, and the first type of test transaction is sent from the second master device to the second slave device, specifically: The verification component based on the verification platform controls the first master device to send a first type of test stimulus to the first slave device, and controls the second master device to send the first type of test stimulus to the second slave device.

5. The method according to any one of claims 1 to 3, characterized in that: The initiation of transmission of the second type of test transaction from the first master device to the second slave device is specifically, transmitting the test write command of the second type of test transaction from the first master device to the second slave device; the initiation of transmission of the second type of test transaction from the second master device to the first slave device is specifically, transmitting the test write command of the second type of test transaction from the second master device to the first slave device.

6. The method according to claim 5, characterized in that The second type test transaction is a pre-constructed second type test stimulus, and the initiation of transmission of the second type test transaction from the first master device to the second slave device, and the initiation of transmission of the second type test transaction from the second master device to the first slave device, are specifically: The verification component based on the verification platform controls the first master device to send the write command to be tested in the second type of test stimulus to the second slave device, and controls the second master device to send the write command to be tested in the second type of test stimulus to the first slave device.

7. The method according to claim 1, characterized in that The determining whether a deadlock occurs based on the data received from the first slave device and the second slave device is specifically: Determine whether the first slave device and the second slave device successfully receive the test write data. If so, no deadlock occurs. If not, a deadlock occurs.

8. The method according to claim 1, characterized in that The first preset length is 256 burst lengths, the second preset length is 5 burst lengths; the preset time interval is less than or equal to 1 clock cycle.

9. The method according to claim 2, characterized in that: After the steps of selecting two master devices connected to the bus architecture as the first master device and the second master device, and selecting two slave devices connected to the bus architecture as the first slave device and the second slave device, the steps of sending a first type of test transaction from the first master device to the first slave device, and sending a first type of test transaction from the second master device to the second slave device are repeated, until the step of again receiving data based on the first slave device and the second slave device is met, until a preset condition is met; The preset conditions are: Confirming that a deadlock occurs in the step of determining whether a deadlock occurs based on the data received from the first slave device and the second slave device or in the step of determining whether a deadlock occurs again based on the data received from the first slave device and the second slave device; or, No deadlock occurs, and the first type of test transaction is sent from the first master device to the first slave device, and the first type of test transaction is sent from the second master device to the second slave device, until the step of again receiving data based on the first slave device and the second slave device is repeated a preset number of times.

10. The method according to claim 1, characterized in that Before the step of selecting two master devices connected to the bus architecture as the first master device and the second master device, and selecting two slave devices connected to the bus architecture as the first slave device and the second slave device, the method further includes: Constructing a test sequence table, wherein the test sequence table is used to indicate the test sequence of the test schemes composed of different master devices and slave devices, wherein at least one of the master devices or the slave devices is different in different test schemes; The step of selecting two master devices connected to the bus architecture as the first master device and the second master device, and selecting two slave devices connected to the bus architecture as the first slave device and the second slave device, specifically, selecting the master device and the slave device in the corresponding test plan based on the order in the test sequence table.

11. A deadlock testing device, characterized in that: Used to test a design to be tested, wherein the design to be tested includes a bus architecture, and a plurality of master devices and slave devices connected in the bus architecture; the device includes: A device selection module, used to select two master devices connected to the bus architecture as the first master device and the second master device, and select two slave devices connected to the bus architecture as the first slave device and the second slave device; A test module, configured to send a first type of test transaction from a first master device to a first slave device, and to send a first type of test transaction from a second master device to a second slave device, wherein the first type of test transaction includes a write command to be tested and write data to be tested, and the write data to be tested in the first type of test transaction is greater than or equal to a first preset length; and, within a preset time interval for sending the first type of test transaction, initiate transmission of a second type of test transaction from the first master device to the second slave device, and initiate transmission of a second type of test transaction from the second master device to the first slave device, wherein the second type of test transaction includes a write command to be tested and write data to be tested, and the write data to be tested in the second type of test transaction is less than or equal to a second preset length; the second preset length is less than the first preset length, and the preset time interval is less than the transmission time of the write data to be tested of the first type of test transaction; The deadlock confirmation module is used to determine whether a deadlock occurs based on the data received by the first slave device and the second slave device.

12. The device according to claim 11, characterized in that Also includes: A sequence table construction module, used to construct a test sequence table, wherein the test sequence table is used to indicate the test sequence of the test schemes composed of different master devices and slave devices, wherein at least one of the master devices or the slave devices is different in different test schemes; The device selection module is used to select two master devices connected to the bus architecture as the first master device and the second master device, and select two slave devices connected to the bus architecture as the first slave device and the second slave device. Specifically, based on the order in the test sequence table, the master device and the slave device in the corresponding test plan are selected.

13. A chip verification system, characterized in that: The chip verification system is configured to execute the deadlock test method according to any one of claims 1-10.

14. A computer device, characterized in that: include: at least one memory and at least one processor; The memory stores one or more computer executable instructions, and the processor calls the one or more computer executable instructions to execute the deadlock testing method according to any one of claims 1-10.

15. A storage medium, characterized in that: The storage medium stores one or more computer executable instructions, and the one or more computer executable instructions are used to execute the deadlock testing method according to any one of claims 1-10.

16. A computer program product, characterized in that It comprises one or more computer executable instructions, and when the one or more computer executable instructions are executed, the deadlock testing method according to any one of claims 1 to 10 is implemented.

Images