return to table of content

Nordic is getting involved in RISC-V

xadhominemx
77 replies
3d2h

Nordic is a very high volume supplier of BT chips for consumer applications, but is getting crushed by a wave of very low cost Chinese competitors. Among the western chip companies, they are the ideal candidate for RISC-V adoption. I'm very curious to see what TI is planning for RISC-V as they begin to seriously engage in the low cost general purpose microcontroller market for the first time.

audunw
34 replies
3d2h

"getting crushed by a wave of very low cost Chinese competitors"

That's an odd way of spelling "maintaining a stable market share in the face of Chinese competition".

Going forward, IoT security is going to be an increasingly important factor for new designs. The EU is quite serious about combating security problems with IoT devices. And security is something that the new products coming out of Nordic is very serious about.

I don't think many big, serious device manufacturers are willing to risk being the target of the first catastrophic IoT attack just to save some pennies on a dirt cheap Chinese design, with some poorly verified RISC-V core thrown in with a power hungry Bluetooth radio.

ARM TrustZone is not something the RISC-V ecosystem has a clear standardized answer to yet. So I think that's a reason why ARM will keep its role as the main application processor in high-end BT/Thread chips for the next several years.

graphe
14 replies
3d1h

Every IoT device already uses esp chips, that's the only reason they can afford to make them. Them being low security doesn't matter, it's not like smart homes are secure now. Security is not important to IoT devices.

jLaForest
10 replies
3d1h
graphe
8 replies
3d1h

It is up to the manufacturer to implement it, most esp devices like 8266 and 32 have weak security firmware, are easily hackable (benefit to me). Most don't have security in mind and don't get security updates.

connicpu
7 replies
3d

The new ESP32 models coming out, especially the RISC-V models, all have security features like Flash encryption and hardware cryptography modules. Unfortunate for those who like to reflash consumer devices.

sitkack
6 replies
2d21h

The chips themselves are $1 qty 1. Remove the old chip, put your unlocked chip in its place.

baq
2 replies
2d20h

how much is the soldering station to do that?

stagger87
1 replies
2d20h

$100 and a steady hand :)

connicpu
0 replies
2d

I got a cheap hot air station from amazon for only $40, works quite well! Maybe another $10 for solder wire and $10 for flux and you're good to go

IshKebab
2 replies
2d21h

It's beyond most people's ability, equipment and effort threshold to order 1 chip from digikey (how much is delivery on that $1?) and replace a QFN package.

sitkack
0 replies
2d12h

Most people aren't going to be tearing down consumer goods and reflashing the firmware.

If someone wants to get a hot air station and a bunch of $1 chips and reprogram their own devices, it would cost them less than a hundred dollars, 150 tops.

Anyone can learn any skill. If you can draw anything recognizable, you can do electronics.

AussieWog93
0 replies
2d20h

how much is delivery on that $1?

From AliExpress, it'd probably be $2-$3 including shipping.

They don't ask questions when ordering large volumes of microcontrollers either.

SV_BubbleTime
0 replies
3d1h

The chances that the popular wireless chip subsidized heavily by the CCP doesnothave a backdoor somewhere are too low to consider seriously.

They are popular only because they are so cheap. Also, so far as chip shortage, China kept pumping them out.

antoniuschan99
1 replies
3d1h

That's not true anymore. There was a shift to Beken Chips a year or two ago so a lot of your Amazon WiFi iot stuff uses that now (Tuya and Tasmota). Check out OpenBeken. I can't find much info on it but thinking it's cheaper than esp's probably more similar to esp8266 than esp32. Espressif chips are much more secure nowadays compared to the esp8266 days.

graphe
0 replies
2d23h

The beken ones don't have cheap Dev boards but I heard they are better sometimes. I don't know if they're better but DIY for them isn't so far.

I don't think security is a real problem for me. Smart devices on their own intranet takes away a lot of problems.

kees99
0 replies
3d1h

Notevery...

Ikea, for example, ships tons of "smart lightbulbs" with silabs/EFR32.

josephcsible
9 replies
3d

Isn't TrustZone inherently evil, though? Isn't its main use to let the megacorps trust that your device won't do what you want and will keep secrets from you?

KerrAvon
5 replies
3d

I can't tell if this is sarcasm. TrustZone is a technology for resource isolation. At an extremely high nontechnical level, it's conceptually similar to memory protection.

josephcsible
4 replies
2d23h

The problem with TrustZone is that control of it always resides with a megacorp and never with the owner of the device. It's not that it isn't security at all, but rather that it's security against the owner.

msgilligan
3 replies
2d20h

The owner can control Trustzone if the device is shipped with unfused OTP registers.

On Raspberry Pi for example, you can write the hash of your own public key to locations 47-54 of the OTP memory block:

https://www.raspberrypi.com/documentation/computers/raspberr...

