System on a chip, digital signal processor system, interruptible exclusive memory method

Abstract

System on a chip that features the following: a storage facility; a memory bus that is communicatively coupled to the memory; and a processor that is communicatively coupled to the memory via the memory bus, wherein the processor has a circuit arrangement for providing interruptible atomic memory operations with an exclusive memory functionality that includes the following: an exclusive memory instruction (STREX instruction) that is effective in interacting with a STREX state machine running in parallel with a main processor pipeline, wherein the STREX instruction has: an exclusive-memory initialization instruction (STREX_INIT instruction), wherein the STREX_INIT instruction is effective to initiate an exclusive-memory transaction into a location in memory, wherein the STREX_INIT instruction is non-interruptible and STREX_INIT causes the STREX state machine to enter a state in which it waits for a response to the transaction; an exclusive memory synchronization instruction (STREX_SYNC instruction), wherein the STREX_SYNC is interruptible and the STREX_SYNC instruction is effective to wait for the STREX state machine to receive a transaction response while monitoring an XWAVAIL indicator which is a bit of a STREX register (158), wherein the XWAVAIL indicator is effective to indicate that an XWRESULT response to the STREX_INIT primitive is available, wherein the XWRESULT response is effective to indicate whether the exclusive memory transaction into the location in memory was successful.

Description

AREA OF REVELATION

[0001] This application relates to a system on a chip, a digital signal processor system and a method with interruptible store exclusive memory. BACKGROUND

[0002] The Advanced Microcontroller Bus Architecture (AMBA) is an open, published standard for a bus on a chip, useful in designing system-on-a-chip (SoC) and application-specific integrated circuit (ASIC)-based microcontrollers. It is used in a wide range of mobile, embedded, and low-power environments. Since its inception, the scope of AMBA has expanded far beyond microcontroller devices and is now widely used in a range of ASIC and SoC parts, including application processors used in modern portable mobile devices such as smartphones. The AMBA standard specifies the interconnection and management of functional blocks in appropriate systems and is useful in designing systems with multiple controllers and / or peripherals.

[0003] The third generation of AMBA includes the advanced extensible interface (AXI), which is designed to accommodate high-performance, high-clock frequency systems.

[0004] The company publication “ARM: AMBA AXI Protocol - Specification, Version: 2.0” dated March 3, 2010, describes the AMBA AXI protocol in version V2.0.

[0005] The company publication “ARM: ARMv7-M Architecture Reference Manual, Issue D” dated February 12, 2010, describes the fourth version of the reference manual for the ARMv7-M architecture.

[0006] The English Wikipedia entry on "Load-link / store-conditional" from February 15, 2014, explains that in computer science, load-link and store-conditional (LL / SC) are a pair of instructions used in multiprogramming to achieve synchronization. A load-link returns the current value of a memory location, while a subsequent store-conditional at the same memory location stores a new value only if no changes have been made to that memory location since the load-link. Together, these instructions enable a lock-free, atomic read-modify-write operation.

[0007] The English Wikipedia entry on "Advanced Microcontroller Bus Architecture" from September 25, 2013, explains that the Advanced Microcontroller Bus Architecture (AMBA) is used as an on-chip bus in system-on-a-chip (SoC) designs. Since its introduction, AMBA's application scope has expanded far beyond microcontrollers and is now widely used in a variety of ASIC and SoC devices, including application processors used in modern portable mobile devices such as smartphones.

[0008] The 2007 course materials by John Kubiatowicz, "CS162 Operating Systems and Systems Programming," from the Department of Electrical Engineering & Computer Sciences at UC Berkeley, cover operating systems and systems programming and cover topics such as thread management, memory management, synchronization mechanisms, and hardware interactions. It explains basic concepts such as processes, threads, critical sections, and locks, as well as advanced topics such as semaphores and monitors. Interrupts, page replacement strategies, and the role of hardware in memory management are also discussed. Particular emphasis is placed on implementing synchronization methods and avoiding busy waiting. Communication between processor and hardware, including device drivers and memory management, is also covered. Overall, the document serves as an introduction to the functionality of modern operating systems.

[0009] The English Wikipedia entry on "callback" from February 17, 2014, explains that in computer programming, a callback is an executable piece of code passed as an argument to another code. This code is expected to invoke (execute) the passed argument at an appropriate time. The invocation can occur immediately, as in a synchronous callback, or at a later time, as in an asynchronous callback.

[0010] The paper by Smith, James et al., "Implementing precise interrupts in pipelined processors" in IEEE Transactions on Computers, 37, 1988, 5, pp. 562-573, ISSN 1557-9956, concerns precise interrupts in pipelined processors. It describes five implementation methods: 1) sequential instruction processing, 2) reorder buffers, 3) reorder buffers with bypass paths, 4) history buffers, and 5) future buffers. These techniques allow the system state to be accurately restored upon an interrupt without compromising parallelism in the pipeline. Simulations show that the reorder buffer with bypass paths offers the best performance, although implementation complexity varies. Challenges such as virtual memory management, cache integration, and extension to vector processors are also discussed. The results emphasize the importance of precise interrupts for efficient parallel architectures.

[0011] John Kubiatowicz's publication, "EECS 252 Graduate Computer Architecture, Lecture 4 Control Flow - Interrupts," from January 13, 2007, addresses control flow control and the challenges of interrupts and exceptions in pipelined processors. It explains how control flow changes caused by jumps, branches, interrupts, and exceptions can disrupt the pipeline and cause delays. It describes techniques such as delayed jumps, dynamic branch prediction, and the implementation of precise interrupts, which save the system state at a defined point. Approaches such as reorder buffers and history buffers are mentioned for orderly instruction completion. The focus is on minimizing performance losses and safely resuming program execution after interrupts. The importance of precise interrupts for debugging, restartability, and operating system design is emphasized.

[0012] Karen Smoler Miller's 1999 publication, "CS / ECE 354-2 Machine Organization and Programming," from the University of Wisconsin, provides an introduction to machine organization and assembly-level programming. It covers topics such as number systems, data representation, arithmetic operations, data structures, the use of registers, and Pentium assembly programming. It explains processes such as assembly translation, I / O operations, exception handling, and performance optimization. Particular emphasis is placed on exception handling, in which hardware triggers interrupts and an exception handler saves the system state, resolves the problem, and restores the state. Additional chapters cover virtual memory management and the MIPS RISC architecture. Relevant case studies reinforce the concepts.

[0013] It is a task to improve the handling of atomic memory operations in processors, especially when interrupts occur during exclusive memory transactions, which could affect system performance and compliance with real-time requirements.

[0014] The problem is solved by the subject matter of the independent patent claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The present disclosure is best understood from the following detailed description when read with the accompanying figures. It is emphasized that, in accordance with standard industry practice, various features are not drawn to scale and are used for illustrative purposes only. Indeed, the dimensions of the various features may be arbitrarily exaggerated or reduced for clarity of discussion. Fig.1 is a schematic block diagram of an example digital signal processor (DSP) core according to one or more examples of the present specification. Fig. 1A is a block diagram of a STREX register according to one or more examples of the present specification. Fig. 2 is a block diagram of a computing device 200 according to one or more examples of the present specification. Fig. 3 is a block diagram of a STREX state machine according to one or more examples of the present specification. Fig. 4-5 are flow diagrams of STREX_INIT and STREX_SYNC primitives according to one or more examples of the present patent specification. Fig. 6 is a flow diagram of a use case of LDEX and STREX primitives according to one or more examples of the present patent specification. Fig. 7 and Fig. 7A are signal timing diagrams of the truth table used in conjunction with Fig. 6, according to one or more examples of the present specification. DETAILED DESCRIPTION OF THE EMBODIMENTS OVERVIEW

[0016] In one example, a processor configured for interruptible atomic exclusive memory operations is disclosed. For example, a load exclusive (LDEX) may be followed by a store exclusive (STREX), the two together forming an atom. To facilitate timely handling of interrupts, the STREX operation is split into two parts. The STREX_INIT is not interruptible but has a specific execution time, requiring a fixed number of clock cycles. The STREX_INIT sends the value to the memory bus. This is followed by a STREX_SYNC operation, which queries a flag regarding whether a return value is available. STREX_SYNC is interruptible, and methods are disclosed for determining whether the atomicity of the operation has been broken upon return from an interrupt.If atomicity is violated, the instruction fails, whereas if atomicity is preserved, the instruction completes.

[0017] In another example, a system on a chip having a memory; a memory bus communicatively coupled to the memory; and a processor communicatively coupled to the memory via the memory bus is disclosed herein, the processor comprising circuitry for providing exclusive memory functionality comprising an exclusive memory initialization (STREX_INIT) instruction, the STREX_INIT instruction operable to initiate an exclusive memory transaction into a memory location; an exclusive memory synchronization (STREX_SYNC) instruction, the STREX_SYNC instruction operable to monitor an XWAVAIL indicator, the XWAVAIL indicator operable to indicate that an XWRESULT response to the STREX_INIT primitive is available, the XWRESULT response operable to indicate whether the exclusive memory transaction into the memory location was successful.

