Verification Project Assignments

Verification Project Assignments
Ramdas M and Robin Garg

1
Disclaimer
Every effort has been made to make this book as complete and as accurate as possible, but no
warranty is implied. The authors shall have neither the liability nor the responsibility to any
person or entity with respect to any loss or damages arising from the information contained in
this book or other resources accompanying this book.
This book is an independent work of the authors and is not endorsed by their employers.
Table of Contents
Introduction .............................................................................................................................. 2
Project 1: Design and Verification of a Synchronous Dual Ported RAM in SystemVerilog
using UVM methodology ......................................................................................................... 3
Project 2: Assertion Based Verification of Synchronous FIFO design ................................ 5
Project 3: Developing a SPI (Serial Peripheral Interface) Master-Slave Verification IP. ...... 7
Project 4: Developing an APB (Advanced Peripheral Bus) Master/Slave VIP .....................11
Project 5: Assertion based Verification of a Round Robin Arbiter ......................................17
Summary .................................................................................................................................18
Bonus ......................................................................................................................................19
This is a free document accompanying the book: Cracking Digital VLSI Verification Interview
For best results, it is recommended to be familiar with concepts and questions discussed in
above book before trying these project assignments.
Introduction
Dear Reader,
Welcome aboard!
Thanks for subscribing to free-resources and updates from Verification Excellence.
Learning through textbooks and courses alone is not good enough to master Verification Skills.
As the old saying goes: Practice makes a Man Perfect, same is applicable for Digital VLSI
Verification as well. Practicing with real examples and working hands-on on relevant projects
will help you better understand various different concepts thoroughly and take you to the next
level.
2
Here, we present 5 mini-project assignments that will help you practice hands-on coding and
enable you to understand different verification methodologies thoroughly. In each mini-project
assignment, we provide you:
1. Detailed description of the project,
2. References for reading and understanding minute details that are needed for completing
the project, and
3. Detailed tasks and steps that are required to be performed for completing and verifying
the project.
We are intentionally not providing a complete code database as solution as it defeats the
purpose of reader putting that extra amount of effort in coding.
Project 1: Design and Verification of a Synchronous Dual

Ported RAM in SystemVerilog using UVM methodology
Description: Dual-ported RAM (DPRAM) is a type of random-access memory that allows

multiple reads or writes to occur at the same time, or nearly the same time, unlike single-ported
RAM which only allows one access at a time.
Following block diagram illustrates a synchronous Dual Ported RAM which has separate Read
and Write ports and a common clock. A write happens on a clock edge when write_en is high to
the address pointed by write_addr and the input data is driven on the datain signal. A read
happens on a clock edge, when the read_en is high to the address pointed by read_addr and
data is output on dataout signal. This RAM does support doing a read and a write in the same
clock cycle as there are two different ports.

3
Details:
1) Design the dual-port RAM module in SystemVerilog with above description.
2) Create a Test plan that lists various scenarios to be verified.
Following can be used as a reference but first try to make your own list as per your
thinking.
a) Verify a simple read to an address and a write to an address
b) Verify simultaneous read and write (same clock cycle) to different addresses and
same address. (Note: What happens when Read and Write happens to same
address in same cycle? Is it ok to get new value or should you get old value?)
c) Verify memory access with different address and data patterns
i) What patterns will be interesting?
d) Verify read after write, write after read and similar sequences with different
delays.
i) Back to back reads, back to back writes
ii) Read or write separated by 1, 2, 3, clock cycles etc
iii) Random delays
3) Architect the UVM compliant testbench with an env/agent/driver/sequencer.
Think through following questions and then refer the following diagram to see the
different components needed.
a) How many agents do we need?
b) How can the driver and sequencer be connected? Do we need a response port?
c) How can we define a checking methodology?

