A processor verification-oriented instruction stream exception positioning method

Abstract

The application discloses a kind of processor verification-oriented instruction stream exception positioning method, a kind of processor verification exception positioning device and a kind of computer readable storage medium, the method comprises: S1, instruction stream acquisition and pre-processing;S2, construct simulation call stack;S3, control flow transfer classification and label;S4, abnormal path extraction and structured report generation;S5, software and hardware defect automatic root cause determination.The application is liberated from the tedious work of manual tracing instruction stream by automatically constructing simulation call stack and control flow transfer label, and the time of exception positioning can be shortened from several hours to minute level, significantly improve the efficiency of exception positioning.

Description

Technical Field

[0001] This invention relates to the field of processor verification, and more specifically, to a method for locating instruction stream anomalies for processor verification, a device for locating processor verification anomalies, and a computer-readable storage medium. Background Technology

[0002] Processor chip verification is a crucial step in the chip development process, with its core task being to identify functional defects in the processor design as much as possible before tape-out. As processor architectures become increasingly complex (multi-core, out-of-order execution, virtualization, multi-level caching, etc.), the complexity of verification scenarios grows exponentially. A typical verification test case may execute millions or even billions of instructions. When test cases fail (such as co-simulation mismatch, assertion violations, program crashes, etc.), the core challenge of processor verification lies in quickly locating the root cause of the error from the massive instruction execution flow and distinguishing whether the error is caused by a hardware design flaw or a software problem in the test program itself.

[0003] Currently, the commonly used anomaly localization methods in the processor verification field mainly include the following categories:

[0004] 1. Co-simulation: This method runs a reference model (ISS, Instruction Set Simulator) and the design under test (DUT) in parallel, comparing the execution results instruction by instruction. When a mismatch is detected, the simulation stops and reports the PC (Program Counter) and register states at the mismatch point. A representative tool is Spike, which performs co-simulation with RTL simulations.

[0005] 2. Waveform Debugging: Use simulation tools (such as VCS, Xcelium) to generate waveform files (FSDB / VCD format), and use waveform viewing tools (such as Verdi) to trace each signal to locate anomalies at the hardware signal level.

[0006] 3. Log Analysis: Insert print statements into the test program, or use the processor's debug interface (such as RISC-V's Debug Module, ARM's ETM / PTM) to output execution logs, and locate anomalies by analyzing the logs.

[0007] Prior art related to this invention:

[0008] The technical solution of existing technology 1:

[0009] Co-simulation is currently the most mainstream method for anomaly detection and localization in processor verification. Its basic scheme is as follows:

[0010] (1) Reference model execution: The same test program is executed using the gold reference model (such as Spike / Sail-RS for RISC-V, ARM model for ARM) to produce reference execution results.

[0011] (2) DUT execution: The processor under test is run in the RTL simulator with the same test program to produce actual execution results.

[0012] (3) Item-by-item comparison: When committing (Commit / Retire) instructions, the execution results of the DUT (PC, register values, memory write operations) are compared with the reference model.

[0013] (4) Mismatch Report: When an inconsistency is detected, the simulation stops and outputs the PC of the mismatch instruction, the instruction code, the expected value and the actual value.

[0014] Disadvantages of existing technology 1:

[0015] While co-simulation can accurately detect mismatches at the instruction execution level, it has the following significant shortcomings in anomaly localization:

[0016] 1. Lack of software execution context: The mismatch point in the co-simulation report only shows the PC and register states of a single instruction, lacking contextual information such as the function call level of the instruction and the source of control flow. Verification engineers need to manually read the disassembled code to trace how the instruction was executed, which is extremely inefficient.

[0017] 2. Inability to differentiate between hardware and software issues: When a mismatch occurs, it may be due to hardware design flaws (such as ALU calculation errors, branch prediction errors, cache coherence issues) or software flaws in the test program itself (such as out-of-bounds access, uninitialized variables, race conditions). Existing methods only report "what went wrong," failing to answer "why it went wrong" and "whose responsibility is it."

[0018] 3. Control flow anomalies are difficult to trace: For mismatches caused by implicit control transfers such as interrupts, exceptions, and system calls, since these transfers are not triggered by explicit instructions in the program, verification engineers find it difficult to directly identify them from the instruction flow. They need a deep understanding of the processor's interrupt controller, exception handling mechanism, and privilege level architecture, making the localization cost extremely high.

[0019] 4. Difficulty in locating mismatches in massive instruction streams: A typical verification test may execute hundreds of millions of instructions, and mismatches can occur anywhere in the execution flow. Even knowing the mismatch PC, reconstructing the control flow path that caused the mismatch from the execution trajectories of hundreds of millions of instructions is still a time-consuming and error-prone manual task.

[0020] Prior art related to this invention:

[0021] Technical solution of existing technology 2:

