Response timing control methods, apparatuses, media, and products for functional verification

Abstract

The application relates to the chip technical field and provides a response timing control method, equipment, medium and product for function verification. The method comprises the following steps: in the case that an access request is an atomic operation request, generating multiple pieces of first response data with a predetermined sequence and maintaining the predetermined sequence of the multiple pieces of first response data; in the case that the access request is a non-atomic operation request, generating second response data and performing out-of-order processing on the generated second response data; selecting target response data from the first response data with the maintained sequence or the second response data subjected to the out-of-order processing, and sending the target response data to a unit to be tested, so that the unit to be tested performs function verification. The application decouples the in-order logic and the out-of-order logic, thereby effectively avoiding the atomic operation verification error caused by the full out-of-order in the related art, and simultaneously solving the problems of single verification scene and low coverage rate caused by the fixed response mode.

Description

Technical Field

[0001] This invention relates to the field of chip technology, and in particular to a response timing control method, apparatus, medium, and product for functional verification. Background Technology

[0002] In multi-core processors, computational units (CUs) typically interact via network-on-chip (NoC) networks. In particular, the multiple return data segments generated by atomic operations experience varying latency in real networks, resulting in interleaved and out-of-order response data. To simulate this complex network behavior in verification environments, current verification methods typically employ either full out-of-order or fixed response interleaving patterns. However, full out-of-order processing fails to meet the refined requirements of "multiple returns from the same atomic request must be ordered" and "responses from different requests can be out of order," easily leading to logical errors; fixed patterns lack randomness and are difficult to simulate complex network interleaving scenarios. Summary of the Invention

[0003] This invention provides a response timing control method, device, medium, and product for functional verification, in order to address the deficiencies existing in related technologies.

[0004] This invention provides a response timing control method for functional verification, comprising the following steps: Receive access requests from the unit under test; In the case that the access request is an atomic operation request, multiple first response data with a predetermined order are generated, and the predetermined order of the multiple first response data is maintained; If the access request is a non-atomic operation request, a second response data is generated, and the generated second response data is processed out of order. Select target response data from the first response data that has been ordered or the second response data that has been out of order, and send the target response data to the unit under test for functional verification.

[0005] According to a response timing control method for functional verification provided by the present invention, the step of selecting target response data from either first response data that has been ordered or second response data that has been out of order includes: Based on a preset scheduling strategy, a target queue is determined from the queue corresponding to the first response data or the queue corresponding to the second response data, and the target response data is extracted from the target queue.

[0006] According to a response timing control method for functional verification provided by the present invention, when the preset scheduling strategy is an instruction type priority strategy, the step of determining the target queue from the queue corresponding to the first response data or the queue corresponding to the second response data includes: If the waiting period of the queue corresponding to the second response data exceeds a preset threshold, the priority of the queue corresponding to the second response data is increased so that the queue of the second response data is preferentially selected as the target queue. If the waiting period does not exceed the preset threshold and the queue corresponding to the first response data is not empty, the queue corresponding to the first response data is selected as the target queue.

[0007] According to the present invention, a response timing control method for functional verification, wherein determining a target queue from the queue corresponding to the first response data or the queue corresponding to the second response data based on a preset scheduling strategy includes: When the preset scheduling strategy is the source unit weight strategy, the target queue is determined from the queue corresponding to the first response data or the queue corresponding to the second response data according to the weight of the source unit corresponding to the first response data and the weight of the source unit corresponding to the second response data. When the preset scheduling strategy is a round-robin strategy, the corresponding queue is selected from the queue corresponding to the first response data or the queue corresponding to the second response data as the target queue according to the order of the response source identifiers corresponding to the first response data and the order of the response source identifiers corresponding to the second response data. When the preset scheduling strategy is a random strategy, a non-empty queue is randomly selected from the queue corresponding to the first response data or the queue corresponding to the second response data as the target queue.

[0008] According to a response timing control method for functional verification provided by the present invention, the generation of multiple first response data with a predetermined order includes: Parse the atomic operation request to determine the target address sequence containing multiple consecutive addresses; For each target address in the target address sequence, the following data acquisition steps are executed sequentially: if there is no historical data for the corresponding target address in the shared memory, data is randomly generated as the response data for the corresponding target address and written into the shared memory; if there is historical data for the corresponding target address in the shared memory, the historical data is read from the shared memory as the response data for the corresponding target address. The response data corresponding to all target addresses in the target address sequence are combined in ascending order of the target address sequence to generate multiple first response data in a predetermined order.

[0009] According to a response timing control method for functional verification provided by the present invention, the step of receiving an access request from a unit under test includes: Obtain the request source identifier, transaction identifier, and address offset information corresponding to the access request; The request source identifier, the transaction identifier, and the address offset information are combined to generate a unique mapping address, which is used as an index to search for or write response data in shared memory.

[0010] According to a response timing control method for functional verification provided by the present invention, the step of performing out-of-order processing on the generated second response data includes: Identify the request source identifier corresponding to the non-atomic operation request; Determine the queue corresponding to the second response data associated with the request source identifier; The generated second response data is stored in the queue corresponding to the second response data; A random position swap operation is performed on the data elements stored in the queue corresponding to the second response data so that the output order of the second response data is inconsistent with the generation order.

[0011] According to a response timing control method for functional verification provided by the present invention, the process of sending the target response data to the unit under test further includes: The target response data is sent to a reference model so that the reference model outputs a standard result consistent with the expected behavior of the unit under test based on the target response data. In this configuration, the shared memory is set up so that for the same access address, the generation and writing of response data are triggered by the first visitor in the unit under test and the reference model, and the response data written is read by the subsequent visitor.

[0012] The present invention also provides a response timing control device for functional verification, comprising the following modules: The receiving module is used to receive access requests from the unit under test. A processing module is configured to, when the access request is an atomic operation request, generate multiple first response data in a predetermined order and maintain the predetermined order of the multiple first response data; If the access request is a non-atomic operation request, a second response data is generated, and the generated second response data is processed out of order. The sending module is configured to select target response data from the first response data that has been ordered or the second response data that has been out of order, and send the target response data to the unit under test for functional verification.

