System and method for synchronizing data processing in cellular modem

Abstract

The invention relates to a system and method for synchronizing data processing in a cellular modem. A cellular modem processor may include a dedicated processing engine that implements specific complex data processing operations. The processing engines may be arranged in a pipeline with different processing engines executing different steps in a sequence of operations. Mixed terms of firmware-based flow control and hardware-based data dependency management may be used to provide flow control or data synchronization between pipeline stages. The firmware instruction may define a data stream by referring to a virtual address space associated with the pipeline buffer. A hardware interlock controller within a pipeline may track and execute data dependencies of the pipeline.

Description

[0001] This application is a divisional application of the Chinese invention patent application with the application date of August 31, 2022, application number 202211050247.5, and invention name “System and method for synchronous data processing in a cellular modem”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. patent application No. 17 / 448,863, filed on September 24, 2021, the disclosure of which is incorporated herein by reference. Background Art

[0004] The present disclosure relates generally to cellular data processing, and in particular to synchronization of data processing between pipeline stages in a cellular modem.

[0005] With the advent of high-speed cellular data communications, users of mobile devices are increasingly able to access information when they need it. Cellular data communication standards promulgated by the 3rd Generation Partnership Project (3GPP) implement radio frequency communications between base stations and various user equipment (UEs), which can be mobile devices such as smartphones, tablets, wearable devices, etc., via "uplinks" from the UE to the base station and "downlinks" from the base station to the UE.

[0006] The standards promulgated by 3GPP include specifications for radio access networks (RANs), such as 4G Long Term Evolution (referred to herein as "4G" or "LTE") and 5G New Radio (referred to herein as "5G" or "NR"). The 4G and 5G RAN specifications define multiple logical channels between a base station and a UE, including a physical uplink shared channel (PUSCH) and a physical downlink shared channel (PDSCH) for transmitting application layer data, and a physical uplink control channel (PUCCH) and a physical downlink control channel (PDCCH) for transmitting various parameters associated with data transmission on these shared channels.

[0007] These specifications also define a sequence of operations for preparing data for transmission as a radio frequency (RF) signal on each channel. As an example of the complexity involved, a general sequence of operations for PDSCH involves the following steps: the base station receives a transport block consisting of a sequence of data bits to be transmitted to the UE. The base station adds cyclic redundancy check (CRC) bits, segments the transport block based on the maximum codeword size, adds CRC bits for each segment, encodes each segment using a coding algorithm (which adds parity bits to implement error correction), performs bit interleaving and rate matching operations (which improves robustness against channel losses), and applies a scrambling algorithm. The resulting sequence of bits is then mapped onto a sequence of modulation symbols assigned to subcarrier frequencies and time intervals (commonly referred to as "resource elements"). An inverse fast Fourier transform (IFFT) generates a digital representation of the waveform, which can be converted to analog, mixed with a carrier frequency and transmitted to the UE via an antenna (or antenna array). The UE reverses the base station operations to recover the data. For example, a UE may receive an RF signal, extract the baseband signal by removing the carrier frequency, generate a digitized representation of the baseband signal, and apply a Fast Fourier Transform (FFT) to transform the signal into the frequency domain. A demapper may apply a channel estimate to generate a log-likelihood ratio (LLR) sequence that represents the relative probability that each transmitted bit is 0 or 1. The LLR sequence may be descrambled, deinterleaved and rate-matched, decoded, and error corrected (based on the parity and CRC bits after decoding) to produce an output data block. For the PUSCH, the sequence of operations is similar, with the roles of the base station and the UE reversed. The PUCCH and PDCCH, which typically include smaller data blocks, have their own associated sequences of operations. The specific operations and sequences may vary; for example, shared channels for 4G and 5G use different coding algorithms and different interleaving orders and rate matching operations.

[0008] To manage these operations at high data rates, UEs typically include a dedicated cellular modem. A cellular modem can be implemented as one or more integrated circuits, logically divided into a "baseband" processor and a "radio frequency" or "RF" processor. The baseband processor handles operations such as segmentation, coding, interleaving, and rate matching, as well as scrambling for uplink channels (and the reverse for downlink channels), while the RF processor handles waveform generation and all analog operations.

[0009] Many types of UEs are portable, battery-powered devices, such as smartphones, tablets, and wearables. For such devices, it is desirable to have a cellular modem that is area-efficient and energy-efficient while supporting high data rates. Furthermore, to support mobility across a range of geographic areas where base stations supporting different standards may be available, it is also desirable that the same modem can support multiple cellular data communication standards, such as both 4G and 5G. Summary of the Invention

[0010] According to some embodiments, a cellular modem processor may include a dedicated processing engine that performs specific complex data processing operations. To perform operations such as decoding a PDSCH channel or encoding a PUSCH channel, the cellular modem may include various pipelines of processing engines that can perform various steps in a sequence of operations. For example, one type of pipeline may prepare data for RF transmission (in the case of a PUSCH channel), while another type of pipeline extracts data from received RF transmissions. Flow control or data synchronization between pipeline stages is provided using a mix of firmware-based flow control and hardware-based data dependency management. For example, firmware instructions may define data flow by referencing a virtual address space associated with a pipeline buffer. A hardware interlock controller within a pipeline may track and enforce data dependencies for that pipeline.

[0011] Some embodiments relate to a processing system comprising a set of processing engines, a buffer memory, a control processor, and an interlock controller. Some or all of the processing engines may include circuits configured to perform operations on input data in response to instructions to generate output data. The processing engines may form a processing pipeline so that at least a portion of the output data generated by a first processing engine in the processing engines is used as at least a portion of the input data of a second processing engine in the processing engines. The buffer memory may be coupled to a plurality of processing engines and may include one or more different physical buffers. The buffer memory may have an associated virtual address space, wherein different virtual addresses in the virtual address space are mapped to different locations in the buffer memory. The control processor may be coupled to the processing engines and configured to dispatch instructions to the processing engines in sequence, wherein at least some of the instructions specify a virtual input address range and a virtual output address range in the virtual address space. An interlock controller may be coupled to the plurality of processing engines and configured to: identify data dependencies between instructions dispatched to different processing engines based on a virtual input address range and a virtual output address range specified in the instructions, and prevent a particular one of the processing engines from reading input data from or writing output data to a location in the buffer memory until the data dependencies of the virtual addresses associated with the locations in the buffer memory are cleared.

[0012] In some embodiments, the processing engine may include a functional unit, a dispatch queue, a dispatch queue interface, and an instruction interface. The functional unit may be configured to perform a specific operation, which may be a complex data processing operation. The dispatch queue interface may be configured to sequentially receive a series of instructions from a control processor to perform the specific operation, queue the received instructions in a dispatch queue for sequential execution, and transmit the virtual input address range and virtual output address range of the received instructions to an interlock controller. The instruction interface may be configured to communicate with the interlock controller to determine whether the data dependencies of the next instruction queued in the dispatch queue have been cleared. For example, the dispatch queue interface may be configured to send a read lock request for the virtual input address range and a write lock request for the virtual output address range to the interlock controller in response to receiving an instruction from the control processor, and the processing engine may be configured to send a clear request for the virtual input address range to the interlock controller after reading data from a location corresponding to the virtual input address range in a buffer memory, and send a clear request for the virtual output address range to the interlock controller after writing data to a location corresponding to the virtual output address range in the buffer memory. In some embodiments, the instruction interface may be configured to send a polling request specifying an input virtual address range for a next instruction to the interlock controller, and receive a response to the polling request from the interlock controller. The response to the polling request may indicate whether any uncleared data dependencies exist with respect to the input virtual address range. The instruction interface enables the functional unit to execute the next instruction only if the response to the polling request indicates that no uncleared data dependencies exist with respect to the input virtual address range.

[0013] In some embodiments, the interlock controller may include: a virtual register file for storing a series of read locks and write locks associated with different virtual address ranges; an update circuit for updating the virtual register file in response to messages received from a processing engine requesting the creation and clearing of read locks and write locks; and decision logic for determining whether data dependencies for a virtual address range have been cleared based on the virtual register file. In some embodiments, the processing engine may poll the interlock controller to determine whether data dependencies for a read or write operation involving a particular virtual address have been cleared, and the interlock controller may execute the decision logic to make a determination and send a response.

[0014] In some embodiments, the control processor may be a scalar processor and the processing engine may be a vector processing engine.

[0015] In some embodiments, the shared memory circuit is coupled to the processing pipeline and one or more other subsystems of the processor.The shared memory may be outside of the virtual address space associated with the buffer memory.

[0016] Some embodiments relate to a cellular modem processor comprising multiple processing pipelines, wherein at least two of the processing pipelines perform different data processing operations. For example, at least one of the processing pipelines may be configured to operate on data to be transmitted via a cellular radio access network, and at least one other of the processing pipelines may be configured to operate on data received via the cellular radio access network. The processing pipeline may include a set of processing engines, a buffer memory, a control processor, and an interlock controller. The processing engines may include circuitry configured to perform operations on input data in response to instructions to generate output data. The processing engines may form a processing pipeline such that at least a portion of output data generated by a first processing engine in the processing engines is used as at least a portion of input data for a second processing engine in the processing engines. The buffer memory may be coupled to the multiple processing engines and may include one or more different physical buffers. The buffer memory may have an associated virtual address space, wherein different virtual addresses in the virtual address space map to different locations in the buffer memory. A control processor may be coupled to the processing engines and configured to dispatch instructions to the processing engines in sequence, wherein at least some of the instructions specify a virtual input address range and a virtual output address range in a virtual address space. An interlock controller may be coupled to the plurality of processing engines and configured to identify data dependencies between instructions dispatched to different processing engines based on the virtual input address range and the virtual output address range specified in the instructions, and to prevent a particular one of the processing engines from reading input data from or writing output data to a location in a buffer memory until the data dependencies of the virtual addresses associated with the locations in the buffer memory are cleared. A processing pipeline may have its own processing engines, its own buffer memory (which has its own virtual address space), and its own interlock controller. In some embodiments, the control processor may be shared among multiple pipelines.

[0017] In some embodiments, the cellular modem processor may further include a shared memory circuit coupled to at least two of the processing pipelines. In the case of a shared memory circuit, the processing engines in the processing pipeline coupled to the shared memory circuit may include: a first processing engine including circuitry configured to read input data from the shared memory circuit and write output data to an output location in a buffer memory of the processing pipeline; and a final processing engine including circuitry configured to read input data from an input location in the buffer memory of the processing pipeline and write output data to the shared memory circuit.

[0018] Some embodiments relate to a method performed in a processing pipeline having a set of processing engines coupled to an interlock controller. In some embodiments, a control processor may issue instructions to the processing pipeline in sequence. The processing engine may: receive a new instruction to be executed from the control processor, the new instruction specifying one or both of a virtual input address range and a virtual output address range in a virtual address space of the processing pipeline; send a read lock request for the virtual input address range of the new instruction and a write lock request for the virtual output address range of the new instruction; queue the new instruction for execution; identify a next instruction to be executed; poll the interlock controller with the virtual input address range of the next instruction before executing the next instruction; execute the next instruction after the interlock controller indicates that data dependencies of the virtual input address range of the next instruction are cleared, wherein executing the next instruction may include reading from a memory address associated with the virtual input address range of the next instruction; and writing to the memory address associated with the virtual output address range of the next instruction. Read input data from a buffer memory location corresponding to an input virtual address range; poll an interlocking controller using a virtual output address range of the next instruction; write output data to a buffer memory location corresponding to the virtual output address range of the next instruction after the interlocking controller indicates that the data dependency of the virtual output address range is cleared; after reading input data from the buffer memory location corresponding to the virtual input address range of the new instruction, send a request to clear a read lock for the virtual input address range of the new instruction; and after writing the output data to the buffer memory location corresponding to the virtual output address range, send a request to clear a write lock for the virtual output address range of the new instruction.

[0019] In some embodiments, the interlock controller may: receive a read lock request, a write lock request, a request to clear the read lock, and a request to clear the write lock from processing engines in a processing pipeline; update data dependency information of a virtual address space in a virtual register file in response to each received read lock request, write lock request, request to clear the read lock, or request to clear the write lock; receive a polling request from one of the processing engines, the polling request identifying a polled virtual address range and indicating a read operation or a write operation; determine whether the polled virtual address range has cleared data dependencies based on the polled virtual address range and the indicated read operation or write operation; and send a response to the polling request to the requesting processing engine, wherein the response is a grant response if the polled virtual address range has cleared data dependencies, and the response is a rejection response if the polled virtual address range has not cleared data dependencies. In some embodiments, determining whether the polled virtual address range clears data dependencies may include: in the case where the polling request indicates a read operation, determining whether any write lock for the polled virtual address range precedes a read lock for the polled virtual address range requested by the processing engine from which the polling request is received; and in the case where the polling request indicates a write operation: determining whether any write lock for the polled virtual address range precedes a write lock for the polled virtual address range requested by the one of the processing engines, wherein the polling request is received from the one processing engine; and determining whether any read lock for the polled virtual address range precedes a write lock for the polled virtual address range requested by the one of the processing engines, wherein the polling request is received from the one processing engine.

