The objective of this verification effort is to validate the functional correctness and protocol compliance of an APB-based memory design. The verification is performed using a UVM-based testbench acting as an APB master, ensuring adherence to the AMBA APB specification.
The following aspects are covered:
- APB protocol timing and handshaking
- Correct execution of write transactions
- Correct execution of read transactions
- Address decoding and data storage
- Ready response behavior (PREADY)
- Reset behavior
- Identification of protocol and design issues
Out-of-scope:
- APB error response (PSLVERR)
- Power-aware or low-power verification
- Performance benchmarking
The DUT is a parameterized APB memory module with the following interface signals:
| Signal | Direction | Description |
|---|---|---|
| PCLK | Input | APB clock |
| PRESETn | Input | Active-low reset |
| PSEL | Input | Peripheral select |
| PENABLE | Input | Transfer enable |
| PWRITE | Input | Write control |
| PADDR | Input | Address bus |
| PWDATA | Input | Write data |
| PRDATA | Output | Read data |
| PREADY | Output | Ready signal |
The verification environment is built using UVM and consists of:
- APB Interface
- Defines APB signals and clocking blocks
- APB Agent
- Driver: Drives APB read/write transactions
- Sequencer: Generates transaction-level stimulus
- Monitor: Observes and samples APB bus activity
- Scoreboard
- Stores written data
- Collects read data for comparison and analysis
- Environment
- Integrates agent and scoreboard using configuration objects
A transaction (apb_xtn) includes:
- Address
- Transaction type (READ / WRITE)
- Write data
- Read data
Transactions are generated using constrained-random and directed sequences.
The following test scenarios are implemented:
| Test ID | Scenario Description |
|---|---|
| TC_01 | Single APB write transaction |
| TC_02 | Single APB read transaction |
| TC_03 | Write followed by read (same address) |
| TC_04 | Multiple address write transactions |
| TC_05 | Multiple address read transactions |
| TC_06 | Back-to-back APB transfers |
| TC_07 | Reset assertion and recovery |
Functional coverage is collected to measure verification completeness.
- Address coverage
- Transaction type coverage (READ / WRITE)
- Write data value ranges
- Read data value ranges
Coverage is sampled in the APB monitor after successful transfers.
Simple assertions are implemented to ensure APB protocol compliance:
- PENABLE is asserted only after PSEL
- PREADY is asserted only during valid APB transfers
- Address and data stability during active transfer
- PWRITE remains stable during a transfer
The verification process focuses on identifying:
- APB protocol violations
- Incorrect ready response behavior
- Invalid read data behavior
- Reset-related issues
- Driver scheduling and return-to-idle issues
All observed issues are documented and analyzed using waveform inspection.
The following issues were identified during verification:
- PRDATA tri-stated during non-read cycles (APB violation)
- PREADY not gated with PSEL
- Incorrect reset sensitivity list in DUT
- Minor APB driver return-to-idle handling issues
These issues were documented and corrected or highlighted as part of the verification process.
- Simulator: Aldec Riviera-PRO 2023.04
- Platform: EDA Playground
- Language: SystemVerilog
- Methodology: UVM 1.2
Verification is considered complete when:
- All planned test scenarios are executed
- APB protocol timing is verified via waveforms
- Functional coverage goals are met
- Identified bugs are documented
- No unexpected simulation errors are observed
-
AMBA APB Protocol Specification:
https://developer.arm.com/documentation/ihi0024/c -
EDA Playground Code:
https://www.edaplayground.com/x/Sw8n -
EDA Playground Waveform:
https://www.edaplayground.com/w/x/R2g
VLSI Mentor: https://www.udemy.com/user/vlsi-mentor/
Course Link: https://www.udemy.com/course/ip-verification-using-sv-uvm-testbench-and-test-cases/?couponCode=KEEPLEARNING