{"id":"7152edc1-5653-4a32-ac71-65e4484d90f9","arxiv_id":"2411.11384","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"An LLVM pass automatically combines parallel low-precision arithmetic operations into single FPGA DSP blocks during HLS, cutting DSP usage by 70% for additions and 50% for multiplications on benchmarks without source changes.","lead":"SILVIA is an open-source compiler pass that automatically packs multiple add, multiply, and multiply-accumulate operations into single FPGA DSP blocks during high-level synthesis, with no manual source edits. A smart generalist might read it as a step toward making FPGA acceleration more automatic, since it matches hand-optimized CNN accelerators on DSP efficiency while reducing DSP use by about 70% for additions and 50% for multiplications.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"SILVIA's DSP-saving claims rest on unverified functional equivalence: the custom RTL replacement and ALAP use-motion are never checked against the original source, so reported savings could be for incorrect hardware.","rationale":"The reader's weakest_assumption focused on the custom RTL replacement modules being functionally equivalent. I agree that this is load-bearing, and I partially agree with the reader's framing: it is the same class of risk (unverified equivalence of the final hardware). However, I would broaden the concern to include the IR-level ALAP use-motion, which can reorder memory operations and is described with only a hand-wavy alias-analysis safeguard. The paper gives no formal argument and no experimental verification that the transformed IR preserves the original program's observable behavior. This is not merely an implementation risk: the pass's whole purpose is to be a semantics-preserving compiler optimization, so the absence of any correctness check on actual benchmarks leaves the central claims ungrounded. The experimental sections are otherwise reasonably thorough: the benchmark set is diverse, the resource reports are post-implementation, the CNN case study compares against manually optimized designs, and the throughput measurements are from hardware. But none of that substitutes for functional equivalence. The concrete test I propose (co-simulation against baseline and original C, plus exhaustive testing of the factor-4 module) would settle the concern directly. If such a check were added and passed, the paper would be a solid conditional acceptance. Given the current missing evidence, the correct verdict remains CONDITIONAL, with the condition being the successful completion and reporting of bit-exact functional verification.","tokens_in":16168,"tokens_out":5181,"duration_ms":91756,"concrete_test":"Run a bit-exact co-simulation for at least one small multiplication-intensive benchmark (e.g., MVM or scal) and one addition-intensive benchmark (e.g., vadd): synthesize the SILVIA-optimized RTL and compare its outputs on random and directed vectors against the baseline Vitis HLS RTL and against the original C++ function. In parallel, instantiate the factor-4 unsigned multiplication replacement module in isolation and exhaustively test all 2^16 combinations of the four 4-bit unsigned multiplicands and one 4-bit multiplier (including signed common factor), comparing against scalar products. If any mismatch occurs, the central DSP-saving claim collapses; if all checks pass, the correctness risk is largely retired but should still be reported in the paper.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The central claim that SILVIA automatically packs operations into DSPs without changing functionality is supported only by resource/performance tables; no experiment checks that the final hardware computes the same outputs as the original C++. Two steps carry this correctness burden and both are assumed rather than demonstrated. First, the ALAP use-motion in Section 3.2.1 (Fig. 4) moves uses of candidate values later in the basic block; in Fig. 4 the moved use is a store, so this is a memory reordering. The paper says the pass preserves dependencies via def-use chains and LLVM alias analysis and conservatively treats function calls as potential aliases, but it does not prove that the motion is semantics-preserving for all moved memory operations, nor does it report a check that no store was moved across an aliasing load in the benchmarks. A single unsound reordering would make the generated accelerator produce wrong results. Second, Section 3.4 says SILVIA replaces the HLS-generated modules for the packed-placeholder functions with custom DSP-packed RTL modules, but those modules are not described, not shown to be bit-accurate, and no co-simulation or hardware output comparison is reported. This matters concretely: the factor-4 unsigned multiplication packing of Section 2.3 requires sign/overflow correction logic, and the SIMD adder requires correct bit-field packing; an error in either would invalidate the measured DSP savings even if the LLVM transformation is otherwise correct. The CNN case study reports throughput from hardware but no accuracy or output-equivalence numbers, so even the successful throughput measurements do not establish correctness. Because the paper's headline reductions (70%/50% DSP savings) are only meaningful if the synthesized designs are functionally equivalent to the sources, this gap is load-bearing.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents SILVIA, an open-source LLVM transformation pass that runs between the frontend and backend of AMD Vitis HLS and automatically identifies superword-level parallelism in HLS designs, packing multiple additions, multiplications, and multiply-and-adds into single DSP slices. The pass is specialized into SILVIAAdd, for four 12-bit or two 24-bit SIMD additions/subtractions, and SILVIAMuladd, for two 8-bit MADs or four 4-bit multiplications with a shared operand. The evaluation covers addition-intensive and multiplication-intensive benchmarks plus CNN accelerators built with NN2FPGA and FINN, reporting average DSP reductions of 70% for additions and 50% for multiplications/MADs relative to a DSP-bound baseline, with equal or improved throughput and comparable quality of results to manually optimized CNN designs.","tokens_in":16451,"tokens_out":3184,"duration_ms":35536,"significance":"If the reported results are correct, SILVIA is a useful contribution: it automates a low-level DSP-packing optimization that currently requires manual RTL or source-level intervention, integrates with a commercial HLS flow, and is released as open source. The CNN case study is a particular strength, because it directly compares the automated flow against two established manually optimized frameworks and shows matching DSP-versus-throughput design points. The work also demonstrates that the LLVM IR level is a practical place to apply DSP packing in HLS. The main limitation is that the correctness of the transformed hardware is not experimentally established: the ALAP use-motion and the custom RTL replacement modules are both asserted to be semantics-preserving, but no simulation, co-simulation, or hardware output comparison is reported. The resource savings therefore cannot yet be fully separated from the possibility that the optimized designs compute something different from the original source.","major_comments":[{"comment":"The ALAP use-motion moves uses of candidate values later within the basic block; in the Fig. 4 example this moves a store of c0 across a load of a1, i.e., it is a memory reordering. The paper states that dependencies are preserved via def-use chains and LLVM alias analysis, and that function calls are conservatively treated as aliasing, but it does not prove that the motion is semantics-preserving for all moved memory operations, and it does not report any check that no store was moved across an aliasing load in the evaluated benchmarks. A single unsound reordering would change accelerator behavior while preserving all reported resource counts. The authors should add a correctness validation of the transformed IR, for example by comparing simulation outputs before and after the pass on every benchmark, or by formally verifying that the pass only moves a memory operation across another operation when aliasing is disproved.","section":"§3.2.1, Fig. 4"},{"comment":"The custom DSP-packed RTL modules that replace the HLS-generated placeholder functions are not described and are never shown to be functionally equivalent to the original scalar operations. This is load-bearing: if the replacement modules are not bit-accurate for the four-12-bit SIMD adder, the two-24-bit adder, the factor-2 MAD packing, or the factor-4 unsigned multiplication packing with its correction logic, all DSP savings in Tables 1 and 2 would be measured on incorrect hardware even if the LLVM transformation is correct. The paper should provide the module implementations or at least a detailed RTL description, together with a testbench or co-simulation that compares the packed outputs against the original C++/LLVM semantics on the actual benchmark data.","section":"§3.4, §2.3"},{"comment":"The general-purpose benchmark results report only post-implementation resource, timing, and power numbers, with no experiment that verifies the computed outputs of the SILVIA-optimized designs against the baseline designs. The CNN case study states that throughput is measured from hardware execution, but it does not state that the hardware outputs were compared with expected values. Given that the two transformation steps above carry the correctness burden, the absence of any end-to-end functional check leaves the central claim that SILVIA preserves functionality unsupported. A simple addition would be to run a hardware or RTL simulation for each benchmark and compare the outputs of the baseline and SILVIA versions.","section":"§4, Tables 1 and 2"}],"minor_comments":[{"comment":"The Introduction reports average savings of 60% for additions and 45% for multiplications/MADs, while the Abstract, Section 4, and the Conclusion report 70% and 50%. The measured geometric means in Table 1 (0.30 and 0.50 normalized DSP utilization) support the 70%/50% figures; the Introduction numbers should be corrected.","section":"§1 vs. Abstract/§4/§5"},{"comment":"All resource and power numbers come from a single synthesis/implementation run, and the paper does not report run-to-run variation or sensitivity to synthesis settings. For differences such as the 9% average LUT overhead or the Fmax variations, a few repeated runs or at least a statement about determinism of the toolchain would help the reader judge significance.","section":"§4, Table 1"},{"comment":"The notation E[3:1]3 in Equation (4) is confusing; it should be written as E3[3:1] to denote the three most significant bits of operand E3. This would make the bit mapping in Fig. 3a easier to follow.","section":"§2.3, Fig. 3"},{"comment":"The distinction between placeholder functions that are directly implemented in LLVM IR and those replaced by custom RTL modules is not entirely clear: Section 3.3 says HLS generates a dedicated module for a placeholder, and Section 3.4 says SILVIA re-implements the Vitis black-box functionality. A concrete example showing the LLVM IR and the corresponding placeholder/RTL interface for one packed operation would clarify the mechanism.","section":"§3.3 and §3.4"},{"comment":"The discussion of the new critical cycle introduced by packing is clear, but the claim that this scenario was never encountered in the benchmarks is stated without supporting data. Reporting the II values or the relevant DDG cycles for each benchmark in Table 1 would make this statement verifiable.","section":"§3.5.1"}],"recommendation":"major_revision","confidential_remarks":"The manuscript fits the journal's scope and the central idea is sound and potentially valuable. My main concern is correctness validation: the paper makes a strong automation claim but never checks that the transformed hardware actually computes the same outputs as the original source. This is fixable within the scope of the manuscript by adding RTL/HW simulations or co-simulation for all benchmarks and by documenting the custom RTL modules. The self-citations are not inappropriate given that NN2FPGA is a natural baseline, and the packing methods are properly attributed to prior work; the novelty lies in the automation, not in the packing arithmetic."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"This paper does something genuinely useful: it automates DSP packing in HLS with an LLVM pass that runs between the frontend and backend, and the benchmark evidence is substantial. To my knowledge, this is the first automated pass for finding packable operations and rewriting the IR to use DSP-packed primitives. The novel unsigned 4-bit filter-reuse packing in Section 2.3 is a real contribution, not just a rehash of Fu et al. or FINN. The validation is solid at face value: 11 benchmarks, post-implementation resource numbers, and a CNN case study where SILVIA matches the DSP count and throughput of manually optimized NN2FPGA and FINN designs.\n\nThe main soft spot is functional equivalence. The paper never demonstrates that the final hardware computes the same outputs as the original C++. Two steps carry this burden: the ALAP use-motion in Section 3.2.1 and the replacement of placeholder HLS modules with custom DSP-packed RTL in Section 3.4. Neither step is formally proven, and there is no co-simulation or hardware output comparison. The stress-test note is right that this gap is central: if the custom RTL is not bit-accurate, the measured DSP savings are meaningless. I don't think this is a fatal flaw in the approach—it is a missing experiment. A referee should demand that the authors add C/RTL co-simulation or an FPGA output comparison for at least the CNN case and a few representative benchmarks.\n\nMinor issues: the intro reports 60%/45% DSP savings while the abstract and results say 70%/50%; that needs fixing. The claim of 'no impact on performance' is too strong since some benchmarks show Fmax drops (axpy goes from 450 to 375 MHz). Cycle-count throughput is unaffected, but wall-clock throughput can change with Fmax. The paper also lacks error bars or multiple runs, so the averages should be read with some caution. The lack of a commit hash or tagged release for the open-source code is a minor reproducibility issue.\n\nThe citation pattern is fine, and comparing against NN2FPGA and FINN is the right way to position the work. The self-citation is not a problem here. The paper is well organized and the writing is clear.\n\nRecommendation: this deserves a serious referee. The core contribution is new and the results are plausible. The functional-equivalence gap is addressable with additional experiments, and a revision that closes it would make the paper much stronger. I would send this out for review.","headline":"An LLVM-based HLS pass for automatic DSP packing that is new and mostly well-validated; the main gap is the missing functional-equivalence check on the custom RTL replacement.","tokens_in":17052,"tokens_out":3606,"would_cite":true,"duration_ms":34078,"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":"An LLVM-based pass automatically detects parallel low-precision arithmetic in HLS designs and packs the operations into single FPGA DSPs, cutting average DSP usage by 70% for additions and 50% for multiplications and multiply-and-adds…","keywords":["High-level synthesis","FPGA","DSP packing","Superword-level parallelism","LLVM","SIMD","Multiply-and-add","Electronic design automation"],"falsifier":"Synthesize any SILVIA-optimized design with the placeholder modules replaced, then run an exhaustive or randomized bit-accurate simulation of the packed RTL against the original scalar operations for all supported input widths; a single mismatch in the four-12-bit adder, the two-24-bit adder, the factor-2 MAD, or the factor-4 multiplier would invalidate the reported DSP savings. A second check is to build the dependence pattern of Fig. 5 and measure whether the initiation interval grows from 2 to 3 cycles as predicted when packing creates a new critical cycle.","tokens_in":15986,"feed_emoji":"⚙️","tokens_out":9026,"duration_ms":82749,"temperature":0.7,"pith_summary":"SILVIA is an open-source LLVM transformation pass that slots into a high-level synthesis (HLS) flow between the frontend and the backend and automatically finds operations that can share one FPGA DSP. It packs four 12-bit (or two 24-bit) additions or subtractions, two 8-bit multiplications or multiply-and-adds with a shared operand, and four 4-bit multiplications with a common operand, all without manual edits to the C++ design. The paper's central claim is that this makes DSP efficiency a compiler responsibility instead of a designer's hand-tuning task. On a diverse set of accelerators, the pass reduced DSP utilization by 70% on average for additions and 50% for multiplications and multiply-and-adds, left throughput unchanged, and matched the quality of manually optimized convolutional neural network accelerators.","feed_headline":"Compiler pass cuts FPGA DSP use by 50-70% without source edits","feed_subtitle":"New HLS pass packs parallel 12-bit adds and 8-bit multiplies into single DSPs, matching hand-tuned accelerators.","key_machinery":"The load-bearing mechanism is the SILVIA pass skeleton: a per-basic-block 'candidate, tuple, pack' pipeline implemented as an LLVM transformation pass, with two concrete specializations. The base class collects candidate instructions (or addition-tree patterns), moves uses as late as possible to create insertion room, groups candidates into valid tuples, and replaces each tuple with a packed-operation call; virtual functions let each specialization define which candidates are legal and how the tuple is packed. The two provided specializations are SILVIAAdd, which targets the DSP SIMD modes (four 12-bit or two 24-bit adds/subtracts), and SILVIAMuladd, which targets factor-2 packed multiply-and-adds with shared operands and factor-4 packed 4-bit multiplications, including a packing for four unsigned 4-bit factors times one common signed or unsigned factor. The packed function is either described in the IR or left as a placeholder module that is later swapped for a custom RTL implementation.","core_discovery":"The paper establishes that superword-level parallelism naturally present in HLS designs, often exposed by loop unrolling, can be recognized and exploited at the LLVM intermediate-representation level without source-code changes. The key move is to treat a basic block as a set of candidate arithmetic instructions, rearrange their uses as late as possible (ALAP) so that packed replacement calls have a valid insertion point, group independent candidates into tuples that satisfy the DSP packing constraints, and replace each tuple with a call to a packed-operation function that the HLS backend binds to a single DSP. This yields a 70% average reduction in DSPs for additions and a 50% average reduction for multiplications and multiply-and-adds across the benchmarks, with no change to pipeline initiation intervals; in CNN case studies the automatically optimized designs occupy the same DSP-versus-throughput points as manually tuned ones.","pith_inferences":["If SILVIA's reliability holds on larger designs, the natural next step is to let the HLS scheduler feed latency information back into tuple formation, eliminating the edge case where packing creates a new critical cycle and increases the initiation interval.","The same candidate-tuple-pack skeleton could be retargeted to other DSP families or to mixed-precision operations by re-deriving the shared-operand and overflow constraints for those architectures.","The resource-sharing extension mentioned in the paper, which would pack even single addition instructions so they share a functional unit with packed tuples, could reduce DSP counts further on designs with many unpaired operations.","Because packing is done at the IR level after frontend width minimization, the approach could combine with other IR-level transformations, such as loop tiling or operation fusion, to expose more packable parallelism than unrolling alone."],"forward_implications":["HLS code can stay scalar and portable: the pass finds the packing opportunities after frontend optimization, so designers no longer hand-insert bit manipulation or RTL modules to use DSP SIMD modes.","Across the measured benchmarks, average DSP utilization drops by 70% for additions and 50% for multiplications and multiply-and-adds, while initiation intervals, and therefore throughput, are unchanged.","In the CNN case studies, SILVIA-optimized designs match manually optimized accelerators in the DSP-versus-throughput trade-off, reaching roughly double throughput when the DSP count is capped.","The base pass is extensible: adding a new packed operation requires only candidate detection and tuple-packing routines, with the ALAP scheduling, tuple-validity checks, and dead-code cleanup reused.","The cost side is explicit: packed pipelines are about 27% deeper on average, using more flip-flops and memory LUTs, while DSP savings still reduce average power by roughly 8-10%."],"supporting_citations":[{"why":"Supplies the factor-2 multiply-and-add packing equations and the DSP-chain overflow bound that SILVIAMuladd enforces.","marker":"[5]"},{"why":"Defines the vectorized wide-integer datapath with numeric-overflow side-band logic that underlies the four-4-bit multiplication packing.","marker":"[14]"},{"why":"Provides an open-source implementation of the four-4-bit packing and a manually tuned CNN baseline that SILVIA is compared against.","marker":"[20]"},{"why":"Documents the UltraScale DSP slice SIMD modes (four 12-bit or two 24-bit additions) and multiplier structure that the packing targets.","marker":"[22]"},{"why":"Documents the Versal DSP engine, the second target architecture for the same packed operations.","marker":"[3]"},{"why":"Supplies the LLVM 3.1 pass infrastructure and APIs that SILVIA's basic-block analysis and transformation are built on.","marker":"[18]"},{"why":"Provides the superword-level vectorization concept and grouping strategy that SILVIA adapts from CPU compilers to HLS.","marker":"[19]"},{"why":"Is the manually optimized residual-CNN accelerator whose DSP utilization and throughput SILVIA matches in the case study.","marker":"[12]"}],"fun_headline_variants":["SILVIA pass packs ops into DSPs, slashing FPGA DSP use by up to 70%","Auto DSP packing: LLVM pass for HLS cuts FPGA resource use 50-70%","LLVM pass for Vitis HLS automatically packs subword ops onto DSPs","SILVIA auto-packing cuts DSP usage 70% for adds, 50% for mults"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The central claim collapses if the custom RTL modules that replace SILVIA's placeholder functions do not compute bit-identically to the original scalar additions, multiplications, and multiply-and-adds for every supported width and signedness.","fun_headline_variants_meta":{"raw":{"variants":["SILVIA pass packs ops into DSPs, slashing FPGA DSP use by up to 70%","Auto DSP packing: LLVM pass for HLS cuts FPGA resource use 50-70%","LLVM pass for Vitis HLS automatically packs subword ops onto DSPs","SILVIA auto-packing cuts DSP usage 70% for adds, 50% for mults"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000902,"raw_usage":{"total_tokens":3877,"prompt_tokens":932,"completion_tokens":2945,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":548,"completion_tokens_details":{"reasoning_tokens":2845}},"tokens_in":548,"tokens_out":2945,"duration_ms":19819,"temperature":1.0,"reasoning_tokens":2845,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T18:34:01.979403+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Synthesize any SILVIA-optimized design with the placeholder modules replaced, then run an exhaustive or randomized bit-accurate simulation of the packed RTL against the original scalar operations for all supported input widths; a single mismatch in the four-12-bit adder, the two-24-bit adder, the factor-2 MAD, or the factor-4 multiplier would invalidate the reported DSP savings. A second check is to build the dependence pattern of Fig. 5 and measure whether the initiation interval grows from 2 to 3 cycles as predicted when packing creates a new critical cycle.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the factor-2 multiply-and-add packing equations and the DSP-chain overflow bound that SILVIAMuladd enforces."},{"cited_title":"Preusser and Thomas A","cited_arxiv_id":null,"evidence_quote":"Defines the vectorized wide-integer datapath with numeric-overflow side-band logic that underlies the four-4-bit multiplication packing."},{"cited_title":"Fraser, Giulio Gambardell a, Michaela Blott, Philip Leong, Magnus Jahre, and Kees Viss ers","cited_arxiv_id":null,"evidence_quote":"Provides an open-source implementation of the four-4-bit packing and a manually tuned CNN baseline that SILVIA is compared against."},{"cited_title":"UltraScale Architecture DSP Slice","cited_arxiv_id":null,"evidence_quote":"Documents the UltraScale DSP slice SIMD modes (four 12-bit or two 24-bit additions) and multiplier structure that the packing targets."},{"cited_title":"Versal ACAP DSP Engine Architecture Manual (AM004)","cited_arxiv_id":null,"evidence_quote":"Documents the Versal DSP engine, the second target architecture for the same packed operations."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the LLVM 3.1 pass infrastructure and APIs that SILVIA's basic-block analysis and transformation are built on."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the superword-level vectorization concept and grouping strategy that SILVIA adapts from CPU compilers to HLS."},{"cited_title":"Lazarescu, an d Luciano Lavagno","cited_arxiv_id":null,"evidence_quote":"Is the manually optimized residual-CNN accelerator whose DSP utilization and throughput SILVIA matches in the case study."}],"review_version":1}