Work through this ASIC design-verification interview set. Use small SystemVerilog examples where they make an answer clearer, and distinguish simulation semantics from synthesizable hardware behavior. ### Part 1: SystemVerilog Scheduling, Interfaces, and OOP Explain blocking versus nonblocking assignments and why combinational and sequential logic normally use different forms. Compare `always_comb` with `always @(*)`, including time-zero behavior and tool checks. Explain virtual interfaces and clocking blocks. Then discuss polymorphism, virtual methods, safe upcasting and downcasting with `$cast`, an expression that sets or clears one selected bit, and an algorithm for counting set bits in a 32-bit value. #### What This Part Should Cover - Event-region and old-versus-new value reasoning - Single-driver and sensitivity semantics of `always_comb` - Why class objects refer to static interfaces through virtual handles - Race avoidance with clocking-block sampling and driving - Dynamic type safety and useful bit-manipulation idioms ### Part 2: UVM Lifecycle and Communication Describe the order and purpose of build, connect, end-of-elaboration, start-of-simulation, run, extract, check, and report phases. Identify phase traversal direction and which phase consumes simulation time. Compare type and instance factory overrides, explain when creation observes an override, describe the sequencer-driver `get_next_item` and `item_done` handshake, explain monitor-to-scoreboard analysis broadcasts, and contrast a UVM component with a UVM object. #### What This Part Should Cover - Phase ordering and function-versus-task behavior - Top-down and bottom-up construction semantics - Factory creation rather than direct construction - Blocking transaction ownership and nonblocking analysis fan-out - Hierarchy and long lifetime versus lightweight transient data ### Part 3: Random Constraints Write or outline constraints for a nonzero one-hot value without `$onehot`, every consecutive window of five array elements being unique, and a strictly increasing array whose adjacent elements differ by at least two. Discuss empty and short arrays, signedness, arithmetic overflow, and solver cost. #### What This Part Should Cover - Correct one-hot treatment of zero - `foreach` bounds that avoid invalid indices - Pairwise or `unique` constraints on each valid window - Monotonic constraints with a safe numeric domain ### Part 4: CDC, FIFO Sizing, Timing, and Clock Division Explain a two-stage synchronizer for a single-bit level and the factors in an MTBF model. Explain why an unsynchronized multi-bit bus is unsafe and when to use a handshake or asynchronous FIFO. Given burst length, write and read rates, startup latency, and efficiency, derive a method for minimum FIFO-depth calculation rather than quoting one universal formula. Explain setup and hold constraints and common fixes. Finally, outline even and odd clock dividers, including what is required for a nominal 50 percent duty cycle on an odd divide. #### What This Part Should Cover - Metastability containment rather than elimination - Coherent data transfer across unrelated clocks - Worst-case backlog as cumulative arrivals minus departures - Why hold repair differs from setup repair - Both clock edges or another explicit technique for odd division ### Part 5: Cache and Pipeline Architecture Explain the purpose and main state transitions of a snooping coherence protocol such as MESI, and note what the owner state adds in MOESI. Compare inclusive and exclusive cache hierarchies. Given address width, capacity, line size, and associativity, derive offset, index, and tag bits. Finally, distinguish structural, data, and control hazards and describe appropriate mitigations. #### What This Part Should Cover - State ownership, sharing, invalidation, and writeback - Inclusion policy trade-offs - Set-count arithmetic rather than memorized formulas - Forwarding, stalls, renaming, prediction, and resource duplication in context ### What a Strong Answer Covers A strong answer reasons from language scheduling, memory ownership, clock-domain boundaries, and architecture invariants. It states assumptions, avoids absolute claims that depend on a particular simulator or microarchitecture, and uses formulas only after defining every term. ### Follow-up Questions - How would you verify an asynchronous FIFO around pointer wraparound? - When can a nonblocking assignment in combinational code create surprising delta-cycle behavior? - How would an exclusive last-level cache change eviction traffic? - Which of these properties are best checked with assertions rather than directed tests?