{"id":"a2337aa8-cc53-498e-91d4-93bb7ef36bf2","arxiv_id":"2502.08807","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"InTAR shows that encoding per-task reconfiguration between dataflow and sequential execution at design time yields faster and more DSP-efficient FPGA accelerators for DNNs with high data-volume variation.","lead":"InTAR is a new FPGA accelerator design that switches between two execution styles, streaming and sequential, for each DNN task, with the switch plan fixed at design time. It reports large speedups over prior FPGA accelerators and better power efficiency than GPUs for GPT-2 input prefill.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"SoTA speedup over DFX compares W4A8 InTAR to FP16 DFX without scaling latency, so the 14.64x/39.14x speedup claims may be substantially due to quantization rather than the reconfiguration paradigm.","rationale":"The paper's core mechanism is plausibly sound: a static schedule encoded at circuit design time, with task-pipeline mode only when intermediate data cannot fit on-chip and sequential/task-parallel mode otherwise, is a coherent way to avoid both pipeline stalls and off-chip traffic. The placed-and-routed results and the use of HLS provide internal support. The most load-bearing weakness is not internal inconsistency but the fairness of the headline external comparison. The paper explicitly acknowledges that DFX runs in FP16 while InTAR and Allo run in W4A8, yet it only adjusts DSP efficiency for the precision difference. Latency is not adjusted, and a W4A8 accelerator will generally have lower latency than an FP16 one even with identical architecture because of reduced data movement and simpler arithmetic. Since the abstract's marquee claim is the 3.65x to 39.14x speedup over Allo and DFX, this missing control directly affects whether the central claim is established. The reader's weakest-assumption analysis correctly identifies this issue, and the verdict of CONDITIONAL is appropriate: the paper should be accepted only after a same-precision comparison or a clearly labeled quantization-adjusted comparison is provided. No stronger action is warranted because the internal evidence and the W4A8-vs-W4A8 comparison against Allo (7.99x on U280) suggest the paradigm has real value even if the DFX comparison is unfair.","tokens_in":14806,"tokens_out":6402,"duration_ms":64293,"concrete_test":"Run the same DFX implementation on U280 with W4A8 quantization, keeping its architecture otherwise unchanged, and measure GPT-2 medium prefill latency for the same input lengths; then recompute the normalized speedup. If InTAR's speedup over quantized DFX falls well below 14.64x, the headline comparison is largely explained by precision. If DFX source is unavailable, an acceptable fallback is to compile and run the InTAR design in FP16 on U280 and compare against FP16 DFX, then separately report the W4A8 comparison as a quantization-accelerated result.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section VI.A states: 'DFX is executed in FP16, and all other designs employ the W4A8 format. We scale the DSP efficiency for DFX to align the data type.' This scales only DSP efficiency, not latency. A W4A8 design can be faster than FP16 for reasons unrelated to InTAR's inter-task reconfiguration: 4-bit weight fetches, 8-bit activation datapaths, and reduced off-chip memory traffic. Since Allo is also W4A8 and Table IV reports only 1.83x speedup over DFX, a meaningful part of the normalized speedup range is attributable to precision. InTAR-on-U280 is reported at 14.64x over DFX, and InTAR-on-VPK180 at 39.14x; without a same-precision DFX baseline, these numbers do not cleanly support the claim that static inter-task reconfiguration is the source of the advantage. The Section V baselines are also described only as 'human-optimized dataflow and sequential accelerators, each designed in four weeks,' with no released code or detailed architecture, so the 1.8x/7.1x core result is difficult to audit independently. The argument is internally consistent, but the external validation has a missing control.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes InTAR, an FPGA accelerator design paradigm for DNN workloads with high data-volume variation (HDV) between tasks. InTAR groups computation into tasks and, at circuit design time, hardens a static schedule into the circuit that switches a grid of compute cores among sequential, task-pipelined, and task-parallel execution modes per task, with a claimed 4-cycle reconfiguration overhead. Designs are generated with HLS using stage-indexed conditional dataflow for data-movement, compute, and control reconfiguration, then placed and routed with TAPA/AutoBridge. The evaluation has two parts: (i) five multi-task HDV kernels (self-attention, FFN, multi-layer CNN, VAE, gating network) on an Alveo U280, reporting 1.8x geomean speedup over hand-optimized dataflow accelerators and 7.1x over sequential accelerators; and (ii) GPT-2 medium input prefilling on U280 and VPK180, reporting 3.65~39.14x speedup and 1.72~10.44x DSP-efficiency improvement over the Allo and DFX baselines, plus 1.66~7.17x power-efficiency improvement over GPUs. The central claim is that encoding reconfiguration schedules at circuit design time lets a single accelerator switch execution patterns per task, avoiding both dataflow pipeline stalls and off-chip traffic for intermediate data.","tokens_in":15073,"tokens_out":18703,"duration_ms":155977,"significance":"Significance if the headline comparisons are made fair: this is a solid and useful contribution. The paper identifies high data-volume variation as a concrete design driver, proposes a design point that avoids the generality overhead of CGRA and DPR by hardening model-specific schedules at circuit design time, and backs it with placed-and-routed implementations at 224-300 MHz with a low 4-cycle mode-switch cost. Credit is due for shipping code (https://github.com/OswaldHe/InTAR), measuring U280 latency via OpenCL profiling, implementing rather than only synthesizing the designs, and choosing the schedule by heuristic before synthesis with no sign of fitting to results; the five-kernel internal trends are consistent, and the GPT-2 medium prefill is a realistic full-model case. Two external-validity gaps separate the paper from its headline claims: the W4A8-versus-FP16 comparison with DFX (Major Comment 1) and the simulated/estimated VPK180 numbers (Major Comment 3). Both are fixable within a revision, and no circularity or fitted-free-parameter issue was found.","major_comments":[{"comment":"Section VI.A, Table IV: the headline speedup over DFX is confounded by a precision mismatch. The text states that 'DFX is executed in FP16, and all other designs employ the W4A8 format. We scale the DSP efficiency for DFX to align the data type,' but only DSP efficiency is scaled, not latency. Since Allo, also W4A8, is reported at just 1.83x over DFX, a substantial part of the 14.64x (U280) and 39.14x (VPK180) speedups could come from 4-bit weight fetches, 8-bit datapaths, and reduced memory traffic rather than from inter-task reconfiguration; the 224/300 MHz InTAR frequencies versus 200 MHz for DFX add a further uncontrolled component. The abstract's '3.65~39.14x' range therefore inherits these confounds, and the GPU comparison in Section VI.B has the same issue since the GPUs run in BFloat16. Please add a W4A8 (or INT8) DFX baseline, or scale the DFX latency by a justified precision factor, or decompose the speedups into quantization, frequency, and scheduling contributions, and also report the DSP-efficiency scaling factor applied to DFX.","section":"Section VI.A, Table IV"},{"comment":"Section V.A, Figure 7: the core internal result, 1.8x over dataflow and 7.1x over sequential accelerators, rests on 'human-optimized dataflow and sequential accelerators, each designed in four weeks,' but the manuscript provides no architectural description, resource breakdown, or repository location for these baselines, so the comparison cannot be independently reproduced. Because the baselines are separate hand-written designs, the speedup also conflates the benefit of reconfiguration with the quality of the InTAR template itself; an ablation that fixes InTAR to a single execution mode on the same template would isolate the reconfiguration benefit. Please document the baseline architectures (or release them with the code) and add such a single-mode ablation.","section":"Section V.A, Figure 7"},{"comment":"Section VI.A: the upper end of the reported speedup and power-efficiency range is not measured on hardware. The paper states that 'Due to a lack of access to a physical device, we employ QEMU and the Xilinx Power Design Manager to calculate the latency and estimate the power consumption of VPK180,' yet the 39.14x speedup over DFX and the 1.66~7.17x power-efficiency claims in the abstract and Section VI.B include these simulated and estimated VPK180 numbers without marking them as such. Please either label the simulated results explicitly in the headline claims or provide a measured result on a physical device.","section":"Section VI.A"},{"comment":"Section III, paragraph preceding Figure 2: three quantitative claims about prior reconfigurable accelerators appear without supporting evidence in this manuscript: '49% LUT reduction for a design with 3x throughput compared to [20] for multiple GEMMs,' a clock frequency of '2.41x that of [20],' and reconfiguration latency '106x faster than DPR [21].' No experiment in Sections V-VI measures these quantities, and Table II is only qualitative. Since these numbers are used to justify the core design point of model-specific, circuit-time-static schedules, please either add the supporting measurements or present these comparisons as qualitative expectations.","section":"Section III, paragraph preceding Figure 2"}],"minor_comments":[{"comment":"The sentence 'with the same process node, INTAR on FPGAs attains higher power efficiency than GPUs' is ambiguous because the evaluated platforms span 16nm (U280), 12nm (T4), 7nm (VPK180 and A100), and 6nm (MI210); please state explicitly which comparison pairs share a process node.","section":"Section VI.A"},{"comment":"The accelerator name is rendered inconsistently across the paper (InTAR in the title and abstract, INTAR in Section I, and 'I NTAR' in several body-text passages and captions); please unify the notation.","section":"Abstract and Section I"},{"comment":"The abstract's phrase 'switches execution patterns automatically with a static schedule' reads as self-contradictory on first encounter; please clarify that switching is automatic at runtime but driven by a schedule hardened at circuit design time.","section":"Abstract, Section III.A"},{"comment":"Section IV.B states that 'we require the designer to manually write the reconfiguration designs based on the static schedule,' which should be reconciled with the abstract's claim of 'fast design generation' via HLS; please quantify the manual effort or qualify the claim.","section":"Section IV.B"},{"comment":"Table III discloses that the on-chip memory constraints are artificial; since the Section V results rest on these constraints, please add a sentence on how representative they are of real deployment conditions (the GPT-2 study in Section VI avoids this limitation).","section":"Table III"},{"comment":"Section II-E and Figure 1 use V' when describing the linear projection of V without defining it; please define V' explicitly in the caption or text.","section":"Section II-E, Figure 1"}],"recommendation":"major_revision","confidential_remarks":"To the editor: the phrase 'each designed in four weeks' for the Section V baselines is not a technical specification and will likely attract criticism in review; the authors should replace it with measurable descriptors (template, resource utilization, reported cycle counts) and, ideally, release the baseline code. The DFX precision mismatch (W4A8 versus FP16) is the most likely attack point in any venue and should be treated as a revision requirement. The concentration of references on the authors' own group's tools (TAPA, AutoBridge, FlexCNN) and closely related work (Allo) is legitimate given the methods used but raises the burden of showing that the SoTA baselines are configured at their strongest. No scope concern: the paper fits the cs.AR audience well."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Here's the quick take: InTAR's core idea—encoding a static, task-level schedule of dataflow/sequential mode switches into the circuit at design time, exposed through HLS—is genuinely new and demonstrated with placed-and-routed implementations on two FPGA families, with code on GitHub. The internal comparison against their own dataflow and sequential accelerators shows 1.8x and 7.1x speedups, and the paper's practical details on memory-port alignment and multi-die floorplanning are the kind of work that actually ships. That part is solid.\n\nThe soft spot is the SoTA comparison in Section VI.A. They compare W4A8 InTAR to FP16 DFX, and only scale DSP efficiency, not latency. The 3.65–39.14x speedup claims therefore include a large quantization effect that has nothing to do with inter-task reconfiguration. A same-precision DFX baseline (or at least a W4A8-DFX variant) is needed before those headline numbers can be taken at face value. The 'human-optimized dataflow and sequential accelerators' baselines are also underspecified—no detailed architecture or released code—so the core 1.8x/7.1x result is harder to audit than it should be. Finally, the VPK180 numbers come from QEMU and power estimation, not a physical board; that's flagged in the paper, but the abstract still presents 39.14x without that caveat.\n\nThe paper is honest about its own limits: the scheduling heuristics are acknowledged as not optimal, and the AMD financial interest is disclosed. Those are marks in its favor. The citation pattern looks fine, with the relevant CGRA/DPR/hybrid work covered.\n\nWho's this for? Anyone building FPGA accelerators for transformer workloads, and HLS tool researchers. It deserves a serious referee, but the evaluation needs a rework: same-precision baselines, better-documented internal baselines, and clearer labeling of simulated results. I'd accept it subject to major revisions.","headline":"Genuinely new static reconfiguration paradigm with solid internal results; SoTA speedups inflated by W4A8-vs-FP16 comparison without latency scaling.","tokens_in":15610,"tokens_out":2504,"would_cite":true,"duration_ms":22325,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"InTAR shows that baking an execution-mode schedule into an FPGA's logic lets one accelerator switch between sequential and dataflow modes per task, reducing both pipeline stalls and off-chip memory traffic.","keywords":["FPGA accelerator","high data volume variation","reconfigurable architecture","dataflow execution","sequential execution","high-level synthesis","transformer prefill","DNN inference acceleration"],"falsifier":"Run the FP16 baselines and the quantized InTAR design under identical data types on the same FPGA and compare end-to-end latency: if the speedup over the dataflow and sequential baselines largely disappears, the claimed gains come from quantization, not from inter-task reconfiguration.","tokens_in":14607,"feed_emoji":"🔀","tokens_out":9850,"duration_ms":86859,"temperature":0.7,"pith_summary":"The paper introduces InTAR, a way to design FPGA accelerators for deep networks whose intermediate tensor sizes vary sharply from task to task. Its claim is that if the reconfiguration schedule is fixed before the circuit is built, a single accelerator can automatically switch among sequential, task-pipeline, and task-parallel execution at task boundaries, with only four cycles of switching overhead. This lets the hardware stream large intermediate data on-chip between dependent tasks and fall back to sequential execution when small intermediate data fits in scratchpad memory, avoiding both pipeline stalls and off-chip memory traffic. Across five multi-task kernels the paper reports 7.1x and 1.8x speedups over sequential and dataflow baselines, and on GPT-2 medium input prefill it reports 3.65-39.14x speedups over two state-of-the-art FPGA accelerators plus 1.66-7.17x power-efficiency gains over GPUs. The significance is that inter-task reconfiguration need not be a costly general-purpose overlay; an application-specific schedule with only necessary logic and interconnects makes the switch cheap and compatible with high-level synthesis.","feed_headline":"Switching modes per task makes FPGAs 1.8-7.1x faster for DNNs","feed_subtitle":"A schedule baked into the circuit switches dataflow and sequential execution with 10-20 ns overhead.","key_machinery":"The mechanism is the static, stage-indexed reconfiguration schedule hardened into the circuit. The architecture template is a grid of compute cores, each containing a reconfigurable processing-element array, a scratchpad memory, a reduction unit, and a data movement control unit, with special function units inserted between cores for nonlinear operations. A global instruction reader pulls configuration instructions from a static buffer, patches loop bounds with the input size, and propagates them to cores; multiplexers keyed on the stage index reroute data sources, destinations, and precision. High-level synthesis conditional dataflow, implemented as if-else blocks on the stage index, lets the synthesis tool merge interconnects and logic across modes so unused paths are never added. A heuristic design-space exploration chooses the mode for each task from the dataflow graph, the on-chip memory budget, and the maximum intermediate size, with batching used for variable input sizes.","core_discovery":"The central discovery is that inter-task reconfiguration can be made nearly free if the schedule is decided before synthesis rather than at runtime. A grid of compute cores and special function units executes tasks in one of three modes—sequential, task-pipeline, or task-parallel—selected by a stage index distributed by a global instruction reader. Each core's processing-element array, scratchpad memory, reduction unit, and data movement control reconfigure through multiplexers and loop-bound changes, with all four switching steps (read, modify, send, decode) fitting in four cycles. This design-time specialization keeps only the interconnects and control logic the schedule needs, avoiding the overhead of general coarse-grained reconfigurable arrays or dynamic partial reconfiguration. On five benchmark kernels the paper reports 7.1x over sequential and 1.8x over dataflow accelerators, and on GPT-2 medium prefill it reports 3.65-39.14x speedups over the two state-of-the-art FPGA baselines, with 1.66-7.17x power efficiency over GPUs.","pith_inferences":["The same design-time-schedule principle could extend beyond DNNs to any high-variation streaming application, such as graph analytics or signal processing, where task dependencies and buffer capacities are known in advance; the paper mentions non-DNN high-variation applications only as future work.","Because switching cost is only 10-20 ns, the approach invites exploring finer-than-task or even per-layer reconfiguration, which could improve utilization further but would increase the multiplexer and control complexity the paper does not quantify.","The reported speedups combine architectural reconfiguration with W4A8 quantization; an orthogonal test would isolate the two by running the same quantized data type on all designs, which the paper does not do.","The static schedule means design-time search effort is amortized over every inference, so a more exhaustive design-space exploration than the heuristic could likely find better schedules at no runtime cost."],"forward_implications":["A single InTAR-style accelerator can execute DNNs whose intermediate tensor sizes vary by over two orders of magnitude without spilling intermediate data to off-chip memory, removing the main latency and energy cost of sequential execution.","Task-level reconfiguration costs only 10-20 ns, so switching modes during inference adds negligible overhead and can be triggered automatically from kernel arguments.","Because the design is generated with high-level synthesis and a template of compute cores plus special function units, new high-variation DNNs can be mapped to FPGAs quickly, and the same template ports across boards with different die counts.","For LLM input prefill, the resulting accelerator can outperform both dataflow and sequential FPGA accelerators by one to two orders of magnitude in speed and DSP efficiency, and beat GPUs in power efficiency for short sequences."],"supporting_citations":[{"why":"Serves as the state-of-the-art dataflow accelerator baseline for the GPT-2 comparison; its latency and DSP efficiency are what InTAR's speedup numbers are measured against.","marker":"[6]"},{"why":"Serves as the state-of-the-art sequential accelerator baseline in the GPT-2 comparison and is the FP16 design whose DSP efficiency is scaled for data-type alignment.","marker":"[23]"},{"why":"Coarse-grained reconfigurable array overlay whose LUT overhead, clock frequency, and reconfiguration latency are the reference points for InTAR's reconfiguration efficiency.","marker":"[20]"},{"why":"Hybrid accelerator with specialized processing elements; its idle-PE behavior motivates InTAR's reconfiguration of all resources across modes.","marker":"[13]"},{"why":"Source of the Llama-family gating-network kernel dimensions and an example of a DNN with high data volume variation.","marker":"[3]"},{"why":"Defines the attention and softmax task structure used by the self-attention kernel and the motivating case study.","marker":"[5]"},{"why":"GPT-2 is the target model for the complete end-to-end prefill evaluation.","marker":"[14]"},{"why":"Task-parallel high-level synthesis framework used to generate and prototype the InTAR designs on FPGA boards.","marker":"[43]"},{"why":"Floorplanning and pipelining tool used for place-and-route of the multi-die designs, enabling the reported clock frequencies.","marker":"[46]"}],"fun_headline_variants":["Design-time schedule lets FPGAs auto-switch modes, 1.8-7.1x faster","InTAR: FPGAs adapt per task with near-free reconfiguration","Baked-in schedule boosts FPGA DNN speed by up to 7.1x","FPGA accelerator reconfigures in 4 cycles, gains 1.8-7.1x on DNNs","Inter-task auto-reconfig makes FPGAs 7.1x faster for DNNs"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The reported speedups assume that comparing an 8-bit quantized InTAR design against FP16 baselines, with only DSP efficiency adjusted, still measures the architectural advantage of reconfiguration rather than the advantage of quantization.","fun_headline_variants_meta":{"raw":{"variants":["Design-time schedule lets FPGAs auto-switch modes, 1.8-7.1x faster","InTAR: FPGAs adapt per task with near-free reconfiguration","Baked-in schedule boosts FPGA DNN speed by up to 7.1x","FPGA accelerator reconfigures in 4 cycles, gains 1.8-7.1x on DNNs","Inter-task auto-reconfig makes FPGAs 7.1x faster for DNNs"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000895,"raw_usage":{"total_tokens":3954,"prompt_tokens":1141,"completion_tokens":2813,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":757,"completion_tokens_details":{"reasoning_tokens":2689}},"tokens_in":757,"tokens_out":2813,"duration_ms":18775,"temperature":1.0,"reasoning_tokens":2689,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T23:36:24.402275+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the FP16 baselines and the quantized InTAR design under identical data types on the same FPGA and compare end-to-end latency: if the speedup over the dataflow and sequential baselines largely disappears, the claimed gains come from quantization, not from inter-task reconfiguration.","supporting_citations":[{"cited_title":"Dfx: A low-latency multi-fpga appliance for accelerating transformer-based text generation,","cited_arxiv_id":null,"evidence_quote":"Serves as the state-of-the-art sequential accelerator baseline in the GPT-2 comparison and is the FP16 design whose DSP efficiency is scaled for data-type alignment."},{"cited_title":"Overgen: Improving fpga usability through domain-specific overlay generation,","cited_arxiv_id":null,"evidence_quote":"Coarse-grained reconfigurable array overlay whose LUT overhead, clock frequency, and reconfiguration latency are the reference points for InTAR's reconfiguration efficiency."},{"cited_title":"Ssr: Spatial sequential hybrid architecture for latency throughput tradeoff in transformer acceleration,","cited_arxiv_id":null,"evidence_quote":"Hybrid accelerator with specialized processing elements; its idle-PE behavior motivates InTAR's reconfiguration of all resources across modes."},{"cited_title":"Tapa: a scalable task-parallel dataflow programming framework for modern fpgas with co-optimization of hls and physical design,","cited_arxiv_id":null,"evidence_quote":"Task-parallel high-level synthesis framework used to generate and prototype the InTAR designs on FPGA boards."},{"cited_title":"Autobridge: Coupling coarse-grained floorplanning and pipelining for high-frequency hls design on multi-die fpgas,","cited_arxiv_id":null,"evidence_quote":"Floorplanning and pipelining tool used for place-and-route of the multi-die designs, enabling the reported clock frequencies."}],"review_version":1}