2021 International Conference on Microelectronics (ICM)

Implementation and Functional Verification of

RISC-V Core for Secure IoT Applications
Abdelrahman Adel1, Dina Saad1, Mahmoud Abd El Mawgoed1, Mohamed Sharshar1, Zyad Ahmed1, Hala Ibrahim2, Hassan Mostafa1,3
1
Electronics and Electrical Communications Engineering Department, Cairo University, Egypt
2
Siemens EDA, Cairo, Egypt
3
University of Science and Technology, Nanotechnology and Nanoelectronics Program, Zewail City of Science and Technology, October Gardens, 6th of October,
Giza 12578, Egypt.
2021 International Conference on Microelectronics (ICM) | 978-1-6654-0839-4/21/$31.00 ©2021 IEEE | DOI: 10.1109/ICM52667.2021.9664926

Email: hmostafa@uwaterloo.ca

Abstract— In the world of technology we live in, there is a huge

increase in the number of internet of things (IoT) devices leading
to a tremendous amount of data being sent. This wireless data is
prone to eavesdropping and being hacked. The contribution of this
work is the design of a System on Chip (SoC) with a processor
based on the instruction set architecture (ISA) of reduced
instruction-set computer (RISC-V). The system focuses on the
security of data between IoT end-nodes. For SoC verification, a
Universal Verification Methodology (UVM) environment is used
for covering most of the functionality and security aspects to
guarantee a sufficient level of trust in the implemented SoC.
Keywords—RISC-V, pipeline, UVM, verification, SoC, IoT.
I. INTRODUCTION
Nowadays, most of the data is being sent wirelessly. Some of this
data is confidential. So, data needs to be secured through
communication. This work proposes a solution, which integrates a
hardware security intellectual property (IP), a UART IP for
communication with the external world, and a core based on the RISC-
V ISA. The full system implements a system-on-chip to act as an end
node for IoT systems as shown in fig.1. The main advantages of RISC-
V ISA is being an open-source ISA, simple, stable, extensible, and
modular [1][5]. Regarding the verification phase, a UVM environment
was built to verify the functionality of the core. UVM is a set of class
libraries developed using SystemVerilog's syntax and semantics.
UVM's major goal is creating modular, reusable, and scalable testbench
frameworks that are used to validate numerous designs usually named
Design Under Test (DUT) [2].
II. BACKGROUND AND RELATED WORKS
When it comes to RISC-V SoC-based designs, there are many
contributions directed towards this field. This is because the RISC-V
ISA is open source and easy to deal with. Most of these contributions
are either directed towards the design and optimization as illustrated in
[3] and [4] or directed towards Verification solutions as illustrated in
[6]. However, the verification solutions being illustrated in the
previously mentioned works are dynamic functional verification. In our
work, we also illustrate the importance of static verification techniques
such as source code linting, clock domain crossing (CDC), and reset
domain crossing (RDC) verification in modern SoC designs. This work
also tries to achieve a balance between the focus on the design phase
and multiple phases of verification. So, it is more of an A-to-Z
workflow. Moreover, there are very few RISC-V based SoCs that are
targeting hardware security. Most proposed security solutions are
targeting software security with the aid of the RISC-V based SoCs such
as [3], which is still prone to bugs, as well as not being targeted for Low
power applications. In our work, hardware security for IoT applications
is the target. Thus, the ACORN algorithm (hardware implementation of
a lightweight cryptography algorithm) is used to save power. ACORN
algorithm is one of the two finalists in the lightweight category in the
Competition for Authenticated Encryption: Security, Applicability and
Robustness (CAESAR).
Fig.1: System on Chip block diagram
III. RISC-V CORE DESIGN
A. Unpipelined RV32I.
RISC-V’s base ISA has six base instruction formats: R-type for
register-register instructions, I-type of immediate values and load
instructions, S-type for store instructions, B-type for conditional branch
instructions, U-type for long immediate instructions, and J-type for
unconditional branch instructions.
There are some basic blocks that any processor should contain:
• Program counter (PC): holds the address of the next instruction to
be executed.
• Instruction memory: holds the instructions (to be executed)
accessed by the address stored in the program counter.
• Control unit: acts as the mind of the processor that generates control
signals to control the data path of each instruction.
• ALU: performs arithmetic and logical operations with the aid of the
control signals generated from the control unit.
• Data memory: stores the temporary data used by the processor
during its operation.
• Register file: contains all the general-purpose registers of the
microprocessor that holds data and addresses. It consists of thirty-
two registers each of 32-bits width.
B. M-extension (Multiply and divide extension)
One of the most important advantages that RISC-V offers is
supporting multiple extensions, depending on the required application.
For our application, the multiplication/division extension (M-
extension) is essential to have as any simple code may require at least
one multiplication/division instruction.
An implementation of multiplication and division operations is to
be implemented behaviorally using FPGA’s Digital signal processor
(DSP), which will end up having a combinational logic. Having 32-bit
operands for the multiplication and division instructions, the generated
block will consume a large area, power, and delay.