[0022] Waveform debugging is the most basic debugging method in hardware verification. Verification engineers generate waveform files using simulation tools, and use tools such as Verdi to view signal waveforms, trace the transition history of signals, and locate defects in the hardware design.

[0023] Disadvantages of existing technology 2:

[0024] 1. Low level of abstraction: Waveform debugging works at the signal level. Verification engineers need to deal with thousands of signals, making it difficult to quickly correlate them with the execution semantics at the software level (such as "which line of which function this instruction belongs to").

[0025] 2. Unable to build control flow view: The waveform tool does not provide instruction-level control flow analysis capabilities and cannot automatically build function call stacks or control flow graphs. Verification engineers need to manually trace changes in the PC signal to reconstruct the execution path.

[0026] 3. Extremely high time cost: In complex processor designs, tracing a mismatch signal to its root cause can take hours or even days, severely limiting verification efficiency. Summary of the Invention

[0027] This invention provides a method for locating instruction stream anomalies for processor verification, a device for locating processor verification anomalies, and a computer-readable storage medium to solve the technical problems existing in the prior art.

[0028] To achieve the above objectives, the present invention provides a method for instruction stream anomaly localization for processor verification, comprising the following steps:

[0029] S1. Command Stream Acquisition and Preprocessing:

[0030] The system collects raw instruction execution trajectories output from the processor simulation environment. Each trajectory carries at least the PC, instruction code, privilege level, register read / write, memory operation, CSR operation, and execution cycle fields. It decodes each instruction according to the target processor's ISA specification, extracting the opcode, operands, and immediate values. It identifies and marks all control transfer instructions, including direct jumps, indirect jumps, conditional branches, system calls, interrupt returns, and exception returns, outputting a structured instruction stream sequence.

[0031] S2. Construct the simulation call stack:

[0032] Based on the processor ABI specification, the structured instruction stream sequence is parsed without relying on hardware stack memory. The function call hierarchy is reconstructed solely through the semantics of the decoded control transfer instructions. Push, Pop, and stack top replacement operations are executed based on call / return instruction characteristics. Stack frame information is recorded each time an instruction is pushed onto the stack. Each stack frame contains at least the return address, calling PC, privilege level, execution cycle, transfer reason, and a snapshot of critical registers. Function boundaries are confirmed through function prologue and tail instruction pattern matching. For indirect calls triggered by function pointers, the target function is parsed using the symbol table to generate a full-process simulated call stack sequence.

[0033] S3. Control Flow Transfer Classification and Labeling:

[0034] It distinguishes between two types of control transfer events: those triggered by explicit program instructions and those triggered implicitly by processor hardware. It identifies interrupts and exceptions by checking CSR read / write status and matching interrupt vector addresses, and further distinguishes exception subtypes based on the values ​​in the mcause / scause registers. It identifies ECALL / SVC system calls and records privilege level switching changes. It distinguishes between conditional branches that have occurred and unconditional jumps, generating control transfer annotation records for each discontinuous PC transfer. The annotations include the source PC, target PC, transfer type, transfer reason, preceding and following privilege levels, and associated stack frames.

[0035] S4. Anomaly Path Extraction and Structured Report Generation:

[0036] It receives error detection point information from co-simulation, assertion triggering, and program crash outputs. Each error detection point includes at least a mismatch PC, mismatch type, and exception occurrence period. It then traces back from the error detection point along the control flow annotation sequence to reconstruct the complete error execution path. It compresses the excessively long path, retaining only key nodes such as function switches, interrupt exceptions, system calls, and branch jumps, and preserving multiple complete instructions adjacent to the error. It outputs a structured exception location report containing an error summary, a complete function call chain, privilege level change records, and a real-time simulation call stack snapshot.

[0037] S5. Automatic root cause determination of software and hardware defects:

[0038] A rule base for determining the cause is established based on the ISA specification. Each instruction's actual execution behavior is compared with the specification's expectation: if the instruction execution result, control jump target, CSR read / write, or interrupt trigger timing violates the ISA specification, it is determined to be a hardware defect; if the instruction execution fully complies with the ISA specification, but the program logic contains illegal address access, uninitialized variables, incorrect system parameters, or data races, it is determined to be a software defect; if the instruction behavior is consistent with the ISA but does not match the output of the golden reference model, it is determined to be a reference model defect. A root cause analysis report carrying the determination rules, confidence level, and debugging suggestions is output.

[0039] In one embodiment of the present invention, optionally, in step S1, the processor simulation environment is an RTL simulation environment or a co-simulation environment, and the gold reference model includes Spike, Sail-RS, and ARM ISS models.

[0040] In one embodiment of the present invention, optionally, in step S2, for the RISC-V architecture, the instructions JAL rd=ra and JALR rd=ra are determined to be function calls executing Push operations; JALR rs1=ra is determined to be a function return executing Pop operations; for the ARM architecture, BL and BLX are determined to be function calls, and BX LR and POP {PC} are determined to be function returns.

