Design Verification of Umc

ABSTRACT
Design Verification needs design specifications to be simulated in the Advanced Verification tools
in order to assure the correctness of the system. This iproject imainly ifocuses ion iverifying ihis
iimportant ifeatures iof iMemory iController iusing iSystem iVerilog iwhich iincludes ia isynthesizable
isubset, ian iassertions ilanguage, ia iconstraint ilanguage, ia icoverage ilanguage iand ian iOOP ilanguage.
The iproposed imethodology iis icapable iof iverifying iSRAM, iSDRAM iand isynchronous imemory.
The itest ienvironment iprovides ia icomplete iverification ienvironment iincluding iConstraint iRandom
iGeneration, iAssertion iBased iVerification iand iCoverage iDriven iVerification. iMore ithan i200
icoverage ipoints ihave ibeen icovered ito iverify ithe ivalidation iof ithe iintegrated ifeatures iwhich imakes
ithe iproposed iuniversal imemory icontroller iwhich iis icapable of replacing the existing controllers.
In this module level verification the entire test environment is modeled using System Verilog and
the write, read transactions from master(memory controller) to slave(memory models) has been
verified with the quantitative values.
CHAPTER 1
INTRODUCTION
1.1 Overview of Memory Controller Block

The processor cannot really understand the type of memory connected to it and might not even
generate the right signals need in order to fully communicate with different types of memory, thus
there is a need for an intermediate device which seats between processor and the memories to
handle such issues.
The figure 1.1 shows the block diagram iof iUMC ifor iSOC ihaving idifferent itypes iof imemories ilike
iSDRAM, iDRAM, iSSRAM, iFLASH ietc.., iit iwill irequire idifferent itypes iof imemory icontrollers ifor
ieach imemory itypes. iWhich iwill iadd iextra ispace ion iSOC. iUniversal imemory icontroller idesign,
iimproved iby iintegration iof ithe iexisting imemory icontroller iin iaddition iof iproviding inovel ifeatures.
iThis imake ithe ilow ipower iconsumption ifor ithe idesign. iUMC icontroller idesign iwhich iis isupporting
iSDRM, iSSRAM iand iSYNC imemories iwhat iwe icall ias iUniversal iMemory i Controller. iThis iUMC
idesign iis ihaving isome ispecific ifunction ilike, iit ihas i8 ichip iselect iline iand iit isupport idifferent itypes
iof imemory.Single memory controller which is supporting different memories, for this UMC
design, verification is done by generating a test cases in system Verilog language.
Figure 1.1:Block diagram of Universal memory controller
As can be seen in the above block diagram the processor communicates the UMC via wishbone
interface and memories linked to the UMC are communicated respectively as per the signal
required by the memories and the request generated via processor. Wish bone block is a place
where we are verifying the UMC by checking read and write data matching, if both read and write
data matching then UMC is working properly and hence verification is done.
Memory imodules icontaining ia idifferent itypes iof imemory ilike iSDRAM, iSSRAM, iand iSYNC.
iThese imemories iattached ito ithe iUMC ithrough imemory iinterface. iAll ithese imemory idesigns iare
iwritten iin iVerilog icode; ithese iVerilog icodes iare iincluded iin ithe itop ifile iof ithe isystem iVerilog
imodule. iWhile iverification isystem iVerilog itop imodules iare iused.
UMC iis ihaving iits iown iarchitecture idesign iwith inovel ifeature isupporting. iUMC iis iplaced ibetween
iWISHBONE iand imemory imodule. iThese iblocks iare iinterfaced iby iWISHBONE iinterface iand
imemory iinterface ito ithe iUMC.
Wishbone iis iused ias ia iportable iinterface iin isemiconductor iIP icores iwhose ipurpose iis ito imake
isystem ire-usability ifaster ito iovercome ithe iDesign iintegration iproblems. i It ialso iimproves ithe
iportability iand ireliability iof ithe isystem iand iresults iin ifaster itime-to-market ifor ithe icustomer.
iWishbone iis inot iitself ian iIP icore ibut iis iused ias ia ispecification irequired ifor ithe icreation iof iIP icore.It
was created for the ease of interconnect interface understanding as well as for writing codes in
HDL prospective for the designers. The Table -1.1. Defines all the signals required for Wishbone
interface.
Table 1.1.:Wishbone Interface Signals
1.2 Problem Definition
It supports both FLASH and DRAM memory types to be controlled. But in project the memory
controller can support more than two imemories iand isome inew ifeatures iof imemory icontroller iand
ianother ione iis ithat ione ichip iselect iis iconnected iwith ione imemory iand iall i8 ichip iselect iare
iconnected iwith isame imemory ior idifferent imemories. i i i i
As iseen iin ithe iheading iof ithe iproject ititle iDesign iVerification iitself itells ithat iUMC iIP icore iis ia ipre-
designed ior ialready idesigned iCore iand ithis iproject iinvolves imethodology ifor iverifying iits idesign.
iThe imain iaspect iof ithe iproject iis ito idevelop iskills ias ia iVerification iEngineer irequired ifor ithe iFront-
End iVLSI iIndustry, ithe ifunctional icoverage ireflects ithe iability iverifying ithe idesign ias iper ithe iclient
irequirement iin iturn iwhich ialso ishowcases ithe iskill sets of a Verification Engineer. By the getting
higher Functional coverage results for the project it may provide an opportunity for the placement
as a Verification Engineer in the VLSI Industry.
1.3 Objectives
 In a verification environment we have to firstly look in to the specification provided by the
clients, in ithe icase iof iUMC iwe ilook iforward iand iunderstands iits ispecifications iprovided iin
ithe imanual.
 After ithe ianalysis iof iits ispecification, ithe inext istep iis ito ichoose ithe imethodology iinvolving
ithe iHDL: iVerilog i& iHDV: iSystem iVerilog.
 Then iwe ilook iforward iin ito ithe iUniversal iSystem iVerilog iArchitecture iwhere iin iUMC iPlay
ias ithe iDUT iwhich ineeds ito ibe icoded iin iVerilog iwhereas ithe iother iblocks iare icoded iin
iSystem iVerilog.
 Later iwe icreate ia itest ienvironment iwith idifferent iregression icases iinvolving ieach iand ievery
iscenario ialso iincludingworst cases.
 Lastly we generate a functional coverage results to identify the gaps of verification left
behind i.e. to check whether all test cases are covered or not.
1.4 Thesis Organization

