Method and device for verifying memory consistency of multi-core processor in development stage

Abstract

The invention relates to the technical field of multi-core processors, and provides a memory consistency verification method and device for a multi-core processor in a development stage, and the method comprises the steps: obtaining a constraint relation set of a program sequence of random verification excitation; monitoring memory access operation executed by a to-be-tested device in the random verification excitation, wherein the to-be-tested device comprises a module-level to-be-tested device; generating a forward instruction set corresponding to each memory access operation; judging whether each forward instruction set meets a corresponding constraint relationship subset in the constraint relationship set or not; and if yes, confirming that the to-be-tested device conforms to the memory consistency. According to the embodiment of the invention, memory consistency verification can be carried out on the multi-core processor in a development stage in advance.

Description

Technical Field

[0001] This application relates to the field of multi-core processor technology, and in particular to a method and apparatus for verifying memory consistency of a multi-core processor in the development stage. Background Technology

[0002] With the widespread adoption of multi-core processor architectures, it has become commonplace for multiple processing cores to access shared memory resources based on out-of-order execution. However, in out-of-order execution scenarios, the lack of unified constraints on memory operations by different cores in a multi-core system can lead to uncertainty in program execution results, resulting in issues such as data races and state inconsistencies. Therefore, memory consistency verification needs to be performed during the development phase of multi-core processors.

[0003] Traditional methods for performing memory consistency verification during the development phase (such as litmus tests) rely on a complete system execution environment and require the completion of the full Register-Transfer Level (RTL) design. However, this approach is time-consuming; if memory consistency errors are discovered at this stage, locating the cause and fixing them are extremely costly. Summary of the Invention

[0004] The purpose of this application is to provide a method and apparatus for verifying memory consistency of a multi-core processor during the development stage, so as to realize the memory consistency verification of the multi-core processor during the development stage in advance.

[0005] To achieve the above objectives, in one aspect, embodiments of this application provide a method for verifying memory consistency of a multi-core processor during the development phase, including:

[0006] Obtain the set of constraints for the program order of random verification stimuli;

[0007] The device under test (DUT) is monitored to perform memory access operations in the random verification stimulus, and the DUT includes module-level DUTs.

[0008] Generate a set of forward instructions corresponding to each memory access operation;

[0009] Determine whether each of the forward instruction sets satisfies the corresponding subset of constraint relationships in the constraint relationship set;

[0010] If the conditions are met, the device under test is confirmed to meet memory consistency requirements.

[0011] In the memory consistency verification method for multi-core processors during the development phase of this application embodiment, the step of obtaining the set of constraint relationships for the program order of random verification stimuli includes:

[0012] The instruction set of the random verification stimulus is mapped to a first directed acyclic graph; the nodes in the first directed acyclic graph represent instructions, and the directed edges in the first directed acyclic graph represent a subset of constraint relationships between instructions;

[0013] The first directed acyclic graph is subjected to a transitive reduction to remove redundant constraint edges in the first directed acyclic graph, thereby obtaining a second directed acyclic graph.

[0014] Determine the in-degree of each node in the second directed acyclic graph;

[0015] Generate a subset of constraint relationships for each node based on its in-degree;

[0016] The combination of each of the aforementioned subsets of constraints is determined as the set of constraints for the program order of the random verification stimulus.

[0017] In the memory consistency verification method for multi-core processors during the development phase of this application embodiment, the step of monitoring the memory access operation performed by the device under test in the random verification stimulus includes:

[0018] The memory access operation in the random verification stimulus is performed based on probe monitoring of the device under test;

[0019] The global visibility time of the memory access operation is determined based on the instruction type and memory attributes of the memory access operation.

[0020] In the memory consistency verification method for multi-core processors during the development phase of this application embodiment, determining the global visibility time of the memory access operation based on the instruction type and memory attributes of the memory access operation includes:

[0021] Determine the instruction type of the memory access operation;

[0022] If the memory access operation is a load instruction, then confirm the memory attributes of the load instruction;

[0023] When the memory attribute of the load instruction is cacheable, the moment when the load instruction retrieves data from the L1 cache is determined as the global visibility moment of the load instruction;

[0024] When the memory attribute of the load instruction is non-cacheable, the moment when the load instruction initiates a read request to the lower-level module is determined as the global visibility moment of the load instruction.

[0025] In the memory consistency verification method for multi-core processors during the development phase of this application embodiment, the step of determining the global visibility time of the memory access operation based on the instruction type and memory attributes of the memory access operation further includes:

[0026] If the memory access operation is a store instruction, then confirm the memory attributes of the store instruction;

[0027] When the memory attribute of the store instruction is cacheable, the moment when the store instruction initiates a write request to the L1 cache is determined as the global visibility moment of the store instruction;

