Detection of execution hazards in offloaded operations

Abstract

Detecting an execution hazard in an offloaded operation is disclosed. A second offload operation is compared to a first offload operation preceding the second offload operation. Based on the comparison of the second offload operation to the first offload operation, it is determined whether the second offload operation causes an execution hazard on the offload target device. If an execution hazard is detected, an error handling operation may be performed. In some examples, the offload operation is a processing-in-memory operation.

Description

Background Art

[0001] A computing system often includes several processing resources (e.g., one or more processors) that can fetch and execute instructions and store the results of the executed instructions in an appropriate place. A processing resource (e.g., a central processing unit (CPU) or a graphics processing unit (GPU)) can be used to execute instructions by performing logical operations on data, and can include several functional units such as, for example, an arithmetic logic unit (ALU) circuit, a floating point unit (FPU) circuit, and / or a combinational logic block. For example, the functional unit circuit may be used to perform arithmetic operations such as addition, subtraction, multiplication, and / or division on operands. Typically, the processing resources (e.g., the processor and / or the related functional unit circuit) are outside the memory array, and data is accessed via a bus between the processing resources and the memory array to execute the instruction set. To reduce the amount of accesses to fetch or store data in the memory array, the computing system may use a cache hierarchy that temporarily stores data that has been recently accessed or modified for use by the processing resources or a group of processing resources. However, by offloading certain operations to a memory-based execution device where the processing resources are implemented inside and / or near the memory so that data processing is performed closer to the storage location where the data is stored rather than bringing the data closer to the processing resources, the processing performance can be further improved. The memory-based execution device can reduce time and save power by reducing external communication (i.e., communication from the processor to the memory array).

Brief Description of the Drawings

[0002] [Figure 1]This is a block diagram of an exemplary system for detecting execution hazards in offloaded operations according to embodiments of the present disclosure. [Figure 2] This is a block diagram of another exemplary system for detecting execution hazards in offloaded operations according to embodiments of the present disclosure. [Figure 3] This is a block diagram of another exemplary system for detecting execution hazards in offloaded operations according to embodiments of the present disclosure. [Figure 4] This flowchart shows another exemplary system for detecting execution hazards in offloaded operations according to embodiments of the present disclosure. [Figure 5] This flowchart shows another exemplary method for detecting execution hazards in offloaded operations according to embodiments of the present disclosure. [Figure 6] This flowchart shows another exemplary method for detecting execution hazards in offloaded operations according to embodiments of the present disclosure. [Figure 7] This flowchart shows another exemplary method for detecting execution hazards in offloaded operations according to embodiments of the present disclosure. [Figure 8] This flowchart shows another exemplary method for detecting execution hazards in offloaded operations according to embodiments of the present disclosure. [Figure 9] This flowchart shows another exemplary method for detecting execution hazards in offloaded operations according to embodiments of the present disclosure. [Figure 10] This flowchart shows another exemplary method for detecting execution hazards in offloaded operations according to embodiments of the present disclosure. [Figure 11] This flowchart shows another exemplary method for detecting execution hazards in offloaded operations according to embodiments of the present disclosure. [Figure 12]This flowchart shows another exemplary method for detecting execution hazards in offloaded operations according to embodiments of the present disclosure. [Modes for carrying out the invention]

[0003] As computation throughput scales faster than memory bandwidth, many techniques have been proposed to keep data flowing to increasing computing power. Processing-in-memory (PIM) enabled hardware moves computation closer to memory, giving the logic near memory the benefit of higher memory bandwidth than the memory bandwidth available to the host. As an example, a possible PIM configuration involves adding simple vector computation elements and local registers within each dynamic random access memory (DRAM) bank. The host processor can then send fine-grained commands (loading into registers, storing from registers, adding, multiplying, etc.) performed in this bank-local logic simply by specifying the target address. For operations that do not directly access memory, only the bank identifier bit of the address is needed to specify which PIM unit is being addressed. In such configurations, PIM can avoid transferring data across the memory interface and slowing down the memory interface, thus increasing the achievable memory bandwidth and improving performance for increasingly data-constrained workload categories.

[0004] However, PIM complicates the memory model for software development and requires an understanding of architecture-specific memory placement details to develop high-performance, functional applications. If a sequence of PIM operations targets multiple addresses while operating on the same intermediate value in a local memory register (e.g., load + add [A]->R1 followed by store R1->[B]), these addresses must reside within the same PIM memory partition. If this is not the case, dependent PIM operations will map to registers in different partitions, causing the program to fail, and the source of the failure can be extremely difficult to debug. For example, PIM execution units are generally located at a specific level within a memory hierarchy (e.g., a bank or channel). For a PIM execution unit to operate on two addresses, both addresses must be contained within the same memory hierarchy partition to which the PIM execution unit is associated (e.g., the memory addresses of the target operands must map to the same physical memory bank). If software assumptions about address-to-physical memory mapping do not match hardware reality (e.g., due to misconfiguration) or addressing errors occur, dependent PIM operations may be incorrectly issued to the wrong memory bank, resulting in subtle memory or PIM register file corruption that can be difficult to debug. This represents a new complexity to the memory model, as it affects the values ​​of data that can be stored in or returned from memory, requiring an understanding of low-level hardware details for correct operation. Therefore, the ability to detect these incorrect PIM operations early is crucial to ensuring programmability and portability in PIM software.

[0005] Furthermore, PIM introduces a second related complexity to the memory model regarding PIM access, which has a race-like nature. Whenever a PIM command is issued that addresses a bank-local register as a source or destination operand, the specific register being accessed is determined by the bank ID bit of the target memory address (in addition to the register ID bit of the specific PIM command). To issue multiple PIM commands in parallel from different cores (which may be necessary to take advantage of the bandwidth benefits of PIM), the software must avoid issuing independent commands simultaneously, as this can lead to corruption of intermediate data if the independent commands target the same bank and register.

[0006] Detecting address mapping errors in PIM systems is a different problem from detecting bad races or memory errors in conventional multithreaded programs. Because they rely on hardware mapping of memory, these types of PIM errors are inextricably linked to the architecture and mapping configuration. This recognition presents a fundamental portability and programmability challenge for PIM software that does not exist in standard shared-memory multithreaded programs, making the problem more difficult than simply detecting data races between threads. For example, a program written for one address mapping may fail in a way that is only detectable at runtime if it is run directly on a new architecture with a different number of PIM modules or differently configured interleaving patterns. In contrast, data races in shared-memory programs can be detected in a hardware-independent manner. This makes the challenge of PIM mapping errors a much more difficult hurdle and makes supporting debugging all the more important.

[0007] To address the above, embodiments of this disclosure provide techniques and mechanisms for detecting potential mapping errors in offload operations targeting offload execution devices such as PIM modules. One exemplary mapping error type occurs when two PIM operations from a single thread are intended to map to the same PIM module, but are mapped to different modules. Another exemplary mapping error type occurs when two PIM operations from different threads are intended to map to different PIM modules, but are mapped to the same PIM module. Such mapping errors can cause execution hazards and incorrect execution in offload execution devices. Detecting these mapping errors facilitates the identification of violating instructions, enables improved programmability, enhances reliability in portable PIM software, and significantly improves debugging.