4
4) Define a stimulus pattern using UVM sequence. Think through following questions:
a) How can we define the basic transaction object?
b) What can be randomized in transaction and what can be randomized in the
sequence that generates transactions (sequence items)?
c) How can we implement a delay between two transactions send from sequence?
Reference:
1) A reference design for dual port RAM available is available here if you want to just start
on verification environment.
https://github.com/VerificationExcellence/SystemVerilogReference/blob/master/projects/
DualPortRam/dualport_ram.sv
2) Reference to other courses/tutorials on UVM
a) You can refer to these self-paced online courses:
http://verificationexcellence.in/online-courses/
b) Refer to SystemVerilog language LRM here: 1800-2012 Standard
3) You can use www.edaplayground.com for testing your code if you dont have access to
any simulator.
4) You can also use the APB Master implementation in UVM as a reference to implement
the Dual Port RAM verification environment:
https://github.com/VerificationExcellence/UVMReference/tree/master/apb_project
Project 2: Assertion Based Verification of Synchronous FIFO

design

5
Description: Synchronous FIFO is a First-In-First-Out queue consisting of a storage array
with control logic that manages the read and write of data and generates status flags. The
number of rows in the array is called the DEPTH of the FIFO, and the bit length of each row
(i.e., the number of columns of the array) is called the WIDTH of the FIFO.
Refer to the following block diagram to understand the interface specification and signals in a
synchronous FIFO.
A Synchronous FIFO has a single clock port for both read and write operations. The Data driven
on the data-input port (DIN) is written into the next available empty FIFO location on a rising
clock edge when the write-request input (WRITE) is high. This is also known as a PUSH
operation on FIFO. Data can be read out of the FIFO via output port (DOUT) in the order in
which it was written by asserting read-request (READ) prior to a rising clock edge.
The FIFO full status output flag (FULL) indicates that no more empty locations remain in the
internal array. The FIFO empty status output flag (EMPTY) indicates that all locations inside the
FIFO are empty. The FIFO status cannot be corrupted by invalid requests. Requesting a read
operation while the EMPTY flag is active will not cause any change in the current state of the
FIFO. Similarly, a write operation while the FULL flag is active will not cause any change in the
current state of the FIFO. The RESET signal clears internal control logic and the status flags.
Details:
Based on the Synchronous FIFO specification given above, we can first capture the properties
that are required to be true for correct FIFO operation. Assume that the FIFO depth is 32 and
width is 16 bits.
A set of sample properties can be defined as following:

1) Black box Assertions - Assertions that can be written for properties without looking at
internals of design
a) When the FIFO is reset, the FIFO empty flag should be set and the full flag
should be reset.

6
b) If the FIFO is full, and there is a write operation without a simultaneous read
operation, the full flag should not change.
c) If the FIFO is full, and there is a write operation without a simultaneous read
operation, the write pointer should not change.
2) White box Assertions - Assertions that can be written for properties by looking at
internals of design
a) If the fifo word counter (fifo_counter) is greater than 31, the FIFO is full.
b) If the fifo word counter (fifo_counter) is less than 32, the FIFO is not full.
c) If the word counter is 31 and there is a write operation without a simultaneous
read operation, the FIFO should go full.
3) Think about other scenarios. What other Assertions can you think of?
4) Once you have a list of assertions, how can these be implemented? Which of the above
can be immediate assertions and which of these need to be concurrent assertions?
5) Create sample testbench to generate stimulus to test your Assertions.
a) This can be as simple as creating a top test bench module and implementing two
tasks to do a write or a read from the FIFO. Use the tasks to create FIFO full,
empty and attempt to read on empty, attempt to write on FIFO full etc. Make sure
your assertion fires.
b) You could also write a SystemVerilog/UVM testbench as in Project Assignment 1
and test your design exhaustively.
6) Refer to the design code and sample assertions available on Github (path in reference),
only when you need.
7) Optionally you can also reuse above properties to implement functional coverage for the
Synchronous FIFO.
Reference:
1) Refer following for a synchronous FIFO design to test your assertions.
a) https://github.com/VerificationExcellence/SystemVerilogReference/blob/master/pr
ojects/SynchFIFO/sync_fifo.sv
Project 3: Developing SPI (Serial Peripheral Interface) Master-

Slave Verification IP.
Description: The Serial Peripheral Interface (SPI) bus is a synchronous serial