[0028] When the memory attribute of the store instruction is non-cacheable, the moment when the store instruction initiates a write request to the lower-level module is determined as the global visibility moment of the store instruction.

[0029] In the memory consistency verification method for multi-core processors during the development phase of this application embodiment, the step of determining the global visibility time of the memory access operation based on the instruction type and memory attributes of the memory access operation further includes:

[0030] If the memory access operation is a fence instruction, then the time when the fence instruction is reclaimed is determined as the time when the fence instruction becomes globally visible.

[0031] In the memory consistency verification method for multi-core processors during the development phase of this application embodiment, generating the forward instruction set corresponding to each memory access operation includes:

[0032] The global visibility times of each memory access operation are sorted in time sequence to obtain the global visibility order of each memory access operation.

[0033] Determine the set of forward instructions for each memory access operation under the globally visible order.

[0034] In the memory consistency verification method for multi-core processors during the development phase of this application embodiment, determining whether each set of forward instructions satisfies the corresponding subset of constraints in the constraint set includes:

[0035] Identify the subset of target constraint relations in the constraint relation set corresponding to each of the forward instruction sets;

[0036] Determine whether each subset of the target constraint relations is a subset of the corresponding forward instruction set;

[0037] If each of the target constraint subsets is a subset of the corresponding forward instruction set, then the device under test is confirmed to meet memory consistency.

[0038] In the memory consistency verification method for multi-core processors during the development phase of this application embodiment, the module-level device under test includes a loading memory unit.

[0039] On the other hand, embodiments of this application also provide a memory consistency verification device for multi-core processors during the development phase, comprising:

[0040] The reference model module is used to obtain the set of constraint relationships for the program order of random verification stimuli;

[0041] The device under test (DUT) monitoring module is used to monitor the DUT's execution of memory access operations in the random verification stimulus, wherein the DUT includes module-level DUTs; and to generate a set of forward instructions corresponding to each memory access operation.

[0042] The memory order check module is used to determine whether each set of forward instructions satisfies the corresponding subset of constraint relationships in the constraint relationship set; if so, it is confirmed that the device under test conforms to memory consistency.

[0043] In the memory consistency verification device for multi-core processors during the development phase of this application embodiment, the device supports at least one of the following memory consistency models:

[0044] RISC-V weak memory ordering model;

[0045] RISC-V complete memory ordering model;

[0046] Complete storage ordering model;

[0047] ARM memory model.

[0048] On the other hand, embodiments of this application also provide a multi-core processor chip, the multi-core processor chip including a memory consistency verification device, the memory consistency verification device being configured to execute instructions of the above method.

[0049] On the other hand, embodiments of this application also provide a computer device, including a memory, a processor, and a computer program stored in the memory, wherein the computer program, when run by the processor, executes instructions of the above-described method.

[0050] On the other hand, embodiments of this application also provide a computer storage medium storing a computer program thereon, wherein the computer program, when run by the processor of a computer device, executes instructions for the above-described method.

[0051] On the other hand, embodiments of this application also provide a computer program product, which includes a computer program that, when run by the processor of a computer device, executes instructions for the above-described method.

[0052] As can be seen from the technical solutions provided in the above embodiments of this application, in the embodiments of this application, based on obtaining the constraint relationship set of the program order of random verification stimuli, the module-level device under test (DUT) is monitored to perform memory access operations in the random verification stimuli, and a forward instruction set corresponding to each memory access operation is generated. When each forward instruction set satisfies the corresponding constraint relationship subset in the constraint relationship set, it is confirmed that the module-level DUT meets the memory consistency requirements. In this way, memory consistency verification can be performed on each core module-level DUT during the development process. When each core module-level DUT passes the memory consistency verification, the memory inconsistency caused by the corresponding module-level DUT in multi-core processors can be reduced or eliminated without waiting for the complete RTL design to be completed (e.g., the core design or multi-core system design to be completed) before performing memory consistency verification. This achieves memory consistency verification of multi-core processors in the development stage in advance. Attached Figure Description

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

[0054] Figure 1 This paper illustrates a schematic diagram of the application environment for memory consistency verification of multi-core processors during the development phase in some embodiments of this application.

[0055] Figure 2 A flowchart of a memory consistency verification method for a multi-core processor during the development phase is shown in some embodiments of this application;

[0056] Figure 3 It shows Figure 2 The flowchart shown illustrates the set of constraint relationships for obtaining the program sequence of random verification stimuli in the method described.

[0057] Figure 4 This illustration shows a schematic diagram of a DAG graph constructed based on a program sequence of random verification stimuli in an exemplary embodiment of this application;

