UVM Verification Environment

Development of Verification Environment for SHA-3
Core using UVM
By
Mayur Navinchandra Kubavat (131060752013)
Guided By
Mr.Ashish Prabhu
Sr. Verification Engineer, LSI India R&D
Remove space
A Thesis Submitted to
Gujarat Technological University
in Partial Fulfillment of the Requirements for
the Degree of Master of Engineering in
VLSI & Embedded System Design
June 2015
Gujarat Technological University, PG SCHOOL
Gujarat Technological University, Ahmedabad
CERTIFICATE
This is to certify that research work embodied in this Thesis entitled Development of Verification Environment for SHA-3 Core using UVM was
carried out by Mr. Mayur Navinchandra Kubava (131060752011) at Gujarat Technological University PG School (106), Ahmedabad for partial
fulfillment of Master of Engineering degree, (Electronics & Communication
Systems
Engineering) in VLSI & Embedded System Design, to be awarded by Gujarat Technological University. This research work has been carried out under my
supervision and is to my satisfaction.
Date: June 2015

Place: Ahmedabad
Signature of Guide
Signature and Name

of Principle
Principal
Seal of Institute
COMPLIANCE CERTIFICATE
This is to certify that research work embodied in this thesis entitled Development of Verification Environment for SHA-3 Core using UVM was carried out by Mr. Mayur Navinchandra Kubavat (Enrollment No. 131060752013)
at Gujarat Technological University PG School (106), Ahmedabad for
partial fulfillment of Master of Engineering degree, (Electronics & Communication Engineering) in VLSI & Embedded System Design, to be awarded
by Gujarat Technological University. He has complied with the comments given
by the Dissertation Phase-I as well as Mid Semester Thesis Reviewer to my satisfaction.
Signature of Student:
Signature of Guide:
Kubavat Mayur N.
Mr. Ashish Prabhu
PAPER PUBLICATION CERTIFICATE
This is to certify that research work embodied in this thesis entitled Development of Verification Environment for SHA-3 Core using UVM carried
out by Mr. Mayur Navinchandra Kubavat (Enrollment No. 131060752013)
at Gujarat Technological University PG School (106), Ahmedabad for
partial fulfillment of Master of Engineering degree, (Electronics & Communication Engineering) in VLSI & Embedded System Design, to be awarded
by Gujarat Technological University, has published article entitled UVM Based
Verification Environmet for SHA-3 Core for publication by the Journal
Name, at City during Volume and Date.
Date: June 2015
Place: Ahmedabad
Signature of Student:
Signature of Guide:
Kubavat Mayur N.
Mr. Ashish Prabhu

Signature and Name of Principal
Seal of Institute
ii
THESIS APPROVAL CERTIFICATE
This is to certify that research work embodied in this thesis entitled Development of Verification Environment for SHA-3 Core using UVM carried
out by Mr. Mayur Navinchandra Kubavat (Enrollment No. 131060752013)
at Gujarat Technological University PG School (106), Ahmedabad is approved for the degree of Master of Engineering with specialization of (Electronics
& Communication Engineering) in VLSI & Embedded System Design
by Gujarat Technological University.
Date: June 2015

Place: Ahmedabad
Examiners Sign and Name:
......................................................... .........................................................
iii
DECLARATION OF ORIGINALITY
We hereby certify that we are the sole authors of this thesis and that neither any
part of this thesis nor the whole of the thesis has been submitted for a degree to
any other University or Institution.
We certify that, to the best of our knowledge, the current thesis does not infringe upon anyones copyright nor violate any proprietary rights and that any
ideas, techniques, quotations or any other material from the work of other people
included in our thesis, published or otherwise, are fully acknowledged in accordance with the standard referencing practices. Furthermore, to the extent that
we have included copyrighted material that surpasses the boundary of fair dealing
within the meaning of the Indian Copyright (Amendment) Act 2012, we certify
that we have obtained a written permission from the copyright owner(s) to include
such material(s) in the current thesis and have included copies of such copyright
clearances to our appendix.
We declare that this is a true copy of thesis, including any final revisions, as
approved by thesis review committee.
We have checked write up of the present thesis using anti-plagiarism database and
it is in allowable limit. Even though later on in case of any complaint pertaining
of plagiarism, we are sole responsible for the same and we understand that as per
UGC norms, University can even revoke Master of Engineering degree conferred
to the student submitting this thesis.
Date: June 2015

Place: Ahmedabad
Signature of Student
Signature of Guide
Kubavat Mayur N.
Mr. Ashish Prabhu
Enrollment No. 131060752013
Institute Code: 106
iv
ACKNOWLEDGMENT
I would like to express my deepest appreciation to all those who provided me the
possibility to complete this report. A special gratitude I give to our guide Mr.
Ashish Prabhu, Sr. Verification Engineer, LSI R&D India, Pune, whose contribution in stimulating suggestions and encouragement helped me to coordinate my
report writing.
Furthermore I would also like to acknowledge with much appreciation the crucial
role of the staff of CDAC. Including Mr. Suresh Sikka, Sr. Technical Officer,
CDAC ACTS, Pune who gave the permission to use all required equipment and
the necessary materials to complete the report. I have to appreciate the guidance
given by other supervisor as well as the panels especially in our Dissertation PhaseI presentation that has improved our presentation skills, any comments and advices
which suggest improvement of this work will be much appreciated.
Credits also go to my friends and senior students, including Pankaj Chavda for
his valuable suggestion and support time and again.
And I thank Gujarat Technological University, Ahmedabad and CDAC
ACTS, Pune for providing IEEE Xplore subscription.
Mayur Kubavat (131060752013)
Contents
Certificate
Compliance Certificate
ii
Thesis Approval Certificate
iii
Declaration of Originality
iv
Acknowledgment
1 Introduction
1.1
Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3
Scope
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5
Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . .
1.6
Expected Outcome . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Universal Verification Methodology
2.1
Verification Methodologies . . . . . . . . . . . . . . . . . . . . . . .
2.2
UVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1
Data Items(Transactions) . . . . . . . . . . . . . . . . . . .
vi
CONTENTS
2.2.2
Sequencer . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3
Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4
Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.5
Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.6
The Environment . . . . . . . . . . . . . . . . . . . . . . . .
2.3
UVM Class Library . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4
UVM Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5
UVM Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6
TLM 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Secure Hash Algorithm-3 Standard
14
3.1
Comparison Parameters of Cryptographic Hash Functions
3.2
Keccak SHA-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3
. . . . . 15
3.2.1
Keccak-p Permutations . . . . . . . . . . . . . . . . . . . . . 16
3.2.2
Sponge Construction . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3
Keccak[c] Specification . . . . . . . . . . . . . . . . . . . . . 17
3.2.4
SHA-3 Function Specification . . . . . . . . . . . . . . . . . 18
Application of Cryptographic Hash Functions . . . . . . . . . . . . 19

