A couple questions about Milk-V Duo boards

[SiliconWizard]

Interested in evaluating the CPU they use. I haven't ordered boards yet.

Does anyone know:
- How the C906 core compares to say a Cortex-M7 (namely the main C906 core @1GHz vs a iMXRT10xx @600MHz, for instance)?
- The approximate current draw under typical load, and any "sleep" mode it may have?
- Whether it's possible (probably) but, most of all, documented, to program the main core baremetal (no Linux)? If so, is there any documentation out there? (I've seen the typical setup was Linux on the main core and some RTOS on the second core, I'd like to use both cores baremetal).

Thanks!

[brucehoult]

On my primes benchmark:

Code: [Select]

//    27.196 sec Teensy 4.0 Cortex M7 @ 960 MHz        228 bytes  26.1 billion clocks
//    27.480 sec HiFive Unleashed RISCV U54 @ 1.45 GHz 228 bytes  39.8 billion clocks
//    30.420 sec Pi3 Cortex A53 @ 1.2 GHz T32          204 bytes  36.5 billion clocks
//    36.652 sec Allwinner D1 C906 RV64 @ 1.008 GHz    224 bytes  36.9 billion clocks
//    39.840 sec HiFive Unl RISCV U54 @ 1.0 GHz        228 bytes  39.8 billion clocks
//    43.516 sec Teensy 4.0 Cortex M7 @ 600 MHz        228 bytes  26.1 billion clocks
//    47.910 sec Pi2 Cortex A7 @ 900 MHz T32           204 bytes  42.1 billion clocks
//    48.206 sec Zynq-7010 Cortex A9 @ 650MHz          248 bytes  31.3 billion clocks

The D1 is not the same chip as the Duo but it's the same core at the same speed, and this benchmark runs entirely in cache.

> The approximate current draw under typical load, and any "sleep" mode it may have?

See:



In the comments:

Without SD card: 15mA

Booting: 80-114mA, average about 90.

Idle after boot: 62mA

> Whether it's possible (probably) but, most of all, documented, to program the main core baremetal (no Linux)?

Sure. The UBoot is, after all, open source, so you can either use that to launch your own code (replacing OpenSBI) or else simply hack on the UBoot SPL. The biggest task will be initing the DDR2 RAM, but the code is there.

[SiliconWizard]

Thanks! So, in terms of pure performance, at least from your benchmark, the C906 looks way behind a Cortex-M7 at the same clock freq, but not too far between a M7 @600MHz and C906@1GHz.

In terms of power draw, the "missing" info is whether it has any kind of sleep mode, which you can go to and resume from, either when running Linux, or baremetal.
62mA on "idle" is not bad for a CPU @1GHz, but the ability to put it in some standby mode drawing much less, and from which it could get out of within maybe less than 1s, would be nice. I haven't found the info so far and may have to order boards and figure it out myself.

[brucehoult]

Thanks! So, in terms of pure performance, at least from your benchmark, the C906 looks way behind a Cortex-M7 at the same clock freq

Sure. The M7 is a pretty good dual-issue uarch -- better than A7, A9, A53, maybe close to A55. And running from SRAM not DRAM helps too. The C906 is purely single-issue, in order.

Note that the Duo has massively more RAM with 64 MB (and 256 MB and 512 MB models just becoming available for only a few dollars more)

[SiliconWizard]

Yep. The amount of RAM can be pretty interesting. Using a Cortex-M7, you rarely have access to anything else than PSRAM if you want more than the internal RAM, which is slow and limited to 8MB/chip (at least for the QSPI ones), or maybe SDRAM for some MCUs?

The Duo's with 256MB and over are slightly different beasts as I've seen, they include an ARM core on top of the 2 RISC-V cores. I haven't figured out yet how all 3 can work together.

[brucehoult]

I think you have to choose one or the other at boot time, but I don't know.

Also see:

https://github.com/orangecms/sg_boot "loader for CVItek/Sophgo SoCs (CV1800B, SG200x)"

He said today initial stuff is working and asked for collaborators.

https://t.me/riscv/1/20904

https://t.me/riscv/1/20913

[brucehoult]

More progress today:

"Daniel aka CyReVolt 🐢: Transferring code to the CVITek 1800B worked with my tool. There was no output on the UART though. I'll see if the SRAM address is different, which isn't described in the manual. UART0 seems to have the same base address per the manual."

