Verification method and device of integrated circuit, computer equipment and storage medium

Abstract

The application provides a verification method and device of an integrated circuit, computer equipment and a storage medium, and belongs to the technical field of computers. The method comprises the following steps: in the case that the total data length of an operation request for verifying the integrated circuit exceeds the maximum data length that a reference model can process at a time, the operation request is split into multiple sub-operation requests; a completion indication signal is generated for each sub-operation request; the multiple sub-operation requests and the respective completion indication signals are sequentially input into the reference model in the position order of the multiple sub-operation requests to obtain an expected bus transaction; and the actual bus transaction output by the integrated circuit based on the operation request is verified based on the expected bus transaction to obtain a verification result of the integrated circuit. The above method realizes decoupling of the reference model and the operation request size, improves the reusability of the reference model, shortens the development cycle, reduces the maintenance cost, and can efficiently adapt to the verification demand of large data volume operation requests.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, computer device, and storage medium for verifying integrated circuits. Background Technology

[0002] As the complexity of integrated circuit design continues to increase, the importance of functional verification is becoming increasingly prominent. In the field of high-speed bus interfaces, in order to make full use of transmission bandwidth, the amount of data carried by a single operation request has increased significantly, for example, from the traditional 64 bytes to 256 bytes or even higher, which poses new requirements for verification methods.

[0003] Currently, mainstream verification methods typically employ reference models for automated comparison. In traditional approaches, the verification environment simultaneously inputs operation requests to both the integrated circuit under test (ICD) and the reference model. The reference model then generates the expected result based on the protocol specification and compares it with the actual output of the IC to verify the correctness of the IC's functionality. To handle operation requests of varying data lengths, the reference model needs to implement corresponding logic based on the size of the operation request and the protocol rules followed.

[0004] However, in the traditional solutions mentioned above, the implementation of the reference model is highly coupled with the scale of the operation request and the protocol rules. When the amount of data in the operation request increases, it is often necessary to redevelop or significantly modify the internal logic of the reference model, resulting in poor reusability of the reference model, long development cycle, high maintenance cost, and difficulty in efficiently adapting to the verification requirements of large-scale operation requests. Summary of the Invention

[0005] This application provides a method, apparatus, computer device, and storage medium for verifying integrated circuits. It decouples the reference model from the scale of operation requests, improves the reusability of the reference model, shortens the development cycle, reduces maintenance costs, and can efficiently adapt to the verification needs of large-scale operation requests. The technical solution is as follows: On the one hand, a method for verifying integrated circuits is provided, the method comprising: An operation request for verifying the integrated circuit is obtained. If the total data length of the operation request exceeds the maximum data length that the reference model can process at one time, the operation request is split into multiple sub-operation requests. The data length of each sub-operation request does not exceed the maximum data length that the reference model can process at one time. The reference model is used to simulate the behavior of the integrated circuit under correct functional conditions in order to generate the bus transactions expected to be output by the integrated circuit. For any one of the plurality of sub-operation requests, a completion indication signal for the sub-operation request is generated based on the position of the sub-operation request among the plurality of sub-operation requests. The completion indication signal is used to indicate whether the reference model has obtained the complete operation request when it receives the sub-operation request. According to the positional order of the multiple sub-operation requests, the multiple sub-operation requests and their corresponding completion indication signals are sequentially input into the reference model to obtain the expected bus transaction; Based on the expected bus transaction, the actual bus transaction output by the integrated circuit based on the operation request is verified to obtain the verification result of the integrated circuit. The verification result is used to indicate whether the function of the integrated circuit is correct.

[0006] On the other hand, an integrated circuit verification apparatus is provided, the apparatus comprising: The splitting module is used to acquire operation requests for verifying the integrated circuit. If the total data length of the operation request exceeds the maximum data length that the reference model can process at one time, the operation request is split into multiple sub-operation requests. The data length of each sub-operation request does not exceed the maximum data length that the reference model can process at one time. The reference model is used to simulate the behavior of the integrated circuit under correct functional conditions in order to generate the bus transactions expected to be output by the integrated circuit. The generation module is used to generate a completion indication signal for any one of the plurality of sub-operation requests based on the position of the sub-operation request among the plurality of sub-operation requests. The completion indication signal is used to indicate whether the reference model has obtained the complete operation request when it receives the sub-operation request. The processing module is used to sequentially input the multiple sub-operation requests and their corresponding completion indication signals into the reference model according to the positional order of the multiple sub-operation requests, so as to obtain the expected bus transaction; The verification module is used to verify the actual bus transaction output by the integrated circuit based on the operation request, based on the expected bus transaction, and to obtain the verification result of the integrated circuit. The verification result is used to indicate whether the function of the integrated circuit is correct.

[0007] In some embodiments, the splitting module is configured to, when the starting address of the operation request is not located at a preset alignment boundary, split the first sub-operation request from the operation request based on the starting address and the preset alignment boundary. The starting address of the first sub-operation request is the starting address of the operation request, and the data length of the first sub-operation request is the data length from the starting address to the preset alignment boundary, where the preset alignment boundary is an integer multiple of the bus width of the integrated circuit. For the remaining data in the operation request, if the data length of the remaining data does not exceed the maximum data length, the remaining data is treated as a new sub-operation request. If the data length of the remaining data exceeds the maximum data length, a new sub-operation request is split from the remaining data based on the starting address and data length of the sub-operation request obtained in the previous splitting and the maximum data length. The starting address of each sub-operation request is the sum of the starting address of the previous sub-operation request and the data length of the previous sub-operation request, and the data length of the sub-operation request obtained in this splitting is the maximum data length.

[0008] In some embodiments, the splitting module is further configured to split any sub-operation request obtained by splitting, if the sub-operation request exceeds the maximum payload size configured by the integrated circuit, to obtain a new sub-operation request, wherein the data length of each sub-operation request does not exceed the maximum payload size.

[0009] In some embodiments, the generation module is configured to, for any one of the plurality of sub-operation requests, if the sub-operation request is a non-last sub-operation request among the plurality of sub-operation requests, set the completion indication signal of the sub-operation request to a first signal, the first signal being used to indicate an incomplete state; if the sub-operation request is the last sub-operation request among the plurality of sub-operation requests, set the completion indication signal of the sub-operation request to a second signal, the second signal being used to indicate a completed state.

[0010] In some embodiments, the actual bus transaction includes multiple actual sub-transactions, which are generated and output by the integrated circuit based on the operation request. The expected bus transaction includes multiple expected sub-transactions, each expected sub-transaction corresponding to each sub-operation request, and is generated by the reference model based on each sub-operation request. The verification module is used to store each actual sub-transaction in the actual bus transaction in a first queue in sequence; and to store each expected sub-transaction in the expected bus transaction in a second queue in sequence; when both the first queue and the second queue are not empty, an actual sub-transaction is taken from the head of the first queue and an expected bus transaction is taken from the head of the second queue for comparison; when all actual sub-transactions and expected sub-transactions are consistent and both the first queue and the second queue are empty, the integrated circuit is determined to be functionally correct.

[0011] In some embodiments, the operation request is a write request.

[0012] On the other hand, a computer device is provided, the computer device including a processor and a memory, the memory being used to store at least one computer program, the at least one computer program being loaded and executed by the processor to implement the integrated circuit verification method in the embodiments of this application.

[0013] On the other hand, a computer-readable storage medium is provided, wherein at least one computer program is stored in the computer-readable storage medium, the at least one computer program being loaded and executed by a processor to implement the verification method of the integrated circuit as described in the embodiments of this application.

[0014] On the other hand, a computer program product is provided, including a computer program stored in a computer-readable storage medium, a processor of a computer device reading the computer program from the computer-readable storage medium, and the processor executing the computer program, causing the computer device to perform the integrated circuit verification method provided in the above-described aspects or various alternative implementations of the aspects.

[0015] The solution provided in this application splits operation requests with total data length exceeding the processing capacity of the reference model into multiple sub-operation requests and generates a completion indication signal for each sub-operation request. This allows the reference model to process operation requests with large data volumes without modifying its internal logic. This method migrates the splitting logic from within the reference model to the input front end, achieving decoupling between the reference model and the scale and protocol rules of the operation requests. When the data volume of the operation requests increases, there is no need to redevelop or significantly modify the reference model; simply reusing the existing reference model is sufficient to generate accurate expected bus transactions. Compared to traditional solutions, this method significantly improves the reusability of the reference model, shortens the verification and development cycle, reduces maintenance costs, and can efficiently adapt to the verification requirements of operation requests with large data volumes. Simultaneously, the completion indication signal ensures that the reference model accurately identifies the complete request boundary, guaranteeing the correctness of the expected output, thus improving verification efficiency while maintaining verification accuracy. Attached Figure Description

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

