Hacker News Reader

ARM royalties 1.0% - 2.0% of the chip cost and negotiable. Higher the volume, smaller the royalty. Foundry pays extra 0.5% for the physical IP package.

When somebody decides to invest into large volume laptop/desktop/server microarchitecture to compete with Intel and AMD, nothing prevents them from adding their own proprietary ISA extensions. RISC-V allows classic embrace and extend tactics. RISC-V for Microsoft surface and RISC-V for Google Chrome may not be fully compatible with each other and RISC-V AWS cloud processors.

Most open software that is not vender provided will run on RISC-V. Meaning no matter if Google or Microsoft, that stuff will work.

It want use their proprietary extensions but often I don't really care about that and if they pay for developing or updating all open source software so it runs on their extension then that's fine also.

Embrace & extend are a big danger indeed. We might be headed into an era where there aren't a few well-understood proprietary ISAs but instead there are lots of badly understood proprietary ISAs that base on some open source core.

Ah, yes. "Know how every ARM system boots slightly differently with different peripherals? How about we encode this wacky incompatibility into the instruction set too?"

> RISC-V for Microsoft surface and RISC-V for Google Chrome may not be fully compatible with each other and RISC-V AWS cloud processors.

It is up to software distributors to decide whether it's worthwhile to use those extensions; provided they are even allowed to run their own software on the thing to begin with (which was not the case with Surface RT anyway, extended ISA or not).

> When somebody decides to invest into large volume laptop/desktop/server microarchitecture to compete with Intel and AMD, nothing prevents them from adding their own proprietary ISA extensions.

Nothing prevents AMD and Intel from doing this either, and they do it all the time! You just don't notice because they agreed privately to cross-license the extensions.

And at the end of the day, the parts of the platform that you'd use for a standard operating system (notwithstanding new tagged memory or other exotic architectures, which I'd argue are a good, innovative form of incompatibility) are fully standardized already on RISC-V. If Microsoft wants to make their next version of NT on RISC-V rely on Qualcomm-proprietary instructions, that's their prerogative.

> provided they are even allowed to run their own software on the thing to begin with (which was not the case with Surface RT anyway, extended ISA or not).

Surface RT allowed Windows Store apps, including native ones.

I think you're agreeing with GP -- it only allowed software signed by Microsoft (in other words, you couldn't run your own software or operating system unless Microsoft said so).

In this hypothetical proprietary RISV-V scenario, you might not even be able to run unsigned code on the device and so nobody is going to bother supporting its weird instruction set.

> RISC-V allows classic embrace and extend tactics. RISC-V for Microsoft surface and RISC-V for Google Chrome may not be fully compatible with each other and RISC-V AWS cloud processors.

The zoo of endianness, and extensions support did not do anything to ARM's rise.

Endianness is not the same, it's a standard part of the architecture.

And the extensions could be tested for based on ISA version. Most of ARM's history is non-divergent.

> But what about "bigger" systems? Laptops or desktops or servers? Do the pareto analysis on those systems, compare an ARM SoC to a RISC-V one. The costs are in memory, support chips, PCBs, tooling etc. Not the CPU license.

But it could be a step towards a "GPL for hardware" type of shift. Someone puts in the work or the money to do a core which is competitive on some important metric (power, cost, etc.), and licenses it at no cost but under the terms that if you make changes you have to publish them and under the same license.

Then some people use it because it's good enough and free-as-in-beer, but if any of them improve it then it gets better. So then more people use it, until it's the Linux of hardware.

Moreover, if you have to publish the changes then you have to document the changes (equivalent of releasing source code), which means hardware that isn't a black box will gain a competitive advantage over hardware that is.

New high performance microarchitecture costs hundreds of millions to develop. You need to develop new microarchitecture every five years or so to stay competitive.

It's not hacking VHDL in your basement type thing where everyone can adds new stuff and it just works together trough common agreed api. All changes must run trough long chain of verification and testing from functional models to physical placement, testing and verification.

Which is why you don't start off by trying to challenge AMD and Intel on raw performance.

But more to the point, most of Linux isn't developed in basements either. Someone like Google/Facebook/Amazon/Microsoft decides it's worth their resources to make a more power efficient chip for their datacenters and more valuable to get further improvements from third parties than to try to sell it externally at commodity margins, or that "commoditize your complement" would be a good thing to do for cell phone chips, and now you've got a billion dollars in funding.

I believe there is a good economic model for open hardware design but it's not the software model. "commoditize your complement" means that only those whit physical hardware can make money.

IMHO Syndicate with clever licensing around RISC-V infrastructure would be the best idea.