[0018] In yet another example, a digital signal processor system comprising a memory; a memory bus communicatively coupled to the memory; and a compute unit communicatively coupled to the memory via the memory bus, the compute unit operable to provide an exclusive memory primitive that supports executing an exclusive memory initialization primitive (STREX_INIT primitive), the STREX_INIT primitive operable to initiate an exclusive memory transaction into a location in memory;executing a separate exclusive memory synchronization primitive (STREX_SYNC primitive), the STREX_SYNC primitive operable to monitor an XWAVAIL indicator, the XWAVAIL indicator operable to indicate that an XWRESULT response to the STREX_INIT primitive is available, the XWRESULT response operable to indicate whether the exclusive memory transaction into the location in memory was successful;

[0019] In yet another example, a method for providing an exclusive memory primitive performed by a computing device is disclosed herein, comprising executing an exclusive memory initialization primitive (STREX_INIT primitive), wherein the STREX_INIT primitive is operable to initiate an exclusive memory transaction into a memory location; executing a separate exclusive memory synchronization primitive (STREX_SYNC primitive), wherein the STREX_SYNC primitive is operable to monitor an XWAVAIL indicator, wherein the XWAVAIL indicator is operable to indicate that an XWRESULT response to the STREX_INIT primitive is available, wherein the XWRESULT response is operable to indicate whether the exclusive memory transaction into the memory location was successful. EXAMPLE EMBODIMENTS OF THE DISCLOSURE

[0020] The following disclosure provides many different embodiments or examples for implementing various features of the present disclosure. Specific examples of components and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to be limiting. Furthermore, the present disclosure may repeat reference numerals and / or reference letters in the various examples. This repetition is for the purpose of simplicity and clarity and does not, in itself, imply any relationship between the various embodiments and / or configurations discussed.

[0021] Different embodiments may have different advantages, and no particular advantage is necessarily required for any embodiment.

[0022] AXI supports "exclusive" semaphore-type memory access. For example, with multiple processing cores operating in parallel, a core may want to perform an atomic read-work-write operation. To ensure that the slave (memory location) is not accessed during the atomic operation, the master (core) can perform an exclusive read and an exclusive write. The bus is not locked during the atomic operation. Rather, a memory controller can mark the affected memory location, and if another master accesses the location after the read is completed and before the write is completed, the AXI bus can set an error flag. An example of a memory controller that supports such an operation is the CoreLink DMC-400 dynamic memory controller from ARM.As used throughout this specification, a "memory controller" includes, under appropriate circumstances, the foregoing memory controller, any equivalent device or structure, a memory management unit (MMU), a combination of a memory controller and an MMU, or any device or combination of devices effective to perform the memory management and control methods disclosed herein. In common practice, an MMU may be located on a core side of the memory architecture, as shown in FIG. Fig. 1, while the bus and memory controller may be located on the memory side. Many other arrangements are possible, and this patent specification is intended to broadly encompass any such arrangement.

[0023] According to one or more example embodiments of the present specification, new "load exclusive" (LDEX) and "store exclusive" (STREX) primitives are defined. A "primitive," in this context, means a basic or primitive operation that can be used to construct higher-level operations in conjunction with other primitives or higher-level operations, and may be, by way of non-limiting example, a user-accessible hardware instruction, a non-user-accessible operation performed as part of another hardware instruction, a user-accessible software procedure, or a non-user-accessible software procedure performed as part of another user-accessible software procedure.

[0024] An LDEX primitive reads a value from a memory location and establishes exclusive access to that location. While a core has exclusive access to a location, the memory controller monitors the location and detects whether another core attempts to establish exclusive access or write a value to the location. In either case, the first core loses exclusive access.

[0025] A STREX performs an exclusive write transaction. The memory controller or equivalent block ensures that this transaction updates the memory location only if the initiating core has exclusive access to the location. A flag can be set or a return value provided, such as a signal on a bus, to indicate whether the location was successfully updated. Using a combination of LDEX and STREX, an atomic memory operation can thus be performed, such as acquiring a lock on a resource or requesting a semaphore. In one example, an atomic operation might involve reading a lock value from a memory location, checking whether the value is locked, and if the value is not locked, writing a locked value to the memory location, and then checking that the location was successfully updated.Obviously, a deadlock would occur if a core successfully modified a lock with the locked value but failed to detect that the update was successful. This might happen, for example, if an interrupt is initiated during an exclusive write transaction, causing the core to perform other work when the success or failure indication appears on the bus in response to the transaction. Consequently, it may be desirable to prevent interrupts during STREX operations so that deadlock does not occur.

[0026] However, the named inventors of the present patent specification have recognized that a non-interruptible STREX primitive can be problematic in cases of a cache or L1 memory miss, where values ​​must be flushed out, slowing down main memory. This can cause unacceptable delays, particularly in embedded or high-performance systems. This can also be problematic for systems intended to be certified for real-time operation, as such certification may require certain latencies that cannot be guaranteed in the case of a STREX primitive that precludes interrupts.

[0027] Advantageously, the present patent specification defines a STREX primitive that is divided into two separate primitives, each of which is either determined or interruptible. In one example, the first primitive is called "exclusive store initialization" (STREX_INIT) and initializes a write request without waiting for a response or checking for success. The second primitive is an "exclusive store synchronization" (STREX_SYNC), which is interruptible and enters a watchdog loop, waiting for a flag to be set indicating that a return value is available for the write request. Once a return value is detected, it is read, and a conditional branch may occur depending on whether the exclusive store was successful.

[0028] The STREX primitive of this patent specification interacts with a state machine running in parallel with a main processor pipeline. This state machine is responsible for waiting for the exclusive write transaction response and passing it back to a primitive running in the main processor pipeline.

[0029] In one example, the STREX_INIT primitive initiates the exclusive write transaction and causes the STREX state machine to enter a state where it waits for the transaction response. This instruction is not inherently interruptible, but the operation as a whole is interruptible within a fixed number of cycles, since both operations of the example STREX_INIT take a fixed number of cycles. After STREX_INIT completes, the STREX state machine proceeds to the STREX_SYNC state.

[0030] The STREX_SYNC primitive waits until the STREX state machine receives the transaction response and enters a "response-available state." Once the machine enters this state, the response is processed and an appropriate action is taken. The state machine then enters the inactive state.

[0031] The STREX_SYNC primitive is interruptible within a fixed number of cycles because it can be aborted while waiting for the STREX state machine to enter the response-available state and then safely restarted upon return from the interrupt (RTI) without losing the exclusive write transaction response. Once the state machine enters the response-available state, the response can be copied to the execution context within a fixed number of cycles.

[0032] Since these two primitives are interruptible within a fixed number of cycles, the sequence consisting of the two primitives is interruptible within a fixed number of cycles.

[0033] In one or more embodiments, after any STREX_INIT primitive is executed, a corresponding STREX_SYNC is expected to complete before another STREX_INIT can be initiated. This ensures that the transaction response is aligned with the correct STREX_INIT, which is a requirement of the AXI atomic exclusive protocol. In one example, upon encountering two STREX_INIT primitives without a complete STREX_SYNC in between, the processor raises an exception.

[0034] It may be considered the programmer's responsibility to avoid multiple STREX_INITs within a single program, but on a processor running a multitasking operating system, the operating system (OS) may be tasked with ensuring that the STREX sequence completes and the response is copied into the execution context before switching to a new flow or process. Thus, within its context-switching code, the OS can check whether the STREX state machine is either waiting for the response or has the response available, and if so, execute a STREX_SYNC to copy the response into the stored execution context. The STREX_SYNC primitive can thus be defined as no operation (NOP) when the STREX state machine is inactive, in which case it can be executed unconditionally.

[0035] Executing a STREX_SYNC primitive within the OS context switch code potentially extends the time it takes to switch context to the duration of any ongoing STREX transaction, but interrupt handlers with higher priority than the context switch code can still execute, so the overall interrupt latency is still fixed.

[0036] On a processor implementing the STREX primitives disclosed in this patent specification, an interrupt handler with higher priority than the context-switch code should not contain STREX_INIT or STREX_SYNC primitives. If they do, they may unconditionally be required to execute a STREX_SYNC upon entry to store the response in the context of the interrupted flow. This would wait for the completion of an ongoing exclusive write transaction, impacting interrupt latency.

[0037] In one example, the STREX_SYNC state can be used in an exception handler to reset the exclusive state for exceptions caused by LDEX or STREX primitives.

[0038] The LDEX primitive of this patent specification reads data from memory like a regular load instruction and also establishes exclusive access to the location. In one example, an exclusive load from non-shared memory via the memory management unit (MMU) performs exactly the same load as a regular load from the same location. However, an exclusive load from shared memory performs an exclusive read on the AXI bus.

[0039] In one example, the STREX primitive may rely on flags. In one embodiment, these are provided in a single register, such as a sequence status (SEQSTAT) register. STREX flags may include the following bits in a SEQSTAT register. BIT NAME DESCRIPTION RESET MODE VISIBILITY 21 XMONITOR Exclusive write monitor. 0=Open, 1=Exclusive 0b0 R / NW Public 22 XACTIVE Exclusive letter active 0b0 R / NW Public 23 XWAVAIL Exclusive reply available 0b0 R / NW Public

