Abstract: An on-chip accelerator manager manages multiple accelerators in a programmable device. In one specific implementation, the multiple accelerators are identical accelerators. The accelerator manager and the multiple accelerators are deployed to the programmable device. One or more calls to a software library in a virtual function table are replaced with one or more calls to the on-chip accelerator manager. The on-chip accelerator manager receives an accelerator call, and in response, allocates the accelerator call to one of the multiple accelerators, performs load balancing to the multiple accelerators, and performs failover when one of the accelerators fails by allocating work that was allocated to the failed accelerator to a different accelerator. The on-chip accelerator can push work to the multiple accelerators in a first mode of operation, and the multiple accelerators can pull work from the on-chip accelerator manager in a second mode of operation.

Abstract: An accelerator manager monitors usage of accelerators by one or more computer programs, and generates a historical log from the monitored usage. The accelerator manager determines from the historical log which of the plurality of accelerators to implement on one or more application-specific integrated circuits. Each application-specific integrated circuit can include implemented accelerators and accelerator images that can be deployed to external programmable devices. Once one or more accelerators are implemented on one or more application-specific integrated circuits, the accelerator manager can direct one of the application-specific integrated circuits to provide a needed accelerator. An application-specific integrated circuit can provide the needed accelerator either using an accelerator implemented in the application-specific integrated circuit, or by deploying an accelerator image in the application-specific integrated circuit to an external programmable device.

Abstract: An accelerator deployment tool determines resource requirements for one or more accelerator images, determines feature sets of a plurality of programmable devices, compares the resource requirements to the feature sets, determines whether the feature sets satisfy the resource requirements, and when the feature sets satisfy the resource requirements, selects one or more of the plurality of programmable devices that has a feature set that satisfies the resource requirements, and deploys the accelerator image(s) to the selected programmable device(s) to provide one or more accelerators corresponding to the accelerator image(s). A call can then be made to the one or more accelerators. The accelerator deployment tool thus automatically selects one or more programmable devices based on their feature sets and can automatically deploy one or more accelerator images to the one or more programmable devices.

Abstract: An accelerator helper monitors pending calls for a first accelerator, and when the accelerator is too busy, the accelerator helper sends a new call to the first accelerator to a software routine instead of to the first accelerator. The software routine processes the new call in parallel with the first accelerator processing a previous call. When the accelerator is not too busy, the accelerator helper sends to the first accelerator the new call to the first accelerator. The determination of when the accelerator is too busy can be whether a number of pending calls for the first accelerator exceeds a predetermined threshold. The accelerator helper speeds up execution of calls to the first accelerator by executing some calls to the accelerator in a software routine when the first accelerator has too many calls pending.

Abstract: An accelerator helper monitors pending calls for a first accelerator, and when the accelerator is too busy, the accelerator helper sends a new call to the first accelerator to a software routine instead of to the first accelerator. The software routine processes the new call in parallel with the first accelerator processing a previous call. When the accelerator is not too busy, the accelerator helper sends to the first accelerator the new call to the first accelerator. The determination of when the accelerator is too busy can be whether a number of pending calls for the first accelerator exceeds a predetermined threshold. The accelerator helper speeds up execution of calls to the first accelerator by executing some calls to the accelerator in a software routine when the first accelerator has too many calls pending.

Abstract: Multiple debug boundaries are defined in a hardware accelerator. The location of debug boundaries can be defined by a human user, or can be determined by automated tools based on characteristics of the circuitry in the hardware accelerator. Each debug boundary includes one or more hardware memory elements that are in a first state to indicate the debug boundary has not yet been reached, and that are changed to a second state by the hardware accelerator to indicate the debug boundary has been reached during execution of the hardware accelerator. Providing multiple debug boundaries in a hardware accelerator aids in debugging the accelerator design by identifying a particular section of the hardware accelerator where the failure occurred. This information regarding location of a failure may be provided to a user or to synthesis and simulation tools for the hardware accelerator design.

