<address id="thnfp"></address>

    <address id="thnfp"><th id="thnfp"><progress id="thnfp"></progress></th></address>
    <listing id="thnfp"><nobr id="thnfp"><meter id="thnfp"></meter></nobr></listing>
    dvbbs
    收藏本頁
    聯系我們
    論壇幫助
    dvbbs

    >> 電腦專業知識交流
    搜一搜相關精彩主題 
    安易免費財務軟件交流論壇專業知識交流電腦知識交流 → 全球芯片荒,行行都"缺芯"?

    您是本帖的第 90 個閱讀者
    樹形 打印
    標題:
    全球芯片荒,行行都"缺芯"?
    莫問天涯
    帥哥喲,離線,有人找我嗎?
    等級:黑俠
    文章:620
    積分:4215
    注冊:2020年8月20日
    樓主
      點擊這里發送電子郵件給莫問天涯

    發貼心情
    全球芯片荒,行行都"缺芯"?

      全球芯片荒延續的時間

      可能遠比想象的糟糕……

      邁克爾?戴爾先生接受媒體采訪表示

      “這種短缺可能會持續數年”

      一枚小小的芯片

      何以撼動世界,引發焦慮?

      今天就來聊聊

      關于它的故事

      近年來隨著智能化水平快速提高,諸多行業對芯片的需求加劇,至今已經被人類制造出來的芯片達上千種之多,分別適用于不同的設備并負責不同的功能。

      芯片背后的故事

      多重因素造成了席卷全球的芯片荒。自去年新冠肺炎疫情爆發,人們待在家里的時間明顯增多,消費電子、家用電器類產品需求增多,消耗了不少芯片。

      同時,全球芯片供應商巨頭所在地日本、美國分別發生海域強震、罕見暴雪,加劇了全球芯片供需失衡狀態。多家芯片制造相關企業局部運轉受阻、宣布暫時停產。

      這次芯片荒之所以引起熱議,還因為并非單一種類的芯片缺貨,而是消費電子、工業等各領域各類型芯片的全方面缺貨。

      在信息時代,芯片廣泛用于各種電子產品和系統,是高端制造業的核心基石。雖然只有指甲蓋大小,芯片卻內有乾坤,能裝下上千萬甚至過億的晶體管,代表著目前人類制造最精密的工藝,因而其設計制造也具有很高的技術門檻。

      我們先來了解一下芯片“誕生記”。一般說來,芯片制造大致可分為三步,從上游的IC芯片設計,到中游的芯片制造,再到下游的封裝測試。

      芯片設計作為芯片產業鏈上游,是整個芯片制造流程中最難、也是最具創新的重要環節,具有高投入、高風險特點。它分為前端設計(也稱邏輯設計)和后端設計(也稱物理設計):

      前端設計

      根據芯片規格書完成芯片的邏輯和集成,使用仿真驗證工具完成SOC的設計驗證。該階段有大量的小文件生成,對隨機IOPS要求很高,并要求目錄深度。

      后端設計

      根據前端設計產生的門級網表,通過EDA工具進行布局布線和物理驗證。該階段會生成很多大文件,對順序IO性能和存儲帶寬有比較高的需求。

      在設計階段,工程師用硬件描述語言(HDL)完成設計文件,隨后由計算機自動完成電路邏輯的編譯、化簡、優化、布局、布線和仿真,直至對特定目標芯片的適配編譯和邏輯映射等工作。芯片的用途、規格、特性、制成工藝,全部是在這個階段完成的規范和設計。

      隨著設計規模和復雜性不斷增加,包含芯片設計在內的各種半導體設計工具需要在成千上萬的高性能服務器上同時訪問數百萬個文件。由于芯片設計極其復雜,并且投入巨大,半導體公司非常重視該階段的技術工藝及基礎架構革新。

      圖片點擊可在新窗口打開查看

      如同其它非結構化數據,半導體設計數據也在成倍地增長。每過渡到一個新的技術節點,對半導體行業的數據存儲容量和性能要求都會增加一倍以上。而在這種指數級的數據增長和半導體設計需求變化中,半導體公司設計工作在存儲架構方面面臨著諸多瓶頸:

      影響性能

      傳統的半導體設計存儲架構需要在存儲組件之間進行手動數據遷移,以平衡半導體設計應用的性能。以往都是限制每個控制器頭的容量,以確保滿足性能要求,但這會給控制器附加太多的容量使其處于飽和狀態,這種情況隨著容量增加而性能無法提高變得更糟。

      磁盤空間利用效率低下

      存儲孤島之間的容量利用不均衡導致一些存儲卷沒有得到充分利用,而另一些存儲卷則被超額占用,其結果是有太多的存儲卷需要管理。人工手動管理各個存儲卷的數據和遷移數據以使其均勻分布,不僅破壞了性能,而且加重了運營負擔。

      多個管理點導致成本增加

      傳統的存儲系統擁有多個管理點。每個存檔者都需要單獨管理,備份和復制也變得越來越復雜。這些都增加了總擁有成本和運營成本。缺乏集中管理還使半導體公司處于戰略劣勢,削弱了他們擴展存儲的能力。

      此外,考慮到大量的文件和目錄,以及隨著時間的推移,設計文件的規模越來越大,并需要進行驗證測試,存儲系統必須使文件管理變得簡單,同時提供無縫、高性能的訪問。

      為了改變已經不適應目前半導體設計需求的傳統存儲架構,同時應對不斷增加的吞吐量和IOPs需求,高性能存儲解決方案成為解決問題的關鍵。

      為“芯芯向榮”注入創新力

      據IDC預測,今年半導體市場收入將達到5220億美元,消費類、計算、5G和汽車半導體需求將繼續強勁增長。半導體市場迎來了繁榮,許多相關企業乘勢而起。

      為了推動半導體行業更好地發展,戴爾科技以創新型橫向擴展存儲解決方案,為半導體設計提供高性能和存儲優化。作為網絡連接存儲(NAS)平臺,戴爾易安信PowerScale將半導體公司各部門、項目、團隊和整個半導體設計工作流程整合到一個統一的存儲解決方案中,簡化工作流程,加快產品上市時間。

      圖片點擊可在新窗口打開查看

      *PowerScale由英特爾至強處理器提供支持,該處理器采用軟件定義的基礎設施和敏捷云架構,為PowerScale提供了卓越的性能和效率,可加速要求嚴苛的文件工作負載,使企業發揮數據資本的價值,加速業務的數字轉型。

      值得注意的是,PowerScale OneFS操作系統將各節點的內存、I/O、CPU和磁盤結合成一個有凝聚力的存儲單元,并且OneFS存儲管理的復雜性不會隨容量的增加而增加。

      總體說來,半導體設計選擇PowerScale可以在以下五個方面帶來顯著改善:

      01、提升存儲效率

      一個PowerScale集群可同時用于各種工作負載,包括設計目錄服務、文件共享,以及為半導體領域大規模并行、計算密集型批處理工作,提供瞬時抓取數據。半導體公司還可以使用SmartPools自動將特定工作負載分配到更經濟高效的存儲層。

      此外,在線數據壓縮和在線重復數據刪除功能,也增加了有效存儲容量,同時降低存儲成本。PowerScale的平均磁盤利用率超過80%,可以說是目前半導體行業市場上最高效、最具成本效益的存儲解決方案之一。

      02、更高的性能

      與傳統的存儲系統只能縱向擴展相比,PowerScale能夠使系統橫向擴展,借助PowerScale容量和性能線性增長的特性,就可以將單個節點的性能增加到PB級。該全閃存陣列可以說是IOPS密集型半導體工作負載的理想選擇,能夠為邏輯綜合、門級仿真、功能驗證和軟件構建提供強力支持。

      03、大規模的可擴展性

      PowerScale借助OneFS強大的橫向擴展體系結構能力,可以讓半導體公司根據需要共享、歸檔文件,動態配置所需的恰當的容量和性能,而無需過度配置存儲或進行推倒重來式的升級。同時簡化了管理、備份和災難恢復操作。

      04、易于使用和管理

      對于半導體等行業客戶來說,PowerScale中的DataIQ能夠幫助他們更好地對已經擁有的數據采取行動和提取價值。它能發現跨越文件、非結構化存儲的所有數據,并在公有云中創建全局搜索和索引,允許企業通過一個單一管理平臺直觀查看所有非結構化數據,有效打破數據孤島。

      圖片點擊可在新窗口打開查看

      05、支持多云

      PowerScale for Multi-cloud可以作為托管服務與所有主要的公有云直接連接,這對于正在尋求利用云功能的半導體公司來講是理想選擇。并且,OneFS for Google Cloud可以提供高達46倍的最大讀取吞吐量和高達96倍的最大寫入吞吐量。這為Google Cloud用戶提供了更好的云原生服務。

      借助戴爾易安信PowerScale提供的高性能、可擴展性等服務,半導體公司可以實現存儲基礎架構現代化,在整個設計工作流程中共享半導體數據,從中獲得更多價值。

      圖片點擊可在新窗口打開查看

    ip地址已設置保密
    2021/5/27 17:19:23

     1   1   1/1頁      1    
    網上貿易 創造奇跡! 阿里巴巴 Alibaba
    北京安易天地軟件有限公司北方論壇
    聯系電話:010-51268244 13611231185 QQ:511102924
    Powered By Dvbbs Version 7.1.0 Sp1
    頁面執行時間 02.31250 秒, 5 次數據查詢
    Channel