Patent classifications
G06F11/3648
Processor with debug pipeline
A processor includes an execution pipeline that includes a plurality of execution stages, execution pipeline control logic, and a debug system. The execution pipeline control logic is configured to control flow of an instruction through the execution stages. The debug system includes a debug pipeline and debug pipeline control logic. The debug pipeline includes a plurality of debug stages. Each debug pipeline stage corresponds to an execution pipeline stage, and the total number of debug stages corresponds to the total number of execution stages. The debug pipeline control logic is coupled to the execution pipeline control logic. The debug pipeline control logic is configured to control flow through the debug stages of debug information associated with the instruction, and to advance the debug information into a next of the debug stages in correspondence with the execution pipeline control logic advancing the instruction into a corresponding stage of the execution pipeline.
SECURITY PROCESSOR CONFIGURED TO AUTHENTICATE USER AND AUTHORIZE USER FOR USER DATA AND COMPUTING SYSTEM INCLUDING THE SAME
A security processor includes a key generator circuit configured to randomly generate a key, an encryption circuit configured to encrypt user data based on the key, and a security manager circuit configured to receive a first user identification (ID), which uniquely corresponds to a user of a device, and determine whether to allow access to the user data by authenticating the first user
ID.
Synthesizing printf and scanf statements for generating debug messages in high-level synthesis (HLS) code
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.
Pipelined micro controller unit
A 3D NAND memory device is provided in which control is performed by two microcontroller units (MCU). During manufacture of the memory device, bug fixes required for the controller may be addressed using a software solution by which an instruction requiring correction in one of the two MCUs is replaced with a corrected instruction stored in a RAM.
Methods, systems, articles of manufacture and apparatus to detect code defects
Methods, apparatus, systems, and articles of manufacture are disclosed to detect code defects. An example apparatus includes repository interface circuitry to retrieve code repositories corresponding to a programming language of interest, tree generating circuitry to generate parse trees corresponding to code blocks contained in the code repositories, directed acyclic graph (DAG) circuitry to generate DAGs corresponding to respective ones of the parse trees, the DAGs including control flow information and data flow information, abstraction generating circuitry to abstract the DAGs, invariant identification circuitry to extract invariants from the abstracted DAGs, and DAG comparison circuitry to cluster respective ones of the extracted invariants to identify respective ones of the abstracted DAGs with common invariants.
Diffing a subject replayable execution trace against a comparison replayable execution trace
Diffing a subject replayable trace against a comparison replayable trace includes identifying a first plurality of functions within a first sequence of instructions recorded in the subject trace, and identifying a second plurality of functions a second sequence of instructions recorded in the comparison trace. A first plurality of groups of the first plurality of functions, and a second plurality of groups of the second plurality of functions are identified. The first and second pluralities of groups are compared, including determining, based on an identity of each group, and on function(s) corresponding to the group, if each first group in the first plurality of groups is at least one of: equal to a second group in the second plurality of groups, a replacement of a second group in the second plurality of groups, deleted from the second plurality of groups, or inserted into the second plurality of groups.
Method and apparatus for protecting trace data of a remote debug session
Methods and apparatus for protecting trace data of a remote debug session for a computing system. In one embodiment, a method includes storing trace data received from one or more trace interfaces to a storage location of a target device, where the trace data is generated from execution at the target device, and where the trace data is protected from an unauthorized access. The method continues with transmitting the trace data to a debug host computer with encryption through a communication channel between the target device and the debug host computer.
Assessing performance of a hardware design using formal evaluation logic
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.
Memory leak detection using real-time memory growth pattern analysis
The disclosure describes techniques that enable detection of memory leaks of software executing on devices within a computer network. An example network device includes memory and processing circuitry. The processing circuitry monitors a usage of the memory by a software component operating within the network device. The processing circuitry periodically determines a memory growth pattern score for the software component based on the usage of the memory. The processing circuitry also predicts whether the user-level process is experiencing a memory leak based on the memory growth pattern score. The processing circuitry applies confirmation criteria to current memory usage of the software component to confirm that the software component is experiencing the memory leak. When the software component is experiencing the memory leak, the processing circuitry generates an alert.
TRACING CIRCUIT, SEMICONDUCTOR DEVICE, TRACER, AND TRACING SYSTEM
A tracing circuit is integrated in a semiconductor device along with a microprocessor including an m-bit program counter, and externally outputs a tracing clock along with an n-bit tracing data (where 2≤n≤m). The tracing circuit, when the program counter remains unchanged, synchronously with the tracing clock sets the tracing data to a first output value; when the program counter is incremented, synchronously with the tracing clock sets the tracing data to a second output value; and when the program counter is loaded, synchronously with the tracing clock sets the tracing data to a third output value, and then suspends the state machine in the microprocessor and split-outputs, as the tracing data, the branch destination address or interrupt destination address loaded in the program counter.