3.3.1
Verify Message Integrity . . . . . . . . . . . . . . . . . . . . 19
3.3.2
Password Verification . . . . . . . . . . . . . . . . . . . . . . 19
3.3.3
File or Data Identifier . . . . . . . . . . . . . . . . . . . . . 19
Page vii
CONTENTS
3.3.4
3.4
PRG and Key Derivation . . . . . . . . . . . . . . . . . . . . 20
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4 Literature Survey
21
4.1
Choosing Verification Methodology . . . . . . . . . . . . . . . . . . 21
4.2
Testbench Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3
Selecting Design Under Test . . . . . . . . . . . . . . . . . . . . . . 23
4.4
SHA-3 FPGA Implementations . . . . . . . . . . . . . . . . . . . . 23
4.5
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5 SHA-3 Verification Plan
26
5.1
Test Scenarios and Test Cases . . . . . . . . . . . . . . . . . . . . . 27
5.2
Coverage Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.1
Code Coverage . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.2
Functional Coverage . . . . . . . . . . . . . . . . . . . . . . 29
5.3
Verification Environment . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6 Simulation Results
32
6.1
Input golden message sequence . . . . . . . . . . . . . . . . . . . . 32
6.2
Input empty message sequence . . . . . . . . . . . . . . . . . . . . . 36
6.3
Input very long message sequence . . . . . . . . . . . . . . . . . . . 36
6.4
Coverage Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Page viii
CONTENTS
7 Conclusion and Future Work
39
A List of Abbreviations
42
B Package File: sha3 pkg.svh
43
C File System Hierarchy
45
D Review Card Compliance
47
E Research Paper & Publication Certificate
54
F Progress Report
55
Page ix
List of Figures
2.1
Timeline: Verification Methodologies . . . . . . . . . . . . . . . . .
2.2
A Typical Verification Environment
. . . . . . . . . . . . . . . . .
2.3
A Partial UVM Class Hierarchy . . . . . . . . . . . . . . . . . . . .
2.4
Phases in UVM (source: soccentral.com) . . . . . . . . . . . . . . . 10
2.5
Producer-Consumer with put method
2.6
Producer Gets from Consumer
2.7
Analysis Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1
Parts of the state array organized by dimensions
3.2
Sponge Construction . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1
Developed Verification Environment
6.1
Test Scenario: Test Requirement 1 . . . . . . . . . . . . . . . . . . 33
6.2
6.3
6.4
Coverage Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
. . . . . . . . . . . . . . . . 11
. . . . . . . . . . . . . . . . . . . . 11
. . . . . . . . . . 17
. . . . . . . . . . . . . . . . . 30
List of Tables
2.1
TLM 1.0 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1
Parameters of Cryptographic Hash Functions . . . . . . . . . . . . . 15
3.2
Keccak-p Permutation width and related quantities . . . . . . . . . 16
5.1
Pin details of high throughput SHA-3 core . . . . . . . . . . . . . . 27
5.2
Pin details of low throughput SHA-3 core . . . . . . . . . . . . . . . 28
xi
Development of Verification Environment for SHA-3

Core using UVM
By
Mayur Navinchandra Kubavat
(131060752013)
Guided By
Mr.Ashish Prabhu
Sr. Verification Engineer, LSI India R&D
ABSTRACT
As CMOS technology advances, complexity of ICs also increases. Moores law
states that number of transistor in ICs doubles approximately every two years.
Verifying working of these complex digital systems has become more important
now, because any small deviation from specification in high density chips can lead
to system failure and complete re-spin of the design cycle. Which then leads to
increased cost and delay in time-to-market. Therefore SystemVerilog HVL was
developed to create testbench for large digital design. SystemVerilog supports
concepts of OOPs and provide higher level of abstraction in our testbench. To
support reusability of verification components UVM is developed later which is
derived from OVM and eRM.
This dissertation work is induced from necessity of development of UVM based
verification environment for SHA-3 cryptographic core. Taking this need in consideration, dissertation work describes flow from specification extraction to development of verification environment.
Continue...
xii
Expected result from this dissertation work includes, developing of UVM component for verification environment, integrating design under test with developed
environment, creating test cases, development of functional model, complete code
coverage and detailed documentation about them all. We also try to achieve
higher functional coverage report and foreign language integration in our verification environment. Scripting can be used to execute commands in batch mode.
The verification environment can also be reused between low and high-throughput
cores as well. Also some design concept can be studied to find new ways of optimizing FPGA implementations.
xiii
CHAPTER
1
Introduction
This report describes various facts used to select thesis statement Development
of verification environment for SHA-3 core using UVM and follow up approach
to realize development of solution for the problem stated. Work progress up to
Mid Semester Thesis Progress Review has been shown in chapter 6. It also discusses areas to be explored if work will be extended. Brief overview of verification
methodology used and design under test, which is Keccak SHA-3 cryptographic
core, are also discussed in following sections. Literature which is surveyed to come
up for the thesis selection is outlined in Literature Survey section. Detailed plan
of Dissertation has been described and followed. Also chapter 5 has detailed plan
till DP-II which will give ideas about tasks to be followed.
1.1
Problem Statement
This dissertation work is induced from need of development of UVM based verification environment for SHA-3 cryptographic core. Taking this need in consideration,
dissertation work describes flow from specification extraction to development of
verification environment.
1.2
Motivation
Following increasing logic complexity in digital ICs, verification requirements has

also become complex. To address this issue SystemVerilog Hardware Verifica-
CHAPTER 1. INTRODUCTION
tion Language (HVL) came into existence. SystemVerilog is comprehensive base
language which supports OOPs and thus abstraction level in testbench. But, to
practice reusability in our testbench environment, UVM methodology is developed
later which has rich set of class library.
SHA-1 is most widely known and used hash function in several applications and
protocols. Many successful attacks have been noted on SHA-1 which led NIST
to require many applications in federal agencies to move to SHA-2 after 2010 because of the weakness in previous hash algorithm. Although no successful attacks
have been noted on SHA-2, development of another option is necessary as future
perspective. NIST has selected a new cryptographic hash algorithm which is referred to as the Secure Hash Algorithm 3 (SHA-3) and is intended to complement
the SHA-2 hash algorithms currently specified in Federal Information Processing
Standard (FIPS) 180-3, Secure Hash Standard. The selected algorithm is intended
to be suitable for use by the U.S. government as well as the private sector and is
available royalty-free worldwide.4
Combining above best practices, flow of development of verification environment
for Keccak SHA-3 core using UVM is described in this report.
1.3
Scope
The thesis aims at applying hardware verification concept to the cryptographic

core and check functional correctness of the core. Find out appropriate verification methodology and build verification environment according to it. Then
integrating our developed environment with the design under test and verifying
appropriate response in comparison to functional model while achieving complete
code coverage. Scope of the dissertation work can also be extended to functional
coverage and redefining hardware block by critical assessment of work done on
Secure Hash Algorithms.
Page 2
1.4
Objectives
Work to be presented in this dissertation thesis aims at following standard verification flow used in industry to develop verification environment of the cryptographic
core.
Critically analyzing the relevant literature of Secure Hash Algorithm and Verification techniques with UVM is the first step.
The work will follow standard practices to develop verification environment for
verification methodology which is Universal Verification Methodology.
Function model for the cryptographic core is also need to be developed to compare
different testcases created. One important aspect of hardware verification is code
coverage, which will also be covered.
Scope of this work can also be extended to generate functional coverage. Concept
of reusability can also be explored.
And area vs. throughput consideration can be analyzed and studied for hardware
design improvements and FPGA implementation.
Other than primary objectives stated above, other objectives covers learning tools
used in the process. Use of Mentor Graphics QuestaSim 10.0b is done to create
verification environment and generate various reports. Understanding and using
scripts for batch execution will also be considered. Extended objectives include
learning use of Xilinx ISE, Timing Tool Editor and generating synthesis and timing
reports on the tools.
1.5
Research Methodology
First step in this dissertation flow is to understand Design under Test (DUT)
specification. Following feature extraction from the design, this is specification of
Page 3
our Keccak SHA-3 core. These features are used to generate testcases.
It is then followed by testbench architecture development phase. This phase contains developing UVM testbench hierarchical components. Development and execution of environment will be done on verification tool QuestaSim 10.0b by Mentor
Graphics. Code coverage and functional coverage functionalities are also provided
by Mentor Graphics Questa Advanced Simulator.
Other waveform viewers like GTK Wave and complementary tools are also used.
To get Linux like environment on windows system Cygwin, which is collection of
GNU and Open Source tools, is also used.
Use of scripting language like Perl or TCL can also be studied to create Makefile
or Do file and command line arguments to run tests and batch execution.
Scope of this dissertation work if extended to design and implementation of SHA-3
Keccak on FPGA then other tools Xilinx ISE, Timing Tool Editor Etc will be used
to create RTL code, linting and synthesizing the RTL and producing technology
view of the RTL.
1.6
Expected Outcome
Expected outcome from this dissertation work include, complete understanding