[0020] The following detailed description, together with the accompanying drawings, will provide a better understanding of the nature and advantages of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 is a simplified block diagram of user equipment according to some embodiments.

[0022] Figure 2 is a simplified block diagram of a cellular modem processor according to some embodiments.

[0023] Figure 3 A simplified block diagram of the architecture of a pipeline for a processor is shown, according to some embodiments.

[0024] Figure 4 Shown according to some embodiments Figure 3 A more detailed block diagram of the pipeline.

[0025] Figure 5 is a simplified block diagram showing additional details of an interlock controller for a pipeline according to some embodiments.

[0026] Figure 6 A process is shown that may be performed when instructions are received into a processing engine according to some embodiments.

[0027] Figure 7 A flowchart of a process for executing instructions in a processing engine according to some embodiments is shown.

[0028] Figure 8 A flow diagram of another process for executing instructions in a processing engine is shown according to some embodiments.

[0029] Figure 9 A flow chart illustrating a process that may be performed by an interlock controller according to some embodiments is shown.

[0030] Figure 10 is a flow chart of a decision logic process for an interlock controller, according to some embodiments.

[0031] Figure 11 A simplified block diagram of a transmit front-end pipeline is shown, according to some embodiments.

[0032] Figure 12 is a flow diagram of a process for encoding a block of data using a pipeline, according to some embodiments.

[0033] Figure 13 Shown is a simplified block diagram of another data processing pipeline according to some embodiments. DETAILED DESCRIPTION

[0034] The following description of exemplary embodiments is provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the claimed embodiments to the precise form described, and those skilled in the art will appreciate that many modifications and variations are possible. These embodiments have been chosen and described to fully illustrate their principles and practical applications, thereby enabling others skilled in the art to fully utilize the various embodiments and make various modifications as are suitable for the particular use contemplated.

[0035] Figure 11 is a simplified block diagram of a user device 100 according to some embodiments. The user device 100 may be, for example, a mobile device such as a smartphone, a tablet, a laptop, a wearable device, or any other electronic device capable of operating as user equipment (UE) in a cellular radio access network. The user device 100 represents a large class of user-operable devices that may incorporate a cellular modem as described herein, and such devices may vary widely in capabilities, complexity, and form factor.

[0036] The main processor 102 may include, for example, one or more single-core or multi-core microprocessors and / or microcontrollers that execute program code to perform various functions associated with the user device 100. For example, the main processor 102 may execute an operating system and one or more application programs compatible with the operating system. In some cases, the program code may include instructions for sending information to other devices or systems and / or receiving information from other devices or systems, for example, via a cellular data network (such as a 4G or 5G network).

[0037] The user interface 104 may include: user-operable input components such as a touchpad, touch screen, scroll wheel, click wheel, dial, buttons, switches, keypad, keyboard, microphone, etc.; and output components such as a video screen, indicator lights, speakers, headphone jack, haptic motor, etc.; as well as supporting electronic components (e.g., digital-to-analog converter or analog-to-digital converter, signal processor, etc.). Depending on the specific implementation of the particular user device 100, the user may operate the input components of the user interface 104 to invoke functions of the user device 100 and / or receive output from the user device 100 via the output components of the user interface 104. In some embodiments, the user device 100 may have a limited user interface (e.g., a small number of indicators and / or buttons) or no user interface.

[0038] The system memory 106 may include any type of data storage media and any combination of data storage media, including but not limited to random access memory (e.g., DRAM, SRAM), flash memory, magnetic disk, optical storage media, or any other non-transitory storage media, or a combination of media, and may include volatile media and / or non-volatile media. The system memory 106 may be used to store program code to be executed by the main processor 102 and any other data or instructions that may be generated and / or used in the operation of the user device 100.

[0039] Input / output (I / O) interface 108 may include hardware components and supporting software that are configured to allow user device 100 to communicate with other devices via point-to-point or local area network links. In some embodiments, I / O interface 108 may support short-range wireless communications (e.g., via Wi-Fi, Bluetooth, or other wireless transmission communications) and may include appropriate transceiver and signal processing circuitry and software or firmware to control the operation of the circuitry. Additionally or alternatively, in some embodiments, I / O interface 108 may support a wired connection to another device.

[0040] To enable communications via a cellular network, including cellular data communications, the user device 100 may include a cellular modem 110 coupled to an antenna subsystem 112. The cellular modem 110 may be implemented as a microprocessor or microcontroller that acts as a coprocessor for the main processor 102. In some embodiments, the cellular modem 110 and the main processor 102 may be implemented as integrated circuits fabricated on a common substrate, for example, as part of a system-on-a-chip design. An exemplary implementation of the cellular modem 110 is described below.

[0041] The antenna subsystem 112 may include an antenna that can be implemented using wires, metal traces, or any other structure capable of radiating radio frequency (RF) electromagnetic fields and responding to RF electromagnetic fields at frequencies used in cellular data communications. For example, 4G and 5G networks currently use various spectrum bands, including bands at 700 MHz, 850 MHz, 900 MHz, 1.5 GHz, 1.8 GHz, 2.1 GHz, 2.5 GHz, and 3.5 GHz. The antenna subsystem 112 may also include circuitry for driving the antenna and circuitry for generating a digital signal in response to a received RF signal. The specific antenna implementation is not critical to understanding the present disclosure, and those skilled in the art will be aware of many implementations. In some embodiments, the antenna subsystem 112 may be shared between the cellular modem 110 and the I / O interface 108; for example, the same antenna may be used to support any combination of cellular, Wi-Fi, and / or Bluetooth communications.

[0042] The user equipment 100 may further include Figure 1Other components not shown in the figure. For example, in various embodiments, user device 100 may include: one or more data storage devices using fixed or removable storage media; a global positioning system (GPS) and / or other global navigation satellite system (GNSS) receiver; a camera; a microphone; a speaker; a power source (e.g., a battery); power management circuitry; any number of environmental sensors (e.g., temperature sensors, pressure sensors, accelerometers, chemical sensors, optical sensors, etc.); and the like. Thus, user device 100 may provide a variety of functionality, some or all of which may be enhanced by or rely on cellular data communications supported by cellular modem 110.

[0043] Figure 2 is a simplified block diagram of a cellular modem processor 200 according to some embodiments. The cellular modem processor 200 may implement Figure 1 All or part of the cellular modem 110. In various implementations, the cellular modem processor 200 may operate as a user equipment (UE) in a cellular radio access network, such as a 4G network and / or a 5G network.

[0044] The signal processing capabilities of the cellular modem processor 200 may be implemented in various processing clusters 202. Each processing cluster 202 may include one or more pipelines 210 and dedicated buffer memory 212 (e.g., SRAM). Processing clusters 202 may be used to allocate portions of the buffer memory 212 to each pipeline 210, so that different pipelines 210 do not require a shared buffer. Each pipeline 210 may implement a specific sequence of operations associated with cellular data communications. For example, the control and authorization cluster 202-a may implement one or more pipelines 210-a for physical downlink control channel (PDCCH) processing for 4G and / or 5G networks. Information extracted from the control channel may be provided to other clusters, for example, via data structure 220. The demodulation / decoding (DMDC) cluster 202-b may implement one or more pipelines 210-b for physical downlink shared channel (PDSCH) processing for 4G and / or 5G networks. The uplink cluster 202-c may implement one or more pipelines 210-c for physical uplink control channel (PUCCH) processing and physical uplink shared channel (PUSCH) processing for 4G and / or 5G networks. The pipelines in the control and grant cluster 202-a, DMDC cluster 202-b, and uplink cluster 202-c may operate in the frequency domain. The time domain cluster 202-d may implement one or more pipelines 210-d for conversion between the time domain and the frequency domain, which may include Fourier transforms and inverse Fourier transforms (e.g., using a fast Fourier transform (FFT) or other discrete Fourier transform (DFT) algorithm).

[0045] Each pipeline 210 includes dedicated logic circuits that implement a specific sequence of operations. The operations may conform to the specifications of a specific cellular data network (including 4G and / or 5G networks). For example, the PDSCH pipeline 210-b in the DMDC cluster 202-b may implement frequency domain signal processing operations for 4G PDSCH channels, including orthogonal frequency division multiplexing (OFDM) symbol demapping, descrambling, deinterleaving, rate recovery, decoding using a turbo decoder, and error detection and correction. Similarly, a separate PDSCH pipeline 210-b in the DMDC cluster 202-b may implement frequency domain signal processing operations for 5G PDSCH channels, including descrambling, deinterleaving, rate recovery, decoding using a low-density parity check (LDPC) decoder, and error detection and correction. In some embodiments, at least one PDSCH pipeline in the PDSCH pipeline 210-b may be a configurable pipeline that handles both 4G and 5G PDSCH decoding. As another example, the PUCCH pipeline 210-c in the uplink cluster 202-c may implement frequency domain uplink processing for 4G PUCCH and PUSCH channels, including multiplexing of PUCCH and PUSCH data blocks. For example, the first pipeline may perform PUSCH encoding operations, including CRC (cyclic redundancy check) calculation, Turbo encoding, interleaving of coding subblocks, and rate matching, while the second pipeline may perform PUCCH encoding operations, including CRC calculation, convolutional encoding, interleaving of coding subblocks, and rate matching. The downstream pipeline may receive the rate-matched output of the first and second pipelines and multiplex the data into a single data stream for transmission, and then scramble the data. The output may be mapped to a sequence of OFDM symbols for transmission. As shown in these examples, each pipeline 210 may implement complex operations, and different pipelines 210 may implement different operations. In some cases, cluster 202 may include multiple copies of the same pipeline 210, which can operate in parallel on different parts of the data stream to support higher throughput. In addition to or instead of this, cluster 202 may include multiple different pipelines 210. For example, in some embodiments, DMDC cluster 202-b may have one pipeline dedicated to 4G PDSCH processing and two copies of a shared pipeline that can be reconfigured for 4G or 5G PDSCH processing. Additional examples of pipeline and signal processing operations are described below.

[0046] As described above, each pipeline 210 may have its own buffer 212 to store data as it progresses through the pipeline. To facilitate sharing of data between different pipelines 210 and different clusters 202, a data structure 200 may be provided that includes memory 222 local to the cellular modem processor (referred to as "L1 memory"). The data structure 200 may include memory circuitry (e.g., SRAM, DRAM, etc.) that implements the L1 memory 222, read and write interfaces connected to the clusters 202 via a crossbar, and arbitration logic for managing multiple requests (e.g., using time division multiplexing or other techniques). In some embodiments, the data structure 200 may be implemented so that any cluster 202 can access any location in the L1 memory 222. The specific memory or data structure architecture is not critical to understanding the present disclosure, and various architectures, including conventional architectures, may be used. In some embodiments, the L1 memory 222 may be used to pass data into and out of the pipeline 210. For example, as described below, each pipeline 210 may include a first stage (or processing engine) that reads input data from L1 memory 222 and a final stage (or processing engine) that writes output data to L1 memory 222 .