[0013] 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, when executing the program, implements the response timing control method for functional verification as described above.

[0014] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the response timing control method for functional verification as described above.

[0015] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the response timing control method for functional verification as described above.

[0016] The present invention provides a response timing control method, device, medium, and product for functional verification. This method receives access requests from the unit under test (DUT) and performs differentiated processing based on the request type. Specifically, it forces the response data generated from atomic operation requests to maintain a predetermined order, while performing out-of-order processing on the response data generated from non-atomic operation requests. Finally, it dynamically selects target response data from either the first response data that has maintained the order or the second response data that has undergone out-of-order processing and sends it to the DUT. Because the present invention decouples the order-preserving logic from the out-of-order logic, it effectively avoids atomic operation verification errors caused by complete out-of-order processing in related technologies. It also solves the problems of limited verification scenarios and low coverage caused by fixed response patterns, significantly improving the accuracy and completeness of multi-core processor hardware verification. Attached Figure Description

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

[0018] Figure 1 This is a flowchart illustrating the response timing control method for functional verification provided by the present invention.

[0019] Figure 2 This is a schematic diagram of the sorting process provided by the present invention.

[0020] Figure 3This is a schematic diagram of the interleaving process provided in an embodiment of the present invention.

[0021] Figure 4 This is a flowchart illustrating the order-preserving and out-of-order processing provided by the present invention.

[0022] Figure 5 This is a schematic diagram of the response control framework provided by the present invention.

[0023] Figure 6 This is a block diagram of the CU cluster system provided by the present invention.

[0024] Figure 7 This is a schematic diagram of the response timing control device for functional verification provided by the present invention.

[0025] Figure 8 This is a schematic diagram of the structure of the electronic device provided by the present invention.

[0026] Figure label: 710: Receiver module; 720: Processing module; 730: Transmitter module; 810: Processor; 820: Communication interface; 830: Memory; 840: Communication bus. Detailed Implementation

[0027] 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.

[0028] In modern multi-core processors, a single core (CU) typically needs to interact with other remote CUs via NoC (NoC). Especially for atomic operations, the resulting return data may be segmented. These multi-source, multi-type responses experience varying latency in real-world network transmission, resulting in interleaved and out-of-order responses returned to the requesting sender. Accurately simulating this complex network behavior is crucial for hardware verification.

[0029] To simulate this behavior in a verification environment, relevant technical solutions typically employ two approaches: one is to perform full out-of-order processing, and the other is to use a fixed response interleaving mode, such as supporting only random strategies or having no interleaving functionality. However, full out-of-order processing cannot distinguish between the refined requirements of "multiple responses from the same atomic request must be in order" and "responses from different requests can be out of order," easily leading to logical errors caused by violating atomicity. Fixed response interleaving modes result in limited response interleaving processing capabilities and a lack of effective mechanisms to simulate network response interleaving behavior under different verification scenarios. Furthermore, relevant solutions often lack clear functional layering, leading to poor code readability and difficulty in expansion and maintenance.

[0030] To address this, the present invention provides a response timing control method for functional verification. This method aims to receive access requests from the unit under test (DUT), maintain the order of multiple first response data points generated by atomic operation requests (which have a predetermined order), and process the second response data generated by non-atomic operation requests (which have an out-of-order order). It then dynamically selects target response data from either the first response data with the maintained order or the second response data with the out-of-order order and sends it to the DUT. This approach ensures data consistency for atomic operations while flexibly simulating the complex interleaving scenarios of random out-of-order and multi-type responses in non-atomic operations, thereby effectively improving the coverage and accuracy of the verification environment.

[0031] in, Figure 1 This is a flowchart illustrating the response timing control method for functional verification provided by the present invention, as shown below. Figure 1 As shown, the method includes steps 110, 120 and 130.

[0032] Step 110: Receive the access request from the unit under test.

[0033] Here, the unit under test (DUT) can be understood as the computing unit currently undergoing functional verification. In modern multi-core processor architectures, the DUT needs to interact with other remote CPUs via an on-chip network.

[0034] Access requests are used to characterize instructions issued by the unit under test (DUT) to acquire or write data. For example, the DUT may send access requests via multicast to one or more remote control units (CUs), or it may send point-to-point unicast access requests. As an alternative embodiment, access requests can be acquired by listening to interface signals between the DUT and the on-chip network.

[0035] Since the unit under test may send multiple access requests within the same time period, after receiving multiple access requests, these requests can be parsed and cached so that corresponding response data can be generated according to the request type and destination address.

[0036] Step 120: If the access request is an atomic operation request, generate multiple first response data in a predetermined order and maintain the predetermined order of the multiple first response data; if the access request is a non-atomic operation request, generate second response data and perform out-of-order processing on the generated second response data.

[0037] Considering that different types of access requests have different protocol constraints and transmission characteristics in a real network environment, this embodiment adopts differentiated processing strategies for different types of access requests in order to accurately simulate this behavior.

[0038] First, atomic operation requests typically involve data integrity and consistency constraints. An atomic operation request can be understood as an operation instruction that cannot be interrupted or divided during execution. For example, an atomic operation request usually produces multiple returned data entries, which logically belong to the same transaction.

[0039] Considering that atomic operation requests typically require operations on a contiguous range of memory addresses, the protocol stipulates that the data returned from these contiguous addresses must be returned to the requester in ascending order of address. If the order is disordered, the internal logic of the unit under test will be unable to correctly reassemble the data, leading to serious functional errors. Therefore, this embodiment generates multiple first response data entries with a predetermined order and maintains this predetermined order. The first response data can be understood as multiple consecutive data packets returned in response to the atomic operation request. For example, for the atomic operation request "read 64 bytes of data starting at address 0x1000", the corresponding first response data could be four 16-byte data entries corresponding to addresses 0x1000, 0x1010, 0x1020, and 0x1030.

[0040] Maintaining the predetermined order of multiple first response data means that the multiple first response data must be arranged strictly according to a specific logical order, and cannot be out of order. If the order is broken, it will violate the protocol of atomic operation, resulting in the failure of functional verification. Therefore, for the first response data, this embodiment performs an order-preserving operation, such as managing it according to the principle of first-in-first-out (FIFO).

[0041] As an optional embodiment, the corresponding data can be generated sequentially by parsing the address range of the atomic operation request, generating first response data, and storing this data in a dedicated atomic response queue in the order of generation to maintain the predetermined order of multiple first response data.

[0042] Furthermore, non-atomic operation requests can be understood as instructions other than atomic operations, such as download instructions, storage instructions, etc. Considering that during network transmission of non-atomic operation requests, due to different routing paths and varying network congestion levels, the arrival order of responses from different sources or to different addresses is often unpredictable, and protocols typically allow such responses to arrive out of order. Therefore, this embodiment generates second response data for non-atomic operation requests and performs out-of-order processing on the generated second response data. The second response data can be understood as read data or write confirmation responses returned for ordinary read / write requests. For example, for a non-atomic operation request "write operation request," the corresponding second response data could be a confirmation response indicating the completion of the write operation. As an optional embodiment, a corresponding response can be generated for each non-atomic request, generating second response data. After these response data are placed in a buffer queue, random position swapping or random extraction operations are performed, and the generated second response data is processed to be out of order.

[0043] Figure 2 This is a schematic diagram of the sorting process provided by the present invention, such as... Figure 2 As shown, firstly, the response data is obtained, and the request type corresponding to the response data is determined. If it is an atomic operation request, the response data is marked as 0; if it is a non-atomic operation request, the response data is marked as 1.

[0044] Next, obtain the response source identifier corresponding to the response data, and determine the queue corresponding to the response data based on the response data identifier and the response source identifier, that is, determine the queue corresponding to the first response data and the queue corresponding to the second response data.

[0045] Step 130: Select target response data from the first response data that has been maintained in order or the second response data that has been processed out of order, and send the target response data to the unit under test for functional verification.

[0046] After generating and initially processing the response data, the verification environment typically maintains multiple response queues to be sent, such as at least one queue storing the first response data and one queue storing the second response data. The target response data refers to the response data currently selected for scheduling and about to be sent to the unit under test.

[0047] In scenarios where priority must be given to ensuring the completion of atomic operations, considering that atomic operations typically have high priority or to prevent data backlog, atomic responses need to be sent first. Therefore, the target response data is selected from the first response data. Specifically, if the first response data queue is not empty, data can be directly extracted from the head of the queue, and the target response data is selected from the first response data.

[0048] In scenarios requiring simulation of network randomness or where ordinary responses have been backlogged for too long, considering the diversity of verification scenarios and to prevent non-atomic responses from being starved for an extended period, it is necessary to send non-atomic responses. Therefore, target response data is selected from the second response data. Specifically, data can be extracted from the second response data queue according to a random or weighted strategy, and the target response data is then selected from the second response data.

[0049] In other words, the selection of target response data is a dynamic scheduling process. It can switch between queues corresponding to different types of response data according to preset strategies (such as priority, round-robin, random, etc.) to determine the target response data.

[0050] After receiving the target response data, the unit under test (DUT) needs to receive it to complete the instruction execution process and verify its logical correctness. Therefore, the target response data needs to be sent to the DUT for functional verification. This can be done by driving the DUT's bus interface. The DUT can receive the target response data and compare it with its internal expected results, or update its internal state based on the target response data to perform functional correctness checks, such as data consistency checks and protocol timing checks.

[0051] The response timing control method for functional verification provided in this embodiment receives access requests from the unit under test (DUT) and performs differentiated processing based on the request type. Specifically, it forces the response data generated from atomic operation requests to maintain a predetermined order, while performing out-of-order processing on the response data generated from non-atomic operation requests. Finally, it dynamically selects target response data from either the first response data that has maintained order or the second response data that has undergone out-of-order processing and sends it to the DUT. Because this embodiment decouples the order-preserving logic from the out-of-order logic, it effectively avoids atomic operation verification errors caused by complete out-of-order processing in related technologies. It also solves the problems of limited verification scenarios and low coverage caused by fixed response patterns, significantly improving the accuracy and completeness of multi-core processor hardware verification.

[0052] Based on the above embodiments, selecting target response data from first response data that has been ordered or second response data that has been out of order includes: Based on a preset scheduling strategy, the target queue is determined from the queue corresponding to the first response data or the queue corresponding to the second response data, and the target response data is extracted from the target queue.

[0053] In real-world verification scenarios, the data streams transmitted in NoCs are highly complex. Different types of response data arrive at the unit under test (DUT) with varying probabilities and orders, depending on factors such as network congestion and routing strategies. To realistically simulate this complex network interleaving behavior, the verification environment cannot simply send one type of data before sending another; instead, it requires an intelligent scheduling mechanism to dynamically determine what data to send next.

[0054] Based on this, this embodiment selects the target queue based on a preset scheduling strategy. The preset scheduling strategy can be understood as an arbitration algorithm configured by the verification personnel according to the testing requirements, used to determine the service order between different queues. For example, this strategy can be a priority strategy, a weighted strategy, a round-robin strategy, or a random strategy, etc.

[0055] The queue corresponding to the first response data is a buffer structure specifically used to store and maintain the order of atomic operation responses. The queue corresponding to the second response data is a buffer structure specifically used to store non-atomic operation responses that have undergone out-of-order processing. The target queue is the queue that is selected and has the right to send in the current scheduling cycle.

[0056] As an optional implementation, the verification environment can maintain a policy pool and select a policy before the simulation begins via a configuration file or parameter settings. At each clock cycle or transmission slot, the scheduler reads the policy and calculates which queue should be served. For example, if the policy is configured as "random," the scheduler generates a random number; if the random number points to the queue corresponding to the second response data, and that queue is not empty, then it is determined as the target queue.

[0057] After identifying the target queue, in order to complete the final data transmission, it is necessary to extract the target response data from the target queue. This extraction can be understood as the operation of reading data from the head of the queue and removing that data from the queue.

[0058] Through the above extraction steps, not only is the physical transmission of data achieved, but the status of the queue is also updated, such as the remaining space in the queue increases, making room for the generation and storage of new data in the future, and ensuring the smooth operation of the entire verification system pipeline.

