Method for verifying cache consistency of multi-core processor, electronic equipment and storage medium

Abstract

The invention provides a method for verifying cache consistency of a multi-core processor, electronic equipment and a storage medium, and the method comprises the steps: generating a model compiled by a target language according to an obtained first conversion rule between any two states of a cache line of the multi-core processor, analyzing the model, and verifying the cache consistency of the multi-core processor; therefore, at least one path of state transition of the cache line is obtained. By generating the excitation corresponding to the at least one path, the excitation is compiled into an executable file, so that the cache consistency of the multi-core processor is verified by running the executable file. Therefore, the generated model written by the target language can automatically generate the incentives for verifying the cache consistency, so that more incentives can be generated, more test scenes can be covered as much as possible, and the cache consistency verification of the multi-core processor is more comprehensive.

Description

Technical Field

[0001] The present application relates to the field of computer software technology, and in particular to a method, electronic device, and storage medium for verifying cache consistency of a multi-core processor. Background Art

[0002] In the field of integrated circuit verification, simulation generally refers to compiling a logic system design and running it on a computer or hardware simulation device to simulate and test the various functions of the design. The design can be, for example, an integrated circuit (ASIC) for a specific application or a system-on-chip (SOC). Therefore, the logic system design being tested or verified in simulation is also called the device under test (DUT).

[0003] As the scale and design complexity of integrated circuits continue to increase, simulation and verification scenarios in the chip development stage have become extremely complex, posing a huge challenge to the completeness of chip development and verification, especially system on chip (SoC).

[0004] Verifying cache coherence protocols (such as MOESI) in SoC systems requires clear verification objectives and requirements, identifying specific aspects to verify, such as state transition accuracy, performance metrics, and consistency maintenance. Throughout the verification process, the complexity of the protocol, the characteristics of the hardware implementation, and the system's performance requirements must be fully considered to ensure the correct and effective implementation of the MOESI protocol.

[0005] Currently, the stimuli used to verify the cache consistency of multi-core processors need to be manually written. However, the number of manually written stimuli is small, and the test scenarios that can be covered are insufficient, making it difficult to perform comprehensive cache consistency verification. Summary of the Invention

[0006] A first aspect of the present application provides a method for verifying cache consistency of a multi-core processor, comprising:

[0007] Obtaining a first conversion rule between any two states of a cache line of the multi-core processor;

[0008] generating a model written in a target language according to the first conversion rule;

[0009] Parsing the model to obtain at least one path of state transition of the cache line;

[0010] generating a stimulus corresponding to the at least one path, and compiling the stimulus into an executable file; and

[0011] The executable file is run to verify cache consistency of the multi-core processor.

[0012] A second aspect of the present application provides an electronic device, comprising: a memory for storing a set of instructions; and at least one processor configured to execute the set of instructions so that the electronic device performs the method as described in the first aspect.

[0013] A third aspect of the present application provides a non-transitory computer-readable storage medium storing a set of instructions for a computer, wherein the set of instructions is used to cause the computer to perform the method according to the first aspect when executed.

[0014] The present application provides a method, electronic device, and storage medium for verifying the cache consistency of a multi-core processor. The method generates a model written in a target language based on a first conversion rule between any two states of a cache line of the multi-core processor, and parses the model to obtain at least one path for the state conversion of the cache line. By generating a stimulus corresponding to the at least one path, the stimulus is compiled into an executable file, and the cache consistency of the multi-core processor is verified by running the executable file. The model written in the target language generated in this way can automatically generate a stimulus for verifying cache consistency, thereby generating a larger number of stimuli, covering as many test scenarios as possible, and making the cache consistency verification of the multi-core processor more comprehensive. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the technical solutions in this application or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are merely embodiments of this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0016] Figure 1 A schematic structural diagram of an electronic device according to an embodiment of the present application is shown.

[0017] Figure 2A A schematic diagram of a simulation test system according to an embodiment of the present application is shown.

[0018] Figure 2B A schematic diagram of a verification system according to an embodiment of the present application is shown.

[0019] Figure 3 A schematic diagram of a state transition diagram of an exemplary cache line according to an embodiment of the present application is shown.

[0020] Figure 4 A flow chart of an exemplary method for verifying cache consistency of a multi-core processor according to an embodiment of the present application is shown.

[0021] Figure 5 FIG. 5 is a flow chart illustrating a cache consistency verification process 500 of an exemplary multi-core processor according to an embodiment of the present application.

[0022] Figure 6 A flow chart of an exemplary method for verifying cache consistency of a multi-core processor according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0023] In order to make the objectives, technical solutions and advantages of this application more clear, this application is further described in detail below in combination with specific embodiments and with reference to the accompanying drawings.

[0024] It should be noted that, unless otherwise defined, the technical or scientific terms used in this application should have the usual meaning understood by people with ordinary skills in the field to which this application belongs. The "first", "second" and similar words used in this application do not indicate any order, quantity or importance, but are only used to distinguish different components. "Include" and similar words mean that the elements or objects appearing before the word include the elements or objects listed after the word and their equivalents, without excluding other elements or objects. "Connect" and similar words are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect.

[0025] As mentioned above, the stimuli currently used to verify the cache consistency of multi-core processors need to be manually written. However, the number of manually written stimuli is small, and the test scenarios that can be covered are insufficient, which makes it difficult to perform comprehensive cache consistency verification.

[0026] The present application provides a method, electronic device and storage medium for verifying the cache consistency of a multi-core processor. By generating a model written in a target language based on the first conversion rule between any two states of the cache line of the multi-core processor, the model is parsed to obtain at least one path for the state conversion of the cache line. By generating a stimulus corresponding to the at least one path, the stimulus is compiled into an executable file, and the cache consistency of the multi-core processor is verified by running the executable file. The model written in the target language generated in this way can automatically generate a stimulus for verifying cache consistency, thereby generating a larger number of stimuli, covering as many test scenarios as possible, and making the cache consistency verification of the multi-core processor more comprehensive.

[0027] Simulation testing is to apply various stimuli to the logic system design on the host running the simulation test system to detect whether the logic system design can achieve the predetermined functions.

[0028] Figure 1 FIG1 shows a schematic diagram of the structure of an electronic device 100 according to an embodiment of the present application. The electronic device 100 may be an electronic device running a simulation system, or the electronic device 100 may be a host 100. Figure 1 As shown, electronic device 100 may include: processor 102, memory 104, network interface 106, peripheral interface 108 and bus 110. Processor 102, memory 104, network interface 106 and peripheral interface 108 are communicatively connected to each other via bus 110 within the electronic device.

[0029] The processor 102 may be a central processing unit (CPU), an image processor, a neural network processor (NPU), a microcontroller (MCU), a programmable logic device, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or one or more integrated circuits. The processor 102 may be used to perform functions related to the technology described in this application. In some embodiments, the processor 102 may also include multiple processors integrated into a single logical component. Figure 1 As shown, the processor 102 may include a plurality of processors 102a, 102b, and 102c.

[0030] The memory 104 may be configured to store data (eg, instruction sets, computer code, intermediate data, etc.). In some embodiments, the simulation test system for simulating the test design may be a computer program stored in the memory 104. Figure 1 As shown, the data stored in the memory may include program instructions (for example, program instructions for implementing the method for verifying cache consistency of a multi-core processor of the present application) and data to be processed (for example, the memory may store temporary code generated during the compilation process). The processor 102 may also access the program instructions and data stored in the memory, and execute the program instructions to operate on the data to be processed. The memory 104 may include a volatile storage device or a non-volatile storage device. In some embodiments, the memory 104 may include a random access memory (RAM), a read-only memory (ROM), an optical disk, a magnetic disk, a hard disk, a solid-state drive (SSD), a flash memory, a memory stick, etc.

[0031] The network interface 106 can be configured to provide the electronic device 100 with communication with other external devices via a network. The network can be any wired or wireless network capable of transmitting and receiving data. For example, the network can be a wired network, a local wireless network (e.g., Bluetooth, WiFi, near field communication (NFC)), a cellular network, the Internet, or a combination thereof. It will be appreciated that the type of network is not limited to the specific examples above. In some embodiments, the network interface 106 can include any number of network interface controllers (NICs), radio frequency modules, transceivers, modems, routers, gateways, adapters, cellular network chips, and the like.

[0032] The peripheral interface 108 can be configured to connect the electronic device 100 to one or more peripheral devices to implement information input and output. For example, the peripheral devices can include input devices such as a keyboard, a mouse, a touchpad, a touch screen, a microphone, and various sensors, as well as output devices such as a display, a speaker, a vibrator, and an indicator light.

[0033] The bus 110 can be configured to transmit information between various components of the electronic device 100 (e.g., the processor 102, the memory 104, the network interface 106, and the peripheral interface 108), such as an internal bus (e.g., a processor-memory bus), an external bus (USB port, PCI-E bus), etc.

[0034] It should be noted that although the above electronic device architecture only shows the processor 102, memory 104, network interface 106, peripheral interface 108 and bus 110, in the specific implementation process, the electronic device architecture may also include other components necessary for normal operation. In addition, it will be understood by those skilled in the art that the above electronic device architecture may also include only the components necessary to implement the embodiments of the present application, and does not necessarily include all the components shown in the figure.

[0035] In the field of logic system design (such as chip design), a simulation system can be used to simulate the design. The simulation system can be running on Figure 1 A computer program on the electronic device 100 is shown.

[0036] Figure 2A FIG. 2 shows a schematic diagram of a simulation test system 200 according to an embodiment of the present application. Figure 2A As shown, simulation test system 200 may include a PSS (Portable Test and Stimulus Standard) tool 210, a test environment 220, and a device under test 230. Simulation test system 200 may generate multiple test cases based on user input 202 for testing multiple functional units of a logic system design during a simulation of the logic system design.

[0037] The PSS tool 210 can generate multiple test cases across platforms based on user input 202. In a simulation test scenario, it is necessary to consider the efficiency of the test, for example, the same test case can be tested on different platforms or at different levels. The PSS tool 210 is proposed to shorten the test time and to achieve continuity in vertical reuse and cross-platform reuse of verification cases and verification plans. The PSS tool 210 generally uses a domain-specific language (DSL) to process internal logic.

[0038] The test environment 220 is used to obtain multiple test cases from the PSS tool 210 and convert them into multiple executable test cases. The test environment 220 may include a verification environment written in the SystemVerilog language, such as a Universal Verification Methodology (UVM) environment. In some embodiments, the test environment 220 may include a hardware simulation platform composed of a hardware simulator (emulator) and a host, etc., to verify the device under test 230. In some other embodiments, the test environment 220 may include a software simulator (simulator) to perform software simulation and testing on the device under test 230.

[0039] Figure 2B FIG2 shows a schematic diagram of a verification system 250 according to an embodiment of the present application.

[0040] like Figure 2B As shown, the verification system 250 may include a verification tool 252, which may run on a host 100, and the host 100 may be an electronic device 100. The verification tool 252 may be the Galaxpss tool (abbreviated as the Portable Stimulus Standard (PSS) tool) developed by Xinhuazhang. The PSS tool customizes a highly abstract test description language, such as a Domain Specific Language (DSL), which may be a PSS language. Test engineers can focus on system-level scenario testing without having to pay attention to the underlying logic. In order to simplify the test model while generating more random test scenarios, the PSS tool provides a scenario inference (actioninfer) function. The PSS tool can complete the preceding behavior based on the input and output data flows, constraints, etc. bound to the existing action and finally generate a complete test scenario.

[0041] A SoC system is a system or product composed of multiple integrated circuits with specific functions combined on a single chip, fully integrating a CPU, a graphics processing unit (GPU), and communication modules. SoC systems typically integrate multiple processor cores, various peripherals, a complex bus architecture, and multi-level caches. This highly integrated and complex system structure makes cache coherence verification extremely difficult, requiring consideration of numerous interactions and potential concurrency scenarios.

[0042] The MOESI protocol states are complex and diverse. The MOESI protocol can contain multiple states, such as Modified, Exclusive, Shared, Owned, and Invalid. The transition conditions and rules between states are complex, making it easy for misunderstandings and implementations to deviate. When a processor core modifies data in the Shared state, it sends a notification to other processor cores via the bus, causing the corresponding cache line in those other cores to become Invalid. When other processor cores need to access that data, they retrieve the latest data from main memory.

[0043] The MOESI protocol is a protocol used to maintain cache consistency in multi-core processors. It considers the cache to have five status bits, namely:

[0044] The M (Modified) bit indicates that the data in the current cache line is different from that in the multi-core processor, and only the current cache holds this cache line data; no other caches have this copy. When replacing this cache line, the data in the cache line does not need to be written back to the memory first.

[0045] E (Exclusive) bit: Indicates that there is a copy only in this cache, no other cache has a copy of this cache line, and the content of this cache line is the same as that in the memory.

[0046] I (Invalid) bit: When the I bit is 1, it means that the current cache line has no valid data or the cache line is not enabled.

[0047] O (Owned) bit: When there is a cache line with the O bit set to 1, it means that the cache line data must have copies in multiple caches, and the content in the cache line is different from the content in the memory, while the contents in each cache line copy are the same.

[0048] S (Shared) bit: When the S bit is 1, it means that the cache line has copies in multiple caches, but whether the cache line content is the same as the memory content depends on the situation. If there is a copy of the cache line with bit 0 set to 1, the cache line content is different from the memory content; if there is no copy with bit 0 set to 1, the cache line content is consistent with the memory content.

[0049] Figure 3 FIG. 3 is a schematic diagram showing a state transition diagram 300 of an exemplary cache line according to an embodiment of the present application.

[0050] like Figure 3 As shown, the state transition diagram 300 may include five states, namely, Invalid state 302 , Exclusive state 304 , Shared state 306 , Owned state 308 and Modified state 310 .

[0051] The following is a description of each state and its transition path in the state transition diagram 300:

[0052] Invalid status 302:

[0053] The state is transitioned to the Exclusive state 304 by a transition rule 3022 (eg, transition rule Read Miss, Exclusive), indicating that a read miss occurs and exclusive access is required.

[0054] The state is converted to Shared state 3306 through conversion rule 3024 (eg, conversion rule Read Miss Shared), indicating that a read miss occurs but the data can be shared by multiple processors.

[0055] The state is transitioned to the Modified state 310 by the transition rule 3026 (eg, the transition rule Write Miss).

[0056] Exclusive status 304:

[0057] The state 304 remains in Exclusive state 304 through a conversion rule 314 (eg, conversion rule Read Hit), indicating a read hit.

[0058] The state is converted to the Modified state 310 by the conversion rule 3042 (for example, the conversion rule Write Hit), indicating a write hit.

[0059] The state is converted to Invalid state 302 by conversion rule 3044 (eg, conversion rule Probe Write Hit), indicating that a write operation hit by another processor causes the current cache line to be invalidated.

[0060] Shared status 306:

[0061] The state 306 is maintained by the conversion rule 316 (eg, conversion rule Read Hit), indicating a read hit.

[0062] The state is converted to Invalid state 302 by conversion rule 3062 (eg, conversion rule Probe Write Hit), indicating that a write operation hit by another processor causes the current cache line to be invalidated.

[0063] The state is transitioned to the Modified state 310 by the transition rule 3064 (eg, the transition rule Write Hit), indicating a write hit.

[0064] Owned status 308:

[0065] The state is converted to Invalid state 302 by conversion rule 3082 (eg, conversion rule Probe Write Hit), indicating that a write operation hit by another processor causes the current cache line to be invalidated.

[0066] The state is transitioned to the Modified state 310 by the transition rule 3084 (eg, the transition rule Write Hit), indicating a write hit.

[0067] Modified status 310:

[0068] The state 310 remains in the Modified state 310 by the conversion rule 318 (eg, conversion rule Read Hit), indicating a read hit.

[0069] The state is converted to Invalid state 302 by conversion rule 3102 (eg, conversion rule Probe Write Hit), indicating that a write operation hit by another processor causes the current cache line to be invalidated.

[0070] The transition to the Owned state 308 by the transition rule 3104 (eg, the transition rule Probe Read Hit) indicates that a read operation hit by another processor causes the current cache line to be in the owned state.

[0071] The cache line can be reset to the invalid state 302 by a command 312 (eg, command Reset INVD, WBINVD). These commands are usually used to clear the cache or when the system is reset.

[0072] like Figure 3 As shown, when the cache line is in the Modified state 310 and the Exclusive state 304, data can be directly written into the cache line, and the state of the cache line becomes M.

[0073] When the cache line is in the Shared state 306, data is directly written to the cache line, the state of the cache line is changed to M, and the cache line storing the copy in other cache lines is changed from state S or state O to state I.

[0074] When the cache line is in the Owned state 308, the data is directly written to the cache line, the state of the cache line is changed to M, and the cache line storing the copy in other cache lines is changed from state S to state I.

[0075] The MOESI protocol allows data to be synchronized between cache lines of multi-core processors, reducing memory operations and thus significantly improving performance, but its logical control is also relatively complex.

[0076] Verifying the MOESI protocol in a SoC system requires clear verification objectives and requirements, identifying specific aspects to be verified, such as state transition accuracy, performance metrics, and consistency maintenance. This includes covering a wide range of possible operational scenarios, including read, write, shared, and exclusive operations. This includes testing for different numbers of processor cores and concurrent operations, including edge cases and exceptions, such as cache misses and erroneous requests.

[0077] Multi-core parallelism, where multiple processor cores simultaneously execute and access shared data, complicates data consistency management. Operations on different cores can affect each other, leading to cache state changes that are difficult to predict and track.

[0078] Large-scale data and high-concurrency access: Practical applications may involve large-scale data processing and high-concurrency access requests, which places high demands on the capabilities of verification tools and methods to effectively handle and analyze these complex situations.

[0079] Completeness of MOESI protocol jump scenario verification: The MOESI protocol usually does not exist in isolation and may interact with other cache consistency protocols or system-level protocols. This increases the difficulty of verification and requires comprehensive consideration of the collaborative work between multiple protocols.

[0080] Commonly used methods for verifying MOESI protocol state transitions include formal verification and Universal Verification Methodology (UVM), but their scalability is limited and they cannot be used for simulation verification with processor cores.

[0081] Manually writing C language test stimuli to test the MOESI protocol cache consistency in the SoC system does not generate enough stimuli and the scenarios are insufficient. Due to personal ability, it is difficult to conduct comprehensive testing or large-scale coverage testing.

[0082] Therefore, there is currently no effective and unified method to verify the cache consistency of multiple core processors of the MOESI protocol.

[0083] To at least address the aforementioned issues, the present invention verifies the MOESI protocol state transitions of a multi-core processor system at the SoC system level, verifying the data consistency between the various coherent interconnected components of the entire system from the application perspective. Because the test is conducted from the application perspective, the load generated by the test can be executed in parallel by multiple core processors, enabling large-scale data and high-concurrency access. The stimulus can also be ported to a hardware emulator for execution without modification, thus achieving state transitions covering the MOESI protocol and verifying the correctness and consistency of the protocol through the generated, more comprehensive stimulus.

[0084] Figure 4 FIG4 is a flow chart of an exemplary method 400 for verifying cache consistency of a multi-core processor according to an embodiment of the present application. The method 400 may be executed by the verification system 200 .

[0085] like Figure 4 As shown, in some embodiments, the host 100 can obtain a first conversion rule 402 between any two states of a cache line of a multi-core processor, such as conversion rules 3022 and 3024 in the state transition diagram 300, and generate a model 404 written in the target language based on the first conversion rule 402.

[0086] Analyze the generation rules of any two state transitions in the state transition to model the MOESI protocol using the target language, such as Figure 3 As shown, for example, the current cache line is in the Invalid state 302, and a "conversion rule 3022 (for example, conversion rule Read Miss, Exclusive)" is generated, that is, a processor read operation, then the cache line state will be converted from the Invalid state 302 to the Exclusive state 304; the current cache line is in the Modified state 310, and a "conversion rule 3104 (for example, conversion rule Probe Read Hit)" is generated, that is, a remote processor read operation, then the cache line state will be converted from the Modified state 310 to the Owned state 308.

