A System Verilog Approach for Verification of Memory Controller

The major bottleneck of the computer system to improve the overall performance, is the memory performance. An effective control of data between processor and memory can be done using memory controller. Verification plays a vital role in any design flow as it is completed before silicon development. In this work a memory controller for interfacing Synchronous Static Random Access Memory (SSRAM), Synchronous Dynamic Random Access Memory (SDRAM), Read Only Memory (ROM) and FLASH which is Electrically Erasable Programmable Read-Only Memory is designed and a Constraint random verification environment which is coverage driven, is built for the designed memory controller. The code is written in Verilog HDL and the verification is done using System Verilog. Using Questa Sim 10.0b software tool the simulation is done, and coverage results are obtained. The verification environment built in this work, gives a functional coverage of 96.8% and assertion success of 100% with 0% assertion failures. Simulation results show that the designed controller gave good performance and full filled all the system specifications. Keywords— Wishbone interface, functional coverage, verification environment, Assertion.


INTRODUCTION
The The memory controller is a digital circuit that manages the flow of data going to and from the computer's main memory. A memory controller can be a separate chip or integrated into another chip. If it is an integral part of a microprocessor it is usually called an integrated memory controller (IMC). It acts as an interface between the processor and external peripherals for accessing memory.
Literature review is done, In [1] the author specifies about the specifications required for the design of memory controller like the configuration of registers and the address range for each of them. It also gave the information about how to connect various memory devices to the Memory Controller. It also specified the clock frequency and other constraints pertaining to memory, for example the refresh cycle time period for SDRAM (synchronous dynamic random-access memory). In [2] the author gave an insight of Integrated Memory Controller (IMC) which supports DDR3 protocols with two independent, 64-bit wide channels each accessing one or two DIMMs. The type of memory supported by the processor is dependent on the PCH SKU in the target platform. The memory controller has an advanced command scheduler where all pending requests are examined simultaneously to determine the most efficient request to be issued next. In [3] the author explains the basic functionality of SDR SDRAM (standard single data rate-synchronous dynamic random-access memory) devices, such as the command structure. In addition to this, DDR (double data rate) SDRAMs contain several enhancements like Double data rate, Source synchronous operation, Low voltage signaling and Differential clocks. In [5] in this constrained random verification, which is created by means of verification methodology manual (VMM) for system verilog and classification trees, is reusable, scalable, configurable and can reduce time of verification.

VERIFICATION ENVIRONMENT FOR MEMORY CONTROLLER
The functionality of the blocks are expressed as: Generator: This generates scenarios or test cases such as register reset, register read write, sram read write, sdram read write, flash read write, synchronous memory(rom) read write, all chip selects connected with different memories, suspend and resume test. Figure 1 presents the block diagram of memory controller.
Driver (BFM): The only block which is driving the scenario to the DUT is the bus functionality model which models the wishbone bus. Figure 2 shows verification environment for memory controller. Reference model: It is a model conceived in an early phase, before the RTL implementation, assumed as ideal. It simulates the DUT at a high level of abstraction, that is, creating reference output using register model.
Checker: This does the comparing of the actual output of DUT with the expected output given the reference model.
Scoreboard: This is responsible for keeping a track of pass/fail transaction counts, that is, if all the fields in the transaction matches with the expected transaction, then only the testcase is said to be passed. This is implemented as a part of checker.
Assertions: This is for checking signal level protocol behavior. There are two things in checking the signal behavior, that is, a positive check where it's checking if DUT is doing what it is expected to do and a negative check where it's checking if DUT is doing anything that it is not expected to do or for any unintended side effects after doing what it's expected to do.

TEST PLAN
In The following are the list of testcases implemented:

Test_register_reset
In this testcase, the reset signal is applied and released so as to verify if the register contents are actually reset on applying a synchronous reset signal as shown in Figure 3.

Test_register_write_read
In this testcase, write and read operations are performed to the registers to check for data corruption, that is, if the data written to a particular address is the same when read back from the same location as shown in Figure 4.

Test_all_chipselects_sram
In this testcase, write and read operations are performed to the SRAM chips connected so as to check for data corruption only after configuring the registers to operate for SRAM as shown in Figure 5.

Test_all_chipselects_sdram
In this testcase, write and read operations are performed to the SDRAM chips connected so as to check for data corruption only after configuring the registers to operate for SDRAM as shown in Figure 6. Figure 6. SDRAM write-read testcase

Test_all_chipselects_flash
In this testcase, write and read operations are performed to the FLASH to check for data corruption after configuring the registers to operate for FLASH

Test_all_chipselects_rom
In this testcase, write and read operations are performed to the ROM chips connected so as to check for data corruption only after configuring the registers to operate for ROM.

Test_all_chipselects_different_memories
In this testcase, write and read operations are performed to all the four different memory chips, that is, SRAM, SDRAM, FLASH, ROM connected so as to check for data corruption only after configuring the registers to operate for different memories.

Test_suspend_resume
In this testcase, after configuring the registers to operate for different memories, the suspend signal is pulled high after one write operation and after that read operation is performed. This testcase cannot read the data, as the operation which was suspended is not resumed as shown in Figure 7.

CONCLUSION
A reusable, scalable and configurable environment and a coverage-driven constraint random-based coverage model are thus presented to verify the functions of a memory controller in a microprocessor in this paper. It's proved by the results that this method used to verify memory controller is more time-efficient than the directed test method. Future work in this direction involves developing an algorithm for automatic generation of memory access groups, given a set of memory timings and a burst size.