of SHA-3 core and UVM components. UVM based verification environment integrated with SHA-3 core. Verification environment component will be created and
mapped to UVM library. Complete code coverage will be achieved by applying
randomly generated testcases. Checks for different test scenario will be done. And
appropriate documentation of prescribed work will be done. Extended work may
include functional verification approach. Also area vs. throughput analysis and
improvement suggestions of the Secure Hash Algorithm-3 design implementation
on FPGA, which can also extend scope to regression tests and design improvements.
Page 4
CHAPTER
2
Universal Verification Methodology
2.1
Verification Methodologies
In hardware design and verification industry there are three major vendors Synopsys, Cadence and Mentor Graphics. Early in the methodology development
phases, Vera language was developed by Sun Micro Systems for its ASIC verification projects. Later it has been passed to Synopsys and named as OpenVera
which is currently supported in its VCS compiler. Synopsys donated parts of Vera
to Verilog to form bases for SystemVerilog. OpenVera uses Reuse Verification
Methodology (RVM) which is documented in Synopsys Verification Methodology
Manual (VMM).e Hardware Verification Language developed by Verisity used as
basis of Universal Verification Methodology (UVM) developed by Cadence. Open
Verification Methodology (OVM) contains building block of verification library for
semiconductor chips. OVM is originally developed from URM and eRM. It also has
parts of Advanced Verification Methodology used by Mentor Graphics. After the
era of OVM, new verification methodology was developed by joint efforts of verification industries which is known as Universal Verification Methodology (UVM).
UVM combines concepts of OVM as well as VMM. Although major vendors and
many other automation tool vendors supports UVM; eRM with e hardware verification language made for highly flexible reusable testbench, supported by Cadence
also has been used in parallel.
A brief timeline of methodology development has been given in figure 2.1 below,
CHAPTER 2. UNIVERSAL VERIFICATION METHODOLOGY
Figure 2.1: Timeline: Verification Methodologies
2.2
UVM
UVM guidelines provide uses of SystemVerilog language to create reusable efficient

testbench. UVM class library provides automation to SystemVerilog language.
Methodology is used to develop recommended architecture for creating testbench.
UVM provides framework for Coverage Driven Verification (CDV). CDV has combination of automatic test generation (pseudo-random pattern generation), selfchecking architecture and coverage metrics to reduce time for developing testbench
significantly.
UVM class library consist of different components for consistent testbench architecture. These classes consist of Environment, Agent, Driver, Sequencer etc.
Descried classes are also known as verification components. UVM Verification
Component (UVC) can be extended to make DUT specific components. UVC
are ready to use component for Bus Protocol, Design Module or Systems. UVC
have consistent architecture and composed of methods for simulating, verifying
and collecting coverage data.
UVCs are as described below,
Page 6
2.2.1
Data Items(Transactions)
Data items are testcases also known as transactions to be applied to DUT to get
desired coverage. These transactions can be randomized to get higher coverage.
Transactions consist of data packet for Ethernet switch, messages for other secure
hash protocols, bus transactions etc.
2.2.2
Sequencer
Transaction items described above only consist test specific data items. It does
not know how to reach to driver at specific interval of time. Sequencer does this
job very well. It randomizes sequences (transactions) to be applied on driver. It
checks for drivers status and sends transactions accordingly. We can add constraints to the sequencer to send data packet in user defined fashion. Sequencer
provides synchronization to the driver, constraint randomize transactions, react
to the current state of the DUT and also provides system level synchronization
for communication protocols.
2.2.3
Driver
Driver is active element in our testbench environment. It takes transactions from

sequencer and drives it to DUT. It converts transactions into signals. Driver also
provides controlling mechanism like Read/Write, Enable signals and when to drive
the DUT.
2.2.4
Monitor
Monitor is passive entity which samples DUT outputs and convert them to transaction. Monitor checks for protocol timing and its violations. It also provides
coverage mechanism. Monitor extracts data items and notifies for events. And
also collects transactions to be sent to Scoreboard.
Page 7
2.2.5
Agent
Agent provides higher abstract class by encapsulating Sequencer, Driver and Monitor. Because sequencer, driver and monitor can be reused between different verification environments, agent makes this work easy by combining all three of them.
Agents can be both active and passive entity. Active agent can drive and monitor
DUT signals while passive agents only monitor DUT.
2.2.6
The Environment
Environment is top level block for UVCs. It consists of one or more agents and
other UVC like scoreboard. Figure below describes reusable verification environment. Notice in figure 2.2 that the environment class may contain monitor other
than provided in agent. Reason is that bus monitor may be independent of specific
agents.
Figure 2.2: A Typical Verification Environment
Page 8
2.3
UVM Class Library
The UVM class library provides all building blocks you need to quickly develop
verification environment. It consist of UVM base classes, pre-defined methods like
print(), copy() etc. It also consists of utilities, macros and provides Transaction
Level Modeling (TLM 1.0) set for communication between UVCs.
A Partial hierarchy of UVM components and TLM is provided in figure 2.3 below,
Figure 2.3: A Partial UVM Class Hierarchy
2.4
UVM Phases
All UVM class described above has simulation phases. These UVM phase are used
to construct, configure and connect components. Although new() is not an phase,
sometimes it is considered to be one. new() is constructor on the parent class.
Some of the phases are described below,
function void build() is used to construct components of testbench hierarchy. Example is, build phase() of agent is used to construct Sequencer,
Driver and Monitor.
Page 9
Figure 2.4: Phases in UVM (source: soccentral.com)

function void connect() connects components created by build phase.
Again inside the agent connect phase will connect sequencer to driver, and
monitor to external component via port and export.
function void end of elaboration() is used to configure the components
when required.
function void start of simulation() prints component hierarchy and other
messages. It may be optional.
function void extract()
function void check()
function void report() gives all test pass/fail status and simulation results.
task run() is considered as main phase of simulation. Simulation will start
from here. In this phase all tests executes and processes are forked.
Page 10
2.5
UVM Macros
UVM macros implement useful methods in classes and in variables. Some of the
important macros are described below,
2.6
TLM 1.0
Transaction Level Modeling (TLM) provides communication infrastructure for

UVCs. UVCs can be made reusable by SystemVerilog implementation of TLM in
UVM verification components. A component can communicate with other components that implements specific interface. TLM specifies behavior but does not
implement method, it is provided by classes inheriting TLM interface. TLM 1.0
is message passing system while TLM 2.0 is mainly designed for high performance
memory-mapped bus-based systems. In TLM 1.0, two main aspects are ports and
exports. Here port defines set of methods and function to be used inside connections whereas exports implements those set of methods. These connections are
shown in figure 2.5 and 2.6 below,
Figure 2.5: Producer-Consumer with put method
Figure 2.6: Producer Gets from Consumer

Here consumer implements set of methods and function that accepts transaction
in its argument. And producer calls the function and pass the transaction in
argument.
Thereby in cases where we want to connect multiple exports to a single component,
Page 11

ports are not designed to connect to multiple exports. Solution for this is to use
analysis port(figure 2.7), it is same like port but we can connect multiple exports
to it. When analysis ports have things to send, it will be send to all exports
subscribed to this analysis port.
Figure 2.7: Analysis Port
Symbol
Type
Port
Export
Analysis Port
Port Declaration
uvm put port
#(Transaction)
port name
uvm put imp
#(Transaction, Classname) export name
uvm analysis port
#(Transaction) analysis port name
Table 2.1: TLM 1.0 Ports
2.7
Conclusion
As system complexity increases it is not feasible to verify it by writing manual test

cases in Verilog. By using verification methodologies we can provide test scenarios
automatically and in any desired sequence. Also reusability of our verification
environment increases using the methodology.
Page 12

This chapter explains UVM methodology and some important aspects of it. We
have seen commencement of UVM by the time, UVCs, UVM phases and TLM 1.0
in brief. These concepts will be used in this dissertation work. And study of them
is necessary to implement verification plan.
Page 13
CHAPTER
3
Secure Hash Algorithm-3 Standard
Number of cryptographic standard are specified in various Federal Information