The clever licensing part:

1) mandatory licensing: licensees must license to everyone with the same conditions. licensees can't refuse to license.

2) pricing model: licensees periodically announce valuations at which they commit to sell their IP, and must sell their intellectual property for that value to anyone who is willing to commit to smaller license fees. There can be a periodic auction each year.

> "commoditize your complement" means that only those whit physical hardware can make money.

Those companies are the ones with physical hardware.

But it's also not true that they'd be the only ones to make money. If you lower your supplier's margins on hardware and then pass half the savings on to your customers, you get both higher margins and higher volumes. But your customers still get lower prices, which means they make more money too, on top of the transactions that it made feasible that weren't previously.

Reportedly, Intel does mostly fully automated synthesis and instead of manually tuning the layout, they improve their essentially fully in-house Verilog to silicon toolchain.

Everyone uses automated toolchains, but getting physical layout from toolchain does not mean it works or performs.

What makes it possible to design small volumes of custom asics for reasonable price is old and well known process, increasing the error margins (and sacrificing performance) or using existing modules. Simulation mostly works and can be trusted, yield is predictable etc.

In a time where most sponsors for FOSS software are moving away from GPL.

The GPL continues to be a popular license. It just got popular enough that in v3 they could take a more aggressive stance on patents and tivoization. Which is inherently a trade off between goals and adoption. They chose to achieve more of their goals at the expense of some usage.

To the point that all major FOSS alternatives on the embedded space, including Zephyr from Linux Foundation aren't based on GPL.

Android already removed their dependency on GCC, following Apple's footsteps, and depending on how Fuchsia turns out, eventually the Linux kernel as well.

But Android is still based on Linux and you need GCC to compile the kernel (yeah I know, other compilers can do it too, but GCC is in some kind of symbiosis with Linux, which is a good thing I guess).

I know about the Fuchsia project, but so-far it can't compete with Linux or other established OSes.

Why is gcc dependency a good thing for the kernel?

It keeps both GPL?

How?

You're right to ask, it does not. In the FOSS world the license of the compiler has nothing to do with the license of the compiled software, and that also goes for the GPL 3.

Probably some leftover thinking from proprietary products that tried to apply license restrictions on the compiled output.

Actually GCC has an explicit clause that GPL doesn't apply to the generated binary, otherwise you could not link to the C runtime library

"GCC Runtime Library Exception"

https://www.gnu.org/licenses/gcc-exception-3.1.en.html

This document was also the inspiration for the Classpath exception in OpenJDK.

Right but that's because the compiler is emitting code into the binary that exists verbatim in the GCC source.

Which makes the assertion false, otherwise there wouldn't be a need for the "GCC Runtime Library Exception".

> "In the FOSS world the license of the compiler has nothing to do with the license of the compiled software".

There is no other FOSS compiler that influences the license of the compiled software, afaik. So I think that statement holds up anyway.

No you don't, Android has removed all dependencies on GCC with Treble changes, upstream just did not took all the changes done by Google.

Quote:

"Android 8.0 and higher support only Clang/LLVM for building the Android platform. Join the android-llvm group to pose questions and get help. Report NDK/compiler issues at the NDK GitHub.

For the Native Development Kit (NDK) and legacy kernels, GCC 4.9 included in the AOSP master branch (under prebuilts/) may also be used."

From https://source.android.com/setup/build/requirements#software...

"Removed GCC and gnustl/stlport. Added lld."

From https://android.googlesource.com/platform/ndk/+/master/docs/...

There are also a couple of Linux/Clang Conferences where Google goes through the kernel and clang changes they have done to accomplish it.

Android might have the Linux kernel under the hood, but it isn't Linux as many know it.

>Android might have the Linux kernel under the hood, but it isn't Linux as many know it.

Not like it matters. They're replacing even that. See Fuchsia.

And that's a good thing: Fuchsia seems to have a better design (microkernel, multiserver).

The info everyone is missing is code density comparison with ARM. Risc-V is more efficient and has about 10% denser code, which translates to more instructions fitting in i-cache, less memory pressure, and ultimately better performance and battery life. Long term roadmap, thats a win for Risc-V.

That is pretty cool, is there a ThumbV2 vs RISC-V paper somewhere for 32 bit RISC-V ?

Andrew Waterman's PhD thesis "Design of the RISC-V Instruction Set Architecture" ("Why Develop a New Instruction Set?") has a nice comparison of ISA encoding and density of RISC-V, MIPS, SPARC, Alpha, ARMv7/8, Thumb, OpenRISC, and x86/x86-64.

https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p...

Page 4: https://riscv.org/2016/04/risc-v-offers-simple-modular-isa/

