Retry mechanism verification system and method

Abstract

The application provides a retry mechanism verification system and method, and relates to the technical field of multi-core processor interconnection bus protocol verification. The system comprises at least one master node monitoring device, a central cooperative processor and at least one request node agent. The master node monitoring device collects the running state signals inside the master node in real time, generates a retry prediction information package containing the predicted expected retry event type and the retry prediction value, and the retry prediction value indicates the future time of the predicted retry event occurrence; the central cooperative processor calculates the request sending delay based on the retry prediction value, generates a request strategy package containing the delay, and sends it to the request node agent; and the request node agent sends a request sequence to the bound request node after the request sending delay to trigger the retry event. The application predicts the retry event occurrence time and accurately controls the excitation sending time accordingly, thereby improving the verification method efficiency and the scene coverage.

Description

Technical Field

[0001] This invention relates to the field of multi-core processor interconnect bus protocol verification technology, and in particular to a verification system and method for a retry mechanism. Background Technology

[0002] The demand for multi-core processors continues to grow, and the scale and design complexity of systems are constantly increasing. Multi-core processors are interconnected using a coherent bus protocol.

[0003] To avoid deadlocks and protect quality of service, interconnect protocols commonly incorporate request retry mechanisms. These mechanisms allow the target node to return a specific retry response when resources are unavailable, prompting the requesting node to re-initiate the request, thus providing the system with resilient processing capabilities. The correctness of the retry mechanism directly affects the functional integrity and performance of multi-core processor systems; therefore, thorough verification of it is crucial.

[0004] Currently, the mainstream retry mechanism verification methods include the following three types: First, the random stress verification method, which sends a large number of random stimuli on the bus interface to create a stress scenario on the transmission channel, thereby triggering the retry mechanism in the design under test; second, the gray box verification method, which generates targeted test stimuli to pre-fill the request buffer to trigger the retry mechanism; and third, the isolation verification method, which isolates the retry module on the request end and the retry response module on the receiving end for separate module-level verification.

[0005] However, all of the above verification methods have obvious shortcomings: the random stress verification method can trigger the retry mechanism, but the triggering depends entirely on randomness, resulting in low verification efficiency, unpredictable coverage scenarios, and forced extension of the verification cycle; the gray box verification method sets behaviors that may exceed the real scenario, loses the coupling between the scenario and the implementation of the design function, and changes in the micro-architecture will cause the verification scenario to be missing; the isolation verification method cannot cover the chain reaction of retry in the system level and the state consistency problem, and the system-level retry mechanism verification is still required in the later stage of verification, resulting in duplicate workload.

[0006] Therefore, how to improve the efficiency and scenario coverage of the retry mechanism verification while ensuring the authenticity of the verification scenario has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0007] This invention provides a verification system and method for a retry mechanism, which solves the problems of low efficiency and lack of coverage in the verification of retry mechanisms in the prior art.

[0008] This invention provides a verification system for a retry mechanism, applied to a design-under-test (DUT) verification scenario using a multi-core processor interconnect bus protocol. The system includes: at least one master node monitoring device, a central coprocessor, and at least one request node agent. The master node monitoring device is bound to the master node in the DUT and is used to collect real-time operating status signals within the bound master node, and generate a retry prediction information packet based on the operating status signals. The retry prediction information packet contains a predicted retry event type and a retry prediction value determined based on the operating status signals, whereby the retry prediction value indicates the future time of the predicted retry event. The central coprocessor is communicatively connected to both the master node monitoring device and the request node agent, and is used to receive the retry prediction information packet, calculate the request transmission delay based on the retry prediction value in the retry prediction information packet, and generate a request policy packet containing the request transmission delay, which is then sent to the request node agent. The request node agent is bound to the request node in the DUT and, upon receiving the request policy packet, sends a request sequence to its bound request node after the request transmission delay, according to the control of the request policy packet, to trigger a retry event.

[0009] According to the present invention, a verification system for a retry mechanism further includes: a retry event pre-configuration module, used to provide multiple retry event types and their corresponding retry event codes; a master node monitoring device, further used to: generate a retry prediction information packet based on the running status signal and the retry event code; the retry event types include resource limitation type, address locking type, and performance management type; wherein, resource limitation type retry event refers to an event triggered by the master node's internal hardware resource occupancy reaching a preset threshold, address locking type retry event refers to an event triggered by the address space pointed to by the access request being in a locked state, and performance management type retry event refers to an event triggered by a conflict between transaction requests of different priorities, in order to ensure the service quality of high-priority transactions, causing low-priority transactions to retry.

[0010] According to the present invention, a verification system for a retry mechanism includes a master node monitoring device comprising: a retry event monitoring sub-device, a retry event prediction sub-device, and a retry event sending sub-device. The retry event monitoring sub-device is used to collect the operating status signals within the master node it is bound to and generate a monitoring information packet containing the collected signal values. The retry event prediction sub-device is used to receive the monitoring information packet and, when it determines that the signal value in the monitoring information packet meets a preset trigger condition, generate a retry prediction information packet. The trigger condition is that the signal value in the monitoring information packet reaches a preset threshold. The retry event prediction sub-device is also used to discard monitoring information packets for the same retry event type within the time period corresponding to the retry prediction value after generating the retry prediction information packet. The retry event sending sub-device is used to select and send the retry prediction information packet with the highest priority to the central co-processor according to a preset sending priority rule when multiple retry prediction information packets to be sent exist simultaneously.

[0011] According to the present invention, a retry mechanism verification system and a retry event monitoring sub-device are specifically used to: extract internal signals or signal groups related to the retry event type from the master node bound to the virtual interface module in a hierarchical path reference manner, so as to realize the acquisition of running status signals.

[0012] According to the present invention, a verification system for a retry mechanism includes a central coprocessor specifically configured to: select a target request node agent from among the request node agents; calculate the request sending delay based on the retry prediction value and the path transmission delay from the target request node agent to the source master node; wherein the rule for selecting the target request node agent is to select the request node agent with the shortest routing distance to the source master node.

[0013] According to the verification system of the retry mechanism provided by the present invention, when the retry event type in the retry prediction information packet is a request address locking event, the request policy packet also contains the same request address as the address information carried in the retry prediction information packet; when the retry event type in the retry prediction information packet is a QoS priority conflict event, the request policy packet also contains a request QoS value that is higher than the QoS value recorded in the retry prediction information packet.

[0014] This invention also provides a verification method for a retry mechanism, applied to a design-under-test (DUT) verification scenario using a multi-core processor interconnect bus protocol. The method includes: real-time acquisition of the operating status signals within the master node of the DUT via a master node monitoring device, and generation of a retry prediction information packet based on the operating status signals; the retry prediction information packet contains a retry event type and a retry prediction value determined based on the operating status signals, whereby the retry prediction value indicates the future time of the predicted retry event; receiving the retry prediction information packet via a central coprocessor, calculating the request transmission delay based on the retry prediction value in the retry prediction information packet, generating a request policy packet containing the request transmission delay, and sending the request policy packet; receiving the request policy packet via a request node proxy, and, according to the control of the request policy packet, sending a request sequence to the DUT after the request transmission delay to trigger a retry event.

[0015] According to a verification method for a retry mechanism provided by the present invention, the master node monitoring device includes: a retry event monitoring sub-device and a retry event prediction sub-device; the method further includes: through the retry event monitoring sub-device, collecting the internal operating status signals of the master node to which it is bound, and generating a monitoring information packet containing the collected signal values; through the retry event prediction sub-device, receiving the monitoring information packet, and generating a retry prediction information packet when it is determined that the signal values ​​in the monitoring information packet meet a preset trigger condition; the trigger condition is that the signal values ​​in the monitoring information packet reach a preset threshold.

