Hardware limits

Accuracy alone does not decide what you ship. A neural net that wins joint accuracy by half a percent can still be the wrong choice if it will not fit the FPGA fabric next to your real-time control stack. ARCADE therefore exposes analytical hardware columns next to accuracy so deployability enters the same conversation as discrimination quality.

What ARCADE estimates

With hardware.enabled set to true, the pipeline runs analytical resource and latency models in arcade.hardware. Typical columns include look-up tables, DSP blocks, and estimated latency under stated clock and word-length assumptions. Optional HLS4ML export and synthesis-report parsing live behind pip install -e ".[hardware]" and the hardware.run_synthesis flag. Keep synthesis off unless you intend Vivado or HLS work in that run.

hardware:
  enabled: true
  target_fpga: xc7z020
  clock_period_ns: 5.0
  run_synthesis: false

Treat the numbers as ranking aids, not bitstream guarantees. They answer a narrow question: among these methods, which are cheap enough to try on hardware next?

How to use the columns

Prefer a method on the Pareto frontier of accuracy versus LUT or latency. Reject wins that explode resources relative to a matched-filter baseline unless you already have a deployment path. Duration sweep and hardware together tell you whether shorter readout saves cycle time without forcing a heavier classifier.

Public helpers include estimate_resources, project_scalability, and explore_design_space. See the API modules autosummary for signatures.