ibex VS riscv-isa-manual

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.

https://github.com/riscv/riscv-isa-manual/releases

Regarding the recent "How to improve the RISC-V specification" post [0], I just wanted to point out, that the latest draft manual is already a great improvement. (see link above)

It includes a lot of the newly ratified extensions: bitmanip,zicond,vector,vector crypto, ...

And there are a bunch of included SAIL definitions for bitmanip and zicond, but other instructions are still missing the SAIL code. Most notably, the SAIL definitions from the RV32I/RV64I base isa are also missing.

I asked for the further SAIL integration plans here: https://github.com/riscv/riscv-isa-manual/issues/1369

Here is an example SAIL snippet from cpopw:

    let bitcount = 0;

I encourage you to look at the newest isa manual draft on github: https://github.com/riscv/riscv-isa-manual/releases

It includes the more recently extensions, and e.g. the bitmanip instructions all have associated pseudo code.

Here is e.g. the code for cpopw:

    let bitcount = 0;

I tried searching the spec [1] for "overflow" and here is what it says at page 17:

> We did not include special instruction-set support for overflow checks on integer arithmetic operations in the base instruction set, as many overflow checks can be cheaply implemented using RISC-V branches.

> For general signed addition, three additional instructions after the addition are required

Is this "cheap", replacing 1 instruction with four? According to some old mainframe era research (cannot find link now), addition is the most often used instruction and they suggest that we should replace each one with four?

Their "rationale" is not rational at all. It doesn't make sense.

Overflow check should be free (no additional instructions required), otherwise we will see the same story we have seen for last 50 years: compiler writers do not want to implement checks because they are expensive; language designers do not want to use proper arithmetic because it is expensive. As a result, there will be errors and vulnerabilities. A vicious circle.

[1] https://github.com/riscv/riscv-isa-manual/releases/download/...

Why not use the actual release PDF instead from their github? https://github.com/riscv/riscv-isa-manual

https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf Part 2

If you don't want to cheat then read the RISC-V ISA manual: https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMAFDQC/riscv-spec-20191213.pdf

Yeah you are on the right track. Processors are designed on top of an Instruction Set Architecture (ISA). For an example you can look on top of the RISC-V specifications:https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMAFDQC/riscv-spec-20191213.pdf (possible PDF download)