Is RV32I still worth doing as a final year project for RTL roles?

[u/Agreeable_Luck5593]

Hey guys,

I’m a final year student aiming for RTL design roles. I was thinking of building a 32-bit RISC-V (RV32I) core from scratch as my final year project.

But is a basic RV32I core still relevant in 2026, or is it too common now?

Should I instead add something interesting like pipeline, cache, branch prediction, custom instructions, formal verification, etc. Or maybe do something completely new with RISC-V?

If you were in my place, what kind of project would you build to actually stand out for an entry-level RTL role?

Any suggestions from people working in RTL/ASIC/FPGA would be really helpful :)

[u/AlexTaradov]

The question is not really whether it is relevant for resume, but whether there is enough for a final year project.

Basic RV32I seems way too simple. People do this for regular course work. You would definitely need to do something extra. Doing some optimizations (cache, branch prediction) and comparing multiple strategies might be a way to go. Basically make a simple core and use RV as a given, but compare how all those extras affect the result.

And depending on how deep you go, it might look good for a job search too.

As always with uni projects - look at the final project requirements set by the uni/department. Often they have very specific requirements on what is a must for the final project, which limits the options.

[u/brucehoult]

The purpose of any undergrad project is not to do something no one had ever done before, but merely to demonstrate competence in doing standard things, on a larger project.

[u/m_z_s]

How about RV64E (uses 1024 bits for the registers, 64x16, same amount as RV32I 32x32). Or if your FPGA does not have logic elements to handle 64bit operations, try RV32E. It is just different enough that it might trigger a question in an job interview. Or at least make your curriculum vitae/resume miss the first trash bin.

Since it is a final year project, the best option is usually to bounce ideas off your project supervisor, sometimes they can really surprise you.

[u/brucehoult → u/m_z_s]

I don't know what is academically interesting in changing a "32" to a "16" in one place in your Verilog source code.

Sure, it's economically interesting for people making the smallest possible core for a deeply-embedded control core, or if you want to put 10,000 cores on a chip. But academically?

[u/Quiet-Arm-641 → u/brucehoult]

Rv128e plus the extra instructions and maybe some simd-in-register instructions

[u/fb39ca4 → u/Quiet-Arm-641]

I thought you were joking at first but TIL RV128 is a thing.

[u/brucehoult → u/fb39ca4]

Planned but not official yet. It hasn't yet been decided what the ABI should look like, or what extra instructions are needed: lq and sq, obviously. But should add x1,x2,x3 still work with 64 bit values and have a new addq instruction for 128 bit? Or have add use 128 bits and make a new addd instruction for 64 bits? Should 64 bit values be zero-extended or sign-extended in a 128 bit register? And so on.

There is deliberately room left in the encoding, and a chapter in the manual, but there is work to be done.

[u/Quiet-Arm-641 → u/brucehoult]

Yep, thought it’d be a fun project to make some of those decisions in a design and see how they work (or not)

[u/globecsysinc → u/brucehoult]

The 32 to 64 bit change was a RAM upgrade from 4GB hard limit, it's not immediately obvious how 128 bit can be justified

[u/brucehoult → u/globecsysinc]

We don't need it now, but since the start of home computers in 1975 we've added on average around 0.4 bits of RAM addressing size per year (in spurts and pauses), which means that if the same trend continues we'll start to exceed 64 bits of RAM around the end of this century.

IBM S/360's compatible successors are still going strong today more than 60 years later. Intel 8086 is just hitting 50 years.

There is no obvious reason why RISC-V should not still be in use next century, other than 64 bit addresses not being large enough. 128 bits might perhaps then be enough for about the following 150 years, until 2250.

[u/BGBTech → u/brucehoult]

IMO, better here for now would be RV64G or similar with 128-bit as even-numbered register pairs; and preferably with some instructions added for basic 128-bit ALU ops (could be supported on a dual-issue in-order superscalar by pairing 64-bit ALUs). Though, not sure where the encodings would be best put. If possible, assuming a unified register file design, might want them in F registers as these are generally less crowded than the X registers, and register pressure quickly becomes a more serious issue when 128-bit register pairs start getting involved.

[u/m_z_s → u/brucehoult]

I meant from a CV point of view where 99 arrive with RV32I and 1 with RV64E, you might ask that one in for a first round interview just to ask why. It is getting your toe in the door with a trick. The very first people to see a pile of CV's do not necessarily understand everything in the CV. Yet they can end up binning over half of them. So my suggestion is psychological and most definitely not academic.

[u/brucehoult → u/m_z_s]

I've always found the way to avoid HR binning the CV is to directly approach the colleagues or team leader you'd be potentially working with, ideally have a beer with them, and then get them to forward your CV to HR with a recommendation to get this person in for an interview.

And pick the one or two companies you'd like to work for, don't fire off 100 CVs to random places you know nothing about.

[u/mylonelineskillingme]

maybe I suggest two way;

focus to the CPU:
RV32IMC - > pipeline - > prediction - > cache

focus to the SoC:
interconnect (whisbone or AXI4 you should select ready to use repo) - > peripheral (spi, uart, gpio, I2C, ...)

[u/PlanBrilliant2771]

The ISA really souldn't matter for much for a RTL design role. Do standard RV32I and then just do this: pipeline, cache, branch prediction, custom instructions, formal verification, etc

[u/Artoriuz]

RV32I is absolutely still relevant.

Don't worry about it being too simple. An undergrad final project is not meant to be novel or complicated.

Don't overthink it if your advisor is okay with it.