[0016] According to the verification method of the retry mechanism provided by the present invention, the master node monitoring device further includes a retry event sending sub-device; the method further includes: when multiple retry prediction information packets are generated simultaneously, the retry event sending sub-device selects and sends the retry prediction information packet with the highest priority to the central co-processor according to a preset sending priority rule; after the retry prediction information packet is generated, the retry event prediction sub-device discards monitoring information packets for the same retry event type within the time period corresponding to the retry prediction value.

[0017] According to a verification method for a retry mechanism provided by the present invention, a request policy packet containing a request sending delay is generated, comprising: selecting the request node agent with the shortest routing distance to the source master node from the request node agents as the target request node agent; calculating the request sending delay based on the retry prediction value and the path transmission delay from the target request node agent to the source master node; and generating a request policy packet containing the request sending delay. Wherein, when the retry event type in the retry prediction information packet is a request address locking event, the request policy packet also contains a request address identical to the address information carried in the retry prediction information packet; when the retry event type in the retry prediction information packet is a QoS priority conflict event, the request policy packet also contains a request QoS value higher than the QoS value recorded in the retry prediction information packet.

[0018] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a verification method for the retry mechanism as described in any of the preceding claims.

[0019] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements a verification method for a retry mechanism as described in any of the preceding claims.

[0020] The present invention also provides a computer program product, including a computer program, which, when executed by a processor, implements a verification method for the retry mechanism as described in any of the preceding claims.

[0021] The verification system and method for the retry mechanism provided by this invention collects the internal operating status signals of the master node in real time through the master node monitoring device and generates a retry prediction information packet containing the retry event type and retry prediction value. This enables the prediction of retry events and their occurrence time, changing the triggering from passive randomness to active prediction. The central coprocessor calculates the request sending delay based on the retry prediction value and generates a request strategy packet containing the delay. The predicted future time point is converted into precise sending time control parameters for the request node agent, completing the time-space scheduling connection from global prediction to local execution. The request node agent sends the request sequence after the request sending delay according to the control of the request strategy packet. Under the condition that the system state naturally approaches the retry boundary, the retry event is accurately induced to occur with normal incentives allowed by the protocol. This avoids gray-box operations that exceed the real scenario, thereby significantly improving the verification efficiency and scenario coverage of the retry mechanism while ensuring the authenticity of the verification scenario and the system-level coupling. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram of a design-to-test and verification environment provided in an embodiment of the present invention.

[0024] Figure 2 This is a schematic diagram of the structure of a verification system for a retry mechanism provided in an embodiment of the present invention.

[0025] Figure 3 This is a schematic diagram of the structure of a verification system for another retry mechanism provided in an embodiment of the present invention.

[0026] Figure 4 This is a schematic diagram of the structure of a master node monitoring device provided in an embodiment of the present invention.

[0027] Figure 5 This is a flowchart illustrating a verification method for a retry mechanism provided in an embodiment of the present invention.

[0028] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0030] Figure 1 This is a schematic diagram of a design-to-test and verification environment provided in an embodiment of the present invention.

[0031] like Figure 1 As shown, the framework consists of two core parts: the design under test and the verification environment.

[0032] For example, the design under test is a Network on Chip (NOC) subsystem based on the Advanced Microcontroller Bus Architecture Coherent Hub Interface (AMBA CHI) bus interface protocol. This design under test is compatible with other multi-core coherent interconnect bus protocols such as Compute Express Link (CXL).

[0033] Specifically, the design under test includes a core cache request node, at least one master node, and a router. The nodes are interconnected via an AMBA CHI bus. The router is responsible for receiving request packets sent by each request node and routing the request packets to each target node for processing, thereby achieving consistent data interaction between the multi-core nodes.

[0034] Specifically, the verification environment is deployed in the chip simulation verification platform to verify the correctness of the retry mechanism function of the design under test. The verification environment includes request node agents, core cache request node agents, master node agents, slave node agents, master node monitoring devices, and a central coprocessor. Each agent, monitoring device, and central coprocessor interact with the verification platform through the communication interface.

[0035] In this embodiment of the invention, the functions of each core component in the verification environment are as follows:

[0036] Core cache request node proxy: It is responsible for sending read and write access requests to the core cache request node of the design under test. At the same time, it can receive policy information issued by the central coprocessor in real time, thereby controlling the generation sequence and attributes of new requests.

[0037] Request Node Proxy: Responsible for sending read and write access requests to the corresponding request node of the design under test. It can also receive policy information issued by the central coprocessor in real time, thereby controlling the generation of new requests and the subsequent processing of requests that have been retried.

[0038] Master Node Agent: Used to receive and process read and write access requests from the master node of the design under test and return the corresponding completion response; it can also send listening requests and receive listening responses; it can return retry responses in a random manner or according to the protocol requirements of the design under test to simulate the behavior of the target node in a real system.

[0039] Slave Node Agent: Used to receive and process read and write access requests from the master node of the design under test, and return the corresponding read and write completion response, simulating the real behavior of the peripheral slave node.

[0040] Master node monitoring device: It is bound one-to-one with the master node of the design under test, and is responsible for monitoring the internal request buffer occupancy rate, credit counters of each channel, directory state machine, listening filter and other operating status information of the master node, generating retry prediction information and retry trigger reasons, and transmitting relevant information to the central co-processor.

[0041] Central Co-processor: The core scheduling module for the verification environment, responsible for aggregating information uploaded by monitoring devices of each master node, generating guiding request control policies based on the aggregated information, and then distributing the policy information to the corresponding request node agents and core cache request node agents; the policy information includes core control parameters such as the clock cycle for predicting retry.

[0042] The following is combined with Figure 2 The present invention describes a verification system for the retry mechanism, which is applied to a design-under-test scenario of a multi-core processor interconnect bus protocol.

[0043] Figure 2This is a schematic diagram of the structure of the verification system for the retry mechanism provided in an embodiment of the present invention. Figure 2 As shown, the system includes: at least one master node monitoring device 210, a central co-processor 220, and at least one request node agent 230. The central co-processor 220 is communicatively connected to both the master node monitoring device 210 and the request node agent 230.

[0044] In some embodiments, the master node monitoring device 210 is bound to the master node in the design under test, and is used to collect the internal operating status signals of the master node it is bound to in real time, and generate retry prediction information packets based on the operating status signals.

[0045] The retry prediction information package includes the type of retry event and the retry prediction value, which are determined based on the operating status signal. The retry prediction value indicates the future time when the retry event is predicted to occur.

[0046] For example, the retry event monitoring sub-device sets up a corresponding monitoring path for each type of retry event. Each monitoring path collects a set of hardware signals related to that type of retry event inside the master node, ensuring that all hardware behaviors that can trigger the retry mechanism can be fully monitored.

[0047] Specifically, after acquiring the real-time status of the corresponding signal, the retry event monitoring sub-device packages the acquired signal value with the unique event code corresponding to the retry event to generate a standardized monitoring information package; whenever the acquired signal changes, the retry event monitoring sub-device generates a new monitoring information package and sends it to the retry event prediction sub-device.

[0048] In some embodiments, the central coprocessor 220 is used to receive a retry prediction information packet, calculate the request transmission delay based on the retry prediction value in the retry prediction information packet, and generate a request policy packet containing the request transmission delay to send to the request node agent 230.

[0049] For example, the central coprocessor serves as the global scheduling core of the verification environment. It can simultaneously receive retry prediction information packets reported by multiple master node monitoring devices, and match the optimal request node agent for each retry prediction information packet to generate a precise request control policy, ensuring that the corresponding retry event is accurately triggered at the predicted retry time.

[0050] Specifically, after receiving the retry prediction information packet, the central coprocessor first determines the retry event code and calls the corresponding processing logic; then it generates the corresponding request policy packet; and finally it sends the request policy packet to the corresponding request node agent for processing.

[0051] Optionally, the central coprocessor 220 may first select the target request node agent from the request node agents.

[0052] The rule for selecting the target request node proxy is to choose the request node proxy with the shortest routing distance to the source master node.

[0053] For example, in this embodiment, the central coprocessor pre-stores complete network topology information of the design under test, which can calculate the routing distance and transmission delay from each request node proxy to any master node in real time, providing a basis for the selection of the target request node proxy.

[0054] Specifically, in combination Figure 1 Taking request node agent 0, core cache request node agent 0, request node agent 2, request node agent 3 and master node monitoring device 0 (corresponding to the master node home node identifier (HNID) of 0x100) as an example, when the retry event code in the retry prediction information packet received by the central co-processor is 0x10, the HNID field in the retry prediction information packet is read to know that the prediction information comes from master node 0, and the retry prediction value is read to know that the best retry opportunity will appear after 5 cycles. Among all request node agents, the request node agent 0 with the shortest routing distance from master node 0 is selected as the target request node agent.

[0055] Furthermore, the central coprocessor 220 calculates the request sending delay based on the retry prediction value and the path transmission delay from the target request node proxy to the source master node.

[0056] For example, the core logic for calculating the request sending delay is to ensure that the request sent by the requesting node reaches the master node just when the master node's state reaches the retry trigger boundary, thereby accurately triggering the retry event.

[0057] Specifically, the request sending delay is calculated according to the following formula: delay = retry prediction value – path transmission delay from the target request node proxy to the source master node; if the calculation result is negative, then x = 0, where x is the final request sending delay value.

[0058] The following description is based on specific embodiments:

[0059] 1) Calculation of request sending delay for request credit exhaustion events:

[0060] Taking the request node agent 0 and the master node monitoring device 0 as an example, the retry prediction value is 5, and the path transmission delay from the request node agent 0 to the master node 0 is 2 clock cycles. Therefore, the request sending delay = 5 - 2 = 3 clock cycles.

[0061] 2) Calculation of request sending delay for data buffer full events:

[0062] Taking request node agent 2 and master node monitoring device 2 as an example, the retry prediction value is 8, and the path transmission delay from request node agent 2 to master node 2 is 2 clock cycles. Therefore, the request sending delay = 8 - 2 = 6 clock cycles.

[0063] If request node proxy 0 is selected as the target request node proxy, its transmission delay to master node 2 is 4 clock cycles, so the request sending delay = 8 - 4 = 4 clock cycles.

[0064] 3) Calculation of request sending delay for request buffer full event:

[0065] Taking requesting node agent 0 and master node 2 as an example, the retry prediction value is x1, and the transmission delay from requesting node agent 0 to master node 2 is 4 clock cycles. Then the request sending delay = x1 - 4. If the calculation result is negative, then delay = 0.

[0066] 4) Calculation of request sending delay for the request address locking event:

[0067] Taking the request node proxy 2 and master node 2 as an example, the retry prediction value is 3, and the path transmission delay to master node 2 is 2 clock cycles. Therefore, the request sending delay = 3 - 2 = 1 clock cycle.

[0068] 5) Calculation of request sending delay for Quality of Service (QoS) priority conflict events:

[0069] Taking the request node proxy 0 and master node 0 as an example, the retry prediction value is 5, and the path transmission delay to master node 0 is 2 clock cycles. Therefore, the request sending delay = 5 - 2 = 3 clock cycles.

[0070] Thus, this invention ensures that the request arrives at the master node at the predicted retry trigger boundary by accurately calculating the request sending delay based on the retry prediction value and path transmission delay, thereby improving the triggering probability of retry events and solving the problems of low triggering efficiency and uncontrollable scenarios in random verification methods.

[0071] In one optional implementation, when the retry event type in the retry prediction packet is a request address locking event, the request strategy packet also contains the same request address as the address information carried in the retry prediction packet.

[0072] For example, for a request address locking event, only requests that access the locked address will trigger a retry. Therefore, the request policy package must specify a request address that is exactly the same as the locked address in order to accurately trigger the corresponding retry event.

[0073] Specifically, taking the request address lock event reported by master node 2 as an example, if the lock address carried in the retry prediction information packet is 0x5123, then in the request policy packet generated by the central coprocessor, the request address addr field is set to the same address information 0x5123 as provided in the retry prediction information packet, ensuring that the request sent by the request node agent accesses the lock address, thereby triggering the address lock retry event.

[0074] In another optional implementation, when the retry event type in the retry prediction packet is a QoS priority conflict event, the request policy packet also includes a request QoS value that is higher than the QoS value recorded in the retry prediction packet.

[0075] For example, for QoS priority conflict events, only higher-priority requests to the same address will trigger a retry of the lower-priority transaction. Therefore, the request policy packet must be set with a QoS value higher than that of the conflicting transaction in order to trigger the corresponding retry event.

[0076] Specifically, taking the QoS priority conflict event reported by master node 0 as an example, if the QoS value of the low-priority transaction carried in the retry prediction information packet is 0x8, then the request QoS field in the request policy packet generated by the central co-processor is set to the QoS value in the retry prediction information packet plus 1, i.e., 0x9, to ensure that the priority of the sent request is higher than the low-priority transaction currently being executed, thereby triggering a QoS priority conflict retry event.

[0077] Thus, by generating request strategy package parameters that match the triggering mechanism for different types of retry events, this invention ensures that each type of retry event can be accurately triggered, achieving full-scenario retry mechanism coverage verification and solving the problem of insufficient scenario coverage in existing technologies.

[0078] In some embodiments, the request node agent 230 is bound to a request node in the design under test, and is used to send a request sequence to the request node it is bound to after a request sending delay, in accordance with the control of the request policy packet, when a request policy packet is received, so as to trigger a retry event.

[0079] For example, the request node proxy includes two types: general request node proxy and core cache request node proxy. Both types of proxies can receive request policy packets issued by the central coprocessor and adjust their own request sending behavior.

[0080] Specifically, the request node proxy and the core cache request node proxy add the content of the received request policy packet to the random constraints of the current request node proxy to generate a new request sequence. After sending out the new request sequence, the current request node performs subsequent tests according to the local sending policy.

[0081] For example, the original sending strategy of the request node agent is: the request command identifier opcode is random only for read types, and the values ​​of other fields are random. During operation, when a request policy packet is received from the central coprocessor, the request agent controls the request source ID identifier srcid, request target ID identifier tgtid, request command identifier opcode, request address addr, request QoS, and request sending delay according to the requirements in the request policy packet, and generates a new request sequence that is different from the original sending strategy. Then, the new request sequence is sent to the port of the design under test. After the sending is completed, the request node agent switches back to the original sending strategy.

[0082] It should be noted that request node proxies that do not receive the request policy packet will still execute the original request sending policy normally, which will not affect the normal random stress test operation of the verification environment.

[0083] The retry mechanism verification system provided by this invention collects the internal operating status signals of the master node in real time through the master node monitoring device and generates a retry prediction information packet containing the retry event type and retry prediction value. This enables the prediction of retry events and their occurrence time, changing the triggering from passive randomness to active prediction. The central coprocessor calculates the request sending delay based on the retry prediction value and generates a request strategy packet containing the delay. The predicted future time point is converted into precise sending time control parameters for the request node agent, completing the time-space scheduling connection from global prediction to local execution. The request node agent sends the request sequence after the request sending delay according to the control of the request strategy packet. Under the condition that the system state naturally approaches the retry boundary, the retry event is accurately induced to occur with normal incentives allowed by the protocol. This avoids gray-box operations that exceed the real scenario, thereby significantly improving the verification efficiency and scenario coverage of the retry mechanism while ensuring the authenticity of the verification scenario and the system-level coupling.

[0084] Optionally, such as Figure 3 As shown, the verification system for the retry mechanism provided by the present invention also includes a retry event pre-configuration module 240.

