ARM Offers Sage Advice to RISC-V Adopters

[kfnight]

https://riscv-basics.com/

It's worth noting that, at the beginning, ARM didn't acknowledge RISC-V's existence, so with ARM creating a site like this is quite an accomplishment for the RISC-V foundation and those supporting it.

 

[Dubbie]

Pretty much textbook F.U.D.

[ataradov]

"Get the Facts" all over again. Did not work the last time, why would it work this time?

Also, who makes an IP purchasing decision based on one-page smear site?

[SiliconWizard]

Yeah, this is some level of recognition. The sign that RISC-V has become a very low-intensity potential threat to ARM that warrants creating a one-page website written by Sir Clive Obvious and that redirects to a free trial of ARM processor IPs.

[bd139]

Fucks sake ARM. Dick move 

[maginnovision]

Maybe they just want them to buy the domain.

[X]

Pretty much textbook F.U.D.

"Get the Facts" all over again. Did not work the last time, why would it work this time?

Also, who makes an IP purchasing decision based on one-page smear site?

Executives with more money than brains, a very numerous and prominent species.


EDIT Now for something completely different.

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.

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.

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.

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

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.

[KE5FX]

RISC-V's credibility just went up a couple of notches, that's for sure.  They are no longer being ignored, or laughed at, but fought.

[cv007]

Cybersquatting is still a thing? (and by a company like ARM?)

Looks like its too late for riscv to get arm-basics.com (registered today? china?)

[brucehoult]

Disclaimer: I recently joined a RISC-V vendor

#1: the site seems to be real. The big infographic (on a desktop browser) with embedded references to RISC-V is served from arm.com https://riscv-basics.com/images/arm-risc-v-5-things-to-consider.png

#2: we're stoked.

[brucehoult]

Looks like its too late for riscv to get arm-basics.com (registered today? china?)

RISC-V is going down well in China (and India).

They're serving www.arm-basics.com from github

You can probably make Pull-Requests if you have fun ideas.

https://github.com/arm-facts/arm-basics.com/blob/master/index.md

[bd139]

Brilliant.

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

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

[bd139]

Send following email too:

I've recently been brought to the attention of the following web estate that has appeared branded ARM.

https://riscv-basics.com/

Seriously this is not how you do business. If this is an ARM product then I'm quite frankly disgusted. If it isn't you need to resolve this. This is 2000's Microsoft business tactics which everyone literally cringes at today:

https://web.archive.org/web/20070622152618/http://www.microsoft.com/windowsserver/facts/default.mspx

I've registered my discontent with it publicly and have screenshot all pages: https://github.com/arm-facts/arm-basics.com/issues/4

If someone is eating your cake, make your product better, not slate everyone else's.

[brucehoult]

Brilliant.

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

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

If that's you, it appears you are complaining about arm-basics.com, not riscv-basics.com

[bd139]

I've emailed the CEO with the riscv-basics link for ref. See above email body.

[chickenHeadKnob]

Aaaaaaannd Its Gone!

server not found

[ataradov]

server not found

Still there, it is just not configured properly, so it needs www: https://www.arm-basics.com/

[SiliconWizard]

server not found

Still there, it is just not configured properly, so it needs www: https://www.arm-basics.com/

They have changed the content though.

[ataradov]

They have changed the content though.

The only changes tracked in Git history are related to a small section about security and Meltdown fiasco.

[SiliconWizard]

Oh, I was comparing to the original web page we saw yesterday and that got taken down. I happen to still have it in my browser's cache. Although it contained a similar message, the content was quite different. It looked a lot more "commercial" and contained just one line about security whereas the "arm-basics.com" page has a bit more detailed content and has a CCA license, which of course the other site didn't.

[bd139]

Everyone needs to stop being dickheads here basically. Responding with the same tactics doesn’t make you any better than the original tactics ARM pulled. In fact it somewhat ruins the moral high ground. Hence why I raised the issue above. 

No response from ARM yet.

[ataradov]

I'm not sure there is a need to have the moral high ground here. Everyone understands what everyone else is doing here, no big deal.

[kfnight]

Yeah, there's no morality here. It's just business.

[mark03]

RISC-V's credibility just went up a couple of notches, that's for sure.  They are no longer being ignored, or laughed at, but fought.

This was my first thought too.  Given that the next step in that [mis-attributed to Ghandi] quotation is "then you win," if I were ARM I'd be very worried right now.  Oh right, I guess they are 

[mark03]

The site seems to have been taken down, but it's archived here:

https://web.archive.org/web/20180708231736/https://www.riscv-basics.com/