[0047] The control structure 230 may include implementing communication between the cluster 202 and / or between the cellular modem processor 200 and a device or system (e.g., Figure 1 The control structure 230 may include circuitry for communicating between the cellular modem processor 200 and other components of the user device 100 in the device or system in which the cellular modem processor 200 operates. For example, the control structure 230 may support messages from the uplink cluster 202-c to the time domain cluster 202-d indicating when uplink data is ready for conversion to the time domain and transmission, and messages from the time domain cluster 202-d to the DMDC cluster 202-b and / or the control and authorization cluster 202-a indicating when downlink data has been received and is ready for decoding. Any other messages or control signals for coordinating operations across different clusters or other components may be supported via the control structure 230. The specific control architecture is not critical to understanding the present disclosure, and various architectures, including conventional architectures, may be used.

[0048] The cellular modem processor 200 may also include a processor for use in a system (e.g., Figure 1 The cellular modem processor 200 interfaces with other components of the user equipment 100 within the system. For example, the system memory interface 240 may provide a direct memory access (DMA) interface to move data between the L1 memory 222 and the cellular modem processor 200. Figure 1The RF interface 250 may communicate with the host processor 102 via an interface such as the Advanced eXtensible Interface (AXI), which is part of the ARM Advanced Microcontroller Bus Architecture, or any other suitable interface for communication between a host processor and a coprocessor. The system memory interface 240, the RF interface 250, and the host processor interface 260 may be coupled to other elements within the cellular modem processor 200 via the control structure 230.

[0049] It should be understood that the cellular modem processor 200 is illustrative and that variations and modifications are possible. The cellular modem processor may include any number and combination of clusters and pipelines that support any number and combination of cellular data communication standards. The data structures and control structures may vary as needed. In some embodiments, the cellular modem processor 200 may have a high throughput to support high-speed cellular networks (e.g., 12 Gbps for 5G networks).

[0050] To provide high throughput, a cellular modem processor may include multiple pipelines, where each pipeline may include multiple dedicated circuits configured to perform specific operations associated with data communications; examples include encoding, decoding, interleaving, rate matching, deinterleaving, derate matching, calculating cyclic redundancy check (CRC) bits, performing CRC, etc. In some embodiments, some or all of the pipelines may be implemented using a general architectural framework that provides flexible (firmware-based) control with data synchronization mechanisms that are independent of the specific functionality of the pipeline or pipeline stage.

[0051] Figure 3A simplified block diagram of the architecture of a pipeline 310 for a processor, such as the cellular modem processor 200, is shown in accordance with some embodiments. The pipeline 310 is presented as a generalized architectural model that can be used to provide data synchronization (or flow control) in various signal processing or other data processing pipelines, including any or all of the pipelines 210 in the cellular modem processor 200. In some embodiments, the pipeline 310 can be a vector pipeline that can execute single instruction multiple data (SIMD) instructions to increase parallelism. The pipeline 310 includes multiple processing engines. In this example, the processing engines include a vector load engine 321, two intermediate processing engines 322, 323, and a vector store engine 324. The vector load engine 321 communicates with the read interface 312 to load data stored in L1 memory (e.g., Figure 2 312). The intermediate processing engine 322 may perform further operations on the data written to the buffer memory 312 via the vector load engine 321, and may write the results of such operations back to the buffer memory 312. Similarly, the intermediate processing engine 323 may perform further operations on the data written to the buffer memory 312 via the intermediate processing engine 322, and may write the results of such operations back to the buffer memory 312. Although two intermediate processing engines are shown, it should be understood that any number of intermediate processing engines may be included in the pipeline. The vector storage engine 324 may communicate with the L1 memory (e.g., Figure 2 222) shown in FIG. For example, the vector storage engine 324 can read data written to the buffer memory 312 through the intermediate processing engine 323 (the last intermediate processing engine) and write the data to the L1 memory. In some embodiments, the vector storage engine 324 can also perform other operations on the data read from the buffer memory 312 before writing the data to the L1 memory. Each processing engine 321-324 may include logic circuits that implement specific functions related to cellular data processing. For example, in the PDSCH pipeline, the processing engines may include processing engines that perform descrambling, deinterleaving and rate recovery, decoding, and error detection and correction.

[0052] Processing engines 321-324 can operate as stages of a pipeline, where later stages operate on the outputs of earlier stages. Due to data dependencies between stages, processing engines 321-324 typically do not operate on the same data set at the same time. However, pipeline 310 can operate as a multi-threaded pipeline, where different processing engines operate on different independent data sets simultaneously. For example, intermediate processing engine 322 can operate on a first data set, while vector load engine 321 loads a second data set. Threads can be defined to correspond to each data set. Each thread can have an associated context. For example, for LDPC encoding, different threads can use different base graphs, code block sizes, etc. Each of processing engines 321-324 can include parameter registers that store parameter values that define the current context of the processing engine; when switching threads, new parameter values can be loaded into the parameter registers.

[0053] Each processing engine 321-324 may perform complex operations (e.g., LDPC decoding) that may take many clock cycles to complete. Operations performed in different processing engines in the same pipeline may take different amounts of time to complete, and in some cases, operations may take a variable amount of time, for example, depending on the parameter values of the threads. Therefore, pipeline 310 may benefit from data synchronization (or flow control) between processing engines 321-324 to ensure that an upstream processing engine writes data for a particular operation to buffer 312 before a downstream processing engine attempts to read the data.

[0054] According to some embodiments, a combination of firmware-based control and hardware-based interlocking mechanisms can be used to provide data synchronization in pipelines such as pipeline 310, and this hardware-based interlocking mechanism can be independent of the specific operation implemented in the pipeline. For example, pipeline 310 can be controlled by control processor 340. Control processor 340 can be, for example, a scalar or superscalar microprocessor that implements an instruction set architecture (ISA), such as the x86 ISA originally developed by Intel and the related x86-64 ISA developed by AMD and Intel, ARM and AArch64 ISA from ARM Holdings, PowerISA and PowerPC ISA, RISC-V or other ISA from IBM / Motorola, including custom ISA. Therefore, control processor 340 may include conventional microprocessor components, such as instruction memory and associated circuits, to obtain and decode instructions and dispatch instructions to processing engines or functional units for execution. In some embodiments, control processor 340 may include functional units, such as general-purpose ALUs, to which some instructions (e.g., addition, comparison, etc.) may be dispatched.

[0055] The ISA supported by the control processor 340 may define the set of instructions that the control processor 340 dispatches to the pipeline 310 (e.g., to a particular processing engine 321-324 of the pipeline 310). For example, a particular instruction may be defined as being dispatched for execution by one of the processing engines 321-324 in the pipeline 310 for the purpose of performing an encoding process (such as LDPC encoding). The instructions dispatched to the pipeline 310 may be vector (SIMD) instructions, regardless of whether the control processor 340 is a vector processor. In some cases, the instructions dispatched to the pipeline may include context (thread-specific) parameters, such as the address range within the buffer 312 for reading and / or writing data, as well as other parameters that specify aspects of the operation to be performed (e.g., rate matching parameters, code block size for encoding or decoding, etc.). Additionally or alternatively, the ISA may define parameter setting instructions that provide some or all of the thread's context parameters to the pipeline 310.

[0056] Program code to be executed by control processor 340 may be provided as firmware. For example, the instruction storage memory of control processor 340 may be loaded with code during installation or upgrade of a user device (e.g., user device 100), and control processor 340 may execute the firmware code.

[0057] The order of instructions in the program code can (implicitly) define data dependencies. For example, if an instruction to write to a particular memory location in the buffer memory 312 precedes an instruction to read from that location, a read-after-write dependency is defined. If an instruction to read from a particular memory location in the buffer memory 312 precedes an instruction to write to that location, a write-after-read dependency is defined. If two different instructions specify writing to the same location in the buffer memory 312, a write-after-write dependency is defined. If instructions with data dependencies are not executed in order relative to each other, incorrect data may be read, resulting in incorrect output data. In some embodiments, the control processor 340 issues all instructions in sequence, which can be helpful in identifying data dependencies within the pipeline 310. In some cases, data dependencies may exist between instructions to different processing engines 321-324. For example, within a thread, the processing engine 323 may operate on output data from the processing engine 322, and the output data involves a read-after-write dependency. In the event that there is data dependency between processing engines, a subsequent processing engine (eg, processing engine 323) should wait until a previous processing engine (eg, processing engine 322) has finished writing its output data before starting to read its input data.

[0058] To manage data dependencies between the processing engines 321-324, the pipeline 310 may include an interlock controller 330. The interlock controller 330 may be a dedicated logic circuit and may have associated memory that implements a virtual register file 332. For example, the virtual register file 332 may be implemented using a lookup table or other addressable memory structure. (It should be understood that, as used herein, the term "virtual register file" refers to a physical memory structure. As described below, the physical memory structure may be used to store data dependency information based on references to virtual addresses.) As described below, the interlock controller 330 may use the virtual register file 332 to track data dependencies and determine when the data dependencies are cleared so that a particular processing engine can execute a particular instruction. For example, upon receiving a dispatch instruction from the control processor 340, any of the processing engines 321-324 may send a read lock request specifying an input address range (which may be defined in a virtual address space) and / or a write lock request specifying an output address range (which may be defined in the same virtual address space) to the interlock controller 330. The interlock controller 330 may update the virtual register file 332 to establish a read lock and a write lock for the specified address, for example, by adding a read lock indicator or a write lock indicator to a lock list associated with the specified address. Upon completion of an instruction (or a read operation or a write operation associated with the instruction), the processing engine may send a clear lock request specifying which read lock or write lock is to be cleared, and the interlock controller 330 may update the virtual register file 332 to clear the read lock or write lock. Before executing an instruction, the processing engines 321-324 may poll the interlock controller 330 using the relevant virtual address, and if the polled virtual address clears the data dependency, the interlock controller 330 may respond with a "grant" signal, and if the polled virtual address does not clear the data dependency, the interlock controller may respond with a "reject" signal. The processing engines 321-324 may wait until a grant signal is received from the interlock controller 330 before executing the instruction (while continuing to poll the interlock controller 330). Thus, interlock controller 330 may provide data synchronization between processing engines 321 - 324 in pipeline 310 .

[0059] It should be noted that the operation of the interlock controller 330 can be independent of the specific operation performed by any processing engine or the time a given operation may take. As long as each processing engine provides a read lock request and a write lock request when it receives an instruction and defers execution until a grant signal is received, the interlock controller 330 can manage data dependencies.

[0060] In some embodiments, each processing engine 321 - 324 may communicate with the control processor 340 and the interlock controller 330 using a unified interface. Figure 4A more detailed block diagram of pipeline 310 according to some embodiments is shown. As described above, pipeline 310 includes a set of processing engines, including vector load engine 321, intermediate processing engines 322-323, and vector store engine 324. Figure 4 Also shown are components of a representative processing engine 322. (It should be understood that other processing engines may include similar components.) The processing engine 322 may include a scheduling queue interface 402, a scheduling queue 403, an instruction interface 404, and one or more functional units 422 (two functional units 422-a and 422-b are shown; in general, a processing engine may have one or more functional units). Each functional unit 422 may be implemented as a vector (SIMD) functional unit, which includes dedicated logic circuitry configured to execute instructions (or operations) on multiple inputs in parallel. Instructions may have arbitrary complexity. For example, a PDSCH processing pipeline that supports both 4G and 5G networks may include an instance of the processing engine 322 that performs decoding. In this case, functional unit 422-a may implement Turbo decoding for 4G networks, while functional unit 422-b implements LDPC decoding for 5G networks. Whether Turbo decoding or LDPC decoding is performed for a particular data block may be determined by instructions from the control processor 340. For example, there may be a specific instruction that calls functional unit 422-a and a different specific instruction that calls functional unit 422-b. Each functional unit 422 may also include registers to store data during instruction execution and / or parameters that control instruction execution. It should be understood that each functional unit 422 is a different physical circuit; different functional units 422 do not share components. Similarly, each processing engine 321-324 is a different physical circuit.

[0061] It should be understood that pipeline 310 and / or its components (e.g., processing engine 322) may include additional components. For example, processing engine 322 (or any processing engine in pipeline 310) may include control and status registers (CSRs) 424 that store information about received and / or executed instructions, data registers, and / or other internal registers that are not shared with other processing engines. In some embodiments, the CSRs and / or other internal registers of a processing engine may be read from or written to by the control processor 340. For example, the control processor 340 may dispatch instructions to a processing engine to read from or write to a specific CSR. In some embodiments, both blocking and non-blocking reads are supported. Register read and register write instructions may be queued in a dispatch queue 403 via a dispatch queue interface 402 and executed sequentially with other instructions to the same processing engine. In some embodiments, the internal registers of a processing engine (e.g., processing engine 322) are not shared between processing engines, and when a register read or register write instruction reaches the front of the dispatch queue 403, the register read or register write instruction may be executed without polling the interlock controller 330. In some embodiments, the execution of a register access instruction may wait until the execution of any preceding instruction has completed. A vector status register and a vector tag register may be implemented in a similar manner. One skilled in the art having access to the present disclosure will be able to provide an appropriate set of status registers and / or tag registers and associated logic to support the execution of instructions using the pipeline 310 and the control processor 340. In various embodiments, any register shared between two or more processing engines may have a virtual address that allows the interlock controller 330 to manage data dependencies for that register, while any register used by only one processing engine may or may not have a virtual address, depending on the specific implementation.

[0062] As mentioned above Figure 3 As described above, a buffer 312 local to the pipeline 310 may be used to transfer data between the processing engines 321-324. In some cases, a buffer may be dedicated to a pair of consecutive processing engines in the pipeline. For example, Figure 4 A dedicated buffer 416 is shown where the vector load engine 321 writes data and the intermediate processing engine 322 reads data. In other cases, the buffer may be shared by more than two processing engines in the pipeline. For example, Figure 4A shared buffer 410 is shown having a write interface 412 and a read interface 414. Intermediate processing engines 322 and 323 each write data to shared buffer 410, and intermediate processing engine 323 and vector storage engine 324 each read data from shared buffer 410. Write interface 412 and read interface 414 can implement a crossbar and arbitration scheme so that any processing engine 321-324 (or any subset of processing engines 321-324) in pipeline 310 can write to or read from any location in shared buffer 410. Within a particular pipeline 310, any combination of shared buffer 410 and dedicated buffer 416 can be used, and within a given cellular modem processor (e.g., processor 200), different pipelines can have different buffer configurations. A pipeline address space can be defined within each pipeline so that each location in buffers 416 and 410 (and / or any other buffers present in the pipeline) has a unique address. In some embodiments, the pipeline address space can be a virtual address space that is converted or mapped to physical locations in buffers 416, 410 via a simple operation (e.g., a virtual address can be a physical address with a pre-pended buffer identifier, or the virtual address can be the same as the physical address); various mappings between virtual addresses and physical addresses can be used, provided that each virtual address maps to a different physical location in the pipeline's buffers. In some embodiments, the virtual address space can also include virtual addresses representing locations other than the buffers in the pipeline. For example, virtual addresses in the virtual address space can be limited to locations in L1 memory (or any shared memory) and / or to internal registers within a processing engine (e.g., any or all of the processing engines in processing engines 322), such as CSR 424, internal data registers, or any other register or data storage location in pipeline 310.

[0063] The operation of the functional unit 422 can be controlled by the dispatch queue interface 402, the dispatch queue 403 and the instruction interface 404. The dispatch queue interface 402 can receive instructions that are dispatched from the control processor 340 for execution by the processing engine 322. The dispatch queue 403 can be a memory structure, such as a FIFO buffer, that can maintain a queue of instructions received from the control processor 340 until these instructions can be executed (in sequence) by the functional unit 422. The depth of the dispatch queue 403 depends on design choice, and in various embodiments, the dispatch queue 403 can hold one, two, or more instructions. The dispatch queue interface 402 can also include circuitry for adding instructions to the dispatch queue 403, and additional circuitry for communicating with the interlock controller 330 to send read lock requests and write lock requests when the dispatch queue interface 402 receives a new instruction. Instruction interface 404 may include circuitry for reading the oldest instruction in dispatch queue 403, communicating with interlock controller 330 (e.g., by polling) to determine when data dependencies of the oldest instruction in dispatch queue 403 are satisfied, and issuing instructions in appropriate functional units 422 when the data dependencies are satisfied. Examples of the operation of dispatch queue interface 402 and instruction interface 404 are described below.

[0064] The interlock controller 330 may receive and respond to requests from the processing engines 321 - 324 . Figure 5 is a simplified block diagram showing additional details of the interlock controller 330 according to some embodiments. The interlock controller 330 may include register update circuitry 532 and decision logic circuitry 534, as well as an interface 536 for the processing engines 321-324. In this example, there are four processing engines. It should be understood that any number of processing engines may be included in a pipeline, and all processing engines in the same pipeline may communicate with the same interlock controller. The interlock controller 330 may maintain a virtual register file 332. As shown in FIG. Figure 5 As shown, the virtual register file 332 may include a data structure 532 (e.g., a lookup table) that tracks the state of each address in the pipeline address space. For example, for each address or address range in the pipeline (virtual) address space, the data structure 532 may store information indicating whether a read lock and / or a write lock is currently established, and if so, by which processing engine(s). In some embodiments, the data structure 532 may store a list associated with the address or address range that lists all read locks and write locks that have been received and not yet cleared, in the order in which they were received.

[0065] Via interface 536, interlock controller 330 can receive requests from processing engines 321-324, including "lock," "clear," and "poll" requests, and can send responses to processing engines 321-324, including "grant" and "reject" responses. In some embodiments, "lock" and "clear" requests are processed by register update circuitry 532, while "poll" requests are processed by decision logic 534. For example, register update circuitry 532 can update the contents of data structure 532 in response to each "lock" or "clear" request. A "lock" request can specify the virtual address range to be locked (as used herein, "address range" can encompass any amount of memory including a single address) and whether the lock is a read lock or a write lock. A read lock indicates that the processing engine will read from the buffer location corresponding to the virtual address range, and a write lock indicates that the processing engine will write to the buffer location corresponding to the virtual address range. A "clear" request indicates that a read lock or a write lock can be cleared; the request can specify the address range to be cleared and the lock type (read lock or write lock). As each request is received, register update circuitry 532 may accordingly update data structure 532. In some embodiments, register update circuitry 532 may send an acknowledgment ("Ack") response to the processing engine after updating data structure 532.

[0066] It should be understood that the address ranges of different "lock" and "clear" requests from different processing engines may overlap but not completely coincide. For example, different processing engines in a pipeline may operate on data blocks or data blocks of different sizes. Thus, for example, in Figure 3 and Figure 4 In the pipeline 310 of FIG. 5 , the vector load engine 321 may write-lock a large address range for a single instruction, while the intermediate processing engine 322 may read-lock a subset of the address range for each instruction. In some embodiments, the data structure 532 may have sufficient granularity to track the state of every address in the virtual address space; a coarser granularity (e.g., line or page) may be used if desired. In some embodiments, the granularity may be selected based on the minimum size of the data block processed by the processing engine.

[0067] When a processing engine is ready to execute the next instruction in its dispatch queue, the processing engine may send a "poll" request. Each "poll" request may identify a virtual address range and the operation to be performed (read or write). Decision logic 534 may use the virtual address range to read data structure 532 to determine whether all data dependencies for the address range have been satisfied based on the presence or absence of read locks and write locks. A specific example of decision logic is described below. If all data dependencies have been satisfied, decision logic 432 may send a "grant" response to the processing engine that sent the "poll" request; if not, decision logic 432 may send a "reject" response.

[0068] In some embodiments, each message from a processing engine may include a processing engine identifier; alternatively, each processing engine 321-324 may be connected to an interface 536 (at Figure 5 , and the port identifiers can be used to identify the processing engines. Other implementations are possible, provided that the virtual register file 332 indicates which addresses have established read locks and / or write locks, and by which processing engines.

[0069] In some embodiments, the processing engine interface 536 may implement arbitration logic to prioritize requests that may be received in the same clock cycle. For example, the arbitration logic may prioritize requests based on the sequence in which the processing engines in the pipeline are assigned (e.g., an upstream processing engine may be prioritized over a downstream processing engine), or round-robin prioritization logic may be used. In some embodiments, time division multiplexing (TDM) may be used, wherein each processing engine is assigned a specific clock cycle during which each processing engine's request to the interlock controller 330 is serviced. TDM may be implemented, for example, by including timing logic in each processing engine to determine when a processing engine sends a request, or by providing a buffer in the interface 536 to store requests from different processing engines and select the next request in a round-robin manner. Various arbitration schemes may be used.

[0070] It should be understood that pipeline 310 is exemplary and that variations and modifications are possible. Any number of processing engines may be included in the pipeline, and the processing engines may perform any operations, including operations related to 4G and / or 5G data processing. The virtual address space may be defined as needed. The scheduling queue of a processing engine may hold any number (one or more) entries, and the scheduling queues of different processing engines may have different depths. A processing engine may include one or more functional units; where there are multiple functional units, each functional unit may have different associated instructions.

[0071] In some embodiments, a processing engine may include multiple functional units that perform sequential operations, and the processing engine may include a hardware sequencer to control the sequencing of operations in the different functional units. The hardware sequencer may include an instance of an interlock controller 330 and a virtual register file 332 local to one processing engine. In other words, any processing engine within a pipeline, such as pipeline 310, may implement a "sub-pipeline," and multiple sub-pipelines may exist within a given pipeline. Where a processing engine implements a sub-pipeline, a control processor (e.g., control processor 340) may schedule only instructions for a sub-pipeline, and the processing engine may be configured to sequentially execute all stages of the sub-pipeline in response to the instruction.

[0072] Examples of specific data synchronization operations that may be implemented within a pipeline (eg, pipeline 310 ) using an interlock controller (eg, interlock controller 330 ) will now be described. Figure 6 、 Figure 7 and Figure 8 Flow control operations that may be implemented in each processing engine of the pipeline are shown according to some embodiments. For example, the operations shown may be implemented in each processing engine 321-324 of pipeline 310. Figure 6 A process 600 is shown that can be performed when a processing engine receives an instruction according to some embodiments. Process 600 can be implemented, for example, in the dispatch queue interface 402 of each processing engine 321-324. At block 602, a new instruction is received at the dispatch queue interface 402, for example, from the control processor 340 as described above. When the new instruction is received, the new instruction can be added to the dispatch queue 403. At block 604, the input (read) virtual address range and the output (write) virtual address range can be extracted from the instruction. At block 606, a read lock request for the input virtual address range and a write lock request for the output virtual address range can be sent to the interlock controller 330. The processing of the read lock request and the write lock request by the interlock controller 330 is described below. It should be understood that some instructions may cause only a read lock request to be generated or only a write lock request to be generated. For example, a "load" instruction issued to the vector load engine 321 may specify a read address range in the L1 memory space (which may be inside or outside the pipeline's virtual address space, as needed) and a write virtual address in the pipeline's virtual address space; conversely, a vector store instruction issued to the vector store engine 324 may specify a read address range in the pipeline's virtual address space and a write address range in the L1 memory space (which may also be inside or outside the pipeline's virtual address space). In some embodiments, any input (or output) address outside the pipeline's buffers does not cause a read lock (or write lock) request to be generated. Thus, in some embodiments where the L1 memory space is not represented in the pipeline's virtual address space, a vector load instruction may cause a write lock request to be generated instead of a read lock request, while a vector store instruction may cause a read lock request to be generated instead of a write lock request. In the case where the L1 memory space is represented in the pipeline's virtual address space, a vector load instruction or a vector store instruction may generate both a read lock request and a write lock request. Where the L1 memory space is represented in the virtual address space of a pipeline, the interlock controller can manage L1 memory data dependencies between instructions (e.g., load instructions and store instructions) within the pipeline. As described above, the L1 memory can be shared between multiple pipelines, and the L1 memory structure can include additional features related to coordinating access requests across different pipelines.

[0073] After executing process 600, dispatch queue interface 402 may queue instructions (e.g., in dispatch queue 403) for execution until all previously received instructions have been executed. At this point, instruction interface 404 may receive an instruction from dispatch queue 403 as the next instruction to be executed. Figure 7 Shown is a flow chart of a process 700 for executing an instruction in a processing engine (e.g., processing engine 322) according to some embodiments. At block 702, the next instruction to be executed can be received. For example, instruction interface 404 can read the next instruction from dispatch queue 403. At block 704, the processing engine can poll an interlock controller to determine whether the input data for the instruction are ready to be read, and whether the output data for the instruction can be safely written to an output buffer (e.g., buffer 410 or buffer 416, as the case may be). For example, processing engine 322 can send a first "poll" request including an input virtual address range for the instruction and a second "poll" request including an output virtual address range for the instruction to interlock controller 330. At block 706, the processing engine can receive a response to each poll request from the interlock controller. For example, interlock controller 330 can respond to each poll request with "authorization" or "rejection." If at block 708, the response to one or both polling requests is not "granted," process 700 may return to block 704 and poll the interlock controller again. In some embodiments, process 700 may wait for one or more clock cycles before polling again. In some embodiments where processing engine 322 initially sends two "poll" requests at block 704, if the response to one request is "granted" and the response to the other request is "rejected," then at the next iteration of block 704, process 700 may only send the poll request that has not yet been granted. In this way, process 700 may continue to poll the interlock controller until requests have been granted for the input virtual address range and the output virtual address range.

[0074] If both requests have been granted at block 708, the processing engine may execute the instruction at block 710. For example, the processing engine 322 may enable the functional unit 422 to perform its operations. Once enabled, the functional unit 422 may continue to operate without further external control. Depending on the description and specific implementation of the functional unit 422, the operations of the functional unit 422 may include: moving data from a buffer location identified by the input virtual address range to an operand register within the functional unit 422, performing computational and / or logical operations, and / or moving data from an operand register to a buffer location identified by the output virtual address range. In some embodiments, the functional unit 422 may read from the buffer location multiple times and / or write to the buffer location multiple times. Because the processing engine 322 maintains a read lock and a write lock throughout the execution process, the data in the lock buffer is not modified except by the functional unit 422. At block 712, execution of the instruction may be completed, which may include, for example, writing the final output data for the instruction (at a location corresponding to the output virtual address range) to the buffer 416.

[0075] At block 714, upon completion of execution, the processing engine may send a message to the interlock controller to clear the read lock for the input virtual address range and clear the write lock for the output virtual address range. For example, the processing engine 322 may send a first "clear" request to the interlock controller 330 indicating that the read lock for the input virtual address range should be cleared, and send a second "clear" request to the interlock controller 330 indicating that the write lock for the output virtual address range should be cleared. In some embodiments, block 714 may be performed after completion of instruction execution, which may include passing output data from registers within the functional unit 422 to a buffer (e.g., buffer 410 or buffer 416, as appropriate).

[0076] Process 700 may be executed for each instruction in dispatch queue 403. In some embodiments, the processing engine executes process 700 for one instruction at a time, and process 700 for the second instruction may begin after completing execution of the first instruction. Other specific implementations are also possible. For example, in some embodiments, process 700 for the second instruction may begin upon execution of the first instruction at block 710. Depending on the specific implementation of the processing engine, if a poll request for the second instruction is granted (a "yes" result at block 708) before completing execution of the first instruction, execution of the second instruction may begin (e.g., if execution of the second instruction does not interfere with execution of the first instruction), or process 700 for the second instruction may wait until execution of the first instruction has completed before beginning execution at block 710. As described above, the instruction interface may be designed to issue instructions sequentially, in which case there would be no benefit in polling the interlock controller for any instruction other than the instruction to be executed next. Different processing engines in the pipeline may execute process 700 independently of each other to process instructions in their respective dispatch queues. (Thus, instructions dispatched to different processing engines may execute out of order with respect to each other, if data dependencies permit.)

[0077] In process 700, instruction execution begins only after both the read poll request and the write poll request are granted, and the processing engine holds the read lock and the write lock in order to complete instruction execution. In some embodiments, it may be desirable to manage the read lock and the write lock at a finer granularity. By way of example, Figure 8 A flow chart of another process 800 for executing an instruction in a processing engine (e.g., processing engine 322) according to some embodiments is shown. Process 800 may be substantially similar to process 700. At block 802, the next instruction to be executed may be received. For example, instruction interface 404 may read the next instruction from dispatch queue 403. At block 804, the processing engine may poll the interlock controller to determine whether the input data for the instruction is ready to be read. For example, processing engine 322 may send a "poll" request including the input virtual address range for the instruction to interlock controller 330. At block 806, the processing engine may receive a response from the interlock controller. For example, interlock controller 330 may respond with "grant" or "reject." If, at block 808, the response is "reject" (or not "grant"), process 800 may return to block 804 and poll the interlock controller again. In some embodiments, process 800 may wait for one or more clock cycles before polling again.

[0078] If the response at block 808 is "Granted," the processing engine may begin executing the instruction at block 810. For example, the processing engine 322 may read the input data from the buffer 416 (at a location corresponding to the input virtual address range) into the input register of the appropriate functional unit 422 and enable the functional unit 422 to perform its operation. Once enabled, the functional unit 422 may continue to generate output data without further external control. The output data may be temporarily stored in a register within the functional unit 422.

[0079] At block 812, the processing engine may send a message to the interlock controller to clear the read lock for the input virtual address range. For example, the processing engine 322 may send a "clear" request to the interlock controller 330 indicating that the read lock for the input virtual address range should be cleared. In various embodiments, block 812 may be performed at any time after all input data for the instruction from the input buffer of the functional unit 422 has been read, including after the instruction has completed execution.

[0080] At block 814, the processing engine may begin polling the interlock controller to determine whether the output data for the instruction can be safely written to the output buffer (e.g., buffer 410 or buffer 416, as appropriate). For example, the processing engine 422 may send a "poll" request to the interlock controller 330 that includes the output virtual address range for the instruction. In some embodiments, block 814 may be performed at any time before the functional unit 422 begins writing any data to the output buffer. For example, if the functional unit 422 is configured to generate a set of output data in a local register of the processing engine 322, the output data may remain in the local register until the processing engine 322 determines that the output data can be written to the output buffer. At block 816, the processing engine may receive a response from the interlock controller. For example, the interlock controller 330 may respond with "grant" or "reject." If, at block 818, the response is "reject" (or not "grant"), the process 800 may return to block 814 and poll the interlock controller again. In some embodiments, the process 800 may wait one or more clock cycles before polling again. If the response at block 818 is "Granted," then at block 820, the processing engine may write the output data from the registers of the functional unit to the appropriate buffer. For example, the processing engine 322 may write the output data from the registers of the functional unit 422 to the shared buffer 410. At block 822, after writing the output data, the processing engine may clear the write lock. For example, the processing engine 322 may send a "Clear" message to the interlock controller 330 indicating that the write lock for the output virtual address range should be cleared. Thereafter, process 800 may be repeated for the next instruction in the dispatch queue 403.

[0081] As shown in processes 700 and 800, the point at which the processing engine begins polling the interlock controller for the virtual input address and / or virtual output address can be varied. Polling both the virtual input address and the virtual output address before starting execution (as in process 700) can simplify logic and may be particularly appropriate where the execution of an instruction may involve a series of read and / or write operations to a virtual address or range of virtual addresses. Similarly, the point at which the processing engine clears the read lock and / or write lock can be varied. Clearing the read lock (or write lock) as soon as the last read operation (or write operation) occurring during the execution of an instruction is complete can help reduce latency for subsequent instructions, but for some types of instructions, such as instructions where the execution involves multiple read-modify-write operations, it may be desirable to wait until the instruction completes.

[0082] In processes 600, 700, and 800, an interlock controller (e.g., interlock controller 330) may receive a "lock" request to establish a read lock or a write lock, may receive a "clear" request to remove a previously established read lock or write lock, and may receive a "poll" request to query whether data dependencies for a particular read or write operation have been satisfied. Figure 9 and Figure 10 is a flow chart illustrating the operation of an interlock controller, such as interlock controller 330 .

[0083] Figure 9 900 is a flow chart illustrating a process 900 that may be performed by an interlock controller (e.g., interlock controller 330) according to some embodiments. Process 900 may be performed in a continuous loop as a message is received from a processing engine of a pipeline (e.g., pipeline 310). At block 902, a message is received from a processing engine. For example, Figure 5 As shown, the message may be received at the processing engine interface 536 of the interlock controller 330. In some embodiments, block 902 may include arbitrating between multiple requests to select a request for processing, for example, as described above with reference to Figure 5 As stated.

[0084] If, at block 904, the message is a lock message, then at block 906, the interlock controller may update the virtual register file (VRF) by adding read lock information or write lock information for the virtual address range specified in the read lock message or write lock message. The specific information added may depend on the specific implementation of the virtual register file 332 (e.g., data structure 532). For example, in some embodiments, when a particular processing engine (e.g., processing engine 322) requests a read lock or a write lock, the interlock controller 330 may add an entry to a lock list associated with one or more addresses within the virtual address range specified in the message; the entry may include an identifier of the requesting processing engine and the lock type (read lock or write lock). The list may be an ordered list reflecting the order in which the lock requests were received.

[0085] If the message is not a lock message, process 900 proceeds to block 912. If, at block 912, the message is a purge message, then, at block 914, the interlock controller may update the virtual register file by removing (clearing) the read lock information or write lock information specified in the purge message. For example, if adding the read lock information or write lock information is performed by adding an entry to a lock list, clearing the read lock information or write lock information may be performed by deleting the entry from the lock list. In some embodiments, the oldest entry with the same processing engine and address range specified in the purge message is deleted.

[0086] If the message is not a lock message or a clear message, process 900 proceeds to block 916. If, at block 916, the message is a poll message, at block 918, the interlock controller may invoke decision logic (e.g., decision logic 534) to generate a response (e.g., grant or deny) based on whether all relevant data dependencies reflected in the virtual register file have been satisfied. Figure 10 is a flow chart of a decision logic process 1000 according to some embodiments. Process 1000 may be performed, for example, in Figure 5 The decision logic 534 is shown as being implemented in the example and may be executed at block 918 of the process 900 .

[0087] At block 1002, decision logic may receive a poll request, which may include a virtual address range and an indication of whether the poll request is for an input (read) address range or an output (write) address range. If the poll request is for an input address range, the data dependency of interest is a read-after-write dependency. If the poll request is for an output address range, the data dependency of interest includes both a read-after-write dependency and a write-after-write dependency. At block 1004, if the poll request is for an input address range, process 1000 may proceed to block 1006. At block 1006, process 1000 may check for any write locks on any addresses within the range that were established prior to the read lock corresponding to the poll request. In some embodiments, the read lock corresponding to the poll request may be considered the oldest read lock on the address range of the poll request requested by the processing engine that issued the poll request. For example, if the virtual register file 332 stores a lock list for virtual addresses or virtual address ranges, processing at block 1006 may include reading the lock list for each address in the input address range to determine whether any write locks exist prior to the read lock associated with the processing engine that sent the poll request. An earlier write lock indicates a read-after-write data dependency that should be cleared before the requesting processing engine begins reading. At block 1008, if any earlier write locks exist, the request should be denied and a "deny" message sent at block 1012. If no earlier write locks exist, the request should be granted and a "grant" message sent at block 1010.

[0088] If, at block 1004, the poll request is for an output address range, process 1000 may proceed to block 1014. At block 1014, process 1000 may check for any write locks established for any addresses within the range prior to the write lock corresponding to the poll instruction. In some embodiments, the write lock corresponding to the poll request may be considered the oldest write lock for the address range of the poll request requested by the processing engine that issued the poll request. For example, if the virtual register file 332 stores a lock list for virtual addresses or virtual address ranges, processing at block 1014 may include reading the lock list for each address within the input address range to determine whether any write locks exist prior to the write lock associated with the processing engine that issued the poll request. An earlier write lock indicates a write-after-write data dependency that should be cleared before the requesting processing engine begins writing. At block 1016, if any earlier write locks exist, the request should be denied and a "deny" message sent at block 1012. If no earlier write lock exists, then at block 1018, process 1000 may check for any read locks established for any addresses within the range that preceded the write lock corresponding to the poll instruction. In some embodiments, the write lock corresponding to the poll request may be considered the oldest write lock for the address range of the poll request requested by the processing engine that issued the poll request. For example, if the virtual register file 332 stores a lock list for virtual addresses or virtual address ranges, processing at block 1018 may include reading the lock list for each address within the input address range to determine whether any read locks exist prior to the write lock associated with the processing engine issuing the poll request. Earlier read locks indicate read-after-write data dependencies that should be cleared before the requesting processing engine begins writing. At block 1020, if any earlier read locks exist, the request should be denied and a "deny" message sent at block 1012. If no earlier read locks exist, the request should be granted and a "grant" message sent at block 1010. Process 1000 may be performed each time a poll request is received.

[0089] Reference again Figure 9 In some embodiments of process 900, any message not identified as a lock, purge, or poll request may be ignored. In other embodiments, such a message may generate a response, such as a negative acknowledgement ("Nack") indicating that the message was not processed.

[0090] It should be understood that Figures 6 to 10The processes shown are illustrative, and variations and modifications are possible. The order of operations may be modified to the extent permitted by logic, operations described individually may be combined, and additional operations not specifically described may be included. For example, the specific point in time at which a processing engine clears a read lock or a write lock during instruction execution may be modified, provided that the read lock (write lock) is not cleared until the processing engine has completed reading data from (writing data to) the address range associated with the lock.

[0091] In some embodiments, a processing engine may clear a read lock (or write lock) for a portion of an address range. Such a partial clearing of a lock may allow another processing engine to begin execution earlier; the tradeoffs include more requests to be processed by the interlock controller and additional logic in the processing engine to determine when a partial clear is safe.

[0092] In some embodiments, polling can be replaced by a notification protocol in which the interlock controller determines which processing engines have instructions that clear data dependencies and notifies those processing engines without waiting for polling. (However, the notification protocol may require more complex decision logic in the interlock controller.) In some embodiments, a pipeline flush operation can be defined as clearing all instructions from the dispatch queue and clearing all read locks and write locks from the virtual register file.

[0093] To further illustrate how a control processor (eg, control processor 340) and an interlock controller (eg, interlock controller 330) can provide data synchronization for a pipeline (eg, pipeline 310), reference is made to Figure 11 , which shows a simplified block diagram of a transmit front-end pipeline 1110 according to some embodiments. Transmit front-end pipeline 1110 may be an example of pipeline 310 described above. Vector loading engine 1121 and vector storage engine 1124 may be similar to or identical to vector loading engine 321 and vector storage engine 324 described above. Processing engine 1122 may implement an encoder algorithm for an uplink channel. For example, processing engine 1122 may include a functional unit that implements a turbo encoder for a 4G PUSCH channel and / or a functional unit that implements a convolutional encoder for a 4G PUCCH channel. Processing engine 1123 may include a functional unit that implements interleaving and rate matching for 4G PUSCH and / or 4G PUCCH channels. Pipeline 1110 may also include one or more buffers 1112 accessible to processing engines 1121-1124. Control processor 1140 and interlock controller 1130 may be similar to or identical to control processor 340 and interlock controller 330.

[0094] The operation of pipeline 1110 may be defined using program code (eg, firmware) executed by control processor 1140 . Figure 121 is a flow chart of a process 1200 for encoding a data block using pipeline 1110, according to some embodiments. Process 1200 will first be described from the perspective of program code. At block 1202, a data block is loaded from L1 memory into buffer 1112 of pipeline 1110, for example, by calling a load instruction. The buffer location into which the data block is loaded can be specified as an address range (A0 to An). To simplify the description, the addresses in this example are specified as virtual addresses in the pipeline virtual address space. In some embodiments, the program code can specify physical addresses, which the processing engines 1121-1124 can convert to virtual addresses when sending messages to interlock controller 1130. Any suitable addressing scheme can be used to specify the location in L1 memory from which the data block is read. At block 1204, a code block size is determined for the encoding operation. This determination can be based on channel conditions, supported code block sizes for a particular cellular network, and / or other information; the specific determination is not relevant to an understanding of the present disclosure and may involve reading parameters and performing arithmetic operations within control processor 1140. At block 1206, the starting virtual address (Ai) and ending virtual address (Aj) for the code block are determined. For example, encoding may begin at the first virtual address (address A0) of the data block and proceed sequentially to the last virtual address (An). If the data block size is larger than the code block size, encoding may be performed in address blocks corresponding to one code block, and the virtual addresses Ai and Aj may be calculated using arithmetic operations (e.g., incrementing the starting and ending addresses based on the code block size). At block 1208, the block is encoded, for example, by calling an encoding instruction. The location of the code block to be encoded may be specified as an input virtual address range (Ai to Aj) for storing the code block, and the location of the buffer for storing the resulting encoded data may be specified as an output virtual address range (Bi to Bj). The input virtual address range and the output virtual address range may have different sizes (e.g., if encoding adds bits to the data, the output virtual address range may be larger than the input virtual address range). At block 1210, the encoded block is interleaved and rate matched, for example, by calling the appropriate "IRM" instruction. The IRM instruction may specify an input virtual address range (Bi to Bj) for storing the encoded code block, and an output virtual address range (Ci to Cj). The input virtual address range and the output virtual address range may be of different sizes (e.g., if rate matching adds bits to the data, the output virtual address range may be larger than the input virtual address range). At block 1212, the rate-matched output data may be stored in L1 memory, for example, by calling a store instruction. The buffer location from which the data should be read may be specified as the virtual address range Ci to Cj. Any suitable addressing scheme may be used to specify the location in L1 memory where the data is written.At block 1214, if the entire data block has not been encoded (e.g., if Aj is less than An), process 1200 may return to block 1206 to determine the address range for the next code block. Once the entire data block has been encoded, process 1200 may end and other processing (including a new iteration of process 1200 to encode another data block) may begin at block 1220.

[0095] Process 1200 will now be described from the perspective of controlling processor 1140 to execute program code using pipeline 1110. (Execution of instructions dispatched to pipeline 1110 is described below.) At block 1202, control processor 1140 may dispatch a load instruction to pipeline 1110, where it enters the dispatch queue of vector load engine 1121. As described above with reference to process 600 ( Figure 6), the dispatch queue interface may send a write lock message for the virtual address range A0 to An, and the interlock controller 1130 receives the message and establishes a write lock, for example, by adding an entry to a lock list. At blocks 1204 and 1206, the control processor 1140 may execute instructions that cause the code block size and the starting and ending virtual addresses for the code block to be determined. These instructions may be scalar instructions that execute locally within the control processor 1140. At block 1208, the control processor 1140 may dispatch the encoding instruction to the pipeline 1110, where the load instruction enters the dispatch queue of the encoder engine 1122. The dispatch queue interface sends a read lock message for the input virtual address range Ai to Aj and a write lock message for the output virtual address range Bi to Bj to the interlock controller 330, which receives the message and establishes the read lock and the write lock, for example, by adding an entry to a lock list. At block 1210, the control processor 1140 may dispatch an IRM instruction to the pipeline 1110, where it enters the dispatch queue of the interleaving and rate matching engine 1123. The dispatch queue interface sends a read lock message for the input virtual address range Bi to Bj and a write lock message for the output virtual address range Ci to Cj to the interlock controller 330, which receives these messages and establishes the read lock and write lock, for example, by adding an entry to a lock list. At block 1212, the control processor 1140 may dispatch a store instruction to the pipeline 1110, where it enters the dispatch queue of the vector store engine 1124. The dispatch queue interface sends a read lock message for the input virtual address range Ci to Cj to the interlock controller 330, which receives these messages and establishes the read lock, for example, by adding an entry to a lock list. At block 1214 , the control processor 1140 may execute instructions to determine whether the entire data block has been encoded and determine whether to return to block 1206 or continue other processing at block 1220 .

[0096] The flow control in pipeline 1110 during process 1200 will now be described. At some point in time after the load instruction is dispatched at block 1202, the load instruction arrives at the front of the dispatch queue of vector load engine 1121. As described above with reference to process 700 ( Figure 7), when a load instruction arrives at the front of the dispatch queue, the vector load engine 1121 may begin polling the interlock controller 1130 using the output virtual address range A0 to An to determine whether the load instruction can be executed. The interlock controller 1130 checks for data dependencies (which may exist in previously received instructions that are still being executed) (e.g., as described above with reference to process 1000) and returns a grant response or a denial response. The vector load engine 1121 continues to poll the interlock controller 1130 until a grant response is received, at which point the vector load engine 1121 may begin loading data into the physical locations in the buffer 1112 that are mapped to the virtual address range A0 to An. Once the load is complete, the vector load engine 1121 may send a message to the interlock controller 1130 to clear the write lock for the address range A0 to An.

[0097] At some point after the encoding instruction is dispatched at block 1208, the instruction arrives at the front of the dispatch queue of encoder engine 1122. This event may occur before or after vector load engine 1121 has completed (or even begun) executing the load instruction. Regardless of the timing, encoder engine 1122 may begin polling interlock controller 1130 using the input virtual address range Ai to Aj (which is a subset of the range A0 to An). If vector load engine 1121 has not cleared the write lock, interlock controller 1130 returns a deny response to encoder engine 1122, which will continue polling (without executing instructions) until vector load engine 1121 clears the write lock. At this point, interlock controller 1130 may return a grant response to the next poll request from encoder engine 1122, and encoder engine 1122 may begin operating on the data in the physical buffer locations corresponding to virtual addresses Ai to Aj. Similar behavior is achieved for each instruction and each processing engine in pipeline 1110.

[0098] It should also be understood that pipeline 1100 can operate as a multi-threaded pipeline. For example, the next iteration of process 1200 may operate on a different block of data and may have different parameters (e.g., due to changing channel conditions); therefore, each iteration of process 1200 can be processed as a thread. Instructions for a new thread can enter pipeline 1110 and begin execution before pipeline 1110 has finished executing instructions for the previous thread. For example, a load instruction for thread 2 can be issued and executed while the downstream processing engine is still operating on thread 1, and the encoder can begin encoding data for thread 2 while interleaving and rate matching for thread 1 are still in progress. As long as the threads use different buffer locations to store data, they do not need to interfere with each other.

[0099] As shown in this example, by tracking read lock requests and write lock requests from processing engines in the pipeline, and by granting or denying polling requests from processing engines based on the presence or absence of earlier read locks and / or write locks, the interlock controller 1130 can prevent downstream processing engines from operating on data that is not yet ready to be operated on, while allowing the processing engines to operate once both the processing engines and the input data are ready. The interlock controller 1130 can achieve this while remaining agnostic about how many processing engines are in the pipeline 1110, what operations are being performed, or how long a given operation may take.

[0100] It should also be noted that the control processor 1140 may be agnostic to the operation of the interlock controller 1130. For example, the program code executed by the control processor 1140 need not include any instructions regarding read locks, write locks, or polling; as long as the input and output addresses are appropriately specified, the hardware in the pipeline automatically produces the desired behavior. The control processor 1140 may also schedule instructions to the pipeline 1140 sequentially without determining whether the instructions are ready for execution. If one or more scheduling queues in the pipeline 1140 fills to capacity, backpressure can be used to pause instruction scheduling by the control processor 1140. The control processor 1140 may also be agnostic to how the various functional units that execute instructions are assigned to the processing engines. For example, the pipeline 1110 may include routing logic that routes each instruction from the control processor 1140 to the scheduling queue of the specific processing engine that can execute the instruction.

[0101] Therefore, the same data synchronization circuit can be applied to any processing pipeline. By way of example, Figure 13A simplified block diagram of a different data processing pipeline, decoding pipeline 1310, according to some embodiments is shown. Decoding pipeline 1310 may be another example of pipeline 310 described above. In this example, it is assumed that decoding pipeline 1310 operates on data received via the PDSCH channel of a 4G radio access network. Vector load engine 1321 and vector storage engine 1324 may be similar to or identical to vector load engine 321 and vector storage engine 324 described above. Vector load engine 1321 may write data read from L1 memory to deinterleaver buffer 1316. Processing engine 1322 may perform deinterleaving and rate recovery. For example, processing engine 1322 may perform deinterleaving by reading data from deinterleaver buffer 1316; if data is written row by row, processing engine 1322 may read data column by column. Rate recovery may be performed by identifying repeated portions of data and combining log-likelihood ratios corresponding to identical data bits. Processing engine 1323 may implement a decoder algorithm for the PDSCH. For example, processing engine 1323 may include a functional unit that implements a turbo decoder for a 4G PDSCH channel. Pipeline 1310 may also include a shared buffer 1314 accessible to processing engines 1322-1324. Control processor 1340 and interlock controller 1330 may be similar to or identical to control processor 340 and interlock controller 330.

[0102] As with pipeline 1110, the operation of pipeline 1310 may be defined using program code (e.g., firmware) executed by control processor 1340. The specific functions and sequences are different because the decoding process is, in a sense, the reverse of the encoding process. The amount of time a functional unit in pipeline 1310 takes to complete an operation may be different than the amount of time a corresponding functional unit in pipeline 1110 takes to complete an operation. For example, for a given code block size, the time to decode may be longer than the time to encode. However, data synchronization or flow control may be handled in exactly the same manner. Control processor 1340 may issue instructions to pipeline 1310 in sequence, and each instruction may enter the dispatch queue of the appropriate processing engine in processing engines 1321-1324. Instructions may specify virtual addresses in the virtual address space of pipeline 1310, which encompass locations in buffers 1314 and 1316. As described above with reference to Figure 6 and Figure 7As described above, receiving an instruction in the dispatch queue interface may trigger the sending of a read lock request and / or a write lock request to the interlock controller 1330, and completing an instruction (or a read operation or a write operation) may trigger the sending of a clear request to the interlock controller 1330. As also described above, before reading or writing, each processing engine may poll the interlock controller with the virtual address to be read or written, and may do so upon receiving an authorization response from the interlock controller 1330. The interlock controller 1330 may implement the same logic described above to respond to the read lock request, the write lock request, the clear request, and the poll request. Therefore, data synchronization within the pipeline may be agnostic to the specific processing activity within the pipeline.

[0103] It should be understood that multiple pipelines, including pipelines implementing different functions, can coexist in the same cellular modem processor. Each pipeline can have its own processing engine, its own buffer, its own interlock controller and virtual register file, and its own virtual address space. For example, the control processor can dispatch instructions to one pipeline to perform OFDM demapping for a received 4G transmit block, and then dispatch instructions to pipeline 1310 to decode the transmit block. Alternatively, some or all of the pipelines can have their own dedicated control processor (which can allow more pipelines to operate in parallel). In the case of sub-pipelines within a processing engine, instruction execution within the sub-pipeline can be hardware-driven (e.g., a functional unit in the sub-pipeline triggers the execution of the next instruction at the appropriate time). Alternatively, if desired, a programmable sub-pipeline control processor can be implemented within the processing engine to execute firmware-defined instruction sequences in the sub-pipeline. In each pipeline, data synchronization may be provided using a combination of firmware-based control (e.g., via control processors 340, 1140, 1340) and hardware-based dependency management (e.g., via interlock controllers 330, 1130, 1330) as described herein.

[0104] Those skilled in the art who have access to this disclosure will appreciate that pipelined data synchronization using a combination of firmware-based control and hardware-based dependency management as described herein may provide various advantages over other methods for flow control or data synchronization.

[0105] For example, to implement purely hardware-based flow control, system designers model each processing engine as a state machine, and the possible state sequences depend on the possible pairs of processing engines (or functional units) that can perform consecutive operations on the same block of data and the time each operation might take. In a pipeline with several processing engines, each with several possible states, the number of state combinations can become large, making it difficult to verify the correct operation of the pipeline under all possible conditions. For firmware-based flow control, the hardware state machine can be simplified, but the firmware developer needs to consider the possible states and sequences of states and incorporate exception and event handling into the program code.

[0106] In contrast, in the various embodiments described herein, each processing engine operates according to a simple state machine: if all data dependencies for the next instruction are met, then proceed; if not, then wait. The same state machine applies to each processing engine (or functional unit) in the pipeline. The simplification of the state machine can simplify the verification of the hardware. Likewise, firmware developers do not have to grapple with complex state machines; firmware developers can simply write program code that expresses the expected data flow. For example, in order for processing engine 323 to operate on data output from processing engine 322, the developer can encode an instruction that can be executed by processing engine 322 to write to a given address, and then encode an instruction that can be executed by processing engine 323 to read from that address. Developers can write such code almost intuitively without having to know the details of the hardware (including which processing engines execute which instructions).

[0107] Some embodiments may also offer the advantage of flexibility. For example, adapting hardware-based flow control to changes in processing algorithms can be difficult and often requires new circuitry. In contrast, in the embodiments described herein, at least some changes to the algorithms can be implemented simply by updating firmware. For example, if a new code block size is added to an existing encoder solution, the firmware can be updated to provide parameters for the new code block size. The new code block size can change the amount of time required for a processing engine to complete encoding (or decoding); however, the same simple state machine can still be applied if a downstream processing engine (or functional unit) waits until an upstream processing engine (or functional unit) has completed encoding (or decoding).

[0108] In addition, some embodiments described herein provide a unified (or universal) data synchronization architecture. The interlock controller design and operation are not specific to any particular processing engine or functional unit, or to any particular combination of processing engines and functional units. The interlock controller may be agnostic about how the virtual address space is mapped to physical memory (e.g., the buffers described above); instead, the virtual address is simply used as an indicator of data dependencies. Furthermore, the decision logic in the interlock controller can operate independently of any processing engine (e.g., which functional units are in a particular processing engine) or any specific function of the pipeline. Data dependencies are defined based on the order in which instructions are scheduled and the input and output address information contained in the instructions, and the same decision logic for determining whether data dependencies have been satisfied can be applied regardless of the amount of data, the specific operations performed on the data, or the location where the data is physically stored. Therefore, there is no need to design an interlock controller separately for each pipeline. In some embodiments, an instance of the same interlock controller circuit can be deployed for each instance of each pipeline in the processor, where the only difference between the interlock controller instances is the number of pipeline stages from which the interlock controller receives requests. This can greatly simplify the implementation of flow control in a processor with multiple distinct pipelines, such as a cellular modem processor.

[0109] While specific embodiments have been described, those skilled in the art will appreciate that variations and modifications are possible. For example, a cellular modem processor may include any number of pipelines and any combination of pipelines and may support any number of radio access networks, including 4G and / or 5G. Each pipeline may have its own control processor, or one control processor may be configured to dispatch instructions to multiple pipelines as desired. A pipeline may include any number of processing engines, and the allocation of specific operations (or functional units) to processing engines may be modified as desired. A processing engine or functional unit may be a vector engine that performs the same operation on multiple inputs in parallel. Buffers between pipeline stages may be implemented using any type of memory circuit and may include any combination of dedicated buffers (where only one processing engine writes and only one processing engine reads) and shared buffers (where multiple processing engines can read and / or write). The interlock controller may use various techniques to track data dependencies. The virtual address space used by the interlock controller can use various addressing schemes, provided that different virtual addresses map to different physical buffer (or other memory) locations and that virtual addresses can be defined at any desired level of granularity (e.g., words, lines, buffers, etc.). Instructions scheduled to the pipeline can specify virtual addresses for the interlock controller directly (e.g., input virtual addresses and output virtual addresses can be operands of the scheduled instructions) or indirectly (e.g., operands of the scheduled instructions can include addresses in any address space that a dispatch queue interface in the processing engine can map to the virtual address space used by the interlock controller). The examples of the processes implemented in the firmware and the specific firmware instructions provided herein are also illustrative. Where names are used for specific functional units or instructions, such names are for ease of description and are not intended to limit or imply any particular ISA.

[0110] All processes described herein are illustrative and can be modified. Operations can be performed in a different order than described, as far as logic allows; operations described above can be omitted or combined; and operations not explicitly described above can be added.

[0111] Unless explicitly indicated, the drawings are schematic in nature and are not drawn to scale. All numerical values presented herein are illustrative and non-limiting. References to specific standards for cellular data communications (e.g., 4G LTE or 5G NR) are also for illustrative purposes; those skilled in the art having access to this disclosure will be able to adapt the devices and methods described herein to be compatible with other standards.

[0112] This disclosure includes references to "an embodiment" or groups of "embodiments" (e.g., "some embodiments" or "various embodiments"). An embodiment is different specific implementations or examples of the disclosed concepts. References to "an embodiment," "one embodiment," "a specific embodiment," etc., are not necessarily to the same embodiment. Numerous possible embodiments are contemplated, including those specifically disclosed, as well as modifications or alternatives that fall within the spirit or scope of this disclosure.

[0113] This disclosure may discuss potential advantages that may result from the disclosed embodiments. Not all implementations of these embodiments will necessarily exhibit any or all of the potential advantages. Whether a particular implementation achieves an advantage depends on many factors, some of which are outside the scope of this disclosure. Indeed, there are many reasons why an implementation falling within the scope of a claim may not exhibit some or all of the disclosed advantages. For example, a particular implementation may include additional circuitry outside the scope of this disclosure that, in combination with one of the disclosed embodiments, negates or mitigates one or more of the disclosed advantages. Furthermore, suboptimal design implementation of a particular implementation (e.g., a specific implementation technique or tool) may also negate or mitigate the disclosed advantages. Even assuming a specific implementation of the technique, the realization of an advantage may still depend on other factors, such as the environmental circumstances in which the implementation is deployed. For example, the inputs provided to a particular implementation may prevent one or more problems addressed in this disclosure from occurring in a particular situation, and as a result, the benefits of its solution may not be realized. Given the existence of possible factors external to this disclosure, any potential advantages described herein should not be construed as claim limitations that must be met in order to prove infringement. Rather, the identification of such potential advantages is intended to illustrate one or more types of improvements available to designers who benefit from this disclosure. Permanently describing such advantages (e.g., stating that a particular advantage "may occur" or "might occur") is not intended to convey a question as to whether such advantage can actually be achieved, but rather a recognition that achievement of such advantage often depends on technical realities of additional factors.

[0114] Unless otherwise indicated, the embodiments are non-restrictive. That is, the disclosed embodiments are not intended to limit the scope of claims drafted based on this disclosure, even when only a single example is described for a particular feature. The embodiments disclosed in the present invention are intended to be illustrative and not restrictive, and no contrary statement is required in the present invention. Therefore, this application is intended to allow claims covering the disclosed embodiments, as well as such alternatives, modifications, and equivalents, which will be apparent to those skilled in the art who are aware of the effective effects of this disclosure.

[0115] For example, features in this application may be combined in any suitable manner. Accordingly, new claims may be formulated during the prosecution of this patent application (or a patent application claiming priority thereto) directed to any such combination of features. In particular, with reference to the appended claims, features of dependent claims may, where appropriate, be combined with features of other dependent claims, including claims that are dependent on other independent claims. Similarly, features from corresponding independent claims may, where appropriate, be combined.

[0116] Thus, while the appended dependent claims may be drafted such that each dependent claim is dependent upon a single other claim, additional dependencies are also contemplated. Any combination of dependent claims consistent with the present disclosure is contemplated and may be claimed in this or another patent application. In short, the combinations are not limited to those specifically recited in the appended claims.

[0117] It is also contemplated that claims drafted in one format or legal type (eg, apparatus) are intended to support corresponding claims in another format or legal type (eg, method), where appropriate.

[0118] ***

[0119] Because this disclosure is a legal document, various terms and phrases may be subject to regulatory and judicial interpretation. Notice is hereby given that the definitions provided in the following paragraphs and throughout this disclosure will be used to determine how claims drafted based on this disclosure are to be interpreted.

[0120] Unless the context clearly dictates otherwise, reference to an item in the singular (i.e., a noun or noun phrase preceded by "a," "an," or "the") is intended to mean "one or more." Thus, reference to "an item" in a claim, without accompanying context, does not exclude additional instances of that item. A "plurality" of an item refers to a collection of two or more items.

[0121] The word "may" is used herein in a permissive sense (i.e., having the potential to, being able to), rather than in a mandatory sense (i.e., must). The word "could" is used herein in the same permissive sense (i.e., having the potential to, being able to).

[0122] The terms "include" and "including" and their forms are open ended and mean "including, but not limited to."

[0123] When the term "or" is used in this disclosure with respect to a list of options, unless the context provides otherwise, it will generally be understood to be used in an inclusive sense. Thus, the expression "x or y" is equivalent to "x or y, or both," thus encompassing 1) x but not y, 2) y but not x, and 3) both x and y. On the other hand, phrases such as "either, but not both, x or y" make it clear that "or" is used in an exclusive sense.