[0017] Figure 1 This is a schematic diagram illustrating the implementation environment of an integrated circuit verification method provided in an embodiment of this application; Figure 2 This is a flowchart of a method for verifying an integrated circuit according to an embodiment of this application; Figure 3 This is a flowchart of another integrated circuit verification method provided according to an embodiment of this application; Figure 4 This is a timing waveform diagram of an operation request provided according to an embodiment of this application; Figure 5 This is a flowchart illustrating a splitting operation request provided according to an embodiment of this application; Figure 6 This is a framework diagram of a verification integrated circuit provided according to an embodiment of this application; Figure 7 This is a block diagram of an integrated circuit verification apparatus provided according to an embodiment of this application; Figure 8 This is a structural block diagram of a terminal provided according to an embodiment of this application; Figure 9 This is a schematic diagram of the structure of a server according to an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0019] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor are there any restrictions on quantity or execution order.

[0020] In this application, the term "at least one" means one or more, and "multiple" means two or more.

[0021] It should be noted that all information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this application have been authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, all operation requests involved in this application were obtained with full authorization.

[0022] The integrated circuit verification method provided in this application can be executed by a computer device. In some embodiments, the computer device is a terminal or a server. The following section first uses a computer device as an example to describe the implementation environment of the integrated circuit verification method provided in this application. Figure 1 This is a schematic diagram illustrating the implementation environment of an integrated circuit verification method according to an embodiment of this application. See also... Figure 1 The implementation environment includes terminal 101 and server 102. Terminal 101 and server 102 can be connected directly or indirectly via wired or wireless communication, which is not limited herein.

[0023] In some embodiments, terminal 101 may be a high-performance desktop computer, graphics workstation, rack-mounted workstation, or mobile workstation, but is not limited thereto. Terminal 101 has installed and runs Electronic Design Automation (EDA) tools related to integrated circuit verification. These EDA tools include any one or more combinations of simulators (such as VCS, Xcelium, QuestaSim), waveform viewers (such as Verdi), formal verification tools, static timing analysis tools, and placement and routing tools. Illustratively, terminal 101 is a terminal used by a user (e.g., a verification engineer) who uses terminal 101 to write verification test cases, perform simulation tests, debug design errors, and collect coverage data. This verification activity includes, but is not limited to, at least one of: functional simulation, timing simulation, formal verification, assertion checking, coverage analysis, and regression testing. Illustratively, the object being verified is an integrated circuit design. This integrated circuit design may include any one of digital circuits, analog circuits, mixed-signal circuits, System on Chip (SoC), or Intellectual Property Core (IP core), and this application embodiment does not limit this.

[0024] Those skilled in the art will understand that the number of terminals described above can be more or less. For example, there may be only one terminal, or there may be dozens or hundreds of terminals, or even more. This application does not limit the number of terminals or the type of device.

[0025] In some embodiments, server 102 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), big data, and artificial intelligence platforms. Server 102 is used to provide background services for the integrated circuit verification process. In some embodiments, server 102 undertakes the main computing work, and terminal 101 undertakes the secondary computing work. For example, server 102 runs large-scale simulation regression testing or formal verification tasks, while terminal 101 is only used for task submission and result analysis; or, server 102 undertakes the secondary computing work, and terminal 101 undertakes the main computing work. For example, terminal 101 completes rapid iterative verification of small modules locally, while server 102 only provides storage or license management services; or, server 102 and terminal 101 use a distributed computing architecture to perform collaborative computing to jointly complete the simulation and verification tasks of ultra-large-scale integrated circuits.

[0026] Figure 2 This is a flowchart of an integrated circuit verification method according to an embodiment of this application. See also... Figure 2 In this embodiment, the method is described using an example executed by a terminal. The verification method for the integrated circuit includes the following steps: 201. The terminal obtains the operation request used to verify the integrated circuit. If the total data length of the operation request exceeds the maximum data length that the reference model can process at one time, the operation request is split into multiple sub-operation requests. The data length of each sub-operation request does not exceed the maximum data length that the reference model can process at one time. The reference model is used to simulate the behavior of the integrated circuit under correct functional conditions in order to generate the bus transaction of the expected output of the integrated circuit.

[0027] In this application embodiment, an integrated circuit refers to a hardware design module with a bus interface, such as a PCIe (Peripheral Component Interconnect Express) controller, an AXI (Advanced eXtensible Interface) bus controller, a DMA (Direct Memory Access) controller, or a memory controller, etc. This application embodiment does not limit the specific type of integrated circuit. In practical application scenarios, this type of integrated circuit acts as a master or slave device in a system, receiving high-level operation instructions (such as memory read / write, configuration access, atomic operations, etc.) from the processor or other master devices, and converting these instructions into physical bus transactions conforming to the protocol specifications according to the followed bus protocol (such as PCIe, AXI, etc.), exchanging data with the target device (such as memory, peripherals) through the bus.

[0028] For example, in a computer system, after the PCIe controller receives a 256-byte memory write request initiated by the CPU (Central Processing Unit), it will split the write request into multiple MemoryWrite Transaction Layer Packets (MemWr TLP) that conform to the PCIe protocol and send them to the PCIe link according to its own configured maximum payload size (max_payload_size) and protocol rules.

[0029] The verification method in this application is designed specifically for the verification needs of such integrated circuits. By simulating their input stimuli (input operation requests) and comparing the output bus transactions, it ensures the correctness of their function under various operating scenarios.

[0030] The terminal runs a verification environment for verifying integrated circuits. An operation request refers to a high-level instruction actively issued by the stimulus generator (usually a software module) in the verification environment. This operation request can be a write request, a read request, an atomic operation, etc., and this application does not impose any restrictions on this. The operation request is not fixed but is randomly generated or randomly generated based on constraints, and this application does not limit the specific content of the operation request. For example, an operation request of "write 256 bytes of data to address 0x1000" includes information such as the starting address, total data length, data content, and byte enable.

[0031] A reference model is an ideal software model used to simulate the expected behavior of an integrated circuit (IC). Its behavior strictly adheres to bus protocol specifications (such as PCIe, AXI, etc.) or design specifications. Unlike hardware ICs, reference models are not limited by physical implementation (such as timing, power consumption, and area) and can accurately determine the bus transactions that the IC should output under correct functional conditions based on input stimuli (input operation requests). A bus transaction is a standardized information unit based on a bus protocol, containing complete information such as operation type, address, data payload, data length, byte enable, and transaction attributes, used to complete a complete communication interaction between the bus master and target devices. In the verification method, the bus transaction is both the expected output form generated by the reference model based on input stimuli and a concrete manifestation of the actual physical bus behavior output by the IC to be verified. The two are compared to verify the functional correctness of the IC.

[0032] The maximum data length that the reference model can process in a single operation refers to a fixed upper limit (e.g., 64 bytes) set by the verification environment to adapt to the processing capabilities of the reference model. Operation requests exceeding this length cannot be directly processed by the reference model.

[0033] During the integrated circuit verification process, the terminal first obtains an operation request for verifying the integrated circuit and determines whether the total data length of the operation request exceeds the maximum data length that the reference model can process in a single operation. If it does not exceed the maximum data length, no splitting is required, and the operation request is directly input into the reference model to determine the bus transaction (i.e., the expected bus transaction) that the integrated circuit should output under correct functionality. If it exceeds the maximum data length, the terminal can split the operation request into multiple sub-operation requests, ensuring that the data length of each sub-operation request does not exceed the maximum data length that the reference model can process in a single operation, so that the reference model can process it subsequently.

[0034] For example, the maximum data length that the reference model can process in a single operation is 64 bytes. If the operation request is to write 256 bytes of data to address 0x1000, which exceeds the maximum data length, the terminal will split the operation request into four sub-operation requests of 64 bytes each, corresponding to addresses 0x1000, 0x1040, 0x1080 and 0x10C0 respectively.

[0035] 202. For any sub-operation request among multiple sub-operation requests, a completion indication signal for the sub-operation request is generated based on the position of the sub-operation request among the multiple sub-operation requests. The completion indication signal is used to indicate whether the reference model has obtained the complete operation request when it receives the sub-operation request.

[0036] In this embodiment, the position of a sub-operation request refers to its order within the split sequence (e.g., the 1st, 2nd, ..., the last). The completion indication signal is a flag signal (e.g., `req_complete`) used to inform the reference model whether the currently received sub-operation request is the last one in the original operation request. The reference model uses this information to determine whether it has obtained complete original request data. For each sub-operation request split in step 201, the terminal generates a corresponding completion indication signal based on its position in the sequence. For example, if the sub-operation request is not the last one in the sequence, the completion indication signal is set to an "incomplete" state (e.g., logic 0); if the sub-operation request is the last one, the completion indication signal is set to a "complete" state (e.g., logic 1).

[0037] Continuing with the previous example, among the four sub-operation requests, the completion indication signal for the first three non-last sub-operation requests is "not completed", while the completion indication signal for the fourth last sub-operation request is "completed".

[0038] 203. The terminal sequentially inputs multiple sub-operation requests and their corresponding completion indication signals into the reference model according to the positional order of the multiple sub-operation requests, thereby obtaining the expected bus transaction.

