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

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod