Memory Subsystem verification – Can it be taken for granted ?

1. Memory Subsystem verification – Can it be taken for granted ? by Shivani Upasani Prashanth Srinivasa LSI Bangalore

2. Agenda • Introduction to the Design under test (DUT) • Scoreboard approach • Interrupt and Exception Checker • Low-power mode verification of memory • Results and Conclusions

3. DUT overview • Scalable architecture • Multiple memory instances • Each memory consisting of multiple sub-banks • Memory controller IP • AXI Framework • Glue logic to connect to Register Block • 128 bit AXI Interfaces • APB Interface sub bank2 sub bankm sub bank1 Memory 1 Memory 2 Memory n mem if mem if mem if Glue Logic Memory controller Register Block Memory controller Memory controller AXI AXI APB AXI Glue Logic AXI Framework Third Party IP AXI AXI

4. Verification Requirement of the Memory subsystem • Data Integrity Check • To confirm that the data on the AXI Framework is correctly getting written into the memory and data read from memory is correctly being returned to the AXI framework. • ECC functionality • Need to verify the ECC functionality of the third party IP. • Need to verify the Glue logic written to update the ECC errors, address, and syndrome values into the register block. • Low-power mode features - The light sleep, deep sleep, and shut down features of the memory need to be verified.

5. Data Integrity Scoreboard Approach Two methods can be adopted. • Reference model approach. • Non-reference model approach (byte level scoreboard, packet based scoreboard, or backdoor read scoreboard)

6. Scoreboard Approach Comparison Non-Reference model approach Reference model approach DUT functionality needs to be modeled. Exact number of reads and writes are predicted. Effort required is more in this approach (in our case 3 weeks). • We don’t need to model the DUT behavior or predict number of reads and writes. • Data can be tapped from the interface using monitors either in a packet format or byte wise. • It is easier to implement (approximately 1 week)

7. Non Reference model Scoreboard AXI WRAP Address =0x22 Burst size = 8 bit/1 byte Burst length = 4 Memory 1 sub bank m sub bank 2 sub bank 1 Compare and decide PASS/FAIL AXI Read Response mem if 0x22 AE bank scoreboard 0x23 65 0x20 29 Register Abstraction Layer 0x21 F7 Glue Logic Register Block Memory Controller AXI monitor AXI if AXI Framework AXI Read Request

8. Reference model Verification Environment 0x22 AE Memory 1 sub bank m sub bank monitor m sub bank scoreboard m 0x23 65 Memory Read sub bank monitor 2 sub bank scoreboard 2 sub bank 2 0x20 29 sub bank scoreboard 1 sub bank 1 sub bank monitor 1 0x21 F7 AXI Read Response Compare and decide PASS/FAIL mem if bank scoreboard Calculate the number of memory transfers Additional effort required in reference model approach Register Abstraction Layer Glue Logic Register Block Memory Controller AXI monitor AXI if AXI Framework AXI Read Request

9. Example of Redundant Read • In case of AXI wrap read transfers, if the address wraps back to the same memory word boundary, two reads are initiated (first read for first beat and second read when it wraps back), though a single read is sufficient. Address : 0x22 Transfer size : 8 bits Burst type : wrapping Burst length : 4 2f 2e 25 24 23 22 21 20 1st transfer 2f 2e 25 24 23 22 21 20 2nd transfer Aligned wrapping byte transfer on a 128 bit bus

10. Redundant Read Issues • Redundant reads in AXI WRAP transfers • Redundant reads in case of back to back read & read-modify-write transfers • Redundant reads in case of write transfers when burst size is less than bus width and ECC generation is disabled. Performance Issues in the DUT

11. ECC Functionality check • Requirement • Real time errors occurring in the memory can result in a system failure and hence it is important to verify them. • Verification Strategy • Inject single bit and double bit errors in the memories via backdoor. • Generate access to those locations and check for data integrity. • Check for the interrupt/exception generation and handling at the system level.

12. ECC Interrupt & Exception Checker Scenario Generator Register Block Error injection into memory via backdoor Glue Logic Backdoor interface Memory Memory controller Bank scoreboard Data Integrity Check Type of error (sec/ded) Drive DUT interface for halt/reset Interrupt Service Routine RAL Interrupt Checker DUT interrupt and exception signals

13. ECC Interrupt & Exception Checker • Independent threads to check the interrupt and exception in case of single bit and double bit errors. This helps in case of back to back errors. • Uses parameterized RAL register classes for passing the registers to the checker. • Checks for the bank error address, syndrome, transfer id, transfer type, and error type correctly getting latched in the bank status reporting registers • Uses the Register Abstraction Layer (RAL) in the environment for reading all these register values using backdoor to avoid any delays in the checker. Parameterized RAL register type `define STATUS_BANK_REG_1 ral_reg_addr_map_register_file_reg1 `define STATUS_BANK_REG_2 ral_reg_addr_map_register_file_reg2 class bank_checker #(type STATUS_REG1 = `STATUS_BANK_REG_1, STATUS_REG2 = `STATUS_BANK_REG_2) extends bank_checker_base .... function new( STATUS_REG1 reg1, STATUS_REG2 reg2 ); .... endfunction .... endclass

14. Interrupt Service Routine(ISR) • Uses RAL backdoor to simultaneously read the interrupt status register while the exception checker is also operating on the same register. • Mimics system level behavior and issues halt or reset to the DUT. • Operates on bit wise status register and clears them one after the another. Keeps a check that unless all the status bits are cleared, the interrupt and exception should remain asserted.

15. Low Power Mode verification • Light sleep, deep sleep, and shut down modes of a memory are verified. • Connectivity checks are carried out to confirm the TOP level power-mode signal correctly connected to the memory bank and sub-bank power mode signals. • Functional checks are carried out by writing to and reading from the memory during low power and comparing actual versus expected behavior. Sub bank 1 Sub bank 2 Clk & Rst Connectivity Checker Clocking Bock LS DS SD Sub bank 1 Sub bank 2

16. Conclusions • 2 weeks of development effort translated to 3 types of redundant read bugs – a very good ROI ! • This verification environment can be packaged as a VIP & re-used. We have successfully re-used this block level environment at the chip level for multiple instances of memory subsystems. • This approach scored high on scalability – it can be configured for varying memory banks or sub-banks configuration. • Low-power modes of the memory are verified for both connectivity checks and functional checks.

17. Thank You