14:55:16
sech1:
We can use XMRig (dev branch) now for testing: https://github.com/xmrig/xmrig/pull/3769
15:09:42
sech1:
SpacemiT K3 RISC-V CPU: https://grokipedia.com/page/SpacemiT_K3 https://browser.geekbench.com/v6/cpu/16145076
15:09:50
sech1:
16 cores, hardware AES support and 256-bit vectors
15:09:54
sech1:
This one is interesting
15:51:29
jpk68:
Has anyone tested the Milk-V Mars?
15:51:42
jpk68:
It's not a super interesting board but I can post benchmarks
17:25:53
jpk68:
I keep getting a build error when trying to compile on the board. It seemed to work last time
17:26:14
jpk68:
Error finding "<riscv_vector.h>"
17:28:52
jpk68:
https://paste.debian.net/plainh/18041cbe
18:02:14
sech1:
This is a standard header for risc-v gcc
18:02:25
sech1:
double check that you're using a recent gcc version
18:38:23
jpk68:
Thanks. Looks like I'll have to compile it from source.
18:38:52
jpk68:
Looking back at older chat logs, it's gonna take a while haha
19:42:56
hyc:
SpacemiT_K3 definitely sounds promising
19:43:58
hyc:
no availability before April
19:44:55
hyc:
Sipeed has a SpacemIT K1 module LicheePi 3A that can replace the LicheePi 4A CPU module
19:44:57
DataHoarder:
can get one of these with SG2044 https://en.sophgo.com/sophon-u/product/introduce/srb3-40.html :)
19:45:27
hyc:
Would be cool if they release a new CPU module with the K3
19:45:42
hyc:
https://www.cnx-software.com/2024/09/05/licheepi-3a-a-spacemit-k1-risc-v-development-board-with-som-and-carrier-board/
19:47:23
hyc:
still no sign of hardware AES in SG2044
21:25:14
sech1:
It doesn't have hardware AES
21:25:57
sech1:
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
21:44:05
tevador:
It has an on-die "Security Protocol Accelerator" that can do AES. Source: https://old.reddit.com/r/RISCV/comments/1lvm7j7/sophgo_technology_newsletter_20250709/
21:46:46
hyc:
ah nice find. have never seen their API
21:49:41
sech1:
"Because encryption, decryption and hashing are performed entirely in the accelerator’s DMA pipeline, throughput is significantly higher"
21:49:43
sech1:
"SPACC streams data over a 128-bit AXI interface"
21:49:52
sech1:
So SG2044 is basically screwed with RandomX v2
21:50:15
sech1:
This crypto accelerator is designed for throughput, not latency. And low latency is required in the main loop
21:51:25
hyc:
the only hits I get on security protocol accelerator / spacc are from Synopsis
21:51:26
tevador:
It's perfect for scratchpad fill/hash, but not so much for v2.
21:52:28
sech1:
My tests on Orange Pi RV2 showed 2x slowdown with v2 because of software AES
21:52:50
sech1:
and because of bigger program size, but software AES contributed the most
23:47:03
sech1:
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.
23:47:41
sech1:
Best case scenario (250 MHz and 50 cycles) is 200 ns latency to get anything back from the SPACC
23:49:16
sech1:
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
23:57:52
sech1:
nevermind, I was looking at the wrong numbers. It is much faster (5-10 cycles), and frequency can be as high as CPU cores
23:58:50
sech1:
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)