CHAPTER 1: Introduction defines the overview of Universal Memory Controller (UMC), which
in turn answers the need for UMC for different applications. As the Micro-controller/Micro-
processor does not understand the different type of memory connected to it, the UMC behave as
an intermediate device which handles all the communication gaps between controller/processor
and the different memories.
CHAPTER 2: Involves Literature Survey which defines the support for the ideology required for
the development of verification methodology and even rectify the gaps and errors involved in the
previously resulted Functional Coverages obtained.
CHAPTER 3: Defines the basic Block diagram of UMC as well as the Specification details of
UMC also involving the data analysis for registers.
CHAPTER 4: Defines Methodology involved for the verification Techniques required for the
project. Mainly involving deciding factor of HDL: Verilog and HDV: System Verilog, also
defines the System Verilog Architecture which plays an important role in verification.
CHAPTER 5: As explained in all the chapters here we implement the same using Code i.e.
Verilog and system Verilog language, to Code DUT we have used Verilog Coding language and
for verification used system Verilog to do the different test cases and verified it on the Questasim
tool.
CHAPTER 6: for this project we have used QuestaSim Tool to write the codes and verifying the
test cases.
CHAPTER 7: Results have been discussed of SSRAM, SDRAM and of Synchronous Chip select
along with it application of memory controller has been discussed in brief and have finally
concluded it with respect the outcomes of the project.
.
CHAPTER 2
LITERATURE SURVEY
With growing gap between processor and memory speeds, the memory bandwidth has become
performance bottleneck for media applications. The memory controller designs are getting
optimized to reduce the latencies added iby ithem. iIt iis inecessary ito iprove ithe iperformance iof
imemory icontroller ion iprototypes. i It ihas ibeen iobserved ithat ithe iperformance icalculated iin
isimulations iis ivery idifficult ito iachieve ion iprototype iboard. iThis iis imainly ibecause iof isubsystem
ilimitations. iThe ipresent ipaper iillustrates ihow ia igeneric iprototype ican ibe idesigned iand iused ito
iprove ithe imemory icontroller iperformance. iHW ibased iperformance imonitor iunit iis idesigned iand
iused iin isimulation iand iprototype ivalidation. iThe iproposed imethodology ihas ibeen iused iin
iperformance ivalidation iof iExternal imemory icontroller ifor iCellular iRam iand iNOR iflash.
[1]. Implementation and verification of a generic universal memory controller based on UVM,
2015 10th International Conference on Design & Technology of Integrated Systems in Nanoscale
Era (DTIS), This paper presents a coverage driven constraint random based functional verification
method based on the iUniversal iVerification iMethodology i(UVM) iusing iSystem iVerilog ifor
igeneric iuniversal imemory icontroller iarchitecture. iThis iuniversal imemory icontroller iis ilooking
iforward ito iimproving ithe iperformance iof ithe iexisting imemory icontrollers ithrough ia icomplete
iintegration iof ithe iexisting imemory icontrollers ifeatures iin iaddition iof iproviding inovel ifeatures. i It
ialso ireduces ithe iconsumed ipower ithrough iproviding ihigh ipower iconsumption icontrol idue ito iits
iproposed idifferent ipower ilevels isupported ito ifit iall ipower iscenarios. iWhile iimplementing ia iworthy
iarchitecture ilike ithe iproposed igeneric iuniversal i memory icontroller, iUVM iis ithe ibest ichoice ito
ibuild iwell-constructed, ihigh icontrolled iand ireusable iverification ienvironment ito iefficiently iverify
iit. iMore ithan i200 icoverage ipoints ihave ibeen icovered ito iverify ithe ivalidation iof ithe iintegrated
ifeatures iwhich imakes ithe iproposed iuniversal imemory controller replaces the existing controllers
on the scene as it provides all of their powerful features in addition of novel features to control two
of the most dominated types of memory; FLASH and DRAM through one memory controller.
[2]. Coverage Closure Efficient UVM Based Generic Verification Architecture for Flash Memory
Controllers, 2016 17th International Workshop on Microprocessor and SOC Test and Verification
(MTV), Memory icontrollers iare istated ias ithe ibackbone iof idiverse iarchitectures iin ithe iASIC iworld.
iAmong imany iconcerns iin ienhancing ithe iperformance iof ithe imemory icontrollers iis ithe itremendous
iverification iprocess ithat iconsumes itime, ieffort iand iresources. iThis ipaper iproposes ian ioptimized
igeneric iuniversal iverification imethodology i(UVM) iarchitecture ito iverify ithe iflash imemory
icontrollers. iThe iarchitecture ibuilt iis ibased ion ia isurvey iabout ithe imain iflash imemory icontroller’s
iarchitecture itypes iincluding iFlex-*ne iNAND, i*pen iNAND iFlash i Interface i(*NFI), iEmbedded
iMulti-Media iCard i(e.MMC), iUniversal iFlash iStorage i(UFS) iand ithe iSD-CARD imemory
icontroller iexamined iwith i-open isource iwishbone(WB) iinterface-. iIntroducing ian ioptimized
isolution ifor imost iof imemory icontroller’s iverification ienvironments iis ia igreat ichallenge iowing ito
ithe iharshness iin ibuilding iand ireusing iresources, ithe inumerous iprotocols ithat ithe iverifier ishould ibe
iaware iof iand ithe ihigh inumber iof iiterations ito ireach ifull ifunctional icoverage. iThe igeneric
ienvironment ioffers iseveral iadvantages, iespecially iregarding ithe inumber iof itests iand isequences
ideveloped ito iachieve ifull icoverage. iThe igeneric ienvironment ialso iprovides ithe iversatility iof iusing
ipre-developed iUVM iarchitectures ithat ieventually icontribute iin iachieving imuch iless ideveloping
itime ifor ithe iwhole idesign iprocess. Throughout the architecture, we will be using new techniques
and state-of-the-art developed blocks to achieve the highest coverage closure time as well as an
innovative way to build a reference model and how to efficiently utilize and accelerate the
scoreboard checking process.
[3]. Development of generic verification environment based on UVM with case study on HMC
controller, 2016 IEEE International Conference on Recent Trends in Electronics, Information &
Communication Technology (RTEICT), ASIC/SOC iverification iis ione iof ithe imost iimportant itask
iin idigital idesign iworld. iA isurvey itells ithat i60 ito i70 i% iof itotal idesign itime iis iconsumed iby
iverification ionly. iDifferent icompanies iadopt idifferent iverification imethodology itill iUVM icomes
iinto ithe ipicture, iwhich iis ithe ibest isolution ito iovercome idrawbacks iof iprevious imethodologies. iThis
ipaper ipresents igeneric iverification ienvironment iarchitecture ibased ion iUVM iand iit ialso ipresents
ihow idifferent icomponent iare iconnected iwith ieach iother. As a case study, generic design of Hybrid
Memory Cube (HMC) memory controller is presented with some test scenario of verification.
[4]. Cache coherency controller verification IP using System Verilog Assertions (SVA) and
Universal Verification Methodologies (UVM), 2017 11th International Conference on Intelligent
Systems and Control (ISCO), Shared imemory iresources iare iinevitable icomponents iin imodern iSOC
iarchitecture idue ito iMulti-Core iArchitectures iresulting iease isynchronization iwith ienhanced ispeed
iand ireliability. iAgain iarchitectural iverification iis ichallenging ifor ithese iprotocols ifor icoherency
isystems. iHence ithis iproject iwork ihas icome iout iwith icomplete iverification ienvironment ifor isuch ia
icomplex iMESI icoherency iprotocol ibased ion imodel ichecking iand iassumes iguarantee iverification
imethods ideveloped ithrough icompositional iapproach iof iSystem iVerilog i Assertions i(SVA) iwith
ifunctional iverification iusing iUniversal iVerification iMethodologies i(UVM) ipackages ito
isubstantially iameliorate ithe idifficulties ifor idesign iaccuracy.
[5]. Verification and Simulation of New Designed NAND Flash Memory Controller, 2013
International Conference ion iCommunication iSystems iand iNetwork iTechnologies, iin ithis ipaper ia
iNAND iflash imemory icontroller iwas idesigned. iFor ithe ibest iuse iof iNAND itype iflash imemory iwe
idesign ia inew iArithmetical iand iLogical iUnit i(ALU) ifor icalculating iincrement, iaddition,
isubtraction, idecrement ioperations ietc. i In ithis imemory icontroller iwe idesign isingle imemory icell,
imemory imodule, ia idecoder ietc. iThese iall iare iencapsulated iinside ia icontroller iand ithis iis ion itop
imost iin ihierarchy. iNAND iflash imemory iis ia inonvolatile istorage imedia iused iin itoday idaily ilife
ielectronic iequipment’s. iNAND iflash imemory iis iprogrammed ion ipage iby ipage ibasis. iTypically
iprogramming itime iis ivery iless ifew imicro isecond iper ipage. iThis iNAND iflash imemory icontroller
iarchitecture ican ibe iused iwith ia ireal isecure idigital icard, imultimedia icard i(SD/MMC), idigital
icameras ietc. iThe iNAND iFlash imemory icontroller ican ibe ian iinternal idevice, ibuilt iinto ithe
iapplication iprocessor ior ihost, ior idesigns ican iincorporate ian iexternal, istand-alone ichip.
iExperimental iresults ishow ithat ithe idesigned icontroller igives igood iperformance iand ifull ifill iall ithe
isystem ispecifications. iWe ihave iused iFPGA ichip ifor idownload iour icode.
[6]. iReusable iand idesign iindependent imemory icontroller iscoreboard iusing imemory idata ihazard
ichecks, i2014 iIEEE iStudent iConference ion iResearch iand iDevelopment, ithis ipaper iinvestigates
imemory idata ihazard ichecks ias ia imethod ito iimplement ia ireusable iand imemory icontroller idesign
iindependent iscoreboard. iA iscoreboard iarchitecture ithat iuses imemory idata ihazard ichecks iis
iproposed iand iimplemented, ialong iwith ia itestbench iimplementation ithat iuses ithis iscoreboard. iThe
imemory idata ihazard iscoreboard iand itestbench iimplementation iis ithen ievaluated ion iselected
imemory icontroller idesigns, ifor ifunctionality, ias iwell ias ireusability. iThe ievaluation iresults ishow
iscoreboard ireusability iof i100% iis iachievable, iwith itestbench ireusability of at least 60%, and up to
70%. A qualification process is established to ensure the scoreboard and testbench is functionally
correct. From the results, it shows that a properly architected scoreboard and testbench code, once
properly qualified, can significantly reduce verification time on subsequent projects.
CHAPTER 3
UNIVERSAL MEMORY CONTROLLER
The memory controller is a chip on a compute’s motherboard or CPU die which manages the flow
of data going to and from the memory. It is the interface between system memory and the central
processing unit. The memory controller consists of special circuitry within a computer system that
interprets requests ifrom ithe icentral iprocessing iunit iin iorder ito ilocate idata ilocations, ior iaddresses,
iin imemory. i
Microprocessors icommunicate iwith imemory icores ithrough imemory icontrollers. iThe imain iaim iof
ithe imemory icontrollers iis ito iprovide ithe imost isuitable iinterface iand iprotocol ibetween ithe ihost iand
ithe imemories ito iefficiently ihandle idata, imaximizing itransfer ispeed, idata iintegrity iand iinformation
iretention.
To iimprove ithis icommunication ias ia isolution ifor ithe imemory ibottleneck, ithe imemory icores iand
imemory icontrollers ican ibe iimproved. i It isupports ia ivariety iof imemory idevices, iflexible itiming iand
ipredefined isystem istartup ifrom ia iFlash ior iROM imemory. i
Memory icontroller iis iused ito imanage imemory ioperations. iIt iinvolves imemory ireset iand
iinitializations, iwrites iand ireads, ithen imaintenance ioperations iif iany. iIt imanages idifferent
imemories. i8 iChip iselects ieach iuniquely iprogrammable, i3. iFlexible itiming ito iaccommodate ia
ivariety iof imemory idevices, i4. iBurst itransfers iand iburst itermination, i5. iSupports iRMW icycles i6.
iPerformance ioptimization iby ileaving iactive irows iopen i7. iDefault iboot isequence isupport, i8.
iDynamic ibus isizing ifor ireading ifrom iAsync. iDevices i9. iByte iparity iGeneration iand iChecking, 10.
Multi Master Memory bus support, 11. Industry standard WISHBONE SoC host interface, 12. Up
to 8 * 64 Mbyte memory size, 13. Supports Power Down Mode.
3.1 Features of Universal memory controller
1. Supports Power Down Mode
2. Burst transfers and burst termination 8 Chip selects, each uniquely programmable
3. Multi iMaster imemory ibus isupport
4. Industry istandard iWISHBONE iSoC ihost iinterface
5. Default iboot isequence isupport

6. Performance ioptimization iby ileaving iactive irows iopen
7. Supports iRMW icycles i
8. 8 iChip iselects, ieach iuniquely iprogrammable i
9. Up ito i8 i* i64 iMbyte imemory isize
10. SDRAM, iSSRAM, iFLASH, iROM iand imany iother idevices isupported i
11. Dynamic bus sizing for reading from Async. devices Industry standard WISHBONE SOC
host interface
12. Byte parity Generation and Checking
13. Flexible timing to accommodate a variety of memory devices Multi Master memory bus
support
3.2. Detail explanation of Universal Memory Controller block
Figure 3.2: Architecture of Universal memory controller

3.2.1. WISHBONE Interface
The iMemory iController icore iincludes ia iWISHBONE ihost iinterface. iThis iinterface iis iWISHBONE
iSOC ibus ispecification iRev. iB icompliant. iThis iimplementation iimplements ia i32-bit ibus iwidth iand
idoes inot isupport iother ibus iwidths.
The WISHBONE interface block performs very simple decoding of the wishbone signals
Figure 3.2.1: WISHBONE Interface
3.2.2. Power-On Configuration

This block is a part of the register file. The Power-On Configuration block, latches the value of
the Memory Data Bus during reset.
Figure 3.2.2: Power-On Configuration

3.2.3. Refresh Controller
This iblock iis iresponsible ifor igenerating irefresh icycle irequests ifor ithe iattached iSDRAMS. iAll
iSDRAMs iare irefreshed iat ithe isame itime. iWhen iSDRAMs iwith idifferent irefresh icycles iare
iconfigured, ithe ishortest irefresh iinterval iis iused ifor iall iSDRAMs.
Figure 3.2.3: Refresh Controller
3.2.4. Open Bank & Row Tracking

