VexRiscv VS ibex

With LiteX you can synthesize a VexRiscV processor. You can run Linux on it. The toolchain is pretty easy to use, as long as you use Xilinx Vivado to compile to gateware.

I don't get what's going on with licensing and device support. I'm missing something here perhaps, but we use Cyclone 10 GX onwards and Quartus Pro so I don't have enough context maybe. Have you considered swapping your Nios ii to a VexRISCV as a side note? At ~1 Dhrystone MIPS/MHz it's roughly double that of the Nios V, for very few resources. All open source too. None of the migration documentation support though, so I can't judge how hard it would be.

If you use LiteX to generate a VexRiscV system-on-a-chip, you can include an open source DDR DRAM PHY. This works on Xilinx Spartan-6, Spartan7Artix7/Kintex7/Virtex7 FPGAs, and Lattice ECP5 FPGAs. DDR/LPDDR/DDR2/DDR3 depending on the FPGA.

Something like https://github.com/SpinalHDL/VexRiscv will take far fewer

A CPU built around the Gentoo philosophy would look like https://github.com/SpinalHDL/VexRiscv ;). Don't want an MMU? Fine. Need a larger RAM interface? You got it. Barrel ALU for DSP? Sure.

Interpreted languages work by consolidating all of the optimization effort in the interpreter. This is similar to how CPUs work now, instead of extremely specific optimizations that are hard to create distributed among all code we use very general optimizations that push the limits of mathematics that is centralized in a CPU.

-----

Itanium had a lot of contemporary issues that made it not work. I would certainly blame Intel's business practices and reputation for a large part of it. There are likely niches for such processors. The VLIW is useful for DSP or graphics. Indeed, the only extant VLIW (that I know of) processor is the Russian Elbrus. I think the VLIW is only included to let them reuse a lot of the core logic of the CPU to drive a DSP engine, useful for radar and scientific simulation, though the sci sim would probably use commercial hardware which would be faster.

It works on GPUs because they're doing DSP, basically. We could have weirder topologies for GPUs however, like a massive string of ALUs driven off an embedded core, so you try to kachunk all your data in a single clock domain after configuring the ALU string.

4) https://github.com/SpinalHDL/VexRiscv

I really like Chisel HDL or any other new HDL languages like SpinalHDL or migen b/c it allows you to create some very complex yet modular designs. See VexRiscv or LiteX for instance. Languages like this exist b/c there is a need for it, but I wouldn't say that you should learn these new languages over verilog. All these languages output verilog/VHDL for now, but there is work being to done eliminate the need for outputting verilog; eventually, Chisel will output an open source CIRCT IR. Hope is to get EDA vendors to support this IR which I'm sure will take a while. For now, you should definitely learn Verilog or VHDL before Chisel.

I'd recommend giving vexriscv a look. It'll handily fit on your FPGA, leaving plants of room for I2C, VGA output, and whatever multiplication you end up wanting to do. It's very easy to get set up, and their example "briey" SOC even has VGA output already, but not hardware I2C (though you could easily bitbang it with the core). Adding in I2C via a "plugin" should be trivial.

> 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.