[0085] In some embodiments, the retry event pre-configuration module 240 is used to provide multiple retry event types and their corresponding retry event codes.

[0086] In this embodiment of the invention, the retry event types include resource restriction type, address locking type, and performance management type.

[0087] Resource-limited retry events refer to events triggered by the master node's internal hardware resource usage reaching a preset threshold. For example, specific resource-limited retry events include request credit exhaustion events, data buffer full events, request buffer full events, listener buffer full events, and internal processing queue full events. This embodiment assigns a unique hexadecimal event code to each specific retry event type, as follows:

[0088] Request credit exhaustion event: This refers to the event where the request credit pool count of the request node corresponding to the master node drops to 0, and it is unable to receive new request messages. This retry event is encoded as 0x10.

[0089] Data buffer full event: This refers to an event in which the data buffer in the master node is full, resulting in the inability to receive new request messages. This retry event is encoded as 0x11.

[0090] Request buffer full event: This refers to an event in which the request buffer in the master node is full, resulting in the inability to receive new request messages. This retry event is encoded as 0x12.

[0091] Listener Buffer Full Event: This refers to an event where the listener request buffer in the master node is full. If a new request needs to generate a listener transaction, the new request message cannot be received and will be retried. This retry event is encoded as 0x13.

[0092] Internal processing queue full event: This refers to an event where the master node's internal processing queue is full, resulting in the inability to receive new request packets. This retry event is encoded as 0x14.

[0093] Address lock retry events refer to events that trigger a retry because the address space pointed to by the access request is locked. Specifically, they include request address lock events, coded as 0x20.

[0094] Performance management retry events refer to events that trigger the retry of low-priority transactions to ensure the service quality of high-priority transactions due to conflicts between transaction requests of different priorities. Specifically, these include QoS priority conflict events, coded as 0x30.

[0095] For example, in this embodiment, the retry event pre-configuration module can flexibly adjust the classification and encoding rules of retry events according to the bus protocol type of the design under test and the microarchitecture design of the master node, so as to adapt to different multi-core interconnect bus protocols and different design under test scenarios.

[0096] Specifically, before verification execution, it is necessary to classify and encode retry events according to the design under test description document and relevant bus protocol specifications. The configured retry event types and corresponding codes are stored in the retry event pre-configuration module to provide a unified event identification benchmark for subsequent monitoring, prediction and verification execution.

[0097] In other embodiments, the master node monitoring device 210 is also used to generate a retry prediction information packet based on the running status signal and the retry event code.

[0098] For example, the master node monitoring device sets up corresponding monitoring, prediction and reporting channels for each type of retry event, and can process the monitoring and prediction tasks of multiple types of retry events of multiple master nodes in parallel.

[0099] Specifically, the master node monitoring device collects the operating status signals related to various retry events inside the master node in real time, generates monitoring information packets by combining them with the pre-configured corresponding event codes, and then determines whether the preset retry triggering conditions are met based on the monitoring information packets. If they are met, a retry prediction information packet is generated and reported to the central co-processor.

[0100] Thus, this invention achieves full coverage monitoring of all retry trigger scenarios through pre-configured standardized event classification and coding, avoiding the problem of missing verification scenarios caused by microarchitecture changes.

[0101] Optionally, such as Figure 4 As shown, the master node monitoring device 210 includes: a retry event monitoring sub-device 211, a retry event prediction sub-device 212, and a retry event sending sub-device 213;

[0102] In this embodiment of the invention, the retry event monitoring sub-device 211 is used to collect the running status signals inside the master node to which it is bound, and generate a monitoring information packet containing the collected signal values.

[0103] For example, the retry event monitoring sub-device sets up a corresponding monitoring path for each type of retry event. Each monitoring path collects a set of hardware signals related to that type of retry event inside the master node, ensuring that all hardware behaviors that can trigger the retry mechanism can be fully monitored.

[0104] Specifically, after acquiring the real-time status of the corresponding signal, the retry event monitoring sub-device packages the acquired signal value with the unique event code corresponding to the retry event to generate a standardized monitoring information package; whenever the acquired signal changes, the retry event monitoring sub-device generates a new monitoring information package and sends it to the retry event prediction sub-device.

[0105] Optionally, the retry event monitoring sub-device 211 is specifically used to extract internal signals or signal groups related to the retry event type from the master node it is bound to through a virtual interface module in a hierarchical path reference manner, so as to realize the acquisition of running status signals.

[0106] For example, in this embodiment, the retry event monitoring sub-device acquires signals from the master node by creating a new virtual interface module. This does not require modification of the original hardware logic of the design under test. It can acquire internal signals without loss by simply using the hierarchical path reference method of the verification platform.

[0107] Specifically, the implementation of the virtual interface module and the signal acquisition methods for each retry event are as follows:

[0108] 1) Monitoring of request credit exhaustion events: The request channel credit counter req_credit_cnt in the master node of the design under test is brought out and connected to the port_req_credit_cnt port in the virtual interface module. Then, port_req_credit_cnt is packaged with retry event code 0x10 to generate monitoring information packet P10. Whenever port_req_credit_cnt changes, the new monitoring information packet P10 is sent to the retry event prediction sub-device.

[0109] 2) Monitoring of data buffer full events: The valid data_valid identifiers related to data buffer occupancy in the master node of the design under test are extracted and connected to the virtual interface module. For example, if there are 8 data buffer entries, they are connected to port_data_valid0, port_data_valid1, port_data_valid2, port_data_valid3, port_data_valid4, port_data_valid5, port_data_valid6, and port_data_valid7 in the virtual interface module, respectively. Then, port_data_valid0 to port_data_valid7 are packaged with retry event code 0x11 to generate monitoring information packet P11. Whenever port_data_valid changes, the new monitoring information packet P11 is sent to the retry event prediction sub-device.

[0110] 3) Monitoring of request buffer full event: The valid req_valid flag of the request buffer being occupied in the master node of the design under test is extracted and connected to the virtual interface module. For example, if there are 8 items in the request buffer, the implementation method is the same as the implementation method of the data buffer full event, and will not be repeated here; whenever port_req_valid changes, the new monitoring information packet P12 is sent to the retry event prediction sub-device.

[0111] 4) Monitoring of the full listening buffer event: The valid snp_valid flag of the listening buffer being occupied in the master node of the design under test is extracted and connected to the virtual interface module. For example, if there are 8 items in the listening buffer, the implementation method is the same as the implementation method of the full data buffer event, and will not be repeated here; whenever port_snp_valid changes, the new monitoring information packet P13 is sent to the retry event prediction sub-device.

[0112] 5) Monitoring of internal processing queue full events: The valid queue_valid identifier of the internal processing queue being occupied in the master node of the design under test is extracted and connected to the virtual interface module. For example, if the internal processing queue has 16 items, the implementation method is the same as the implementation method of the data buffer full event, and will not be repeated here; whenever port_queue_valid changes, the new monitoring information packet P14 is sent to the retry event prediction sub-device.

[0113] 6) Monitoring of Address Locking Events: The address lock validity signal lock_valid and address lock value lock_addr in the master node of the design under test are extracted and connected to the virtual interface module. For example, in this embodiment, there is only one lock_valid and lock_addr in the master node of the design under test, which can only lock one address. They are connected to port_lock_valid and port_lock_addr in the virtual interface module, respectively. Then, port_lock_valid and port_lock_addr are packaged with retry event code 0x20 to generate monitoring information packet P20. Whenever port_lock_valid is valid and port_lock_addr changes, the new monitoring information packet P20 is sent to the retry event prediction sub-device.

