
Cryptography is no longer just a mechanism used by the military or government officials to secure sensitive information. Over the years, it has evolved into a mandatory mechanism to protect individuals and their information regardless of their objective importance. From securing high quantities of data to validating a person’s identity or whether a file’s integrity has not been compromised, cryptographic algorithms come in multiple forms due to their high computational complexity and purpose:
- Symmetric
- Asymmetric
- Hashing
Due to their widespread use in modern systems, efficiency is crucial. As a result, engineers increasingly adopt hardware implementations for both pre-quantum and post-quantum algorithms [1]. Because they process large data volumes efficiently, symmetric encryption algorithms have gained popularity in hardware implementations [2].
This paper presents a UVM-based UVC providing the functionalities of the Advanced Encryption Standard (i.e., AES), currently considered the most secure and widely used symmetric encryption algorithm [3]. It also includes multiple National Institute of Standards and Technology (i.e., NIST) approved block modes of operation.
The official documentation for the AES may be found in FIPS 197 [4].
The official documentation for the block modes of operation implemented may be found in SP 800-38A [5].
Table of Contents
- Introduction
- Package Structure
- Proposed use cases
- Conclusion
- Acknowledgements
- Download
- Bibliography
Introduction
A block mode AES transaction requires the following elements:
- Input block as multiple of 128 bits.
- Secret key of 128, 192 or 256 bits.
- Initialization Vector (IV) of 128 bits.
The block mode operations are described as wrappers around the standard AES Encryption and Decryption functions, as shown in the figure below.
Package Structure
The AES UVC resides within a UVM-based package containing transaction level components and objects illustrated in the following figure:

The amiq_aes_uvc_pkg package includes the following elements:
- Utils Library
- Miscellaneous Library
- Input Item
- Output Item
- Configuration Object
- Core
- Coverage Collector
- Communication Component
: amiq_aes_uvc_utils_lib;
: amiq_aes_uvc_misc_lib;
: amiq_aes_uvc_input_item;
: amiq_aes_uvc_output_item;
: amiq_aes_uvc_config_obj;
: amiq_aes_uvc_core;
: amiq_aes_uvc_coverage_collector;
: amiq_aes_uvc;
Core
The Core component performs AES transactions using three levels of public methods that accept progressively more parameters:
- Level 1: Individual encrypt() / decrypt() functions defined for each block mode.
- Level 2: xcrypt() functions that wrap Level 1 functions to combine encryption and decryption into a single operation.
- Level 3: aes_main() function with multiple input parameters wrapping over Level 2 functions.

