International Business Machines Corporation

Lance Gordon Thompson

Paul E Schardt

James E Carey

Jim C Chen

Janice Lynn Pascoe

William Andrew Oswald

Robert Lowell Kanzelman

Mark A Williams

Scott Henry Mack

Kenneth Michael Caron

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.

Dynamic accelerator generation and deployment

A computer program includes calls to a software library. A virtual function table is built that includes the calls to the software library in the computer program. A programmable device includes one or more currently-implemented accelerators. The available accelerators that are currently-implemented are determined. The calls in the software library that correspond to a currently-implemented accelerator are determined. One or more calls to the software library in the virtual function table are replaced with one or more corresponding calls to a corresponding currently-implemented accelerator. When a call in the software library could be implemented in a new accelerator, an accelerator image for the new accelerator is dynamically generated. The accelerator image is then deployed to create the new accelerator. One or more calls to the software library in the virtual function table are replaced with one or more corresponding calls to the new accelerator.

Dynamically replacing a call to a software library with a call to an accelerator

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.

Accelerator monitoring and testing

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.

Selecting and using a cloud-based hardware accelerator

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.

Helping a hardware accelerator using software

Hardware accelerators are scored according to various metrics and attributes that characterize the accelerators. Examples of suitable accelerator scoring criteria include whether the software simulation of the accelerator is complete, whether hardware testing is complete, whether the accelerator is currently deployed, the number of times the accelerator has been deployed to a private cloud, the number of times the accelerator has been deployed to a public cloud, ratings by users, number of failures, number of executions, space utilization and efficiency, code metrics, power consumption, speed, and image characteristics, including space used, resources used, use of dedicated functions on a programmable device, etc. These accelerator scoring criteria are tracked for each accelerator in an accelerator scoring catalog. When an accelerator is needed, accelerator selection criteria is specified and compared with the accelerator scoring criteria in the accelerator scoring catalog to locate one or more accelerators that satisfy the accelerator selection criteria.

Selecting hardware accelerators based on score

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.

Managing cloud-based hardware accelerators

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.

Automatically deploying hardware accelerators based on requests from users

A thermal manager manages programmable devices that include one or more accelerators. The thermal manager may be part of an accelerator manager that manages multiple accelerators in multiple programmable devices. The thermal manager monitors the temperature of a programmable device and casts out one or more accelerators when the temperature of the programmable device exceeds a threshold. Where there are multiple accelerator images that have different thermal effects for a given function the thermal manager may replace the cast out accelerator with another accelerator image for the same function that uses less power.

Thermal management of hardware accelerators

An accelerator manager monitors hardware accelerators that are called by one or more computer programs. A virtual function table includes multiple entries, where each entry correlates a call from a computer program to a corresponding call to either a software library or a hardware accelerator. A call by the computer program to a function in the virtual function table results in the call being routed to either the software library or to a hardware accelerator depending on the contents of the corresponding entry in the virtual function table. The accelerator manager, in response to a detected failure in an accelerator, replaces one or more calls in the virtual function table to the failed accelerator with calls to the software library. The accelerator manager can then retry the call that caused the accelerator to fail, which will then be executed by the software library.

Failover of a hardware accelerator to software

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.

Debug boundaries in a hardware accelerator

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.

Growing community of inventors

Rochester, MN, United States of America

Lance Gordon Thompson