[0039] In this embodiment, the positional order refers to the sequential order of sub-operation requests within the split sequence. The expected bus transaction is the anticipated output generated by the reference model according to a bus protocol (such as PCIe) based on the input sub-operation requests and completion indication signals. Its format is a standard physical bus transaction, which may contain complete information such as address, data, length, and byte enable. The terminal inputs each sub-operation request and its corresponding completion indication signal into the reference model sequentially according to their positional order. The reference model independently generates the corresponding expected bus transaction based on the content of the sub-operation request and the completion indication signal.

[0040] Since the input consists of multiple sub-operation requests, the reference model outputs expected bus transactions comprising multiple expected sub-transactions, each corresponding one-to-one with a sub-operation request. In the example above, the terminal sequentially sends four sub-operation requests and their corresponding completion indication signals (incomplete, incomplete, incomplete, complete) to the reference model. The reference model then outputs four expected sub-transactions sequentially, corresponding to write addresses 0x1000, 0x1040, 0x1080, and 0x10C0, respectively. Each expected sub-transaction carries 64 bytes of data.

[0041] 204. The terminal determines the verification result of the integrated circuit based on the actual bus transaction and expected bus transaction output by the integrated circuit based on the operation request. The verification result is used to indicate whether the integrated circuit is functioning correctly.

[0042] In this embodiment, an actual bus transaction refers to a bus transaction actually issued by the integrated circuit (hardware) to be verified based on the original operation request. The integrated circuit may be constrained by its own configuration (such as maximum payload size) and protocol rules, splitting the original operation request into multiple actual transactions. The verification result is used to indicate whether the integrated circuit functions correctly, typically categorized as "pass" or "fail".

[0043] During actual operation, the integrated circuit (IC) outputs actual bus transactions based on the received operation request, according to its internal hardware logic and the bus protocol it follows. The terminal obtains the actual bus transaction output by the IC based on the original operation request and compares it with the expected bus transaction output by the reference model in step 203. If the actual bus transaction is completely consistent with the expected bus transaction, it indicates that the IC is functioning correctly; if there is a difference between the actual bus transaction and the expected bus transaction, it indicates that the IC has a functional defect. In this way, the terminal can intuitively determine whether the IC's behavior under a given operation request meets expectations, thereby completing the functional verification of the IC.

[0044] This application provides a verification method for integrated circuits. By splitting operation requests with a total data length exceeding the processing capacity of a reference model into multiple sub-operation requests and generating a completion indication signal for each sub-operation request, the reference model can process operation requests with large data volumes without modifying its internal logic. This method migrates the splitting logic from within the reference model to the input front end, achieving decoupling between the reference model and the scale and protocol rules of the operation requests. When the data volume of the operation requests increases, there is no need to redevelop or significantly modify the reference model; simply reusing the existing reference model is sufficient to generate accurate expected bus transactions. Compared to traditional solutions, this method significantly improves the reusability of the reference model, shortens the verification development cycle, reduces maintenance costs, and can efficiently adapt to the verification needs of operation requests with large data volumes. Simultaneously, the completion indication signal ensures that the reference model accurately identifies the complete request boundary, guaranteeing the correctness of the expected output, thereby improving verification efficiency while maintaining verification accuracy.

[0045] The above Figure 2 The diagram shown is merely the basic flow of this application. The following section will further elaborate on the solution provided in this application based on a specific implementation method. Figure 3 This is a flowchart of another integrated circuit verification method provided according to an embodiment of this application. See also... Figure 3 In this embodiment, the method is described using an example executed by a terminal. The verification method for the integrated circuit includes the following steps: 301. The terminal obtains the actual bus transaction output by the integrated circuit based on the operation request. The actual bus transaction includes multiple actual sub-transactions.

[0046] In this implementation, the integrated circuit to be verified receives operation requests from the verification environment during actual operation. Based on its internal hardware logic and the bus protocol it follows, the integrated circuit converts these requests into one or more physical bus transactions and outputs them to the bus. The terminal, through a monitor component in the verification environment, collects signals from the integrated circuit's output pins or bus interfaces in real time, parses these signals into transaction-level data structures, and thus obtains the actual bus transactions output by the integrated circuit. Because the integrated circuit may be constrained by its own hardware configuration (such as maximum payload size, bus width, etc.) and protocol rules (such as address alignment requirements, byte enable continuity requirements, etc.), a single original operation request is often split into multiple actual sub-transactions and issued sequentially. Therefore, the actual bus transactions obtained by the terminal typically contain multiple actual sub-transactions, each corresponding to a complete bus communication interaction.

[0047] In some embodiments, the generation method of actual sub-transactions is closely related to the type and configuration of the integrated circuit. Such integrated circuits (e.g., bus controllers, DMA controllers, etc.) typically have a built-in protocol state machine. Upon receiving an operation request, this state machine dynamically determines how to split the original request into bus transactions that conform to the protocol requirements, based on parameters in its internal configuration registers (e.g., maximum payload size, bus width, address alignment mode, etc.) and mandatory rules in the protocol specification (e.g., byte enable must be continuous, address must be aligned to the bus width boundary, etc.). Specifically, if the data length of the original request exceeds the maximum payload size of the hardware configuration, the state machine will split it into multiple transactions, each with a data length not exceeding this maximum value; if the starting address of the original request is not aligned to the bus width boundary, the state machine will first issue a header transaction to fill in the alignment boundary, and then issue subsequent aligned transactions; if the byte enable of the original request is sparsely distributed, the state machine will split it into multiple transactions with continuous byte enable according to the protocol specification's requirements for byte enable continuity. Finally, the state machine sends these split transactions sequentially to the bus interface, forming the actual output bus transaction stream.

[0048] Taking the PCIe controller as an example, this controller is internally configured with a maximum payload size (max_payload_size) parameter, which determines the maximum amount of data that a single PCIe Transaction Layer Packet (TLP) can carry. When the PCIe controller receives a 256-byte write request, if its max_payload_size is configured to 128 bytes, the controller will split this write request into two 128-byte memory write transactions (MemWr TLPs) and send them to the PCIe link. Furthermore, if the starting address of the write request is not aligned to the bus width boundary, or if the byte enable is sparsely distributed, the controller will perform finer-grained splitting according to the PCIe protocol specification. For example, a write request spanning a 4-byte boundary and with byte enable set to 0xABC can be split into multiple address-aligned sub-transactions with consecutive byte enable settings. The terminal collects these actually sent TLP packets through a monitor and parses them into actual sub-transactions containing information such as address, data length, and byte enable settings, storing them sequentially in queues used in subsequent steps.

[0049] 302. The terminal stores each actual sub-transaction in the actual bus transaction in the first queue in sequence.

[0050] In this implementation, the output timing of the integrated circuit (IC) and the computation timing of the reference model are often out of sync. After receiving an operation request, the IC may, according to its internal hardware logic and protocol rules, begin outputting actual bus transactions before receiving all the data (e.g., splitting and sending data according to the maximum payload size after receiving only a portion). This can result in multiple actual bus transactions being output consecutively within a very short time. The reference model, however, typically waits for a completion indicator signal (e.g., `req_complete`) to go high before confirming that it has acquired the complete operation request data and then begins generating the expected bus transaction. Furthermore, the monitor often employs a "wait for complete data before submitting" strategy when acquiring data, meaning it only transmits all accumulated data to the reference model at once after the completion indicator signal goes high. This means that the reference model may generate the expected bus transaction significantly later than the IC actually outputs the bus transaction. If a real-time comparison is performed directly, the actual bus transaction will have nowhere to be stored before the reference model outputs the expected bus transaction, making comparison impossible. Therefore, after the terminal obtains the actual bus transaction output by the integrated circuit, since this actual bus transaction may contain multiple actual sub-transactions, and these actual sub-transactions are output sequentially in chronological order, the terminal can temporarily store them according to the output order for subsequent sequential comparison with the expected sub-transactions generated by the reference model. Specifically, the terminal can maintain a First-In-First-Out (FIFO) queue structure in memory, called the first queue. Whenever the integrated circuit outputs an actual sub-transaction, the terminal adds it to the tail of the first queue. In this way, the storage order of the actual sub-transactions in the first queue is completely consistent with its output order, ensuring that they can be retrieved in chronological order during subsequent comparisons.

[0051] In some embodiments, the depth of the first queue needs to be configured appropriately based on the verification scenario to ensure that the queue can accommodate the peak output of the integrated circuit under worst-case conditions and avoid data loss due to queue overflow. The core principle for configuring the depth of the first queue is that the queue depth should not be less than the maximum possible number of outputs the integrated circuit can produce within the time required for a single computation by the reference model. Specifically, the following factors can be considered in the configuration: the maximum output rate of the integrated circuit (i.e., the maximum number of sub-transactions that can be output per unit time), the time required for a single computation by the reference model (usually related to the data length and processing complexity of the operation request), and extreme scenarios that may occur in the verification environment (such as multiple operation requests arriving consecutively and each operation request being split into multiple sub-transactions). Verification engineers can set a depth value for the first queue sufficient to accommodate peak output based on these factors and actual observations during simulation.

[0052] For example, a high-performance PCIe controller with extremely high output rates may issue a sub-transaction in one clock cycle, while the reference model may need hundreds of clock cycles to process an operation request. In this case, the queue depth needs to be at least several hundred to ensure that all actual sub-transactions can be safely stored before the reference model completes its calculations.

