
Three of Apple and Google’s former star chip designers launch NUVIA - tosh
https://techcrunch.com/2019/11/15/three-of-apple-and-googles-former-star-chip-designers-launch-nuvia-with-53m-in-series-a-funding/
======
ISL
How do people start new ventures like this without falling afoul of past non-
disclosure agreements?

~~~
K0SM0S
Late reply: we don't know the details but it's entirely possible that part of
their knowledge from their experience at Apple is allowed to be used so long
as they do not compete with Apple products using that knowledge; and the
server / enterprise target is clearly the one space where Apple is de facto
absent in tech.

If I were to bet, I'd say it's actually a mutual understanding of 'taking
A-chips' to their full potential for these use-cases. It's also smart to make
it a startup, because why spend the full power of a corporation when a small
tight band is actually better. Sort of a separation of concerns; friendly
relationship, possibly deals between the two entities — I'm sure Apple's
datacenters could use some A-chip mojo in their blades.

~~~
ISL
A reply from the future: looks like Apple is unhappy.

[https://news.ycombinator.com/item?id=21752781](https://news.ycombinator.com/item?id=21752781)

------
ksec
Assuming they are well connected to ARM, I wonder if they get to be working on
uArc based ARMv9?

And I think this also shows that Apple has no intention to build an ARM chip
for its Desktop and Mac Pro products. Had this been the case I think the three
would not have jump the chance for its own Startup.

~~~
PossiblyKyle
They could’ve possibly done this move to get acquired by Apple for a larger
sum than plainly working there

------
hartator
NUVIA =~ NVIDIA. That’s a bad name.

~~~
robocat
New VIA? It looks like VIA are still producing CPUs:
[https://en.m.wikipedia.org/wiki/VIA_Technologies](https://en.m.wikipedia.org/wiki/VIA_Technologies)

~~~
hartator
That's even make things worse!

------
rwmj
Also Jon Masters, ex Red Hat.

------
newshorts
my question to the group is:

How will this affect Apple’s ability to innovate going forward? Were these
executives a crucial part of Apple’s competency?

------
Angostura
Tech Crunch has the foulest of cookie control systems. Not reading that.

~~~
panpanna
Someone please create a mirroring service for HN submissions.

Even Reddit has one

------
rough-sea
I wonder if they are considering RISC-V. Probably not - they don’t sound like
risk-taking people. But given the timelines of chip production, I would think
a couple years from now a solid RISC-V server might be very much in demand.

~~~
Tuna-Fish
The RISC-V ISA is pretty awful for high-end designs. No competitive servers
can be built with it.

Plenty of people seem to have been caught up in the hype of RISC-V taking over
the world and doing everything, but that's never going to happen. The ISA is
heavily optimized towards making very low-end devices very cheap. Like, don't
think cellphone chips, think appliances. This is not a bad call, as it's the
area where greenfield designs with cost advantage have the best chance to get
market share. However, there is no path of extending the ISA that will make it
competitive with ARM or x86 on high-end devices. The only way to do that is to
design RISC-VI, that abandons most of the things that RISC-V what it is.

~~~
tyingq
Interesting view. The SIMD, Vector, and Hypervisor RISCV extensions, as well
as things like OoOE seem to contradict your claim. Are you saying they
intended to target the high end, and failed? Or that they never intended to
target the high end?

~~~
Symmetry
There are a lot of things about the RISCV design that come from a very
ideological place and hurt in a high end design. Yes, there are extensions and
designs with high end features, that's certainly true, and I'm sure people
someone will be making a high end version at some point. But the ISA isn't
very well suited to it compared to Power or ARM.

By default, code density on RISC-V is pretty bad. You can try to solve that by
using variable length instructions which many high end RISC-V projects intend
to do but having variable length instructions means your front end is going to
have to be more complicated to reach the same level of performance that a
fixed width instruction machine can achieve.

More instructions for a task means your back end also has to execute more
instructions to reach the same level of performance. One way to do better is
to fuse together ISA-level instructions into a smaller number of more complex
instructions that get executed in your core. This is something that basically
every high end design does but RISC-V would have to do it far more extensively
than other architectures to achieve a similar level of density on the back end
which makes designing a high end core more complex and possibly uses extra
pipeline stages making mispredicts more costly.

And more more criticisms here:
[https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d99...](https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d9982f7618ef68)

EDIT: But in fairness it looks like conditional move might be getting added to
the bit manipulation RISC-V extension which would fix one big pain point.

This isn't to say that RISC-V is bad. It's simplicity makes it wonderful for
low end designs. It's extensibility makes it great for higher level embedded
uses where you might want to add some instruction that makes your life easier
for your hard driver controller or whatever in a way that would require a very
expensive architecture license if you were using ARM. It's open, which would
be great if you were making a high end open-source core for other people to
use except the Power ISA just opened up so if I were to start a project like
that I'd use that instead.

~~~
zozbot234
> By default, code density on RISC-V is pretty bad.

Code density _with the C extension_ is competitive with x86, which is _very_
good for a RISC. And the C extension is not even that hard on the decoder,
since most or even all 'compressed' instructions have a single uncompressed
counterpart. It's _easier_ to implement than what ARM32 does with Thumb.

> One way to do better is to fuse together ISA-level instructions into a
> smaller number of more complex instructions that get executed in your core.

Insn fusion has in fact been endorsed by the designers of RISC-V as an
expected approach in high-end designs. The RISC-V spec even gives "suggested"
sequences for things like overflow checking, that can be transparently insn-
fused if an implementation supports it.

~~~
Symmetry
Yes, RISC-V's instruction compression is easier to use than Thumb. But there's
a reason no arm server uses compressed instructions and ARM dropped it from
A64.

~~~
atq2119
Enlighten us: what is that reason?

~~~
Symmetry
As far as I can tell the reason is that with variable length instructions you
have a mux layer between fetch and decode that sends the right set of bytes to
the right decode slot. Your first set of 16 bits is certainly going into the
first decoder but your fourth might be going to the second, third, or fourth
depending on previous decoding. Or maybe not, I've only worked with fixed
width instructions when getting into the weeds of processors and only entirely
designed a simple five stage classic RISC myself. So don't take the above too
seriously.

What you should take seriously is that three of the four big RISC ISAs - MIPS,
ARM, and POWER - all have extensions for variable length instructions. They
all use them in embedded systems where program memory size is a big factor in
your bill of materials and reducing that can save you money. But none of them
use it on their high end processors. So I think we can conclude that the
power/transistor cost of fetching a number of variable length instructions per
clock is higher than the cost of expanding the L1 instruction cache to deal
with full size instructions.

~~~
monocasa
At most, you're looking at an extra pipeline stage for all of that. The less
I$ pressure is almost certainly worth it.

The real cost you're looking at is the complexity for instructions to straddle
cache lines and MMU pages, but even then it's less of a deal than you might
think.

~~~
Taniwha
Nope, done right the cost is a layer of 2:1 muxes and some control logic to
pass data between decoders, and 16 flops to hold a partially decoded
instruction between fetch bundles

~~~
atq2119
It's more complicated than that if you want to decode multiple instructions
per cycles, which you have to for high-end designs. I still agree with
monocasa that it's almost certainly going to be worth it for the reduced I$
pressure.

------
unnouinceput
I wish him good luck. The more the merrier for us, consumers.

------
tambourine_man
What’s sad is that he had to exit Apple and found a company. Maybe to sell it
back to Apple in the future.

It seems symptomatic that he couldn’t inside Apple.

Sad that it’s so hard to do some things inside humongous companies. Even when
you’re obviously incredibly talented and accomplished.

~~~
yabadabadoes
I don't see it as sad, the existence of NeXT as a separate entity allowed many
possibilities. I.e. it left room open for a completely different startup to
roll new tech directions back into Apple and NeXT to end up as new direction
at SGI, HP or whatever. Even if the end looked a lot like the status quo
should have looked, a wider range of possibilities shape the industry and
individual motivation.

~~~
tambourine_man
The fact that Jobs had to found another company is unfortunate and symptomatic
to me.

There’s no reason why huge companies can’t foster innovation, besides bad
management. See Bell Labs and Xerox Parc.

You would think a place with almost unlimited money for R&D would be perfect
for nurturing an ambitious project, but instead most go for VC.

What’s sad to me is that it’s cheaper and easier to buy a startup than to fix
broken culture, given a large enough company.

~~~
yabadabadoes
Bell and Xerox are great examples of why. If the ideas were separate entities,
Bell or Xerox could have decided which to buy back and run as a business. They
didn't decide anything and each idea had to be stolen by a visitor.

------
dang
Related and recent:
[https://news.ycombinator.com/item?id=21547850](https://news.ycombinator.com/item?id=21547850)

------
known
Alternative to RISC-V? [https://archive.is/fFw5T](https://archive.is/fFw5T)

------
jaytaylor
Is it possible or probable they'll go into mobile chips to compete with
Qualcomm?

In any case, best wishes and godspeed. I believe an increase in competition in
the CPU space is good for humanity and only improves our chance of surviving
as a species.

~~~
stevenwoo
Apple is already doing this(mobile chips part), opening or expanding offices
in San Diego/Austin for chip design based on public announcements, job
openings, personnel changing companies.

~~~
Leherenn
They're not really competing with Qualcomm though, since they don't sell their
chips.

------
scarface74
Let’s be honest. They aren’t building a company to take on Intel and AMD. They
are at most “building a company” to either be an acquisition for one of the
major chip producers (maybe even Apple) or to be acquihired.

~~~
myrandomcomment
Building a company to sell is a very bad thing to do. There is no guaranty it
will even happen. You should always build a company with the idea that you
will go public as doing so forces discipline in how you do things (there are a
ton of internal processes, accounting, etc.). Having that work done and clean
makes you more attractive to someone that would want to acquire the company
and also gives you a better negotiating position. In an ideal world, you build
it to go public and are at a point where you are starting the paperwork, and
someone makes an offer which you can then shop to their biggest competitor in
the space. A bidding war starts and you are sold for IPO price++++, a number
that is 12 months down the road from where you think you would be after the
IPO. You have just made a ton, and removed a years worth of risk.

~~~
scarface74
_You should always build a company with the idea that you will go public as
doing so forces discipline in how you do things_

How did that work out for Uber, Lyft, and closer to home DropBox? They all
went public and still haven’t shown that they have any idea how to become
profitable.

~~~
valuegram
It worked out very well for the founders of all of those companies.

~~~
pstuart
While I admit that I'd take the money and run too, that kind of approach when
viewed from afar looks like a genteel pump and dump.

~~~
scarface74
I don’t begrudge them their money. But I feel a lot more at ease depending on
a company whose business model is I give them money and they give me stuff and
that they are doing so profitably. That’s part of the reason that I’m a big
fan of companies like Backblaze and JetBrains.

I worked as a dev lead for one company where we were our vendors largest
customer (over 60% of their revenue). I recommended that we either don’t
depend on that vendor for our new implementation when contract renewals came
or that we insisted on them putting their code in escrow in case they were
sold and they abandoned the software.

------
discardable_dan
While I like this idea, I think supporting a full x86-64 instruction set for
high-performance applications, from scratch, is likely years out. This company
will need a 10-year runway to see any market impact.

~~~
throwGuardian
Where is x86-64 mentioned? I assumed they were building ARM chips.

In any case, they don't mention any secret sauce. Intel has strong channels,
fabs and the x86-64 ISA with massive software compatibility on the server
side. Even with better performance/power, Intel can simply undercut the
competition to drive them out of business. If Qualcomm's sales channels
couldn't dent the server space, I am sceptical about upstarts, unless their
[power, performance, cost] is significantly better than Intel.

~~~
chrisseaton
Are there any chips which support multiple ISAs? Could a single chip decode
both AMD64 and ARM instruction streams? Or could the memory models not be
unified so it's not possible?

~~~
als0
Yes there are chips that support multiple ISAs...although typically one ISA is
more native. At least, I believe NVIDIA Denver qualifies as that[1]. Also I
believe some Itanium chips had a (slow) x86 hardware decoder that changed the
instructions into the native EPIC instruction set[2].

However, unifying the memory models sounds like a performance disaster for the
ARM code. And having multiple decoders in hardware (as well as having enough
of them) doesn't seem like a justifiable use of silicon real estate.

[1]
[https://en.wikipedia.org/wiki/Project_Denver](https://en.wikipedia.org/wiki/Project_Denver)

[2]
[https://www.techsupportalert.com/pdf/r1048.pdf](https://www.techsupportalert.com/pdf/r1048.pdf)

~~~
my123
The x86 hardware decoder on Itanium turned out to be slower than a JIT, and
was removed from hardware pretty quickly.

Also note that the x86 memory model is a perfectly valid implementation for an
ARM chip, as it's a superset of the ARM memory model constraints. And the
performance impact isn't that big really.

~~~
als0
Yes, I agree with you. Many of the barrier instructions will end up as
internal NOPs. Performance wouldn't be terrible. Power may suffer.

------
russler23
TechCrunch has more details than Reuters does. Such as confirming ARM ISA, but
custom arch. [https://techcrunch.com/2019/11/15/three-of-apple-and-
googles...](https://techcrunch.com/2019/11/15/three-of-apple-and-googles-
former-star-chip-designers-launch-nuvia-with-53m-in-series-a-funding/)

~~~
dang
Ok, we changed to that from [https://www.reuters.com/article/us-nuvia-tech-
idUSKBN1XP19V](https://www.reuters.com/article/us-nuvia-tech-idUSKBN1XP19V).
Thanks!

------
gigatexal
Nuvia like the ring ;)

------
keymone
Any news from Mill computing?

------
rvnx
I wonder what Apple thinks once they will see their IP exfiltrated like this

~~~
dmix
I’m sure that would be the first thing the VCs would ask about before putting
$50m into the business.

The three worked on mobile chips at Apple and Google, and are now focusing on
enterprise data centres. So it’s not exactly the same.

> That said, what’s interesting is that while the troika of founders all have
> a background in mobile chipsets, they are indeed focused on the data center
> broadly conceived (i.e. cloud computing), and specifically reading between
> the lines, to finding more energy-efficient ways that can combat the rising
> climate cost of machine learning workflows and computation-intensive
> processing.

> The company’s CMO did tell me that the startup is building “a custom clean
> sheet designed from the ground up” and isn’t encumbered by legacy designs.
> In other words, the company is building its own custom core, but leaving its
> options open on whether it builds on top of ARM’s architecture (which is its
> intention today) or other architectures in the future.

~~~
rvnx
It can simply be a form of risk-management by Dell/VCs. How likely is that
Apple going to sue them? How likely the company going to succeed and deal with
the issue?

It's rarely black or white.

We have seen it with the case of Uber and the self-driving cars.

In their own words, they said they will reuse knowledge from ARM and Apple
(including Desktop CPUs).

As public investor of Apple, yes I think it's a very legitimate question.

~~~
dmix
Of course it's a legitimate question, it's an obvious question, which is why
the CMO mentioned clean room building it and the founders having worked on a
combined 100 patents. VC's do plenty of due-diligence, they don’t invest
blindly when there’s such an obvious risk.

The Uber case was quite rare and egregious. It's not as simple as working on
similar stuff.

Uber directly acquiring a company (well after raising hundreds of millions)
made by someone who worked at Google to work on the exact same thing which is
far riskier than working on a completely different product category you're
building from scratch. But even then the case against Uber heavily relied on
the fact he _stole_ IP directly from company computers and used that as the
base of the product.

