Member of Technical Staff, FPGA and Driver Systems

Why this work matters

Touchdown starts with people doing real work: teach the team, build one useful AI system, manage what runs, and measure what still breaks. We follow repeated limits through software, inference, kernels, memory, hardware, materials, and manufacturing research only when the evidence earns the next layer. The ambition is broad. The work is always bounded by a user, a test, and a receipt.

Overview

You will work at the boundary between software and programmable hardware. The focus is a testable path from a host application and runtime through drivers, control interfaces, firmware, RTL or HLS, memory movement, and device-level evidence. FPGA work is used to answer a bounded systems question before a more expensive physical commitment, not to create an impressive board demo without a workload or verification plan.

What you will own

• Translate workload and architecture requirements into host, driver, firmware, RTL, memory, and interface contracts.
• Build host software, Linux drivers, firmware, FPGA logic, and test infrastructure for bounded systems questions.
• Define command, control, DMA, memory-coherency, telemetry, reset, update, and failure behavior.
• Create simulation, emulation, verification, synthesis, timing, bring-up, and performance test plans.
• Integrate the programmable path with representative software and measure the end-to-end effect.
• Document what the prototype proves, what remains analytical or simulated, and the next qualification gate.

Technical territory

PCIe and related host interfaces; DMA and memory systems; Linux kernel and user-space drivers; firmware and embedded control; Verilog/SystemVerilog or HLS; AXI and on-chip fabrics; simulation and formal or constrained-random verification; FPGA toolchains; timing closure; board bring-up; telemetry, fault handling, and reproducible host-to-device tests.

Representative outputs

• A versioned host, driver, firmware, register, command, DMA, memory, telemetry, reset, and update interface specification.
• Simulation and verification artifacts with reference models, assertions, coverage, expected failures, and reproducible regressions.
• A synthesized and timed FPGA image or a documented stop decision, plus resource, timing, power, and interface evidence.
• A host-to-device demonstration on the representative workload with measured data movement, latency, throughput, recovery, and limitations.

What success looks like

• The host-to-device contract is versioned, testable, observable, and recoverable after failure.
• Simulation, FPGA measurements, and analytical assumptions are clearly separated.
• The prototype answers the named performance, control, or memory question on a representative workload.
• The team has a defensible go, revise, use-merchant-hardware, or stop decision.

What you bring

• Experience with FPGA development, device drivers, embedded systems, or hardware interfaces.
• Strong debugging across software and hardware boundaries.
• Understanding of buses, DMA, memory ordering or coherency, timing, and verification.
• Experience with Linux, C/C++, RTL or HLS, and at least one FPGA toolchain.
• Ability to create reproducible simulation, bring-up, and performance artifacts.
• Ability to define safe failure, reset, update, and rollback paths.

Helpful experience

• PCIe, CXL, or high-speed interfaces
• Formal verification or UVM
• Memory controllers and accelerators
• Board design and signal integrity
• Compiler or runtime integration

How the role works

• Full-time role.
• San Francisco / Bay Area preferred. Remote within the United States may be considered for the right person.
• Scope, start date, and employment details are discussed during the process.