[0053] Taking a PCIe controller verification scenario as an example, assuming the controller's `max_payload_size` is configured to 128 bytes, and the reference model's single-transaction processing capacity is also 128 bytes, the original operation request is to write 1024 bytes of data to address 0x1000. The integrated circuit can split this 1024-byte write request into eight 128-byte MemWr TLPs and send them consecutively within a very short time (e.g., eight clock cycles). However, because the reference model needs to wait for the completion indicator signal (`req_complete`) to go high before confirming that it has received the complete operation request data, its input time may be significantly later than the integrated circuit's output time. Before the reference model starts outputting the expected sub-transaction, the integrated circuit may have already sent all eight actual sub-transactions. In this case, if the depth of the first queue is less than 8, the queue will overflow when the eighth actual sub-transaction arrives, leading to data loss and verification failure. Therefore, verification engineers need to configure the first queue depth to at least 8 (i.e., the maximum number of transactions after splitting), and usually reserve some margin, such as configuring it to 16, to cope with more complex scenarios (such as multiple operation requests arriving in a pipeline). In actual configuration, simulation logs can also be used to observe the maximum depth value of the first queue in actual operation, and a safety margin can be added to this as the final queue depth. In addition, the terminal can also set a timeout mechanism for the first queue, triggering a warning when the queue is not cleared within a preset time, helping verification engineers to locate potential deadlocks or performance bottlenecks.

[0054] 303. The terminal obtains the operation request used to verify the integrated circuit. If the total data length of the operation request exceeds the maximum data length that the reference model can process at one time, the operation request is split into multiple sub-operation requests. The data length of each sub-operation request does not exceed the maximum data length that the reference model can process at one time. The reference model is used to simulate the behavior of the integrated circuit under correct functional conditions in order to generate the bus transaction of the expected output of the integrated circuit.

[0055] In this implementation, the operation request is actively constructed and issued by the Stimulus Generator in the verification environment. During the verification process, after generating the operation request, the Stimulus Generator sends it simultaneously through two paths: one path directly inputs to the integrated circuit to be verified, also known as the Device Under Test (DUT), driving it to generate actual output; the other path is acquired by the terminal for subsequent splitting and reference model processing. These operation requests can be of different types, such as write requests, read requests, and atomic operations. Their parameters (such as starting address, data length, byte enable, and data content) are typically generated randomly or with constraints to cover as many verification scenarios as possible. After receiving the operation request, the terminal first determines whether its total data length exceeds the maximum data length that the reference model can process in a single operation. This maximum data length is a fixed upper limit set by the verification environment to adapt to the reference model, for example, 64 bytes. If the limit is not exceeded, the terminal does not need to split the request and can directly input the original operation request as a single sub-operation request into the reference model for subsequent processes. If the limit is exceeded, the terminal needs to split the operation request into multiple sub-operation requests to ensure that the data length of each sub-operation request does not exceed the single processing capacity of the reference model, so that the existing reference model can process it directly.

[0056] For example, Figure 4 This is a timing waveform diagram of an operation request according to an embodiment of this application. See also... Figure 4 The top part represents the clock cycle, and the rest are four control signals: ReqVld, Req_complete, DatVld, and DatLast. Among them, ReqVld is the request valid signal, used to indicate the start of the operation request. Figure 4 The ReqVld signal is pulled high only during the first clock cycle and remains low thereafter, indicating that the request phase of the operation request lasts only one cycle. Req_complete is the request completion signal, used to mark the end boundary of the entire operation request. Figure 4 The `Req_complete` signal remains high throughout the entire process, indicating that the operation request is a single data packet and there is no need to use this signal to mark the boundaries of multiple requests. `DatVld` is the data valid signal, used to indicate that data on the data bus is valid. Figure 4 If DatVld is pulled high for multiple clock cycles (e.g., cycle 1 to cycle 4), it indicates that the operation request contains multiple data packets. DatLast is the last data packet signal, used to identify whether the currently transmitted data is the last data packet of the operation request. Figure 4 In the middle, DatLast only goes high on the last data point (e.g., period 4) to indicate the end of the data. Figure 4As can be seen, an operation request carries multiple data frames, ReqVld is only valid for one frame, the Last signal is valid for the last frame of data, and Req_complete is always high to indicate an independent request. This clearly shows that the operation request is a request with a large amount of data and needs to be split.

[0057] This application does not limit the method of splitting operation requests in its embodiments. In some embodiments, regardless of whether the byte enable of the operation request is in continuous mode or sparse mode, the terminal can split the operation request based on the data length. Specifically, the terminal splits the operation request into multiple sub-operation requests according to the maximum data length that the reference model can process in a single operation, and the data length of each sub-operation request does not exceed the maximum data length that the reference model can process in a single operation. Continuous mode indicates that the valid bits in the byte enable of the operation request are continuous in the address space, that is, all valid bytes are adjacent in address space without gaps. For example, the byte enable is 0xFFFF (all valid) or 0xFF00 (the high two bytes are valid), etc. Sparse mode indicates that the valid bits in the byte enable of the operation request are not continuous in the address space, that is, there are invalid bytes between valid bytes, for example, the byte enable is 0x1010 (only addresses 0x1001 and 0x1003 are valid). This splitting method is concise and efficient, fully utilizing the upper limit of the reference model's processing capacity. While ensuring that each sub-operation request does not exceed the reference model's input limit, it minimizes the number of sub-operation requests, thereby reducing the number of reference model calls and the processing overhead of the verification environment. For operation requests with large amounts of data, this method can quickly complete the splitting and send it to the reference model, effectively improving verification efficiency. It is particularly suitable for scenarios involving the transmission of continuous payloads in high-speed bus interfaces, enabling the verification environment to efficiently adapt to the large data block transmission requirements of practical applications.

[0058] Building upon the aforementioned splitting, the terminal can also perform cyclic splitting based on address alignment. Specifically, the terminal determines a preset alignment boundary, which is an integer multiple of the integrated circuit bus width. For example, when the bus width is 4 bytes, the alignment boundaries are 0x00, 0x04, 0x08, etc. Then, the terminal checks whether the starting address of the operation request is located on the preset alignment boundary. If the starting address of the operation request is not located on the preset alignment boundary (for example, if the starting address is 0x1001 and the bus width is 4 bytes, then 0x1001 is not an integer multiple of 4), the terminal splits the first sub-operation request from the operation request based on the starting address and the preset alignment boundary. The starting address of the first sub-operation request is the starting address of the operation request. The data length of the first sub-operation request is the data length from the starting address to the preset alignment boundary (for example, 3 bytes from 0x1001 to 0x1003). In this way, the first sub-operation request completes the address alignment "padding," allowing subsequent splitting to start from the aligned address.

[0059] Then, the terminal processes the remaining data in the operation request. For the remaining data in the operation request, if the length of the remaining data does not exceed the maximum data length (hereinafter referred to as the maximum data length), the remaining data is treated as a new sub-operation request, and the splitting ends. If the length of the remaining data exceeds the maximum data length, the terminal splits a new sub-operation request from the remaining data based on the starting address and data length of the sub-operation request obtained in the previous split, as well as the maximum data length. The starting address of each sub-operation request is the sum of the starting address and data length of the previous sub-operation request, and the data length of the sub-operation request obtained in this split is the maximum data length. That is, the terminal calculates the starting address of the current sub-operation request based on the starting address and data length of the sub-operation request obtained in the previous split, and sets the data length of the current sub-operation request to the maximum data length. This process continues until all remaining data has been split.

[0060] For example, assuming a bus width of 4 bytes and a maximum data length of 64 bytes for the reference model, the operation request is to write 256 bytes of data to address 0x1001. The terminal first splits the first sub-operation request: address 0x1001, data length 3 bytes (0x1001 to 0x1003). The remaining data is 253 bytes, starting from address 0x1004. Since 253 exceeds 64, the terminal sequentially splits the data into sub-operation requests at address 0x1004 (64 bytes), address 0x1044 (64 bytes), address 0x1084 (64 bytes), and address 0x10C4 (61 bytes), ultimately resulting in 5 sub-operation requests.

[0061] This splitting method strictly adheres to the alignment requirements of the bus protocol, ensuring that the split sub-operation requests are naturally consecutive in address, conforming to the address alignment specifications of bus transactions. Furthermore, the splitting process relies solely on address and length calculations, eliminating the need for byte parsing and enabling, resulting in low computational load and high execution efficiency. For large-volume operation requests, this splitting method can complete the splitting process in milliseconds, significantly shortening the preprocessing time of the verification environment and improving overall verification efficiency.