[0008] Embodiments provided in this disclosure relate to a method for detecting execution hazards in offloaded operations. The method includes comparing a second offload operation with a first offload operation preceding the second offload operation, and determining, based on the comparison between the second offload operation and the first offload operation, whether the second offload operation causes an execution hazard on the offload target device. In some embodiments, the method includes initiating an error handling action in response to determining that the second offload operation causes an execution hazard on the offload target device. The error handling action may include sending an error message, generating an error log entry, or triggering a fault.

[0009] In some embodiments, comparing a second offload operation with a first offload operation preceding the second offload operation includes comparing a second offload target device identifier associated with the second offload operation with a first offload target device identifier associated with the first offload operation. In these embodiments, determining whether the second offload operation causes an execution hazard on the offload target device based on the comparison between the second and first offload operations includes detecting an execution hazard if the first and second offload target device identifiers do not match.

[0010] In some embodiments, the method may include storing a first offload target device identifier in response to an indicator that a first offload operation initiates a sequence of dependent offload operations. In these embodiments, comparing a second offload operation with a first offload operation preceding the second offload operation includes identifying the sequence label of the second offload operation and identifying the first offload target device identifier based on the sequence label of the second offload operation.

[0011] In some embodiments, comparing a second offload operation with a first offload operation preceding the second offload operation includes comparing a second thread identifier associated with the second offload operation with a first thread identifier associated with the first offload operation. In these embodiments, determining whether the second offload operation causes an execution hazard on the offload target device based on the comparison between the second and first offload operations includes detecting an execution hazard on the offload target device if the first and second thread identifiers do not match. In some embodiments, the method includes identifying that race detection is enabled on the offload target device. In these embodiments, identifying that race detection is enabled on the offload target device may include storing a first thread identifier for the first offload operation associated with a race detection indicator.

[0012] In some embodiments, the method includes identifying a pattern of sequential offload instructions having a first offload target device identifier. In some examples, the second offload operation and the first offload operation are PIM operations. In these examples, the first offload target device and the second offload target device are PIM modules. In some embodiments, comparing the second offload operation with a first offload operation preceding the second offload operation, and determining whether the second offload operation causes an execution hazard on the offload target device based on the comparison between the second and first offload operations, is performed at runtime.

[0013] Another embodiment of the present disclosure relates to a device for detecting execution hazards in offloaded operations. The device includes logic circuitry configured to compare a second offload operation with a first offload operation preceding the second offload operation, and to determine, based on the comparison between the second offload operation and the first offload operation, whether the second offload operation causes an execution hazard on an offload target device. In some embodiments, the logic is configured to initiate an error handling action in response to determining that the second offload operation causes an execution hazard on the offload target device. The error handling action may include sending an error message, generating an error log entry, or triggering a fault.

[0014] In some embodiments, comparing a second offload operation with a first offload operation preceding the second offload operation includes comparing a second offload target device identifier associated with the second offload operation with a first offload target device identifier associated with the first offload operation. In these embodiments, determining whether the second offload operation causes an execution hazard on the offload target device based on the comparison between the second and first offload operations includes detecting an execution hazard if the first and second offload target device identifiers do not match.

[0015] In some embodiments, comparing a second offload operation with a first offload operation preceding the second offload operation includes comparing a second thread identifier associated with the second offload operation with a first thread identifier associated with the first offload operation. In these embodiments, determining whether the second offload operation causes an execution hazard on the offload target device based on the comparison between the second and first offload operations includes detecting an execution hazard on the offload target device if the first and second thread identifiers do not match.

[0016] Further embodiments of the present disclosure relate to a system for detecting execution hazards in offloaded operations, the system comprising two or more processor cores, two or more in-memory processing (PIM) modules, and logic circuits, the logic circuits configured to compare a second offload operation with a first offload operation preceding the second offload operation, and to determine, based on the comparison of the second offload operation with the first offload operation, whether the second offload operation causes an execution hazard on the offload target device. In some embodiments, the logic is configured to initiate an error handling action in response to determining that the second offload operation causes an execution hazard on the offload target device. The error handling action may include sending an error message, generating an error log entry, or triggering a fault.

[0017] In some embodiments, comparing a second offload operation with a first offload operation preceding the second offload operation includes comparing a second offload target device identifier associated with the second offload operation with a first offload target device identifier associated with the first offload operation. In these embodiments, determining whether the second offload operation causes an execution hazard on the offload target device based on the comparison between the second and first offload operations includes detecting an execution hazard if the first and second offload target device identifiers do not match.

[0018] In some embodiments, comparing a second offload operation with a first offload operation preceding the second offload operation includes comparing a second thread identifier associated with the second offload operation with a first thread identifier associated with the first offload operation. In these embodiments, determining whether the second offload operation causes an execution hazard on the offload target device based on the comparison between the second and first offload operations includes detecting an execution hazard on the offload target device if the first and second thread identifiers do not match.

[0019] Embodiments of this disclosure will be described in further detail, beginning with Figure 1. Throughout the specification and drawings, the same reference numerals refer to the same components. Figure 1 shows a block diagram of an exemplary system 100 for detecting execution hazards in offloaded operations according to this disclosure. The exemplary system 100 in Figure 1 includes two or more processor cores 102, 104. In various examples, the processor cores 102, 104 are CPU cores or GPU cores of a host device 130 configured to host single-threaded or multi-threaded applications. For example, the host device 130 may host a multi-threaded application such that each processor core 102, 104 executes each thread of the multi-threaded application. The processor cores 102, 104 implement an instruction set architecture that includes offload instructions for offloading operations to an offload target device. The offload instructions are completed by the processor cores 102, 104, for example, when the memory address associated with the offload instruction is resolved, the operand value in the processor register is available, and a memory check is completed. The operations indicated in the offload instruction (e.g., load, store, add, multiply) are not executed on the processor core, but are instead offloaded for execution on an offload target device. Upon completion of the offload instruction, processor cores 102 and 104 generate and issue an offload request or command containing the offload operation, operand values ​​and memory addresses, and other metadata. In this way, the workload on processor cores 102 and 104 is reduced by offloading operations to be executed on devices outside or remote of processor cores 102 and 104.

[0020] For example, the offload operation may be a processing-in-memory (PIM) operation that instructs the PIM module to perform an operation on data stored in the PIM-capable memory device. In such an example, the operator of the offload instruction may include a load operator, a store operator, and an arithmetic operator, and the operand of the offload instruction may include a PIM register (i.e., a register local to the PIM module), a memory address, and a value from a core register or other core computed value.

[0021] Also, system 100 includes at least one memory controller 106 shared by processor cores 102, 104 to access memory device 108. Although the example of FIG. 1 shows a single memory controller 106, system 100 may include multiple memory controllers each corresponding to a memory channel within memory device 108. In some examples, memory controller 106 is used by processor cores 102, 104 to offload operations for execution by an offload target device. In these examples, memory controller 106 generates an offload command for the offload operation that instructs the offload target device to perform the offload operation in response to an offload request generated by processor cores 102, 104.

[0022] In some examples, the memory controller 106 and the host device 130 including the processor cores 102, 104 are implemented on the same chip (e.g., within a System-on-Chip (SoC) architecture). In some examples, the memory device, the memory controller 106, and the host device 130 including the processor cores 102, 104 are implemented on the same chip (e.g., within a System-on-Chip (SoC) architecture). In some examples, the memory device, the memory controller 106, and the host device 130 including the processor cores 102, 104 are implemented within the same package (e.g., within a System-in-Package (SiP) architecture).

