Live data from Hacker News

Arm is canceling Qualcomm's chip design license

bloomberg.com

391–400 of 480 posts

Re: Arm is canceling Qualcomm's chip design license

#391

Because of all the discussions in the comments about ARM and RISC-V, could someone explain to me the difficulties of designing a chip for a new ISA? I'm wondering because to me as a layman it sounds like it's 'only' a different language, so why is it not that easy to take already existing designs and modify them to 'speak' that language and that's it? Or is an ISA more than just a different 'language'? Or is hardware…

It's not about the chip itself at all, it's about the software that runs on it. My Computer Architecture professor always used to say, nobody wants to recompile their code!

There are still binaries that were compiled in the 80s running happily on an x86 system because the chip conforming to the ISA guarantees that machine instruction will run the same as it did in the 80s.

As for "only" a different language, absolutely lots of software does this. As part of Apple's move from x86 to ARM, they implemented a software called Rosetta which translates x86 instructions into ARM (also known as emulation). The only problem with this is that there's a performance penalty you pay for the emulation, which can make using a program slower, choppier, etc.

Re: Arm is canceling Qualcomm's chip design license

#392

Earlier quoted context omitted.

There’s so many sub varieties of the standards. You’re making a gross oversimplification that they’re “the same”. Compare intel vs Qualcomm modems that were released on iPhones. They were “the same” standard but the Qualcomm modems were notably faster in testing. Maybe they’re all at parity these days, but it’s pretty hard to do a fair comparison.

By all means, point to some official statement showing that Google cannot market the Pixel phone as supporting the 4g/5g standards due to Google's use of Samsung modems.

You’re not hearing what I’m saying. I’m saying that Qualcomm historically has supported more advanced 4g and 5g standards that allow them to achieve faster modem rates. Whether that’s true today I’m not sure, but it was definitely true back when Intel was making modems. “Supporting 4g/5g” is meaningless. It matters what bands, what data rates, the sub carrier rates, how many channels you can bond together, etc etc. Take a look at the product briefs of each modem and compare the actual “supported features” and it’s a lot more specific than just “5g” and certain bands, for instance.

Re: Arm is canceling Qualcomm's chip design license

#393

Earlier quoted context omitted.

> If NVidia wanted their GPUs to work on Raspberry Pi, then it would already be done. It wouldn’t be an issue. But NVidia doesn’t care, because that’s not a real market for their GPUs. It's weird af that Geerling ignores nVidia. They have a line of ARM based SBCs with GPUs from Maxwell to Ampere. They have full software support for OpenGL, CUDA, and etc. For the price of an RPi 5 + discreet GPU, you can get a Jetson…

> It's weird af that Geerling ignores nVidia. “With the PCI Express slot ready to go, you need to choose a card to go into it. After a few years of testing various cards, our little group has settled on Polaris generation AMD graphics cards. Why? Because they're new enough to use the open source amdgpu driver in the Linux kernel, and old enough the drivers and card details are pretty well known. We had some success w…

I mean in terms of his quest for GPU + ARM. He's been futzing around with Pis and external GPUs and the entire time you've been able to buy a variety of SBCs from nVidia with first class software support.

Re: Arm is canceling Qualcomm's chip design license

#394

Earlier quoted context omitted.

> attempting to turn RISC-V into Arm64 but without the restrictions This flew past me, do you have a link?

Brucehoult mentions it further down. > This time last year they were all over the RISC-V mailing lists, trying to convince everyone to drop the "C" extension from RVA23 because (basically confirmed by their employees) it was not easy to retrofit mildly variable length RISC-V instructions (2 bytes and 4 bytes) to the Aarch64 core they acquired from Nuvia. At the same time, Qualcomm proposed a new RISC-V extension that…

I don't really see how this follows. Fixed length instructions are a well known and highly desirable property for instruction decoders (at the cost of some density), which has been known about and done since the first RISCs. And ARMv8 is basically just a warmed-over RISC with very little new or innovative in there. It's just an ISA.

ARM Ltd is basically rent-seeking on keeping the ISA proprietary, same as Intel and AMD do. Sure it's a highly specialized and very impressive task to make an ISA, but not to the value of extracting hundreds of millions of dollars ever year. If ARM gets upset because someone wanted fixed-length instructions standardized in RISCV that's really the height of hypocrisy.

Re: Arm is canceling Qualcomm's chip design license

#395

Earlier quoted context omitted.

They’re open standards, sure, but there is almost no competition in the cellular modem space. Intel tried and failed spectacularly. Apple bought the scraps of the Intel modem business and still hasn’t released their own modems after… 5 years? Cellular tech is hard and has a lot of esoteric requirements. If you want a cell modem for a smartphone, you essentially buy either the latest and greatest from Qualcomm or you…

Samsung, Huawei and MediaTek SOCs implement the same open 4g/5g standards. Apple's modem is said to be shipping this coming spring in the newest iPhone SE iteration. Google's Pixel phone lineup has used Samsung's modems for generations now.

Google's Pixel handsets have worse modem performance than similar flagship Samsungs sold in the US, as even Samsung won't sell their underperforming Exynos chipsets in their flagship phones in the USA.