[0059] As an optional embodiment, when the target queue is determined to be the queue corresponding to the first response data, the scheduler can send a read enable signal to the queue, and the queue will then output the first piece of data stored at the head of the queue as the target response data and send it to the driver layer, and then to the unit under test.

[0060] Based on any of the above embodiments, when the preset scheduling strategy is an instruction type priority strategy, determining the target queue from the queue corresponding to the first response data or the queue corresponding to the second response data includes: If the waiting period of the queue corresponding to the second response data exceeds a preset threshold, the priority of the queue corresponding to the second response data is increased so that the queue of the second response data is selected as the target queue. If the waiting period does not exceed the preset threshold and the queue corresponding to the first response data is not empty, the queue corresponding to the first response data is selected as the target queue.

[0061] Considering that in real-world processor operation scenarios, atomic operations typically correspond to locking or synchronization operations on shared data structures, prolonged blocking of atomic operation responses can lead to system lockouts or severe performance degradation. Therefore, atomic operations should be given high priority by default. However, simply prioritizing atomic operations might result in non-atomic operation responses remaining unserved for extended periods, causing starvation and impacting the fairness and coverage of verification. To balance these two factors, this embodiment introduces an instruction type priority strategy with an anti-starvation mechanism.

[0062] First, if the waiting period of the queue corresponding to the second response data exceeds a preset threshold, the priority of the queue corresponding to the second response data is increased so that the queue of the second response data is selected as the target queue.

[0063] This step is performed because simple static priority scheduling can easily lead to low-priority queues (i.e., the queue corresponding to the second response data) being indefinitely delayed when the network is under high load. By monitoring the waiting period and dynamically increasing the priority, the anti-starvation mechanism in the network controller can be simulated to ensure that all types of requests eventually receive a response.

[0064] The queue corresponding to the second response data refers to the queue that stores non-atomic operation responses. The waiting period can be understood as the number of clock cycles that the data at the head of the queue is ready to be sent but remains in the queue because it has not been selected by the scheduler, or it can refer to the time span since the queue was last served. The preset threshold can be a user-configured time parameter, which can be set to 1000 cycles. Increasing the priority of the queue corresponding to the second response data can mean temporarily changing the scheduling weight, forcing the scheduler to select that queue in the next time step.

[0065] As an optional implementation, the verification environment can maintain a counter for the queue corresponding to the second response data. The counter increments whenever the queue is not empty but not selected; it is reset to zero once the queue is selected for transmission. When the counter value exceeds a preset threshold (e.g., 1000), anti-starvation logic is triggered, temporarily adjusting the priority of the queue to the highest level, even higher than the atomic operation queue. This ensures that the queue containing the second response data is preferentially selected as the target queue until one or more data packets are sent.

[0066] Secondly, if the waiting period does not exceed the preset threshold and the queue corresponding to the first response data is not empty, the queue corresponding to the first response data is selected as the target queue.

[0067] This step is performed to implement the design principle of prioritizing atomic operations. Under normal conditions, where the anti-starvation mechanism is not triggered (i.e., the waiting time for ordinary responses is still acceptable), time-sensitive atomic operations are usually processed first to simulate the tendency of real hardware to process atomic transactions quickly.

[0068] The queue corresponding to the first response data is the queue that stores the responses to atomic operations. A non-empty queue indicates that there is currently valid data to be sent in the queue.

[0069] As an optional implementation, the scheduler makes a judgment in each clock cycle: first, it checks whether the aforementioned waiting period exceeds a preset threshold; if it does not exceed the preset threshold, it checks the status signal of the queue corresponding to the first response data. If the status signal shows that it is not empty, the scheduler directly ignores other low-priority queues, locks the queue corresponding to the first response data, selects it as the target queue, and extracts data from it for transmission.

[0070] Furthermore, considering that in real multi-core processor systems, different computing units have different network bandwidth requirements, and network arbitration mechanisms are complex and diverse, the verification environment needs to support multiple flexible scheduling strategies to more comprehensively cover various network traffic models. Based on this, this embodiment provides specific implementation methods for different strategies in the step of determining the target queue based on a preset scheduling strategy.

[0071] Based on any of the above embodiments, determining the target queue from the queue corresponding to the first response data or the queue corresponding to the second response data based on a preset scheduling strategy includes: When the preset scheduling strategy is the source unit weight strategy, the target queue is determined from the queue corresponding to the first response data or the queue corresponding to the second response data according to the weight of the source unit corresponding to the first response data and the weight of the source unit corresponding to the second response data. When the preset scheduling strategy is a round-robin strategy, the corresponding queue is selected as the target queue from the queue corresponding to the first response data or the queue corresponding to the second response data, according to the order of the response source identifiers corresponding to the first response data and the order of the response source identifiers corresponding to the second response data. When the preset scheduling strategy is a random strategy, a non-empty queue is randomly selected from the queue corresponding to the first response data or the queue corresponding to the second response data as the target queue.

[0072] Considering that in certain verification scenarios, it is necessary to simulate situations where certain specific computing units generate high-density traffic while other units generate low-density traffic, in order to verify the processing capability of the unit under test under non-uniform traffic pressure, this embodiment determines the target queue from the queue corresponding to the first response data or the queue corresponding to the second response data based on the weight of the source unit corresponding to the first response data and the weight of the source unit corresponding to the second response data.

[0073] Here, the weights of the source units corresponding to the first and second response data can be understood as the probability values ​​or proportional coefficients of selection for different response source identifier configurations. The source unit is the unit that sends the response data.

[0074] This weight-based scheduling allows for precise control over the transmission frequency of response data from different senders, thereby creating stress test scenarios that conform to specific traffic distributions.

[0075] As an optional implementation, the verification environment can maintain a weight counter or a probability table. Assume there are source units CU0 and CU1, configured with a weight ratio of 3:1. CU0 is the source unit corresponding to the first response data, and CU1 is the source unit corresponding to the second response data. When selecting, the scheduler generates a random number between 0 and 100. If the random number is between 0 and 75, it tends to select the queue corresponding to CU0 (which could be the queue corresponding to the first or second response data); if it is between 76 and 100, it tends to select the queue corresponding to CU1. Alternatively, the scheduler serves the queue of CU0 three times, and then serves the queue of CU1 once.