[0023] In the exemplary system 100 of Figure 1, the memory device 108 is a PIM-enabled memory device that includes two or more PIM modules 110, 112, which are exemplary offload target devices in that the PIM modules 110, 112 are configured to perform operations offloaded from the host device 130. The host device 130 and the PIM modules 110, 112 share access to the same data that is generated and erased by applications running on the host device 130. For example, this data may be data stored in memory arrays 120, 122 of the memory device 108, to which the PIM modules 110, 112 are respectively coupled. The PIM modules 110, 112 are characterized by faster access to the data compared to the host device 130. In some examples, the PIM modules 110, 112 operate at the direction of processor cores 102, 104 to perform memory-intensive tasks. The memory arrays 120, 122 may be arrays of bank memory cells, arrays of banks, or other memory hierarchical partitions. For the purposes of this explanation, we assume that each PIM module 110, 112 is coupled to its respective memory bank (i.e., in the form of memory arrays 120, 122). Those skilled in the art will understand that various configurations of PIM modules and memory partitions (physical or logical) in a PIM-enabled memory device can be employed without departing from the spirit of this disclosure.

[0024] In the example in Figure 1, the PIM modules 110, 112 include control logic 114 for decoding instructions or commands issued from processor cores 102, 104, an arithmetic logic unit (ALU) 116 for performing offloaded operations (i.e., PIM operations) indicated in the instructions or commands, and a register file 118 for holding data to be read from or written to memory arrays 120, 122. In some examples, the ALU 116 can perform a limited set of operations relative to the ALUs of processor cores 102, 104, thereby simplifying the implementation of the ALU 116 and making it more suitable for in-memory applications. PIM operations can move data between a PIM temporary storage (e.g., the PIM register file 118) and / or memory arrays 120, 122, and can also trigger near-memory calculations on this data within the ALU 116. Each PIM operation carries a target address used to direct the PIM operation to the appropriate PIM module, and the operation to be performed, which may further specify the location within the PIM temporary storage (e.g., register file 118). Each PIM module 110, 112 can operate on a separate subset of the physical address space. When a PIM operation reaches a PIM module 110, 112, it is serialized with other PIM operations and memory accesses to memory arrays 120, 122.

[0025] In the exemplary system 100 shown in Figure 1, two PIM operations from a single thread running on a processor core are intended to map to the same PIM module; however, due to errors or misinterpretations in the mapping between memory addresses and memory banks or modules, they may instead be intended to map to different PIM modules. For example, the mapping function is likely to vary for different architectures, causing errors when porting the code. Furthermore, the mapping function may be dynamically programmed to optimize the data interleaving strategy for different workloads. Such errors are difficult to find and debug. Identifying such branching PIM operations is beneficial to simplify the process of programming, testing, and debugging new PIM software.

[0026] To facilitate programming, testing, and debugging of PIM-enabled software, the system 100 in Figure 1 also includes a branch detection device 150. The branch detection device 150 extracts a PIM module identifier from the target address bits of an associated PIM operation. As described below, the extracted PIM module identifiers of a set of PIM operations are compared to detect a branch in the set of PIM operations, where a particular PIM operation targets a different PIM module than the other PIM modules targeted in the set of PIM operations. That is, the branch detection device 150 includes a logic circuit configured to compare a second offload operation with a first offload operation preceding the second offload operation, and to determine, based on the comparison between the second offload operation and the first offload operation, whether the second offload operation would cause an execution hazard on the offload target device. Specifically, the branch detection device 150 includes a logic circuit that compares a second offload target device identifier associated with a second offload operation with a first offload target device identifier associated with a first offload operation, and detects an execution hazard if the first offload target device identifier and the second offload target device identifier do not match.

[0027] In some embodiments, the branch detection device 150 identifies when a comparison should be performed. In one example, the branch detection device 150 identifies a program declaration of a sequence of offload operations (e.g., PIM operations) in which a comparison should be performed. In another example, one or more bits in an offload instruction (e.g., a PIM instruction) processed by processor cores 102, 104 are used to indicate that a subsequent PIM instruction must map to the same offload target device (e.g., PIM modules 110, 112). In yet another example, one or more bits in an offload instruction are used to indicate that the instruction must map to the same offload target device as the previous offload instruction. In yet another example, a separate, dedicated offload instruction (e.g., a PIM instruction) is used to indicate that a subsequent / previous offload instruction must map to the same offload target device (e.g., PIM modules 110, 112). In yet another example, access to a reserved target address identified in an offload instruction (e.g., a PIM instruction) is used to indicate that subsequent / previous offload instructions must map to the same offload target device (e.g., PIM modules 110, 112). In some embodiments, the hardware infers when to perform a comparison based on pattern detection without explicit instructions from the software.

[0028] For further explanation, consider an example vector addition kernel implemented by the PIM instruction. for i=0:N: PIM_Ld(a[i]->pimR1) PIM_Add(pimR1+=b[i]) PIM_St(pimR1->c[i])

[0029] In the example above, the elements of array a[] are read from memory into PIM register pimR1 in the PIM register file (e.g., PIM register file 118) (i.e., PIM_Ld(a[i]->pimR1)). The contents of pimR1 are then added to the elements of array b[] in memory, and the result is stored in pimR1 (i.e., PIM_Add(pimR1+=b[i])). The contents of pimR1 are then stored in the elements of array c[] (i.e., PIM_St(pimR1->c[i])). However, if arrays a[], b[] and c[] are not properly aligned (or the address offsets are not calculated correctly), a[i], b[i] and c[i] may all be mapped to different PIM modules, resulting in garbage values ​​being written to c[], which can lead to undefined, and potentially non-decisive behavior, when c[] is read later.

[0030] In some embodiments, the semantics in the instruction set architecture (ISA) are provided to indicate that a sequence of dependent PIM instructions maps to the same PIM module. For example, special instructions are provided to indicate the start and end of a sequence of PIM instructions that should map to the same PIM module (i.e., offload requests / commands generated from PIM instructions should target the same PIM module). The sequence start and sequence end instructions may be standalone instructions or modifications of conventional PIM instructions. To illustrate this feature, consider the above kernel example of code modified with sequence start / end semantics (shown in bold) according to embodiments of the present disclosure. for i=0:N: PIM_Ld_begin_seq(a[i]->pimR1) PIM_Add(pimR1+=b[i]) PIM_St(pimR1->c[i]) PIM_end_seq() Note that PIM_Ld_begin_seq is a sequence start instruction that includes a modification of the PIM_Ld instruction. In this case, PIM_Ld_begin_seq indicates that this instruction and the subsequent instructions are part of the same sequence of PIM instructions that should be mapped to the same PIM module. The PIM_end_seq() instruction is a sequence end instruction that indicates that subsequent instructions do not need to be mapped to the same PIM module associated with the sequence start instruction. In some examples, a sequence end instruction is not necessary, and the sequence ends when a new sequence begins.

