Transaction verification method and apparatus across chips

Abstract

The application provides a cross-chip transaction verification method and device. The method comprises the following steps: when a target transaction sent by a peer chip is received by a local chip, obtaining a transaction identifier and to-be-verified field information of the target transaction; querying a target index mapped by the transaction identifier in a peer mapping table, and based on the target index, querying a target cache entry pointed by the target index from the peer chip to obtain expected field information of the target transaction recorded in the target cache entry; and performing consistency verification on the expected field information and the to-be-verified field information. By storing a peer mapping table of a peer chip in a local chip, the local chip can accurately locate a target cache entry of a target transaction on the peer chip based on the peer mapping table, so as to realize cross-chip transaction verification by using expected field information of the target transaction recorded in the target cache entry.

Description

Technical Field

[0001] This specification relates to the field of integrated circuit technology, and in particular to a cross-chip transaction verification method and apparatus. Background Technology

[0002] Chips typically have the ability to verify local transactions. Specifically, when a chip receives a local transaction, the verification module (such as a scoreboard) in the verification environment (testbench) can allocate a cache entry (such as an entry object) for the transaction. This cache entry is used to store the expected field information (such as address, QoS, data, etc.) expected after the transaction is completed, and to verify the consistency between the actual field information to be verified after the transaction is completed and the expected field information, thereby obtaining the verification result.

[0003] With the continuous development of integrated circuit technology, multi-chip systems (such as multi-die packaging of server CPUs) have become mainstream. In multi-chip systems, there are situations where one chip transmits local transactions to other chips, which involves the need for cross-chip (Chip-to-Chip, C2C) transaction verification.

[0004] However, in chip verification-related technologies, there is only chip-side transaction verification (i.e., the chip-to-local transaction verification described above), and no cross-chip transaction verification capability. Summary of the Invention

[0005] In view of the above, one or more embodiments of this specification provide a cross-chip transaction verification method and apparatus, electronic device, and storage medium to solve the problems existing in the related art.

[0006] To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions: According to a first aspect of the embodiments of this specification, a cross-chip transaction verification method is provided for consistency verification between any two chips, wherein any chip stores a peer-to-peer mapping table of the peer chip, the peer-to-peer mapping table recording the mapping relationship between the index of the cache entry allocated by the peer chip for each transaction and the transaction identifier, the cache entry recording the expected field information of the transaction, the method comprising: When the local chip receives a target transaction sent by the peer chip, it obtains the transaction identifier and the field information to be verified of the target transaction. Query the target index mapped by the transaction identifier in the peer mapping table, and query the target cache entry pointed to by the target index from the peer chip based on the target index to obtain the expected field information of the target transaction recorded in the target cache entry; The consistency between the expected field information and the field information to be verified is verified.

[0007] Optionally, the expected field information includes the expected field and the expected field value, and the field information to be verified includes the field to be verified and the field value to be verified; the method further includes: The instruction code field related to the instruction code in the field to be verified is downgraded and mapped to obtain the downgraded instruction code field; The consistency verification of the expected field information and the field information to be verified includes: Compare the target expected field that is identical to the downgraded mapping instruction code field; The consistency of the expected field value of the target expected field and the field value to be verified of the downgraded instruction code field is verified.

[0008] Optionally, the method further includes: When the local chip receives the first local transaction, it parses the actual index of the cache entry allocated to the first local transaction from the resource allocation signal in the local chip; The real index is associated with the transaction identifier of the first local transaction as a mapping relationship, which is written into the local mapping table stored in the local chip, and the mapping relationship written in the local mapping table is synchronized to the peer mapping table stored in the peer chip.

[0009] Optionally, the method further includes: When the local chip receives a verification request for the second local transaction, it queries the local mapping table to see if there is an index mapped to the transaction identifier based on the transaction identifier of the second local transaction. If an index exists that maps to the transaction identifier, obtain the expected field information of the cached entry record pointed to by the index; The expected field information is then verified to be consistent with the information to be verified obtained after executing the second local transaction.

[0010] Optionally, the method further includes: If no index is found that maps to the transaction identifier, the second local transaction is added to the transaction queue. Once the new mapping relationship is written into the local mapping table, the query is performed again to check whether there is an index in the local mapping table that maps to the transaction identifier; If an index mapping to the transaction identifier exists, delete the second local transaction from the transaction queue.

[0011] Optionally, the cached entries also record an array of progress indicators for the completion status of transactions at each stage; After verifying the consistency between the expected field information and the information to be verified obtained after executing the second local transaction, the method further includes: Obtain the progress flag array of the cached entry record pointed to by the index of the second local transaction; Based on the transaction type of the second local transaction, obtain the conditions for determining transaction integrity; where different transaction types correspond to different conditions. The progress identifier array is compared with the determination condition. When it is determined that the second local transaction has been fully completed, the cache entry allocated to the second local transaction is released.

[0012] Optionally, the method further includes: When the local chip receives the code file of the target inspection task to be deployed, it defines an event trigger hook related to the transaction type according to the transaction type targeted by the target inspection task; When the event trigger hook is triggered, the code file of the target inspection task is called to execute the target inspection task.

[0013] Optionally, the method further includes: When the target inspection task does not have a corresponding transaction type, a background persistent hook corresponding to the target inspection task is defined in the background; wherein, the background persistent hook is used to call the code file of the target inspection task and execute the target inspection task periodically.

[0014] Optionally, the method further includes: The local chip acquires the third local transaction that triggers the event trigger hook; A general container is added to the cache entry of the third local transaction allocation. The general container is used to share the intermediate state information of the target inspection task. The shared intermediate state information can be read by other inspection tasks.

