Hardware-based accelerator signaling

Abstract

The processor[102] uses a hardware signal monitor[110] to manage signaling for accelerators[103, 104]. The hardware signal monitor monitors designated memory addresses assigned to accelerator signals. In response to a memory write[112] to any of the designated memory addresses, the hardware signal monitor performs one or more sets of actions (called callbacks). The hardware signal monitor thereby enables improved and enhanced signaling capabilities, such as asynchronous signaling between agents, signaling between accelerators, and signaling between processes.

Description

Background Art

[0001] (Background) To improve processing efficiency and save power, some processing systems employ one or more accelerators to perform designated operations instead of a central processing unit (CPU). For example, some processing systems employ a graphics processing unit (GPU) for performing graphics operations, an AI accelerator for performing artificial intelligence (AI) operations, a digital signal processor (DSP) for performing signal processing operations, and the like. To facilitate communication between an accelerator and a CPU, some processing systems use signals, where each signal is a shared memory object that can be accessed by the CPU and one or more accelerators to share information. Examples of signals include doorbell signals that notify an agent (e.g., one or more accelerators) that work is available, and completion signals that notify an agent (e.g., the CPU or an accelerator) when the assigned work is available. However, existing signal implementations are not very suitable for asynchronous communication and require a relatively large amount of overhead, such as software polling or interrupts, to observe the state of each signal.

[0002] This disclosure may be better understood by referring to the accompanying drawings, and numerous features and advantages thereof will be apparent to those skilled in the art. The use of the same reference numerals in different drawings indicates similar or identical items.

Brief Description of the Drawings

[0003] [Figure 1] FIG. 1 is a block diagram of a system employing a hardware signal monitor to manage signals in a system according to some embodiments. [Figure 2] FIG. 2 is a block diagram showing aspects of the hardware signal monitor of FIG. 1 according to some embodiments. [Figure 3]A block diagram of an example of a hardware signal monitor in Figure 1 that enables signaling between accelerators according to several embodiments. [Figure 4] This block diagram shows an example of a hardware signal monitor in Figure 1 that enables inter-process signaling according to several embodiments. [Figure 5] This figure shows an example of the CPU in Figure 1 that uses a page table to manage the monitoring of hardware signals in Figure 1, according to several embodiments. [Figure 6] This is a flowchart illustrating a method for managing signals in a hardware signal monitor, according to several embodiments. [Figure 7] This is a flowchart illustrating a method of employing a hardware signal monitor to perform a standby process in a system, according to several embodiments. [Modes for carrying out the invention]

[0004] Figures 1 to 7 illustrate circuits and techniques for employing a hardware signal monitor to manage accelerator signaling in a system, according to several embodiments. The hardware signal monitor monitors designated memory addresses assigned to accelerator signals. In response to a memory write to any of the designated memory addresses, the hardware signal monitor performs one or more sets of actions (called callbacks). The hardware signal monitor thereby enables improved and enhanced signaling capabilities, such as asynchronous signaling between agents, inter-accelerator signaling, and inter-process signaling.

[0005] For example, in some embodiments, the system includes several agents, each including at least one CPU and two or more accelerators. To communicate, the agents use a set of signals, each of which is a shared memory-assisted object with a corresponding memory address assigned to it. Each signal includes both a signal value and a signal condition. A signal is typically listened to by one or more agents, and each agent takes action when the signal condition is met by the corresponding signal value (for example, the signal condition is met when the signal value is less than 1). An agent sends a signal when it performs a write to the corresponding address using an atomic memory operation. An example of a signal is a doorbell signal, which is used by one agent (e.g., a CPU) to indicate to another agent (e.g., an accelerator) that work (e.g., one or more commands) is available. Another example of a signal is a completion signal, which is used by one agent to indicate to another agent that the assigned work is complete.