[0062] In other embodiments, considering that the hardware configuration of the integrated circuit may differ from the processing capability of the reference model, the terminal can also perform a secondary split based on the hardware configuration of the integrated circuit, building upon the previous split. Specifically, the terminal obtains the maximum payload size of the integrated circuit configuration, which is the upper limit of the data volume of a single bus transaction that the hardware can actually send (e.g., the max_payload_size configured in the PCIe controller). For any sub-operation request obtained from the split, if the sub-operation request exceeds the maximum payload size of the integrated circuit configuration, the terminal splits the sub-operation request to obtain a new sub-operation request. The data length of each sub-operation request does not exceed the maximum payload size. The solution provided in this application automatically performs a secondary split when the data length of the split sub-operation request exceeds the maximum payload of the hardware configuration, ensuring that each sub-operation request not only meets the input requirements of the reference model but also conforms to the actual sending capability of the integrated circuit. This limitation ensures that the expected bus transaction generated by the reference model and the bus transaction actually output by the hardware are consistent in length, avoiding misjudgments caused by the mismatch between the hardware configuration and the processing capability of the reference model. This method enables the verification environment to flexibly adapt to different hardware configurations without having to redevelop a reference model for each configuration, further improving the configurability and reusability of the verification platform.

[0063] For example, suppose the reference model can process a maximum data length of 128 bytes at a time, while the maximum payload size configured in the integrated circuit is 64 bytes. The terminal first splits the original operation request into several sub-operation requests based on 128 bytes. However, the length of these sub-operation requests (128 bytes) exceeds the actual transmission capacity of the hardware (64 bytes). At this point, the terminal further splits each of these 128-byte sub-operation requests into two 64-byte sub-operation requests, ensuring that the final generated sub-operation requests satisfy both the input requirements of the reference model (no more than 128 bytes) and the actual transmission capacity of the hardware (no more than 64 bytes). In this way, the expected bus transactions generated by the reference model based on these sub-operation requests will maintain the same length as the actual bus transactions output by the hardware, avoiding misjudgments due to configuration differences.

[0064] For example, Figure 5 This is a flowchart illustrating a splitting operation request according to an embodiment of this application. See also... Figure 5Upon receiving an operation request (mwr_tran), the system first checks if its total data length exceeds the 64-byte boundary. If not, the original request is directly output to the reference model, and the process ends. If it exceeds the boundary, the system proceeds to splitting. It then checks if this is the first sub-operation request after splitting. If so, the data length of the sub-operation request is taken from the starting address to the next 64-byte alignment boundary (i.e., padded to 64-byte alignment). If not, the data and byte enable of the sub-operation request are generated based on the length of the remaining data. After generating a sub-operation request, the system checks if the remaining data length is greater than 0. If the remaining data length is greater than 0, the system continues to generate the next sub-operation request; otherwise, the generated sub-operation request is output to the reference model, and the process ends. When generating a sub-operation request other than the first, the system first checks if the current data length to be processed is less than 64 bytes (equivalent to 16 Dwords). If it is less than 64 bytes, the system further checks if this sub-operation request is the last sub-operation request after splitting. If so, the completion indicator signal is set to 1; otherwise, the completion indicator signal is set to 0. If the data length is not less than 64 bytes, the data length of the current sub-operation request is 64 bytes; otherwise, the data length remains unchanged (i.e., the remaining data length is used). After determining the length, the corresponding data and byte enable are generated based on that length. For each sub-operation request, after generation, it is output to the reference model, and the starting address and data length of the remaining data are updated. The remaining data of the operation request is then evaluated until the remaining data length is 0. The entire splitting process decomposes operation requests exceeding 64 bytes into multiple sub-operation requests of the required length through multiple loops, and generates corresponding completion indication signals so that the reference model can correctly identify the request boundaries.

[0065] 304. For any sub-operation request among multiple sub-operation requests, the terminal generates a completion indication signal for the sub-operation request based on the position of the sub-operation request among the multiple sub-operation requests. The completion indication signal is used to indicate whether the reference model has obtained the complete operation request when it receives the sub-operation request.

[0066] In this implementation, after the terminal splits the operation request, it obtains a set of ordered sub-operation requests. Since the reference model needs to know when it has received the complete original operation request in order to begin generating the expected bus transaction (or complete the internal state update), the terminal needs to attach a completion indication signal to each sub-operation request. The value of this signal depends on the position of the sub-operation request in the split sequence: for sub-operation requests that are not at the end of the sequence, the completion indication signal is set to "incomplete," indicating that the reference model has not yet obtained the complete data; for sub-operation requests that are at the end of the sequence, the completion indication signal is set to "complete," indicating that the reference model possesses the complete original operation request information after receiving this sub-operation request. In this way, the reference model can accurately identify request boundaries, avoiding expected output errors caused by boundary misjudgment.

[0067] Specifically, for any sub-operation request among multiple sub-operation requests, if the sub-operation request is not the last one among the multiple sub-operation requests, the terminal sets the completion indication signal of the sub-operation request to the first signal, which indicates an incomplete state. If the sub-operation request is the last one among the multiple sub-operation requests, the terminal sets the completion indication signal of the sub-operation request to the second signal, which indicates a completed state. This method enables the reference model to accurately determine when the complete operation request has been acquired after receiving the completion indication signal, avoiding expected output deviations caused by boundary recognition errors. This signal generation method is independent of the specific content of the operation request, relying only on the position information of the sub-operation request. It has a wide range of applications, strong scalability, and provides a reliable synchronization mechanism for the reference model to correctly parse the split sub-operation requests.

[0068] The completion indication signal can be implemented using a single-bit signal, with logic 0 indicating "incomplete" and logic 1 indicating "complete". When generating a sub-operation request, the terminal simultaneously generates the corresponding completion indication signal and packages the two into a single data unit for subsequent input into the reference model.

[0069] For example, continuing the splitting example in step 303, the terminal splits the 256-byte write request into 5 sub-operation requests (3 bytes, 64 bytes, 64 bytes, 64 bytes, and 61 bytes). The first 4 sub-operation requests are not the last, and their completion indicator signals are set to 0; the 5th sub-operation request is the last, and its completion indicator signal is set to 1. Regardless of whether the byte enable is in continuous mode or sparse mode, the multiple sub-operation requests obtained from the splitting also follow this rule: no matter how many sub-operation requests there are, only the completion indicator signal of the last sub-operation request is 1, and the rest are 0.

[0070] 305. The terminal sequentially inputs multiple sub-operation requests and their corresponding completion indication signals into the reference model according to the positional order of the multiple sub-operation requests to obtain the expected bus transaction. The expected bus transaction includes multiple expected sub-transactions, and each expected sub-transaction corresponds one-to-one with each sub-operation request. It is generated by the reference model based on each sub-operation request.

[0071] In this implementation, the terminal inputs the split sub-operation requests and their corresponding completion indication signals into the reference model sequentially, according to their order in the sequence. The reference model is an ideal software model independent of the hardware design, which internally implements all the rules of the bus protocol specification. Each time the reference model receives a sub-operation request, it calculates the corresponding expected output based on the address, data, length, byte enable, and other information of the sub-operation request, as well as the request boundary state indicated by the completion indication signal. Since each sub-operation request is input independently, the reference model outputs a corresponding expected sub-transaction for each sub-operation request. The format of these expected sub-transactions is completely consistent with the bus transactions actually output by the integrated circuit, containing complete information such as operation type, address, data payload, data length, byte enable, and transaction attributes, providing a benchmark for subsequent comparison.

[0072] In some embodiments, when processing sub-operation requests, the reference model determines whether to immediately output the expected sub-transaction based on the status of the completion indication signal. For example, for a sub-operation request with a completion indication signal of "incomplete," the reference model may only record the received data information and not output the final transaction, but instead wait for the arrival of subsequent sub-operation requests; when a sub-operation request with a completion indication signal of "complete" is received, the reference model confirms that complete data has been obtained, and then generates the corresponding expected sub-transaction based on all accumulated sub-operation request information. This mechanism ensures that the reference model can correctly handle complex scenarios spanning multiple sub-operation requests.

[0073] Taking a PCIe write request as an example, if the original 256-byte write request is split into four 64-byte sub-operation requests, and the completion indication signal of the first three sub-operation requests is 0 and the fourth is 1, then the reference model may only cache the data in the first three calls, and only output the four expected sub-transactions (each corresponding to a 64-byte sub-operation request) at once in the fourth call.

[0074] 306. The terminal stores each expected sub-transaction in the expected bus transaction in the second queue in sequence.

[0075] In this implementation, the expected bus transaction output by the reference model typically contains multiple expected sub-transactions, which are generated sequentially according to the order of the input sub-operation requests. The terminal needs to temporarily store these expected sub-transactions for sequential comparison with the actual sub-transactions in the first queue. To this end, the terminal maintains another first-in-first-out queue in memory, called the second queue. Whenever the reference model outputs an expected sub-transaction, the terminal adds it to the tail of the second queue. In this way, the storage order of the expected sub-transactions in the second queue is completely consistent with the input order of the sub-operation requests, ensuring that they can be retrieved in the correct order during subsequent comparisons.