[0041] In one embodiment of the present invention, optionally, in step S3, the interrupt / exception determination conditions include: the target PC falls into the interrupt vector table address range and the mepc / sepc register is written, the MRET / ERET interrupt return instruction is executed, and the mcause / scause register is written with a fault code.

[0042] In one embodiment of the present invention, optionally, in step S4, the path compression rule is: within the same function, instructions executed sequentially only retain the function entry and exit nodes, and the original instruction records of a preset number of steps away from the error detection point are fully retained.

[0043] In one embodiment of the present invention, optionally, in step S5, the hardware defect determination scenarios include ALU operation errors, branch jump address calculation errors, unexpected interrupt triggering, interrupt vector address errors, pipeline instruction submission order violations, and memory read / write data mismatches; the software defect determination scenarios include illegal memory access, stack overflow, uninitialized variable reading, system call parameter errors, and multi-core data contention.

[0044] In one embodiment of the present invention, the method is optionally adapted to multiple processor architectures such as RISC-V, ARM, and x86, and can be ported simply by replacing the corresponding ISA and ABI specification configuration files.

[0045] The present invention also provides a processor verification anomaly location device for performing the above method, comprising:

[0046] The instruction stream preprocessing module is used to acquire simulation instruction trajectories, decode instructions, and mark control transfer instructions.

[0047] The simulation call stack construction module is used to parse instructions according to ABI rules and generate a dynamic stack frame sequence;

[0048] The control flow annotation module is used to identify branches, interrupts, exceptions, system calls, and generate transfer annotations;

[0049] The path backtracking and reporting module is used to receive error points, backtrack to generate abnormal execution paths, and output a location report;

[0050] The root cause analysis and determination module stores ISA determination rules, automatically distinguishes between three types of faults: hardware defects, software, and reference model, and outputs a root cause report.

[0051] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described processor-oriented instruction stream anomaly localization method.

[0052] The present invention has the following beneficial technical effects:

[0053] 1. Significantly improves anomaly localization efficiency: By automatically constructing simulation call stacks and control flow transfer annotations, verification engineers are freed from the tedious work of manually tracing instruction flows, and anomaly localization time can be shortened from several hours to minutes.

[0054] 2. Lower the verification threshold: The automatically generated anomaly localization report includes function call chains, control transfer reasons, and root cause classifications, allowing verification engineers to quickly locate problems without needing in-depth understanding of processor microarchitecture details.

[0055] 3. Clearly define responsibility: By classifying root causes in software and hardware, quickly distinguish between hardware design defects and test program defects, avoiding the shifting of responsibility between the verification team and the design team.

[0056] 4. Support for debugging in complex scenarios: This method can automatically identify and label implicit control transfer scenarios such as interruptions, exceptions, and system calls, solving the problem of difficulty in locating such scenarios in existing methods.

[0057] 5. Architectural versatility: Based on the ISA and ABI specifications, this invention is applicable to various processor architectures such as RISC-V, ARM, and x86, and has good versatility and scalability. Detailed Implementation

[0058] The technical solutions in the embodiments of the present invention will be clearly and completely described below. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0059] As processor architecture complexity continues to increase, the scale of verification test cases has grown from tens of thousands of instructions to billions of instructions. When test cases fail, verification engineers face a fundamental dilemma: they know that an instruction has failed to execute, but they cannot quickly determine why the instruction was executed, what control flow path it went through, and whether the error should be attributed to a hardware design flaw or a software problem in the test program itself.

[0060] To address the aforementioned pain points, this invention proposes a method for instruction flow anomaly localization for processor verification. This method automatically constructs a simulated call stack from the processor execution flow, combining multi-dimensional information such as processor interrupt / exception models, branch instruction semantics, privileged call instruction (System Call) identification, and assembly ABI (Application Binary Interface) rules to achieve the following objectives:

[0061] 1. Automatically reconstruct the error execution path: When a test fails, automatically reconstruct the complete instruction path that caused the error from the instruction execution flow, including the function call level, control flow transfer points, and the reason for each transfer.

[0062] 2. Control flow transfer reason labeling: For each control transfer on the path, automatically label its type (function call, function return, conditional branch, interrupt, exception, system call, etc.) and specific reason.

[0063] 3. Root Cause Classification: Automatically analyze the error execution path, determine whether the anomaly is caused by a software defect (test program logic error) or a hardware defect (processor design error), and provide the basis for the judgment.

[0064] First embodiment:

[0065] This invention provides a method for instruction stream anomaly localization for processor verification, comprising the following steps:

[0066] S1. Command Stream Acquisition and Preprocessing:

[0067] The system collects raw instruction execution trajectories output from the processor simulation environment. Each trajectory carries at least the PC, instruction code, privilege level, register read / write, memory operation, CSR operation, and execution cycle fields. It decodes each instruction according to the target processor's ISA specification, extracting the opcode, operands, and immediate values. It identifies and marks all control transfer instructions, including direct jumps, indirect jumps, conditional branches, system calls, interrupt returns, and exception returns, outputting a structured instruction stream sequence.