[0076] Considering scenarios requiring verification of system fairness or ensuring timely responses to all source unit requests, it's necessary to avoid prolonged bus occupancy by responses from certain source units. Therefore, with the preset scheduling strategy being a round-robin strategy, the target queue is selected from either the queue corresponding to the first response data or the queue corresponding to the second response data, based on the order of the response source identifiers corresponding to the first and second response data.

[0077] Here, the round-robin strategy refers to a scheduling algorithm that serves each queue in a fixed order. The order of the response source identifiers refers to the arrangement order of the source units, such as CU0→CU1→CU2.

[0078] By using a polling strategy, it can be ensured that the response queue of each source unit has a chance to be selected, thereby verifying the functional correctness of the unit under test when receiving uniformly interleaved traffic and preventing verification dead zones caused by starvation of some queues.

[0079] As an optional implementation, the scheduler can maintain a pointer that records which request source identifier corresponds to the queue in the last service. During the current scheduling, the pointer automatically points to the next logical position. If the queue is not empty, it is identified as the target queue; if it is empty, it is skipped and continues to point to the next one until a non-empty queue is found.

[0080] Given the highly unpredictable nature of congestion and latency in real-world networks, complete randomness needs to be introduced to cover as many unpredictable extreme timing combinations as possible. Therefore, with the preset scheduling strategy being random, a non-empty queue is randomly selected as the target queue from either the queue corresponding to the first response data or the queue corresponding to the second response data.

[0081] Here, the random strategy refers to selecting queues purely based on random probability, without relying on priority, weight, or order. A non-empty queue is one that currently stores response data to be sent. Selecting a non-empty queue is to avoid ineffective scheduling and improve bus utilization.

[0082] As an optional implementation, the scheduler can first scan all queues corresponding to the first response data and the queues corresponding to the second response data to generate a list containing all non-empty queue IDs. Then, it uses a random number generator to randomly select an ID from this list and determines the queue corresponding to that ID as the target queue. For example, it first randomly decides whether to send the first or second response data, and then randomly selects a queue of a source unit within the selected type.

[0083] Figure 3 This is a schematic diagram of the interleaving process provided in an embodiment of the present invention, such as... Figure 3 As shown, firstly, based on the user-configured preset scheduling strategy, the strategy decision engine selects a specific strategy execution logic from the strategy pool.

[0084] If strategy A (instruction type priority strategy) is selected, when the queue corresponding to the first response data and the queues corresponding to other types of responses are not empty, scheduling is performed according to atomic operation priority, and the queue corresponding to the first response data is selected as the target queue. If the queue corresponding to the first response data is empty, when scheduling other types of responses, a queue is randomly selected from the queues corresponding to the available source units.

[0085] If strategy B (source unit weight strategy) is selected, the selection is made according to the weight probability of each source unit configured by the user. First, the queue set corresponding to a certain source unit is selected according to the weight probability, and then the instruction response type is randomly selected within the set, such as randomly selecting the queue corresponding to the first or second response data.

[0086] If strategy C (polling strategy) is selected, the system will poll according to the response type and source unit number, and select the corresponding queue in turn.

[0087] If strategy D (random strategy) is selected, the response type is first randomly selected, such as randomly selecting the first response data or the second response data, and then the source unit is randomly selected from the randomly selected response data to determine the target queue.

[0088] Then, the scheduling execution module extracts the target response data from the selected target queues. Next, the status update module performs the following operations: For strategy C, it records the "queue served last time" according to the index to update the queue position for the next service; for strategy A, although the first response data is prioritized in principle, if the queue corresponding to the second response data is waiting for more than a preset threshold, its priority needs to be increased. Therefore, it is necessary to record a waiting counter for these two types of response data and update it after each scheduling execution to prevent starvation of low-priority queues.

[0089] During hardware verification, especially for atomic operations involving cache or memory consistency, it is crucial to ensure that the data read by the unit under test (DUT) and the reference model is consistent. If data is generated completely randomly for each request without recording historical states, the DUT and the reference model may obtain different data when accessing the same address, leading to comparison failures and making it impossible to determine whether the issue stems from a design flaw or a verification environment problem.

[0090] Based on this, in order to ensure that the response data returned to the unit under test and the reference model are consistent and to meet the timing requirements of the atomic operation protocol, this embodiment adopts the following scheme to generate multiple first response data with a predetermined order.

[0091] Specifically, in this embodiment, generating multiple first response data entries in a predetermined order includes: Parse atomic operation requests to determine the target address sequence containing multiple consecutive addresses; For each target address in the target address sequence, the following data acquisition steps are executed sequentially: if there is no historical data for the corresponding target address in the shared memory, randomly generate data as the response data for the corresponding target address and write it into the shared memory; if there is historical data for the corresponding target address in the shared memory, read the historical data from the shared memory as the response data for the corresponding target address. The response data corresponding to all target addresses in the target address sequence are combined in ascending order of the target address sequence to generate multiple first response data in a predetermined order.

[0092] Specifically, an atomic operation request typically carries information about the starting address and the operation length or data size. The target address sequence refers to the set of all memory addresses that the atomic operation will access, which are physically or logically contiguous.

[0093] For example, if the unit under test initiates an atomic operation request for address 0x2000, with a data width of 64 bytes and a bus width of 16 bytes, then the request actually needs to access four consecutive addresses: 0x2000, 0x2010, 0x2020, and 0x2030.

[0094] As an optional embodiment, the starting address and the number of transmissions can be calculated by parsing the control field in the atomic operation request using a decoder, and then the target address sequence containing multiple consecutive addresses can be derived.

[0095] To achieve data consistency between the unit under test (DUT) and the reference model, this embodiment introduces a shared memory mechanism. This shared memory is used to maintain the global data state in the verification environment. The reference model can be understood as a standard model (often called a Golden Model) used to simulate the expected logical behavior of the DUT. It generates standard results that should be consistent with the DUT under the same input stimulus, allowing the functional correctness of the DUT to be verified by comparing its actual output with the standard output of the reference model. Historical data corresponding to a target address refers to data that has been previously generated and stored for that target address. If no historical data for the target address exists in shared memory, it means that the target address is being accessed for the first time. In this case, to simulate a real random data environment, randomly generated data is written to shared memory for archiving, so that subsequent visitors can read the same data.