[0087] All transitions between any two states of the MOESI protocol state transition diagram 300 and the conditions that lead to cache line state transitions are modeled using the target language. By using the verification tool 202 to parse the model, the scenario inference function of the verification tool 202 will randomly generate jumps to various states based on the input state and constraints.

[0088] In some embodiments, the construction of model 404 can be implemented based on verification tool 202, and verification tool 202 can be a PSS tool. In some embodiments, the target language can include a domain-specific language, and the domain-specific language can include a PSS language. PSS is a standard in the field of chip development that further solves the difficult problems of randomized and cross-platform complex combination scenario definition and code generation based on the UVM verification methodology. The emergence of the PSS standard is intended to achieve effective reuse of test stimuli, ensure the reuse of test stimuli at different levels (such as module level, subsystem level, system level, etc.) and on different types of test benches (such as EDA, EMU, FPGA, etc.), and ensure the consistency of verification on different platforms.

[0089] The PSS standard provides new domain-specific language specification support to help developers more effectively define and generate test stimuli. It provides a standardized approach for chip verification, making the verification process more efficient and reliable.

[0090] The PSS tool provides various flow objects for handling input and output, as well as data exchange, between actions, such as buffer objects, stream objects, and state objects. The scheduling relationships between actions sharing the same flow object are also determined by that flow object. A state object can be used to represent the state of a design under test (DUT) or certain elements in the test environment at a specific moment. A state object supports read and write operations by multiple actions, but only one action can write at a time. Multiple read actions can execute concurrently. The state object provides a built-in variable (for example, the built-in variable prev) that points to the previous state of the current state. Therefore, the values ​​of various variables in the previous state can be obtained using the built-in variable value (for example, the built-in variable value prev.var). Constraint syntax (for example, constraint syntax) allows flexible constraints on the relationship between the current state and the previous state. This syntax allows modeling and implementing transitions between any two states in the MOSEI protocol.

[0091] In an SoC system, the system can interact with the cache coherence protocol of a multi-core processor through a set of actions, such as input actions, internal actions, and output actions. Input actions are actions from the user to the system that can result in memory access, such as processor read (loads) and write (store) operations. Internal actions are actions that occur within the system, such as operations to maintain cache coherence. Output actions are actions from the system to the user, such as the return value of a read operation.

[0092] Input and output actions are visible to the user, while internal actions are not. Therefore, a series of observable input actions can be used to stimulate cache coherence verification of the SoC system, and the observable output actions generated by the system due to the observable input actions can be used to check the cache coherence verification of the SoC system. The stimuli of read and write accesses to cache line addresses generated by the PSS tool serve as the input actions of the system, and the return values ​​corresponding to these input actions can be used to check the correctness of the cache coherence protocol.

[0093] In the SoC system, a different cache line address is assigned to each processor core cache as the target cache line. The PSS tool supports modeling the transitions between the various states of the state machine, and the read and write accesses to the cache line address by the processor core in the SoC system will result in the transition of the cache line state. Therefore, in some embodiments, the transitions between the various states of the MOESI protocol (for example, the first transition rule) can be described by the first grammar of the target language (for example, the state grammar) to generate a second transition rule written by the first grammar, and the second transition rule can constrain the random transition of the MOESI protocol state. In some embodiments, the behavior of allocating cache line addresses can be abstracted using the second grammar of the target language (for example, the action grammar) to generate the first function of the model, and the first function can constrain the generation of random cache line addresses. The second grammar can be used for abstraction when modeling the behavior of the cache line transitioning from one state to another using the target language.

[0094] The processor core's read and write accesses to cache line addresses can be abstracted using a second syntax. The target language's third syntax (e.g., buffer syntax) is then used to generate the model's second function. This second function can store and pass parameters related to the processor's second operation, which can include at least a read operation and a write operation. Furthermore, the second function can store the processor's core ID, core address, the value to be stored in a write operation, and the comparison value expected in a read operation. Building models using different syntaxes in the target language allows for more efficient description and verification of complex SoC system behavior, while also improving verification flexibility and reusability.

[0095] The model models a first function for allocating cache line addresses, a second transition rule for cache line MOESI protocol states, and a second function for storing parameters related to read and write operations on cache line addresses by multiple processor cores. Furthermore, a verification tool 202 (e.g., a PSS tool) can be used to generate a large number of random stimuli 408 for cache coherence modeling. In some embodiments, the stimuli 408 can include code written in a software description language, which can include at least one of C, C++, or Python. The cache line access addresses of these stimuli 408 are generated by random constraints, the state transitions of the MOESI protocol are randomly generated, and the processor cores accessing the target cache line addresses are also randomly generated. Write operations write data to the cache, and read operations read data from the cache and check whether the read data is equal to the expected comparison value. The stimuli 408 are compiled into a binary file (e.g., an executable file 410) of the SoC system for simulation, thereby verifying the cache coherence of the multi-core processor. By using the target language to model scenarios for MOESI protocol state transitions and automatically generate test stimuli for the SoC system, the verification cycle can be greatly shortened and the verification efficiency can be improved.