[0031] In some embodiments, when a PIM sequence start instruction is identified in a thread running on processor cores 102, 104, a flag is set to extract the target PIM module ID from the target address bits of the associated PIM operation. In these embodiments, the flag travels through the load / store pipeline until a virtual-to-physical address translation is performed for the PIM instruction. In some examples, the target PIM module ID is then calculated based on architectural address mapping information. In other examples, the target PIM module ID is determined from the page offset bits and can therefore be calculated without virtual-to-physical translation. If only some of the bits used to identify the target PIM module ID are included in the page offset bits, it may be preferable to compare only these bits to avoid performing virtual-to-physical translation (at the expense of some precision). In the branch detection device 150, the target PIM module ID associated with the sequence start instruction is extracted and stored in a thread-local register as the active PIM module ID (replacing the previous content). The target PIM module ID of the subsequent instruction is then compared with the active PIM module ID. For example, when a subsequent PIM instruction is decoded, the subsequent PIM instruction sets a flag indicating that a PIM index check is required. The target PIM module ID is similarly calculated for these operations and compared to the value of the active PIM module ID associated with the current thread. If a mismatch exists, this indicates an execution hazard that may occur on the PIM module when the PIM operation is performed. When such an execution hazard is detected, an error handling operation may be initiated. For example, the branch detection device 150 may generate an interrupt or page fault, log warning information for debugging, and enforce a fault or other similar error handling operation.

[0032] In some examples, a single thread may interleave multiple instructions to offload PIM operations to multiple PIM modules 110, 112. This interleaving can improve memory parallelism and help hide latency in PIM operations. Additional detection mechanisms are provided to enable the compiler to implement this optimization while still detecting PIM mapping errors and branch PIM operations within sequences. In such examples, additional semantic / syntactic representations may be included in the PIM code to indicate that a PIM instruction is part of a particular sequence. For example, each PIM instruction may include a sequence label. This support can be implemented by allowing each PIM instruction to specify a bit indicating a sequence label used to associate operations targeting the same PIM module. To illustrate this feature, consider an example of PIM code modified with sequence start / end semantics and sequence label semantics (shown in bold) according to embodiments of the present disclosure. for i=0;i <N;i+=3: PIM_Ld_begin_seq(a[i]->pimR1,seq0) PIM_Ld_begin_seq(a[i+N]->pimR1,seq1) PIM_Add(pimR1+=b[i],seq0) PIM_Add(pimR1+=b[i+N],seq1) PIM_St(pimR1->c[i],seq0) PIM_St(pimR1->c[i+N],seq1) PIM_end_seq(seq0) PIM_end_seq(seq1) In the example above, the instructions are executed on processor core 102, where the instruction labeled seq0 a is required to map to the same PIM module (which may be determined to be PIM module 110 after the PIM module ID is extracted, for example), and the instruction labeled seq1 is required to map to the same PIM module (which may be determined to be PIM module 112 after the PIM module ID is extracted, for example).

[0033] In these examples, a sequence start instruction associated with a PIM load instruction indicates the start of a PIM sequence, causing the calculated PIM module ID to be stored in a table as the active PIM module. This table stores multiple indexes per thread (one for each active sequence label), and the sequence label associated with the sequence start operation is used to index the table. In subsequent PIM instructions, the target PIM module ID for the subsequent PIM instruction is calculated and compared to the entry in the table that matches the sequence label associated with the instruction. If there is a mismatch in the PIM module ID, the error handling action described above is taken.

[0034] For further explanation, Figure 2 shows an exemplary embodiment of the branch detection device 150. After the PIM instruction is decoded, the branch detection device 150 extracts PIM instruction information from the PIM request issued by the processor cores 102 and 104. The PIM ID extraction unit 202 extracts the PIM module ID from the resolved target memory address (or page offset) associated with the PIM instruction. If the sequence start flag is set, a write signal is asserted and the extracted PIM module ID is written to the active PIM module ID storage unit 204. If the PIM instruction has an associated sequence label, a new table entry is created for the sequence label and the extracted PIM module ID is written to the entry. The sequence label is then used to index the table to identify the active PIM module ID associated with a particular sequence. The PIM module IDs for each subsequent instruction that is neither a sequence start nor a sequence end are also extracted by the PIM ID extraction unit 202 and a read signal is asserted on the active PIM module ID storage unit 204. The stored active PIM module ID is read by the comparator 206 and compared with the extracted PIM module ID. If the PIM instruction includes a sequence label, the sequence label is indexed in a table in the active PIM module ID storage unit 204 and used to identify the active PIM module ID corresponding to that sequence label. If the active PIM module ID stored in the active PIM module ID storage unit 204 does not match the extracted PIM module ID, a PIM mapping error may occur, which can lead to execution hazards.

[0035] In some embodiments, existing software synchronization semantics may be leveraged instead of, or in addition to, modifying the processor core ISA using sequencing semantics. For example, a PIM architecture may already utilize memory fences or other synchronization semantics to implement the isolation of PIM commands from the same thread to the same PIM module and prevent their reordering in the memory system. In this case, information about PIM commands intended to map to the same module (in that they are isolated by the fence) may be used for branch PIM command detection. Since PIM fences are used only between accesses to the same PIM module, the branch detection device 150 described above may be modified to detect, based on the extracted PIM module ID of each PIM operation, if the PIM module accessed by the last PIM operation before the fence does not match the PIM module accessed by the first PIM operation after the fence. In some examples, the most recent PIM operation before the fence is latched (for example, by treating all PIM operations as sequence start operations), and the first PIM operation after each fence is latched by comparing it to this latched value. For example, this can also be achieved by setting a bit on a fence instruction to trigger a sequence check for the next PIM operation.

[0036] In some embodiments, instead of or in addition to modifying the processor core's ISA, branch PIM operations can be inferred. In some examples, an error log entry is generated for a PIM operation that targets a different PIM module than one or more preceding PIM operations. In some cases, the branch detection device 150 infers whether a request should be for the same PIM module and logs only requests that violate this inference to reduce the logged information. For example, the branch detection device 150 may identify that a threshold number of consecutive PIM operations or common patterns of PIM operation types targeted the same PIM module (by comparing each PIM module ID of each new PIM operation with the PIM module ID of the preceding PIM operation) and log the next PIM operation that does not target the same PIM module ID as a potential branch PIM operation that could cause an execution hazard. In the event of an actual fault, this log may be examined for instructions that were expected to map to the same PIM module.

[0037] Returning to Figure 1, in the exemplary system 100, two PIM operations from different threads (e.g., on different cores 102 and 104) are intended to map to different PIM modules, but in practice, they can map to the same PIM module. Similar to the previous error case of PIM operation branching, this error case of PIM module race conditions can occur when the mapping function changes for different architectures, causing errors when porting code. Furthermore, these errors are difficult to find and debug. Identifying such PIM module race conditions is beneficial to simplify the process of programming, testing, and debugging new PIM software.

