{"id":"ae8b7ed7-67ee-41d8-b087-f5428d1438a8","arxiv_id":"2411.15574","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"Vespa adds multi-replica accelerator tiles, independently clocked frequency islands with dynamic frequency scaling, and runtime monitoring to the open-source ESP SoC framework.","lead":"The authors present Vespa, an open-source extension of the ESP framework that lets designers pack several copies of the same accelerator into one tile, split a system-on-chip into independently clocked frequency islands, and read runtime counters. It is a toolkit paper: the value is in how quickly and flexibly FPGA-based heterogeneous SoCs can be built and tuned.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Throughput-scaling claim in §II-A is bounded by the shared AXI bridge/NoC/memory path: dfadd and dfmul in Table I both cap at exactly 26.06 MB/s at 4× replication despite different 1× throughput, so K× accelerator-throughput scaling is only established for unshared, compute-bound tiles.","rationale":"I read the paper as an engineering contribution: it is open-source, runs on real FPGA prototypes, and provides a monitoring infrastructure with actual measurements. The central claim is that the K-replica tile yields scalable throughput by configuring K without touching the accelerator or the NoC. For that claim to hold, each added replica must add useful throughput; this fails when the shared front-end or memory saturates. Table I's identical 26.06 MB/s cap for dfadd and dfmul is an internal check that points to exactly that failure for memory-bound accelerators. Therefore I agree with the Reader's CONDITIONAL assessment and do not move the verdict; however, the authors should explicitly scope the K× claim and characterize the bridge/NoC ceiling. The concern is not about novelty or fitting; it is about the boundary conditions of the headline result.","tokens_in":6261,"tokens_out":3588,"duration_ms":33666,"concrete_test":"Instantiate dfmul and dfadd in the A1 placement with K = 1, 2, 4, and 8, with all TG tiles disabled, the NoC and memory island at 100 MHz, and the accelerator island at 50 MHz, placing a hardware counter at the AXI bridge output. If aggregate throughput stops growing with K (e.g., both accelerators still cap near 26 MB/s while per-replica throughput decreases), the shared bridge/NoC/memory path is the bottleneck and the §II-A K× claim must be restricted to compute-bound accelerators; if aggregate throughput continues to scale past 26 MB/s, the saturation in Table I is accelerator-specific and the concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section II-A states that instantiating K replicas of an accelerator in one tile \"intuitively provides a K× increase of the throughput of the baseline accelerator.\" Section III-A then quantifies this with average throughput increases of 1.92× and 3.58× for 2× and 4× replication. The most load-bearing assumption is that the replicated accelerator remains the throughput bottleneck. The paper's own Table I indicates otherwise: dfadd goes 9.22 → 16.88 → 26.06 MB/s, and dfmul goes 8.70 → 15.07 → 26.06 MB/s, so both memory-bound accelerators saturate at the identical 26.06 MB/s value at 4×. The exact coincidence of the ceiling for two accelerators with different baseline throughputs is strong evidence of a common resource limit—the single AXI bridge, the single NoC link, or DDR bandwidth—rather than a property of the accelerators. Section III-B also shows dfmul throughput collapsing as NoC traffic increases, confirming that the bridge/memory path is often the limiting resource. The authors do call dfadd memory-bound, so the data are not hidden, but the K× claim is stated without this qualification, and the conclusion calls it a \"scalable throughput architecture.\" If the bridge/NoC/memory path is the ceiling, the headline scalability result is actually a saturation study for a nontrivial class of accelerators.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents Vespa, an open-source framework that extends ESP to support design space exploration and runtime optimization of FPGA-based multi-core heterogeneous SoCs. Three main capabilities are added: multi-replica accelerator tiles that instantiate K copies of an AXI-compatible accelerator within a single NoC node, configurable frequency islands with independent DFS actuators (using a dual-MMCM scheme to avoid clock-gating during reconfiguration), and a memory-mapped monitoring infrastructure that exposes execution time, packet counts, and round-trip time. The evaluation on a 4x4 tile-based SoC implemented on a Virtex-7 2000 FPGA shows resource and throughput trade-offs for 2x and 4x replication of five CHStone accelerators, the throughput behavior of compute- versus memory-bound accelerators under NoC traffic, and the effect of island clock frequencies on memory traffic.","tokens_in":6579,"tokens_out":7390,"duration_ms":57319,"significance":"If the claims hold, Vespa is a valuable open-source contribution: it provides a practical way to explore accelerator replication and fine-grained frequency-island partitioning on real FPGA prototypes, and the dual-MMCM DFS mechanism addresses a genuine problem in FPGA clock reconfiguration. The monitoring infrastructure is a useful enabler for run-time optimization. The paper ships open source, and the experiments are direct measurements on implemented hardware with no fitted parameters. However, the central throughput-scaling claim is only partially supported by the data, and the reported quantitative results contain an inconsistency that needs correction.","major_comments":[{"comment":"The claim that instantiating K replicas \"intuitively provides a K× increase of the throughput of the baseline accelerator\" is not supported for memory-bound accelerators. In Table I, dfadd and dfmul both saturate at exactly 26.06 MB/s at 4x replication despite having different baseline throughputs (9.22 and 8.70 MB/s), which indicates a shared resource limit—likely the AXI bridge, the NoC link, or the memory controller—rather than the accelerator itself. Section III-B further shows that dfmul throughput collapses as NoC traffic increases. The paper should qualify the Kx scaling claim to compute-bound accelerators and state the conditions under which the bridge/NoC/memory path is not the bottleneck; this is load-bearing because the conclusion describes Vespa as a \"scalable throughput architecture.\"","section":"§II-A, §III-A, Table I"},{"comment":"The reported average throughput increases of 1.92x and 3.58x for 2x and 4x replication do not match the data in Table I. Computing the average of the per-accelerator throughput ratios from the table gives 1.89x and 3.41x, and the latter value actually appears in the \"Incr.\" row of Table I. The 3.58x figure appears to be an arithmetic error or to be based on a different set of accelerators. Please correct the numbers and, more importantly, report per-accelerator throughput ratios so that the saturation of dfadd and dfmul is transparent.","section":"§III-A, Table I"}],"minor_comments":[{"comment":"Please clarify whether each throughput value in Table I is the result of a single execution or the average of multiple runs; if multiple runs were performed, include error bars or variance, especially for the key replication measurements.","section":"§III-A"},{"comment":"The core name \"CV A6\" should be written \"CVA6\" (or \"Ariane\") as in reference [9].","section":"§III"},{"comment":"The phrase \"quite smaller than the replication factor\" is awkward; consider \"substantially smaller\" or \"significantly smaller.\"","section":"§III-A"},{"comment":"The figure legend uses \"Resync\" and \"resychronizers\" (typo); it should be \"resynchronizers\" consistently. The labels \"DFSm\" and \"DFSn\" are also visually confusing and could be clarified.","section":"Fig. 1"}],"recommendation":"major_revision","confidential_remarks":"The paper is a well-scoped framework contribution with an open-source release. The self-citations [1,3,7] are used appropriately to motivate the monitoring and acceleration context. The main technical issue—the unqualified Kx throughput claim—is fixable by adding the necessary qualifications and by correcting the reported average increases. I recommend major revision rather than rejection because the framework itself is useful and the core architectural ideas are sound."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper is worth reading if you work with ESP or FPGA prototyping of heterogeneous SoCs. The new and real thing is the Vespa framework: multi-replica accelerator tiles that keep the same AXI interface to the NoC, glitch-free dual-MMCM DFS actuators per frequency island, and memory-mapped monitoring counters. It is open source, the experimental setup is described in enough detail to reproduce, and the resource/throughput tables are concrete. This is a genuine engineering contribution, not a reparameterization of prior work.\n\nThe soft spots are in the scaling claim. Section II-A says that K replicas 'intuitively provide a Kx increase of throughput.' The data in Table I show that dfadd and dfmul both hit exactly 26.06 MB/s at 4x replication despite very different 1x throughputs. That is a red flag for a shared bottleneck, likely the AXI bridge or the NoC/memory path. The stress-test note is right: the headline Kx scaling is only established for lightly loaded, compute-bound accelerators. The paper does call dfadd memory-bound and Fig. 3 shows dfmul collapsing under NoC traffic, so the authors are not hiding the data, but the claim in the introduction and conclusion is overbroad. That is a moderate flaw, not a fatal one.\n\nTwo other minor issues: there are no error bars or multiple runs, which is common for FPGA prototype papers but worth noting; and there is no baseline against plain ESP to show what Vespa adds in area or performance. These are minor because the framework ships and the qualitative behavior is clear.\n\nThe circularity burden is truly low: no fitted parameters, no self-defined success metric, just direct measurements of real hardware. Self-citations are used to motivate the work, not to carry the central result.\n\nWho gets value: researchers doing DSE on FPGA-based SoCs, especially those using ESP who want accelerator replication, DFS islands, and monitoring without writing RTL from scratch. It is a niche but active audience.\n\nRecommendation: send it to peer review. It deserves referee time. I would ask the authors to qualify the Kx claim to compute-bound accelerators and add a sentence acknowledging the shared-path ceiling, but I would not reject it over that.","headline":"Vespa is a solid, openly released extension of ESP, but its Kx throughput claim only holds for compute-bound accelerators, and the data show a common shared-path ceiling for memory-bound ones.","tokens_in":7070,"tokens_out":1229,"would_cite":true,"duration_ms":12950,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Multi-replica tiles push SoC accelerator throughput up to 3.58x.","keywords":["system-on-chip","FPGA prototyping","network-on-chip","dynamic frequency scaling","hardware accelerator replication","design space exploration","run-time monitoring"],"falsifier":"Measure the throughput of a memory-bound accelerator placed in a 4x-replication tile while NoC traffic is varied. If the K=4 tile does not deliver roughly four times the K=1 tile's throughput under light traffic, or if its throughput saturates at a value that does not change with K, the Kx scaling claim is falsified.","tokens_in":6093,"feed_emoji":"⚙️","tokens_out":8663,"duration_ms":73160,"temperature":0.7,"pith_summary":"Vespa is an open-source framework for building large FPGA-based heterogeneous systems-on-chip whose tiles can be reconfigured to trade throughput against area, run at per-island clock frequencies, and report their own performance statistics. Its central idea is the multi-replica accelerator tile: K copies of the same AXI-based accelerator occupy a single network-on-chip node behind one bridge, so the designer can raise accelerator throughput without touching the accelerator or the interconnect. The framework also partitions the SoC into frequency islands with independent dynamic-frequency-scaling actuators that keep the clock running during reconfiguration, and it provides memory-mapped counters for execution time, packet counts, and memory round-trip time. On a 4-by-4 tile prototype, 2x and 4x replication give average throughput increases of 1.92x and 3.58x, with DSP usage growing roughly linearly while the other resource classes grow more slowly. The paper argues these capabilities make FPGA prototypes usable for design space exploration and run-time optimization of complex accelerator-centric SoCs.","feed_headline":"Multi-replica tiles push SoC accelerator throughput up to 3.58x","feed_subtitle":"An open-source framework adds configurable replication, frequency islands, and run-time counters to FPGA SoC design.","key_machinery":"The load-bearing object is the multi-replica accelerator (MRA) tile: K copies of one accelerator, each exposing AXI4-Stream interfaces for read control, write control, read data, and write data, multiplexed by a single AXI bridge into the tile's four buffers toward the NoC. The replication factor K is a design-time parameter, so scaling requires no change to the accelerator or the network. Two mechanisms support the rest of the framework: frequency islands whose clocks come from either a fixed source or a dynamic frequency scaling (DFS) actuator built from two clock managers so one keeps the island clock alive while the other reconfigures, and memory-mapped counters that record accelerator execution time, incoming and outgoing packets, and round-trip time.","core_discovery":"The paper's central claim is that an accelerator's throughput can be scaled by an integer factor K simply by instantiating K replicas of it in one tile, and that this configurable replication, combined with per-island dynamic frequency scaling and run-time counters, is enough to support design space exploration and run-time optimization of a large SoC. The evidence is that 2x and 4x replication raise average throughput by 1.92x and 3.58x on the evaluated accelerators, while the same experiments show that a memory-bound accelerator loses throughput as NoC traffic rises, so the near-Kx scaling holds when the accelerator, not the bridge, NoC, or memory, is the limiting resource.","pith_inferences":["A natural extension the paper does not develop is to use the counters to close a feedback loop: a run-time policy could raise an island's frequency when its accelerator is the bottleneck and lower it when memory traffic saturates.","The saturation of dfadd and dfmul near 26 MB/s at 4x replication suggests the AXI bridge or memory path becomes the next bottleneck; testing higher values of K would reveal the ceiling of this approach.","The same MRA tile could be paired with multiple bridge paths or wider NoC links to push the scaling limit, an option the paper leaves on the table.","A designer could use the framework to build a Pareto-optimal set of SoC configurations in replication, frequency, and placement before committing to a final design."],"forward_implications":["A designer can tune each accelerator's throughput-versus-area trade-off with a single parameter, without editing accelerator RTL or resizing the NoC.","Software or host logic can change the clock of each island separately at run time, so the SoC frequency can adapt to the workload without stopping the island's clock.","The memory-mapped counters give a uniform way to watch accelerator execution, packet traffic, and memory round-trip latency during both exploration and deployed operation.","Because DSP blocks scale roughly with K while other resources scale less, replication is most area-efficient for accelerators whose replication cost is dominated by non-DSP logic.","The reported 1.92x and 3.58x average gains indicate that first-order throughput scaling by replication is achievable on FPGA prototypes for accelerators that are not memory-bound."],"supporting_citations":[{"why":"the open-source SoC prototyping framework whose tile architecture and design flow Vespa extends.","marker":"[4]"},{"why":"the benchmark suite whose HLS-generated accelerators populate the experimental SoC instances.","marker":"[8]"},{"why":"the CPU core used as the processor tile in the 4-by-4 prototype, making the platform a realistic heterogeneous SoC.","marker":"[9]"}],"fun_headline_variants":["Accelerator replication in one tile scales SoC throughput up to 3.58x","Vespa's replica tiles deliver near-linear SoC throughput gains","Accelerator replication yields 1.92x-3.58x SoC throughput gains","Vespa adds accelerator replication and frequency islands to FPGA SoC design"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The K-times throughput gain assumes the accelerator is the bottleneck; it breaks when the AXI bridge, the network-on-chip, or memory saturates first.","fun_headline_variants_meta":{"raw":{"variants":["Accelerator replication in one tile scales SoC throughput up to 3.58x","Vespa's replica tiles deliver near-linear SoC throughput gains","Accelerator replication yields 1.92x-3.58x SoC throughput gains","Vespa adds accelerator replication and frequency islands to FPGA SoC design"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001481,"raw_usage":{"total_tokens":5905,"prompt_tokens":856,"completion_tokens":5049,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":472,"completion_tokens_details":{"reasoning_tokens":4971}},"tokens_in":472,"tokens_out":5049,"duration_ms":30297,"temperature":1.0,"reasoning_tokens":4971,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T14:08:51.599281+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Measure the throughput of a memory-bound accelerator placed in a 4x-replication tile while NoC traffic is varied. If the K=4 tile does not deliver roughly four times the K=1 tile's throughput under light traffic, or if its throughput saturates at a value that does not change with K, the Kx scaling claim is falsified.","supporting_citations":[{"cited_title":"Mantovani, D","cited_arxiv_id":null,"evidence_quote":"the open-source SoC prototyping framework whose tile architecture and design flow Vespa extends."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"the benchmark suite whose HLS-generated accelerators populate the experimental SoC instances."},{"cited_title":"Zaruba and L","cited_arxiv_id":null,"evidence_quote":"the CPU core used as the processor tile in the 4-by-4 prototype, making the platform a realistic heterogeneous SoC."}],"review_version":1}