A user-annotated reference implementation identifies variable values generated by the reference implementation during its execution. A software implementation under analysis is executed. Variable values in the running memory of the program code of the software implementation under analysis, during its execution, are identified and copied. The variable values traced from the running memory of the program code are compared against the annotated variable values generated by the reference implementation, to determine a similarity between the program code under analysis, and the reference implementation. An output is generated that is indicative of whether the traced variables from the program code under analysis are the same as the annotated variable values generated by the reference implementation.

Identifying a trace based on wait chain coverage analysis comprises identifying a scenario covered by a plurality of traces, as well as a plurality of scenario phases. Each phase has corresponding phase beginning and ending, and is covered by corresponding trace(s) of the plurality of traces. For each prior instance of each phase, a corresponding wait chain comprising a series of wait operations is identified. After identifying signatures configured to match a subset of wait operations in wait chain(s), at least a signature coverage is calculated over the identified corresponding wait chains. The signature coverage characterizes portions(s) of these wait chains that are matched by the signature(s). Based on calculating the signature coverage, one or more of the plurality of traces are identified as having unknown wait states, based on the identified trace(s) corresponding to a larger amount of uncovered wait chain portions than others of the plurality of traces.

The present invention is related to a digital circuit testing and analysis module system comprising a memory (22). The memory (22) is addressed by numerical values defined by a group of digital signals. A respective memory location associated with a specific numerical value indicates a status of the group of digital signals. The status can for example reflect the validity of the signals in the group of signals when testing a circuit.

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.

A bus monitoring system, a method and an apparatus, wherein the system comprises: a bus node; a bus monitoring module configured to monitor a first bus where the bus monitoring module is located to generate monitoring information; an information storage module configured to acquire the monitoring information from the bus monitoring module through a second bus; the first bus being configured to connect a master device and a slave device of the bus node; the second bus being configured to connect the information storage module and the bus monitoring module, wherein the second bus is independent from the first bus. By means of the present disclosure, the technical problem that bus monitoring information cannot be acquired when bus exception occurs in the related art is solved.

High level synthesis (HLS) begins with high-level specification of a problem, where behavior is generally decoupled from e.g., clock-level timing. Programming code can be run and debugged during functional simulation using debugging techniques. However, it is not possible to understand execution flow of register transfer level instructions (RTL) generated during RTL debug. Conventionally, it is challenging and not possible due to nature of debugging techniques which ignore printf statements in code for invocation. Systems and methods of present disclosure synthesize printf and/or scanf statements for generating debug messages in HLS code, wherein printf and/or scanf statements is/are included before/after function(s) in sections comprising instructions in code and synthesized as a block during run-time which communicate with host system and debug messages are generated for display on screen. This enables traceability of the code execution on the screen and printf/scanf statements output can be observed without any challenges.

A method of analyzing a performance of a microservices-based application comprises generating a plurality of traces from a plurality of spans associated with the microservices-based application. The method also comprises generating a plurality of data sets each associated with a respective analysis mode of a plurality of analysis modes using the plurality of traces, wherein each analysis mode extracts a different level of detail for analyzing the performance of the services in the application from the plurality of spans. Further, the method comprises selecting, based on a first user query, a first analysis mode from the plurality of analysis modes for generating a response to the first user query. The method also comprises accessing a data set of the plurality of data sets that is associated with the first analysis mode and generating the response to the first user query using the data set associated with the first analysis mode.

Methods, systems and computer program products for tracking, encoding and decoding the code-location of runtime events. The system receives an encoded identifier function call as a parameter for a first function included in at least one file in a plurality of files of a source code base. The system returns a compact encoded identifier generated by the encoded identifier function call during compilation of the plurality of files of the source code base. In response to receiving a runtime event's identifier from execution of the source code base, the system decodes the encoded identifier to trace back to a unique location of the first function in the source code base, thereby identifying the filename and line number where the event occurred.

A semiconductor device includes a data bus, a data memory, a selector, a processor, and a debug controller. The selector is configured to be controlled by the debug controller to be in either a first selecting state in which the processor transmits a first signal to the data bus and a second selecting state in which the debug controller transmits a second signal to the data bus. The debug controller is configured to control the state of the selector based on the reception state of a predetermined command from an external device as well as the states of a read enable signal and a write enable signal from the processor such that, when the selector is in the second selecting state, the debug controller accesses the data bus via the selector.

Methods and systems are presented for dynamically configuring a software application to log different data variables without requiring re-deploying the software application. When a software application is executed, the software application may obtain and/or generate data variables. During runtime of the software application while processing a request, the software application may access a log script external to the software application. The software application may select a subset of data variables for logging, and may record only the subset of data variables in a log file. The log script may be modified without requiring the software application to be modified or re-deployed such that the software application may log different subset of data variables while processing different processes based on different versions of the log script.