[0096] When parsing the model, in some embodiments, the model can be parsed to obtain at least one path for the state transition of the cache line, and then generate a stimulus 408 corresponding to the at least one path. In some embodiments, after the SoC system is reset, the initial state of the path is generally the Invalid state. Therefore, the end state of the path can be defined in the model. For example, it can be defined that the state transition of the cache line ends when the end state of the path is the same as the initial state (for example, the end state is also the Invalid state). As an optional embodiment, the end state of the path can also be defined as any other state. When the state of the cache line jumps to this arbitrary state, the state transition of the cache line ends.

[0097] Taking the case where both the initial state and the end state of a path are Invalid as an example, the Invalid state (e.g., the first state) as the end state in the model can be first determined. Since the state transition rules of the cache line are constructed in the model, in some embodiments, the scenario inference function of the verification tool 202 can be used to determine the previous state of the end state (e.g., the second state) and the first description of the state transition between the end state and its previous state in the model. For example, the end state is Invalid. According to the state transition rules defined in the model, the previous state of the Invalid state is Owned. It can be determined that the state description of the transition from Owned to Invalid can be snoop_write_owned_to_invalid_a. Based on the scenario inference technology of the verification tool, one or more possible paths with the first state as the end state can be inferred, thereby improving the coverage of the stimulus and the diversity of the test scenarios.

[0098] By using the above-mentioned scenario inference method, at least one path can be obtained until the initial state of the path is found. For example, if the previous state of the inferred second state is the Invalid state (for example, the third state), which is the same as the end state, at least one path can be obtained based on the first state, the second state, the third state, and the first description, the third state, and the second description corresponding to the second state. According to each description in the path, a stimulus corresponding to each description can be generated, for example, what operation the processor needs to perform to implement the description. By defining in the model that the third state is the same as the first state as a complete path, a complete path can be parsed based on the stop time when inferring from the end state to the previous state (that is, it can be inferred to stop at the initial state).

[0099] A possible path in the analytical model is as follows (taking two processors (processors P0 and P1) executing cache as an example):

[0100] invalid_to_exclusive_a(Invalid->Exclusive),exclusive_to_shared_a(Exclusive->Shared),shared_to_modified_a(Shared->Modified),modified_to_owned_a(Modified->Owned),snoop_write_owned_to_invalid_a(Owned->Invalid)

[0101] Among them, invalid_to_exclusive_a describes that the cache line state of processor P0 changes from the Invalid state to the Exclusive state, and processor P0 needs to perform a read access operation;

[0102] The exclusive_to_shared_a description indicates that the cache line state of processor P0 is transitioned from the Exclusive state to the Shared state, and processor P1 needs to perform a read access operation;

[0103] The shared_to_modified_a description indicates that the cache line state of processor P0 is changed from the Shared state to the Modified state, and processor P0 needs to perform a write access operation;

[0104] The modified_to_owned_a description indicates that the cache line state of processor P0 changes from the Modified state to the Owned state, and processor P1 needs to perform a read access operation;

[0105] The snoop_write_owned_to_invalid_a description indicates that the cache line state of processor P0 changes from the Owned state to the Invalid state, and processor P1 needs to perform a write access operation.

[0106] In addition to at least one operation (e.g., a read operation or a write operation) generated according to at least one path, in some embodiments, the stimulus 408 may also include an address of a cache line, which may be an address of a cache line randomly generated by a first function generated in the model using a second grammar. In this way, the randomly generated address of the cache line and the at least one operation are compiled into an executable file 410, and the execution process of a multi-core processor can be simulated in a subsequent verification process, thereby verifying the cache consistency of multiple processors.

[0107] Specifically, in some embodiments, a cache line address may be randomly generated, and a first operation of the processor corresponding to the description is generated according to the description in the path, where the first operation may include a read operation or a write operation. The cache line address and the first operation are compiled into an executable file 410. This can effectively simulate a processor that can perform read and write operations.

[0108] The model can be tested for cache line state transitions. Taking the test of two processors executing the model in time sequence as an example, the results of some stimuli are shown in Table 1:

[0109]

[0110]

[0111] As shown in Table 1, at time T0, the system is reset (Reset), and the caches of processors P0 and P1 are set to the Invalid state, and no monitoring operation (Snoop operation) is generated. At time T1, processor P0 performs a read access operation on the cache line, and the cache line state is converted to the Exclusive state, and no Snoop operation is generated. At time T2, processor P1 performs a read access operation on the cache line. Since processor P0's cache has already cached the cache line and the state is Exclusive, the system will perform a Snoop operation, and the cache line state of processor P0 will be converted to the Shared state. At the same time, the cache line state of processor P1 will also be converted to the Shared state. At time T3, processor P0 performs a write access operation on the cache line. Since processor P1's cache has already cached the cache line and the cache line is shared cleanly, processor P0 will initiate a request to exclusively occupy the cache line. The system generates a Snoop operation, and the cache line state of processor P1 is converted to the Invalid state. At the same time, the cache line state of processor P0 is also converted to the Modified state. At time T4, processor P1 performs a read access operation on the cache line. Since processor P0's cache already caches the cache line and the cache line is dirty, the system generates a Snoop operation, and the cache line state of processor P0 is converted to the Owned state. At the same time, the cache line state of processor P1 is also converted to the Shared state. At time T5, processor P1 performs a write access operation on the cache line. Since processor P0's cache already caches the cache line and the cache line is shared and dirty, the system generates a Snoop operation, and the cache line state of processor P0 is converted to the Invalid state. At the same time, the cache line state of processor P1 is also converted to the Modified state.