[0038] To facilitate programming, testing, and debugging of PIM-enabled software, the system 100 in Figure 1 includes a race detection device 152. The race detection device 152 extracts thread identifiers (thread IDs) from the thread index bits or core index bits of offloaded PIM operations. As described below, the extracted thread IDs of a pair of PIM operations are compared to detect a race condition between two threads in a PIM module, where a specific thread ID accesses a different PIM module than other thread IDs within the pair of PIM modules. Unlike PIM operation branches, PIM operations with a race nature issued by multiple threads cannot be easily detected by processor cores 102, 104. Therefore, in some embodiments, the race detection device 152 is implemented within PIM modules 110, 112. In other embodiments, the race detection device 152 may be implemented elsewhere in the shared memory system (e.g., within the memory controller 106). For example, the memory controller mediates between offloaded PIM operations for access to a given PIM module 110, 112.

[0039] In other words, the race detection device 152 includes a logic circuit configured to compare a second off-road operation with a first off-road operation preceding the second off-road operation, and to determine, based on the comparison between the second off-road operation and the first off-road operation, whether the second off-road operation causes an execution hazard on the off-road target device. Specifically, the logic circuit is configured to compare a second thread identifier associated with the second off-road operation with a first thread identifier associated with the first off-road operation, and to detect an execution hazard on the off-road target device if the first thread identifier and the second thread identifier do not match.

[0040] For further explanation, consider the following example of a multithreaded version of the vector addition function described above. Thread 0 for i=0:(N / 2): PIM_Ld(a[i]->pimR1) PIM_Add(pimR1+=b[i]) PIM_St(pimR1->c[i]) Thread 1 for i=(N / 2+1):N: PIM_Ld(a[i]->pimR1) PIM_Add(pimR1+=b[i]) PIM_St(pimR1->c[i]) In this example, threads 0 and 1 run in parallel under the assumption that the two threads access array partitions that map to different PIM modules. However, if the assumed mapping is incorrect (or, in more complex code, the address calculation is wrong), the partition mapping will overlap, with both threads accessing the same PIM module's PIM register pimR1 simultaneously, leading to data corruption and invalid values ​​in c[].

[0041] One way to determine whether two competing PIM accesses will cause a race condition error is to compare the issuing threads or cores of the PIM accesses. In many cases, race-like operations (i.e., two PIM operations from different host threads accessing the same PIM module without any synchronization) should not occur. However, in some cases, it may be desirable for multiple threads to access the same PIM module. Thus, it is beneficial to allow software to specify when race-like PIM accesses should not occur.

[0042] In some embodiments, the race detection device 152 relies on programmer / compiler signals and indices to determine if a PIM access race is not permitted between two or more threads. In these embodiments, the issuing thread index bit, the issuing core index bit, or any subset of these bits (referred to herein as the thread ID) is sent to the memory device 108 with each PIM request. During the race-free interval, a particular PIM module should provide only PIM access to offload PIM operations to a single thread or processor core. In some examples, a global race-free start signal (and optionally a race-free end signal) may be used to enable or disable race detection in all or a subset of the PIM modules 110, 112. In these examples, these signals are implemented via access to memory-mapped addresses. In some examples, race detection is individually enabled or disabled in each PIM module 110, 112 via special memory access. In some examples, race detection is individually enabled or disabled in each PIM module 110, 112 via PIM operations to the target PIM module (similar to the "start sequence" and "end sequence" operations described above). When race detection is first enabled, the thread ID is extracted from the PIM operation associated with the enable signal, such as the first PIM operation after the enable signal or the PIM operation that enables race detection. The thread ID is stored as the active thread index in a register local to the PIM module. Subsequent PIM operations (which themselves do not represent enable or disable signals) are checked to compare their thread IDs with the currently active thread index. If there is a mismatch, an invalid PIM race condition is detected. In response to the detection of an invalid race condition, an error handling operation is performed. The error handling operation may include sending a Nack message back to the requesting processor core, raising a wire that triggers a fault, or writing error information to a log that can be queried by the host.To enable different threads to access the PIM module at different times, a race-free end signal or a new race-free start signal must be provided to the PIM module, which can be automatically inserted at the synchronization point. To enable different threads to access different registers of the PIM module simultaneously, individual thread IDs can be stored and looked up for each register accessed by the PIM operation.

[0043] In various embodiments, comparing identifiers such as PIM module IDs or thread IDs may involve comparing a subset of bits within the PIM module ID or thread ID rather than the complete identifier. Doing so can reduce overhead costs at the expense of hazard detection accuracy (which may increase the likelihood of false positives). For debugging purposes rather than code functionality, high accuracy may not be necessary, and this trade-off may be desirable in many systems.

[0044] For further explanation, Figure 3 shows an exemplary embodiment of the race detection device 152. When the thread ID extraction unit 302 detects a race detection signal, it extracts the thread ID associated with the first PIM operation after the race detection signal or a PIM operation simultaneous with the race detection signal. A write signal is asserted in the active thread ID storage unit 304 to record the extracted thread ID as the active thread index. The thread IDs for each subsequent PIM operation that is not the race detection start or race detection end signal / indicator are also extracted by the PIM ID extraction unit 202, and a read signal is asserted on the active thread ID storage unit 304. The stored active thread index is read by the comparator 306 and compared with the extracted thread ID there. If the stored active thread ID in the active thread ID storage unit 304 does not match the extracted thread ID, a PIM mapping error may have occurred, which can lead to execution hazards.

[0045] In some embodiments, a race detection signal or indicator indicates that an active thread ID should be stored for each PIM register within a PIM module so that race-like access to the same PIM module is permitted, but race-like access to the same PIM register is not permitted. In these embodiments, the active thread index is tracked per register, rather than per module. For each PIM operation targeting a PIM register, the thread ID associated with the PIM operation is compared with the active thread index for that PIM register, which is latched in response to the race detection signal. In such an example, the active thread ID storage unit 304 stores active thread indices for multiple registers in the register file 118 within PIM modules 110, 112.

[0046] In some embodiments, the race detection device 152 tracks the active threads of a plurality of PIM modules 110, 112. For example, the race detection device 152 may be implemented in a memory device 108 or a memory controller 106 so that the race detection device 152 monitors PIM access to the plurality of PIM modules 110, 112. In these embodiments, the active thread ID storage unit 304 includes a table in which each entry includes a PIM module ID and an active thread index for that PIM module.

[0047] In some embodiments, when race detection is enabled, race-like writes are not permitted, but race-like reads are. In this case, only PIM operations writing to the PIM register are compared with the active thread index. This ensures that the race detection device 152 remains unconcerned with races between a single active writer and simultaneous readers with race characteristics.

[0048] For further explanation, Figure 4 shows a block diagram of an exemplary system 200 for detecting execution hazards in offloaded operations as described herein. Exemplary system 200 shows an alternative configuration of system 100 in Figure 1. Exemplary system 200 shows an alternative configuration of branch detection device 150 shared by two or more cores 102, 104. In such a configuration, branch detection device 150 tracks the active PIM module IDs of two or more threads. Thereafter, branch detection device 150 identifies the thread ID (e.g., core index or thread index) associated with the first PIM operation in a sequence and stores the thread identifier along with the active PIM module ID. The thread identifiers of subsequent instructions in the sequence are also identified and used to index the corresponding active PIM module ID for comparison. If a sequence label is used, the thread identifier is used to index the sequence label and the corresponding active PIM module ID.

[0049] In the exemplary system 200, an alternative configuration of the race detection device 152 is shown, in which the race detection device 152 is implemented within the memory controller 106. In this configuration, the race detection device 152 must track the active thread IDs of two or more PIM modules. Thereafter, the branch detection device 150 identifies the PIM module ID targeted by the PIM operation and uses the PIM module ID to index the active thread ID of that PIM module.