[0068] S2. Construct the simulation call stack:

[0069] Based on the processor ABI specification, the structured instruction stream sequence is parsed without relying on hardware stack memory. The function call hierarchy is reconstructed solely through the semantics of the decoded control transfer instructions. Push, Pop, and stack top replacement operations are executed based on call / return instruction characteristics. Stack frame information is recorded each time an instruction is pushed onto the stack. Each stack frame contains at least the return address, calling PC, privilege level, execution cycle, transfer reason, and a snapshot of critical registers. Function boundaries are confirmed through function prologue and tail instruction pattern matching. For indirect calls triggered by function pointers, the target function is parsed using the symbol table to generate a full-process simulated call stack sequence.

[0070] S3. Control Flow Transfer Classification and Labeling:

[0071] It distinguishes between two types of control transfer events: those triggered by explicit program instructions and those triggered implicitly by processor hardware. It identifies interrupts and exceptions by checking CSR read / write status and matching interrupt vector addresses, and further distinguishes exception subtypes based on the values ​​in the mcause / scause registers. It identifies ECALL / SVC system calls and records privilege level switching changes. It distinguishes between conditional branches that have occurred and unconditional jumps, generating control transfer annotation records for each discontinuous PC transfer. The annotations include the source PC, target PC, transfer type, transfer reason, preceding and following privilege levels, and associated stack frames.

[0072] S4. Anomaly Path Extraction and Structured Report Generation:

[0073] It receives error detection point information from co-simulation, assertion triggering, and program crash outputs. Each error detection point includes at least a mismatch PC, mismatch type, and exception occurrence period. It then traces back from the error detection point along the control flow annotation sequence to reconstruct the complete error execution path. It compresses the excessively long path, retaining only key nodes such as function switches, interrupt exceptions, system calls, and branch jumps, and preserving multiple complete instructions adjacent to the error. It outputs a structured exception location report containing an error summary, a complete function call chain, privilege level change records, and a real-time simulation call stack snapshot.

[0074] S5. Automatic root cause determination of software and hardware defects:

[0075] A rule base for determining the cause is established based on the ISA specification. Each instruction's actual execution behavior is compared with the specification's expectation: if the instruction execution result, control jump target, CSR read / write, or interrupt trigger timing violates the ISA specification, it is determined to be a hardware defect; if the instruction execution fully complies with the ISA specification, but the program logic contains illegal address access, uninitialized variables, incorrect system parameters, or data races, it is determined to be a software defect; if the instruction behavior is consistent with the ISA but does not match the output of the golden reference model, it is determined to be a reference model defect. A root cause analysis report carrying the determination rules, confidence level, and debugging suggestions is output.

[0076] In one embodiment of the present invention, optionally, in step S1, the processor simulation environment is an RTL simulation environment or a co-simulation environment, and the gold reference model includes Spike, Sail-RS, and ARM ISS models.

[0077] In one embodiment of the present invention, optionally, in step S2, for the RISC-V architecture, the instructions JAL rd=ra and JALR rd=ra are determined to be function calls executing Push operations; JALR rs1=ra is determined to be a function return executing Pop operations; for the ARM architecture, BL and BLX are determined to be function calls, and BX LR and POP {PC} are determined to be function returns.

[0078] In one embodiment of the present invention, optionally, in step S3, the interrupt / exception determination conditions include: the target PC falls into the interrupt vector table address range and the mepc / sepc register is written, the MRET / ERET interrupt return instruction is executed, and the mcause / scause register is written with a fault code.

[0079] In one embodiment of the present invention, optionally, in step S4, the path compression rule is: within the same function, instructions executed sequentially only retain the function entry and exit nodes, and the original instruction records of a preset number of steps away from the error detection point are fully retained.

[0080] In one embodiment of the present invention, optionally, in step S5, the hardware defect determination scenarios include ALU operation errors, branch jump address calculation errors, unexpected interrupt triggering, interrupt vector address errors, pipeline instruction submission order violations, and memory read / write data mismatches; the software defect determination scenarios include illegal memory access, stack overflow, uninitialized variable reading, system call parameter errors, and multi-core data contention.

[0081] In one embodiment of the present invention, the method is optionally adapted to multiple processor architectures such as RISC-V, ARM, and x86, and can be ported simply by replacing the corresponding ISA and ABI specification configuration files.

[0082] The present invention also provides a processor verification anomaly location device for performing the above method, comprising:

[0083] The instruction stream preprocessing module is used to acquire simulation instruction trajectories, decode instructions, and mark control transfer instructions.

[0084] The simulation call stack construction module is used to parse instructions according to ABI rules and generate a dynamic stack frame sequence;

[0085] The control flow annotation module is used to identify branches, interrupts, exceptions, system calls, and generate transfer annotations;