[0058] Figure 5 It shows Figure 4 The diagram shown is a schematic of the DAG obtained after the DAG graph has undergone transitive reduction processing.

[0059] Figure 6 It shows Figure 2The flowchart shown illustrates the method of monitoring memory access operations of the device under test based on random verification stimuli using probes.

[0060] Figure 7 It shows Figure 2 The flowchart shown illustrates the method for generating the forward instruction set corresponding to each memory access operation.

[0061] Figure 8 It shows Figure 2 The flowchart shown illustrates the method for determining whether each set of forward instructions satisfies the corresponding subset of constraints in the constraint set.

[0062] Figure 9 The present application shows a structural block diagram of a memory consistency verification device for a multi-core memory access system in some embodiments;

[0063] Figure 10 A structural block diagram of a computer device in some embodiments of this application is shown.

[0064] [Explanation of Labels in the Attached Image]

[0065] 10. Input source;

[0066] 20. Device under test;

[0067] 30. Memory consistency verification device;

[0068] 91. Reference Model Module;

[0069] 92. Device under test monitoring module;

[0070] 93. Memory order check module;

[0071] 1002. Computer equipment;

[0072] 1004, Processor;

[0073] 1006. Memory;

[0074] 1008. Drive mechanism;

[0075] 1010. Input / output interface;

[0076] 1012. Input devices;

[0077] 1014. Output devices;

[0078] 1016. Presentation device;

[0079] 1018. Graphical User Interface;

[0080] 1020. Network interface;

[0081] 1022. Communication link;

[0082] 1024. Communication bus. Detailed Implementation

[0083] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0084] It should be noted that in the embodiments of this application, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved are all information and data authorized and agreed upon by the user and fully authorized by all parties. That is, the acquisition, transmission, storage, use, and processing of data in the technical solution of this application all comply with the relevant provisions of national laws and regulations.

[0085] Figure 1 The diagram illustrates an application environment for memory consistency verification of a multi-core processor during the development phase in some embodiments of this application. This application environment includes an input source 10, a device under test (DUT) 20, and a memory consistency verification device 30. The input source 10 can provide random verification stimuli for memory consistency verification to the memory consistency verification device 30. The memory consistency verification device 30 can obtain a set of constraint relationships for the program order of the random verification stimuli; monitor the DUT 20 executing memory access operations in the random verification stimuli, where the DUT includes module-level DUTs; generate a set of forward instructions corresponding to each memory access operation; determine whether each set of forward instructions satisfies the corresponding subset of constraint relationships in the constraint relationship set; if satisfied, confirm that the DUT 20 conforms to memory consistency. Embodiments of this application can perform memory consistency verification of a multi-core processor during the development phase in advance.

[0086] This application provides a method for verifying memory consistency of a multi-core processor during the development phase, which can be applied to the aforementioned memory consistency verification device. (Refer to...) Figure 2 As shown in some embodiments of this application, the memory consistency verification method for multi-core processors during the development phase may include the following steps:

[0087] Step 201: Obtain the set of constraints for the program order of random verification stimuli.

[0088] Step 202: Monitor the memory access operation performed by the device under test in the random verification stimulus. The device under test includes module-level devices under test.

[0089] Step 203: Generate the forward instruction set corresponding to each memory access operation.

[0090] Step 204: Determine whether each of the forward instruction sets satisfies the corresponding subset of constraint relations in the constraint relation set; if so, proceed to step 205; otherwise, proceed to step 206.

[0091] Step 205: Confirm that the device under test meets memory consistency requirements.

[0092] Step 206: Confirm that the device under test does not meet memory consistency requirements.

[0093] In this embodiment, based on the set of constraints for the program order of random verification stimuli, the memory access operations in the random verification stimuli are monitored by the block-level device under test (DUT), and a set of forward instructions corresponding to each memory access operation is generated. When each set of forward instructions satisfies the corresponding subset of constraints in the set of constraints, the module-level DUT is confirmed to meet memory consistency. Thus, memory consistency verification can be performed on each core module-level DUT during its development process. When each core module-level DUT passes memory consistency verification, the memory inconsistency caused by the corresponding module-level DUT in multi-core processors can be reduced or eliminated without waiting for the complete RTL design to be completed (e.g., core design completion or multi-core system design completion) before performing memory consistency verification. This achieves memory consistency verification of multi-core processors in the development stage in advance.

[0094] Randomized verification stimuli are sequences of test instructions that conform to specific constraints, generated by an algorithmic model within a verification environment. Their order can be considered the program sequence. The constraints governing the program sequence can be extracted from the program sequence of the randomized verification stimuli.

