General > General Technical Chat
RISC-V Technology Conference: Nerds Talking to Nerds About RISC V
<< < (3/5) > >>
anotherlin:

--- Quote from: SiliconWizard on April 17, 2023, 08:03:10 pm ---Was it ever planned?
You can design a very small core with RV32E already.
Not sure anything 16-bit was ever planned for RISC-V, would be curious to know more.

--- End quote ---

I just thought I heard it somewhere, but now, I just can't remember where.
So may be you're right, it may never have been planned.

That being said, RV32E can be small enough, but it still "fully featured", basically a general purpose CPU.
I was rather thinking, something smaller, in the class to compete with the PIC18 and AVR alike.
32-bit registers are just overkill
tom66:

--- Quote from: anotherlin on April 19, 2023, 09:08:42 am ---I just thought I heard it somewhere, but now, I just can't remember where.
So may be you're right, it may never have been planned.

That being said, RV32E can be small enough, but it still "fully featured", basically a general purpose CPU.
I was rather thinking, something smaller, in the class to compete with the PIC18 and AVR alike.
32-bit registers are just overkill

--- End quote ---

Having spent some time with Cortex-M0 and PIC32's M4K core, I see a lot of advantages of having 32-bit word width.  For instance, when doing fixed point math, it can significantly improve the resolution that can be computed -- this is especially useful if the core features a 32x32-bit multiplier.  Or, when interacting with peripherals since you can fit more settings in each register on the peripheral, configuring peripherals often takes less code space and/or more complex functions are possible without filling the memory space with lots of registers requiring complex paging (as used on 8-bit and some 16-bit processors.)

Additionally, the cost of some larger registers and ALU, buses, etc. are pretty minimal compared to the area of the die required for things like I/O pads, flash and RAM memory and non-CPU peripherals like timer units.

Ultimately, is there a significant saving in die area to justify the added complexity of having a 16-bit core too?  Would a lot of concerns not be met by just having the Arm-equivalent of Thumb where instructions are mostly 16-bit with occasional 32-bit long instructions for less frequently used operations?  It's already possible to have a 'Thumb'-like operation in RV32E, with the 'compressed' ISA extension.
SiliconWizard:

--- Quote from: anotherlin on April 19, 2023, 09:08:42 am ---
--- Quote from: SiliconWizard on April 17, 2023, 08:03:10 pm ---Was it ever planned?
You can design a very small core with RV32E already.
Not sure anything 16-bit was ever planned for RISC-V, would be curious to know more.

--- End quote ---

I just thought I heard it somewhere, but now, I just can't remember where.
So may be you're right, it may never have been planned.

That being said, RV32E can be small enough, but it still "fully featured", basically a general purpose CPU.
I was rather thinking, something smaller, in the class to compete with the PIC18 and AVR alike.
32-bit registers are just overkill

--- End quote ---

RV32E - the base ISA with no extension at all - is pretty barebones. You can hardly make it simpler than it is - or you'd get something really crippled.

As to the register size itself, I think it's in most cases, using modern process nodes, an almost absolutely irrelevant point, except possibly in extremely niche applications.
The silicon area a basic in-order RV32E core will take on a reasonably recent process node is very small compared to anything required around it to make something functional (peripherals, memory, and pads.) There would be little benefit for going 16-bit in practice. Unless maybe you were designing either a multi-core CPU with MANY such cores, or you were designing an ultra-small IC with maybe just a few hundred bytes of memory and a few pads, maybe something to run a very basic watch, or something.

And that was for the physical aspect of things. Now with the ISA: going 16-bit would imply going for a 16-bit address space, which is itself very limited by modern standards even for small stuff.
A "RV16" ISA with larger than 16-bit addressing would completely break the RISC-V ISA model.

But you can feel free to take this as an exercise. Take the RISC-V specs, define XLEN=16, discard all 32-bit base instructions and only keep 16-bit instructions from the C extension, and see how far you can go. Haven't thought it through. Maybe it's trivial. Maybe some things would be severely missing.
anotherlin:

--- Quote from: tom66 on April 19, 2023, 06:50:47 pm ---Having spent some time with Cortex-M0 and PIC32's M4K core, I see a lot of advantages of having 32-bit word width.  For instance, when doing fixed point math, it can significantly improve the resolution that can be computed -- this is especially useful if the core features a 32x32-bit multiplier... 

--- End quote ---

The use case you are describing is exactly why you should definitely go for an ARM M0, PIC32, or RV32. Doing 32-bit fixed-point math is rather what a full featured CPU would do.

I was rather thinking about a microcontroller doing basic "housekeeping", handling user interface (no high speed I/O). What can be handled by 8-bit registers doing carry additions for 32-bit value, and loops for multiplication.


--- Quote ---Ultimately, is there a significant saving in die area to justify the added complexity of having a 16-bit core too?

--- End quote ---

Yes, I agree with you. The other answer by SiliconWizard convinces me. With today's technologies, there's probably not much to be gained by reducing to 16-bit.
anotherlin:

--- Quote from: SiliconWizard on April 19, 2023, 08:29:15 pm ---As to the register size itself, I think it's in most cases, using modern process nodes, an almost absolutely irrelevant point, except possibly in extremely niche applications.
...

[...] or you were designing an ultra-small IC with maybe just a few hundred bytes of memory and a few pads, maybe something to run a very basic watch, or something.

--- End quote ---

You guys convinced me :)  I agree with you that with modern processes, not much saving can probably be achieved.
But yes, I was really thinking something very low-area, low-power. Basically replacing what microcontrollers (8051) do.

Maybe as a drop-in microcontroller to include on a FPGA. Bigger ones (Artix7 may even be considered a small one today), feature DSP primitives (adder and multiplier) which help implementation of ALU, and some even have embedded ARM cores.
But my guess, a RV32E would still eat quite some resources on something smaller like a Lattice's ICE40.


--- Quote ---But you can feel free to take this as an exercise. Take the RISC-V specs, define XLEN=16, discard all 32-bit base instructions and only keep 16-bit instructions from the C extension, and see how far you can go. Haven't thought it through. Maybe it's trivial. Maybe some things would be severely missing.

--- End quote ---

The whole point of RISC-V is that it is a standard. There is not much point to creating a 16-bit extension just for fun or for the sake of exercise. But yes, using/permitting only 16-bit encoding for instructions, while keeping 32-bit RV32E instructions, would achieve something like what a 16/32 Motorolla 68000 does. I'll find some time and dig into the Risc-V spec to see if that's possible.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod