# 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.

```yaml
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 {doc}`../reference/api/index` autosummary
for signatures.