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

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • RTL Foundations36
  • Combinational Design25
  • Sequential Design27
  • FSM & Control27
  • Timing & Clocking39
  • Reset & CDC34
  • Memory & Buses57
  • Advanced RTL28
  • Senior & Interview76
    • Low-Power RTL Hub
    • DFT and Scan Hub
    • Physical Awareness Hub
    • Waveform Debug Hub
      • Debug hierarchy before touching code
      • Controlled dumps and trigger capture
      • Waveform bug patterns: latch and race
      • Handshake protocol violation
    • STA and ECO Hub
    • RTL-to-Implementation Closure
    • DFT-Ready RTL
    • Capstone: Resilient Streaming Peripheral
    • Principal Design Review
    • Senior RTL Interview Questions & Model Answers
  • Glossary and Notation
Loading lesson

‹Waveform Debug Hub
  1. Topics
  2. RTL Design
  3. Senior & Interview
  4. Waveform Debug Hub
  5. Handshake protocol violation

Part 9 · Senior · Senior

Handshake protocol violation

The valid/ready stability rule, a payload-change violation on the wave, and a monitor that catches it.

On this page

    Why this matters

    A source can hold valid high and still corrupt the transfer by changing data under it. Checking only valid stability catches half the rule.

    After this lesson you can: state the valid/ready stability rule, write both assertions, and build a monitor that counts violations.

    The valid/ready contract

    A transfer happens when valid and ready are high together. The source owns valid and the payload, and the sink owns ready.

    Rule

    Meaning

    Valid waits for ready

    Once asserted, valid stays high until a handshake.

    Payload waits with valid

    Data stays stable while valid is high and ready is low.

    Ready may fall anytime

    The sink can delay acceptance. The source tolerates the wait.

    The stability rule

    Two assertions state the rule. They sit in a snippet so the bench runs on simulators without concurrent-assertion support (for example Icarus). The testbench below checks the same conditions procedurally.

    design.sv
    1
    2
    3
    4
    5
    // snippet
    `timescale 1ns/1ps
    // Stable-payload rules for a valid/ready source (checked procedurally in the testbench):
    // assert property (@(posedge clk) valid_o && !ready_i |=> valid_o);
    // assert property (@(posedge clk) valid_o && !ready_i |=> $stable(data_o));

    Watch data against valid and ready. The payload changes while the first offer is still waiting.

    • Slot 1: idle: valid is 0 and data is 0.

    • Slot 2: the source offers a5 with valid high and ready low.

    • Slot 3: ready is still low and the offer holds.

    • Slot 4: data changes to 3c while ready is still low: the violation.

    • Slot 5: ready rises and the transfer completes with the wrong payload.

    • Slot 6: valid drops and the bus is idle.

    A monitor that catches it

    The testbench samples the previous cycle and flags any change under valid without ready. It counts exactly one violation for the wave above, then proves a fixed source transfers two payloads cleanly.

    Common pitfall

    Checking only valid stability misses half the rule. A source can hold valid high and still corrupt the transfer by changing data underneath it. Both assertions above are needed.

    Interview

    “What must a valid/ready source guarantee?” Valid stays asserted until the handshake, and the payload stays stable while valid waits for ready. The monitor quotes both assertions.

    Check yourself Valid is high, ready is low, and data changes. Which rule fires, and what does the sink receive?

    The $stable(data) rule fires. When ready rises later, the sink receives the new data, and the original payload is lost.

    Check yourself A source deasserts valid immediately after its accepting clock edge and has no next payload. Is that legal?

    Yes. The accepted offer retires on that edge, and the following cycle is idle. Keeping the old offer asserted through another ready-high edge would accept a duplicate; the fixed source below clears valid on acceptance.

    Testbench

    A violating driver and a fixed two-item source. Acceptance is sampled before register updates. The fixed source is checked with continuous READY, isolated READY pulses and a long initial stall, so an extra accepted copy cannot hide behind one-cycle ready pulses.

    hs_fixed_src.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    `timescale 1ns/1ps
    module hs_fixed_src (
      input  logic       clk, rst_n, ready,
      output logic       valid,
      output logic [7:0] data
    );
      logic idx = 1'b0, done = 1'b0;
      always_ff @(posedge clk) begin
        if (!rst_n) begin valid <= 1'b0; data <= 8'd0; idx <= 1'b0; done <= 1'b0; end
        else if (!valid && !done) begin valid <= 1'b1; data <= (idx == 1'b0 ? 8'hA5 : 8'h3C); end
        else if (valid && ready) begin
          valid <= 1'b0;                          // retire the offer on its accepting edge
          if (idx == 1'b0) idx <= 1'b1;
          else done <= 1'b1;
        end
      end
    endmodule
    

    Remember

    • A transfer happens when valid and ready are both high; the source owns valid and the payload, the sink owns ready.

    • Valid stays asserted until the handshake, and the payload stays stable while valid waits for ready.

    • Both assertions are needed: one for valid, one for data.

    Rule of thumb: once offered, a payload cannot change until the handshake.

    Keep going

    • Practice: Two-stage valid/ready pipeline with backpressure

    • Code lab: AXI stream handshake

    • Interview: run a mock interview on this topic

    Related topics

    • Debug hierarchy before touching code

    Previous

    290 / 350

    Next: STA and ECO Hub

    Up next

    Up nextSTA and ECO Hub

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Debug hierarchy before touching code
    • Controlled dumps and trigger capture
    clkvalidreadydata0a53c
    A payload change before acceptance