[0096] If historical data for the target address exists in the shared memory, it means that the target address has been accessed before. In order to ensure consistency, the historical data is directly read as the response data for the target address.

[0097] Furthermore, considering that the return data of atomic operation requests typically has strict order preservation requirements in the transmission protocol, meaning it must be transmitted sequentially from low to high address, and cannot be out of order, if the acquired data segments are returned in shuffled order, the unit under test will be unable to correctly reassemble the data, leading to functional verification errors. Therefore, this embodiment, after acquiring data from all target addresses, combines them according to the ascending address order of the target address sequence to generate multiple first response data segments with a predetermined order. Here, combining them according to the ascending address order of the target address sequence means strictly arranging the response data from each target address into an ordered response data stream according to their corresponding address order.

[0098] As an optional embodiment, the data obtained for each target address can be sequentially pushed into a first-in-first-out (FIFO) queue or list to ensure that the lower address data obtained first is at the head of the queue, thereby forming multiple first response data with a predetermined order.

[0099] This embodiment achieves cross-model data consistency maintenance by parsing the continuous address characteristics of atomic operations and combining them with the historical data checking mechanism of shared memory. Furthermore, by combining data in ascending address order, it ensures that the atomic operation response strictly conforms to the protocol's ordering requirements.

[0100] Considering that in a multi-core processor verification environment, the unit under test (DUT) and the reference model typically run in parallel, a mechanism is needed to ensure that accesses to the same logical address retrieve the same data in order to guarantee that the random data received by both is consistent for subsequent data comparison and verification. Furthermore, in on-chip networks, different computing units may initiate access simultaneously. To avoid address conflicts and accurately distinguish data sources, this embodiment further refines and limits the step of "receiving access requests from the DUT." Specifically, receiving access requests from the DUT includes: Obtain the request source identifier, transaction identifier, and address offset information corresponding to the access request; The request source identifier, transaction identifier, and address offset information are combined to generate a unique mapping address, which is used as an index to look up or write response data in shared memory.

[0101] Considering that multiple devices in a multi-core system may simultaneously initiate access requests, and each device may issue multiple transactions concurrently, key feature information that can distinguish these accesses needs to be extracted to uniquely identify each specific data access in the network. Based on this, this embodiment obtains the request source identifier, transaction identifier, and address offset information corresponding to the access request.

[0102] Here, the request source identifier can be understood as the unique number of the source unit that initiated the access request. The transaction identifier can be understood as the label of a specific instruction issued by the computing unit. The address offset information can be understood as the offset of the access address relative to the base address, or the low-order part of the address.

[0103] As an optional embodiment, the request source identifier, transaction identifier, and address offset information can be extracted by parsing the bus protocol packet header sent by the unit under test.

[0104] Considering that shared memory in a verification environment is typically a large storage space, directly using physical addresses for mapping may lead to memory waste due to excessive address space or data inconsistency between the unit under test and the reference model due to random address conflicts. By combining the aforementioned key identifiers to generate a virtual unique mapping address, it can be ensured that specific address accesses from specific units and specific transactions are accurately mapped to a unique location in shared memory, thereby achieving cross-component data consistency. Based on this, this embodiment combines the request source identifier, transaction identifier, and address offset information to generate a unique mapping address. This unique mapping address is used as an index to find or write response data in shared memory.

[0105] Here, a unique mapping address can be understood as an address generated by concatenation or hashing using a specific algorithm, used to index data within the verification environment. Shared memory can be understood as a storage model in the verification environment used to store randomly generated data, accessible to both the unit under test (DUT) and the reference model.

[0106] As an optional embodiment, the request source identifier can be used as the high bit, the transaction identifier as the middle bit, and the address offset information as the low bit. The request source identifier, transaction identifier, and address offset information can be combined by bit concatenation to generate a unique mapping address.

[0107] The generated unique mapping address is then used as an index to query the shared memory. If the location corresponding to the index already contains data, indicating that either the unit under test or the reference model has accessed the shared memory, the data is directly read as the response data; if the location corresponding to the index is empty, a random response data is generated and written to that location.

[0108] Considering that in the real-world operating environment of multi-core processor clusters, the unit under test (UTC) will simultaneously send requests to multiple different remote computing units, and the responses from different sources will follow different paths in the network, resulting in varying levels of congestion and physical latency. Mixing all non-atomic responses from the same source into a single queue for uniform out-of-order processing might mask the communication characteristics of specific source nodes, making it impossible to accurately simulate complex verification scenarios where "responses from CU1 are fast, but responses from CU2 are slow and out of order." Therefore, this embodiment introduces a source-identifier-based grouping mechanism when performing out-of-order processing.

[0109] Specifically, the generated second response data is subjected to out-of-order processing, including: Identify the request source identifier corresponding to a non-atomic operation request; Determine the queue corresponding to the second response data associated with the request source identifier; The generated second response data is stored in the queue corresponding to the second response data; Perform a random position swap operation on the data elements stored in the queue corresponding to the second response data so that the output order of the second response data is inconsistent with the generation order.

[0110] Specifically, the request source identifier can be understood as a unique identifier of the source unit that initiated the non-atomic operation request. The queue corresponding to the second response data associated with the request source identifier refers to a buffer structure pre-allocated in the verification environment for each possible request source, specifically used to store the non-atomic response data generated by that source.

[0111] As an optional embodiment, after generating the second response data, the transaction information to which the data belongs is parsed to extract the request source identifier 'a'. Then, the queue index corresponding to this identifier is searched in a lookup table or mapping relationship to determine that the queue with index 'a' is the queue corresponding to the second response data associated with the request source identifier. Next, the second response data is pushed to the end of this queue. In this way, physical or logical isolation of response data according to its source is achieved, providing a foundation for subsequent fine-grained out-of-order processing targeting specific sources.