RV32C and ThumbV2 have equal code sizes.

Is "10% denser" comparing RV32 or RV64 against A32, T32, or A64? And is that with or without the Compressed Instructions extension?

As of early 2016, with the GCC port at that time, RV32GC was as dense as Thumb, and RV64GC was denser than AArch64 and every other major 64-bit ISA, including AMD64. Though RV64G (no C) was in some extreme cases up to 50% larger than AArch64 (due to inlining memcpy and memset, which are a bit larger without compressed instructions), but usually around the same (except MIPS64, which is way larger than the other 64-bit ISAs, probably because of exposed delay slots). [0]

There's some indication that density should have increased somewhat since then, but I haven't looked at it myself.

[0]: https://youtu.be/Ii_pEXKKYUg

That's why I have a lot more faith in RISC-V's ability to take on relatively high end embedded tasks than lower end ones. I'd expect compression to be too expensive, transistor wise, for many roles where you'd use an ARM Cortex M2 or such and program memory is at a premium in those places.

The cost of compression is very small for low performance designs (single instruction in-order issue). It's very straightforward to implement.

It gets harder for more complex designs though.

But for cases where you want to replace a Cortex M2, the area increase will be trivial.

Cortex-M2? ¿Que? CM2 doesn't exist -- the naming scheme jumps straight from CM1 (which is FPGA-only) to CM3.

> I'd expect compression to be too expensive

It's not the kind of compression you might be thinking of. It's just 16-bit "shortcuts" for some of the common 32-bit instructions. The impact in gate count should be minimal. In a lot of these applications you'll have the code in on-chip non-volatile memory which means reducing code size may also reduce chip area.

I think with relatively little increase in gate count you could also make some sequences of two 16-bit instructions execute simultaneously, which could yield nice performance improvements for micro-controller cores.

Also, you might be surprised at how "big" many micro-controllers are becoming these days.

> I'd expect compression to be too expensive, transistor wise, for many roles where you'd use an ARM Cortex M2 or such...

Decoding the "compressed" instructions is actually pretty straightforward, it doesn't add much complexity to a design. ARM Cortex M0+/M3/M4 implements a similar (but more complex) "compressed" instruction set called Thumb, and comparable RISC-V cores available from SiFive are smaller, faster, and more efficient.

In a very small RISC-V core by the venerable Clifford Wolf called PicoRV32 [0], you can look at the complexity introduced by configuring it with the COMPRESSED_ISA option.

> ...and program memory is at a premium in those places.

Program memory is one thing, but on processors of all sizes, code size has a big impact on performance in common types of program.

[0]: https://github.com/cliffordwolf/picorv32

I'm sorry, did you just describe the core advantage of a new RISC CPU against incumbents as smaller code size? Where am I, and what is happening?

Still matters in many embedded applications.

Code size for RV32IMAC is still pretty mediocre with the current GCC/RISCV compiler. And the standard library they use by default is pretty sub-optimal. I know they're working on it, and it's clear they're making quick progress, but it's not easy at the moment. The last project I worked on, I had to abandon ABI conventions and hand craft large chunks of code.

Smaller code size makes your caches more effective. L1 instruction cache is size limited because it's on a critical timing path. Increasing its size limits your operating frequency.

Is it a core advantage? Maybe. But smaller code size has beneficial effects on the silicon cost. Choice 1: If you can benchmark the same on important work loads with 10% smaller I-Cache, make the die smaller. Manufacturing costs go down with a greater than square law effect with die area. Choice 2: Use the die area freed up to put more functional units in the same area.

Core advantage? I will let others debate that. Significant: surely.

That's a pretty damn good argument. It's 10% ahead of the best ISAs that took decades of development. Just think of how adoption would be affected if it was 30% worse.

In other words: not only is it better in terms of royalties and ecosystem, it also better at everything else too. Isn't that terrific?

I read the GP as talking about how code size was always a weakness of RISC, and seemingly the largest one.

And here it is compared against a classical CISC platform and a hybrid one highly optimized for code size, and winning. What just makes RISC-V even more awesome than just any non-optimized design beating the incumbents.

RISC-V has a code compression extension so it's not classic RISC but it's still far simpler than CISC. https://riscv.org/wp-content/uploads/2015/05/riscv-compresse...

x86-64 isn't very space efficient anymore, so it's not hard to beat. Even AArch64, with a fixed 32-bit instruction size, competes well with x86-64.

REX prefixes really killed the space efficiency of the x86 architecture.

