Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • Start Here5
  • SystemVerilog Language Foundations28
  • Object-Oriented SystemVerilog for Verification30
  • Constraint Randomization — Interview-Critical Deep Dive39
  • SystemVerilog Assertions — Interview-Critical Deep Dive41
  • Functional Coverage in SystemVerilog25
  • Testbench Architecture in SystemVerilog24
  • Advanced Language & Integration26
  • Senior & Interview Preparation23
    • Senior Debug Playbook
    • Reviewing Verification Code
    • Verification Strategy: Spec to Sign-Off
    • SystemVerilog Interview Q&A Bank
      • Q&A: Language Core
      • Q&A: Testbench Plumbing
      • Q&A: Classes and Interfaces
      • Q&A: Constraint and Assertion Fire-Drill
      • Q&A: Scenario and Design Questions
    • Capstone: Verify a Parameterized FIFO
  • Principal-Level Verification34
Loading lesson

←SystemVerilog Interview Q&A Bank
  1. Topics
  2. SystemVerilog
  3. Senior & Interview Preparation
  4. SystemVerilog Interview Q&A Bank
  5. Q&A: Language Core
On this page

    Part 8 of 9, lesson 13 of 23Part 8 of 9/Senior & Interview Prep/Lesson 13 of 23Intermediate

    Q&A: Language Core

    Revision: blocking versus nonblocking, four-state discipline, combinational intent, tasks and storage, as short answers with links to the lessons.

    Every answer in this bank follows one formula: direct answer first, evidence second, the edge third, and the testbench payoff last. Each question below gives the short answer and names the lesson that teaches it.

    • Direct answer: one sentence that answers exactly what was asked.

    • Evidence: the smallest code that proves it.

    • The edge: the follow-up, raised before the interviewer does.

    • So what: where it bites in a real testbench.

    One driver and four states

    Q: What is the difference between logic, wire and reg

    logic is a 4-state variable type: one continuous driver, or any number of procedural writers, but not both kinds. wire is a net that resolves many drivers, for tristate buses. reg is the legacy name logic replaces; it never implied a register.

    Taught in: Nets vs Variables.

    Q: Four-state versus two-state, when is each right

    Four-state belongs wherever a signal touches the DUT, because X is a debugging signal. Two-state is for testbench bookkeeping, but assigning X to it silently gives 0. Rule: 4-state at the DUT boundary, 2-state inside, with $isunknown guarding the crossing.

    Taught in: 4-State vs 2-State Types.

    The swap and the scheduler

    Q: Blocking versus nonblocking, why does the swap matter

    Blocking (=) executes in statement order. Nonblocking (<=) samples its right-hand side now and assigns in the NBA region. Use nonblocking in clocked logic so every block reads pre-edge values and results are deterministic.

    The classic whiteboard proof is the swap. The bench shows the nonblocking pair exchanging values while the blocking pair collapses to one value.

    design.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    module tb_swap;
      timeunit 1ns; timeprecision 1ps;
      logic clk = 0;
      always #5 clk = ~clk;
      logic a_nb = 1'b0, b_nb = 1'b1, a_b = 1'b0, b_b = 1'b1;
      int errors = 0;
      always_ff @(posedge clk) begin a_nb <= b_nb; b_nb <= a_nb; end
      always @(posedge clk) begin a_b = b_b; b_b = a_b; end
      initial begin
        @(posedge clk); #1;
        if (a_nb !== 1'b1 || b_nb !== 1'b0) errors++;   // clean swap
        if (a_b !== 1'b1 || b_b !== 1'b1) errors++;     // blocking kept itself
        @(posedge clk); #1;
        if (a_nb !== 1'b0 || b_nb !== 1'b1) errors++;   // swapped back
        if (errors == 0) $display("PASS: nonblocking swap exchanges values and blocking version collapses");
        else $fatal(1, "FAIL: swap behavior wrong");
        $finish;
      end
    endmodule

    Taught in: Blocking vs Nonblocking Assignments, The Event Scheduler & Stratified Regions.

    Combinational intent

    Q: Two combinational styles, are they the same

    No. always_comb runs once at time zero, is sensitive to signals read inside called functions, and forbids other processes from writing its outputs. always @* waits for an input change and can miss function-internal reads. An inferred latch is a warning that lint may escalate.

    Taught in: always_comb, always_ff, always_latch.

    Tasks, functions and storage

    Q: Task versus function, what is the real split

    A function runs in zero time and returns a value. A task may consume time. Anything touching the clock is a task, pure computation is a function, and both should be automatic in testbenches.

    Taught in: Tasks vs Functions.

    Q: Packed versus unpacked, what maps to what

    Packed dimensions sit before the name and form one contiguous vector, so whole-vector operations work. Unpacked dimensions sit after the name and form separate elements, the natural model for memories.

    Taught in: Packed vs Unpacked Arrays.

    Sampling DUT outputs into bit or int turns X into 0 and hides the bug. Guard with $isunknown before converting, and keep blocking assignments out of clocked blocks.

    The swap pair is the classic whiteboard proof. Write both versions, predict a == b for the blocking one, and name NBA deferral as the reason cross-block reads stay deterministic.

    Check yourself Why does the blocking swap end with a == b?

    The first line updates a immediately, so the second line reads the new a instead of the old one. Both end up holding the old b.

    Check yourself A called function reads a signal that is not an argument. Which construct stays correct, and why?

    always_comb stays correct because its sensitivity includes function-internal reads. always @* misses them and goes stale.

    Check yourself When must a testbench helper be a task rather than a function?

    When it consumes time: driving pins across clock edges or waiting for a response. Computation with no time advance belongs in a function.

    Related topics

    • Foundations: data types

    • Foundations: procedural blocks

    Previous

    231 / 275

    Next: Q&A: Testbench Plumbing

    Up next

    Up nextQ&A: Testbench Plumbing

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Q&A: Classes and Interfaces
    • Q&A: Constraint and Assertion Fire-Drill
    • Q&A: Scenario and Design Questions