NVIDIA ASIC Verification Engineer Interview: UVM, SystemVerilog, and Verification Methodology

Background

Let me start with my background. I have a bachelor's degree in Microelectronics and a master's focused on Digital IC Design. After graduation, I spent 3 years as a verification engineer at a mid-size chip company, mainly working with UVM and SystemVerilog for module-level and system-level verification, including SoC verification projects. Honestly, HiSilicon has always been my dream company, so when I saw the chip verification engineer position open, I applied without hesitation.

About two weeks after submitting my application, HR called to schedule interviews — three technical rounds plus one HR round. I was both excited and nervous, knowing HiSilicon's reputation for tough interviews. I spent a week systematically reviewing SystemVerilog, UVM, and verification methodology, and organized key points from my past projects.

Interview Process Review

Round 1: SystemVerilog + UVM Fundamentals (~1 hour)

Two senior engineers conducted the first round. They started with a self-introduction, then dove right into fundamentals.

SystemVerilog Section:

The first question caught me off guard — "Explain the differences between class and struct in SystemVerilog, and their respective use cases in verification." I handled this reasonably well: classes support inheritance and polymorphism, making them ideal for building verification frameworks; structs are lighter and better for data packaging and passing. The interviewer followed up on virtual class and parameterized class use cases, and I used uvm_object as an example.

Next came OOP core concepts — how encapsulation, inheritance, and polymorphism manifest in verification. I discussed the UVM component and object inheritance hierarchy and how the factory mechanism implements polymorphism. The interviewer seemed satisfied and nodded.

Then constraints and randomization — "What's the difference between randomize with and randomize? What's the execution order of pre_randomize and post_randomize?" I answered fluently and gave an example of using pre_randomize for weight control.

Coverage questions followed — differences between function coverage and assertion coverage, the relationship between covergroup and coverpoint, and how to use cross coverage. Having practical experience with these, I answered naturally.

UVM Section:

The first UVM question was about the phase mechanism — "How does the UVM phase mechanism work? Which phases are top-down and which are bottom-up?" I drew a phase execution diagram, walking through from build_phase to report_phase. The interviewer followed up on the relationship between run_phase and task phases, and I explained that run_phase and dynamic phases execute in parallel. They said "basically correct."

Then the factory mechanism — "What's the purpose of the UVM factory? What are the different override methods?" I detailed type_override and instance_override, and how the create method instantiates objects through the factory. They also asked about factory debugging, and I mentioned factory.print() and +UVM_VERBOSITY options.

The sequence-sequencer relationship was a must-ask. "How does a sequence send transactions to a sequencer? How does a sequencer distribute transactions to a driver?" I walked through the entire flow from sequence's start task to sequencer's arbitration mechanism to driver's get_next_item/item_done handshake.

Finally, TLM communication — "What's the difference between uvm_analysis_port and uvm_blocking_transport_port?" I explained the one-to-many versus one-to-one distinction and the various TLM communication modes.

At the end of Round 1, the interviewer said "solid fundamentals" and told me to wait for the second round. Overall, Round 1 focused on breadth — detailed but not extremely deep.

Round 2: Verification Methodology + Coverage (~1.5 hours)

Round 2 was with a more senior technical leader, and the questions were noticeably deeper.

It opened with an open-ended question — "What do you think a complete verification plan should include?" I covered verification planning, test case strategy, coverage modeling, check mechanisms, and regression strategy. The interviewer probed each point for details — how to write a verification plan, how to set coverage targets, what levels of check mechanisms exist.

Then we went deep into coverage — "What's the difference between functional coverage and code coverage? If code coverage is high but functional coverage is low, what does that indicate?" I explained that high code coverage only means code was executed, not that functionality was correctly verified; low functional coverage means many functional scenarios remain uncovered. The interviewer followed up with "What about the reverse — high functional coverage but low code coverage?" I thought for a moment and suggested it might indicate dead code or redundant logic paths. They said "that's a reasonable interpretation."

Next came assertions — "What's the difference between sequence and property in SVA? What's the difference between |-> and |=>?" I answered quickly: sequence is a condition sequence, property is an attribute description; |-> matches in the same clock cycle, |=> matches in the next. They also asked about disable iff and assume — I didn't answer the assume part well, only mentioning the difference from assert. The interviewer supplemented that assume is used to constrain input behavior.

On verification methodology, they asked about "the evolution and characteristics of VMM, UVM, and OVM." I started with OVM, explained how UVM unified the strengths of VMM and OVM, and the improvements in UVM 1.2 over 1.1. They also asked "What do you think are UVM's shortcomings?" Drawing from project experience, I mentioned the steep learning curve, debugging difficulties, and sometimes lower simulation efficiency compared to C++ verification environments. The interviewer seemed to appreciate these points.