I think this is wrong. Certainly the GCC toolchain spits out some remarkably mediocre code. RISC-V compressed is generally on par with Thumb2, and where it differed, Thumb2 seemed to be a tiny bit more dense.
If you compare GCC/ARM with GCC/RISCV the difference isn't too great, but even the IAR ARM compiler gives you noticeable improvements over GCC/RISCV. And ARM's compilers are actually quite good with respect to code size; MUCH better than GCC/RISCV (or even GCC/ARM).
That being said, were I to add some custom instructions, I would COMPLETELY prefer to do it with RISC-V than with ARM.

[] Though the gcc/riscv toolchain is getting better pretty quickly.

> Risc-V is more efficient and has about 10% denser code, which translates to more instructions fitting in i-cache, less memory pressure, and ultimately better performance and battery life. Long term roadmap, thats a win for Risc-V.

Only in the most extreme cases.

1) Battery life isn't dominated by run current for the vast majority of embedded devices. Sleep current dominates (most cases) or peripheral current dominates (RF transmit/receive, for example). You try to dial down the number of times you turn on until it's below the amount of energy you burn while off.

2) RAM is expensive; flash not so much. Code space isn't the issue--10% almost certainly not. Correlated: this is why I expect you really won't see 64 bits making a lot of inroads into embedded--doubling RAM consumption is expensive on embedded.

I wonder if you can salvage useful RISC-V SoCs from WD disks three or five years down the road. That kind of thing hasn't been useful in the Moore era; now that it's over, maybe it'll make more sense.

I'm not sure what happened with the ATMega. As far as I can tell, Atmel basically stopped developing AVR chips almost entirely around 2006, just selling the old ones; presumably they were having a hard time competing. With Cortex-M0s like the LPC2100? With PICs? With bargain-basement 10¢ Chinese microcontrollers made with obsolete process nodes? I'm not sure. The fact that they eventually sold the AVR line to Microchip makes me suspect it was PIC, but nowadays the chips that look like good AVR alternatives to me are almost entirely 32-bit ARMs.

The reasons they look like good alternatives, though, don't have a lot to do with "differentiation". The AVR was attractive because, as an 8-bit chip, it could be used in places where you couldn't afford a 32-bit or even a 16-bit chip, and it used less power. But then fabrication processes improved to the point where a 32-bit chip costs the same as an AVR, uses less power, runs far faster, and has more memory. Maybe if they'd kept developing the AVR that wouldn't be true — or maybe at that price point almost all the cost goes to dicing, testing, and packaging, which is what you seem to be saying.

> But what about "bigger" systems?… Not the CPU license.

I feel like the major cost of the CPU license is not the money you pay Intel but the built-in IME backdoor it ships with.

Yup. Everything you say is true.

I would add though there are a couple places in the low end where one or two cents seem to matter. Or at least product managers think that it matters.

In the mid-range, RISC-V providers (certainly SiFive) are pushing the idea that it's easy/easier to add custom logic to your RISC-V based die. I'm not able to judge whether that's really true, but since they're starting with a clean slate in terms of interface logic then maybe. I can't imagine it being harder to add your own tile to a RISC-V design than an ARM design.

The tools seem to me to be pretty primitive, though. IAR says they'll have a compiler soonish. GCC still emits some "not completely great" code. (I mean, don't get me wrong, it's not horrible, but compared to the mature toolchains like ARM, Intel & MIPS, it's kind of bad.) Though it's certainly getting better over time.

If you look at the architecture though, it does seem a bit easier to implement than ARM and there's more to open designs than just the "free as in beer" argument.

RISC-V seems to be appealing to people who have a strong desire to "play around with" an architecture or a solution or are financially motivated to add logic that's somehow hard to add to ARM.

> Will it let people build chips for phones like Apple does with their own GPUs and microarchitecture? Sure, and at less cost, but what then does that give the average consumer?

Isn't the biggest benefit of Apple's hardware the user experience enabled by top to bottom ownership of the software and hardware stack? I would imagine being able to replicate that without the enormous upfront design costs would be game changing, but I am not familiar with the unit economics of CPUs.

It is certainly a benefit, and it would allow a handset maker to differentiate their offering more easily than they can with just software. That said, actually building custom chips for a phone is a very high risk spend because you are in a cut throat market for "off brand" phones, you don't know the volumes you can achieve, and the upfront costs of the chip are going to be large. Trying to get the calculus right so that you make money will be quite challenging.

I've only recently become aware of risc-v, but it was in the context of FPGAs. I've been following FPGAs for years, and recently the open tooling is good enough for cheap FPGAs that I'm seeing a lot of projects starting to use them. You can get an FPGA that can simulate a risc-v for $6 in small batches. While you could probably get a much cheaper ARM cpu that is way more powerful, you have an FPGA that can do things that no comparably priced cpu can do, and change it without replacing the chip.

