Apparatus, method and system for supporting synchronized data streams with identification of executable tasks

Abstract

Devices, methods, and systems are disclosed for supporting synchronized data streams with identifications of executable tasks. Techniques and mechanisms for identifying a next task to perform for an application modeled with a Synchronization Data Flow (SDF) graph. In embodiments, the SDF graph includes nodes that each represent a different respective task, where the nodes exchange tokens representing data for application operations in various ways via channels. Manager circuitry manages and provides access to a schedule register, the schedule register providing state information at a node-specific granularity level. For a given node, a corresponding scheduling register provides a state parameter that identifies whether the given node is currently eligible to be executed. The state parameter is based on one or more channel registers that each provide state information at a channel-specific granularity level. In another embodiment, a processor includes circuitry to send a request to manager circuitry to identify a next task to be performed based on a schedule register.

Description

Related applications

[0001] This patent application relates to U.S. Patent Application Serial No. 18 / 345,280, filed June 30, 2023, entitled "HARDWARE ACCELERATION FOR DATA-DRIVEN MULTI-CORE SIGNAL PROCESSING SYSTEMS", and U.S. Patent Application Serial No. 17 / 958,108, filed September 30, 2022, entitled "TECHNIQUES TO REDUCE POWER CONSUMPTION FOR ADISTRIBUTED COMPUTATIONAL MODEL MAPPED ONTO A MULTI-PROCESSING NODE SYSTEM", which have been assigned to the assignee of the subject matter hereof and are incorporated herein by reference. background 1. Technical Field

[0002] This disclosure generally relates to synchronous data streaming systems, and more specifically, but not exclusively, to marking tasks as ready for execution. 2. Background Technology

[0003] A synchronous data flow (SDF) graph is a special case of the Kahn process network (KPN) used to describe signal processing systems that use processes (e.g., processing nodes) connected to each other via unbounded first-in-first-out (FIFO) communication channels (arcs) to transform data flows. Typically, writes routed via the communication channels modeled in the SDF graph are non-blocking, while reads from the communication channels are blocking. For example, if a processing node needs data from one or more previous processing nodes and the communication channel is empty, a process or workload will typically remain blocked until the required amount of data (e.g., one or more tokens) becomes available on the communication channel. For a communication channel, the FIFO can only be read by a single processing node, and multiple processing nodes are not allowed to write to a single FIFO. Processes or workloads modeled into the SDF graph need to be deterministic for the data flow. For example, each processing node is configured to produce the same amount of data (e.g., one or more tokens), regardless of the amount of input data. Attached Figure Description

[0004] Various embodiments of the invention are illustrated in the accompanying drawings by way of example and not by way of limitation, in which:

[0005] Figure 1 The figure shows a block diagram of a computer system including a processor according to an embodiment, the processor having a core with synchronous data stream (SDF) circuitry and an SDF manager.

[0006] Figure 2 A flowchart illustrating features of a method for identifying an executable task using an SDF circuit, according to an embodiment, is shown.

[0007] Figure 3 The figure shows a block diagram of a memory partitioned into data stream buffers for hierarchical blocks of SDF data, according to an embodiment.

[0008] Figure 4 The diagram illustrates a task according to an embodiment, a corresponding application diagram for that task, and a computing system including SDF functional circuitry and SDF manager circuitry to implement the corresponding application diagram.

[0009] Figure 5 The figure shows a block diagram of the SDF manager circuit according to an embodiment.

[0010] Figure 6 The figure illustrates an example format of address decomposition and task identifier at the protocol interface (PI) of the SDF manager according to an embodiment.

[0011] Figure 7 The figure illustrates the information command encoding for communication between the SDF functional circuit (SDFFC) and the SDF manager according to an embodiment.

[0012] Figure 8 The figure illustrates an example channel register for an SDF manager for a single channel according to an embodiment.

[0013] Figure 9 A tabular diagram illustrating the features of a scheduling register for a single task, according to an embodiment, is shown.

[0014] Figure 10 The figure illustrates a state machine for providing state transitions for a task, according to one embodiment.

[0015] Figure 11 The figure illustrates the input and output ports of the SDFFC according to an embodiment.

[0016] Figure 12 The figure illustrates an exemplary system.

[0017] Figure 13The diagram shows a block diagram of an example processor that may have more than one core and may have an integrated memory controller.

[0018] Figure 14A This is a block diagram illustrating both an exemplary ordered pipeline and an exemplary register renaming, out-of-order issue / execution pipeline, based on the example.

[0019] Figure 14B This is a block diagram illustrating both an exemplary example of an ordered architecture core to be included in a processor and an exemplary register renaming, out-of-order issue / execution architecture core, based on the example.

[0020] Figure 15 The diagram illustrates an example of one or more execution unit circuit systems.

[0021] Figure 16 It is a block diagram of a register architecture based on some examples. Detailed Implementation

[0022] The embodiments discussed herein provide techniques and mechanisms for tasks of an application in various ways, wherein such an application is represented by a synchronous data flow (SDF) graph to be identified as currently eligible to become the next task to be performed.

[0023] Multi-core digital signal processing is an example of a technology that largely benefits from data-driven multi-core communication and synchronization mechanisms, such as those conceptually represented using the Synchronous Data Flow (SDF) model. In this model, the application is described as a node graph that consumes and produces data, where such data is abstracted as tokens spanning node input and output terminals connected via directed arcs. Nodes self-schedule and synchronize based on the availability of sufficient tokens on each input terminal of a given node and the availability of sufficient token space on each output terminal of that node. This availability condition is called the “SDF firing rule” for the node. Achieving synchronization consistent with this firing rule requires a protocol, which we call the SDF protocol. While the SDF protocol itself is kept as simple as possible, the overhead of fully implementing the protocol in software (SW) or firmware (FW) running on an embedded programmable processor becomes prohibitive for high-performance, high-throughput digital signal processing workloads. An example of such workloads is the digital front-end (DFE) processing workload for software-defined radios.

[0024] Some embodiments facilitate the execution of applications that leverage SDF graph modeling in various ways by efficiently identifying graph nodes as eligible for execution (e.g., when a node is identified as the next node to be executed). In some cases (e.g., when the number of nodes to be scheduled on a given processor is relatively large, and / or when the required scheduling rates of the nodes differ from one another), the identification of the next task to be executed tends to be associated with excessive overhead.

[0025] To mitigate the impact of this overhead, some embodiments enable agents (e.g., implemented using execution software) to explicitly request the SDF management circuitry (referred to herein as the "SDF manager") to identify the next eligible node in various ways. As used herein, the term "eligible node" refers to a node that currently satisfies the corresponding SDF triggering rules, and the term "next eligible node" refers to an eligible node that has been scheduled (or will be scheduled) as the next node to be executed.

[0026] For example, some embodiments support at least one type of request (referred to herein as a “node identification request” or “task identification request”) in various ways for the SDF manager to evaluate the state of some or all nodes in a given SDF graph to determine which nodes(s), if present, currently satisfy their respective SDF activation rules and are thus eligible to be executed. In the event that multiple eligible nodes are detected, the SDF manager is used to select one such eligible node and to identify the selected node as the next eligible node in its response to the node identification request. In this particular context, it should be understood that (unless otherwise stated) the term “node identification” as used herein is equivalent to “task identification”—for example, at least to the extent that identifying a particular node in the SDF graph also identifies the task represented by that node.

[0027] In various embodiments, the SDF manager and the request broker communicating with the SDF manager support protocols that include one or more types (e.g., two types) of node identification requests (and responses to said node identification requests). These two types are adapted in various ways to whether the operation of the request broker (or the operation of some other resource associated with the request broker) should be blocked until the next eligible node is identified; to this extent, these two types are referred to herein as “blocking” and “non-blocking”.

[0028] In some embodiments, the SDF manager performs node identification in a blocking mode by sending a response to the node identification request only after the SDF manager has identified the next eligible node based on the node identification request. For example, the SDF manager does not send any response to the requester agent informing them that no node is currently eligible. This blocking mode helps the requester agent and / or other resources to stop, slow down, or otherwise reduce operations (e.g., to save power) until the SDF node becomes eligible to be identified.

[0029] Alternatively or additionally, the SDF manager performs node identification in non-blocking mode by sending a response to the node identification request regardless of whether the SDF manager has already identified the next eligible node based on the node identification request. For example, under certain conditions, the SDF manager sends a response to the requesting agent conveying that no node is currently eligible. In one such embodiment, an additional response is automatically sent once the SDF node is eligible to be identified.

[0030] In some embodiments, the SDF manager hardware selects one eligible node from a plurality of currently eligible nodes as the next node to be executed. For example, this selection is performed based on the relative priorities of some or all nodes relative to each other. In embodiments, node priorities are configured in various ways during the initialization of the multiprocessor system—for example, some or all such priorities may be increased or decreased in various ways during runtime execution using the multiprocessor system. Accordingly, some embodiments utilize circuit hardware to accelerate SDF management functions by improving the efficiency of execution scheduling.

[0031] The techniques described herein can be implemented in one or more electronic devices. Non-limiting examples of electronic devices that can utilize the techniques described herein include any kind of mobile and / or fixed equipment, such as cameras, cellular phones, computer terminals, desktop computers, e-readers, fax machines, automated service machines, laptops, netbooks, notebook computers, internet devices, payment terminals, personal digital assistants, media players and / or recorders, servers (e.g., blade servers, rack-mounted servers, combinations thereof), set-top boxes, smartphones, tablet PCs, ultra-mobile PCs, wired phones, combinations of the foregoing, and so on. More generally, the techniques described herein can be employed in any electronic device of a variety of electronic devices, including circuit systems for supporting the operation of multiprocessor systems.

[0032] Figure 1The diagram illustrates a block diagram of a computer system 100 according to an example embodiment, including a processor 102 having a core 106 with synchronous data stream (SDF) circuitry 108 and an SDF manager 124 (e.g., circuitry). In some embodiments, the computer system 100 includes multiple processors (e.g., processor 102b, processor 102c, processor 102d, etc.). In some examples, one or more other processors (e.g., processor 102b, processor 102c, processor 102d, etc.) include... Figure 1 One or more (e.g., all) of the components depicted in processor 102. In some examples, the processor communicates with one or more other processors via system bus 128, for example, to jointly execute the SDF graph.

[0033] In some examples, processor 102 includes unit 104, which includes core 106 and input / output 114 (e.g., control circuitry) for core 106. In some examples, SDF circuitry 108 is included, for example, as referenced. Figure 4 Examples of SDF function circuitry 408 discussed. In some examples, SDF manager 124 (e.g., circuitry) includes multiple interfaces with core I / O 114, as described below.

[0034] In some examples, SDF circuitry 108 is coupled to the protocol interface of SDF manager 124, for example, via the main protocol interface (PI) 116 of core I / O 114. In some examples, the first load store unit (XLSU) 110 of core 106 is coupled to the content initiator interface (CII) of SDF manager 124, for example, via the main content interface 118 of core I / O 114. In some examples, core 106 further includes one or more (e.g., other) load / store units 112-0 to 112-(S-1), for example, where S is the number of LSUs. For example, in some embodiments, one or more other LSUs 112 are each coupled to a corresponding arbitrator 120 (e.g., circuitry) to allow access to the corresponding memories 122-0 to 122-(S-1).

[0035] In some examples, the interrupt request controller 126 is coupled to the SDF manager 124, for example, to allow the SDF manager 124 (e.g., via a corresponding interrupt) to signal errors.

[0036] In some examples, the application is abstracted as one or more Synchronous Data Flow (SDF) graphs, where nodes represent tasks that repeatedly invoke algorithms on streaming data (e.g., from memory 122), and arcs represent data communication paths between such nodes. In some examples, this abstraction (e.g., the SDF model) provides a good fit for a wide range of applications in digital signal processing.

[0037] In some examples, data communication is abstracted by modeling the hierarchical data blocks held in the buffer as tokens residing on arcs in the SDF graph.

[0038] Some embodiments improve upon existing SDF management techniques in various ways by providing technologies and / or mechanisms that enable software (or other) agents to explicitly request the SDF manager to mark the next node as ready for execution. In various embodiments, for example, the SDF manager supports non-blocking functionality even when there is no currently available next node for execution, provided the requesting agent intends to continue operation. In one such embodiment, the SDF manager supports non-blocking functionality by responding to such requests (referred to herein as "task identification request" or "node identification request") with a message specifying whether a particular next node is currently available for execution. By way of illustration and not limitation, such a message returns a Boolean value indicating whether any node is currently available for execution (and, for example, returns the identifier of the currently available node if one exists).

[0039] Alternatively or additionally, for example, where the requester agent intends to delay, abandon, or otherwise block operation at least until the next node becomes available for execution, the SDF manager supports a non-blocking function. In one such embodiment, the SDF manager supports a blocking function, which defers providing any response to a given node identification request until the node is identified as currently available for execution. For example, the requester agent knows that such a response will not be provided until an available node is identified. In some embodiments, the node identification request specifies or otherwise indicates to the SDF manager whether a response to the request should be provided to facilitate a particular one of the blocking or non-blocking functions (i.e., not the other).

[0040] In some embodiments, the SDF manager includes one or more registers (referred to herein as "scheduling registers") or any of a variety of other suitable resources, or is otherwise accessible to one or more registers or any of a variety of other suitable resources, which serve as a repository for state information updated during the execution of various nodes in the SDF graph. For example, the SDF manager includes logic (e.g., including hardware, firmware, and / or execution software), is coupled to access logic, or otherwise operates based on logic that maintains state information for a given node based on the current state of one or more input arcs and / or one or more output arcs. By way of illustration and not limitation, this logic (referred herein as "scheduler") maintains state information for a given node based on other arc state information, including, for example, the total number of tokens in a given input arc, the amount of available space in an output arc, etc. Such arc state information may be provided, for example, in one or more registers (referred herein as "channel registers") or any of a variety of other suitable resources. In response to a node identification request, the SDF manager accesses one or more schedulers to determine which node in the SDF graph (if present) represents a task currently eligible for execution.

[0041] While some embodiments are not limited in this respect, the SDF manager is capable of selecting a node from a plurality of nodes currently available for execution—for example, where such selection is based on the relative priorities of the plurality of nodes in the SDF graph. In one such embodiment, priorities are configured for some or all of the nodes in the SDF graph during some initialization phase—for example, some or all of such priorities are increased or decreased in various ways at different times during the execution of one or more applications represented by the SDF graph. Thus, various embodiments provide accelerated hardware scheduling of execution of different nodes running on the same processor.

[0042] In various embodiments, two or more processors across system 100 support SDF management functions (e.g., including node identifier request functionality). By way of illustration and not limitation, processor 102 sends load / store operations to an external device, for example, via the CII interface of SDF manager 124. In one such embodiment, the SDF manager of the external device (e.g., where the external device is one of processors 102b, 102c, 102d) signals via system bus 128 that a load / store operation (or any of various other operations) has been executed or alternatively deferred. Alternatively or additionally, SDF manager 124 sends a node identifier request to the SDF manager of the external device on behalf of the requester agent of core 106—e.g., where SDF manager 124 receives a response supporting blocking functionality or alternatively non-blocking functionality for the requester agent of core 106. Accordingly, such embodiments accelerate or otherwise provide SDF protocols that facilitate data-driven, multi-core synchronization, and task scheduling in various ways.