[0040] Upon successful completion of an LDEX primitive, a DATA register may be updated and the following flag is set. Flag Condition Value at command completion SEQSTAT.XMONITOR Always updated 1

[0041] In one example, if the AXI exclusive read returns an "OKAY" response, the slave does not support exclusive transactions and an exception may be caused.

[0042] In some embodiments, the address must be aligned, even if misaligned accesses are generally supported. An LDEX may cause the following exceptions and errors in addition to those that might be caused by a regular load. Condition Exception or H / W error Misaligned address Exception for violation with misaligned address during data access Access to core MMR Illegal use of surveillance resource Access marked I / O device space of memory in CPLB Data Access CPLB Protection Violation Exception AXI exclusive reading returns the OKAY response External memory addressing error

[0043] A STREX_INIT can only modify memory if it has exclusive access to the addressed memory. Consequently, the primitive depends on the value of the XMONITOR flag as follows: Flag Value at command start Plot SEQSTAT.XMONITOR 0 CC=0 SEQSTAT.XMONITOR 1 Attempt to update (Preg,val), CC=1, XWACTIVE=1

[0044] If the location is not shareable, the memory update can be performed as a regular store to that location, except that the kernel updates SEQSTAT, as described below. If the location is shareable, the memory update is attempted with an exclusive write on the AXI bus.

[0045] In one example, the completion of the STREX_INIT primitive, but not the attempted write, may modify the condition code flag (CC flag) of an ASTAT register. Flag Condition Meaning ASTAT.CC Always updated 0=no write attempted, 1=write attempted SEQSTAT.XMONITOR Always updated 0=no write attempted, 1=write attempted SEQSTAT.XWACTIVE Only set when writing is attempted Exclusive writing response pending

[0046] As with the LDEX primitive, in some embodiments the address must be aligned, even though misaligned accesses are generally supported.

[0047] A sample STREX_INIT primitive may cause the following exceptions and errors in addition to those that might be caused by a regular save. Condition Exception or H / W error Misaligned address Exception for violation with misaligned address during data access Access to core MMR Illegal use of surveillance resource Access marked I / O device space of memory in CPLB Data Access CPLB Protection Violation Exception XWACTIVE=1 or XWAVAIL=1 before the command Illegal use of the surveillance resource?

[0048] The STREX state machine can track the progress of the write transaction and updates the flags in SEQSTAT when it receives a response from the system. Flag Condition Value when the write transaction is completed SEQSTAT.XWAVAIL Always updated 1 Exclusive reply available

[0049] The write response itself can be stored as internal state in the MMU and delivered, for example, as a bus signal. The response is called MMU.XWRESULT and is defined as follows. MMU.XWRESULT Meaning 0 AXI exclusive write transaction responded with any value other than EXOKAY 1 Write was in non-shareable or AXI exclusive write response was EXOKAY

[0050] The STREX_SYNC primitive synchronizes the processor state with the STREX state machine, capturing any outstanding write response and breaking exclusivity.

[0051] If XMONITOR and XWACTIVE are set, the instruction pauses until XWAVAIL is set by the STREX state machine. Then, when XMONITOR, XWACTIVE, and XWAVAIL are set, the response is copied from the exclusive write to CC.

[0052] Upon completion of the instruction, XMONITOR, XWACTIVE, and XWAVAIL are all cleared, resetting the STREX state machine. Flag Condition Value at command completion Meaning ASTAT.CC Only changed if XMONITOR and XWACTIVE and XWAVAIL are running ? 0=writing failed, 1=writing successful SEQSTAT.XMONITOR Always updated 0 SEQSTAT.XWACTIVE Always updated 0 SEQSTAT.XWAVAIL Always updated 0

[0053] If the STREX_SYNC primitive is interrupted, the STREX state machine can continue to track the write transaction and update the flags in SEQSTAT in the background.

[0054] In an example embodiment, the details of LDEX and STREX can vary depending on whether the memory they address is shareable or non-shareable. Shareability can be inferred from the memory space and the cacheable protection lookaside buffer (CPLB) settings. CPLB descriptors in Analog Blackfin ® For example, processors define the caching capability and protection attributes for given memory pages. memory Cacheability properties Meaning Sharability MMR any Core or systemic MMR ILLEGAL L1 any L1-SRAM NOT FOR SHARING L2 CPLBEN=0 CPLB deactivated SHARED L2 CPLBBYPASS=1 Cache temporarily disabled SHARED L2 000 Page is not cacheable memory SHARED L2 001 Not cacheable in L2, write back cacheable in L1 NOT FOR SHARING L2 010 Write back cacheable in L2, non-cacheable in L1 NOT FOR SHARING L2 011 Write back cacheable in L1 and L2 NOT FOR SHARING L2 100 I / O device room ILLEGAL L2 101 Non-cacheable in L2, write-through cacheable in L1 NOT FOR SHARING L2 110 Write-through cacheable in L2, non-cacheable in L1 NOT FOR SHARING L2 111 Write-through cacheable in L1 and L2 NOT FOR SHARING

[0055] An LDEX or STREX primitive pointing to a location marked "ILLEGAL" above may cause an exception.

[0056] An LDEX or STREX primitive that targets non-shareable memory may succeed, but it cannot be exclusive with respect to other cores. Rather, it can only be exclusive with respect to other threads running on the same core.

[0057] An LDEX or STREX pointing to shared memory ensures exclusivity with respect to other cores using exclusive transactions, for example on an AXI bus.

[0058] If one now turns to the attached drawings, Fig.1 is a schematic block diagram of an example digital signal processor (DSP) core 100 according to one or more examples of the present specification. It should be noted that DSP core 100 is provided as a non-limiting example of a type of processor, and the term "processor" as used throughout this specification is intended to broadly encompass any combination of hardware, software, or firmware that provides programmable logic, including, as a non-limiting example, a microprocessor, digital signal processor, field-programmable logic array, programmable logic array, application-specific integrated circuit, or virtual machine processor.The DSP core 100 may form part of a larger "computing device," which in various embodiments may include, or be part of, as a non-limiting example, a computer, an embedded computer, an embedded controller, an embedded sensor, a personal digital assistant (PDA), a laptop computer, a mobile phone, an IP phone, a smartphone, a tablet computer, a handheld calculator, or any other electronic, microelectronic, or microelectromechanical device for processing and communicating data. Fig. 1 has been simplified for clarity and to facilitate understanding of the novel concepts of the present disclosure. Accordingly, additional features may be added to DSP core 100, and some of the features described below may be replaced or eliminated in other embodiments of DSP core 100.

[0059] The DSP core 100 may include a control unit 110, a memory 120, and a computing array 130. In one example, the control unit 110 and the computing array 130 form a core processor that can perform computational and data processing functions of the DSP core 100. Some embodiments of the DSP core 100 include other components such as a microcontroller for executing microcontroller instructions, a direct memory access (DMA) unit, and various interfaces to off-chip devices. Although the memory 120 is shown here as a single logic block, it should be further recognized that the memory 120 may include system main memory, various levels of on-chip or local memory, a cache, and / or other volatile or non-volatile memory technologies.

[0060] The control unit 110 facilitates program execution of the DSP core 100. The control unit 110 may include an arithmetic logic unit and data address generation unit (ALU-DAG) 112, a program flow controller 114, and local program memory 116. The control unit 110 may also include other components, such as an instruction cache, a timer, and an instruction register. In one example, the ALU-DAG 112 supports general-purpose integer calculations and provides memory addresses. For example, the ALU-DAG 112 provides memory addresses when transferring data between memory 120 and registers (such as register files of the compute array 130, described below). The ALU-DAG 112 may provide addresses to data memory (e.g., memory 120) and / or program memory 116. The program sequencer 114 provides instruction addresses to the program memory 116 for instruction fetching.Program memory 116 stores programs implemented by DSP core 100 to process data (such as data stored in memory 120) and may also store process data. "Programs," as used throughout this specification, include any ordered set of executable instructions effective to instruct a processor, such as DSP core 100, to perform a specified task. DSP core 100 may implement programs by retrieving the instructions, for example, by retrieving them from memory 120 and loading them into program sequencer 114, decoding the instructions, and delivering the decoded instructions to processing elements PE for execution or executing them locally in ALU-DAG unit 112.In one example, programs may include instruction sets for implementing various DSP algorithms, including algorithms that can be executed in parallel by executing them across two or more processing elements (PEs), or in single-instruction-multiple-data (SIMD) mode, in which two or more processing elements execute the same instruction, as received from program flow controller 114, on different data elements. SIMD is commonly used, for example, for rapidly processing large arrays of data by dividing the array into n sub-arrays and then allowing n processing elements to separately process each sub-array.