[0076] In some embodiments, the depth configuration of the second queue can be based on the computation latency of the reference model to ensure that the queue can accommodate the peak output of the reference model in the worst case, avoiding data loss due to queue overflow. The core principle for configuring the depth of the second queue is that the queue depth should not be less than the maximum expected number of sub-transactions that the reference model may output in a single computation cycle. Specifically, the following factors can be considered in the configuration: the time required for the reference model to process one operation request, the number of sub-operation requests obtained after splitting the operation request, whether the reference model adopts a batch output strategy (i.e., waiting for sub-requests with a completion indicator signal of "complete" before outputting multiple expected sub-transactions at once), and extreme scenarios that may occur in the verification environment (such as multiple operation requests arriving consecutively and each request generating multiple expected sub-transactions). Verification engineers can set a depth value for the second queue sufficient to accommodate peak output based on these factors and actual observations during simulation.

[0077] Taking a PCIe controller verification scenario as an example, assume the reference model employs a batch output strategy, meaning it only outputs all expected sub-transactions corresponding to the original operation request at once after receiving a sub-operation request with a "complete" completion indicator. The reference model's single-processing capacity is 64 bytes. The original operation request is to write 1024 bytes of data to address 0x1000, which is split into 16 sub-operation requests of 64 bytes each. The reference model only caches data and does not output it during the first 15 calls, only outputting all 16 expected sub-transactions at once on the 16th call (when the completion indicator is "complete"). At this point, the second queue will change from empty to containing 16 expected sub-transactions in a very short time. If the second queue depth is less than 16, when the 17th expected sub-transaction arrives (actually there are only 16, but if the depth is configured to 8, it will overflow when the 9th arrives), the queue will overflow, resulting in data loss. Therefore, verification engineers can configure the second queue depth to at least 16, and usually reserve some margin, such as 32, to deal with more complex scenarios (such as multiple operation request pipelines arriving, resulting in multiple batches of expected sub-transactions being output continuously).

[0078] In actual configuration, simulation logs can be used to observe the maximum depth of the second queue during operation, and a safety margin can be added as the final queue depth. Furthermore, the terminal can be configured with the same timeout mechanism as the first queue for the second queue, triggering a warning if the queue is not emptied within a preset time, helping verification engineers locate potential computational bottlenecks or anomalies.

[0079] 307. When both the first queue and the second queue are not empty, the terminal takes an actual sub-transaction from the head of the first queue and a expected bus transaction from the head of the second queue for comparison. When all actual sub-transactions and expected sub-transactions match and both the first queue and the second queue are empty, the integrated circuit is determined to be functioning correctly.

[0080] In this implementation, the terminal continuously monitors the status of the first and second queues. As long as both queues are not empty, the terminal retrieves an actual sub-transaction from the head of the first queue and an expected sub-transaction from the head of the second queue, comparing them field-by-field. The comparison may include key information such as transaction type, starting address, data length, byte enable, data payload, and transaction attributes; this embodiment does not limit this. If the comparison results are completely consistent, it indicates that the current pair of sub-transactions has matched successfully. The terminal removes them from the queues and continues to check the queue status, retrieving the next pair for comparison. If the comparison results are inconsistent (e.g., address mismatch, different data lengths, or different data content), the terminal immediately determines that the integrated circuit is malfunctioning and can record relevant information (such as expected value, actual value, timestamp, etc.) for analysis by the verification engineer (user). When all actual and expected sub-transactions match, and both the first and second queues are empty, it indicates that all bus transactions output by the integrated circuit completely match the expectations generated by the reference model, and the terminal determines that the integrated circuit is functioning correctly.

[0081] In some embodiments, the comparison process can also support flexible matching strategies. For example, for scenarios where the specific data content is not important, the terminal can skip the data payload field during comparison and only compare the address and length; for scenarios with non-deterministic behavior (such as reading certain status registers), the terminal can perform fuzzy matching or allow specific fields to fluctuate within a certain range. Furthermore, the terminal can add a timeout mechanism to the comparison process: if the first or second queue is empty while the other queue is not empty for a long period (such as when the number of simulation clock cycles reaches a preset threshold), it indicates that the actual output does not match the expected output in quantity, and the terminal will also determine that the integrated circuit is malfunctioning. This mechanism can effectively capture errors such as missed or excessive transactions by the integrated circuit.

[0082] For example, taking the splitting example in step 303: Regarding the actual bus transaction, assuming the integrated circuit's max_payload_size is configured to 128 bytes, the original 256-byte write request is split by the hardware into two 128-byte actual sub-transactions, corresponding to addresses 0x1000 and 0x1080 respectively; regarding the expected bus transaction, the reference model generates four 64-byte expected sub-transactions based on four 64-byte sub-operation requests, corresponding to addresses 0x1000, 0x1040, 0x1080, and 0x10C0 respectively. The terminal stores the two actual sub-transactions in the first queue and the four expected sub-transactions in the second queue. Then, they are compared sequentially: In the first pair, the actual sub-transaction (0x1000, 128) and the expected sub-transaction (0x1000, 64) have matching addresses but mismatched lengths, resulting in a failed comparison and verification result. If the hardware configuration of the integrated circuit is consistent with the granularity of the reference model (i.e., the hardware also outputs four 64-byte sub-transactions), then the actual sub-transactions in the first queue are (0x1000, 64), (0x1040, 64), (0x1080, 64), and (0x10C0, 64) in sequence. The expected sub-transactions in the second queue are also these four. After comparing them one by one, they are all consistent. Both queues are eventually empty, and the verification result is passed.

[0083] To more clearly describe the verification method provided in the embodiments of this application, the method is further described below with reference to the accompanying drawings. For example, Figure 6 This is a framework diagram of a verification integrated circuit provided according to an embodiment of this application. See also... Figure 6The verification environment first generates an operation request (e.g., a memory write request). This operation request is simultaneously sent to two paths: one path directly inputs to the integrated circuit under test (DUT), and the other path enters the preprocessing module. In the preprocessing module, it is determined whether the data volume of the operation request is "large" (i.e., whether it exceeds the maximum data length that the reference model can process in a single operation). If so, the original operation request is split into multiple sub-operation requests according to preset rules; otherwise, no splitting is required. The split sub-operation requests, along with the integrated circuit's configuration parameters (such as maximum payload size), are sent to the reference model. Based on these inputs, the reference model generates expected bus transactions (represented in TLP form) according to the bus protocol specification and stores these expected TLPs sequentially into the rf_queue queue (i.e., the second queue). Simultaneously, after receiving the original operation request, the integrated circuit under test (DUT), based on its internal hardware logic and configuration, actually outputs bus transactions conforming to the protocol (also represented in TLP form) and stores these actual TLPs sequentially into the dut_queue queue (i.e., the first queue). Finally, the scoreboard retrieves the expected TLP and the actual TLP sequentially from the head of the rf_queue and dut_queue respectively for comparison. If they match perfectly, the comparison continues to the next pair; if all TLPs match and both queues are empty, the integrated circuit is deemed to be functioning correctly; if the comparison shows discrepancies, the integrated circuit is deemed to be malfunctioning.

[0084] This application provides a method for verifying integrated circuits. First, a first queue temporarily stores the actual sub-transactions output by the integrated circuit, while a second queue temporarily stores the expected sub-transactions generated by the reference model. This first-in, first-out (FIFO) queue structure decouples the dependency between the integrated circuit output timing and the reference model computation timing, solving the real-time comparison failure problem caused by hardware output outpacing reference model computation in traditional solutions. Furthermore, by intelligently splitting operation requests, large data volume requests exceeding the reference model's processing capacity are decomposed into multiple sub-operation requests of suitable length. These sub-operation requests are accompanied by completion indication signals, enabling the reference model to accurately identify request boundaries. This achieves complete reuse of the existing reference model without requiring redevelopment or significant modification of its internal logic. Then, a sequential comparison mechanism ensures a one-to-one correspondence between multiple sub-transactions, avoiding misjudgments caused by out-of-order comparisons. This method significantly shortens the verification development cycle, reduces maintenance costs, and efficiently adapts to the verification needs of large data volume operation requests. Simultaneously, queue depth configuration and timeout mechanisms enhance the robustness of the verification environment, improving verification efficiency while ensuring the accuracy of verification results.

[0085] Figure 7This is a block diagram of an integrated circuit verification apparatus according to an embodiment of this application. The integrated circuit verification apparatus is used to perform the steps of the aforementioned integrated circuit verification method, see below. Figure 7 The verification device for integrated circuits includes: The splitting module 701 is used to obtain the operation request for verifying the integrated circuit. If the total data length of the operation request exceeds the maximum data length that the reference model can process at one time, the operation request is split into multiple sub-operation requests. The data length of each sub-operation request does not exceed the maximum data length that the reference model can process at one time. The reference model is used to simulate the behavior of the integrated circuit under the condition of correct function in order to generate the bus transaction of the expected output of the integrated circuit. The generation module 702 is used to generate a completion indication signal for any sub-operation request among multiple sub-operation requests, based on the position of the sub-operation request among the multiple sub-operation requests. The completion indication signal is used to indicate whether the reference model has obtained the complete operation request when it receives the sub-operation request. Processing module 703 is used to sequentially input multiple sub-operation requests and their corresponding completion indication signals into the reference model according to the position order of the multiple sub-operation requests, so as to obtain the expected bus transaction; The verification module 704 is used to verify the actual bus transaction output by the integrated circuit based on the operation request based on the expected bus transaction, and to obtain the verification result of the integrated circuit. The verification result is used to indicate whether the function of the integrated circuit is correct.