[0114] 7) Monitoring of QoS Priority Conflict Events: The QoS values ​​(qos_value), execution addresses (run_addr), and retry_permit signals for all requests currently being executed in the master node of the design under test are extracted and connected to the virtual interface module. For example, in this embodiment, the internal processing queue has 16 items, which are connected to 16 groups of port_qos_value, port_run_addr, and port_retry_permit in the virtual interface module, respectively. Then, the 16 groups of port_qos_value, port_run_addr, and port_retry_permit are packaged with the retry event code 0x30 to generate a monitoring information packet P30. Whenever the signal in the group changes, the new monitoring information packet P30 is sent to the retry event prediction sub-device.

[0115] It should be noted that the retry_permit signal is designed to identify the time range during which a request in the process is allowed to be retried. If a higher-priority request with the same address enters during the retry_permit period, the current request can be retried to avoid the logical deadlock problem caused by low-priority transactions blocking high-priority transactions.

[0116] Thus, by using a hierarchical path referencing method for virtual interface modules, this invention can achieve real-time, lossless acquisition of all retry-related status signals within the master node without modifying the hardware logic of the design under test. This ensures complete consistency between the verification scenario and the actual operating scenario of the design under test, avoiding scenario distortion caused by modifying the design logic in gray-box verification.

[0117] In this embodiment of the invention, the retry event prediction sub-device 212 is used to receive a monitoring information packet and generate a retry prediction information packet when it is determined that the signal value in the monitoring information packet meets the preset triggering conditions.

[0118] The trigger condition is that the signal value in the monitoring information packet reaches a preset threshold.

[0119] For example, the retry event prediction sub-device is configured with independent trigger judgment logic and prediction rules for each type of retry event. For different types of retry events, a prediction algorithm adapted to its trigger mechanism is adopted to ensure the accuracy of retry prediction.

[0120] Specifically, the retry prediction information packet generated by the retry event prediction sub-device adopts a standardized format, the basic format of which is shown in Table 1 below:

[0121] Table 1

[0122]

[0123] Among them, the master node HNID is a unique identifier of the master node in the design under test, which is used to mark the source master node of the retry prediction information packet.

[0124] Specifically, for each type of event monitoring information packet, the retry event prediction sub-device sets a corresponding conversion threshold. Only when the signal value in the monitoring information packet meets the threshold condition is the monitoring information packet converted into a retry prediction information packet. The specific prediction implementation methods for various types of retry events are as follows:

[0125] 1) Request the prediction implementation of the credit exhaustion event:

[0126] Set the request credit exhaustion event threshold register req_credit_value, and its initial value is less than the request credit count value in the design under test; in this embodiment, the request credit count value of the design under test is 15, and the initial value of req_credit_value is set to 12.

[0127] The specific usage method is as follows: When the monitoring information packet P10 is received, first determine whether the retry event code is equal to 0x10. If they are equal, then read the port_req_credit_cnt value. Then, if port_req_credit_cnt is greater than or equal to req_credit_value, start generating retry prediction information.

[0128] In this embodiment, the retry event caused by the predicted credit exhaustion event will occur after 5 clock cycles. The prediction rule is as follows: calculate the current remaining credit_cnt quantity, and then add the transmission delay of the request node closest to the current master node's transmission path; for example, if the current port_req_credit_cnt is 12, the remaining credit_cnt quantity is 3, and the transmission delay of the request node closest to the current master node's transmission path is 2 clock cycles, add the two values ​​to obtain the retry prediction value credit_prediction of 5.

[0129] The credit_prediction is also used to delay the corresponding clock cycle, and to prevent the generation of retry prediction packets for credit exhaustion events within 5 clock cycles.

[0130] Finally, the retry prediction information packet content of the request credit exhaustion event is shown in Table 2 below (taking the master node HNID as 0x100 as an example):

[0131] Table 2

[0132]

[0133] Unused fields in the retry prediction information packet will be filled with 0x0.

[0134] If port_req_credit_cnt is less than req_credit_value, no processing will be performed, and monitoring information packet P10 will be discarded.

[0135] 2) Implementation of predicting data buffer full events:

[0136] Set the data buffer full event threshold register data_buffer_value, and its initial value is less than the total capacity of the data buffer in the design under test; in this embodiment, the total capacity of the data buffer in the design under test is 8, and the initial value of data_buffer_value is set to 6.

[0137] The specific usage method is as follows: When the monitoring information packet P11 is received, first determine whether the retry event code is equal to 0x11. If they are equal, then read port_data_valid. Then determine whether the number of valid port_data_valid is greater than or equal to data_buffer_value, and start generating retry prediction information.

[0138] In this embodiment, the retry event caused by the predicted full data buffer will occur after 6 clock cycles. The prediction rule is as follows: In the design under test, it takes 3 cycles from when a request enters the master node to when it is finally confirmed whether to use the data buffer. If the current number of valid port_data_valid is 6, it means that there are 2 data buffers remaining. Multiply the number of remaining data buffers by the clock cycles required for a single request to confirm the use of the data buffer to obtain the retry prediction value data_prediction of 6.

[0139] data_prediction is also used to delay the corresponding clock cycle, and to prevent the generation of retry prediction packets for data buffer full events within 6 clock cycles.

[0140] Finally, the retry prediction information packet for the data buffer full event is shown in Table 3 below:

[0141] Table 3

[0142]

[0143] If the number of valid port_data_valid entries is less than the data_buffer_value, no processing will be performed, and monitoring information packet P11 will be discarded.

[0144] 3) Implementation of predicting the request buffer full event:

[0145] Set the request buffer full event threshold register req_buffer_value, and its initial value is less than the total capacity of the request buffer in the design under test; in this embodiment, the total capacity of the request buffer of the design under test is 8, and the initial value of req_buffer_value is set to 6.

[0146] 4) Implementation of predicting events when the listening buffer is full:

[0147] Set the snp_buffer_value register to be the full event threshold register for the listening buffer. Its initial value is less than the total capacity of the listening buffer in the design under test. In this embodiment, the total capacity of the listening buffer in the design under test is 8, and the initial value of snp_buffer_value is set to 6.

[0148] 5) Implementation of internal queue full event prediction:

[0149] Set the internal processing queue full event threshold register req_queue_value, and its initial value is less than the number of internal processing queues in the design under test; in this embodiment, the internal processing queue of the design under test is 16, and the initial value of req_queue_value is set to 14.

[0150] It should be noted that the specific prediction implementation methods for the above-mentioned retry events 3), 4), and 5) are the same as those for the monitoring information packet P11, and will not be described here again.

[0151] 6) Implementation of predictive handling of address lock events:

[0152] Set the request address lock event control register lock_retry_control, with an initial value of 1; in this embodiment, when lock_retry_control is 1, the received monitoring information packet P20 is converted into a retry prediction information packet; when it is 0, no conversion is performed.

[0153] The specific usage method is as follows: When the monitoring information packet P20 is received, first determine whether the retry event code is equal to 0x20. If they are equal, then determine whether lock_retry_control is equal to 1. When lock_retry_control is equal to 1, then start generating retry prediction information.

[0154] In this embodiment, it is predicted that the retry event caused by the address lock request will occur after 3 clock cycles. The prediction rule is as follows: In the design under test, the transmission delay of the request node closest to the master node transmission path is 2 clock cycles, and it also needs to consume 1 clock cycle to judge the logic related to address lock. Therefore, it is predicted that a retry event can be generated after 3 clock cycles, and the retry prediction value lock_prediction is 3.

[0155] Similarly, lock_prediction is also used to delay the corresponding clock cycle, and no longer generate retry prediction packets for request address lock events within 3 clock cycles.

[0156] Finally, the retry prediction information packet content of the requested address locking event is shown in Table 4 below (taking the locked address as 0x5123 and the master node HNID as 0x100 as an example):

[0157] Table 4

[0158]

[0159] If the retry event code is 0x20, but lock_retry_control is 0, no further processing will be performed, and the monitoring information packet P20 will be discarded.

[0160] It should be noted that the unlocking time of a request address lock event is generally long or has a high degree of randomness. Therefore, as long as the predicted time is controlled within the range of the unlocking event, a retry event can be generated.

