Skip to main content

Interview Prep & Advanced Topics

Image
By

Interview Prep & Advanced Topics


Mastering I2C Design Discussion

Part 5 of 5: SystemVerilog I2C Master Design

What You'll Learn

  1. Elevator Pitch: How to Describe Your Project
  2. Core Interview Questions
  3. Deep Dive Topics
  4. Common Interview Pitfalls
  5. Scaling to UVM
  6. Performance Optimization
  7. Series Recap & Next Steps

Elevator Pitch: How to Describe Your Project

In 60 seconds, you should be able to explain your I2C project to a hiring manager. Practice this:

Your Pitch: "I designed and verified a SystemVerilog I2C master controller with a 6-state FSM, addressing clock synchronization, open-drain simulation, and collision detection. The testbench includes 10 comprehensive test cases covering protocol fundamentals, edge cases, and error scenarios. I also modeled a slave responder to validate bidirectional communication—the design is fully self-contained and ready for EDA Playground simulation with Synopsys VCS."

Why This Works:

  • Scope is clear: Master + slave, 6 states, 10 tests—concrete numbers impress.
  • Technical depth: FSM, open-drain, collision detection—shows you understand protocol nuances.
  • Verification mindset: Testbench, test cases, edge cases—you think like a verification engineer.
  • Production-ready: Synopsys VCS, EDA Playground—you've thought about deployment.

Core Interview Questions

Here are the most common I2C questions you'll face, with model answers:

Q1: What is I2C and why is it important?
I2C (Inter-Integrated Circuit) is a synchronous, two-wire serial protocol with only SCL (clock) and SDA (data) lines. It's important because it's low-cost (only 2 wires), scalable (supports multiple masters and slaves via open-drain architecture), and widely used in embedded systems, sensors, and ASIC/FPGA testing. The open-drain design enables wired-AND arbitration, allowing multiple devices to safely share the bus.
Q2: Explain the START and STOP conditions. Why is the sequence important?
START: Master pulls SDA LOW while SCL is HIGH. This unique transition wakes all slaves and signals the start of a transaction. STOP: Master releases SDA to HIGH while SCL is HIGH. This signals end of transaction and releases the bus. The sequence is critical because any other transition could be misinterpreted—if both SCL and SDA fell simultaneously, a slave might not recognize it as a START condition.
Q3: What is the purpose of ACK/NACK, and how is it signaled?
ACK (acknowledge): Receiver pulls SDA LOW during the 9th clock pulse, confirming it received the byte and is ready for more. NACK (no acknowledge): Receiver releases SDA (leaves it HIGH during bit 9), signaling it cannot accept more data. In write transactions, only the slave can ACK/NACK; in read transactions, the master sends ACK/NACK after receiving each byte to control data flow.
Q4: How do you model pull-up resistors in simulation?
I use a wired-AND model with continuous assignments: assign scl_in = (scl_out==0) ? 0 : 1; This mimics the open-drain behavior without simulating RC charging curves. The line is LOW if ANY device pulls it; otherwise, pull-ups bring it HIGH. For timing-critical designs, I can add slew-rate modeling with a ramp function, but for functional verification, the binary model is sufficient and simulation is much faster.
Q5: Explain clock stretching. When and why does it occur?
Clock stretching happens when a slave holds SCL LOW (scl_out=0) indefinitely. The slave does this when it needs processing time before the next bit (e.g., reading from slow EEPROM). The master must wait until SCL is released before proceeding. In my design, I implemented this with a wait(scl_stable==1) condition that tolerates indefinite delays. This is critical for real-world multi-slave systems where devices have varying speeds.
Q6: What is 7-bit vs. 10-bit addressing?
7-bit addressing: First byte contains 7 address bits [7:1] + 1 R/W bit [0]. Supports 128 addresses (0x00–0x7F). 10-bit addressing: First byte is special: 5 bits [7:3]=11110, 2 address bits [1:0], R/W bit [0]. Next byte contains remaining 8 address bits. Supports 1024 addresses. My design implements 7-bit addressing, which is by far the most common in modern embedded systems.
Q7: How did you detect and handle collisions?
In my design, I monitor SDA while the master releases it (sda_out=1). If SDA_IN reads as 0 despite release, another device is pulling it—this is a collision. I set error=1 to flag it. In multi-master arbitration, the master that loses arbitration (its data differs from the bus) should stop driving and monitor bus activity. For this design, I focused on detection; full arbitration (master backing off) would require state machine extensions.

Deep Dive Topics

Multi-Master Arbitration