[0043] Some embodiments enable agents (such as agents with SDF circuitry 108 or similar circuitry provided by another processor) to explicitly request SDF manager 124 to identify the next eligible node to be executed. For example, some embodiments support requests received by the PI of SDF manager 124 (e.g., from protocol interface 116) for SDF manager 124 to evaluate the state of some or all nodes in the SDF graph. For example, scheduler 150 (or other suitable circuitry) of SDF manager 124 accesses one or more registers (e.g., including the illustrated scheduling register 152) based on node identification requests to determine which node(s), if present, currently satisfies its corresponding SDF activation rules and is therefore eligible to be executed. In some embodiments, in the case of multiple eligible nodes detected, scheduler 150 selects one such eligible node and, in response to a node identification request, identifies the selected node as the next eligible node to SDF circuitry 108 (directly or indirectly).

[0044] In various embodiments, the scheduler 150 updates the scheduling register 152 during the runtime execution of the application using state information about the corresponding eligibility status of a specified SDF graph node. In one such embodiment, the update of the scheduling register 152 is performed based on other registers (not shown), referred to herein as "channel registers," which provide additional state information at a channel-specific granularity. Some embodiments improve the efficiency of node scheduling by mitigating the overhead of polling such finer-grained state information from the channel registers, which would otherwise be necessary.

[0045] In various embodiments, the SDF manager 124 and SDF circuitry 108 (and / or similar circuitry of one of the processors 102b, 102c, 102d) support a protocol that includes a blocking version of the message type—referred to herein as "sdf_pick_task"—as a node identification request. In an illustrative scenario according to one embodiment, the SDF manager 124 only sends a reply to the sdf_pick_task message after the scheduler 150 has identified the next eligible node based on the sdf_pick_task message (e.g., where the SDF manager 124 does not send any reply to the SDF circuitry 108 conveying that no node is currently eligible).

[0046] Alternatively or additionally, the protocol supports another message type as a non-blocking version of a node identification request, referred to herein as "sdf_find_task". In one such embodiment, the SDF manager 124 sends a reply to the sdf_find_task message regardless of whether the scheduler 150 has identified the next eligible node based on the sdf_find_task message. For example, under certain conditions, the SDF manager 124 sends a reply to the sdf_find_task message conveying to the requester agent that no node is currently eligible. In one such embodiment, once the scheduler 150 determines that a node has become eligible to be executed, an additional reply to the same sdf_find_task message is automatically sent.

[0047] Figure 2 Features of a method 200 for identifying an executable task using an SDF manager circuit according to an embodiment are illustrated. Method 200 is performed by an SDF manager circuit (e.g., SDF manager 124) that facilitates modeling of an application using an SDF graph, which includes nodes communicating with each other in various ways via channels. For example, for a given such node, one or more “input” channels each provide corresponding data to a corresponding input terminal of that node. Alternatively or additionally, one or more other “output” channels each serve to receive corresponding data from a corresponding output terminal of that node.

[0048] In one such embodiment, the runtime execution of the application utilizes registers (referred to herein as "channel registers") to facilitate the process, which define, specify, or otherwise indicate the state of some or all channels in various ways. By way of illustration and not limitation, a given channel in the SDF graph corresponds to a corresponding set of one or more first registers (channel registers) used to specify or otherwise indicate the state of that channel (and, correspondingly, the state of the corresponding terminal with which the channel will communicate). In various embodiments, some or all channel registers provide corresponding state information at a channel-specific granularity. During the runtime of the application represented by the SDF graph, the corresponding set of channel registers for multiple channels is updated in various ways—for example, based on messages that include, specify, or otherwise indicate the use of some or all such channels.

[0049] In one such embodiment, a given channel corresponds to a channel register (referred to herein as a status register) that indicates any of a plurality of possible channel states at various times. For example, a first such channel state (referred herein as an ARMED state) indicates that the corresponding channel currently meets the conditions for accommodating the execution of the task represented by the corresponding node. However, a second such channel state (referred herein as an UNARMED state) indicates that the corresponding channel currently does not meet such conditions. In an example embodiment, an input channel (i.e., the channel for providing tokens to the input terminal of the corresponding node) will be in an ARMED state, wherein it is determined that the input channel currently has enough tokens to accommodate (e.g., at least partially enable) the next execution of the task represented by the corresponding node. In contrast, an output channel (i.e., the channel for receiving tokens from the output terminal of the corresponding node) will be in an ARMED state, wherein it is determined that the output channel currently has enough available space to accommodate (e.g., at least partially enable) the next execution of the task represented by the corresponding node.

[0050] In one such embodiment, the runtime execution of the application further utilizes additional registers (referred to herein as "scheduling registers") to facilitate the process, which define, specify, or otherwise indicate the state of some or all nodes in various ways. By way of illustration and not limitation, a given node in the SDF graph corresponds to a corresponding set of one or more second registers (scheduling registers) used to specify or otherwise indicate the state of that node. In various embodiments, some or all scheduling registers provide corresponding state information at a node-specific granularity. During the runtime of the application represented by the SDF graph, the corresponding sets of scheduling registers for multiple nodes are updated in various ways—for example, where updates to the node's scheduling registers are performed based on the current state of each channel to which communication with the given node is to take place.

[0051] In one such embodiment, a given node corresponds to a type of scheduling register (referred to herein as a QUALIFY register), which indicates any of a plurality of possible node states at various times. A first such node state (referred herein as a QUALIFIED state) indicates that the node is currently qualified to be executed. For example, a qualified state indicates that, for each channel coupled to a terminal of the node in question, that channel currently meets the corresponding conditions for accommodating the execution of the task represented by that node. In contrast, a second such node state (referred herein as an UNQUALIFY state) indicates that the node in question is currently not qualified to be executed. For example, an UNQUALIFY state indicates that, for at least one channel coupled to a terminal of the node in question, that channel currently does not meet the corresponding conditions for accommodating the execution of a task.

[0052] In some embodiments, the SDF manager circuitry operates during application runtime to maintain and / or provide access to the scheduling registers of at least one node of the SDF graph. In one such embodiment, the SDF manager circuitry (via firmware agent, software agent, etc.) provides access to any of a plurality of sets of one or more scheduling registers, where each such set corresponds to a different corresponding node in the SDF graph.

[0053] like Figure 2As shown, method 200 includes (at 210) performing a first access to one or more first registers (i.e., one or more channel registers) during the application's runtime. In an embodiment, the application is modeled using an SDF graph comprising multiple nodes, each node representing a corresponding task of the application, and communicating in various ways via channels of the SDF graph during runtime. For example, one or more channels are each used for communication via a first node among the multiple nodes, wherein one or more first registers each correspond to a different corresponding channel among the one or more channels. In an embodiment, the one or more first registers are status registers, wherein the first access at 210 includes: the SDF manager circuitry performing a read to determine whether, for each of the one or more channels, the channel is currently capable of accommodating the execution of a first task of the application.

[0054] Based on this first access, method 200 (at 212) performs a second access to the second register (i.e., the scheduling register) corresponding to the first node. In an embodiment, the second register is an eligibility register, wherein the second access at 212 performs a write or other appropriate operation to provide a value for a first status parameter of the second register, wherein the value indicates whether the first task is currently eligible to be executed.

[0055] Method 200 further includes (at 214) receiving a request during application runtime to identify the next task to be executed. For example, the request is received from SDF circuitry 108 or another suitable SDF function circuitry of the multiprocessor system (e.g., representing a firmware agent or alternatively a software agent). Method 200 further includes (at 216) performing a third access to the second register based on the request received at 214. In an embodiment, the third access reads the current value of the first status parameter to determine whether the first task is currently eligible to be executed.

[0056] Method 200 further includes (at 218) generating a response to the request based on a first state parameter. For example, the response is communicated by the SDF manager 124 to the SDF circuitry 108 or any of various other suitable request brokers. In some embodiments, method 200 further includes performing another access to a third register (i.e., another type of scheduling register referred to herein as the ACTIVITY register) based on the request, the third register including an identifier of the starting address of the first task. For example, this other access is, for example, reading or otherwise determining the identifier of the starting address, which is provided in the response at 218 to indicate that the first task is the next task to be performed. In another embodiment, the response provides a unique task identifier for the next eligible task—for example, where the request broker would need to access additional information based on the task identifier in the response to determine the address for performing the next eligible task.

[0057] In an illustrative scenario according to one embodiment, the request received at 214 is a "blocking" type request, where (in some cases) the response generated at 218 indicates that no task was identified as currently eligible for execution. In an alternative scenario, the request received at 214 is a "non-blocking" type request, where (in some cases) method 200 delays the generation of a response—for example, at least until a node is identified as eligible for execution. For example, method 200 delays sending the response at 218 based on the failure to identify any node as currently eligible for execution.

[0058] In some embodiments, the third access performed at 216 by method 200 includes accessing each of a plurality of eligibility registers corresponding to different corresponding nodes in the SDF graph based on a request. For example, each of the plurality of eligibility registers includes a corresponding status parameter indicating whether the corresponding node is eligible to be executed. In some cases, accessing the plurality of eligibility registers causes the SDF manager circuitry to detect a condition in which the plurality of nodes are currently each eligible to be executed. In one such embodiment, method 200 further performs a selection from the plurality of nodes, for example, a first node, based on this condition—for example, where the response identifies the first node based on this selection. In embodiments, the selection of the first node is performed based on the relative priorities of the plurality of nodes relative to each other—for example, where scheduling registers provide corresponding priority information indicating relative priorities in various ways. In some embodiments, method 200 further includes other operations (not shown) to change the relative priorities during application runtime—for example, where these other operations are based on information indicating whether the priority of a particular node (such as the first node) should be increased or decreased.

[0059] Figure 3The figure illustrates a block diagram of a memory 322 partitioned into data flow buffers (e.g., illustrated using example data flow buffer 300) for hierarchical blocks of SDF data, according to an embodiment. In the embodiment, memory 322 functionally corresponds to one or more memories in memory 122.

[0060] In some embodiments, data exchange between tasks is abstracted using tokens, which travel across arcs in the SDF graph in a first-in-first-out (FIFO) order in various ways, e.g., from buffer to buffer, with nodes performing corresponding computations between buffers. In some embodiments, indicators are responsible for maintaining the buffer read state at the granularity of such tokens (e.g., via placement indicator 302) and maintaining the buffer write state (e.g., via acquisition indicator 304). In some embodiments, acquisition indicator 304 is maintained and updated by consuming nodes and / or placement indicator 302 is maintained and updated by producing nodes. However, in some embodiments, both acquisition and placement indicators are needed to determine the number of tokens or token space present in the buffer (e.g., arc state). Therefore, to ensure that both producers and consumers can evaluate the arc state, in some embodiments, indicators are exchanged between each pair of terminals connected at either end of the arc in the SDF graph. This exchange is called indicator sharing (or “remote indicator writing”). In some embodiments, exchanging indicators enables the processor to self-schedule and self-synchronize its tasks.

[0061] In some embodiments, multi-core digital signal processing systems greatly benefit from data-driven multi-core (e.g., multiprocessor) communication and synchronization mechanisms, such as those conceptually defined by the Synchronous Data Flow (SDF) model. In some SDF models, applications (e.g., computation programs) are described as a node graph that consumes and produces data, which is abstracted as tokens spanning node input and output terminals connected via directed arcs. In some embodiments, nodes self-schedule and synchronize based on the availability of sufficient tokens (e.g., a token space) on all relevant node terminals. In some embodiments, this synchronization mechanism is implemented via an SDF protocol. In some embodiments, the SDF protocol includes three key synchronization phases, referred to as (1) "request," (2) "completion," and (3) "notification."

[0062] Some implementations are at least partially aimed at accelerating the SDF protocol across multiple protocol phases—for example, this facilitates simplified programming and provides full observability for debugging compared to providing acceleration only for a subset of SDF protocol phases, doing so only in a limited form, and / or doing so in a way that complicates SW debugging (examples in this document).

[0063] Some embodiments described herein provide acceleration for programming models, such as those where synchronized data flows should be applied at a coarse-grained task level (e.g., as opposed to applying them at a fine-grained operation level). In some embodiments, nodes in the synchronized data flow graph represent entire algorithms (e.g., tasks). In some embodiments, each node maps to a single processor in a multiprocessor system. In some embodiments, nodes map to central processing units (CPUs), microcontrollers, digital signal processors (DSPs), application-specific instruction set processors (ASIPs), hardware accelerators, and / or I / O peripherals. In some embodiments, the arcs in the graph thus model the data flow between such tasks running on different processors at a coarse-grained (multi-dimensional) data block level. In the example embodiment shown, a given token in data flow buffer 300 represents some or all of a three-dimensional (3D) data block, where multiple fields of such a 3D block each represent a corresponding two-dimensional (2D) data block. For example, the height h of a given 2D data block comprises multiple rows, and the width w of the 2D data block comprises multiple columns.

[0064] In some embodiments, these arcs are implemented as communication buffers, which may include, for example, hardware FIFOs, software buffers in conventional memory-mapped memory, and / or volatile I / O ports. In some embodiments, signal processing tasks mapped to heterogeneous multiprocessor systems employ extensive low-level programming to ensure proper buffer setup, communication path setup, and synchronization between tasks mapped to different processors. This is further complicated if the target processor and its associated buffer implementations are of different types within the heterogeneous multiprocessor system.

[0065] Some embodiments provide or otherwise utilize an application programming interface (API), for example, an API that accommodates the use of various low-level primitives in different cores of a heterogeneous multi-core system. In one such embodiment, the API enables the implementation of SDF functionality using a programming model and / or a synchronization protocol implemented in software as firmware.

[0066] When both the "Get" and "Place" indicators are available for a given terminal of a node, the SDF manager can at least partially determine whether the node's firing rules are satisfied. Such an SDF manager can determine whether sufficient tokens are available at each input terminal of the node in question, and whether sufficient token space is available at each output terminal of the node. For example, in various embodiments, the SDF manager includes registers (referred to herein as "channel registers"), registers that can be accessed or otherwise operated on, which provide status information, some or all of which is at a channel-specific (and therefore terminal-specific) granularity. One or more sets of channel registers each correspond to a different corresponding channel in the SDF graph—for example, one or more sets of channel registers each correspond to a corresponding channel for a single node, and one or more other sets of channel registers each correspond to a corresponding channel for a different node. In one such embodiment, a given set of channel registers includes a register (referred herein as a status register) that is kept up-to-date by the SDF manager during runtime execution. For example, the SDF manager monitors messages going to and / or coming from SDF circuit 108 (and / or other such agents), and based on this monitoring, stores the latest value in a status register that indicates whether the corresponding channel has enough tokens (or, alternatively, enough space) to accommodate the next firing of a node communicating via that channel.