[0006] Traditionally, signals are managed by software polling, interrupts, or a combination of both. In software polling, the software runs a polling loop that repeatedly checks the signal value until the signal condition is met. However, this approach requires a relatively large number of memory accesses (to check the signal value) and consumes energy and memory bandwidth. Furthermore, this approach does not enable true asynchronous signaling because the software checks the signal value synchronously. In the case of interrupts, the system is configured to trigger a specified interrupt when the corresponding signal condition is met. However, this approach suffers from relatively high latency and is therefore unsuitable for low-latency applications. Moreover, these approaches are managed by the CPU and therefore prevent direct signaling between accelerators and signaling between different running processes.

[0007] Using the techniques described herein, in contrast to the approach described above, a hardware signal monitor circuit (referred to simply as a hardware signal monitor or HSM) monitors memory writes to memory addresses assigned to signals. As described above, a storage operation to any of these memory addresses indicates the transmission of the corresponding signal. Therefore, in response to a storage operation to any of these memory addresses, the HSM performs a corresponding callback (i.e., performs one or more operations corresponding to the callback). Examples of such operations include direct memory access (DMA) operations, interrupt issuance, enqueuing packets to a work dispatch queue, or any combination thereof. The HSM monitors and performs callbacks independently of the CPU and accelerators, thus reducing signal management overhead and enabling asynchronous signaling between agents.

[0008] Furthermore, since the HSM operates independently of the CPU, it supports direct signaling between accelerators, as well as signaling between different processes running on the CPU and the accelerators. In addition, in some embodiments, the callback behavior of one or more signals is programmable, thus supporting more advanced signal processing such as callback analysis, conditional signaling, scheduling, and broadcasting without major redesign of the CPU or accelerators.

[0009] Figure 1 shows System 100 in several embodiments. System 100 is generally configured to execute an instruction set (e.g., a computer program) to perform actions as specified by the set of instructions, instead of an electronic device. Thus, in different embodiments, System 100 is any part of many electronic devices, such as a desktop or laptop computer, a server, a smartphone, a tablet, or a game console.

[0010] To facilitate instruction execution, system 100 includes a CPU 102 and a set of accelerators (e.g., accelerators 103 and 104). The number of accelerators shown in Figure 1 is merely an example; in other embodiments, system 100 may include more or fewer accelerators. Furthermore, in some embodiments, system 100 includes additional circuitry not shown in Figure 1 that supports instruction execution, such as one or more memory controllers, one or more input / output controllers, one or more memory modules, etc., or any combination thereof. In some embodiments, the CPU 102 and accelerators 103 and 104 are part of a single processor. In other embodiments, one or more of accelerators 103 and 104 are external to system 100. In other embodiments, the CPU 102 and accelerators 103 and 104 are part of the same integrated circuit package but are mounted on separate integrated circuit dies.

[0011] The CPU 102 is generally configured to execute a set of instructions for the system 100. In some embodiments, the CPU 102 includes one or more processor cores, each processor core including one or more instruction pipelines. Each instruction pipeline includes circuitry configured to fetch instructions from a set of instructions assigned to the pipeline, decode each fetched instruction into one or more operations, execute the decoded operations, and retire each instruction when the corresponding operations have completed execution. In the process of executing at least some of these operations, the CPU 102 generates operations that are executed by either of the accelerators 103 and 104.

[0012] Each of the accelerators 103 and 104 is a circuit configured to perform a specified operation on behalf of the CPU 102. For example, in different embodiments, each of the accelerators 103 and 104 is one of the following: a GPU, a vector processor, a general-purpose GPU (GPGPU), a non-scalar processor, a highly parallel processor, an artificial intelligence (AI) processor, an inference engine, a machine learning processor, a DSP, a network controller, etc. Furthermore, in at least some embodiments, each of the accelerators 103 and 104 is a different type of accelerator.

[0013] To facilitate communication of operations and their results between the CPU 102 and accelerators 103 and 104, the system 100 includes an accelerator queue 105. In some embodiments, the accelerator queue 105 includes one or more work queues (e.g., work queues 107 and 108), each work queue storing information such as commands and corresponding data for the accelerator to instantiate and execute operations. For example, in some embodiments, the CPU 102 sends an operation (also called a work item) to accelerator 103 by storing a packet indicating the operation and any corresponding data in work queue 107. Accelerator 103 retrieves the packet from work queue 107, determines the operation indicated by the packet, and executes the indicated operation. The CPU 102 similarly uses work queue 108 to provide an operation to accelerator 104.