If two masters drive simultaneously, I2C arbitration ensures exactly one wins:

  1. Each master sends its address/data bit (sda_out)
  2. Master samples the bus (sda_in)
  3. If sda_out ≠ sda_in: Master lost arbitration; it should stop driving and listen
  4. If sda_out = sda_in: Master won; continue normally

To implement this in SystemVerilog:

// Arbitration during TX_DATA state always @(posedge scl_rising) begin if (state == TX_DATA) begin // We sent a bit; check if it matches the bus if (sda_out == 1'b0 && sda_in == 1'b1) begin // We pulled LOW, but bus is HIGH → LOST arbitration arbitration_lost <= 1'b1; // Stop driving; switch to monitoring mode sda_out <= 1'b1; scl_out <= 1'b1; end end end
Interview Talking Point: "Multi-master arbitration is elegant because it's asynchronous—no central arbiter needed. The bus itself enforces fairness. Masters with the highest priority naturally win because they drive bits first."

Timing Verification

Real silicon must meet strict timing constraints. Key parameters:

Parameter Standard (100 kHz) Fast (400 kHz) Impact
tLOW (SCL low time) 4.7 µs 1.3 µs Slave must release SCL in this time
tHIGH (SCL high time) 4.0 µs 0.6 µs Master must not pull SCL too fast
tSU:DAT (data setup) 250 ns 100 ns SDA must be stable before SCL rise
tHD:DAT (data hold) 300 ns 300 ns SDA must stay stable after SCL fall

To verify timing in simulation:

// Monitor setup time always @(posedge scl_rising) begin if (sda_changed_since_scl_fall < 250ns) begin $warning("Setup time violation: t_SU:DAT = %t", $time - sda_change_time); end end

Common Interview Pitfalls

Avoid these mistakes when discussing your project:

Mistake 1: "I just ran the simulator and got passing tests."
Better Answer: "I designed 10 focused test cases with explicit pass/fail criteria. Each test targets a specific protocol requirement—START condition timing, ACK generation, collision detection. I also reviewed waveforms to verify setup/hold times and edge transitions."
Mistake 2: "My testbench has no slave model; I just checked the outputs."
Better Answer: "I implemented a slave responder to generate ACK bits and simulate clock stretching. This lets me validate the full I2C transaction from both sides—master and slave negotiation."
Mistake 3: "I don't know if my design would work at 400 kHz; I only tested at 100 kHz."
Better Answer: "I parameterized the clock divider (CLK_DIV_100K, CLK_DIV_400K) and tested both speeds. At 400 kHz, timing margins are tighter, so I paid special attention to setup/hold violations."
Mistake 4: "I didn't think about what happens if two masters collide."
Better Answer: "I implemented collision detection by monitoring SDA changes while releasing it. If the bus doesn't match my output, I set error=1. A full multi-master system would add arbitration logic to back off gracefully."

Scaling to UVM

Your class-based testbench is a great foundation. Upgrading to UVM adds structure:

// UVM Testbench Skeleton class i2c_master_test extends uvm_test; `uvm_component_utils(i2c_master_test) i2c_env env; function new(string name, uvm_component parent); super.new(name, parent); endfunction virtual function void build_phase(uvm_phase phase); super.build_phase(phase); env = i2c_env::type_id::create("env", this); endfunction virtual task run_phase(uvm_phase phase); super.run_phase(phase); phase.raise_objection(this); // Send sequences (start, write, stop) repeat(10) env.driver.write_byte(8'hA5); phase.drop_objection(this); endtask endclass

UVM Benefits Over Class-Based TB

Feature Class-Based TB UVM
Reusability Good—components are modular Excellent—UVM base classes standardize structure
Sequence Library Manual; ad-hoc Built-in; combinatorial mixing
Scoreboarding Hand-coded per project UVM Subscriber pattern + TLM
Coverage Integration Via SystemVerilog events Unified via UVM factory
Learning Curve Fast (days) Steep (weeks)
Interview Strategy: "My current testbench is class-based and functional. I understand UVM and could migrate it if the project requires large-scale regression or multi-site validation. For this scope (10 test cases, single DUT), the simpler approach was appropriate."

Performance Optimization

Synthesis Optimizations

Goal: Reduce area/power while meeting timing at target frequency.

  • FSM Encoding: One-hot (few gates) vs. binary (compact) vs. gray (glitch-free transitions)
  • Clock Divider: Use shift register (synthesizes well) instead of counter for certain ratios
  • Synchronizers: Double-flop is minimal; 3+ flops only if metastability risk is severe
// One-hot FSM (synthesizes to smaller mux tree) typedef enum logic [5:0] { IDLE = 6'b000001, START_COND = 6'b000010, TX_DATA = 6'b000100, RX_DATA = 6'b001000, ACK_BIT = 6'b010000, STOP_COND = 6'b100000 } state_t; state_t state, next_state; always @(posedge clk or negedge rst_n) begin if (~rst_n) state <= IDLE; else state <= next_state; end

