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%

WNS timing comparison between CPU-only and CPU plus crypto coprocessor — Timing WNS improves from 10.194 ns to 2.84 ns in the comparison capture.

Power consumption comparison between CPU-only and CPU plus crypto coprocessor — Power The coprocessor path uses 0.268 W versus 0.227 W for CPU-only.

LUT and flip-flop resource comparison — Logic Dedicated acceleration increases LUT and FF use by design.

BRAM tile comparison — Memory BRAM rises from 2.5 to 11.5 tiles for the shared memory system.

Project demo / video evidence

See the SoC move from firmware command to board-level result.

The demo video shows the recorded execution evidence for the PYNQ-Z2 implementation, including the software-to-coprocessor handshake and visible status behavior.

Watch demo video ↗

▶

Video demoGoogle Drive folder

↗

06 / Trade-offs

The engineering decision

Hardware acceleration is not free. It is chosen where the payoff is repeatable.

The coprocessor spends fabric, memory, timing margin, and power to remove expensive software round loops. The point is not zero cost; the point is a better system-level balance.

Cost 01 / Logic +853.2% LUTs

Dedicated round logic grows from 958 to 9,132 Slice LUTs, while Slice Registers increase from 662 to 8,092 (+1,122.4%). The accelerated SoC still uses only 17.17% of the available LUTs and 7.61% of the available registers.

Why accept it: crypto rounds repeat predictably and are a better fit for parallel combinational logic than long firmware loops.

Cost 02 / Memory +360% BRAM

BRAM rises from 2.5 to 11.5 tiles because the SoC now stores shared buffers and accelerator state.

Why accept it: the memory cost buys a clean MMIO contract and keeps input/result movement deterministic.

Cost 03 / Timing 10.194 → 2.84 ns

WNS margin is reduced, but the post-route result remains positive, so the 50 MHz target still passes timing.

Why accept it: the clock margin is spent on useful datapath work, not on an unresolved timing violation.

Cost 04 / Power 0.227 → 0.268 W

Estimated on-chip power increases by 18.1% as additional crypto logic and memory become active.

Why accept it: the increase is bounded while workload time falls from 5,211 to 1,853 cycles.

Why the trade is worth it 2.81× faster overall

The accelerated path turns the added hardware into a measurable system benefit: 3.26× for AES-like work, 4.93× for SHA-like work, and 1.57× for ChaCha-like work. It also uses 0 DSPs, keeps slice utilization at 22.47%, and closes timing with positive slack.

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.