communication interface specification used for short distance communication, primarily in
embedded systems. SPI devices communicate in full duplex mode using a master-slave
architecture with a single master. The master device originates the frame for reading and
writing. Multiple slave devices are supported through selection with individual slave select (SS)
lines.
7
Following diagram shows a basic SPI master-slave configuration with a single master driving a
single slave device. It is also possible to have multiple slaves connected to a single master but
for this project we will use following example to develop a verification IP (Intellectual Property)
and test the same.
The SPI bus specifies four logic signals which are following:
1) SCLK : Serial Clock (output from master).
2) MOSI : Master Output, Slave Input (output from master).
3) MISO : Master Input, Slave Output (output from slave).
4) SS : Slave Select (active low, output from master) (For multiple slave connections, there
will be a separate slave select line from the master to each of the slaves)
SPI is a single-master communication protocol. When the SPI master wishes to send data to a
slave and/or request information from it, it selects slave by pulling the corresponding SS line low
and it activates the clock signal at a clock frequency usable by the master and the slave. The
master generates information onto MOSI line while it samples the MISO line. On the other side,
Slave samples the MOSI line and drives back the MISO line with responses.
There are 4 modes that are supported by SPI based on which clock edge and polarity the
sampling of serial line happens as shown below.
1) Mode=0, CPOL=0, CPHA=0. In this mode, the first rising edge of the clock (after slave
select is pulled low) when the clock polarity is zero is used to start sampling and then
every rising edge is used as shown below

8
2) Mode=1 CPOL=0, CPHA=1. In this mode, the first falling edge of the clock (after slave
select is pulled low) is used for sampling. This is right after first clock rises from
polarity=0 and then falls.
3) Mode=3 CPOL=1, CPHA=0. In this mode, after the slave select is pulled low, the first
falling edge which happens from the first time clock polarity is high is used for sampling
as shown below.
4) Mode=4 CPOL=1, CPHA=1. In this mode, the first rising edge of the clock after the
clock polarity=high is seen is the first sampling point followed by every rising edge.

9
Verification IP Development:
Once the details of SPI bus protocols are understood, this Verification IP can be developed in
SystemVerilog, preferably using UVM Verification methodology and using following
steps/guidelines.
A SPI Master-Slave Verification IP will have a Master component and a Slave Component. Both
these components can be developed and tested by connecting the Master component to the
Slave component and a scoreboard can be used to check for Protocol checking that looks at the
SPI bus interface.
Following block diagram illustrates how the SPI VIP can be implemented in an UVM verification
environment and tested as part of this project.
1) There will be two separate UVM Agent classes, one for Master and other for Slave.
2) The Master Agent will consist of a Master driver, sequencer and a monitor component.
3) The Slave Agent will have a Slave Driver (or responder), Slave sequencer and Slave
monitor.
4) Both the Agents can then be created inside a SPI environment class.
5) A SPI scoreboard can be implemented in the environment class that looks at the bus
interface activity as seen by the monitor and checks for proper protocol rules.
6) Create sequences that can model a simple SPI transaction and can be send to the
Master sequencer. The Slave Driver/Responder needs to abstract the serial bits, create
a response transaction and drive back. Alternatively, response transactions can be
created independently and send to the slave driver through slave sequencer for the
purpose of testing the VIP.
7) Finally a SPI test class can be created that instantiates the environment class, start the
sequences and verify functionality of both Master and Slave.
8) A SPI config class is also shown in the diagram which can support the SPI mode
configuration. The Master/Slave Driver will use this configuration class to determine
which one of the 4 supported modes are used.

10
Notes:
1) For Simplicity and initial implementation, SPI mode=0 (which is the most common
usage) can be always assumed and the driver implementation can be simple.
2) Once basic implementation is done, another enhancement can be to unify the Master
and Slave components into a single Agent and use another configuration field in the SPI
config class to have same component behave either as a master or as a slave.
References:
1) For more understanding of SPI, read following articles:
a) https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus
b) http://www.byteparadigm.com/applications/introduction-to-i2c-and-spi-protocols/
c) http://www.corelis.com/education/SPI_Tutorial.htm
d) https://learn.sparkfun.com/tutorials/serial-peripheral-interface-spi
2) For details on what is a Verification IP, read following post on Quora - What is difference
between VIP and IP?
3) For references to SystemVerilog and UVM, use the same references as mentioned in
first project.
Project 4: Developing an APB (Advanced Peripheral Bus)

Master/Slave VIP

11
Description: The aim of this project is to design and implement an APB (Advanced
Peripheral Bus) compliant master in SystemVerilog that can be used as a VIP. It is
recommended to be implemented in SystemVerilog using UVM methodology, but for those who
are yet to learn UVM, this can also be implemented in SystemVerilog without UVM.
The APB is part of the AMBA bus protocol family. It provides a low-cost interface that is
optimized for minimal power consumption and reduced interface complexity. The APB interfaces
to any peripherals that are low-bandwidth and do not require the high performance of a
pipelined bus interface. Following diagram shows a typical AMBA based system and the APB is
used for interfacing with peripheral devices like UART, Timer, keypad, PIO etc.
The APB bus supports read transfer and write transfers between a master and multiple APB
slaves. Following diagram shows the set of signals that are used by the protocol for
communication between APB master and slaves and the table gives a description of signals

12
Signals Description
PCLK Bus clock all transfers are timed on the rising edge
PRESETn Bus reset - active LOW. This signal is normally connected

directly to system bus reset
PADDR Address bus upto 32-bits wide driven by the peripheral

bus bridge
PSELx Slave device select - from the secondary decoder within the
peripheral bus bridge indicates a data transfer is required
PENABLE Enable - indicates the second cycle of a transfer, rising edge

of PENABLE occurs in the middle of a transfer
PWRITE Write/Read when HIGH write access and when LOW a

read access
PRDATA Read data-bus is driven by the selected slave during read

cycles
PWDATA Write databus is driven by the peripheral bus bridge unit

during write cycles
PREADY A slave drives this to master to extend a transfer phase if it

is not ready to accept a request

13
Following timing diagram shows how the READ and WRITE operations happen with and without
a wait state.
a) Write Transfer without Wait State: The write transfer starts with the address, write
data, write signal and select signal all changing after the rising edge of the clock. The
first clock cycle of the transfer is called the Setup phase. After the following clock edge
the enable signal is asserted (PENABLE), and this indicates that the Access phase is
taking place. The address, data and control signals all remain valid throughout the
Access phase. The transfer completes at the end of this cycle.
b) Write Transfer with Wait State: The difference in this case is that PREADY signal is
low for two extended cycles indicating slave is not ready and hence the master needs to
wait until PREADY goes high which is the cycle where WRITE happens.
c) Read Transfer without Wait State: For read case, after the master drives Address and
PWRITE=0 along with PSEL and PENABLE=1, the slave responds with PRDATA along
with PREADY indicating read data. If there is no wait state the data is returned in same
cycle as PENABLE.

14
d) Read Transfer with Wait State: If the slave is not ready then Master keeps extending
all signals including PENABLE until PREADY is high when the Read data can be
sampled.
References:
1) Download APB spec from ARM website here. You will need to create a login before
downloading https://silver.arm.com/download/download.tm?pv=1082425
2) Here is another reference document that you can use
http://classes.engineering.wustl.edu/cse465/Lectures/Lecture%202%20-
%20AMBA%20APB%20Bus.pdf
3) You can use the following APB master implementation in UVM as a reference to
implement the complete master and slave BFM and test it out.
https://github.com/VerificationExcellence/UVMReference/tree/master/apb_project

15
4) Use www.edaplayground.com if you dont have reference to any other simulator for
SystemVerilog.
Verification IP development:
Once the details of APB bus protocols are understood, this Verification IP can be developed in
SystemVerilog, preferably using UVM Verification methodology and using following
steps/guidelines.
An APB Master-Slave Verification IP will have a Master component and a Slave Component.
Both these components can be developed and tested by connecting the Master component to
the Slave component and a scoreboard can be used to check for Protocol checking that looks at
the APB bus interface.
Following block diagram illustrates how the APB VIP can be implemented in an UVM verification
environment and tested as part of this project.
1) There will be two separate UVM Agent classes, one for Master and one for Slave.
2) The Master Agent will consist of a Master driver, sequencer, and a monitor component.
3) The Slave Agent will have a Slave Driver (or responder), Slave sequencer, and a Slave
monitor.
4) Both the Agents can then be created inside a APB environment class.
5) An APB scoreboard can be implemented in the environment class that looks at the bus
interface activity as seen by the monitor and checks for proper protocol rules.

16
6) Create sequences that can model a simple APB read/write transaction and can be sent
to the Master sequencer. The Slave Driver/Responder needs to abstract the serial bits,
create a response transaction and drive back. Alternatively, response transactions can
be created independently and sent to the slave driver through slave sequencer for the
purpose of testing the VIP.
7) Finally an APB test class can be created that instantiates the environment class, start
the sequences and verify functionality of both Master and Slave.
Project 5: Assertion based Verification of a Round Robin

Arbiter
Description: A common problem with any design is access to a shared resource by multiple
agents. An arbiter design is used to ensure that only one agent has access to the shared
resource at any given time. A common example of the need of arbiter is in a multiprocessor
memory design where multiple processors needs to access memory using a shared bus.
There are different arbitration techniques used in design of arbiter based on different
requirements and round robin arbiter is one of the commonly used arbitration mechanism that
ensures fairness.
A round robin arbitration policy is a token passing scheme where fairness among the multiple
requesting agents is ensured with no starvation. In each cycle, one of the master has the
highest priority to get access to the shared resource. This is then rotated in a round robin order.
If any master does not need access to the resource in the cycle, then the next master in round
robin order gets the priority.
Following diagram shows the block diagram of an arbiter that controls 4 requesting agents and
generates 4 grants to each of the agent in a round robin order.

17
Design Specification:
Assume that each of the requesting agent can assert the request signal (Req 0/1/2/3)
independently and will hold it asserted until the arbiter gives them grant for a pulse. The
arbitration order is Req0 followed by 1 and then 2 and then 3 in a round robin fashion.
Given that there are 4 requesting agents, each of them should get a grant at least one in 4
cycles. This also means that if a request is asserted, the grant signal for that agent should be
assigned in a maximum of 4 cycles.
Assertion Based Verification Details:

Based on above design specifications, think through the possible assertions that you can
implement to check for correct design behavior. Here is a list of reference assertions that should
match your list:
1) In any cycle, there can be only one grant signal that can be asserted.
2) Each requesting agent should get a grant signal in a maximum 4 cycle window.
3) If one requesting agent gets a grant, it cannot receive another grant unless no other
agent is requesting.
4) If there are no requests, there cannot be any grants asserted
References:
1) Here is a sample round robin algorithm implemented in SystemVerilog that you can use
as reference for your project
https://github.com/VerificationExcellence/SystemVerilogReference/blob/master/projects/r
ound_robin_arb/rr_arbiter.svh
2) A good paper from SNUG on arbiter coding styles
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86.550&rep=rep1&type=pdf
3) Here is a sample set of assertions (written in OVL though) that you can refer
http://www.vhdl.org/ovl/pages/examples/arb1_ovl.sv
Summary
We hope that these project assignments help you understand Digital VLSI verification process
better, enhance your programming skills with SystemVerilog, and give you a thorough hands-on
practice with methodologies like UVM and SVA. These are very widely used in the Digital VLSI
Verification industry and are considered as key skills for a Verification job.
We hope that you will honestly follow the guidelines given in the project assignments and try to
implement them. We hope that this would help you in your pursuit of excelling in Verification
Interview.

18
This is a free document accompanying the book: Cracking Digital VLSI Verification Interview
For best results, it is recommended to be familiar with concepts and questions discussed in
above book before trying these project assignments.
Bonus
As a bonus, we want to list down few more project ideas for those who are enthusiastic
to learn and practice more!
Here are some more ideas that you can build upon in your quest of learning and
success:
1) Develop a library of SVA (SystemVerilog Assertions) for an AXI interface protocol.
2) Development of a UART IP and its Verification.
3) Development of a I2C Master-Slave BFM.
4) Development of an APB to I2C bridge for Verification.
5) Develop a DRAM controller BFM that can be used for Verifying a DDR memory.
Thank you and wishing you all the best!
Ramdas M - LinkedIn || Twitter || Quora

Robin Garg - LinkedIn || Twitter || Quora
Cracking Digital VLSI Verification Interview

19

Verification Project Assignments

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Verification Project Assignments

Загружено:

Авторское право:

Доступные форматы

Verification Project Assignments

Ramdas M and Robin Garg

Project 1: Design and Verification of a Synchronous Dual

Description: Dual-ported RAM (DPRAM) is a type of random-access memory that allows