assertions part3

SystemVerilog Assertions (SVA) in functional verification, traditional testbench-based verification, controllability and observability, and the responsibilities of design and verification engineers in writing assertions. First, Action Blocks in SystemVerilog Assertions are procedural blocks that execute when an assertion passes or fails, allowing verification engineers to print meaningful messages, record debugging information, increment counters, or terminate a simulation. For example, if a request signal (req) is asserted and an acknowledgment signal (ack) arrives within the expected clock cycle, the assertion passes and prints a success message; if the acknowledgment is missing, the assertion fails and displays an error message. The waveform illustrates both scenarios, with the PASS case showing req followed by ack and the FAIL case showing req without the expected acknowledgment. Second, Traditional Verification uses a testbench consisting of a stimulus generator, driver, and monitor to apply inputs to the Design Under Test (DUT), observe its responses, and send the collected information to a checker, scoreboard, and coverage model. In the FIFO verification example, the testbench applies write and read enables, supplies input data such as 11, 22, and 33, and checks whether the output data appears in the correct order while monitoring the full and empty status signals. This approach helps identify functional bugs by comparing actual DUT behavior against expected results. Third, Controllability and Observability are two essential concepts for effective verification: controllability is the ability to drive the DUT into a specific state or condition by applying suitable input combinations, while observability is the ability to detect the effects of those inputs through output signals, internal signals, or assertions. For example, to verify an APB wait state, the testbench can assert PSEL and PENABLE while keeping PREADY low, forcing the transfer to remain in the wait state until PREADY becomes high. For FIFO verification, an assertion can check that full and empty are not simultaneously high, detecting an illegal status condition. Both concepts are important because a bug cannot be reliably detected if the testbench cannot reach the relevant condition or observe its incorrect behavior. Fourth, Who Writes Assertions? Both design engineers and verification engineers write assertions, but their focus differs. Design engineers typically write implementation-specific assertions to check internal FSM states, datapath behavior, pipeline conditions, and counter operation during RTL development and debugging. For example, an FSM assertion can verify that the state register contains only legal states such as IDLE, SETUP, ACCESS, and ERROR. Verification engineers generally write protocol- and specification-based assertions to check interface behavior, timing requirements, and protocol compliance. For example, an AXI stability assertion checks that when AWVALID is high and AWREADY is low, the address and associated control information remain stable until the handshake can complete. Together, these techniques improve bug detection, reduce debugging time, and increase verification confidence by checking both internal design behavior and externally visible protocol requirements.