Verification Optimizations

  • Constraint random testing: Beyond hand-coded cases, generate random address/data
  • Coverage-driven verification: Identify untested code paths and generate targeted tests
  • Formal verification: Prove properties (e.g., "start_cond_req always leads to START condition within N cycles")
// Simple property-based check (SVA) property start_condition_generated; start_cond_req |=> ##[1:100] (scl_stable && ~sda_stable); endproperty assert property (start_condition_generated) else $error("START never generated");

Series Recap & Next Steps

What We Built

  • Part 1: I2C protocol fundamentals—START, STOP, ACK/NACK, addressing, timing.
  • Part 2: 6-state FSM master controller with edge detection and clock generation.
  • Part 3: Slave responder with address matching, ACK generation, and pull-up simulation.
  • Part 4: Comprehensive testbench with 10 test cases and systematic debugging.
  • Part 5: Interview prep, advanced topics, UVM scaling, and optimization strategies.

Next Steps for Your Portfolio

  1. Verify on EDA Playground: Upload design.sv and testbench.sv to edaplayground.com and confirm "ALL TESTS PASSED"
  2. Add to LinkedIn: Post a 2-3 sentence summary with the link. Tag VLSI/verification communities.
  3. Document on GitHub: Upload your project with a comprehensive README explaining each module and test.
  4. Interview Talking Points: Practice your elevator pitch. Prepare waveform screenshots showing START/STOP/ACK.
  5. Expand the Project: Add multi-master arbitration, formal property checks, or UVM testbench upgrade.

Stay Tuned for More!

On The Silicon Stack, we'll continue publishing in-depth guides on VLSI protocols, verification methodologies, and interview prep. Subscribe to be notified of:

  • SPI protocol design & verification
  • UART with parity and flow control
  • AXI4-Lite interconnect architecture
  • UVM best practices & advanced patterns
  • Formal verification with SystemVerilog assertions

About the author: Upalparna is a VLSI engineer and design verification specialist with expertise in functional verification, UVM testbenches, and protocol design. She runs The Silicon Stack, a VLSI education platform, and teaches embedded systems and semiconductor design.

Have questions or need clarification on any part of the series? Drop a comment below or reach out on LinkedIn—I'm here to help!

Series Navigation:
Part 1: Protocol Fundamentals →
Part 2: Master Controller FSM →
Part 3: Slave Responder & Pull-up Logic →
Part 4: Testbench Design & Test Cases →
Part 5: Interview Prep & Optimization (You are here)

🎉 Series Complete! 🎉
Thank you for reading. Now go build, simulate, and ace that interview!
Labels:

Comments

Post a Comment

Popular posts from this blog

Module 1 — SystemVerilog Basics

