4 ms·

No... This is contracts 101, and furthermore, how fabs want to manage IP. If you want ARM, you play by ARM's rules. Or you don't get to use the license. Either

No... This is contracts 101, and furthermore, how fabs want to manage IP. If you want ARM, you play by ARM's rules. Or you don't get to use the license. Either ARM is about to learn a valuable lesson about knowledge wanting to be free, or Qualcomm is the about to get beaten with the lawsuit bat. I think it's ludicrous we even bother with this daftness, but seeing as everything has to revolve around money, it is what it is.

dkjaudyeqooe 4y ago
It's not really contracts 101, it's a question of what's in the contract that ARM is relying on. They're basically saying you can't transfer any IP without their permission. Who would agree to those terms, if creating IP is your business, and how could Qualcomm miss that if it was clearly stated in the contract? I just can't see Qualcomm's lawyers flubbing this one. They are an extremely aggressive company when it comes to IP and the law. It's not like they don't have top notch IP lawyers. If ARM persists in this stupidity my money is on Qualcomm tearing them a new one.
- robert_foss 4y ago
  Apparently having approval be a requirement is standard for ARM ISA licenses, it would probably not seem strange to them. Besides, Nuvia would have been their own company at the time of signing this contract.
- scarface74 4y ago
  Who would approve of those terms? A tiny startup that needs an ARM license to create ARM server chips. Also see a multi trillion dollar company that has to deal with onerous terms for cellular chips from Qualcomm because there is no viable alternative.