[0112] When verifying the cache consistency of multiple processors, in some embodiments, the executable file 410 can be run to obtain the return value corresponding to the executable file 410. The stimulus generated by parsing the model using the verification tool 202 includes at least one path, and the path includes a target value corresponding to the return value. For example, the end state of a path in the executable file 410 is obtained by performing a read operation, and running the executable file 410 can obtain the return value corresponding to the read operation. The stimulus 408 corresponds to the same path, and accordingly, the target value of the read operation corresponding to the end state of the path (the target value can be called the expected value) has been obtained through the parsing process. Therefore, by comparing whether the return value is consistent with the expected value, it can be determined whether the caches of multiple processors are consistent.

[0113] Figure 5 FIG. 5 is a flow chart illustrating a cache consistency verification process 500 of an exemplary multi-core processor according to an embodiment of the present application.

[0114] like Figure 5 As shown, in some embodiments, it is possible to first determine whether the processor performs a write operation (e.g., step 502). If the write operation is performed (the judgment result is yes), then it is determined whether to terminate the execution (e.g., step 504). For example, if there is no data to be written or the processor has no available cache or the state of the cache line has been converted to the end state, it is determined that the execution of the processor can be terminated (the judgment result is yes). If the execution of the processor is not terminated (the judgment result is no), then it is determined whether to perform the write operation. If the write operation is not performed (the judgment result is no), then a read operation is performed (e.g., step 506), and then it is determined whether the cache consistency of multiple processors is faulty (e.g., step 508). If there is an error (the judgment result is yes), then the error location can be determined (e.g., step 512), for example, which processor among the multiple processors has an error. After the error location is determined, the execution of the processor can be terminated, and engineers can adjust the faulty processor. If there is no error (the judgment result is no), then it is determined whether to terminate the execution (e.g., step 510). If the judgment result is no, then it is determined whether to perform the write operation; if the judgment result is yes, then the execution of the processor is terminated.

[0115] Figure 6 The following is a flow chart illustrating an exemplary method 600 for verifying cache coherence of a multi-core processor according to an embodiment of the present application. The method 600 may be executed by the electronic device 100 (host 100), and more specifically, by the verification system 200 running on the electronic device 100. The method 600 may include the following steps.

[0116] In step 602 , the electronic device 100 may obtain a model written in a target language, where the model is generated according to a transition rule between any two states of a cache line of a processor.

[0117] In some embodiments, a second conversion rule written in a first grammar can be generated based on a first conversion rule. A first function can be generated using the second grammar, where the first function is used to randomly generate cache line addresses. A second function can be generated using a third grammar, where the second function is used to save and pass parameters for a second operation of the processor, where the second operation includes at least a read operation and a write operation. A model is generated based on the second conversion rule, the first function, and the second function. Building models using different grammars of the target language can more efficiently describe and verify complex SoC system behavior while improving the flexibility and reusability of verification.

[0118] In step 604 , the electronic device 100 may parse the model to obtain at least one path of state transition of the cache line.

[0119] In some embodiments, a first state in a model can be determined. Based on the first state, a second state in the model and a first description of the state transition between the second state and the first state can be determined, where the second state is the state immediately preceding the first state. Based on the first state, the second state, and the first description, at least one path can be derived. Scenario inference technology based on verification tools can infer one or more possible paths ending in the first state, thereby increasing stimulus coverage and diversity of test scenarios.

[0120] In some embodiments, a third state in the model and a second description of the state transition between the third state and the second state can be determined based on the second state, where the third state is the state immediately preceding the second state. In response to the third state being the same as the first state, at least one path is obtained based on the first state, the second state, the third state, the first description, and the second description. By defining in the model that a complete path exists when the third state is the same as the first state, a stop time when extrapolating from the end state to the previous state (i.e., extrapolating to the initial state) can be used to resolve a complete path.

[0121] In step 606 , the electronic device 100 may generate a stimulus corresponding to at least one path and compile the stimulus into an executable file.

[0122] In some embodiments, a cache line address can be randomly generated, at least one operation can be generated based on at least one path, and the cache line address and at least one operation can be compiled into an executable file. This can simulate the execution process of a processor and thus verify cache coherence across multiple processors.

[0123] In some embodiments, a cache line address can be randomly generated, and based on the first description, a first operation of the processor corresponding to the first description is generated, where the first operation includes at least a read operation or a write operation. The cache line address and the first operation are compiled into an executable file. This effectively simulates a processor capable of performing read and write operations, thereby verifying cache coherence across multiple processors.

[0124] At step 608 , the electronic device 100 may run the executable file to verify cache coherence of the multiple processors.

[0125] In some embodiments, an executable file may be run to obtain a return value corresponding to the executable file, a target value corresponding to the return value in a stimulus may be determined, cache consistency of multiple processors may be verified based on the return value and the target value, and cache consistency of the multiple processors may be determined in response to the return value being the same as the target value. Whether the caches of the multiple processors are consistent may be determined by comparing the return value with the expected value.

