ARM RISC-V Chip Developer Interview: ISA, Processor Microarchitecture, and Toolchain

Background

I have a bachelor's in Computer Architecture and a master's focused on Processor Design. After graduation, I spent 2 years as a RISC-V development engineer at a chip company, primarily working on RISC-V ISA extensions, processor microarchitecture design, and toolchain adaptation. T-Head is the core driver of China's RISC-V ecosystem, so when I saw they were hiring RISC-V chip developers, I applied without hesitation.

Honestly, while RISC-V is very hot, few people have real hands-on experience. I'd participated in a RISC-V processor project built from scratch — from ISA definition to microarchitecture design to FPGA verification — so I had some confidence. About a week later, HR contacted me to schedule three technical rounds.

Interview Process Review

Round 1: RISC-V ISA + Assembly (~1 hour)

Round 1 was with a young engineer who also worked on RISC-V development. After a self-introduction, they started asking ISA-related questions.

RISC-V ISA Section:

The first question energized me — "Explain RISC-V's design philosophy and how it compares to ARM and x86." I said RISC-V's philosophy is modularity and extensibility, with only 40+ base instructions, using extensions to support different application scenarios. It's more open than ARM and more streamlined than x86. The interviewer followed up with "What's RISC-V's privilege architecture?" I explained the M, S, and U privilege levels and their corresponding CSRs and exception handling mechanisms.

Then instruction encoding — "What are RISC-V's instruction encoding formats? Why are they designed this way?" I listed the R, I, S, B, U, and J formats, explaining that this design simplifies instruction decoding and all instructions are fixed 32-bit (except compressed instructions). The interviewer followed up with "What's the encoding format for compressed instructions (RVC)?" I explained RVC uses 16-bit encoding, with low bits distinguishing between 16-bit and 32-bit instructions.

Next came ISA extensions — "Which RISC-V extensions are you familiar with? How do you create custom extensions?" I listed common extensions like M (multiply/divide), A (atomic), F/D (floating-point), C (compressed), V (vector), then described the custom extension process — from instruction encoding space allocation to instruction definition to toolchain support. The interviewer followed up with "How do you choose the encoding space for custom extensions?" I said to avoid conflicts with standard extensions, typically using the custom-0 to custom-3 encoding space.

Memory model came up — "What's RISC-V's memory model? What are the core rules of RVWMO?" I explained that RISC-V uses RVWMO (RISC-V Weak Memory Ordering), a weakly ordered model. Core rules include preserving program order, synchronization instruction ordering rules, and address dependencies. The interviewer followed up with "What's the purpose of the fence instruction and what do its parameters mean?"

Assembly Section:

The interviewer had me hand-write assembly code — implementing a simple memcpy function. I wrote loop-based load/store code using ld/sd instructions and a loop counter. The interviewer asked me to optimize it, so I used loop unrolling and aligned access. They also asked "What's the function calling convention? Which registers are caller-saved and which are callee-saved?" I explained according to the RISC-V ABI.

At the end of Round 1, the interviewer said "good grasp of the ISA" and told me to wait for Round 2.

Round 2: Processor Microarchitecture + Pipeline (~1.5 hours)

Round 2 was with a senior architect, and the questions were noticeably deeper.

It opened with a core question — "Describe the microarchitecture of the processor you designed, focusing on the pipeline structure." I described my 5-stage in-order pipeline, walking through Fetch, Decode, Execute, Memory, and Writeback. The interviewer followed up with "How do you handle data hazards in the pipeline?" I explained the forwarding network design and that load-use hazards require a one-cycle stall. They followed up with "How many forwarding paths are there? How do you verify forwarding correctness?"

Then branch prediction — "What are the types and principles of branch predictors? Which one did you use?" I covered static prediction, 2-bit saturating counters, global history predictors, and TAGE predictors. I used a 2-bit saturating counter plus BTB scheme. The interviewer followed up with "What's the structure of BTB? How do you handle BTB alias problems?"

Next came cache design — "What are the cache mapping methods? Which did you use?" I described direct-mapped, set-associative, and fully-associative, and said I used 4-way set-associative. The interviewer followed up with "What cache replacement policies exist? How do you approximate LRU?" I covered LRU, PLRU, and Random, explaining that PLRU uses 1-bit pairs to approximate LRU.

TLB came up — "What's the purpose of TLB? How do you handle TLB misses?" I explained TLB is a cache for virtual-to-physical address translation, and TLB misses require page table walks. The interviewer followed up with "What's the common TLB structure? How do you handle TLB alias and homonym problems?"

Round 2 also included a deep question — "If you were to design an out-of-order execution processor, how would you approach it?" I covered the issue queue, reorder buffer (ROB), register renaming, and load/store queue. The interviewer followed up with "What's the principle of register renaming? How do you handle WAW and WAR hazards?"