Abstract: A cloud-based hardware accelerator is selected by deploying an accelerator image to first and second clouds to generate first and second cloud-based hardware accelerators, executing a first request on the first and second cloud-based hardware accelerators, monitoring characteristics of the first and second cloud-based hardware accelerators executing the first request, which may include execution time and monetary cost, and selecting one of the first and second hardware accelerators according to defined selection criteria. Subsequent requests are then routed to the selected cloud-based accelerator.

Abstract: A memory manager on a programmable device manages memory allocated to accelerators on the programmable device and allocated to processes that access the programmable device. The memory manager can manage both memory on the programmable device as well as external memory coupled to the programmable device. The memory manager protects the memory from unauthorized access by enforcing protection for the memory, using keys, encryption or the like. The memory manger can allocate a partition of memory to an accelerator when an accelerator is deployed to a programmable device, then allocate subpartitions within the allocated partition for each process that accesses the accelerator. When an accelerator is cast out of the programmable device, the memory partition is scrubbed so it can be reclaimed and allocated to another accelerator. When a process terminates, the subpartitions corresponding to the process are scrubbed so they may be reclaimed and allocated to another process.

Abstract: A cloud-based accelerator manager manages cloud-based hardware accelerators. The accelerator manager monitors computer programs running in the cloud and generates a trace that indicates which accelerators were used and when. The trace may be for a single computer program or may be for multiple computer programs. Thus, the trace can be program-specific, showing all accesses to accelerators by a single program, or may be accelerator-specific, showing all accesses to each accelerator by all computer programs. The cloud-based accelerator manager detects a failure in one of the computer programs executing in the cloud. The cloud-based accelerator manager provides the trace to a user, who can then analyze the trace to determine whether the failure was due to an accelerator. The cloud-based accelerator manager thus helps detect when cloud-based accelerators are the reason for failures for computer programs running in a cloud.

Abstract: A cloud-based accelerator manager manages cloud-based hardware accelerators. The accelerator manager monitors computer programs running in the cloud and generates a trace that indicates which accelerators were used and when. The trace may be for a single computer program or may be for multiple computer programs. Thus, the trace can be program-specific, showing all accesses to accelerators by a single program, or may be accelerator-specific, showing all accesses to each accelerator by all computer programs. The cloud-based accelerator manager detects a failure in one of the computer programs executing in the cloud. The cloud-based accelerator manager provides the trace to a user, who can then analyze the trace to determine whether the failure was due to an accelerator. The cloud-based accelerator manager thus helps detect when cloud-based accelerators are the reason for failures for computer programs running in a cloud.

Abstract: An accelerator manager monitors run-time performance of multiple accelerators in one or more programmable devices, and when first and second accelerators satisfy at least one coalescence criterion, the accelerator manager generates a new accelerator image corresponding to a third accelerator that coalesces the first accelerator and the second accelerator. In a first embodiment, the accelerator manager generates the new accelerator image from the accelerator images for the first and second accelerators. In a second embodiment, the accelerator manager generates the new accelerator image from hardware description language representations of the first and second accelerators. The new accelerator image is deployed to a programmable device to provide a new accelerator, and calls to the first and second accelerators are replaced with calls to the new accelerator.

Abstract: A code portion in a computer program is identified that will be improved from being deployed to a hardware accelerator to enhance the run-time performance of the computer program. An accelerator catalog includes a listing of currently-implemented accelerators, along with available resources on one or more programmable devices. When the catalog does not include the needed accelerator, the available resources are determined from the catalog, and when the available resources are insufficient to deploy the needed accelerator, one or more of the existing accelerators is cast out of the programmable device according to specified ranking criteria to make room for the needed accelerator. The needed accelerator image is dynamically generated and deployed, the identified code portion of the computer program is replaced with a call to the deployed hardware accelerator, the newly-generated accelerator is stored in the catalog, and the available resources data in the catalog is updated.

Abstract: An accelerator manager monitors one or more requests for accelerators from one or more users, and deploys one or more accelerators to one or more programmable devices based on the one or more requests from the one or more users. In a first embodiment, the accelerator manager deploys an accelerator that satisfies multiple user requests. The multiple user requests can be multiple requests from one user, or could be multiple requests from multiple users. In a second embodiment, the accelerator manager compiles historical data from the monitored requests, identifies one or more accelerators that are requested following the request for a first accelerator, and deploys the one or more accelerators after the first accelerator is requested and before they are requested.