[0086] The path backtracking and reporting module is used to receive error points, backtrack to generate abnormal execution paths, and output a location report;

[0087] The root cause analysis and determination module stores ISA determination rules, automatically distinguishes between three types of faults: hardware defects, software, and reference model, and outputs a root cause report.

[0088] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described processor-oriented instruction stream anomaly localization method.

[0089] Second embodiment:

[0090] The complete technical solution of the instruction stream anomaly localization method for processor verification provided by this invention consists of the following five steps, which are described in detail using a RISC-V architecture processor verification scenario as an example (this method is also applicable to ARM, x86, and other architectures):

[0091] Step 1: Command Stream Acquisition and Preprocessing

[0092] Input: Processor execution trace, processor architecture specification, ABI specification document.

[0093] deal with:

[0094] (1) Instruction Stream Acquisition: Instruction execution trajectories are acquired from the processor simulation environment (RTL simulation or co-simulation environment). Each trajectory record contains the following fields in Table 1:

[0095] PC Instruction address 0x80001000 instruction Instruction encoding 0x00f50513 priv_level Privileged level M / S / U regs_read Registers and values ​​read x10=0x80002000 regs_written Registers and values ​​written x10=0x80002004 mem_ops Memory operations R:0x80003000→0xdeadbeef csr_ops CSR Operations mepc←0x80001004 cycle Execution cycle number 1234567

[0096] Table 1

[0097] (2) Instruction decoding: According to the processor architecture specifications (such as RISC-VISA, ARM Architecture Reference Manual), each instruction is decoded to extract fields such as opcode, operand, and immediate value.

[0098] (3) Control transfer instruction identification: Mark all instructions that may lead to changes in control flow, including:

[0099] Direct jump / call (RISC-V: JAL; ARM: B / BL)

[0100] Indirect jump / call (RISC-V: JALR; ARM: BLX / BX)

[0101] Conditional branching (RISC-V: BEQ / BNE / BLT, etc.; ARM: B.EQ / B.NE, etc.)

[0102] System call / exception trigger instructions (RISC-V: ECALL / EBREAK; ARM: SVC / HVC / SMC)

[0103] Interrupt return / exception return instructions (RISC-V: MRET / SRET; ARM: ERET)

[0104] Output: A structured sequence of instruction stream records, each containing complete decoding information and control transfer markers.

[0105] Step 2: Simulated Call-Stack Construction

[0106] Input: Structured instruction stream record sequence, ABI specification.

[0107] deal with:

[0108] The core innovation of this approach is that it reconstructs the function call hierarchy by externally observing the instruction stream, rather than relying on the processor's internal stack memory. This ensures that even if the hardware stack is corrupted (potentially due to a hardware bug), the simulated call stack can still provide a reliable call context. Starting from first principles, the processor's function call mechanism is essentially a semantic convention of the ABI specification for control transfer instructions—the caller stores the return address in the link register (ra in RISC-V / LR in ARM), and the callee jumps back to that address upon return. This method reconstructs the call hierarchy by externally decoding the instruction stream and based on these ABI conventions, rather than reading from the hardware stack memory.

[0109] (1) Function call identification: Function call instructions are identified based on ABI rules. Taking RISC-V as an example, as shown in Table 2:

[0110] JAL rd=ra(×1) or JALR rd=ra(×1) function call Push(return_PC, caller_context) JALR rd=×0, rs1=ra(×1) Function return Pop() JAL rd≠ra Tail call / non-call jump Replace the top of the stack (return_PC) JALR rd=×0, rs1≠ra Indirect jump No operation

[0111] Table 2

[0112] For the ARM architecture, see Table 3:

[0113] BL / BLX function call Push(LR, caller_context) BX LR or POP {PC} Function return Pop() B (non-BL) Branch / Tail Calls Replace the top of the stack or do nothing.

[0114] Table 3

[0115] (2) Function boundary identification: The function boundary is further confirmed by matching the function prologue and epilogue patterns.

[0116] Preface mode (RISC-V example): addi sp, sp, -frame_size → sw ra, offset(sp) →sw s0, offset(sp)

[0117] Tailback mode (RISC-V example): lw ra, offset(sp) → addi sp, sp, frame_size → ret

[0118] (3) Call context recording: Record the following information for each Push operation:

[0119] struct StackFrame { uint64_t return_pc; / / Return address uint64_t caller_pc; / / Call point PC uint32_t priv_level; / / Privilege level during the call uint64_t cycle; / / Call cycle string transfer_reason; / / Transfer reason map<string, uint64_t> regs; / / Snapshot of critical registers};

[0120] (4) Indirect call processing: For indirect calls through function pointers, virtual function tables (vtables), etc., the target function name is parsed out by matching the target address of the JALR / BX instruction with the symbol table or disassembly results.

[0121] Output: Simulated call stack sequence, recording the function call hierarchy at each moment.

[0122] Step 3: Classification and Labeling of Control Flow Transfers

