Everything your firmware expects to find around it: sensors that answer, loads that push back, buses that respond, and faults that arrive when the agent decides they should.
A sensor breakout on a jumper harness, a motor with a load on it, a bench supply, a logic analyzer, and a person to power-cycle the whole thing when the DUT locks up.
Augur One is that bench as one board. Your DUT board plugs in, and the world your firmware reads is generated in hardware and driven from the network.
Your DUT board carries the part under test and whatever it needs to boot. The connectors bring it everything else.
Emulating a world is two kinds of work, and they want different silicon.
| Sensor register models, bus slaves, PWM and encoder decode, fault injection, capture | Lattice ECP5 FPGA | Timing is decided in gateware, so the DUT's bus is answered at the DUT's clock |
| Plant models, closed-loop state, physics integration | STM32N657, Cortex-M55 | State advances between the DUT's samples |
| The agent, test authoring, verdicts, evidence | Your bench computer | None of it is real-time, so none of it can stall the plant |
The first two rows are Augur One. The third is a Linux machine with gigabit Ethernet that you supply: we do not sell it, and a lab that already has machines does not buy another one.
Power over Ethernet is standard, 802.3bt Type 4: one run of Cat-6 carries power and network, so a bench is a switch port. USB-C is the backup link, the recovery path, and an alternative power input when there is no PoE switch on hand.
A dedicated supervisor MCU, an STM32H563, sits on its own rail and owns recovery and DUT power. The board is built around one rule: Ethernet must not drop while something is being recovered.
Watch an agent run a task on the bench.
Neither the FPGA nor the real-time MCU has a power switch anywhere on the board, so half-powered states do not exist to get stuck in. That comes from the schematic, not from firmware discipline.
Nowhere. The agent runs on the bench computer you supply, inside your network, and your firmware source stays on it. What leaves is the run record: verdicts, captures, and the commit hash each iteration ran against.
| FPGA | Lattice ECP5 LFE5U-85F · protocol, bus capture, fault injection |
| Real-time MCU | STM32N657 · Cortex-M55 · NPU for physics acceleration |
| Supervisor | STM32H563 · recovery, DUT power |
| Wireless peer | ESP32-C5 · Wi-Fi, Bluetooth LE |
| Digital I/O | Up to 216 pins · 4 banks · 1.2–3.3 V per bank up to 200 MHz |
| Pin functions | Gateware-defined · SPI, I2C, UART, CAN, PWM, quadrature, GPIO |
| Analog from DUT | 4x 12-bit · 5 MSPS |
| Debug | SWD / JTAG · any DUT I/O pin |
| DUT supply | 1.8–5 V adjustable |
| Current sense | Dual-range · 250 µA/LSB run · 31 nA/LSB sleep |
| Ethernet to DUT | 2x 1000BASE-T · 4-pair MDI |
| USB to DUT | 2x USB 2.0 OTG · software attach/detach |
| Wireless to DUT | Wi-Fi · Bluetooth LE · scriptable link faults |
| DUT self-ID | 11x strap · revision, capability, supply select · unknown boards stay unpowered |
| Channels | Up to 40 · 10 slots x 4 · any module mix |
| High-speed DAC module | 2x AD3542R · 16 MUPS/DAC · 8 MSPS/ch · 0–5 V incl. true 0 V |
| Low-speed DAC module | DAC80504 · 200 kUPS/ch |
| Uplink | Gigabit Ethernet · PoE 802.3bt Type 4 |
| USB-C | Backup link · recovery · alternate power input |
| Form factor | 210 x 130 mm |
Interface figures are counted from the built netlist rather than a block diagram. DAC figures come from the parts named above.
Bring your board to the bench.
See the full specification Price your bench Book 15 minutes