978-1-6654-0839-4/21/$31.00 ©2021
Authorized licensed use limited to: ANNA IEEE
UNIVERSITY. Downloaded254
on August 24,2022 at 08:29:04 UTC from IEEE Xplore. Restrictions apply.
 2021 International Conference on Microelectronics (ICM)
Fig.2: five-stage pipeline
The second implementation is sequential multipliers/dividers
algorithms. For division, the “restoring division” algorithm is chosen
while for multiplication “radix-2 booth multiplier” for signed
multiplications is used.
After implementing both combinational and sequential
implementations, it was observed that sequential implementation is
advantageous over combinational one concerning area, power, and
speed as illustrated in Table III. However, nothing comes with no
tradeoffs, the core now has instructions that consume more than one
clock cycle which is called “multi-cycle instructions”. So, to maintain
the order of the instructions, the processor’s pipeline must be frozen
for thirty-two clock cycles until Multiplication/Division unit is done
with results calculations. This is done using a Multiplication and
Division stalling unit (MDSU).
C. Pipelined RV32IM
Pipelining is a process of arrangement of hardware elements of the
CPU such that its overall performance is increased. It basically breaks
up our single instruction path into a distinct number of stages, allowing
simultaneous execution of more than one instruction in the pipelined
processor. In this work, the processor is designed to have a five-stage
pipeline with fetch, decode, execute, memory, and write-back stages in
this sequence as shown in fig.2. In the pipeline, some situations that
prevent the next instruction -in the instruction stream- from executing
during its designated clock cycles. This is known as a hazard [7].
Hazards can be classified into three categories, which are:
1) Structural hazards: occurs due to resource contention, this was
avoided using separate instruction and data memories (Harvard
architecture).
2) Data hazards: occurs due to data dependency between
instructions, where a value that has not been updated yet is required
in another stage. Data hazards are solved either by forwarding data
and/or by stalling the core. Both solutions are done using different
units embedded in the core. These units are:
• Forwarding unit at execute stage (third stage)
If one of the source registers (Rs) addresses of the third stage is
equal to the destination register (Rd) address of the fourth or the fifth
stage, this means that the instruction in stage three needs a value
from stage four or stage five. So, this value should be forwarded.
• Forwarding unit at memory stage (fourth stage):
If one of the Rs addresses of store instructions at the fifth stage is
equal to the Rd address of load instructions at the fourth stage, this
means that a value from stage five should be forwarded to stage
four.
• Hazard detection unit at decode stage (second stage):
It is responsible for catching data dependency between instructions
where the data needed is not yet calculated to be forwarded. So, this
unit generates a stall signal to freeze the first two stages for one
clock cycle until a value is calculated, then forwards the data using
the forwarding unit.
3) Control hazards: occurs due to branch instructions. In our
implementation, the branch decision is taken at the memory stage
(fourth stage). This delay in determining the correct instruction to
be fetched allows three new instructions to enter the pipeline.
Authorized licensed use limited to: ANNA UNIVERSITY. Downloaded255
on August 24,2022 at 08:29:04 UTC from IEEE Xplore. Restrictions apply.
A common solution for this is to always predict branches as not taken.
In case it is taken, a flush signal will be asserted to reset the first three
stages of the pipeline architecture.
IV. SYSTEM ON CHIP
Most real-life applications are implemented using System on
chips, not using stand-alone cores. Our SoC is designed to act as an end
node in an IoT system that needs to transfer its data securely over a
wired or a wireless communication channel while maintaining the
security of data throughout the communication process. For a simple
end-node, our RISC-V core acts as a controller for reading and writing
data from other IPs on the SoC. These IPs are HW security IP
(Hardware implementation of ACORN algorithms) and a UART IP.
A. SoC integration (MIMO)
The integration between the Core and the IPs has been implemented
by redirecting the core’s load and store instructions to access internal
registers of the IPs using an address decoder. This solution is known as
memory-mapped input-output (MMIO).
B. SoC integration issues and proper solutions
One of the most critical problems that need to be caught and fixed
when designing modern SoCs is the clock domain crossing issue. In our
SoC, we have three clock domains, one for the core, one for the Acorn
security IP, and another for the UART IP. In multiple clock domains, if
data is being sent from one domain to another, and the transmitting and
receiving clocks are not an integer multiple of each other, data from the
first domain will inevitably arrive at the setup or hold time of the second
domain leading to metastability.
The most suitable solution to avoid metastability is using an
Asynchronous FIFO. Asynchronous FIFO is a memory block with read
and write pointers for reading and writing data, the transmitting and
receiving domains have different clocks. Two-flop synchronizers are
used to synchronize the read pointer to the writing domain and
synchronize the write pointer to the reading domain. These pointers
should be gray encoded (so that only one-bit changes from a count to
the next one) as the Two-flop synchronizers do not synchronize multi-
bit buses due to its one-clock cycle uncertainty.
Another problem is the reset domain crossing (RDC). The term
RDC refers to a design method in which the source and destination parts
(flops, latches, and clock gates) operate on different independent resets.
Metastability occurs when an asynchronous reset from one reset
domain causes a transition too close to the clock edge of a flip-flop in
another reset domain or without a reset, causing a non-deterministic
flip-flop value that propagates throughout the design resulting in
functional failures. Having used asynchronous FIFO to eliminate
metastability due to CDC, this problem has also been avoided, as when
exchanging the pointers between the reading and writing domains, these
pointers are the only signals that are crossing reset domains, the pointers
are gray encoded, and a synchronizer is added. Thus, eliminating the
metastability.
V. FUNCTIONAL VERIFICATION
Functional verification ensures that the implementation conforms
to the specification from a functional perspective. Because of the rapid
growth of both design size and complexity, functional verification has
become one of the key bottlenecks in the design process. In this work,
the functional verification is done using static verification which will
be discussed in (SoC section) and dynamic verifications using the
Universal Verification Methodology (UVM) [2].
As designs grow with respect to size and complexity, it takes time
to verify them completely with the conventional test benches which are
not reusable.
 2021 International Conference on Microelectronics (ICM)

