[HN Gopher] Nordic is getting involved in RISC-V
___________________________________________________________________
Nordic is getting involved in RISC-V
Author : hasheddan
Score : 271 points
Date : 2023-11-10 13:42 UTC (9 hours ago)
(HTM) web link (blog.nordicsemi.com)
(TXT) w3m dump (blog.nordicsemi.com)
| SigmundurM wrote:
| It was not obvious to me this was talking about a company called
| Nordic Semiconductor, and not "The Nordic" as in the Nordic
| countries.
| owlninja wrote:
| The URL helps
| ruune wrote:
| 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 wrote:
| This is all about the NordicTrac home exercise system sold on
| late night television, right?
| RaoulP wrote:
| 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".
| formerly_proven wrote:
| Presumably that headline would be "Nordics are Getting Involved
| in RISC-V"
| vidarh wrote:
| Between Norse, Scandinavian, and Norwegian (all airlines) I
| guess I've gotten sufficiently used to assuming it'll be a
| company...
| ctz wrote:
| Smells like leverage for the next time they renew their ARM
| license.
| cmrdporcupine wrote:
| 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 wrote:
| Nordic announced a processor w/ Arm + RISC-V cores on the
| same die. It's already happening!
| sitkack wrote:
| Right before Arm becomes MIPS, they will sue customers to
| not put RV cores on the same die as their Arm cores.
| xadhominemx wrote:
| 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.
| ahartmetz wrote:
| > 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.
| xadhominemx wrote:
| 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.
| 0xDEF wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Where are the nRF52 usb dongles for $10?
| nxa wrote:
| Have you looked at Mouser or Digikey? $9.60 for per unit,
| in single unit quantities, heaps in stock as of today.
| graphe wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| wallaBBB wrote:
| 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.
| lionpixel wrote:
| For $9.90 you get a Seeed Xiao NRF52840[1] board with
| Arduino support. In sleep mode it consumes just 1uA. 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 wrote:
| 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 wrote:
| 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...
| usrusr wrote:
| Isn't the JTAG programmer something you can run on any
| old arduino if you happen to have one lying around?
| markrages wrote:
| 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.
| the__alchemist wrote:
| ST-LinkV2s, including the $8USD clones, work on nRF.
| (StLink-V3 does not).
| boesboes wrote:
| 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 wrote:
| 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.
| Qwertious wrote:
| I think the above comment is talking about domestically
| produced items?
| dvdkon wrote:
| 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.
| audunw wrote:
| > 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.
| stefan_ wrote:
| 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 wrote:
| 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.
| freeopinion wrote:
| 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 wrote:
| 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.
| wallaBBB wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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?
| 5ADBEEF wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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. :-)
| audunw wrote:
| > "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 wrote:
| 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 wrote:
| Esp32 is not low security:
| https://blog.espressif.com/esp32-s2-security-
| improvements-5e...
| graphe wrote:
| 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 wrote:
| 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 wrote:
| The chips themselves are $1 qty 1. Remove the old chip,
| put your unlocked chip in its place.
| IshKebab wrote:
| 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.
| AussieWog93 wrote:
| >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.
| baq wrote:
| how much is the soldering station to do that?
| stagger87 wrote:
| $100 and a steady hand :)
| SV_BubbleTime wrote:
| The chances that the popular wireless chip subsidized
| heavily by the CCP does _not_ have 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.
| kees99 wrote:
| Not _every_...
|
| Ikea, for example, ships tons of "smart lightbulbs" with
| silabs/EFR32.
| antoniuschan99 wrote:
| 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 wrote:
| 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.
| paulgerhardt wrote:
| 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 wrote:
| The famous APProtect bug was patched in a silicon rev IIRC.
| Unless you're thinking of another exploit
| MrQuincle wrote:
| Through voltage glitching isn't it? Which rev protects
| against it? Must be quite new.
| 5ADBEEF wrote:
| Yes, this fix was mentioned in IN-142 from Nordic.
| AussieWog93 wrote:
| >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.)
| zh3 wrote:
| 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).
| josephcsible wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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/raspb
| err...
|
| Here's the QuickStart for the entire process: https://git
| hub.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 wrote:
| 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 wrote:
| How do you propose patching security vulnerabilities in
| deployed devices?
| AnthonyMouse wrote:
| 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.
| sweetjuly wrote:
| 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 wrote:
| This shouldn't be downvoted. It is a legitimate question
| and widely held misconception that is addressed in several
| of the responses to parent.
| weinzierl wrote:
| _" 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 wrote:
| > 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 an _advantage_ , since
| it's often used to prevent this.
| the__alchemist wrote:
| 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!
| 5ADBEEF wrote:
| 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
| OhMeadhbh wrote:
| TI has had the opportunity to engage the RISC-V community for
| several years and has, so far, declined to do so.
| ryukoposting wrote:
| 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 wrote:
| 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
| dkjaudyeqooe wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| >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 the _actual_ perf benefits outweigh
| the costs, and the _only_ correct 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.
| gary_0 wrote:
| > 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.
| mardifoufs wrote:
| 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 wrote:
| No, not inherently. The point is that simplicity and elegance
| enables efficiency.
| mannyv wrote:
| 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.
| jplrssn wrote:
| Can you point to something specific in the Arm ISA for embedded
| CPUs that makes it less power-efficient than the RISC-V
| equivalent?
| ben-schaaf wrote:
| 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.
| mark_l_watson wrote:
| 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.
| qwertox wrote:
| 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.
| antoniuschan99 wrote:
| 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.
| bfrog wrote:
| 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 wrote:
| In fairness they were previously using Xtensa which is a far
| worse option than Arm so they had a _much_ bigger incentive to
| switch to something that people actually wanted.
| bfrog wrote:
| for sure, but yeah an fcc licensed ble/wifi/riscv module for
| $2.50 on digikey? yeah that's a win
| vkdelta wrote:
| How good is their security? Did they improve over time?
|
| https://asset-group.github.io/disclosures/sweyntooth/
___________________________________________________________________
(page generated 2023-11-10 23:00 UTC)