[0095] In some embodiments of this application, the set of constraints on the program order of random verification stimuli can be represented by a Directed Acyclic Graph (DAG); thus, complex sequence constraints can be made intuitive; more importantly, by introducing a DAG, different graph construction rules can be easily configured, flexibly supporting multiple memory consistency models and microarchitecture custom rules; thereby improving the flexibility and scalability of memory consistency verification for multi-core processors during the development phase.

[0096] refer to Figure 3 As shown in some embodiments of this application, obtaining the set of constraint relationships for the program order of random verification stimuli may include the following steps:

[0097] Step 301: Map the instruction set of the random verification stimulus to a first directed acyclic graph.

[0098] In the embodiments of this application, nodes in the first directed acyclic graph represent instructions, and directed edges in the first directed acyclic graph represent a subset of constraint relationships between instructions.

[0099] For example, in an exemplary embodiment of this application, if the program order of a random verification stimulus is ABCDEFG (containing 7 instructions), the sorting nodes (referred to as nodes, each node corresponding to one instruction) are created in the order of the program order, and each sorting node is added to the directed acyclic graph in turn; the process of building the directed acyclic graph can be as follows: Figure 4 (See partial view on the right). Figure 4 The constraints represented by the final DAG graph include:

[0100] A→C, A→E, B→C, C→E, D→E, E→F, E→G, F→G

[0101] Taking A→C as an example, it means that node C depends on node A. It should be noted that if a node has no edges with any other node, it is an isolated node and its order does not need to be checked. Similarly, if there are no constraints between two sets of nodes, then these two sets will form two directed acyclic graphs.

[0102] Step 302: Perform a transitive reduction on the first directed acyclic graph to remove redundant constraint edges in the first directed acyclic graph and obtain a second directed acyclic graph.

[0103] In graph theory, transitive reduction is a simplification technique based on DAG graphs, which eliminates redundant information by arranging vertices in a linear order. In the embodiments of this application, by performing transitive reduction on the first directed acyclic graph, redundant constraint edges in the first directed acyclic graph can be removed, thereby reducing the computational complexity and time cost of subsequent comparison operations.

[0104] exist Figure 5 In the exemplary embodiment shown, by means of Figure 5 The DAG graph on the left side, after undergoing transitive reduction, yields the following: Figure 5 The simplified DAG diagram shown on the right. From Figure 5 As can be seen from the simplified DAG diagram shown on the right, redundant constraints A→E and F→G have been removed.

[0105] Step 303: Determine the in-degree of each node in the second directed acyclic graph.

[0106] by Figure 5 Taking the exemplary embodiment shown as an example, in Figure 5 The simplified DAG diagram shown on the right:

[0107] Node A: In-degree is 0;

[0108] Node B: In-degree is 0;

[0109] Node C: In-degree is 2;

[0110] Node D: In-degree is 0;

[0111] Node E: In-degree is 2;

[0112] Node F: In-degree is 1;

[0113] Node G: In-degree is 1.

[0114] Step 304: Generate a subset of constraint relations for each node based on the in-degree of each node.

[0115] by Figure 5 Taking the exemplary embodiment shown as an example, the constraint relationship subset for each node is generated based on the in-degree of each node as follows:

[0116] The constraint relationship of node A is: B1={}, that is, the constraint relationship of node A is empty or has no constraint.

[0117] The constraint relationship of node B is: B2 = {};

[0118] The constraint relationship of node C is: B3={1,2}, that is, node C depends on node 1 (i.e. node A) and node 2 (i.e. node B).

[0119] The constraint relationship of node D is: B4 = {};

[0120] The constraint relationship of node E is: B5={3,4}, that is, node E depends on node 3 (i.e. node C) and node 4 (i.e. node D).

[0121] The constraint relationship of node F is: B6={5}, that is, node F depends on node 5 (i.e. node E).

[0122] The constraint relationship of node G is: B7={5}, that is, node G depends on node 5 (i.e. node E).

[0123] Step 305: Determine the set of constraints for the program order of the random verification stimulus by combining the various subsets of constraints.

[0124] by Figure 5 Taking the exemplary embodiment shown as an example, the combination of each subset of constraint relations forms the set of constraint relations for the program order of random verification stimuli:

[0125] Bn={B1={}, B2={}, B3={1,2}, B4={}, B5={3,4}, B6={5}, B7={5}}.

[0126] Wherein, Bn is the set of constraints on the program order of random verification stimuli.

[0127] refer to Figure 6 As shown, in some embodiments of this application, monitoring the memory access operation performed by the device under test (DUT) during the random verification stimulus may include the following steps:

[0128] Step 601: Execute the memory access operation in the random verification stimulus based on probe monitoring of the device under test.

