Verification of Digital Systems

Class Project Presentation – Spring 2017

UVM and Formal Verification of AES module

Aggarwal, Rohit
Sayal, Aseem
Srivastava, Prateek

Instructor: Prof. Jacob Abraham

04-20-2017
Agenda
• Motivation
• Highlights
• AES Algorithm
• DUT Specifications
• Verification Methodology
• UVM Methodology/Setup
• UVM Results
• Formal Verification Methodology/Setup
• Formal Verification Results
• Conclusion
• Next Steps
• Key Learnings
 Motivation – Why AES?
• Advanced Encryption Standard (AES) is the most widely adopted
encryption standard

• Specification for encryption of electronic data established by US NIST

(National Institute of Standards and Technology)

• Till date, no practical cryptanalytic attacks against AES has been

discovered

• Thus, design verification of hardware implementation of AES module

becomes of the utmost importance
Highlights
• This works deals with implementation of UVM and Formal
verification techniques for AES module to achieve signoff quality

• Tested the design hierarchically i.e. tested the submodules

encipher, decipher and then the top module aes_core

• UVM è Analyzed and improved code and functional coverage

• FV è Developed assertions and explored formal techniques to test

the state machine
 AES Algorithm

• The key is divided into 16

bytes & arranged in 4*4 block

• The four words, of these 4

columns get expanded in 44
words

• These keys are then applied

across 10 rounds of encryption
AES Encryption Algorithm
Bytes • Multiplicative inverse in GF(28) - x8+x4+x3+x+1
• Bit Scrambling - b′i = bi⊗b(i+4) mod 8⊗b(i+5)

Substitution mod 8⊗b(i+6) mod 8⊗b(i+7) mod 8⊗ci (1)

Rows
Shifting
Column
Mixing
Round key • XOR operation of bytes with the round key
• The final output obtained is fed to next round

Addition • After 10 rounds, the output is the 128 bit

cipher text
AES Key Expansion
 DUT Specifications (1/2)
• The DUT supports
encryption with both
AES 256 & 128 bit key

AES • AES SBOX: Lookup

Core table used by
encryption block
AES AES AES Key AES AES INV
Encipher Decipher Mem SBOX SBOX
• AES INV SBOX:
Inverted lookup
table used by
decryption block

DUT Verilog Implementation by secworks: https://github.com/secworks/aes/tree/master/src/rtl

 DUT Specifications (2/2)

AES Core AES Encipher

DUT Verilog Implementation by secworks: https://github.com/secworks/aes/tree/master/src/rtl

Verification Methodology

• UVM along with the SV brings a

UVM lot of automation, maintainability,
and reuse to the verification
process

Formal • Act of proving or disproving the

correctness of system
Verification • Ensures signoff quality design
UVM Test Bench
UVM Sequencer
No. of test cases : 10,000
Input Distribution :
S No. Input Value Distribution
128 bit 50
1 Keylength
256 bit 50
Encode 50
2 Encode/Decode
Decode 50
Zero 10
3 Key and Input block
Non-Zero 90
UVM Driver
• DUT needs time to expand keys and generate results both of these
are signified by DUT signals

• Driver reads these signals and properly drive the inputs

• Reset DUT (wait for 4 cycles)
• Apply key (wait for key ready signal)
• Apply input (wait for output ready signal)
• DUT takes multiple cycles to complete a run and is non-pipelined, Driver waits
for inputs to be consumed before reading new transaction

• Solution:
• Use FIFO (Not implemented)
• Use objections. Driver raises objection in run phase and lowers the objection
only after DUT gives final results (Implemented)
UVM Monitor
• Issues similar to Driver

• Monitor inputs and outputs correctly sample DUT inputs and

outputs when they are applied by Driver

• Implemented by correctly delaying the read of transactions with

appropriate number of cycles

• Synchronization is implemented using objections

UVM Scoreboard
• It reads input transaction, calculates the expected output and
compares with output transaction to determine the correctness

• We used an open source C++ implementation for the scoreboard

• Since System Verilog supports most of C++ constructs, it was easy

to integrate it with our implementation

• Changes were required to:

– Data Structures used
– Code manipulating the Input and Output variables
– Some syntactical changes
Verification Metrics - Coverage
• UVM system verilog coverage
– Only inputs for the DUT are interesting with respect to
coverage. We made sure to cover following
• Encipher and Decipher
• Key length of 128 and 256
• Input block being zero and nonzero
• Key being zero and nonzero

Interesting case : Decipher with key = 0 and input = 0

• Verilog DUT code

– Statement and Branch coverage and analysis
UVM Results (1/2)
UVM Results (2/2)
Formal Verification

SV Assertions
(AES Core and AES Encipher)
 AES Core FSM
• Begins in CTRL_IDLE state
• If INIT signal is high, it goes to state
CTRL_INIT & performs key expansion
• When key expansion is done, KEY_
READY signal is set high, which makes
it return back to CTRL_IDLE
• After this, next signal is set high, which
takes the design in CTRL_NEXT state
• In this state, one round of encipher
/decipher is performed
• After completing one round the design
goes back to CTRL_IDLE state (when
MUXED_READY is high)
• This process continues for 10 rounds
to get the final encrypted/decrypted
text (14 rounds for 256 bit key)
 AES Encipher
• Begins in CTRL_IDLE state
• To begin the next round, next signal is set high,
and the control passes to CTRL_INIT state
• Calculates the initial block by XORing the input
with the initial round key.
• Goes to CTRL_SBOX state; finds the S-box for the
input block, by looking up in the ROM word by
word. Stays in this state for 4 cycles
• SWORD_CTR_REGè3, goes to CTRL_MAIN state
• In CTRL_MAIN state, increments the ROUND_
CTR_REG and updates the block
• If the ROUND_CTR_REG is still less than
NUM_ROUNDS, it goes back to CTRL_SBOX state
to begin the next round otherwise it sets the ready
signal high and goes to CTRL_IDLE state.
 FV Issues & Resolution
Issue 1: Verilog Syntax

Resolution: Reading netlist

with v2k switch, instead of verilog

Issue 2: Assertion failing with warning

while reading SV

Resolution: Renaming port name

FV Results (1/3)
FV Results (2/3)
FV Results (3/3)
Conclusion
• AES module is verified using UVM and formal techniques

• Improved code and functional coverage in UVM technique

• Resolved flow issues, and developed assertions to formally

verify the state machine of aes_core and aes_encipher blocks
Next Steps
• UVM è Test the block by applying NIST provided plaintext
and key inputs

• FV è Try to come up with more assertions to test the state

machine formally for AES decipher module and key expansion
module
Key Learnings
• Lot of time is spent to understand the AES module and its
components before coming up with a good verification
strategy and metrics

• UVM test bench setup è High initial setup time and complex
framework, but provides modularity and reusability for future
runs

• Explored both simulation and formal based techniques

THANK YOU!

Q&A