[0161] 7) Implementation of QoS priority conflict event prediction:

[0162] The QoS priority conflict event control register qos_retry_control is set with an initial value of 1. In this embodiment, when qos_retry_control is 1, the received monitoring information packet P30 is converted into a retry prediction information packet; when it is 0, no conversion is performed.

[0163] The specific usage method is as follows: When the monitoring information packet P30 is received, first determine whether the retry event code is equal to 0x30. If they are equal, then determine whether qos_retry_control is equal to 1. When qos_retry_control is equal to 1, then start generating retry prediction information.

[0164] In this embodiment, the monitoring information packet P30 contains 16 sets of port_qos_value, port_run_addr, and port_retry_permit information. First, the signal group with valid port_retry_permit and the smallest port_qos_value is selected from the 16 groups, such as the currently selected smallest QoS value of 0x8. Then, it is predicted that the retry event caused by the QoS priority conflict will occur after 5 clock cycles. The prediction rule is as follows: in the design under test, the transmission delay of the request node closest to the master node's transmission path is 2 clock cycles, the master node also needs to consume 1 clock cycle to judge QoS-related logic, and the request being executed needs to consume 2 clock cycles to perform resource release operations. Therefore, it is predicted that a retry event can be generated after 5 clock cycles, and the retry prediction value qos_prediction is 5.

[0165] Similarly, qos_prediction is also used to delay the corresponding clock cycle, and to prevent the generation of retry prediction packets for QoS priority conflict events within 5 clock cycles.

[0166] Finally, the retry prediction information packet content of the QoS priority conflict event is shown in Table 5 below (taking the master node HNID as 0x100 and the conflict address as 0x4998 as an example):

[0167] Table 5

[0168]

[0169] If the retry event code is 0x30 but qos_retry_control is 0, no further processing will be performed, and the monitoring information packet P30 will be discarded.

[0170] In this embodiment of the invention, the retry event sending sub-device 213 is used to select and send the retry prediction information packet with the highest priority to the central coprocessor 220 according to a preset sending priority rule when there are multiple retry prediction information packets to be sent at the same time.

[0171] For example, in this embodiment, a fixed sending priority is set for various retry events based on the degree of impact of retry events on system stability and the irreversibility of event triggering, so as to ensure that the most urgent and easily triggered retry events are processed by the central coprocessor first.

[0172] Specifically, the preset transmission priority rule is arranged from high to low priority according to the retry event encoding priority as follows: 0x10>0x11>0x12>0x13>0x14>0x20>0x30. When the retry event transmission sub-device 213 receives multiple retry prediction information packets of different types, it sends the retry prediction information packet with the highest priority according to the above priority order, and the retry prediction information packets with lower priority will be discarded.

[0173] Thus, by setting fixed priorities for different retry events, this invention avoids the congestion problem in the central co-processor caused by the simultaneous reporting of multiple retry prediction information packets, ensures the verification priority of core retry scenarios, and improves the pertinence and efficiency of verification.

[0174] Optionally, the retry event prediction sub-device 212 is further configured to discard monitoring information packets for the same retry event type within the time period corresponding to the retry prediction value after generating the retry prediction information packet.

[0175] For example, in this embodiment, for the same type of retry event, after generating a retry prediction information packet, the retry event prediction sub-device will enter a blocking period of corresponding duration. During the blocking period, the monitoring information packets of the same event will not be processed again to avoid repeated reporting.

[0176] Specifically, the duration of the blocking period is equal to the retry prediction value generated this time. For example, if the retry prediction value generated for the request credit exhaustion event is 5, then within 5 clock cycles after the retry prediction information packet is generated, the retry event prediction sub-device will discard all received monitoring information packets P10 corresponding to the request credit exhaustion event until the blocking period ends, at which point the monitoring and prediction processing of the event will be resumed.

[0177] Thus, by setting a masking period that matches the retry prediction value, the present invention avoids repeated prediction and reporting of the same retry event, reduces the computational overhead of the verification platform, and avoids incentive sending conflicts caused by repeated request policy issuance.

[0178] The following is combined with Figure 5 The verification method for the retry mechanism of this invention is described below. For the sake of consistency, the entity executing this method will be uniformly named "system" and will not be described further thereafter.

[0179] Figure 5 This is a flowchart illustrating the verification method of the retry mechanism provided in an embodiment of the present invention. Figure 5 As shown, the method includes the following steps:

[0180] S501. The master node monitoring device collects the operating status signals inside the master node of the design under test in real time, and generates retry prediction information packets based on the operating status signals.

[0181] In this embodiment of the invention, the master node monitoring device includes a retry event monitoring sub-device and a retry event prediction sub-device.

[0182] In some embodiments, the retry event monitoring sub-device can collect the operating status signals inside the master node it is bound to and generate a monitoring information packet containing the collected signal values.

[0183] For example, before performing verification, it is necessary to pre-classify and encode the events in the system that will trigger the retry mechanism according to the design under test description document and relevant bus protocol specifications. The specific classification and encoding can be referred to the relevant description of the retry event pre-configuration module in the above system embodiment, which will not be repeated here.

[0184] Specifically, by creating a new virtual interface module, relevant signals or signal groups that can identify corresponding events are extracted from the main node of the design under test in a hierarchical path reference manner and connected to the virtual interface module. The virtual interface module collects the operating status of the corresponding signals in real time. The collected signal status and the code of the corresponding retry event are packaged to generate a standardized monitoring information package. Whenever the collected signal changes, a new monitoring information package is generated and sent to the retry event prediction sub-device.

[0185] Furthermore, the retry event prediction sub-device receives monitoring information packets and generates retry prediction information packets when it determines that the signal value in the monitoring information packet meets the preset triggering conditions.

[0186] The trigger condition is that the signal value in the monitoring information packet reaches a preset threshold.

[0187] For example, for each type of retry event, corresponding trigger judgment conditions are pre-set, including the threshold register for the corresponding hardware resource occupation and the enable control register for the corresponding event. The retry prediction information packet is only generated when the signal value in the monitoring information packet meets the corresponding trigger conditions.

[0188] Specifically, the prediction and processing steps for each type of retry event are as follows:

[0189] 1) For the credit exhaustion event: Set a threshold register req_credit_value whose initial value is less than the credit count value of the design under test. When the corresponding monitoring information packet is received, determine whether the collected credit count value is greater than or equal to the threshold. If so, calculate the retry prediction value based on the remaining credit quantity and path transmission delay, and generate a retry prediction information packet.

[0190] 2) For data buffer full events: Set an initial value less than the total capacity of the data buffer of the design under test in the data_buffer_value register. When the corresponding monitoring information packet is received, determine whether the number of effectively occupied buffers is greater than or equal to the threshold. If so, calculate the retry prediction value based on the remaining number of buffers and the buffer confirmation period of a single request, and generate a retry prediction information packet.

[0191] 3) For events such as request buffer full, listener buffer full, and internal processing queue full: set corresponding threshold registers respectively, and handle them in the same way as the data buffer full event.

[0192] 4) For address lock request events: Set the corresponding enable control register lock_retry_control. When the enable is turned on and an address lock monitoring information packet is received, calculate the retry prediction value based on the path transmission delay and the judgment period of the address lock logic, and generate a retry prediction information packet carrying the lock address.

[0193] 5) For QoS priority conflict events: Set the corresponding enable control register qos_retry_control. When enabled and the corresponding monitoring information packet is received, filter out the transactions with the lowest QoS value that are allowed to be retried, calculate the retry prediction value based on the path transmission delay, QoS judgment period and resource release period, and generate a retry prediction information packet carrying the conflict address and low priority QoS value.

[0194] Specifically, after generating the retry prediction information packet, no more retry prediction information packets for the same retry event type will be generated within the clock cycle corresponding to the retry prediction value, so as to avoid duplicate reporting.