[0067] In some embodiments, the SDF manager 124 and the request agent (such as SDF circuitry 108 or similar circuitry to one of the processors 102b, 102c, 102d) support an interface (e.g., a protocol interface, an application programming interface, etc.) through which the request agent can access status information from one or more given channel registers in the channel registers. By way of illustration and not limitation, such an interface supports one type of message (“sdf_check” herein) that is a request from the SDF manager for accessing status information for a specific terminal of a specific node, for example, a node identified in the sdf_check message. Alternatively or additionally, the interface supports another type of message (“sdf_check_all” herein) that is a request from the SDF manager for accessing status information for all terminals of a specific node, for example, a node identified in the sdf_check_all message.

[0068] Therefore, by issuing sdf_check messages, sdf_check_all messages, etc., for a specified node, the software (or firmware) agent can request the SDF manager to determine whether the triggering rules for that specified node are currently met. Based on the SDF manager's response to the request, the agent can, for example, invoke the task program belonging to a node that has been checked and determined to be ready for execution, or check whether another node is ready if the node in question is not yet ready. However, without additional functionality, such messages typically require the firmware (or software) agent to perform a "polling" scheduling loop—for example, repeatedly checking the execution readiness of all nodes assigned to the same processor. In some cases, these polling requirements can lead to significant performance overhead.

[0069] To mitigate the need for such overhead, some embodiments provide supplemental SDF manager circuitry functionality in various ways to maintain and access additional state information based on channel register information. For example, this additional state information is provided by the circuitry hardware at a node-specific (and therefore task-specific) granularity that is higher (e.g., more abstract) than the channel-specific granularity. In some embodiments, this type of additional state information is kept up-to-date in various ways in scheduling registers, each corresponding to a specific node (and therefore, the corresponding task represented by that node). In one such embodiment, some or all of these scheduling registers are accessible to the requesting agent by sending an sdf_pick_task message (e.g., a request for firmware or software agent to perform an sdf_pick_task operation to send such a message) to the SDF manager to request the identifier of the next eligible node.

[0070] Figure 4 The diagram illustrates a task (“C”) according to an embodiment, a corresponding application graph 460 for that task (having nodes A, B, C, and D), and a computing system 400 including an SDF functional circuit (SDFFC) 408 and an SDF manager circuit 424 to implement the corresponding application graph. In some embodiments, the SDFFC 408 and / or the SDF manager circuit 424 facilitate the identification of specific nodes in the SDF graph as currently eligible (or “available”) to be executed (and correspondingly, the task corresponding to said node as currently eligible (or “available”) to be executed). In one such embodiment, the SDFFC 408 and / or the SDF manager circuit 424 further provide acceleration for multiple SDF protocol phases at the node level (e.g., rather than at individual terminal levels) while maintaining and further improving power savings when a task is not yet ready to be executed.

[0071] like Figure 4 As shown, system 400 includes a system bus 428 and a plurality of processors coupled to each other via system bus 428, such as illustrative processor 402 and one or more other processors (not shown). Processor 402 includes a memory resource (DMEM) 422, which is accessible by one or more local resources (such as the illustrative load store unit (LSU) 412 shown) and, for example, by one or more other processors via SDFFC 408. In some embodiments, the core of processor 402 includes LSU 412 and any of a variety of other suitable functional blocks, such as an arithmetic logic unit (ALU) 404, a multiplier circuit (MUL) 406, etc.

[0072] In embodiments, processor 402 and system bus 428 functionally correspond (respectively) to processor 102 and system bus 128—for example, where SDFFC 408 and SDF manager circuitry 424 functionally correspond (respectively) to SDF circuitry 108 and SDF manager 124. In the example embodiment shown, SDF manager circuitry 424 is located external to processor 402—for example, where any access to DMEM 422 by another processor of system 400 is via system bus 428. In one such embodiment, SDF manager circuitry 424 is coupled to provide SDF management functionality to two or more processors in system 400 in various ways. However, in alternative embodiments (such as the embodiment shown in system 100), SDF manager circuitry 424 is located internal to processor 402—for example, where SDF manager circuitry 424 is configured to listen for communications accessing DMEM 422 and update channel registers and scheduling registers (not shown) in various ways based on such communications.

[0073] The advantages of using the SDFFC 408 and / or SDF manager circuitry 424 (e.g., compared to conventional SDF techniques) include a highly efficient API with relatively low code overhead, greater speedup, and consequently less performance overhead, full observability, and debuggability. This simplifies software development and improves performance and overall quality. Some embodiments herein use the SDFFC 408 and / or SDF manager circuitry 424 to achieve performance efficiency utilizing, for example, multi-core programming APIs for data-driven multi-core signal processing systems.

[0074] In some embodiments, SDFFC 408 acts as a special load / store unit and is connected to (e.g., an external SDF manager 124, or a device) via an interface that maps memory (e.g., in the core I / O 114) of the processor 102 and (e.g., "regular") memory in the I / O subsystem.

[0075] Turn to Figure 4 The depicted SDF manager circuitry 424 includes multiple interfaces, such as some or all of interfaces CI, PI, CII, and TII. In some embodiments, the device is configured by the processor 402 in system 400 using (e.g., a single) Configuration Interface (CI). In some embodiments, for debugging purposes, some or all of the relevant information of the SDF manager circuitry 424 can be observed or dumped through the same interface.

[0076] In some embodiments, a (e.g., a single) Protocol Interface (PI) of processor 402 is used to execute different (e.g., “critical”) phases of the SDF synchronization protocol (e.g., request, completion, and notification phases) via custom operations issued on SDFFC 408. In some embodiments—e.g., via load operations issued on SDFFC—for example, to obtain specific node and terminal attributes for task scheduling and processing, or for debugging and observability from firmware running on the processor, the PI provides read-only access to a standard memory mapping of the internal register mapping of SDF manager circuitry 424. In some embodiments, during the SDF protocol “request” phase, the PI interface allows a single SDFFC custom load operation to check the complete SDF firing rules of the node. In some embodiments, this check can be blocking or non-blocking and will assess whether sufficient tokens or space are available on all terminals of the node for the node to execute (e.g., “firing”). In some embodiments, for the SDF protocol “completion” and “notification” phases, the interface allows combined completion and notification operations on all terminals of the node using a single SDFFC custom memory operation. In some embodiments, in response to this operation, all local (e.g., locally held) indicators across all terminals of the node are updated, and the updated values ​​are shared with remote terminals connected to the far end of the arc to which each terminal is connected. This effectively speeds up indicator updates and sharing, as explained above. In some embodiments, the SDFFC and SDF manager use dedicated sideband information bits (e.g., such as...) passed across the PI interface with each load / store operation. Figure 7 (As shown in the diagram) distinguishes between custom load operations and custom store operations.

[0077] In some embodiments, a (e.g., a single) Content Initiator Interface (CII) of processor 402 is used to pass (e.g., “normal”) data loads and stores initiated by processor 402 to the rest of system 400. In some embodiments, the CII interface allows SDF manager circuitry 424 to inject additional transfers initiated via SDFFC 408 completion and notification operations into the regular data load / store stream initiated by the processor. In some embodiments, according to the SDF programming model, (e.g., “normal”) access initiated by node software running on the processor consists only of token content writes, while the additionally injected transfers will consist of indicators to be shared between communicating nodes running on different processors. In some embodiments, these combined data and indicator writes collectively form an abstract token shared between nodes running on different processors. In various embodiments, the CII (or any of various other suitable interfaces of processor 402) is additionally or alternatively used to provide the request agent of system 400 (e.g., an agent of processor 402 or another processor) with an identifier in the SDF graph that a particular node is currently available as the next node to be executed.

[0078] In some embodiments, the processor 402's (e.g., a single) Token Target Interface (TTI) is used to receive SDF tokens generated by other processors in system 400. In some embodiments, this includes both token content and / or remote indicator writes received due to notifications executed by other nodes running on other processors. In some embodiments, write request listening is used to detect remote indicator writes in the received request stream. For this purpose, in some embodiments, the SDF manager circuitry 424 includes: (e.g.) a set of control registers configured by the main processor in the system, channel registers defining corresponding remote indicator write listening address ranges for one or more buffers, and scheduling registers that identify, in various ways, whether a given node in the SDF graph is currently eligible for execution. In some embodiments, the address of any write request received via the TTI is checked against listening address range boundaries; for example, any write request falling within those boundaries is marked as a remote indicator write. In some embodiments, for example, depending on the memory address range into which the requested address falls, each request received via TTI (including remote indicator write requests) is by default delivered to one of the processor's tightly coupled local data memories (e.g., 120-0 to 120-(S-1)). Alternatively, remote indicator writes can be filtered out such that these remote indicator writes do not occupy memory space if they are not explicitly used by task software running on the processor.

[0079] In some embodiments, a single (e.g., one-bit) error interface (EI) is used to mark errors caused by one or more error commands or command arguments supplied to the SDF manager circuit 424, for example, to send an error indication to the interrupt request controller 126.

[0080] In an illustrative scenario according to one embodiment, nodes C and D of FIG460 are each assigned to processor 402, which includes or otherwise supports the use of SDF protocol acceleration, such as protocol acceleration provided by the circuitry of SDF manager circuitry 424. For example, such SDF protocol acceleration is accessed from the data path of processor 402 via SDFFC 408, which is capable of performing specific custom operations or otherwise directing commands to SDF manager circuitry 424 (e.g., requesting information from SDF manager circuitry 424). In the illustrated example embodiment, the scheduler 450 of SDF manager circuitry 424 supports maintaining and / or otherwise accessing up-to-date status information in scheduling register 452—for example, some or all of this status information is at the node granularity level. By way of illustration and not limitation, in response to performing a node identification operation on SDFFC 408 (e.g., from within a given task program (referred to as a task "activity")), SDF manager circuitry 424 will access scheduling register 452 to determine whether any node representing another task is currently eligible to be executed. In one such embodiment, the scheduler() function of SDFFC 408 is adapted to generate one or more node identification requests for SDF manager circuitry 424, thereby alleviating the need for repeated access to channel-specific status information (using sdf_check requests, sdf_check_all requests, etc.) until SDFFC 408 is able to identify an eligible node.

[0081] In the example embodiment shown, the scheduler() function of SDFFC 408 can perform the sdf_pick_task operation to generate a blocking version of the node identification request—for example, where the scheduler() function simply waits (e.g., pauses processor 402) until the task is eligible to be executed, thereby saving power when no task is available. In some embodiments, the scheduler() function can additionally or alternatively perform the sdf_find_task operation to generate a non-blocking version of the node identification request.

[0082] In various embodiments, a request to access status information of one or more channel registers (such as an sdf_check request or an sdf_check_all request) includes one or more parameters that directly or indirectly identify the channel(s)(s) to which the request is directed. In contrast, a node identification request (or, according to some embodiments, other status information for accessing one or more status registers) does not identify any specific node, but rather relies on the SDF manager to select the currently eligible node (if any) from a pool of nodes.

[0083] Figure 5 The figure illustrates a block diagram of an SDF manager circuit 500 according to an embodiment. In some embodiments, configuration requests from the system (e.g., from processor 102 or another processor) are received via a CI interface and forwarded to channel register set 508 and control register set 510. In some embodiments, any errors occurring within the SDF manager circuit 500 can be flagged to the system via an EI interface connected to one or more error registers within control register set 510, for example, as set by handler 506 of SDF core 502.