[0050] For further explanation, Figure 5 is a flowchart illustrating an exemplary method for detecting execution hazards in offloaded operations according to embodiments of the present disclosure. The embodiment in Figure 4 includes comparing a second offload operation with a first offload operation preceding the second offload operation 502. In some examples, comparing a second offload operation with a first offload operation preceding the second offload operation 502 includes comparing characteristics of the offload operations, such as operands including an offload target device identifier, issuing thread index, issuing core index, target memory address or register, and / or compiler notation or declarations (e.g., instruction labels or flags). In one example, the offload operation is a PIM operation to be executed on a PIM device, the offload request for the offload operation is generated from an offload instruction executed on a processor core, and the PIM module is implemented in or near memory outside the processor core.

[0051] Furthermore, the method in Figure 5 includes determining whether the second offload operation causes an execution hazard on the offload target device based on a comparison of the second offload operation with the first offload operation 504. In some examples, determining whether the second offload operation causes an execution hazard on the offload target device based on a comparison of the characteristics of the offload operations 504 includes identifying a branch in the offload device targeted by the offload instruction from a comparison of the characteristics of the offload operations. For example, a sequence of offload instructions within a processor core targeting a particular offload device may represent an explicit or implicit pattern, and as a result, offload instructions targeting different offload devices may indicate a mapping error or a deviation from a pattern that could otherwise lead to an execution hazard on the intended or unintended offload device. In another example, offload instructions received on an offload device from different threads / cores may indicate a mapping error or a race condition that could otherwise lead to an execution hazard on the offload device. Such mapping errors or execution hazards are detected by comparing the characteristics of an instant offload operation to one or more previous offload operations, the characteristics may include operands containing an offload target device identifier, issuing thread index, issuing core index, target memory address or register, and / or compiler notation or declarations (e.g., instruction label or flags). Continuing the above examples, the offload device may be a PIM module implemented in or near memory outside the processor core, as described above. In some examples, determining whether the second offload operation would cause an execution hazard on the offload target device based on a comparison of the second offload operation with the first offload operation is done at runtime before offloading the offload operation to the offload target device. In this case, if an execution hazard is detected, the PIM operation is not provided to the PIM module.

[0052] In some embodiments, software may explicitly communicate which actions depend on each other and require hazard checking (for example, the compiler path may infer which actions have dependencies and which should be independent). Alternatively, hardware may infer when hazard checking should be performed based on observed patterns. For example, if a thread repeatedly issues the same three actions, and all actions within each set of three actions map to the same offload target device, hazard detection may be triggered when any of the offload actions within a subsequent set of three actions map to a different offload target device than the other two in that set. This may not accurately identify the hazard because the programmer's intent is not explicitly specified (for example, the violating action may be intended to map to a different target device), but logging warnings at these times is helpful for programmability and debugging.

[0053] For further explanation, Figure 6 is a flowchart illustrating another exemplary method for detecting execution hazards in offloaded operations according to the present disclosure. Similar to the method in Figure 5, the method in Figure 6 includes comparing a second offload operation with a first offload operation preceding the second offload operation 502, and determining, based on the comparison of the second offload operation with the first offload operation, whether the second offload operation causes an execution hazard on the offload target device 504. The method in Figure 6 also includes initiating an error handling action 602 in response to determining that the second offload operation causes an execution hazard on the offload target device. In some embodiments, initiating an error handling action 602 in response to determining that the second offload operation causes an execution hazard on the offload target device is performed by sending an error message or Nack, triggering a fault, forcing a fault, or creating an entry in an error log.

[0054] For further explanation, Figure 7 is a flowchart illustrating another exemplary method for detecting execution hazards in offloaded operations according to the present disclosure. Similar to the method in Figure 5, the method in Figure 7 includes comparing a second offload operation with a first offload operation preceding the second offload operation 502, and determining, based on the comparison of the second offload operation with the first offload operation, whether the second offload operation causes an execution hazard on the offload target device 504.

[0055] In the method shown in Figure 7, comparing a second offload operation to a first offload operation preceding the second offload operation 502 includes comparing a second offload target device identifier associated with the second offload operation to a first offload target device identifier associated with the first offload operation 702. In some examples, comparing a second offload target device identifier associated with a second offload operation to a first offload target device identifier associated with a first offload operation 702 is performed by extracting the second offload target device identifier from data describing the second offload operation and the first offload target device identifier from data describing the first offload operation. In some examples, the first offload operation may be a reference operation in that the second offload operation is expected to map to the same offload target device as the first offload operation. In some embodiments, the first and second offload operations are PIM operations targeting a PIM module. In these embodiments, the PIM module ID is extracted from a subset of bits in the resolved target memory address or from the page offset using an architecture mapping table.

[0056] In the method shown in Figure 7, determining whether a second offload operation causes an execution hazard on an offload target device based on a comparison of the second offload operation with the first offload operation 504 includes detecting an execution hazard on an offload target device if the first offload target device identifier and the second offload target device identifier do not match 704. In some examples, detecting an execution hazard if the first offload target device identifier and the second offload target device identifier do not match 704 is performed by determining that an offload target device mapping error has occurred based on the identification that the first offload target device identifier and the second offload target device identifier do not match. Assuming that the second offload operation and the first offload operation should be mapped to the same offload target device, the detected offload target device mapping error presents an execution hazard to the intended offload target device, an unintended offload target device, or both. In some embodiments, the first off-road target device identifier is a reference identifier in which a second off-road operation is expected to be mapped to this identifier.

[0057] In some embodiments, comparing a second offload target device identifier associated with a second offload operation with a first offload target device identifier associated with a first offload operation (702), and detecting an execution hazard if the first offload target device identifier and the second offload target device identifier do not match (704), is performed by a branch detection device 150 described with reference to Figure 1, in which the branch detection device 150 is implemented on processor cores 102 and / or processor cores 104. In some examples, as shown in Figure 4, the branch detection device 150 may be shared by multiple processor cores 102, 104. In these examples, the branch detection device 150 distinguishes between offload operations issued by multiple cores and the offload devices targeted by those operations. In such an example, comparing a second offload operation with a first offload operation preceding the second offload operation 502 further includes identifying a second thread identifier associated with the second offload operation and a first thread identifier associated with the first offload operation.

[0058] For further explanation, Figure 8 is a flowchart illustrating another exemplary method for detecting execution hazards in offloaded operations according to the present disclosure. Similar to the method in Figure 7, the method in Figure 8 includes comparing a second offload operation with a first offload operation preceding the second offload operation 502, which includes comparing a first offload target device identifier associated with the second offload operation with a second offload target device identifier associated with the first offload operation 702; and determining, based on the comparison of the second offload operation with the first offload operation, whether the second offload operation causes an execution hazard on the offload target device 504, which includes detecting an execution hazard if the first offload target device identifier and the second offload target device identifier do not match 704.

