https://www.facebook.com/RDinPortland/posts/3209441572481555
來談談下單台積電後帶給英特爾的一些副作用.
製程卡關雖然不好, 但是對英特爾來說其實沒有真正的傷到筋骨. 英特爾的本業
CPU/Server幾十年打下來的江山很牢固, 尤其是Server的市佔牢牢地抓在手裡, 再加上
10nm產能慢慢上來, AMD雖然急起直追, 但是要真的追上來還有一段時間. 英特爾比較大
的問題是設計部門的包袱太大, 思維過於封閉僵化, 跟不上變化, 早晚有一天會遇上瓶頸
. 當製程落後和設計瓶頸同時到來的那天, 城池可能就守不住了. 這也是為什麼BK要在
2015年找來Murthy (除舊), 2018年再找來Raja Koduri和Jim Keller (佈新).
找Murthy來就是要來給公司震撼教育和動手術的, Murthy一上任就巡了一遍所有的山頭,
看到不配合的主管就拉下來, 然後順勢往下動刀. 不賺錢的group, 砍! 表現不好的
EVP/VP/Director, 砍! 沒錢景的project, 砍! 冗員, 砍! 每砍完一刀, 就把整個單位直
接收編歸他管轄, 砍到後來甚至連製程部門都收服了. 新官上任還真有一點新氣象的感覺
. 不過什麼事做過頭了總會出問題, Murthy忘了動手術是要用手術刀, 不是用菜刀的. 把
腫瘤跟肥肉切掉, 不能順便把身體裡面捅出一堆洞來. 2015年砍了12000名員工就是一個
很失敗的裁員行動, 裁掉了很多好員工, 從此士氣大落.
其實之所以找Murthy來動刀, 就是因為除了製程部門外, 設計部門也需要好好的整頓一下
.
英特爾的設計部門就像一台載了沉重包袱的牛車, 慢慢的往前走, 越走包袱越多, 偶爾有
人提出丟掉一些包袱, 但是聲音馬上就被壓下去, 沒有主事者敢承擔把一些包袱丟掉的風
險, 反正一路走來都是這樣過來了, 大鍋飯吃得好好的, 何必沒事找事.
先不提IP/Library設計, 就舉Design Flow的例子. 英特爾CPU的底層電路的實作精神就是
手刻電路. 在關鍵的block裡, 每一條data path, 每一個cell, 每一條net都要很精準的
控制, 務必要把所有多餘的一絲絲的delay都榨出來, 然後每一代靠著製程的進步來把CPU
整體速度往上擠一點. 然而業界的EDA Tool一直在進步, 自動化能夠達到的效能已經慢慢
追上手刻. 英特爾也用這些Tool, 但在使用上的哲學就是, 不管工具有多少新功能, 就只
拿其中一部分來實現英特爾現有的客製化Flow裡的功能, 其實這無可厚非, 畢竟最關鍵的
部分必須很小心的做好. 但是絕大部分的block, 都不需要這樣的設計, 如果Flow是圍繞
著手刻的哲學疊上去的, 就會對大部分的block造成負擔.
這樣的負擔英特爾有辦法靠大量的DA (design automation)人力吃下來, 再靠S提供的服
務(畢竟英特爾是S的衣食父母)來讓Flow繼續運作下去, 但是整體來說就是處在一種危險
的平衡下. 再加上英特爾山頭越來越多, 所謂天下Flow, 合久必分, 分久必合. 每幾年就
有人提議把所有的Flow都併到中央單位, 但是久了以後各山頭又嫌中央Flow不好用, 自己
偷偷搞起內部Flow. 久而久之, 英特爾的Flow就變成一隻龐然巨獸, 想改都不知道從何改
起.
在B(手機/平板SOC)時期, 英特爾力圖振作, 搞了一個算是和業界有接軌的Flow, 整個設
計理念也比照業界SOC. 但是公司史上所有只要不是正統CPU的project, 夭折率都很高, B
也不例外, 在2016宣告放棄.
笨重的牛車繼續蹣跚地向前行, 走到了分叉路, 14nm產能不夠, 各山頭要出走台積電的時
候.
當時還存在的通訊部門說, 數據機兩年後要下單台積電然後交貨給某手機公司, 你讓我開
牛車一定到不了, 給我一支重騎兵. 中央Flow team哪敢說不好, 立馬分兵引進S給小公司
專用的輕量級flow, 然後把一些英特爾特有的東西加上去, 通訊部門帶了糧草就上路了.
但內部Flow從此一分為二: 給英特爾製程專用的flow, 還有給台積電製程專用的flow.
Flow team的人力有變多嗎? 有沒有聽過一個笑話, 老闆請你用50% bandwidth做A, 50%
bandwidth做B, 最後就是200% bandwidth做AB.
Server的IP部門說我要給某網路公司做一個樣品, 一年半後交貨, 我也不要坐牛車, 給我
一支輕騎兵就好, 但是有一部分我想試試C, 因為有一些外面招來的員工說C才是業界流行
的. Flow team想想上面大老闆正在強調要擁抱變化, 公司又在推行dual source (C/S並
存), 上面都交代了那就搞吧, 所以Flow正式二分為四, 但是Flow team的人力有變多嗎?
你知道的.
重騎兵和輕騎兵都各自出征了, 然後都被殲滅了 (project被取消了).
打了敗仗, 結果是什麼? 幾年的人力經費打水漂, 後勤支援體系(memory, IO, library)
不堪負荷, Flow team的DA苦不堪言. S不棄不離了那麼多年, 換來了dual source的結局
, 滿肚子委屈.
這只是改用台積電之後帶來的其中一個副作用, IP和Library就更不用說了. 晶片設計產
品的規劃都是三五年以上, 大軍未動, 糧草先行. 假設三年後要出貨, 那所有的東西都要
在預定的時間到位, 產能要先預訂好, IP/Library開發要提早準備, 人力要找齊, Flow要
先定下來. 以下為假設情況, 如果你告訴project負責人, 三年後那顆IC你用台積電 7nm
出貨, 五年後那顆有可能英特爾7nm, 也可能台積電5nm, 也可能兩個都用. project負責
人只好根據每一種情況做準備, 排列組合之後有多少可能? Gantt chart大概好幾頁都畫
不下. 英特爾長期以來的成功就在於專注, 一手抓製程, 一手抓設計, 照自己的步調慢慢
走, 就算設計部門過於保守, 也還應付的來. 現在演變成多頭馬車的快攻, 但是設計思維
又沒有跟上外界, 很多時候就力不從心.
用台積電在現階段是一個必須, 但是50年老店英特爾還沒有做好心理準備. 曾經有一個人
看出了這個問題, 一個最擅長扭轉局勢, 戰無不勝的大將之材. 可惜Jim Keller來了,
Jim Keller又走了.
--
來談談下單台積電後帶給英特爾的一些副作用.
製程卡關雖然不好, 但是對英特爾來說其實沒有真正的傷到筋骨. 英特爾的本業
CPU/Server幾十年打下來的江山很牢固, 尤其是Server的市佔牢牢地抓在手裡, 再加上
10nm產能慢慢上來, AMD雖然急起直追, 但是要真的追上來還有一段時間. 英特爾比較大
的問題是設計部門的包袱太大, 思維過於封閉僵化, 跟不上變化, 早晚有一天會遇上瓶頸
. 當製程落後和設計瓶頸同時到來的那天, 城池可能就守不住了. 這也是為什麼BK要在
2015年找來Murthy (除舊), 2018年再找來Raja Koduri和Jim Keller (佈新).
找Murthy來就是要來給公司震撼教育和動手術的, Murthy一上任就巡了一遍所有的山頭,
看到不配合的主管就拉下來, 然後順勢往下動刀. 不賺錢的group, 砍! 表現不好的
EVP/VP/Director, 砍! 沒錢景的project, 砍! 冗員, 砍! 每砍完一刀, 就把整個單位直
接收編歸他管轄, 砍到後來甚至連製程部門都收服了. 新官上任還真有一點新氣象的感覺
. 不過什麼事做過頭了總會出問題, Murthy忘了動手術是要用手術刀, 不是用菜刀的. 把
腫瘤跟肥肉切掉, 不能順便把身體裡面捅出一堆洞來. 2015年砍了12000名員工就是一個
很失敗的裁員行動, 裁掉了很多好員工, 從此士氣大落.
其實之所以找Murthy來動刀, 就是因為除了製程部門外, 設計部門也需要好好的整頓一下
.
英特爾的設計部門就像一台載了沉重包袱的牛車, 慢慢的往前走, 越走包袱越多, 偶爾有
人提出丟掉一些包袱, 但是聲音馬上就被壓下去, 沒有主事者敢承擔把一些包袱丟掉的風
險, 反正一路走來都是這樣過來了, 大鍋飯吃得好好的, 何必沒事找事.
先不提IP/Library設計, 就舉Design Flow的例子. 英特爾CPU的底層電路的實作精神就是
手刻電路. 在關鍵的block裡, 每一條data path, 每一個cell, 每一條net都要很精準的
控制, 務必要把所有多餘的一絲絲的delay都榨出來, 然後每一代靠著製程的進步來把CPU
整體速度往上擠一點. 然而業界的EDA Tool一直在進步, 自動化能夠達到的效能已經慢慢
追上手刻. 英特爾也用這些Tool, 但在使用上的哲學就是, 不管工具有多少新功能, 就只
拿其中一部分來實現英特爾現有的客製化Flow裡的功能, 其實這無可厚非, 畢竟最關鍵的
部分必須很小心的做好. 但是絕大部分的block, 都不需要這樣的設計, 如果Flow是圍繞
著手刻的哲學疊上去的, 就會對大部分的block造成負擔.
這樣的負擔英特爾有辦法靠大量的DA (design automation)人力吃下來, 再靠S提供的服
務(畢竟英特爾是S的衣食父母)來讓Flow繼續運作下去, 但是整體來說就是處在一種危險
的平衡下. 再加上英特爾山頭越來越多, 所謂天下Flow, 合久必分, 分久必合. 每幾年就
有人提議把所有的Flow都併到中央單位, 但是久了以後各山頭又嫌中央Flow不好用, 自己
偷偷搞起內部Flow. 久而久之, 英特爾的Flow就變成一隻龐然巨獸, 想改都不知道從何改
起.
在B(手機/平板SOC)時期, 英特爾力圖振作, 搞了一個算是和業界有接軌的Flow, 整個設
計理念也比照業界SOC. 但是公司史上所有只要不是正統CPU的project, 夭折率都很高, B
也不例外, 在2016宣告放棄.
笨重的牛車繼續蹣跚地向前行, 走到了分叉路, 14nm產能不夠, 各山頭要出走台積電的時
候.
當時還存在的通訊部門說, 數據機兩年後要下單台積電然後交貨給某手機公司, 你讓我開
牛車一定到不了, 給我一支重騎兵. 中央Flow team哪敢說不好, 立馬分兵引進S給小公司
專用的輕量級flow, 然後把一些英特爾特有的東西加上去, 通訊部門帶了糧草就上路了.
但內部Flow從此一分為二: 給英特爾製程專用的flow, 還有給台積電製程專用的flow.
Flow team的人力有變多嗎? 有沒有聽過一個笑話, 老闆請你用50% bandwidth做A, 50%
bandwidth做B, 最後就是200% bandwidth做AB.
Server的IP部門說我要給某網路公司做一個樣品, 一年半後交貨, 我也不要坐牛車, 給我
一支輕騎兵就好, 但是有一部分我想試試C, 因為有一些外面招來的員工說C才是業界流行
的. Flow team想想上面大老闆正在強調要擁抱變化, 公司又在推行dual source (C/S並
存), 上面都交代了那就搞吧, 所以Flow正式二分為四, 但是Flow team的人力有變多嗎?
你知道的.
重騎兵和輕騎兵都各自出征了, 然後都被殲滅了 (project被取消了).
打了敗仗, 結果是什麼? 幾年的人力經費打水漂, 後勤支援體系(memory, IO, library)
不堪負荷, Flow team的DA苦不堪言. S不棄不離了那麼多年, 換來了dual source的結局
, 滿肚子委屈.
這只是改用台積電之後帶來的其中一個副作用, IP和Library就更不用說了. 晶片設計產
品的規劃都是三五年以上, 大軍未動, 糧草先行. 假設三年後要出貨, 那所有的東西都要
在預定的時間到位, 產能要先預訂好, IP/Library開發要提早準備, 人力要找齊, Flow要
先定下來. 以下為假設情況, 如果你告訴project負責人, 三年後那顆IC你用台積電 7nm
出貨, 五年後那顆有可能英特爾7nm, 也可能台積電5nm, 也可能兩個都用. project負責
人只好根據每一種情況做準備, 排列組合之後有多少可能? Gantt chart大概好幾頁都畫
不下. 英特爾長期以來的成功就在於專注, 一手抓製程, 一手抓設計, 照自己的步調慢慢
走, 就算設計部門過於保守, 也還應付的來. 現在演變成多頭馬車的快攻, 但是設計思維
又沒有跟上外界, 很多時候就力不從心.
用台積電在現階段是一個必須, 但是50年老店英特爾還沒有做好心理準備. 曾經有一個人
看出了這個問題, 一個最擅長扭轉局勢, 戰無不勝的大將之材. 可惜Jim Keller來了,
Jim Keller又走了.
--
All Comments