Exynos 5G New Radio chipsets got really bad with the Pixel 6 series, where the phone randomly loses cell signal and WiFi at the same time in areas with strong signal, and the only way to get back online is to put the phone in airplane mode or reboot the phone, sometimes neither works though.

Re: Arm is canceling Qualcomm's chip design license

#396

Earlier quoted context omitted.

There’s so many sub varieties of the standards. You’re making a gross oversimplification that they’re “the same”. Compare intel vs Qualcomm modems that were released on iPhones. They were “the same” standard but the Qualcomm modems were notably faster in testing. Maybe they’re all at parity these days, but it’s pretty hard to do a fair comparison.

By all means, point to some official statement showing that Google cannot market the Pixel phone as supporting the 4g/5g standards due to Google's use of Samsung modems.

Google certainly tortured me and everyone else I knew who had a Pixel 6 (or Pro) phone, you would randomly lose cellular and WiFi and they would not recover on their own, necessitating a reboot or toggling airplane mode to get back online.

The Exynos chipset is cursed, Samsung only ships it in markets where performance is a lower priority than price, hence not shipping Exynos in the US outside the Google Pixel whitelabel relationship.

Re: Arm is canceling Qualcomm's chip design license

#397

Earlier quoted context omitted.

Brucehoult mentions it further down. > This time last year they were all over the RISC-V mailing lists, trying to convince everyone to drop the "C" extension from RVA23 because (basically confirmed by their employees) it was not easy to retrofit mildly variable length RISC-V instructions (2 bytes and 4 bytes) to the Aarch64 core they acquired from Nuvia. At the same time, Qualcomm proposed a new RISC-V extension that…

Not a cpu designer, but aren’t variable length instructions a big part of why x86 decoders take up so much area, and also increases branch predictor complexity?

x86 specifically is extra awful to decode because there's no easy way to tell the instruction length without doing a good portion of the decode process, so it ends up needing to attempt to decode at each byte offset. Valid lengths being all between 1 and 15 doesn't help.

So processing a fetched 16 bytes requires doing 16 partial decodes, each of them non-trivial (skip over unordered prefix bytes; parse fixed prefix before opcode (most bytes are the opcode immediately, except 0x0F, 0xC4, 0xC5, and more for rarer instructions & AVX-512/APX, which have extra skipping necessary); index a LUT by the opcode (with a different table for the 0x0F case, and maybe more cases idk; plus maybe some more length depending on byte after opcode; for some opcodes the length even depends on if a specific prefix byte was given, which intel just assumes doesn't happen and behaves slowly if it does); if the opcode needs ModR/M, also parse that from the next byte (another variable-length sequence)).

Re: Arm is canceling Qualcomm's chip design license

#398
post #363

Earlier quoted context omitted.

Just the impact of making this move will have a chilling effect, regardless of the long term outome. ARM Ltd wants to position itself as the ISA. It is highly proprietary of course, but the impression they want to give is that it is "open" and freely available, no lock-in, etc. This really brings the reality back into focus that ARM controls it with an iron fist, and they're not above playing political games and sidi…

I don’t understand how they can copyright just the ISA. Didn’t a recent Supreme Court case in oracle v google Java issue decide that you can copy the api if you impelement it differently? So what exactl is arm pulling? Implementation hardware specs? I suspect Qualcomm can do that on its own

> Dudn’t a recent Supreme Court case in oracle v google Java issue decide that you can copy the api if you impelement it differently

No, it didn’t. It ruled that the specific copying and use of that Google did with Java in Android was fair use, but did not rule anything as blanket as “you can copy an API as long as you re-implement it”.

Re: Arm is canceling Qualcomm's chip design license

#399

Earlier quoted context omitted.

> verification of a very high-powered RISC-V core that is going to be manufactured in high-volume is probably much more expensive and time-consuming than the case for an ARM design. Why do you say this?

Presumably, when you have a relationship with ARM, you have access to things that make it somewhat less painful: - People who have been working with spec and technology for decades - People who have implemented ARM machines in fancy modern CMOS processes - Stable and well-defined specifications - Well-understood models, tools, strategies, wisdom I'm not sure how much of this exists for you in the RISC-V space: you're…

There is a market for RISC-V design verification.

And there is already some companies specializing on supplying this market. They do consistently present at RISC-V Summit.

Re: Arm is canceling Qualcomm's chip design license

#400
post #331

Earlier quoted context omitted.

A well-designed (by apple [1], by analyzing millions of popular applications and what they do) instruction set. One, where there are reg+reg/reg+shifted_reg addressing modes, only one instruction length, and sane useful instructions like SBFX/UBFX, BFC, BFI, and TBZ. All of that is much better than promises of a magical core that can fuse 3-4 instructions into one magically. [1] https://news.ycombinator.com/item?id=3…

1 - thank you 2 - thank you again for sharing your eink hacking project!

Note that these are just a person's own opinions, obviously not shared by the architects behind RISC-V.

There are multiple approaches here. There's this tendency for each designer to think their own way is the best.

Post reply on HN