Arm Custom Instructions Coming to Armv8-M Embedded Processors

Orange Pi Development Boards

So far Arm defined all instructions for their cores with the benefit of code portability between solutions, so code compiled for an Arm Cortex-M33 based microcontroller would run on another without modifications (we’re obviously talking about code running directly on the core, not using specific peripherals here).

But with RISC-V open-source architecture many have seen the benefit of custom instructions for specific tasks, at the risk of potential fragmentation. With Arm Techcon 2019 now taking place, Arm has just announced support for custom instructions for ARMv8-M embedded CPUs starting with Arm Cortex-M33 cores.

Arm Custom Instructions

The implementation of Arm Custom Instructions for specific embedded and IoT applications will start in H1 2020 at no additional cost to licensees and without risk of software fragmentation using NOCP exception if the instructions are not available.

Arm futher explains:

Arm Custom Instructions are enabled by modifications to the CPU that reserve encoding space for designers to easily add custom datapath extensions while maintaining the integrity of the existing software ecosystem. This feature, together with the existing co-processor interface, enable Cortex-M33 CPUs to be extended with various types of accelerators optimized for edge compute use cases including machine learning (ML) and artificial intelligence (AI).

Specifically, Arm Custom Instructions for Armv8-M add a customizable module inside the processor which shares the same interface as the standard Arithmetic Logic Unit (ALU) of the CPU. There are multiple regions of the encoding space available for customization and you can choose up to eight regions based on the type of instructions you want to implement.

SoC designers will still have to follow classes of instruction extension for general-purpose and FPU/M-Profile Vector Extension (MVE). The announcement features quotes from STMicro, NXP, and Silicon Labs so one should probably expect new Arm Cortex-M33 MCU with custom instructions from those companies sometimes in 2020 or 2021.

Here’s an example of code (population count function) that could be optimized with custom instructions:


Hand-written, optimized assembly would look as follows:


This code could be replaced by a single custom instruction that saves space, improves performance & efficiency executing in just one cycle:


More details, including a whitepaper, can be found on the product page.

Support CNX Software - Donate via PayPal or become a Patron on Patreon

14
Leave a Reply

avatar
2 Comment threads
12 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
2 Comment authors
dgpblu Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
blu
Guest
blu

Makes sense. MCUs are the ideal medium for tinkering with instruction. Applications processors — less so.

dgp
Guest
dgp

Undocumented vendor specific extensions that only work with some hacked up tarball of GCC 4.8 here we come!

blu
Guest
blu

I thought you were being enthusiastic about RV32 not long ago?..

dgp
Guest
dgp

I’m against vendor specific extensions anywhere and yes they do already exist in the commercial RISC-V cores. The difference here is that RISC-V is a foundation not a single company and hopefully the extensions that survive will be those that become official RISC-V extensions.

The real irony here is that ARM has such a presence in the MCU area because a common core that the silicon vendors couldn’t mess with (not with the license for cheap MCU parts anyway) did a lot to do away with the 500MB zipped IDE that only ran on Windows XP that people used to have to suffer with. Now presumably we’ll have a bunch of extensions that aren’t really needed but provide DRM for vendor middleware that’ll get abandoned as soon as the next buzzword bingo comes around and the poor embedded guys will have the fun task of fixing bugs with IDA.

blu
Guest
blu

> The difference here is that RISC-V is a foundation not a single company and hopefully the extensions that survive will be those that become official RISC-V extensions.

I’m not seeing the difference though. Arm A-profile (not even M-profile) already has 3rd-party-originating extensions that made it into the core ISA. I’m not aware of such stuff in RV G (it inevitably will happen one day, just not yet). Actually, the fact it’s one company versus a foundation means faster turnaround — RV V is still pre-1.0, while arm licensees already ship SVE silicon.

But we’re getting off topic. One of the main benefits of RV32 has been, and will remain, the fact implementors can experiment with whatever insturctions they see fit (and yes, that’s been happening in the commercial space for a while now). Same with Xtensa, another successful MCU ISA. It is only natural arm is going that route with their M-profile.

dgp
Guest
dgp

>I’m not seeing the difference though.

For the foundation to work there has to be cross vendor cooperation, patent sharing etc. If they don’t play ball they can’t put the RISC-V mark on their stuff. No RISC-V mark means you aren’t going to be showing up in my digikey parametric search.

> 3rd-party-originating extensions that made it into the core ISA.

Which means they are documented and supported by vendor-neutral tooling and can’t be used to lock you to a specific vendor’s version of ARM. Perfect.

>Same with Xtensa, another successful MCU ISA.

Xtensa, ARC etc are really only used in ASIC applications and in those cases you are already locked into the IP providers eco-system by their design tools (multi-gigabyte zipped environment that only runs on Windows). If they can’t provide full documentation for their stuff you’re already boned.

blu
Guest
blu

