SoylentNews is people
SoylentNews
Apple announces Mac architecture transition from Intel to its own ARM chips, offers emulation story
Apple has just announced its plans to switch from Intel CPUs in Macs to silicon of its own design, based on the ARM architecture. This means that Apple is now designing its own chips for iOS devices and its Mac desktop and laptops. Apple said it will ship its first ARM Mac before the end of the year, and complete the Intel -> ARM transition within two years.
Apple will bring industry leading performance and performance-by-watt with its custom silicon. Apple's chips will combine custom CPU, GPU, SSD controller and many other components. The Apple silicon will include the Neural Engine for machine learning applications.
[...] "Most apps will just work".
The Next Phase: Apple Lays Out Plans To Transition Macs from x86 to Apple SoCs
[From] an architecture standpoint, the timing of the transition is a bit of an odd one. As noted by our own Arm guru, Andrei Frumusanu, Arm is on the precipice of announcing the Arm v9 ISA, which will bring several notable additions to the ISA such as Scalable Vector Extension 2 (SVE2). So either Arm is about to announce v9, and Apple's A14 SoCs will be among the first to implement the new ISA, otherwise Apple will be setting the baseline for macOS-on-Arm as v8.2 and its NEON extensions fairly late into the ISA's lifecycle. This will be something worth keeping an eye on.
[...] [In] order to bridge the gap between Apple's current software ecosystem and where they want to be in a couple of years, Apple will once again be investing in a significant software compatibility layer in order to run current x86 applications on future Arm Macs. To be sure, Apple wants developers to recompile their applications to be native – and they are investing even more into the Xcode infrastructure to do just that – but some degree of x86 compatibility is still a necessity for now.
The cornerstone of this is the return of Rosetta, the PowerPC-to-x86 binary translation layer that Apple first used for the transition to x86 almost 15 years ago. Rosetta 2, as it's called, is designed to do the same thing for x86-to-Arm, translating x86 macOS binaries so that they can run on Arm Macs. Rosetta 2's principle mode of operation will be to translate binaries at install time.
See also: Apple Announces iOS 14 and iPadOS 14: An Overview
Apple's First ARM-Based (Mac) Product Is a Mac mini Featuring an A12Z Bionic, but Sadly, Regular Customers Can't Buy It
Previously: Apple Will Reportedly Sell a New Mac Laptop With its Own Chips Next Year
(Score: 0) by Anonymous Coward on Wednesday June 24 2020, @05:21PM
What do ARM provide?
In the typical case ARM *do* provide Verilog to their partners. Typically one is not allowed to change the design although if you have a strong enough case (e.g. some kind of mismatch between the design of components that breaks a reasonable use-case) a waiver is possible. The CPUs in any resulting SoC have to pass a verification test suite before they can be shipped but these rules are enforced through legal measures in the IP license, not technical obfuscation.
What is Apple's contribution?
Some partners have an Architecture license. In the most extreme case this is (a) figuratively a copy of the ARM specification with the "For reference only, you cannot use this to clone an ARM processor" crossed out, (b) a copy of the verification suite and (c) a license to use the relevant ARM patents. The micro-architectural design can start with a blank piece of paper. Other companies might modify an existing design.
All SoC vendors (with or without an Architecture license) have to take all the various bits of IP, from ARM and other companies, and stitch them together, and they have to think about the scenarios they would like to work effectively and plan the size, number and connectivity of those components appropriately. e.g. do you want to allow a 3D game to splat a video file on to some surfaces? Okay, in that case you need an efficient path from the video decoder into the GPU and you need enough bandwidth on the bus to do both simultaneously, or prove to your satisfaction that you can do them in alternate time slices so the bus is never trying to carry the traffic of both the video decoder and the GPU at once. What about a live feed from a camera? Does that mean we need a wider bus? Could we just increase the bus frequency a bit? How does the area of the silicon vary for faster vs wider? Could we settle for either video or live camera input but not both?
Simulations will be run to try to confirm these choices before the design is finished and sent to the fab. Under-spec. it and your SoC won't do all the cool things you had planned for, or not for the planned battery life. Over-spec. it and your SoC will be bigger (more expensive) and potentially less efficient than the competition and customers will go elsewhere.
BTW @KilroySmith, I'm curious about your source for "in general they provide a precompiled block" - that needs correcting.