"plat/cv180x/include/platform_def.h
296:    #define VC_RAM_BASE 0x3BC00000 // Shadow_vc_mem"

"Daniel aka CyReVolt 🐢: aha aha - 0x3BC00000 - neither "VC RAM" nor that address is mentioned in the manual"

"Daniel aka CyReVolt 🐢: THAT WORKS! VROOM VROOM! 🥳"

"I have now successfully run my own code on
- Duo (CV1800B)
- Duo 256M (SG2002)
- Duo S (SG2000)

The CV1800B has its SRAM at a different base address.
UART0 is mapped to the same address for all three."

His "own code" is written in Rust. Blergh for some people, ++ for others :-)

A note on chip names and companies ... Sophgo bought Cvitech a year or two ago, so CV1800B and SG200* share lineage.  Also, a well informed Chinese person on Telegram said a couple of days ago that Sophgo and Radxa are parts of the same company, or fall under the same umbrella company (Bitmain?). I just found this repo, which lends support to this: https://github.com/radxa/bm-bootloader-arm64

[SiliconWizard]

I ordered a couple boards and dug into the SDK and datasheet to figure out the details and possibly how to use it "baremetal".

The SDK repo: https://github.com/milkv-duo/duo-buildroot-sdk
Datasheets & schematics: https://github.com/milkv-duo/duo-files

This post which gave a starting point: https://forum.sophgo.com/t/use-opensbi-to-boot-your-own-operating-system/340

I was able to build the FSBL with mainline GCC 14.1, but that took quite a few changes in various files, so I suggest sticking to the toolchain they provide (which unfortunately is based on GCC 8 ), unless you are brave enough. It takes a while.
Note that recent GCC now includes the T-head extensions in mainline, I guess with GCC 8 this was patched: https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Options.html
The T-head extensions are described here: https://github.com/T-head-Semi/thead-extension-spec/tree/master

So with that info and the datasheet, I should be able to write baremetal stuff. I should receive the boards in a week or so, I'll see how it goes.

The second core should also be freely usable, as far as I got it, they share the same resources, and apart from the fact it doesn't have the vector extension and runs at 700MHz max "only", it's pretty much the same core. In the SDK distribution with Linux on the first core and FreeRTOS on the second, they reserve the upper 768KB of DRAM for the second core, but I think there shouldn't be any problem sharing RAM differently when going baremetal. All this looks pretty cool.

There's even a third core, 8051-based, but which can run at up to 300 MHz. Not sure I'll bother with that for now, but it's also described in the datasheet.

Also, it should be able to boot from eMMC or even from a SPI flash chip. Not sure yet how you'd program the flash chips though, at least initially. Probably before assembly? Haven't gotten into all details about the ROM bootloader. It's not documented in details, just a few sentences.

[Nominal Animal]

Do keep us informed about your experiences; I for one am very interested, and might go the same way.