[0129] In some embodiments of this application, the memory access key interfaces in the Device Under Test (DUT) can be monitored using probes (e.g., by pulling specific circuit signals of the memory access key interfaces from the DUT using hardware probes); when a memory access behavior (i.e., a memory access operation) occurs, it is recorded in real time. Here, the memory access operation executed by the DUT in the random verification stimulus refers to the memory access instruction in the instruction set of the random verification stimulus.

[0130] Step 602: Determine the global visibility time of the memory access operation based on the instruction type and memory attributes of the memory access operation.

[0131] In some embodiments of this application, the instruction type of the memory access operation can be determined first; the instruction type may include load instructions (i.e., load instructions or read instructions, which read data from memory into registers), store instructions (i.e. store instructions or write instructions, which write data from registers into memory), fence instructions (also known as memory barriers or memory fences, which are synchronization instructions used in concurrent programming to enforce a globally visible order of memory operations), etc.

[0132] (1) If the memory access operation is a load instruction, then confirm the memory attributes of the load instruction;

[0133] When the memory attribute of the load instruction is cacheable, the moment when the load instruction retrieves data from the L1 cache is determined as the global visibility moment of the load instruction;

[0134] When the memory attribute of the load instruction is non-cacheable, the moment when the load instruction initiates a read request to the lower-level module is determined as the global visibility moment of the load instruction.

[0135] (2) If the memory access operation is a store instruction, then confirm the memory attributes of the store instruction;

[0136] When the memory attribute of the store instruction is cacheable, the moment when the store instruction initiates a write request to the L1 cache is determined as the global visibility moment of the store instruction;

[0137] When the memory attribute of the store instruction is non-cacheable, the moment when the store instruction initiates a write request to the lower-level module is determined as the global visibility moment of the store instruction.

[0138] (3) If the memory access operation is a fence instruction, then the time when the fence instruction is reclaimed is determined as the time when the fence instruction is globally visible.

[0139] In the embodiments of this application, the globally visible moment refers to the point in time when, in a multi-core system, a modification made by one core to shared data becomes observable by all other cores in the system.

[0140] refer to Figure 7 As shown, in some embodiments of this application, generating the forward instruction set corresponding to each memory access operation may include the following steps:

[0141] Step 701: Sort the global visibility times of each memory access operation in a time sequence to obtain the global visibility order of each memory access operation.

[0142] Sequentially ordering the global visibility moments of each memory access operation means: sorting the global visibility moments according to their chronological order to obtain a global visibility moment sequence; since there is a one-to-one correspondence between global visibility moments and memory access operations, the global visibility order of each memory access operation can be obtained based on the global visibility moment sequence. The global visibility order defines the effective order of memory operations on different cores in a multi-core system from a global perspective; it is an actual out-of-order execution.

[0143] Step 702: Determine the set of forward instructions for each memory access operation under the globally visible order.

[0144] For example, in an exemplary embodiment of this application, the program order of the random verification stimulus described above is ABCDEFG (containing 7 instructions).

[0145] If the global visibility order of the actual memory access operations is ABCDEFG, and the corresponding node numbers are 1234567; under the global visibility order ABCDEFG, assume that the forward instruction set of each node can be obtained as follows:

[0146] Node 1: A1 = {};

[0147] Node 2: A2={1};

[0148] Node 3: A3={1,2};

[0149] Node 4: A4={1,2,3};

[0150] Node 5: A5={1,2,3,4};

[0151] Node 6: A6={1,2,3,4,5};

[0152] Node 7: A7={1,2,3,4,5,6}.

[0153] If the global visibility order corresponding to the actual memory access operation is AGCDBFE, the corresponding node numbers are 1734265; under the global visibility order AGCDBFE, assuming the forward instruction set of each node can be obtained as follows:

[0154] Node 1: A1 = {};

[0155] Node 2: A2={1,3,4,7};

[0156] Node 3: A3={1,7};

[0157] Node 4: A4={1,3,7};

[0158] Node 5: A5={1,2,3,4,6,7};

[0159] Node 6: A6={1,2,3,4,7};

[0160] Node 7: A7={1}.

[0161] If the global visibility order corresponding to the actual memory access operation is BADCEGF, and the corresponding node numbers are 2143576; under the global visibility order BADCEGF, assuming that the forward instruction set of each node can be obtained as follows:

[0162] Node 1: A1={2};

[0163] Node 2: A2 = {};

[0164] Node 3: A3={1,2,4};

[0165] Node 4: A4={1,2};

[0166] Node 5: A5={1,2,3,4};

[0167] Node 6: A6={1,2,3,4,5,7};

[0168] Node 7: A7={1,2,3,4,5}.

