摩爾定律的瓶頸，未來會靠「AI 設計晶片」突破
TO 精選觀點2021-08-26
【為什麼我們要挑選這篇文章】晶片尺寸逐漸逼近物理極限，市場皆在討論，摩爾定律是否走到極限。然而隨著 AI 晶片設計技術的發展，摩爾定律會交由 AI 來延續。但未來晶片設計工程師會失業嗎？還是工程師會與 AI 協作，推動晶片設計邁進人工智慧時代？（責任編輯：郭家宏）
AI 設計的晶片，性能十年內將提高 1,000 倍。
作為 Synopsys 執行長、晶片設計自動化的先驅之一，Aart de Geus 在 Hot Chips 在線晶片大會上表示，現在人工智慧設計的晶片，性能可能會在未來十年內提高 1,000 倍。
自 80 年代以來，自動化一直都是晶片設計的一部分。但現在，每兩年晶片性能翻一倍的「摩爾定律」似乎已經達到了瓶頸。要突破這個瓶頸，最好的辦法或許就是你我都熟知的：人工智慧。
一篇刊登在 Nature 上的文章指出，經過訓練的機器學習系統，在晶片設計上的表現超過人類。
不少晶片架構師都擔心自己的飯碗未來會被 AI 搶走。不過 De Geus 卻認為，晶片架構師不僅不會下崗，還會轉移到產業鏈的上遊，比現在負責更多任務。
Synopsys 從去年開始就使用 AI 來設計客戶的晶片，與人工設計的晶片相比有了相當大的改進。目前，三星也正在使用 Synopsys 的工具 DSO.ai 來設計 Exynos 晶片。而它的競爭對手 Cadence Design Systems 也在今年推出了自己的人工智慧晶片設計專案。
用 AI 設計晶片，有望打破摩爾定律的瓶頸
De Geus 在 1986 年創立了 Synopsys，一家電子設計自動化（EDA）軟體公司。憑借多年尖端半導體設計經驗，Synopsys 利用這個寶貴的資產制作了第一代 AI 晶片軟體 DSO.ai。
要超越摩爾定律，就要利用 AI 來解決複雜性、功耗和擴展要求，最終實現 1,000 倍性能的目標。
「機器學習出現在我們使用的每一種工具中，這個設計空間優化（DSO）的新工具的不同之處在於，它不適用於單個設計步驟，而是適用於整個設計流程。」
這就是 Synopsys 採用的自主晶片設計方法，從綜合方法進行晶片設計，而不僅僅是晶片布局。
晶片設計的一個早期步驟是 floor planning，其確定了晶片的尺寸、標準單元的排列形式、IO 單元及宏單元的位置、電源地網絡的分布等。
由於宏單元潛在配置數量巨大（約為 10^2500），規劃就會變得非常複雜，而且隨著邏輯電路設計的發展，還需要進行多次疊代。如果每次疊代都由人類工程師手動生成，就要耗時數天或數週。
但如果用 AI 設計晶片，它就能夠利用強化學習，優化晶片的功率、性能和面積大小。還能解決針對特定應用程式以及系統的所有維度的快速定制晶片：硬體（物理）、軟體（功能）、可製造性和架構（形式）。
隨著 AI 接管更多任務，以往負責設計少量電晶體的工程師，現在可能負責設計更大晶片中的 10 億個電晶體。
這樣就能夠在更短的時間內設計出更快的晶片，改變晶片的架構，將晶片性能提高 10 倍、100 倍甚至是 1,000 倍。
Google、NVIDIA 正在用 AI 設計晶片
與使用最先進設計工具的世界一流設計團隊相比，DSO.ai 能夠將功耗降低 25%，性能是當下最好的 AI 晶片設計工具的 5 倍。
而在未來的 AI 晶片設計時代，晶片能夠根據各個垂直行業進行設計。
面對特定專案的差異化需求，DSO.ai 可以用來優化輸入參數以及晶片設計工作流程的選擇。
工程師可以使用 DSO.ai 進行更多設計流程中的參數輸入，例如微調庫單元以提供最佳頻率或最低功率，採用現有平面圖並盡量縮小晶片尺寸，確定多高的工作電壓會實現功耗與性能的最佳權衡等。
全球「缺晶片」，雖然說不少產業都受到影響，但人們也深刻認識到了晶片的重要性。晶片雖小，但卻是一個重要的基礎設施。
除了 Synopsys，Google、NVIDIA 也開始嘗試使用人工智慧技術設計晶片。Google 的 TPU（張量處理單元）晶片即將發布新版本，優化了人工智慧計算。目前 NVIDIA 也專注於使用 AI 技術生產更好的 GPU 和雲端運算 TPU 平台，以增強自身競爭力。
晶片設計的工程師不會失業。而人工及 AI 相結合的設計思路將會推動晶片設計邁進人工智慧時代。
附圖：人類設計的晶片平面圖（a）與機器學習系統生成的平面圖（b）
摩爾定律逐漸扁平，晶片設計重任落到了 AI 肩上。
在晶片設計的新時代，自動化大不相同。
晶片定制會更普遍
資料來源：https://buzzorange.com/techorange/2021/08/26/ai-sustain-moore-law/
軟體工程流程圖 在 [閒聊]資工專業很親切--軟體工程未受重視- 看板Soft_Job 的推薦與評價
※ 引述《VVll (偽Wii)》之銘言：
: 軟體業 也有一個一直存在的事實
: 並不重視 軟體工程 這個區塊
: 不論是UML的流程 或是 已經推一陣子的CMMI
: 應該很少軟體公司 在做
: 之前去 某個網路遊戲開發公司面試
: 提到 個人專題 是做國科的OpenSurce計畫
: 依照 CMMI的流程去規劃與設計...
: 厚厚的一本專題作品 都是在寫文件...
: 就被面試主管打槍
: 說業界根本就沒在用這個
: 都嘛直接寫 比較快
: 你們做的這個 比較偏學術研究 或是政府標案
: 聽起來 好像沒有什麼不對
: 但是 依照當初所學 的觀點去看
: 當系統程式的規模越來越大 沒有預先設計規劃好 整個開發生命週期
: 東西真的做的出來嗎..
: 在另家公司面試時 跟裡面的人聊到 橘子?之前有個團隊在自製遊戲
: 但是錢燒了2-3年東西還是沒出來 最後就把那個團隊先抓去弄代理遊戲了
: 從WOW在台灣上線 到今日.. 都過了4年以上
: 而台灣到現在 卻做不出同樣規模水準的大遊戲(軟體)
: 軟體工程... 真的沒用嗎?
==================================================================
資工系很親切, 說的是任何人都可以入行, 這行有些特別的地方,
那可能就是軟體工程.
台灣所有跟IT有關的產品, 即使是組裝, 都用上軟體來控管生產或增強
產品性能, 幾乎沒有一個老板會說軟體不重要, 因為都是靠軟體在增加
附加價值與競爭力. 但如此重視軟體, 為何很多 IT 產品業, 常會被批
評不把軟體工程當一回事?
思惟不受規範限制, 自然是海闊天高, 創意無限, 愛怎麼做就怎麼做,
當然也就任何人都可進來做, 沒有一堆菱角, 當然是親切.
但做軟體的會想把軟體做垮嗎? 事實上絕非如此,
只是這些業界重視的軟體工程與方法的, 跟這些掛著軟體工程自認最正
牌的專家或學者在認知上是有些互看不對眼.
軟工專業的, 總有一些特異的現象:
第一個特徵:
在資工系裡, 很多教師不會被軟工專業者認為是懂軟體工程.
這種事在工學院的老系, 如土木系裡決不會發生土木系的教師批評系裡
其他教師不懂土木工程. 因為他們通常都使用同一種工程圖號表示法,
說的都是同一種表達形式, 也幾乎用同一套數學工具, 不會各說各話.
第二個特徵:
被批評不懂軟體工程的, 幾乎都會有軟體工程管用嗎? 這種質疑軟工的
奇特看法.
譬如專學軟體工程的若看到台灣這些做軟體的, 尤其是在台灣 "能賺到
錢" 的IT 業, 幾乎都會罵 "亂無章法, 既原始又野蠻只懂暴力法".
主要的原因是這些靠軟體加持在賺錢的業者, 認為照著軟體工程專家的
搞法會賺不到錢! 但專家的看法則是目前這樣搞, 將來賺不到大錢.
以前, 賺錢老板的惡劣答覆一定是 "公司目前的方法雖爛, 可是卻能賺
到錢", 言下之意就暗示著 "能賺到錢再說". 時下, 軟工概念至少推了
一陣, 也被 "印度軟體" 頂了一頓, 就只好說那是學院派的.
=============================================================
軟工要在台灣推動, 最大問題是沒有跟國情結合.
1. 台灣的 PC 硬體滿街跑, 外銷的 PC系統組裝商每台電腦根據每個
CPU 數量都必須付每個 CPU 一套作業系統的錢. 但街上的經銷商
卻可以告訴買者, 那套作業系統不算買方的錢, 他附帶拷給你.
而買方也真以為省了錢賺到了! 台灣進口幾顆 CPU , 美國海關會
不知道? 這使得當真再付作業系統軟體錢的人, 可能是白付給經銷
商了.
2. 台灣大力推廣使用電腦, 學習寫程式. 非本科系都要學. 懂一點的
人太多.
問題1: 使用電腦的不想付軟體的錢, 更別談改個batch command 指令
要錢! 斤斤計較少付代價是否就是人性?
假如 batch command 的備註寫得很清楚, 小改的人是否很多? 要不到
錢的機率是否會變得更高?
在公司裡把備註寫得很清楚, 配發給客戶又要發時間拿掉, 那是幹嘛?
公司裡的文件不會因很齊全, 更容易被洩漏盜賣嗎?
假如文件用黑話, 行話表示, 別人就不容易看得懂, 那可讀性, 新人接
手又怎麼辦?
問題2: 工程圖設計圖, 多數的外行人看不懂, 也不敢亂接亂改. 普通
電腦程式亂改, 最壞蕩機. 重開機, 避開那種用法就行, 又不
是核能電廠的軟體, 蕩機死不了人!
問題3: 軟體維護修改要不到多大的錢, 一切重做才要得了大錢 !
規劃軟體時做到模組化, 可再用, 易讀易維護, 在台灣這種小市場, 那
豈不跟自己飯碗過不去?
當老板要的東東很清楚, 軟工專家針對客戶需要, 怎會處理不了?
通常, 很靈通柔軟的, 見招拆招的都能應付這種問題, 但很靈活跟亂無
章法會有多大差別? 台灣一向講求 "亂中有序", 照扛老外教科書難免
死硬, 兩方對不攏, 這時候一點都不親切 !
軟體從流程圖到 UML 從來都不曾定案實施. 不像電機的工程圖, 至少
大家用 美規 也都 "服從" 了很久 ! 如果工程圖都如天書, 非本科系
看不懂, 只有入行看得改得, 這時候資工系就不那麼親切了 !
==============================================================
n 年前的黑手老板雖不做電腦, 但也有同樣的問題. 使用電磁開關控制
的複雜動作, 其接線圖就如同電腦程式, 日據時代留下來的黑手老板把
接線圖用自己的符號自個寫下來, 但久了就一堆亂成一團的鬼畫符, 連
自己也弄不清楚, 更別談有人敢接班那張原設計圖了. 畢竟萬一接錯線
, 模具工具機的刀具亂跑也是會嚇死人的.
黑手老板的機器可能就靠那張電磁開關的控制電路圖, 可以唯一的自行
變化來擋住同行的進入, 這就是典型的 Know-How 機密做法. 黑手老板
用的是日規符號加上自創的, 若碰上學回美規電磁開關工程圖的洋博,
被斥外行, 暴力 也就不冤枉. 不過, 別忘了黑手老板因自創密笈可以
賺到這地區的錢 !
模具業很賺錢, 到現在依然是如此! X海精機 就是做模具起家的, 目前
也自認對軟體會有一套辦法!
※ 編輯: ggg12345 來自: 140.115.4.12 (03/01 08:37)
黑手老板可以自己看自創的符號圖做出控制電路來, 維持 know-how
不外洩, 換成教授則多數都不行.
黑手老板不肯教別人看懂他訂的符號, 別人只能猜.
軟工訂的規範沒人肯遵守, 怕的原因之一是怕機密外洩, 怕無法保
障自己 "小小電路圖(程式)" 的智財權, 要分工合作很難, 多數是
單包獨幹, 累死自己.
土木系教授未必會去蓋房子, 但出來的學生不會看不懂工程設計圖,
也不會亂訂別人看不懂的符號.
電磁開關的電路圖稱為 relay ladder diagram 是一種邏輯電路,
跟電腦硬體的邏輯電路同一種原理, 都能用 Boolean algebra 描述.
既然是講工程就會有 規範, 工法, 道具的問題.
只是軟體還多一樣: 如何保護投入的資金與產出的智財權.
IBM 給的糖衣就是 利用 IDE 道具形成資本與人力投入的障礙 做保護!
說的是: 花大錢就能解決心頭大患!
※ 編輯: ggg12345 來自: 140.115.4.12 (03/01 13:12)
... <看更多>