[0124] The expression "w, x, y, or z, or any combination thereof" or "... at least one of w, x, y, and z" is intended to encompass all possibilities involving individual elements up to the total number of elements in the set. For example, given the set {w, x, y, z}, these phrases encompass any single element in the set (e.g., w but not x, y, or z), any two elements (e.g., w and x, but not y or z), any three elements (e.g., w, x, and y, but not z), and all four elements. The phrase "... at least one of w, x, y, and z" thus refers to at least one element in the set {w, x, y, z}, thereby encompassing all possible combinations in that list of elements. The phrase should not be interpreted as requiring the presence of at least one instance of w, at least one instance of x, at least one instance of y, and at least one instance of z.

[0125] In this disclosure, various "labels" may precede a noun or noun phrase. Unless the context provides otherwise, different labels used for a feature (e.g., "first circuit," "second circuit," "particular circuit," "given circuit," etc.) refer to different instances of the feature. Furthermore, unless otherwise specified, the labels "first," "second," and "third" do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) when applied to features.

[0126] The phrase "based on" is used to describe one or more factors that influence a determination. This term does not exclude that there may be additional factors that may influence the determination. That is, a determination may be based solely on the specified factors or on the specified factors and other unspecified factors. Consider the phrase "A is determined based on B." This phrase specifies that B is a factor used to determine A or that B influences the determination of A. This phrase does not exclude that the determination of A may also be based on some other factor, such as C. This phrase is also intended to cover embodiments in which A is determined solely based on B. As used herein, the phrase "based on" is synonymous with the phrase "based at least in part on."