[0195] Thus, by real-time monitoring and threshold judgment of the internal state of the master node, the present invention realizes the early prediction of retry events, transforming the passive retry triggering in the prior art into active prediction and guidance, which greatly improves the triggering efficiency of retry events.

[0196] Optionally, the master node monitoring device may also include a retry event sending sub-device.

[0197] In some embodiments, when multiple retry prediction packets are generated simultaneously, the retry event sending sub-device selects and sends the retry prediction packet with the highest priority to the central coprocessor according to a preset sending priority rule.

[0198] For example, a fixed sending priority is pre-set for different types of retry events to ensure that core retry scenarios are processed first.

[0199] Specifically, the preset priority order is: request credit exhaustion event > data buffer full event > request buffer full event > listener buffer full event > internal processing queue full event > request address lock event > QoS priority conflict event, with the corresponding event codes having priority order of 0x10 > 0x11 > 0x12 > 0x13 > 0x14 > 0x20 > 0x30; when there are multiple retry prediction information packets to be sent at the same time, only the retry prediction information packet with the highest priority is sent, and the other low-priority packets are directly discarded.

[0200] In other embodiments, after generating the retry prediction information packet, the retry event prediction sub-device can also discard monitoring information packets for the same retry event type within the time period corresponding to the retry prediction value.

[0201] For example, for the same retry event type, after generating a retry prediction information packet, a corresponding blocking period is set to avoid repeated processing.

[0202] Specifically, the duration of the blocking period is equal to the retry prediction value generated this time. During the blocking period, the retry event prediction sub-device will discard all received monitoring information packets of the same retry event type until the blocking period ends, at which point monitoring and prediction of the event will resume.

[0203] Thus, by setting priority scheduling and masking periods, this invention avoids congestion and duplicate reporting of prediction packets, reduces the computational overhead of the verification platform, and improves the operational efficiency of verification.

[0204] S502: Receive the retry prediction information packet through the central coprocessor, calculate the request sending delay based on the retry prediction value in the retry prediction information packet, generate a request policy packet containing the request sending delay, and send the request policy packet.

[0205] In some embodiments, the request node proxy with the shortest routing distance to the source master node can be selected from the request node proxies as the target request node proxy.

[0206] For example, based on the network topology information of the design under test, the optimal request sending node is matched for each retry event to ensure that the request can reach the target master node as quickly as possible.

[0207] Specifically, from all request node proxies and core cache request node proxies, the request node proxies with the shortest routing distance to the source master node are selected as the target request node proxies to ensure minimal request transmission latency and improve triggering accuracy.

[0208] Furthermore, the request sending delay is calculated based on the retry prediction value and the path transmission delay from the target request node to the source master node.

[0209] For example, based on the retry prediction time point and the request transmission delay, the sending time of the request is accurately calculated to ensure that the request arrives at the master node at the retry trigger boundary.

[0210] Specifically, the formula for calculating the request sending delay can be found in the relevant description in the above system embodiment, and will not be repeated here.

[0211] Furthermore, a request strategy package containing the request sending delay is generated.

[0212] For example, for different types of retry events, request strategy package parameters that match their triggering mechanisms are generated to ensure that retry events can be triggered accurately.

[0213] Specifically, the generated request policy package contains at least the following parameters: Request Source ID (srcid): pointing to the ID number of the target request node proxy; Request Target ID (tgtid): pointing to the ID number of the master node from which the design under test originates; Request Command ID (opcode): selecting the corresponding type based on the retry event type; Request Address (addr): set to a random value or a specified address based on the retry event type; Request QoS: set to a random value or a specified priority based on the retry event type; Request Sending Delay (delay): a value calculated using the above formula.

[0214] Specifically, the parameter configuration rules for different retry event types are as follows:

[0215] 1) For events such as request credit exhaustion, request buffer full, and internal processing queue full: the request command identifier opcode is of random type, the request address addr is of random value, and the request QoS is of random value.

[0216] 2) For the data buffer full event: the request command identifier opcode is the request command type that needs to be transmitted, the request address addr is a random value, and the request QoS is a random value.

[0217] 3) For the full listening buffer event: the request command identifier opcode is the type of request command that can generate a listening request, the request address addr is a random value, and the request QoS is a random value.

[0218] 4) For the request address lock event: the request command identifier opcode is of random type, the request address addr is the same as the address information provided in the retry prediction information packet, and the request QoS is a random value.

[0219] 5) For QoS priority conflict events: the request command identifier opcode is of random type, the request address addr is of random value, and the requested QoS is the QoS value in the retry prediction packet plus 1.

[0220] Specifically, after generating the request policy package, it is sent to the selected target request node proxy.

[0221] Thus, this invention achieves precise triggering control for each type of retry event through global collaborative scheduling and differentiated strategy generation, covering all possible scenarios that may trigger retries and solving the problem of missing scenarios covered by existing technologies.

[0222] S503. Receive the request policy packet through the request node proxy, and send the request sequence to the design under test after the request sending delay, in accordance with the control of the request policy packet, to trigger the retry event.

[0223] In some embodiments, a request node agent that receives a request policy packet pauses the original random request sending policy and executes the control instructions in the policy packet; a request node agent that does not receive a request policy packet continues to operate according to the original request sending policy.

[0224] For example, the request node agent integrates the control parameters of the request strategy package into its own incentive generation logic to generate a request sequence that meets the requirements.

[0225] Specifically, the request node agent and the core cache request node agent add the content of the received request policy packet to the random constraints of the current request node agent to generate a new request sequence. After waiting for the clock cycle corresponding to the request sending delay, the new request sequence is sent to the corresponding port of the design under test. After the sending is completed, the request node agent switches back to the original request sending strategy and continues to perform normal random stress testing.

[0226] For example, the original sending strategy of the request node proxy is: the request command identifier opcode is random only in read type, and the values ​​of other fields are random; during operation, if a request strategy packet is received from the central coprocessor, the request proxy will precisely control the request source ID, request target ID, request command, request address, request QoS, and sending delay according to the requirements in the request strategy packet, generate a new request sequence that is different from the original sending strategy, and send it to the design under test after the specified delay. After the sending is completed, the original sending strategy is restored.

[0227] The retry mechanism verification method provided by this invention collects the internal operating status signals of the master node in real time through the master node monitoring device and generates a retry prediction information packet containing the retry event type and retry prediction value. This enables the prediction of the retry event and its occurrence time, changing the triggering from passive randomness to active prediction. The central coprocessor calculates the request sending delay based on the retry prediction value and generates a request strategy packet containing the delay. The predicted future time point is converted into precise sending time control parameters for the request node agent, completing the time-space scheduling connection from global prediction to local execution. The request node agent sends the request sequence after the request sending delay according to the control of the request strategy packet. Under the condition that the system state naturally approaches the retry boundary, the retry event is accurately induced to occur with normal incentives allowed by the protocol. This avoids gray-box operations that exceed the real scenario, thereby significantly improving the verification efficiency and scenario coverage of the retry mechanism while ensuring the authenticity of the verification scenario and the system-level coupling.

[0228] It should be noted that the detailed descriptions of the master node monitoring device, retry event monitoring sub-device, retry event prediction sub-device, retry event sending sub-device, central co-processor, and request node agent in the above method embodiments can be found in the relevant descriptions of the corresponding components in the above system embodiments, and will not be repeated here.

[0229] Figure 6 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 6 As shown, the electronic device may include: a processor 610, a communications interface 620, a memory 630, and a communications bus 640, wherein the processor 610, the communications interface 620, and the memory 630 communicate with each other through the communications bus 640.