This block iremembers iwhich ibank iand iwhich irow iwithin ia ibank iis ialready iopen. iThis ifeature
iallows ifor ivery ifast iaccess ito ialready iopen irows iwithin ia ibank iand irow. iThis iblock iis ionly iused
iwhen ithe ikro ibit ifor ia ichip iselect iis iset.
Figure 3.2.4: Open Bank & Row Tracking

3.2.5. Data Latch, Packer & Parity
This block is responsible for the data bus connections between the Memory bus and the
WISHBONE bus. Data iThat igoes iout ito ithe iMemory iBus, iis isimply ilatched iat iappropriate itimes.
iData iRead ifrom ithe iMemory ibus, iis ieither ipassed ithrough ia ilatch ito ithe iWISHBONE ibus, ior igoes
ithrough ia idata ipacket ifirst. iThe idata ipacker iassembles ia i32-bit iword ifrom i8 ior i16 ibit iwide idevices
ion ithe imemory ibus.
Figure 3.2.5: Data Latch, Packer & Parity
3.2.6. Memory Timing Controller

This block is responsible for memory timing and control. It performs the appropriate cycles to
access various memories, as defined in the memory Controller configuration registers. This block
also generates control signals for most of the other block.
3.2.7. Memory Interface
The Memory Interface block provides simple synchronization for IOs. All outputs and inputs are
registered at the rising edge of the Memory Clock.
Figure 3.2.6: Memory Interface
3.2.8. Clocks
The Memory Controller utilizes two clocks: 1) ithe imain iwishbone iclock; i2) ithe imemory iclock.
iBoth iclocks iare iused iby ithe icore iinternally. iThe iMemory iclock iis ialso iused iby iexternal imemory
idevices. iTo iavoid isynchronization ibetween ithe iclocks iand ifor ioptimal ioperations, ithe imemory
iclock imust ibe iderived ifrom ithe iWISHBONE iclock iby idividing ithe iWISHBONE iclock iby itwo iand
iphase isynchronizing iit ito ithe iWISHBONE iclock.

3.2.9. Configuration & Status Registers
This block holds all the registers in the Memory Controller. It also generates requests to update
the Mode Register within SDRAMs whenever the value of the TMS register changes. This block
also decodes the actual Chip Select Signals.
Figure 3.2.9: Configuration & Status Registers

CHAPTER 4
VERILOG & SYSTEM VERILOG METHODOLOGY
4.1 HDL
Hardware description language (HDL) is a specialized computer language used to program
electronic and digital logic circuits. The structure, operation and design of the circuits are
programmable using HDL. HDL iincludes ia itextual idescription iconsisting iof ioperators,
iexpressions, istatements, iinputs iand ioutputs. iInstead iof igenerating ia icomputer iexecutable ifile, ithe
i HDL icompilers iprovide ia igate imap. iThe igate imap iobtained iis ithen idownloaded ito ithe
iprogramming idevice ito icheck ithe ioperations iof ithe idesired icircuit. iThe ilanguage ihelps ito idescribe
iany idigital icircuit iin ithe iform iof istructural, ibehavioral iand igate ilevel iand iit iis ifound ito ibe ian
iexcellent iprogramming ilanguage ifor iFPGAs iand iCPLDs.
The three common HDLs are Verilog, VHDL, and System C. Of these, System C is the
newest. The HDLs will allow fast design and better verification. In most of the industries, Verilog
and VHDL are common. Verilog, one of the main Hardware Description Language standardized
as IEEE 1364 is used for designing all types of circuits. It consists of modules and the language
allows Behavioral, Dataflow and Structural Description. VHDL (Very High Speed Integrated
Circuit Hardware Description Language) is standardized by IEEE1164. The design is composed
of entities consisting of multiple architectures. System C is a language that consist a set of
C++classes and macros. It allows electronic system level and transaction modeling.
Below are the HDLs described in detail which we used in our project work.
4.1.1 Verilog
Verilog, standardized as IEEE 1364, is a hardware description language (HDL) used to model
electronic systems. It is most commonly used in the design and verification of digital circuits at
the register-transfer level of abstraction.
It iis ialso iused iin ithe iverification iof ianalog icircuits iand imixed-signal icircuits. iHardware idescription
ilanguages isuch ias iVerilog idiffer ifrom isoftware iprogramming ilanguages ibecause ithey iinclude
iways iof idescribing ithe ipropagation itime iand isignal istrengths i(sensitivity).
iThere iare itwo itypes iof iassignment ioperators; ia iblocking iassignment i(=), iand ia inon-blocking i(<=)
iassignment. iThe inon-blocking iassignment iallows idesigners ito idescribe ia istate-machine iupdate
iwithout ineeding ito ideclare iand iuse itemporary istorage ivariables. iSince ithese iconcepts iare ipart iof
iVerilog's ilanguage isemantics, idesigners icould iquickly iwrite idescriptions iof ilarge icircuits iin ia
irelatively icompact iand iconcise iform. i

At the time of Verilog's introduction (1984), Verilog represented a tremendous productivity
improvement for circuit designers who were already using graphical schematic capture software
and specially written software programs ito idocument iand isimulate ielectronic icircuits. iThe
idesigners iof iVerilog iwanted ia ilanguage iwith isyntax isimilar ito ithe iC iprogramming ilanguage,
iwhich iwas ialready iwidely iused iin iengineering isoftware idevelopment. iLike iC, iVerilog iis icase-
sensitive iand ihas ia ibasic ipreprocessor i(though iless isophisticated ithan ithat iof iANSI iC/C++). iIts
icontrol iflow ikeywords i(if/else, ifor, iwhile, icase, ietc.) iare iequivalent, iand iits ioperator iprecedence iis
icompatible iwith iC. iSyntactic idifferences iinclude: irequired ibit-widths ifor ivariable ideclarations,
idemarcation iof iprocedural iblocks i(Verilog iuses ibegin/end iinstead iof icurly ibraces i{}), iand imany
iother iminor idifferences.
iVerilog irequires ithat ivariables ibe igiven ia idefinite isize. iIn iC ithese isizes iare iassumed ifrom ithe i'type'
iof ithe ivariable i(for iinstance ian iinteger itype imay ibe i8 ibits).
4.1.2 System Verilog
System Verilog, standardized as IEEE 1800, is a hardware description and hardware verification
language used to model, design, simulate, test iand iimplement ielectronic isystems. iSystem iVerilog
iis ibased ion iVerilog iand isome iextensions, iand isince i2008 iVerilog iis inow ipart iof ithe isame iIEEE
istandard. i It iis icommonly i used iin ithe isemiconductor iand ielectronic idesign iindustry ias ian ievolution
iof iVerilog.
System Verilog started with the donation of the Superlog language to Accellera in 2002.The bulk
of the verification functionality is based on the Open Vera language donated by Synopsys. In 2005,
System Verilog was adopted as IEEE Standard 1800-2005. In 2009, the standard was merged with
the base Verilog (IEEE 1364-2005) standard, creating IEEE Standard 1800-2009. The current
version is IEEE standard 1800-2017.
The feature-set of System Verilog can be divided into two distinct roles:
1. System Verilog for register-transfer level (RTL) design is an extension of Verilog-
2005; all features of that language are available in System Verilog. Therefore, Verilog
is a subset of System Verilog.
2. System iVerilog ifor iverification iuses iextensive iobject-oriented iprogramming
itechniques iand iis imore iclosely irelated ito iJava ithan iVerilog. iThese iconstructs iare
igenerally inot isynthesizable. iThe iremainder iof ithis iarticle idiscusses ithe ifeatures iof
iSystem iVerilog inot ipresent iin iVerilog-2005.

i
In ithe idesign iverification irole, iSystem iVerilog iis iwidely iused iin ithe ichip-design iindustry. iThe
ithree ilargest iEDA ivendors i(Cadence iDesign iSystems, iMentor iGraphics, iSynopsys) ihave
iincorporated iSystem iVerilog iinto itheir imixed-language iHDL isimulators. iAlthough ino isimulator
ican i yet iclaim isupport ifor ithe ientire iSystem iVerilog iLRM i[when idefined ias?], imaking itestbench
iinteroperability ia ichallenge, iefforts ito ipromote icross-vendor icompatibility iare iunderway. [when?]
In 2008, Cadence and Mentor released the Open Verification Methodology, an open-source
class-library and usage-framework to facilitate the development of re-usable testbenches and
canned verification-IP. Synopsys, which had been the first to publish a System Verilog class-
library (VMM), subsequently responded by opening its proprietary VMM to the general public.
Many third-party providers have announced or already released System Verilog verification IP.
In the design synthesis role (transformation of a hardware-design description into a gate-netlist),
System Verilog adoption has been slow. Many design teams use design flows which involve
multiple tools from different vendors. Most design teams cannot migrate to System Verilog RTL-
design until their entire front-end tool suite (linters, formal verification and automated test
structure generators) support a common language subset.
4.2 System Verilog Architecture

The iFig-4.2 iis ifor ithe iSystem iVerification iArchitecture ias ican ibe iseen ithere iare ivarious iblocks
iwhich iare ineed ito icoding iin ithe itool, ibut ithe iquestion iis iwhy iVerilog ionly ican ibe iused iand iwhy iin
iwhat iway idoes iSystem iVerilog ihave iadvantage iover iVerilog. iDUT iBlock iis ithe iDevice iunder itest
ii.e. ithe itop imodule ifor iwhich icoding iis idone iby iusing iVerilog. i If iall ithe iremaining iBlocks iare
icoded ivia iVerilog ithen iwe ihave ito iinstantiate icoding iby idefining imodule iname ifor ieach iblock,
imodule ito imodule icommunication iis ivery ihectic ithus iwe idon’t iprefer iVerilog ifor icoding iof iother
iblocks iinstead iprefer iSystem iVerilog. iThe imain ireason iis iSystem iVerilog iincludes iOOPs iconcepts
ithus idefining ieach iblocks icodes iin ia iclass iformat iprovides ieasy iway iof icoding ias icompare ito
iVerilog.
The ifollowing iFigure ican ibe idivided ias itwo iparts ifor imaster iand islave iconfiguration, ithe ileft ihand
iside iis ifor imaster iand ithe iright ihand iside iis ifor ithe islave.Depending upon the no of slave and
master the figure can be modified for different design aspects.
Figure 4.2: System Verilog Architecture