Clearly the core, arm-sanctioned ISA is not going anywhere. And you digikey parametric searches will forever be safe as long as they include ‘m0, m3, .. mN’ and not ‘Joe’s private extension 768’ — whether the parts you get hits of may *also* contain ‘JPE768’ should be largely irrelevant, as those extensions will be essentially dark silicon to you.

For the record, I also expect M-parts with custom extensions to be really only used in ASICs.

dgp
Guest
dgp

>Clearly the core, arm-sanctioned ISA is not going anywhere.

That’s not the problem. The problem is silicon vendors getting control over part of the ISA, adding undocumented crap and then putting out binary middleware that uses it. One day they decide actually the crap they added was a bad idea, drop it and leave you stuck on an island with a single discontinued part that can run that piece of middleware. They already do this and really don’t need extra tools to make the situation even worse. This applies for RISC-V too.

blu
Guest
blu

At the end of the day it’s their discretion — they may or may not have a very good reason ™ for wanting those extensions in their silicon (maybe it’s that extension that made their product a success in the first place?). In your turn, it’s your discretion whether you want to have anything to do with it or not. I mean, I do ISA extensions at my dayjob that I don’t feel happy about, but I still do them for being well compensated. It’s all a trade-off.

Back on topic: ISAs do matter, and things have been moving in that direction on a global scale for a while (RV was not even the first harbinger), so arm only took a natural step.

dgp
Guest
dgp

>Back on topic: ISAs do matter,

As I said before much of the reason that all of the different funky MCU ISAs have gone by the wayside is because ARM offered a standardised cores, generic tools and so forth. This might be great business for ARM and silicon vendors but in the long run it means some poor guy desperately trying to find the special patched GCC tarball a few years down the line.

blu
Guest
blu

In the long run it means devices with BOMs not burdened by performance margins imposed by ISA limitations, which limitations are usually solved either by clock margins (GHz MCUs, anybody?) or FPGAs — if you think gcc tarballs are bad, you should see some of the FPGA tools out there. That ‘poor guy desperately trying to find patched tools’ is usually well compensated for their efforts. That compensation comes from sales. Those sales come from — you’d never guess it — product competitiveness.

dgp
Guest
dgp

>you should see some of the FPGA tools out there.

I have. For the older Xilinx stuff you need windows xp because it’s almost impossible to get ISE to run properly anywhere else.

>That ‘poor guy desperately trying to find patched tools’ is usually
>well compensated for their efforts.

I’m not sure why you keep feeling the need to talk to me like you’re teaching me something. Firmware I have written is out in the world running on well over a million cortex m? chips.

blu
Guest
blu

> I’m not sure why you keep feeling the need to talk to me like you’re teaching me something. Firmware I have written is out in the world running on well over a million cortex m? chips.

Good for you. I’m glad I haven’t taught you anything this time around. You fooled me with your first post, seemingly contradicting even your own prev stances, so I switch to basics yet again — mea culpa. So are you after all excited for RV32 or not? You do realize you’d have quite some gcc tarball hunting to do with many of its current and future implementations, right?

dgp
Guest
dgp

>So are you after all excited for RV32 or not?

Did I say I was excited for RISC-V because it had vendor extensions? I don’t think so. I remember talking about official optional extensions that have been implemented specifically so that you don’t need special GCC versions, can be trapped and handled in ROM code etc.

FYI: I’m not actually excited about RISC-V because of the ISA. I think in a few years we will see access to old crappy fab processes open up like we have for PCBs and we might get to the point where almost anyone can whip up their own SoC in some python based HDL, send it off to JLCIC (look up JLCPCB if you don’t get this reference) and have a small run of chips that are perfect for your little hobbyist/small run project. Having a reasonable freely available core around is a must for that to happen and so far all of the cores that have been floating around like OpenRISC, microblaze etc haven’t gotten on par with with a tens of cents STM32 part so it was only really worth messing around with them if you needed a core within a larger FPGA project. Personally I used TG68 because although takes up a lot more of the FPGA the M68K support for GCC is still pretty good.

>So are you after all excited for RV32 or not?

I already have a bunch of RV32 and RV64 stuff on my desk that I’m working on. I don’t really have to be excited for something I already have. If you mean am I excited for the potential for even the joker class projects to have access to close-to-ASIC levels of integration with a totally open vendor neutral core with decent tooling and a ton of weird Chinese chips in all shapes and sizes that are super cheap. Yes I am excited. Maybe it’ll turn out like that j-core project and never actually deliver.

>You do realize you’d have quite some gcc tarball hunting to do with many
>of its current and future implementations, right?

I’m not sure why you have stick up your ass about this really. Stuff that only works properly with vendor builds of GCC is bad whether you are ARM, RISC-V, Xtensa, whatever. The point that RISC-V have set out with the intention to implement optional extensions in a way that is clean is all I really care about. Of course silicon vendors will try their best to make an utter mess of it and that’s why you need someone like ARM or the RISC-V foundation to temper their bullshit. If silicon vendors got their way we would have hundreds of GCC tarballs floating around, a ton of different model compilers for ML accelerators, some more eclipse based IDEs that include a long abandoned version of the JRE.