TABLE I. TRACEABILITY MATRIX

Test Features UT_1 UT_2 UT_3 UT_4 UT_5 UT_6 UT_7 UT_8 UT_9 UT_10 UT_11
Instruction R-TYPE
Types U-TYPE
variations S-TYPE
J-TYPE
B-TYPE
I-TYPE
Hazards Structural hazards
variations Data hazards Forwarding
Stall generation
Control hazards Flush generation
PC update
M-extension Multiplication Signed
unsigned
Division Signed
unsigned
Operand sign Positive
variation Negative
Zero
Corner cases Wrong opcode

The problem with these designs is testing all possible combinations of
their signals, which takes too long to simulate. UVM addresses this
issue by constraining the stimulus to certain values and randomizing
them. Accordingly, some advantages of the UVM are:
• Reduction of coding effort and enabling a high level of code reuse
• Support of constrained random verification methodology
• Extensive stimulus generation
• Decrease of verification cycle
A. UVM components and objects
• Driver: drives transactions from the sequencer to the DUT.
• Monitor: captures signals from the DUT and converts them from
pin level to transaction level. Input monitor ensures that the
transaction has been sent correctly to the DUT.
• Sequencer: controls the flow of transactions.
• Sequence: generates a transaction and randomizes it.
• C++ reference model: mimics the functionality of the DUT.
• Scoreboard: checks that everything has worked by comparing the
output signals from the DUT and the reference model.
B. Reactive Agent
Stalls should prevent the core from fetching a new instruction. So,
the randomization of the sequence items in the sequence needs to be
stalled and no new instructions should be driven to the DUT. A similar
case is when the MULDIV instructions enter the core, the core is frozen
for multiple clock cycles. This randomization process of the sequence
items sent to the DUT is controlled by a signal monitored from the DUT
itself. A Reactive Agent should be used in this case instead of an Active
Agent to control when exactly an instruction should be sent to the DUT
[8].
TABLE II. TEST FEATURES
Unit Test. Description
(UT_1) Testing of each type’s basic operation separately.
(UT_2) Testing of the M-extension basic operation with a
combination of different inputs and testing the data
hazard (forwarding unit stage 3).
(UT_3) Testing of the division by zero.
(UT_4) Testing of the data hazard (forwarding unit stage 4).
(UT_5) Testing of the data hazard (stalls generation) for two
dependent instructions as in Load -> Add.
(UT_6) Testing of the data hazard with M-extension.
(UT_7) Testing of two consecutive stalls (Load -> Add ->
Load -> Add).
(UT_8) Testing of the Conditional jump and Unconditional
jump, check the flush, and the PC value updates.
(UT_9) Testing of a combination of hazards like control
hazards (B-type/ J-type) with data hazards (stall)
and checking FLUSH and the PC value updates.
(UT_10) Testing Branch instructions with M-extension
instructions.
(UT_11) Fault injection with wrong opcodes (corner case).
The reactive agent-based verification approach is used to verify a
design that works as follows: Device-1 and Device-2 are
communicating with each other, where Device-2 is generating a request
(which is the stall signal) whereas Device-1 is responding to the request
(By sending a new random sequence item if no stalls occurred or by
freezing the randomization process if stalls occurred). Device-2 is the
DUT and Device-1 is the Reactive Agent. There are several approaches
to implement a reactive agent. In this work, the Monitor-sequencer
approach is used. The monitor serves as the sampler in this method. The
monitor delivers the request to the sequencer after sampling it. After
sampling the stall from the DUT, the sequence could stop the
randomization process according to the value of the sampled stall
signal.
VI. THE BEAUTY OF VERIFICATION
At first, a test plan was implemented for direct testing to hit specific
interesting cases, which is illustrated in Table I and Table II, and then
the UVM environment is implemented as shown in fig.3.

