Engineering Architect, ISA & Co-Design

Why this role exists

Defining an ISA extension is not a hardware problem. It’s a hardware-software co-design problem that most silicon teams get wrong because they design instructions in isolation from the compiler that has to generate them and the workloads that have to justify them.

VRULL sits in the middle of that gap. We analyse the workloads — AI inference, training, HPC simulation, scientific computing — define the extensions, prove them in compiler backends (GCC, LLVM, MLIR), and validate them against real performance targets. All before the silicon team commits transistors. When we propose a matrix-computing extension to a RISC‑V partner, it comes with the code generation, the workload analysis across both AI and HPC, and the performance evidence. That’s not a suggestion — it’s an engineering argument.

This work happens at the frontier of what RISC‑V can do. Custom AI extensions, HPC-oriented vector operations, application-specific instructions, encoding trade-offs that balance die area against compiler exploitability. The internal teams don’t go here because the risk is too high and the expertise too cross-cutting. We go here because that’s the entire point.

What you’ll do

• Analyse AI and HPC workloads to identify where the RISC‑V ISA leaves performance unrealised — the instructions that should exist but don’t
• Define ISA extensions: encoding, semantics, interaction with existing architecture state, forward-compatibility constraints
• Prove extensions in compiler backends — write the code generation in GCC, LLVM, and MLIR that demonstrates the extension is exploitable, not just implementable
• Validate extensions against real workloads from both domains: inference kernels, training operators, stencil codes, sparse linear algebra, FFT
• Run pre-silicon simulation and performance prediction to validate extension proposals before tape-out decisions
• Drive proposals through RISC‑V International working groups — argue the technical case, build consensus, get extensions ratified
• Conduct competitive analysis against ARM, x86, and other RISC‑V implementations across AI and HPC benchmarks

What we’re looking for

• Deep understanding of at least one ISA at the microarchitectural level — not just the programmer’s model, but pipeline behaviour, encoding constraints, and state interactions
• Compiler backend experience across GCC, LLVM, or MLIR — you need to know whether an instruction is compilable, not just implementable
• Experience with workload analysis across AI and/or HPC domains and the ability to connect application behaviour to ISA gaps
• Understanding of how different languages (C/C++, Fortran, Julia) exercise ISA features differently — an extension that helps Fortran stencil codes may need different encoding trade-offs than one aimed at PyTorch operators
• Active participation in standards bodies or architecture working groups
• The ability to make a technical argument to a room of silicon architects and win

What sets you apart

• Direct experience defining or extending an ISA — proposing instructions, getting them ratified, seeing them in silicon
• RISC‑V International working group membership or contribution history
• Experience with pre-silicon simulation frameworks (Spike, QEMU, custom simulators)
• The cross-domain vision to see an instruction from the workload’s perspective, the compiler’s perspective, and the microarchitect’s perspective simultaneously — whether that workload is an AI model or an HPC simulation

We don’t review ISA proposals. We write them.