Abstract: An accelerator manager validates an accelerator image using one or more suitable validation methods, which may include comparing results of running an accelerator with results of simulating the accelerator, comparing results of running an accelerator on two different programmable devices, and deploying the accelerator to a cloud of an accelerator provider and running the accelerator to determine whether the accelerator meets defined specifications. The accelerator manager can also report information about one or more accelerators to an accelerator provider and/or to a provider of a programmable device.

Abstract: A memory manager on a programmable device manages memory allocated to accelerators on the programmable device and allocated to processes that access the programmable device. The memory manager can manage both memory on the programmable device as well as external memory coupled to the programmable device. The memory manager protects the memory from unauthorized access by enforcing protection for the memory, using keys, encryption or the like. The memory manger can allocate a partition of memory to an accelerator when an accelerator is deployed to a programmable device, then allocate subpartitions within the allocated partition for each process that accesses the accelerator. When an accelerator is cast out of the programmable device, the memory partition is scrubbed so it can be reclaimed and allocated to another accelerator. When a process terminates, the subpartitions corresponding to the process are scrubbed so they may be reclaimed and allocated to another process.

Abstract: An accelerator manager monitors and logs performance of multiple accelerators, analyzes the logged performance, determines from the logged performance of a selected accelerator a desired programmable device for the selected accelerator, and specifies the desired programmable device to one or more accelerator developers. The accelerator manager can further analyze the logged performance of the accelerators, and generate from the analyzed logged performance an ordered list of test cases, ordered from fastest to slowest. A test case is selected, and when the estimated simulation time for the selected test case is less than the estimated synthesis time for the test case, the test case is simulated and run. When the estimated simulation time for the selected test case is greater than the estimated synthesis time for the text case, the selected test case is synthesized and run.

Abstract: An accelerator deployment tool deploys multiple accelerators to multiple programmable devices, and detects when a new programmable device becomes available. When a first accelerator in a first programmable device is a better match to the new programmable device, the accelerator deployment tool automatically generates an image for the first accelerator for the new programmable device, deploys the image on the new programmable device to generate a second accelerator, changes references to the first accelerator to reference instead the second accelerator, and casts the first accelerator out of the first programmable device.

Abstract: An accelerator helper monitors pending calls for a first accelerator, and when the accelerator is too busy, the accelerator helper sends a new call to the first accelerator to a software routine instead of to the first accelerator. The software routine processes the new call in parallel with the first accelerator processing a previous call. When the accelerator is not too busy, the accelerator helper sends to the first accelerator the new call to the first accelerator. The determination of when the accelerator is too busy can be whether a number of pending calls for the first accelerator exceeds a predetermined threshold. The accelerator helper speeds up execution of calls to the first accelerator by executing some calls to the accelerator in a software routine when the first accelerator has too many calls pending.

Abstract: An accelerator tester partitions accelerator logic for a hardware accelerator into a plurality of sequential logic blocks, defines debug boundaries between adjacent sequential logic blocks, and inserts logic corresponding to the plurality of debug boundaries into the accelerator logic. The accelerator tester then tests the accelerator logic that includes the logic corresponding to the debug boundaries, and when the test fails, determines which of the debug boundaries were successfully crossed during the test. The information of which of the debug boundaries were successfully crossed during the test can then be fed back into a subsequent test by the accelerator tester.

Abstract: An accelerator manager monitors usage of accelerators by one or more computer programs, and generates a historical log from the monitored usage. The accelerator manager determines from the historical log which of the plurality of accelerators to implement on one or more application-specific integrated circuits. Each application-specific integrated circuit can include implemented accelerators and accelerator images that can be deployed to external programmable devices. Once one or more accelerators are implemented on one or more application-specific integrated circuits, the accelerator manager can direct one of the application-specific integrated circuits to provide a needed accelerator. An application-specific integrated circuit can provide the needed accelerator either using an accelerator implemented in the application-specific integrated circuit, or by deploying an accelerator image in the application-specific integrated circuit to an external programmable device.