International Business Machines Corporation

Globalfoundries Inc.

Paul E Schardt

Robert Allen Shearer

Matthew Ray Tubbs

Eric Oliver Mejdrich

Adam James Muff

Lance Gordon Thompson

James E Carey

Jim C Chen

Mark Gary Kupferschmidt

Jamie Randall Kuesel

Russell Dean Hoover

Thomas M Armstead

David Keith Fowler

Jason D Greenwood

Scott Michael Willenborg

Gregory Albert Dancker

Lance R Meyer

Corey Virgil Swenson

John Hubert Klaus

Steven D McJunkin

Nathaniel K Tuen

William Andrew Oswald

Janice Lynn Pascoe

Charles David Wait

Kent Harold Haselhorst

Jon K Kriegel

Mark Joseph Hickey

George Russell Zettles, Iv

Frederick Jacob Ziegler

Gerald G Fagerness

Sierra Spring

Terry J Opie

Robert A Shearer, Iii

David E Wood

Dave Fowler

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

A method for providing a computer system including: a trivial file transfer protocol (TFTP) server computer, a system management controller computer and a set of subnet(s) including a first subnet, with each subnet of the set of subnet(s) including a primary computer and a plurality of host computers that respectively include a field programmable gate array (FPGA) with programmable blocks, polling, by the system management controller, each computer of the first subnet to determine that all of the computers of the first subnet are ready to receive a broadcast of an FPGA image, instructing the TFTP server computer to send the FPGA image to all of the machines of the first subnet; and sending, by the TFTP server computer and to all of the computers of the first subnet, the FPGA image.

TFTP (trivial file transfer protocol) broadcast controller

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

A circuit arrangement and program product for dynamically providing a status of a hardware thread/hardware resource independent of the operation of the hardware thread/hardware resource using an inter-thread communication protocol. A master hardware thread may be configured to communicate status requests to associated slave hardware threads and/or hardware resources. Each slave hardware thread/hardware resource may be configured with hardware logic configured to automatically determine status information for the slave hardware thread/hardware resource and communicate a status response to the master hardware thread without interrupting processing of the slave hardware thread/hardware resource.

Dynamic thread status retrieval using inter-thread communication

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

A method for dynamically providing a status of a hardware thread/hardware resource independent of the operation of the hardware thread/hardware resource using an inter-thread communication protocol. A master hardware thread may be configured to communicate status requests to associated slave hardware threads and/or hardware resources. Each slave hardware thread/hardware resource may be configured with hardware logic configured to automatically determine status information for the slave hardware thread/hardware resource and communicate a status response to the master hardware thread without interrupting processing of the slave hardware thread/hardware resource.

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.

Growing community of inventors

Stewartville, MN, United States of America

Paul E Schardt