[0014] To support further communication between the CPU 102 and accelerators 103 and 104, system 100 is configured to support a signal architecture such as a heterogeneous system architecture (HAS). In particular, the CPU 102 and accelerators 103 and 104 are configured to communicate specified information, such as status information, via a set of signals, each of which is a shared memory object accessible by at least two of the CPU 102, accelerator 103, and accelerator 104. To support the signals, system 100 includes a signal memory 111 containing multiple addressable entries, each corresponding to a different signal. To change the state of a signal, an accelerator or CPU 102 performs a write operation (e.g., write 112) to the memory address corresponding to the signal. The value written by the write operation sets the value of the signal corresponding to the memory address.

[0015] To illustrate with an example, in some embodiments, an operating system (not shown) or other software running on the CPU 102 assigns a memory address as a doorbell signal for the accelerator 103, and the value of the signal indicates whether the accelerator 103 is available to process additional work items from the CPU 102. Therefore, if the accelerator 103 determines that it can process more work items, the accelerator 103 writes the specified value to the memory address in the signal memory 111 that was assigned to the doorbell signal. In response, the CPU 102 provides one or more additional work items to the work queue 107. In different embodiments, the signal memory 111 stores the values ​​of any number of signals, such as a signal indicating the completion of one or more work items by the accelerator, a signal indicating that a specified action is performed by the CPU 102, etc., and should be understood to indicate any of several statuses or other information.

[0016] As described above, one method for the CPU 102 and accelerators 104 to determine the status of a given signal is to poll the signal by performing a read operation at the memory address specified by the signal. However, this requires the CPU 102 to repeatedly perform the polling loop for the signal, which consumes CPU resources and hinders asynchronous communication of the signal status. Therefore, to facilitate more efficient signal communication and more advanced signal processing, the system 100 includes a hardware signal monitor (HSM) 110. The HSM 110 is a circuit configured to monitor write operations to the signal memory 111 and to perform one or more specified operations on the signal in response to a write operation to a given signal. One or more specified operations are called signal callbacks.

[0017] In different embodiments, the HSM110 identifies signal writes in one of several different ways. For example, in some embodiments, accelerators 103 and 104 and CPU 102 are all connected to the signal memory 111 via a common memory bus (not shown). The HSM110 is configured to store a table of memory addresses assigned to each signal and snoop the common memory bus for memory writes. Based on the snooping, the HSM110 performs a corresponding callback in response to identifying a memory write to an address stored in the table. In other embodiments, the monitoring circuit of the HSM110 is located within a memory controller (not shown) that manages write operations to the signal memory 111. In these embodiments, the memory controller provides the HSM110 with each write operation (or each write operation to a specified address range), and the HSM110 determines whether the write operation is to the signal memory 111. Monitoring signals using the HSM110 reduces the signal management overhead in the system 100. Furthermore, as will be further described below, in some embodiments, the HSM110 supports relatively advanced signal processing, including inter-accelerator and inter-process signaling, as well as programmable callbacks for signals.

[0018] Figure 2 is a block diagram showing embodiments of the HSM110 according to several models. In the illustrated example, the HSM110 includes a signal address register 220, a signal callback buffer 225, and a signal processing circuit 230. The signal address register 220 consists of multiple registers (e.g., registers 221 and 222), each register storing an address assigned to a signal. In some embodiments, the address values ​​in each of the signal address registers 220 are stored by an operating system, a device driver, or other software running on the CPU 102. For example, in some embodiments, the operating system assigns a memory address to each signal used by accelerators 103 and 104 during the initialization or boot process of the system 100, and stores each assigned memory address in a different register of the signal address register 220.