Processing Standard Publications (FIPS PUBs) and issued by National Institute of Standard and Technology (NIST). Some of them are encryption standards
which includes Data Encryption Standard (DES), Triple-DES, Advanced Encryption Standard (AES) and RSA. Encryption standards are used in encryption of
electronic data. Hash standards are used to check integrity of data, in authentication and to protect sensitive information. It includes Message Digest algorithm
MD5, Secure Hash Standard-1 (SHA-1), SHA-2 and SHA-3.
FIPS 180-4 specifies secure hash algorithms, SHA-1, SHA-224, SHA-256, SHA-384,
SHA-512, SHA-512/224 and SHA-512/256. From which SHA-1 is currently used in
many applications. In 2005, cryptanalysis found theoretical attacks on SHA-1 and
algorithm might not be secure for ongoing use. NIST required many applications
in federal agencies to move to SHA-2 after 2010. Although no successful attacks
have been found on SHA-2, it shares same structural elements as SHA-1. So, NIST
decided to organize competition to develop new hash standard which is called SHA3. Current research shows that SHA-2 will be secure for future applications but if
it became vulnerable it would take years to find replacement. Thats why SHA3 is considered complement of SHA-2 rather than replacement.11 In 2012 NIST
selected Keccak for SHA-3 algorithm out of five Round-3 candidates. SHA-3 is
also called as Keccak (pronounced ket-chak) SHA-3 and also Keccak algorithm.
14
CHAPTER 3. SECURE HASH ALGORITHM-3 STANDARD
3.1
Comparison Parameters of Cryptographic Hash

Functions
Table below compares some properties of hash functions3 like message size, word
size, output digest size etc.
Algorithm
MD5
SHA-1
SHA-224,
SHA-256
SHA-384,
SHA-512,
SHA512/224,
SHA512/256
SHA-3
SHA3-224
SHA3-256
SHA3-384
SHA3-512
Output
Size(bits)
128
160
Internal
Block Length Word
Rounds
State
Size
Size
Size
Size
128
512
64
32
84
160
512
64
32
80
256/224
256
512
64
32
84
384/512/
224/256
512
1024
128
64
80
224/256/
384/512
1600
64
24
224
256
384
512
1600
1600
1600
1600
64
64
64
64
24
24
24
24
1600
2*bits
1152
1088
832
576
Table 3.1: Parameters of Cryptographic Hash Functions
3.2
Keccak SHA-3
Draft FIPS-202 is new SHA-3 standard based on Keccak, the algorithm NIST
has selected as the winner of the public SHA-3 Cryptographic Hash Algorithm
Competition.4 The SHA-3 family consists of four cryptographic hash functions
and two extendable output functions. All six functions share common structure
called as the sponge construction described in 3.2.1.
The four SHA-3 hash functions are SHA3-224, SHA3-256, SHA3-384 and SHA3512. Here suffix denotes length of output message digest. Two extendable output
Page 15

functions (XOFs) are SHAKE128 and SHAKE256. Where suffix number indicates
security strength that these two functions support.
3.2.1
Keccak-p Permutations
Keccak-p permutations are based on the equation Keccak-p[b, nr]. Here two
parameters are length of the string to be permuted, called width b and number of
iteration of an internal round called nr.
A round of Keccak-p permutation Rnd consists of a sequence of five round transformations. It is called step-mappings. Set of b-bit to the permutation is called
state. Seven possible values for Keccak-p is in table below,
b
w = b/25
l = log2(b/25)
25
1
0
50
2
1
100
4
2
200
8
3
400
16
4
800
32
5
1600
64
6
Table 3.2: Keccak-p Permutation width and related quantities

A is state array denotes 5-by-5-by-w, which represents state. A state represents
three dimension array A[x, y, z] where, 0 x < 5, 0 y < 5, 0 z < w. Converting
from state array to string and vice-versa, and labelling conventions are given in.4
The five step mappings that comprise a round of Keccak-p[b, nr] are denoted by
, , , , and . Each step mapping denoted by A takes an array and update it
to A. This is shown in figure 3.1 below,
3.2.2
Sponge Construction
SHA-3 uses sponge construction in its underlying structure which is same general
structure provided in other iterative hash functions. Sponge construction build a
function SPONGE[f,pad,r]. Where,
f is internal function used to process input block, r is the size of input block, also
called bit rate, pad is padding algorithm.
Page 16
Figure 3.1: Parts of the state array organized by dimensions

Figure 3.2 below shows the sponge construction of Keccak SHA-3.
3.2.3
Keccak[c] Specification
Keccak is family of sponge function with function as Keccak-p = [b, 2l+12] permutation as underlying function and padding rule pad1*01. Any specific function
from family is defined by choices of parameters rate r and capacity c such that
r+c is 25, 50, 100, 200, 400, 800, 1600. This is values of b specified in table 2.
DUT we have selected consist of 512-bit hash value for which value of b is 1600-
Page 17
Figure 3.2: Sponge Construction

bits. So, if we consider case with b=1600, Keccak family is denoted by Keccak[c];
in this case r is determined by choice of c. And
Keccak[c] = SPONGE[Keccak-p[1600, 24], pad10*1, 1600 c] Thus, given M and
output d we have,
Keccak[c] (M, d) = SPONGE[Keccak-p[1600, 24], pad10*1, 1600 c] (M, d)
3.2.4
SHA-3 Function Specification
Four SHA-3 hash functions defined from Keccak-p function specification in 2.2.3
and by appending two bits to the message are,
SHA3-224(M) = Keccak [448] (M || 01, 224)
SHA3-256(M) = Keccak[512] (M || 01, 256)
SHA3-384(M) = Keccak[768] (M || 01, 384)
SHA3-512(M) = Keccak[1024] (M || 01, 512)
And the two SHA-3 XOFs defined from Keccak are as following,
SHAKE128(M, d) = Keccak[256] (M || 1111, d)
SHAKE256(M, d) = Keccak[512] (M || 1111, d)
Here, two 11 bit appended to message provides domain specification. That is
Page 18

to distinguish XOFs from other four functions. And last two 11 bits appended
to message for compatibility with Sakura coding scheme. This scheme supports
development of function called tree hashing, in which parallel processing is applied
to compute and update digest of long messages more efficiently.7
3.3
3.3.1
Application of Cryptographic Hash Functions

Verify Message Integrity
Cryptographic hash functions are used to determine if any changes made to a

message or file. For example, compare message digest (hash value) before and
after transmission. MD5 or SHA-1 hashes are posted on website or forum for
the integrity of software being downloaded. An MD5 hash generated from an
OpenOffice.org download (v2.3.0 for Win32, English language) looks like this:
beda08800f9505117220b6db1deb453a
3.3.2
Password Verification
Storing passwords as plaintext can result in massive security breach if password

file goes to eavesdroppers hands. So, its secure to store message digest of each
password instead of plaintext. That is why secure website has options for password
reset instead of retrieving old passwords.
3.3.3
File or Data Identifier
Message digest are also used for reliably identifying files on several code management systems like Git, Mercurial or Monotone etc. uses sha1sum of various types
of content (file content, directory trees, ancestry information, etc.) to uniquely
identify them. Peer to Peer file sharing and Magnet links are other examples of
Hash identifiers.
Page 19
3.3.4
PRG and Key Derivation
Hash functions are also used to generate pseudorandom bits or to derive multiple
keys from a single key.
3.4
Conclusion
This chapter explains details of Secure Hash Algorithm-3 cryptographic algorithm.

It also gives comparison between MD5 and SHA family primitives. Important
step to look upon is Keccak SHA-3 specifications at algorithmic level. Some
applications of Cryptographic Hash Functions are also given.
Page 20
CHAPTER
4
Literature Survey
Literature referred for selecting out various key concepts are divided in four main
groups stated below,
4.1
Choosing Verification Methodology
Complex verification projects have span of various team of verification engineers