[0084] In some embodiments, the processor (e.g., one or more other processors) is targeted at that associated processor (e.g., Figure 1 Data reads and / or writes to the processor 102's memory are initiated via a TTI interface. In some embodiments, a fork circuit 516 (e.g., a device) extracts, listens for, or otherwise detects write requests from the incoming TTI request stream and forwards such requests (or at least versions or other indicators of such requests) as communication SNPs to a listening circuit 504. In some embodiments, the listening circuit 504 is used to detect remote indicator writes within the write stream. In some (e.g., parallel) embodiments, the fork circuit 516 passes all requests (reads and writes) to an internal bus circuit 518, which routes the requests to the appropriate target memory, for example, based on the request address and a memory routing map implemented by bus logic.

[0085] Figure 5The SDF manager circuitry 500 depicted includes multiple entry circuits 512-0 to 512-m (e.g., where m is a positive integer). In some embodiments, entry circuits 512-0 to 512-m on each path to processor memory are used to prevent race conditions between regular data writes and special remote indicator writes that are effectively used as SDF synchronization markers. In some embodiments, each entry circuit 512-0 to 512-m automatically converts the last data write request prior to a remote indicator write request detected by the listening circuit 504 into a posted write for which it expects a response. In some embodiments, where there is no native hardware support for posted writes and write responses, this can be accomplished by injecting a read request into the entry output stream of each entry circuit toward its target memory whenever each entry circuit 512-0 to 512-m receives a “publication” trigger (e.g., one of the illustrated post triggers pst0, pst1, ..., pstm) from the listening circuit 504. In some embodiments, upon receiving a response to an injected read, each entry circuit 512-0 to 512-m will send an announcement response back to the listener. In some embodiments, the listener circuit 504 waits until it has received an announcement response signal from each entry circuit 512-0 to 512-m. In some embodiments, the listener circuit 504 only notifies the channel register 508 of a detected remote indicator write after all published responses have been received. In some embodiments, this means that any update to the channel register 508 is only reflected after it is determined that any data write that should have preceded a remote indicator write has reached its destination. In some embodiments, this logic thus eliminates any separate non-announcement write bus logic required in the system.

[0086] In some embodiments, read and / or write requests received from standard load / store units in the processor data path enter the SDF manager circuit 500 via the CII interface and are transmitted to the system via the exit circuit 514.

[0087] In some embodiments, the disposal program circuit 506 within the SDF manager circuit 500 retrieves data from the SDFFC (e.g., from the data path of the corresponding processor) from the SDFFC. Figure 1 SDF circuit 108 or Figure 4The SDFFC 408 receives commands. In some embodiments, the handler 506 is used to execute all relevant SDF protocol phases in response to the received command, for example, while processing the corresponding information held in various ways in the control register 510, channel register 508, and scheduling register 552. In some embodiments, the notification command causes the handler 506 to inject an indicator-shared write request into the CII stream of the read / write request (e.g., this results in a remote indicator write received at another processor). In some embodiments, any notification-controlled write receives higher priority than other (e.g., “normal”) reads and writes on that interface, so that the processor can automatically stop as long as the notification write is pending, for example, if it attempts to issue (e.g., “normal”) (e.g., SDF-independent) reads and writes via the CII interface. In some embodiments, this priority setting guarantees the order in which SDF remote indicator writes are initiated via the PI interface, followed by further (e.g., “normal”) data writes via the CII interface, for example, mitigating the risk of potential race conditions from such write sources.

[0088] In some embodiments, a standard register mapping reflecting the physical organization of channel register 508 is provided via the CI interface. In some embodiments, by using this register mapping, the system can configure registers and / or read and thereby observe the contents of registers for analysis and debugging using standard memory-mapped I / O. In some embodiments, analysis and debugging are provided via (e.g., “normal”) system interconnects and / or via a dedicated debug network.

[0089] In some embodiments, a “virtual” address mapping view on channel register 508 is provided to the SDFFC embedded in the processor via a PI interface. In some embodiments, the PI interface allows three types of access to channel register 508 from within the processor. For example, the PI interface allows access to registers via custom load / store operations to execute the SDF protocol. In some embodiments, these accesses have side effects within the SDF manager channel register 508; for example, the access may result in modification of the values ​​of one or more (e.g., multiple) registers. In some embodiments, this may include registers that fall outside the range of other (e.g., “normal”) load / store byte accesses, such as those specified via address and data type information mapped via conventional memory. For example, a custom load operation against the SDF manager PI interface may specify the data vector to be returned by the SDF manager circuitry 500 based on a read of registers covered by a specified load address and data type range, but may actually modify SDF manager registers even those outside that range.

[0090] In one such embodiment, the PI interface allows standard scalar read access to a single register associated with a single terminal, where the response is returned as a single (e.g., 32-bit) scalar value, thus representing a standard (e.g., 32-bit) load operation. Furthermore, the PI interface allows standard vector read access to multiple equivalent registers residing in different channels and therefore associated with multiple terminals of the same node, for example, where the response is returned as a vector of multiple bit elements (e.g., 16-bit or 32-bit elements), thus representing a standard (e.g., 16-bit or 32-bit) element vector load operation.

[0091] While some embodiments are not limited in this respect, in order to support the aforementioned access types via a single uniform address mapping, the channel register 508 of the SDF manager circuitry 500 is treated as a virtual vector memory via a PI interface, for example, supporting different access widths. In some embodiments, the supported access widths are both scalar and per element of a vector (e.g., 32-bit scalar, 32-bit element vector, and 16-bit element vector). Figure 6 Examples of this are shown in the different PI address compositions.

[0092] In an embodiment, the SDF core 502 provides functionality to maintain and provide access to the status information in the channel register 508. For example, the channel register 508 comprises multiple sets of channel registers, each such set corresponding to a different corresponding channel in the SDF graph. During runtime execution of the application, the monitoring circuitry 504, the handler 506, and / or other logic of the SDF core 502 automatically and periodically update the individual channel registers in the channel register 508 with, for example, the latest status information at a channel-specific granular level. Also during runtime execution, the handler 506 and / or other appropriate logic of the SDF core 502 process (e.g., received from the SDFFC via PI) requests access to such status information in the channel register 508 in various ways. The requested channel-specific status information is conveyed, for example, via any of the various output interfaces of the SDF manager circuitry 500.

[0093] Furthermore, scheduler 550 (or other suitable logic of SDF core 502) provides functionality to maintain additional state information in scheduler register 552 and to provide access to that additional state information. In one such embodiment, scheduler register 552 comprises multiple sets of scheduler registers, each such set corresponding to a different corresponding node in the SDF graph. During runtime execution, scheduler 550 maintains up-to-date state information of each scheduler register in scheduler register 552 at, for example, a node-specific granularity. For example, the information in scheduler register 552 is automatically and periodically updated by scheduler 550 based on updates to state information in channel register 508. Also during runtime execution, scheduler 550 (e.g., together with disposer 506 of SDF core 502 and / or other suitable logic) is operable to process (e.g., received from SDFFC via PI) node identification requests that request access to such state information in scheduler register 552 in various ways.

[0094] For example, disposition 506 is coupled to receive any of various node identification requests via PI. Based on such a node identification request, disposition 506 signals scheduler 550 to access scheduling register 552 to determine which node(s), if present, currently meets the corresponding firing rules that qualify the node for execution. The current eligibility status of a given node is identified, for example, by a value in the corresponding eligibility register of scheduling register 552—for example, where the value is based on channel registers for one or more channels used by the node. For example, eligibility status is determined based on whether channel register 508 indicates that for each channel communicating with the node in question, the channel currently has sufficient tokens (for input channels) or sufficient available space (for output channels) to accommodate the node's firing.

[0095] In an illustrative scenario according to one embodiment, SDF core 502 responds to a node identification request by identifying the next eligible node, which is selected by scheduler 550 from a plurality of currently eligible nodes. For example, scheduler 550's priority unit 554 selects the next eligible node from a plurality of currently eligible nodes based on the priorities of some or all SDF nodes relative to each other. By way of illustration and not limitation, the scheduling register for a given node includes a priority register that identifies the scheduling priority level currently assigned to that node.

[0096] Figure 6The figures illustrate example formats 600a to 600d of address decomposition at the Protocol Interface (PI) of the SDF manager according to an embodiment (where each field has an example bit width). In some examples, the format includes a register index field (e.g., 4-bit wide), a task identifier field (e.g., 4-bit wide), and / or a port identifier field (e.g., 6-bit wide).

[0097] like Figure 6 As shown, (e.g., within a processor core) the SDFFC can issue commands to the SDF manager pointing to a specific terminal by encoding a task and port identifier pair corresponding to that terminal in an address passed across the PI interface. Additionally or alternatively, the SDFFC can specify a complete node by causing the SDF manager to consider only the task identifier specified in the address. In some embodiments, the node identification request omits the node's identifier—for example, where the response to the node identification request includes the task identifier of the next eligible node or other appropriate identifier.

[0098] In some examples, additional sideband information (e.g., metadata) is provided along with each custom load / store request passed from the SDFFC to the SDF manager to instruct the SDF manager on how to translate address fields and what commands to execute. In some examples, this sideband information translates standard load / store operations into specialized commands for the SDF manager.

[0099] Figure 7 The diagram illustrates information command encoding 700 for SDFFC-to-SDF manager communication according to an embodiment. In some examples, encoding 700 (e.g., via information sidebands) provides seven different command modifiers, which can be configured, for example, via... Figure 7 Each information bit in the range [6:0] shown in the figure is enabled independently.

[0100] Therefore, using information bits, atomic and fusion commands generated by custom operations supported on SDFFC can be specified to the SDF manager via the PI interface. In some examples, if all information bits are deasserted (e.g., cleared to 0), the SDF manager will perform a standard load / store operation. If any of the information bits are asserted, a special load / store operation (e.g., for the SDF graph) will be performed. In some examples, the choice between a load or store operation and the expected data type is independently controlled via the standard write enable (we_n) and type signals on the PI interface. In some examples, the ALL information flag (e.g., bit index [6]) controls whether the operation is applied to all terminals of a node or only to a single terminal. In some examples, the BLOCKING flag is only relevant if the REQUEST flag is also asserted, and the corresponding REQUEST command is modified to a non-blocking or blocking command. In some examples, the remaining five flags indicate individual commands that match one by one with the (extended) SDF protocol phases discussed in this article: REQUEST, COMPLETE, NOTIFY, RESERVE, and CANCEL.

[0101] In some examples, by driving specific combinations of we_n, address, and information signals on the PI interface, the SDFFC can issue commands to the SDF manager relating to a specific single terminal identified by the TASK_ID and PORT_ID pairs, or relating to all terminals of a specified node identified only by the TASK_ID. In some examples, the SDF manager can therefore perform SDF protocol phase operations on all terminals of a given task based on a single operation, or on each terminal individually. In some examples, the TASK_ID and PORT_ID provided in the PI address can be compared with the corresponding register fields of the TERMINAL_ID register (terminal_ID) contained in the SDF manager's channel register. In this way, the SDF manager can determine on which channels to operate in response to a given command received from the SDFFC.

[0102] In some examples, the channel registers are physically organized into channels, for example, where each channel holds a register used to accelerate all SDF protocol stages for a single terminal. Figure 8 An example of a channel register is depicted in the text.

[0103] Figure 8 The figure illustrates Table 800 according to an embodiment, which lists the channel registers (e.g., for a single channel) of the SDF manager. Figure 5An example of channel register 508 in the example embodiment. In the example embodiment shown, the channel register for a given channel includes a valid (VALID) register, which indicates whether the contents of the corresponding channel are valid and active. The channel register for a given channel further includes a TERMINAL_ID register, which includes a PORT_ID field and a TASK_ID field. The PORT_ID field is a repository of unique identifiers for the task port corresponding to the node terminal to which the channel in question is assigned. For example, during the initialization of the SDF graph, each port belonging to a given task receives a unique, sequentially incrementing port identifier—for example, where the assigned port identifiers start from zero (“0”) in the order of port declaration, as part of the task interface. The TASK_ID field is used to provide a unique identifier for the task instantiated by the node to which the channel in question is assigned. For example, during the initialization of the SDF graph, each task assigned to a given processor receives a unique, sequentially incrementing task identifier—for example, where the assigned task identifiers start from zero (“0”) in the order of assignment.

[0104] In an embodiment, the channel register for a given channel further includes a rate register, which is a storage of a rate value, for example, the number of tokens consumed (in the case of a mode-specified input) or generated (in the case of a mode-specified output) upon each firing of the parent node of the terminal assigned to the channel in question. Furthermore, a mode register is used to identify the mode of the terminal (i.e., input or output) – for example, where a reserve register is used to identify the number of tokens or space already reserved for the terminal. Further still, a capacity register is used to indicate the capacity of the arc connected to the terminal (e.g., where capacity is expressed as the number of tokens).

[0105] In an embodiment, the channel register for a given channel further includes a LOCAL_IDC (Local_IDC) register, which is a store of local indicator values ​​(e.g., the value of the "Get" indicator when the mode register specifies an input, or the value of the "Place" indicator when the mode register specifies an output). Furthermore, a REMOTE_IDC (Remote_IDC) register is a store of remote indicator values ​​(e.g., the value of the "Place" indicator when the mode register specifies an input, or the value of the "Get" indicator when the mode register specifies an output). Still further, an IDC_SHARE (IDC_Shared) register is a store of the address where the local indicator is to be shared as part of a notification.

[0106] In an embodiment, the channel register for a given channel further includes an index register, which is a store of indices for the next available token or space. Additionally, an available register indicates available space (such as the number of available tokens). Furthermore, a status register indicates the current status of the terminal assigned to the channel in question. In an embodiment, the current status is one of several possible states, including ARMED, UNARMED, and UNKNOWN. The value of the index register is valid only when the corresponding status register is in an ARMED or UNARMED state. Similarly, the value of the available register is valid only when the corresponding status register is in an ARMED or UNKNOWN state.

[0107] In some embodiments, the provisioning status value for a given channel indicates that sufficient tokens or space are available for the terminal, thus satisfying the firing condition for that terminal. In some embodiments, the firing rule for a given node can be checked by combining the provisioning statuses of all terminals associated with that node. In some embodiments, upon receiving a non-blocking request (e.g., a check) or blocking request command (e.g., information flag all (ALL) asserted) for a given node via the PI interface, the SDF manager checks the status of all channels associated with the terminal of the specified node, and only determines that the firing rule is satisfied and returns a true value if all channels are provisioned. In some embodiments, if one or more associated status registers are not provisioned, the SDF manager determines that the firing rule is not satisfied and returns a false value in response to the non-blocking check command, or waits to send a response to the blocking request command. In the latter case, in some embodiments, the SDF manager will actually wait to send a response until the firing rule for the task is satisfied. In some embodiments, if no response to the request command is received, the processor associated with the SDF manager will automatically stop until a response is received. In some embodiments, if a node's triggering rules are not met, a request to that node will automatically cause the processor to stop, thereby halting the node executing on that processor and providing the node with fully data-driven self-scheduling behavior. This halting can be implemented using clock gating of the processor core, for example, automatically conserving power when no progress is being made in processing.

[0108] In some embodiments, the SDF manager includes a logic circuitry system to implement a state machine, and for a particular channel, a given state register transitions between equipped, unequipped, and unknown states in various ways according to the state machine.

[0109] In an illustrative scenario according to one embodiment, a given status register is set to an unknown state during certain initialization, reset, or other appropriate events. In such an embodiment, the status register can conditionally transition from an unknown state to either a equipped or unequipped state, and must return to the unknown state before being conditionally transitioned to either a equipped or unequipped state. By way of illustration and not limitation, the transition of the status register from an unknown state to an equipped state is performed in response to a condition in which the value indicated by the corresponding available register is greater than or equal to the sum of the corresponding values ​​of the corresponding rate register and the corresponding reserved register.

[0110] In one such embodiment, in response to an event in which the corresponding LOCAL_IDC register is updated or the corresponding reserved register value is increased, the status register is transitioned from an equipped state back to an unknown state. In either case, a port that previously had sufficient tokens or space available to obtain an equipped state will now have fewer available tokens or space and may therefore become unequipped under certain conditions. By changing the equipped state back to unknown, in some embodiments a new evaluation of the correct state will be triggered.

[0111] Furthermore, the transition of the status register from an unknown state to an unequipped state is performed in response to a condition in which the value indicated by the corresponding available register is less than the sum of the corresponding values ​​of the corresponding rate register and the corresponding reserved register.

[0112] Furthermore, in response to events including writing to the corresponding REMOTE_IDC register or decreasing the value of the corresponding reserved register, the execution status register is transitioned from an unequipped state to an unknown state. In either case, terminals that previously resulted in an unequipped state due to insufficient available tokens or space will now have more available tokens or space and may therefore become equipped under certain conditions. By changing the unequipped state back to an unknown state, a new evaluation of the correct state will be triggered.

[0113] In some embodiments, during configuration time, the SDF graph API running on a processor in a multiprocessor system declares a channel for each terminal of each node assigned to a given processor associated with the SDF manager. In some embodiments, one of the processors (e.g., the "master" processor) records this information in a TERMINAL_ID register for the declared channel. In some embodiments, the mode register, rate register, capacity register, and IDC_SHARE register for a given terminal are also configured, for example, in the same channel. In some embodiments, during application execution, whenever the SDF manager receives a command from the SDFFC, the SDF manager operates on each channel covered by all (ALL) flags contained in the task and port identifiers included in the address and the information sideband signals associated with the SDFFC command.

[0114] In some embodiments, the reserved register of the channel register is incremented by a rate (RATE) each time a "reserve" command is issued, or the reserved register of the channel register is decremented by a rate (RATE) each time a "cancel" command is issued.

[0115] In some embodiments, the LOCAL_IDC register of the channel register is updated each time a "complete" command is issued. In some embodiments, this update involves incrementing the LOCAL_IDC value modulo twice the capacity value.

[0116] In some embodiments, the REMOTE_IDC register is updated each time the SDF manager detects a remote indicator write (e.g., due to a "notification" initiated by a remote processor), while simultaneously listening for incoming write requests on the TTI interface. In some embodiments, the update involves storing the write data of the listened-for write request in the REMOTE_IDC register of the channel identified by a channel index field derived from the address of the listened-for write request.

[0117] Figure 9 The figure illustrates Table 900 according to an embodiment, which lists the SDF manager's scheduling registers for a single SDF node (and corresponding task). Figure 5 An example of the scheduling register 552 in the document. In various embodiments, the SDF management function is extended using additional registers (referred to herein as the "scheduling register") that provide pre-computed status information for each task—for example, where, for each of one or more tasks, this status information identifies whether the task is currently eligible to be executed. In one such embodiment, the eligibility requirement for a given task to be executed is such that all channels associated with that task have their corresponding status registers set to equipped.

[0118] In the example embodiment shown, the scheduling register for a given node (representing a node assigned a task with a task identifier n) includes an eligibility register indicating whether the task in question (with task identifier n) is currently eligible to be executed. At any given time during the application's runtime execution, the eligibility register for a given task is in one of several states, including an "eligible" state indicating that the triggering rule for the task in question is currently satisfied, and an "uneligible" state indicating that the triggering rule is currently not satisfied. The SDF manager provides the ability to update such eligibility registers during runtime execution, for example, based on the current state of the corresponding channel registers for one or more corresponding channels (e.g., arcs) used to provide input to and / or output to the node in question in various ways. In some embodiments, the SDF manager further provides the ability to generate a response to a node identification request based on the corresponding eligibility registers for one or more nodes. In one such embodiment, the response identifies a particular node as currently eligible and the next node to be executed.

[0119] In some embodiments, the scheduling register for a given node further includes an activity register, which is a repository of starting address identifiers for the task in question (i.e., the task with task identifier n). In one such embodiment, the SDF manager responds to a node identifier request by providing such a starting address to a requester agent (such as an SDFFC from which it receives a node identifier request).

[0120] In an illustrative scenario according to one embodiment, the SDF manager responds to a node identification request by identifying the next node to be executed, wherein the identified node is selected by the SDF manager from a plurality of currently eligible nodes. The selection of a node is based, for example, on the priority of some or all SDF nodes relative to each other, although some embodiments are not limited in this respect. By way of illustration and not limitation, the scheduling register for a given node further includes a priority register that identifies the scheduling priority level currently assigned to the represented task.

[0121] In an example embodiment, the SDF manager selects the next node to be scheduled for execution, where this selection is based on the corresponding priority level of the currently eligible nodes. For example, the SDF manager creates one or more lists of eligible nodes for execution using corresponding priority levels—for example, where each such list corresponds to a different corresponding priority level, and where nodes in a given such list each have the same priority. In one such embodiment, the SDF manager checks each list for eligible nodes—for example, starting with the highest priority list. If an eligible node is found in this list, that node is selected as the node to be identified in the response to a node identification request. If no such node is found in the list, the SDF manager checks the list corresponding to the next lower priority level and returns an eligible node from that list (if found). Otherwise, the SDF manager proceeds sequentially through the lower priority lists until any eligible node is found, or until no more lists are available for review. In some embodiments, the traversal across all such lists is done in parallel—for example, within a single clock cycle in the hardware.

[0122] In one such embodiment, the scheduling register for a given node further includes a raise (RAISE) register, which indicates whether the priority indicated by the current value of the corresponding priority register should be gradually increased. In some embodiments, gradually increasing the priority corresponds to increasing (or, in another embodiment, decreasing) the value of the priority register. Alternatively or additionally, increasing the priority is prevented if, for example, the priority register already represents the maximum possible priority value. In various embodiments, the raise register is automatically reset to "0" after a clock cycle of updating the priority register.

[0123] Furthermore, the scheduling register of a given node further includes a LOWER register, which indicates whether the priority indicated by the current value of the corresponding priority register should be gradually reduced. In some embodiments, gradually reducing the priority corresponds to decreasing (or, in another embodiment, increasing) the value of the priority register. Alternatively or additionally, priority reduction is prevented if, for example, the priority register already represents the lowest possible priority value. In various embodiments, the LOWER register is automatically reset to "0" after a clock cycle of updating the priority register.

[0124] In various embodiments, such priority changes can be initiated, for example, by hardware, by host software, or by firmware (e.g., firmware running on a processor that includes, is coupled to, or is otherwise associated with an SDF manager). In one such embodiment, a watchdog timer is used to automatically increase the priority of a given task, for example, based on determining that the task in question has not been scheduled after a time period of a threshold length. Alternatively or additionally, the firmware running on the processor provides the functionality to selectively decrease the priority of a given task, for example, based on determining by the firmware that the task has been executed a sufficient number of times within a given time period.

[0125] Figure 10 The diagram illustrates a state transition state machine 1000 according to an embodiment, used to determine the eligibility state of a node (and the task represented by the node) in an SDF graph. In some embodiments, the SDF manager 124 (or, for example, SDF manager circuitry 424) includes a logic circuitry system to implement the state machine 1000. In some embodiments, the SDF manager circuitry system implements the state machine 1000 for a particular node by transitioning the corresponding eligibility register in various ways between an invalid (INVALID) state, a yes (YES) (i.e., eligible) state, a no (NO) (i.e., unqualified) state, and a possible (MAYBE) state.

[0126] In some embodiments, the value of the eligibility register (for a given task assigned a task identifier n) is automatically calculated based on the corresponding value(s) of each status register(s) corresponding to a channel having a TASK_ID also set to n, for example, recalculated once or more during application runtime. Accordingly, the value of this eligibility register changes over time based on events affecting one or more status registers corresponding to the task in question.

[0127] In some embodiments, an invalid state indicates that the corresponding task is not currently a valid task—for example, where the state may indicate that it is currently uncertain whether the activation rules for the (valid) task in question are met. In one such embodiment, a negative state confirms that the activation rules for the task are not currently met—for example, a positive state confirms that the activation rules for the task are currently met.

[0128] In an illustrative scenario according to one embodiment, such a qualification register is set to an invalid state during certain initialization, reset, or other appropriate events. In one such embodiment, the qualification register can conditionally transition from an invalid state to a possible state. The qualification register can conditionally transition from a possible state to any one of a yes state, a no state, or an invalid state. The qualification register can conditionally transition from any one of a yes state or a no state to any one of a possible state or an invalid state.

[0129] In the example embodiment shown, the eligibility register for a given task n is set to an invalid state based on initialization, reset, or other appropriate event. Alternatively or additionally, such eligibility registers are set to an invalid state based on receiving an INVALIDATE command (e.g., from SDFFC). Alternatively or additionally, such eligibility registers are set to an invalid state if it is determined that for each channel whose corresponding TASK_ID is set to n, the corresponding valid register of the channel register is de-asserted (e.g., each such channel valid register is set to "0" to indicate channel invalidity).

[0130] In one such embodiment, if it is determined that for at least one channel whose corresponding TASK_ID is set to n, the corresponding valid register of the channel register is asserted (e.g., at least one channel will set the valid register to "1" to indicate channel validity), the eligibility register for a given task n changes from an invalid state to a possible state. Furthermore, if it is determined that for each currently valid channel whose corresponding TASK_ID is set to n, the corresponding status register of the channel register is currently in an equipped state, the eligibility register for a given task n changes from a possible state to a yes state. Further still, if it is determined that for at least one currently valid channel whose corresponding TASK_ID is set to n, the corresponding status register of the channel register is currently in an unequipped state, the eligibility register for a given task n changes from a possible state to a no state.

[0131] Furthermore, if it is determined that for at least one currently active channel with its corresponding TASK_ID set to n, the corresponding status register of the channel register is not currently in an equipped state, the eligibility register for a given task n changes from a yes state to a possible state. Further, if it is determined that for each currently active channel with its corresponding TASK_ID set to n, the corresponding status register of the channel register is not currently in an unequipped state, the eligibility register for a given task n changes from a no state to a possible state.

[0132] Figure 11 The diagram illustrates the input and output ports of an SDFFC 1100 (e.g., SDF circuit 108 or SDFFC 408) according to an embodiment. In some embodiments, multiple scalar input ports (shown as two scalar input ports ip0 and ip1) are connected from the processor data path (e.g., ... Figure 1 The scalar register file within the processor 102 receives the arguments. In some embodiments, multiple scalar output ports (shown as two scalar output ports op0 and op1) serve as processor data paths (e.g., ...). Figure 1The results are produced by the scalar register file within the processor 102. In some embodiments, (e.g., a) vector output port (shown as vp2) is the processor data path (e.g., ...). Figure 1 The vector register file in the processor 102 produces the results. In some embodiments, the memory-mapped request port (shown as mm_req) and the memory-mapped response port (shown as mm_res) are connected to the PI interface of the SDF manager and include, for example, any of the I / O signals (e.g., values) of various common memory maps. In some embodiments, the signals for the mm_req request port include one or any combination of the following: valid, write enabled, data type, address, write data (e.g., unused), and sideband information signals. In some embodiments, the signals for the mm_res response port include one or any combination of the following: a response valid signal and a response data signal. In some embodiments, the response data signal is capable of transmitting a vector of data elements, for example, where the highest-numbered element contains a scalar result (such as, but not limited to, a Boolean value indicating whether a triggering rule is satisfied), while other elements each represent a data element (such as, but not limited to, an index of the next available token or space at each terminal of the requesting node). Exemplary Computer Architecture

[0133] The following is a detailed description of an exemplary computer architecture. Other system designs and configurations known in the art for laptops, desktop computers, handheld personal computers (PCs), personal digital assistants, engineering workstations, servers, discrete servers, network devices, network hubs, switches, routers, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, cellular phones, portable media players, handheld devices, and various other electronic devices are also suitable. In general, various systems or electronic devices capable of incorporating processors and / or other execution logic as disclosed herein are generally suitable.

[0134] Figure 12The figure illustrates an exemplary system. The multiprocessor system 1200 is a point-to-point interconnect system and includes multiple processors, including a first processor 1270 and a second processor 1280 coupled via a point-to-point interconnect 1250. In some examples, the first processor 1270 and the second processor 1280 are homogeneous. In some examples, the first processor 1270 and the second processor 1280 are heterogeneous. Although the exemplary system 1200 is shown as having two processors, the system may have three or more processors, or it may be a single-processor system.

[0135] Processors 1270 and 1280 are shown as including integrated memory controller (IMC) circuitry systems 1272 and 1282, respectively. Processor 1270 also includes point-to-point (PP) interfaces 1276 and 1278 as part of its interconnect controller; similarly, the second processor 1280 includes PP interfaces 1286 and 1288. Processors 1270 and 1280 can exchange information via a point-to-point (PP) interconnect 1250 using the point-to-point (PP) interface circuitry 1278 and 1288. IMCs 1272 and 1282 couple processors 1270 and 1280 to corresponding memories, namely memories 1232 and 1234, which may be portions of the main memory locally attached to the respective processor.

[0136] Processors 1270 and 1280 can each exchange information with chipset 1290 via respective PP interconnects 1252 and 1254 using point-to-point interface circuits 1276, 1294, 1286, and 1298. Chipset 1290 can optionally exchange information with coprocessor 1238 via interface 1292. In some examples, coprocessor 1238 is a dedicated processor, such as, for example, a high-throughput processor, a network or communication processor, a compression engine, a graphics processor, a general-purpose graphics processing unit (GPGPU), a neural-network processing unit (NPU), an embedded processor, etc.

[0137] A shared cache (not shown) may be included in either of the processors 1270 and 1280, or external to these processors but connected to them via a PP interconnect, such that if the processors are placed in a low-power mode, the local cache information of either or both processors may be stored in the shared cache.

[0138] Chipset 1290 may be coupled to a first interconnect 1216 via interface 1296. In some examples, the first interconnect 1216 may be a Peripheral Component Interconnect (PCI) interconnect or an interconnect such as a PCI Fast Interconnect or another I / O interconnect. In some examples, one interconnect is coupled to a power control unit (PCU) 1217, which may include circuitry, software, and / or firmware for performing power management operations in relation to processors 1270, 1280, and / or coprocessor 1238. PCU 1217 provides control information to a voltage regulator (not shown) to cause the voltage regulator to generate an appropriate regulated voltage. PCU 1217 also provides control information to control the generated operating voltage. In various examples, PCU 1217 may include various power management logic units (circuitry) for performing hardware-based power management. Such power management can be entirely controlled by the processor (e.g., by various processor hardware, and it can be triggered by workload and / or power, thermal constraints, or other processor constraints), and / or power management can be performed in response to external sources (such as platform or power management sources or system software).

[0139] The PCU 1217 is illustrated as logic separate from processors 1270 and / or 1280. In other cases, the PCU 1217 may execute on one or more cores of processors 1270 or 1280 (not shown). In some cases, the PCU 1217 may be implemented as a (dedicated or general-purpose) microcontroller or other control logic configured to execute its own dedicated power management code (sometimes referred to as P-code). In still other examples, the power management operations to be performed by the PCU 1217 may be implemented externally to the processor, such as through a separate power management integrated circuit (PMIC) or another component external to the processor. In still other examples, the power management operations to be performed by the PCU 1217 may be implemented within the BIOS or other system software.

[0140] Various I / O devices 1214 may be coupled to a first interconnect 1216 via a bus bridge 1218, which in turn couples the first interconnect 1216 to a second interconnect 1220. In some examples, one or more additional processors 1215 (such as coprocessors, high-throughput many-integrated-core (MIC) processors, GPGPUs, accelerators (such as graphics accelerators or digital signal processing (DSP) units), field-programmable gate arrays (FPGAs), or any other processors) are coupled to the first interconnect 1216. In some examples, the second interconnect 1220 may be a low-pin-count (LPC) interconnect. Various devices may be coupled to the second interconnect 1220, including, for example, a keyboard and / or mouse 1222, a communication device 1227, and a storage circuitry 1228. The storage circuitry 1228 may be one or more non-transitory machine-readable storage media as described below, such as a disk drive or other mass storage device that may include instruction / code and data 1230 in some examples. Furthermore, the audio I / O 1224 can be coupled to the second interconnect 1220. Note that other architectures besides the point-to-point architecture described above are also possible. For example, instead of a point-to-point architecture, systems such as the multiprocessor system 1200 can implement multi-branch interconnects or other such architectures. Exemplary core architecture, processor, and computer architecture.

[0141] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, such core implementations can include: 1) general-purpose ordered cores designed for general-purpose computing; 2) high-performance general-purpose out-of-order cores designed for general-purpose computing; and 3) dedicated cores designed primarily for graphics and / or scientific (throughput) computing. Different processor implementations can include: 1) CPUs, which include one or more general-purpose ordered cores and / or one or more general-purpose out-of-order cores designed for general-purpose computing; and 2) coprocessors, which include one or more dedicated cores designed primarily for graphics and / or scientific (throughput) computing. These different processors give rise to different computer system architectures, which may include: 1) a coprocessor on a separate chip from the CPU; 2) a coprocessor in the same package as the CPU but on a separate die; 3) a coprocessor on the same die as the CPU (in this case, such a coprocessor is sometimes referred to as dedicated logic or a dedicated core, such as integrated graphics and / or scientific (throughput) logic); and 4) a system-on-a-chip (SoC), which may be included on the same die as the described CPU (sometimes referred to as one or more application cores or one or more application processors), the coprocessors described above, and additional functionality. An exemplary core architecture is then described, followed by exemplary processor and computer architectures.

