Earlier this year, Intel drastically cut their mobile product line, dropping SoFIA and Broxton from their roadmap completely. At the same time, Intel also reduced their work on porting new versions of Android to x86 processors, leading many to suspect that Intel was pulling out of the Android phone space completely, with their attempts to catch up in the mobile sector being called a $10 billion waste.
Intel quickly commented that they would continue to focus on their Core M line for 2-in-1’s and on developing network technologies in preparation for 5G systems, however they refused to comment on the future of the Atom line, beyond saying that they will continue to ship their currently in-production SoCs.
While Intel struggled in many regards with their Atom chips (having to pay OEMs to use them), one issue that stood out was cellular radio power usage. Intel has spent substantial amounts of money buying companies and investing in R&D over the past six years trying to improve their performance, and to some extent it has paid off. Intel has shown extensive improvement in that timeframe, but they’re still playing catch up. This year’s XMM 7480 is the first Intel modem to have an integrated envelope tracking IC, which is fantastic technology that makes a huge difference for cellular power consumption, but it is technology that we’ve seen from Qualcomm since 2013. More pressingly, Intel has been having substantial difficulty leveraging their technological advantages, with even their latest modems like the 7480 and last year’s 7360 still being built on the TSMC 28 nm process node, the same node that is used by Qualcomm for their X5 LTE modem found in entry level 41x series processors.
The process node issues have been especially problematic, as they have prevented Intel from shipping a SoC with an integrated cellular radio to this date. Their SoFIA Atom x3 chip was meant to be the first, a collaboration with Rockchip and Spreadtrum on the TSMC 28 nm node, but the cancellation of SoFIA has left Intel’s efforts towards an integrated LTE modem up in the air.
Some of the questions surrounding Intel’s future have now been answered with Intel’s 7360 being picked for use in the GSM-only iPhone 7 models (the first time Apple has used a non-Qualcomm modem since 2010, back when they used Infineon modems). Intel is ramping up production of their discrete modems, and trying to find a dedicated customer base for the former Infineon business unit, the likes of which it hasn’t seen since before Intel bought them. Back in 2010 at the time of the purchase, Steve Jobs was supposedly “very happy” with Intel’s purchase of Infineon and Intel was viewed as a lock for being the modem supplier for Apple for years to come, before Apple promptly dropped them in favor of Qualcomm and CDMA support.
Intel’s plans seem to be to continue to build for a future entrance into the smartphone market, by avoiding directly entering the smartphone market.
Intel is building their low-power processor portfolio by treating the tablet and 2-in-1 markets as an extension of their laptop market, allowing them to continue to focus their R&D spending in a way that benefits them in both the short and long term, without having to spend billions to push for market share on a platform where their chips currently aren’t quite as competitive.
They’re also continuing to develop their baseband portfolio by avoiding integration just yet. By focusing on the basebands themselves, Intel is hoping to build a product that can compete with Qualcomm directly before attempting to put it all together and integrate it with their in-house chips.
The question then becomes one of “where does Intel go from here?” Hardware is only a small part of the picture if Intel wants to re-enter the Android market. Reviews of phones with Intel chipsets, like the Asus ZenFone 2, have shown that Intel’s binary translation makes any apps coded for the NDK take a hit in performance and in battery usage if they aren’t compiled for x86 (not to mention the heavy battery drain that the phone saw when using LTE, reminiscent of early LTE devices like the HTC ThunderBolt). If Intel wants to be competitive, they need to provide incentives for developers to compile their NDK apps for x86 as well as for ARM.
They need to work with Google to make sure that Android updates are ready for the x86 platform from day one, too. They need to work with OEMs to ensure that there are proper drivers available for all the devices they end up shipping. They need software support.
They also need to find ways to minimize the problems that they currently have. While providing a compelling platform and helping developers compile for x86 is the ideal end-game, Intel has to realize that even if they hold substantial market share, there will still be NDK apps that are only compiled for ARM. Even if some of them are older apps that are no longer supported by their developers, if people still use them, then they are important. Backwards compatibility is a key factor in device choice, and is a major reason for Intel’s dominance in the desktop space. As Linus Torvalds says, “WE DO NOT BREAK USERSPACE!”; from the perspective of the users, there should be no difference between what software their current device and their previous device were capable of running (unless absolutely necessary). If Intel wants to deal with that issue, they need to see some improvements to their binary translation.
That in turn leads to further questions about the design of Intel’s binary translation, and whether the issues are inherent to x86, or a code issue. Nvidia’s binary translation largely originates from the same company, Transmeta, but they seem to see substantially fewer issues with it. Platform independant tests seem to show x86 and ARM performing at relatively the same level in terms of efficiency currently, so where does the larger drain for Intel’s binary translation come from? Is it because Nvidia’s binary translation isn’t doing quite as much translation thanks to Denver being compatible with the ARM ISA? If so, then that will be a hard gap for Intel to bridge. Is it because Nvidia designed Denver with binary translation in mind, and was able to maximize performance for both? If that is the case, then Intel will be able to make changes in the future to better utilize their own form of binary translation, and we could see the gap shrink significantly. Those aren’t easy questions to find the answer to, but those are the questions that Intel will need to figure out if they want to be successful in the Android market.
Do you think Intel can rally around their Core M designs to produce a viable smartphone chip in the future? How could Intel go about building the dev support that they need? Sound off below!
Intel quickly commented that they would continue to focus on their Core M line for 2-in-1’s and on developing network technologies in preparation for 5G systems, however they refused to comment on the future of the Atom line, beyond saying that they will continue to ship their currently in-production SoCs.
While Intel struggled in many regards with their Atom chips (having to pay OEMs to use them), one issue that stood out was cellular radio power usage. Intel has spent substantial amounts of money buying companies and investing in R&D over the past six years trying to improve their performance, and to some extent it has paid off. Intel has shown extensive improvement in that timeframe, but they’re still playing catch up. This year’s XMM 7480 is the first Intel modem to have an integrated envelope tracking IC, which is fantastic technology that makes a huge difference for cellular power consumption, but it is technology that we’ve seen from Qualcomm since 2013. More pressingly, Intel has been having substantial difficulty leveraging their technological advantages, with even their latest modems like the 7480 and last year’s 7360 still being built on the TSMC 28 nm process node, the same node that is used by Qualcomm for their X5 LTE modem found in entry level 41x series processors.
The process node issues have been especially problematic, as they have prevented Intel from shipping a SoC with an integrated cellular radio to this date. Their SoFIA Atom x3 chip was meant to be the first, a collaboration with Rockchip and Spreadtrum on the TSMC 28 nm node, but the cancellation of SoFIA has left Intel’s efforts towards an integrated LTE modem up in the air.
Some of the questions surrounding Intel’s future have now been answered with Intel’s 7360 being picked for use in the GSM-only iPhone 7 models (the first time Apple has used a non-Qualcomm modem since 2010, back when they used Infineon modems). Intel is ramping up production of their discrete modems, and trying to find a dedicated customer base for the former Infineon business unit, the likes of which it hasn’t seen since before Intel bought them. Back in 2010 at the time of the purchase, Steve Jobs was supposedly “very happy” with Intel’s purchase of Infineon and Intel was viewed as a lock for being the modem supplier for Apple for years to come, before Apple promptly dropped them in favor of Qualcomm and CDMA support.
Intel’s plans seem to be to continue to build for a future entrance into the smartphone market, by avoiding directly entering the smartphone market.
Intel is building their low-power processor portfolio by treating the tablet and 2-in-1 markets as an extension of their laptop market, allowing them to continue to focus their R&D spending in a way that benefits them in both the short and long term, without having to spend billions to push for market share on a platform where their chips currently aren’t quite as competitive.
They’re also continuing to develop their baseband portfolio by avoiding integration just yet. By focusing on the basebands themselves, Intel is hoping to build a product that can compete with Qualcomm directly before attempting to put it all together and integrate it with their in-house chips.
The question then becomes one of “where does Intel go from here?” Hardware is only a small part of the picture if Intel wants to re-enter the Android market. Reviews of phones with Intel chipsets, like the Asus ZenFone 2, have shown that Intel’s binary translation makes any apps coded for the NDK take a hit in performance and in battery usage if they aren’t compiled for x86 (not to mention the heavy battery drain that the phone saw when using LTE, reminiscent of early LTE devices like the HTC ThunderBolt). If Intel wants to be competitive, they need to provide incentives for developers to compile their NDK apps for x86 as well as for ARM.
They need to work with Google to make sure that Android updates are ready for the x86 platform from day one, too. They need to work with OEMs to ensure that there are proper drivers available for all the devices they end up shipping. They need software support.
They also need to find ways to minimize the problems that they currently have. While providing a compelling platform and helping developers compile for x86 is the ideal end-game, Intel has to realize that even if they hold substantial market share, there will still be NDK apps that are only compiled for ARM. Even if some of them are older apps that are no longer supported by their developers, if people still use them, then they are important. Backwards compatibility is a key factor in device choice, and is a major reason for Intel’s dominance in the desktop space. As Linus Torvalds says, “WE DO NOT BREAK USERSPACE!”; from the perspective of the users, there should be no difference between what software their current device and their previous device were capable of running (unless absolutely necessary). If Intel wants to deal with that issue, they need to see some improvements to their binary translation.
That in turn leads to further questions about the design of Intel’s binary translation, and whether the issues are inherent to x86, or a code issue. Nvidia’s binary translation largely originates from the same company, Transmeta, but they seem to see substantially fewer issues with it. Platform independant tests seem to show x86 and ARM performing at relatively the same level in terms of efficiency currently, so where does the larger drain for Intel’s binary translation come from? Is it because Nvidia’s binary translation isn’t doing quite as much translation thanks to Denver being compatible with the ARM ISA? If so, then that will be a hard gap for Intel to bridge. Is it because Nvidia designed Denver with binary translation in mind, and was able to maximize performance for both? If that is the case, then Intel will be able to make changes in the future to better utilize their own form of binary translation, and we could see the gap shrink significantly. Those aren’t easy questions to find the answer to, but those are the questions that Intel will need to figure out if they want to be successful in the Android market.
Do you think Intel can rally around their Core M designs to produce a viable smartphone chip in the future? How could Intel go about building the dev support that they need? Sound off below!
0 comments:
Post a Comment