The architecture of System Verilog for memory controller is having the blocks like generator,
BFM or driver, mailbox, monitor, checker, reference model, coverage, score board, slave model
etc.
A. Generator
It generates the transaction. Transactor does the high level operations like burst-operations
into individual commands, sub-layer protocol in layered protocol like PciExpress
Transaction layer over PciExpress iData iLink iLayer, iTCP/IP iover iEthernet ietc. iIt ialso
ihandles ithe iDUT iconfiguration ioperations. iThis ilayer ialso iprovides inecessary iinformation
ito icoverage imodel iabout ithe istimulus igenerated. iStimulus igenerated iin igenerator iis ihigh
ilevel ilike iPacket iis iwith igood icrc, ilength iis i5 iand ida, iis i8h0. iThis ihigh ilevel istimulus iis
iconverted iinto ilow-level idata iusing ipacking. iThis ilow ilevel idata iis ijust ian iarray iof ibits ior
ibytes. iCreates itest iscenarios iand itests ifor ithe ifunctionality iand iidentifies ithe itransaction
ithrough ithe iinterface. I
B. BFM or Driver
It converts transaction level to pin level. The drivers translate the operations produced by
the generator into the actual inputs for the design under verification. Generators icreate
iinputs iat ia ihigh ilevel iof iabstraction inamely, ias itransactions ilike iread iwrite ioperation. iThe
idrivers iconvert ithis iinput iinto iactual idesign iinputs, ias idefined iin ithe ispecification iof ithe
idesigns iinterface i[2]. iIf ithe igenerator igenerates iread ioperation, ithen iread itask iis icalled, iin
ithat, ithe iDUT iinput ipin i"read iwrite" iis iasserted. I
C. Monitor
It helps to monitor or manage the valid signals at interface. It has read only capabilities.
Monitor reports the protocol violation and identifies all the transactions. Monitors are two
types, Passive and active. iPassive imonitors ido inot idrive iany isignals i[2]. iActive imonitors
ican idrive ithe iDUT isignals. iSometimes ithis iis ialso ireferred ias ireceiver. iMonitor iconverts
ithe istate iof ithe idesign iand iits ioutputs ito ia itransaction iabstraction ilevel iso iit ican ibe istored iin
ia i'score-boards' idatabase ito ibe ichecked ilater ion. iMonitor iconverts ithe ipin ilevel iactivities iin
ito ihigh ilevel. i
D. Checker i
It ichecks ior icompare ithe itransaction. iThe imonitor ionly imonitors ithe iinterface iprotocol. iIt
idoesn't icheck ithe iwhether ithe idata iis isame ias iexpected idata ior inot, ias iinterface ihas inothing
ito ido iwith ithe idata. iChecker iconverts ithe ilow ilevel idata ito ihigh-level idata iand ivalidated ithe
idata i[2]. iThis ioperation iof iconverting ilow-level idata ito ihigh-level idata iis icalled
iUnpacking, iwhich iis ireverse iof ipacking ioperation. iFor iexample, iif idata iis icollected ifrom
iall ithe icommands iof ithe iburst ioperation iand ithen ithe idata iis iconverted iin ito iraw idata, iand
iall ithe isub ifields iinformation iare iextracted ifrom ithe idata iand icompared iagainst ithe
iexpected ivalues. iThe icomparison istate iis isent ito iscoreboard.

E. Mailbox
A mailbox is a communication mechanism that allows messages to be exchanged between
processes or threads [2]. Data can be sent to a mailbox by one process and retrieved by
another.
F. Reference model
It is basically high level language. It gives the expecting transaction to the checker.
G. Scoreboard
It keeps track the number of transaction initiated and whether the transaction passed or fail.
H. Coverage
Coverage is defined as the percentage of verification objectives that have been met. The functional
coverage routines and methods will allow users to gather information about the stimulus as well
as the standard protocols. iUsers iof iVIP iwill iuse ithe iprovided icoverage iobject ias itemplate iand iadd
itheir iown icoverage idefinitions i[2]. iThe isame iapproach ias idescribed ifor imonitors ican ibe iused iin
ithis icase. iThat imeans icreating ia ivirtual ibased iclass ithat icould ibe iextended iby iusers’ idefined-
classes. iCoverage iobjects ican ibe idefined iin ithis ivirtual ibased iclass iand ican ibe iturned i“OFF” iby
idefault. iAll iVerification iIP ilayers ishould ibe iable ito iaccess ithese iobjects ithrough iappropriate
imethods i[2].
4.3 Verification Steps
(I) Features posting depressed.

(ii) Scenario posting depressed.
(iii) Test plan improvement.
(iv) Functional Coverage Point posting depressed.
(v) Test-seat engineering meaning.
(vi) Test-seat segment encoding.
(vii) Sanity experiment advancement.
(viii) Sanity experiment raise.
(ix) Other experiments.
(x) Setting up relapse.
(xi) Running relapse and investigating relapse outcomes.
(xii) Generating inclusion outcomes.
(xiii) Analyze inclusion outcomes.
(xiv) Closing utilitarian Attention.
4.4 SV Verification Tools
There are many companies which provides simulating advanced verification tools namely
QuestaSim, ModelSim, Xilinx, Cadence etc.
Usually the tools work in 3 steps which includes:

(i) Compilation.
(ii) Elaboration.
(iii) Simulation.
Tool like QuestaSim has an inbuilt writing notepad otherwise the code written in a separate
notepad can be linked to the tools. For every Design prospective we need to create a new project
in the tool and make sure all the required libraries linked to the directories are included for the
same project.
CHAPTER 5
CODES
Mc_tb_top:
program mc_tb_top();
mc_env env;
initial begin
env = new();
env.run();
end
endprogram: mc_tb_top
mc_environement:
class mc_env;
wb_env wb_env_h;
mem_monitor m_mon_h;
mc_ref ref_model_h;
mem_checker checker_h;
// construct components
function new();
wb_env_h = new();
m_mon_h = new();
ref_model_h = new();
checker_h = new();
endfunction: new
task run();
$display("mc_env run task");
fork
wb_env_h.run();
m_mon_h.run();
ref_model_h.run();
checker_h.run();
join
endtask: run
endclass: mc_env
mc_transaction:
class mc_tx;
bit [23:0] addr;
bit [1:0] mem_type;
bit wr_rd;
// bit [31:0] data[$];
bit [31:0] data;
bit [1:0] bw; // bus width
// bit [31:0] wdata[$];
// bit [31:0] rdata[$];
function bit compare(mc_tx tx);

begin
if(tx.addr != addr)
return 0;
else if(tx.mem_type != wr_rd)
return 0;
else if(tx.bw != bw)
return 0;
else if(tx.wr_rd != wr_rd)
return 0;
else
return 1;
end
endfunction
endclass
mc_register:
class csr_reg;
bit [7:0] ref_prescalar;
bit [2:0] ref_int;
bit fs;
bit fvpen;
function write(bit [31:0] data);