A very practical question followed — "If your verification environment takes 8 hours for one regression run, how would you optimize it?" I discussed reducing redundant tests, optimizing random seeds, parallel simulation, and incremental compilation. They followed up with "How do you determine which tests are redundant?" I suggested analyzing coverage data to identify tests with low coverage contribution.

At the end of Round 2, the interviewer said "good analytical thinking," which made me feel optimistic.

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

Round 3 was with a department manager-level interviewer, focusing more on practical project experience and systems thinking.

First, they asked me to detail a verification project I'd worked on. I chose a PCIe Controller verification project, walking through the verification architecture design, test plan formulation, coverage model construction, and bug discovery process. The interviewer interrupted at each stage to probe further — "Why did you design the architecture this way? Did you consider alternatives? How was this bug discovered? Why didn't previous tests cover it?"

Then SoC verification questions — "What's the biggest difference between SoC-level and module-level verification?" I explained that SoC verification focuses more on inter-module interactions, bus protocol correctness, interrupt handling, and clock domain crossing. They followed up on "How do you verify cross-clock-domain designs?" I discussed CDC checking tools and asynchronous FIFO verification methods.

Formal verification came up — "What are the respective use cases for formal verification and simulation-based verification?" I said formal is suitable for mathematically provable small modules, while simulation is better for large-scale system-level verification. They asked "Which formal tools have you used?" I honestly said I'd only used Jasper for simple assertion proofs and didn't have extensive experience.

Finally, several open-ended questions — "What impact do you think AI will have on the chip verification industry?" and "How do you see RISC-V changing verification work?" I shared my views based on industry trends. The interviewer didn't judge right or wrong but kept probing for details, which felt like testing depth of thought.

About three days after Round 3, HR called to say I passed and scheduled the HR round. The HR round was standard — salary expectations, career planning, nothing special.

Key Questions Summary

SystemVerilog:

1. Differences between class and struct and their use cases

2. Use cases for virtual class and parameterized class

3. How OOP's three pillars manifest in verification

4. Differences between randomize with and randomize

5. Execution order of pre_randomize and post_randomize

6. Differences between function coverage and assertion coverage

7. Usage of covergroup, coverpoint, and cross coverage

UVM:

8. Phase mechanism and execution order

9. Relationship between run_phase and task phases

10. Factory mechanism and override methods

11. Sequence-sequencer-driver interaction flow

12. TLM communication modes and port types

13. Callback mechanism use cases

Verification Methodology:

14. Components of a complete verification plan

15. Relationship between functional coverage and code coverage

16. Differences between sequence, property, |->, and |=> in SVA

17. Evolution of VMM/UVM/OVM

18. Regression optimization strategies

SoC Verification:

19. Differences between SoC-level and module-level verification

20. Cross-clock-domain verification methods

21. Use cases for formal verification vs. simulation

Key Takeaways

1. Build a solid foundation. HiSilicon interviews heavily emphasize fundamentals. Every detail of SystemVerilog and UVM could be asked. I recommend thoroughly reviewing the IEEE 1800 standard and UVM Class Reference, not just training materials.

2. Be able to articulate your project experience clearly. Interviewers will mine your project descriptions for questions. Prepare the design rationale, challenges encountered, and solutions for each project. Ideally, draw architecture diagrams on a whiteboard during the interview.

3. Develop systems thinking. The three rounds have different emphases — Round 1 tests breadth, Round 2 tests depth, Round 3 tests height. By Round 3, interviewers care more about whether you can think from a system perspective, not just write testbenches.

4. Honesty matters. If you don't know something, say so. I admitted my limited formal verification experience, and the interviewer appreciated the honesty.

5. Stay current with industry trends. Round 3 includes open-ended questions. Having your own perspective on industry trends will earn bonus points.

FAQ

Q: Is English proficiency required for HiSilicon interviews?

A: Technical rounds don't test English directly, but documentation and specifications are in English, so reading proficiency is necessary. The HR round might include brief English conversation.

Q: How long is the interview process?

A: From application to offer took about 1.5 months. Each round was spaced 1-2 weeks apart, so the overall pace isn't too fast.

Q: Can you pass without UVM project experience?

A: It's difficult. HiSilicon verification positions generally require hands-on UVM experience. If you only have SystemVerilog experience, I'd suggest building a small UVM project first.

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

A: Yes. Round 1 had me hand-write a simple sequence and scoreboard; Round 2 required writing an SVA assertion. Practice whiteboard coding beforehand.

Q: How's the compensation?

A: HiSilicon's compensation is above average in the chip industry, depending on level and negotiation. They also offer signing bonuses and stock, making the overall package quite competitive.