On-board testing & deployment

Simulation only proves your logic is correct — the real chip can still fail from timing violations or wiring issues that simulation simply cannot see, because simulation doesn't model real-world physical delay by default, no matter how detailed your testbench is.

The discipline that saves you here is strictly incremental testing: start with one small, known-good module (a UART loopback is the classic first choice). Verify it works on real hardware. Then add pieces one at a time. When something breaks after adding a new piece, you know exactly what caused it — the piece you just added — instead of debugging an entire integrated pipeline blind, with no idea which of a dozen modules is responsible.

A practical validation loop worth setting up early: a PC-side Python script that sends test LiDAR patch data to the FPGA (over UART or PCIe), receives the extracted feature descriptors back, and compares them directly to your Python golden reference. This is the only reliable way to confirm that INT8 quantization and any CSD weight encoding produce bit-exact results on real hardware, not just "close enough in simulation."

When something does go wrong on real hardware, use the ILA (Integrated Logic Analyzer) strategically rather than everywhere at once — instrument the pipeline at module boundaries (output of the feature extractor, input to the matcher, output of the transform estimator) and confirm data integrity at each stage before drilling further into internal signals. Avoid the temptation to probe every signal simultaneously; it makes the waveform view unreadable and defeats the purpose of isolating the failure.