which are internal and external to the organization. Due to different incompatible
methodologies adaption by these teams, productivity is limited.
SystemVerilog provides OOPs features into testbench environment that is sufficient for modeling and verification. SystemVerilog is very expressive language and
extends in abstraction level from functional modeling to netlist level expressions.
It also provides domain-specific features like constraint randomization, temporal
assertions and functional coverage constructs. Although the language has all the
features needed SystemVerilog lacks in provisional of additional libraries, toolkit
and methodology documentation.
To overcome this bottleneck, Accellera has standardized first verification methodology as Universal Verification Methodology (UVM). Evolution of industry standard methodologies as discussed in1 led to release of UVM 1.0 by Accellera in Feb
2011. Comparison between SystemVerilog and UVM as between e and eRM is
also given in.1 As SystemVerilog is very large and its not possible for a working
engineer to learn all language features, built in library like UVM comes into play.
Shared responsibility between language features and libraries are explained in.1
21
CHAPTER 4. LITERATURE SURVEY

UVM is also revolutionary because it is built on older Open Verification Methodology (OVM), which again combines Mentor provided Advanced Verification Methodology (AVM) and Universal Reuse Methodology (URM) by Cadence with concepts
of e Reuse Methodology (eRM). UVM also includes code and concepts from Verification Methodology Manual (VMM) by Synopsys.
4.2
Testbench Architecture
Using standardization in developing testbench allows creation of portable, reusable

and compatible components. That in turn promotes creation of Verification IPs
(VIP) and Verification Components (VC). Verification Components are ready
made reconfigurable codes to be used as verification environments. UVM provide
extensive base classes to build VCs. Application of UVM in Unit Level verification
is explained in.9 After creating verification environment for unit level component
this environment (VC) can be used in higher hierarchies. Doing this leverages time
and expenses done in creation testbench environment of lower level hierarchies.
UVM testbench of unit component FIFO buffer module is created and reused in
I2C EEPROM slave module in.9 This helps in defining testbench architecture
with reusable component using UVM library method, like VC factory methods
and VC communication mechanism.
Parameterized testbench architecture is studied from.12 It discusses development
of parameterized UVM testbench, parameterized connection and DUT-TB connections. Parameterized design in testbench architecture provides highly flexible
and reusable testbench, which is used to verify parameterized DUT. Important
aspect of verification is layered testbench. In paper12 it is shown how to make
layered testbench structure parameterized with a method. Advantage of parameterized testbench is, developing single testbench for many designs having different
bus widths. For parameterized interfaces, basic verification requirements are to
configure driver and monitor with different bus widths. Approach in12 help resolve
this issue.
Page 22
4.3
Selecting Design Under Test
There are many Cryptographic cores used in wide range of digital systems. Any
application requiring security, like password management systems, ATM, Sensor Network, Communication networks employ application of Cryptography with
HW/SW. A broad field of Cryptographic primitives is has functions. Cryptographic Hash Functions are used in security of messages, password verification, to
check file integrity and Pseudo Random Number Generation (PRNG).
Well known and officially used Hash Function is Secure Hash Algorithm-1 (SHA1) and SHA-2. Recently serious attack has been published against SHA-1. It is
suggested that SHA-1 can be broken in near future. NIST has suggested moving
toward SHA-2 algorithm. While moving toward SHA-2 need for other more secure
hashing standard is needed for future replacements. While SHA-1 and SHA-2 share
same basic architectural elements, SHA-3 has been developed to complement SHA2 and provide greater security level. Need for different hardware implementations
of SHA-3 are discussed in.10 Detailed structure of SHA-3 Crypto Core and inside
functionality are explained in.11
4.4
SHA-3 FPGA Implementations
In,2 FPGA implementation of Keccak on Xilinx Vertex-5 FPGA is presented.

Some of the proposed implementation uses DSP48E block which also comes with
Xilinx Vertex-5 FPGA, its name for Xtreme DSP. The paper presents performance comparisons for Keccak implementations with and without Xtreme DSP
blocks.Implementation on FPGA requires Keccak specifications, architecture, considerations based on FPGA, which includes whether to use DSP48E block and use
of pipelining stages. After that in,2 synthesis results are recorded with Xilinx ISE
11 tool. Where target board used is XC5VSX240T-2FF1738. The measurements
are based on throughput and area considerations. Results are compared with
previous work, which shows considerable improvements. Also its stated that for
Page 23

design with low complexity use of DSP block is an inefficient method. The core
has been implemented on Xilinx Vertex-5, 6, 7 FPGA technologies.
In paper,6 two-staged pipelined architecture is implemented which can operate on
single or multiple block message lengths. Given SHA-3 pipelined hash core architecture consists, Transformation round, VSX module (used for version selection),
initial XORing and Control Unit. As opposed to existing Keccak implementations
VSX module is placed after initial XORing. Authors of 6 had made this choice so
as to implement the whole module as one component inside FPGA. This consequently leads to low routing overhead improving delay and area metrics. Proposed
architecture is described using VHDL and implemented inside Virtex-5 xc5vlx155t3FF1136, Virtex-6 xc6vlx240t-3FF784, and Virtex-7 xc7v855t-3FFG1157 FPGA
device using Xilinx ISE Design Suit v13.1. Initial logic before P&R (Post & Rout)
verified using ModelSim simulator by applying test vectors. On the board functionalities are verified using Xilinx ChipScope tool.
Implementation in8 has combined all five steps of SHA-3 functions in such a way
that it has 25 equations of 64-bits word each and having different set of inputs.
Throughput thus author gained is highest (best of his knowledge and till date
of paper writing) i.e 17.132Gbps and Throughput Per Area (TPA) is 13.27 on
Vertex-5 FPGA.
Paper5 presents compact design for SHA-3 Keccak on Xilinx Vertex-5 FPGA. By
logically merging Rho, Pi and Chi in one single step method in the paper saves
16% logical recourses for overall implementation. It reduces latency and hence
increases of frequency. Design only utilizes 240 slices and has frequency of 301.02
MHz. Design in this paper has Throughput Per Slice ratio (TPS) of 30.1
4.5
Conclusion
Here we have seen various aspects related to choosing verification methodology

to develop verification environment, entry of Keccak SHA-3 as newly developed
cryptographic hash function. Also various hardware architecture of SHA-3 on
Page 24

FPGA has been stated. That includes implementation of SHA-3 on FPGA with
Xtreme DSP blocks and two-staged pipelined architecture, merging of all five state
equations and merging of , and into one compression box.
Page 25
CHAPTER
5
SHA-3 Verification Plan
Verification plan gives us idea about two things mainly. Two questions are generally asked; what to verify? How to verify it? It is a blueprint of plan we
have established. The plan includes architecture of the DUT, specification extraction, creating test scenarios and testcases based on test scenarios. Verification
environment has been created based on the DUT architecture. This verification
environment includes VCs such as test module, environment module, agent and
score board etc.
Detailed verification plan also specifies DUT specifications, pin tables, VCs and
their interconnection based on verification methodology used and coverage plan.
Originally verification plan consist of verification environment, methodology used
and communication methods between VCs.
Another term is test plan, includes specific test to be applied and coverage planning. Test plan is very specific to DUT. It also includes development of function
model which is integrated in scoreboard. Function model can be developed by
personal other than verification engineer. Model in C language can be connected
by DPI-C functionality of SystemVerilog language. Detailed test plan is described
in figure below,
Specification for SHA-3 core is taken from Keccak SHA-3 documentation from
OpenCores.org. These specifications include signal details, timing and usage of
the core.
Specification for Keccak SHA-3 core is given below,
26
CHAPTER 5. SHA-3 VERIFICATION PLAN

1. Core has two different versions, high throughput core with 64-bit input and
low throughput core with 32-bit input.
2. Detailed working of SHA-3 algorithm is implemented as explained in section
3.
3. In high throughput core two rounds are done per clock cycle. It finishes
permutation in 12 clock cycles.
4. Low throughput core perform one round per clock cycle. It finishes permutation in 24 clock cycles.
5. Input signals are sampled at rising edge of clock.
6. Output signals are registered and not connected directly to combination logic
inside.
7. Reset core before calculating hash for new input value.
Pin signals of design is given in table below,