[0019] The signal callback buffer 225 is comprised of multiple buffers (e.g., buffers 227 and 228), each buffer storing a set of operations assigned to a signal. In different embodiments, operations are identified by data stored in the signal callback buffer 225 in different ways. For example, in some embodiments, each buffer stores a set of instructions executed by a microcontroller, processor, or instruction pipeline, and the set of instructions indicates an operation to be performed in response based on the value of the corresponding signal. In other embodiments, each buffer stores an index of the initial state (or set of states) of a state machine, and the initial state indicates a set of operations to be performed in response based on the value of the corresponding signal. In different embodiments, examples of operations stored in the signal callback buffer 225 and performed based on the value of the corresponding signal include one or more DMA or other memory transfers of one or more bytes, atomic memory operations, enqueue or dequeue operations of packets from software or hardware-assisted queues, task dispatch operations, a set of signal operations, and one or more program instructions executed by a signal processing circuit, command processor, accelerator, another processor, or any combination thereof.

[0020] The signal processing circuit 230 is a set of circuits having at least two aspects: a circuit that monitors the writing of signal values ​​to the signal memory 111, and a circuit that performs actions based on the signal values. In some embodiments, to perform actions, the signal processing circuit 230 includes a microcontroller or microprocessor configured to execute instructions stored in a signal callback buffer 225. In other embodiments, the signal processing circuit 230 is a circuit configured to execute one or more state machines, the initial state of the state machine being indicated by information stored in the signal callback buffer 225. Thus, to perform a set of actions on a signal, the signal processing circuit 230 accesses the corresponding buffers in the signal callback buffer 225 and determines both the initial state of one or more state machines and the transitions between different states based on the indicated set of actions.

[0021] During operation, the signal processing circuit 230 monitors writes to the signal memory 111, and in particular, writes to memory addresses stored in the signal address register 220. Upon identifying a write to any of the stored addresses, the signal processing circuit 230 executes a set of operations in the corresponding buffer of the signal callback buffer 226. For example, in some embodiments, buffer 226 stores the callbacks (sets of operations to be performed) for signals associated with register 221. That is, register 221 stores the memory address of a given signal, and buffer 226 stores the callback for that signal. Similarly, register 222 stores the memory address of a different signal, and buffer 227 stores the callback for the signal corresponding to the memory address stored in register 222. Upon identifying a memory write to an address stored in register 221, the signal processing circuit 230 executes the callback in buffer 226. Similarly, in response to identifying a memory write to an address stored in register 222, the signal processing circuit 230 executes a callback stored in buffer 227.

[0022] The HSM110 supports extended signal processing in system 100 according to several embodiments. For example, in some embodiments, the signal processing circuit 230 identifies the writing of a signal value and executes the corresponding callback in parallel and asynchronously with 1) instructions executed by the CPU 102, 2) operations performed by accelerators 103 and 104, and 3) any combination thereof. This eliminates the need for the CPU 102 to perform a polling loop to check the signal value, reducing the signal management overhead in the CPU 102 and improving overall processing efficiency.

[0023] In addition, as described above, the signal processing circuit 230 can execute one or more callbacks (i.e., one or more sets of operations) according to different signal values. Thereby, the HSM 110 can execute more complex signal processing and support inter-accelerator communication and inter-process signaling. An example of an HSM that supports inter-accelerator signaling according to some embodiments is shown in FIG. 3. In the illustrated example, the accelerator 103 executes a memory write 112 to write a value to the corresponding signal. In response to the memory write 112, the HSM 110 executes the corresponding callback. One of the operations of the executed callback is to store the work item 335 in the work queue 108. The work item 335 indicates a set of operations to be executed by the accelerator 104. The accelerator 104 retrieves the work item 335 from the work queue 108 and executes the indicated operations. Thus, in the example of FIG. 3, the accelerator 103 does not request the CPU 102 to provide the work item 335, but uses a signal to directly schedule the work to be executed by the accelerator 104. That is, in some embodiments, the accelerators 103 and 104 use signals to directly schedule work in other accelerators without intervention or management by the CPU 102, thus improving the overall processing efficiency in the system 100.

