突破SoC的性能瓶頸！

SoC 不斷增加處理核心，但它們不太可能得到充分利用，因為真正的瓶頸沒有得到解決。

SoC 需要處理的數(shù)據(jù)量激增正在拖累性能，雖然處理器本身可以處理這些涌入的數(shù)據(jù)，但內存和通信帶寬正在緊張?，F(xiàn)在的問題是可以做些什么。

內存和 CPU 帶寬之間的差距——所謂的內存墻——有據(jù)可查，絕對不是一個新問題。但它并沒有消失。事實上，情況還在繼續(xù)惡化。

早在 2016 年，德克薩斯高級計算中心的研究科學家 John McCalpin 發(fā)表了一次演講，他在演講中研究了高性能計算 (HPC) 的內存帶寬和系統(tǒng)資源之間的平衡。他分析了當時排名前 500 的機器，并剖析了它們的核心性能、內存帶寬、內存延遲、互連帶寬和互連延遲。他的分析表明，每個插槽的峰值 FLOPS 每年增加 50% 到 60%，而內存帶寬每年僅增加約 23%。此外，內存延遲以每年約 4% 的速度下降，而互連帶寬和延遲每年增加約 20%。這些表明數(shù)據(jù)移動方面存在持續(xù)且不斷擴大的不平衡。

這意味著如果我們是流式數(shù)據(jù)，每次內存?zhèn)鬏敾ㄙM的時間相當于 100 次浮點算術運算。在內存延遲的情況下，您無法預取并且錯過了緩存，您已經失去了進行 4,000 多次浮點運算的機會。

                                                                 圖 1：系統(tǒng)性能要素的不平衡。資料來源：德克薩斯大學奧斯汀分校 TACC 的 John McCalpin

一個設計良好的系統(tǒng)是平衡的。“如果有兩種解決方案，其中一種可以更有效地使用晶體管，那么每美元的吞吐量和每瓦特的吞吐量就會更高，而這正是大多數(shù)人想要的，”Flex Logix 首席執(zhí)行官杰夫泰特說?！昂茈y交付獲得高利用率的架構，但您可以獲得的利用率越高越好。晶體管仍然不是免費的。”

其他人同意。Achronix產品營銷總監(jiān) Bill Jenkins 說：“在查看系統(tǒng)性能時，事情要么受計算限制，要么受內存限制，要么受 I/O 限制?！?“隨著計算速度的加快，您需要更加重視更快的內存來跟上計算的步伐，并且還需要更高帶寬的接口來將數(shù)據(jù)傳入和傳出設備?！?/p>

但業(yè)界對加工性能著迷?！坝嬎銌卧哪芰?，無論它是什么，都很重要，但它們通常不是實際系統(tǒng)速度的限制因素，” Synopsys研究員 Rob Aitken 說。“系統(tǒng)速度取決于工作負載，它取決于數(shù)據(jù)從某個地方獲取、以某種方式進行處理并發(fā)送到使用它的任何地方的速度有多快，并受到沿途一切事物的各種限制?！?/p>

這意味著不可能構建一個對所有任務都最優(yōu)的系統(tǒng)。關鍵是要確保它是平衡的，并且在任何區(qū)域都沒有過度配置。

移動數(shù)據(jù)

移動數(shù)據(jù)的成本肯定會影響系統(tǒng)性能，但它也與功耗有關，因為移動數(shù)據(jù)所消耗的功率比對其執(zhí)行計算要多幾個數(shù)量級。完成一個任務，一般意味著數(shù)據(jù)通過外部接口進入內存，從內存到CPU，中間結果在內存和CPU之間來回跳動，最后通過外部接口推回。

“無論你的計算速度有多快，或者你的內存陣列有多大，最終決定你的芯片和系統(tǒng)性能的是連接兩者的總線帶寬，”模擬技術首席產品經理 Pradeep Thiagarajan 說。以及西門子 EDA的混合信號 IC 驗證解決方案?！斑@就是你遇到的最大瓶頸。它不僅僅是一輛公共汽車。它基本上是您的收發(fā)器、SerDes 鏈路，它為需要解決的問題帶來了一個完全不同的維度?！?/p>

