Progressive Mismatch Localization Chain
- PMLC is a three-layer mismatch evidence mechanism that progressively narrows failures from output symptoms to source-level runtime divergence.
- It employs log normalization, AST backward slicing, and dual-trace instrumentation to convert raw mismatch logs into a concise repair brief.
- Empirical results demonstrate high localization accuracy and efficiency in mismatch-dense high-level synthesis workflows.
Searching arXiv for the cited papers to ground the article and verify the provided identifiers. Progressive Mismatch Localization Chain (PMLC) is a three-layer mismatch evidence chain introduced in "Evidence-Driven LLM Agent for C-to-Synthesizable-C Conversion and Verification" as the dedicated evidence-extraction mechanism for the hardest high-level synthesis failure mode, namely CSim/CoSim mismatches (Zhao et al., 25 Jun 2026). Within the paper’s closed-loop generation-verification-diagnosis-repair workflow, PMLC converts a raw simulator report such as a cycle/output failure into a small, repairable set of source-level suspects through log normalization, AST backward slicing, and dual-trace instrumentation. Its defining property is progressive scope reduction: output-level symptoms are translated into source-level causality and then into runtime first-divergence evidence, so that repair is anchored to checkable observations rather than to unconstrained model guesswork (Zhao et al., 25 Jun 2026).
1. Definition and operational role
PMLC is used only when the verifier reaches the CSim/CoSim mismatch regime. The underlying paper distinguishes this regime from compile and synthesis failures, arguing that the latter are usually localized enough already, whereas mismatch failures are not: a long cycle-by-cycle log indicates that behavior diverged, but not why or where (Zhao et al., 25 Jun 2026). In that setting, PMLC serves as the bridge between verifier failure and LLM repair.
Formally, the paper packages mismatch evidence as
where is output-level evidence, is source-level evidence, and is runtime evidence (Zhao et al., 25 Jun 2026). The function of the chain is to shrink the localization scope monotonically from the whole HLS-C candidate to a few suspect lines. The paper states the inclusion relation
This monotone shrinkage is presented as part of Proposition 1 and is central to the paper’s characterization of PMLC as a progressive localization mechanism rather than a single-pass diagnostic heuristic (Zhao et al., 25 Jun 2026).
In the overall agentic pipeline, the verifier runs four stages in order—compilation, C simulation (CSim), synthesis, and C/RTL co-simulation (CoSim)—and short-circuits on the first failure. When the first failure is a CSim or CoSim mismatch, the orchestrator invokes PMLC, the failure analyst converts the resulting evidence into a structured repair brief, the programmer applies a patch, and the verifier reruns the candidate, with the loop continuing up to (Zhao et al., 25 Jun 2026).
2. Three-layer evidence chain
The chain consists of three successive localization layers. Each layer narrows the fault region while preserving an auditable link to the observed mismatch (Zhao et al., 25 Jun 2026).
| Layer | Evidence type | Reported contents |
|---|---|---|
| Output-level evidence | matched/total counts; first failing cycle; failed-output list; a few mismatch examples | |
| Source-level evidence | key-variable map; related variables; assignment sites; control sites; merged suspect line ranges | |
| Runtime evidence | first-divergence cycle; diverging variables |
The first stage, log normalization, constructs from the raw CSim/CoSim mismatch log. The paper states that this layer normalizes the log into matched/total counts, first failing cycle, failed-output list, and a few mismatch examples, and that it includes a standalone predicate that distinguishes genuine mismatches from compile/tool errors (Zhao et al., 25 Jun 2026). This step reduces an unstructured trace to a concise output-side failure object.
The second stage, AST backward slicing, constructs 0. The HLS-C source is parsed into an AST, and a backward slice is rooted at the failed outputs identified by 1. The result is described as a key-variable map together with related variables, assignment sites, control sites, and merged suspect line ranges. The paper further notes that recursion depth is bounded so that the slice remains precise (Zhao et al., 25 Jun 2026). In effect, this stage moves from output-level symptomatology to source-level causal candidates.
The third stage, dual-trace instrumentation, constructs 2. Instrumentation is inserted selectively at the suspect sites identified by 3, and the collected runtime evidence includes assignments, loop iterations, branch outcomes, and variable snapshots. When the original C program is available as a golden reference, co-located probes are placed on both the original C and the HLS-C candidate, and the traces are aligned to identify the first-divergence cycle and the diverging variables (Zhao et al., 25 Jun 2026). The paper explicitly describes 4 as localizing the mismatch to the first divergence between the C golden trace and the HLS-C trace.
A common misconception is that PMLC simply feeds full simulator traces to the model. The paper states the opposite: raw logs are normalized, slicing is bounded, instrumentation is selective, and no full-trace exposure to the LLM is allowed in the prompt-facing path (Zhao et al., 25 Jun 2026).
3. Formal properties, budgets, and design constraints
PMLC is not presented as an unconstrained reasoning loop. The paper associates the evidence layers with finite budgets 5 and states in Proposition 1 that these layers do not grow with input size while satisfying the line-set inclusion relation above (Zhao et al., 25 Jun 2026). The text does not frame this as a theorem with a formal proof; instead, it characterizes the property as an externally auditable implementation constraint.
The engineering budgets explicitly mentioned include slice depth, line-merge / expansion thresholds, snapshot retention, 80-line error excerpt length, and radius-8 code window (Zhao et al., 25 Jun 2026). These limits are part of the paper’s reproducibility and robustness argument. Their role is practical: they cap prompt-facing evidence, avoid combinatorial growth in the slice, and preserve a bounded repair context for downstream agents.
Several additional design choices define the chain’s operating envelope. Selective instrumentation keeps overhead low and avoids huge traces. Bounded recursion depth in AST slicing prevents over-expansion. The structured mismatch predicate separates simulation mismatches from tool or compile failures. Hard isolation ensures that PMLC operates without reference HLS, labeled bugs, or manual repairs in the prompt-facing path, although the original C program may optionally be used as a golden reference for dual-trace alignment (Zhao et al., 25 Jun 2026).
The paper also stresses a methodological boundary: PMLC is intended as an analogy to slicing and spectrum-based localization, but without claiming formal equivalence guarantees (Zhao et al., 25 Jun 2026). This clarifies that the framework is evidence-driven and auditable, yet not positioned as a general proof-producing localization calculus.
4. Inputs, outputs, and repair-brief construction
PMLC consumes mismatch-related artifacts from the verifier and the current source state. The paper lists the mismatch log from CSim/CoSim, the failing code, the earliest failing stage and its raw log excerpt, the current HLS-C candidate, the project-log summary and local code window, and optionally the original C program as a golden reference for dual-trace alignment (Zhao et al., 25 Jun 2026). Within the paper’s evidence taxonomy, the full raw trace and related artifacts remain audit-only, while PMLC exposes only compressed prompt-facing evidence.
Its output is a three-layer evidence bundle comprising 6, 7, and 8. The paper then describes a packaging step that combines the three evidence layers, the failing code window, the project-log summary, the raw error excerpt, and the must-preserve contract (Zhao et al., 25 Jun 2026). This package becomes the repair brief passed to the failure analyst and programmer agents.
The significance of this packaging is methodological rather than merely presentational. PMLC does not diagnose in isolation; it structures evidence so that the repair stage receives not just a failure notice, but a constrained description of why the current code fails, where the minimal edit should land, and what must not change (Zhao et al., 25 Jun 2026). This suggests a division of labor in which localization is separated from patch synthesis under strict evidence isolation.
5. Empirical characterization
The paper reports PMLC-specific localization results on the full50 diagnostic set of 50 mismatch cases with known ground-truth fault locations (Zhao et al., 25 Jun 2026). The reported accuracies are 50/50 for 9, 50/50 for 0, and 45/50 for 1 on first-divergence localization. These numbers provide direct empirical support for the claim that the three stages progressively preserve and sharpen mismatch evidence rather than losing it during compression.
PMLC is also situated inside an end-to-end workflow evaluation. On the mismatch-dense subset 2 of 24 designs that expose CSim/CoSim mismatches, the paper reports 70.83% for Ours+RAG, 20.83% for C2HLSC, 12.50% for ChatHLS, and 0% for HLSTrans (Zhao et al., 25 Jun 2026). The text attributes much of this advantage to the mismatch localization path, because this subset is precisely where mismatch repair is the bottleneck.
The paper further notes that adding RAG on top of the workflow improves the mismatch-dense subset by +29.17% over no-RAG, while emphasizing that the PMLC ablation is the component directly tied to localization accuracy (Zhao et al., 25 Jun 2026). A plausible implication is that the paper treats PMLC as the evidence bottleneck and RAG as the knowledge-access bottleneck; both matter, but in different parts of the repair stack.
6. Relation to adjacent progressive localization frameworks
Although PMLC is defined in the HLS mismatch-repair setting, the paper’s progressive evidence-chain logic has close conceptual analogues in other recent work. The most direct hardware-debugging analogue is Pecker, described as a causal-chain reconstruction framework for sequential hardware bug localization (Tang et al., 3 Mar 2026). Pecker addresses timing misalignment between bug activation and observation, and progressive error propagation through state elements, by reconstructing the broken causal chain through temporal backtracking using Estimated Minimal Propagation Cycles and strategic trace pruning to eliminate state pollution effects (Tang et al., 3 Mar 2026). The overlap is conceptual rather than terminological: both methods work backward from an observed failure, estimate the relevant causal region, and remove or avoid later evidence that would otherwise distort localization.
A second analogue appears in the image forensics domain through the In-Context Forensic Chain (ICFC), a training-free framework for image manipulation localization that combines Rule Decomposition and Filtering, Multi-step Progressive Reasoning, and SAM (Chen et al., 11 Oct 2025). ICFC is not named PMLC, but the extracted description emphasizes a coarse-to-fine reasoning chain in which the system starts from broad suspicious cues, narrows likely tampered regions, refines to boundary-accurate localization, and produces an explanation (Chen et al., 11 Oct 2025). This suggests that “progressive localization chain” is a broader methodological pattern spanning code-repair, hardware debugging, and forensic localization, even though the target artifacts and observables differ.
At the same time, the distinctions are important. Pecker is concerned with activation, propagation, and observation in sequential circuits; ICFC is concerned with global suspicion, candidate regions, refined regions, and pixel masks; PMLC is concerned with CSim/CoSim mismatches, source slices, and first-divergence traces (Tang et al., 3 Mar 2026). Treating them as interchangeable would be inaccurate. The commonality lies in progressive narrowing, not in a shared formalism.
7. Scope, assumptions, and interpretive boundaries
PMLC is specialized to mismatch diagnosis in a four-stage HLS verification workflow. It is not described as a universal remedy for all HLS failures, and the paper is explicit that compile or synthesis failures often do not require this machinery because raw log excerpts and local code windows are usually sufficient (Zhao et al., 25 Jun 2026). Its use is therefore conditional on a particular failure regime.
The framework also makes concrete assumptions about available artifacts. It requires the mismatch log from CSim or CoSim, the current HLS-C candidate, and the surrounding project context; dual-trace alignment is possible only when the original C program is available as a golden reference (Zhao et al., 25 Jun 2026). The resulting runtime localization is correspondingly asymmetric: 3 can identify the first divergence between the C golden trace and the HLS-C trace when both are observable, but the paper does not claim that such evidence is always available.
Another potential misunderstanding concerns supervision. The paper states that PMLC provides evidence without leaking reference HLS solutions or labeled bug data, and that hard isolation is maintained in the prompt-facing path (Zhao et al., 25 Jun 2026). This does not mean that the chain is unsupervised in an abstract sense; rather, it means that mismatch diagnosis is grounded in verifier artifacts and controlled instrumentation rather than in privileged repair exemplars.
In summary, PMLC denotes a mismatch-specific progressive localization mechanism in which log normalization yields output-level evidence, AST backward slicing yields source-level evidence, and dual-trace instrumentation yields runtime first-divergence evidence. Its defining contribution is not merely another debugging heuristic, but a bounded and auditable evidence pathway from verifier-observed divergence to source-local repair action (Zhao et al., 25 Jun 2026).