[0230] The processor 610 can call logic instructions in the memory 630 to execute a verification method for the retry mechanism. This method includes: real-time acquisition of the operating status signals within the master node of the design under test (DUT) via a master node monitoring device, and generating a retry prediction information packet based on the operating status signals; the retry prediction information packet contains the type of retry event and a retry prediction value determined based on the operating status signals, whereby the retry prediction value indicates the future time of the predicted retry event; receiving the retry prediction information packet via a central coprocessor, calculating the request transmission delay based on the retry prediction value in the retry prediction information packet, generating a request policy packet containing the request transmission delay, and sending the request policy packet; receiving the request policy packet via a request node agent, and, according to the control of the request policy packet, sending a request sequence to the DUT after the request transmission delay to trigger a retry event.

[0231] Furthermore, the logical instructions in the aforementioned memory 630 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0232] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the verification method of the retry mechanism provided by the above methods. The method includes: acquiring the running status signal inside the master node of the design under test in real time through a master node monitoring device, and generating a retry prediction information packet based on the running status signal; the retry prediction information packet includes a retry event type and a retry prediction value determined based on the running status signal, and the retry prediction value is used to indicate the future time of the predicted retry event; receiving the retry prediction information packet through a central coprocessor, calculating the request sending delay based on the retry prediction value in the retry prediction information packet, generating a request policy packet containing the request sending delay, and sending the request policy packet; receiving the request policy packet through a request node agent, and sending a request sequence to the design under test after the request sending delay according to the control of the request policy packet to trigger a retry event.

[0233] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements a verification method for performing the retry mechanism provided by the above methods. This method includes: real-time acquisition of the operating status signal inside the master node of the design under test via a master node monitoring device, and generating a retry prediction information packet based on the operating status signal; the retry prediction information packet includes a retry event type and a retry prediction value determined based on the operating status signal, the retry prediction value indicating the future time of the predicted retry event; receiving the retry prediction information packet via a central coprocessor, calculating a request transmission delay based on the retry prediction value in the retry prediction information packet, generating a request policy packet containing the request transmission delay, and sending the request policy packet; receiving the request policy packet via a request node agent, and, according to the control of the request policy packet, sending a request sequence to the design under test after the request transmission delay to trigger a retry event.

[0234] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0235] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0236] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A verification system with a retry mechanism, applied to a design-under-test (DUT) verification scenario involving a multi-core processor interconnect bus protocol, characterized in that, The system includes: at least one master node monitoring device, a central coprocessor, and at least one request node agent; The master node monitoring device is bound to the master node in the design under test. It is used to collect the internal operating status signals of the master node in real time and generate a retry prediction information package based on the operating status signals. The retry prediction information package includes the type of retry event and the retry prediction value determined based on the operating status signals. The retry prediction value is used to indicate the future time of the predicted retry event. The central coprocessor is communicatively connected to the master node monitoring device and the request node agent, respectively, and is used to receive the retry prediction information packet, calculate the request sending delay based on the retry prediction value in the retry prediction information packet, and generate a request policy packet containing the request sending delay and send it to the request node agent. The request node proxy is bound to the request node in the design under test. When it receives the request policy package, it sends a request sequence to the request node it is bound to after the request sending delay, in accordance with the control of the request policy package, so as to trigger the retry event.

2. The system according to claim 1, characterized in that, The system also includes: The retry event pre-configuration module is used to provide various retry event types and their corresponding retry event codes; The master node monitoring device is also used to generate the retry prediction information packet based on the running status signal and the retry event code; The retry event types include resource restriction, address locking, and performance management types. Among them, the resource restriction retry event refers to the event triggered by the master node's internal hardware resource usage reaching a preset threshold; the address locking retry event refers to the event triggered by the address space pointed to by the access request being locked; and the performance management retry event refers to the event triggered by the conflict between transaction requests of different priorities, in order to ensure the service quality of high-priority transactions, and the low-priority transaction is retried.

3. The system according to claim 2, characterized in that, The master node monitoring device includes: a retry event monitoring sub-device, a retry event prediction sub-device, and a retry event sending sub-device; The retry event monitoring sub-device is used to collect the operating status signals inside the master node it is bound to, and generate a monitoring information packet containing the collected signal values. The retry event prediction sub-device is used to receive the monitoring information packet and generate the retry prediction information packet when it is determined that the signal value in the monitoring information packet meets a preset triggering condition; the triggering condition is that the signal value in the monitoring information packet reaches a preset threshold. The retry event prediction sub-device is also used to discard monitoring information packets for the same retry event type within the time period corresponding to the retry prediction value after generating the retry prediction information packet; The retry event sending sub-device is used to select and send the retry prediction information packet with the highest priority to the central co-processor when there are multiple retry prediction information packets to be sent at the same time, according to a preset sending priority rule.

4. The system according to claim 3, characterized in that, The retry event monitoring sub-device is specifically used for: By using a virtual interface module and a hierarchical path reference, internal signals or signal groups related to the retry event type within the master node to which it is bound are extracted to achieve the acquisition of the running status signals.

5. The system according to claim 1, characterized in that, The central coprocessor is specifically used for: Select the target request node agent from the request node agents; The request sending delay is calculated based on the retry prediction value and the path transmission delay from the target request node to the source master node. The rule for selecting the target request node proxy is to select the request node proxy with the shortest routing distance to the source master node.

6. The system according to claim 5, characterized in that, When the retry event type in the retry prediction information packet is a request address locking event, the request policy packet also contains the same request address as the address information carried in the retry prediction information packet. When the retry event type in the retry prediction packet is a QoS priority conflict event, the request policy packet also includes a request QoS value that is higher than the QoS value recorded in the retry prediction packet.

7. A verification method for a retry mechanism, applied to a design-under-test scenario involving a multi-core processor interconnect bus protocol, characterized in that, The method includes: The master node monitoring device collects the operating status signals inside the master node of the design under test in real time, and generates a retry prediction information packet based on the operating status signals. The retry prediction information packet contains the retry event type and retry prediction value determined based on the operating status signals. The retry prediction value is used to indicate the future time of the predicted retry event. The central coprocessor receives the retry prediction information packet, calculates the request sending delay based on the retry prediction value in the retry prediction information packet, generates a request policy packet containing the request sending delay, and sends the request policy packet. The request node agent receives the request policy packet and, under the control of the request policy packet, sends a request sequence to the design under test after the request sending delay to trigger the retry event.

8. The method according to claim 7, characterized in that, The master node monitoring device includes: a retry event monitoring sub-device and a retry event prediction sub-device; the method further includes: The retry event monitoring sub-device collects the operating status signals inside the master node it is bound to, and generates a monitoring information packet containing the collected signal values. The retry event prediction sub-device receives the monitoring information packet and generates the retry prediction information packet when it determines that the signal value in the monitoring information packet meets a preset trigger condition; the trigger condition is that the signal value in the monitoring information packet reaches a preset threshold.

9. The method according to claim 8, characterized in that, The master node monitoring device further includes a retry event sending sub-device; the method further includes: When multiple retry prediction information packets are generated simultaneously, the retry event sending sub-device selects and sends the retry prediction information packet with the highest priority to the central co-processor according to the preset sending priority rules. After generating the retry prediction information packet, the retry event prediction sub-device discards monitoring information packets for the same retry event type within the time period corresponding to the retry prediction value.

10. The method according to claim 7, characterized in that, The generation of the request strategy package containing the request sending delay includes: Select the request node proxy with the shortest route distance to the source master node from the request node proxies, and use it as the target request node proxy; The request sending delay is calculated based on the retry prediction value and the path transmission delay from the target request node to the source master node. Generate the request strategy packet that includes the request sending delay; Specifically, when the retry event type in the retry prediction information packet is a request address locking event, the request policy packet also contains the same request address as the address information carried in the retry prediction information packet; when the retry event type in the retry prediction information packet is a QoS priority conflict event, the request policy packet also contains a request QoS value that is higher than the QoS value recorded in the retry prediction information packet.

Images