[0112] Furthermore, considering that even multiple non-atomic operation responses from the same source, such as consecutive read requests, may arrive earlier during network transmission due to the dynamic nature of routing algorithms or arbitration mechanisms of intermediate nodes, if the queue only maintains a first-in, first-out (FIFO) approach, it cannot expose potential bugs in the unit under test when handling out-of-order returns. Therefore, this embodiment performs a random position swap operation on the data elements stored in the queue corresponding to the second response data after the data is enqueued, so that the output order of the second response data is inconsistent with the generation order.

[0113] As an optional implementation, a pseudo-random number generator can be used to generate random indices. Assuming the queue corresponding to the second response data currently stores N data elements, the verification environment randomly selects two elements at different positions in the queue at each clock cycle or a specific scheduling time, and swaps the contents of these two elements; alternatively, when output data is needed, instead of directly popping the head element, an element at position k is randomly selected from the valid range of the queue and popped as the output.

[0114] in, Figure 4 This is a flowchart illustrating the order-preserving and out-of-order processing provided by the present invention, as shown below. Figure 4 As shown, firstly, the queues corresponding to the first and second response data are obtained. Next, the type of access request corresponding to each queue is determined. If the access request is an atomic operation request (i.e., processing the first response data), the corresponding queue is kept in a first-in, first-out (FIFO) order. If the access request is a non-atomic operation request (i.e., processing the second response data), the corresponding queue is shuffled, meaning the second response data is processed out of order, simulating scenarios where other types of responses can be out of order in a real network. Finally, the data after the above order-preserving or out-of-order processing is sent to the output queue.

[0115] In the chip verification process, to determine whether the function of the unit under test (DUT) is correct, a reference model with correct behavior is usually needed as a comparison standard. This requires the reference model to receive the exact same input stimulus and response data as the DUT in order to produce comparable expected results. Furthermore, to ensure that the random data acquired by both are decoupled in timing but consistent in content, this embodiment expands and refines the process of "sending the target response data to the DUT".

[0116] Specifically, the process of sending the target response data to the unit under test also includes: The target response data is sent to the reference model so that the reference model outputs a standard result that is consistent with the expected behavior of the unit under test based on the target response data. In the shared memory configuration, for the same access address, the generation and writing of response data is triggered by the first visitor in the unit under test and the reference model, and the written response data is read by the subsequent visitor.

[0117] Considering that the core objective of the verification environment is automatic comparison, the reference model can only accurately simulate the expected internal state changes of the unit under test (UTP) when it receives response data consistent with the UTP, thereby generating standard results for comparison. Based on this, this embodiment sends the target response data to the reference model, enabling the reference model to output standard results consistent with the expected behavior of the UTP based on the target response data.

[0118] Here, the reference model can be understood as a software model written in a high-level language with correct functional logic, used to simulate the expected behavior of the hardware design. The standard result can be understood as the correct data or state that the unit under test should output under ideal conditions.

[0119] As an optional embodiment, while the target response data is driven to the bus interface of the unit under test in the driver layer, a copy of the target response data can be sent to the reference model synchronously through the internal communication mechanism of the verification environment.

[0120] In random verification, data generation is typically dynamic. If the unit under test (DUT) and the reference model generate random data independently, the values ​​read from the same address may differ, leading to comparison failure. Furthermore, the DUT and the reference model operate at different speeds, making it impossible to predict which will initiate the request first. Therefore, a "generate once, reuse multiple times" mechanism is needed to ensure data consistency. Based on this, in this embodiment, the shared memory is configured such that for the same access address, the first accessor in the DUT and the reference model triggers the generation and writing of response data, and the subsequent accessor reads the written response data.

[0121] Here, the first visitor can be understood as the component that initiates a data request for a specific, unique mapped address through the response generator on the simulation timeline. This component could be the unit under test or the reference model. The subsequent visitor can be understood as the second component to initiate a request for the same address.

[0122] As an alternative implementation, the shared memory can be designed as a read-only sparse memory. When a read request is received, it is checked whether the target address already contains data. If not, it indicates that the first visitor has accessed the memory, so a random function is called to generate data, which is first written to the address and then returned. If the data already exists, it indicates that the second visitor has accessed the memory, so the stored data is directly read and returned.

[0123] Figure 5 This is a schematic diagram of the response control framework provided by the present invention, as shown below. Figure 5 As shown, firstly, the access request from the unit under test is received, and the response generation layer is entered. If the access request is an atomic operation request, one request will generate multiple first response data returns; if the access request is a non-atomic operation request, one second response data will be generated and returned.

[0124] Then, the response sorting layer places the first response data or the second response data into the corresponding queue based on the access request type and response source identifier generated by the response generation layer.

[0125] Next, the out-of-order layer maintains the predetermined order of the first response data from the same unit under test, while performing out-of-order processing on the second response data within the unit under test.

[0126] Subsequently, the interleaving layer selects the target response data from the various queues maintained by the out-of-order layer according to the preset scheduling strategy.

[0127] Finally, the driving layer sends the target response data to the unit under test or the reference model, and after a delay, repeats the above process to simulate the physical delay uncertainty that exists in real-world scenarios.

[0128] Figure 6 This is a block diagram of the CU cluster system provided by the present invention, such as... Figure 6 As shown, the CU cluster consists of the current computing unit, other virtual computing units, and on-chip networks. The current computing unit contains the unit under test and the reference model. The CU cluster response generator includes all computing units within the cluster except the current computing unit. It is responsible for receiving requests and generating responses, and its processing flow is as follows: First, the unit under test or reference model in the current computing unit sends an access request through the on-chip network. This access request can be sent to multiple upstream or downstream computing units via multicast, or it can be sent to only one computing unit via point-to-point, and the current computing unit supports sending multiple incomplete access requests.

[0129] Then, the receiving module of the CU cluster response generator receives the access request from the current computing unit, and the generation module generates response data simulating a real-world scenario based on the request type. During this process, to compare with the reference model, the reference model also sends an access request to the CU cluster response generator, just like the unit under test (DUT), and the CU cluster response generator also generates response data. To ensure data consistency, the system maintains private memory for the DUT, private memory for the reference model, and shared memory. The DUT's private memory is used to store write data and generate read data, while the reference model's private memory is used to store write data and generate read data. The shared memory is read-only and is used to store random data generated during the first address access, ensuring data consistency when the DUT and the reference model access the same address.