Due to the usage of constrained random stimulus to the DUT,

unexpected bugs that were not considered in the test plan have been
revealed. Some of these bugs are illustrated in the following section.

Fig.3: UVM environment

Authorized licensed use limited to: ANNA UNIVERSITY. Downloaded256

on August 24,2022 at 08:29:04 UTC from IEEE Xplore. Restrictions apply.
 2021 International Conference on Microelectronics (ICM)
A. Core Bugs
1) First Bug: Shift Arithmetic Right (SRA) and Shift Arithmetic
Left (SRL) instructions were not implemented correctly (when
comparing with a RISC-V simulator). The core was shifting the first
operand by the whole value of the second operand.
2) Second Bug: Branch Less Than (BLT). This instruction subtracts
the first operand from the second operand, then checks the sign of the
result to determine branching decision. The bug was that in case an
overflow occurred in the subtraction, the sign bit of the result is not
calculated correctly, which leads to a wrong branching decision.
3) Third Bug: Branch instructions with M-extension instructions. If
the M-extension instruction is at the execute stage and the branch at the
memory stage, two conflicting control signals will be asserted
simultaneously. Firstly, the stall signal of the MDSU unit will disable
all the five pipeline registers for thirty-two clock cycles and the UVM
sequence will be blocked due to the reactive agent, which will cause the
instruction at the decode stage to be duplicated in the fetch stage in the
next cycle. Secondly, the FLUSH signal will reset the first three
pipeline registers. In this case, the MDSU stall signal should not be
asserted.
B. Bugs Validation
1) The first bug was fixed by modifying the ALU to do shifting
by the value of the least-significant five bits of the second operand.
2) The second bug was fixed by adding an overflow flag and
XORing it with the sign flag to decide whether a branch will be taken.
3) The third bug was solved by modifying the priority of the
FLUSH signal to be greater than the MDSU unit stall signal.
VII. QUESTA TOOLS
Nowadays, the Complexity of SoC design increases rapidly.
Accordingly, tools serving the digital field are indispensable. Through
our project, most of the tools used were Siemens EDA tools, such as:
Questa Sim: provides you with simulation, debug, and verification
platforms. The tool was used in the design and verification phases [9].
Questa Lint: provides an easy solution that enables you to perform
extensive checks on the early stages of RTL development to avoid bad
coding techniques that may end up with RTL synthesis issues.[10]
Questa CDC/RDC: very powerful tool, using only RTL (and UPF
power intent file), Questa CDC/RDC used to identify chip-killing
clock/reset-domain crossing issues rapidly [11].
VIII. RESULTS
According to the previously mentioned core and
Multiplication/Division extension implementations, Table III shows
the results of these different implementations with respect to the speed
of the core. After performing both direct testing and constrained
random testing with the UVM environment on the core, the resulting
bugs were fixed and validated. This was an acceptable exit criterion
for the testing phase. As shown in fig.4, a snippet from the UVM report
shows the results obtained when comparing the output of the C++
reference model and the output of the DUT. After implementing,
verifying, and integrating the core with the hardware security and
UART IPs, an assembly code using RISC-V instructions were written
to test the system-on-chip functionality. The code was written to send
a string “Mentor Graphics” from the core to the hardware security IP
for encryption, then sending it back to the core upon finishing
encryption. Then the encrypted string "#`Nÿ ra-_-/@&Ï" was sent
to the UART to be transmitted to the external world safely. This
encrypted data was then sent back to the hardware security IP to
perform data decryption, the decrypted data was sent back to the core
to ensure it was decrypted successfully to “Mentor Graphics”.
Fig.4: UVM results
Authorized licensed use limited to: ANNA UNIVERSITY. Downloaded257
on August 24,2022 at 08:29:04 UTC from IEEE Xplore. Restrictions apply.
TABLE III. DIFFERENT IMPLEMENTATION RESULTS
Core Implementation Un-Pipelined Pipelined
MUL/DIV Combinational Sequential
Implementation
Speed 2.4 MHz 12 MHz 125 MHz
IX. FUTURE WORK
The UVM environment was designed for testing the RISC-V Core.
The UVM environment can be furthermore improved to be able to test
the whole SoC.
X. ACKNOWLEDGMENT
This work was partially funded by ONE Lab at Zewail City of
Science and Technology and Cairo University, Siemens EDA
(Mentor Graphics), ASRT, NTRA, and ITAC.
XI. CONCLUSION
IoT security is a very important aspect that should be
accomplished. Hardware security has proven to be more robust than
software security. This is due to being faster and immune to software
bugs and having dedicated hardware to execute, which provides more
security to the IoT data. The huge increase in the complexity of SoCs
led EDA companies to develop powerful tools to deal with the issues
that may arise while designing and discover these issues in the early
phases to save time and money. In this work, an SoC was designed for
IoT hardware security applications, and a generic UVM environment
was designed to test our implementation of the RISC-V based Core
and can test other implementations of other RISC-V cores as well.
REFERENCES
[1] Patterson, David, and Andrew Waterman. The RISC-V Reader: an
open architecture Atlas. Strawberry Canyon, 2017.
[2] Accellera Systems Initiative. “Universal Verification Methodology
(UVM) 1.2 User’s Guide” October 2015.
[3] Wu, Wenjuan, Dongchu Su, Bo Yuan, and Yong Li. "Intelligent
Security Monitoring System Based on RISC-V SoC." Electronics 10,
no. 11 (2021): 1366.
[4] Kumar, Vinay BY, Anupam Chattopadhyay, Jawad Haj-Yahya,
and Avi Mendelson. "Itus: A secure risc-v system-on-chip." In 2019
32nd IEEE International System-on-Chip Conference (SOCC), pp.
418-423. IEEE, 2019
[5] M. Bahnasawi, A., K. Ibrahim, A. Mohamed, M. Khalifa, A.
Moustafa, K. Abelmonim, Y. ismail, and H. Mostafa, “ASIC-Oriented
Comparative Review of Hardware Security Algorithms for the Internet
of Things Applications”, IEEE International Conference on
Microelectronics (ICM 2016), Cairo, Egypt, pp. 285-288, 2016.
[6] Oleksiak, Adrian, Sebastian Cieślak, Krzysztof Marcinek, and
Witold A. Pleskacz. "Design and´ verification environment for risc-v
processor cores." In 2019 MIXDES-26th International Conference"
Mixed Design of Integrated Circuits and Systems", pp. 206-209. IEEE,
2019.
[7] Hennessy, J. L., and D. A. Patterson. "Computer Organization and
Design RISC-V Edition: The Hardware Software Interface." (2017).
[8] A. Hussien, S. Mohamed, M. Soliman, Hagar Mostafa, K. Salah,
M. Dessouky, and Hassan Mostafa, “Development of a Generic and a
Reconfigurable UVM-Based Verification Environment for SoC
Buses, ” IEEE International Conference on Microelectronics (ICM
2019), Cairo, Egypt, pp. 195-198, 2019.
[9] Questa® Sim User Guide version 2021.3, 2021.
[10] Questa® Lint User Guide version 2021.3, 2021.
[11] Questa® CDC User Guide version 2021.3, 2021.