[0024] FIG. 4 shows an example of the HSM 110 that enables inter-process signaling according to some embodiments. In the illustrated example, the CPU 102 simultaneously executes two threads of the designated threads 440 and 441, and each of the threads 440 and 441 represents a set of instructions (e.g., program threads) to be executed in the instruction pipeline of the CPU 102. Further, each of the threads 440 and 441 instantiates and manages different processes, the designated processes 442 and 443, in the accelerator 103. Each of the processes 442 and 443 represents a set of operations to be executed in the accelerator 103 in place of the corresponding thread. For example, in some embodiments, the accelerator 103 is a GPU, and the processes 442 and 443 represent different rendering operations to be executed by the GPU in place of the threads 440 and 441, respectively.

[0025] In a conventional processor, the processes 442 and 443 cannot communicate directly via signals. Instead, each process communicates with other processes via the corresponding thread. However, in the illustrated example, the HSM 110 generates an inter-process signal 446 for direct communication of information between the processes 442 and 443. In particular, in response to the process 442 transmitting a signal 445 (i.e., performing a memory write of a value to the memory location corresponding to the signal 445), the HSM 110 executes a corresponding callback. One operation of the callback is to generate an inter-process signal 446 that is directly communicated to the process 443 when executed. Thus, the process 442 directly communicates information to the process 443 via a signal without the intervention of the corresponding threads 440 and 441. Thus, the HSM 110 supports flexible and efficient communication of information between processes, enables synchronization of operations between processes, and thus supports more complex task pipelines.

[0026] In some embodiments, the CPU 102 employs a page table to manage signaling and the HSM 110. Examples of some embodiments are shown in Figure 5. In the illustrated examples, the CPU 102 runs a kernel-mode driver (KMD) 450 and user-mode drivers (UMDs) 451 and 452. In some embodiments, the KMD 450 is a software component that runs in the same memory space as the operating system (OS, not shown) running on the CPU 102. Each of the UMDs 451 and 452 is a software component for the corresponding accelerator (accelerators 103 and 104, respectively). Each of the UMDs 451 and 452 runs in a memory space separate from the OS.

[0027] In some embodiments, the KMD450 (a) supports user-mode monitor-based signals and (b) allocates pages of memory shared across multiple user-mode process (virtual address) spaces. The KMD450 and the OS allocate appropriate physical memory pages to represent signals used by system 100. Each of the UMD451 and 452 is configured to request and use signals allocated from the shared pages by the KMD450. Furthermore, each UMD451 and 452 operates within an independent process address space and therefore has its own mapping from user process virtual addresses to the physical addresses of signals. In some embodiments, each UMD451 and 452 performs monitor-based waiting operations for shared signals, as further described below.

[0028] In one embodiment, KMD450 controls access to a set of shared signals 455 used for inter-process communication. UMD451 and 452 call KMD450 to request new shared signals or access existing shared signals. In another embodiment, either or both of UMD451 and 452 are configured to control access to shared signals. In some embodiments, signals are generated in response to either UMD451 or 452 calling KMD450 to allocate the shared signals to the appropriate pages in memory. In some embodiments, a UMD then allows other UMDs to access the signals to enable inter-process communication. In the illustrated example, KMD450 assigns private signals 453 and 454, which represent signals dedicated to specific accelerators 103 and 104.

[0029] In some embodiments, each user process uses the same virtual address for a shared signal. The KMD450 and the OS cooperate to install a consistent virtual address translation for each UMD shared signal in page table 452, thereby creating a single shared memory space abstraction for the shared signals.

[0030] A virtual address across all agent and user-mode processes for a given signal allows for the seamless passing of signal handles (addresses) between processes and accelerators without the need for virtual-virtual address translation. For example, in some embodiments, one process dispatches a task to an accelerator, and the accelerator task communicates the address of the completion signal to another process that depends on the first process. The dependent process then waits for the completion of the first task, targeting a given virtual address of the assigned signal, using monitor-based signal waiting behavior as described below. When the completion signal is sent, the dependent process receives the notification, wakes up, dispatches its accelerator task, and thereby forms a multi-process accelerator task pipeline. The use of monitor-based signaling directly enables inter-process synchronization without the need for high-latency inter-process interrupts.