[0169] refer to Figure 8 As shown, in some embodiments of this application, determining whether each set of forward instructions satisfies the corresponding subset of constraints in the set of constraints may include the following steps:

[0170] Step 801: Identify the subset of target constraint relations in the constraint relation set that corresponds to each of the forward instruction sets.

[0171] In some embodiments of this application, the target constraint subset corresponding to each forward instruction set in the constraint set can be identified based on the node number or the constraint subset number. For example, the constraint subset corresponding to node 1 is the target constraint subset of the forward instruction set corresponding to node 1; the constraint subset corresponding to node 2 is the target constraint subset of the forward instruction set corresponding to node 2, and so on.

[0172] Step 802: Determine whether each subset of the target constraint relations is a subset of the corresponding forward instruction set. If each subset of the target constraint relations is a subset of the corresponding forward instruction set, proceed to step 803; otherwise, proceed to step 804.

[0173] For example, in an exemplary embodiment of this application, taking the above-mentioned random verification stimulus program order as ABCDEFG (containing 7 instructions) as an example; the constraint relationship set of the random verification stimulus program order is as follows: Bn={B1={}, B2={}, B3={1,2}, B4={}, B5={3,4}, B6={5}, B7={5}}.

[0174] (1) If the global visibility order corresponding to the actual memory access operation is ABCDEFG, the forward instruction set of each node 1 to 7 under the global visibility order ABCDEFG is as follows:

[0175] A1={}, A2={1}, A3={1,2}, A4={1,2,3}, A5={1,2,3,4}, A6={1,2,3,4,5}, A7={1,2,3,4,5,6}.

[0176] In this scenario, it can be confirmed that:

[0177] B1 A1, B2 A2, B3 A3, B4 A4, B5 A5, B6 A6, B7 A7.

[0178] (2) If the global visibility order corresponding to the actual memory access operation is AGCDBFE, the forward instruction set of each node 1 to 7 under the global visibility order BADCEGF is as follows:

[0179] A1={}, A2={1,3,4,7}, A3={1,7}, A4={1,3,7}, A5={1,2,3,4,6,7}, A6= A6={1,2,3,4,7}, A7={1}.

[0180] In this scenario, it can be confirmed that:

[0181] B1 A1, B2 A2, B3 A3, B4 A4, B5 A5, B6 A6, B7 A7.

[0182] (3) If the global visibility order corresponding to the actual memory access operation is BADCEGF, the forward instruction set of each node 1 to 7 under the global visibility order BADCEGF is as follows:

[0183] A1={2}, A2={}, A3={1,2,4}, A4={1,2}, {1,2,3,4}, A6={1,2,3,4,5,7}, A7={1,2,3,4,5}.

[0184] In this scenario, it can be confirmed that:

[0185] B1 A1, B2 A2, B3 A3, B4 A4, B5 A5, B6 A6, B7 A7.

[0186] Step 803: Confirm that the device under test meets memory consistency requirements.

[0187] Step 804: Confirm that the device under test does not meet memory consistency requirements.

[0188] In cases where memory consistency is not met, it is necessary to constrain or limit the execution of the device under test in the corresponding globally visible order to avoid the uncertainty of program execution results that may be caused by such out-of-order execution.

[0189] In some embodiments of this application, the device under test (DUT) can be a module-level DUT, such as a Load Store Unit (LSU). In a multi-core system, the LSU within each core is a significant source of memory consistency. Therefore, memory consistency verification can be performed during the development of each core's LSU. When the LSU of each core passes memory consistency verification, memory inconsistencies caused by LSUs in multi-core processors can be reduced or eliminated without waiting for the completion of the complete RTL design (e.g., core design completion or multi-core system design completion) before performing memory consistency verification. This achieves memory consistency verification of multi-core processors during the development phase in advance.

[0190] In other embodiments of this application, the processing logic of the memory consistency verification method described above can also be applied to system-level devices under test (e.g., multi-core processors), and this specification does not limit this.

[0191] Although the process described above includes multiple operations that occur in a specific order, it should be clearly understood that these processes may include more or fewer operations that can be executed sequentially or in parallel (e.g., using parallel processors or a multithreaded environment).

[0192] Corresponding to the above-described method for verifying memory consistency of multi-core processors during the development phase, this application also provides a device for verifying memory consistency of multi-core processors during the development phase, as described above. Figure 9 As shown, in some embodiments of this application, the memory consistency verification device may include:

[0193] Reference model module 91 is used to obtain the set of constraint relationships for the program order of random verification stimuli;

[0194] The device under test (DUT) monitoring module 92 is used to monitor the DUT's execution of memory access operations in the random verification stimulus, wherein the DUT includes module-level DUTs; and to generate a forward instruction set corresponding to each memory access operation.

