RISC-V Technology Conference: Nerds Talking to Nerds About RISC V - Page 1
Forum section: electronics / general

author: MT
author_rank: Super Contributor
timestamp: April 14, 2023, 07:17:19 pm
content: Day1...

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 14, 2023, 07:56:33 pm
content: Yeah I've sumbled upon this video already, couldn't watch much more than a few minutes with a lot of fast forward. Dunno about you guys.Surely not the most interesting conference I've seen about RISC-V.

author: asmi
author_rank: Super Contributor
timestamp: April 14, 2023, 08:10:16 pm
content: 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.

author: MT
author_rank: Super Contributor
timestamp: April 14, 2023, 08:31:49 pm
content: Quote from: SiliconWizard on April 14, 2023, 07:56:33 pmCome on now, if you know about Risc V stuff out there just share it, be positive!

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 14, 2023, 08:47:37 pm
content: I think I've been talking about RISC-V stuff quite a bit all in all.Have you actually watched this video entirely, and if so could you tell us what part you particularly found interesting?

author: tom66
author_rank: Super Contributor
timestamp: April 14, 2023, 09:14:02 pm
content: Quote from: asmi on April 14, 2023, 08:10:16 pmI'm most excited about getting to play with this device...https://www.microchip.com/en-us/products/fpgas-and-plds/system-on-chip-fpgas/polarfire-soc-fpgasIt looks like it could be a good competitor for Zynq-7000, but with five computing cores (one quad complex plus one real time complex) at 600MHz.It's a shame Microchip's FPGA tools are so dire, but I might be able to manage. Been looking for a lower power alternative to the Zynq for some time.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 14, 2023, 09:34:35 pm
content: Microchip acquired Microsemi (ex-Actel) FPGA division and the Actel/Microsemi tools were pretty horrific (IMO.)Haven't looked recently, so don't know whether Microchip has improved anything with that yet or not. I guess not.

author: asmi
author_rank: Super Contributor
timestamp: April 14, 2023, 10:38:40 pm
content: Quote from: SiliconWizard on April 14, 2023, 09:34:35 pmHas Microchip ever improved anything?

author: anotherlin
author_rank: Frequent Contributor
timestamp: April 17, 2023, 12:40:44 pm
content: Any news about a proposed RV16E (super small 16-bit RISC-V for embedded)?That would be super useful for anything requiring a small control processor.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 17, 2023, 08:03:10 pm
content: Quote from: anotherlin on April 17, 2023, 12:40:44 pmWas 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.

author: anotherlin
author_rank: Frequent Contributor
timestamp: April 19, 2023, 09:08:42 am
content: Quote from: SiliconWizard on April 17, 2023, 08:03:10 pmI 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

author: tom66
author_rank: Super Contributor
timestamp: April 19, 2023, 06:50:47 pm
content: Quote from: anotherlin on April 19, 2023, 09:08:42 amHaving 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 19, 2023, 08:29:15 pm
content: Quote from: anotherlin on April 19, 2023, 09:08:42 amRV32E - 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.

author: anotherlin
author_rank: Frequent Contributor
timestamp: April 19, 2023, 09:36:31 pm
content: Quote from: tom66 on April 19, 2023, 06:50:47 pmThe 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.QuoteYes, 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.

author: anotherlin
author_rank: Frequent Contributor
timestamp: April 19, 2023, 09:56:24 pm
content: Quote from: SiliconWizard on April 19, 2023, 08:29:15 pmYou guys convinced meI 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.QuoteThe 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.

author: tom66
author_rank: Super Contributor
timestamp: April 19, 2023, 09:57:23 pm
content: Quote from: anotherlin on April 19, 2023, 09:36:31 pmI 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.

author: eti
author_rank: Super Contributor
timestamp: April 20, 2023, 03:16:26 am
content: Skip the sleeping tablets, this will save insomniacs a FORTUNE! 🤣🤣

author: anotherlin
author_rank: Frequent Contributor
timestamp: April 20, 2023, 11:15:41 am
content: 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

author: TomS_
author_rank: Frequent Contributor
timestamp: April 20, 2023, 05:22:04 pm
content: Quote from: asmi on April 14, 2023, 08:10:16 pmI 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.

author: asmi
author_rank: Super Contributor
timestamp: April 20, 2023, 06:16:17 pm
content: Quote from: TomS_ on April 20, 2023, 05:22:04 pmI want chips, not SBC boards. I like designing stuff myself.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 20, 2023, 07:43:41 pm
content: Quote from: anotherlin on April 20, 2023, 11:15:41 amSo, you did it!Quote from: anotherlin on April 20, 2023, 11:15:41 amProbably not. As you mentioned, the big plus of RISC-V it its specs and the traction it got - so you have high-quality toolchains for it.If you're deriving something from RISC-V that is not RISC-V, you'll lose most of this, and while the RISC-V ISA itself is pretty sane, I don't think it would make the best basis for a 16-bit architecture.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 20, 2023, 08:27:54 pm
content: Quote from: asmi on April 20, 2023, 06:16:17 pmAt the moment, I personally don't much care for neither chips nor SBC boards, as, just as a fact, available ARM-based solutions are just better at this point both in terms of performance and power consumption.Now I like having alternatives, and the future probably holds a lot of cool stuff for RISC-V, but right now, not particularly interested in off-the-shelf solutions.But "designing stuff" is precisely what got me interested in RISC-V actually. RISC-V has made it easy to design your own CPUs with a decent ISA, while having access to quality toolchains for free.So, that's the part I've been interested in.

author: anotherlin
author_rank: Frequent Contributor
timestamp: April 24, 2023, 12:06:06 am
content: Quote from: SiliconWizard on April 20, 2023, 07:43:41 pmNo, I did not. In retrospect, it's just that I start getting oldand couldn't envision a microcontroller or low power embedded CPU, as something 32-bit.There's most probably already quite some work done targeting ultra-low power/battery powered, super efficient, microcontroller class type of implementation. One example was the RV32E with internal 16-bit datapath designed in China.In fact, there's a proposal (https://github.com/riscv/riscv-code-size-reduction) regarding code reduction which is well on its way to become ratified as standard. It does not intend to provide an extension with all instructions being 16-bit, but rather just have more compact code. Which can be beneficial even to huge high-performance RV64 CPU with vector extension (code cache is still a scarce and valuable resource).It's just that we probably don't get as much as presentation of ucontroller types of implementations. Maybe less "sexy" than high performance ones. With RISC-V's well designed and very clean architecture, I'm pretty much sure we can obtain something even more efficient than ARM M0.