Port
Name
clk
reset
Width
1
1
Direction
in
in
in
byte num
in ready
is last
buffer full
out
out ready
64
3
1
1
1
512
1
in
in
in
in
out
out
out
Description
Clock applied
Synchronous reset aligned with posedge of
clk
input
Byte length of input
Input valid or not
Current input last or not
Buffer full(ready) or not
output hash result
output ready or not
Table 5.1: Pin details of high throughput SHA-3 core
5.1
Test Scenarios and Test Cases
Test scenarios and testcases based on that are given in table below,
Page 27

Port
Name
clk
reset
Width
1
1
Direction
in
in
in
byte num
in ready
is last
buffer full
out
out ready
32
2
1
1
1
512
1
in
in
in
in
out
out
out
Description
Clock applied
Synchronous reset aligned with posedge of
clk
input
Byte length of input
Input valid or not
Current input last or not
Buffer full(ready) or not
output hash result
output ready or not
Table 5.2: Pin details of low throughput SHA-3 core
5.2
Coverage Plan
To minimize wasted effort, coverage is used as a guide for directing verification

resources by identifying tested and untested portions of the design. - IEEE Standard for System Verilog (IEEE Std. 1800-2009)
5.2.1
Code Coverage
Code coverage can be of number of different types. Some of these types are listed
and explained in brief as given below,
Line Coverage/ Statement Coverage: It is required to get 100% line coverage in
any verification project. Line coverage includes every line of DUT code, it covers
only executable code portion and lines which are not executable such as module,
endmodule and timescale are not considered as part of line/ statement coverage.
Block Coverage: It is nearly same as statement coverage but only includes blocks
line if/else, wait, case statement etc. Block coverage is used to identify dead code
inside our design.
Conditional Coverage: It is also known as expression coverage. If Boolean conditions are given, then it will check for covered expression. It is ratio of expression
Page 28

covered to the total number of expressions.
Branch Coverage: It covers all conditions of branches. Branch such as if/else,
case statement and ternary operator are evaluated for all true/false conditions
and possible cases.
Path Coverage: This coverage is considered more complete than branch coverage
because number of path created by statements like if/else represents particular
sequence from which we can enter into simulation. Path coverage is relatively
difficult to perform.
Toggle Coverage: It measures number of times net or signal line toggles from 0
> 1 and 1 > 0. It gives information of the signal that did not change the state.
It is useful for gate level simulation.
FSM Coverage: It can be most complex coverage to achieve in design verification.
It gives information related to sates visited and transitions. State coverage gives
information about states covered. All state in State Machine should be covered.
Transition coverage will count number of transitions happed in our design. FSM
coverage can also inform about stuck transitions if error conditions are applied.
Goal of any verification project is to cover all coverage as much as possible. Time
to market and cost of bugs will also be considered. We can say that the design is
completely verified and has no bugs. But we can reduce possibility of having bugs
in certain stages by performing code coverage.
5.2.2
Functional Coverage
Functional coverage is better than code coverage and tells what features has been
tested by particular testcase applied. Function coverage is manually added to our
test environment. By performing functional coverage we can qualify our testbench.
It also gives details about testcases that are redundant. Functional coverage can be
performed by item coverage with cover groups, cross cover groups and transition
points.
Page 29
5.3
Verification Environment
Verification environment includes detailed testbench architecture with various

components and connection between them. We choose testbench architecture from
the verification methodology specified inside the test plan. Verification methodology followed here is UVM. So we will discuss UVM verification components with
respect to SHA-3 core integration.
Figure 5.1: Developed Verification Environment

To develop verification environment for SHA-3 core we need to create various
verification blocks, for which file system is as specified,
Scoreboard functionality is to compare all inputs to the relative outputs. And for
that scoreboard will be connected to SHA-3 functional model. Here, this functional
model can be in any foreign language like C, C++, Python etc or it can be created
in SystemVerilog. To connect SHA-3 functional model to scoreboard we require
DPI-C if the model is in C language.
Page 30
5.4
Conclusion
This chapter represents standard verification flow to be followed with the detailed
test plan. Detailed test plan consists of DUT specifications, understanding of the
pin signals and test scenarios and testcases are developed to test SHA-3 Core
thoroughly for normal operation, corner cases and error conditions. Also detailed
test plan requires developing verification environment which is also specified above.
Another important aspect of developing verification environment is to check for
error free working environment, it can be justified by performing sanity check. It
then follows connecting DUT to the environment and adding DUT specific changes
in UVM components.
Page 31
CHAPTER
6
Simulation Results
Based on the test scenarios and testcases created in chapter 5, simulation results
obtained from the testcases are,
6.1
Input golden message sequence
//sha3_base_test defined as virtual class

// It cant be extended
virtual class sha3_base_test extends uvm_test;
sha3_env env_h; //sha3_env handle
sequencer sequencer_h; //sequencer handle
// Build Phase and End_of_elaboration phase with print() method
// Constructor new()
endclass: sha3_base_test
Test sequence for tr1 test is defined in tr1 seq class pseudo code for which looks
like given below,
32
CHAPTER 6. SIMULATION RESULTS
class tr1_seq extends uvm_sequence #(uvm_sequence_item);

//factory registration macro
sequencer sequencer_h;
uvm_component uvm_component_h; //Temporary handle.
//Constructor method and handing over

//env_h.agent.sequencer_h to the sequencer handle
task body();
//Start sequences on sequencer_h
endtask : body
endclass : tr1_seq
Simulation waveform for tr1 test testcase is as shown below,
Figure 6.1: Test Scenario: Test Requirement 1

Figure 6.1 above shows Test Requirement 1, which is application of golden message
in hash functions. Golden message applied is The quick brown fox jumps over
the lazy dog. For that output hash value is:
Page 33

d135bb84d0439dbac432247ee573a23ea7d3c9deb2a968eb31d47c4fb45f1ef4
422d6c531b5b9bd6f449ebcc449ea94d0a8f05f62130fda612da53c79659f609
Which matches output shown in the waveform. Also for tr test, test hierarchy
using print() method created is given below,
Page 34

# ---------------------------------------------------------------# UVM-1.0p1
# (C) 2007-2011 Mentor Graphics Corporation
# (C) 2007-2011 Cadence Design Systems, Inc.
# (C) 2006-2011 Synopsys, Inc.
# ---------------------------------------------------------------# UVM_INFO @ 0: reporter [RNTST] Running test tr1_test...
# -----------------------------------------------------------------# Name
Type
Size
Value
# -----------------------------------------------------------------# uvm_test_top
tr1_test
@460
sha3_env
@468
sha3_agent
@475
env_h
agent
agent_ap
uvm_analysis_port
@493
driver
sha3_driver
@501
rsp_port
uvm_analysis_port
@516
sqr_pull_port
uvm_seq_item_pull_port
@508
sha3_monitor
@524
uvm_analysis_port
@642
uvm_sequencer
@531
#
#
#
monitor
monitor_ap
sequencer_h
rsp_export
uvm_analysis_export
@538
seq_item_export
uvm_seq_item_pull_imp
@632
arbitration_queue
array
lock_queue
array
num_last_reqs
integral
32
d1
num_last_rsps
integral
32
d1
sha3_scoreboard
@482
uvm_tlm_analysis_fifo #(T)
@664
#
#
scoreboard
fifo
analysis_export
uvm_analysis_imp
@703
get_ap
uvm_analysis_port
@695
get_peek_export
uvm_get_peek_imp
@679
put_ap
uvm_analysis_port
@687
put_export
uvm_put_imp
@671
scoreboard_ae
uvm_analysis_export
@656
Page 35
6.2
Input empty message sequence
Test Requirement 2 checks for application of empty input message on design under
test. Here, empty string is represented by and shown in waveform as sequence
of zeros. Application of tr2 test on Low throughput SHA-3 Core leads to message
digest after 24 clocks. And High throughput core yields same 512-bits of output
digest in 12 clock cycles.
Pseudo code for Test Requirement is given below,
class tr3_seq extends base_sequence;
uvm_object_utils(tr3_seq);
// Sequence handles
function new(string name = "tr3_seq");