[0123] Inputs: Structured instruction flow record, simulated call stack, processor interrupt / exception model.

[0124] deal with:

[0125] For each control flow transfer (PC not incrementing discontinuously), classification is performed using multi-dimensional criteria. Based on first principles, processor control flow transfers originate from only two sources: (a) explicit control transfer instructions issued by the program itself (branch, jump, call, return); and (b) implicit control transfers triggered by processor hardware (interrupts, exceptions). The essential difference lies in that the former is determined by instruction encoding, while the latter is determined by the processor's internal state machine (interrupt controller, exception detection logic), and is usually accompanied by privilege level switching and CSR register updates. This method classifies controls flow accordingly.

[0126] (1) Interrupt / Exception Identification, as shown in Table 4:

[0127] The target PC ∈ the interrupt vector table address range and the CSR (mepc / sepc) is written. Entering an exception / interrupt The command is MRET / SRET / ERET and CSR (mepc / mstatus) is read. Exception / Interruption Return CSR (mcause / scause) is written to a specific value. It can be further categorized (specific anomaly types).

[0128] Table 4

[0129] Specific exception types are mapped using mcause / scause values ​​(taking RISC-V as an example), as shown in Table 5:

[0130] 0 Instruction address misaligned 2 Illegal instruction 5 Load access fault 7 Store access fault 8 / 9 / 11 Environment call (U / S / M mode) 12 / 13 / 15 Instruction / Load / Store page fault

[0131] Table 5

[0132] (2) System call identification, as shown in Table 6:

[0133] The instruction is ECALL (RISC-V) or SVC (ARM). System call Privilege level from U→S or U→M User-mode system calls Privilege level from S to M Superuser mode system calls

[0134] Table 6

[0135] (3) Branch instructions are classified as shown in Table 7:

[0136] Conditional branch instructions and branch taken Conditional branch (jump) Conditional branch instruction and branch not taken Conditional branch (no jump) Unconditional jump instruction (non-call) Unconditional redirect

[0137] Table 7

[0138] (4) Control transfer annotation: Generate annotation records for each control transfer:

[0139] struct ControlTransfer { uint64_t from_pc; / / Source PC uint64_t to_pc; / / Target PC TransferType type; / / Transfer type enumeration string reason; / / Transfer reason description uint32_t from_priv; / / Source privilege level uint32_t to_priv; / / Target privilege level uint64_t cycle; / / Cycle of occurrence StackFrame* stack_context; / / Associated call stack frame};

[0140] Output: Complete control flow transfer annotation sequence.

[0141] Step 4: Extracting and Generating Abnormal Paths

[0142] Input: Control flow transfer annotation sequence, simulation call stack, error detection point information.

[0143] deal with:

[0144] (1) Error detection point access: Receives error detection point information from the co-simulation system, assertion checker, or program crash signal, including:

[0145] Mismatched PC (Instruction address inconsistent with reference model)

[0146] Mismatch types (inconsistent register values, inconsistent memory operations, inconsistent program counters, etc.)

[0147] Mismatch cycle

[0148] (2) Error path backtracking: Starting from the error detection point, backtracking forward along the control flow transfer sequence to reconstruct the erroneous execution path. An example is shown below:

[0149] Error path = [ {func: "main", pc: 0x80001000, transfer: "function_call → foo()", cycle: 100}, {func: "foo", pc:0x80002000, transfer: "ecall (syscall: write)", cycle: 150}, {func: "trap_handler", pc: 0x80003000, transfer: "exception_return → foo()", cycle: 200}, {func: "foo", pc: 0x80002010, transfer: "branch_taken → bar()", cycle: 250}, {func: "bar", pc:0x80004000, transfer: "MISMATCH!", cycle: 300},]

[0150] (3) Path compression and key node extraction: For paths that are too long, compression is performed:

[0151] Merge consecutive sequential executions within the same function (keeping only the entry and exit points).

[0152] Retain all control transfer points

[0153] Retain complete information about the last N instructions directly related to the error.

[0154] (4) Report Generation: Generate a structured anomaly location report, including:

[0155] Error summary (error type, location, frequency)

[0156] Incorrect execution path (function call chain + control transfer annotation)

[0157] Call stack snapshot (simulated call stack state at the time of the error)

[0158] History of Privilege Level Changes

[0159] Output: Structured anomaly localization report.

[0160] Step 5: Root Cause Analysis (Software Defects vs. Hardware Defects)

[0161] Inputs: anomaly localization report, reference model execution results, ISA specifications.

[0162] deal with:

[0163] This step uses multi-dimensional heuristic analysis to determine the root cause of the anomaly. Starting from first principles, hardware defects and software defects exhibit fundamental differences in their manifestation at the instruction flow level: hardware defects mean that the processor's actual behavior deviates from the behavior defined by the ISA specification (i.e., "the processor performed an operation it should not have performed" or "the processor failed to correctly perform the operation it should have performed"); software defects mean that the processor's behavior fully conforms to the ISA specification, but the program's own logic leads to an unexpected execution path (i.e., "the processor faithfully executed the wrong program"). This method classifies and determines the cause based on this.