At the end of Round 2, the interviewer said "good microarchitecture understanding, but out-of-order execution experience needs accumulation" — a fair assessment.

Round 3: Toolchain + Project Deep Dive (~1.5 hours)

Round 3 was with the department's technical lead, focusing more on toolchain and ecosystem.

First, they asked me to describe the RISC-V toolchain components and adaptation process. I covered GCC/LLVM compiler backend adaptation, binutils toolchain, QEMU emulator, and OpenOCD debugger. The interviewer followed up with "If you add a custom instruction, what toolchain modifications are needed?" I detailed GCC backend instruction definition and pattern matching, assembler instruction encoding, linker script adaptation, and QEMU instruction simulation.

Then verification methods — "What processor verification methods exist? Which did you use?" I covered ISS comparison, random instruction generation, formal verification, and FPGA prototyping. I used ISS comparison plus random instruction generation. The interviewer followed up with "How do you ensure coverage with random instruction generation?"

Debugging came up — "What's RISC-V's debug architecture? What's the relationship between JTAG and Debug Module?" I explained that RISC-V debugging accesses the Debug Module through JTAG, and the Debug Module can control processor execution and access registers and memory. The interviewer followed up with "How do you implement breakpoint debugging?"

Finally, several open-ended questions — "What's your take on the current state of RISC-V ecosystem development?" and "What's the biggest obstacle for RISC-V to truly challenge ARM?" I said the biggest shortfalls are software ecosystem and IP maturity, but openness and flexibility are long-term advantages. The interviewer followed up with "In which domains do you think RISC-V has the best chance of breaking through first?"

About 5 days after Round 3, HR notified me that I passed. Overall, T-Head's interviews heavily emphasize RISC-V professional depth, with very detailed questions.

Key Questions Summary

RISC-V ISA:

1. RISC-V design philosophy compared to ARM/x86

2. RISC-V privilege architecture and CSRs

3. Instruction encoding formats and design rationale

4. RVC compressed instruction encoding

5. Common extensions and custom extension process

6. RVWMO memory model and fence instruction

Assembly:

7. RISC-V function calling convention

8. Caller-saved and callee-saved registers

Processor Microarchitecture:

9. 5-stage pipeline structure and data hazard handling

10. Forwarding network design and verification

11. Branch predictor types and BTB structure

12. Cache mapping methods and replacement policies

13. PLRU approximate implementation

14. TLB structure and alias/homonym problems

15. Out-of-order execution processor design

16. Register renaming and WAW/WAR hazards

Toolchain & Ecosystem:

17. Custom instruction toolchain adaptation

18. Processor verification methods

19. Random instruction generation coverage assurance

20. RISC-V debug architecture

21. Hardware and software breakpoints

Key Takeaways

1. Know the ISA inside and out. T-Head's interviews have extremely high RISC-V ISA requirements — knowing concepts isn't enough; you need to explain encoding formats, privilege architecture, and memory models in detail. I recommend carefully reading the RISC-V Spec, especially the Privileged Architecture section.

2. Have hands-on microarchitecture experience. Interviewers will dig deep into your processor design, from pipeline to branch prediction to cache — every detail could be probed. I recommend completing at least one full processor design project.

3. Toolchain adaptation is a bonus. Many RISC-V practitioners only focus on the ISA and microarchitecture, with limited toolchain knowledge. Being able to explain GCC backend adaptation and QEMU simulation will significantly boost your chances.

4. Understand the RISC-V ecosystem. Interviewers will ask ecosystem-related questions. Knowing about RISC-V International, various RISC-V IP vendors, and open-source processor projects will earn bonus points.

5. Stay current with industry developments. The RISC-V field evolves rapidly, and interviewers will ask about frontier topics like vector extensions, trusted execution environments, and Chiplets. Keep up with RISC-V Summit and industry news.

FAQ

Q: Does T-Head require high RISC-V experience?

A: Very high. As the core driver of the RISC-V ecosystem, T-Head's interviewers have deep RISC-V understanding. If your knowledge is only surface-level, it's very difficult to pass.

Q: Can you pass without processor design experience?

A: It's difficult. You need at least module-level design experience. If you only have ISA knowledge, I recommend building a RISC-V processor project first.

Q: Do they ask you to write code on the spot?

A: Yes. Round 1 had me hand-write assembly code; Round 2 required drawing a pipeline structure diagram and writing forwarding logic pseudocode.

Q: What's the work intensity like?

A: T-Head's work intensity is above average in the chip industry. Overtime happens during tight projects, but the overall atmosphere is decent.

Q: How's the compensation?

A: T-Head's compensation is at the top level in the RISC-V space. With Alibaba's stock and benefits, the overall package is very competitive.