The single CPU core is a T-Head XuanTie C906.
RV64GC with MMU, In-order at max 1 GHz.
In other sources, itis said to have Vector-instructions but if it does it is most probably an obsolete variant, because the V-extension spec was only finalised last summer and the C906 design is older than that.
Sure, as the D1 SoC has been available for a year already and the C906 core it is was designed around 2.5 years ago, it implements an older draft 0.7.1 version of the RISC-V vector spec.
You can call this "obsolete", but as there are no competing chips on the market now with a newer version -- and probably not for the next 12 months -- I'm not sure that's really fair. For the moment the choice is 0.7.1 or nothing.
It's not as if you even have a choice of ARM SVE (spec published 2016, or 2019 for SVE2) instead in an SBC.
There are of course differences between RISC-V V 0.7.1 and 1.0. The overall style and structure of code is unchanged. Some code is binary-compatible between them, for example the natural implementations of memcpy(), strcpy(), strlen() and friends is. e.g. the code here
https://hoult.org/d1_memcpy.txt and here
https://hoult.org/d1_strcpy.txt which I tested on a D1 board a year ago. With one caveat: to be binary compatible with v1.0 the vlb.v instruction in memcpy() should be changed to vlbu.v. One of the biggest changes between 0.7.1 and 1.0 is that loads and stores no longer widen or narrow values, so the opcodes for sign-extended loads were no longer required and were reassigned. IN this case the mnemonic was also changed, so 1.0 renames vlbu.v to vle8.u, with the same binary encoding. If the prior vsetvli specified 8 bit elements with e8 then the operation is the same.
TLDR: RVV 0.7.1 in the D1 chip and the ratified 1.0 are a little different, but 0.7.1 is not only the sole length-agnostic vector ISA available on an SBC, but is also close enough to prototype code that will usually require only minor changes to wrk on 1.0.
Facebook
Twitter
Instagram