有效內存帶寬的最大進步之一是緩存的采用。這有效地使內存更接近處理器，并減少延遲，假設大多數(shù)內存訪問來自此內存而不是主內存。但是，緩存性能一直在下降，這是延遲增加的主要原因之一（如上圖 1 所示）。即使 HBM 的引入也未能扭轉這一趨勢，因為處理器性能增長如此迅速，主要是通過快速增加的內核數(shù)量。McCalpin 說延遲的下降是因為緩存變得越來越復雜，尤其是當更多的內核保持一致時，并且多級緩存中的查找被序列化以節(jié)省功率。

另一種選擇是將計算移動到更靠近內存的位置。“內存計算時代才剛剛開始，”Cadence 產品營銷組總監(jiān) Marc Greenberg說的 IP 組?！拔铱吹竭@可能發(fā)生的三種方式。通常，由于 DRAM 制造的經濟性，我們在 DRAM 芯片上看不到很多復雜的邏輯。我們可能會看到少量非常具體的功能被添加到這些模具中——例如，累加或乘法累加功能，這在許多 DSP 和 AI 算法中很常見。第二種可能是像 CXL.mem 這樣的技術，在這種技術中，將計算功能添加到控制內存陣列的邏輯芯片是非?？尚械?。從技術上講，這是在內存附近處理，而不是在內存中處理。第三個介于兩者之間。對于像 HBM 這樣的某些堆疊式存儲器，通常有一個邏輯芯片與 DRAM 共同封裝在同一堆棧中，而該邏輯芯片是面向 CPU 的總線與 DRAM 設備之間的接口。

HBM 的成功無疑幫助普及了 chiplet 的概念，在這種情況下，受到光罩限制或產量限制的芯片現(xiàn)在可以在多個 chiplet 上制造并集成到一個封裝中。然而，這現(xiàn)在需要 die-to-die 連接解決方案，這些連接解決方案可能比單個 die 上的連接解決方案慢。西門子 EDA 產品經理 Sumit Vishwakarma 表示：“當公司將芯片拆分成多個同質裸片時，您希望從拆分芯片進行相同的操作，而不會降低性能或精度?！?“你要確保兩者之間的延遲幾乎為零?！?/p>

實際上，這些小芯片是在系統(tǒng)環(huán)境中設計的，反之亦然?！斑@不僅僅是存儲器或控制器的設計，”是德科技副總裁兼 PathWave 軟件解決方案總經理 Niels Faché 說。“封裝中的 IC 設計會引入其自身的寄生效應。因此，您必須查看實用程序和阻抗水平的潛在變化。你真的需要將其視為一個系統(tǒng)，查看眼圖，了解如何根據(jù)系統(tǒng)的運行條件對其進行優(yōu)化?！?/p>

為此，設計團隊正在考慮將一些以前存在于包外的功能引入包中，從而顯著增加帶寬并減少延遲?！案鶕?jù)來源和接收方，這些目的決定了接口和協(xié)議，”西門子的 Thiagaraja 說?！坝嬎愕接嬎銓⑹且换厥?。對于計算到內存，相同的接口將大不相同。它可能與計算到 I/O 有很大不同。我們現(xiàn)在看到在同一個包中的 HBM 堆棧，它們也需要接口。您有這么多協(xié)議——USB、SATA、PCIe、CXL、DDR、HMC、AXUI、MIPI——這個列表還在繼續(xù)。由于要求，正在創(chuàng)建更新的協(xié)議，并且需要為這些芯片到芯片的連接提供新的接收器?！?/p>

多管芯系統(tǒng)的一大優(yōu)勢是可用的連接數(shù)量變得更大?！皬?I/O 的角度來看，我們曾經有 1,024 位總線，然后我們轉向了串行接口，”Jenkins 說?！暗罱l(fā)生的事情是那些串行接口現(xiàn)在變成了并行接口，例如 x32 PCIe，它由 32 通道的超高速串行連接組成?！?/p>