[0015] According to a second aspect of the embodiments of this specification, a cross-chip transaction verification apparatus is provided for consistency verification between any two chips, wherein any chip stores a peer mapping table of the peer chip, the peer mapping table recording the mapping relationship between the index of the cache entry allocated by the peer chip for each transaction and the transaction identifier, the cache entry recording the expected field information of the transaction, the apparatus comprising: The acquisition unit, when receiving a target transaction sent by the peer chip, acquires the transaction identifier and the field information to be verified of the target transaction. The query unit queries the target index mapped by the transaction identifier in the peer mapping table, and queries the target cache entry pointed to by the target index from the peer chip based on the target index to obtain the expected field information of the target transaction recorded in the target cache entry; The verification unit performs consistency verification on the expected field information and the field information to be verified.

[0016] According to a third aspect of the embodiments of this specification, an electronic device is provided, including a processor; a memory for storing processor-executable instructions; wherein the processor implements the above-described method by executing the executable instructions.

[0017] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided, wherein computer-readable instructions are stored on the computer-readable storage medium, and the computer-readable instructions, when executed by a processor, implement the above-described method.

[0018] The technical solutions provided in the embodiments of this specification may include the following beneficial effects: By storing a peer-to-peer mapping table of the peer chip on the local chip, the local chip can accurately locate the target cache entry of the target transaction on the peer chip based on this mapping table. This allows for cross-chip transaction verification using the expected field information of the target transaction recorded in the target cache entry. Specifically, since the peer-to-peer mapping table records the mapping relationship between the index of the cache entry allocated by the peer chip for each transaction and the transaction identifier, when the local chip receives a target transaction transmitted by the peer chip, it queries the target index in the peer-to-peer mapping table corresponding to the transaction identifier of the target transaction. It then queries the peer chip for the actual target cache entry of the target transaction pointed to by the target index, and uses the expected field information recorded in the target cache entry to perform consistency verification with the field information to be verified of the target transaction, thus obtaining the cross-chip transaction verification result. Attached Figure Description

[0019] Figure 1 A schematic diagram of a multi-chip system provided for an exemplary embodiment of this specification; Figure 2 A flowchart illustrating a cross-chip transaction verification method provided as an exemplary embodiment of this specification; Figure 3 A schematic diagram illustrating the sampling of cache entries provided for an exemplary embodiment of this specification; Figure 4 A schematic diagram illustrating the various stages of the transaction lifecycle provided for an exemplary embodiment of this specification; Figure 5 This is a schematic diagram of the structure of an electronic device containing a cross-chip transaction verification device, provided as an exemplary embodiment of this specification. Figure 6 This is a block diagram of a cross-chip transaction verification apparatus provided for an exemplary embodiment of this specification. Detailed Implementation

[0020] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0021] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0022] As previously mentioned, chip verification technologies only support single-chip transaction verification and lack cross-chip transaction verification capabilities. The reason for this is that when a local chip wants to verify a target transaction transmitted by a peer chip, the required expected field information is stored in the peer chip's cache entries. However, the local chip cannot accurately locate the cache entry corresponding to the target transaction in the peer chip, nor can it obtain the expected field information of the target transaction recorded in that cache entry. Therefore, the local chip cannot verify cross-chip target transactions.

[0023] Based on this, this application aims to provide a cross-chip transaction verification scheme. By storing a peer-to-peer mapping table of the peer chip on the local chip, the local chip can accurately locate the target cache entry of the target transaction on the peer chip based on the peer-to-peer mapping table. Then, it utilizes the expected field information of the target transaction recorded in the target cache entry to achieve cross-chip transaction verification. Specifically, since the peer-to-peer mapping table records the mapping relationship between the index of the cache entry allocated by the peer chip for each transaction and the transaction identifier, when the local chip receives the target transaction transmitted by the peer chip, it queries the target index in the peer-to-peer mapping table corresponding to the transaction identifier of the target transaction, queries the peer chip for the target cache entry pointed to by the target index, and performs consistency verification using the expected field information recorded in the target cache entry and the field information to be verified of the target transaction to obtain the cross-chip transaction verification result.

[0024] The cross-chip transaction verification method described in this specification will be explained in detail below with reference to the accompanying drawings.

[0025] Please refer to Figure 1 , Figure 1 This is a schematic diagram of a multi-chip system provided for an exemplary embodiment of this specification. Figure 1 Only two chips are shown in the diagram (i.e., chip A and chip B in the figure). In actual applications, there can be more than two chips, but the cross-chip transaction verification process between any two chips is the same. Figure 1 In this case, it is simplified to transaction verification between two chips.

[0026] exist Figure 1 In this system, each chip can store a peer-to-peer mapping table for the peer chip. For example, chip A stores a peer-to-peer mapping table for chip B, and chip B stores a peer-to-peer mapping table for chip A. The peer-to-peer mapping table records the mapping relationship between the index of the cache entry allocated to each transaction by the peer chip and the transaction identifier. For instance, the peer-to-peer mapping table of chip A records the mapping relationship between the index of the cache entry allocated to each transaction in chip A (e.g., transaction 1 / transaction 2 / transaction 3) and the transaction identifier (e.g., the mapping relationship between index 1 of transaction 1 and transaction identifier 1 of transaction 1, index 2 of transaction 2 and transaction identifier 2 of transaction 2, and index 3 of transaction 3 and transaction identifier 3 of transaction 3). The peer-to-peer mapping table of chip B records the mapping relationship between the index of the cache entry allocated to each transaction in chip B (e.g., transaction 4 / transaction 4 / transaction 4) and the transaction identifier (e.g., the mapping relationship between index 4 of transaction 4 and transaction identifier 4 of transaction 4, index 5 of transaction 5 and transaction identifier 5 of transaction 5, and index 6 of transaction 6 and transaction identifier 6 of transaction 6).

