Research Member of Technical Staff, Hardware 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 translate measured workload limits into hardware systems research. The work can cross processors, memory, controllers, interconnects, packaging boundaries, power, thermal constraints, test strategy, and hardware-software co-design, but every project begins with a written question, a commercial baseline, and a proof plan. The role must be ambitious enough to explore new systems and disciplined enough to recommend software, merchant hardware, revision, or termination when the evidence points there.

What you will own

• Translate accepted workloads, traces, failure modes, and scaling limits into quantitative hardware requirements.
• Model compute, memory capacity and bandwidth, data movement, latency, interconnect, power, thermal, reliability, and cost tradeoffs.
• Compare software changes, commercial components, architecture changes, simulation, FPGA prototypes, and physical implementation paths.
• Define hardware-software interfaces, verification plans, workloads, reference models, error budgets, resource needs, and stop conditions.
• Build or direct analytical models, simulators, RTL or FPGA experiments, and joined software-hardware test artifacts.
• Coordinate scoped work with qualified external organizations when written access, supervision, rights, safety, and publication terms are in place.

Technical territory

Computer architecture; heterogeneous compute; memory hierarchy and controllers; HBM and adjacent memory technologies; chiplet, die-to-die, substrate, interposer, and package boundaries; scale-up and scale-out interconnects; power delivery and thermal budgets; reliability, DFT, test, and fault containment; performance and economic modeling; reference software; simulation, RTL, FPGA, emulation, physical-design interfaces, and silicon bring-up. The public role covers the problem space, not a confidential implementation or committed product.

Representative outputs

• A workload-derived requirement packet covering compute, memory capacity and bandwidth, data movement, latency, interconnect, power, thermal, reliability, test, cost, and kill conditions.
• A comparator study across software changes, commercial components, architecture alternatives, simulation, FPGA prototypes, and physical implementation paths.
• Reference models, simulators, interface specifications, verification plans, error budgets, and traceable assumptions with named evidence states.
• A qualification and transfer packet that tells design, software, verification, packaging, test, manufacturing, and external collaborators what must be proved next.

What success looks like

• A measured workload limit becomes a versioned requirement packet with comparators and kill conditions.
• The research separates claims supported by source, model, simulation, FPGA, and measured device evidence.
• External work has named owners, interfaces, acceptance tests, rights, and an integration path.
• The company knows whether to improve software, use commercial hardware, continue research, or stop.

What you bring

• Advanced training or equivalent experience in computer architecture, electrical engineering, or hardware systems.
• Experience with architecture analysis, performance modeling, RTL, verification, FPGA, memory systems, interconnects, DFT/test, or package-level design.
• Ability to translate application and software behavior into quantitative hardware requirements.
• Ability to separate analytical models, simulation, prototypes, and measured hardware proof.
• Understanding of verification, test, power, thermal, reliability, and economic constraints.
• Clear technical writing across software, hardware, research, partner, and business audiences.

Helpful experience

• HBM, memory controllers, and interconnects
• Chiplets, die-to-die links, advanced packaging, and test
• FPGA, emulation, and driver integration
• Physical design, DFT, or silicon bring-up
• Research program ownership and external technical transfer

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.