The main use case for myself is, once again, as an intelligent controller for small displays to use with headless SBCs ("IoT"'y servers) and routers and switches (non-technical human interface for status reporting).

You see, if the interface is slow or sluggish, the nontechnical folks just don't trust it.  It it is slick with small animations (my favourite one is having Tux, my mascot and shown as my avatar, roll its eyes in different directions when booting or checking out something), they seem to trust it much better.

I am intelligent enough to not try and convince them otherwise, since the technology is here to do the job their way.  I just need to learn enough to make the software needed for the job.

In the Milk-V Duo case, I might even run a simple network server (tracking which machines are connected and how) on the Linux side, and the display driver on the RTOS side.  Typical display sizes I use are 320×240 and 480×320, mostly IPS panels from BuyDisplay/EastRising; I don't want the expensive HDMI stuff here.  The simple Linux network server would make it easy to add support for e.g. some ESP32's with temperature and humidity sensors to measure otherwise hard-to-reach nooks and crannies in a big rural house, for example.  It's just that I'm finding it difficult to find/get SD cards I can trust, so would prefer eMMC or something more durable.

[SiliconWizard]

I will. I'll have to confirm with actual tests, of course, but so far I think there should be no problem using this chip as a MCU on steroids.
The only thing that lacks documentation - that I could find - is the TPU, if you're at all interested in using that at a low level as some kind of "general-purpose" accelerator.

One other annoyance (albeit minor) is that this chip has 2 C906 cores, which are good overall but were designed when the vector extension was not ratified yet. So it implements rvv 0.7.1, while rvv has been ratified and is 1.0 now, and recent binutils only support rvv 1.0. That bites as there are a number of actual chips on the market that have implemented rvv 0.7.1 and they are now "let down" by the toolchains - you'd have to stick to a pretty old version, and find it. This has been discussed already a couple years ago (found discussions about it with Bruce), so this is not a new problem. From what I know, so far, very few actual, available chips implement rvv 1.0. There is the newer K230 which apparently does, but I haven't had all that great experience with Kendryte in terms of support (with the K210), so I would personally shy away from Kendryte at this point.

Of course, the chip is perfectly usable without the vector extension. Alternatively, one can either find a version of binutils that supports rvv 0.7.1 and just use 'as' for assembly code which uses rvv and still use a recent and mainline GCC/binutils for the rest. Or implement your own assembler.

Regarding displays, yes, note that the CV1800B doesn't support any video output, only input. But of course you can drive TFT panels which have a SPI controller. Note that the chip doesn't have any kind of "parallel"/FSMC interface, so you either have SPI, UART or SDIO. (It has 2 SDIO controllers, one is used by the SD card, but I'm thinking of using the second for communicating with a FPGA. You can otherwise use it to connect another flash chip, SD card or even modules with a SDIO interface such as some WiFi modules.)

Yes in your case, going "baremetal" may not be the most efficient approach: using the provided Linux on the main core and FreeRTOS on the second will work, and it's readily supported.
For using eMMC, from what I gathered, the board has a footprint (not populated) for a Flash chip that can be used instead of a SD card - note that the pins are routed in parallel, so it's either one or the other, they share the same SDIO controller. And you'd need a eMMC chip with a SDIO interface, from what I got. They give a list of supported chips in the following file: duo-files/duo/hardware/CV1800B-Flash-Support-List.pdf
As I said, I don't know yet how you can flash it this way, as one can't solder a Flash chip and boot from a SD card at the same time. Either you'd have to flash the chip beforehand with an external programmer, or maybe there's a USB mode in the bootloader that I don't know how to use yet. Something to figure out.

[brucehoult]

One other annoyance (albeit minor) is that this chip has 2 C906 cores, which are good overall but were designed when the vector extension was not ratified yet. So it implements rvv 0.7.1, while rvv has been ratified and is 1.0 now, and recent binutils only support rvv 1.0.

Not if by "recent" you mean gcc 14.1, binutils 2.42 which support both RVV 1.0 and RVV 0.7.1 (under the name XTHeadVector).

You can choose which version you want using command line -march.

Even better, if you write RVV code using the C intrinsic function interface then the same source code can be compiled to either 0.7.1 or 1.0.

The only missing feature is auto-vectorisation doesn't support 0.7.1.

That bites as there are a number of actual chips on the market that have implemented rvv 0.7.1

Yes, literally billions of chips shipped according to THead, and on Linux-capable boards priced as low as $5 (such as the Duo, but also Pine64 ox64 and Sipeed M1s (BL808 chip) both of which also have 64 MB RAM.

0.7.1 is, obviously, not quite as good as 1.0, otherwise we wasted 2 1/2 years of committee time between those releases, but it's still a darned good vector ISA, and better than SIMD ISAs. Probably as good as Arm's SVE.

Meanwhile, what's the cheapest thing you can get SVE (spec published in 2016) or SVE2 (2019) in? No SBC that I know of -- not the RK3588, for example. High end phones only.

and they are now "let down" by the toolchains - you'd have to stick to a pretty old version, and find it. This has been discussed already a couple years ago (found discussions about it with Bruce)

Not a problem, I've had the relevant GCC/binutils snapshot at https://github.com/brucehoult/riscv-gnu-toolchain even since the first C906 boards came out in 2021.

But now you can simply use current GCC.

From what I know, so far, very few actual, available chips implement rvv 1.0. There is the newer K230 which apparently does

K230 was the first, with the CanMV-K230 board released back in October. It's got two cores with the larger (1.6 GHz, dual issue C908) one supporting RVV 1.0. There are a couple of annoyances with it, the big one being that it's only got 0.5 GB RAM, the small one that the vendor OS runs Linux on the small (non RVV) core reserving the big core for microcontroller/realtime use. 3rd parties had figured out how to run Linux on the big core, with RVV enabled.

https://code.videolan.org/Courmisch/k230-boot/

See also this excellent video which demos running RVV 1.0 code on the CanMV-K230:

youtube.com/watch?v=Ozj_xU0rSyY

The BananaPi BPI-F3 started getting delivered to customers in the last month. It has 8 dual-issue cores running at 1.6 GHz (and reportedly better than Arm A55 or SiFive U74) each with RVV 1.0. Also the price is good at $63 for a board with 2 GB RAM or $75 for a board with 4 GB RAM.

https://www.aliexpress.us/item/1005006921744822.html

The problem is I don't regard 4 GB as enough for an 8 core system. The SoC supports 16 GB RAM, which would be great, but boards with this are not (yet) available.

There are a couple of faster boards coming up using SiFive P550 cores. They will be comparable to RK3588 boards except they DON'T have RVV.

Late in the year the SG2380 boards with 16 SiFive P670 cores with RVV 1.0 should appear. Those are OoO with roughly Arm A78 performance, including around 2.5 GHz clock for the P cores. That should make a really usable PC, getting up into early i7 territory I think.

Of course, the chip is perfectly usable without the vector extension. Alternatively, one can either find a version of binutils that supports rvv 0.7.1 and just use 'as' for assembly code which uses rvv and still use a recent and mainline GCC/binutils for the rest. Or implement your own assembler.

Yup. Been doing that for years.

But now just use the current GCC version, 14.1.

[SiliconWizard]

One other annoyance (albeit minor) is that this chip has 2 C906 cores, which are good overall but were designed when the vector extension was not ratified yet. So it implements rvv 0.7.1, while rvv has been ratified and is 1.0 now, and recent binutils only support rvv 1.0.

Not if by "recent" you mean gcc 14.1, binutils 2.42 which support both RVV 1.0 and RVV 0.7.1 (under the name XTHeadVector).

Ah thanks! Didn't realize that was what the XTHeadVector implemented. Great. I'm using GCC 14.1 now, so that's all good. Solved.

[brucehoult]

One other annoyance (albeit minor) is that this chip has 2 C906 cores, which are good overall but were designed when the vector extension was not ratified yet. So it implements rvv 0.7.1, while rvv has been ratified and is 1.0 now, and recent binutils only support rvv 1.0.

Not if by "recent" you mean gcc 14.1, binutils 2.42 which support both RVV 1.0 and RVV 0.7.1 (under the name XTHeadVector).

Ah thanks! Didn't realize that was what the XTHeadVector implemented. Great. I'm using GCC 14.1 now, so that's all good. Solved.

There are a couple of minor differences:

- XTHeadVector doesn't include the "ediv" feature from 0.7.1 (which was optional and C906/C910 don't implement)

- XTHeadVector adds the "vlenb" CSR (vector register length in bytes), which was not in the 0.7.1 spec.

I think that's it!

[SiliconWizard]

I should have received the boards almost a week ago, but the package got stuck at a transit facility for an unknown reason. Annoying.

[SiliconWizard]

I finally received the boards and got some good news, more on that later. The baremetal approach does work just fine.

[SiliconWizard]

So, some results so far:

• As shown in the post I linked to, but not really explained, the approach here for going baremetal is to build OpenSBI and have it start your own code, in place of u-boot. This is the easiest and fastest way to go baremetal. The DDR controller and all clocks get configured for you. You don't need u-boot, and going via u-boot would probably make it not just longer to boot, but harder, unless you know u-boot very well and are meaning to write some kernel that resembles Linux.
• The boot time from power on to your own code, as I measured using the integrated 'time' CSR, and giving a result consistent with what I timed manually, is, in my case, 1816 ms. So, that's just the CPU booting and OpenSBI running to completion. Not bad, but I was expecting shorter. It's probably possible to get shorter boot time by configuring OpenSBI appropriately, for instance by disabling the console output, which is configured for UART output @115200 Bd, so that's kinda slow.
• There's a tool in the SDK (as also shown in the linked post) that generates a 'fip.bin' file which amalgamates OpenSBI and your own code (or u-boot), and additionally the code for the second core. For the SD card, you just to format it with a primary FAT32 partition, and copy the fip.bin file in the root of it. I have created the partition as a 128 MB one with the boot flag, and labeled it 'boot', as is done my milkV too, but I'm not sure this is at all required. Possibly all you need is a FAT32 partition as the first primary partition, and that's it. But anyway, 128 MB is more than enough to fit this file, knowing that you only have 64MB of RAM in total anyway. You can always create other partition to store more data, as they do for Linux.
• I measured the current draw from USB (so @5V) with my test program running on the main core. I get an average of about 70 mA. Note that the second core is (for now) unused, and I don't know whether it's parked in a low-power state, or if it runs an infinite loop, or whatever. I don't know the intricacies of OpenSBI on this chip quite yet. Also note that the board uses only buck converters (and not LDOs) for generating all voltages, so this is more or less really the power that the chip draws. Plus the LED that I'm flashing.

My first test was freezing the CPU once OpenSBI started my code, and I finally found out why (no debugger with this...): the generated code used some vector (from rvv 1.0) instructions for optilmizing memory copy operations, because I had forgotten to remove the 'v' in the march options, using GCC 14.1. So it was just triggering an exception when hitting the first vector instruction. (This is done by GCC's optimizer, at no point I was explicitely using vector instructions. So, something to know.)

I use a riscv64-unknown-elf GCC.

These are the compiler options I use:

-mabi=lp64d
-march=rv64imafdc_xtheadcmo_xtheadsync_xtheadvector_zicsr_zifencei
-mcmodel=medany

You'll need the medany memory model, because with this chip (like with many other 64-bit RISC-V CPUs), the DDR RAM lies beyond the 2GB limit.
So you'll need a GCC compiler that was built with support with medany. Not all riscv64-unknown-elf toolchains support it, so be careful, in particular if you build your own toolchain.

Other than that, the CV1800B datasheet is decent. There's a lot that is missing (it's only 692 pages for such a complex chip), but there's enough to use all peripherals. The only thing that I've found missing so far, unless I missed it, is the 'pinmux' registers that are not documented. But you'll find the "doc" in form of source code (good luck) in the buildroot SDK.

Some additional random notes:

• The SPI peripherals only support master mode. I2C supports both master and slave, though.
• There are 8 32-bit timers, but only downcounting.
• The initial boot process is not documented. There are barely a few lines to hint at how we can boot from SPI Flash instead of SD, but that's pretty much it.
• I have tested GPIOs and UART in baremetal code so far, both working as expected. I tried reading the temperature sensors, but I only get 0 so far for the readings. I haven't found code about them in the SDK, so not sure (or almost sure not) they are using them with Linux. Maybe the clock for them is not enabled by default. I'll have to figure it out.

Also, for those curious, this is the console output you get initially from OpenSBI:

Code: [Select]

C.SCS/0/0.WD.URPL.SDI/25000000/6000000.BS/SD.PS.SD/0x0/0x1000/0x1000/0.PE.BS.SD/0x1000/0xc400/0xc400/0.BE.J.
FSBL Jb28g9:g34fb84e8-dirty:2024-06-01T08:27:38+02:00
st_on_reason=d0000
st_off_reason=0
P2S/0x1000/0x3bc12400.
SD/0xd400/0x1000/0x1000/0.P2E.
DPS/0xe400/0x2000.
SD/0xe400/0x2000/0x2000/0.DPE.
DDR init.
ddr_param[0]=0x78075562.
pkg_type=3
D3_1_4
DDR2-512M-QFN68
Data rate=1333.
DDR BIST PASS
PLLS.
PLLE.
C2S/0x0/0x0/0x0.
No C906L image.
MS/0x10400/0x80000000/0x22000.
SD/0x10400/0x22000/0x22000/0.ME.
L2/0x32400.
SD/0x32400/0x200/0x200/0.L2/0x414d3342/0xcafe04ed/0x80200000/0x1a00/0x1a00
COMP/1.
SD/0x32400/0x1a00/0x1a00/0.DCP/0x80200020/0x1000000/0x81500020/0x1a00/1.
DCP/0x23e0/0.
Loader_2nd loaded.
Use internal 32k
Jump to monitor at 0x80000000.
OPENSBI: next_addr=0x80200020 arg1=0x80080000
OpenSBI v0.9
   ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |____) | |_) || |_
  \____/| .__/ \___|_| |_|_____/|____/_____|
        | |
        |_|