[0027] The index is used to locate cache entries in the peer chip. For example, based on index 2, the cache entry 2 allocated by chip A for transaction 2 can be accurately located.

[0028] Since each chip stores the peer-to-peer mapping table of the peer chip, when any chip receives a target transaction transmitted by the peer chip (the target transaction is a local transaction generated by the peer chip), although the chip does not have a target cache entry for the target transaction (i.e., the chip does not record the expected field information of the target transaction), it can use the transaction identifier of the target transaction to query the target index mapped by the transaction identifier in the peer-to-peer mapping table. This allows the chip to accurately locate the target cache entry pointed to by the target index and the expected field information recorded in the target cache entry.

[0029] like Figure 1As shown, chip A transmits local transaction 2 to chip B. Chip B can obtain the index 2 of transaction 2 by querying the peer mapping table of chip A, and then query the cache entry 2 pointed to by index 2 from chip A. The cache entry 2 records the expected field information of transaction 2. Using this expected field information, chip B can verify transaction 2, thus realizing cross-chip transaction verification.

[0030] Please refer to Figure 2 , Figure 2 The flowchart illustrates a cross-chip transaction verification method provided in an exemplary embodiment of this specification, used for consistency verification between any two chips. Each chip stores a peer-to-peer mapping table, which records the mapping relationship between the index of a cache entry allocated by the peer chip for each transaction and the transaction identifier. The cache entry records the expected field information of the transaction. The method includes: Step 210: When the local chip receives the target transaction sent by the remote chip, it obtains the transaction identifier and the field information to be verified of the target transaction. Typically, the transaction identifier can refer to information that uniquely corresponds to a transaction, such as a transaction ID, denoted as txn_id. For example, to distinguish different chips that might use the same transaction ID but correspond to different transactions, it can also be a concatenation of the transaction ID and the transaction initiator ID, forming {src_id, txn_id}, where src_id is the transaction initiator ID. Another example is that as time progresses, the chip may reuse previously completed transaction IDs; it can also be a concatenation of the transaction ID and a timestamp, forming {src_id, time}, where time is the timestamp. Alternatively, it can be a combination of the above, such as {src_id, txn_id, time}. This application does not limit the specific form of the transaction identifier.

[0031] The information to be verified can be sent by the peer chip. That is, after the peer chip completes the target transaction locally, it transmits the target transaction to the local chip. At the same time as transmitting the target transaction, the information to be verified generated by the completion of the target transaction is also transmitted.

[0032] It is understandable that the information to be verified may also be the information generated by the local chip after receiving the target transaction and completing the verification process on the local chip.

[0033] It is worth mentioning that cross-chip transactions can be transmitted based on cache coherency protocols such as Coherent Hub Interface (CHI).

[0034] Step 220: Query the target index mapped by the transaction identifier in the peer mapping table, and query the target cache entry pointed to by the target index from the peer chip based on the target index to obtain the expected field information of the target transaction recorded in the target cache entry.

[0035] As before Figure 1 As described in the embodiment, since the local chip stores the peer mapping table of the peer chip, when the local chip receives the target transaction transmitted by the peer chip (the target transaction is a local transaction generated by the peer chip), although the local chip does not have the target cache entry of the target transaction (that is, the local chip does not record the expected field information of the target transaction), it can use the transaction identifier of the target transaction to query the target index mapped by the transaction identifier in the peer mapping table. In this way, it can query the peer chip to accurately locate the target cache entry pointed to by the target index, and after locating the target cache entry, obtain the expected field information recorded in the target cache entry.

[0036] Step 230: Perform consistency verification between the expected field information and the field information to be verified.

[0037] After the local chip obtains the expected field information, it can perform consistency verification between the expected field information and the field information to be verified.

[0038] For example, both the expected field information and the field information to be verified can be composed of fields and field values; that is, the expected field information includes the expected field and the expected field value, and the field information to be verified includes the field to be verified and the field value to be verified. Therefore, consistency verification can be a comparison of whether the field values ​​of the same field are consistent, that is, a comparison of whether the expected field values ​​and the field values ​​to be verified corresponding to the same expected field and the field to be verified are consistent. If they are all consistent, the consistency verification is considered successful; if there are any inconsistencies, the consistency verification is considered unsuccessful.

[0039] In this application, the fields whose expected field information is the same as the field information to be verified may include Addr, QoS, Size, Mem_attr, LPID, Order, NS, LikelyShared, Excl_snpme, Exp_compack, Trace_tag, Opcode, etc.

[0040] Here, Addr stands for Address: the target address. It is used to specify the specific physical memory address that the current transaction will access.

[0041] QoS (Quality of Service): Transaction priority (typically ranging from 0 to 15). Primarily used for traffic scheduling to ensure that high real-time or critical IO requests are prioritized for forwarding and processing.

[0042] Size: Data length. Used to indicate the amount of data involved in the current transaction (e.g., 1 byte, 8 bytes, 64 bytes, etc.).

[0043] Mem_attr (Memory Attributes): Memory attributes. Used to ensure cache consistency, they are typically composed of attributes such as EarlyWrite Acknowledge (EWA), Device, Cacheable, and Allocate, indicating the memory type and cache allocation strategy of the transaction.

[0044] LPID (Logic Processor ID): A field belonging to system debugging and management, used to identify logic processors and manage operations such as persistence or stashing.

[0045] Order: Transaction order. Used for flow control and order preservation. Different values ​​will change the format of channel data packets to ensure that transactions are executed in the expected order.

