From 2ab298eb2d550acb2bf30d00f656465c4da5d30f Mon Sep 17 00:00:00 2001 From: Mayur Kubavat Date: Tue, 30 Jun 2015 14:50:14 +0100 Subject: [PATCH] First Commit. Report Added. --- .gitignore | 5 ++ abstract.tex | 23 ++++++ abstract2.tex | 3 + acknowledge.tex | 16 +++++ acknowledge2.tex | 3 + appendix.tex | 4 ++ appendixa.tex | 25 +++++++ appendixb.tex | 83 ++++++++++++++++++++++ appendixc.tex | 3 + appendixd.tex | 30 ++++++++ appendixe.tex | 5 ++ approvalcerti.tex | 22 ++++++ cdac.tex | 3 + certificate.tex | 31 ++++++++ certificate2.tex | 35 +++++++++ chap1.tex | 46 ++++++++++++ chap2.tex | 149 +++++++++++++++++++++++++++++++++++++++ chap3.tex | 139 ++++++++++++++++++++++++++++++++++++ chap4.tex | 43 +++++++++++ chap5.tex | 165 +++++++++++++++++++++++++++++++++++++++++++ chap6.tex | 176 ++++++++++++++++++++++++++++++++++++++++++++++ conclusion.tex | 4 ++ contents.tex | 5 ++ declaration.tex | 30 ++++++++ futurework.tex | 3 + main.tex | 124 ++++++++++++++++++++++++++++++++ plagiarism.tex | 2 + references.bib | 115 ++++++++++++++++++++++++++++++ titlepage.tex | 37 ++++++++++ 29 files changed, 1329 insertions(+) create mode 100644 .gitignore create mode 100644 abstract.tex create mode 100644 abstract2.tex create mode 100644 acknowledge.tex create mode 100644 acknowledge2.tex create mode 100644 appendix.tex create mode 100644 appendixa.tex create mode 100644 appendixb.tex create mode 100644 appendixc.tex create mode 100644 appendixd.tex create mode 100644 appendixe.tex create mode 100644 approvalcerti.tex create mode 100644 cdac.tex create mode 100644 certificate.tex create mode 100644 certificate2.tex create mode 100644 chap1.tex create mode 100644 chap2.tex create mode 100644 chap3.tex create mode 100644 chap4.tex create mode 100644 chap5.tex create mode 100644 chap6.tex create mode 100644 conclusion.tex create mode 100644 contents.tex create mode 100644 declaration.tex create mode 100644 futurework.tex create mode 100644 main.tex create mode 100644 plagiarism.tex create mode 100644 references.bib create mode 100644 titlepage.tex diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..9726208 --- /dev/null +++ b/.gitignore @@ -0,0 +1,5 @@ +*.aux +*.log +*.pdf +*.jpg +/images \ No newline at end of file diff --git a/abstract.tex b/abstract.tex new file mode 100644 index 0000000..7fc173c --- /dev/null +++ b/abstract.tex @@ -0,0 +1,23 @@ +\thispagestyle{plain} + +\begin{center} + \vspace{1cm} + + \bigsize{\textbf{Development of Verification Environment for SHA-3 Core using UVM}} + + \vspace{1.5cm} + + \normalsize + By\\ + \textbf{Mayur Navinchandra Kubavat}\\ + \textbf{(131060752013)} \\ + Guided By\\ + \textbf{Mr.Ashish Prabhu}\\ + \textbf{Sr. Verification Engineer, LSI India R\&D} + + \bigsize\textbf\textit\underline{ABSTRACT} +\end{center} + +As CMOS technology advances, complexity of ICs also increases. Moore’s 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. \par + +This dissertation work is induced from necessity of development of UVM based verification environment. Proposed work in this thesis describes flow from specification extraction to development of verification environment and implements UVM based reusable verification environment. \par \ No newline at end of file diff --git a/abstract2.tex b/abstract2.tex new file mode 100644 index 0000000..91807f9 --- /dev/null +++ b/abstract2.tex @@ -0,0 +1,3 @@ +\thispagestyle{plain} + +Expected result from this dissertation work includes, developing of UVM component for verification environment, integrating design under test with developed environment, creating test cases, complete code coverage and detailed documentation about them all. We also try to achieve higher functional coverage report in our verification environment. Use of scripting is made to execute commands in batch mode. The verification environment is reused between low and high-throughput cores. This dissertation work on development of UVM based verification environment will try to bridge gap between Academia and Indutry practices. \ No newline at end of file diff --git a/acknowledge.tex b/acknowledge.tex new file mode 100644 index 0000000..3765379 --- /dev/null +++ b/acknowledge.tex @@ -0,0 +1,16 @@ +\thispagestyle{plain} + +\begin{center} + \midsize\textbf{\underline {ACKNOWLEDGMENT}} + \addcontentsline{toc}{chapter}{Acknowledgment} +\end{center} + +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 \textbf{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. + +Credits also go to my friends and senior students, including \textbf{Pankaj Chavda} for his valuable suggestion and support time and again. + +And I thank \textbf{Gujarat Technological University, Ahmedabad} and \textbf{CDAC ACTS, Pune} for providing IEEE Xplore subscription. + +\vspace{4cm} + + \hfill \hfill \textbf{Mayur Kubavat} (131060752013) \ No newline at end of file diff --git a/acknowledge2.tex b/acknowledge2.tex new file mode 100644 index 0000000..2c75852 --- /dev/null +++ b/acknowledge2.tex @@ -0,0 +1,3 @@ +\thispagestyle{plain} + +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. \ No newline at end of file diff --git a/appendix.tex b/appendix.tex new file mode 100644 index 0000000..2267dbb --- /dev/null +++ b/appendix.tex @@ -0,0 +1,4 @@ +\begin{appendices} +\chapter{Some Appendix} +The contents... +\end{appendices} \ No newline at end of file diff --git a/appendixa.tex b/appendixa.tex new file mode 100644 index 0000000..63f54ef --- /dev/null +++ b/appendixa.tex @@ -0,0 +1,25 @@ +\begin{appendices} +\chapter{List of Abbreviations} +\NumTabs{6} + +IEEE \tab{Institute of Electrical and Electronics Engineers} \\ +ASIC \tab{Application Specific Integrated Circuit} \\ +EDA \tab{Electronic Design Automation} \\ +RTL \tab{Register Transfer Level} \\ +HDL \tab{Hardware Description Language} \\ +FPDA \tab{Field Programmable Gate Array} \\ +DSP \tab{Digital Signal Processing} \\ +FIFO \tab{First In First Out} \\ +DUT-TB \tab{Design Under Test - Testbench} \\ +VC \tab{Verification Component} \\ +VIP \tab{Verification Intellectual Property (IP)} \\ +UVM \tab{Universal Verification Methodology} \\ +OVM \tab{Open Verification Methodology} \\ +eRM \tab{e Reuse Methodology} \\ +VMM \tab{Verification Methodology Manual} \\ +AVM \tab{Advanced Verification Methodology} \\ +NIST \tab{National Institute of Standards and Technology} \\ +FIPS-PUB \tab{Federal Information Processing Standards Publication} \\ +SHA \tab{Secure Hash Algorithm} \\ +AES \tab{Advanced Encryption Standard} \\ +RSA \tab{Ron Rivest, Adi Shamir and Leonard Adleman} \ No newline at end of file diff --git a/appendixb.tex b/appendixb.tex new file mode 100644 index 0000000..f7cf9d2 --- /dev/null +++ b/appendixb.tex @@ -0,0 +1,83 @@ +\chapter{Package File: sha3\_pkg.svh} + +\begin{verbatim} +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/msg_seq.svh" +`include "sequences/empty_msg_seq.svh" +`include "sequences/long_msg_seq.svh" +`include "sequences/tr1_seq.svh" +`include "sequences/tr2_seq.svh" +`include "sequences/tr3_seq.svh" +`include "sequences/tr4_seq.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" +`include "test/tr2_test.svh" +`include "test/tr3_test.svh" +`include "test/tr4_test.svh" + +endpackage: sha3_pkg + +\end{verbatim} + +\newpage +\section{File System Hierarchy} +% To print plaintext +\begin{verbatim} +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 +| | |__ tr4_seq.svh +| |__ test +| | |__ sha3_base_test.svh +| | |__ tr1_test.svh +| | |__ tr2_test.svh +| | |__ tr3_test.svh +| | |__ tr4_test.svh +| |__ sequence_item.svh +| |__ sha3_agent.svh +| |__ sha3_driver.svh +| |__ sha3_env.svh +| |__ sha3_monitor.svh +| |__ sha3_scoreboard.svh +|__ dut_htc.f +|__ dut_ltc.f +|__ interface_htc.sv +|__ interface_ltc.sv +|__ run.do +|__ sha3_pkg.svh +|__ tb.f +|__ top.sv +|__testcases.xlsx +\end{verbatim} \ No newline at end of file diff --git a/appendixc.tex b/appendixc.tex new file mode 100644 index 0000000..93ca8a9 --- /dev/null +++ b/appendixc.tex @@ -0,0 +1,3 @@ +\addcontentsline{toc}{chapter}{Paper} +\includepdf[pages={1-5}]{1432358802.pdf} +\includepdf[pages={1}]{eCertificate.pdf} \ No newline at end of file diff --git a/appendixd.tex b/appendixd.tex new file mode 100644 index 0000000..e6f0e71 --- /dev/null +++ b/appendixd.tex @@ -0,0 +1,30 @@ +\chapter{} +\addcontentsline{toc}{chapter}{Review Card Compliance} +%Image +\includepdf{01.jpg} + +%Image +\includepdf{02.jpg} + +%Image +\includepdf{03.jpg} + +%Image +\includepdf{04.jpg} + +%Image +\includepdf{05.jpg} + +\begin{table}[ht] +\begin{tabulary}{1.0\textwidth}{|C|L|L|} +\hline + No. & Comments Given By External Review Panel & Mdification done based on Comments\\ +\hline + 1 & \nextitem Instead of generalized verification plan, a detailed verification plan for your project should be written.\nextitem Literature survey on more IEEE papers should be done. & Came up with specific testplan and working on it.\\ +\hline + 2 & More testcases for specification is required & Came up with more test scenarios and different combinations and started working on coding and implementation of them.\\ +\hline + 3 & \nextitem Publish one paper in reputed journal. \nextitem Verification concept extend, upto functional verification \nextitem Implement on Xilinx FPGA for throughput and power considerations. & Paper has been published in a reputed journal on May 15, 2015 issue. \nextitem Verification concept has been extended for functional coverage introduction in DUT. \nextitem As work is verification with SV UVM, design \& implementation not considered and are out of the scope of the theme.\\ +\hline +\end{tabulary} +\end{table} \ No newline at end of file diff --git a/appendixe.tex b/appendixe.tex new file mode 100644 index 0000000..594b9eb --- /dev/null +++ b/appendixe.tex @@ -0,0 +1,5 @@ +\addcontentsline{toc}{chapter}{Progress Report} + +\includepdf[pages={1-4}]{Report4Page.pdf} + +\end{appendices} \ No newline at end of file diff --git a/approvalcerti.tex b/approvalcerti.tex new file mode 100644 index 0000000..4160b06 --- /dev/null +++ b/approvalcerti.tex @@ -0,0 +1,22 @@ +\thispagestyle{plain} + +\thiswatermark{\centering \put(0,-575){\includegraphics[scale=0.4]{gtu-hd-rgb.png}} } + +\begin{center} + \midsize\textbf{\underline {THESIS APPROVAL CERTIFICATE}} + \addcontentsline{toc}{chapter}{Thesis Approval Certificate} +\end{center} + +This is to certify that research work embodied in this thesis entitled \textbf{``Development of Verification Environment for SHA-3 Core using UVM"} carried out by \textbf{Mr. Mayur Navinchandra Kubavat} (Enrollment No. \textbf{131060752013}) at \textbf{Gujarat Technological University PG School (106), Ahmedabad} is approved for the degree of Master of Engineering with specialization of \textbf{(Electronics \& Communication Engineering) in VLSI \& Embedded Systems Design} by Gujarat Technological University. + + \vspace {0.5cm} + + \textbf{Date: June 2015} \\ + \textbf{Place: Ahmedabad} + + \vspace {1.0cm} + + \textbf{Examiners Sign and Name:} + \vspace{1.0cm} + + ......................................................... ......................................................... diff --git a/cdac.tex b/cdac.tex new file mode 100644 index 0000000..9e107f5 --- /dev/null +++ b/cdac.tex @@ -0,0 +1,3 @@ +\addcontentsline{toc}{chapter}{CDAC Certificate} +%Image +\includepdf{CDAC.jpg} diff --git a/certificate.tex b/certificate.tex new file mode 100644 index 0000000..37749a7 --- /dev/null +++ b/certificate.tex @@ -0,0 +1,31 @@ +\thispagestyle{plain} + +\begin{center} + \midsize\textbf{\underline {CERTIFICATE}} + \addcontentsline{toc}{chapter}{Certificate} +\end{center} + +This is to certify that research work embodied in this Thesis entitled \textbf{"Development of Verification Environment for SHA-3 Core using UVM"} was carried out by \textbf{Mr. Mayur Navinchandra Kubava (131060752011) at Gujarat Technological University PG School (106), Ahmedabad} for partial fulfillment of Master of Engineering degree, \textbf{(Electronics \& Communication Engineering) in VLSI \& Embedded Systems Design}, to be awarded by Gujarat Technological University. This research work has been carried out under my supervision and is to my satisfaction. + + \vspace {1cm} + + \textbf{Date: June 2015} \\ + \textbf{Place: Ahmedabad} + + \vspace{2cm} + + \begin{tabular}{c m{4cm} c} + \textbf{Signature of Guide} & & \textbf{Signature and Name} \\ + & & \textbf{of Principle} \\ + \end{tabular} + + \vspace{2.5cm} + + \begin{center} + + \textbf{Principal}\\ + \vspace{2.5cm} + \textbf{Seal of Institute} + \end{center} + +\thiswatermark{\centering \put(0,-575){\includegraphics[scale=0.4]{gtu-hd-rgb.png}} } \ No newline at end of file diff --git a/certificate2.tex b/certificate2.tex new file mode 100644 index 0000000..6338840 --- /dev/null +++ b/certificate2.tex @@ -0,0 +1,35 @@ +\thispagestyle{plain} + +\thiswatermark{\centering \put(0,-575){\includegraphics[scale=0.4]{gtu-hd-rgb.png}} } + + +\begin{center} + \midsize + \textbf{\underline {COMPLIANCE CERTIFICATE}} + \addcontentsline{toc}{chapter}{Compliance Certificate} +\end{center} + +This is to certify that research work embodied in this thesis entitled \textbf{``Development of Verification Environment for SHA-3 Core using UVM"} was carried out by \textbf{Mr. Mayur Navinchandra Kubavat} (Enrollment No. \textbf{131060752013}) at \textbf{Gujarat Technological University PG School (106), Ahmedabad} for partial fulfillment of Master of Engineering degree, \textbf{(Electronics \& Communication Engineering) in VLSI \& Embedded Systems 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. + + \begin{tabular}{c m{4cm} c} + \textbf{Signature of Student:} & &\textbf{Signature of Guide:} \\ + \textbf{Kubavat Mayur N.} & &\textbf{Mr. Ashish Prabhu} + \end{tabular} + +\thispagestyle{plain} +\vspace{0.5cm} + +\begin{center} + \midsize + \textbf{\underline {PAPER PUBLICATION CERTIFICATE}} +\end{center} + +This is to certify that research work embodied in this thesis entitled \textbf{``Development of Verification Environment for SHA-3 Core using UVM"} carried out by \textbf{Mr. Mayur Navinchandra Kubavat} (Enrollment No. \textbf{131060752013}) at \textbf{Gujarat Technological University PG School (106), Ahmedabad} for partial fulfillment of Master of Engineering degree, \textbf{(Electronics \& Communication Engineering) in VLSI \& Embedded Systems Design}, to be awarded by Gujarat Technological University, has published article entitled \textbf{``Development of UVM based Reusable Verification Environment for SHA-3 Cryptographic Core"} for publication by the \textbf {IJRITCC, during Volume 3 Issue 5 on 15 May 2015.} + + \textbf{Date: June 2015} \\ + \textbf{Place: Ahmedabad} + + \begin{tabular}{c m{4cm} c} + \textbf{Signature of Student:} & &\textbf{Signature of Guide:} \\ + \textbf{Kubavat Mayur N.} & &\textbf{Mr. Ashish Prabhu} + \end{tabular} \ No newline at end of file diff --git a/chap1.tex b/chap1.tex new file mode 100644 index 0000000..0fdda61 --- /dev/null +++ b/chap1.tex @@ -0,0 +1,46 @@ +\chapter{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. Here, verification environment for SHA-3 Cryptographic Core is proposed and developed using UVM methodology. Literature which is surveyed to come up for the thesis selection is outlined in Literature Survey section. SHA-3 is cryptographic hash function and used in many applications including data integrity, password matches, etc. Proposed verification uses concept of OOPs provided in SystemVerilog language with UVM industry standard methodology used in ASIC/SoC verification. + +\section{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. + + +\section{Motivation} + +Following increasing logic complexity in digital ICs, verification requirements has also become complex. To address this issue SystemVerilog Hardware Verification 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. \par + +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 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\cite{fips202}. \par + +Combining above best practices, flow of development of verification environment for Keccak SHA-3 core using UVM is described in this report. + +\section{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. Proposed environemt can be used to verify other cryptographic RTLs with minimun configuration changes exploiting reusability in UVM based environment. + +\section{Objectives} + +Work to be presented in this dissertation thesis aims at following standard verification flow used in industry to develop verification environment for the cryptographic core. \par + +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. \par + +One important aspect of hardware verification is code coverage, which will also be covered. \par + +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. \par + +\section{Research Methodology} + +First step in the dissertation flow is to understand Design under Test (DUT) specification. Following feature extraction from the design, this is specification of our Keccak SHA-3 core. Interpretation of design features is used to generate test scenarios under which selected RTL will be operating. \par + +It is then followed by testbench architecture development phase. This phase contains developing UVM testbench hierarchical components. Development and execution of environment is done on verification tool QuestaSim 10.0b by Mentor Graphics tool. Code coverage and functional coverage functionalities are also provided by Mentor Graphics Questa Advanced Simulator. \par + +File format like .sv .svh .do .f and etc for required verification environment are created using emacs editor under Linux Ubuntu 15.04. And documentation for creating thesis report is done on Gummi Latex Editor tool.\par + +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. \par + +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 can be used to create RTL code, linting and synthesizing the RTL and producing technology view of the RTL. And proposed verification environment can be applied to verify functionality of RTL using exhausted number of testcases provided. + +\section{Expected Outcome} + +Expected outcome from this dissertation work include, 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. \ No newline at end of file diff --git a/chap2.tex b/chap2.tex new file mode 100644 index 0000000..8c34a7a --- /dev/null +++ b/chap2.tex @@ -0,0 +1,149 @@ +\chapter{Universal Verification Methodology} + +\section{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. \par + +A brief timeline of methodology development has been given in figure \ref{timeline} below, + +%Image +\begin{figure}[h] + \centering + \includegraphics[width=13cm,height=5cm]{images/timeline} + \caption{Timeline: Verification Methodologies \label{timeline}} +\end{figure} + +\section{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. \par + +UVM provides framework for Coverage Driven Verification (CDV). CDV has combination of automatic test generation (pseudo-random pattern generation), self-checking architecture and coverage metrics to reduce time for developing testbench significantly. \par + +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. \par + +UVCs are as described below, + +\subsection{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. \par + +\subsection{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 driver’s 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. + +\subsection{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. + +\subsection{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. + +\subsection{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. + +\subsection{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 \ref{uvmenv} that the environment class may contain monitor other than provided in agent. Reason is that bus monitor may be independent of specific agents. + +\begin{figure}[h] +\centering +\includegraphics[width=13cm,height=10cm]{images/uvm_env} +\caption{A Typical Verification Environment \label{uvmenv}} +\end{figure} + +\section{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. \par + +A Partial hierarchy of UVM components and TLM is provided in figure \ref{uvmclass} below, + +\begin{figure}[h] +\centering +\includegraphics[width=13cm,height=8cm]{images/uvm_class_lib} +\caption{A Partial UVM Class Hierarchy \label{uvmclass}} +\end{figure} + +\section{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, + +\begin{figure}[h] + \centering + \includegraphics[width=10cm,height=12cm]{images/phase} + \caption{Phases in UVM (source: soccentral.com)\label{phase}} +\end{figure} + + + \begin{itemize} + \item \textbf{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. + \item \textbf{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. + \item \textbf{function void end\_of\_elaboration()} + is used to configure the components when required. + \item \textbf{function void start\_of\_simulation()} + prints component hierarchy and other messages. It may be optional. + \item function void extract() + \item function void check() + \item function void report() + gives all test pass/fail status and simulation results. + \item \textbf{task run()} + is considered as main phase of simulation. Simulation will start from here. In this phase all tests executes and processes are forked. + \end{itemize} + +\section{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 \ref{pc} and \ref{getpc} below, + +\vspace{0.5cm} + +\begin{figure}[ht] + \centering + \includegraphics[width=8cm,height=1.5cm]{images/pc} + \caption{Producer-Consumer with put method \label{pc}} +\end{figure} + +\vspace{0.5cm} + +\begin{figure}[ht] + \centering + \includegraphics[width=8cm,height=1.5cm]{images/getpc} + \caption{Producer Gets from Consumer \label{getpc}} +\end{figure} + + + +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. \par +Thereby in cases where we want to connect multiple exports to a single component, ports are not designed to connect to multiple exports. Solution for this is to use analysis port(figure \ref{ap}), 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. + +\vspace{0.5cm} + +\begin{figure}[h] + \centering + \includegraphics[width=10cm,height=5cm]{images/ap} + \caption{Analysis Port \label{ap}} +\end{figure} + +\vspace{1cm} + +\noindent +\begin{table}[ht] + \centering + \begin{tabular}{| c | m{2.5cm} | m{4cm} |} + \hline + Symbol & Type & Port Declaration \\ \hline + $\square$ & Port & uvm\_put\_port \#(Transaction) port\_name \\ \hline + $\bigcirc$ & Export & uvm\_put\_imp \#(Transaction, Classname) export\_name \\ \hline + $\Diamond$ & Analysis Port & uvm\_analysis\_port \#(Transaction) analysis\_port\_name \\ \hline + \end{tabular} + \caption{TLM 1.0 Ports} + \label{tlm} +\end{table} + +\section{Conclusion} + +As system complexity increases in RTL, 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. \par + +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 understanding of them is necessary to implement verification plan. \ No newline at end of file diff --git a/chap3.tex b/chap3.tex new file mode 100644 index 0000000..999e4b7 --- /dev/null +++ b/chap3.tex @@ -0,0 +1,139 @@ +\chapter{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. \par + +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 SHA-3. Current research shows that SHA-2 will be secure for future applications but if it became vulnerable it would take years to find replacement. That’s why SHA-3 is considered complement of SHA-2 rather than replacement\cite{insha3}. 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. + +\section{Comparison Parameters of Cryptographic Hash Functions} + +Table below compares some properties of hash functions \cite{shs} like message size, word size, output digest size etc. + +\begin{table}[ht] + \centering + +\begin{tabular}{|m{2cm}||>{\centering}m{1.6cm}|>{\centering}m{1.3cm}|>{\centering}m{0.9cm}|>{\centering}m{1.2cm}|>{\centering}m{0.9cm}|m{1.2cm}|} +\hline + Algorithm & Output Size(bits) & Internal State Size & Block Size & Length Size & Word Size & Rounds \\ \hline + MD5 & 128 & 128 & 512 & 64 & 32 & 84 \\ \hline + SHA-1& 160 & 160 & 512 & 64 & 32 &80 \\ \hline + SHA-224, SHA-256 & 256/224 & 256 & 512 & 64 & 32 & 84 \\ \hline + SHA-384, SHA-512, SHA-512/224, SHA-512/256 & 384/512/ 224/256 & 512 & 1024 & 128 & 64 & 80 \\ \hline + SHA-3 & 224/256/ 384/512 & 1600 & 1600 - 2*bits & - & 64 & 24 \\ \hline + SHA3-224 & 224 & 1600 & 1152 & - & 64 & 24 \\ \hline + SHA3-256 & 256 & 1600 & 1088 & - & 64 & 24 \\ \hline + SHA3-384 & 384 & 1600 & 832 & - & 64 & 24 \\ \hline + SHA3-512 & 512 & 1600 & 576 & - & 64 & 24 \\ \hline +\end{tabular} +\caption{Parameters of Cryptographic Hash Functions} +\label{table:1} +\end{table} + +\section{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 \cite{fips202}. 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. \par + +The four SHA-3 hash functions are SHA3-224, SHA3-256, SHA3-384 and SHA3-512. Here suffix denotes length of output message digest. Two extendable output functions (XOFs) are SHAKE128 and SHAKE256. Where suffix number indicates security strength that these two functions support. + +\subsection{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. \par + +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, + +\begin{table}[ht] + \centering + +\begin{tabular}{|c||c|c|c|c|c|c|c|} +\hline + b & 25 & 50 & 100 & 200 & 400 & 800 & 1600 \\ \hline + w = b/25 & 1 & 2 & 4 & 8 & 16 & 32 &64 \\ \hline + l = log2(b/25) & 0 & 1 & 2 & 3 & 4 & 5 & 6 \\ \hline +\end{tabular} +\caption{Keccak-p Permutation width and related quantities} +\label{table:2} +\end{table} + +‘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 $\leq$ x $<$ 5, 0 $\leq$ y $<$ 5, 0 $\leq$ z $<$ w. Converting from state array to string and vice-versa, and labelling conventions are given in \cite{fips202}. \par + +The five step mappings that comprise a round of Keccak-p[b, nr] are denoted by $\theta$, $\rho$, $\pi$, $\chi$, and $\iota$. Each step mapping denoted by A takes an array and update it to A’. This is shown in figure \ref{state} below, + +%Image +\begin{figure}[ht] + \centering + \includegraphics[width=12cm,height=15cm]{images/state} + \caption{Parts of the state array organized by dimensions \label{state}} +\end{figure} + + +\subsection{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. + +Figure \ref{sponge} below shows the sponge construction of Keccak SHA-3. +%Image +\begin{figure}[ht] + \centering + \includegraphics[width=12cm,height=6cm]{images/sponge} + \caption{Sponge Construction \label{sponge}} +\end{figure} + + +\subsection{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-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) + +\subsection{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, + +\vspace{0.5cm} +\begin{BVerbatim} + 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) +\end{BVerbatim} + +And the two SHA-3 XOFs defined from Keccak are as following, + +\vspace{0.5cm} +\begin{BVerbatim} + SHAKE128(M, d) = Keccak[256] (M || 1111, d) + SHAKE256(M, d) = Keccak[512] (M || 1111, d) +\end{BVerbatim} + +Here, two `11' bit appended to message provides domain specification. That is 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\cite{sha3ref}. + + +\section{Application of Cryptographic Hash Functions} + +\subsection{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 + +\subsection{Password Verification} + +Storing passwords as plaintext can result in massive security breach if password file goes to eavesdropper’s hands. So, it’s 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. + +\subsection{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. + +\subsection{PRG and Key Derivation} + +Hash functions are also used to generate pseudorandom bits or to derive multiple keys from a single key. + +\section{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. diff --git a/chap4.tex b/chap4.tex new file mode 100644 index 0000000..87f35a6 --- /dev/null +++ b/chap4.tex @@ -0,0 +1,43 @@ +\chapter{Literature Survey} + +Literature referred for selecting out various key concepts are divided in four main groups stated below, + + +\section{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. \par + +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. \par + +To overcome this bottleneck, Accellera has standardized first verification methodology as Universal Verification Methodology (UVM). Evolution of industry standard methodologies as discussed in \cite{svuvm} 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 \cite{svuvm}. As SystemVerilog is very large and it’s 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 \cite{svuvm}. \par + +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. + +\section{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 \cite{tbarch}. 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. \par + +UVM testbench of unit component FIFO buffer module is created and reused in I2C EEPROM slave module in \cite{tbarch}. This helps in defining testbench architecture with reusable component using UVM library method, like VC factory methods and VC communication mechanism. \par + +Parameterized testbench architecture is studied from \cite{uvmparam}. 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 paper \cite{uvmparam} 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 in \cite{uvmparam} help resolve this issue. + +\section{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). \par + +Well known and officially used Hash Function is Secure Hash Algorithm-1 (SHA-1) 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 SHA-2 and provide greater security level. Need for different hardware implementations of SHA-3 are discussed in \cite{tosha3}. Detailed structure of SHA-3 Crypto Core and inside functionality are explained in \cite{insha3}. \par + +\section{SHA-3 FPGA Implementations} + +In \cite{fpgades}, 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 \cite{fpgades}, 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 it’s stated that for 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. \par + +In paper \cite{hight}, 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 \cite{hight} 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 xc5vlx155t-3FF1136, 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. \par + +Implementation in \cite{effv5} 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. \par + +Paper \cite{comimp} 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 + +\section{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 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 $\rho$, $\pi$ and $\chi$ into one compression box. \ No newline at end of file diff --git a/chap5.tex b/chap5.tex new file mode 100644 index 0000000..66d036b --- /dev/null +++ b/chap5.tex @@ -0,0 +1,165 @@ +\chapter{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. \par + +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. \par + +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. \par + + +Specification for Keccak SHA-3 core is given below, + +\begin{enumerate} +\item Core has two different versions, high throughput core with 64-bit input and low throughput core with 32-bit input. +\item Detailed working of SHA-3 algorithm is implemented as explained in section 3. +\item In high throughput core two rounds are done per clock cycle. It finishes permutation in 12 clock cycles. +\item Low throughput core perform one round per clock cycle. It finishes permutation in 24 clock cycles. +\item Input signals are sampled at rising edge of clock. +\item Output signals are registered and not connected directly to combination logic inside. +\item Reset core before calculating hash for new input value. + +\end{enumerate} + +Pin signals of design is given in table below, + + +\begingroup +\fontsize{10pt}{12pt}\selectfont +\begin{table}[ht] + \centering + +\begin{tabulary}{1.0\textwidth}{|C||C|C|L|} +\hline + Port Name & Width & Direction & Description \\ \hline + clk & 1 & in & Clock applied \\ \hline + reset & 1 & in & Synchronous reset aligned with posedge of clk \\ \hline + in & 64 & in & input \\ \hline + byte\_num & 3 & in & Byte length of input \\ \hline + in\_ready & 1 & in & Input valid or not \\ \hline + is\_last & 1 & in & Current input last or not \\ \hline + buffer\_full & 1 & out & Buffer full(ready) or not \\ \hline + out & 512 & out & output hash result \\ \hline + out\_ready & 1 & out & output ready or not \\ \hline +\end{tabulary} +\caption{Pin details of high throughput SHA-3 core} +\label{table:3} +\end{table} +\endgroup + + +%Bring Table to top of the page +\makeatletter% Set distance from top of page to first float +\setlength{\@fptop}{5pt} +\makeatother + +\begingroup +\fontsize{10pt}{12pt}\selectfont + +\begin{table}[ht] + \centering +\begin{tabulary}{1.0\textwidth}{|C||C|C|L|} +\hline + Port Name & Width & Direction & Description \\ \hline + clk & 1 & in & Clock applied \\ \hline + reset & 1 & in & Synchronous reset aligned with posedge of clk \\ \hline + in & 32 & in & input \\ \hline + byte\_num & 2 & in & Byte length of input \\ \hline + in\_ready & 1 & in & Input valid or not \\ \hline + is\_last & 1 & in & Current input last or not \\ \hline + buffer\_full & 1 & out & Buffer full(ready) or not \\ \hline + out & 512 & out & output hash result \\ \hline + out\_ready & 1 & out & output ready or not \\ \hline +\end{tabulary} +\caption{Pin details of low throughput SHA-3 core} +\label{table:4} +\end{table} +\endgroup + +\section{Test Scenarios and Test Cases} + +Test scenarios and testcases based on that are given in table \ref{table:5} below, +\begingroup +\fontsize{10pt}{12pt}\selectfont + +\begin{table}[ht] + \centering +\begin{tabulary}{1.0\textwidth}{|L|L|L|L|} +\hline + TR & Test Scenario & STR & Test Cases \\ \hline + TR1 & Test for Reset alignment & TR1.1 & Apply reset for single clock cycle \\ \hline + & & TR1.2 & Apply reset for more than one clock cycle \\ \hline + & & TR1.3 & Align positive edge of both clock and reset \\ \hline + & & TR1.4 & Apply slight change in alignments \\ \hline + TR2 & Vary input string size & TR2.1 & Try passing empty message \\ \hline + & & TR2.2 & Input message size less than 32-bits \\ \hline + & & TR2.3 & Input message size equal to 32-bits \\ \hline + & & TR2.4 & Input message size more than 32-bits but less than 64-bits \\ \hline + & & TR2.5 & Input message size equal to 64-bits \\ \hline + & & TR2.6 & Input message size greater than 64-bits \\ \hline + & & TR2.7 & Apply very large input message \\ \hline + TR3 & Check for is\_last & TR3.1 & Enable and disable is\_last and check for byte\_num \\ \hline + TR4 & Apply Input at slower rate & TR4.1 & Make in\_ready zero for varying time duration \\ \hline + & & TR4.2 & Toggle in\_ready \\ \hline + TR5 & Check for buffer\_full & TR5.1 & Check for buffer\_full is 1 and in\_ready is zero. \\ \hline + TR6 & Check for out\_ready & TR6.1 & After output is ready. Observe output for arbitrary amount of time when out\_ready is 1. \\ \hline +\end{tabulary} +\caption{Test Cases} +\label{table:5} +\end{table} +\endgroup + + +\section{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) + +\subsection{Code Coverage} + +Code coverage can be of number of different types. Some of these types are listed and explained in brief as given below, \par + +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. \par + +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. \par + +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 covered to the total number of expressions. \par + +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. \par + +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. \par + +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. \par + +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. \par + +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. + +\subsection{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. + +\section{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. + +\vspace{1cm} +%Image +\begin{figure}[ht] + \centering + \includegraphics[width=13cm,height=8cm]{images/env} + \caption{Developed Verification Environment \label{env}} +\end{figure} + + +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. + +\section{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. + diff --git a/chap6.tex b/chap6.tex new file mode 100644 index 0000000..57d3ec8 --- /dev/null +++ b/chap6.tex @@ -0,0 +1,176 @@ +\chapter{Simulation Results} + +Based on the test scenarios and testcases created in chapter 5, simulation results obtained from the testcases are, + +\section{Input golden message sequence} + +\begin{tcolorbox} + + \begin{verbbox} + +//sha3_base_test defined as virtual class +// It can't 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 + \end{verbbox} + \resizebox{0.95\textwidth}{!}{\theverbbox} + +\end{tcolorbox} + +Test sequence for tr1\_test is defined in tr1\_seq class pseudo code for which looks like given below, + + +\begin{tcolorbox} + + \begin{verbatim} + +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 + \end{verbatim} + +\end{tcolorbox} + +Simulation waveform for tr1\_test testcase is as shown below, + +%Image +\begin{figure}[ht] + \centering + \includegraphics[width=13cm,height=8cm]{images/tr1_test} + \caption{Test Scenario: Test Requirement 1 \label{tr1test}} +\end{figure} + +Figure \ref{tr1test} 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: + +\begin{tcolorbox} + + \begin{verbbox} + +d135bb84d0439dbac432247ee573a23ea7d3c9deb2a968eb31d47c4fb45f1ef4 +422d6c531b5b9bd6f449ebcc449ea94d0a8f05f62130fda612da53c79659f609 + \end{verbbox} + \resizebox{0.95\textwidth}{!}{\theverbbox} + +\end{tcolorbox} + +Which matches output shown in the waveform. Also for tr\_test, test hierarchy using print() method created is given below, + + +\begin{center} +\begin{tcolorbox} + + \begin{verbbox} + +# ---------------------------------------------------------------- +# 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 +# env_h sha3_env - @468 +# agent sha3_agent - @475 +# 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 +# monitor sha3_monitor - @524 +# monitor_ap uvm_analysis_port - @642 +# sequencer_h uvm_sequencer - @531 +# rsp_export uvm_analysis_export - @538 +# seq_item_export uvm_seq_item_pull_imp - @632 +# arbitration_queue array 0 - +# lock_queue array 0 - +# num_last_reqs integral 32 'd1 +# num_last_rsps integral 32 'd1 +# scoreboard sha3_scoreboard - @482 +# fifo uvm_tlm_analysis_fifo #(T) - @664 +# 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 +# ------------------------------------------------------------------ + \end{verbbox} + \resizebox{0.95\textwidth}{!}{\theverbbox} + +\end{tcolorbox} +\end{center} + + +\section{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.\par +Pseudo code for Test Requirement is given below, + +\begin{tcolorbox} + + \begin{verbatim} + 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 + \end{verbatim} + +\end{tcolorbox} + +%Image +\begin{figure}[ht] + \centering + \includegraphics[width=13cm,height=8cm]{images/tr2_test} + \caption{Test Scenario: Test Requirement 2 \label{tr2_test}} +\end{figure} + + +\section{Input very long message sequence} +%Image +In test requirement 3 we apply boundary case, which is to apply a long string so as to make buffer\_full signal high. TR3\_TEST uses reset\_seq as well as long\_msg\_seq test sequences created for previous testcases. +\begin{figure}[ht] + \centering + \includegraphics[width=13cm,height=8cm]{images/tr3_test} + \caption{Test Scenario: Test Requirement 3 \label{tr3_test}} +\end{figure} + +\section{Coverage Results} +%Image +\begin{figure}[ht] + \centering + \includegraphics[width=13cm,height=8cm]{images/tr3_cov} + \caption{Coverage Results \label{tr3cov}} +\end{figure} diff --git a/conclusion.tex b/conclusion.tex new file mode 100644 index 0000000..78f5a1d --- /dev/null +++ b/conclusion.tex @@ -0,0 +1,4 @@ +\chapter*{Conclusion} +\addcontentsline{toc}{chapter}{Conclusion} + +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. Copy of working environment is available online on Git www.github.com/mayur13/UVM-Verification-Environment. \ No newline at end of file diff --git a/contents.tex b/contents.tex new file mode 100644 index 0000000..cc83749 --- /dev/null +++ b/contents.tex @@ -0,0 +1,5 @@ +\tableofcontents +\newpage +\listoffigures +\newpage +\listoftables \ No newline at end of file diff --git a/declaration.tex b/declaration.tex new file mode 100644 index 0000000..c9a4f45 --- /dev/null +++ b/declaration.tex @@ -0,0 +1,30 @@ +\thispagestyle{plain} + +\thiswatermark{\centering \put(0,-575){\includegraphics[scale=0.4]{gtu-hd-rgb.png}} } + +\begin{center} + \midsize\textbf{\underline {DECLARATION OF ORIGINALITY}} + \addcontentsline{toc}{chapter}{Declaration of Originality} +\end{center} + + +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. \par + +We certify that, to the best of our knowledge, the current thesis does not infringe upon anyone's 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. \par + +We declare that this is a true copy of thesis, including any final revisions, as approved by thesis review committee. \par + +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. + + \vspace {0.5cm} + + \textbf{Date: June 2015} \\ + \textbf{Place: Ahmedabad} + + \vspace{0.5cm} + \begin{tabular}{l m{1cm} l} + \textbf{Signature of Student} & &\textbf{Signature of Guide} \\ + \textbf{Kubavat Mayur N.} & &\textbf{Mr. Ashish Prabhu}\\ + \textbf{Enrollment No. 131060752013} & & \textbf{Institute Code: 106} + \end{tabular} + \ No newline at end of file diff --git a/futurework.tex b/futurework.tex new file mode 100644 index 0000000..f74d282 --- /dev/null +++ b/futurework.tex @@ -0,0 +1,3 @@ +\chapter*{Future Work} +\addcontentsline{toc}{chapter}{Future Work} + Proposed verification environment can be applied to verify hash function RTL with minimal changes in Env configuration. Concepts studied for Keccak SHA-3 functionalities can be used to develop RTL core and optimized for Area Vs. throughput considerations. \ No newline at end of file diff --git a/main.tex b/main.tex new file mode 100644 index 0000000..0ed8d8f --- /dev/null +++ b/main.tex @@ -0,0 +1,124 @@ +\documentclass[a4paper,oneside,12pt]{book} +\renewcommand{\baselinestretch}{1.5} + +\usepackage[utf8]{inputenc} + +%Set Fonts +\usepackage{lmodern} % http://ctan.org/pkg/lm +%\usepackage{fontspec} +%\setmainfont{Times New Roman} +\font\TimesNew = ptmr at 12pt +\newcommand{\vbigsize}{\fontsize{18pt}{18pt}\selectfont} +\newcommand{\bigsize}{\fontsize{16pt}{16pt}\selectfont} +\newcommand{\midsize}{\fontsize{14pt}{14pt}\selectfont} + +\setlength{\parindent}{0em} +\setlength{\parskip}{1em} +\usepackage[english]{babel} + +\usepackage{setspace} +\usepackage{tabto} + +\usepackage[a4paper, left=3.8cm, right=2.54cm, top=2.54cm, +bottom=2.54cm, bindingoffset=0cm]{geometry} + +%Graphics Package to manage images. +\usepackage{graphicx} +\graphicspath{ {images/} } +\usepackage{watermark} + +\usepackage{verbatimbox} +\usepackage[most]{tcolorbox} + +\tcbset{ + frame code={} + center title, + left=0pt, + right=0pt, + top=0pt, + bottom=0pt, + colback=gray!10, + colframe=white, + width=\dimexpr\textwidth\relax, + enlarge left by=0mm, + boxsep=5pt, + arc=0pt,outer arc=0pt, + } + +%Sets fix table by m{cm} +\usepackage{array} +\usepackage{tabulary} +\newcommand{\nextitem}{\par\hspace*{\labelsep}\textbullet\hspace*{\labelsep}} +\usepackage{amsmath} +\usepackage{amssymb} +\usepackage{fancyvrb} +\usepackage[superscript]{cite} %[superscript,biblabel] + +%For code snippets +\usepackage{listings} +\usepackage{appendix} +\usepackage{pdfpages} +\usepackage{titlesec} +%% To suppress ``Chapter`` keyword +\titleformat{\chapter}[display]{\normalfont\bfseries}{}{0pt}{\midsize} +\titlespacing*{\chapter}{0cm}{-1cm}{1.5cm} +%% Customize heading for Chapters +\titleformat{\chapter}[display] +{\bfseries\Large} +{\filright\MakeUppercase{\chaptertitlename} \Huge\thechapter} +{1ex} +{\titlerule\vspace{1ex}\filleft} +[\vspace{1ex}\titlerule] + +\usepackage{ragged2e} + +%% Header and Footer +\usepackage{fancyhdr} +\pagestyle{fancy} +\fancyhf{} +\rhead{\leftmark} +%%\lhead{Guides and tutorials} +\rfoot{Page \thepage} +\lfoot{Mayur Kubavat (131060752013)} + + + + +\begin{document} + +\include{titlepage} + +\frontmatter +\include{certificate} +\include{cdac} +\include{certificate2} +\include{approvalcerti} +\include{declaration} +\include{acknowledge} +\include{contents} +\include{abstract} +\include{abstract2} + +\mainmatter + +\include{chap1} +\include{chap2} +\include{chap3} +\include{chap4} +\include{chap5} +\include{chap6} + +\include{conclusion} +\include{futurework} + +\bibliographystyle{plain} +\bibliography{references} + +\include{appendixa} +\include{appendixb} +\include{appendixd} +\include{appendixc} +\include{appendixe} +\include{plagiarism} + +\end{document} diff --git a/plagiarism.tex b/plagiarism.tex new file mode 100644 index 0000000..ed09b46 --- /dev/null +++ b/plagiarism.tex @@ -0,0 +1,2 @@ +\addcontentsline{toc}{chapter}{Plagiarism Report} +\includepdf[pages={72}]{plagiarismreport} \ No newline at end of file diff --git a/references.bib b/references.bib new file mode 100644 index 0000000..9d4aff3 --- /dev/null +++ b/references.bib @@ -0,0 +1,115 @@ +% $Description: Dissertaion Report$ +% $Author: Mayur Kubavat $ +% $Date: 2015/5/8$ + +@ARTICLE{svuvm, + AUTHOR = {Bromley, Jonathan}, + TITLE = {``If SystemVerilog is so good, why we need the UVM? Sharing responsibilities between libraries and the core language"}, + JOURNAL = {in Specification \& Design Languages (FDL)}, + YEAR = {2013}, + month = {April}, +} + +@ARTICLE{tbarch, + AUTHOR = {Francesconi J.; Agustin Rodriguez J.; Julian P.M.}, + TITLE = {``UVM Based Testbench Architecture for Unit Verification"}, + JOURNAL = {Argentine Conference on Micro-Nanoelectronics, Technology and Applications (EAMTA)}, + YEAR = {2014}, + month = {July}, +} + +@ARTICLE{uvmparam, + AUTHOR = {Geng Zhong; Jian Zhou ; Bei Xia}, + TITLE = {``Parameter and UVM, Making a Layered Testbench Powerful"}, + JOURNAL = {IEEE 10th International Conference on ASIC (ASICON)}, + YEAR = {2013}, + month = {December}, +} + +@ARTICLE{tosha3, + AUTHOR = {Sklavos, N.}, + TITLE = {``Towards to SHA-3 Hashing Standard for Secure Communications: On the Hardware Evaluation Development"}, + JOURNAL = {in Latin America Transactions, IEEE}, + YEAR = {2012}, + month = {May}, +} + +@ARTICLE{insha3, + AUTHOR = {Stallings, W.}, + TITLE = {``Inside SHA-3"}, + JOURNAL = {in Potentials, IEEE}, + YEAR = {2013}, + month = {June}, +} + +@ARTICLE{fpgades, + AUTHOR = {Provelengios G.; Kitsos P.; Sklavos N.; Koulamas C.}, + TITLE = {``FPGA-Based Design Approaches of Keccak Hash Function"}, + JOURNAL = {15th Euromicro Conference on Digital System Design (DSD)}, + YEAR = {2012}, + month = {August}, +} + +@ARTICLE{hight, + AUTHOR = {Athanasiou G.S.; Makkas G.-P.; Theodoridis G.}, + TITLE = {``High Throughput Pipelined FPGA implementation of the new SHA-3 Cryptographic Hash Algorithm"}, + JOURNAL = {in 6th IEEE International Symposium on Communications, Control and Signal Processing (ISCCSP)}, + YEAR = {2014}, + month = {October}, +} + +@ARTICLE{ieee1588, + AUTHOR = {Moreira N.; Astarloa A.; Kretzschmar U.; Lazaro, J.; Molina E.}, + TITLE = {``Securing IEEE 1588 Messages with Message Authentication Codes based on the KECCAK Cryptographic Algorithm Implemented in FPGAs"}, + JOURNAL = {IEEE 23rd International Symposium on Industrial Electronics (ISIE)}, + YEAR = {2014}, + month = {July}, +} + +@ARTICLE{effv5, + AUTHOR = {Rao M.; Newe T.; Grout I.}, + TITLE = {``Efficient High Speed Implementation of Secure Hash Algorithm-3 on Virtex-5 FPGA"}, + JOURNAL = {IEEE 23rd International Symposium on Industrial Electronics (ISIE)}, + YEAR = {2014}, + month = {August}, +} + +@ARTICLE{comimp, + AUTHOR = {Arshad A.; Kundi D.-e.-S. ; Aziz A.}, + TITLE = {``Compact Implementation of SHA3-512 on FPGA"}, + JOURNAL = {Conference on Information Assurance and Cyber Security (CIACS)}, + YEAR = {2014}, + month = {January}, +} + +@ARTICLE{shs, + AUTHOR = {NIST Computer Security Division (CSD)}, + TITLE = {``Secure Hash Standard (SHS)"}, + JOURNAL = {In FIPS PUB 180-4, NIST. Available online at }, + YEAR = {2014}, + month = {October}, +} + +@ARTICLE{fips202, + AUTHOR = {NIST Computer Security Division (CSD)}, + TITLE = {``SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions"}, + JOURNAL = {Available online at }, + YEAR = {2014}, + month = {October}, +} + +@ARTICLE{sha3ref, + AUTHOR = {Guido Bertoni, Joan Daemen, Michaël Peeters and Gilles Van Assche}, + TITLE = {``The Keccak reference"}, + JOURNAL = {Available online at }, + YEAR = {2014}, + month = {October}, +} + +@ARTICLE{opencores, + AUTHOR = {Homer Hsing}, + TITLE = {``SHA-3 Core Specification"}, + JOURNAL = {Available online at }, + YEAR = {2013}, + month = {January}, +} diff --git a/titlepage.tex b/titlepage.tex new file mode 100644 index 0000000..f77911c --- /dev/null +++ b/titlepage.tex @@ -0,0 +1,37 @@ +\begin{titlepage} + \begin{center} + \vspace*{1cm} + + \vbigsize{\textbf{Development of Verification Environment for SHA-3 Core using UVM}} + \addcontentsline{toc}{chapter}{Title} + + \vspace{0.5cm} + + \vspace{1.5cm} + + \normalsize + By\\ + \textbf{Mayur Navinchandra Kubavat (131060752013)} \\ + Guided By\\ + \textbf{Mr.Ashish Prabhu}\\ + \textbf{Sr. Verification Engineer, LSI India R\&D} + + \vspace{2cm} + + A Thesis Submitted to\\ + Gujarat Technological University \\ + in Partial Fulfillment of the Requirements for\\ + the Degree of Master of Engineering in \\ + VLSI \& Embedded Systems Design + + June 2015 + \vspace{1.5cm} + + \includegraphics[width=1.65cm,height=1.78cm]{images/gtu} + + Gujarat Technological University PG School, Ahmedabad\\ + Gujarat Technological University + + + \end{center} +\end{titlepage} \ No newline at end of file