[0061] Memory 120 stores data to be processed by DSP core 100 (data memory), programs implemented by DSP core 100 to process the data (program memory), or a combination thereof. In some examples, memory 120 may have a multi-group interleaved memory structure such that memory 120 includes memory groups M1-Mn, where n is a total number of memory groups of memory 120. In one example, memory 120 is a random access memory such as static random access memory (SRAM), dynamic RAM (DRAM), read-only memory (ROM), flash memory, or other suitable memory technology.

[0062] In one example, one or more memory banks M are separate RAM. Alternatively, memory 120 may represent a multi-level memory structure, including, for example, a fast L1 memory, an intermediate L2 memory, and a slow main memory, where the size and cost of each may vary inversely with the memory's access speed. In yet another example, memory 120 may include a cache or any other suitable type of memory.

[0063] A memory management unit (MMU) 132 may be provided to manage memory operations for the DSP core 100 and, in some examples, may be part of a single integrated circuit with the DSP core 100. The MMU 132 provides memory management services and facilitates communication with the memory 120. In some cases, the MMU 132 may include or interface with a direct memory access (DMA) controller to enable DMA operations from the DSP core 100 to the memory 120. In one example, a STREX state machine, such as the one described in Fig.3 may be programmed into the MMU 132 or elsewhere on the core side of the memory bus 170-3, while a memory controller contained within the memory 120 may provide the other end of an exclusive transaction, including monitoring which core of a multi-core system has exclusive access to a location and causing a write transaction to fail if exclusive access is lost.

[0064] As an example, three buses 170 are shown. As used throughout this specification, a "bus" includes any interconnect, network, interconnect, trunk, single bus, multiple buses, crossbar network, single-level network, multi-level network, or other routing medium operative to transfer data between portions of a computing device or between computing devices. In this example, a main system bus 170-1 is provided to communicatively couple the DSP core 100 to other system components, as described as a more detailed example in Fig.2. Compute bus 170-2 communicatively couples compute array 130 to controller 110. Memory bus 170-3 communicatively couples processing elements PE to memory 120 and, in one example, is an AXI-compatible bus. It should be noted that these uses are disclosed only as a non-limiting example, and that some embodiments may omit one or more of the foregoing buses, while others may utilize additional or different buses.

[0065] The control unit 110 can issue instructions and data addresses to the computing device 130 via the computing bus 170-2. The computing bus 170-2 transfers addresses for instructions and data to various processing elements PE of the computing device 130. The memory bus 170-3 can transfer data and / or instructions from memory (such as memory 120, program memory 116, other memory, or a combination thereof) so that the contents of any register in the DSP core 100 can be transferred to any other register or memory location, and the memory 120 can provide data operands (values) to the computing device 130.

[0066] In the Fig.In the example shown in Figure 1, the computing arrangement 130 includes four processing elements PE1-PE4. In other embodiments, the computing arrangement 130 may include zero or more discrete processing elements. The processing elements PE perform numerical processing and, in one example, may include specialized hardware for executing specific types of calculations, such as DSP algorithms. The processing elements PE may operate independently, in parallel, or as a SIMD machine. In the present example, each processing element PE may be a vector processor. Alternatively, the processing elements PE may be scalar processors or a combination of scalar processors and vector processors.

[0067] The processing elements PE each comprise a respective arithmetic unit (CU) 152. In the illustrated embodiment, the arithmetic units 152 may be identical, although the present disclosure contemplates embodiments in which the arithmetic units 152 are not identical. The present disclosure further contemplates configurations in which one or more processing elements PE do not comprise arithmetic unit 152. In the present example, the arithmetic units 152 each comprise an arithmetic unit (ALU), a multiplier-accumulator (MAC), a converter, another arithmetic unit, or combinations thereof. An ALU can perform arithmetic and logical operations, such as adding, subtracting, negating, incrementing, decrementing, absolute value, AND, OR, XOR, NOT, a divide primitive, other arithmetic operations, other logical operations, or combinations thereof.An example MAC may perform multiplication operations, as well as multiplication and accumulation operations, such as single-cycle multiplication, multiply / add, multiply / subtract, other operations, or combinations thereof. A converter may perform logical and arithmetic conversions, bit manipulation, normalization, denormalization, exponent derivation operations, other operations, or combinations thereof. The various arithmetic operations, logical operations, and other operations may be performed in both fixed-point and floating-point formats. In various embodiments, the ALU, MAC, and / or converter include registers associated with them.

[0068] The processing elements PE may also each include a respective register file 154. In the illustrated embodiment, register files 154 may be identical, although the present disclosure contemplates embodiments in which the register files 154 are not identical. The present disclosure further contemplates configurations in which one or more processing elements PE do not include a register file 154. The register files 154 include registers that transfer data between the processing elements PE and the memory bus 170-3 and store results. In the present example, the register files 154 may include a respective general-purpose register set 155 that includes general-purpose registers with widths depending on the design requirements of the DSP core 100, such as32-bit general-purpose registers, 40-bit general-purpose registers, 64-bit general-purpose registers, 128-bit general-purpose registers, general-purpose registers of other widths, or a combination thereof. For the purposes of the following discussion, general-purpose registers 155 comprise 32-bit general-purpose registers. In one example, register files 154 each comprise a respective STREX register, which may be configured to hold flags and / or values ​​related to the STREX primitives described herein. Register files 154 may comprise additional registers according to the design requirements of DSP core 100. In various implementations, STREX registers 158 may further be general-purpose registers 154 from general-purpose register sets 155. In one example embodiment, each PE comprises at least one dedicated STREX register 158 that is 32 bits wide. In other embodiments, each PE may comprise multiple STREX registers 158.In yet another example, the processing elements PE do not include separate STREX registers 158, but rather, the ALU-DAG unit 112 includes a main STREX register 158 that is applicable to the entire DSP core 100.

[0069] The DSP core 100 can perform various parallel operations. For example, during a single cycle, the processing elements PE can access an instruction (via interconnect network 142) and access N data operands from memory (via memory bus 170-3) for synchronous processing. In SIMD mode, the DSP core 100 can process multiple data streams in parallel.For example, in SIMD mode, DSP core 100 may, in a single cycle, dispatch a single instruction to each or more of the processing elements PE over compute bus 170-2; load N data sets from memory (memory 120, program memory 116, other memory, or a combination thereof) over memory bus 170-3, one data set for each processing element PE (in one example, each data set may include two data operands); execute the single instruction synchronously in the processing elements PE; and store data results from the synchronous execution in memory 120.

[0070] Fig. 1A is a block diagram of an example STREX register 158 according to one or more examples of the present specification. In one example, the DSP core 100 is an Analog Devices, Inc. Blackfin ®DSP, where STREX flags are contained within the flow control status register (SEQSTAT register), so in this example Blackfin ® SEQSTAT is considered STREX register 158. SEQSTAT is configured to provide information about the current state of the Blackfin ® -Sequence control, as well as diagnostic information from a recent event. In the example, SEQSTAT is read-only from a programmer's perspective. The DSP core 100 can be configured so that any reset of SEQSTAT, including a soft reset, can return the register to the value 0b0000 0000.

[0071] Bits 0-20 and 24-32 of SEQSTAT may be reserved or assigned to other purposes, such as containing a value for a last executed exception, hardware fault identification, or a flag that identifies the cause of the last reset of the DSP core 100.

[0072] In this example, bits 21, 22 and 23 are dedicated to the STREX flags, which provide values ​​required to run the state machine used in conjunction with Fig. 3. The following table describes the value and purpose of each flag. It should be noted, however, that this configuration is provided only as an example and is not intended to be limiting. BIT NAME DESCRIPTION RESET MODE VISIBILITY 21 XMONITOR Exclusive write monitor. 0=Open, 1=Exclusive 0b0 R / NW Public 22 XACTIVE Exclusive letter active 0b0 R / NW Public 23 XWAVAIL Exclusive reply available 0b0 R / NW Public

[0073] As shown in this table, bit 21 is called XMONITOR 710 and is used to indicate whether an atomic pair of exclusive read and exclusive write transactions has been interrupted. The DSP core 100 can set this flag to 0b1 after initiating an LDEX primitive and reset this flag to 0b0 when an interrupt is performed or when a STREX primitive completes successfully. The DSP core 100 can test this flag before attempting an exclusive write transaction. If the flag is 0b0, the atomic pair has been interrupted and the core will not initiate an exclusive write transaction. This flag operates in read-only (no write) mode, meaning a programmer cannot directly manipulate this flag but can use its value in program flow.The flag is publicly visible, meaning that it forms part of the architectural state of the DSP core 100 and a programmer can read the value by testing the corresponding bit in the STREX register.

[0074] Bit 22 is called XACTIVE 720 and is used to indicate whether an exclusive write operation is currently active. The DSP core 100 can set this flag when an exclusive write is initiated and can clear it when the exclusive write is complete. Resetting this flag returns its value to 0b0. This flag operates in read-only mode (no writing), meaning a programmer cannot directly manipulate this flag but can use its value during program execution. The flag is publicly visible, meaning it forms part of the architectural state of the DSP core 100, and a programmer can read the value by testing the corresponding bit in the STREX register.

