ARM Offers Sage Advice to RISC-V Adopters

[Sal Ammoniac]

Fucks sake ARM. Dick move 

Maybe this is a reverse psychology move by RISC-V to generate positive publicity for them and negative publicity for ARM? Has anyone checked to see who actually owns the site?

[westfw]

there's no morality here.

I was never a big fan of anti-competitor marketing-heavy scare pages (remember AVR vs PIC?  I wonder if that's still around?)But for me, squatting on riscv-basics.com crossed some sort of moral line between "distasteful" and "sleazy."

[tsman]

Has anyone checked to see who actually owns the site?

Looks like it was real and made by Arm

Regretfully, the result was something different, a page that wasn’t in line with Arm’s collaborative culture, so we’ve taken it down. Indeed, many of our own people also told us they didn’t like it.

[ataradov]

Regretfully, the result was something different, a page that wasn’t in line with Arm’s collaborative culture, so we’ve taken it down. Indeed, many of our own people also told us they didn’t like it.

I don't get it. The site is still up.

[bd139]

It’s gone here.

Now they enter phase three of marketing attack. Hoping everyone will forget.

[ataradov]

It’s gone here.

Yes, I was getting the cached version. The site is gone.

[X]

Never forget.

[brucehoult]

Fucks sake ARM. Dick move 

Maybe this is a reverse psychology move by RISC-V to generate positive publicity for them and negative publicity for ARM? Has anyone checked to see who actually owns the site?

While the domain and site themselves were anonymous the main infographic was served from arm.com.

ARM has admitted it was them.

Arm told us it had hoped its anti-RISC-V site would kickstart a discussion around architectures, rather than come off as a smear attack. In any case, on Tuesday, it took the site offline by killing its DNS.

“Our intention in creating a webpage to offer key considerations around commercial RISC-V based products was to inform a lively industry debate," an Arm spokesperson told The Register.

"Regretfully, the result was something different, a page that wasn’t in line with Arm’s collaborative culture, so we’ve taken it down. Indeed, many of our own people also told us they didn’t like it.

"One thing to clear up immediately is we absolutely did not want to give the impression we were attacking open source as we are highly committed supporters of open source communities in many different areas. Our intention is to cultivate a healthy discussion around architectural choices as it is one of many subjects critical to our industry’s future.”

https://www.theregister.co.uk/2018/07/10/arm_riscv_website/

[ali_asadzadeh]

We need 128Bit processors! yeah ha!

[lukewren]

We need 128Bit processors! yeah ha!

Not in consumer space, but there are some crazy clusters out there with huge SSD arrays mapped into flat address spaces. Currently, the largest is 57 bits, i.e. 2 orders of magnitude (in storage!) from blowing a 64-bit physical address space. PAE or similar could hold the line for a while after that, but at some point those computers are gonna want larger address spaces.

[lukewren]

Brilliant.

https://github.com/arm-facts/arm-basics.com/issues/4

Have screenshot the above and sending to simon segars, ARM CEO.

No offense but that little issue thread comes across a little sanctimonious and self-important. We get it, you know Simon Segars.

I (and probably most others here) read the arm-basics.com site as a fun dig back at ARM for some pretty underhanded FUD. It's going to be taken down soon; there is a countdown timer on the site.

[AG7CK]

Brilliant.

https://github.com/arm-facts/arm-basics.com/issues/4

Have screenshot the above and sending to simon segars, ARM CEO.

No offense but that little issue thread comes across a little sanctimonious and self-important. We get it, you know Simon Segars.

I (and probably most others here) read the arm-basics.com site as a fun dig back at ARM for some pretty underhanded FUD. It's going to be taken down soon; there is a countdown timer on the site.

Oh dear! Oh dear! What have we here? A brittanic knight saving the honour of the empire's digital epic?

Who are "we" in "We get it, ..."? Old chap, I find it hard to spot anything "sanctimonious and self-important" anywhere related to this topic. With the exception of ARM's writings and your post.

My good man, you write "I (and probably most others here) read ...". Would you be so kind as to let me read myself?

You will? Thank you very much. Jolly good. That's my lad.

[helius]

brittanic knight Old chap My good man. Jolly good. That's my lad.

This kind of jingoist baiting is quite unnecessary.

[bd139]

Incidentally I don’t know Simon Segars. I obtained his email address. I havent been graced with a reply either.

If someone is being a dick you call them on it.

lukewren: none of this is fun. It’s childish.

[donotdespisethesnake]

lukewren: none of this is fun. It’s childish.

First time on the internet? 

[bd139]

No I've been on the Internet since before asshattery was the norm and wish for it to return back to that state of civility.

Everything these days is built on conflict and taking sides. It's designed to play on people's instincts of tribalism. We need to move past that otherwise, quite frankly, we're all fucked.

[janoc]

I have no stake in neither RISC-V or ARM, but let's get a bit real here, shall we?

1. Cost
With RISC-V, you don't run the risk of getting sued out of your life savings as a result in a technicality regarding IP licensing. There are also no restrictions, and no uncertainties should the company either go out of business or be acquired by a company with questionable morals, who want to change your IP licensing agreements at a whim.

Only until the first patent lawsuit hits. I guess that is actually the idea of that website - to instill fear of this (fairly real - just look at Microsoft extracting royalty fees from companies using the FAT filesystem) threat. The IP licensing is all for naught if you can get sued out of business by a deep pocketed competing vendor having a patent on a key part of your tech.

Also this is not some code library - whoever is going to build a chip based on this likely has both the money and the lawyers to negotiate a proper contract, covering their backside. So these licensing threats are mostly a moot (and managed) risk.

2. A large, supportive ecosystem
RISC-V is getting there, and there are now COTS development solutions in place. ARM, on the other hand, is just the ISA, and it is critical not to ignore all the surrounding support components of a system.
It will happen sooner now thanks to ARM's FUD-propaganda Streisand-effect website.

I am not sure whether you are trying to imply that ARM's ecosystem sucks here or that the RISC-V's is anywhere near the ARM's. In either case that's a fairly laughable assertion, IMO.

3. Fragmentation risk
Since RISC-V allows for private extensions, it would benefit those who don't intend to allow some random rinky-dink apps to run on their system as they can optimise it for their own individual use cases. The base RISC-V implementations and COTS solutions will still be available.
As for ARM's supporting infrastructure: so many combinations, so many choices, so much fragmentation.

Right, so RISC-V allows private extensions that will lead to various incompatible variants emerging, fragmenting the market. How is this different from ARM apart from the fact that the fragmentation possibility is written straight into the spec in the RISC-V case (where ARM specs only the core and leaves the rest to the implementors).

4. Security
For ARM it's, like, totally no big deal.

Rather disingenuous and completely misleading argument given that you are comparing what is likely the most widespread CPU architecture in the world that has been on the market for decades (the CVE list doesn't make any differences between the different ARM versions) with an architecture that has no market penetration (and thus no published CVEs) at all at this point.

Even worse, the list you have linked includes both hardware bugs (e.g. the various cache side channel attacks) and software bugs in the tools produced by ARM (the company), such as problems in mBed's libraries. What does that have to do with the CPU?

5. Design assurance
Having one major company "verify" your CPU, or having a large community with plenty of eyes verify and find faults in the design. You decide.

Just LOL. You actually believe that the actual SoCs apart from the baseline reference designs will be open? Especially given the very permissive BSD license on the IP? The first thing an implementor of this will do is to take the RISC-V IP and make a closed design to protect their secret sauce. Nobody in this industry is giving away their IP for competitors to benefit from.  Just look at the various '51 clones - that architecture was also free and published but pretty much none of the clones and modern chips that use it are.

RISC-V may have advantages over ARM (or others), I am not considering myself to be competent to judge that. However these "arguments" you have listed are just laughable. Less Cool-aid, please.

[lukewren]

Just LOL. You actually believe that the actual SoCs apart from the baseline reference designs will be open? Especially given the very permissive BSD license on the IP? The first thing an implementor of this will do is to take the RISC-V IP and make a closed design to protect their secret sauce. Nobody in this industry is giving away their IP for competitors to benefit from.  Just look at the various '51 clones - that architecture was also free and published but pretty much none of the clones and modern chips that use it are.

Yeah that's a good point. Have worked at a company where someone went down a list of IPs (small things like serial interfaces) on opencores and crossed off anything that was e.g. GPL rather than BSD.

There are some companies like SiFive which are doing fully open designs and taping them out. I think one of their employees is a member here. I still haven't grasped the business model (i.e. what's stopping someone from downloading the design and taping it out themselves), but I'm watching it with interest 

Right, so RISC-V allows private extensions that will lead to various incompatible variants emerging, fragmenting the market. How is this different from ARM apart from the fact that the fragmentation possibility is written straight into the spec in the RISC-V case (where ARM specs only the core and leaves the rest to the implementors).

One difference between RISC-V and ARM here is that RISC-V explicitly allocates opcode space for non-standard extensions, so that they can break each other, but not future standard extensions.

There is also a review path through the foundation for non-standard extensions to become standardised if they turn out to be widely applicable. This doesn't solve my general concern of how shrinkwrapped software distributors are going to (not) handle the various possible ISA configurations, but it's also not exactly the same situation as ARM

I am not sure whether you are trying to imply that ARM's ecosystem sucks here or that the RISC-V's is anywhere near the ARM's. In either case that's a fairly laughable assertion, IMO.

Yeah it's quite odd that most RISC-V SoC projects are developing their own bus standards rather than using AMBA. Anyone can freely implement AMBA masters and slaves, and IMO that seems like a better way of leveraging existing infrastructure 

I guess this is what happens when a lot of nerds get excited about something... when the dust clears, we'll probably still be seeing a lot of AMBA. They are (not you, AHB) great bus standards.

[janoc]

There are some companies like SiFive which are doing fully open designs and taping them out. I think one of their employees is a member here. I still haven't grasped the business model (i.e. what's stopping someone from downloading the design and taping it out themselves), but I'm watching it with interest