ref_prescalar = data[31:24];
ref_int = data[10:8];
fs = data[2];
fvpen = data[1];
endfunction: write
function bit [31:0] read();
return {ref_prescalar[7:0],13'b0,ref_int[2:0], 5'b0,fs, fvpen,1'b0};
endfunction: read
endclass: csr_reg
class ba_mask_reg;
bit [7:0] mask;
function write(bit [31:0] data);

mask = data[7:0];
endfunction
function bit [31:0] read();

return {24'h0,mask};
endfunction
endclass : ba_mask_reg
class csc_reg;
bit [7:0] sel;
bit pen;
bit kro;
bit bas;
bit wp;
bit [1:0] ms;
bit [1:0] bw;
bit [2:0] mem_type;
bit en;
function iwrite(bit i[31:0] idata);

iiii $display("csc_reg iwrite ifunction");
i i i isel i= idata[23:16];
i i i ipen i= idata[11];
i i i ikro i= idata[10];
i i i ibas i= idata[9];
i i i iwp i i= idata[8];
i i i ims i i= idata[7:6];
i i i ibw i i= idata[5:4];
i i i imem_type i= idata[3:1];
i i i ien i= idata[0];
i iendfunction
ii function ibit i[31:0] iread();

iiiireturn i{8'h00, isel, i4'h0, ipen, ikro, ibas, iwp, ims, ibw, imem_type, ien};
i iendfunction
endclass: icsc_reg
class itms_reg_sdram;
i i// i`ifdef iCS0_SDRAM_CONNECTED
i ibit i[3:0] itrfc;
i ibit i[3:0] itrp;
i ibit i[2:0] itrcd;
i ibit i[1:0] itwr;
i ibit iwrite_bl;
i ibit i[1:0] ioper_mode;
i ibit i[2:0] icas_lat;
i ibit i i i i i i ibt;
i ibit i[2:0] ibl;
ii function iwrite(bit i[31:0] idata);

iiiii trfc i= idata[27:24];
i i i i itrp i i= idata[23:20];
i i i i itrcd i= idata[19:17];
i i i i itwr i i= idata[16:15];
i i i i iwrite_bl i= idata[9];
i i i i ioper_mode i= idata[8:7];
i i i i icas_lat i= idata[6:4];
iiiiibt i= idata[3];
iiiiibl i= idata[2:0];
i iendfunction

iiiireturn i{'h40, itrfc, itrp, itrcd, itwr, i5'h00, iwrite_bl, ioper_mode, icas_lat, ibt, ibl};
i iendfunction i: iread
endclass i: itms_reg_sdram
class itms_reg_async_cs;
i ibit i[5:0] itwwd;
i ibit i[3:0] itwd;
i ibit i[3:0] itwpw;
i ibit i[3:0] itrdz;
i ibit i[7:0] itrdv;

iiiii twwd i= idata[25:20];
i i i i itwd i i= idata[19:16];
i i i i itwpw i= idata[15:12];
i i i i itrdz i= idata[11:8];
i i i i itrdv i= idata[7:0];
ii endfunction

iiiiireturn i{6'h0,twwd, itwd, itwpw, itrdz, itrdv};
i iendfunction
endclass: itms_reg_async_cs
class itms_reg_sync_cs;
i ibit i[8:0] itto;
i ibit i[3:0] itwr;
i ibit i[3:0] itrdz;
i ibit i[7:0] itrdv;

iiii tto i i= idata[24:16];
i i i itwr i i= idata[15:12];
i i i itrdz i= idata[11:8];
i i i itrdv i= idata[7:0]; i
i iendfunction

iiiireturn i{7'h0,tto,twr,trdz,trdv};
i iendfunction
endclass: itms_reg_sync_cs
class imc_reg;
ii csr_reg icsr;
i iba_mask_reg iba_mask;
i icsc_reg icsc[8];
i itms_reg_sdram itms_sdram[8];
i i// itms_reg_sram itms_sram[8];
i itms_reg_sync_cs itms_sync_cs[8];
i itms_reg_async_cs itms_async_cs[8];
i ibit i[28:0] iaddr_t;
i ievent iconfig_e;
ii // iThe icovergroups iare ideclared iinside ireg imodel iitself.

ii covergroup imc_config_cg i@(config_e); i
i i i i iREF_SCALAR_CP i: icoverpoint icsr.ref_prescalar iiff(addr_t i== i29'h0) i{
i i i i i i i i i i ibins iLOW i= i{[10:50]};
i i ibins iMID i= i{[50:95]};
i i ibins iMID_96 i= i{96};
i i ibins iHIGH i i i= i{[99:255]};
i i i i i}
i i i i iREF_INT_CP i: icoverpoint icsr.ref_int iiff(addr_t i== i29'h0); i// i8 ibins
i i i i iFS_CP i: icoverpoint icsr.fs iiff(addr_t i== i29'h0);
i i i i iVPEN_CP i: icoverpoint icsr.fvpen iiff(addr_t i== i29'h0);
i i i i iMASK_CP i: icoverpoint iba_mask.mask iiff(addr_t i== i29'h8) i{
i i i i ioption.auto_bin_max i= i8;
i i i i i}
i i i i iCSC0_SEL_CP i: icoverpoint icsc[0].sel iiff(addr_t i== i29'h10) i{
i i i i ioption.auto_bin_max i= i8;
i i i i i}
i i i i iCSC0_PEN_CP i: icoverpoint icsc[0].pen iiff(addr_t==29'h10);
i i i i iCSC0_KRO_CP i: icoverpoint icsc[0].kro iiff(addr_t==29'h10);
i i i i iCSC0_BAS_CP i: icoverpoint icsc[0].bas iiff(addr_t==29'h10);
i i i i iCSC0_WP_CP i: icoverpoint icsc[0].wp iiff(addr_t==29'h10);
i i i i iCSC0_MS_CP i: icoverpoint icsc[0].ms iiff(addr_t==29'h10) i{
i i i i iignore_bins iING i= i{2'b11};
i i i i i}
i i i i iCSC0_BW_CP i: icoverpoint icsc[0].bw iiff(addr_t==29'h10) i{
i i i i iignore_bins iING i= i{2'b11};
i i i i i}
i i i i iCSC0_MEM_TYPE_CP i: icoverpoint icsc[0].mem_type iiff(addr_t==29'h10) i{
i i i ibins iSDRAM i= i{0};
i i i ibins iSSRAM i= i{1};
i i i ibins iFLASH i= i{2};
i i i ibins iSCSD i i= i{3};
i i i iignore_bins iING i= i{[4:7]};
i i i i i} i
i i i i icross iCSC0_MEM_TYPE_CP, iCSC0_MS_CP;
i i i i iCSC0_EN_CP i: icoverpoint icsc[0].en iiff(addr_t i== i29'h10);

ii endgroup
ii function inew();
iiii mc_config_cg i= inew();
i i i icsr i= inew();
i i i iba_mask i= inew();
i i i icsc[0] i= inew();
i i i itms_sdram[0] i= inew();
i i i itms_sync_cs[0] i= inew();
i i i itms_async_cs[0] i= inew();
i iendfunction i
ii function iwrite_reg(bit i[31:0] iaddr, ibit i[31:0] idata);

i i i i$display("Reg iis iupdated iat iaddr i= i%h", iaddr);
i i i iif(addr[28:0] i== i29'h0) icsr.write(data);
i i i iif(addr[28:0] i== i29'h8) iba_mask.write(data);
iiii if(addr[28:0] i== i29'h10) icsc[0].write(data);

iiii if(addr[28:0] i== i29'h14 i&& i(csc[0].mem_type i==0)) i
i i i i i itms_sdram[0].write(data);
i i i iif(addr[28:0] i== i29'h14 i&& i(csc[0].mem_type i==2)) i
i i i i i itms_async_cs[0].write(data);

iiiiii tms_sync_cs[0].write(data);

iiii // iif(addr[28:0] i== i29'h1C) itms1.write(data);
i i i iif(addr[28:0] i== i29'h1C i&& i(csc[1].mem_type i==0)) i
i i i i i itms_sync_cs[1].write(data);

iiii // iif(addr[28:0] i== i29'h24) itms2.write(data);




iiii if(addr[28:0] i== i29'h44 i&& i(csc[6].mem_type i==2)) i
iiiiii tms_async_cs[6].write(data);

iiiiaddr_t i= iaddr[28:0];
iiii-> iconfig_e;
i iendfunction: iwrite_reg
ii function ibit i[31:0] iread_reg(bit i[31:0] iaddr);

iiii if(addr[28:0] i== i29'h0) ireturn icsr.read();
i i i iif(addr[28:0] i== i29'h8) ireturn iba_mask.read();
i i i iif(addr[28:0] i== i29'h10) ireturn icsc[0].read();
i i i iif(addr[28:0] i== i29'h14 i&& i(csc[0].mem_type==0)) ireturn itms_sdram[0].read();
i i i iif(addr[28:0] i== i29'h14 i&& i(csc[0].mem_type==2)) ireturn itms_async_cs[0].read();
i i i iif(addr[28:0] i== i29'h14 i&& i(csc[0].mem_type==3)) ireturn itms_sync_cs[0].read();
iiii if(addr[28:0] i== i29'h18) ireturn icsc[1].read();

iiii // iif(addr[28:0] i== i29'h1C) ireturn itms1.read();
i i i iif(addr[28:0] i== i29'h1C i&& i(csc[1].mem_type==0)) ireturn itms_sdram[1].read();
i i i iif(addr[28:0] i== i29'h1C i&& i(csc[1].mem_type==2)) ireturn itms_async_cs[1].read();
i i i iif(addr[28:0] i== i29'h1C i&& i(csc[1].mem_type==3)) ireturn itms_sync_cs[1].read();

iiii // iif(addr[28:0] i== i29'h24) ireturn itms2.read();



iiii if(addr[28:0] i== i29'h3C i&& i(csc[5].mem_type==0)) ireturn itms_sdram[5].read();


ii endfunction: iread_reg
endclass: imc_reg
mc_reference:
class imc_ref;
i i// i1. itransaction iwill icome ifrom iwb imonitor ito iref imodel.
i i// i2. ienable imc_reg ilayer ihere ifor iwriting iinto imc_reg iand ifor icollecting icoverage.
i i// i3. iidentify iwhether ithe itx iis ifor iregisters ior ifor imemory, iif imemory iconvert ithe itransaction iinto imem
itransaction itype iand isend iit ito ichecker iusing imailbox.
i imc_reg imc_reg_i;
i imc_tx imc_tx_i;
i iwb_tx itx;
i ifunction inew();
i i i imc_reg_i i= inew();
i iendfunction
ii task irun();
iiii bit i[31:0] icsc_value, itms_value;
i i i ibit i[2:0] imem_type, ics_target;
i i i ibit i[1:0] ibw;
iiii forever ibegin

iiiiii mc_config::wb_mon2ref.get(tx);
i i i i i iif i(tx.wr_rd i== i1) ibegin
icase i(tx.wb_addr_i[31:29])
i i i3'b011 i: ibegin
i i i i i imc_reg_i.write_reg(tx.wb_addr_i,tx.wb_data); i// iRegister iaccess
i i i i i i$display("mc_ref iwriting ito ireg" i);
i i i iend
i i i3'b000 i: ibegin i// imemory iaccess
i i i i i// igenerate iaddress ibased ion itarget imemory
i i i i i//1. iIdentify iCS itargetted?
i i i i i// iwrite ia ifunction ito iwhich ireturn itype iis ics_used iand ithe iinput iargument iis ithe iwb_addr
iiiii mc_config::ref2mem_mon.put(mc_reg_i);
iiiii cs_target i= ics_used(tx.wb_addr_i);
i i i i i//2. iIdentify imemory itype iattached ito ics?
i i i i icsc_value i= imc_reg_i.read_reg(`CSC_ADDR+32'h10+cs_target*8);
i i i i itms_value i= imc_reg_i.read_reg(`CSC_ADDR+32'h14+cs_target*8);
i i i i imem_type i= icsc_value[3:1];
i i i i ibw i= icsc_value[5:4];
i i i i i//3. iis ithat iCS iis ienabled?
i i i i iif i(csc_value[0]!=1)
i i i i i i i i$display("ERROR iCS iis inot ienabled");
i i i i i//4. icalculate iaddress iand icollect ifor imem itransaction.
i i i i i i imc_tx_i i= inew();
i i i i i i i i i i i i i i imc_tx_i.addr i= icalc_addr(tx.wb_addr_i, imem_type, ibw);
i i i i i i imc_tx_i.wr_rd i= itx.wr_rd;
i i i i i i imc_tx_i.data i= itx.wb_data;
i i i i i i imc_tx_i.mem_type i= imem_type;
i i i i i i imc_tx_i.bw i= ibw; i
i i i i i//5. isend icollected itransaction ito ichecker.
i i i i i i i i i i i i i i imc_config::ref2ckr.put(mc_tx_i);
iiiiiiiiiii end
i i i i i i i i iendcase
i i i i i i iend
i i i i iend
i iendtask
ii // iWe ineed ito iidentify ithe iba_mask ivalue iand i& iwith icsc iregister isel ifield.
i i// ithe iaddr[28:21] ivalue imatch iwith iba_mask i&& icsc.sel ivalue.
i ifunction ibit i[2:0] ics_used(bit i[31:0] iaddr);
i i i ibit i[31:0] irdata;
i i i irdata i= imc_reg_i.read_reg(`BA_MASK_ADDR);
i i i iif i((rdata[7:0] i& imc_reg_i.csc[0].sel) i== iaddr[28:21]) ireturn i0;
i iendfunction i
ii function ibit i[23:0] icalc_addr(bit i[31:0] iaddr, ibit i[2:0] imem_type, ibit i[1:0] ibw);
iiii case(mem_type)
i i i i i i`SDRAM i: ibegin
i i i i i iend
i i i i i i`SSRAM: ibegin
i i i i i i// iaddr_t i= iaddr[25:2];
i i i i i ireturn i{addr[25:2]};
i i i i i iend
i i i i i i`ASCD: ibegin
iiiiii end
iiiiii `SSCD: ibegin
i i i i i iend
i i i iendcase
i iendfunction
endclass
mc_interface:
interface imem_intf(input imc_clk);
i ibit imc_br;
i ibit imc_bg;
i ibit imc_ack;
i ibit i[23:0] mc_addr;

i ibit i[31:0] mc_data_i;
i ibit i[31:0] mc_data_o;
i ibit i[3:0] mc_dp_i;
i ibit i[3:0] mc_dp_o;
i ibit imc_doe;
i ibit i[3:0] mc_dqm;

i ibit imc_oe;
i ibit imc_we;
i ibit imc_cas;
i ibit imc_ras;
i ibit imc_cke;
i ibit i[7:0] mc_cs;

i ibit imc_sts;
i ibit imc_rp;
i ibit imc_vpen;
i ibit imc_adsc;
i ibit imc_adv;
i ibit imc_zz;
i ibit imc_coe;
endinterface
mc_monitor:
class imem_monitor;
ii virtual imem_intf imvif;
ii mc_tx itx;
ii mc_reg imc_reg_i;
task irun();
ii
iiii bit i[1:0] imem_type;

iiii bit i[2:0] iactive_cs;
iiii mvif i= imc_config::mvif;
iiii // imc_reg_i i= inew();
// i2 ithreads iin iparallel, i1 ifor icollecting isynchronous idata iand i2nd ifor icollecting iasynchronous idata.
iiii
iiiiii mc_config::ref2mem_mon.get(mc_reg_i);
iiiiii forever ibegin
// isynchronous imemories
// iReg imodel iis iused ito iidentify imem_type i
// i$display("Mem_monitor idisplay i= i%t", i$time);
@(posedge imvif.mc_clk);
active_cs i= iget_active_cs(mvif.mc_cs);
if(mvif.mc_cs[active_cs] i==0) ibegin
iiii mem_type i i= imc_reg_i.csc[active_cs].mem_type;
iiii $display("Mem_monitor idisplay imem_type=%d", imem_type);
iiii case(mem_type)
iiiiiiiiiiiii `SDRAM: ibegin
//TODO
i
iiiii end
iiiiiiiiiiiii `SSRAM: ibegin
tx i= inew();
i
tx.mem_type i= i`SSRAM;
i
tx.addr i= imvif.mc_addr;
i
i $display("SSRAM i");
//case i(mvif.mc_we)
i
// i i0: ibegin
i
//
i while(mvif.mc_we i!=1) ibegin
// i i i i i i i i i@(posedge imvif.mc_clk);
i
// i i i i i i i i itx.wdata.push_back(mvif.mc_dq);
i
iiiiiiiii// i i i i i i i i imc_config::mem_mon2ckr.put(tx);
// i i i i i i iend
i
// i i i i iend
i
iiiiiiiii// i i1: ibegin

//
i while(mvif.mc_oe i!=1) ibegin
// i i i i i i i i i@(posedge imvif.mc_clk);
i
// i i i i i i i i itx.rdata.push_back(mvif.mc_dq);
i
iiiiiiiii// i i i i i i i i imc_config::mem_mon2ckr.put(tx);
// i i i i i i iend
i
iiiiiiiii// i i i i iend
// iendcase
i
if(mvif.mc_adsc==0 i&& imvif.mc_doe i== i1) ibegin

i
iii @(posedge imvif.mc_clk);

iii tx.addr i= imvif.mc_addr;
iii tx.data i= imvif.mc_data_o;
iiiiiiiiiii mc_config::mem_mon2ckr.put(tx);
i end
iiiiiiiiiiiiiii end
iii endcase
end
iiiiii end
ii endtask: irun i
i function iint iget_active_cs(bit i[7:0] ics);

iii case i(cs)
8'b1111_1110 i: ireturn i0;
8'b1111_1101 i: ireturn i1;
8'b1111_1011 i: ireturn i2;
8'b1111_0111 i: ireturn i3;
8'b1110_1111 i: ireturn i4;
8'b1101_1111 i: ireturn i5;
8'b1011_1111 i: ireturn i6;
8'b0111_1111 i: ireturn i7;
//default i: i$display("mem_monitor iERROR");
iii endcase
i endfunction
i function iint iget_active_cs_temp(bit i[7:0] ics);
iii case i(cs)
8'b0000_0001 i: ireturn i0;
8'b0000_0010 i: ireturn i1;
8'b0000_0100 i: ireturn i2;
8'b0000_1000 i: ireturn i3;
8'b0001_0000 i: ireturn i4;
8'b0010_0000 i: ireturn i5;
8'b0100_0000 i: ireturn i6;
8'b1000_0000 i: ireturn i7;
//default i: i$display("mem_monitor iERROR");
iii endcase
i endfunction
endclass: imem_monitor
mc_configuration:
`define iSDRAM i0
`define iSSRAM i1
`define iASCD i2
`define iSSCD i3
`define iCSC_ADDR i32'h00000000

`define iBA_MASK_ADDR i32'h00000008
`define iCSR_REG i32'h60000000

`define iPOC_REG i32'h60000004
`define iBA_MASK_REG i32'h60000008
`define iCSC0_REG i32'h60000010
`define iTMS0_REG i32'h60000014
`define iTMS1_REG i32'h6000001C
// iAddess iranges
`define iCS0_START i32'h0020_0000
`define iCS0_END i i i32'h003F_FFFF
`define iCS1_START i32'h0040_0000 i
class mc_config;
static virtual wb_intf wvif;
static virtual mem_intf mvif;
static mailbox gen2bfm = new();
static mailbox bfm2gen = new();
static mailbox wb_mon2ref = new();
static mailbox wb_mon2cov = new();
static mailbox ref2ckr = new();
static mailbox ref2mem_mon = new();
static mailbox mem_mon2ckr = new();
static string testcase;
static event e;
static bit [31:0] reg_mask[19] = {{8'hff,13'h0000, 3'h7, 5'h0, 1'b1, 1'b1, 1'b0},
32'h0,
{24'h0,8'hff},
{8'h0,8'hff,4'h0,1'b1,1'b1,1'b1,1'b1,2'b11,2'b11,3'b111,1'b1},
'hffffffff,
{8'h0,8'hff,4'h0,1'b1,1'b1,1'b1,1'b1,2'b11,2'b11,3'b111,1'b1},
'hffffffff,
{8'h0,8'hff,4'h0,1'b1,1'b1,1'b1,1'b1,2'b11,2'b11,3'b111,1'b1},
'hffffffff,
{8'h0,8'hff,4'h0,1'b1,1'b1,1'b1,1'b1,2'b11,2'b11,3'b111,1'b1},
'hffffffff,
{8'h0,8'hff,4'h0,1'b1,1'b1,1'b1,1'b1,2'b11,2'b11,3'b111,1'b1},
'hffffffff,
{8'h0,8'hff,4'h0,1'b1,1'b1,1'b1,1'b1,2'b11,2'b11,3'b111,1'b1},
'hffffffff,
{8'h0,8'hff,4'h0,1'b1,1'b1,1'b1,1'b1,2'b11,2'b11,3'b111,1'b1},
'hffffffff,
{8'h0,8'hff,4'h0,1'b1,1'b1,1'b1,1'b1,2'b11,2'b11,3'b111,1'b1},
32'hffffffff
};
endclass: mc_config
mc_checker:
class scoreboard;
int match;
int mismatch;
function new();
match = 0;
mismatch = 0;
endfunction
endclass
class mem_checker;
// collect the transactions from both ref model and mem monitor
// compare both
mc_tx tx_exp, tx_act;
mc_tx tx_exp1, tx_act1;
mc_tx exp_txQ[$];
mc_tx act_txQ[$];
scoreboard sb_inst;
function new();
sb_inst =new();
endfunction
task run();
bit comp_f;
fork
while(1) begin
tx_exp = new();
mc_config::ref2ckr.get(tx_exp);
$display("run task ref2ckr");
exp_txQ.push_back(tx_exp);
end
while(1) begin
tx_act = new();
mc_config::mem_mon2ckr.get(tx_act);
$display("run task mem_mon2ckr");
act_txQ.push_back(tx_act);
end
// comparison
while(1) begin
wait(exp_txQ.size > 0 && act_txQ.size > 0);
$display("mem_checker compare loop");
tx_exp1 = exp_txQ.pop_front();
tx_act1 = act_txQ.pop_front();
// comp_f = tx_exp1.compare(tx_act1);
// if(comp_f == 1) begin
if((tx_exp1.data == tx_act1.data) && (tx_exp1.addr == tx_act1.addr)) begin
$display("MC_TX comparison maatched data = %h, data=%h", tx_exp1.data, tx_act1.data);
$display("MC_TX comparison maatched addr = %h, addr=%h", tx_exp1.addr, tx_act1.addr);
sb_inst.match++;
end
else begin
$display("MC_TX comparison failed");
sb_inst.mismatch++;
end
end
join_any
endtask: run
endclass: mem_checker
WB_tx:
class wb_tx;
rand bit [31:0] wb_addr_i;
rand bit [31:0] wb_data;
rand bit wr_rd;
rand bit reg_mem_f;
function print();
$display("wr_rd %h at time=%t", wr_rd, $time);
$display("wb_addr_i %h", wb_addr_i);
$display("wb_data %h", wb_data);
endfunction
constraint addr_range {
(reg_mem_f==1) -> (wb_addr_i[31:29]=='b011);
(reg_mem_f==0) -> (wb_addr_i[31:29]=='b0);
}
endclass: wb_tx
Wb_generator:
class wb_gen;
wb_tx tx, txQ[$], rx;
task run();
bit [31:0] wrdata,data_t;
@(mc_config::e);
$display("WB_GEN run task");
case(mc_config::testcase)
"mc_reset_read_reg": begin
for(int i=0;i<3;i++) begin
tx = new();
tx.randomize() with {reg_mem_f==1; wb_addr_i[28:0]==i*4; wr_rd==0;};
mc_config::gen2bfm.put(tx);
end
for(int i=4;i<=19;i++) begin

tx = new();
end
end
"mc_write_read": begin
// Write
tx = new();
tx.wb_data = tx.wb_data & mc_config::reg_mask[i];
end

tx = new();
tx.wb_data = tx.wb_data & mc_config::reg_mask[i];
end
// Read
tx = new();
end

tx = new();
end
end
"sanity_sram_write_read": begin
//BA_MASK register
tx = new();
tx.randomize() with {wb_addr_i==`BA_MASK_REG; wr_rd==1; wb_data=='hFF;};
// CSC0 register
tx = new();
wrdata = {8'h00,8'h01,4'h0,1'b0,1'b0,1'b0,1'b0,2'b0,2'b1,3'b1, 1'b1 };
tx.randomize() with {wb_addr_i==`CSC0_REG; wr_rd==1; wb_data == wrdata;};
// CSC1 register
tx = new();
// CSC2 register
tx = new();
// CSC3 register
tx = new();
// CSC4 register
tx = new();
// CSC5 register
tx = new();
// CSC6 register
tx = new();
// CSC7 register
tx = new();

tx = new();
// tx.randomize() with {wr_rd==1; wb_addr_i inside
{[`CS0_START:`CS0_END],[`CS1_START:`CS1_END],[`CS2_START:`CS2_END],[`CS3_START:`C
S3_END],[`CS4_START:`CS4_END],[`CS5_START:`CS5_END],[`CS6_START:`CS6_END],[`CS7_S
TART:`CS7_END]};};
tx.randomize() with {wr_rd==1; wb_addr_i inside {[`CS0_START:`CS0_END]};};
txQ.push_back(tx);
end
tx = new();
tx.randomize() with {wr_rd==0; wb_addr_i ==txQ[i].wb_addr_i;};
mc_config::bfm2gen.get(rx);
if(txQ[i].wb_data != rx.wb_data) begin
$display("ERROR: data mismatch, write_data=%h, read_data=%h",txQ[i].wb_data,
rx.wb_data);
end
else
$display("data matched, write_data=%h, read_data=%h",txQ[i].wb_data, rx.wb_data);
end
end
"sanity_sdram_write_read": begin
//BA_MASK, CSC0 registers
tx = new();
tx.randomize() with {wr_rd == 1; wb_addr_i == `BA_MASK_REG;
wb_data == 8'hFF;};
//CSC0
tx = new();
data_t = {8'h0, 8'h01, 4'h0, 1'b0, 1'b0, 1'b0, 1'b0, 2'b0, 2'b10, 3'b0, 1'b1};
tx.randomize() with {wr_rd == 1; wb_addr_i == `CSC0_REG; wb_data
== data_t;};
//TMS0
tx = new();
data_t = {4'h0, 4'hF, 4'hF, 3'h7, 2'h3, 5'h0, 1'b1, 2'b0, 3'h2, 1'b0, 3'h0};
tx.randomize() with {wr_rd == 1; wb_addr_i == `TMS0_REG; wb_data
== data_t;};
tx = new();
== data_t;};
//TMS1
tx = new();
== data_t;};
tx = new();
== data_t;};
//TMS2
tx = new();
== data_t;};
tx = new();
== data_t;};
//TMS3
tx = new();
== data_t;};
tx = new();
== data_t;};
//TMS4
tx = new();
== data_t;};
tx = new();
== data_t;};
//TMS5
tx = new();
== data_t;};
tx = new();
== data_t;};
//TMS6
tx = new();
== data_t;};
//CSC7
tx = new();
== data_t;};
//TMS7
tx = new();
== data_t;};
//CS0 : sram connected

//ba_mask & csc0.sel === addr[28:21] => CS0 is selected
//ba_mask & csc1.sel === addr[28:21] => CS1 is selected..so on
for (int i = 0; i < 10; i++) begin
tx = new();
tx.randomize() with {reg_mem_f == 0; wb_addr_i inside {
[`CS0_START : `CS0_END]
//[`CS7_START : `CS7_END],
//[`CS1_START : `CS1_END]
/*
[`CS0_START : `CS0_END],
[`CS7_START : `CS7_END]
*/
};
wr_rd == 1;};
txQ.push_back(tx);
end
for (int i = 0; i < 10; i++) begin
tx = new();
tx.randomize() with {reg_mem_f == 0; wb_addr_i ==
txQ[i].wb_addr_i; wr_rd == 0;};
$display("ERROR: data mismatch, write_data=%h,
read_data=%h",txQ[i].wb_data, rx.wb_data);
end
else
$display("data matched, write_data=%h, read_data=%h",txQ[i].wb_data,
rx.wb_data);
end
end
"sync_cs_write_read": begin
//BA_MASK register
tx = new();
// CSC0 register
tx = new();
// TMS0 register
tx = new();
//wrdata = {4'h0,4'h0,4'h0,3'b00,2'b00,5'b0,1'b1,2'b0,3'b10,1'b1,3'b0};
wrdata = {7'h0,9'hff, 4'h2, 4'h5, 8'h5};
tx.randomize() with {wb_addr_i==`TMS0_REG; wr_rd==1; wb_data == wrdata;};
tx = new();
//tx.randomize() with {wr_rd==1; wb_addr_i inside
TART:`CS7_END]};};
txQ.push_back(tx);
end
tx = new();
TART:`CS7_END]};};
tx.randomize() with {wr_rd==0; wb_addr_i == txQ[i].wb_addr_i;};
end
end
"async_cs_write_read": begin
//BA_MASK register
tx = new();
// CSC0 register
tx = new();
// TMS0 register
tx = new();
//wrdata = {4'h0,4'h0,4'h0,3'b00,2'b00,5'b0,1'b1,2'b0,3'b10,1'b1,3'b0};
wrdata = {6'h0,6'h3, 4'h2, 4'h5, 4'h2, 8'h5};
tx.randomize() with {wb_addr_i==`TMS0_REG; wr_rd==1; wb_data == wrdata;};
tx = new();
TART:`CS7_END]};};
tx.randomize() with {wr_rd==1; wb_addr_i inside {[`CS0_START:`CS0_END]};
wb_addr_i[1:0]==0;};
txQ.push_back(tx);
end
tx = new();
TART:`CS7_END]};};
tx.randomize() with {wr_rd==0; wb_addr_i == txQ[i].wb_addr_i;};
end
end
"sanity_sram_cs0_write_read": begin
//BA_MASK register
tx = new();
// CSC0 register
tx = new();
#100;
tx = new();
// tx.randomize() with {wr_rd==1; wb_addr_i inside
TART:`CS7_END]};};
txQ.push_back(tx);
end
#200;
tx = new();
tx.randomize() with {wr_rd==0; wb_addr_i ==txQ[i].wb_addr_i;};
$display("ERROR: data mismatch, write_data=%h, read_data=%h",txQ[i].wb_data,
rx.wb_data);
end
else
$display("data matched, write_data=%h, read_data=%h",txQ[i].wb_data, rx.wb_data);
end
end
endcase
endtask: run
endclass: wb_gen
Wb_driver:
class wb_bfm;
virtual wb_intf wvif;
wb_tx tx;
task run();
bit wb_ack_f;
wvif = mc_config::wvif;
@(negedge wvif.wb_rst);
forever begin
wb_ack_f = 1;
//if (wvif.wb_rst==0) begin
@(posedge wvif.wb_clk);
$display("wb_bfm run task entered");
// tx = new();
mc_config::gen2bfm.get(tx);
wvif.wb_addr = tx.wb_addr_i;
wvif.wb_cyc = 1'b1;
wvif.wb_sel = 'hf;
wvif.wb_stb = 1'b1;
if(tx.wr_rd) begin
wvif.wb_data_i = tx.wb_data;
end
wvif.wb_we = tx.wr_rd;
while(wb_ack_f) begin
if(wvif.wb_ack) begin
wb_ack_f = 0;
if(!tx.wr_rd) begin
tx.wb_data = wvif.wb_data_o;
mc_config::bfm2gen.put(tx);
end
end
end
tx.print();
wvif.wb_cyc = 1'b0;
wvif.wb_sel = 'h0;
wvif.wb_stb = 1'b0;
//end
end
endtask: run
endclass
WB_environement:
class wb_env;
// generator, bfm, monitor and coverage
wb_gen gen_h;
wb_bfm bfm_h;
wb_monitor mon_h;
wb_coverage cov_h;
// construct components
function new();
gen_h = new();
bfm_h = new();
mon_h = new();
cov_h = new();
endfunction: new
// run task
task run();
$display("wb_env run task");
fork
gen_h.run();
bfm_h.run();
mon_h.run();
cov_h.run();
join
endtask: run
endclass: wb_env
Wb_interface:
interface wb_intf(input bit wb_clk, wb_rst);
bit [31:0] wb_data_i;

bit [31:0] wb_data_o;
bit [31:0] wb_addr;
bit [3:0] wb_sel;
bit wb_we;
bit wb_cyc;
bit wb_stb;
bit wb_ack;
bit wb_err;
bit susp_req;
bit resume_req;
bit suspended;
bit [31:0] poc;

// POC
endinterface: wb_intf
Wb_monitor:
class wb_monitor;
virtual wb_intf wvif;
wb_tx tx_collect;
task run();
wvif = mc_config::wvif;
forever begin
tx_collect = new();
if(wvif.wb_cyc && wvif.wb_stb && wvif.wb_ack) begin
tx_collect.wb_addr_i = wvif.wb_addr;
if(wvif.wb_we) begin
tx_collect.wr_rd = 1;
tx_collect.wb_data = wvif.wb_data_i;
end
else begin
tx_collect.wr_rd = 0;
tx_collect.wb_data = wvif.wb_data_o;
end
end
mc_config::wb_mon2ref.put(tx_collect);
mc_config::wb_mon2cov.put(tx_collect);
end
endtask: run
endclass: wb_monitor
Wb_coverage:
class wb_coverage;
event e;
wb_tx tx_collect;
covergroup wb_cov @(e);

coverpoint tx_collect.wr_rd;
coverpoint tx_collect.wb_addr_i {
bins CS0_BIN = {[`CS0_START:`CS0_END]};
}
endgroup
function new();
wb_cov = new();
endfunction
task run();
forever begin
mc_config::wb_mon2cov.get(tx_collect);
-> e;
end
endtask
endcla
CHAPTER 6
TOOL USED
Figure 6: QuestaSim Tool
In this project we are using tool which name is Questa sim. It is the latest tool in Mentor Graphics
tool suite ifor iFunctional iVerification. iThis itool iprovides isimulation isupport ifor ilatest istandards iof
iSystem iC, iSystem iVerilog, iVerilog iand iVHD i[7]. i
• iIt isupports ifor iadvanced iverification ifeatures ilike i

• iCoverage idatabases i
• iCoverage idriven iverification i
• iWorking iwith iassertions i
• iSV iconstrained- irandom ifunctionality
CHAPTER 7
RESULTS
7.1 DIFFERENT MEMORY INTERFACE TO UMC
7.1.1 SDRAM Module
Synchronous Dynamic Random Access Memory. SDRAM are faster than Asynchronous DRAM.
In SDRAM whenever there is change in input side causes changes in the output side only when
clock changes. SDRAM memory is divided into four banks, so read and write operations happens
faster than other memories.
Pin diagram of Memory Controller and SDRAM both blocks are interfaced by Memory interface
shown in figure 7.1.1 a.
Figure 7.1.1: a) Interface of SDRAM with Memory Controller
The data from memory controller is written to the memory of SDRAM in one address location and
from same address location data is read back to the Memory Controller.
Figure 7.1.1: b) SDRAM Read and Write
Whenever acknowledgement, cyclic and strobe pins goes high read and write operation will
happen. When WB pin goes zero read operation will happen, when WB pin goes high wright
happens. As the memory is synchronous the out will changes after the clock changes even there is
change in input.
7.1.2 SSRAM module
Synchronous istatic irandom iaccess imemory. iSSRAM iis ivolatile imemory iit inot irequires ithe irefresh
icycle ito istore ithe idata. iAs iit iis isynchronous imemory, i In iSDRAM iwhenever ithere iis ichange iin iinput
iside icauses ichanges iin ithe ioutput iside ionly iwhen iclock ichanges, ioutput idepends ion iclock.
Figure 7.1.2: a) SSRAM Read cycle

Figure 7.1.2.: b) SSRAM Write Cycle
This is the expected wave forms for read and write operations. MC_WE Pin goes High write
operation will happen. And when MC_OE pin goes low read operations will happen.
Figure 7.1.2: c) SSRAM Read and Write

7.1.3. Sync
• Synchronous chip select device; it also clocks dependent. All SSRAM parameters in respect to
the clock and are not configurable
• MC supports standard Sync Burst, Pipelined SSRAMs with double cycle deselect. Synchronous
CS devices are synchronous to memory controller’s clock.
Figure 7.1.3: a) Synchronous Chip Select Device Read Cycle
Figure 7.1.3: b) Synchronous Chip Select Device Write Cycle
This is the expected wave forms for read and wright operation. MC_WE goes pin high write
operation will happen. And when MC_OE pin goes low read operations will happen.
Figure 7.1.3: c) Synchronous Chip Select Device Read and Write
APPLICATIONS
Memory controllers contain the logic necessary to read and write to DRAM, and to "refresh" the
DRAM. Without constant refreshes, DRAM will lose the data written to it as the capacitors leak
their charge within a fraction of a second (not more than 64 milliseconds according to JEDEC
standards).
Reading iand iwriting ito iDRAM iis iperformed iby iselecting ithe irow iand icolumn idata iaddresses iof ithe
iDRAM ias ithe iinputs ito ithe imultiplexer icircuit, iwhere ithe ide imultiplexer ion ithe iDRAM iuses ithe
iconverted iinputs ito iselect ithe icorrect imemory ilocation iand ireturn ithe idata, iwhich iis ithen ipassed
iback ithrough ia imultiplexer ito iconsolidate ithe idata iin iorder ito ireduce ithe irequired ibus iwidth ifor ithe
ioperation.
Bus iwidth iis ithe inumber iof iparallel ilines iavailable ito icommunicate iwith ithe imemory icell. iMemory
icontrollers' ibus iwidths irange ifrom i8-bit iin iearlier isystems, ito i512-bit iin imore icomplicated isystems
iand ivideo icards i(typically iimplemented ias ifour i64-bit isimultaneous imemory icontrollers ioperating
iin iparallel, ithough isome iare idesigned ito ioperate iin i"gang imode" iwhere itwo i64-bit imemory
icontrollers ican ibe iused ito iaccess ia i128-bit imemory idevice).
Some memory controllers, such as the one integrated into Power QUICC II processors, can be
connected to different kinds of devices at the same time, including SDRAM, SRAM, ROM, and
memory-mapped I/O; each kind of these devices requires a slightly different control bus, while the
memory controller presents a common system bus / front-side bus to the processor. Some memory
controllers, such as the one integrated into Power QUICC II processors, include error detection
and correction hardware.
CONCLUSION
Memory is the main part of any processer, there are different types of memory present on SOC.
To controller the different types iof imemory iinstead iof iusing idifferent itypes iof imemory icontroller
ifor ieach imemory, ionly ione imemory icontroller iis iused icalled iUniversal iMemory iController. iIn
ithis iproject, ithe iverification iis idone ifor ithe iMemory icontroller iwhich iis isupporting idifferent itypes
iof iSynchronous imemories, ialong iwith imany ifeathers isupporting icompared ito iold iMemory
iControllers. iWaveform ishowing ithe iresults iof iwriting idata ito ithe iMemory iController iand ireading
iit iback ifrom imemory ithrough ithe iWISHBONE iis isame.The data which is given the same data is
reading back hence Universal Memory Controller is working.

REFERENCES
[1]Biswal, B. P., Singh, A., & Singh, B. (2017, January). Cache coherency controller verification
IP using SystemVerilog Assertions (SVA) and Universal Verification Methodologies (UVM). In
2017 11th International Conference on Intelligent Systems and Control (ISCO) (pp. 21-24). IEEE.
[2]El-Yamany, A., El-Ashry, S., & Salah, K. (2016, December). Coverage Closure Efficient UVM
Based Generic Verification Architecture for Flash Memory Controllers. In 2016 17th International
Workshop on Microprocessor and SOC Test and Verification (MTV) (pp. 30-34). IEEE.
[3]Khalifa, K., & Salah, K. (2015, April). Implementation and verification of a generic universal
memory controller based on UVM. In 2015 10th International Conference on Design &
Technology of Integrated Systems in Nanoscale Era (DTIS) (pp. 1-2). IEEE.
[4]Lin, C. S., Chen, K. Y., Wang, Y. H., & Dung, L. R. (2006, December). A NAND flash memory
controller for SD/MMC flash memory card. In 2006 13th IEEE International Conference on
Electronics, Circuits and Systems (pp. 1284-1287). IEEE.
[5]Agarwal, K., Magraiya, V. K., & Saxena, A. K. (2013, April). Verification and simulation of
new designed NAND flash memory controller. In 2013 International Conference on
Communication Systems and Network Technologies (pp. 762-766). IEEE.
[6]Doshi, N. K., Suryawanshi, S., & Kumar, G. N. (2016, May). Development of generic
verification environment based on UVM with case study on HMC controller. In 2016 IEEE
International Conference on Recent Trends in Electronics, Information & Communication
Technology (RTEICT) (pp. 550-553). IEEE.
[7] A Reconfigurable Real-Time SDRAM Controller for Mixed Time-Criticality Systems 978-1-
4799-1417-3/13/$31.00 ©2013 IEEE
[8] A Novel AHB Based SDRAM Memory Controller International journal of research in
Computer and Communication Technology, Vol4, Issue 6, June-2015J. www.ijrcct.org
[9] MohdWajid,Shahank SB, ”Architecture for Faster RAM Controller Design with Inbuilt
Memory”, IEEE ,2010 ARM, AMBA Specification Rev.2.0, 1999. “Memory Controllers for Real-
Time Embedded systems” Benny Akesson
[10] “Memory Controller Architectures: A comparative Study” 978-1-4799-35253/13/$31.00
©2013 IEEE
[11] “Implementation and Verification of A Generic Universal Memory Controller Based On
UVM” 2015 10th International Conference on Design & Technology of Integrated Systems in
Nanoscale Era (DTIS) 978-1-4799-1999-4/15/$31.00 ©2015 IEEE
[12] IEEE Standard for SystemVerilog — Unified Hardware Design, Specification, and
Verification Language. New York: IEEE 2005 (a.k.a. SystemVerilog Language Reference
Manual, or LRM.)
[13] Bergeron, Janick, Cerny, Eduard, Hunter, Alan, and Nightingale, Andrew. Verification
Methodology Manual for SystemVerilog. Norwell, MA: Springer, 2005

Design Verification of Umc

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Design Verification of Umc

Diunggah oleh

Hak Cipta:

Format Tersedia

ABSTRACT

1.1 Overview of Memory Controller Block

design, verification is done by generating a test cases in system Verilog language.

Figure 1.1:Block diagram of Universal memory controller

imodule. iWhile iverification isystem iVerilog itop imodules iare iused.

imemory iinterface ito ithe iUMC.

iconnected iwith isame imemory ior idifferent imemories. i i i i

1.4 Thesis Organization

ifunctional iverification iusing iUniversal iVerification iMethodologies i(UVM) ipackages ito

isubstantially iameliorate ithe idifficulties ifor idesign iaccuracy.

ipredefined isystem istartup ifrom ia iFlash ior iROM imemory. i

3.1 Features of Universal memory controller

1. Supports Power Down Mode

3. Multi iMaster imemory ibus isupport

4. Industry istandard iWISHBONE iSoC ihost iinterface

5. Default iboot isequence isupport

7. Supports iRMW icycles i

8. 8 iChip iselects, ieach iuniquely iprogrammable i

9. Up ito i8 i* i64 iMbyte imemory isize

12. Byte parity Generation and Checking

Figure 3.2: Architecture of Universal memory controller

idoes inot isupport iother ibus iwidths.

Figure 3.2.1: WISHBONE Interface

3.2.2. Power-On Configuration

Figure 3.2.2: Power-On Configuration

Figure 3.2.3: Refresh Controller

3.2.4. Open Bank & Row Tracking

iwhen ithe ikro ibit ifor ia ichip iselect iis iset.

Figure 3.2.4: Open Bank & Row Tracking

ion ithe imemory ibus.

Figure 3.2.5: Data Latch, Packer & Parity

3.2.6. Memory Timing Controller

Figure 3.2.6: Memory Interface

iphase isynchronizing iit ito ithe iWISHBONE iclock.

Figure 3.2.9: Configuration & Status Registers

iexcellent iprogramming ilanguage ifor iFPGAs iand iCPLDs.

irelatively icompact iand iconcise iform. i

iother iminor idifferences.

4.1.2 System Verilog

iSystem iVerilog inot ipresent iin iVerilog-2005.

4.2 System Verilog Architecture

master the figure can be modified for different design aspects.

Figure 4.2: System Verilog Architecture

ithrough ithe iinterface. I

ithat, ithe iDUT iinput ipin i"read iwrite" iis iasserted. I

ito ihigh ilevel. i

iexpected ivalues. iThe icomparison istate iis isent ito iscoreboard.

4.3 Verification Steps

(I) Features posting depressed.

4.4 SV Verification Tools

Usually the tools work in 3 steps which includes:

function bit compare(mc_tx tx);

function write(bit [31:0] data);

function write(bit [31:0] data);

function bit [31:0] read();

function iwrite(bit i[31:0] idata);

ii function ibit i[31:0] iread();

i ibit i[3:0] itrfc;

i ibit i[3:0] itrp;

i ibit i[2:0] itrcd;

i ibit i[1:0] itwr;

i ibit i[1:0] ioper_mode;

i ibit i[2:0] icas_lat;

i ibit i[2:0] ibl;