[0086] In some embodiments, the splitting module 701 is configured to, when the starting address of the operation request is not located at a preset alignment boundary, split the first sub-operation request from the operation request based on the starting address and the preset alignment boundary. The starting address of the first sub-operation request is the starting address of the operation request, and the data length of the first sub-operation request is the data length from the starting address to the preset alignment boundary. The preset alignment boundary is an integer multiple of the bus width of the integrated circuit. For the remaining data in the operation request, if the data length of the remaining data does not exceed the maximum data length, the remaining data is treated as a new sub-operation request. If the data length of the remaining data exceeds the maximum data length, a new sub-operation request is split from the remaining data based on the starting address and data length of the sub-operation request obtained in the previous splitting and the maximum data length. The starting address of each sub-operation request is the sum of the starting address of the previous sub-operation request and the data length of the previous sub-operation request, and the data length of the sub-operation request obtained in this splitting is the maximum data length.

[0087] In some embodiments, the splitting module 701 is further configured to split any sub-operation request obtained by splitting, if the sub-operation request exceeds the maximum payload size configured by the integrated circuit, to obtain a new sub-operation request, wherein the data length of each sub-operation request does not exceed the maximum payload size.

[0088] In some embodiments, the generation module 702 is configured to, for any one of the multiple sub-operation requests, if the sub-operation request is not the last sub-operation request among the multiple sub-operation requests, set the completion indication signal of the sub-operation request to a first signal, the first signal being used to indicate an incomplete state; if the sub-operation request is the last sub-operation request among the multiple sub-operation requests, set the completion indication signal of the sub-operation request to a second signal, the second signal being used to indicate a completed state.

[0089] In some embodiments, an actual bus transaction includes multiple actual sub-transactions, which are generated and output by an integrated circuit based on an operation request. An expected bus transaction includes multiple expected sub-transactions, each of which corresponds one-to-one with each sub-operation request and is generated by a reference model based on each sub-operation request. The verification module 704 is used to store each actual sub-transaction in the actual bus transaction in a first queue in sequence; and to store each expected sub-transaction in the expected bus transaction in a second queue in sequence; when both the first queue and the second queue are not empty, an actual sub-transaction is taken from the head of the first queue and an expected bus transaction is taken from the head of the second queue for comparison; when all actual sub-transactions and expected sub-transactions are consistent and both the first queue and the second queue are empty, the integrated circuit is determined to be functionally correct.

[0090] In some embodiments, the operation request is a write request.

[0091] This application provides a verification apparatus for integrated circuits. By splitting operation requests with a total data length exceeding the processing capacity of a reference model into multiple sub-operation requests and generating a completion indication signal for each sub-operation request, the reference model can process operation requests with large data volumes without modifying its internal logic. This method migrates the splitting logic from within the reference model to the input front end, achieving decoupling between the reference model and the scale and protocol rules of the operation requests. When the data volume of the operation requests increases, there is no need to redevelop or significantly modify the reference model; simply reusing the existing reference model is sufficient to generate accurate expected bus transactions. Compared to traditional solutions, this method significantly improves the reusability of the reference model, shortens the verification development cycle, reduces maintenance costs, and can efficiently adapt to the verification needs of operation requests with large data volumes. Simultaneously, the completion indication signal ensures that the reference model accurately identifies the complete request boundary, guaranteeing the correctness of the expected output, thereby improving verification efficiency while maintaining verification accuracy.

[0092] It should be noted that the integrated circuit verification device provided in the above embodiments is only illustrated by the division of the above functional modules when verifying the function of the integrated circuit. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the integrated circuit verification device and the integrated circuit verification method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0093] In the embodiments of this application, the computer device can be configured as a terminal or a server. When the computer device is configured as a terminal, the terminal can act as the execution subject to implement the technical solutions provided in the embodiments of this application. When the computer device is configured as a server, the server can act as the execution subject to implement the technical solutions provided in the embodiments of this application. Alternatively, the technical solutions provided in this application can be implemented through the interaction between the terminal and the server. The embodiments of this application do not limit this.

[0094] Figure 8 This is a structural block diagram of a terminal 800 according to an embodiment of this application. The terminal 800 can be a portable mobile terminal, such as a smartphone, tablet computer, MP3 player (Moving Picture Experts Group Audio Layer III), MP4 player (Moving Picture Experts Group Audio Layer IV), laptop computer, or desktop computer. The terminal 800 may also be referred to as a user device, portable terminal, laptop terminal, desktop terminal, or other names.

[0095] Typically, terminal 800 includes a processor 801 and a memory 802.

[0096] Processor 801 may include one or more processing cores, such as a quad-core processor or an octa-core processor. Processor 801 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 801 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 801 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 801 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0097] The memory 802 may include one or more computer-readable storage media, which may be non-transitory. The memory 802 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 802 are used to store at least one computer program, which is executed by the processor 801 to implement the integrated circuit verification method provided in the method embodiments of this application.

[0098] In some embodiments, the terminal 800 may also optionally include a peripheral device interface 803 and at least one peripheral device. The processor 801, memory 802, and peripheral device interface 803 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 803 via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of the following: a radio frequency circuit 804, a display screen 805, a camera assembly 806, an audio circuit 807, and a power supply 808.

[0099] Peripheral device interface 803 can be used to connect at least one I / O (Input / Output) related peripheral device to processor 801 and memory 802. In some embodiments, processor 801, memory 802 and peripheral device interface 803 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 801, memory 802 and peripheral device interface 803 can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0100] The radio frequency (RF) circuit 804 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 804 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 804 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. In some embodiments, the RF circuit 804 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, etc. The RF circuit 804 can communicate with other terminals through at least one wireless communication protocol. This wireless communication protocol includes, but is not limited to: the World Wide Web, metropolitan area networks, intranets, various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks, and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit 804 may also include circuitry related to NFC (Near Field Communication), which is not limited in this application.

[0101] Display screen 805 is used to display a UI (User Interface). This UI may include graphics, text, icons, videos, and any combination thereof. When display screen 805 is a touch display screen, it also has the ability to collect touch signals on or above its surface. These touch signals can be input as control signals to processor 801 for processing. In this case, display screen 805 can also be used to provide virtual buttons and / or a virtual keyboard, also known as soft buttons and / or a soft keyboard. In some embodiments, there may be one display screen 805, disposed on the front panel of terminal 800; in other embodiments, there may be at least two display screens, disposed on different surfaces of terminal 800 or in a folded design; in other embodiments, display screen 805 may be a flexible display screen, disposed on a curved or folded surface of terminal 800. Furthermore, display screen 805 may be configured as a non-rectangular irregular shape, i.e., a non-rectangular screen. Display screen 805 may be made of materials such as LCD (Liquid Crystal Display) or OLED (Organic Light-Emitting Diode).

[0102] The camera assembly 806 is used to acquire images or videos. In some embodiments, the camera assembly 806 includes a front-facing camera and a rear-facing camera. Typically, the front-facing camera is located on the front panel of the terminal, and the rear-facing camera is located on the back of the terminal. In some embodiments, there are at least two rear-facing cameras, which are any one of a main camera, a depth-sensing camera, a wide-angle camera, and a telephoto camera, to achieve background blurring by fusion of the main camera and the depth-sensing camera, panoramic shooting by fusion of the main camera and the wide-angle camera, VR (Virtual Reality) shooting, or other fusion shooting functions. In some embodiments, the camera assembly 806 may also include a flash. The flash can be a single-color temperature flash or a dual-color temperature flash. A dual-color temperature flash is a combination of a warm-light flash and a cool-light flash, which can be used for light compensation at different color temperatures.

[0103] The audio circuit 807 may include a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, converting the sound waves into electrical signals that are input to the processor 801 for processing, or input to the radio frequency circuit 804 to achieve voice communication. For stereo sound acquisition or noise reduction purposes, multiple microphones may be used, each located at a different part of the terminal 800. The microphone may also be an array microphone or an omnidirectional microphone. The speaker is used to convert the electrical signals from the processor 801 or the radio frequency circuit 804 into sound waves. The speaker may be a conventional diaphragm speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can convert electrical signals not only into audible sound waves but also into inaudible sound waves for purposes such as distance measurement. In some embodiments, the audio circuit 807 may also include a headphone jack.

[0104] Power supply 808 is used to supply power to the various components in terminal 800. Power supply 808 can be AC ​​power, DC power, a disposable battery, or a rechargeable battery. When power supply 808 includes a rechargeable battery, the rechargeable battery can be a wired rechargeable battery or a wireless rechargeable battery. A wired rechargeable battery is a battery that is charged via a wired line, while a wireless rechargeable battery is a battery that is charged via a wireless coil. The rechargeable battery can also be used to support fast charging technology.

[0105] In some embodiments, the terminal 800 further includes one or more sensors 809. The one or more sensors 809 include, but are not limited to, an accelerometer 810, a gyroscope 811, a pressure sensor 812, an optical sensor 813, and a proximity sensor 814.