[0127] The phrases "in response to" and "in response to" describe one or more factors that trigger an effect. The phrases do not exclude the possibility that additional factors may influence or otherwise trigger the effect, either in conjunction with or independent of the specified factors. That is, the effect may be responsive only to these factors, or may be responsive to the specified factors as well as other unspecified factors. Consider the phrase "in response to B, A is performed." The phrase specifies that B is the factor that triggers the performance of A or triggers a particular result of A. The phrase does not exclude that the performance of A may also be responsive to some other factor, such as C. The phrase also does not exclude that the performance of A may be performed in response to B and C in conjunction. This phrase is also intended to cover embodiments in which A is performed only in response to B. As used herein, the phrase "in response to" is synonymous with the phrase "at least partially in response to." Similarly, the phrase "in response to" is synonymous with the phrase "at least partially in response to."

[0128] ***

[0129] Within this disclosure, different entities (which may be variously referred to as "units," "circuits," other components, etc.) may be described or claimed as being "configured to" perform one or more tasks or operations. This expression—an entity configured to perform one or more tasks—is used herein to refer to a structure (i.e., a physical thing). More specifically, the expression is used to indicate that the structure is arranged to perform one or more tasks during operation. A structure may be said to be "configured to" perform certain tasks even if the structure is not currently being operated. Thus, an entity described or recited as "configured to" perform certain tasks refers to a physical thing, such as a device, a circuit, a system having a processor unit and a memory storing program instructions executable to perform the task, etc. The phrase is not used herein to refer to an intangible thing.

