DVCon 26 Hackathon Problem

Yet Another Processing Protocol

DV

You are the lead verification engineer for a new design block called YAPP (Yet Another Processing Protcol). The design team has just completed the first version of the RTL and you are now tasked with creating a testbench to verify the design. You decide to use SystemVerilog for your testbench and you want to create a comprehensive set of checks to ensure that the design is functioning correctly. The design team has provided you with a specification document that outlines the functionality of the YAPP protocol, including the various signals and their expected behavior. Here is the specification for the YAPP protocol:

YAPP Protocol Specification:

  1. The YAPP protocol consists of a request-response mechanism where the sender initiates a request to a completer and the completer responds with the appropriate data.
  2. The sender initiates a request by asserting the yapp_req signal and providing a unique request ID on the yapp_req_id signal.
  3. The completer responds to the request by asserting the yapp_resp signal and providing the corresponding request ID on the yapp_resp_id signal and the associated data.
  4. The completer can respond to requests in any order, but it must ensure that the response ID matches to one of the pending requests.
  5. The completer can abort the response as well by asserting the yapp_resp_abort signal where the completer is responsible for sending another response for the aborted ID. The sender must ignore the aborted response and shouldn't consume it.
  6. The sender and completer must handle the case where the request buffer is full. When full the sender should not assert the yapp_req signal until there is space in the request buffer.

Interface Definition

The RTL consists of the following interface:

  • yapp_req_o : Indicates a valid request when asserted
  • yapp_req_id_o[3:0] : A 4b request ID for the request
  • yapp_reqbuf_full_o: Indicates the request buffer is full
  • yapp_resp_i : Indicates a valid response when asserted
  • yapp_resp_id_i[3:0] : A 4b response ID for the response
  • yapp_resp_abort_i : Response got aborted and will be tried again
  • yapp_resp_data_i[31:0] : Associated data with the response

Design Specification:

The design team has also shared the following design specification highlighting some of the design choices:

  • The design can support up-to 12 pending responses. This implies that the yapp_reqbuf_full_o signal will be asserted when there are 12 pending transfers
  • The valid range for ID signal is from 0 to 11 since there can be atmost 12 pending responses
  • Design is free to utilise the ID for a request as long as it is not pending a response. However, it is guaranteed that the ID will be within the valid range (0..11)
  • There are no timing relationship between when the request gets asserted and when the responses are sent back

Coding Exercise

As part of this challenge, you are expected to find 4 hidden bugs in the RTL by coding different checks in the yapp_scoreboard.sv file as per the above information. All the other testbench components have already been coded and you should only be updating yapp_scoreboard to add checks which will find the hidden RTL bugs. Whenever a bug is found, you should register it by calling the bug_tracker() function which takes in the current timestamp ($time) and the buggy ID. The buggy ID must be the request ID for which RTL displays the incorrect behaviour. There is one check already added in the scoreboard and you are expected to come up with similar checks. The testbench runs a test which stresses the following conditions:

  • Send responses in any order to ensure RTL can handle out-of-order responses correctly
  • Sends responses with yapp_resp_abort attribute to check if RTL doesn't consume them
  • Blocks responses until the yapp_reqbuf_full signal gets asserted to check if there are 12 pending responses
  • Calls end_of_test () function when there are no pending responses and no new requests are expected
  • The test ensures that the full condition is tested to ensure at least one request is seen fore each ID

Add the missing checks in the yapp_scoreboard to find all the 4 hidden bugs in the RTL!

Loading the interactive workspace...