In order to reduce the number of parameters required for a transaction in the UVC and encourage the use of AES for its intended purpose (encrypting high volumes of data), the user can set the secret key and initialization vector separately using the set_key and set_iv methods.
Those setters check the size of the key and IV , assess their validity and issue a `uvm_info if the user set an incorrectly sized parameter.
function void set_key(byte unsigned new_key[], amiq_aes_key_size_e size);
valid_key = 0;
new_setup = AES_TRUE;
if ((size == AES_128) || (size == AES_192) || (size == AES_256)) begin
if (new_key.size() >= (`AES_UVC_MIN_KEY_BYTE_LENGTH + (8 * (size - 1)))) begin
valid_key = 1;
end
end
if (valid_key == 1) begin
nk = 2 * (size + 1);
nr = nk + unsigned'(6);
key_exp_size = `AES_UVC_MIN_KEY_BYTE_LENGTH * (nr + 1);
for (int i = 0; i < ((size + 1) * `AES_UVC_BYTE); i++) begin
key[i] = new_key[i];
end
key_expansion();
end
else begin
`uvm_info(this.get_full_name(), $sformatf(
"Incorrect key length, needed:128/192/256bits(16/24/32bytes), actual:%dbits(%d bytes)", new_key.size * 8,
new_key.size), UVM_NONE)
end
endfunction
If the user attempts to run an AES operation with an invalid key and/or IV, the guards inside the Level 1 and Level 2 functions invoke call_failure(). This function alerts the user through a `uvm_info, `uvm_warning or `uvm_error depending on the verbosity_level and the toggle_setup_info_warning_error flags inside the amiq_aes_config_obj.
function void call_failure(
string ctx,
string message,
uvm_verbosity verbosity = m_aes_config_obj.verbosity_level
);
case (m_aes_config_obj.toggle_setup_info_warning_error)
`AES_INFO : `uvm_info(ctx, message, verbosity)
`AES_WARNING : `uvm_warning(ctx, message)
`AES_ERROR : `uvm_error(ctx, message)
default : `uvm_error(this.get_full_name(), "received an illegal parameter")
endcase;
endfunction
Currently the Core supports transactions for the ECB, CTR, CBC, OFB and CFB (with offsets of 1, 8 and 128 bits), all AES key sizes, and padding for incomplete data blocks [4].
Communication Component
The communication component, symbolically named UVC, integrates all required components within a single package, eliminating the need for additional instantiations. It wraps the Core and provides the user with an implementation port specialized for an amiq_aes_uvc_input_item. Its associated _write() function extracts the required parameters from the item and executes a Core transaction. The resulting data is then wrapped in an amiq_aes_uvc_output_item and sent through the analysis port inside the component.

This component also contains the Coverage Collector, which connects to the Core through TLM ports. While using it is optional, it offers alternative access to the same functionalities. Users can independently instantiate and connect the Core and Coverage Collector without relying on the communication component or items.
Input & Output Items
The transactions defined inside the amiq_aes_uvc are driven using the input and output items. The amiq_aes_uvc_input_item contains the data, key, IV and a transaction setup with the necessary fields to configure a transaction (new_setup, key_size, block_mode, operation) as shown in the figure below:

As mentioned earlier, the output is encapsulated in an amiq_aes_uvc_output_item which can be observed in the figure below:

The items can also serve primary input and output agent items in AES-based verification environments.
Coverage Collector
In order to validate the versatility and capability of the UVC to manage all possible transactions, the Coverage Collector implements three categories of coverage described in the verification plan:
- Data based: Ensures each byte in the data, key and IV achieves every power 2 up to 255, verifying full 8-bit toggling.
- Configuration based: Covers all possible configurations of new setup / block mode / key size / operation, including transitions between 3 successive transactions.
-
Statistics based: Collects general metrics such as:
- Counting how many transactions use the same key and IV, and information about their occurrence.
- Counting how many transactions still have the same configuration even if the new_setup parameter has been set to true.
- Counting how many concurrent transactions use the same key after they reach a certain threshold defined in the Configuration Object.
Utils & Misc
The amiq_aes_uvc_utils_lib defines custom enum types, the transaction_setup class used in the Input Item, and the data structures for coverage statistics. The amiq_aes_uvc_misc_lib provides debugging functions to print hex arrays and UVC items.
Configuration Object
The configuration object manages parameters related to the Coverage Collector, including: enabling the coverage, enabling the storage of statistics coverage, the maximum number of transactions using the same key and setting up the uvm info / warning / error and the verbosity regarding invalid key / IV messages.
Proposed use cases
Since the UVC is defined as a transaction-level component, it can be integrated and used in any scenario where its encryption/decryption functionality is relevant, as shown in the figure below.
This article proposes two basic use cases of the AES-UVC.
Reference model for checks
Users can instantiate the UVC inside the environment and connect it to the scoreboard using TLM ports. In this scenario, the UVC acts as a reference model for verifying whether an AES RTL produces the correct output.

Stimulus generation
Similarly, the users can instantiate the UVC inside the environment and access it through its public methods from the input sequence. In this scenario, the generated input is encrypted before being sent to the driver. The RTL is used in CTR mode which means the scoreboard will compare the original data instead of the encrypted data.

Conclusion
The UVC has been functionally validated through the Annexes presented in FIPS 197 and SP 800-38A to guarantee that the output is correct.
Through the 100% test passing rate and 100% coverage rate obtained from the implementation of the verification plan, the UVC handles all possible configurations reliably.
This paper presents the implementation of an AES-based UVC in a modular and extensible manner supporting multiple block modes of operation. As it is a transaction level package of components, it may be used with minimal effort inside verification environments, both through public methods and analysis ports.
Acknowledgements
I would like to express my gratitude to Amiq Consulting, especially Tiberiu, Eda and Marius, for guiding me throughout the elaboration of my bachelor’s thesis as well as this article which is based on it.
Download
This project’s source code may be accessed at AMIQ’s Github Repository.
Bibliography
[1] Favin Fernandes, Gauravi Dungarwal, Aishwariya Gaikwad, Ishan Kareliya, & Swati Shilaskar. (2021). VLSI Implementation of Cryptographic Algorithms & Techniques: A Literature Review.
[2] Coppolino, L., D’Antonio, S., & Mazzeo, G. (2019). A Comprehensive Survey of Hardware-assisted Security: from the Edge to the Cloud. Internet of Things, 6, 100055.
[3] Maharaj, A. (2020). A Review on Advanced Encryption Standards (AES). University of Naples ’Parthenope’ Centro Direzionale, Isola C4, 80133 Napoli
[4] Announcing the Advanced Encryption Standard (AES), Federal Information Processing Standards Publication (FIPS) 197, National Institute of Standards and Technology (NIST), Nov. 2001.
[5] Morris Dworkin, Recommendation for Block Cipher Modes of Operation: Methodsand Techniques, NIST Special Publication 800-38A, National Institute of Standards and Technology (NIST), Dec. 2001.