[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.

[ali_asadzadeh]

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.

That's great news! what sort of prices should we expect for the RISCV parts?

[janoc]

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.

If the next version adds whatever restriction it can't be applied retroactively to the older specifications. You just may not be able to use the latest spec - which is not necessarily a problem, AMBA is an on-chip bus that isn't exposed to anything else, so if you want/need to change to something else in the future, you can without anyone else but you being affected during the development of the new product.

If anyone could change their terms retroactively and then sue you based on that, any license documents wouldn't have the worth of the paper they are written on. So in that regard you should be safe, IMO.

Anyway, I didn't want to get into the debate whether or not someone should start using AMBA, that's a cost/risk & benefit assessment that everyone needs to make themselves. I only wanted to say that there certainly are non-ARM products using the specification.

[ataradov]

So in that regard you should be safe, IMO.

Technically yes. The same way as first dose is free in drug consumption.

That why I said that once you abandon your own design fro the bus, you give up control. If next version of AMBA is not free to use, but you need to move to the bus architecture with more capabilities, you are stuck designing that bus from scratch while not having any background work done because you relied on someone else.

[janoc]

So in that regard you should be safe, IMO.

Technically yes. The same way as first dose is free in drug consumption.

That why I said that once you abandon your own design fro the bus, you give up control. If next version of AMBA is not free to use, but you need to move to the bus architecture with more capabilities, you are stuck designing that bus from scratch while not having any background work done because you relied on someone else.

And how would that be different from doing that work *now*? It is exactly the same thing. The R&D cost would need to be paid either way.

However, using a pre-existing and known to work design allows you to get the product to the market faster, cheaper and push that redesign for later when you actually are selling a product already and have an established market (and income!). Investing loads of money into R&D upfront and then running the company in the ground because you can't recover it in sales fast enough is not the best business strategy. Especially for a feature that customers don't really care about (few choose a micro or a SoC based on the internal bus architecture as long as it is good enough for the job).

[ataradov]

And how would that be different from doing that work *now*? It is exactly the same thing. The R&D cost would need to be paid either way.

Less of a shock when you already have established tools and workflow.

However, using a pre-existing and known to work design allows you to get the product to the market faster, cheaper and push that redesign for later when you actually are selling a product already and have an established market (and income!). Investing loads of money into R&D upfront and then running the company in the ground because you can't recover it in sales fast enough is not the best business strategy. Especially for a feature that customers don't really care about (few choose a micro or a SoC based on the internal bus architecture as long as it is good enough for the job).

I'm not saying that AMBA is bad in all cases. It is good in some, but it is also good to have an alternative, especially if a company feels like there are resources to do so.

[brucehoult]

So in that regard you should be safe, IMO.

Technically yes. The same way as first dose is free in drug consumption.

That why I said that once you abandon your own design fro the bus, you give up control. If next version of AMBA is not free to use, but you need to move to the bus architecture with more capabilities, you are stuck designing that bus from scratch while not having any background work done because you relied on someone else.

And how would that be different from doing that work *now*? It is exactly the same thing. The R&D cost would need to be paid either way.

However, using a pre-existing and known to work design allows you to get the product to the market faster, cheaper and push that redesign for later when you actually are selling a product already and have an established market (and income!). Investing loads of money into R&D upfront and then running the company in the ground because you can't recover it in sales fast enough is not the best business strategy. Especially for a feature that customers don't really care about (few choose a micro or a SoC based on the internal bus architecture as long as it is good enough for the job).

You don't need to do any work *now* because there already exist several unquestionably open and free to use bus specifications that are good enough.

[janoc]

You don't need to do any work *now* because there already exist several unquestionably open and free to use bus specifications that are good enough.

Even better. But I am sure someone would argue again that what if the license changes in the future or a patent suit hits or whatever. We could have such pointless debate forever.

[brucehoult]

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.

That's great news! what sort of prices should we expect for the RISCV parts?

Impossible to answer. Anything from tenths of a cent to many tens of dollars. Which core(s) do you want? Configured how? 32 bit or 64 bit? With multiply? How fast? With divide? How fast? How much if any branch prediction? How much return address stack? How many hardware breakpoints? How many performance monitor registers? FP? MMU? How many of each core on the part? How much L1 data and instruction cache or tightly-coupled scratchpad? What about L2? What peripherals do you want from SiFive or its partners, and how many? What process do you want to use?

SiFive isn't a typical chip manufacturer. We don't come up with ten configurations that we think will sell and then build a few million of them and put them in a warehouse. The idea is to provide a chip buying experience that is like going into a web site and ordering pizza. You pick your size, thickness of the base, type of crust, toppings, sauces press a button and some time later the pizza arrives at your door.

Or in the case of SiFive, you get a bitstream and RTL based on your custom choices within a few hours.

Watch this, especially starting at around 7m40s:



SiFive *can* organise to get your chip fabbed -- especially for a sample run of 100 chips -- or even for high volume production runs, but most customers will already be making chips and just want to add our cores to their own chip. SiFive gives them the RTL and they do synthesis and something that falls out the end of that is the area and therefore the cost.

You can right away, for free, download real working (but limited) RTL for a few fixed configurations of various SiFive cores right away, put it through your workflow and get your own PPA estimates. You can download real working FPGA bitstreams of them and write and test software (at limited MHz, obviously).

https://dev.sifive.com/risc-v-core-ip/evaluate/rtl/

If you want to build a typical E31 core (like the HiFive1, but updated and improved) on 180 nm then you'd be looking at a few cents per processor. If you take an E20 and configure it with minimal scratchpad RAM then the cost per core could be fractions of a cent.

[ali_asadzadeh]

Dear brucehoult thanks for the feedback, it was very helpful, I have seen some complete chips in your website, like the E2 Series ,E5 Series and U5 Series, I was wondering if they are available to buy? and what sort of prices to expect and where to buy?

[brucehoult]

The only place you can currently buy chips by themselves at retail is the FE310-G000 on CrowdSupply for $25 for a pack of five.

https://www.crowdsupply.com/sifive/hifive1

That's a chip that taped out almost two years ago and is in the HiFive1 evaluation board. It's an early version of the E31.