最近關於蘋果A9訂單的消息好多好亂,其實用合理性來推斷就可以知道:
1.一定是會分散風險:
以蘋果這種需要大量出貨的晶片廠商而已, 最好的做法一定是要分散訂單, 既然三星14奈米跟台積電 16奈米都差不多 ready 那當然是兩邊都有機會都會下訂單. 如果有兩家廠商都可以下對蘋果一定是最有利.那有人會問為何台積20奈米可以獨吃A8?
廢話, 當蘋果要做A8來賣 iphone6 時全世界只有台積可以提供20奈米製程 , 蘋果不全給台積要給誰? 同樣台積可以幾乎全吃 28奈米製程也是因為只有台積可以提供 28奈米製程.
同樣的現在高通跟中芯搞28, 聯發科跟華力微搞 28都是一樣的道理. 哪個IC設計公司會希望產能被台積一家獨大控制呢? 所以基本上三星跟台積如果都可以提供 14/16且時程符合A9製作需求時那一定都會拿到訂單.
2.誰多誰少?
現在不在講三星拿到九成或是台積八成, 意義都不大, 這牽涉到產能規劃與良率兩件事, 但是這很複雜. 通常晶圓代工廠規劃新技術的產能時都會詢問這些大咖的設計公司的需求, 還有市場調查, 譬如全球手機一年賣多少量要多少晶片,推估產能 .
所以像蘋果高通這類大咖都要預估產能給晶圓代工. 但是對晶圓代工而已, 建造新製程是很貴的, 都必須抓得剛剛好, 不然多出來的產能光是折舊虧損就會承受不了. 動不動幾千億的投資,一不小心就會讓一家公司產生巨大虧損.
在產能規劃通常是剛剛好,而且預估良率也都是高良率去預估.廢話, 不然只用五成良率去估要買倍機台一定會虧損. 而且光是五成良率估一定被老闆打死. 所以即使蘋果或高通可能會多估產能需求給晶圓代工廠, 但是對三星跟台積也是非常保守的, 除非確定有那樣需求, 不然不會亂冒險買設備建產能.所以即使蘋果或高通亂開需求也不會被三星跟台積買帳的. 他們也不敢亂開然後沒填滿, 那以後就拿不到該有的產能了.
這也是為什麼三星要聯合G.F的產能來吃蘋果, 也是分散自己建置產能的風險, 不然好吃的蘋果自己吃都不夠還分人?
3.良率才是賺錢王道
另外就是良率,通常越先進製程,良率愈難搞, 一開始通常不高, 所以這也是為什麼台積 28 產能一開始讓高通這些廠商又愛又恨的牙癢癢的, 因為產能規劃很緊, 只要良率不是很高, 就讓這些廠商緊張到跳腳但也沒轍.也亟思要培養第二代工來源. 所以不管是三星或台積的14/16 良率才是重點, 但是即使良率達到高水準,也才剛好符合市場需求, 所以一開始良率不夠高也不夠穩,一定是缺貨缺到爆, 而且不是你要拿八成就拿的下, 那也要看良率能不能超高水準, 全下給你, 做不出來也沒用, 而且不是說下就下這麼簡單.
在新製程研發時這些大咖客戶早就會投片工程試作了, 而且持續修正改進,差不多能吃多少貨跟一開始良率多少都預估數量, 不會幾周內就變來變去. 更何況一開始產能規劃根本就不太可能達到吃下八成這種大膽策略, 產能規劃應該是各一半一半多一點起點, 現在大家都是用喊的, 也是兩面手法的階段,
不是很重要, 重點是生產後, 誰良率持續改善, 能讓製程穩定有高獲利才是未來重點.
前面提到三星聯合G.F的產能, 明眼人應該知道這對良率而言應該是淺在很大的風險.跨個廠有時候良率就變差, 何況還跨公司, 14奈米應該沒這麼容易搞,更何況不同公司各懷鬼胎, 這樣合作得起來還能做好,實在沒甚麼說服力. 當然台積在這方面是比較有優勢的.
結論:
所以現在喊誰拿下多少, 真的不重要, 都是畫餅, 能吃的下且消化吸收而不瀉肚子才是重點.以後開始量產開始搶下多少單做出多少單才是重點. 到時候搞不好某家良率拉不上來產能不夠,說不定蘋果會反過來跟另一家代工廠拼命追單也說不定....
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.223.182.228
※ 文章網址: https://www.ptt.cc/bbs/Stock/M.1421243364.A.DCC.html
→
01/14 21:53, , 1F
01/14 21:53, 1F
※ 編輯: scatliu (61.223.182.228), 01/14/2015 22:01:08
→
01/14 21:54, , 2F
01/14 21:54, 2F
→
01/14 21:54, , 3F
01/14 21:54, 3F
→
01/14 21:58, , 4F
01/14 21:58, 4F
→
01/14 21:58, , 5F
01/14 21:58, 5F
推
01/14 22:00, , 6F
01/14 22:00, 6F
→
01/14 22:02, , 7F
01/14 22:02, 7F
※ 編輯: scatliu (61.223.182.228), 01/14/2015 22:05:23
推
01/14 22:09, , 8F
01/14 22:09, 8F
→
01/14 22:09, , 9F
01/14 22:09, 9F
推
01/14 22:11, , 10F
01/14 22:11, 10F
推
01/14 22:11, , 11F
01/14 22:11, 11F
推
01/14 22:23, , 12F
01/14 22:23, 12F
→
01/14 22:23, , 13F
01/14 22:23, 13F
→
01/14 22:25, , 14F
01/14 22:25, 14F
推
01/14 22:26, , 15F
01/14 22:26, 15F
→
01/14 22:26, , 16F
01/14 22:26, 16F
→
01/14 22:27, , 17F
01/14 22:27, 17F
推
01/14 22:29, , 18F
01/14 22:29, 18F
推
01/14 22:38, , 19F
01/14 22:38, 19F
推
01/14 22:38, , 20F
01/14 22:38, 20F
→
01/14 22:40, , 21F
01/14 22:40, 21F
→
01/14 22:44, , 22F
01/14 22:44, 22F
推
01/14 22:54, , 23F
01/14 22:54, 23F
推
01/14 22:55, , 24F
01/14 22:55, 24F
推
01/14 22:58, , 25F
01/14 22:58, 25F
→
01/14 22:58, , 26F
01/14 22:58, 26F
→
01/14 23:00, , 27F
01/14 23:00, 27F
→
01/14 23:03, , 28F
01/14 23:03, 28F
→
01/14 23:06, , 29F
01/14 23:06, 29F
推
01/14 23:10, , 30F
01/14 23:10, 30F
→
01/14 23:12, , 31F
01/14 23:12, 31F
→
01/14 23:18, , 32F
01/14 23:18, 32F
推
01/14 23:18, , 33F
01/14 23:18, 33F
推
01/14 23:20, , 34F
01/14 23:20, 34F
→
01/14 23:22, , 35F
01/14 23:22, 35F
→
01/14 23:30, , 36F
01/14 23:30, 36F
→
01/14 23:32, , 37F
01/14 23:32, 37F
※ 編輯: scatliu (61.223.182.228), 01/14/2015 23:47:47
推
01/14 23:41, , 38F
01/14 23:41, 38F
推
01/14 23:52, , 39F
01/14 23:52, 39F
推
01/14 23:54, , 40F
01/14 23:54, 40F
→
01/14 23:54, , 41F
01/14 23:54, 41F
推
01/14 23:58, , 42F
01/14 23:58, 42F
推
01/15 00:00, , 43F
01/15 00:00, 43F
→
01/15 00:17, , 44F
01/15 00:17, 44F
→
01/15 00:28, , 45F
01/15 00:28, 45F
推
01/15 00:36, , 46F
01/15 00:36, 46F
→
01/15 01:00, , 47F
01/15 01:00, 47F
→
01/15 01:01, , 48F
01/15 01:01, 48F
推
01/15 02:26, , 49F
01/15 02:26, 49F
→
01/15 02:27, , 50F
01/15 02:27, 50F
推
01/15 02:47, , 51F
01/15 02:47, 51F
→
01/15 02:47, , 52F
01/15 02:47, 52F
→
01/15 02:49, , 53F
01/15 02:49, 53F
→
01/15 02:50, , 54F
01/15 02:50, 54F
→
01/15 02:51, , 55F
01/15 02:51, 55F
推
01/15 17:45, , 56F
01/15 17:45, 56F
討論串 (同標題文章)
完整討論串 (本文為第 1 之 2 篇)：
標的
24
56