Here's the QuickStart for the entire process:https://github.com/raspberrypi/usbboot/blob/master/secure-bo...

Note that the Raspberry Pi does not have a full TrustZone implementation to protect secure mode memory, etc. But it is a widely available device with good documentation and allows developers to experiment with and learn about the basics of TrustZone architecture.

josephcsible
2 replies
2d20h

OTP and e-fuses are also evil. Devices should never be forced to become e-waste over them being set "wrong". There should always be a factory reset option that clears everything.

PennRobotics
1 replies
2d19h

How do you propose patching security vulnerabilities in deployed devices?

AnthonyMouse
0 replies
2d18h

Why would that require fuses? You store the firmware in flash, which can be updated to a newer version, restored to the original version or replaced entirely with third party firmware by the device's owner if the OEM fails to patch it, e.g. because they go out of business.

tremon
0 replies
2d17h

TrustZone doesn't run on a separate processor like the x86 TPM. It's more like a hypervisor-level ring fence than a coprocessor.

sweetjuly
0 replies
2d21h

What are you talking about? TrustZone is an ISA feature which lets you mark certain pages as "secure only". Compliant devices with SMMUs should not allow any access to these pages except when initiated by the secure world. It's not some big evil plan by Arm. It's up to vendors how they use it. Many just use it for key storage and verifying biometric data so that even a compromised kernel can't trivially steal the most sensitive data on a device.

If you start building your own hardware and/or buy devices with unlocked bootloaders, you can load whatever you want in EL3 to play with TZ. This isn't a problem with TZ.

msgilligan
0 replies
2d20h

This shouldn't be downvoted. It is a legitimate question and widely held misconception that is addressed in several of the responses to parent.

paulgerhardt
6 replies
3d1h

Having bought a few hundred thousand Nordic chips I can assure you they don’t care about security in a meaningful sense.

All Nordic chips are susceptible to bootloader attacks which make them a poor choice for storing key material. This can be mitigated in the design phase by adding an external security chip like a ATECC608B but if you were to tear down a device and see a board present without this module it certainly will have other vulnerabilities too.

Having worked extensively with both Nordic and Chinese chips, what makes Nordic win is the ease of development - they are by far the best in market when it comes to programmability. Hands down.

The security problems have been known since the NRF51 and despite that those vulnerabilities were carried over into the NRF52 because the cost of validation of chip designs is so prohibitive they did not want to touch it and filed the “oh some random person can extract the entire contents of the chip” bug as “won’t fix”. They are baked into a silicon ip core and can’t be fixed with a software update.

As for RISC-V, there are some amazingly innovative and brilliant alternatives to TrustZone presented at the conference but I suspect Rambus may block innovation here using their position on the board (and chairing the security standing committee) in favor of their own (patented) solutions using an embrace, extend, extinguish strategy.

5ADBEEF
2 replies
3d

The famous APProtect bug was patched in a silicon rev IIRC. Unless you're thinking of another exploit

MrQuincle
1 replies
2d23h

Through voltage glitching isn't it? Which rev protects against it? Must be quite new.

5ADBEEF
0 replies
2d20h

Yes, this fix was mentioned in IN-142 from Nordic.

zh3
0 replies
2d19h

The security issues also cause inconvenience, e.g. the later revisions of the nrf52 needing either a recover operation or updated firmware (the hack of flashing a default bootloader in recovery mode that disables security is...interesting).

That aside, Nordic still seems the best choice out there though quite a lot of features are leveraging the ARM ecosystem. RISC-V involvement is possibly toe in the water stuff/de-risking from ARM ("who owns them today?"). The recent big switch in SDK's (nrfSDK to Zephyr) wasn't teribly welcome, so the possiblility of another one is not welcome (if there was an approximately equal competitor with more stability we'd jump ship).

snvzz
0 replies
2d3h

I suspect Rambus may block innovation here using their position on the board (and chairing the security standing committee) in favor of their own (patented) solutions using an embrace, extend, extinguish strategy.

RISC-V members have to sign an agreement when they join, which has clauses to prevent this sort of situation.

AussieWog93
0 replies
2d20h

Having worked extensively with both Nordic and Chinese chips, what makes Nordic win is the ease of development

This seems to be the norm for Chinese chips in general.

Poor documentation, even in the native Chinese, no official dev boards, sometimes no JTAG debuggers, random bugs, just a whole lot of bullshit to deal with as a foreign developer.

I suspect it might be a cultural thing; developers are less prone to pouring over data sheets and more prone to asking their friends/colleagues to introduce them to someone who works at one of the microcontroller companies. (This is just a hunch, and I could be completely wrong.)

weinzierl
0 replies
2d23h

"I don't think many big, serious device manufacturers are willing to risk being the target of the first catastrophic IoT attack [..]"

You must be kidding, right? It's not that they would have cared much in the past. Now, I would be the first to celebrate a change in that regard, but it's just not the world we live in now.

AnthonyMouse
0 replies
2d18h

I don't think many big, serious device manufacturers are willing to risk being the target of the first catastrophic IoT attack just to save some pennies on a dirt cheap Chinese design, with some poorly verified RISC-V core thrown in with a power hungry Bluetooth radio.

The small budget OEMs will save some pennies on a dirt cheap Chinese design. The big, serious device manufacturers will do the design themselves by starting with an open reference design and making some minor modifications that suit them, then pay someone to fab it because they're shipping millions of units. Who does that even leave?

ARM TrustZone is not something the RISC-V ecosystem has a clear standardized answer to yet.

This has almost nothing to do with IoT security, if not being directly opposed to it as a thing used to prevent people from installing custom firmware on devices the OEM fails to support.

The #1 problem in IoT security is OEMs that release a device which they neither patch nor allow anyone else to patch. And the first can't be a solution for small OEMs because they go out of business, so the only way to actually fix it is to have devices that users can update with third party firmware. For which the lack of ARM TrustZone is anadvantage, since it's often used to prevent this.

ahartmetz
23 replies
3d2h

is getting crushed by a wave of very low cost Chinese competitors

Oh lordy. Bluetooth is about to get even worse? AFAIK, Nordic's harwdare and software are among the few high quality Bluetooth stacks.

0xDEF
20 replies
3d2h

Maybe the quality of the Chinese competitors is/was worse but ESP32 and its predecessor have completely taken over the cheap BLE/WiFi segment by simply flooding hobbyists and students with ultra-cheap devkits.

Maybe something the Western competitors should learn from.

fullstop
14 replies
3d2h

You can get started with esp32 for $5. Nordic devkits are more expensive, and going past that requires a JTAG programmer, which is an expensive option for hobbyists and students.

It's not surprising that they have taken off like they have. Initially it was because it was inexpensive, but now the community is huge and that is a very attractive selling point.

audunw
6 replies
3d1h

You can get a BBC micro:bit with Nordic SoC for $15 Not exactly $5, but not very expensive either There's also a decent growing community around them

You've also got the nRF52 USB dongle which seems similar to those cheaper ESP32 kits, for around $10.

and going past that requires a JTAG programmer

No, the official Nordic devkits comes with a built-in debugger. Same for micro:bit. It's just plain USB.

That said, I do think Nordic could be better at penetrating the hobbyist/student market. I think one problem is the lack of a combined BT/WiFi chip.

I think once Zephyr becomes more mature and there's more tutorials/guides around it, a good BT+Thread+WiFi solution from Nordic could become very popular. Zephyr is a bit hard to get into, but incredibly powerful once you get used to it.

graphe
2 replies
3d1h

Where are the nRF52 usb dongles for $10?

nxa
1 replies
3d1h

Have you looked at Mouser or Digikey? $9.60 for per unit, in single unit quantities, heaps in stock as of today.

graphe
0 replies
3d1h

No, I usually get chips on AliExpress or eBay since I usually use esp32 for free shipping and they're $20 or more on there.

fullstop
2 replies
3d1h

No, the official Nordic devkits comes with a built-in debugger. Same for micro:bit. It's just plain USB.

Right, the devkits can do this. If you want to go past that, like making your own PCB with a NRF52 on it you need JTAG, which is not a requirement for esp32.

Maybe the NRF52 has some sort of ROM serial loader that I've missed though.

SwaraLink
1 replies
3d1h

It’s actually possible to use the debugger on the NRF dev kits to flash/debug custom PCBs with NRF chips. So a separate (more expensive) JTAG debugger is in fact not required.

m-ee
0 replies
2d22h

Yes nrf dev boards have an on board j-link, and Nordic provides instructions on how to turn the board into a programmer. Their licensing with segger explicitly allows this as long as you use it for other Nordic devices. Much cheaper than a standalone j-link.

lionpixel
2 replies
3d

For $9.90 you get a Seeed Xiao NRF52840[1] board with Arduino support. In sleep mode it consumes just 1µA. In my spare time I'm building smart locks with these that last for up to 2 years with a CR123 battery. Recently I switched from Arduino to the nrf Connect SDK and a tiny nrf52832 board that cost just 4$ on AliExpress. Works like a charm.

[1]https://www.seeedstudio.com/Seeed-XIAO-BLE-nRF52840-p-5201.h...

fullstop
1 replies
3d

Yeah, Nordic crushes it right now with their sleep mode. Espressif is making progress in that area, though, but they have a lot of ground to make up.

Out of curiosity, how do you flash the nrf52832 board?

lionpixel
0 replies
2d20h

With SWD and a Tag-Connect connector[1]. I watched someone on youtube recommend it due to the small space and low profile. You can use the VSCode NRF Connect SDK plugin (coupled with Jlink or NRF52 dev kit) to flash the device. But of course you can just use USB und copy a generated .hex file directly on the device. I use SWD because its faster to flash many boards by just pressing the pogo pins on the connector pad. Boom done. :)

[1]https://www.tag-connect.com/product/tc2030-ctx-nl-6-pin-no-l...

wallaBBB
0 replies
3d1h

GDB options for debugging/flashing can be had for sub 10eur, Segger is not mandatory. Moreover, the onboard Segger of the devkit can be used externally on Nordic MCUs in custom products and is covered by the licensing agreement between Nordic and Segger for this usecase.

usrusr
0 replies
3d

Isn't the JTAG programmer something you can run on any old arduino if you happen to have one lying around?

the__alchemist
0 replies
2d22h

ST-LinkV2s, including the $8USD clones, work on nRF. (StLink-V3 does not).

markrages
0 replies
2d22h

You can load Black Magic Probe firmware on a bluepill and have JTAG for about $2. I also ported it to nRF52840 if you have an extra dongle laying around. Or esp8266 for debugging over wifi (wireless JTAG is super useful sometimes.)

Segger has been really successful at marketing "JTAG == JLink" but it is just not true.

boesboes
3 replies
3d2h

Definitely! And make sure to sell to consumers too if you want to compete. Anecdotal, but I wanted to build a 3D printer, most parts are simply not available in the EU if you are normal person. Even stuff like hex-bolts and t-nuts are impossible to source in the EU outside of specialty webshops where the markup is 2000%.

And that was just the mechanical parts...

ihattendorf
2 replies
3d1h

Do you not have anything like Home Depot/Grainger/McMaster-Carr in the EU? A quick check shows 3/8"-16 T-Nuts are $10/10, $15/50, and $33/100 respectively, with the first two available within a 15 minute drive of my location in the US.

dvdkon
0 replies
3d

I don't know about any such EU-wide store.

The small local hardware store near me is great for common things like M3+ screws, but understandably doesn't stock slightly exotic items like M1.6 threaded inserts. There's larger e-shops that sell those, though I can't speak to the markup. Larger parts are generally easier to find.

Qwertious
0 replies
3d

I think the above comment is talking about domestically produced items?

audunw
0 replies
3d2h

Maybe something the Western competitors should learn from.

Back in the day our university was flooded with Atmel AVR kits.

I don't know about my university now, but many high schools now use BBC micro:bit kits, which uses Nordic Semi SoCs.

xadhominemx
0 replies
3d2h

I am not an engineer and have not dealt with the chinese suppliers directly, but my understanding is that their software, support, and documentation have gotten much better. And they are very very cheap because they use RISC-V and/or inexpensive Chinese alternatives to TSMC.

stefan_
0 replies
3d2h

They don't exactly make their own Bluetooth stack yet, e.g. the one chinese RISCV board I have seen used IP from RivieraWaves (made in France & Israel):

https://www.ceva-dsp.com/product/rivierawaves-bluetooth-plat...

At the end of the day, 2.4 GHz frontends can be done in the same silicon process that makes your SoC and the antenna needs to be nothing more than a PCB trace, so what on earth was going to save Nordic from competition?

fullstop
12 replies
3d2h

Unless things have changed recently, Nordic is still king of low power applications.

With that being said, I've worked with both the Nordic NRF SDK and the Espressif SDK and greatly preferred Espressif.

For doo-dads that I make for my home, esp32 and esp8266 are fantastic. The modules are inexpensive and the community is huge. I would not want to be in Nordic's shoes right now.

wallaBBB
9 replies
3d1h

There are actually 2 Nordic SDKs, nRF5 (now in maintenance, but still in many supported products in the field) and nRF Connect (bundled with Zephyr). Later gives a lot of access to both Host and Controller part of the stack and for commercial products that are not simply flipping a lightbulb it is still a standard. ESPs are good for quick hacks and more competitive with Nordic if low power is not an imperative.

fullstop
8 replies
3d1h

I've only used the nRF5 SDK. It worked, and it worked well, but it was cumbersome to work with if you didn't want to keep your code in the same tree as the the SDK itself. This was probably an organizational issue on my part, honestly.

The other thing which really bit me was someone here used a symbol name which collided with one used in the SDK, but the build system allowed this to link without error.

wallaBBB
4 replies
3d1h

nRF5 is indeed inferior SDK of the 2 (thus abandoned). Also I dislike that a big chunk of the stack there is a binary blob. Regarding the code organization, not sure what toolchain you used, but the latest recommendation for nRF5 (Segger studio) could make it fairly easy to do this, but manually opening the project config files and changing them, not through the GUI.