- salawat 4y ago
  I'm still getting contract 101 vibes. As a software person, it's taken me a bit of time to absorb the difference between the idea pf IP in software, and in hardware, but once you bridge that, it does simplify things a bit. ARM seems to be the AWS of hardware IP cores. It is very much the case that if someone is basing a design off their base designs, that comes with granting ARM a thumb on the scale, and a place at the negotiating table if two of their (ARM's) customers engage in an M&A. Qualcomm licensed stuff for handsets. Nuvia licensed stuff for servers. The new composite entity is still constrained by both contracts, which requires an IP firewall. If, on the other hand, Qualcomm wanted Nuvia due to their server core IP, and does not intend to merely consume that company's blackboxed output, then they need to renegotiate terms with ARM, either acquiring a second license for Qualcomm proper, or paying whatever fees are customary for a transferrable license. In the end, it's unsexy paperwork. But I get it though. If you dig into semiconductor/hardware lit, like things on logic locking, that entire industry of fabless semi-conductor fabrication has a Jesus Nut in terms of license enforcement. The prospect of physical design/mask theft or unauthorized design reproduction in a way substantially different, and much more tangible than software is. It really annoys me that someone somewhere describes this as "piracy", because it isn't really, it's straight up breach of contract/unauthorized use of physical design masks. Like getting the printing plates from a mint. Frankly, I've been skeptical of the entire thing, because it does basically rely on manufactured scarcity/info asymmetry created and maintained through legal means, but no one exactly asked either for my input, or seems open to being told not to try to monetize something you can only collect on by essentially parking lawyers at strategic points in the business lifecycle. From a theoretical system point of view it works. From an execution point of view... Not so much.
smoldesu 4y ago
Yes, you're right; but I think the parent comment was suggesting something else. ARM is in a weird spot right now, it's a licensed ISA with dozens of extensions and prefabbed cores, but mounting competition on all sides. Everyone that isn't Apple is woefully unequipped to make ARM desktop chips, and even on the server side of things ARM is struggling to fend off x86 in every category except raw value. That mostly leaves them with a low-margin embedded market to cater to, which could just as easily get poached by RISC-V once Chinese manufacturers are designing their own cores for pennies on the dollar. In fairness, ARM's ownership of the ARM ISA couldn't be an advantage very long. Much like x86, ARM is just old nowadays. Unless you're supplanting it with a half-dozen ISA extensions and additional hardware, it's a hard sell for anything other than embedded/minimalist applications. Which makes it all the more odd that ARM is picking legal fights instead of making it easier for customers to adopt their (proprietary!!!) instruction set. My untrained, unsolicited opinion is that ARM is just pivoting to support their pre-existing customers and lock-down the money makers.
- renox 4y ago
  > Much like x86, ARM is just old nowadays I disagree: ARM64 is from 2011, it's not that old and it was a significant ISA makeover.
  - snvzz 4y ago
    They lost thumb2's advantage in code density. Thumb was what made ARM a good ISA. I have no idea what ARM's thinking at this point.
    - brucehoult 4y ago
      Yup. ARMv4T (two modes with 32 bit and 16 bit instructions) was what got ARM's foot in the door with Nokia, but it was Thumb2 (ARMv7) that sealed the deal and led directly to ARM's current dominance in mobile and embedded. Abandoning all that for a fixed-length 32 bit opcode 64 bit instruction set with just barely better code density than original ARM (and dropping the stuff that made sense in 1985 but doesn't today, such as predication everywhere and load/store multiple) just looked like lunacy to me in 2012 when I read the Aarch64 manual, and looked even worse when RISC-V came out with a 64 bit instruction set using the same basic idea as Thumb2. If you're doing very wide instruction decode then two instruction lengths is a little harder to handle then one, but not enough to matter, at least at 8- or 16-wide. You can EITHER 1) put a 2:1 32 bit mux in front of half of the decoders if you don't want much extra hardware, OR 2) build 50% more decoders and put bigger 2:1 muxes on the outputs of the decoders. The latter is slightly faster because you have to examine 2 bits out of each 16 bit parcel in the instruction stream to decide which mux input to choose, and option 2) lets you do that in parallel with the decoding instead of having to do it before the decoders. It's just completely incomparable to doing wide decode on x86_64 where you have to deal with 1-15 byte instructions with an arbitrary number of prefix bytes and several opcode bytes to decode before you know the length of an instruction, and therefore where the next instruction starts. If the first instruction starts at offset 0 then the second instruction can start anywhere from offset 1 to 16, the third instruction can start anywhere from offset 2 to 31, the fourth instruction anywhere from offset 3 to 46 etc.

dkjaudyeqooe 4y ago

It's not really contracts 101, it's a question of what's in the contract that ARM is relying on. They're basically saying you can't transfer any IP without their permission. Who would agree to those terms, if creating IP is your business, and how could Qualcomm miss that if it was clearly stated in the contract? I just can't see Qualcomm's lawyers flubbing this one. They are an extremely aggressive company when it comes to IP and the law. It's not like they don't have top notch IP lawyers. If ARM persists in this stupidity my money is on Qualcomm tearing them a new one.

robert_foss 4y ago
Apparently having approval be a requirement is standard for ARM ISA licenses, it would probably not seem strange to them. Besides, Nuvia would have been their own company at the time of signing this contract.
scarface74 4y ago
Who would approve of those terms? A tiny startup that needs an ARM license to create ARM server chips. Also see a multi trillion dollar company that has to deal with onerous terms for cellular chips from Qualcomm because there is no viable alternative.
salawat 4y ago
I'm still getting contract 101 vibes. As a software person, it's taken me a bit of time to absorb the difference between the idea pf IP in software, and in hardware, but once you bridge that, it does simplify things a bit. ARM seems to be the AWS of hardware IP cores. It is very much the case that if someone is basing a design off their base designs, that comes with granting ARM a thumb on the scale, and a place at the negotiating table if two of their (ARM's) customers engage in an M&A. Qualcomm licensed stuff for handsets. Nuvia licensed stuff for servers. The new composite entity is still constrained by both contracts, which requires an IP firewall. If, on the other hand, Qualcomm wanted Nuvia due to their server core IP, and does not intend to merely consume that company's blackboxed output, then they need to renegotiate terms with ARM, either acquiring a second license for Qualcomm proper, or paying whatever fees are customary for a transferrable license. In the end, it's unsexy paperwork. But I get it though. If you dig into semiconductor/hardware lit, like things on logic locking, that entire industry of fabless semi-conductor fabrication has a Jesus Nut in terms of license enforcement. The prospect of physical design/mask theft or unauthorized design reproduction in a way substantially different, and much more tangible than software is. It really annoys me that someone somewhere describes this as "piracy", because it isn't really, it's straight up breach of contract/unauthorized use of physical design masks. Like getting the printing plates from a mint. Frankly, I've been skeptical of the entire thing, because it does basically rely on manufactured scarcity/info asymmetry created and maintained through legal means, but no one exactly asked either for my input, or seems open to being told not to try to monetize something you can only collect on by essentially parking lawyers at strategic points in the business lifecycle. From a theoretical system point of view it works. From an execution point of view... Not so much.

smoldesu 4y ago

Yes, you're right; but I think the parent comment was suggesting something else. ARM is in a weird spot right now, it's a licensed ISA with dozens of extensions and prefabbed cores, but mounting competition on all sides. Everyone that isn't Apple is woefully unequipped to make ARM desktop chips, and even on the server side of things ARM is struggling to fend off x86 in every category except raw value. That mostly leaves them with a low-margin embedded market to cater to, which could just as easily get poached by RISC-V once Chinese manufacturers are designing their own cores for pennies on the dollar. In fairness, ARM's ownership of the ARM ISA couldn't be an advantage very long. Much like x86, ARM is just old nowadays. Unless you're supplanting it with a half-dozen ISA extensions and additional hardware, it's a hard sell for anything other than embedded/minimalist applications. Which makes it all the more odd that ARM is picking legal fights instead of making it easier for customers to adopt their (proprietary!!!) instruction set. My untrained, unsolicited opinion is that ARM is just pivoting to support their pre-existing customers and lock-down the money makers.

renox 4y ago
> Much like x86, ARM is just old nowadays I disagree: ARM64 is from 2011, it's not that old and it was a significant ISA makeover.
- snvzz 4y ago
  They lost thumb2's advantage in code density. Thumb was what made ARM a good ISA. I have no idea what ARM's thinking at this point.
  - brucehoult 4y ago
    Yup. ARMv4T (two modes with 32 bit and 16 bit instructions) was what got ARM's foot in the door with Nokia, but it was Thumb2 (ARMv7) that sealed the deal and led directly to ARM's current dominance in mobile and embedded. Abandoning all that for a fixed-length 32 bit opcode 64 bit instruction set with just barely better code density than original ARM (and dropping the stuff that made sense in 1985 but doesn't today, such as predication everywhere and load/store multiple) just looked like lunacy to me in 2012 when I read the Aarch64 manual, and looked even worse when RISC-V came out with a 64 bit instruction set using the same basic idea as Thumb2. If you're doing very wide instruction decode then two instruction lengths is a little harder to handle then one, but not enough to matter, at least at 8- or 16-wide. You can EITHER 1) put a 2:1 32 bit mux in front of half of the decoders if you don't want much extra hardware, OR 2) build 50% more decoders and put bigger 2:1 muxes on the outputs of the decoders. The latter is slightly faster because you have to examine 2 bits out of each 16 bit parcel in the instruction stream to decide which mux input to choose, and option 2) lets you do that in parallel with the decoding instead of having to do it before the decoders. It's just completely incomparable to doing wide decode on x86_64 where you have to deal with 1-15 byte instructions with an arbitrary number of prefix bytes and several opcode bytes to decode before you know the length of an instruction, and therefore where the next instruction starts. If the first instruction starts at offset 0 then the second instruction can start anywhere from offset 1 to 16, the third instruction can start anywhere from offset 2 to 31, the fourth instruction anywhere from offset 3 to 46 etc.