[0126] In some embodiments, the target language includes a domain-specific language, the domain-specific language includes a PSS language, and the stimulus includes code written in a software description language, the software description language including at least one of C or C++. A model written in the target language can automatically generate stimuli for verifying cache coherence, thereby generating a greater number of stimuli to cover as many test scenarios as possible, thereby making cache coherence verification of the processor more comprehensive.

[0127] The present application provides a method, electronic device, and storage medium for verifying the cache consistency of a multi-core processor. The method generates a model written in a target language based on a first conversion rule between any two states of a cache line of the multi-core processor, and parses the model to obtain at least one path for the state conversion of the cache line. By generating a stimulus corresponding to the at least one path, the stimulus is compiled into an executable file, and the cache consistency of the multi-core processor is verified by running the executable file. The model written in the target language generated in this way can automatically generate a stimulus for verifying cache consistency, thereby generating a larger number of stimuli, covering as many test scenarios as possible, and making the cache consistency verification of the multi-core processor more comprehensive.

[0128] The embodiment of the present application also provides an electronic device. The electronic device can be Figure 1 The electronic device 100 may include a memory for storing a set of instructions; and at least one processor configured to execute the set of instructions so that the electronic device performs the method 600.

[0129] The embodiment of the present application further provides a non-transitory computer-readable storage medium that stores a set of computer instructions, which are used to cause the electronic device to perform method 600 when executed.

[0130] The foregoing describes some embodiments of the present application. 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 an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0131] Those skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of the present application (including the claims) is limited to these examples. Within the scope of the present application, the above embodiments or technical features in different embodiments may be combined, the steps may be implemented in any order, and there are many other variations of the different aspects of the present application as described above, which are not provided in detail for the sake of simplicity.

[0132] Although the present invention has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of these embodiments will be apparent to those skilled in the art based on the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may utilize the embodiments discussed.

[0133] This application is intended to cover all such substitutions, modifications and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this application should be included in the scope of protection of this application.

Claims

1. A method for verifying cache consistency of a multi-core processor, comprising: Obtaining a model written in a target language, wherein the model is generated according to a transition rule between any two states of a cache line of the multi-core processor; Parsing the model to obtain at least one path of state transition of the cache line; Generate a stimulus corresponding to the at least one path, and compile the stimulus into an executable file; as well as The executable file is run to verify cache consistency of the multi-core processor.

2. The method according to claim 1, wherein The parsing of the model to obtain at least one path of the state transition of the cache line further includes: determining a first state in the model; determining, based on the first state, a second state in the model and a first description of a state transition between the second state and the first state, wherein the second state is a state preceding the first state; The at least one path is obtained according to the first state, the second state, and the first description.

3. The method according to claim 2, wherein: The obtaining of the at least one path according to the first state, the second state, and the first operation further includes: determining, according to the second state, a third state in the model and a second description of a state transition between the third state and the second state, wherein the third state is a state preceding the second state; In response to the third state being the same as the first state, the at least one path is obtained according to the first state, the second state, the third state, the first description, and the second description.

4. The method according to claim 1, wherein The stimulus includes the address of the cache line and at least one operation corresponding to the at least one path, and generating the stimulus corresponding to the at least one path and compiling the stimulus into an executable file further includes: Randomly generating an address of the cache line; generating the at least one operation according to the at least one path; The address of the cache line and the at least one operation are compiled into the executable file.

5. The method according to claim 2, wherein: The stimulus includes the address of the cache line, and the generating of the stimulus corresponding to the at least one path and compiling the stimulus into an executable file further includes: Randomly generating an address of the cache line; generating, according to the first description, a first operation of the multi-core processor corresponding to the first description, where the first operation includes at least a read operation or a write operation; The address of the cache line and the first operation are compiled into the executable file.

6. The method of claim 1, wherein: The conversion rule includes a first conversion rule, the target language includes a first grammar, a second grammar, and a third grammar, the model includes a first function and a second function, and the method further includes: generating, according to the first conversion rule, a second conversion rule written in the first grammar; generating the first function using the second grammar, wherein the first function is used to randomly generate an address of the cache line; Generate the second function using the third grammar, where the second function is used to save and transfer parameters of a second operation of the multi-core processor, where the second operation includes at least a read operation and a write operation; The model is generated according to the second conversion rule, the first function and the second function.

7. The method of claim 1, wherein: The running of the executable file to verify the cache consistency of the multi-core processor further includes: Running the executable file to obtain a return value corresponding to the executable file; Determining a target value corresponding to the return value in the incentive; Verifying cache consistency of the multi-core processor according to the return value and the target value; In response to the return value being identical to the target value, it is determined that the cache of the multi-core processor is consistent.

8. The method of claim 1, wherein: The target language includes a domain specific language, the domain specific language includes a PSS language, the stimulus includes a code written in a software description language, and the software description language includes at least one of C or C++.

9. An electronic device comprising: a memory for storing a set of instructions; as well as At least one processor is configured to execute the set of instructions so that the electronic device performs the method according to any one of claims 1 to 8. 10 . A non-transitory computer-readable storage medium storing a set of instructions for a computer, the set of instructions being configured to cause the computer to perform the method according to claim 1 when executed.

Images