[0075] Bit 22 is called XWAVAIL 730 and is used to indicate whether the STREX response is available. The DSP core 100 can set this flag when the STREX primitive ends either successfully or unsuccessfully, and can clear it after the response is read into a register or status bit of the DSP core 100. Resetting this flag returns its value to 0b0. This flag operates in read-only mode (no writing), meaning a programmer cannot directly manipulate this flag but can use its value in program flow. The flag is publicly visible, meaning it forms part of the architectural state of the DSP core 100, and a programmer can read the value by testing the corresponding bit in the STREX register.

[0076] DSP core 100 may also use a value such as MMU.XWRESULT, which stores the current result of the STREX operation. In some embodiments, MMU.XWRESULT may be encoded in a different bit of STREX register 158. In one example, MMU.XWRESULT is not stored in a register, but rather is encoded by memory bus 170-3 itself. Memory bus 170-3 may set MMU.XWRESULT upon completion. In this example, a value of 0b1 may represent a successful STREX operation, while a value of 0b0 may represent a failed STREX operation.

[0077] Fig. 2 is a block diagram of a computing device 200 according to one or more examples of the present specification. As described with reference to Fig.1, computing device 200 includes a DSP core 100 communicatively coupled to a system bus 170-1 and a memory bus 170-3. Memory bus 170-3 communicatively couples DSP core 100 to memory 120, which is loaded with an operating system 122 that provides low-level services for application software. However, this patent specification contemplates embodiments where a conventional operating system 122 may be unnecessary, such as in embedded systems or controllers where applications may run on "bare metal."

[0078] A storage 240 may communicatively couple to the DSP core 100 via the system bus 170-1. The storage 240 may be a species of the memory 120. In some embodiments, the memory 120 and the storage 240 may be separate devices, with the memory 120 being a relatively low-latency volatile storage device and the storage 240 being a relatively high-latency non-volatile storage device. The storage 240 may also be another device, such as a hard disk drive, a solid-state drive, an external storage device, a redundant array of independent disks (RAID), a network-attached storage device, optical storage, a tape drive, a backup system, cloud storage, or any combination of the foregoing. The storage 240 may be or include a database or databases or data stored in other configurations.Many other configurations are also possible and are intended to be encompassed within the broad scope of this patent specification. In one example, program execution involves loading instructions from repository 240 into memory 120. Instructions are then fetched into DSP core 100 for execution. Data may also be loaded from repository 240 into memory 120 for availability to DSP core 100 during program execution.

[0079] A network interface 270 may communicatively couple to the DSP core 100 and may be operable to communicatively couple the DSP core 100 to a network. In this specification, a "network" encompasses any communicative platform operable to exchange data or information within or between computing devices, including, by way of non-limiting example, a local area network (LAN), an internet architecture that provides computing devices with the ability to electronically interoperate, a point-of-service telephone system (POTS) that computing devices might use to conduct transactions in which they may be assisted by human operators or in which they may manually enter data into a telephone or other suitable electronic equipment, any packet data network (PDN) that provides a communication interface or exchange between any two nodes in a system,or any local area network (LAN), wide area network (MAN), wide area network (WAN), wireless local area network (WLAN), virtual private network (VPN), intranet, or any other suitable architecture or system that facilitates communications in a network or telephone environment.

[0080] A peripheral interface 250 communicatively couples to the DSP core 100 via the system bus 170-1 and may be operative to communicatively couple the DSP core 100 to one or more peripherals. As used in this specification, a "peripheral" includes any auxiliary device that interfaces with the computing device 200, but is not necessarily a part of the core architecture of the computing device 200. A peripheral may be operative to provide extended functionality for the computing device 200 and may or may not be entirely dependent on the computing device 200. In some cases, a peripheral may be a stand-alone computing device. Peripherals may include input and output devices, such as, for example, a display.Displays, terminals, printers, keyboards, mice, modems, network controllers, sensors, transducers, actuators, controllers, data acquisition buses, cameras, microphones, speakers, or external storage as a non-limiting example.

[0081] It should be noted that the Fig. 2 are shown only as an example and are not intended to limit the computing device 200 to the specific configuration shown. Any component of Fig.2 may be omitted under appropriate circumstances, while under other appropriate circumstances, any component may be duplicated as required or combined with another component. For example, it is common for system bus 170-1 and memory bus 170-3 to be the same bus. In another example, network interface 270 may be used to provide connectivity to certain peripheral devices, so that the function of peripheral device interface 250 is combined therein. Consequently, it should be understood that the division between components here is not intended to imply a required or strict physical division. Rather, the components are divided according to logical functions, and where appropriate, a single device may perform multiple functions.In one example, the computing device 200 may be arranged in its entirety as a system on a chip (SoC), where some or all of the functions disclosed herein may be provided in a single monolithic semiconductor device.

[0082] To enable interrupt handling, a STREX instruction can be divided into two instructions: exclusive memory initialization (STREX_INIT) and exclusive memory synchronization (STREX_SYNC). Fig.3 is a block diagram of a STREX state machine 300 according to one or more examples of the present patent specification. In one example, the STREX state machine 300 is implemented in hardware in the MMU 132 or otherwise on the core side of the memory bus 170-3 and continues to track the progress of the STREX primitive even if the STREX_SYNC primitive is interrupted. The state machine 300 begins in a state S0 310, which is active. To advance from state S0 310, a STREX_INIT instruction initiates an exclusive write transaction on the memory bus 170-3, which advances the state machine to state S1 320. In state S1 320, the DSP core 100 waits for a response from the STREX primitive. Notably, and contrary to practice, in at least some prior art processors, state S1 320 is interruptible.Consequently, interrupts need not be preempted during state S1, which may take an indefinite amount of time and may be long enough to adversely affect system performance. If an interrupt is received during state S1 320, the operating system 122 may handle the interrupt according to its standard procedures while the state machine 300 continues to execute in parallel with any instructions or other primitives running on the DSP core 100. Upon receiving a transaction response from the memory bus 170-3, the state machine 300 advances from state S1 320 to state S2 330. State S2 330 represents a condition under which a response is available. This means that the response is ready to be read within a certain number of clock cycles. To return from state S2 330 to state S0 310, a STREX_SYNC instruction reads the response.

[0083] Fig.4 and Fig. 5 are flow diagrams of STREX_INIT and STREX_SYNC primitives according to one or more examples of the present patent specification. In one example, STREX_INIT and STREX_SYNC operate with the state machine 300 of Fig.3 together. It should be noted that several flow diagrams are disclosed throughout this patent specification, and it should be understood that each is presented to illustrate only one example method of operating on a particular machine, transforming substance, or otherwise achieving a useful result. The steps are presented in a specific order only as an example, and those skilled in the art will readily recognize that many combinations and variations to the disclosed method are possible. In some cases, certain steps may be combined with other steps or eliminated entirely without departing from the scope of the disclosed method, and in some cases, certain additional or intermediate steps may be present between the disclosed steps.Furthermore, the disclosed steps need not be in the disclosed order or in any particular order, except as expressly stated or as clear from the context.

[0084] Fig. 4 is a flow diagram of a STREX_INIT primitive 400 according to one or more examples of the present patent specification. In one example, STREX_INIT is a hardware instruction implemented in DSP core 100. STREX_INIT primitive 400 begins at block 410. At block 420, STREX_INIT 400 initiates a STREX primitive, for example, by asserting data to be written to memory 120 on memory bus 170-3. At block 430, STREX_INIT primitive 400 advances state machine 300 to state S1 320 to await a response from the STREX transaction. At block 440, STREX_INIT primitive 400 completes.

[0085] Fig.5 is a flow diagram of a STREX_SYNC primitive 500 according to one or more examples of the present patent specification. In one example, STREX_SYNC is a hardware instruction implemented in the DSP core 100. The STREX_SYNC primitive 500 begins at block 510. At block 520, the STREX_SYNC primitive 500 enters a loop that continuously checks whether the state machine 300 has progressed to state S2, indicating that a response from STREX_INIT is available. If no response has been received, control loops back to block 520. Importantly, the loop of block 520 is interruptible. For example, if an interrupt 530 is received, control transfers to block 540, where the operating system 122 may handle the interrupt 530 according to its normal procedures.After handling interrupt 530, operating system 122 may restart STREX_SYNC 500 so that the primitive's operation continues at block 510, proceeds to block 520, and continues waiting for a response. If a response is received, state machine 300 proceeds to state S2 330. In one example, STREX_SYNC 500 detects that state machine 300 has progressed to state S2 550 and proceeds to block 560. At block 560, STREX_SYNC 500 reads the response and returns it to STREX register 158. At block 570, state machine 300 returns to state S0 310. At block 580, STREX_SYNC primitive 500 is complete.

[0086] Fig. Figure 6 is a flow diagram of a use case of LDEX and STREX primitives according to one or more examples of the present patent specification. The example here can replace known TESTSET instructions based on locked AXI transactions.

