Valid Must Eventually Handshake
Write an assertion for a ready/valid interface.
Task
Assert that once valid is asserted, it remains asserted until ready is observed.
Examples
- valid=1, ready=0 → valid stays 1
- valid=1, ready=1 → transfer occurs
Constraints
- Sample on the rising clock edge.
- Do not require ready to be high immediately.
What this problem is testing
SVA questions test temporal reasoning: exactly when signals are sampled, overlapped versus non-overlapped implication, reset disabling, and whether an assertion can pass vacuously.
Interview habit: before coding, state reset behavior, the state that must be stored, and the conditions that update each output.
Verification plan
- Write one passing trace and one deliberately failing trace.
- Check the exact cycle where the antecedent becomes true and where the consequent starts.
- Exercise reset while the property is active.
- Use cover or directed stimulus when useful to prove the antecedent can actually occur.
Edge cases worth testing
- A trace where the antecedent occurs but the consequent fails.
- A trace where the antecedent never occurs, to inspect vacuity.
- VALID held while READY is low.
- READY asserted before VALID.
- Back-to-back transfers without an idle cycle.
Common mistakes
- Choosing |-> versus |=> by habit.
- Forgetting disable iff or mishandling reset.
- Allowing vacuous success because the antecedent never occurs.
- Using unbounded eventuality when the protocol has a finite response requirement.
Interview follow-up questions
- Would overlapped or non-overlapped implication be correct here, and why?
- How would you detect or avoid vacuous success?
Concepts to review
assertion, handshake, property
Open Valid Must Eventually Handshake in the HDLForge interactive editor.
Related problems
- Synchronous FIFO — Hard
- Reset Clears State — Easy
- Backpressure-Safe Ready/Valid Source — Medium
- AXI-Lite Write Register Slave — Hard
- Request/Acknowledge Controller — Medium
Explore the SystemVerilog Assertions (SVA) Practice hub.