[0130] Next, specific response data is generated based on the type of access request. For atomic operation requests, multiple first response data entries are generated; for non-atomic operation requests (excluding atomic operations), a single second response data entry is generated.

[0131] Finally, the scheduling module selects the target and response data from the first and second response data and returns them to the current computing unit through the on-chip network.

[0132] The response timing control device for functional verification provided by the present invention will be described below. The response timing control device for functional verification described below can be referred to in correspondence with the response timing control method for functional verification described above.

[0133] Based on any of the above embodiments Figure 7 This is a schematic diagram of the response timing control device for functional verification provided by the present invention, as shown below. Figure 7 As shown, the device includes: The receiving module 710 is used to receive access requests from the unit under test; The processing module 720 is used to generate multiple first response data in a predetermined order and maintain the predetermined order of the multiple first response data when the access request is an atomic operation request. In the case of a non-atomic operation request, a second response data is generated, and the generated second response data is processed out of order. The sending module 730 is used to select target response data from the first response data that has been maintained in order or the second response data that has been processed out of order, and send the target response data to the unit under test for functional verification.

[0134] Figure 8 This is a schematic diagram of the structure of the electronic device provided by the present invention, such as... Figure 8 As shown, the electronic device may include a processor 810, a communications interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communications interface 820, and the memory 830 communicate with each other via the communication bus 840. The processor 810 can call logical instructions in the memory 830 to execute a response timing control method for functional verification.

[0135] Furthermore, the logical instructions in the aforementioned memory 830 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 related technologies, 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.

[0136] On the other hand, the present invention also provides a computer program product, the computer program product including a computer program that can be stored on a non-transitory computer-readable storage medium, and when the computer program is executed by a processor, the computer is able to execute the response timing control method for functional verification provided by the above methods.

[0137] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the response timing control method for functional verification provided by the methods described above.

[0138] The device 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.

[0139] 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 parts that contribute to the related technology, can be embodied in the form of software products. 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.

[0140] 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 response timing control method for functional verification, characterized in that, include: Receive access requests from the unit under test; In the case that the access request is an atomic operation request, multiple first response data with a predetermined order are generated, and the predetermined order of the multiple first response data is maintained; If the access request is a non-atomic operation request, a second response data is generated, and the generated second response data is processed out of order. Select target response data from the first response data that has been ordered or the second response data that has been out of order, and send the target response data to the unit under test for functional verification.

2. The response timing control method for functional verification according to claim 1, characterized in that, The step of selecting target response data from the first response data after maintaining order or the second response data after out-of-order processing includes: Based on a preset scheduling strategy, a target queue is determined from the queue corresponding to the first response data or the queue corresponding to the second response data, and the target response data is extracted from the target queue.

3. The response timing control method for functional verification according to claim 2, characterized in that, When the preset scheduling policy is an instruction type priority policy, determining the target queue from the queue corresponding to the first response data or the queue corresponding to the second response data includes: If the waiting period of the queue corresponding to the second response data exceeds a preset threshold, the priority of the queue corresponding to the second response data is increased so that the queue of the second response data is preferentially selected as the target queue. If the waiting period does not exceed the preset threshold and the queue corresponding to the first response data is not empty, the queue corresponding to the first response data is selected as the target queue.

4. The response timing control method for functional verification according to claim 2, characterized in that, The step of determining the target queue from the queue corresponding to the first response data or the queue corresponding to the second response data based on a preset scheduling strategy includes: When the preset scheduling strategy is the source unit weight strategy, the target queue is determined from the queue corresponding to the first response data or the queue corresponding to the second response data according to the weight of the source unit corresponding to the first response data and the weight of the source unit corresponding to the second response data. When the preset scheduling strategy is a round-robin strategy, the corresponding queue is selected from the queue corresponding to the first response data or the queue corresponding to the second response data as the target queue according to the order of the response source identifiers corresponding to the first response data and the order of the response source identifiers corresponding to the second response data. When the preset scheduling strategy is a random strategy, a non-empty queue is randomly selected from the queue corresponding to the first response data or the queue corresponding to the second response data as the target queue.

5. The response timing control method for functional verification according to any one of claims 1 to 4, characterized in that, The generation of multiple first response data entries in a predetermined order includes: Parse the atomic operation request to determine the target address sequence containing multiple consecutive addresses; For each target address in the target address sequence, the following data acquisition steps are executed sequentially: if there is no historical data for the corresponding target address in the shared memory, data is randomly generated as the response data for the corresponding target address and written into the shared memory; if there is historical data for the corresponding target address in the shared memory, the historical data is read from the shared memory as the response data for the corresponding target address. The response data corresponding to all target addresses in the target address sequence are combined in ascending order of the target address sequence to generate multiple first response data in a predetermined order.

6. The response timing control method for functional verification according to any one of claims 1 to 4, characterized in that, The receiving of access requests from the unit under test includes: Obtain the request source identifier, transaction identifier, and address offset information corresponding to the access request; The request source identifier, the transaction identifier, and the address offset information are combined to generate a unique mapping address, which is used as an index to search for or write response data in shared memory.

7. The response timing control method for functional verification according to any one of claims 1 to 4, characterized in that, The step of performing out-of-order processing on the generated second response data includes: Identify the request source identifier corresponding to the non-atomic operation request; Determine the queue corresponding to the second response data associated with the request source identifier; The generated second response data is stored in the queue corresponding to the second response data; A random position swap operation is performed on the data elements stored in the queue corresponding to the second response data so that the output order of the second response data is inconsistent with the generation order.

8. The response timing control method for functional verification according to any one of claims 1 to 4, characterized in that, The process of sending the target response data to the unit under test also includes: The target response data is sent to a reference model so that the reference model outputs a standard result consistent with the expected behavior of the unit under test based on the target response data. In this configuration, the shared memory is set up so that for the same access address, the generation and writing of response data are triggered by the first visitor in the unit under test and the reference model, and the response data written is read by the subsequent visitor.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the response timing control method for functional verification as described in any one of claims 1 to 8.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the response timing control method for functional verification as described in any one of claims 1 to 8.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the response timing control method for functional verification as described in any one of claims 1 to 8.

Images