[0087] In a "spinlock" operation, a flow requiring exclusive access to a resource (such as a semaphore) continuously checks whether the resource is locked ("waits") until a lock is acquired. Pseudocode for an example spinlock operation using the LDEX and STREX primitives of the present patent specification is disclosed below. In this example, the spinlock is used to access a semaphore. R1 is a register containing the "lock" value (1). P0 is an address register containing the address of a memory location containing a one-byte lock flag for the resource (0b1 = locked, 0b0 = unlocked), where b[P0] represents a byte-sized access to P0. CC is a condition code flag that can be used to check the success or failure of an operation to control branching and can be a condition status bit found in a status register.In the example where the DSP core 100 is a Blackfin. ® DSP, a "CC" bit is found in the arithmetic status register (ASTAT register), which is a 32-bit register containing several status flags, including the "condition code" flag (CC flag), which is used to hold the result of some arithmetic comparisons. R0 is a register for holding the value of B[P0] after a read operation.

[0088] In another example, the STREX primitive is called in context-switch code to clear any exclusive transactions and save the result of any exclusive store in the CC bit of the preserved ASTAT register. For example:

[0089] Interrupt handlers known not to use exclusive operations may leave the exclusive state unmodified. Any pending exclusive write operations complete and update the state in SEQSTAT, which is read by STREX_SYNC upon return from the handlers.

[0090] If you look at the procedure 600 of Fig. 6, the spinlock procedure starts in block 610. Block 620 includes a label "READ": which is used as a reference point for jump instructions. In block 620, a processing element such as PE1 of Fig. 1 executes an LDEX primitive, which in this case is an exclusive read instruction. Specifically, PE1 loads the current value of B[P0] into R0 in preparation for checking whether B[P0] is locked.

[0091] In block 630, PE1 assigns the value of R0 to the condition code CC. According to this step, CC receives the value of the lock code.

[0092] In block 640, the lock code is checked. If the lock code is 0b1, then another process has a lock on the resource. Control can then return to block 620, where the check "waits" for an unlocked resource.

[0093] If block 640 reaches a condition where the resource is not locked, control transfers to block 650. In block 650, PE1 executes the STREX_INIT primitive to assign the value in R1, which should now be 0b1, to B[P0] to acquire a lock on the resource. The return value of this operation is assigned to CC, which indicates whether STREX_INIT initiated a write transaction.

[0094] At block 660, PE1 executes a STREX_SYNC primitive to test whether the write transaction successfully wrote 0b1 to B[P0]. If the atomicity of the operation is not broken by an intermediate interrupt, then MMU.XWRESULT returns 0b1 ("SUCCESS"), which is then assigned to CC.

[0095] If CC is 0b0 in block 670, then an intermediate operation has violated the atomicity of the STREX operation. In this case, control returns to block 620 to attempt to acquire a valid lock on the resource again.

[0096] When control transfers to block 680, the lock is successful, and the process ends at block 690. After block 690, the essential code that originally requested the lock can be executed, and then the lock can be cleared.

[0097] If control transitions smoothly and linearly from block 610 to block 690, then a lock has been acquired without any incidents. In certain known systems, system interrupts would be excluded throughout blocks 620 through 670. However, this may be unacceptable in certain systems, including real-time systems, where predictable timing and interrupt handling are more important. In these cases, the LDEX and STREX primitives of the present specification provide interruptible operations. In other known systems, interrupts would be excluded for the duration of blocks 650 and 660; this may also be unacceptable in certain systems due to the unpredictable timing of the write transaction.

[0098] In one example, the LDEX primitive of block 620 takes an indefinite number of cycles, but can be safely interrupted and restarted because the primitive returns the system to state, although it is executed many times. The assignment operation of block 630 takes a certain number of clock cycles, so it must be non-interruptible to complete a certain number of cycles before an interrupt can be handled. However, an interrupt can occur between block 620 and block 630. Note that the LDEX primitive of block 620 sets the XMONITOR flag to the value 0b1, while XWACTIVE and XWAVAIL both remain at their default values ​​of 0b0. This can cause an internal "abort" mechanism within the STREX primitive to activate because the atomicity of the operation has been violated.When the process loops back to block 620 after returning from the interrupt, the LDEX primitive resets the XMONITOR, XWACTIVE, and XWAVAIL flags, and the process continues as normal. However, when control transfers to block 650, the STREX_INIT primitive detects that the procedure's atomicity has been violated and enters a "no operation" (NOP) state, where it performs no useful work but can reset XMONITOR, XWACTIVE, and XWAVAIL to their default values ​​of 0b0 and set CC to indicate a failure. STREX_SYNC also enters a NOP state in block 660, in which case it does not modify CC, and in block 680, control returns to block 620.

[0099] In another example, an interrupt occurs between block 630 and block 640. Again, in this case, the termination mechanism takes over because XMONITOR is 0b1 while XWACTIVE and XWAVAIL are 0b0. Consequently, STREX_INIT and STREX_SYNC both execute their NOP states, and in block 680, control returns to block 620.

[0100] The behavior of STREX_INIT is controlled by the following pseudocode:

[0101] Rephrased, if the XMONITOR flag is now set to its default value of 0b0, STREX_INIT can conclude that the intermediate interrupt performed at least one exclusive operation, thus breaking the atomicity of the operation. If this is the case, CC is set to zero and the NOP condition is executed, so control returns to block 620.

[0102] On the other hand, if XMONITOR is still 0b1, then PE1 can conclude that an intermediate interrupt did not perform any exclusive operations, and thus atomicity was preserved. In this case, CC is set to 0b1, XWACTIVE is set to 0b1, and XMONITOR remains set to 0b1, so the STREX_SYNC operation in block 660 executes normally.

[0103] The STREX_SYNC primitive can be used after a STREX_INIT, as in block 660, or it can be used in an interrupt handler to abort an atomic sequence if the interrupt occurs between block 620 and block 660, or to read the STREX_INIT response and store it in the execution context if the interrupt occurred between block 650 and block 660 or during block 660. The behavior of STREX_SYNC is controlled by the following pseudocode:

[0104] Under the first condition, if XMONITOR is set to 0b0, then STREX_SYNC can conclude that no exclusive-write transaction is in progress. Either STREX_SYNC is executing in an interrupt handler that is not interrupting an atomic LDREX / STREX sequence, or STREX_SYNC is following a STREX_INIT that executed in NOP mode, or STREX_SYNC is following a STREX_INIT that initiated an exclusive-write transaction, but an intermediate interrupt executed STREX_SYNC to copy the transaction response to CC. In all cases, CC already contains the desired value, and STREX_SYNC executes its NOP state, setting the XWAVAIL and XWACTIVE flags to their default values ​​of 0b0. CC is not modified. If STREX_SYNC is in an interrupt handler but is not interrupting an atomic sequence, then the current value of CC must be preserved as part of the execution context.If STREX_SYNC follows a STREX_INIT that executed in NOP mode, that operation already set CC to 0b0. If STREX_SYNC follows a STREX_INIT, but an intermediate interrupt executed a STREX_SYNC to copy the transaction response to CC, then CC already contains the transaction response.

[0105] Under the second condition, if XMONITOR is 0b1 and the XWACTIVE flag is set to 0b1, STREX_SYNC continues to perform its normal function: it monitors the XWAVAIL flag until it flips to a 0b1 value, at which point CC receives the value of MMU.XWRESULT from memory bus 120. STREX_SYNC then resets XMONITOR and XWAVAIL to their default values ​​of 0b0 and exits.

[0106] Under the third condition, if XMONITOR is 0b1, XWACTIVE is 0b0, and XWAVAIL is 0b1, then the write request has ended, clearing the XWACTIVE flag and setting the XWAVAIL flag. In this case, CC receives the value of MMU.XWRESULT, and both XMONITOR and XWAVAIL are reset to their default value of 0b0.

[0107] In any other case, an unexpected error condition has occurred, and an ABORT state is entered. The ABORT state may, for example, cause an exception or provide some other error mechanism. XMONITOR and XWACTIVE are both reset to their default value of 0b0. [Again, why not XWAVAIL?]

[0108] A truth table of the example procedure is as follows, where “M” represents XMONITOR, “P” represents “XWACTIVE” (pending), and “A” represents “XWAVAIL”: case M P A Behave 1 0 X X NOP case 2 1 0 0 ABORT case: Delete state 3 1 0 1 XWAVAIL case. Read result, clear state. 4 1 1 0 XWACTIVE case: Poll XWAVAIL until it is set. 5 1 1 1 Illegal and impossible because XWACTIVE is deleted when XWAVAIL is set.

[0109] In summary, if XMONITOR==0b0, no atomic operations are pending, and the STREX primitives can be in a NOP state. This means that when they are called, they simply execute NOP. In case 2, an interrupt occurred between LDEX and before STREX_INIT. In this case, XMONITOR is set to 0b0, and CC is not changed. Setting XMONITOR=0 means that the next STREX_INIT will not initiate an exclusive write, so this is an abort case.

[0110] Case 3 implies that STREX_SYNC has ended, and the result is available for reading. Case 4 implies that STREX_SYNC is still pending, so XWAVAIL should be polled until it is set. Case 5 should not occur because XWACTIVE is cleared when XWAVAIL is set. Consequently, in a correctly implemented architecture, case 5 never occurs.