By
VLSI Verification  •  SystemVerilog Series Module 1 — SystemVerilog Basics A complete, example-driven walkthrough of SystemVerilog fundamentals: data types, variables vs nets, arrays of every flavor, strings, enums, structs, unions, and typedef — the building blocks every verification engineer needs before UVM. 🧩 Beginner → Intermediate ⏱ ~25 min read 💻 Code Examples Included 📑 Table of Contents Introduction to SystemVerilog Verilog vs SystemVerilog Data Types: 2-State vs 4-State Logic Variables and Nets Arrays: Packed vs Unpacked Dynamic Arrays Queues Associative Arrays Strings Enumerations Structures Unions Typedef 1 Introduction to SystemVerilog SystemVerilog (IEEE 1800) is a unified hardware description and verification language (HDVL). It extends Verilog (IEEE 1364) with powerful constructs for design (interfaces, always_comb/always_ff, enhanced d...
Post a Comment
Read more

GPU Memory System & Interconnect: How Data Travels Inside a Modern GPU

By
GPU Memory System & Interconnect: How Data Travels Inside a Modern GPU Modern GPUs deliver incredible computing power by processing thousands of operations simultaneously. While compute cores often receive the spotlight, the real performance of a GPU depends heavily on how efficiently data moves between memory and compute units. A GPU memory system is designed to provide extremely high bandwidth while keeping latency as low as possible. This is achieved through a collection of specialized hardware components working together, including the Memory Controller, HBM/GDDR memory, Crossbar, Network-on-Chip (NoC), DMA Engine, PCIe Interface, and NVLink. In this article, we'll explore each component in detail and understand how they collectively enable high-performance parallel computing. Why Does GPU Memory Matter? Every GPU application—from gaming and graphics rendering to AI model training and scientific simulations—requires continuous movement of enormous amounts of data. For examp...
Post a Comment
Read more

Clock Domain Crossing (CDC): A Complete Beginner's Guide to Metastability, Synchronizers & Safe Data Transfer

By
Clock Domain Crossing (CDC): A Complete Beginner's Guide to Metastability, Synchronizers & Safe Data Transfer Modern System-on-Chip (SoC) designs rarely operate with a single clock. Instead, different modules such as CPUs, GPUs, memory controllers, communication interfaces, and peripherals often run at different clock frequencies or even use completely independent clock sources . When data moves from one clock domain to another, timing uncertainty can cause serious problems such as metastability , data corruption , and unpredictable system behaviour . This challenge is known as Clock Domain Crossing (CDC) . CDC is one of the most important topics in ASIC Design , RTL Design , ASIC Verification , FPGA Design , and SoC Architecture . Every modern chip—from smartphones to automotive processors—uses CDC techniques to ensure reliable communication between multiple clock domains. In this article, we'll explore CDC fundamentals, metastability, synchronization techniques, asynchro...
Post a Comment
Read more

AXI Verification Interview Questions and Real-World Debugging

By
AMBA Protocol Series · Part 10 of 10 AXI Verification Interview Questions and Real-World Debugging Common protocol violations, how to read them off a waveform, and a curated set of interview questions with concise, correct answers — the capstone of the core 10-day series. AMBA Protocol Series: From APB & AHB to AXI — A Complete Guide for VLSI Engineers This wraps up the core 10-day series. Everything here draws directly on Days 1–9 — if any answer below feels unfamiliar, that's a good signal for which earlier post to revisit. (If you want to go further, see the 20-day extended list at the end of this post.) In This Article Common Protocol Violations Debugging From a Waveform Interview Questions and Answers Series Recap Extending the Series 1. Common Protocol Violations VALID deasserted before handshake — a source drops VALID before READY ever went high (violates the Day 8 stabi...
Post a Comment
Read more

Cache Basics and Cache Mapping Techniques

By
  Cache Basics and Cache Mapping Techniques  Modern processors execute billions of instructions every second. However, processor speed has increased much faster than main memory (RAM) speed. This difference, known as the memory wall , creates a performance bottleneck because the CPU often has to wait for data from slower memory. To solve this problem, computer systems use cache memory —a small, high-speed memory located between the CPU and the main memory. In this article, we will understand the fundamentals of cache memory, the principle of locality, cache organization, and the three major cache mapping techniques. What is Cache Memory? Cache memory is a small, high-speed memory that stores copies of frequently accessed data from the main memory. Since accessing cache is much faster than accessing RAM, the CPU first checks whether the required data is available in the cache. If the data is found in the cache, it is called a cache hit . Otherwise, the CPU fetches the dat...
Post a Comment
Read more

Timing Basics in Static Timing Analysis (STA): Delay Models, Sequential Timing, and Wire Delays

By
Timing Basics in Static Timing Analysis (STA) Static Timing Analysis (STA) is one of the most important verification techniques used in modern VLSI design. Before a chip is manufactured, engineers must verify that every signal reaches its destination within the required clock period. Even if a design passes functional simulation, it may still fail after fabrication because of timing violations. Unlike simulation, Static Timing Analysis mathematically analyzes every timing path without applying input test vectors. This makes STA significantly faster and capable of analyzing millions of timing paths efficiently. Table of Contents What is Static Timing Analysis? Why STA is Required Propagation Delay Contamination Delay Cell Delay Models Combinational Gate Delay Sequential Timing Setup Time Hold Time Wire Delay RC Delay Model PVT Corners Worked Examples Interview Questions Key Takeaways What is Static Timing Analysis? Static Ti...
Post a Comment
Read more

Computer Architecture Interview Question Part 1

By
Skip to content Computer Architecture Interview Series Part 1 · CPU Basics · RISC vs CISC · ISA 50 Most Asked Computer Architecture Interview Questions (Part 1) The foundational round every VLSI, ASIC, and CPU design interview opens with: instruction set architecture, RISC vs CISC trade-offs, Von Neumann vs Harvard design, registers, endianness, and the fetch-decode-execute cycle — explained the way interviewers actually expect you to answer.  40 Questions (Q1–Q40) ⌛ 22 min read  VLSI & Computer Architecture Interviews On this page Foundations of Computer Architecture RISC vs CISC — Core Differences Von Neumann, Harvard & the Semantic Gap Architecture Styles, Endianness & Registers ILP, VLIW, Superscalar & Amdahl's Law Register Files, Microcontrollers & the Fetch Cycle Tip...
Post a Comment
Read more