HCMUTE / graduation project / hardware security

A compact RISC-V SoC with crypto where the bottleneck lives.

CryptoCore RV32 moves AES-128, SHA-256, and ChaCha20 from firmware loops into dedicated RTL accelerators, connected to PicoRV32 through a memory-mapped AXI4-Lite interface.

Explore the architecture ↓ Read the measured result ↗

PlatformPYNQ-Z2

Clock50 MHz

ISARV32I

Authors Cao Thanh An / Phan Khanh Trinh

01 System at a glance

Fig. 01

The CPU keeps control flow; the coprocessor owns the long cryptographic datapaths.

3hardware
crypto cores

2.81×overall
speedup

0DSPs
consumed

2.840 nspost-route
WNS

00 / The project

One memory map, three cryptographic personalities.

The project is an end-to-end hardware/software co-design study on a Xilinx Zynq-7020 board. PicoRV32 boots firmware from ROM, addresses data RAM and the crypto peripheral through an AXI4-Lite crossbar, and exposes completion through status registers and board I/O.

Control stays software-visible. Firmware selects an algorithm, fills the shared buffer, asserts START, and polls STATUS.

Datapaths stay hardware-native. Each core preserves the natural block or stream format of its algorithm.

Comparison stays honest. CPU-only and CPU + coprocessor paths are evaluated on the same 50 MHz platform.

01 / Architecture

Memory-mapped acceleration

Software starts the job. Hardware carries the rounds.

The AXI4-Lite crossbar gives PicoRV32 one predictable address space for boot ROM, data RAM, and the crypto slave.

Control path MMIO registers

CTRL, STATUS, ALGO_SEL, and BUF[0..31] turn a multi-cycle core into a deterministic firmware call.

Data path Shared register buffer

Inputs and results travel through a 32-bit word buffer without changing the algorithm’s internal operand format.

Dispatch Operation FSM

Idle, dispatch, wait, and done states isolate the three cores and prevent accidental retriggering.

See the register contract ↓

Detailed top-level architecture with PicoRV32, AXI crossbar, ROM, RAM, and crypto cores — Figure 01 The shared address space makes the coprocessor observable, testable, and easy to drive from RISC-V firmware.

01Write BUFInput words

→

02Write CTRLSTART edge

→

03FSM dispatchAlgorithm select

→

04Read STATUSDONE / ERR

02 / Algorithms

Three cores / one interface

Different algorithms. Same disciplined handoff.

Each accelerator is a dedicated RTL core with a ready/busy/done contract and a direct verification path.

01 / Block cipher

AES-128

A 128-bit encryption core with key expansion, SubBytes, ShiftRows, MixColumns, and an explicit round-control FSM. The implementation also exposes encryption/decryption paths and block-mode context at the system level.

128-bit block128-bit keyENC / DECCBC / CTR context

✓

Known-answer validationAES-128 core test matches the expected ciphertext for the standard vector.

AES algorithm overview diagram — Figure 02 AES rounds are mapped to a multi-step state machine so START, BUSY, and DONE remain observable at the system boundary.

03 / Integration

A small register file makes the accelerator feel like a peripheral.

The CPU does not need a custom instruction extension to use the crypto engines. It performs ordinary RV32 loads and stores into an AXI4-Lite address range.

0x00CTRLSTART control bitW

0x04STATUSBUSY / DONE / ERRR

0x08ALGO_SELAES / SHA / ChaChaW

0x10–0x8CBUF[0..31]Input and result wordsR/W

Target boardPYNQ-Z2

Annotated PYNQ-Z2 FPGA development board

The wrapper derives a 50 MHz internal clock from the board reference and exposes status signals through LEDs and Pmod pins.

04 / Evidence

Simulation and implementation

Every claim has a waveform, report, or both.

The verification set covers individual cores, the AXI transaction path, firmware-driven SoC behavior, and post-route implementation evidence.

Simulation / AXI01

Address, data, response

AXI4-Lite handshakes and register-visible completion are exercised before comparing the algorithm outputs.

Core checks02

Known-answer tests

Dedicated AES, SHA-256, and ChaCha20 benches check the expected result and single-start behavior.

Implementation / Vivado03

Placed, routed, and clean

Post-route evidence records 0 DRC warnings, 0 ns TNS, and a positive 2.840 ns WNS at the target clock.

2.840WNS / ns

0TNS / ns

0DRC warnings

05 / Results

CPU-only vs CPU + coprocessor

The acceleration case is visible in both cycles and fabric.

The same three workloads are executed by PicoRV32 firmware alone and by the memory-mapped accelerator design.

Headline comparison2.81×

overall throughput improvement

Across AES-like, SHA-like, and ChaCha-like workloads, the coprocessor path reduces the combined measurement from 5,211 cycles to 1,853 cycles.

CPU-only

5,211 cycles

CPU + crypto

1,853 cycles

Measured performance50 MHz

Workload	CPU-only	Accelerated	Gain
AES-like	1,196	367	3.26×
SHA-like	2,608	529	4.93×
ChaCha-like	1,244	794	1.57×
Total	5,211	1,853	2.81×

The SHA-like workload shows the largest speedup because its round schedule benefits most from dedicated state and constant storage.

Placed utilizationCPU + crypto

Slice LUTs9,132 / 17.17%

Registers8,092 / 7.61%

BRAM tiles11.5 / 8.21%

Vivado timing summary — Timing Positive slack at the target clock.

Vivado power report — Power On-chip power reported after implementation.

LUT and flip-flop comparison — Logic Lower LUT and register pressure than CPU-only.

BRAM tile comparison — Memory Deliberate BRAM use for the shared memory system.

The takeaway

Acceleration is an interface decision before it is a datapath decision.

CryptoCore RV32 keeps the RISC-V software model simple while moving the expensive, repetitive rounds into purpose-built hardware. The result is a compact SoC that is measurable at the firmware boundary and explainable at the RTL boundary.