nRF Connect is a different world, comes with a lot more options, some really rooted in Zephyr OS, some lessons learned from the prior SDK. And if you're familiar with Linux build configuration system, that is basically what Zephyr brings to the table (comes from Linux foundation). But yeah all that flexibility comes as a penalty when you want simple stuff, compared to ESP32-Sx

fullstop
2 replies
3d1h

nRF5 is indeed inferior SDK of the 2 (thus abandoned). Also I dislike that a big chunk of the stack there is a binary blob. Regarding the code organization, not sure what toolchain you used, but the latest recommendation for nRF5 (Segger studio) could make it fairly easy to do this, but manually opening the project config files and changing them, not through the GUI.

Yes, I ended up editing the .emProject files by hand. It worked, but it felt like I was doing something wrong. I assume that you are referring to the soft device blob? Has that been abandoned in nRF Connect?

wallaBBB
0 replies
2d8h

I assume that you are referring to the soft device blob? Has that been abandoned in nRF Connect?

Quite, yes. They took the ZephyrOS approach, but it comes with a learning curve penalty, unless you go the easy route of nRF Connect GUI. In that case you do have some limitations of how you organize the code base (so that the GUI works), but even that is miles ahead in configuration compared with to the nRF5 SDK + Segger Studio.

Some skim reading material about it:https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/...

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/...

5ADBEEF
0 replies
3d

There is a Zephyr BLE stack that can be used as well as a SoftDevice stack but SoftDevice isn't a huge binary anymore, much more modular to save code space.

lgg
0 replies
2d20h

I have been out of this area for almost a decade now, but I have very fond memories of the nRF5 SDK. When I was evaluating the (then new) Nordic BLE SoC's for future products it was so much nicer than the TI CC2540 we had used in our first BLE device.

zh3
2 replies
2d19h

The simple hack is a softlink to the actual SDK.

On the other hand, checking in the whole SDK as part of a project gives an impressive LoC tally ;)

Link issue was possibly macro craziness? The scars of sdk_config.h etc.

fullstop
1 replies
2d19h

If you base your project off of one of the examples, the project file has relative paths back to the SDK. For example:

    <file file_name="../../../../../../components/libraries/log/src/nrf_log_backend_rtt.c" />
No amount of symlinking can fix this, and there's a lot of these files. Maybe copying an example project is not the right way to do things.

The link issue was, I think, the result of what Nordic does with weak symbols. I don't recall the symbol name, but it was something which caused very unusual results.

Regarding LoC tallies, I often try to minimize mine. :-)

zh3
0 replies
2d9h

If you're using segger, a quick find-and-replace will take care of that (ditto GCC Makefiles). Must admit that when I started with nrf52 SDK, I too used thge embed-the-application-inside-the-SDK approach. Pretty soon that got cumbersome, so I switched to the softlink approach. The exact approach is to store the SDK somewhere, create a softlink to it in the project directory and have the project files/makefiles use that instead.

freeopinion
1 replies
3d1h

It's easy for us hobbiests to forget that all the spare do-dads we have floating around our workbench aren't even a drop in the bucket compared to the number of chips bought by a single manufacturer for a single model of a kitchen blender.

We matter a little and can be somewhat of an indicator sometimes. Right up until we don't. A lot of times what matters to us just doesn't apply at scale.

StillBored
0 replies
2d20h

But these kinds of things also seem to follow a tech playbook, cheap parts show up, lots of hobbyist, small companies, etc start using them in low volume applications. They work out the bugs, and the newer competitors parts keep getting better. The existing big company doesn't care because, as someone else pointed out they are maintaining a stable volume/revenue.

Only, in the tech industry that's almost always a bad sign, the competitors are winning new designs that haven't yet really started to ramp, while the existing vendor is coasting on the current device using their parts. Then what happens is they get stuck in a declining revenue/volume situation while the newer cheaper better competitor slowly eats the market, and at that point investing in a "dying" product just about never happens.

the__alchemist
2 replies
3d

They have excellent documentation, and their register-level APIs are relatively high level.

Most of their chips fall into this or a related niche: good-enough computating and IO capabilities with RF for battery-powered devices. If I were to build something like this, they'd be my top choice.

I wish they would move away from the third-party suppliers for making their integrated modules. So you could buy a 'nRF-53 module with antenna' instead of browsing third party websites.

Speaking of competing with China: A Wi-Fi-capable Nordic chip is a glaring omission in their lineup. Give Espressif some competition!

xadhominemx
0 replies
1d22h

They are working on Wi-Fi

5ADBEEF
0 replies
3d

There is a companion chip, the nRF7002 which supports Wi-Fi. Not integrated into a SoC though but probably way lower power consumption than an ESP. Not sure on the difference in performance between the two competitors Wi-Fi solutions

ryukoposting
0 replies
12h54m

getting crushed by a wave of very low cost Chinese competitors