super.new(name);
//Create Sequences
endfunction : new
task body();
//Start sequences
endtask : body
endclass : tr3_seq
6.3
Input very long message sequence
6.4
Coverage Results
Page 36
Page 37
Figure 6.4: Coverage Results
Page 38
CHAPTER
Do not include conclusion and future work in same chapter.

Keep separate.
Conclusion and Future Work
Aim of the thesis work is to create verification environment for SHA-3 Crypto
Processor Core in SystemVerilog Hardware Description and Verification Language
using UVM 1.1 accellera standard methodology. UVM 1.1 library comes with
QuestaSim 10.0b Simulation tool. The UVM based environmet contains standard
UVM Verification Components, Driver, Monitor, Agen, Env etc, connected via
virtual interface. Complexity of Keccak SHA-3 Crpto Core requires structural
testbench concepts used in industry. UVM methodology is industry standard
methodology evolved from OVM and VMM. With the use of HVL and appropriate methodology, to verify DUT, coverage management helps keep track of
coverage result in terms of code coverage and functional coverage. Appropriate
coverage closure enables achieve time-to-market and cost control. Coverage management being important aspect, in this work code coverage report has been created using test regression and coverage UVC keeps track of functional coverage.
Testcases have been developed considering test scenarios for appropriate functionalities. Scope of this work can also be extended to design Keccak SHA-3 RTL/
other SHS (Secure Hash Standard) RTLs and implementation on Xilinx FPGA
families for throughput and area improvement considerations. And Verification
Environment created in this work can be applied to verify RTL functionality with
minimum re-configuration applied on the Verification Environment.
39
Bibliography
[1] Jonathan Bromley. if systemverilog is so good, why we need the uvm? sharing responsibilities between libraries and the core language. in Specification
& Design Languages (FDL), April 2013.
[2] Provelengios G.; Kitsos P.; Sklavos N.; Koulamas C. fpga-based design
approaches of keccak hash function. 15th Euromicro Conference on Digital
System Design (DSD), October 2012.
[3] NIST Computer Security Division (CSD). secure hash standard (shs). In
FIPS PUB 180-4, NIST. Available online at, October 2014.
[4] NIST Computer Security Division (CSD). sha-3 standard: Permutationbased hash and extendable-output functions. Available online at, October
2014.
[5] Arshad A.; Kundi D. e. S. ; Aziz A. compact implementation of sha3-512 on
fpga. Conference on Information Assurance and Cyber Security (CIACS),
October 2014.
[6] Athanasiou G.S.; Makkas G.-P.; Theodoridis G. high throughput pipelined
fpga implementation of the new sha-3 cryptographic hash algorithm. in
6th IEEE International Symposium on Communications, Control and Signal
Processing (ISCCSP), October 2014.
[7] Michael Peeters Guido Bertoni, Joan Daemen and Gilles Van Assche. the
keccak reference. Available online at, October 2014.
[8] Rao M.; Newe T.; Grout I. efficient high speed implementation of secure
hash algorithm-3 on virtex-5 fpga. IEEE 23rd International Symposium on
Industrial Electronics (ISIE), October 2014.
40
BIBLIOGRAPHY
[9] Francesconi J.; Agustin Rodriguez J.; Julian P.M.
uvm based test-
bench architecture for unit verification. Argentine Conference on MicroNanoelectronics, Technology and Applications (EAMTA), October 2014.
[10] N. Sklavos. towards to sha-3 hashing standard for secure communications:
On the hardware evaluation development. in Latin America Transactions,
IEEE, October 2012.
[11] W. Stallings. inside sha-3. in Potentials, IEEE, October 2013.
[12] Geng Zhong; Jian Zhou ; Bei Xia. parameter and uvm, making a layered testbench powerful. IEEE 10th International Conference on ASIC (ASICON),
October 2013.
Page 41
APPENDIX
A
List of Abbreviations
IEEE
Institute of Electrical and Electronics Engineers
ASIC
Application Specific Integrated Circuit
EDA
Electronic Design Automation
RTL
Register Transfer Level
HDL
Hardware Description Language
FPDA
Field Programmable Gate Array
DSP
Digital Signal Processing
FIFO
First In First Out
DUT-TB
Design Under Test - Testbench
VC
Verification Component
VIP
Verification Intellectual Property (IP)
UVM
Universal Verification Methodology
OVM
Open Verification Methodology
eRM
e Reuse Methodology
VMM
Verification Methodology Manual
AVM
Advanced Verification Methodology
NIST
National Institute of Standards and Technology
FIPS-PUB
Federal Information Processing Standards Publication
SHA
Secure Hash Algorithm
AES
Advanced Encryption Standard
RSA
Ron Rivest, Adi Shamir and Leonard Adleman
42
APPENDIX
B
Package File: sha3 pkg.svh
package sha3_pkg;
// Include Package Items and Macros

import uvm_pkg::*;
include "uvm_macros.svh"
// Define Sequencer, Include Sequence Items

include "sequence_item.svh"
typedef uvm_sequencer#(sequence_item) sequencer;
// Sequences
include "sequences/base_sequence.svh"
include "sequences/reset_seq.svh"
include "sequences/init_seq.svh"
include "sequences/strt_ctrl_seq.svh"
include "sequences/finish_ctrl_seq.svh"
include "sequences/msg_seq.svh"
include "sequences/empty_msg_seq.svh"
include "sequences/rndmsg_seq.svh"
include "sequences/long_msg_seq.svh"
include "sequences/tr1_seq.svh"
43
APPENDIX B. PACKAGE FILE: SHA3 PKG.SVH
// UVM Components
include "sha3_driver.svh"
include "sha3_monitor.svh"
include "sha3_agent_config.svh"
include "sha3_agent.svh"
include "sha3_scoreboard.svh"
include "sha3_env.svh"
// Base Test and Extended Tests

include "test/sha3_base_test.svh"
include "test/tr1_test.svh"
endpackage: sha3_pkg
Page 44
APPENDIX
File System Hierarchy
sha3_uvm
|__ main
|
|__ high_throughput_core
|__ low_throughput_core
|__ testbench
|__ sequences
|__ msg_seq.svh
|__ reset_seq.svh
|__ rndmsg_seq.svh
|__ empty_seq.svh
|__ tr1_seq.svh
|__ tr2_seq.svh
|__ tr3_seq.svh
|__ test
|__ sha3_base_test.svh
|__ tr1_test.svh
|__ tr2_test.svh
|__ tr3_test.svh
|__ sequence_item.svh
|__ sha3_agent.svh
|__ sha3_driver.svh
|__ sha3_env.svh
|__ sha3_monitor.svh
|__ sha3_scoreboard.svh
45
APPENDIX C. FILE SYSTEM HIERARCHY

|__ dut_htc.f
|__ dut_ltc.f
|__ interface_htc.sv
|__ interface_ltc.sv
|__ run.do
|__ sha3_pkg.svh
|__ tb.f
|__ top.sv
|__testcases.xlsx
Page 46
APPENDIX
D
Review Card Compliance
Remove space
47
Where is Guide signature ?????
APPENDIX D. REVIEW CARD COMPLIANCE

No. Comments Given By External Review
Panel
1
Instead of generalized verification
plan, a detailed verification plan for
your project should be written.
Literature survey on more IEEE
papers should be done.
2 More testcases for specification is
required
Mdification done based on

Comments
Came up with specific testplan
and working on it.
Came up with more test

scenarios and different
combinations and started
working on coding and
implementation of them.
Publish one paper in reputed journal.

Verification concept extend, upto
functional verification
Implement on Xilinx FPGA for
throughput and power considerations.
Page 53
APPENDIX
Research Paper & Publication Certificate
Writing Paper
Add research paper full text and certificate
54
APPENDIX
F
Plagiarism Report
55
Mayur Kubavat
ORIGINALITY REPORT
11
SIMILARIT Y INDEX
9%
0%
7%
INT ERNET SOURCES
PUBLICAT IONS
ST UDENT PAPERS
PRIMARY SOURCES
Submitted to Institute of Technology, Nirma