[0142] Figure 13 The diagram illustrates a block diagram of an example processor 1300 that may have more than one core and may have an integrated memory controller. Solid-line boxes illustrate a processor 1300 having a single core 1302A, a system proxy unit circuitry 1310, and a set of one or more interconnect controller unit circuitry 1316, while dashed-line boxes optionally illustrate an alternative processor 1300 having multiple cores 1302A-1302N, a set of one or more integrated memory controller units 1314 in the system proxy unit circuitry 1310, and a set of dedicated logic 1308 and one or more interconnect controller unit circuitry 1316. Note that processor 1300 may be... Figure 12 One of the processors 1270 or 1280, or the coprocessor 1238 or 1215.

[0143] Therefore, different implementations of processor 1300 may include: 1) a CPU, wherein dedicated logic 1308 is an integrated graphics device and / or scientific (throughput) logic (which may include one or more cores, not shown), and cores 1302A-1302N are one or more general-purpose cores (e.g., general-purpose ordered cores, general-purpose out-of-order cores, or a combination of both); 2) a coprocessor, wherein cores 1302A-1302N are a large number of dedicated cores designed primarily for graphics and / or scientific (throughput); and 3) a coprocessor, wherein cores 1302A-1302N are a large number of general-purpose ordered cores. Thus, processor 1300 may be a general-purpose processor, a coprocessor, or a dedicated processor, such as, for example, a network or communication processor, a compression engine, a graphics processor, a GPGPU (general purpose graphics processing unit circuitry), a high-throughput many-integrated-core (MIC) coprocessor (including 30 or more cores), an embedded processor, etc. The processor may be implemented on one or more chips. The processor 1300 may be part of one or more substrates and / or implemented on one or more substrates using any of a variety of process technologies, such as, for example, complementary metal-oxide-semiconductor (CMOS), bipolar CMOS (BiCMOS), P-type metal oxide semiconductor (PMOS), or N-type metal oxide semiconductor (NMOS).