Not in my experience. Reputable chipmakers are as important as they ever have been. "Westernized" supply chains are a selling point to investors.

Regardless, Nordic leads the space because their firmware libraries are best-in-class, and their documentation and support are least-terrible-in-class. The hardware has never been the most sophisticated (or the cheapest) in the segment. ex: until the nRF5340 came out, SiLabs blew them out of the water architecturally, but SiLabs' development tools are a tire fire so it doesn't matter.

OhMeadhbh
0 replies
2d22h

TI has had the opportunity to engage the RISC-V community for several years and has, so far, declined to do so.

dkjaudyeqooe
18 replies
3d2h

This is a harbinger of RISC-V's rise. ARM can't compete in power usage with RV's simple and clean ISA, just like x86 can't compete with ARM's power optimised design. Ultimately power usage decides everything.

Eventually there will advanced RV implementations that outdo everything x64 and ARM can offer because of the RV design advantage and because there will be multiple players completing to capture market share. Intel no longer has a process advantage, and is unlikely to ever regain it.

flumpcakes
7 replies
3d1h

Does a "clean" vs. "messy" ISA really affect power utilisation more than low single digits?

I can't see what the difference is outside the FE decoding.

Perhaps an ISA having more useful instructions would matter, as we would then be able to implement hardware optimisations. But just having poor ISA encoding or inconsistency seems, to my uneducated eyes, more of a human problem than a machine problem?

dkjaudyeqooe
4 replies
3d1h

I think complexity always costs. You have to devote more gates to implementing it, more engineering, more area, and more power.

People claim that there is no efficiency difference in ISAs, but why did Intel not implement a low power processor to compete with ARM, even when it had a process advantage? Maybe they could have pulled it off in terms of power budget but the implementation was too hard.

Qwertious
3 replies
3d

I think complexity always costs. You have to devote more gates to implementing it, more engineering, more area, and more power.

Complexity also benefits - instead of having to do 12 different simple instruction, you can just do the one obscure instruction appropriate to the situation.

The question is whether theactualperf benefits outweigh the costs, and theonlycorrect answer to this is to actually measure what runs faster.

Currently we don't have a decades-mature RISC-V chip, but ARM currently outperforms RISC-V massively so it's best to reserve judgement, and not make any hasty claims. Especially since people were claiming RISC would beat out CISC since at least the 90s, and yet three decades later CISC still dominates.

imtringued
0 replies
2d3h

Look I'm a fan of x86 processors for the high end, because the gap is just that large. But when you are building these MCUs, you actually want your transistor count to be as small as possible. These chips don't have anything complicated going on. They probably have a simple five stage pipeline with most of the transistors going into the minimum 32 general purpose registers, CSR registers and pipeline registers instead of actual logic.

gary_0
0 replies
3d

instead of having to do 12 different simple instruction, you can just do the one obscure instruction appropriate to the situation

That one instruction just turns into 12 micro-ops, though, and then you need a much more complicated front-end to decode it. (And a smart enough compiler to use it in the first place.)

You do benefit from higher code density, but when you compare real-world RISC and CISC code the size difference is arguably small enough that it's not worth it, especially when there are other improvements to spend resources on that provide more benefits, like better branch prediction.

Also, instruction sets like ARM and RISC-V aren't needlessly minimalist, so you still get "extra" instructions such as vector/SIMD extensions where it makes sense. The old-school kitchen-sink instruction sets aren't popular any more for a reason.

brucehoult
0 replies
2d17h

ARM currently outperforms RISC-V massively

Only if you compare CPUs with vastly different microarchitectures e.g. a 4-wide OoO Arm and a single issue in-order RISC-V, or an Arm running SIMD code to a RISC-V CPU without SIMD/Vector.

Arm has more advanced microarchitectures and Neon deployed in the field right at this moment, certainly, but RISC-V vendors have cores up to Cortex-X3 (SiFive) or even Zen/M1 level designed, simulated, and announced and those will all be in chips you can buy in 3-4 years.

Comparing similar to similar e.g. SiFive U74 vs Arm A55 (on code not using Neon) you'll find very similar performance, and in my experience the U74 usually winning.

imtringued
0 replies
2d3h

ISA really affect power utilisation more than low single digits?

Your overall power consumption is already in milliwatts. Of course it matters. The fans on your desktop consume more power than these chips.

brucehoult
0 replies
2d17h

I can't see what the difference is outside the FE decoding.

In a sufficiently small CPU, the instruction decoder becomes a very significant proportion of the whole thing.

As an example of this consider the SeRV bit-serial RV32I core, which on a Xilinx FPGA uses 125 LUTs (most simple RISC-V cores use 1000-2000).

QeRV was just introduced, with a 4-bit wide data path and ALU instead of 1-bit wide. It increases speed by 3x while increasing the LUT count by 15%.