[0130] In some cases, various units / circuits / components may be described herein as performing a set of tasks or operations. It should be understood that these entities are "configured to" perform those tasks / operations, even if not specifically stated.

[0131] The term "configured to" is not intended to mean "configurable to." For example, an unprogrammed FPGA would not be considered "configured to" perform a particular function. However, the unprogrammed FPGA could be "configurable to" perform that function. After being appropriately programmed, the FPGA could then be considered "configured to" perform the particular function.

[0132] For purposes of a U.S. patent application based on the present disclosure, stating in a claim that a structure is “configured to” perform one or more tasks is expressly intended not to invoke 35 U.S.C. §112(f) for that claim element. If an applicant desires to invoke section 112(f) during prosecution of a U.S. patent application based on the present disclosure, the applicant would use the “means for [performing the function]” construct to recite the claim element.

[0133] Different “circuits” may be described in this disclosure. These circuits or “circuitry” constitute hardware that includes various types of circuit elements, such as combinational logic, clock storage devices (e.g., flip-flops, registers, latches, etc.), finite state machines, memories (e.g., random access memory, embedded dynamic random access memory), programmable logic arrays, etc. Circuits may be custom designed or taken from standard libraries. In various specific implementations, circuits may include digital components, analog components, or a combination of both, as appropriate. Certain types of circuits may be generally referred to as “units” (e.g., decoding units, arithmetic logic units (ALUs), functional units, memory management units (MMUs), etc.). Such units are also referred to as circuits or circuits.