[0046] NS (Non-Secure): Non-secure identifier. Used for security isolation, and combined with NSE to indicate access permissions to the Physical Address Space (PAS) (such as secure, insecure, root, or realm status).

[0047] LikelyShared: A possible sharing indicator. A cache performance optimization hint; when set, it indicates that the requested data may have already been shared among other requesters, helping the system optimize cache allocation.

[0048] Excl _snpme: Exclusive access and consistency related attributes. Used to ensure cache consistency, support exclusive access mechanisms, or indicate Snoop-related behavior.

[0049] Exp_compack (Expect Completion Acknowledge): Expected completion acknowledgment. Used for flow control ordering, indicating whether the requesting party needs a CompAck response from the receiving end to finally conclude the transaction.

[0050] Opcode (Operation Code): Instruction code. Used to indicate the type of operation performed by a transaction, such as write operation, read operation, etc.

[0051] Trace_tag: A trace tag. Used for system debugging and performance measurement, it carries debugging information to trace transaction paths and helps analyze system performance bottlenecks.

[0052] By verifying the consistency of the above fields, the requirements for cross-chip transaction verification scenarios can be fully covered.

[0053] In practical applications, some transactions require instruction code (such as opcode) conversion across chips. In such cases, downgrade mapping of the instruction code field is necessary. Downgrade mapping is a dedicated processing method for instruction code conversion. The instruction code field changes before and after downgrade mapping, therefore consistency verification of the changed instruction code is required.

[0054] In an exemplary embodiment, the instruction code field related to the instruction code in the field to be verified is downgraded and mapped to obtain the downgraded instruction code field; The above step 230, which verifies the consistency between the expected field information and the field information to be verified, may further include: Compare the target expected field that is identical to the downgraded mapping instruction code field; The consistency of the expected field value of the target expected field and the field value to be verified of the downgraded instruction code field is verified.

[0055] For example, the instruction code fields before and after the downgrade mapping can be shown in the following table: By using downgrade mapping, consistency verification can be performed on instruction code fields that are not originally in the field information to be verified, which can cover consistency problems that cannot be found by simple field comparison.

[0056] The peer-to-peer mapping table stored on the local chip in this application is from the perspective of the local chip. However, if the perspective is that of the peer chip, a copy of this peer-to-peer mapping table is also maintained locally. For the peer chip, the locally maintained mapping table can be called the local mapping table. Similarly, the local chip also maintains a local mapping table, which is also stored on the peer chip.

[0057] It's important to note that while chip-side transaction verification in chip-related technologies inherently possesses a mapping table—specifically, maintained by the verification module within the chip (such as a scoreboard)—the verification module in the verification environment is only responsible for allocating cached entries for transactions, not for building corresponding indexes for those entries. These indexes are allocated by the resource manager within the DUT (Design Under Test) (i.e., the actual index). Since the verification environment is completely isolated from the DUT, the verification module in the verification environment cannot directly access the indexes allocated by the DUT for the cached entries.

[0058] Traditionally, the verification module uses a round-robin guessing method, generating a guessed index that increments linearly according to transaction order. However, the actual index allocated by the DUT is not always linearly increasing. For example, if a transaction has a higher priority, its index will be allocated first; or, if a previously allocated index corresponds to a completed transaction, the allocated index will be released and idle, and will then be reassigned to a new transaction. These situations will cause the guessed index (the linearly increasing index) corresponding to the cached entries in the mapping table (i.e., the traditional mapping table) created by the verification module to be inconsistent with the actual index allocated by the DUT.

[0059] When the guessed index differs from the true index, the verification module, during the verification of the current transaction, uses the guessed index to locate a cached entry, and the expected field information recorded in that cached entry belongs to another transaction. Clearly, the expected field information of other transactions is inconsistent with the information to be verified in the current transaction, resulting in a consistency verification failure. This type of failure caused by an index error is called a false failure.

[0060] To avoid false failures, this application provides a precise sampling mechanism: In an exemplary embodiment, when the local chip receives a first local transaction, the index of the cache entry allocated to the first local transaction is parsed from the resource allocation signal in the local chip; The real index is associated with the transaction identifier of the first local transaction as a mapping relationship, which is written into the local mapping table stored in the local chip, and the mapping relationship written in the local mapping table is synchronized to the peer mapping table stored in the peer chip.

[0061] In this embodiment, such as Figure 3 As shown, the local chip can start an independent background process, which is used to block and sample the resource allocation signals of the DUT's internal resource manager through the monitoring interface. Figure 3The verification module parses the real index of the cached entry allocated to the first local transaction from the `alloc` signal. It then associates the real index with the transaction identifier of the first local transaction (such as `{src_id, txn_id}` as described earlier, creating a mapping relationship, and writes this mapping relationship to the local mapping table maintained by the verification module. If the local mapping table maintained by the verification module already records a mapping relationship with the same transaction identifier (a mapping relationship between the transaction identifier and the guessed index), the existing mapping relationship is replaced with the newly written mapping relationship between the transaction identifier and the real index. In some embodiments, the verification module may also stop using polling to generate the guessed index; in this case, the written mapping relationship will be stored as a new mapping relationship in the local mapping table.

[0062] In this way, it can be ensured that the indexes in the mapping table maintained locally by the verification module are the actual indexes allocated by the DUT.

[0063] After the new mapping relationship is written into the mapping table maintained by the verification module, the local chip also needs to synchronously notify the peer chip of the written mapping relationship so that the peer chip can synchronously update its stored peer mapping table.

[0064] For the local chip, as long as the verification module always keeps the index in its maintained local mapping table as the real index, it can accurately respond to verification requests for local transactions as shown below.

