Skip to main content

Hardware selection guide: from requirements to solution

· 3 min read

Selecting the right hardware platform is a multi-dimensional decision that balances performance, power, I/O, lifecycle, and ecosystem support. This long-form guide turns those dimensions into a repeatable evaluation workflow, with practical checkpoints and links to the project's docs where you can find validated hardware pages, BSP build instructions, and flashing guides.

Key sections:

  1. Define workload and performance targets
  • Quantify the workload: expected throughput, latency requirements, model size (for ML workloads), and concurrency. For example, a multi-camera vision pipeline needs both sustained memory bandwidth and inference acceleration; an industrial gateway emphasizes deterministic networking and low-power sleep modes.
  • Translate workload into measurable targets: CPU core count and frequency, GPU/accelerator peak TOPS, memory bandwidth, and storage IOPS. Use simple benchmarks (kernel compile, ffmpeg transcode, or representative inference runs) to produce baseline numbers.
  1. I/O and peripheral mapping
  • Create an I/O matrix listing required interfaces (Ethernet, Wi-Fi, USB, MIPI-CSI, PCIe, CAN, serial) and minimum bandwidth/latency expectations.
  • Check the docs hardware pages for validated peripheral mappings and known limitations (e.g., shared buses or muxed pins). Link recommended pages from /docs/latest/hardware/ to confirm connector and power details.
  1. Power, thermal, and environmental requirements
  • Determine the target operating temperature, expected ambient range, and power budget. For fanless systems, thermal headroom is critical; consult the hardware validation pages under /docs/latest/formfactor/ or the specific board page for thermal guidance.
  • Assess whether the platform supports power domains, DVFS, and suspend modes needed for your use case.
  1. Software and BSP maturity
  • Review the BSP and official Yocto layers referenced in the docs. Prefer platforms with up-to-date BSPs and documented JetPack/Yocto integration (see /docs/latest/bsp/ and /docs/latest/jetpack-* pages).
  • Check release cadence, kernel versions supported, and whether secure boot, OTA, and vendor SDKs are documented.
  1. Long-term availability and supply chain
  • Verify product lifecycle and long-term availability commitments from the vendor. The docs hardware pages often list ordering codes and SKU information—use those to cross-check supply timelines.
  • Plan for second-source or similar hardware strategies if your product requires multi-year availability.
  1. Security and compliance
  • Confirm supported secure boot options, trusted execution environments, and documented patch processes in BSP docs. Ensure the vendor provides security bulletins or CVE-tracking for their BSPs.
  1. Validation plan and CI
  • Define a hardware validation checklist mapped to the docs' flashing and test instructions: boot, network, peripheral sanity checks, stress and soak tests. Automate smoke tests where possible and record image hashes and test outputs.

Practical workflow example

  • Step 1: Create a one-page requirements spec (compute, I/O, environment, lifecycle).
  • Step 2: Shortlist 2–3 candidate boards from /docs/latest/hardware/* that match the spec.
  • Step 3: For each candidate, perform a quick evaluation: flash a validated image (follow the board's doc), run representative workloads, and capture power/temperature metrics.
  • Step 4: Compare results against targets, document trade-offs, and choose a primary and fallback board.

References

  • Consult the project's docs hardware and BSP sections under /docs/latest/ for per-board validation steps, BSP pages, and JetPack/Yocto integration notes. If you want, I can add direct links to specific board pages and example commands for flashing and benchmarking.

Evaluation dimensions​

  • Compute and accelerators (GPU/NPU/DSP)
  • Data pipeline (interfaces and bandwidth)
  • Environmental robustness and reliability (temperature, vibration, EMC)