{"id":"ba64d022-87c3-45eb-b410-08663e163c98","arxiv_id":"2607.21077","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"A 23-stage pipelined FPGA probability-bit engine keeps fully-connected Ising machine updates flowing at 300 MHz, giving about a 10x throughput gain over a non-pipelined design at equal parallelism.","lead":"A new FPGA design for optimization chips that flip random \"probability bits\" uses a deep assembly-line (23-stage) pipeline and overlapped scheduling to run fully-connected problems at 300 MHz, about ten times faster per bit than a non-pipelined version at equal parallelism. It targets dense workloads such as financial portfolio optimization and error-correction decoding, where sparse Ising accelerators lose their advantage.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Pipeline-fill/ordering assumption is unproven: the 10x speedup and sequential-Gibbs equivalence both depend on the claim that local-field updates can be fully overlapped at fixed DOP, but no schedule proof or RTL is provided.","rationale":"The paper is an engineering contribution with real board-measured results at 512 p-bits, and I do not question the 300 MHz vs 40 MHz clock difference or the basic feasibility of a 23-stage pipeline. The reason I single out the pipeline-fill/ordering assumption is that the headline number is not just a clock-frequency ratio; it depends on replacing the baseline's N/DOP-cycle update phase with a constant L_up-cycle overlap. That replacement is only legitimate if every local-field delta is available before its spin is evaluated. The paper asserts this ('guaranteeing...', 'strictly sequential... for any DOP') but the only support is a scheduling description and a handful of benchmarks. The admission in Table 1 that 'stalls occur' when parameters are not tuned shows the property is not automatic. Because no formal proof, RTL, or cycle-accurate simulator is provided, the reader cannot verify the deadline constraints. This matches the Reader's weakest_assumption. My proposed check is deliberately simple: simulate the published schedule under worst-case all-flips behavior; this settles whether the pipeline can remain continuously filled at the claimed operating points. If it can, the conditional verdict stands; if not, the order-of-magnitude claim is not supported.","tokens_in":16737,"tokens_out":12974,"duration_ms":146543,"concrete_test":"Take the published schedule (Supplementary Note 7) and simulate it cycle-accurately for N=512 and DOP values reported in Fig. 3 (e.g., 2, 8, 32, 128, 512) with L_ev and L_up as reported, using a worst-case pattern in which every evaluated spin flips. Track pending local-field deltas and count cycles in which a p-bit evaluation is delayed because the target local field is stale. Unless the simulation shows zero delayed evaluations for every claimed operating point, the 'continuously filled pipeline' / 'strictly sequential for any DOP' assertion is false and the order-of-magnitude claim must be re-scoped.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim (Abstract; Conclusion: 'more than an order-of-magnitude higher update throughput ... at fixed parallelism') rests on the assertion in Results B that 'a new local field update is launched at every clock cycle, guaranteeing that the pipeline remains continuously filled' and that 'the proposed architecture preserves strictly sequential-update sampling for any DOP.' This is the load-bearing point. For a fully-connected update, one accepted flip of spin i generates N local-field deltas; those deltas must be retired before each later spin reads its local field. The paper gives the issue interval L_ev + L_up cycles but provides no deadline/queueing analysis for this update backlog, and no RTL or cycle-accurate schedule is released. The text itself concedes that 'if the degree of parallelism and pipeline depth are not properly tuned, stalls occur and peak throughput is not achieved' (Table 1, Cons). If the pipeline stalls or the update order is changed to hide latency, both the 10x throughput curve and the claimed equivalence to sequential software-PIM sampling break. The empirical validation on a few workloads cannot distinguish a correct stall-free schedule from one that silently reorders or drops updates.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents a pipelined FPGA implementation of a fully-connected probabilistic Ising machine (PIM). The architecture uses a 23-stage pipeline to overlap p-bit evaluation with local-field and energy updates, combined with bandwidth-aware on-chip memory organization, and reports operating frequencies up to 300 MHz on an AMD ZCU106, compared to 40 MHz for a non-pipelined baseline. The central claim is that at fixed degree of parallelization (DOP), the pipelined design delivers more than an order-of-magnitude higher update throughput, with application demonstrations on portfolio optimization and LDPC decoding. The paper includes board-level measurements for 512-p-bit designs, synthesis-based estimates for larger sizes, and projections beyond 1024 p-bits.","tokens_in":17071,"tokens_out":6396,"duration_ms":69909,"significance":"If the central claim holds, the work is a meaningful step toward scalable digital PIMs for dense, fully-connected optimization problems, a regime where previous FPGA implementations rely on sparsity, graph embedding, or external memory. The paper's strengths include clear validation-level taxonomy (implemented/measured/estimated/projected), fixed-DOP comparison protocols, and board-measured 512-p-bit results at 300 MHz vs 40 MHz. However, the main contribution rests on an asserted but not formally demonstrated pipeline-fill and ordering guarantee, and the energy claims are based on Vivado power estimates rather than board measurements. These load-bearing points need to be substantiated before the performance claims can be fully accepted.","major_comments":[{"comment":"The claim that 'a new local field update is launched at every clock cycle, guaranteeing that the pipeline remains continuously filled' is not supported by a quantitative condition. In a fully-connected model, each accepted spin flip generates N local-field increments. With an evaluation issue interval of L_ev + L_up cycles and a throughput of DOP increments per cycle, a necessary condition for avoiding a growing backlog is DOP >= N/(L_ev+L_up). The manuscript never states or verifies this condition for the reported operating points. For example, at N=2048 with L_ev+L_up=23, DOP >= 89 would be required, yet the paper does not report a validated 2048-p-bit configuration at that DOP. Table 1 itself concedes that stalls occur when DOP and pipeline depth are not properly tuned. The central 'order-of-magnitude' throughput claim therefore depends on an unproven schedule property; a formal deriv","section":"Results B, paragraph 2 ('Thanks to the pipelined organization...')"},{"comment":"The assertion that the architecture 'preserves strictly sequential-update sampling for any DOP' is load-bearing for the equivalence to the software PIM baseline, but no formal invariant or proof is provided. Reordering local-field updates to prioritize p-bit i+1 may change the effective order in which state changes are observed by subsequent evaluations. The paper does not show a cycle-level schedule or RTL to rule out silent reordering or dropped updates. The empirical agreement with software PIM on invertible logics and Max-Cut instances is encouraging but cannot certify the 'any DOP' claim. Please provide either a proof of the ordering invariant or a detailed schedule showing exactly when each local-field update is applied relative to each spin evaluation.","section":"Results B, paragraph 2 ('By carefully scheduling memory accesses...')"},{"comment":"The energy per sweep reduction (52% on validated designs, 29% on projections) is computed from Vivado power estimates, not board-level power measurements. The paper's own taxonomy in Results says that 'Estimated' applies only to power, and the Summary notes that 'explicit energy measurements will be important.' Yet the Conclusion states that 'the architecture improves the sampling time of 10x and reduce the energy consumption' without this caveat. The abstract also omits the estimated nature of the energy result. Figure 4b should be clearly labeled as estimated, and the text should carry the same caveat in the abstract and conclusion.","section":"Fig. 4b and Summary/Conclusion energy statements"},{"comment":"The central claim rests on a specific pipeline schedule and on the absence of stalls. No RTL, cycle-accurate simulation results, or schedule traces are provided; the data availability statement says 'available upon reasonable request' only. Given that the paper's main contribution is an architectural scheduling claim, the absence of any machine-checked schedule or released RTL prevents independent verification of the load-bearing assumption. At minimum, the authors should release the schedule pseudocode with precise L_ev and L_up values and measured cycle counts for the reported designs.","section":"Data availability / reproducibility"}],"minor_comments":[{"comment":"Typo: '16/10/2-bit fixed-point coefficient for for J and h' should read 'for J and h'.","section":"Results A, paragraph 1"},{"comment":"The quantities L_ev and L_up are introduced but their numerical values (in cycles) are never specified. The reader cannot verify the issue-interval formula L_ev + L_up without these values. Please report them for the 23-stage configuration.","section":"Results B, paragraph 1 / Fig. 1 caption"},{"comment":"The figure labels and text mix 'measured' and 'projected' points in the same plot. The validation-level taxonomy is helpful, but the main-text descriptions (e.g., 'Results above 512 p-bits are a projection') should be visually encoded in the figures themselves (e.g., dashed lines) for clarity.","section":"Results C / Fig. 3 caption"},{"comment":"The abbreviation 'MQT QAO' is not defined. It appears to refer to a software library; please provide a reference or full name.","section":"Methods, Portfolio optimization"},{"comment":"The comparison with prior PIMs is careful, but the 'Highest reported operating frequency' claim should be qualified by the fact that update primitives differ across architectures (as the paper itself notes in the paragraph before Summary). Please make that qualification explicit in the caption of Table 1 as well.","section":"Discussion / Table 1"}],"recommendation":"major_revision","confidential_remarks":"The paper addresses a timely and relevant topic, and the measured 512-p-bit results at 300 MHz vs 40 MHz are valuable. The main concern is structural: the central throughput and sampling-equivalence claims depend on an unproven pipeline-fill/ordering guarantee. I would encourage the editor to ask for either a formal schedule proof, a cycle-accurate simulation with exact L_ev and L_up, or release of the RTL/schedule traces. If the authors can supply that, the claims would be substantially strengthened. The energy claims should also be softened or properly labeled as estimated."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a real piece of engineering work. The authors build a fully-connected FPGA PIM with a 23-stage pipeline, run it at 300 MHz on a ZCU106 board, and measure an order-of-magnitude throughput gain over their own non-pipelined baseline at the same DOP, with 512 p-bits at 16-bit precision. That is new.\n\nThe key idea is to overlap the local-field update with the next spin evaluation, so that the update bottleneck is hidden. Prior FPGA PIMs either exploited sparsity (Aadit et al.), restricted couplings to 2 bits (pc-COP), or used graph coloring for sparse lattices (Chowdhury et al.). This design handles dense all-to-all graphs natively, and the memory organization (paging, multi-row banking, symmetric reuse) is sensible. The board measurements give real weight to the claim. The validation on portfolio and LDPC instances shows the fixed-point hardware agrees with the software reference, which is reassuring.\n\nThe soft spots are not fatal but need attention. The claim that the pipeline stays continuously filled and that strictly sequential update ordering is preserved for any DOP is asserted more than proven. The paper mentions that stalls occur if DOP and pipeline depth are not tuned, so the \"any DOP\" part is too strong. For the tested configurations, the measured throughput implies the schedule does work, so the empirical evidence covers the main claim. I would like to see either a more careful scheduling analysis, or a release of the RTL/cycle-accurate model to back the general statement. Also, energy is estimated from Vivado power reports, not measured, and some figures include projected points beyond the measured sizes. There is an inconsistency in the claimed resource reduction (16x in the intro, 8x in the results) that needs reconciling. And the phrase \"In the revised manuscript this term applies only to power\" is a revision artifact that should not be in a final version.\n\nThe citation pattern is fine; they cite the relevant previous work, including the theoretical pipelined adder paper [45], and state honestly where their architecture differs.\n\nBottom line: this deserves a serious referee. It is a useful, measured contribution to FPGA probabilistic computing. I would recommend sending it to review, with the expectation of moderate revision to tighten the scheduling claim and clean up the inconsistencies.","headline":"A genuinely useful pipelined FPGA PIM for dense Ising problems, with measured 300 MHz operation; the main caveat is that the stall-free schedule is asserted rather than proven, though the 512-p-bit measurements back it up for the tested configurations.","tokens_in":17585,"tokens_out":4394,"would_cite":true,"duration_ms":50919,"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":"A 23-stage pipelined FPGA design keeps fully-connected probabilistic Ising machines running at 300 MHz, delivering an order-of-magnitude higher update throughput than a non-pipelined baseline at the same degree of parallelization.","keywords":["probabilistic Ising machine","p-bits","FPGA","pipeline architecture","local-field update","fully-connected Ising model","combinatorial optimization","LDPC decoding"],"falsifier":"Measure the p-bit update rate as a function of problem size N while holding DOP fixed past the synthesized range (e.g., N = 4096 or 8192 on a larger FPGA): if throughput falls proportionally to N/DOP rather than remaining near the 300 MHz limit, the pipeline is stalling and the central claim is refuted. Alternatively, run the pipelined design and a strictly sequential software PIM on the same dense instance and compare the distribution of spin configurations (or an update-order-sensitive statistic) with a statistical test; a significant difference would falsify the claimed sampling equivalence","tokens_in":16664,"feed_emoji":"⚙️","tokens_out":4899,"duration_ms":46965,"temperature":0.7,"pith_summary":"This paper argues that the bottleneck for dense, fully-connected probabilistic Ising machines on FPGAs — the local-field update step — can be removed by deep pipelining instead of by adding parallel hardware. It reports a 23-stage pipelined p-bit update path that overlaps spin evaluation with local-field updates, keeping the pipeline continuously filled, and a bandwidth-aware on-chip memory organization for coupling and bias matrices. The result, on an AMD ZCU106 board, is a 300 MHz clock (versus 40 MHz for an optimized non-pipelined baseline) and more than an order-of-magnitude higher update throughput at the same degree of parallelization, with logic area growing with parallelism rather than problem size. If correct, this makes native all-to-all Ising problems practical on reconfigurable hardware without sparsification or graph embedding.","feed_headline":"23-stage pipeline gives Ising machines 10x faster updates","feed_subtitle":"Dense, fully-connected optimization problems run on FPGAs without sparsification, at 300 MHz versus 40 MHz.","key_machinery":"The carrying mechanism is the 23-stage pipelined p-bit update path, which overlaps the two phases that a non-pipelined design runs sequentially: evaluating whether a spin flips (random comparison with tanh of the local field) and updating the local fields and energy for all other spins. The schedule prioritizes the update of p-bit i+1, so the next evaluation can begin as soon as that field is ready while remaining updates proceed in the background. The design is completed by a bandwidth-aware on-chip memory hierarchy — shared and paged memories, multi-row banking, symmetry-aware reuse, word packing — that streams coupling coefficients from Block RAM at one element per cycle per DOP, avoiding","core_discovery":"The paper's central claim is that a deeply pipelined update engine (23 stages in the validated design) lets a fully-connected probabilistic Ising machine sustain high update rates on dense problems using only a moderate, configurable degree of parallelization. The pipeline splits the critical path that limited the non-pipelined baseline to 40 MHz, and reorders local-field updates so the next p-bit evaluation can begin once its own field is ready, without waiting for the full update phase. A new local-field update starts every clock cycle, keeping the pipeline continuously filled, with strictly sequential p-bit sampling preserved. At fixed DOP the design reports over an order-of-magnitude hig","pith_inferences":["If the stall-free pipeline behavior persists at sizes beyond the synthesized range, the 23-stage structure should transfer to an ASIC where fine-grained SRAM banking and clock gating could push frequency and energy efficiency beyond the FPGA demonstrator.","The paper's reordering argument suggests that a formal proof of equivalence between the reordered schedule and strictly sequential Gibbs sampling would elevate the empirical validation into a guarantee; absent such a proof, the sampling-order claim rests on experiments.","Because pipeline depth is a property of the arithmetic path rather than of problem size, the approach could extend naturally to higher-order Ising models by reorganizing coefficient storage around hyperedges, as the paper sketches.","A consequence the authors leave implicit is that the architecture's advantage grows with problem density: workloads whose Ising matrices are already sparse would gain less, since the baseline's memory bottleneck is less severe there."],"forward_implications":["Dense Ising formulations (portfolio optimization, LDPC decoding, Max-Cut on dense graphs) can be accelerated on FPGAs without sparsification, graph embedding, or external memory in the update loop.","At fixed DOP, the pipelined architecture's throughput remains nearly flat as problem size grows, whereas the non-pipelined baseline degrades roughly as N/DOP; this changes the scaling strategy for larger p-bit counts.","Logic utilization scales primarily with the chosen DOP rather than with the number of p-bits, so a balanced operating point (about 30% of p-bits as DOP) gives near-peak throughput at a fraction of full-parallelism resources.","The energy per Monte Carlo sweep is lower (about 52% reduction on validated designs) because the higher clock frequency more than offsets the increased dynamic power.","The same architecture can host multiple independent replicas sharing the coupling and bias memories, enabling annealing schemes such as parallel tempering or simulated quantum annealing."],"fun_headline_variants":["Pipelined p-bit engine speeds dense Ising by 10x on FPGA","Deep pipeline lifts dense Ising throughput 10x without sparsification","Ising machine pipeline hits 300 MHz, 10x faster on dense problems","23-stage pipeline unlocks 10x update rate for fully-connected Ising"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The load-bearing assumption is that the pipeline stays continuously filled and that the reordered local-field updates preserve exactly the sequential p-bit update order; if stalls appear as problem size grows, or if the reordering changes the effective sampling order, the order-of-magnitude throughput gain and the equivalence to software PIM sampling both fail.","fun_headline_variants_meta":{"raw":{"variants":["Pipelined p-bit engine speeds dense Ising by 10x on FPGA","Deep pipeline lifts dense Ising throughput 10x without sparsification","Ising machine pipeline hits 300 MHz, 10x faster on dense problems","23-stage pipeline unlocks 10x update rate for fully-connected Ising"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000536,"raw_usage":{"total_tokens":2426,"prompt_tokens":771,"completion_tokens":1655,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":515,"completion_tokens_details":{"reasoning_tokens":1584}},"tokens_in":515,"tokens_out":1655,"duration_ms":11218,"temperature":1.0,"reasoning_tokens":1584,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T08:31:18.481340+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Measure the p-bit update rate as a function of problem size N while holding DOP fixed past the synthesized range (e.g., N = 4096 or 8192 on a larger FPGA): if throughput falls proportionally to N/DOP rather than remaining near the 300 MHz limit, the pipeline is stalling and the central claim is refuted. Alternatively, run the pipelined design and a strictly sequential software PIM on the same dense instance and compare the distribution of spin configurations (or an update-order-sensitive statistic) with a statistical test; a significant difference would falsify the claimed sampling equivalence","supporting_citations":[],"review_version":1}