[0059] Furthermore, the method in Figure 8 includes storing a first offload target device identifier 802 in response to an indicator that a first offload operation initiates a sequence of offload operations. In some embodiments, storing a first offload target device identifier 802 in response to an indicator that a first offload operation initiates a sequence of offload operations is performed by a branch detection device 150 shown in Figures 1, 2, or 4. In some examples, storing a first offload target device identifier 802 in response to an indicator that a first offload operation initiates a sequence of offload operations includes latching a first offload target device identifier associated with the first offload operation in the sequence of offload operations. For example, the first offload target device identifier is latched in response to a first offload operation that includes a sequence start flag or immediately after a sequence start instruction. In these examples, the first offload target device identifier is latched in a storage unit such as the active PIM module ID storage unit 204 described with reference to Figure 3. For example, the first offload target device identifier is extracted and latched in response to the detection of the start of a sequence of PIM operations. In this example, the offload target device identifier of each subsequent PIM operation, including the second offload target device identifier of the second offload operation, is compared to the latched first offload target device identifier until the end of the sequence is encountered or a new sequence is detected. The sequence of PIM operations can be detected from special instructions, flag bits, program instructions, or access to reserved target addresses, as described above. For example, a sequence start instruction and a sequence end instruction may be used to mark the boundaries of a sequence of PIM operations that should be mapped to the same PIM module.Upon detecting a sequence start instruction (for example, a PIM operation associated with a sequence start instruction, or a PIM operation identified by a flag bit set for the PIM operation or by following immediately after the sequence start instruction), the PIM module ID associated with the PIM operation is latched for future reference.

[0060] In some examples, each offload operation is treated as a sequence start operation, in which case the offload target device identifier is latched from all offload operations. When used with synchronization primitives such as fences, the offload target device identifier latched immediately after a fence may be compared to the offload target device identifier latched immediately before the fence. For example, a PIM operation immediately after a fence may be compared to a PIM operation immediately before the fence for the purpose of detecting execution hazards or identifying potential memory mapping errors.

[0061] For further explanation, Figure 9 is a flowchart illustrating another exemplary method for detecting execution hazards in offloaded operations according to the present disclosure. Similar to the method in Figure 8, the method in Figure 9 includes: 802 storing a first offload target device identifier in accordance with an indicator that a first offload operation initiates a sequence of offload operations; 502 comparing a second offload operation with a first offload operation preceding the second offload operation, including 702 comparing a second offload target device identifier associated with the second offload operation with a first offload target device identifier associated with the first offload operation; and 504 determining, based on the comparison of the second offload operation with the first offload operation, whether the second offload operation causes an execution hazard to the offload target device, including 704 detecting an execution hazard if the first offload target device identifier and the second offload target device identifier do not match.

[0062] In the method shown in Figure 9, storing a first offload target device identifier 802, in response to an indicator that the first offload operation initiates a sequence of offload operations, includes storing a sequence label 902 for the first offload operation. In some embodiments, storing a sequence label 902 for the first offload operation is performed by a branch detection device 150 shown in Figures 1, 2, or 4. In some examples, storing a sequence label 902 for the first offload operation includes reading the sequence label from information associated with the first offload operation. For example, the first offload operation may be associated with a sequence start instruction that includes a sequence label. Storing a sequence label 902 for the first offload operation may also include setting a flag to indicate that the sequence labels for subsequent operations should be identified from information associated with those operations. In some examples, the offload operations are PIM operations, and the offload target device is a PIM module. In these examples, the sequence label of the PIM operation associated with the sequence start instruction and the corresponding active PIM module ID are stored in a table in the branch detection module's active PIM module ID storage unit 204, as shown with reference to Figure 2.

[0063] In the method shown in Figure 9, comparing a second offload operation to a first offload operation preceding the second offload operation 502 further includes identifying the sequence label of the second offload operation 904. In some embodiments, identifying the sequence label of the second offload operation 904 is performed by a branch detection device 150 shown in Figures 1, 2, or 4. In some examples, identifying the sequence label for the second offload operation 904 includes reading the sequence label from information associated with the second offload operation. For example, the second offload operation may be an operation following a first offload operation associated with a sequence start instruction. In such an example, the sequence label of the second offload operation may be read in response to identifying that a flag has been set to check the sequence label of the offload operation.

[0064] In the method shown in Figure 9, comparing a second offload operation to a first offload operation preceding the second offload operation 502 further includes identifying a first offload target device identifier based on the sequence label of the second offload operation 906. In some embodiments, identifying a first offload target device identifier based on the sequence label of the second offload operation 906 is performed by a branch detection device 150 shown in Figure 1, Figure 2, or Figure 4. In some examples, the sequence label of the second offload operation is used to index a table containing entries for the corresponding active offload target device identifier. In some examples, the offload operation is a PIM operation, and the offload target device is a PIM module. In these examples, the sequence label of the PIM operation associated with the second offload operation is used to identify and offload a target device identifier from a table of active PIM module IDs stored in the active PIM module ID storage unit 204 of the branch detection module, as described with reference to Figure 2.

[0065] For further explanation, Figure 10 is a flowchart illustrating another exemplary method for detecting execution hazards in offloaded operations according to the present disclosure. Similar to the method in Figure 7, the method in Figure 10 includes comparing a second offload operation with a first offload operation preceding the second offload operation 502, which includes comparing a second offload target device identifier associated with the second offload operation with a first offload target device identifier associated with the first offload operation 702, and determining, based on the comparison of the second offload operation with the first offload operation, whether the second offload operation causes an execution hazard on the offload target device 504, which includes detecting an execution hazard if the first offload target device identifier and the second offload target device identifier do not match 704.

[0066] Furthermore, the method in Figure 10 includes identifying a pattern of sequential offload instructions having a first offload target device identifier 1002. In some embodiments, a threshold number of consecutive accesses to the same offload target device is required before access to a different offload target device is considered to be branching in such a way that execution hazards may exist. In some examples, identifying a pattern of sequential offload instructions having a first offload target device identifier 1002 includes extracting an offload target device identifier for each offload operation encounter and comparing it to the immediately preceding offload target device identifier. For each instance in which a subsequent offload target device identifier matches the first offload target device identifier, a counter is incremented. When the counter reaches a threshold number of instances of matching offload target device identifiers, a flag is set to indicate that the threshold has been met. While the flag is set, a mismatch between the first and second offload target device identifiers may indicate that the second offload operation is a branching offload operation that could potentially map to an incorrect offload target device. In this case, potential execution hazards can be logged to the error log for use in debugging.

[0067] For further explanation, Figure 11 is a flowchart illustrating another exemplary method for detecting execution hazards in offloaded operations according to the present disclosure. Similar to the method in Figure 5, the method in Figure 11 includes comparing a second offload operation with a first offload operation preceding the second offload operation 502, and determining, based on the comparison of the second offload operation with the first offload operation, whether the second offload operation causes an execution hazard on the offload target device 504.

[0068] In the method shown in Figure 11, comparing a second offload operation with a first offload operation preceding the second offload operation 502 includes comparing a second thread identifier associated with the second offload operation with a first thread identifier associated with the first offload operation 1102. In some embodiments, comparing a second thread identifier associated with a second offload operation with a first thread identifier associated with a first offload operation is performed by a race detection device 152 described with reference to Figures 1, 3, and 4. In some examples, comparing a second thread identifier associated with a second offload operation with a first thread identifier associated with a first offload operation 1102 includes identifying a thread index or core index associated with the second offload operation and the first offload operation, and using the thread index or core index as a thread identifier for the second offload operation and the first offload operation, respectively. In some examples, the thread index or core index includes information about the second and first offload operations received from processor cores 102 and 104. In some embodiments, the second and first offload operations are PIM operations offloaded to PIM modules 110 and 112.