[0164] (1) Hardware defect judgment rules, as shown in Table 8:

[0165] The instruction execution result does not conform to the ISA specification. Such as errors in ALU calculation results, errors in shift operations, etc. Compare each instruction with the ISA specification. Control transfer target error The branch instruction jump address does not match the ISA calculation result. Calculate the expected target PC based on the instruction code. Unexpected interruption / exception triggering The processor triggered an interrupt / exception at a time when it should not have. Check interrupt enable status and interrupt source status. Interrupt / Exception Vector Address Error Interrupt jump target address does not match interrupt vector table Calculate the expected vector based on the mtvec / stvec register values. CSR Behavior Abnormality CSR read / write values ​​do not conform to the specification, or have not been updated according to the specification. Check reading and writing behavior against CSR guidelines Memory access data error The data returned by Load does not match the data actually stored in memory. Maintain shadow memory models for comparison Out-of-order execution / pipeline anomaly Command submission order violates architectural specifications Check the consistency between the submission order and the program order.

[0166] Table 8

[0167] (2) Software defect judgment rules, as shown in Table 9:

[0168] The instructions were executed correctly, but the program logic was incorrect. If the conditional branch condition is calculated incorrectly, it may cause the jump direction to be incorrect. The instruction output conforms to the ISA specification, but the program behaves abnormally. Accessing an illegal address The program accessed an unmapped or unauthorized address. The hardware correctly triggered the exception (Access Fault / Page Fault). Stack overflow / stack corruption Stack operations in the program may cause a stack overflow or the return address to be overwritten. Analyze the changes between the simulated call stack and the actual stack pointer. Uninitialized variables used The program used uninitialized registers or memory values. Tracing register / memory definitions - using chains Competitive conditions Data races occur in multi-core scenarios. Analysis of multi-core instruction interleaving sequences System call parameter error The program passed an invalid system call number or parameter. Checking register values ​​when executing ECALL / SVC instructions

[0169] Table 9

[0170] (3) Comprehensive judgment logic:

[0171] if (instruction execution result != ISA specification expectation): return HARDWARE_BUG / / Processor did not execute according to specification elif (instruction execution result == ISA specification expectation) and (instruction execution result != reference model result): return REFERENCE_MODEL_BUG / / Reference model may be incorrect elif (instruction execution result == ISA specification expectation) and (program behavior is abnormal): if (the exception is caused by the program's own logic): return SOFTWARE_BUG / / Program logic error elif (the exception is caused by an external event such as an interrupt / exception): if (the interrupt / exception is triggered at the correct time): return SOFTWARE_BUG / / Program did not handle the interrupt correctly else: return HARDWARE_BUG / / The interrupt / exception is triggered at the wrong time

[0172] (4) Root Cause Analysis Report: Generate a root cause analysis report, including:

[0173] Root cause classification (hardware defect / software defect / reference model defect)

[0174] Judgment basis (rules and evidence for determining hits)

[0175] Confidence assessment

[0176] Suggested debugging directions

[0177] Output: Root cause analysis report.

[0178] A comparison of the present invention with the prior art is shown in Table 10:

[0179] Report Granularity Single instruction mismatch signal level Complete execution path + call stack Control flow analysis none None (manual) Automatically label the reason for each transfer Hardware and software distinction Not supported Not supported Supports automatic judgment Interruption / Exception Tracing difficulty Extremely difficult Automatic identification and classification Function call context none none Simulated call stack Positioning efficiency Low (manual traceability required) Extremely low High (automation) Applicable stage Verification phase Verification phase Verification phase + post-silicon debugging

[0180] Table 10

[0181] Those skilled in the art will understand that the modules in the apparatus of the embodiments can be distributed in the apparatus of the embodiments as described in the embodiments, or they can be located in one or more devices different from this embodiment with corresponding changes. The modules of the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0182] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for instruction stream anomaly localization for processor verification, characterized in that, Includes the following steps: S1. Command Stream Acquisition and Preprocessing: Collect the raw instruction execution traces output by the processor simulation environment. Each trace should carry at least the PC, instruction code, privilege level, register read / write, memory operation, CSR operation, and execution cycle field. According to the target processor ISA specification, each instruction is decoded to extract the opcode, operand, and immediate value; all control transfer instructions are identified and marked, including direct jump, indirect jump, conditional branch, system call, interrupt return, and exception return instructions, and a structured instruction stream sequence is output. S2. Construct the simulation call stack: Based on the processor ABI specification, the structured instruction stream sequence is parsed without relying on hardware stack memory. The function call hierarchy is reconstructed solely through the semantics of the decoded control transfer instructions. Push, Pop, and stack top replacement operations are executed based on call / return instruction characteristics. Stack frame information is recorded each time an instruction is pushed onto the stack. Each stack frame contains at least the return address, calling PC, privilege level, execution cycle, transfer reason, and a snapshot of critical registers. Function boundaries are confirmed through function prologue and tail instruction pattern matching. For indirect calls triggered by function pointers, the target function is parsed using the symbol table to generate a full-process simulated call stack sequence. S3. Control Flow Transfer Classification and Labeling: It distinguishes between two types of control transfer events: those triggered by explicit program instructions and those triggered implicitly by processor hardware. It identifies interrupt and exception events by matching CSR read / write status and interrupt vector addresses, and further distinguishes the sub-types of exceptions based on the values ​​of the mcause / scause registers. Identify ECALL / SVC system calls and record privilege level switching changes; distinguish whether a conditional branch jump occurs or not, and generate control transfer annotation records for each discontinuous PC transfer. The annotation content includes source PC, target PC, transfer type, transfer reason, previous and subsequent privilege levels, and associated stack frames. S4. Anomaly Path Extraction and Structured Report Generation: It receives error detection point information from co-simulation, assertion triggering, and program crash outputs. Each error detection point includes at least a mismatch PC, mismatch type, and exception occurrence period. It then traces back from the error detection point along the control flow annotation sequence to reconstruct the complete error execution path. It compresses the excessively long path, retaining only key nodes such as function switches, interrupt exceptions, system calls, and branch jumps, and preserving multiple complete instructions adjacent to the error. It outputs a structured exception location report containing an error summary, a complete function call chain, privilege level change records, and a real-time simulation call stack snapshot. S5. Automatic root cause determination of software and hardware defects: A rule base for determining the cause is established based on the ISA specification. Each instruction's actual execution behavior is compared with the specification's expectation: if the instruction execution result, control jump target, CSR read / write, or interrupt trigger timing violates the ISA specification, it is determined to be a hardware defect; if the instruction execution fully complies with the ISA specification, but the program logic contains illegal address access, uninitialized variables, incorrect system parameters, or data races, it is determined to be a software defect; if the instruction behavior is consistent with the ISA but does not match the output of the golden reference model, it is determined to be a reference model defect. A root cause analysis report carrying the determination rules, confidence level, and debugging suggestions is output.