Clearly, instruction fetch / decode / control was totally dominating the data path. And still is on QeRV.

A couple of obvious RISC-V instruction decoding advantages over any of Arm's ISAs:

- src and dst registers are always encoded in the same bits in RISC-V but not in Arm. e.g. in A32 all data processing instructions have Rd in bits 15:12, except MUL & MULA put Rd in bits 19:16, and STR and other store instructions (which don't have an Rd) use bits 15:12 for the src register whose contents are to be stored. This seems trivial, but it adds significant extra muxes and wiring on a small design.

- It's the same in T16 (and the 16-bit opcodes in T32) which usually has Rd in bits 2:0, except the store instructions use those bits for a src register, and SP-relative load/store and "load address" (add a constant to SP or PC) have the Rd (again a src for store) in bits 10:8. So this hits Arm's smallest Cortex-M0 core.

- RISC-V uses slightly funky encodings for constants/offsets of varying sizes (including LUI and AUIPC, which encode bits 31:12, and conditional and unconditional branches, which do not encode bit 0) which minimises the number of places in the instruction that bits in the final 32 bit constant come from. This adds a couple of lines of code to assemblers and disassemblers, and makes it harder for humans trying to encode or decode binary instructions (mostly branch offsets), but considerably simplifies the muxes and wiring in the instruction decoder.

T16 also simply has alotof instruction formats (19) and instructions (close to 90?) compared to RV32I's 4 formats (6 counting the different offset encoding for branch instructions, but src/dst/opcode etc are in the same places) and 37 instructions.

RISC-V's "C" extension (16 bit opcodes) adds nine more instruction formats, but that's optional and on a very small CPU core in an application with not much program code you can choose to not implement it.

mardifoufs
5 replies
3d1h

Is risc-v really more power efficient at similar performance levels? I would think the ISA itself wouldn't matter that much for power efficiency, all things considered.

dkjaudyeqooe
3 replies
3d1h

No, not inherently. The point is that simplicity and elegance enables efficiency.

mannyv
2 replies
2d21h

Enables, but does not guarantee.

The PPC ISA is simple, but the POWER chips themsleves were never designed for power efficiency.

Likewise the ARM ISA is now associated with power efficiency, but there's nothing in the ISA itself that mandates power efficiency.

In fact, I'll bet a clever chip designer could design an x86 (or x86_64) chip that was low power. That would be a killer exercise. I want to say some of the third party licensees tried to do that with their x86 SoCs a long time ago. They failed for different reasons.

brucehoult
1 replies
2d17h

The PPC ISA is huge, with a vast number of instructions (hundreds), which implies a lot of energy-sucking decoder circuitry -- and data path too.

RISC-V allows tiny designs with just 37 instructions. ARMv6-M aka Thumb 1 (plus CSR instructions) is also fairly minimal, though not as much as RV32I.

RetroTechie
0 replies
20h30m

The PPC ISA is huge, with a vast number of instructions (hundreds), which implies a lot of energy-sucking decoder circuitry -- and data path too.

Not necessarily. It depends on how regular (orthogonal) the instruction formats are. Highly regular (few formats) = easy to decode even if there are many instructions.

But for example x86 has many different instruction formats and -lengths. Decoding all those does come at a cost.

RISC-V is very good in this regard. There's even "embedded" variants that drop half the register set (RV64E, which imho doesn't make much sense, and RV32E which does).

And there's some projects having a go at designing a 16-bit variety (to compete with legacy 8-bit ISAs perhaps?). Remains to be seen if that ever becomes a standard though.

brucehoult
0 replies
2d17h

In the smallest designs e.g. RV32E vs Cortex-M0, yes.

Seehttps://news.ycombinator.com/item?id=38225898

It's still very noticeable at Cortex M3/M4 level. Much less so in Linux applications processors.

jplrssn
1 replies
3d1h

Can you point to something specific in the Arm ISA for embedded CPUs that makes it less power-efficient than the RISC-V equivalent?

brucehoult
0 replies
2d17h
ben-schaaf
1 replies
3d1h

I don't see how you can come to this conclusion. The first generation of AMD mobile chips on a comparable process node to Apple only just released and the 7840u is even with the M2 Max in multi-core performance while using less power.

I think the conclusion to draw here is that Apple's efficiency advantage seems to be rooted outside the ISA. Their idle power usage from what I've seen is very impressive.

snvzz
0 replies
2d6h

AIUI Apple is using a better node than AMD, and they lose despite.

SigmundurM
6 replies
3d2h

It was not obvious to me this was talking about a company called Nordic Semiconductor, and not "The Nordic" as in the Nordic countries.

ruune
1 replies
3d2h

I understood Nordic as a company immediately, however I did not know this Nordic. The first Nordic that came to mind was now called THQ Nordic, which I figured couldn't be what was meant. So after a lot of confusion I now know this semiconductor Nordic

