← NVIDIA Interview Insights

NVIDIA·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say
Jun 2026

Summary

Brutal NVIDIA hardware-adjacent design interview for what was listed as a software role. The whole session was a deep dive into low-power SoC architecture, power domain crossings, and CDC schemes. Not what I expected walking in.

Questions Asked (4)

Q1

In a SoC with two independently power-gated domains A and B running at potentially different supply voltages, how do you architect a registered 1-bit control signal crossing from A to B? Walk through the required boundary cells, reset strategy at source and sink, and where each cell lives relative to always-on vs. switchable rails.

System DesignTechnical Trade-offs
Author's notes

I knew level shifters were needed and said so immediately, but I fumbled on the isolation cell placement.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying that this is a clock domain and power domain crossing, so you need synchronization, isolation, and level shifting. Then walk through the signal path from source to destination, specifying the required cells at each stage and their power domains, and finally discuss reset strategies for both domains.

Pro tip: Emphasize that the synchronizer must be in the destination domain and that isolation cells must be placed on the source side of the level shifter to prevent floating signals when the source is powered down. Also, mention that reset synchronization is crucial to avoid metastability and that the reset for the destination flops should be synchronized to the destination clock.

1. Identify domain crossing requirements

Determine that the signal crosses from power domain A to B, which may have different voltages and can be independently power-gated. This requires isolation, level shifting, and synchronization.

2. Define source-side cells

In domain A, the registered signal is launched. Add an isolation cell (clamp) on the output to hold a known value when A is powered down. If voltage differs, add a level shifter from A to B after isolation.

3. Define destination-side cells

In domain B, the signal must be synchronized to B's clock using a two-flop synchronizer (or more for high MTBF). The synchronizer flops must be on the always-on rail if B can be powered down, or on B's switchable rail if B is always on when receiving.

4. Plan reset strategy

Source reset: ensure the source flop resets to a known state. Destination reset: synchronize the reset de-assertion to B's clock and ensure the synchronizer flops are reset to a known state. Use asynchronous assert, synchronous de-assert reset synchronizers.

5. Verify power domain placement

Isolation cells and level shifters that interface with A must be powered by A's rail (or always-on if A can be off). Synchronizer flops must be powered by B's rail (or always-on if B can be off). Ensure no floating signals when either domain is off.

Key Points to Mention

  • Isolation cells to clamp the signal when source domain is powered down, preventing floating inputs to destination.
  • Level shifters to handle voltage differences between domains, placed after isolation and before synchronization.
  • Two-flop synchronizer in destination domain to mitigate metastability, with flops on the destination's power rail.
  • Reset synchronization: asynchronous assert, synchronous de-assert for both source and destination resets to ensure clean reset release.
  • Power domain placement: isolation and level shifters on the source side (or always-on), synchronizer on destination side (or always-on if destination can be off).
  • Consideration of always-on vs. switchable rails: if either domain can be powered down, the boundary cells must be on an always-on rail to maintain signal integrity.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

If domains A and B run on different clocks and the control signal has ordering requirements (so you can't just treat it as async noise), which CDC scheme do you pick between a two-flop synchronizer, pulse-to-toggle, request/ack handshake, or async FIFO, and what STA/CDC constraints do you add to go with it?

System DesignTechnical Trade-offs
Author's notes

This is where I actually felt okay.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First, clarify the ordering and data-width requirements: if the control signal is a single-bit event with ordering, a request/ack handshake is the safest choice; if it's multi-bit data with ordering, use an async FIFO. Then justify why two-flop or pulse-to-toggle are insufficient due to ordering violations, and specify the STA/CDC constraints (set_false_path, set_max_delay -datapath_only, ASYNC_REG) to ensure correct synchronization.

Pro tip: Emphasize that ordering is preserved by the handshake protocol itself, not by timing constraints; constraints only ensure metastability is contained. Also mention that for multi-bit control, you must use a FIFO or handshake with a stable data bus, never a two-flop synchronizer per bit.

1. Clarify signal characteristics

Determine if the control signal is single-bit or multi-bit, and whether it's a pulse or level. This dictates the viable CDC schemes.

2. Evaluate ordering requirements

If ordering between multiple control signals or data is required, two-flop and pulse-to-toggle cannot guarantee it; handshake or async FIFO are needed.

3. Select the CDC scheme

For single-bit ordered control, choose request/ack handshake; for multi-bit ordered data, choose async FIFO. Justify why others fail.

4. Define STA/CDC constraints

Apply set_false_path or set_max_delay -datapath_only on synchronizer paths, set ASYNC_REG on synchronizer flops, and constrain handshake/FIFO control paths appropriately.

5. Verify and document

Run CDC checks, ensure no reconvergence, and document the chosen scheme and constraints for review.

Key Points to Mention

  • Two-flop synchronizer only for single-bit level signals without ordering; it cannot preserve ordering or handle multi-bit buses.
  • Pulse-to-toggle converts a pulse to a level, but still requires handshake for ordering and is only for single-bit events.
  • Request/ack handshake provides inherent ordering by waiting for acknowledgment before next request, suitable for single-bit or narrow control.
  • Async FIFO is required for multi-bit data with ordering, using gray-coded pointers and dual-clock FIFO structure.
  • STA constraints: set_false_path or set_max_delay -datapath_only on synchronizer paths, ASYNC_REG attribute on synchronizer flops, and proper timing exceptions for handshake/FIFO control.
  • CDC verification: ensure no combinational logic between synchronizer flops, check for reconvergence, and use vendor CDC tools.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

How does your approach change if A and B share the same clock? Which constraints do you keep, which do you drop, and how do you verify timing in that case?

System DesignTechnical Trade-offs
Author's notes

Honestly a bit of a relief after the async question.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First clarify that sharing a clock eliminates clock-domain crossing (CDC) issues, so you can drop synchronization constraints and focus on intra-clock timing. Then explain how you would verify timing using static timing analysis (STA) with a single clock constraint, while still considering skew, jitter, and other intra-clock effects.

Pro tip: Emphasize that even with a shared clock, you must account for clock skew and jitter, and that proper timing constraints (like create_clock and set_clock_uncertainty) are still essential for accurate STA.

1. Clarify the scenario

Confirm that A and B are synchronous to the same clock and identify any remaining timing concerns such as skew, jitter, and combinational path delays.

2. Identify constraints to keep and drop

Drop CDC-related constraints (e.g., set_max_delay -datapath_only, set_false_path between domains) and keep setup/hold, clock uncertainty, and input/output delays relative to the shared clock.

3. Adjust timing verification methodology

Use static timing analysis (STA) with a single clock definition, ensuring all paths are analyzed for setup and hold with appropriate derating and uncertainty.

4. Consider physical effects

Account for clock skew and jitter by adding uncertainty margins, and verify that the clock tree synthesis (CTS) balances the clock to both endpoints.

5. Validate with simulation and hardware

Run gate-level simulation with timing annotations and, if possible, validate on hardware using on-chip timing monitors or oscilloscopes to confirm margins.

Key Points to Mention

  • Elimination of CDC and associated synchronization circuits (e.g., dual-flop synchronizers, FIFOs).
  • Removal of false paths and max delay constraints between A and B.
  • Retention of setup/hold checks, clock uncertainty, and input/output delays.
  • Impact of clock skew and jitter on intra-clock timing.
  • Use of static timing analysis (STA) with a single clock constraint.
  • Importance of clock tree synthesis (CTS) for balanced skew.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q4

If the signal passes through logic in domain B and feeds back into domain A, how do you close timing and CDC across both crossings? And if B can be powered off, how do you decide whether to clamp the returning signal to 0, 1, a retained last value, or high-Z? Where does the isolation logic live, what powers it, and how do you sequence the wake-up correctly? How do you verify all of this with power intent tools?

System DesignTechnical Trade-offsAdaptability & Ambiguity
Author's notes

This one wrecked me a little.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Structure your answer by first addressing the dual CDC crossings (A→B and B→A) with proper synchronization and timing closure, then discuss power domain isolation and retention strategies, and finally cover verification with UPF/CPF and simulation. Emphasize the trade-offs and the need for a holistic approach that considers both functional and power intent.

Pro tip: Mention that the isolation cell's power domain and control signal must be carefully chosen to avoid glitches during power-up/down, and that verification should include both static checks (UPF lint) and dynamic simulation with power-aware testbenches.

1. Understand the crossings and timing

Identify the two CDC paths: A→B and B→A. For each, determine the clock relationships (synchronous, asynchronous, or mesochronous) and apply appropriate synchronization (e.g., 2-flop synchronizer, handshake, or FIFO). Ensure timing closure by constraining both paths in STA, including false paths or multicycle paths as needed.

2. Decide on isolation strategy for B→A

When domain B is powered off, the returning signal must be isolated to prevent floating or contention. Choose clamp value (0, 1, or last value) based on system requirements: 0/1 for safe default, last value for retention. High-Z is rarely used for internal signals due to noise sensitivity. Consider using isolation cells with clamp values and retention flops if needed.

3. Place and power isolation logic

Isolation logic should be placed in the always-on domain (domain A) or in a separate always-on power domain, so it remains powered when B is off. The isolation control signal must also be in an always-on domain. Ensure the isolation cell's power supply is from the always-on domain to avoid glitches.

4. Sequence power-up/down and wake-up

Define a power sequence: before powering down B, assert isolation enable to clamp the B→A signal. After powering up B, wait for B's clocks and resets to stabilize, then de-assert isolation. For retention, save state before power down and restore after power up. Ensure the sequence is controlled by an always-on power management unit.

5. Verify with power intent tools

Use UPF/CPF to specify power domains, isolation, retention, and power states. Run static checks (UPF lint, domain crossing checks) and dynamic simulation with power-aware testbenches that exercise power transitions. Verify that isolation and retention behave correctly and that no glitches or contention occur.

Key Points to Mention

  • CDC synchronization techniques: 2-flop synchronizers, handshakes, asynchronous FIFOs, and the need for proper timing constraints (false paths, max delay).
  • Isolation cell types: clamp to 0, clamp to 1, clamp to last value (retention), and high-Z; trade-offs and when to use each.
  • Power domain partitioning: always-on domain for isolation logic and control, and the importance of level shifters if voltage differences exist.
  • Power sequencing: order of isolation assertion/de-assertion relative to power switches, clock/reset stabilization, and retention save/restore.
  • Verification with UPF/CPF: static checks (lint, domain crossing), dynamic simulation with power-aware testbenches, and formal verification of power intent.
  • Potential pitfalls: glitches on isolation control, metastability due to asynchronous power-up, and the need for synchronization of control signals across domains.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.