I think that not everyone has the money and time to do that, so there is likely going to be a market for ready-to-go parts. So there may be a business model, I don't know.

My point was more about debunking the idea that the design is somehow better because it is open - as if that ensured somehow that the actual implementations will be too (not counting the reference designs as those obviously aren't going to compete with ARM).

One difference between RISC-V and ARM here is that RISC-V explicitly allocates opcode space for non-standard extensions, so that they can break each other, but not future standard extensions.

There is also a review path through the foundation for non-standard extensions to become standardised if they turn out to be widely applicable. This doesn't solve my general concern of how shrinkwrapped software distributors are going to (not) handle the various possible ISA configurations, but it's also not exactly the same situation as ARM

The main issue is that vendor A may implement features A,B,C & X and vendor B does B,C and Y. Boom, the CPUs are both the same architecture but not really compatible.

With ARM you have these ISA extensions (Neon, Thumb, etc) standardized (or rather - imposed) by ARM themselves and the licensee isn't allowed to add extra instructions or to omit something if they want to claim compatibility. If anything, that's a much stronger assurance against fragmentation than allowing everyone to build their own CPU which is mostly compatible but isn't really because they have added some extra proprietary instructions nobody else has.

A compiler built for a certain ARM ISA variant and ABI will work on any ARM CPU implementing it on the market. Good luck with building compilers for and supporting those vendor-specific, nonstandard RISC-V extensions ... I am sure the GCC and LLVM folks are going to "love" that "feature".

However, that's all a pretty large red herring when talking about fragmentation - regardless of whether or not the ISA is standardized you will get market fragmentation because not every vendor will implement every feature in every part (it makes little sense to have e.g. the Neon instruction set in small Cortex M parts or running Thumb on ARM A series SoCs).

Worse, all that covers only the ISA, nothing else - peripherals, booting, etc. That's where the most of the ARM ecosystem fragmentation (and related problems) is coming from, not the differences in the instruction sets. And the RISC-V spec does nothing whatsoever about that.

[brucehoult]

I have no stake in neither RISC-V or ARM, but let's get a bit real here, shall we?

1. Cost
With RISC-V, you don't run the risk of getting sued out of your life savings as a result in a technicality regarding IP licensing. There are also no restrictions, and no uncertainties should the company either go out of business or be acquired by a company with questionable morals, who want to change your IP licensing agreements at a whim.

Only until the first patent lawsuit hits. I guess that is actually the idea of that website - to instill fear of this (fairly real - just look at Microsoft extracting royalty fees from companies using the FAT filesystem) threat. The IP licensing is all for naught if you can get sued out of business by a deep pocketed competing vendor having a patent on a key part of your tech.

Unfortunately, anyone can sue anyone with little or no justification, and if their pockets are deep enough they can put you out of business even if their case has no merits and you win.

Companies that have joined the RISC-V foundation have certified that RISC-V does not infringe any of their patents.

RISC-V has been consciously designed using only principles that have prior art, and preferably that *was* patented, but the patents have expired.

At this point, that includes everything up to and including the Pentium Pro, early PowerPC, DEC Alpha. MIPS R4000, ARMv2. Not to mention of course IBM 360, Cray etc. That sets free not only basically every useful instruction known to man, but also a lot of very useful and advanced high performance implementation techniques (especially the Pentium Pro and Alpha).

Precedents for every RISC-V instruction have been documented at https://riscv.org/risc-v-genealogy/

You can never have zero chance of getting sued, but the chances of getting sued for using RISC-V are probably as low as it's possible to make them.

[brucehoult]

There are some companies like SiFive which are doing fully open designs and taping them out. I think one of their employees is a member here. I still haven't grasped the business model (i.e. what's stopping someone from downloading the design and taping it out themselves), but I'm watching it with interest 