并行化也擴展到多核系統(tǒng)。Codasip高級技術營銷總監(jiān) Roddy Urquhart 表示：“四核系統(tǒng)運行類似操作系統(tǒng)，一些操作可以并行化，而其他操作本質上是順序的?！? “這就是阿姆達爾定律適用的地方。然后，還有其他新興挑戰(zhàn)，例如 AI/ML，您可以在其中利用數(shù)據(jù)并行性，并且通過使用該數(shù)據(jù)并行性，您可以開發(fā)非常專業(yè)的架構來處理非常具體的問題。嵌入式設備也有一些機會。我們一直在使用相當傳統(tǒng)的三級流水線、32 位 RISC-V 內核進行一些研究，使用谷歌的 TensorFlow Lite for Microcontrollers 進行量化，然后創(chuàng)建自定義 RISC-V 指令以使用非常有限的計算資源加速神經網絡. 現(xiàn)在，這在 IoT 的邊緣會很好地工作，在那里你可能需要進行簡單的傳感或簡單的視頻處理。但是對于增強現(xiàn)實或自動駕駛之類的東西，您要處理的視頻數(shù)據(jù)量要大得多。

這對處理方面有很大幫助，但這只是解決方案的一部分。McCalpin 表示，重點是讓 DRAM 更大，而不是讓它們更快。DRAM 周期時間在過去 20 年中基本保持不變，性能的所有改進都來自突發(fā)發(fā)送更大的數(shù)據(jù)塊。如果通過 HBM 可以使用更多的通信通道，這可能會使內存周期時間成為瓶頸。

工作負載

如前所述，系統(tǒng)性能取決于工作負載。不可能針對所有事情優(yōu)化通用機器。“弄清楚這種平衡迫使人們重新思考人們如何處理這個問題，”艾特肯說。“根據(jù)你是誰和你在做什么，解決‘我有一個我理解的非常具體的工作負載，并且我對自己的計算世界有足夠的控制’的問題的解決方案是我實際上可以設計一些東西它是為優(yōu)化我的工作量或類似我的工作量的工作量而定制的，無論我想做什么，它都會從中受益?！?/p>

即使像 AI 這樣的任務也代表不同的工作負載?！叭绻憧慈斯ぶ悄?，它有兩個方面，”西門子的 Vishwakarma 說?！耙粋€是訓練，在訓練中你需要不斷地訪問記憶，因為重量就在那里。你不斷地改變權重，因為你在訓練模型。在那里，溝通是關鍵。然而，如果你看推理，模型已經訓練好了，你所要做的就是 MAC 操作。你沒有改變權重。重量是固定的?！?/p>

Aitken 說，創(chuàng)造正確的平衡需要一種共同設計的方法?！拔医鉀Q這個問題的方式，以及我將算法分配到各個組件的方式，是解決問題的理想方式嗎？一旦確定這是我想要的通用算法結構，您就可以將其映射到一些具有預定義計算能力、預定義帶寬等的對象上。如果我決定我需要一個自定義處理對象，我可以將它們放在一起。這些都是問題的要素。這個領域有很多機會，隨著越來越多的人想嘗試這個東西，這一點會變得很明顯?！?/p>

即使在硬件領域內，也需要進行大量協(xié)同設計?！坝幸粋€架構階段，您可以在其中評估多管芯的各種場景，”Thiagaraja 說?！凹軜嫀煹闹饕P注點實際上是芯片內以及芯片外的吞吐量和帶寬。另一方面，您的物理設計團隊必須找出管芯的最佳尺寸。由于產量和功率，它不能太大。它不能太小，因為這樣您就必須在每個芯片中處理更少量的計算。他們是從權力和面積的角度來看的。然后你就有了設計團隊，他們必須為他們構建接口和協(xié)議。

