归于软银帐下,ARM需要接受的变与不变

简介:

摘要:软银此次对于ARM的收购,在无形之中也拉近了ARM与日本IDM大厂间的合作距离,可以帮助其更好地进行超算芯片的制造;而从另一个层面来讲,“后K超级计算机”又何尝不是ARM的一个“活字招牌”?
image
7月中旬,软银宣布将以243亿英镑(约合320亿美元)的现金收购英国芯片公司ARM。而就在昨天,软银正式宣布已经完成了对于ARM的收购事宜,至此,这项今年全球科技市场最大的并购案之一正式落下帷幕。

作为全球领先的半导体知识产权供应商,ARM在全球有着可观的市占和很高的信誉。全世界超过95%的智能手机和平板电脑CPU都采用ARM架构,且ARM设计了大量高性价比、低功耗的RISC处理器以及相关的技术及软件。

ARM不需要“被收购”?
在此基础上,很多人认为ARM完全不需要“被收购”。但是,从另一个角度来看,作为芯片领域的两大巨头,Intel与ARM的商业模式是大不相同的:

Intel自己研发处理器架构,自己研发处理器,在自家的晶圆工厂制造,向整机制造商高价出售处理器;

ARM研发统一的处理器架构,授权给各家芯片设计公司自行研发处理器,再找第三方晶圆代工厂制造,其中ARM只收平均不到1美元的授权费。

两种商业模式的不同,就造就了双方在盈利方面的天差地别,当Intel的年营收达到几百亿美元的时候,ARM就只能守着那可怜巴巴的10亿英镑(约合13.3亿美元),而这其中的大部分还将用于来年的技术研发。或许是出于自身利益的缘故,ARM董事会决定以高价“卖掉”ARM。

被收购后,ARM的赚钱能力会加强吗?
因为嫌弃ARM不会赚钱,抑或是为了改变现状,其董事会通过了将ARM“卖身”软银的决定。但是,这之后的发展真的会如其所愿吗?

对于ARM收购后的安排,软银方面表示,ARM将继续作为独立公司运营,并且,未来几年或将把ARM的员工数量增加一倍,达到5000至6000人。

事实上,对于软银来说,保持ARM的独立性是必然的。在业务上,“技术和价格”就是ARM占领市场的两大王牌。他们在技术的研制上心无旁骛,从而才能够打败芯片巨头Intel,而合理的价格就是吸引客户的最大诱惑。

不过,如果在被收购后不能够保持独立性,由于观念等方面的不同,软银的插手或多或少都会带来一点改变,进而影响ARM的业务,这种结果不管是对软银还是ARM ,都会显得有点得不偿失。

而在独立之后,为了安稳客户的心,避免客户的流失和业务的大幅缩水,ARM的专利技术许可费/特许权使用费必将继续保持在合理价格内。同时,针对ARM客户的产品也会继续保持高水准,这就意味着成本的继续大幅投入。

从这两点看来,对于ARM被收购后的赚钱能力,镁客君并不抱有多大的期望。不过,ARM好像并没有过于看重自身的盈利,甚至转而投入了服务器芯片的怀抱,在占领了移动端市场后,欲与Intel至强一争服务端天下。

  “天河二号”超级计算机

被收购后,ARM的超算计划是否受影响?
超级计算机的芯片是Intel x86的天下,但就在那个被“垄断”的时代,有人尝试打破这个“局”。

2011年,西班牙巴塞罗那超级计算中心(BSC)启动了一个超算项目,代号为“Mont-Blanc Project”(勃朗峰工程)。在这个项目中,他们将使用ARM Cortex-A15架构打造,也是ARM第一次尝试高性能计算(HPC)。

而正如项目简介中所说,“ARM处理器从来就不是针对HPC设计的,ARM芯片也从未用于HPC系统,这带来了大量的严峻挑战。……这将是第一次在HPC中使用嵌入式移动SoC。”到目前为止,我们还未看到有关于这个项目的更多消息或进展。

  K超级计算机

不过,这并没有打击ARM进入超算领域的决心。就在今年的超级计算机大会上,日本富士通已表明会在自己打造的巨型级超级计算机“后K”上使用64位ARMv8内核。

按照他们的设想,后K超级计算机的应用性能是K超级计算机(世界排行第五)的100倍以上,其速度将达每秒100亿亿次浮点运算(神威太湖之光为12.54亿亿次浮点运算)。如若打造成功,这将是世界上最快的ARM芯片计算机系统。

在对抗服务端芯片老大Intel上,ARM的强项在于其相较于x86架构更具省电效益的潜力,此特性对于高耗能的超级计算机来说颇具助益,也是ARM抢夺Intel市场的一个有利突破口。

软银此次对于ARM的收购,在无形之中也拉近了ARM与日本IDM(国际整合元件制造商)大厂间的合作距离。比如说与富士通之间拉近距离,可以帮助其更好地进行超算芯片的制造;而从另一个层面来讲,“后K超级计算机”又何尝不是ARM的一个“活字招牌”?而着力开发“后K超级计算机”,或许就是它打入服务端市场的第一步。

本文转自d1net(转载)

相关文章
软银旗下ARM子公司推出针对自动驾驶汽车传感器的芯片
这款软件的设计理念是近乎实时地处理自动驾驶汽车传感器的数据流
319 0