Hi :-) I've been a member here longer than I've been at SiFive. I'm not a founder or manager or spokesperson or anything like that, just a pleb programmer. All opinions are most definitely my own. I liked the tech and its possibilities so much I joined the company.

The business model is, I would say, something like RedHat. Nothing stops you putting together your own Linux distro or using one of the many free ones, but some people prefer to pay money for a supported version, with components and versions of components that have been tested and certified to work together.

Last I saw, RedHat had $2.9 billion of annual revenue.

Right, so RISC-V allows private extensions that will lead to various incompatible variants emerging, fragmenting the market. How is this different from ARM apart from the fact that the fragmentation possibility is written straight into the spec in the RISC-V case (where ARM specs only the core and leaves the rest to the implementors).

One difference between RISC-V and ARM here is that RISC-V explicitly allocates opcode space for non-standard extensions, so that they can break each other, but not future standard extensions.

Yes, also non-standard extensions are quite likely to not be made public, but just be deeply buried in that company's products. Compatibility with someone else's non-standard extensions is unlikely to be a factor.

People who would like to submit their extensions for ratification as part of the standard are encouraged to stick to RISC-V norms (e.g. no more than two source registers and one destination register for integer instructions), put operands in the standard places in the encoding, and generally use as few encoding bits as practical.