計算范式

對于某些問題，使用傳統(tǒng)軟件本身可能導致解決方案效率低下。這發(fā)生在從單核到多核的過渡以及 GPGPU 的采用期間。業(yè)界正在等待它發(fā)生在新一代 AI 硬件上。

“GPU 有一個實現(xiàn)點，它是一個大規(guī)模并行計算對象，可以做各種事情，而不僅僅是渲染形狀，”Aitken 說?！昂芏嗳硕荚谂ρ芯窟@些類型的架構在未來會是什么樣子。對于 AI，在采用 TensorFlow 或你擁有的東西與“我能想出一些新方法、一種新架構來處理更好地解決類似問題的替代方法嗎？”之間存在緊張關系。對此有很多猜測。有很多人在嘗試，但我不知道有沒有人達到可以用它做 GPGPU 的水平，并說這是從現(xiàn)在開始的前進方向。如果他們這樣做會很酷?！?/p>

并且有一些非常具體的硬件步驟可以應用于 AI 以完全克服內存?zhèn)鬏攩栴}。Vishwakarma 說：“模擬計算有不同的方法來看待同一個問題，但從不同的角度來看?！?“如果你想做一個數(shù)字加法器，一個加法器大約需要七八個門。每個門可能有四五個晶體管。只需將兩個數(shù)字相加，您就會看到大約 50 個晶體管。但是如果你采用模擬方法，你基本上連接了兩根電線。這是最新的。對于具有此 MAC 運算（乘法和累加）的推理，您可以使用模擬計算并將權重存儲在閃存中。在這里，您采用了不同的方法來進行整體計算?！?/p>

“幾十年來，我一直是這項技術的忠實擁護者，”Cadence 的格林伯格說?！?然而，當它即將起飛時，它似乎總是被數(shù)字領域的進步所取代。也許有一天我們會把模擬計算視為一種‘超越摩爾定律’的技術，但我們還沒有完全達到模擬戰(zhàn)勝數(shù)字領域的地步?！?/p>

模擬領域的幾家有前途的初創(chuàng)公司都失敗了。當難以比較時，很難銷售一個全新的概念。Lightelligence 工程副總裁 Maurice Steinman 表示：“計算能力通常是通過數(shù)據(jù)中心架構師用作評估供應商解決方案的方法的基準測試來看待的?！?“基準測試結果通常表示為原始性能，或根據(jù)‘其他重要因素’的性能，例如成本、面積或能源——基本上是完成了多少工作以及成本是多少。”

業(yè)界似乎對原始處理器性能視而不見?！癈PU 本身具有一定水平的原始計算能力——基本上，這東西的單線程性能是多少，”Aitken 說?！氨M管這不是全部指標，但它仍然是衡量系統(tǒng)能力的有用指標。然后還有更廣泛的指標，例如每瓦操作數(shù)。這是衡量系統(tǒng)整體效率的關鍵指標。擺脫對加速器上每瓦原始 TOP 的迷戀是一項挑戰(zhàn)，但它是在什么上運行的，以及必要的數(shù)據(jù)是如何到達那里的？那需要多少瓦？這留給用戶作為練習?！?/p>

結論

添加更多或更快的處理內核固然很好，但除非您能讓它們保持忙碌，否則您就是在浪費時間、金錢和電力。你能讓他們忙碌的可能性正在降低。具有正確的內存?zhèn)鬏斉c計算比率的算法數(shù)量正在減少。

隨著 DRAM 遷移到封裝中，我們可以預期潛在帶寬將持續(xù)增加，人們越來越擔心 DRAM 性能在過去 20 年中沒有增加。如果DRAM制造商不能解決這個問題，那么行業(yè)將不得不自己解決這個問題。

轉載微信公眾號：半導體行業(yè)觀察

聲明：本文版權歸原作者所有，轉發(fā)僅為更大范圍傳播，若有異議請聯(lián)系我們修改或刪除：zhangkai@cgbtek.com