RV32E configuration

[troibe]

Hi Olof,
Thanks for creating serv.
It's the smallest RISC-V CPU I could find so far.
Small enough that it almost fits on the Speed Tang Nano. (It's just off by 100 or so LUTs.)
I saw that you posted on the RISC-V forums about RV32E for serv. Therefore I was just curious whether you implemented such a configuration.
If not I would be happy to add it if you provide me with some pointers.
I'm using the CPU with LiteX so there is probably some room to save a few LUTs there as well. (Without UART the SoC would fit but that wouldn't be too useful of a system😂).
Best wishes
Martin

[olofk]

Hi Martin,

Thanks for reaching out. I'm hoping to see an RV32E option but it hasn't been a priority. The major reason is that it would at most only shave of a handful LUTs so I haven't felt it's worth the extra testing.

I did some experiments with the Gowin devices and IIRC I managed to fit 2-4 SERV cores in that device so it should be plenty of room. I do think it's the Litex infrastructure taking up most of the space. In Servant, the reference SoC for SERV, I actually don't use an UART and instead bitbang a GPIO pin to implement a UART. Unfortunately there aren't any official ports of Servant to Gowin devices, mainly because there isn't a Gowin backend in Edalize so we can't easily build it.

Don't know if Litex offers a bitbang UART option but it should probably do a lot more than making SERV RV32E

[troibe]

I didn't realise how many corners SERV already cuts compared to LiteX.
Now that I read up more on it I think probably it would be an interesting idea consider getting Servant running on Gowin.

My idea for this project was basically to have a cheap, beginner friendly SoC with a RISC-V CPU to demonstrate how accessible computer architecture has become.
LiteX has really delivered on the simplicity side so I'm curious to see how fusesoc+servant compares.
Do you have good pointers on getting started for someone like me that knows LiteX pretty well?

I'll also look into cutting down UART or other components that LiteX generates.
However so far what Florent has told me is that size has not been as core of a concern for LiteX.

[gregdavill]

I was thinking about this recently when packing serv into the GF180 MPW0. On FPGA targets the removal of 16*32bit registers isn't huge, typically because both configurations fit in the same BRAM blocks.
But on an ASIC target the savings are bigger, especially if using DFF based RAM.

[olofk]

I have thought about RV32E as well, but I think there's another way that can save even more memory, namely by memory-mapping the RF. We already do this in Subservient and the Serving SoClet. This alone saves us quite a bit of overhead by only needing one SRAM instead of two. But there's an added benefit in that we can also reclaim any unused registers as memory. Compiling as rv32e automatically gives us 1632 bits of extra RAM and if we have a program that only use the first four registers, we can use the remaining 3228 bytes as data/program memory.

I actually proposed a new extension, tentatively called Zrfinram, at the RISC-V Summit last month. You can find the video here https://award-winning.me/serv-32-bit-is-the-new-8-bit/ We don't really need a special extension for hand-coded assembly programs, but perhaps the compiler/linker could do analyze which regs that are actually never used, shuffle around some regs and do other clever stuff