[0144] The memory hierarchy includes one or more levels of cache cell circuitry 1304A-1304N within cores 1302A-1302N, a collection of one or more shared cache cell circuitry 1306, and external memory (not shown) coupled to a collection of one or more integrated memory controller cell circuitry 1314. The collection of one or more shared cache cell circuitry 1306 may include one or more intermediate-level caches (such as level 2, L2, level 3, L3, level 4, L4) or other-level caches (such as last-level cache, LLC) and / or combinations thereof. While in some examples a ring-based interconnect network circuitry 1312 interconnects dedicated logic 1308 (e.g., integrated graphics logic), the collection of one or more shared cache cell circuitry 1306, and system proxy cell circuitry 1310, alternative examples use any number of known techniques for interconnecting such cells. In some examples, consistency is maintained between one or more of the shared cache unit circuitry 1306 and cores 1302A-1302N.

[0145] In some examples, one or more cores of cores 1302A-1302N are capable of multi-threaded operation. System agent unit circuitry 1310 includes components that coordinate and operate cores 1302A-1302N. System agent unit circuitry 1310 may include, for example, a power control unit (PCU) circuitry and / or a display unit circuitry (not shown). The PCU may be, or may include, the logic and components required to regulate the power states of cores 1302A-1302N and / or dedicated logic 1308 (e.g., integrated graphics logic). The display unit circuitry is used to drive one or more externally connected displays.

[0146] Cores 1302A-1302N can be homogeneous in terms of instruction set architecture (ISA). Alternatively, cores 1302A-1302N can be heterogeneous in terms of ISA; that is, a subset of cores 1302A-1302N may be able to execute an ISA, while other cores may be able to execute only that ISA or a subset of another ISA. Exemplary core architecture—ordered and out-of-order core block diagrams.

[0147] Figure 14A This is a block diagram illustrating both an exemplary ordered pipeline and an exemplary register renaming, out-of-order issue / execution pipeline, based on the example. Figure 14BThis is a block diagram illustrating both an exemplary example of an ordered architecture core to be included in a processor and an exemplary register renaming, out-of-order issue / execution architecture core, based on the example. Figures 14A-14B The solid-line boxes in the diagram illustrate ordered pipelines and ordered cores, while the optional additions of dashed boxes illustrate register renaming, out-of-order issue / execution pipelines, and cores. Since the ordered aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described.

[0148] exist Figure 14A In this processor pipeline 1400, a fetch phase 1402, an optional length-decode phase 1404, a decode phase 1406, an optional alloc phase 1408, an optional rename phase 1410, a scheduling (also called dispatch or issue) phase 1412, an optional register read / memory read phase 1414, an execution phase 1416, a write-back / memory write phase 1418, an optional exception handling phase 1422, and an optional commit phase 1424 can be performed in each of these processor pipeline phases. For example, during the fetch phase 1402, one or more instructions are fetched from instruction memory, and during the decode phase 1406, the fetched instructions can be decoded, an address using the forwarded register port (e.g., a load store unit (LSU) address) can be generated, and branch forwarding (e.g., an immediate offset or a link register (LR)) can be performed. In one example, the decoding phase 1406 and the register read / memory read phase 1414 can be combined into a single pipeline phase. In one example, during the execution phase 1416, decoded instructions can be executed, LSU address / data pipelined to the Advanced Microcontroller Bus (AMB) interface can be executed, multiplication and addition operations can be performed, arithmetic operations with branch results can be performed, and so on.

[0149] As an example, Figure 14BThe exemplary register renaming, out-of-order issue / execution architecture core can implement pipeline 1400 as follows: 1) Instruction fetch circuitry 1438 executes fetch phase 1402 and length decoding phase 1404; 2) Decoding circuitry 1440 executes decoding phase 1406; 3) Rename / allocator unit circuitry 1452 executes allocation phase 1408 and rename phase 1410; 4) (one or more) scheduler circuitry 1456 executes scheduling phase 1412; 5) (one or more) physical register file circuitry 14 58 and memory cell circuit system 1470 perform register read / memory read phase 1414; (one or more) execution cluster 1460 performs execution phase 1416; 6) memory cell circuit system 1470 and (one or more) physical register file circuit system 1458 perform write-back / memory write phase 1418; 7) individual circuit systems may be involved in exception handling phase 1422; and 8) retirement unit circuit system 1454 and (one or more) physical register file circuit system 1458 perform commit phase 1424.

[0150] Figure 14B A processor core 1490 is shown, which includes a front-end unit circuitry 1430 coupled to an execution engine unit circuitry 1450, and both are coupled to a memory unit circuitry 1470. The core 1490 can be a reduced instruction set architecture computing (RISC) core, a complex instruction set architecture computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. Alternatively, the core 1490 can be a dedicated core, such as, for example, a network or communication core, a compression engine, a coprocessor core, a general-purpose computing graphics processing unit (GPGPU) core, a graphics core, and so on.

[0151] Front-end unit circuitry 1430 may include branch prediction circuitry 1432 coupled to instruction cache circuitry 1434, which is coupled to translation lookaside buffer (TLB) 1436, which is coupled to instruction fetch circuitry 1438, which is coupled to decode circuitry 1440. In one example, instruction cache circuitry 1434 is included in memory cell circuitry 1470 instead of front-end circuitry 1430. Decode circuitry 1440 (or decoder) decodes instructions and generates one or more micro-operations, microcode entry points, microinstructions, other instructions, or other control signals as output, which are decoded from, or otherwise reflect, the original instructions or derived from the original instructions. Decode circuitry 1440 may further include address generation unit (AGU, not shown) circuitry. In one example, the AGU uses the forwarded register port to generate the LSU address and can further perform branch forwarding (e.g., immediate offset branch forwarding, LR register branch forwarding, etc.). The decoding circuitry 1440 can be implemented using various mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLAs), microcode read-only memory (ROMs), etc. In one example, core 1490 includes a microcode ROM (not shown) or other medium (e.g., within the decoding circuitry 1440, or otherwise within the front-end circuitry 1430) storing microcode for certain macro instructions. In one example, the decoding circuitry 1440 includes micro-ops or operation caches (not shown) to save / cachive decoded operations, microtags, or micro-operations generated during the decoding phase or other phases of the processor pipeline 1400. The decoding circuitry 1440 may be coupled to the rename / allocator unit circuitry 1452 within the execution engine circuitry 1450.

[0152] The execution engine circuitry 1450 includes a renaming / allocator unit circuitry 1452, which is coupled to a retirement unit circuitry 1454 and a set of one or more scheduler circuitry systems 1456. The scheduler circuitry system 1456 represents any number of different schedulers, including reservation stations, central command windows, etc. In some examples, the scheduler circuitry system 1456 may include an arithmetic logic unit (ALU) scheduler / scheduling circuitry, an ALU queue, an arithmetic generation unit (AGU) scheduler / scheduling circuitry, an AGU queue, etc. The scheduler circuitry system 1456 is coupled to one or more physical register file circuitry systems 1458. Each physical register file circuit system in (one or more) physical register file circuit systems 1458 represents one or more physical register files, wherein different physical register files store one or more different data types, such as scalar integers, scalar floating-point numbers, compressed integers, compressed floating-point numbers, vector integers, vector floating-point numbers, status (e.g., an instruction pointer as the address of the next instruction to be executed), etc. In one example, (one or more) physical register file circuit systems 1458 include vector register unit circuit systems, write mask register unit circuit systems, and scalar register unit circuit systems. These register units can provide architectural vector registers, vector mask registers, general-purpose registers, etc. One or more physical register file circuitry systems 1458 are coupled to retirement unit circuitry systems 1454 (also referred to as a retirement queue) to illustrate various ways register renaming and out-of-order execution can be implemented (e.g., using one or more reorder buffers (ROBs) and one or more retirement register files; using one or more future files, one or more history buffers, and one or more retirement register files; using register mappings and register pools, etc.). Retirement unit circuitry systems 1454 and one or more physical register file circuitry systems 1458 are coupled to one or more execution clusters 1460. Execution clusters 1460 include a set of one or more execution unit circuitry systems 1462 and a set of one or more memory access circuitry systems 1464. One or more execution unit circuit systems 1462 can perform various arithmetic, logical, floating-point or other types of operations (e.g., shift, addition, subtraction, multiplication) and can perform operations on various data types (e.g., scalar integer, scalar floating-point, compressed integer, compressed floating-point, vector integer, vector floating-point).While some examples may include multiple execution units or execution unit circuitry systems dedicated to a specific function or set of functions, other examples may include only one execution unit circuitry system or multiple execution units / execution unit circuitry systems that all perform all functions. One or more scheduler circuitry systems 1456, one or more physical register file circuitry systems 1458, and one or more execution clusters 1460 are shown as potentially multiple because some examples create separate pipelines for certain types of data / operations (e.g., scalar integer pipelines, scalar floating-point / compact integer / compact floating-point / vector integer / vector floating-point pipelines, and / or memory access pipelines each having their own scheduler circuitry system, one or more physical register file circuitry systems, and / or execution clusters—and in the case of separate memory access pipelines, some examples implement where only the execution cluster of that pipeline has one or more memory access circuitry systems 1464). It should also be understood that, in the case of using separate pipelines, one or more of these pipelines may be out-of-order releases / executions, and the remaining pipelines may be ordered releases / executions.

[0153] In some examples, the execution engine unit circuit system 1450 can perform load storeunit (LSU) address / data pipelined to the Advanced Microcontroller Bus (AMB) interface (not shown), as well as address phased and write-back, data phased loading, storage, and branching.

[0154] The set of memory access circuitry 1464 is coupled to memory cell circuitry 1470, which includes data TLB circuitry 1472, which is coupled to data cache circuitry 1474, which is coupled to level 2 (L2) cache circuitry 1476. In one exemplary example, memory access circuitry 1464 may include load cell circuitry, memory address cell circuitry, and memory data cell circuitry, each of which is coupled to data TLB circuitry 1472 in memory cell circuitry 1470. Instruction cache circuitry 1434 is further coupled to level 2 (L2) cache circuitry 1476 in memory cell circuitry 1470. In one example, instruction cache 1434 and data cache 1474 are combined into L2 cache circuitry 1476, level 3 (L3) cache circuitry (not shown), and / or a single instruction and data cache (not shown) in main memory. The L2 cache circuitry system 1476 is coupled to one or more other cache levels and ultimately to main memory.

[0155] Core 1490 may support one or more instruction sets (e.g., x86 instruction set architecture (optionally with some extensions added with newer versions); MIPS instruction set architecture; ARM instruction set architecture (optionally with optional additional extensions such as NEON)), including one or more instructions described herein. In one example, core 1490 includes logic for supporting compact data instruction set architecture extensions (e.g., AVX1, AVX2), thereby allowing the use of compact data to perform operations used by many multimedia applications. Exemplary (one or more) execution unit circuit systems.

[0156] Figure 15 The diagram illustrates examples of one or more execution unit circuit systems, such as... Figure 14B The system comprises one or more execution unit circuitry systems 1462. As shown, the execution unit circuitry system 1462 may include one or more ALU circuits 1501, optional vector / single instruction multiple data (SIMD) circuitry 1503, load / store circuitry 1505, branch / jump circuitry 1507, and / or floating-point unit (FPU) circuitry 1509. ALU circuitry 1501 performs integer arithmetic and / or Boolean operations. Vector / SIMD circuitry 1503 performs vector / SIMD operations on compressed data (such as SIMD / vector registers). Load / store circuitry 1505 executes load and store instructions to load data from memory into registers or store data from registers into memory. Load / store circuitry 1505 may also generate addresses. Branch / jump circuitry 1507 causes a branch or jump to a memory address depending on the instruction. FPU circuitry 1509 performs floating-point arithmetic. The width of the (one or more) execution unit circuit system 1462 varies depending on the example and can range from, for example, 16 bits to 1024 bits. In some examples, two or more smaller execution units are logically combined to form a larger execution unit (e.g., two 128-bit execution units are logically combined to form a 256-bit execution unit). Exemplary Register Architecture

[0157] Figure 16This is a block diagram of register architecture 1600 based on some examples. As shown, register architecture 1600 includes vector / SIMD registers 1610, whose width varies from 128 bits to 1024 bits. In some examples, vector / SIMD register 1610 is physically 512 bits, and depending on the mapping, only some of the lower bits are used. For example, in some examples, vector / SIMD register 1610 is a 512-bit ZMM register: the lower 256 bits are used for the YMM register, and the lower 128 bits are used for the XMM register. Thus, there is a stacking of registers. In some examples, the vector length field is selected between a maximum length and one or more other shorter lengths, where each such shorter length is half the length of the previous length. Scalar operations are performed on the lowest-order data element positions in the ZMM / YMM / XMM registers; depending on the example, higher-order data element positions remain the same as before the instruction or are zeroed out.