2. The instruction stream anomaly localization method for processor verification according to claim 1, characterized in that, In step S1, the processor simulation environment is an RTL simulation environment or a co-simulation environment, and the gold reference models include Spike, Sail-RS, and ARM ISS models.

3. The instruction stream anomaly localization method for processor verification according to claim 1, characterized in that, In step S2, for the RISC-V architecture, the instructions JAL rd=ra and JALR rd=ra are determined to be function calls executing Push operations; JALR rs1=ra is determined to be a function return executing Pop operations; for the ARM architecture, BL and BLX are determined to be function calls, and BX LR and POP {PC} are determined to be function returns.

4. The instruction stream anomaly localization method for processor verification according to claim 1, characterized in that, In step S3, the interrupt / exception determination conditions include: the target PC falls into the interrupt vector table address range and the mepc / sepc register is written, the MRET / ERET interrupt return instruction is executed, and the mcause / scause register is written with a fault code.

5. The instruction stream anomaly localization method for processor verification according to claim 1, characterized in that, In step S4, the path compression rule is: within the same function, instructions executed sequentially only retain the function entry and exit nodes, and the original instruction records of the preset number of steps from the error detection point are fully preserved.

6. The instruction stream anomaly localization method for processor verification according to claim 1, characterized in that, In step S5, the hardware defect determination scenarios include ALU operation errors, branch jump address calculation errors, unexpected interrupt triggering, interrupt vector address errors, pipeline instruction submission order violations, and memory read / write data mismatch. Software defect detection scenarios include illegal memory access, stack overflow, reading of uninitialized variables, incorrect system call parameters, and multi-core data race.

7. The instruction stream anomaly localization method for processor verification according to claim 1, characterized in that, The method is compatible with multiple processor architectures such as RISC-V, ARM, and x86, and can be ported simply by replacing the corresponding ISA and ABI specification configuration files.

8. A processor verification anomaly location device, characterized in that, The method for performing any one of claims 1-7 comprises: The instruction stream preprocessing module is used to acquire simulation instruction trajectories, decode instructions, and mark control transfer instructions. The simulation call stack construction module is used to parse instructions according to ABI rules and generate a dynamic stack frame sequence; The control flow annotation module is used to identify branches, interrupts, exceptions, system calls, and generate transfer annotations; The path backtracking and reporting module is used to receive error points, backtrack to generate abnormal execution paths, and output a location report; The root cause analysis and determination module stores ISA determination rules, automatically distinguishes between three types of faults: hardware defects, software, and reference model, and outputs a root cause report.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the instruction stream anomaly localization method for processor verification as described in any one of claims 1 to 7.