[0069] In the method shown in Figure 11, determining whether a second off-road operation creates an execution hazard on an off-road target device based on a comparison of the second off-road operation with the first off-road operation 504 includes detecting an execution hazard on the off-road target device 1104 if the first thread identifier and the second thread identifier do not match. In some embodiments, detecting an execution hazard on the off-road target device 1104 if the first thread identifier and the second thread identifier do not match is performed by a race detection device 152 described with reference to Figures 1, 3 and 4. In some examples, detecting an execution hazard on the off-road target device 1104 if the first thread identifier and the second thread identifier do not match includes determining that two processor cores (e.g., processor cores 102, 104) have created a race condition for access to an off-road target device (e.g., PIM module 110). In these examples, a race condition is detected based on the determination that the thread identifier of the second offload operation does not match the thread identifier of the first offload operation. For example, the second and first offload operations may be PIM operations. When an execution hazard caused by a race condition is detected, the offload target device may send a Nack or error message to the processor core and / or trigger a fault.

[0070] For further explanation, Figure 12 is a flowchart illustrating another exemplary method for detecting execution hazards in offloaded operations according to the present disclosure. Similar to the method in Figure 11, the method in Figure 12 includes comparing a second offload operation with a first offload operation preceding the second offload operation 502, which includes comparing a second thread identifier associated with the second offload operation with a first thread identifier associated with the first offload operation 1102, and determining, based on the comparison of the second offload operation with the first offload operation, whether the second offload operation causes execution hazards on the offload target device 504, which includes detecting execution hazards on the offload target device if the first thread identifier and the second thread identifier do not match 1104.

[0071] Furthermore, the method in Figure 12 includes identifying that race detection is enabled on the off-road target device 1202. In some embodiments, identifying that race detection is enabled on the off-road target device 1202 is performed by a race detection device 152 described with reference to Figures 1, 3 and 4. In some examples, identifying that race detection is enabled on the off-road target device 1202 is performed by detecting a race detection signal. A race detection signal may be used to enable or disable race detection on one or more off-road target devices. In some examples, identifying that race detection is enabled on the off-road target device 1202 is performed by identifying an off-road operation that enables or disables race detection on the off-road target device. In some examples, identifying that race detection is enabled on the off-road target device 1202 is performed by identifying access to a reserved target memory address on the off-road target device. While race detection is enabled, race conditions are not permitted on the off-road target device in that only off-road operations resulting from the same thread identifier should be allowed to run.

[0072] In some embodiments, identifying that race detection is enabled on the off-road target device 1202 includes storing a first thread identifier 1204 for a first off-road operation associated with a race detection indicator. For example, the race detection indicator may be a race detection signal, a race detection that enables an off-road operation, or access to a reserved target memory address as described above. In some examples, the first off-road operation is associated with the race detection indicator in that it is the first off-road operation after the race detection indicator has enabled race detection. In some examples, the off-road operation itself may include a race detection indicator that enables race detection. Upon identifying that race detection, in some examples, the thread identifier associated with the first off-road operation is latched. For example, the first off-road operation may be a PIM operation, and the off-road target device may be a PIM module 110, 112. In this example, storing a first thread identifier for a first offload operation associated with a race detection indicator 1204 can be done by storing the thread identifier associated with the processor cores 102, 104 that issued the offload operation in the active thread ID storage unit 304, as described with reference to Figure 3.

[0073] The flowcharts and block diagrams in the figures illustrate the architecture, function, and operation of possible embodiments of the systems, methods, and logic circuits according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions containing one or more executable instructions for implementing a specified logic function. In some alternative embodiments, the functions described in a block may occur in a different order than shown in the figure. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or blocks may be executed in reverse order depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, may be implemented by a dedicated hardware-based system that performs a specified function or action, or combines dedicated hardware with computer instructions.

[0074] While this disclosure has been specifically illustrated and described with reference to its embodiments, it should be understood that various modifications in form and detail may be made without departing from the spirit and scope of the following claims. Therefore, the embodiments described herein are for illustrative purposes only and do not limit the invention. This disclosure is defined by the appended claims rather than the detailed description, and all differences within that scope should be construed as being included within the invention.

Claims

1. A device for detecting execution hazards in offloaded operations, Equipped with logic circuits, The aforementioned logic circuit is The second off-road operation is compared with the first off-road operation that precedes the second off-road operation, Based on a comparison of the second offload operation and the first offload operation, it is determined whether the second offload operation causes an execution hazard on the offload target device, wherein the execution hazard is detected when the first offload operation and the second offload operation are assigned to different offload target devices. It is configured to do, Device.

2. The logic circuit is configured to initiate an error handling action when it determines that the second offload operation causes the execution hazard on the offload target device. The apparatus according to claim 1.

3. Comparing a second offload operation with a first offload operation preceding the second offload operation includes comparing a second offload target device identifier associated with the second offload operation with a first offload target device identifier associated with the first offload operation. Determining whether the second offload operation causes an execution hazard on the offload target device based on a comparison of the second offload operation and the first offload operation includes detecting the execution hazard if the first offload target device identifier and the second offload target device identifier do not match. The apparatus according to claim 1.

4. Comparing a second offload operation with a first offload operation preceding the second offload operation includes comparing a second thread identifier associated with the second offload operation with a first thread identifier associated with the first offload operation. Determining whether the second offload operation causes an execution hazard on the offload target device based on a comparison of the second offload operation and the first offload operation includes detecting the execution hazard on the offload target device if the first thread identifier and the second thread identifier do not match. The apparatus according to claim 1.

5. A system for detecting execution hazards in offloaded operations, Two or more processor cores, Two or more processing-in-memory (PIM) modules, Equipped with logic circuits, The aforementioned logic circuit is The second off-road operation is compared with the first off-road operation that precedes the second off-road operation, Based on a comparison of the second offload operation and the first offload operation, it is determined whether the second offload operation causes an execution hazard on the offload target device, wherein the execution hazard is detected when the first offload operation and the second offload operation are assigned to different offload target devices. It is configured to do, system.

6. The logic circuit is configured to initiate an error handling action when it determines that the second offload operation causes the execution hazard on the offload target device. The system according to claim 5.

7. Comparing a second offload operation with a first offload operation preceding the second offload operation includes comparing a second offload target device identifier associated with the second offload operation with a first offload target device identifier associated with the first offload operation. Determining whether the second offload operation causes an execution hazard on the offload target device based on a comparison of the second offload operation and the first offload operation includes detecting the execution hazard if the first offload target device identifier and the second offload target device identifier do not match. The system according to claim 5.

8. Comparing a second offload operation with a first offload operation preceding the second offload operation includes comparing a second thread identifier associated with the second offload operation with a first thread identifier associated with the first offload operation. Determining whether the second offload operation causes an execution hazard on the offload target device based on a comparison of the second offload operation and the first offload operation includes detecting the execution hazard on the offload target device if the first thread identifier and the second thread identifier do not match. The system according to claim 5.

Images