[0158] In some examples, the register architecture 1600 includes a write mask / predicate register 1615. For example, in some examples, there are eight write mask / predicate registers (sometimes referred to as k0 to k7), each with a size of 16 bits, 32 bits, 64 bits, or 128 bits. The write mask / predicate register 1615 may allow merging (e.g., allowing any set of elements in the destination to be exempt from updating during the execution of any operation) and / or zeroing (e.g., a zeroing vector mask allows any set of elements in the destination to be zeroed during the execution of any operation). In some examples, each data element position in a given write mask / predicate register 1615 corresponds to a data element position in the destination. In other examples, the write mask / predicate register 1615 is scalable and consists of a set number of enable bits for a given vector element (e.g., eight enable bits for each 64-bit vector element).

[0159] The register architecture 1600 includes several general-purpose registers 1625. These registers can be 16-bit, 32-bit, 64-bit, etc., and can be used for scalar operations. In some examples, these registers are referenced by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15.

[0160] In some examples, register architecture 1600 includes a scalar floating-point (FP) register 1645, which is used for scalar floating-point operations on 32 / 64 / 80-bit floating-point data using the x87 instruction set architecture extension, or as an MMX register to perform operations on 64-bit compressed integer data, and to store operation objects for some operations performed between the MMX and XMM registers.

[0161] One or more flag registers 1640 (e.g., EFLAGS, RFLAGS, etc.) store status and control information used for arithmetic, comparison, and system operations. For example, one or more flag registers 1640 may store condition code information such as carry, parity, auxiliary carry, zero, sign, and overflow. In some examples, one or more flag registers 1640 are referred to as program status and control registers.

[0162] Segment register 1620 contains segment points used when accessing memory. In some examples, these registers are referenced by the names CS, DS, SS, ES, FS, and GS.

[0163] The machine-specific register (MSR) 1635 controls and reports processor performance. Most MSRs 1635 handle system-related functions and are not accessible to applications. The machine check register 1660 consists of control, status, and error reporting MSRs, which are used to detect and report hardware errors.

[0164] One or more instruction pointer registers 1630 store instruction pointer values. One or more control registers 1655 (e.g., CR0-CR4) determine the operating mode of the processor (e.g., processors 1270, 1280, 1238, 1215, and / or 1300) and the characteristics of the currently executing task. Debug register 1650 controls and allows monitoring of debug operations on the processor or core.

[0165] Memory (mem) management register 1665 specifies the location of data structures used for protected mode memory management. These registers may include the GDTR, IDRT, task register, and LDTR register.

[0166] Alternative examples may use wider or narrower registers. Additionally, alternative examples may use more, fewer, or different register files and registers. Register architecture 1600 may be used, for example, in one or more physical register file circuit systems 1458.

[0167] The description herein includes numerous details to provide a more thorough explanation of embodiments of the present disclosure. However, it will be apparent to those skilled in the art that embodiments of the present disclosure may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the present disclosure.

[0168] Note that in the corresponding figures of the embodiments, lines are used to represent signals. Some lines may be thicker to indicate a greater number of component signal paths, and / or have arrows at one or more ends to indicate the direction of information flow. Such indications are not intended to be limiting. Rather, lines are used in conjunction with one or more exemplary embodiments to facilitate a more readily understood understanding of the circuit or logic unit. Any signal represented may practically include one or more signals that can travel in either direction, as specified by design needs or preferences, and may be implemented using any suitable type of signaling scheme.

[0169] Throughout the specification and in the claims, the term "connected" means a direct connection between connected objects, such as an electrical, mechanical, or magnetic connection, without any intermediary device. The term "coupled" means a direct or indirect connection, such as a direct electrical, mechanical, or magnetic connection between connected objects or an indirect connection via one or more passive or active intermediary devices. The terms "circuit" or "module" can refer to one or more passive and / or active components arranged to cooperate with each other to provide a desired function. The term "signal" can refer to at least one current signal, voltage signal, magnetic signal, or data / clock signal. The meanings of "a / an" and "the" include plural references. The meaning of "in" includes both "in" and "on".

[0170] The term "device" can generally refer to an arrangement depending on the context in which the term is used. For example, an device can refer to a stack of layers or structures, a single structure or layer, a connection of various structures with active and / or passive components, and so on. Generally, a device is a three-dimensional structure having a plane along the xy direction of the xyz Cartesian coordinate system and a height along the z direction. The plane of the device can also be the plane of the apparatus that includes the device.

[0171] The term "scaling" generally refers to converting a design (schematic and layout) from one process technology to another, and subsequently reducing its size within the layout area. The term "scaling" also generally refers to reducing the size of a layout and device within the same technology node. The term "scaling" can also refer to adjusting the signal frequency relative to another parameter (e.g., slowing down or speeding up—i.e., scaling down or scaling up, respectively).

[0172] The terms “substantially,” “close to,” “approximately,” “near,” and “about” generally refer to values ​​within + / - 10% of the target value. For example, unless otherwise specified in the explicit context of their use, the terms “substantially equal,” “approximately equal,” and “approximately equal” mean that there is only accidental variation between the objects so described. In the art, such variation typically does not exceed + / - 10% of the predetermined target value.

[0173] It should be understood that the terms used so are interchangeable where appropriate, for example, to enable the embodiments of the invention described herein to operate in other orientations than those illustrated or otherwise described herein.

[0174] Unless otherwise specified, the use of ordinal adjectives such as “first,” “second,” “third,” etc. to describe common objects merely indicates that different instances of similar objects are mentioned, and is not intended to imply that objects described in this way must be in a given order in time, space, ranking, or any other way.

[0175] The terms “left,” “right,” “front,” “rear,” “top,” “bottom,” “above,” “below,” etc. (if any) used in the specification and claims are for descriptive purposes and are not necessarily used to describe permanent relative positions. For example, the terms “above,” “below,” “front side,” “rear side,” “top,” “bottom,” “above,” “below,” and “on” as used herein refer to the relative position of a component, structure, or material with respect to other referenced components, structures, or materials within the device, where such physical relationships are significant. These terms are used herein solely for descriptive purposes, and these terms are primarily in the context of the device’s z-axis; therefore, these terms can be relative to the device’s orientation. Thus, in the context of the figures provided herein, a first material “above” a second material may also be “below” the second material if the device is oriented upside down relative to the context of the provided figures. In the context of materials, a material disposed above or below another material may be in direct contact or may have one or more intermediate materials. Furthermore, a material disposed between two materials may be in direct contact with both layers or may have one or more intermediate layers. In contrast, a first material “on” a second material is in direct contact with the second material. A similar distinction is made in the context of component assemblies.

[0176] The term "between" can be used in the context of the z-axis, x-axis, or y-axis of a device. A material between two other materials can be in contact with one or both of those two materials, or it can be separated from both of those two materials by one or more intermediary materials. Therefore, a material "between" two other materials can be in contact with either of those two materials, or it can be coupled to either of those two materials by an intermediary material. A device between two other devices can be directly connected to one or both of those two devices, or it can be separated from both of those two devices by one or more intermediary devices.

[0177] As used throughout the specification and in the claims, a list of items joined by the terms "at least one of..." or "one or more of..." may refer to any combination of the listed items. For example, the phrase "at least one of A, B, or C" may mean A; B; C; A and B; A and C; B and C; or A, B, and C. It should be noted that those elements of the drawings that have the same reference numerals (or names) as elements of any other drawing may operate or function in any manner similar to those described, but are not limited thereto.

[0178] Furthermore, the various elements of combinational and sequential logic discussed in this disclosure may relate to physical structures (such as AND gates, OR gates, or XOR gates) or to a synthetic or otherwise optimized collection of devices that implement the logic structure as the Boolean equivalent of the logic in question.

[0179] This document describes the techniques and architectures used for scheduling the execution of tasks. In the above description, numerous specific details are set forth for illustrative purposes to provide a thorough understanding of certain embodiments. However, it will be apparent to those skilled in the art that certain embodiments can be implemented without these specific details. In other instances, structures and devices are shown in block diagram form to avoid obscuring the description.

[0180] In this specification, references to "an embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment of the invention. The phrase "in an embodiment" appearing in different places throughout this specification does not necessarily refer to the same embodiment.

[0181] Some of the detailed descriptions in this paper present the algorithms and symbolic representations of operations on data bits within computer memory. These algorithmic descriptions and representations are methods used by those skilled in the art in the most effective way to convey their working nature to others skilled in the art. Algorithms are generally conceived here as self-consistent sequences of steps that achieve the desired result. These steps are those that require physical manipulation of physical quantities. Often, but not necessarily, these quantities take the form of electrical or magnetic signals that can be stored, transmitted, combined, compared, and otherwise manipulated. It has proven convenient, primarily for common purposes, to refer to these signals as bits, values, elements, symbols, characters, items, numbers, etc.

[0182] However, it should be remembered that all these and similar terms are associated with appropriate physical quantities and are merely convenient designations for those quantities. Unless otherwise explicitly stated, as will be apparent from the discussion herein, it should be understood that throughout the specification, the use of terms such as “processing” or “calculating” or “operating” or “determining” or “displaying” refers to the actions and processes of a computer system or similar electronic computing device that manipulates data represented as physical (electronic) quantities in the registers and memories of the computer system and converts them into other data similarly represented as physical quantities in the computer system’s memory or registers or other such information storage, transmission or display devices.

[0183] Some embodiments also relate to means for performing the operations described herein. Such means may be specifically configured for the desired purpose, or may include a general-purpose computer selectively activated or reconfigured by a computer program stored therein. Such computer programs may be stored in computer-readable storage media such as, but not limited to, any type of disk, including floppy disks, optical disks, CD-ROMs, magneto-optical disks, read-only memory (ROM), random access memory (RAM) (such as dynamic RAM (DRAM)), EPROM, EEPROM, magnetic cards or optical cards, or any type of media suitable for storing electronic instructions and coupled to a computer system bus.

[0184] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various general-purpose systems can be used with the programs based on the teachings herein, or it may prove convenient to construct more specialized devices to perform the required method steps. The necessary structures for various such systems will be presented from the description herein. Furthermore, some embodiments are not described with reference to any particular programming language. It will be appreciated that the teachings of such embodiments described herein can be implemented using various programming languages.

[0185] In one or more first embodiments, a Synchronous Data Flow (SDF) manager circuit includes: a first circuit system for performing a first access to one or more first registers during the runtime of an application modeled using an SDF graph, the SDF graph including: a plurality of nodes, each representing a corresponding task of the application, and one or more channels, each providing corresponding communication to or from a first node among the plurality of nodes, wherein the one or more first registers each correspond to a different corresponding channel among the one or more channels, and wherein the first access is used to determine for each of the one or more channels whether the channel is currently capable of accommodating the execution of a first task of the application; wherein the first circuit system is further configured to perform a second access to a second register corresponding to a first node based on the first access, wherein the second access is used to provide a value of a first status parameter of the second register, the value of which indicates whether the first task is currently eligible to be executed; and a second circuit system for performing a third access to the second register based on a request identifying the next task to be executed, the second circuit system being further configured to generate a response to the request based on the first status parameter.

[0186] In one or more second embodiments, further in the first embodiment, a response is used to indicate that no task can be identified as currently eligible to be executed.

[0187] In one or more third embodiments, further in the first or second embodiment, based on the inability to identify any node as representing a corresponding task currently eligible to be executed, the second circuit system is used to delay the generation of a response until the node is identified as eligible to be executed.

[0188] In one or more fourth embodiments, further in any one of the first to third embodiments, the first circuit system is further configured to perform a first update, the first update setting a first state parameter to a first value indicating that the first task is currently eligible to be executed; and the first update is based on a first indication of a first condition to one or more first registers, wherein: for each input channel to the first node, the total number of tokens in the input channel is sufficient to accommodate the execution of the first task; and for each output channel from the first node, the total available space in the output channel is sufficient to accommodate the execution of the first task.

[0189] In one or more fifth embodiments, further in a fourth embodiment, the first circuit system is further configured to perform a second update, which sets a first state parameter to a second value indicating that the first task is currently not eligible to be executed; and the second update is based on a second indication of a second condition to a second condition of one or more first registers, wherein: for at least one input channel to the first node, the total number of tokens in the input channel is insufficient to accommodate the execution of the first task; or for at least one output channel from the first node, the total available space in the output channel is insufficient to accommodate the execution of the first task.

[0190] In one or more sixth embodiments, further in any one of the first to third embodiments, the second circuit system for performing the third access includes: the second circuit system for accessing each of a second plurality of registers corresponding to different corresponding nodes in the SDF graph based on a request, wherein each of the second plurality of registers includes a corresponding status parameter indicating whether the corresponding node is eligible to be executed.

[0191] In one or more seventh embodiments, further in a sixth embodiment, based on a request, a second circuit system is configured to detect conditions in which a plurality of nodes are currently eligible to be executed; based on the conditions, the second circuit system is configured to perform a selection of a first node from the plurality of nodes; the selection is based on the relative priority of the plurality of nodes relative to each other; and a response is made to identify the first node based on the selection.

[0192] In one or more of the eighth embodiments, and further in the seventh embodiment, the SDF manager circuitry further includes a third circuit system coupled to the second circuit system, the third circuit system being configured to: receive information indicating whether to increase or decrease the priority of the first node during application runtime; and change the relative priorities of the plurality of nodes with respect to each other.

[0193] In one or more ninth embodiments, further in any of the first to third embodiments, upon request, the second circuit system is further configured to: access a third register including an identifier of the starting address of the first task; and provide the identifier of the starting address in a response to indicate that the first task is the next task to be executed.

[0194] In one or more tenth embodiments, a method at a Synchronous Data Flow (SDF) manager circuit includes: performing a first access to one or more first registers during the runtime of an application modeled using an SDF graph, the SDF graph including: a plurality of nodes, each representing a corresponding task of the application, and one or more channels, each providing corresponding communication to or from a first node among the plurality of nodes, wherein the one or more first registers each correspond to a different corresponding channel among the one or more channels, and wherein the first access determines, for each of the one or more channels, whether the channel is currently capable of accommodating the execution of a first task of the application; wherein a second access to a second register corresponding to a first node is performed based on the first access, wherein the second access provides a value of a first status parameter of the second register, the value being used to identify whether the first task is currently eligible to be executed; and performing a third access to the second register based on a request identifying the next task to be executed, and generating a response to the request based on the first status parameter.

[0195] In one or more eleventh embodiments, and further in a tenth embodiment, the response indicates that no task can be identified as currently eligible to be executed.

[0196] In one or more twelfth embodiments, and further in tenth or eleventh embodiments, the method further includes: delaying the generation of a response based on the inability to identify any node as representing a corresponding task currently eligible to be executed, until the node is identified as eligible to be executed.

[0197] In one or more thirteenth embodiments, and further in any one of the tenth to twelfth embodiments, the method further includes: performing a first update that sets a first state parameter to a first value indicating that a first task is currently eligible to be executed; wherein the first update is based on a first indication of a first condition to one or more first registers, wherein: for each input channel to the first node, the total number of tokens in the input channel is sufficient to accommodate the execution of the first task; and for each output channel from the first node, the total available space in the output channel is sufficient to accommodate the execution of the first task.

