openc906 VS ibex

Datasheet: https://github.com/milkv-duo/hardware

Reading the datasheet, it looks like there is one C906 cpu with 700 Mhz without the the vector extension and one C906 cpu at 1Ghz with rvv 0.7.1. The C906 design has been opensourced and is available here: https://github.com/T-head-Semi/openc906

The C906 supports rv64gc with optimal rvv 0.7.1 with a vlen of 128, but a 256 wide ALU.

They list H.264/H.265 support, but I don't think it's a standardized extension.

But see my other comment about using the pre ratification vector extension:

Note that the implementations themselves are often not open source, for example a random person won't be able to get the sources of these SiFive cores anywhere. As of a open-source core from a commercial company, the OpenC906 is an open-source implementation provided by T-Head, but the vector unit is not included in the open source version and thus cannot enabled.

Still not free hardware, real chads use XuanTie C906 based MangoPi MQ-PRO!

Try and see if you can find any stolen code here[0] or here[1].

Cheers.

0. https://github.com/T-head-Semi/openc906

1. https://github.com/T-head-Semi/openc910

I wouldn't quite say that's the case. Two of the three full Linux capable RISC-V SoC releases this year are using open source CPU cores. The BL808 and the Allwinner D1 both use T-Head CPU cores that are available on GitHub https://github.com/T-head-Semi/openc906 . The JH7110 in the VisionFive2 and Star 64 does use a closed CPU core however.

For example, let's take the ClockworkPi uConsole. It uses an Allwinner D1 chip as it's main processor which has a seemingly auditable XuanTie C906 which could theoretically be verified if one opened up a few chips.

For an example of what CPU core RTL looks like look no further than: https://github.com/T-head-Semi/openc906

For example, for the record, the open source C906 RTL, found here https://github.com/T-head-Semi/openc906 doesn't even have the vector files in there.

> Right now, most devices on the market do not support the C extension

This is not true and easily verifiable.

The C extension is defacto required, the only cores that don't support it are special purpose soft cores.

C extension in the smallest IP available core https://github.com/olofk/serv?tab=readme-ov-file

Supports M and C extensions https://github.com/YosysHQ/picorv32

Another sized optimized core with C extension support https://github.com/lowrisc/ibex

C extension in the 10 cent microcontroller https://www.wch-ic.com/products/CH32V003.html

This one should get your goat, it implements as much as it can using only compressed instructions https://github.com/gsmecher/minimax

We've had people consider Ibex for space applications, well verified and has a dual-core lockstep option: https://github.com/lowRISC/ibex.

An ETH Zurich team have done a triple core lockstep version for cubesats: https://www.theregister.com/2023/10/05/riscv_microcontroller...

I definitely agree with the primary point, "building a chip that meets specfic requirements we got from the customer" is not easy and it what matters.

However, RISCV cores abound. In pretty much any computing language known to man with varying design trade-offs and capabilities. It's extremely difficult to differentiate at the RTL level at this time.

Here is a high quality, well documented, SystemVerilog version intended for embedded applications that I know has been included in multiple ASIC and FPGA designs successfully.

https://github.com/lowRISC/ibex

lowRISC's (www.lowrisc.org) mission is to bring open source silicon to the hardware world and see it shipping in volume in commercial applications. We want to see open source silicon occupy a similar position to open source software (e.g. look at Linux, it's the default choice in many applications, we'd like open source silicon to be used for similar foundational technologies in the hardware world).

Here I will just use Ibex, a risc-v processor as an example, of which the repository is here: lowrisc_ibex. There are many files in this repository and I wonder which files I need given a specific configuration (for example, the configuration of "maxperf"), and how I can combine all the necessary files together, feed them to verilator and get its verilated model? I understand that only by going through this step will I acquire necessary C++ header files to write the testbench

i think it might be worth it to post it here because lowrisc develops ibex (a open source risc-v core).

Yeah but you can have both an open source (e.g. ibex) and closed source implementations for controllers (the open source one is free and you can improve it and even close its source so competitors won't benefit from your improvements) , and you can migrate from one supplier to another without spending a lot of money on migrating the software.

I am pretty new to RISC-V and open-source hardware and just began learning and working with them as part of my research. I searched about different models that have some credible documents and research done into them and decided I would try and use the ibex as the hardware language is easier for me to follow too.

Ibex is open source and has taped out - https://github.com/lowRISC/ibex

That said we used Spike as a reference simulator for verifying Ibex (RISC-V core I work on, https://github.com/lowRISC/ibex) and we run an extensive set of random programs through it comparing its execution to Ibex's and I've not come across any major issues.