[0106] Accelerometer 810 can detect the magnitude of acceleration on the three coordinate axes of a coordinate system established by terminal 800. For example, accelerometer 810 can be used to detect the components of gravitational acceleration on the three coordinate axes. Processor 801 can control display screen 805 to display the user interface in either a landscape or portrait view based on the gravitational acceleration signal acquired by accelerometer 810. Accelerometer 810 can also be used for games or for acquiring user motion data.

[0107] The gyroscope sensor 811 can detect the orientation and rotation angle of the terminal 800. The gyroscope sensor 811, in conjunction with the accelerometer sensor 810, can collect 3D motion data from the user on the terminal 800. Based on the data collected by the gyroscope sensor 811, the processor 801 can perform the following functions: motion sensing (e.g., changing the UI based on the user's tilt), image stabilization during shooting, game control, and inertial navigation.

[0108] The pressure sensor 812 can be disposed on the side bezel of the terminal 800 and / or the lower layer of the display screen 805. When the pressure sensor 812 is disposed on the side bezel of the terminal 800, it can detect the user's grip signal on the terminal 800, and the processor 801 can perform left / right hand recognition or quick operation based on the grip signal collected by the pressure sensor 812. When the pressure sensor 812 is disposed on the lower layer of the display screen 805, the processor 801 can control the operable controls on the UI interface based on the user's pressure operation on the display screen 805. The operable controls include at least one of button controls, scroll bar controls, icon controls, and menu controls.

[0109] An optical sensor 813 is used to collect ambient light intensity. In one embodiment, the processor 801 can control the display brightness of the display screen 805 based on the ambient light intensity collected by the optical sensor 813. Specifically, when the ambient light intensity is high, the display brightness of the display screen 805 is increased; when the ambient light intensity is low, the display brightness of the display screen 805 is decreased. In another embodiment, the processor 801 can also dynamically adjust the shooting parameters of the camera assembly 806 based on the ambient light intensity collected by the optical sensor 813.

[0110] The proximity sensor 814, also known as a distance sensor, is typically located on the front panel of the terminal 800. The proximity sensor 814 is used to detect the distance between the user and the front of the terminal 800. In one embodiment, when the proximity sensor 814 detects that the distance between the user and the front of the terminal 800 is gradually decreasing, the processor 801 controls the display screen 805 to switch from a screen-on state to a screen-off state; when the proximity sensor 814 detects that the distance between the user and the front of the terminal 800 is gradually increasing, the processor 801 controls the display screen 805 to switch from a screen-off state to a screen-on state.

[0111] Those skilled in the art will understand that Figure 8 The structure shown does not constitute a limitation on terminal 800 and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0112] Figure 9This is a schematic diagram of a server structure according to an embodiment of this application. The server 900 can vary considerably due to different configurations or performance. It may include one or more Central Processing Units (CPUs) 901 and one or more memories 902. The memory 902 stores at least one computer program, which is loaded and executed by the processor 901 to implement the integrated circuit verification method provided in the above-described method embodiments. Of course, the server may also have wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The server may also include other components for implementing device functions, which will not be elaborated here.

[0113] This application also provides a computer-readable storage medium storing at least one computer program. This computer program is loaded and executed by a processor of a computer device to implement the operations performed by the computer device in the integrated circuit verification method of the above embodiments. For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, and optical data storage device, etc.

[0114] In some embodiments, the computer program involved in the present application embodiments may be deployed and executed on a computer device, or executed on multiple computer devices located in one location, or executed on multiple computer devices distributed in multiple locations and interconnected through a communication network. Multiple computer devices distributed in multiple locations and interconnected through a communication network may constitute a blockchain system.

[0115] This application also provides a computer program product, including a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the integrated circuit verification method provided in the various optional implementations described above.

[0116] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0117] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for verifying integrated circuits, characterized in that, The method includes: An operation request for verifying the integrated circuit is obtained. If the total data length of the operation request exceeds the maximum data length that the reference model can process at one time, the operation request is split into multiple sub-operation requests. The data length of each sub-operation request does not exceed the maximum data length that the reference model can process at one time. The reference model is used to simulate the behavior of the integrated circuit under correct functional conditions in order to generate the bus transactions expected to be output by the integrated circuit. For any one of the plurality of sub-operation requests, a completion indication signal for the sub-operation request is generated based on the position of the sub-operation request among the plurality of sub-operation requests. The completion indication signal is used to indicate whether the reference model has obtained the complete operation request when it receives the sub-operation request. According to the positional order of the multiple sub-operation requests, the multiple sub-operation requests and their corresponding completion indication signals are sequentially input into the reference model to obtain the expected bus transaction; Based on the expected bus transaction, the actual bus transaction output by the integrated circuit based on the operation request is verified to obtain the verification result of the integrated circuit. The verification result is used to indicate whether the function of the integrated circuit is correct.

2. The method according to claim 1, characterized in that, The step of splitting the operation request into multiple sub-operation requests includes: If the starting address of the operation request is not located at the preset alignment boundary, a first sub-operation request is extracted from the operation request based on the starting address and the preset alignment boundary. The starting address of the first sub-operation request is the starting address of the operation request, and the data length of the first sub-operation request is the data length from the starting address to the preset alignment boundary. The preset alignment boundary is an integer multiple of the bus width of the integrated circuit. If the remaining data in the operation request does not exceed the maximum data length, then the remaining data will be treated as a new sub-operation request. If the length of the remaining data exceeds the maximum data length, a new sub-operation request is split from the remaining data based on the starting address and data length of the sub-operation request obtained from the previous split and the maximum data length. The starting address of each sub-operation request is the sum of the starting address of the previous sub-operation request and the data length of the previous sub-operation request, and the data length of the sub-operation request obtained in this split is the maximum data length.

3. The method according to claim 2, characterized in that, The method further includes: For any sub-operation request obtained by splitting, if the sub-operation request exceeds the maximum payload size configured by the integrated circuit, the sub-operation request is split to obtain a new sub-operation request, and the data length of each sub-operation request does not exceed the maximum payload size.

4. The method according to claim 1, characterized in that, For any one of the plurality of sub-operation requests, based on the position of the sub-operation request among the plurality of sub-operation requests, generating a completion indication signal for the sub-operation request includes: For any of the plurality of sub-operation requests, if the sub-operation request is a non-last sub-operation request among the plurality of sub-operation requests, then the completion indication signal of the sub-operation request is set to the first signal, and the first signal is used to indicate the incomplete state. If the sub-operation request is the last sub-operation request among the plurality of sub-operation requests, then the completion indication signal of the sub-operation request is set to the second signal, which is used to indicate the completion status.

5. The method according to claim 1, characterized in that, The actual bus transaction includes multiple actual sub-transactions, which are generated and output by the integrated circuit based on the operation request. The expected bus transaction includes multiple expected sub-transactions, each of which corresponds one-to-one with each sub-operation request and is generated by the reference model based on each sub-operation request. The process of verifying the actual bus transaction output by the integrated circuit based on the operation request, based on the expected bus transaction, to obtain the verification result of the integrated circuit, includes: Each actual sub-transaction in the actual bus transaction is stored sequentially in the first queue; Each expected sub-transaction in the expected bus transaction is stored sequentially in the second queue; When both the first queue and the second queue are not empty, an actual sub-transaction is taken from the head of the first queue and an expected bus transaction is taken from the head of the second queue for comparison. When all actual sub-transactions and expected sub-transactions match and both the first queue and the second queue are empty, the integrated circuit is determined to be functioning correctly.

6. The method according to claim 1, characterized in that, The operation request is a write request.

7. A verification device for integrated circuits, characterized in that, The device includes: The splitting module is used to acquire operation requests for verifying the integrated circuit. If the total data length of the operation request exceeds the maximum data length that the reference model can process at one time, the operation request is split into multiple sub-operation requests. The data length of each sub-operation request does not exceed the maximum data length that the reference model can process at one time. The reference model is used to simulate the behavior of the integrated circuit under correct functional conditions in order to generate the bus transactions expected to be output by the integrated circuit. The generation module is used to generate a completion indication signal for any one of the plurality of sub-operation requests based on the position of the sub-operation request among the plurality of sub-operation requests. The completion indication signal is used to indicate whether the reference model has obtained the complete operation request when it receives the sub-operation request. The processing module is used to sequentially input the multiple sub-operation requests and their corresponding completion indication signals into the reference model according to the positional order of the multiple sub-operation requests, so as to obtain the expected bus transaction; The verification module is used to verify the actual bus transaction output by the integrated circuit based on the operation request, based on the expected bus transaction, and to obtain the verification result of the integrated circuit. The verification result is used to indicate whether the function of the integrated circuit is correct.

8. A computer device, characterized in that, The computer device includes a processor and a memory, the memory being used to store at least one computer program, the at least one computer program being loaded by the processor and executed as the verification method for the integrated circuit according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store at least one computer program for performing the verification method for an integrated circuit according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the verification method for the integrated circuit as described in any one of claims 1 to 6.

Images