[0031] In some embodiments, the OS virtual memory system uses page table 452 to provide virtual-to-physical address translation and memory protection. The metadata of the page table entries indicates the availability of hardware-supported address monitors or monitor-based signaling mechanisms for the memory pages. This metadata is represented as signal monitor attribute 456 in Figure 5. For example, in some embodiments, the signal monitor attribute includes an OS availability bit indicating whether the virtual addresses belonging to the page are permitted to be targeted by the hardware address monitor. The runtime queries the status of signal monitor attribute 456 to dynamically determine at runtime whether a monitor-based signaling implementation can be used by the runtime. In different embodiments, the OS, KMD450, or runtime plays a role in detecting hardware address monitor support and querying the hardware functionality register to set the signal monitor attribute 456 based on the query. This allows for page granularity selection of the monitor waiting mechanism. That is, in some embodiments, some signals are indicated as monitorable by signal monitor attribute 456, and others are indicated as not monitorable. The HSM110 monitors only the signals indicated as monitorable by signal monitor attribute 456.

[0032] Figure 6 shows a flowchart of method 600 for managing signals in a hardware signal monitor, according to several embodiments. While method 600 is described with respect to an exemplary embodiment in system 100, it should be understood that in other embodiments, method 600 may be implemented in processing systems with different configurations.

[0033] In block 602, the CPU 102 generates a signal operation for each signal, also referred to herein as a callback. For example, in some embodiments, one or more application programming interfaces (APIs) provide a set of operations for each signal based on instructions provided by one or more programmers. This allows the programmer to coordinate the operations performed for each signal and to set different operations to be performed for different signal values. In block 604, the CPU 102 stores the different signal operations for each signal in the corresponding buffers of the signal callback buffer 225.

[0034] In block 606, the signal processing circuit 230 monitors the memory bus for write operations to memory addresses stored in the signal address register 220. Upon determining that a write operation targets one of the stored addresses, the signal processing circuit determines that a signal value has been set for the corresponding signal. Therefore, in block 608, the signal processing circuit identifies the callback buffer associated with the identified signal and then executes the set of operations stored in the identified callback buffer.

[0035] Figure 7 shows a flowchart of Method 700 of signal waiting operations performed by a system hardware signal monitor in several embodiments. Although Method 700 is described with respect to an exemplary embodiment in System 100, it should be understood that in other embodiments, Method 600 may be implemented in processing systems with different configurations.

[0036] In some embodiments, method 700 is performed as part of a set of callback operations depending on the corresponding signal. A callback operation indicates that the signal processing circuit will perform a signal waiting operation. To perform a signal waiting operation, in block 702, the signal processing circuit 230 optionally configures a user timeout request, thereby waiting to check any signal state until the timeout amount is satisfied. In block 704, the signal processing circuit determines whether the timeout level is greater than zero. If not, the method flow moves to block 708, which is described below. If the timeout level is greater than zero, the method flow moves to block 706, where the signal processing circuit configures a timer interrupt. In some embodiments, the timer interrupt provides a latency boundary for checking the signal value. For example, in some embodiments, software calling a monitor may want notification about the signal after the timeout latency has expired, even if the signal value has not yet met a specified condition. In some embodiments, the timer interrupt is used to determine whether an entity expected to write the signal has stalled or is overloaded at work. After the timer interrupt is configured, the method flow moves to block 708.

[0037] In block 708, the signal processing circuit 230 determines whether the signal condition of the signal is met. If it is met, the method moves to block 718, and the signal processing circuit 230 returns the signal value. If the signal condition is not met, the method flow moves to block 710, and the signal processing circuit 230 performs a monitoring operation on the signal. Depending on the monitoring operation, a hardware signal monitor is assigned to monitor whether the signal condition is met. In block 712, the signal processing circuit 230 determines whether the signal condition of the signal was met while the hardware signal monitor was being set up. If it is met, the method moves to block 718, and the signal processing circuit 230 returns the signal value.