[0198] In one or more fourteenth embodiments, and further in a thirteenth embodiment, the method further includes: performing a second update that sets a first state parameter to a second value indicating that a first task is currently not eligible to be executed; wherein the second update is based on a second indication of a second condition to a second condition of one or more first registers, wherein: for at least one input channel to the first node, the total number of tokens in the input channel is insufficient to accommodate the execution of the first task; or for at least one output channel from the first node, the total available space in the output channel is insufficient to accommodate the execution of the first task.

[0199] In one or more of the fifteenth embodiments, further in any of the tenth to twelfth embodiments, performing the third access includes: accessing each of a second plurality of registers corresponding to different corresponding nodes in the SDF graph based on the request, wherein each of the second plurality of registers includes a corresponding status parameter indicating whether the corresponding node is eligible to be executed.

[0200] In one or more sixteenth embodiments, and further in a fifteenth embodiment, the method further includes: based on a request, detecting conditions in which a plurality of nodes are currently eligible to be executed; and based on the conditions, performing a selection of a first node from the plurality of nodes; wherein the selection is based on the relative priority of the plurality of nodes relative to each other; and responding to identify the first node based on the selection.

[0201] In one or more of the seventeenth embodiments, and further in the sixteenth embodiment, the method further includes: receiving information indicating whether to increase or decrease the priority of a first node during the runtime of the application; and changing the relative priority of the plurality of nodes relative to each other.

[0202] In one or more of the eighteenth embodiments, and further in any of the tenth to twelfth embodiments, the method further includes: accessing a third register, based on a request, an identifier including a starting address of a first task; and providing the identifier of the starting address in a response to indicate that the first task is the next task to be executed.

[0203] In one or more nineteenth embodiments, a system includes: a system bus; a plurality of processors, each coupled to the system bus, the plurality of processors including a first processor; and synchronous data flow (SDF) manager circuitry coupled between the system bus and the first processors, the SDF manager circuitry including: a first circuit system for performing a first access to one or more first registers during runtime of an application modeled using an SDF graph, the SDF graph including: a plurality of nodes, each representing a corresponding task of the application; and one or more channels, each providing corresponding communication to or from the first node among the plurality of nodes, wherein the one or more first registers each correspond to a different corresponding channel among the one or more channels, and wherein the first access is used to determine for each of the one or more channels whether the channel is currently capable of accommodating the execution of a first task of the application; wherein the first circuit system is further used to perform a second access to a second register corresponding to a first node based on the first access, wherein the second access is used to provide a value of a first status parameter of the second register, the value of which indicates whether the first task is currently eligible to be executed; and a second circuit system for performing a third access to the second register based on a request identifying the next task to be executed, the second circuit system further generating a response to the request based on the first status parameter.

[0204] In one or more twentieth embodiments, and further in the nineteenth embodiment, a response is provided to indicate that no task can be identified as currently eligible to be executed.

[0205] In one or more of the twenty-first embodiments, and further in the nineteenth or twentieth embodiment, based on the inability to identify any node as representing a corresponding task currently eligible to be executed, the second circuit system is used to delay the generation of a response until the node is identified as eligible to be executed.

[0206] In one or more twenty-second embodiments, and further in any of the nineteenth to twenty-first embodiments, the first circuit system is further configured to perform a first update, the first update setting a first state parameter to a first value indicating that the first task is currently eligible to be executed; and the first update is based on a first indication of a first condition to one or more first registers, wherein: for each input channel to the first node, the total number of tokens in the input channel is sufficient to accommodate the execution of the first task; and for each output channel from the first node, the total available space in the output channel is sufficient to accommodate the execution of the first task.

[0207] In one or more twenty-third embodiments, and further in a twenty-second embodiment, the first circuit system is further configured to perform a second update, which sets a first state parameter to a second value indicating that the first task is currently not eligible to be executed; and the second update is based on a second indication of a second condition to a second condition of one or more first registers, wherein: for at least one input channel to the first node, the total number of tokens in the input channel is insufficient to accommodate the execution of the first task; or for at least one output channel from the first node, the total available space in the output channel is insufficient to accommodate the execution of the first task.

[0208] In one or more twenty-fourth embodiments, and further in any one of the nineteenth to twenty-first embodiments, the second circuit system for performing the third access includes: the second circuit system for accessing each of a second plurality of registers corresponding to different corresponding nodes in the SDF graph based on a request, wherein each of the second plurality of registers includes a corresponding status parameter indicating whether the corresponding node is eligible to be executed.

[0209] In one or more twenty-fifth embodiments, and further in a twenty-fourth embodiment, based on a request, a second circuit system is configured to detect conditions in which a plurality of nodes are currently eligible to be executed; based on the conditions, the second circuit system is configured to perform a selection of a first node from the plurality of nodes; the selection is based on the relative priority of the plurality of nodes relative to each other; and a response is made to identify the first node based on the selection.

[0210] In one or more twenty-sixth embodiments, and further in a twenty-fifth embodiment, the SDF manager circuitry further includes a third circuitry coupled to the second circuitry, the third circuitry being configured to: receive information indicating whether to increase or decrease the priority of the first node during application runtime; and change the relative priorities of the plurality of nodes with respect to each other.

[0211] In one or more twenty-seventh embodiments, and further in any of the nineteenth to twenty-first embodiments, upon request, the second circuit system is further configured to: access a third register including an identifier of the starting address of the first task; and provide the identifier of the starting address in a response to indicate that the first task is the next task to be executed.

[0212] In addition to the content described herein, various modifications may be made to the disclosed embodiments and implementations therein without departing from their scope. Therefore, the descriptions and examples herein should be interpreted as illustrative rather than restrictive. The scope of the invention should be defined solely by reference to the appended claims.

Claims

1. A synchronous data flow SDF manager circuit for determining task execution, the SDF manager circuit comprising: first circuitry for performing a first access to one or more first registers during runtime of an application modeled using an SDF graph, the SDF graph comprising: a plurality of nodes, each of the plurality of nodes being used to represent a corresponding task of the application, and one or more channels, the one or more channels each for providing a respective communication to or from a first node of the plurality of nodes, wherein the one or more first registers each correspond to a different respective one of the one or more channels, and wherein the first access is used to determine, for each of the one or more channels, whether the channel is currently able to accommodate execution of the first task of the application; wherein the first circuit system further performs a second access to a second register corresponding to the first node based on the first access, wherein the second access is used to provide a value of a first state parameter of the second register, the value being used to identify whether the first task is currently eligible to be executed; and A second circuit system is configured to perform a third access to the second register based on a request identifying a next task to be executed, the second circuit system being further configured to generate a reply to the request based on the first state parameter.

2. The SDF manager circuit according to claim 1, characterized in that The reply is used to indicate that no tasks could be identified as currently eligible to be executed.

3. The SDF manager circuit according to claim 1 or claim 2, characterized in that: Based on a failure to identify any node as representing a corresponding task that is currently eligible to be executed, the second circuit system is configured to delay generation of the reply until a node is identified as eligible to be executed.

4. The SDF manager circuit according to any one of claims 1 to 3, characterized in that: The first circuit system is further configured to perform a first update, the first update setting the first state parameter to a first value, the first value indicating that the first task is currently eligible to be executed; and The first update is based on a first indication of a first condition by the one or more first registers, wherein: for each input channel to the first node, a total number of tokens of the input channel is sufficient to accommodate the execution of the first task; and For each output channel from the first node, the total space available in the output channel is sufficient to accommodate the execution of the first task.

5. The SDF manager circuit according to claim 4, characterized in that: The first circuit system is further configured to perform a second update, the second update setting the first state parameter to a second value indicating that the first task is currently ineligible to be executed; and The second update is based on a second indication of a second condition by the one or more first registers, wherein: For at least one input channel to the first node, a total number of tokens of the input channel is insufficient to accommodate the execution of the first task; or For at least one output channel from the first node, a total space available in the output channel is insufficient to accommodate the execution of the first task.

6. The SDF manager circuit according to any one of claims 1 to 3, characterized in that: The second circuit system is used to perform the third access, including: the second circuit system is used to access each register of a second plurality of registers corresponding to different corresponding nodes of the SDF graph based on the request, wherein the second plurality of registers each includes a corresponding state parameter, and the corresponding state parameter indicates whether the corresponding node is eligible to be executed.

7. The SDF manager circuit according to claim 6, characterized in that: Based on the request, the second circuit system is to detect a condition in which a plurality of nodes are currently eligible to be executed; The second circuit system is configured to perform selection of the first node from among the plurality of nodes based on the condition; The selecting is based on the relative priorities of the plurality of nodes with respect to each other; and The reply identifies the first node based on the selection.

8. The SDF manager circuit of claim 7, further comprising a third circuit system coupled to the second circuit system, the third circuit system being configured to: During the runtime of the application, receiving information indicating whether to increase or decrease the priority of the first node; and The relative priorities of the plurality of nodes with respect to each other are changed.

9. The SDF manager circuit according to any one of claims 1 to 3, characterized in that: Based on the request, the second circuit system is further configured to: accessing a third register including an identifier of a starting address of the first task; and The identifier of the starting address is provided in the reply to indicate that the first task is the next task to be executed.

10. A method for determining task execution at a synchronous data flow (SDF) manager circuit, the method comprising: A first access to one or more first registers is performed during runtime of an application modeled using an SDF graph, the SDF graph comprising: a plurality of nodes, each of the plurality of nodes being used to represent a corresponding task of the application, and one or more channels, the one or more channels each for providing a respective communication to or from a first node of the plurality of nodes, wherein the one or more first registers each correspond to a different respective one of the one or more channels, and wherein the first access determines, for each of the one or more channels, whether the channel is currently able to accommodate execution of the first task of the application; performing a second access to a second register corresponding to the first node based on the first access, wherein the second access provides a value of a first state parameter of the second register, the value being used to identify whether the first task is currently eligible to be executed; performing a third access to the second register based on a request identifying a next task to be executed; and A reply to the request is generated based on the first state parameter.

11. The method according to claim 10, characterized in that The reply indicates that no tasks could be identified as currently eligible to be executed.

12. The method according to any one of claims 10 or 11, further comprising: Based on the inability to identify any node as representing a corresponding task that is currently eligible to be executed, the generation of the reply is delayed until a node is identified as eligible to be executed.

13. The method according to any one of claims 10 to 12, further comprising: performing a first update, the first update setting the first state parameter to a first value, the first value indicating that the first task is currently eligible to be executed; The first update is based on a first indication of a first condition by the one or more first registers, in which: for each input channel to the first node, a total number of tokens of the input channel is sufficient to accommodate the execution of the first task; and For each output channel from the first node, the total space available in the output channel is sufficient to accommodate the execution of the first task.

14. The method according to claim 13, further comprising: performing a second update, the second update setting the first state parameter to a second value, the second value indicating that the first task is currently not eligible to be executed; The second update is based on a second indication of a second condition by the one or more first registers, in which the second condition: For at least one input channel to the first node, a total number of tokens of the input channel is insufficient to accommodate the execution of the first task; or For at least one output channel from the first node, a total space available in the output channel is insufficient to accommodate the execution of the first task.

15. The method according to any one of claims 10 to 12, characterized in that: Performing the third access includes accessing each register of a second plurality of registers corresponding to a different corresponding node of the SDF graph based on the request, wherein the second plurality of registers each include a corresponding state parameter indicating whether the corresponding node is eligible to be executed.

16. The method according to claim 15, further comprising: Based on the request, detecting a condition in which a plurality of nodes are currently eligible to be executed; as well as Based on the condition, performing selection of the first node from the plurality of nodes; in: The selecting is based on the relative priorities of the plurality of nodes with respect to each other; and The reply identifies the first node based on the selection.

17. The method according to claim 16, further comprising: during the runtime of the application, receiving information indicating whether to increase or decrease the priority of the first node; as well as The relative priorities of the plurality of nodes with respect to each other are changed.

18. The method according to any one of claims 10 to 12, further comprising: accessing a third register including an identifier of a start address of the first task based on the request; as well as The identifier of the starting address is provided in the reply to indicate that the first task is the next task to be executed.

19. A system for determining task execution, the system comprising: System bus; a plurality of processors, each of the plurality of processors being coupled to the system bus, the plurality of processors including a first processor; A synchronous data flow SDF manager circuit, the SDF manager circuit is coupled between the system bus and the first processor, the SDF manager circuit comprising: first circuitry for performing a first access to one or more first registers during runtime of an application modeled using an SDF graph, the SDF graph comprising: a plurality of nodes, each of the plurality of nodes being used to represent a corresponding task of the application, and one or more channels, the one or more channels each for providing a respective communication to or from a first node of the plurality of nodes, wherein the one or more first registers each correspond to a different respective one of the one or more channels, and wherein the first access is used to determine, for each of the one or more channels, whether the channel is currently able to accommodate execution of the first task of the application; wherein the first circuit system is further configured to perform a second access to a second register corresponding to the first node based on the first access, wherein the second access is configured to provide a value of a first state parameter of the second register, the value being configured to identify whether the first task is currently eligible to be executed; and The second circuit system is configured to perform a third access to the second register based on a request identifying a next task to be executed, and the second circuit system is further configured to generate a reply to the request based on the first state parameter.

20. The system according to claim 19, characterized in that The reply is used to indicate that no tasks could be identified as currently eligible to be executed.

21. A system according to any one of claims 19 or 20, characterized in that Based on a failure to identify any node as representing a corresponding task that is currently eligible to be executed, the second circuit system is configured to delay generation of the reply until a node is identified as eligible to be executed.

22. The system according to any one of claims 19 to 21, characterized in that: The first circuit system is further configured to perform a first update, the first update setting the first state parameter to a first value, the first value indicating that the first task is currently eligible to be executed; and The first update is based on a first indication of a first condition by the one or more first registers, wherein: for each input channel to the first node, a total number of tokens of the input channel is sufficient to accommodate the execution of the first task; and For each output channel from the first node, the total space available in the output channel is sufficient to accommodate the execution of the first task.

23. The system according to claim 22, characterized in that: The first circuit system is further configured to perform a second update, the second update setting the first state parameter to a second value indicating that the first task is currently ineligible to be executed; and The second update is based on a second indication of a second condition by the one or more first registers, wherein: For at least one input channel to the first node, a total number of tokens of the input channel is insufficient to accommodate the execution of the first task; or For at least one output channel from the first node, a total space available in the output channel is insufficient to accommodate the execution of the first task.

24. The system according to any one of claims 19 to 21, characterized in that The second circuit system is used to perform the third access, including: the second circuit system is used to access each register of a second plurality of registers corresponding to different corresponding nodes of the SDF graph based on the request, wherein the second plurality of registers each includes a corresponding state parameter, and the corresponding state parameter indicates whether the corresponding node is eligible to be executed.

25. The system according to claim 24, characterized in that: Based on the request, the second circuit system is to detect a condition in which a plurality of nodes are currently eligible to be executed; The second circuit system is configured to perform selection of the first node from among the plurality of nodes based on the condition; The selecting is based on the relative priorities of the plurality of nodes with respect to each other; and The reply identifies the first node based on the selection.

Images