Recommendations are being worked on to allow the actual opcodes for extensions to be remapped as easily as possible (e.g. possibly as simple as a single #define in binutils). Even though the resulting binary programs won't be compatible, source code will be compatible at the C and asm levels.

There is also a review path through the foundation for non-standard extensions to become standardised if they turn out to be widely applicable. This doesn't solve my general concern of how shrinkwrapped software distributors are going to (not) handle the various possible ISA configurations, but it's also not exactly the same situation as ARM

Even in shrink-wrapped applications, the vast vast majority of code will do just fine using the standard instruction set. Extensions are likely to be confined to just a few routines in a library. Mechanisms such as GNU function multiversioning can be used to choose the best functions at runtime.

Yeah it's quite odd that most RISC-V SoC projects are developing their own bus standards rather than using AMBA. Anyone can freely implement AMBA masters and slaves, and IMO that seems like a better way of leveraging existing infrastructure 

AMBA has a free license but it's not unlicensed. You have to agree to the license terms, and it seems possible ARM could decide to withdraw a license.

There is particular confusion around whether you can use AMBA with non-ARM CPU cores. Some people interpret the wording to mean you can't have a non-ARM CPU in your AMBA system. Others interpret it to mean if your core executes ARM instructions then it must have a paid-for license from ARM.

None of which has I think been tested in court.

Using AMBA in a RISC-V system might be low risk, but could still be the largest risk of getting sued.

SiFive uses Berkeley's "TileLink" point to point interface. I think it's roughly equivalent to AXI4 ACE. We have high performance adaptors to AXI if you need them.

I think some others are using WishBone? I'm not aware of anyone rolling their own from scratch.

[lukewren]

Hi :-) I've been a member here longer than I've been at SiFive. I'm not a founder or manager or spokesperson or anything like that, just a pleb programmer. All opinions are most definitely my own. I liked the tech and its possibilities so much I joined the company.