[0038] In block 712, if the signal condition is not met, the method flow moves to block 714, where the signal processing circuit 230 performs a waiting operation for a specified time. In some embodiments, depending on the waiting operation, the system 100 enters a stopped state or another defined state. When the waiting operation is complete (for example, depending on the wake-up of the system 100), the method flow moves to block 716, where the signal processing circuit 230 determines whether the signal timeout has expired. If it has not expired, the method flow returns to block 708. If the signal timeout has expired, the method flow moves to block 718, where the signal processing circuit returns the signal value.

[0039] In some embodiments, the method includes a hardware signal monitor asynchronously notifying a first process of a signal based on a signal issued by a first accelerator. In one embodiment, the asynchronous notification includes the hardware signal monitor performing a set of operations based on the signal. In another embodiment, the set of operations includes one or more of the following: a memory transfer of one or more bytes of data, an atomic memory operation, an enqueue of a first packet, a dequeue of a second packet, a task dispatch operation, a set of signal operations, and instructions executed by the processor. In yet another embodiment, the set of operations includes the hardware signal monitor sending a task to a second accelerator.

[0040] In one embodiment, submitting a task involves a hardware signal monitor submitting the task based on a value generated by one of several accelerators. In another embodiment, submitting a task involves enqueuing the task in the work queue of a second accelerator. In yet another embodiment, the set of operations is programmable. In yet another embodiment, the signal is issued by a second process running on the first accelerator, the second process being independent of the first process. In yet another embodiment, the signal is issued by the first accelerator in response to a write operation to a specified memory address.

[0041] In some embodiments, the method includes a hardware signal monitor receiving a signal associated with a first accelerator from a first process, and the hardware signal monitor indicating the signal to a second process, the second process being independent of the first process. In one embodiment, the second process is associated with a second accelerator of a processor.

[0042] In some embodiments, the system includes a first accelerator and a hardware signal monitor circuit for asynchronously notifying a first process of a signal based on a signal associated with the first accelerator. In one embodiment, the hardware signal monitor circuit includes a signal processing circuit for performing a set of operations based on the signal. In another embodiment, the set of operations includes one or more of the following: a memory transfer of one or more bytes of data, an atomic memory operation, an enqueue of a first packet, a dequeue of a second packet, a task dispatch operation, a set of signal operations, and instructions to be executed by the processor. In yet another embodiment, the set of operations includes the hardware signal monitor circuit sending a task to a second accelerator. In yet another embodiment, the hardware signal monitor circuit sends a task based on a value generated by any of the multiple accelerators.

[0043] In one embodiment, a hardware signal monitoring circuit sends a task to a work queue of a second accelerator. In another embodiment, the set of operations is programmable. In yet another embodiment, the signal is issued by a second process, which is independent of the first process. In yet another embodiment, the signal is based on a write operation to a specified memory address.

[0044] Computer-readable storage media include any non-temporary storage media or combination of non-temporary storage media that are accessible by a computer system during use to provide instructions and / or data to the computer system. Such storage media may include, but are not limited to, optical media (e.g., compact discs (CDs), digital versatile discs (DVDs), Blu-ray® discs), magnetic media (e.g., floppy disks, magnetic tapes, magnetic hard drives), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or microelectromechanical system (MEMS) based storage media. Computer-readable storage media (e.g., system RAM or ROM) may be built into the computing system, computer-readable storage media (e.g., magnetic hard drives) may be permanently mounted to the computing system, computer-readable storage media (e.g., optical disks or Universal Serial Bus (USB) based flash memory) may be detachably mounted to the computing system, and computer-readable storage media (e.g., network-accessible storage (NAS)) may be connected to the computer system via a wired or wireless network.

[0045] In some embodiments, certain aspects of the technology described above are implemented by one or more processors of a processing system that executes the software. The software includes one or more sets of executable instructions, which are stored in a non-temporary computer-readable storage medium or otherwise clearly embodied. The software may also include instructions and specific data, which, when executed by one or more processors, operate the one or more processors to execute one or more aspects of the technology described above. Non-temporary computer-readable storage mediums may include, for example, magnetic or optical disk storage devices, solid-state storage devices such as flash memory, caches, random-access memory (RAM), or other non-volatile memory devices (one or more). Executable instructions stored in a non-temporary computer-readable storage medium can be implemented as source code, assembly language code, object code, or other instruction forms that can be interpreted or otherwise executed by one or more processors.