[0195] The memory order checking module 93 is used to determine whether each of the forward instruction sets satisfies the corresponding constraint subset in the constraint relationship set; if it does, the device under test is confirmed to meet memory consistency.

[0196] Obviously, the memory consistency verification device of this application, as a custom memory consistency model, can perform memory consistency verification independently or in parallel with other known memory consistency models to improve the accuracy and reliability of the verification. Furthermore, in some embodiments of this application, the memory consistency verification device supports any one or more of the following memory consistency models:

[0197] RISC-V Weak Memory Sequencing Model (RVWMO);

[0198] RISC-V Complete Memory Sequencing Model (RVTSO);

[0199] Complete Storage Ordering (TSO) model;

[0200] ARM Memory Model (ARM MEM).

[0201] The memory consistency verification device of this application embodiment can be integrated into any one or more of the above-mentioned memory consistency models. This makes the memory consistency verification device of this application embodiment more flexible and reusable, thereby reducing redundant development and lowering the development cost of multi-core processor chips.

[0202] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0203] In some embodiments of this application, a multi-core processor chip is also provided, the multi-core processor chip including a memory consistency verification device, the memory consistency verification device being configured to perform the memory consistency verification method described above.

[0204] Embodiments of this application also provide a computer device. For example... Figure 10As shown, in some embodiments of this application, the computer device 1002 may include one or more processors 1004, such as one or more central processing units (CPUs) or graphics processing units (GPUs), each of which may implement one or more hardware threads. The computer device 1002 may also include any memory 1006 for storing any kind of information such as code, settings, data, etc. In one specific embodiment, a computer program on the memory 1006 and executable on the processor 1004, when run by the processor 1004, can execute instructions of the memory consistency verification method described in any of the above embodiments. Without limitation, for example, the memory 1006 may include any type of RAM, any type of ROM, flash memory, hard disk, optical disk, etc. More generally, any memory can use any technology to store information. Further, any memory can provide volatile or non-volatile retention of information. Further, any memory may represent a fixed or removable component of the computer device 1002. In one scenario, when processor 1004 executes associated instructions stored in any memory or combination of memories, computer device 1002 can perform any operation of the associated instructions. Computer device 1002 also includes one or more drive mechanisms 1008 for interacting with any memory, such as hard disk drive mechanisms, optical disk drive mechanisms, etc.

[0205] Computer device 1002 may also include an input / output interface 1010 (I / O) for receiving various inputs (via input device 1012) and providing various outputs (via output device 1014). A specific output mechanism may include a presentation device 1016 and an associated graphical user interface 1018 (GUI). In other embodiments, the input / output interface 1010 (I / O), input device 1012, and output device 1014 may be omitted, and the device may function solely as a computer device within a network. Computer device 1002 may also include one or more network interfaces 1020 for exchanging data with other devices via one or more communication links 1022. One or more communication buses 1024 couple the components described above together.

[0206] The communication link 1022 can be implemented in any way, such as via a local area network, a wide area network (e.g., the Internet), a point-to-point connection, or any combination thereof. The communication link 1022 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc., governed by any protocol or combination of protocols.

[0207] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), computer-readable storage media, and computer program products according to some embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processor to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processor, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0208] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processor to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0209] These computer program instructions may also be loaded onto a computer or other programmable data processor, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0210] In a typical configuration, a computer device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0211] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0212] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by computer equipment. As defined in this application, computer-readable media does not include transient media, such as modulated data signals and carrier waves.

[0213] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0214] The embodiments of this application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. The embodiments of this application can also be practiced in distributed computing environments where tasks are performed by remote processors connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0215] It should also be understood that, in the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0216] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0217] In the description of this application, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the embodiments of this application. In this application, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in a suitable manner in any one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this application, as well as the features of different embodiments or examples.

[0218] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for verifying memory consistency in a multi-core processor during the development phase, characterized in that, include: Obtain the set of constraints for the program order of random verification stimuli; The device under test (DUT) is monitored to perform memory access operations in the random verification stimulus, and the DUT includes module-level DUTs. Generate a set of forward instructions corresponding to each memory access operation; Determine whether each of the forward instruction sets satisfies the corresponding subset of constraint relationships in the constraint relationship set; If the conditions are met, the device under test is confirmed to meet memory consistency requirements.

2. The memory consistency verification method for multi-core processors during the development phase as described in claim 1, characterized in that, The set of constraints for obtaining the program order of random verification stimuli includes: The instruction set of the random verification stimulus is mapped to a first directed acyclic graph; the nodes in the first directed acyclic graph represent instructions, and the directed edges in the first directed acyclic graph represent a subset of constraint relationships between instructions; The first directed acyclic graph is subjected to a transitive reduction to remove redundant constraint edges in the first directed acyclic graph, thereby obtaining a second directed acyclic graph. Determine the in-degree of each node in the second directed acyclic graph; Generate a subset of constraint relationships for each node based on its in-degree; The combination of each of the aforementioned subsets of constraints is determined as the set of constraints for the program order of the random verification stimulus.

