Verification Project Assignments Mar 15

Verification Project Assignments Ramdas M and Robin Garg

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. Verification Project Assignments Ramdas M and Robin Garg

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.


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) 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 Verification Project Assignments Ramdas M and Robin Garg

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.


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) MasterSlave 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. Verification Project Assignments Ramdas M and Robin Garg

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) 2) 3) 4)

SCLK : Serial Clock (output from master). MOSI : Master Output, Slave Input (output from master). MISO : Master Input, Slave Output (output from slave). 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


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. Verification Project Assignments Ramdas M and Robin Garg

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. Verification Project Assignments Ramdas M and Robin Garg

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 Verification Project Assignments Ramdas M and Robin Garg

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


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 data –bus 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


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. Verification Project Assignments Ramdas M and Robin Garg

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


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. Verification Project Assignments Ramdas M and Robin Garg

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.


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.


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) 2) 3) 4) 5)

Develop a library of SVA (SystemVerilog Assertions) for an AXI interface protocol. Development of a UART IP and its Verification. Development of a I2C Master-Slave BFM. Development of an APB to I2C bridge for Verification. 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


Verification Project Assignments Mar 15

Recommend Documents