[0134] Thus, the disclosed circuits / units / components and other elements shown in the accompanying drawings and described herein include hardware elements, such as those described in the preceding paragraphs. In many cases, the internal arrangement of hardware elements in a particular circuit can be specified by describing the functionality of that circuit. For example, a particular "decode unit" may be described as performing the function of "processing an instruction's opcode and routing that instruction to one or more of a plurality of functional units," meaning that the decode unit is "configured to" perform that function. For one skilled in the computer arts, this functional specification is sufficient to suggest a set of possible architectures for the circuit.

[0135] In various embodiments, as described in the preceding paragraphs, circuits, units, and other elements may be defined by the functions or operations they are configured to implement. The arrangement of such circuits / units / components relative to one another and the manner in which they interact form a microarchitecture definition of the hardware that is ultimately manufactured in an integrated circuit or programmed into an FPGA to form a physical implementation of the microarchitecture definition. Thus, a microarchitecture definition is considered by those skilled in the art to be a structure from which many physical implementations can be derived, all of which fall within the broader structure described by the microarchitecture definition. That is, a technician with a microarchitecture definition provided in accordance with the present disclosure can, without undue experimentation and with the application of ordinary skill, implement the structure by coding a description of the circuits / units / components in a hardware description language (HDL) such as Verilog or VHDL. HDL descriptions are often expressed in a manner that can be rendered as functional. However, for those skilled in the art, the HDL description is a means for converting the structure of a circuit, unit, or component into the next level of implementation details. Such HDL descriptions may take the form of behavioral code (which is generally non-synthesizable), register transfer language (RTL) code (which is generally synthesizable compared to behavioral code), or structural code (e.g., a netlist specifying logic gates and their connectivity). The HDL description may be sequentially synthesized against a library of cells designed for a given integrated circuit manufacturing technology and may be modified for timing, power, and other reasons to obtain a final design database that is transmitted to the factory to generate masks and ultimately produce the integrated circuit. Some hardware circuits or portions thereof may also be custom designed in the schematic editor and captured into the integrated circuit design along with the synthesized circuits. The integrated circuit may include transistors and other circuit elements (e.g., passive elements such as capacitors, resistors, inductors, etc.), as well as interconnects between the transistors and circuit elements. Some embodiments may implement multiple integrated circuits coupled together to implement the hardware circuit, and / or discrete elements may be used in some embodiments. Alternatively, the HDL design may be synthesized into a programmable logic array such as a field programmable gate array (FPGA) and implemented in the FPGA. This decoupling between the design of a set of circuits and the subsequent low-level implementation of those circuits often leads to situations where the circuit or logic designer never specifies a specific set of structures for the low-level implementation beyond a description of what the circuits are configured to do, because that process is performed at a different stage in the circuit implementation process.