Platform Name             : Milk-V Duo
Platform Features         : mfdeleg
Platform HART Count       : 1
Platform IPI Device       : clint
Platform Timer Device     : clint
Platform Console Device   : uart8250
Platform HSM Device       : ---
Platform SysReset Device  : ---
Firmware Base             : 0x80000000
Firmware Size             : 160 KB
Runtime SBI Version       : 0.3

Domain0 Name              : root
Domain0 Boot HART         : 0
Domain0 HARTs             : 0*
Domain0 Region00          : 0x0000000074000000-0x000000007400ffff (I)
Domain0 Region01          : 0x0000000080000000-0x000000008003ffff ()
Domain0 Region02          : 0x0000000000000000-0xffffffffffffffff (R,W,X)
Domain0 Next Address      : 0x0000000080200020
Domain0 Next Arg1         : 0x0000000080080000
Domain0 Next Mode         : S-mode
Domain0 SysReset          : yes

Boot HART ID              : 0
Boot HART Domain          : root
Boot HART ISA             : rv64imafdcvsux
Boot HART Features        : scounteren,mcounteren,time
Boot HART PMP Count       : 16
Boot HART PMP Granularity : 4096
Boot HART PMP Address Bits: 38
Boot HART MHPM Count      : 8
Boot HART MHPM Count      : 8
Boot HART MIDELEG         : 0x0000000000000222
Boot HART MEDELEG         : 0x000000000000b109


