Metric Driven Verification of Reconfigurable Memory Controller IPs Using UVM Methodology for Improved Verification Effectiveness and Reusability
Chaithanya B S, Gopakumar. G, Deepu K Krishnan, S. Krishnakumar Rao , Biju C. Oommen (Centre for Development of Advanced Computing)
ABSTRACT
Rapid advancement in technology that accelerates the demand for faster and smaller electronic devices with reduced cost and time to market triggered the necessity for functional verification. The paper presents a method for verifying a standard SDRAM controller IP, based on UVM framework using the Object Oriented verification language System Verilog. The verification technique focuses on a Metric Driven approach for reconfiguring the predictor model to suit the various functional realizations of the memory controller and also to improve the performance by effectively reducing the verification cycles for maximum functional coverage. The entire verification environment is modularized into reusable blocks for defining new test cases at ease, for any specific functional requirements. The predictor and comparator modules in the proposed verification environment being designed are independent of a global synchronising signal with respect to the memory controller, ensures minimum modification of the reusable blocks for verifying various standard memory controller IPs with different timing specifications.
1. Introduction
The SDRAM is a Dynamic Random Access Memory, synchronized with the system bus which is primarily used for achieving higher data access rates. The SDRAM Memory Devices are organized into Banks, Rows and Columns of various sizes; each bank constituting two dimensional arrays of rows and columns. In order to access a particular memory cell, it is necessary to first activate the required row in the required bank through “ACTIVE” command, and then access the specific column inside the selected row through “READ/WRITE” command. The SDRAM Device requires “REFRESH” commands at regular intervals to retain the data stored in the memory cells. Once activated, the Row should be deactivated prior to activating another Row inside the same Bank by issuing “Precharge” command to the respective Bank/Row. The SDRAM Device also has an internal register which can be accessed through “Load Mode Register” command for configuring the various modes of operation. To ensure the successful completion of each command send to the SDRAM device, certain timing parameters need to be maintained as mentioned in its specification.
A Memory Controller is primarily intended to control data flow between a Master Device and Memory Devices. A typical Memory Controller will have a standardized Master Interface at input side and a Memory Device interface at output side. Apart from Read/Write commands, the Memory Controller should issue the Refresh, Precharge, Load Mode Register, NOP commands to the SDRAM Device for ensuring the proper operation of the device. The Memory Controller discussed in the proposed verification architecture is an AMBA compliant peripheral which supports Memory Devices with various segmentation configurations and timing parameters. The controller is configured for various modes of operation and timing parameters through the APB interface; whereas different transfers viz. read/write with varying burst lengths, data access types and sizes are triggered through the AHB interface.
The conventional SDRAM Controller verification model includes the design of an SDRAM Memory model which replicates the device functionality as a memory array with the associated registers. The traditional SDRAM Controller verification model has the disadvantage of higher resource utilisation due to the usage of large static/dynamic memory arrays, which will slow down the verification turn around time. We propose a verification model which dynamically monitors and verifies each command generated by the SDRAM Controller IP, without the aid of static/dynamic arrays.
Fig 1.1
System Verilog and object-oriented verification become more and more important nowadays, in order to solve large-scale circuit verification challenges. System Verilog has distinguished features such as constrained random generation, temporal assertion and functional coverage constructs which helps to achieve the verification goals at ease compared to other traditional methods. Universal Verification Methodology (UVM) is introduced to take full advantage of System Verilog features for building transaction level verification environment. UVM defines the verification architecture outlines and provides the building blocks needed to develop structured verification components, making the verification components well encapsulated for the best reuse as Verification IP (VIP) across various designs.
The verification environment is primarily constituted by UVM Verification Components (UVC) which represents the reusable units as shown in Fig 1.1. The SDRAM controller depicted in the proposed architecture is an AMBA complaint peripheral which uses AHB bus interface for the read/write transactions and APB bus interface for internal register configurations. The internal register serves the purpose of configuring SDRAM controller with the various timing parameters of the Memory device. Each of the UVC consists of sequencer, driver, collector, monitor & checker corresponding to that particular component. The scoreboard consists of the predictor model of the SDRAM controller and a comparator to cross check the predictor and DUV outputs generating pass/fail responses.
The proposed verification methodology concentrates on a metric driven approach which helps in reconfiguring the predictor to suit the different state machine implementation of the controller and also for achieving higher functional/code coverage with minimum verification cycles. The architecture also has the advantage of minimum resource utilization for verification of the memory controllers compared to the traditional memory model based verification.
2. Metric Based Verification Approach
Metrics can be defined as the set of parameters that are relevant to the various functional aspects of the DUV. The proposed paper focuses on two categories of metrics
- Coverage Metrics
- Configuration Metrics
2.1 Coverage Metrics
Coverage Metrics constitutes the functional vectors that are targeted to achieve extensive functional and code coverage with minimum verification cycles. The metric based approach ensures that the functional vectors not only covers the various configurations & operating modes supported by the DUV, but also the special functional requirements of the DUV. For the proposed verification architecture of SDRAM Controller, the various read/write configurations can be achieved by generating all the possible AHB transactions supported by the controller.
The SDRAM Controller requires certain special functional test cases such as the automatic boundary management for row/column overflows, AHB error response for illegal memory addresses etc. Boundary management refers to the automatic switching to the subsequent bank/row when a row/column overflow happens in between a burst mode. The Metric based verification for Coverage Metrics is as depicted in fig 2.1.1.
Fig 2.1.1
The metrics configure the test file to generate test cases suiting the verification requirements. Each of the test case triggers the AHB & APB transactions to the DUV; for which the UVC (DUV) predicts the golden output which is checked against the DUV (SDRAM Controller) output. Based on the comparison result, the UVC (DUV) eventually issues a PASS/FAIL status. The Monitor block in both the AHB & APB UVCs collects the coverage information of their respective transactions.
2.2 Configuration Metrics
Configuration metrics serves the purpose of reconfiguring the internal states of the predictor in UVC (DUV) to meet the various implementation strategies of the DUV. The use of configuration metrics adds additional advantage of reusing the same verification IP for various user specific state flow implementations of the DUV. For instance, the state machine implementation of the autorefresh feature of the DUV (SDRAM Controller) in the proposed architecture has the flexibility of being implemented in multiple ways as depicted below.
- Case I: Read/Write has higher priority compared to the Autorefresh timeout. If an autorefresh timeout occurs in the midst of a Read/Write burst operation; the DUV (SDRAM controller) waits for the Read/Write to finish prior changing its state to autorefresh.
- Case II: Autorefresh has higher priority compared to the Read/Write transactions. If an autorefresh timeout occurs in the midst of a Read/Write burst operation; the DUV (SDRAM controller) pauses the burst transfer, changes its state to Autorefresh. On successful completion of Autorefresh command, the DUV resumes the remaining transfers of the burst.
The above scenario is applicable to any generic circuit where there are no specific protocols for state machine implementation. A typical UVC (DUV) predictor module designed to satisfy any one of the above cases requires the source code modification in order to suit the other.
Fig 2.2.1
The proposed architecture facilitates reconfiguration of the predictor internal states that can be achieved using the Configuration Metrics which makes it suited for the various user implementations of the DUV. The Configuration Metrics prioritizes the internal states of the predictor by parameterization of the internal state control variables. At a broader level, the Configuration Metrics can be further enhanced to suit the verification of a larger variety of Controller IPs, by efficient reuse of every available block.
Fig 2.2.2
3. Architecture
The architecture of the proposed Memory Controller VIP focuses on three major aspects
- Re-configurable Metrics Based Controller Model
- . Asynchronous Predictor/Comparator
- Minimum Resource Utilization Approach
3.1 Re-configurable Metrics Based Controller Model
System Verilog being a highly powerful language with lot of advanced constructs, there are multiple ways of implementing a capability using the same. The reconfiguration of the proposed predictor is implemented using the “‘Unique” and “Array Locator Method” features of the System Verilog.
A typical implementation of the prediction logic for the proposed architecture is as depicted in fig 3.1.1. The state transition variables are generated based on the priority set for each state along with the input and other internal state conditions. This approach is extended to generate the entire state transition variables of the proposed memory controller.
The prediction mechanism has the provision to avoid transition to certain stages by changing it to ‘invalid states’ by setting the priority to ‘0’. Also, there is provision to give same priority level to multiple states. However it should be ensured that the same priority levels are set only for mutually exclusive signals. The predictor uses the “Unique” feature of System Verilog to ensure that same priority levels are assigned to signals that are mutually exclusive. If found otherwise a “warning” will be issued by the “Unique” decision modifier.
Fig 3.1.1
3.2 Asynchronous Predictor/Comparator approach
Another key feature of the proposed verification architecture is that the verification IP can verify the SDRAM controller (DUV) as an asynchronous device for each valid transactions generated by the AHB transaction model. The predictor generates the expected output synchronously with each AHB transactions, but the comparator waits for a “start compare” signal from the SDRAM Controller Output Interface model. The SDRAM Controller Output Interface model continuously monitors the SDRAM Controller output and generates a trigger for every transaction which is followed by the “start compare” signal for each valid command as depicted in figure 3.2.1. This technique enables the verification architecture suitable for integrating with different types of memory controllers irrespective of the nature of their clocking signal.
Any transition at the DUV output interface with a valid chip select signal, other than the NOP corresponds to a valid command. Since comparison is asynchronous, the comparator also ensures that each valid command received from the memory controller (DUV) has the minimum pulse width requirements with respect to the DUV clock period.
Fig 3.2.1
3.3 Minimum Resource Utilisation approach
The conventional SDRAM Controller verification model includes the design of an SDRAM Memory model which consists of a memory array of the specified memory size along with the associated registers. System Verilog has the provision to declare memory array as static as well as dynamic allocations. In case of static array, the entire memory locations are allocated at the compile time itself while dynamic/associative memory locations are allocated only when they are written to. The sole advantage of dynamic memory allocation lies on the assumption that less than 15% of the memory locations are only accessed while simulating large memory devices. Even though dynamic memory allocations are highly effective and utilize fewer resources compared to static memory allocations; there can be conditions where the memory controllers need to ‘write’ large number of locations for memories like SDRAM / DDR. Thus the traditional Memory Controller verification model has the disadvantage of higher resource utilisation due to large static/dynamic memory arrays, which will slow down the verification turn around time. The proposed verification model dynamically monitors and verifies each command generated by the Memory Controller IP, without the aid of static/dynamic arrays. The Verification IP doesn’t stores any of the write data; instead it predicts/compares the entire ‘write’ command happening at the Controller output interface for each write operation with respect to the transaction at the Master interface. For read operations, the SDRAM Controller Output Interface will provide a random data at the memory data bus which need not be necessarily the written data value. The Predictor/Comparator just need to make sure that the “read” data value from the Memory Controller at the Master interface is according to the corresponding random data provided at the Memory Data bus provided by the SDRAM Controller Output Interface.
4. Results & Conclusion
The Metric driven controller model, along with the asynchronous comparison approach aids the reuse of the proposed memory controller verification IP for wide varieties of the Controllers. This technique can be further enhanced to build a universal verification IP for controllers which have similar functionalities that can be reused.
5. References
- White paper on “Maximizing Verification Effectiveness Using MDV” by Nick Heaton, Distinguished Engineer, Cadence Design Systems
- A comparison of VHDL and Verilog Resource Usage by behavioural Memory Models by Richard Munden, Free Model Foundry.
- System Verilog’s priority & unique –A Solution to Verilog’s “full_case” & “parallel_case” Evil Twins! By Clifford E.Cummings sunburst Design,Inc
- System Verilog 3.1 Accellera’s extension to Verilog
- www.jedec.org
- www.micron.com
Related Articles
- Smart way to memory controller verification: Synopsys Memory VIP
- Efficient methodology for design and verification of Memory ECC error management logic in safety critical SoCs
- Metric Driven Validation, Verification and Test of Embedded Software
- System Verilog based Generic Verification Methodology for IPs/ASICs/SOCs: A Case Study
- Re-Use of Verification Environment for Verification of Memory Controller
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
- Layout versus Schematic (LVS) Debug
- Usage of Multibit Flip-Flop and its Challenges in ASIC Physical Design
E-mail This Article | Printer-Friendly Page |