[0136] The fact that many different low-level combinations of circuit elements can be used to achieve the same specifications of a circuit results in a large number of equivalent structures for that circuit. As noted, these low-level circuit implementations can vary depending on variations in manufacturing technology, the foundry chosen to manufacture the integrated circuit, the cell libraries available for a particular project, and so on. In many cases, the selection made by different design tools or methodologies to produce these different implementations can be arbitrary.

[0137] Furthermore, for a given embodiment, a single implementation of a particular functional specification of a circuit typically includes a large number of devices (e.g., millions of transistors). Consequently, the shear volume of this information makes it impractical to provide a complete description of the low-level structure used to implement a single embodiment, let alone the large number of equivalent possible implementations. For this reason, the present disclosure describes the structure of the circuit using functional shorthand commonly used in the industry.

[0138] Various embodiments may use computer program code to implement various features. Any such program code may be encoded and stored on various computer-readable storage media; suitable media include disks or tapes, optical storage media such as compact discs (CDs) or DVDs (digital versatile discs), flash memories, and other non-transient media. (It should be understood that the "storage" of data is different from the propagation of data using transient media such as carrier waves.) A computer-readable medium encoded with program code may include an internal storage medium of a compatible electronic device and / or an external storage medium that can be read by an electronic device that can execute the code, which may be any electronic device with the ability to read and execute program code. In some cases, program code may be supplied to an electronic device via internet download or other transmission paths.

[0139] Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to encompass all such variations and modifications.

Claims

1. A processing system comprising: a buffer memory having an associated address space; a plurality of processing engines configured to receive instructions and perform operations in response to the instructions, wherein performing at least some of the operations includes reading input data from input addresses in the buffer memory and writing output data to output addresses in the buffer memory, wherein the plurality of processing engines includes a first processing engine configured to perform a first operation to generate first output data and a second processing engine configured to perform a second operation on the first output data; and a controller coupled to the plurality of processing engines, the controller comprising: an interface circuit configured to receive requests specifying addresses in the address space from the plurality of processing engines and to send responses to the plurality of processing engines, wherein the requests include at least one of a lock request, a clear request, or a poll request; a virtual register file to store at least one list for different addresses in the address space, wherein the at least one list includes an entry identifying a processing engine that has requested a lock and whether the requested lock is a read lock or a write lock; register update logic configured to update one or more of the stored lists in response to a received lock request or clear request; and Decision logic circuitry is configured to determine whether to send an authorization response in response to a polling request specifying an address, wherein the determination is based on a stored list for the address specified in the polling request.

2. The processing system of claim 1 , wherein the plurality of processing engines comprises: a dispatch queue interface configured to: receive an instruction having an input address and an output address, and in response to receiving the instruction, send a read lock request for the input address and a write lock request for the output address to the controller; a dispatch queue configured to receive instructions from the dispatch queue interface and store the instructions for in-order execution; and An instruction interface is configured to: send a polling request for an input address and an output address of the oldest instruction in the scheduling queue to the controller, and in response to receiving an authorization response from the controller, initiate execution by the processing engine of an operation corresponding to the oldest instruction.

3. The processing system according to claim 2, wherein the instruction interface is configured to: after writing output data generated by executing an operation corresponding to the instruction into the buffer memory, send a clear request for the input address and the output address of the oldest instruction to the controller.

4. The processing system of claim 1 , wherein the plurality of processing engines comprises: a dispatch queue interface configured to: receive an instruction having an input address and an output address, and in response to receiving the instruction, send a read lock request for the input address to the controller and send a write lock request for the output address to the controller; a dispatch queue configured to receive instructions from the dispatch queue interface and store the instructions for in-order execution; and A command interface, wherein the command interface is configured to: sending a first polling request for an input address of an oldest instruction in the dispatch queue to the controller, wherein sending the first polling request is repeated until a first grant response is received from the controller; In response to receiving the first authorization response from the controller, initiating execution by the processing engine of an operation corresponding to the oldest instruction; sending a second polling request for the output address of the oldest instruction to the controller, wherein sending the second polling request is repeated until a second authorization response is received from the controller; as well as In response to receiving the second grant response from the controller, writing output data generated by executing the operation corresponding to the oldest instruction back to the buffer memory is initiated.

5. The processing system of claim 4 , wherein the instruction interface is further configured to: in response to completion of executing the operation corresponding to the oldest instruction, send a first clear request for the input address of the oldest instruction to the controller; and in response to completion of writing back output data generated by executing the operation corresponding to the oldest instruction, send a second clear request for the output address of the oldest instruction to the controller.

6. The processing system of claim 1 , further comprising a control processor coupled to the plurality of processing engines and configured to dispatch instructions to the plurality of processing engines in sequence, wherein at least some of the instructions specify input addresses and output addresses in the address space of the buffer memory.

7. The processing system of claim 1 , wherein the register update logic circuit is further configured to add entries to one or more of the stored lists in response to a lock request and remove entries from one or more of the stored lists in response to a purge request.

8. A processor comprising: A plurality of processing pipelines, the plurality of processing pipelines including a first processing pipeline, wherein the first processing pipeline includes: a buffer memory local to the first processing pipeline, wherein locations in the buffer memory are mapped to addresses in an address space; a plurality of processing engines configured to receive instructions and perform operations in response to the instructions, wherein performing the operations comprises reading input data from input addresses in the buffer memory and writing output data to output addresses in the buffer memory, wherein the plurality of processing engines comprises a first processing engine configured to perform a first operation to generate first output data and a second processing engine configured to perform a second operation on the first output data to generate second output data; and a controller coupled to the plurality of processing engines, the controller comprising: an interface circuit configured to receive requests specifying addresses in the address space from the plurality of processing engines and to send responses to the plurality of processing engines, wherein the requests include lock requests, clear requests, and polling requests; a virtual register file to store at least one list for different addresses in the address space, wherein the at least one list includes an entry identifying a processing engine that has requested a lock and whether the requested lock is a read lock or a write lock; register update logic configured to update the stored list in response to a received lock request or a clear request; and Decision logic circuitry is configured to determine whether to send an authorization response in response to a polling request for a specified address, wherein the determination is based on a stored list for the address specified in the polling request, wherein at least two of the plurality of processing pipelines implement different data processing operations.

9. The processor of claim 8, wherein at least one of the plurality of processing pipelines operates on data to be transmitted via a cellular radio access network, and at least one other of the plurality of processing pipelines operates on data received via the cellular radio access network.

10. The processor of claim 8, further comprising: A shared memory circuit is coupled to at least two processing pipelines of the plurality of processing pipelines.

11. The processor of claim 10, wherein the plurality of processing engines in the first processing pipeline comprises: a load processing engine comprising circuitry configured to read data from the shared memory circuitry and write the data to an output location in the buffer memory local to the first processing pipeline; and A storage processing engine includes circuitry configured to read input data from input locations in the buffer memory local to the first processing pipeline and write the data to the shared memory circuitry.

12. The processor of claim 11, wherein the address space further comprises virtual addresses for locations in the shared memory circuit.

13. The processor of claim 8 , further comprising a control processor coupled to a plurality of processing engines of one or more of the plurality of processing pipelines and configured to dispatch instructions to the plurality of processing engines in sequence, wherein at least some of the instructions specify an input address range and an output address range in the address space of the buffer memory.

14. A method performed in a processing pipeline having a plurality of simultaneously operating processing engines coupled to a controller, the method comprising: By the controller: receiving, from the plurality of processing engines, a read lock request, a write lock request, and a request to clear a read lock and a write lock specifying an address in an address space; In response to each received read lock request, write lock request, or request to clear a read lock or write lock, updating the stored list for the specified address; receiving a polling request from one of the plurality of processing engines, the polling request identifying a polled address and indicating a read operation or a write operation; determining whether the polled address clears data dependencies based on the polled address, the indicated read operation or write operation, and the stored list for the polled address; as well as A response to the polling request is sent to the one of the plurality of processing engines, wherein the response is a grant response when the polled address clears data dependencies and the response is a rejection response when the polled address does not clear data dependencies.

15. The method of claim 14, wherein determining whether the polled address clears data dependencies comprises: when the polling request indicates a read operation, determining whether any write lock for the polled address precedes a read lock for the polled address requested by the one of the plurality of processing engines from which the polling request is received; as well as When the polling request indicates a write operation: determining whether any write lock for the polled address precedes a write lock for the polled address requested by the one of the plurality of processing engines, wherein the polling request is received from the one processing engine; as well as A determination is made as to whether any read lock for the polled address precedes the write lock for the polled address requested by the one of the plurality of processing engines, wherein the polling request is received from the one processing engine.

16. The method of claim 14 , wherein the plurality of processing engines receive instructions from a control processor in sequence, wherein the instructions specify addresses in the address space, and wherein the plurality of processing engines send the read lock request, the write lock request, and the request to clear the read lock and the write lock using the addresses specified in the instructions.

17. The method of claim 14, wherein a separate stored list is maintained for each of a plurality of different address ranges within the address space.

Images