[0065] In an exemplary embodiment, when the local chip receives a verification request for a second local transaction, it queries the local mapping table to see if there is an index mapped to the transaction identifier based on the transaction identifier of the second local transaction. If an index exists that maps to the transaction identifier, obtain the expected field information of the cached entry record pointed to by the index; The expected field information is then verified to be consistent with the information to be verified obtained after executing the second local transaction.

[0066] In this embodiment, since the index in the local mapping table maintained by the verification module is the real index allocated by the DUT, when the verification module queries the index corresponding to the second local transaction, it can accurately locate the cached entry allocated to the second local transaction based on the index, and thus obtain the correct expected field information to perform consistency verification on the field information to be verified for the second local transaction. The resulting consistency verification result is accurate, and even if the consistency verification fails, it is not a false failure caused by an index error.

[0067] In one exemplary embodiment, if no index is found that maps to the transaction identifier, the second local transaction is added to the transaction queue; Once the new mapping relationship is written into the local mapping table, the query is performed again to check whether there is an index in the local mapping table that maps to the transaction identifier; If an index mapping to the transaction identifier exists, delete the second local transaction from the transaction queue.

[0068] In this embodiment, if the resource allocation signal (e.g., the alloc signal) for the second local transaction has not yet been sampled, but a verification request (e.g., flit) for the second local transaction arrives first, then there will be no mapping relationship related to the transaction identifier of the second local transaction in the local mapping table. In this case, the second local transaction is temporarily stored in a transaction queue (e.g., a peering queue). When the alloc signal for the second local transaction arrives and the mapping relationship between its transaction identifier and index is written into the local mapping table, the index corresponding to the second local transaction can be queried. To avoid the transaction queue from bloating, the transaction after the index is found will be deleted from the transaction queue.

[0069] The above embodiments can handle both cases correctly, whether the alloc signal arrives first (the transaction can directly query the index from the local mapping table) or the flit signal arrives first (the transaction cannot query the index from the local mapping table temporarily). There is no need to introduce artificial delays for the flit signal arriving first (artificially setting the flit delay execution time, such as a delay of 1 minute or 2 minutes).

[0070] Existing verification modules lack a mechanism to automatically identify "transaction lifecycle completion." This leads to situations where, even though a transaction has completed, the cached entries allocated to that transaction by the verification module are never released (i.e., cached entries are retained). This not only wastes limited cache resources but also causes false failures in transaction verification. Unlike the false failures caused by index inconsistencies mentioned earlier, these false failures are caused by cached entry retention. Specifically, when the DUT reuses the index of the same completed transaction for a new transaction, the cached entries retained in the verification module will be matched when verifying the new transaction, resulting in inconsistencies between the expected field information recorded in the retained cached entries and the field information to be verified in the new transaction.

[0071] To avoid false failures caused by cached entries remaining in the cache, this application provides a lifecycle management mechanism for cached entries: In one exemplary embodiment, the cache entry also records an array of progress identifiers indicating the completion status of a transaction at each stage; After verifying the consistency between the expected field information and the information to be verified obtained after executing the second local transaction, the method further includes: Obtain the progress flag array of the cached entry record pointed to by the index of the second local transaction; Based on the transaction type of the second local transaction, obtain the conditions for determining transaction integrity; where different transaction types correspond to different conditions. The progress identifier array is compared with the determination condition. When it is determined that the second local transaction has been fully completed, the cache entry allocated to the second local transaction is released.

[0072] In this embodiment, such as Figure 4 As shown, taking a write transaction as an example, the stages of a write transaction can sequentially include: stage 410 for allocating cache entries → stage 420 for receiving the DBIDResp response → stage 430 for receiving write data → stage 440 for sending and receiving Comp → stage 450 for waiting for CompAck if exp_compack is received. Finally, an integrity check 460 determines whether the write transaction has been fully completed. If it has been fully completed, the cache entries will be released.

[0073] In this context, stage 410, which involves allocating cache entries, refers to the cache entries allocated by the verification module for a local transaction after the local chip receives the transaction. The progress flag in stage 410 is set to true after the verification module successfully allocates the cache entries, and vice versa.

[0074] Phase 420, upon receiving the DBIDResp response, signifies that the requester of the local transaction sends a write request on the request channel (REQ). Upon receiving the request, the chip, if resources permit, allocates a write data buffer and returns a DBIDResp response via the response channel (RSP). The DBIDResp carries the DBID (Data Buffer ID). This DBID acts as a "token" or "ticket," informing the requester: "I have prepared a buffer for you to receive write data; please include this DBID when sending data on subsequent data channels." Upon receiving the DBIDResp response, the progress flag in phase 420 is set to true; otherwise, it is set to false.

[0075] Phase 430, upon receiving the write data response, refers to the requesting party sending one or more data flits on the Data Channel (DAT). These data flits must contain the DBID received in the previous step to ensure correct routing of data to the previously allocated write data buffer. If the write transaction's data length exceeds one flit, DataCheck, Poison, and data continuity flags (such as the DataID or Last flag) must also be set to indicate data integrity. The progress flag in Phase 430 is set to true upon receiving the write data and vice versa.

[0076] Phase 440 of the Comp response process refers to the completion indication phase of the write transaction. After successfully receiving and processing all write data, a Comp response is sent to the requester via the Response Channel (RSP). The Comp response signifies that the write transaction has been completed at the system consistency level. For the requester, receiving a Comp response means that it can safely release local resources associated with the transaction (such as write buffers) and can be confident that subsequent read operations will see the results of this write. Upon receiving the Comp response, the progress flag in phase 440 is set to true; otherwise, it is set to false.

[0077] If exp_compack and the CompAck waiting phase 450 is specified, it refers to the final acknowledgment phase of the write transaction (optional). CompAck is a response sent by the requesting party, and its sending requires the CompAck expectation flag to be explicitly set in the Comp response (i.e., exp_compack=1). Only then will the requesting party send CompAck after receiving the Comp response. If exp_compack=0, phase 450 is skipped. For transactions requiring phase 450, the progress flag for phase 450 will be set to true after the requesting party sends CompAck, and vice versa.

[0078] For example, since different transaction types may have different stages, the criteria for determining transaction integrity can also be determined according to the transaction type.

[0079] For example, in a write transaction, the conditions for determining transaction integrity could be: data has been written (progress flag in phase 430 is true), Comp has been written (progress flag in phase 440 is true), no CompAck is needed or CompAck is completed (progress flag in phase 450 is empty or true).

[0080] For reading transactions, the conditions for determining transaction integrity can be: Comp or CompData has been received, Comp or CompData has been sent, no CompAck is required, or the sending and receiving of CompAck is completed.

[0081] For Dataless / CMO transactions, the conditions for determining transaction integrity can be: a Comp has been issued, no CompAck is required, or CompAck has been completed.

[0082] For Snoop transactions, the conditions for determining transaction integrity can be: receiving SnpResp or SnpRespData, or sending SnpResp or SnpRespData.

[0083] If the progress identifier array of the current second local transaction meets the corresponding transaction integrity judgment condition, the release of the cached entries allocated to the second local transaction can be triggered. The release may include clearing the data recorded in the cached entries and deleting the mapping relationship between the index and transaction identifier corresponding to the cached entries recorded in the local mapping table. Furthermore, since a mapping relationship is deleted from the local mapping table, the peer chip also needs to be notified so that the peer mapping table stored in the peer chip also deletes the mapping relationship.

[0084] For example, before releasing the cached entry allocated to the second local transaction, check_entry_completeness (checking the integrity of the cached entry) can be called to perform a final check. For instance, if a critical response of a transaction is missed (such as not sending DBIDResp when popping a write transaction, or not sending ReadReceipt when popping an ordered read transaction), a COMPLETEENESS error can be reported, identifying the "early release / missed response" exception.

[0085] In the above embodiments, by recording the progress flag array of each stage of the transaction lifecycle and combining it with the preset transaction integrity judgment conditions, it is possible to accurately determine whether the current transaction has been fully completed. The cache entry corresponding to the transaction is released only when all the necessary progress flags required by the judgment conditions are true, which solves the problem of cache entry retention and avoids premature cache entry reclamation.

[0086] In practical applications, in addition to the aforementioned consistency verification, chip-local transaction verification can also include manually configured check tasks. Verification engineers can deploy one or more check tasks on any chip according to testing requirements, and different verification engineers can deploy check tasks on the same chip simultaneously. Since check tasks need to be executed by the verification module, existing technologies require all check task code to be deployed in the verification module's source files, which can lead to code merge conflicts.

[0087] Therefore, this application no longer deploys the code for the inspection tasks in the source files of the verification module, but instead generates the code for each inspection task as an independent code file and provides a mechanism for calling the code file for the inspection tasks: Upon receiving the code file for the target inspection task to be deployed, define event trigger hooks related to the transaction type targeted by the target inspection task; When the event trigger hook is triggered, the code file of the target inspection task is called to execute the target inspection task.

[0088] In the above embodiments, since the code for the inspection task is no longer deployed to the source file of the verification module, and the code file for each inspection task is an independent entity, even if multiple verification engineers add inspection tasks in parallel, there will be no code merging conflict.

[0089] It should be noted that, in order to enable the inspection task, registration can also be performed using the chip's UVM (Universal Verification Methodology) factory mechanism, registering the target inspection task to the registration list. This registration list (e.g., register_list) is a queue-like structure; each inspection task needs to have a line of registration information added to the end of the registration list when it registers. This registration information is used to locate the code file of the inspection task.

[0090] Typically, the checks invoked by event-triggered hooks are simple field comparison checks (e.g., checking whether the value of a certain field meets the requirements).

[0091] In related technologies, traditional inspection tasks are event-triggered, and these tasks can be invoked through the aforementioned event-triggered hooks. Furthermore, event-triggered inspection tasks are typically pure field comparison checks (e.g., checking whether the value of a certain field meets the requirements).

[0092] However, traditional event-triggered inspection tasks alone cannot cover inspection requirements such as "continuous background monitoring of RTL internal signals (e.g., monitoring a certain invariant signal to ensure it never takes an illegal value)." These inspection requirements necessitate that the inspection task be continuously running to monitor RTL internal signals, while traditional event-triggered inspection tasks can only execute when a specific event occurs. Therefore, this application also provides the following implementation method: In one exemplary embodiment, when the target inspection task does not have a corresponding transaction type, a background persistent hook corresponding to the target inspection task is defined in the background; wherein, the background persistent hook is used to call the code file of the target inspection task and periodically execute the target inspection task.

[0093] In this embodiment, in addition to providing the aforementioned event-based trigger hooks, a background persistent hook that can be monitored throughout the process is also supported.

[0094] For the target inspection task of "full-process background resident monitoring of RTL internal signals", no transaction type needs to be configured. Therefore, when it is determined that there is no corresponding transaction type for the target inspection task, it can be assumed that the target inspection task is used for full-process background resident monitoring of RTL internal signals. At this time, a background resident hook can be started in the background. This background resident hook can periodically monitor the internal signal invariants of RTL; when an illegal value is found in the internal signal, an alarm will be triggered.

[0095] It should be noted that both the background persistent hooks and the event-triggered hooks can inherit from the base class (such as uvm_object), which can maintain the persistent state of the event-triggered hooks and the background persistent hooks.

[0096] In related technologies, intermediate states cannot be shared between different inspection tasks (for example, a timeout counter set by one inspection task cannot be read by another inspection task). Therefore, this application also provides the following implementation method: In one exemplary embodiment, the local chip acquires a third local transaction that triggers the event trigger hook; A general container is added to the cache entry of the third local transaction allocation. The general container is used to share the intermediate state information of the target inspection task. The shared intermediate state information can be read by other inspection tasks.

[0097] In this embodiment, the general container may include a sticky note board (int chk_state[string]), which adds a sticky note board to the cache entries so that the target inspection task can write shared intermediate state information.

[0098] It should be noted that since the same transaction can trigger multiple different inspection tasks, inspection tasks can be isolated by namespace key (such as timeout.armed) and write their shared intermediate state information into the cache subspace isolated by their namespace. This can effectively distinguish them from the intermediate state information shared by other inspection tasks.

[0099] It should be noted that the sticky note board has a single write constraint, that is, each key is only allowed to be written by the corresponding inspection task, while the other inspection tasks are read-only, thereby avoiding competition and tampering.

[0100] After introducing the methods of exemplary embodiments of this specification, the apparatus, electronic devices, and computer-readable storage media of exemplary embodiments of this specification will now be described.

[0101] In an exemplary embodiment of this specification, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor implements the method described above by executing the executable instructions.

[0102] Figure 5 This is a schematic structural diagram of an electronic device provided in an exemplary embodiment. Please refer to... Figure 5 At the hardware level, the electronic device includes a processor, internal bus, network interface, memory, and non-volatile memory, and may also include other hardware required for business operations. One or more embodiments of this specification can be implemented in software, such as the processor reading the corresponding computer program from non-volatile memory into memory and then running it. Of course, besides software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software. That is to say, the execution entity of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0103] Please refer to Figure 6 In one software implementation, a cross-chip transaction verification device is provided for consistency verification between any two chips. Each chip stores a peer-to-peer mapping table for the peer chip. The peer-to-peer mapping table records the mapping relationship between the index of a cache entry allocated by the peer chip for each transaction and the transaction identifier. The cache entry records the expected field information of the transaction. The device includes: The acquisition unit 710 acquires the transaction identifier and the field information to be verified of the target transaction when the local chip receives the target transaction sent by the remote chip. The query unit 720 queries the target index mapped by the transaction identifier in the peer mapping table, and queries the target cache entry pointed to by the target index from the peer chip based on the target index to obtain the expected field information of the target transaction recorded in the target cache entry; Verification unit 730 performs consistency verification on the expected field information and the field information to be verified.

[0104] Optionally, the expected field information includes the expected field and the expected field value, and the field information to be verified includes the field to be verified and the field value to be verified; the device further includes: The downgrade subunit performs downgrade mapping on the instruction code field related to the instruction code in the field to be verified, and obtains the downgraded instruction code field; The verification unit 730 is further configured to compare the target expected field that is the same as the downgraded instruction code field; and to perform consistency verification between the expected field value of the target expected field and the field value to be verified of the downgraded instruction code field.

[0105] Optionally, the device further includes: The mapping table update subunit, when the local chip receives the first local transaction, parses the real index of the cache entry allocated to the first local transaction from the resource allocation signal in the local chip; associates the real index with the transaction identifier of the first local transaction as a mapping relationship, writes it into the local mapping table stored in the local chip, and synchronizes the mapping relationship written in the local mapping table to the peer mapping table stored in the peer chip.

[0106] Optionally, the device further includes: When the local chip receives a verification request for the second local transaction, the local verification subunit queries the local mapping table to see if there is an index mapped to the transaction identifier based on the transaction identifier of the second local transaction; if there is an index mapped to the transaction identifier, it obtains the expected field information of the cached entry record pointed to by the index; and performs consistency verification between the expected field information and the information to be verified obtained after the second local transaction.

[0107] Optionally, the device further includes: If no index mapping to the transaction identifier exists in the queue storage subunit, the second local transaction is added to the transaction queue. After the local mapping table is written with a new mapping relationship, the query is performed again to see if an index mapping to the transaction identifier exists in the local mapping table. If an index mapping to the transaction identifier exists, the second local transaction is deleted from the transaction queue.

[0108] Optionally, the cached entries also record an array of progress indicators for the completion status of transactions at each stage; Following the local verification subunit, the following is also included: Release the subunit, obtain the progress identifier array of the cached entry record pointed to by the index of the second local transaction; obtain the judgment condition for transaction integrity according to the transaction type of the second local transaction; wherein, different transaction types correspond to different judgment conditions; compare the progress identifier array with the judgment condition, and when it is determined that the second local transaction has been fully completed, release the cached entry allocated to the second local transaction.

[0109] Optionally, the device further includes: The inspection subunit, when the local chip receives the code file of the target inspection task to be deployed, defines an event trigger hook related to the transaction type targeted by the target inspection task; when the event trigger hook is triggered, it calls the code file of the target inspection task and executes the target inspection task.

[0110] Optionally, the inspection subunit is further configured to define a background persistent hook corresponding to the target inspection task in the background when the target inspection task does not have a corresponding transaction type; wherein, the background persistent hook is used to call the code file of the target inspection task and periodically execute the target inspection task.

[0111] Optionally, the device further includes: The state sharing subunit allows the local chip to acquire a third local transaction that triggers the event trigger hook; a general container is added to the cache entry allocated by the third local transaction, the general container being used to share the intermediate state information of the target inspection task, and the shared intermediate state information being readable by other inspection tasks.