University
5%
St udent Paper
2
3
4
4%
csrc.nist.gov
Int ernet Source
2%
en.wikipedia.org
Int ernet Source
1%
Submitted to Manipal University

St udent Paper
EXCLUDE QUOT ES
ON
EXCLUDE
BIBLIOGRAPHY
ON
EXCLUDE MAT CHES
< 1%
APPENDIX
G
Progress Report
57
C-DAC & GUJARAT TECHNOLOGICAL UNIVERSITY

Dissertation Phase - II Consolidated Progress Report
Date: 15/05/2015
Enrollment No. : 131060752013
Branch Name: VLSI and Embedded System Design
Name of Student: Kubavat Mayur Navinchandra
Title of the thesis: Development of Verification Environment for SHA-3 Core using UVM
Name of Theme: ASIC Verification, UVM
Name of Supervisor: Mr. Ashish Prabhu
1. Review of Literatures for finding of Research Gap ; its relevance

Using standardization in developing testbench allows creation of portable, reusable and compatible
components. That in turn promotes creation of Verification IPs (VIP) and Verification Components (VC).
Verification Components are ready made reconfigurable codes to be used as verification environments.
UVM provide extensive base classes to build VCs. After creating verification environment for unit level
component this environment (VC) can be used in higher hierarchies. Doing this leverages time and
expenses done in creation testbench environment of lower level hierarchies.
UVM Based Testbench Architecture for Unit Verification
In this paper UVM is analyzed throughout its application that targets FIFO buffer module and
I2C EEPROM Slave Module. Paper also discusses Key concepts of UVM Class library,
Component Class, Transaction Class, and application of these features on above stated
modules.
Parameter and UVM, Making a Layered Testbench Powerful
Here focus is on creating parameterized UVM, interconnections and interoperation which is
proven useful in different kinds of scenarios.
If SystemVerilog Is So Good, Why Do We Need the UVM?
Comparison of sharing Responsibilities between Libraries and the Core Language has been
discussed in the paper. It also explores relationship between SV and UVM.
Page 1 of 3

2. Objectives of the Research Work
1) To develop verification environment for SHA-3 RTL,
2) Use UVM methodology with SystemVerilog,
3) Develop Verification component,
Driver
Monitor
Sequencer
Agent (Configurable)
Active & Passive
Scoreboard
Env
4) Develop Test Sequences and Run on environment
5) Develop Error cases
6) Coverage Reports. Achieve complete code coverage, define and implement parameters for
functional coverage.
3. Hypotheses: Relevance and in accordance to the Research Area

To verify ASIC, linear testbench comes short. Modular testbench introduces concept of reuse into the
code. To utilize OOPs and reusability in ASIC verification, UVM methodology is exercised in industry. So,
to critically analyse and apply Accellera standard methodology to the SHA-3 RTL core, which would
eventually be very important to standard development and improvement. Taking this need in
consideration, dissertation work describes flow from specification extraction to development of
verification environment and coverage reports. And creating and coding all possible test scenarios and
testcases to verify DUT thoroughly.
4. Research Methodology
1) Methodology followed is industry standard procedure used in RTL Design/Verification domain.
2) Specification Extraction from the SHA-3 Core,
3) Defining Test Scenarios and creating Testcases,
4) Development of UVM verification environment,
5) Create and apply sequences to the testbench
6) Collection of coverage information and report generation.
5. Data Analysis and interpretation

Achieving 100% code coverage by means of Test Sequences and Test Cases.
Define functional coverage parameters. And measure them against test sequences.
Page 2 of 3

6. Suggestions in the past review
Date
18/11/2015
Review
Literature Review
Suggestions
Instead of generalized verification plan, a
detailed verification plan for your project
should be work on.

Literature survey on more IEEE papers should
be done.
29/12/2015
Dissertation Phase - 1
More test cases for specification is required.
13/04/2015
Mid-Semester Review
Publish one paper in a reputed journal.
Verification Concept extend, up-to
functional verification.
Implement on Xilinx FPGA for throughput
& power considerations.
7. Status of work progress.
Completed
Literature review and its relevance,
Specification extraction,
Create Test Scenarios and Testcases,
Study of SystemVerilog and Universal
Verification Methodology,
Development of major components inside
To be done
Achieve 100% code coverage,
Generate coverage report,

Defining parameters for functional
coverage.
UVM environment,
Integrating UVM environment with SHA-3
Core,
Run basic sequence.
Code testcases and running combination of
sequences,
8. Any other information (publications etc.)

List of some good journals has been chosen, preparation of paper is in progress.
Page 3 of 3

UVM Verification Environment

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

UVM Verification Environment

Enviado por

Direitos autorais:

Formatos disponíveis

Development of Verification Environment for SHA-3

Core using UVM

Gujarat Technological University, PG SCHOOL

Gujarat Technological University, Ahmedabad

Date: June 2015

Signature and Name

Mr. Ashish Prabhu

PAPER PUBLICATION CERTIFICATE

Mr. Ashish Prabhu

THESIS APPROVAL CERTIFICATE

Date: June 2015

Examiners Sign and Name:

Date: June 2015

Mr. Ashish Prabhu

Enrollment No. 131060752013

Institute Code: 106

Mayur Kubavat (131060752013)

Thesis Approval Certificate

2 Universal Verification Methodology

UVM Class Library . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Secure Hash Algorithm-3 Standard

Comparison Parameters of Cryptographic Hash Functions

SHA-3 Function Specification . . . . . . . . . . . . . . . . . 18

Application of Cryptographic Hash Functions . . . . . . . . . . . . 19

Verify Message Integrity . . . . . . . . . . . . . . . . . . . . 19

File or Data Identifier . . . . . . . . . . . . . . . . . . . . . 19

Mayur Kubavat (131060752013)

PRG and Key Derivation . . . . . . . . . . . . . . . . . . . . 20

Choosing Verification Methodology . . . . . . . . . . . . . . . . . . 21

Selecting Design Under Test . . . . . . . . . . . . . . . . . . . . . . 23

SHA-3 FPGA Implementations . . . . . . . . . . . . . . . . . . . . 23

5 SHA-3 Verification Plan

Test Scenarios and Test Cases . . . . . . . . . . . . . . . . . . . . . 27

Input golden message sequence . . . . . . . . . . . . . . . . . . . . 32

Input empty message sequence . . . . . . . . . . . . . . . . . . . . . 36

Input very long message sequence . . . . . . . . . . . . . . . . . . . 36

Mayur Kubavat (131060752013)

B Package File: sha3 pkg.svh

C File System Hierarchy

D Review Card Compliance

E Research Paper & Publication Certificate

Mayur Kubavat (131060752013)

Timeline: Verification Methodologies . . . . . . . . . . . . . . . . .

A Typical Verification Environment

A Partial UVM Class Hierarchy . . . . . . . . . . . . . . . . . . . .

Phases in UVM (source: soccentral.com) . . . . . . . . . . . . . . . 10

Producer-Consumer with put method

Producer Gets from Consumer

Parts of the state array organized by dimensions

Developed Verification Environment

Test Scenario: Test Requirement 1 . . . . . . . . . . . . . . . . . . 33

Test Scenario: Test Requirement 2 . . . . . . . . . . . . . . . . . . 37

Test Scenario: Test Requirement 3 . . . . . . . . . . . . . . . . . . 37

TLM 1.0 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Parameters of Cryptographic Hash Functions . . . . . . . . . . . . . 15

Keccak-p Permutation width and related quantities . . . . . . . . . 16

Pin details of high throughput SHA-3 core . . . . . . . . . . . . . . 27

Pin details of low throughput SHA-3 core . . . . . . . . . . . . . . . 28

Development of Verification Environment for SHA-3

Following increasing logic complexity in digital ICs, verification requirements has

The thesis aims at applying hardware verification concept to the cryptographic

Mayur Kubavat (131060752013)

Mayur Kubavat (131060752013)

Expected outcome from this dissertation work include, complete understanding