[SiliconWizard]

Some additional facts.

I managed to make the temperature sensor work. I was initializing it correctly, except for one thing: I was passing "3" for the channel selection (tempsen_ctrl register, see datasheet of the CV1800B), as was documented, to enable both sensors.
Looking for some clues, I found this patch: https://lore.kernel.org/linux-kernel/20240531-oyster-duct-9eaf5f3e6f35@spud/T/ (which hasn't made it to the milkv sdk yet, that I know of). The driver contains code for converting the read values in °C, which the datasheet does not document, so that was handy too.
They do pass "1" for the channel selection. They seem to use only 1 channel anyway. Since everything else was exactly the same, I tried passing 1 instead of 3, and bam, it worked. So, I'm assuming there's either a fault in the datasheet, or this is a silicon bug. What leads me to think of a silicon bug is that the interrupt flags (in tempsen_intr_raw register) show that both channels 0 and 1 have completed a measurement, yet the second channel only ever returns 0. When passing 3 as the channel selection, both channels return 0 and the interrupts flags are all 0. So, yeah. If anyone reads this and has worked on the Linux driver, and has a clue about that... (I guess they had access to documentation/info that is not in the public documents?)

Note that the SG2000/2002 are very similar to the CV1800B (that I'm assuming Sophgo bought, and then released new chips under their own name), and the docs are there: https://github.com/sophgo/sophgo-doc/releases/
These docs are nicer to navigate, and while very similar in content, they at least document the pinmux functions, while the CV1800B DS did not. So, that'll help. But regarding the temperature sensors, they document that in the exact same way as in the CV1800B. So, I dunno. To see if  both channels actually work in the SG2000/2002, I'd have to get a board with one of these (Duo 256M, Duo S).

Regarding power consumption, I got about 0.35W on average, but the given figure of 0.5W with video input active and the TPU seems to be about right. Conversely, all clocks seem to be enabled by default, so disabling clocks for peripherals that aren't used should lower power consumption significantly. Something I'll try.

Back to temperature, the internal temp sensor gives me around 46.5°C (for 25°C ambiant) after 1 hour or so. So that shouldn't require any heatsink whatsoever. Maybe if you intend to use it in very high temperature environments, you could stick a small passive heatsink and call it a day. Note that the internal temp sensor peripheral implements thresholding and that can be tied to interrupts, or even just reset the CPU in case the temp is outside the thresholds you defined.

[SiliconWizard]

I've run Bruce's countPrimes() on the main core. Here's the result:

Code: [Select]

37.918 sec CV1800B C906 @ 1.0 GHz               ??? bytes  32.2 billion clocks
I also computed the average CPI for this function and got: 1.147. (The code is very branchy.)

Not bad at all. It sits between the SiFive U54 and SiFive U74.

The discrepancy between the execution time and number of clock cycles indicates that either the CPU clock is not set for 1 GHz exactly, or that the 'time' CSR that I use for timing execution is not accurate. (Although I doubt the latter as it's clocked from the 25 MHz crystal oscillator.)

[brucehoult]

That's fairly much in line with the original AWOL Nezha D1 dev board:

36.652 sec Allwinner D1 C906 RV64 @ 1.008 GHz    224 bytes  36.9 billion clocks

That was run in March 2021 via ssh to an early board in China, so a fairly old gcc version (though the benchmark isn't very susceptible to compilers or optimisation).

[SiliconWizard]

Yeah, trying to figure out clock settings. The results I got seem to indicate that the core runs @ 850 MHz.
My code, as I explained, runs after OpenSBI, and I'm not sure how they set up clocks at this stage, or if they leave them as default.
And the datasheet, regarding clocks, is uh, not very explicit.
My best bet might be to have a look at the Linux code and how they handle CPU clock frequency.

Edit: OK, I think I found it. They set clocks in the FSBL (first-stage bootloader). Can be seen in: duo-buildroot-sdk/fsbl/plat/cv180x/platform.c , in sys_pll_nd() , line 317.
They set the first core at 850 MHz, and the second at 594 MHz. I don't know what the rationale for these frequencies is. I'm curious.
In fact, the first core is clocked from the MPLL, which is set at 850 MHz, while the chip's default for MPLL is 1000 MHz. Again, why, it's anybody's guess.
But the source code of this function has all I need to change frequencies.

So, while it's the number of clock cycles that matters for your benchmark, please change the "1 GHz" value to "850 MHz" to make it correct. I'll re-test when I manage to switch to 1 GHz. I may also try "overclocking" the core to see what happens.

[brucehoult]

Yeah, trying to figure out clock settings. The results I got seem to indicate that the core runs @ 850 MHz.

Ahh, so the lower number of clocks may be correct if, for example, your compiler is using the THead extensions. Though 15% lower is a lot.

[SiliconWizard]

Just to make sure it was clear: I use the cycle CSR to count cycles and the time CSR (which on this chip is clocked from the main 25 MHz oscillator) to count time. So, the number of cycles (+/- obviously a few cycles) is exact and does not rely on timing. This is also why I got a time that wasn't consistent with the number of cycles (that should have been @ 1 GHz), which is how I figured that the CPU was not running at 1 GHz, but 850 MHz. Later confirmed by the above code.

So, the CPU clock frequency shouldn't change the number of cycles whatsoever. Just the time. And at 1 GHz, it will be about 32.2 s.

I looked at the disassembled code, and no vector extension is used, nor anything specific to C906, as far as I saw. So, either the C906 is more efficient on this chip than on the D1, or it's just a matter of compiler optimizations. Which is likely. Note that I got this result at -O3. I can check with -O1 for a comparison.

Otherwise, the differences will mainly be about cache differences, I guess. Also, the C906 may not be configured exactly the same way as in the D1 for some other parameters. Might be worth rechecking on the D1 with GCC 14.1, but before that, I'll test at -01 and may get the same result as you saw for the D1.

Result with -O1: 39.1 billion clocks
Result with -O2: 32.2 billion clocks

So, definitely a significant difference here between -O1 and -O2 / -O3, with GCC 14.1. There is almost no difference between -O2 and -O3, although very slightly fewer clocks at -O2 (but less that 1% difference).

[brucehoult]

Wow that 39.1 with -O1 is weirdly more than the 36.9 on the D1 in 2021.

There won't be any vector instructions, but things from Zba such as `sh2add` (`(rs1 << 2) + rs2`) make a noticeable difference to array addressing on SiFive's U74 -- see the difference between the HiFive Unleashed and the VisionFive 2.

The `xtheadba` extension (supported in gcc 13 and later) has the similar `th.addsl rd, rs1, rs2, imm2` instruction, which does `rs1 + (rs2 << imm2)`

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=8351535f20b52cf332791f60d2bf22a025833516

[SiliconWizard]

Nope, it seems to only use instructions from the base RV64IM. Unless I missed something.

You can check for yourself, with the same options I used: https://godbolt.org/z/Ef4TY844x
and compare with -O1.

[brucehoult]

Nope, it seems to only use instructions from the base RV64IM. Unless I missed something.

You can check for yourself, with the same options I used: https://godbolt.org/z/Ef4TY844x
and compare with -O1.

You do have to add the relevant extensions :-)

https://godbolt.org/z/1KExjPfaa

For some unknown reason gcc uses the Zba instructions later on in the .L9 block too, but not for XTHeadba.