The business model is, I would say, something like RedHat. Nothing stops you putting together your own Linux distro or using one of the many free ones, but some people prefer to pay money for a supported version, with components and versions of components that have been tested and certified to work together.

Hello!

One difference I see between RedHat and SiFive is that SiFive has a silicon foundry in between their team and the delivered products, and once they hit volume, this is presumably a significant portion of the per-unit cost. It feels like there is an opportunity for SiFive to get undercut by second sources of their own products, whether from a different foundry, or by another foundry customer with better foundry relations. OTOH, if you are literally distributing binary copies of a RedHat image, this is still illegal as far as I know. I realise people thought of this before starting a multimillion company, I'm just curious!

AMBA has a free license but it's not unlicensed. You have to agree to the license terms, and it seems possible ARM could decide to withdraw a license.

There is particular confusion around whether you can use AMBA with non-ARM CPU cores. Some people interpret the wording to mean you can't have a non-ARM CPU in your AMBA system. Others interpret it to mean if your core executes ARM instructions then it must have a paid-for license from ARM.

None of which has I think been tested in court.

Oops. I should have looked into that more deeply when I started working on my AHB-lite RV32IMC core...  that does put things in context though. And I guess hobby projects are mostly safe.

Using AMBA in a RISC-V system might be low risk, but could still be the largest risk of getting sued.

SiFive uses Berkeley's "TileLink" point to point interface. I think it's roughly equivalent to AXI4 ACE. We have high performance adaptors to AXI if you need them.

I think some others are using WishBone? I'm not aware of anyone rolling their own from scratch.

Oops, yeah, TileLink is the one I was thinking of. The one that's in RocketChip too right? I guess my brain went "also berkeley + also new/in dev -> same team".

I wasn't aware you could do high frequency * area product (i.e. insert pipe stages without throughput reduction) and coherent stuff with Wishbone, guess I should look into that more! I have only seen it used in a similar context to APB.

Given the ubiquity of AMBA slave IP (in my corner of the industry at least), I still feel like it won't be too long until we get that ARM/AMBA test case in court will be interesting to see how that is handled. And also whether there is a line drawn between AMBA busfabric vs non-proprietary busfabric and adapter to AMBA slave, since the adapter + slave effectively combine to make a non-AMBA slave. As you said though, the validity of the case doesn't really matter.

I need to understand AMBA licensing better, thank you for the pointer

[lukewren]

Here is the first term from AMBA 3 (I'm using AHB-lite)

1. Subject to the provisions of Clauses 2 and 3, ARM hereby grants to LICENSEE a perpetual, non-exclusive, non-transferable, royalty free, worldwide licence to:

(i) use and copy the AMBA 3 Specification for the purpose of developing, having developed, manufacturing, having manufactured, offering to sell, selling, supplying or otherwise distributing integrated circuits which may or may not include a CPU but which incorporate a bus which is compatible with the AMBA 3 Specification, provided that where such integrated circuits incorporate a CPU then either: (a) such CPU is manufactured under licence from ARM; or (b) such CPU is neither substantially compliant with nor marketed as being compliant with the ARM instruction sets licensed by ARM from time to time;

So to me that seems pretty black and white that it cannot be revoked, and that the restriction is that ARM-compatible CPUs must be manufactured by separately licensed from ARM. Potentially AMBA 4 and AMBA 5 have different terms.

[janoc]

There are MIPS SoCs using AMBA - apparently ADM5120 by Infineon is one such beast.

https://www.linux-mips.org/wiki/Adm5120

So I don't believe AMBA is restricted to ARM only.

[ataradov]

So I don't believe AMBA is restricted to ARM only.

It is not at the moment, but given the obvious hostility of ARM, why even risk it. What if next version of the specification does add restrictions specifically for RISC-V? And in the mean time you have abandoned your own bus infrastructure.