nativeit
0 replies
3d1h

This is all about the NordicTrac home exercise system sold on late night television, right?

vidarh
0 replies
3d2h

Between Norse, Scandinavian, and Norwegian (all airlines) I guess I've gotten sufficiently used to assuming it'll be a company...

owlninja
0 replies
3d2h

The URL helps

formerly_proven
0 replies
3d2h

Presumably that headline would be "Nordics are Getting Involved in RISC-V"

RaoulP
0 replies
3d2h

It's common for people at the company (and in the rest of Trondheim) to refer to the company as just "Nordic", which I suppose gets reflected in our blogs (I work there).

But personally I agree, better to spell it out. We can't all lay claim to the term "nordic".

ctz
4 replies
3d2h

Smells like leverage for the next time they renew their ARM license.

cmrdporcupine
3 replies
3d2h

While you might be right, I suspect there will be some years of people doing chips in both ARM and RISC-V to trial balloon it and see how it goes. Most customers will already have ARM toolchain they'd just prefer to stick with.

But if it works out for them, I think it will be far more than a marketing play. Having control over the ISA and dropping the license fee while still getting access to industry standard toolchains, is too tempting.

ARM would not have gotten a $50B+ valuation if the license fee was seen as not a big deal.

5ADBEEF
2 replies
3d

Nordic announced a processor w/ Arm + RISC-V cores on the same die. It's already happening!

sitkack
1 replies
2d21h

Right before Arm becomes MIPS, they will sue customers to not put RV cores on the same die as their Arm cores.

snvzz
0 replies
2d6h

They won't, as it would result on replacement of said Arm cores.

ARM is dumb, but not to this extent.

bfrog
3 replies
3d

Espressif always seems to be ahead of the game.

The premade compliant modules, shifting to riscv, providing a rust sdk, and so on.

I like Nordic products in some ways but they are becoming very complex and not necessarily in all the right ways.

Esp32 having ble and Wi-Fi in a single part is especially appealing, add in I can now program in rust and avoid all the cruft of C and it’s becoming an ever harder sell.

IshKebab
2 replies
2d21h

In fairness they were previously using Xtensa which is a far worse option than Arm so they had amuchbigger incentive to switch to something that people actually wanted.

bfrog
1 replies
2d19h

for sure, but yeah an fcc licensed ble/wifi/riscv module for $2.50 on digikey? yeah that's a win

snvzz
0 replies
2d6h

Investigate XH-C2X.

ryukoposting
1 replies
3d2h

For those who aren't in the know: Nordic is arguably the leader in small embedded Bluetooth SoCs today. I've written a lot of code for these things. Nordic selling a RISC-V product would open the door to RISC-V in tons of low-cost embedded devices.

RaoulP
0 replies
3d2h

Just to be clear, this blog post follows the recent announcement that Nordic Semiconductor would join a RISC-V consortium.

In terms of actual products, the first chips with RISC-V cores were announced back in April:

https://news.ycombinator.com/item?id=35540418

vkdelta
0 replies
2d23h

How good is their security? Did they improve over time?

https://asset-group.github.io/disclosures/sweyntooth/

qwertox
0 replies
3d

If this wouldn't be the year of mainstream AI, RISC-V's adoption would probably be the most notable fact of the year. It's still so small that it's barely noticeable if you don't follow the news, but if you do, you notice that there's something cooking which will have big implications in a couple of years.

Companies could do the same mistake Google did in regard to AI.

mark_l_watson
0 replies
3d1h

Classic HN: the comments here are more interesting than the article.

Off topic, but I have started to realize that I am developing a strong bias of liking anything “open” (open source, open LLMs, books released under Creative Commons licenses, etc., etc.) and a dislike or mistrust against closed proprietary systems. I used to be more balanced in my views. I am not a hardware person, just a humble programmer, but articles about RISC-V always interest me.

antoniuschan99
0 replies
3d

Nordic recently released news that their bluetooth power consumption is even lower (AirTags uses it). They also released a WiFi chip, but it's more like a co-processor so it's not really a competitor to ESP chips because you will still need a microcontroller. Espressif bluetooth isn't comparable because they still haven't gotten the battery consumption down to uA levels yet :$.

On the flip side, Esp is releasing the P4 which is just a microcontroller (no wifi or bluetooth so you'll need an ESP32 for co-processing) as there's things you can't currently do on esp32's such as mipi csi to interface with a wider range of camera modules easily.

Lastly, I recently discovered a lot of Chinese IoT stuff you get on Amazon (eg. Tuya and Tasmota) have migrated away from Espressif and use Beken (Google OpenBeken). I think it's more comparable to esp8266's but haven't found much info on it.

Risc-v is looking likely to be dominant in the iot segment.