[0112] For details on the implementation process of the functions and roles of each module in the above-mentioned device, please refer to the implementation process of the corresponding steps in the above-mentioned cross-chip transaction verification method. For relevant parts, please refer to the description of the method implementation method. It will not be repeated here.

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

[0114] The systems, devices, modules, or units described in the above embodiments can be implemented by a computer or entity, or by a product with a certain function. A typical implementation device is a computer, which can be a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0115] In exemplary embodiments of this specification, a computer-readable storage medium is also provided, on which computer-readable instructions are stored, which, when executed by a processor, implement the aforementioned method embodiments.

[0116] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0117] Program code contained on a computer-readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RE, or any suitable combination thereof.

[0118] Program code for performing the operations described herein can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0119] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0120] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0121] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this specification. The singular forms “a,” “described,” and “the” used in one or more embodiments of this specification and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0122] It should be understood that although the terms first, second, third, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of one or more embodiments of this specification, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "in response to a determination," or "when," or "in the event of a determination."

[0123] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the protection scope of one or more embodiments of this specification.

Claims

1. A cross-chip transaction verification method, characterized in that, For consistency verification between any two chips, wherein any chip stores a peer-to-peer mapping table of the peer chip, the peer-to-peer mapping table records the mapping relationship between the index of the cache entry allocated by the peer chip for each transaction and the transaction identifier, the cache entry records the expected field information of the transaction, the method includes: When the local chip receives a target transaction sent by the remote chip, it obtains the transaction identifier and the field information to be verified of the target transaction. Query the target index mapped by the transaction identifier in the peer mapping table, and query the target cache entry pointed to by the target index from the peer chip based on the target index to obtain the expected field information of the target transaction recorded in the target cache entry; The consistency between the expected field information and the field information to be verified is verified.

2. The method according to claim 1, characterized in that, The expected field information includes the expected field and the expected field value; the field information to be verified includes the field to be verified and the field value to be verified; the method further includes: The instruction code field related to the instruction code in the field to be verified is downgraded and mapped to obtain the downgraded instruction code field; The consistency verification of the expected field information and the field information to be verified includes: Compare the target expected field that is identical to the downgraded mapping instruction code field; The consistency of the expected field value of the target expected field and the field value to be verified of the downgraded instruction code field is verified.

3. The method according to claim 1, characterized in that, The method further includes: When the local chip receives the first local transaction, it parses the actual index of the cache entry allocated to the first local transaction from the resource allocation signal in the local chip; The real index is associated with the transaction identifier of the first local transaction as a mapping relationship, which is written into the local mapping table stored in the local chip, and the mapping relationship written in the local mapping table is synchronized to the peer mapping table stored in the peer chip.

4. The method according to claim 3, characterized in that, The method further includes: When the local chip receives a verification request for the second local transaction, it queries the local mapping table to see if there is an index mapped to the transaction identifier based on the transaction identifier of the second local transaction. If an index exists that maps to the transaction identifier, obtain the expected field information of the cached entry record pointed to by the index; The expected field information is then verified to be consistent with the information to be verified obtained after executing the second local transaction.

5. The method according to claim 4, characterized in that, The method further includes: If no index is found that maps to the transaction identifier, the second local transaction is added to the transaction queue. Once the new mapping relationship is written into the local mapping table, the query is performed again to check whether there is an index in the local mapping table that maps to the transaction identifier; If an index mapping to the transaction identifier exists, delete the second local transaction from the transaction queue.

6. The method according to claim 4, characterized in that, The cache entries also record an array of progress indicators for the completion status of transactions at each stage; After verifying the consistency between the expected field information and the information to be verified obtained after executing the second local transaction, the method further includes: Obtain the progress flag array of the cached entry record pointed to by the index of the second local transaction; Based on the transaction type of the second local transaction, obtain the conditions for determining transaction integrity; where different transaction types correspond to different conditions. The progress identifier array is compared with the determination condition. When it is determined that the second local transaction has been fully completed, the cache entry allocated to the second local transaction is released.

7. The method according to claim 1, characterized in that, The method further includes: When the local chip receives the code file of the target inspection task to be deployed, it defines an event trigger hook related to the transaction type according to the transaction type targeted by the target inspection task; When the event trigger hook is triggered, the code file of the target inspection task is called to execute the target inspection task.

8. The method according to claim 7, characterized in that, The method further includes: When the target inspection task does not have a corresponding transaction type, a background persistent hook corresponding to the target inspection task is defined in the background; wherein, the background persistent hook is used to call the code file of the target inspection task and execute the target inspection task periodically.

9. The method according to claim 7, characterized in that, The method further includes: The local chip acquires the third local transaction that triggers the event trigger hook; A general container is added to the cache entry of the third local transaction allocation. The general container is used to share the intermediate state information of the target inspection task. The shared intermediate state information can be read by other inspection tasks.

10. A cross-chip transaction verification device, characterized in that, For consistency verification between any two chips, wherein any chip stores a peer-to-peer mapping table of the peer chip, the peer-to-peer mapping table records the mapping relationship between the index of the cache entry allocated by the peer chip for each transaction and the transaction identifier, the cache entry records the expected field information of the transaction, the device includes: The acquisition unit, when receiving a target transaction sent by the peer chip, acquires the transaction identifier and the field information to be verified of the target transaction. The query unit queries the target index mapped by the transaction identifier in the peer mapping table, and queries the target cache entry pointed to by the target index from the peer chip based on the target index to obtain the expected field information of the target transaction recorded in the target cache entry; The verification unit performs consistency verification on the expected field information and the field information to be verified.

11. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1-9 by executing the executable instructions.

12. A computer-readable storage medium, characterized in that, It stores computer-readable instructions that, when executed by a processor, implement the method as described in any one of claims 1-9.

Images