Speaking of ARM, I still can't figure out how ARM was acquired for $32B. I
f even a student can make a synthesizable 32-bit processor in a few weeks,
how much value can there be in a processor? It's almost a commodity. I kn
ow there is a lot of value in prediction pipelines, cache logic, compilers,
etc., but not $32b' worth.
So, maybe the people who SOLD it are laughing their way to the bank.
ARM processor variants have a huge installed base -- I suspect that went
a long way to justifying the $32B. But, if ST started offering parts
with the RISC-V core tomorrow, at a better price, I'd switch.
You would. I probably wouldn't, having a larger team to drag around and
all of the associated infrastructure.
But the cell phone companies, with all that already written codebase and
10s of millions of units sold per year? Not a chance they do. That's
billions of dollars of inertia.
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
The probably have a pretty good revenue stream. I don't remember what
they get per processor instance, but pretty much all the major
semiconductor houses, and several of the fabless ones are shipping
products with ARM processors in them. They are showing up in all kinds
of ASICs as well.
Also, coding a synthesizable, 32 bit processor is only the beginning.
Verifying it, implementing a silicon validation suite, getting compiler
and debugger support and getting all of that stable and accepted are
pretty big tasks. ARM has been at this project for a LONG time (early to
mid 90's that I know of, maybe longer). That's a lot of customer experience.
Having a uniform (fairly, anyway) ecosystem on multiple vendors is worth
some to me. I like that the I/O, Interrupt, power control and clock
generation stuff is at least recognizable from vendor to vendor.
I can't say whether it is all worth $32B, but I guess it was to somebody...
I probably have 20 lines of ARM assembly written, and in retrospect that
could just as well be carefully-crafted C. Assuming that FreeRTOS makes
a port, everything else is C or C++, and could just be compiled for the
I don't know about the cell phone companies -- are they really that
heavily invested in processor-specific stuff?
This design has processors plus other interconnecting logic. Hard to
say how much is processor. Taking it all as processor gives around 1.54
kLCs per processor. There are lots of processors that are much smaller
I don't see *any* info on the speed of these processors, so I don't know
what the "fast" claim is based on.
The value of a company is not directly related to technology. There are
many ways to make a buck and making a buck is what the value of a
company is about.
Anyone can make hamburgers, but McDonalds seems to have done well over
Assembly language code is not the only way to be wedded to an
architecture. There are lots of C code written to manage the CPU and
tightly coupled functionality not to mention optimizing code for maximum
performance in an architecture. Then there is the effort required to
optimize the tools. Yes, it is easy to port tools, but to get them
honed for optimal usage requires a lot more effort. I doubt that has
been done for the RISC-V as yet.
A sizeable part of that is hidden in the three key components - the OS
kernel, the basic libraries, and the compiler. The huge majority of the
code on a telephone is cpu agnostic. Most of it got bumped from 32-bit
ARM to 64-bit ARM without much bother, and the 32 to 64 bit jump is
often a bigger port issue than moving between different 32-bit
I don't know if the current state of these RISC-V tools are good enough,
however - I believe the Linux port of RISC-V is quite new, and the gcc
port has just been redone. For the big customers, they will want to see
a bit of maturity before considering RISC-V.
For us mere mortals, however, RISC-V is a great idea. If nothing else,
it gives ARM some much-needed competition (which should have come from
They didn't buy ARM so much as they bought a concept with a business model
that many companies had foolishly signed up to accept - that's where the
valuation comes from. The actual commodity - like those of pyramid schemes -
(which is what IP is effectively) - is mostly irrelevant.
and yes - a student can design "A processor" - but one that fulfills a market need
that "significantly" (and underlined) moves the market forward adding value
in power, performance, size, manufacturability and so on - is not so easy to do.
(Trust me - I'm working on ideas myself - it's not trivial at all)
Yes, those "many companies" are crying all the way to the bank.
The pyramid is at the basis of most business models. It's a great idea
actually and everyone participates voluntarily.
Any yet, ARM seems to be doing very well adding value for all the chip
The proportion of the code to be modified is not relevant, only the
amount. It is also not relevant where the code resides. If you want to
port to a new processor you will have to touch every bit of code that is
specific to the processor, period.
I had the impression MIPS is still a viable contender in many markets,
but mostly built into ASICs.
I wonder how important the royalties are when designing a CPU into an
SOC. I believe the RISC-V is totally royalty free. But I'm not
familiar with the BSD license, but I think it allows for commercial
versions. So a company may spring up that adds significant value and
Yes and no. Everything that David quotes are things that are spread out
over many users and -- with the possible exception of the OS kernel --
are not proprietary. So in commercial terms there's a large customer
base to amortize the cost over -- in open-source terms anyone offering
paid support for the processor would get paid, and the starry-eyed
idealists will do it to help the large number of potential users.
Control systems, embedded software and circuit design
Processor clock speed is 300-375 MHz
in a Kintex UltraScale. Placement constraints are required to get this
kind of clock speed, something that Jan Gray is very good at. Follow the
link to the 'Best Short Paper Award' for more details on how the logic
is partitioned between processor and router. For another perspective on
I agree, but I would not call risc-v (the ISA) "open source". It is an
Two added advantages are (I think)
- that it is free of patents (so everybody can implement it)
- it is designed to be extensible from the ground up.
Well, what sets is appart from most (if not all) other ISAs is that
risc-v is *designed* to be extensible.
This is not only about the official "M, A, F, D, Q, C, P" extensions.
Everybody can just extend the ISA with their own "optimised for my
Concidering one of the core members of the risc-v concortium: NVIDIA.
This means that they are able to take the risc-v ISA and extend it (e.g.
for GPU or passive-parrallel related technologies) and sell chips based
on a "RISC-V + NVIDIA" ISA.
The only thing that is not clear for me is if they can still call this
"risc-v", or what would be the correct naming for this kind of "extended
I would like to point out that the ISA does not mandate that a
implementation needs to be open-source or that you need share it.
It is completely free for a company to come up with their closed-source
implementation of the ISA standard and sell it, either as silicon or as
Or, you can "mix-match" licenses. Sifive (the company that sells the
E310 CPU and hifive devboards) are an interesting example of this.
They open-sourced the RTL design but keep the knowledge of actually
implementing a risc-v core as optimised as possible for themselfs, as a
service to sell.
I would put it like this:
What Risc-v does is, by removing the need of licensing the basic ISA,
that it allows companies to come up with services they want to sell,
without being limited by a license to somebody else who has its own
Althou risc-v is usually equated with "open source", I think it is more
then just that.
Cheerio! Kr. Bonne.
This doesn't really address the original issue which was the wedding of
a user to a CPU ISA/processor. All of this has been done for the ARM
and done very well. The fact that very little of the code used in a
product is assembly is not the important fact. To change architectures
a user will want to know that all of the above things have been done and
done well in addition to the work involved in the *user* coming up to
speed with a new ISA/processor.
I don't believe for a minute that CPU users are largely CPU agnostic
even if most of the code it. "Most of the code" doesn't mean most of