3. The memory consistency verification method for multi-core processors during the development phase as described in claim 1, characterized in that, The monitoring of the device under test (DUT) performing memory access operations during the random verification stimulus includes: The memory access operation in the random verification stimulus is performed based on probe monitoring of the device under test; The global visibility time of the memory access operation is determined based on the instruction type and memory attributes of the memory access operation.

4. The memory consistency verification method for multi-core processors during the development phase as described in claim 3, characterized in that, Determining the global visibility time of the memory access operation based on the instruction type and memory attributes of the memory access operation includes: Determine the instruction type of the memory access operation; If the memory access operation is a load instruction, then confirm the memory attributes of the load instruction; When the memory attribute of the load instruction is cacheable, the moment when the load instruction retrieves data from the L1 cache is determined as the global visibility moment of the load instruction; When the memory attribute of the load instruction is non-cacheable, the moment when the load instruction initiates a read request to the lower-level module is determined as the global visibility moment of the load instruction.

5. The memory consistency verification method for multi-core processors during the development phase as described in claim 4, characterized in that, The step of determining the global visibility time of the memory access operation based on the instruction type and memory attributes of the memory access operation further includes: If the memory access operation is a store instruction, then confirm the memory attributes of the store instruction; When the memory attribute of the store instruction is cacheable, the moment when the store instruction initiates a write request to the L1 cache is determined as the global visibility moment of the store instruction; When the memory attribute of the store instruction is non-cacheable, the moment when the store instruction initiates a write request to the lower-level module is determined as the global visibility moment of the store instruction.

6. The memory consistency verification method for multi-core processors during the development phase as described in claim 4, characterized in that, The step of determining the global visibility time of the memory access operation based on the instruction type and memory attributes of the memory access operation further includes: If the memory access operation is a fence instruction, then the time when the fence instruction is reclaimed is determined as the time when the fence instruction becomes globally visible.

7. The memory consistency verification method for multi-core processors during the development phase as described in claim 3, characterized in that, The generation of the forward instruction set corresponding to each memory access operation includes: The global visibility times of each memory access operation are sorted in time sequence to obtain the global visibility order of each memory access operation. Determine the set of forward instructions for each memory access operation under the globally visible order.

8. The memory consistency verification method for multi-core processors during the development phase as described in claim 1, characterized in that, The step of determining whether each of the forward instruction sets satisfies the corresponding subset of constraint relations in the constraint relation set includes: Identify the target constraint relation subset corresponding to each forward instruction set in the constraint relation set; Determine whether each of the target constraint relation subsets is a subset of the corresponding forward instruction set; If each of the target constraint subsets is a subset of the corresponding forward instruction set, then the device under test is confirmed to meet memory consistency.

9. The memory consistency verification method for multi-core processors during the development phase as described in claim 1, characterized in that, The module-level device under test includes a loading storage unit.

10. A memory consistency verification device for a multi-core processor during the development phase, characterized in that, include: The reference model module is used to obtain the set of constraint relationships for the program order of random verification stimuli; A device under test (DUT) monitoring module is used to monitor the DUT's execution of memory access operations in the random verification stimulus, wherein the DUT includes module-level DUTs. Generate a set of forward instructions corresponding to each memory access operation; the device under test includes a memory loading unit module; The memory order checking module is used to determine whether each set of forward instructions satisfies the corresponding subset of constraint relationships in the set of constraint relationships. If the conditions are met, the device under test is confirmed to meet memory consistency requirements.

11. The memory consistency verification device for a multi-core processor in the development phase as described in claim 10, characterized in that, The device supports at least one of the following memory consistency models: RISC-V weak memory ordering model; RISC-V complete memory ordering model; Complete storage ordering model; ARM memory model; A custom memory consistency model.

12. A multi-core processor chip, characterized in that, The multi-core processor chip includes a memory consistency verification device configured to perform the method according to any one of claims 1 to 9.

13. A computer device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, When the computer program is run by the processor, it executes the instructions of the method according to any one of claims 1-9.

14. A computer storage medium having a computer program stored thereon, characterized in that, When the computer program is run by the processor of the computer device, it executes the instructions of the method according to any one of claims 1-9.

15. A computer program product, characterized in that, The computer program product includes a computer program that, when run by the processor of a computer device, executes instructions according to any one of claims 1-9.

Images