CIRCE – CROSS Integrated RISC-V Cryptographic Extension

CIRCE is a tightly-coupled cryptographic accelerator integrated through the Core-V eXtension Interface (CV-X-IF) and implementing the CROSS primitives — both R-SDP and R-SDPG variants — on RISC-V.

The accelerator extends the X-HEEP SoC with custom coprocessor instructions and provides a complete software/hardware evaluation flow, including simulation and FPGA execution.

---

📁 Repository Structure

CIRCE/
├── config/         # Build configuration files and SoC setup
├── hw/             # Hardware modules
├── scripts/        # Automation and compilation scripts
├── sw/             # CROSS test applications and full implementations
├── tb/             # Testbenches and simulation environments
└── util/           # Support utilities and helper files

---

🚀 Getting Started

To build the X-HEEP MCU and prepare the Questasim environment:

make mcu-gen
make questasim-build

Run the full (headless) simulation:

make questasim-sim

Run the selected software application on the simulated SoC:

make questasim-run

Simulation UART output is available at:

build/polito_vlsi_crheepto_0/sim-modelsim/uart.log

To inspect the waveforms:

make questasim-gui

---

🧪 Software Applications

All applications are stored under sw/ and fall into two categories:

---

1) Unit Tests for Individual CROSS Primitives (sw/tests/)

These applications validate a single R-SDP or R-SDPG primitive, in either software or hardware mode (depending on compile-time flags):

#define ENABLE_<test_name> 1

keccak is common to both variants

R-SDP Unit Tests

• _dznorm
• _r2v
• _rvm
• _rvmul
• _syupd
• _vmul
• _vpw

R-SDPG Unit Tests

• _r2vg
• _rvmg
• _rvmulg
• _syupg
• _vmulg
• _vpwg

---

2) Full CROSS Implementations (sw/CROSS-apps/)

Applications whose names start with CROSS_ or G_CROSS_ contain the complete implementation of the CROSS algorithm.

They are provided for all security levels (1, 3, 5) and optimization corners (b, f, s).

R-SDP Full Implementations

• CROSS_1_RSDP_b, CROSS_1_RSDP_f, CROSS_1_RSDP_s
• CROSS_3_RSDP_b, CROSS_3_RSDP_f, CROSS_3_RSDP_s
• CROSS_5_RSDP_b, CROSS_5_RSDP_f, CROSS_5_RSDP_s

R-SDPG Full Implementations

• G_CROSS_1_RSDPG_b, G_CROSS_1_RSDPG_f, G_CROSS_1_RSDPG_s
• G_CROSS_3_RSDPG_b, G_CROSS_3_RSDPG_f, G_CROSS_3_RSDPG_s
• G_CROSS_5_RSDPG_b, G_CROSS_5_RSDPG_f, G_CROSS_5_RSDPG_s

---

🧩 Compiling Applications

Applications can be compiled manually or via the interactive compilation script.

---

Option A — Manual Compilation

Use:

make app PROJECT=<app_name>

Example (unit test):

make app PROJECT=tests/keccak

Example (full CROSS implementation):

make app PROJECT=CROSS-apps/CROSS_5_RSDP_f

---

Option B — Recommended: Interactive Compilation Script

To simplify compilation and avoid manual copying/configuration, use:

Compile a unit test:

./scripts/compile_apps.sh --test

This will:

1. Display an interactive menu of all unit-test applications
2. Run make app PROJECT=<test>
3. Store the compiled app in:

build/sw

---

Compile a full CROSS application:

./scripts/compile_apps.sh --complete

This will:

1. Show an interactive menu of all CROSS_ and G_CROSS_ applications

2. Let the user select which part of the protocol to run:

   • keygen
   • sign
   • sign_open
     This must be modified INSIDE the script!

3. Compile the application via make app PROJECT=...

4. Store the final output in:

sw/compiled_apps

This script is the recommended way to build both test benches and full CROSS applications.
Once compiled, the application can be ran through Questasim.

---

🔧 FPGA Deployment

CIRCE can be executed on FPGA using the X-HEEP hardware infrastructure.

1. Generate the Bitstream

make vivado-fpga FPGA_BOARD=zcu104

2. Build a Software Application for FPGA

Also in this case, two options are available.

Manually

make app PROJECT=<application_name> TARGET=zcu104 LINKER=on_chip

After this, the FPGA system is ready to run the application.

Helper script

The repository also provides:

./scripts/compile_apps_fpga.sh <app_folder> <app_name1> [app_name2 ...]

This helper script is intended for batch compilation of selected applications for the ZCU104 target. For each specified application, it:

1. checks that the application exists under sw/applications/<app_folder>/
2. modifies the protocol-selection macros in the local main.c
3. runs:

make app PROJECT=<app_folder>/<app_name> LINKER=on_chip TARGET=zcu104

4. copies the generated output from build/sw/app into a dedicated destination folder

In its current configuration, the script is set to build the sign flow, i.e.:

#define TEST_KEY 0
#define TEST_SIGN 1
#define TEST_SIGN_OPEN 0

Therefore, to build keygen or sign_open, the corresponding macro values must be changed inside the script before execution.

---

For more details on FPGA execution, refer to X-HEEP's FPGA documentation: https://github.com/esl-epfl/x-heep/tree/main/docs/source/How_to

---

🔧 ASIC

All the commands for the ASIC flow have been left in this repo for completion, even though all the sensitive information and scripts have been removed.

To perform the ASIC synthesis:

make asic

All the post-synthesis functional simulations and power analyses are supported:

make questasim-sim-postsynth 

Power analysis

Power analysis is performed on the applications in sw/applications/VCD_triggered_apps/, which isolate representative self-contained cryptographic kernels with high runtime impact and meaningful activity on the accelerated datapath.

To obtain the post-synthesis power results for a specific test, compile the app and then run:

make questasim-sim-postsynth VCD_MODE=2
make power-analysis

The helper script scripts/get_power_results.sh can be used to automatically run this flow on selected applications from sw/applications/VCD_triggered_apps/.

Usage:

./scripts/get_power_results.sh <app1> [<app2> ...]

For each selected application, the script:

1. compiles it with:

make app PROJECT=VCD_triggered_apps/<appname>

2. runs the post-synthesis simulation with VCD dumping enabled:

make questasim-sim-postsynth VCD_MODE=2

3. launches the power analysis step:

make power-analysis

4. stores the generated reports by renaming:

implementation/power_analysis/reports

to

implementation/power_analysis/reports_<appname>

👥 Authors

• Alessandra Dolmeta — alessandra.dolmeta@polito.it
• Valeria Piscopo — valeria.piscopo@polito.it