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

--- Quote from: anotherlin on April 19, 2023, 09:36:31 pm ---
--- 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.

--- End quote ---

I think that these cases are perfect for 8-bit processors.  AVR8 for instance is a very nice 8-bit architecture (sadly, the 8-bit PIC architecture in comparison, is HORRID).  If all you are doing is very basic function control yes you probably do not need a 32-bit processor.  And for the sub 10-cent "bigclivedotcom made-in-China tat controller" they are perfect.  A 16-bit controller as a stepping stone once made sense, I spent quite some time playing with MSP430 and PIC24 and the dsPIC33F derivative.  But I think it's rapidly lost favour with Cortex-M0 winning that battle.  We just replaced the last PIC24 in one of our products, and it seems Microchip don't want to invest much more in them anymore either. They've also been amongst the hardest components to source during the shortage we had last year, though that may have just been bad luck.
eti:
Skip the sleeping tablets, this will save insomniacs a FORTUNE! 🤣🤣
anotherlin:
So I've taken a quick look at RISC-V's spec.

It should be possible to use only the "C" extension 16-bit encoding. All ALU functions are available, ADD, SUB, AND, OR, XOR, various shifts, along with load/store, and branching. There would be limitations for offsets, but nothing that can't be addressed (no pun intended) by using multiple/indirect loads. The other big issue is that we would be limited to 8 registers, notably the ALU instructions can access only 8 registers. However, x86 long lived with only 7 (user visible) general purpose registers.

The 2 big issues are rather that it would be 1) non standard (RV32E mandates 16 registers, we would be limited to 8 here). And 2) the compilers would have to be modified to generate that non-standard 8 registers limited 16-bit C encodings. So, not trivial, but no huge difficulties.

The big question would be: is it worth it?

As already mentioned, with current silicon technologies, probably not (compared to RV32E we would "only" save 8x32-bit regs area + the 32-bit instruction decoder area).
As an old timer (Zilog Z80 or 6502 8-bit CPU + 64K RAM), I always find it weird to have 32-bit registers for "modern" microcontrollers: https://www.silabs.com/mcu/32-bit-microcontrollers/efm32-zero-gecko (ARM M0+ with 4K RAM and 32K ROM (flash)). In fact, there is already one such RISC-V processor with internal 16-bit datapath, named RV16: https://link.springer.com/article/10.1007/s11390-022-0910-x (the pdf is freely viewable on chinese institute which designed the chip).

My guess is that a clean sheet design looking for the absolute minimum in power consumption and area, that should be considered.
Otherwise, the "niche" of integrated small microcontroller for FPGAs, is probably the best target. In fact, there's already such a proof of concept: https://github.com/AntonMause/rv16poc

 
TomS_:

--- Quote from: asmi on April 14, 2023, 08:10:16 pm ---I'm not really interested in listening about RISC-V anymore, what I want to is to have actual devices in my hands which I can play with and build something. And I don't mean puny microconrollers, but more like high-performance Linux-capable ones which are priced comparable with competing ARM devices, say iMX 8 SoCs. I don't really care much about peripherals - my ideal device would only expose DDRx memory controller, a PCI Express root complex with say 16 lanes and some sort of boot device interface (like QSPI flash for BIOS/UEFI). And so far I'm not aware of any.

--- End quote ---

I dont know if any of them meet your exact specs, but check out Explaining Computers on YouTube. He does a yearly run down of RISC-V based SBCs, and there are certainly some Linux capable SBCs out there.
asmi:

--- Quote from: TomS_ on April 20, 2023, 05:22:04 pm ---I dont know if any of them meet your exact specs, but check out Explaining Computers on YouTube. He does a yearly run down of RISC-V based SBCs, and there are certainly some Linux capable SBCs out there.

--- End quote ---
I want chips, not SBC boards. I like designing stuff myself.
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