[0111] Upon reaching block 670, CC contains 0b1, if a write was attempted and the response in MMU.XWRESULT was 0b1, indicating that the write successfully updated the memory location, the process loops back to block 620 or not depending on the value of CC.

[0112] Fig. 7 and Fig. 7A are signal timing diagrams of the in conjunction with Fig.6. It should be noted that the signal names disclosed in the diagram are provided to correspond exactly to the flags they set. However, in some embodiments, signals may have names other than the flag, and they are represented here with identical names only to simplify discussion. In the disclosed example, the timing for the flag signals XMONITOR, XWACTIVE, and XWAVAIL are disclosed along with the timing for the data signal MMU.XWRESULT. The span between the time cursors xWaitStart and xWaitEnd represents the duration of a STREX_SYNC primitive.

[0113] In Fig. 7 and Fig.7A, the XMONITOR 710, XWACTIVE 720, XWAVAIL 730, and XWRESULT 740 signals are used for illustration. In the above truth table, Example 1 corresponds to graph 702, Example 2 corresponds to graph 704, Example 3 corresponds to graph 706, Example 4 corresponds to graph 708, and Example 5 corresponds to graph 712. Graph 714 represents a case of a programmer mistakenly attempting a second STREX_INIT primitive before the preceding STREX primitive completes and is not part of the truth table.

[0114] The example case 1702 is a NOP case, where all three flags remain zero. Since no data operation is performed, XWRESULT receives no data.

[0115] Example case 2704 is an ABORT case in which XWMONITOR is set to 0b1 and XWAVAIL is set to 0b0, but at the end of STREX_SYNC, XWMONITOR is reset to 0b0 because STREX_SYNC is executed between an LDEX and STREX_INIT, for example, in an interrupt handler. The abort procedure is described in more detail above.

[0116] Example 3 706 represents an XWAVAIL case. Here, at the end of STREX_SYNC, XWAVAIL and XMONITOR are both set to 0b0 because the value of MMU.XWRESULT was read into CC.

[0117] In Fig. 7A introduces two new cursors, namely xRead, which represents the call to an exclusive read or LDEX primitive, and xWrite, which represents the call to an exclusive write or STREX_INIT primitive.

[0118] Example 4708 illustrates the XWACTIVE case. In this case, on xRead, XMONITOR goes high, indicating that an LDEX was successfully performed. On xWrite, STREX_INIT is performed, and XWACTIVE goes high, indicating that the STREX primitive is attempting to write an exclusive value. On xWaitStart, the STREX_SYNC primitive detects that XWACTIVE is high, so it waits until XWAVAIL goes high, indicating that the write response is in MMU.XWRESULT. On xWaitEnd, the STREX_SYNC primitive copies MMU.XWRESULT to CC and sets XWMONITOR and XWAVAIL low.

[0119] In Example 5712, XMONITOR is set during the LDEX primitive, but an interrupt or context switch occurs before the STREX procedure is executed. In this case, all three flags are 0b0 on xWrite, and STREX executes its NOP state.

[0120] In Example 6714, an xRead that sets XMONITOR is followed by a first xWrite that sets XWACTIVE. However, before the process is complete, a second xWrite is attempted. This could, for example, be the result of a programming error. In this case, a user error has occurred, so the STREX primitive can abort and raise an exception.

[0121] According to one or more embodiments of the present patent specification, two processes that perform exclusive store operations can advantageously be implemented on the same processing element PE, regardless of the memory type. In this case, two processes can only compete for the same lock if there is a context switch between the exclusive load and exclusive store: Sequence command XMONITOR XWAVAIL MMU.XWRESULT CC 0 0 0 a 0 R0 = b[P0] (z,excl) 1 0 0 a system CC=syncexcl 0 0 0 a system [-sp] = ASTAT 0 0 0 a system ASTAT = [sp++] 0 0 0 b 1 R0 = b[P0] (z,excl) 1 0 0 b 1 CC=(b[P0] = R1) (excl) 1 1 1 1 system CC=syncexcl 0 0 0 1 system [-sp] = ASTAT 0 0 0 1 system ASTAT = [sp++] 0 0 0 a 0 CC = (b[P0] = R1) (excl) 0 0 0 0 0 CC=syncexcl 0 0 0 0 system CC=syncexcl 0 0 0 0 system [-sp] = ASTAT 0 0 0 0 system ASTAT = [sp++] 0 0 0 1 1 if !CC jump spin; Success - Failure

[0122] Note that in the previous example, for simplicity, the value of the XWACTIVE bit and the asynchronous update of XWAVAIL are not shown.

[0123] It should be noted that the activities discussed above with reference to the figures are applicable to any integrated circuits that include signal processing (e.g., gesture signal processing), particularly those that can execute specialized software programs or algorithms, some of which may be associated with the processing of digitized real-time data. Certain embodiments may relate to multi-DSP signal processing, floating-point processing, signal / control processing, fixed-function processing, microcontroller applications, etc. In certain contexts, the features discussed herein may be applicable to medical systems, scientific instrumentation, wireless and wired communications, radar, industrial process control, audio and video equipment, power sensing, instrumentation (which may be highly accurate), and other digital processing-based systems.Certain embodiments discussed above may also be incorporated into digital signal processing technologies for medical imaging, patient monitoring, medical instrumentation, and home healthcare. This could include lung monitors, accelerometers, heart rate monitors, pacemakers, etc. Other applications may include automotive technologies for safety systems (e.g., stability control systems, driver assistance systems, braking systems, infotainment, and any type of internal applications). Furthermore, powertrain systems (e.g., in hybrid and electric vehicles) may utilize high-precision data conversion products in battery monitoring, control systems, reporting controls, maintenance activities, etc.In still other example scenarios, the teachings of the present disclosure may be applicable to industrial markets that include process control systems that help advance productivity, energy efficiency, and reliability. In consumer applications, the teachings of the signal processing circuits discussed above may be used for image processing, autofocus, and image stabilization (e.g., for digital still cameras, camcorders, etc.). Other consumer applications may include audio and video processors for home theater systems, DVD recorders, and high-resolution televisions. Still other consumer applications may include advanced touchscreen controllers (e.g., for any type of portable media device). Such technologies could therefore easily be part of smartphones, tablets, security systems, PCs, gaming technologies, virtual reality, simulation training, etc.

[0124] The foregoing overviews depict several embodiments so that those skilled in the art can more easily understand aspects of the present disclosure. Those skilled in the art should recognize that they can readily use the present disclosure as a basis for designing or modifying other processes and structures for carrying out the same purposes and / or achieving the same advantages of the embodiments introduced herein. Those skilled in the art should also recognize that such equivalent constructions do not depart from the spirit and scope of the present disclosure and that they may make various changes, substitutions, and alterations herein without departing from the spirit and scope of the present disclosure.

[0125] The specific embodiments of the present disclosure may readily include a central processing unit (CPU) of a system on a chip (SOC). An SOC represents an integrated circuit (IC) that integrates components of a computer or other electronic system into a single chip. It may include digital, analog, mixed-signal, and radio frequency functions, all of which may be arranged on a single chip substrate. Other embodiments may include a multi-chip module (MCM), wherein multiple chips are arranged in a single electronic package and configured to closely interact with each other through the electronic package.In various other embodiments, the digital signal processing functionalities may be implemented in one or more silicon cores in application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and other semiconductor chips.

[0126] In example implementations, at least some portions of the processing activities outlined herein may also be implemented in software. In some embodiments, one or more of these features may be implemented in hardware external to the elements of the disclosed figures or combined in any suitable manner to achieve the intended functionality. The various components may include software (or interchangeable software) that can coordinate to achieve the operations outlined herein. In still other embodiments, these elements may include any suitable algorithms, hardware, software, components, modules, interfaces, or objects that facilitate their operations.

[0127] Furthermore, some of the components associated with described microprocessors may be removed or otherwise combined. In general terms, the arrangements depicted in the figures may be more logical in their representations, whereas a physical architecture may include various permutations, combinations, and / or hybrids of these elements. It is important to note that countless possible design configurations may be used to achieve the operational objectives outlined here. Consequently, the associated infrastructure will comprise a myriad of replacement arrangements, design choices, device options, hardware configurations, software implementations, equipment options, etc.

[0128] Any suitably configured processor component may execute any type of instructions associated with the data to achieve the operations detailed herein. Any processor disclosed herein may transform an element or object (e.g., data) from one state or thing to another state or thing.In another example, some activities outlined herein may be implemented with fixed logic or programmable logic (e.g., software and / or computer instructions executed by a processor), and the elements identified herein could be any type of programmable processor, programmable digital logic (e.g., a field programmable gate array (FPGA), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM)), an ASIC including digital logic, software, code, electronic instructions, flash memory, optical disks, CD-ROMs, DVD-ROMs, magnetic or optical cards, other types of machine-readable media suitable for storing electronic instructions, or any suitable combination thereof.In operation, processors may store information in any suitable type of non-volatile storage medium (e.g., random access memory (RAM), read-only memory (ROM), field programmable gate array (FPGA), erasable programmable read-only memory (EPROM), electrically erasable programmable ROM (EEPROM), etc.), software, hardware, or any other suitable component, device, element, or object, as appropriate and based on particular needs.Furthermore, the information tracked, sent, received, or stored in a processor could be provided in any database, register, table, cache, queue, control list, or memory structure based on specific needs and implementations, all of which could be referenced in any suitable timeframe. Any of the memory elements discussed herein should be understood as encompassed within the broad term "memory." Likewise, any of the potential processing elements, modules, and engines described herein should be understood as encompassed within the broad term "microprocessor" or "processor."

[0129] Computer program logic that implements all or part of the functionality described herein is embodied in various forms, including, but by no means limited to, source code form, computer-executable form, and various intermediate forms (e.g., forms generated by an assembler, compiler, linker, or localizer). In one example, source code comprises a set of computer program instructions implemented in various programming languages, such as object code, assembly language, or a high-level language such as OpenCL, Fortran, C, C++, Java, or HTML, for use with various operating systems or operating environments. The source code may define and use various data structures and communication messages. The source code may be in computer-executable form (e.g., via an interpreter), or the source code may be (e.g.,via a translator, assembler, or compiler) into a computer-executable form. Furthermore, any of the foregoing may be used to create an emulation or virtualization environment in which certain hardware functions are provided in software emulation or software virtualization.

[0130] In the above discussions of the embodiments, the buffers, peripheral interface elements, interconnect boards, clocks, DDRs, digital cores, transistors, and / or other components can be easily replaced, interchanged, or otherwise modified to accommodate specific circuitry needs. Furthermore, it should be noted that the use of complementary electronic devices, hardware, non-transitory software, etc., provides an equally viable option for implementing the teachings of the present disclosure.

[0131] In one example embodiment, any number of the electrical circuits of the figures may be implemented on a circuit board of an associated electronic device. The circuit board may be a general-purpose printed circuit board that may hold various components of the internal electronic system of the electronic device and may further provide interconnection elements for other peripherals. In particular, the circuit board may provide the electrical connections through which the other components of the system may communicate electrically. Any suitable processors (including digital signal processors, microprocessors, support chipsets, etc.), memory elements, etc., may be suitably coupled to the circuit board based on particular configuration needs, processing requirements, computer designs, etc. Other components, such asExternal memory, additional sensors, audio / video display controllers, and peripherals can be attached to the board as plug-in cards, via cables, or integrated into the board itself. In another example embodiment, the electrical circuits of the figures can be implemented as standalone modules (e.g., a device with associated components and circuitry configured to perform a specific application or function) or as plug-in modules into application-specific hardware of electronic devices.

Claims

[1] System on a chip comprising: a memory; a memory bus communicatively coupled to the memory; and a processor communicatively coupled to the memory via the memory bus, the processor comprising circuitry for providing interruptible atomic memory operations with exclusive memory functionality, comprising: an exclusive memory instruction (STREX instruction) operable to interact with a STREX state machine running in parallel with a main processor pipeline, the STREX instruction comprising: an exclusive memory initialization (STREX_INIT) instruction, the STREX_INIT instruction being operable to initiate an exclusive memory transaction into a location in memory, the STREX_INIT instruction being non-interruptible and STREX_INIT causing the STREX state machine to enter a state waiting for the response to the transaction; an exclusive memory synchronization (STREX_SYNC) instruction, wherein the STREX_SYNC is interruptible and the STREX_SYNC instruction is operable to wait for the STREX state machine to receive a transaction response while monitoring an XWAVAIL indicator that is a bit of a STREX register (158), the XWAVAIL indicator being operable to indicate that an XWRESULT response to the STREX_INIT primitive is available, the XWRESULT response being operable to indicate whether the exclusive memory transaction into the location in memory was successful. [2] The system on a chip of claim 1, wherein the memory stores an operating system with instructions to provide semaphore handling over the exclusive memory functionality. [3] The system on a chip of claim 1 or 2, wherein the memory stores an operating system with instructions to perform an unconditional STREX_SYNC upon a context switch. [4] A system on a chip according to any preceding claim, wherein the memory bus is an advanced extensible interface (AXI) bus. [5] A system on a chip according to any preceding claim, wherein the STREX_SYNC primitive is interruptible by a system interrupt. [6] A system on a chip according to any preceding claim, wherein: the processor is further operative to provide an exclusive load primitive (LDEX primitive) preceding the STREX_INIT primitive, wherein LDEX, STREX_INIT, and STREX_SYNC together form an atomic transaction; and the STREX_INIT primitive is effective to fail without initiating a memory transaction if an interrupt occurs between LDEX and STREX_INIT and initiates a second LDEX. [7] The system on a chip of any preceding claim, wherein the processor is further operable to, when an interrupt occurs between the STREX_INIT primitive and the STREX_SYNC primitive and when the interrupt performs a second STREX_SYNC, cause the STREX_SYNC primitive to enter a no-operation state. [8] Digital signal processor system comprising: a memory; a memory bus communicatively coupled to the memory; and a computation unit communicatively coupled to the memory via the memory bus, the computation unit operable to provide interruptible atomic memory operations with an exclusive memory primitive comprising: an exclusive memory instruction (STREX instruction) operable to interact with a STREX state machine running in parallel with a main processor pipeline, the STREX instruction comprising: Executing an exclusive memory initialization primitive (STREX_INIT primitive), the STREX_INIT primitive operable to initiate an exclusive memory transaction into a location in memory, the STREX_INIT instruction being non-interruptible and STREX_INIT causing the STREX state machine to enter a state waiting for the response to the transaction; Executing a separate exclusive memory synchronization primitive (STREX_SYNC primitive), wherein the STREX_SYNC is interruptible and the STREX_SYNC primitive is operative to wait for the STREX state machine to receive a transaction response while monitoring an XWAVAIL indicator that is a bit of a STREX register (158), the XWAVAIL indicator is operative to indicate that an XWRESULT response to the STREX_INIT primitive is available, the XWRESULT response is operative to indicate whether the exclusive memory transaction into the location in memory was successful. [9] The digital signal processor system of claim 8, wherein the memory bus is an advanced extensible interface (AXI) bus. [10] A digital signal processor system according to claim 8 or 9, wherein the STREX_SYNC primitive is interruptible by a system interrupt. [11] The digital signal processor system of claim 8, 9 or 10, wherein the STREX_SYNC primitive is operable to enter a no-operation state when the system interrupt initiates a second STREX_INIT primitive. [12] A digital signal processor system according to claim 8, 9, 10 or 11, wherein the STREX_INIT primitive requires a certain number of clock cycles to execute. [13] A digital signal processor system according to any one of claims 8 to 12, wherein the XWRESULT indicator is provided by the memory bus. [14] The digital signal processor system of any of claims 8 to 13, wherein the STREX_INIT primitive is configured to cause an exception if a second STREX_INIT is executed before a STREX_SYNC is executed. [15] A method for providing interruptible atomic memory operations with an exclusive memory primitive performed by a computing device, comprising: an exclusive memory instruction (STREX instruction) operable to interact with a STREX state machine running in parallel with a main processor pipeline, the STREX instruction comprising: Executing an exclusive memory initialization primitive (STREX_INIT primitive), the STREX_INIT primitive being operative to initiate an exclusive memory transaction into a memory location, the STREX_INIT instruction being non-interruptible and the STREX_INIT causing the STREX state machine to enter a state waiting for the response to the transaction; Executing a separate exclusive memory synchronization primitive (STREX_SYNC primitive), wherein the STREX_SYNC is interruptible and the STREX_SYNC primitive is operative to wait for the STREX state machine to receive a transaction response while monitoring an XWAVAIL indicator that is a bit of a STREX register (158), the XWAVAIL indicator is operative to indicate that an XWRESULT response to the STREX_INIT primitive is available, the XWRESULT response is operative to indicate whether the exclusive memory transaction into the memory location was successful. [16] The method of claim 15, wherein the STREX_SYNC primitive is interruptible by a system interrupt. [17] A method according to claim 15 or 16, further comprising: Executing an exclusive load primitive (LDEX primitive) preceding the STREX_INIT primitive, where LDEX, STREX_INIT, and STREX_SYNC together form an atomic transaction; and The STREX_INIT primitive fails without initiating a memory transaction if an interrupt occurs between LDEX and STREX_INIT and initiates a second LDEX. [18] The method of claim 16 or 17, further comprising, when an interrupt occurs between the STREX_INIT primitive and the STREX_SYNC primitive and when the interrupt performs a second STREX_SYNC, performing a no operation state in place of the STREX_SYNC primitive. [19] The method of any one of claims 15 to 18, wherein the STREX_INIT primitive requires a certain number of clock cycles to execute. [20] A method according to any one of claims 15 to 19, wherein the XWRESULT indicator is provided by a memory bus. [21] The method of any one of claims 15 to 20, wherein the STREX_INIT primitive is configured to cause an exception if a second STREX_INIT is executed before a STREX_SYNC primitive is executed.

Images