Methods, apparatus, systems, and articles of manufacture are disclosed to debug a hardware accelerator such as a neural network accelerator for executing Artificial Intelligence computational workloads. An example apparatus includes a core with a core input and a core output to execute executable code based on a machine-learning model to generate a data output based on a data input, and debug circuitry coupled to the core. The debug circuitry is configured to detect a breakpoint associated with the machine-learning model, compile executable code based on at least one of the machine-learning model or the breakpoint. In response to the triggering of the breakpoint, the debug circuitry is to stop the execution of the executable code and output data such as the data input, data output and the breakpoint for debugging the hardware accelerator.

Methods and devices for testing graphics hardware may include reading content of a selected capture file from a plurality of capture files. The methods and devices may include transferring content from the selected capture file to an emulator memory of an emulator separate from the computer device. The methods and devices may include executing at least one pseudo central processing unit (pseudo CPU) operation to coordinate the execution of work on a graphics processing unit (GPU) of the emulator using the content from the selected capture file to test the GPU. The methods and devices may include receiving and store rendered image content from the emulator when the work is completed.

Methods and systems are disclosed for debugging program code at instruction level by emulating an epilog. Issues with retrieving values that a caller function has stored in non-volatile registers before calling a callee function are addressed at the instruction code level by through emulation. The epilog of the callee function may be emulated after copying a computing environment of the target program code from a target system to an emulation system. When the debugged code does not include an epilog, values that a caller function stored before calling a callee function in non-volatile registers may be retrieved by emulating the calling function forward from the breakpoint.

Provided are systems, methods, and media for concurrency conflict testing for shared resources. An example method includes identifying shared resources that are to be accessed by an application. Generating a plurality of concurrency test scenarios based on the shared resources. Analyzing a plurality of concurrency test cases to detect which concurrency test cases include a reference to the shared resources. Executing a concurrency test scenario. Performing the following while or before the concurrency test scenario is executing, obtaining analyzed concurrency test cases associated with the concurrency test scenario which referenced the shared resources, obtaining application modules pertaining to the obtained concurrency test cases, generating concurrency application modules by adding breakpoints to the obtained application modules, executing the obtained concurrency test cases until all of the obtained concurrency test cases are latched at the breakpoints, and simultaneously resuming the execution of the obtained concurrency test cases.

An image processing apparatus includes a host controller that controls a hardware resource, a guest controller, an emulator that is provided between the host controller and the guest controller and allows the guest controller to control the hardware resource, and a changer that changes an HDL program, wherein the guest controller includes a guest driver, the emulator includes a device emulator that emulates the hardware resource by executing the changed HDL program, and a switcher that switches control to any one of a first control for controlling the host controller in accordance with control of the hardware resource by the guest driver and allowing the hardware resource to be controlled, and a second control for controlling the device emulator in accordance with the control of the hardware resource by the guest driver.

A hardware monitor arranged to assess performance of a hardware design for an integrated circuit to complete a task. The hardware monitor includes monitoring and counting logic configured to count a number of cycles between start and completion of the symbolic task in the hardware design; and property evaluation logic configured to evaluate one or more formal properties related to the counted number of cycles to assess the performance of the hardware design in completing the symbolic task. The hardware monitor may be used by a formal verification tool to exhaustively verify that the hardware design meets a desired performance goal and/or to exhaustively identify a performance metric (e.g. best case and/or worst case performance) with respect to completion of the task.

Methods, media, and systems for detecting anomalous program executions are provided. In some embodiments, methods for detecting anomalous program executions are provided, comprising: executing at least a part of a program in an emulator; comparing a function call made in the emulator to a model of function calls for the at least a part of the program; and identifying the function call as anomalous based on the comparison. In some embodiments, methods for detecting anomalous program executions are provided, comprising: modifying a program to include indicators of program-level function calls being made during execution of the program; comparing at least one of the indicators of program-level function calls made in the emulator to a model of function calls for the at least a part of the program; and identifying a function call corresponding to the at least one of the indicators as anomalous based on the comparison.

Methods, media, and systems for detecting anomalous program executions are provided. In some embodiments, methods for detecting anomalous program executions are provided, comprising: executing at least a part of a program in an emulator; comparing a function call made in the emulator to a model of function calls for the at least a part of the program; and identifying the function call as anomalous based on the comparison. In some embodiments, methods for detecting anomalous program executions are provided, comprising: modifying a program to include indicators of program-level function calls being made during execution of the program; comparing at least one of the indicators of program-level function calls made in the emulator to a model of function calls for the at least a part of the program; and identifying a function call corresponding to the at least one of the indicators as anomalous based on the comparison.

A hardware monitor arranged to assess performance of a hardware design for an integrated circuit to complete a task. The hardware monitor includes monitoring and counting logic configured to count a number of cycles between start and completion of the symbolic task in an instantiation of the hardware design; and property evaluation logic configured to evaluate one or more formal properties related to the counted number of cycles to assess the performance of the instantiation of the hardware design in completing the symbolic task. The hardware monitor may be used by a formal verification tool to exhaustively verify that the hardware design meets a desired performance goal and/or to exhaustively identify a performance metric (e.g. best case and/or worst case performance) with respect to completion of the task.

A touch detector with a code debugger is provided. The touch detector can include a base, a PCBA with a base-side of the PCBA mounted to the base, a frame mounted to a frame-side of the PCBA, and a debugging device mounted on, coupled to, or soldered to the PCBA for debugging other components soldered to the PCBA. The debugging device can be externally accessible to a user when the base, the PCBA, and the frame are mounted together. The touch detector can also include a battery and/or a USB port, each of which can be externally accessible to the user when the base, the PCBA, and the frame are mounted together.