Personally I think having a license free cpu will be an integral part in continuing to make FPGAs more and more viable, and I think we're going to start seeing them in places that no one ever really imagined 15 years ago.

https://hackaday.com/2018/12/25/how-a-microcontroller-hiding...

> but I don't see the vector for getting them into general distribution

There once was a time when Linux was this teeny little player. Many people thought it would never amount to anything. After all Microsoft was the big player, support and tooling for it was everywhere. It was possible to license it for embedded use. The only benefit of Linux was freedom, and that can't possibly be enough of a benefit.

Linux didn't start off competing with Windows, it started off competing with commercial UNIX. (Most people were running Linux on hardware that had Windows licensing costs rolled in.) The price gap between Linux and a "real" UNIX were huge, especially given that you had to buy hardware to match. Is RISC-V really a huge difference in price for any ARM CPU (as opposed to ISA) licensee?

This was discussed just a couple of days ago here as well, so I'll just link to one of my comments there: https://news.ycombinator.com/item?id=19119398

So the answer is: it really depends.

I think RISC-V will quickly infiltrate the invisible on-chip microcontrollers. The ones that manage power regulation, SDRAM calibration training, etc. There is very little friction there.

Then it will slowly enter low cost microcontrollers where cost is absolutely essential.

The high-end will be IMO negligible for years to come.

This! I gave a talk about how difficult it will be for RISC-V to enter the server space: https://rwmj.wordpress.com/2018/05/21/my-talk-from-the-risc-...

For full disclosure, I work for Red Hat and am keeping an eye on RISC-V for servers, and I hope it does succeed but there's a mountain to climb and lots of ways to screw up.

Quite right Linux contributed more to commercial UNIXes downfall than anything else.

For example, gcc was pretty much ignored until Sun started the trend of selling UNIX SDK tooling instead of bundling it with the OS.

> it started off competing with commercial UNIX

It started off as a Unix-like toy/learning-platform that people could run on devices too cheap to run Unix.

Then it evolved into a Unix that people could use on devices too cheap to run real Unixes.

It took the best part of a decade to make it competitive with the other Unixes. What just reinforces your point, I guess.

But there was definitely a time where Linux was competing with Minix, which was low price (affordable to a Hacker) and had more features.

However its development wasn't done in the open and it was not "free" (in the FOSS) sense, so it's usage in a specific setting (e.g. commercial) was not possible. I guess Linux open license played a huge role in its adoption and not just the fact that it was free as in "beer" (compared to expensive traditional Unix systems) - and within a short time it surpassed Minix features. There might be disagreements about technical choices made (see legendary conversation about kernel architecture), but in terms of features it surpassed Minix in a short time (and today sets the state of the art for commercial Unices).

There’s no analogy here.

It only took a few hundred dollars worth of hardware to use Linux back in the day, and a windows license was a significant percentage of that.

To use a chip architecture? It takes a design team and booking of fab time. I.e. 10s of millions of dollars.

That teeny little player profited from the contributions from IBM, Intel, Compaq, Oracle, and nowadays even Microsoft.

Non-copyleft UNIX clones weren't so lucky.

Even if RISC-V succeeds in the market, there isn't any guarantee that we won't have a plethora of incompatible extensions.

A couple things.

Dealing with are is not just % cost, put lawyers and time. If you are small company that is very valuable.

The choice WD made is not about cost but about an architecture that is adoptable adaptability. The whole argument is that you DON'T have to be apply to make it worth it to get a costume chip.

Also, you will have more venders to choice from when doing a product.

> Bottom line is that I think it is great to have the ability to create computers that are not beholden to a certain vendor but I don't see the vector for getting them into general distribution where consumers actually benefit from the change.

End consumers never benefit from any individual technology. They buy product and that work. RISC-V is more important for the overall industry and specially for those interested in open source.

As long as we base everything on proprietary ISA we can not have open chip projects that run lots of common software and that stops open silicon in its tracks, and with that open hardware as a whole.

RISC-V enables open source culture to be even legally possible and making it practically viable.

There is also the market for tv top boxes and a lot more embedded applications for stuff like e.g. remote controllers, IoT and more. Then on top of that you have stuff like the kindle. Think how many copies these market segments have sold. Arm takes a couple cents per copy. Now keep in mind that these are rather small and simple cpus. Some alwinner chips sell for less than 4$ a piece and they sell millions per quarter. That's enough revenue saved for them to cover the moving to RISC-V costs.