[0046] In addition to the foregoing, it should be noted that not all activities or elements described in the summary are required, and certain activities or parts of devices may not be required, and one or more additional activities may be performed, and one or more additional elements may be included. Furthermore, the order in which the activities are listed does not necessarily indicate the order in which they are performed. Also, the concepts have been described with reference to specific embodiments. However, those skilled in the art will understand that various modifications and variations can be made without departing from the scope of the invention as described in the claims. Therefore, the specification and drawings should be considered illustrative rather than restrictive, and all of these variations are intended to fall within the scope of the invention.

[0047] Benefits, other advantages, and solutions to problems have been described above with respect to specific embodiments. However, benefits, advantages, solutions to problems, and features that may give rise to or manifest any benefits, advantages, or solutions are not to be construed as essential, necessary, or indispensable features to any or all of the claims. Furthermore, the disclosed invention can be modified and implemented in different but similar ways, in a manner that is obvious to those skilled in the art who are interested in the teachings of this specification; therefore, the specific embodiments described above are merely illustrative. There are no limitations to the details of the configuration or design shown herein beyond those described in the appended claims. Accordingly, the specific embodiments described above may be modified or altered, and it is clear that all such modifications are within the scope of the disclosed invention. Accordingly, the protection sought herein is described in the appended claims.

Claims

1. It is a method, The hardware signal monitor includes asynchronously notifying a first process of a signal based on a signal issued by a first accelerator, method.

2. The aforementioned asynchronous notification means The hardware signal monitor includes performing a set of operations based on the signal, The method according to claim 1.

3. The set of operations includes one or more instructions executed by the processor, such as a memory transfer of one or more bytes of data, an atomic memory operation, an enqueue of a first packet, a dequeue of a second packet, a task dispatch operation, a set of signaling operations, and an instruction executed by the processor. The method according to claim 2.

4. The set of operations includes the hardware signal monitor sending a task to a second accelerator. The method according to claim 2.

5. Sending the task includes the hardware signal monitor sending the task based on a value generated by any of the accelerators. The method according to claim 4.

6. Sending the task includes enqueuing the task in the work queue of the second accelerator. The method according to claim 4.

7. The set of operations described above is programmable. The method according to claim 2.

8. The aforementioned signal is issued by a second process executed in the first accelerator, and the second process is independent of the first process. The method according to claim 1.

9. The aforementioned signal is issued by the first accelerator in response to a write operation to a specified memory address. The method according to claim 1.

10. It is a method, In a hardware signal monitor, the receiving of a signal from a first process, wherein the signal is associated with a first accelerator, The hardware signal monitor includes the step of indicating the signal to a second process, wherein the second process is independent of the first process. method.

11. The second process is associated with the second accelerator of the processor, The method of claim 10.

12. It is a system, The first accelerator, The system includes a hardware signal monitor circuit that asynchronously notifies a first process of a signal associated with the first accelerator, system.

13. The aforementioned hardware signal monitoring circuit is Includes a signal processing circuit that performs a set of operations based on the aforementioned signal, The system according to claim 12.

14. The set of operations includes one or more instructions executed by the processor, such as a memory transfer of one or more bytes of data, an atomic memory operation, an enqueue of a first packet, a dequeue of a second packet, a task dispatch operation, a set of signaling operations, and an instruction executed by the processor. The system according to claim 13.

15. The set of operations includes the hardware signal monitoring circuit transmitting a task to a second accelerator. The system according to claim 14.

16. The hardware signal monitoring circuit transmits the task based on a value generated by one of the multiple accelerators. The system according to claim 15.

17. The hardware signal monitoring circuit transmits the task to the work queue of the second accelerator. The system according to claim 15.

18. The set of operations described above is programmable. The system according to claim 13.

19. The signal is issued by a second process, which is independent of the first process. The system according to claim 13.

20. The aforementioned signal is based on a write operation to a specified memory address. The system according to claim 13.

Images