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: 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 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: 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: Techniques for cognitive interpretation of source code are provided. Metadata associated with a section of code in a software project is analyzed to determine a change history of the section of code. A plurality of discussions related to the section of code is evaluated, where each of the plurality of discussions occurred during a code review process. Further, a plurality of support records related to the section of code is analyzed. A sentiment score for the section of code is determined based on the associated metadata, the evaluation of the plurality of discussions, and the analysis of the plurality of support records. Additionally, a display color for the section of code is selected based on the sentiment score. Finally, generation of a graphical user interface (GUI) is facilitated, where the GUI displays the first display color in association with the first section of code.

Abstract: A touch screen device includes a security enforcer that monitors the environment of the touch screen device and sets an appropriate security level for the touch screen device based on the monitored environment. The monitored conditions may include users and devices in physical proximity to the touch screen device. When the touch screen device is in physical proximity to users and/or devices the touch screen device does not recognize, the touch screen device elevates its security level. The touch screen device may include a system and application profiles that defines characteristics for enhancing the security of the touch screen device by changing locations of one or more selectable objects for authentication and by changing location of one or more selectable objects for applications based on one or more defined thresholds, or for making an icon unselectable or hidden based on an elevated security level of the touch screen device.

Abstract: An accelerator image generator includes a synthesis block and a simulation block. The accelerator image generator receives a hardware description language representation for a desired function, inputs the hardware description language representation for the desired function to the synthesis block and to the simulation block so the synthesis block and simulation block work in parallel, monitors progress of the synthesis block and the simulation block, and when a defined threshold is reached in the synthesis block, halts the simulation block while the synthesis block continues until the synthesis block outputs an accelerator image for deployment to a programmable device. When an error is detected in the synthesis block following halting of the simulation block, the simulation block may be resumed, and the defined threshold may be adjusted. The accelerator image can be deployed to a programmable device to provide a hardware accelerator corresponding to the accelerator image.

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 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 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 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: A method, system and computer program product are provided for implementing anomaly detection and notification through profiled context. Anomalies are detected by effectively using multiple devices and using predefined profiles to generate a contextual comparison for subtle differences detected. When predefined subtle anomalies are detected using at least one of the predefined profiles, a selected notification is provided.

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: 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: Embodiments presented herein describe techniques for tracking operators of a distributed computing environment (e.g., a streams processing environment) using metadata. During execution of a distributed application of the computing environment, a tracker tool monitors a plurality of operators of the distributed application. Each of the operators stores one or more specified metadata values associated with the operator. For each operator, the tracker tool retrieves the one or more specified metadata values associated with the operator. Upon determining that one of the one or more specified metadata values do not comply with a corresponding expected metadata value, the tracker tool generates an indicator for the operator. The indicator includes information describing the one or more specified metadata values.

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 decision support engine allows defining multiple events and corresponding actions. An event could be, for example, a decision that is at variance with what the professional usually suggests, or at variance with standard practice of other professionals. Suitable action can be taken when an event occurs. Examples of suitable actions include, for example, to notify the professional, to notify the customer or patient, to notify an administrator, and to log all data related to the decision that caused the event. The decision support engine receives biometric input from one or more biometric sensors worn by the professional, and can thus log the physical state of the professional at the time the event occurs. For each event, the professional's biometric data is logged and can be analyzed to determine statistical correlations between the events corresponding to the professional and the professional's physical state.

Abstract: A mutation coordinator processes in-flight file operations in a role mutable file system to provide high availability data storage and uninterrupted network request processing. The mutation coordinator uses a container with data received from in-flight operations as they progress past checkpoints to enable the file system to seamlessly mutate between server and client operational roles. The checkpoint functions determine whether the operation should halt at the checkpoint when a mutation begins and log information in the container to reflect the progress of the operation. The halted operations are then completed on the new server when the mutation is complete.