We can use XMRig (dev branch) now for testing: xmrig/xmrig #3769

SpacemiT K3 RISC-V CPU: grokipedia.com/page/SpacemiT_K3 browser.geekbench.com/v6/cpu/16145076

16 cores, hardware AES support and 256-bit vectors

This one is interesting

Has anyone tested the Milk-V Mars?

It's not a super interesting board but I can post benchmarks

I keep getting a build error when trying to compile on the board. It seemed to work last time

Error finding "<riscv_vector.h>"

This is a standard header for risc-v gcc

double check that you're using a recent gcc version

Thanks. Looks like I'll have to compile it from source.

Looking back at older chat logs, it's gonna take a while haha

SpacemiT_K3 definitely sounds promising

no availability before April

Sipeed has a SpacemIT K1 module LicheePi 3A that can replace the LicheePi 4A CPU module

can get one of these with SG2044 en.sophgo.com/sophon-u/product/introduce/srb3-40.html :)

Would be cool if they release a new CPU module with the K3

still no sign of hardware AES in SG2044

It doesn't have hardware AES

Whatever they did in X9, it has to be either a separate accelerator on the same package (kind of like an APU), or a special version of SG2044

It has an on-die "Security Protocol Accelerator" that can do AES. Source: old.reddit.com/r/RISCV/comments/1lv…phgo_technology_newsletter_20250709

ah nice find. have never seen their API

"Because encryption, decryption and hashing are performed entirely in the accelerator’s DMA pipeline, throughput is significantly higher"

"SPACC streams data over a 128-bit AXI interface"

So SG2044 is basically screwed with RandomX v2

This crypto accelerator is designed for throughput, not latency. And low latency is required in the main loop

the only hits I get on security protocol accelerator / spacc are from Synopsis

It's perfect for scratchpad fill/hash, but not so much for v2.

My tests on Orange Pi RV2 showed 2x slowdown with v2 because of software AES

and because of bigger program size, but software AES contributed the most

I googled a little about AXI interfaces - their typical latencies are 50-100 AXI clock cycles, and AXI clock frequency is in the range 100-250 MHz.

Best case scenario (250 MHz and 50 cycles) is 200 ns latency to get anything back from the SPACC

well, it has access to L3, so CPU cores can read processed data from L3 directly, but they still need to know when it's safe to read the data - they need to wait for SPACC's "ok" to read the data

nevermind, I was looking at the wrong numbers. It is much faster (5-10 cycles), and frequency can be as high as CPU cores

But SPACC can only exchange data with CPU cores through the L3 cache, as far as I understand, so the whole thing can't be faster than L3 access (+SPACC's internal latency)