在每年找工作的時候，在校學生就會分割成軟件崗位和硬件崗位兩大陣營。心儀軟件崗位的同學就是專注于各種算法和語法寶典；而立志硬件崗位的同學則會專注于數字電路、模擬電路、單片機、FPGA。出現這樣的情況，一方面是因為個人興趣和工資收益使然，另一方面也是因為公司招聘崗位的刻意引導。

　　哪怕是對軟件和硬件都有涉獵的同學，也不得不在軟件和硬件之間做出選擇。但實際工作中的崗位遠不是硬件和軟件這么簡單的劃分。現在，推薦一個需要涉獵軟件和硬件的崗位——集成電路系統建模工程師。

　　1.集成電路設計流程方法的演進與軟件對于集成電路設計的作用

　　從60年代集成電路出現到今天，集成電路設計流程經歷了三次較大的變革。每一次變革都使得軟件在集成電路設計中起到越來越大的作用。

　　1.1專業分工：前端設計和后端設計

　　在最開始的時候，集成電路的設計完全依賴于基于標準器件的手工操作。工程師需要自己繪制電路版圖，再交付制造工序。在這一時期，模擬集成電路和數字集成電路在設計流程上的區分還不明顯。

　　圖1. 手工繪制版圖（來源：網絡）

　　這種方式顯然不能適應大規模集成電路的設計。隨著設計流程分工細化，出現了“前端+后端”的設計流程。前端設計側重于邏輯設計/功能設計，將一個想法轉化成邏輯電路的原理圖。后端設計側重于物理設計，將這個電路轉化為可以制造的版圖，包括布局、時鐘樹、布線、設計規則檢查等等。前端設計完成并且驗證通過后，將原理圖提供給后端設計；后端設計完成并且驗證通過后，將版圖交付制造工序。

　　“前端+后端”的設計流程對于數字集成電路和模擬集成電路是通用的。對于數字集成電路，前端設計和后端設計已經演化為了相互獨立的兩個部門。公司內部也常常按照前端設計（邏輯設計）和后端設計（物理設計）劃分部門。前端設計更側重于邏輯設計（與或非的布爾邏輯），不需要考慮物理設計的細節。不過模擬集成電路并沒有非常徹底的前端和后端分工。前端設計和后端設計都需要充分考慮晶體管半導體特性以及布局布線的細節才能夠滿足設計規格。

　　圖2. “前端+后端”設計流程

　　“前端+后端”也是一個相互迭代的過程。如果后端工程師發現無法滿足設計規格的時候（時序違例、面積過大、功耗過高等），可能會要求前端設計進行相應的調整。隨著工藝的進步和芯片設計參數的提高，這種反饋越來越強。

　　設計流程的發展和鞏固還依賴于流程化的電子設計自動化（EDA）工具的出現。龍頭EDA工具商都提供全流程的EDA工具鏈。這些工具鏈能夠滿足設計者從想法到流片的全部設計和驗證流程，甚至可以引導設計者完成設計。Synposys公司的EDA工具牢牢占領著國內數字集成電路的市場，DC+VCS和ICC+PT+VCS是國內大部分設計公司的標配。Cadence公司的EDA工具在模擬集成電路設計和數字電路設計后端市場，尤其是數模混合芯片市場具有不可替代性。畢竟Cadence是做后端工具起家的。FPGA的設計工具也是類似的情況，Intel的Quartus和Xilinx的Vivado都能夠引導用戶完成一次完整而有效的設計。

　　“前端+后端”已經成為集成電路設計的主要流程，迄今沒有顛覆性的變化。目前設計流程的發展趨勢可以概括為：提高EDA工具的自動化程度，減少人工干預和接入，降低設計門檻，提高生產率。

　　1.2提升自動化程度：芯片設計軟件化

　　在硬件描述語言（HDL）出現之前，前端設計和后端設計的接口就是原理圖。但是設計一個復雜電路的原理圖是非常辛苦和耗時的。目前，HDL已經完全取代了原理圖作為前端設計的載體。前端工程師將設計想法轉化為HDL描述。隨后，綜合工具將HDL描述轉化為網表。網表用標準單元的連接描述電路。前端設計和后端設計的接口接受用HDL語言描述的網表。常用的HDL語言就是Verilog和VHDL。

　　HDL的出現，讓前端設計師得到了充分的解放，也讓數字集成電路設計出現明顯的軟件化趨勢。

　　首先，從形式上，HDL代碼與計算機軟件程序非常相似。不過這里必須要說明，HDL代碼與計算機軟件程序有明顯的區別，即便是在行為級描述。HDL代碼是對電路行為或者連接的描述，而不是類似于軟件程序那樣的可執行程序。相對于軟件語言，HDL語言特別加強了對于并行化的描述和位運算的描述。以Verilog HDL為例。在Verilog中，賦值分為阻塞賦值和非阻塞賦值，以描述信號之間的并發關系。Verilog相對于高級軟件編程語言，補充了比特級別的信號類型。

　　其次，HDL代碼可以通過腳本來生成。HDL代碼的呈現形式是文本文件。這就使得，可以用腳本程序（比如python，perl等）來生成一個有規律的HDL代碼文件。通過腳本生成的HDL代碼經過綜合之后得到的電路，會與行為描述產生的電路等效，甚至會比通過行為級描述產生的電路更加簡化。這是因為，HDL代碼的不同寫法只是對相同電路功能的不同描述而已。只要功能（輸入和輸出的對應關系）一致，那么綜合得到的電路就是等效的。比如，對于一個8比特數除3求余數和模數。直接的想法是寫一個除法器按照移位減法進行計算。同時，也可以寫一個腳本，直接生成256個輸入對應的輸出，并用case結構寫成一個Verilog模塊。生成的腳本綜合出的模塊就是一個組合邏輯。綜合工具會使得電路結構最簡。這一種策略在實際工程中經常遇到。

　　此外，HDL代碼是可以直接仿真的。但是，仿真是串行執行的，所以HDL語言還要規定大量的仿真規則以規定HDL代碼在仿真時的行為。在仿真時，EDA軟件借鑒了軟件的概念來提供調試功能（單步調試、信號值等）。這使得HDL代碼更加類似于軟件，也使得HDL代碼的概念變得混亂。

　　1.3 SoC設計方法學：IP核和“攢”芯片

　　隨著芯片集成能力的提升，由一家設計公司完成電路中所有模塊開發的成本顯著提高。模塊的定義、開發、驗證是一個消耗時間和人力的工作。另一方面，隨著SoC設計方法學的流行，芯片內部的組成模塊也越來越趨同。一款SoC芯片內部一般都由CPU核、片內互聯、片內存儲、DRAM接口、USB接口等基本模塊以及各種慢速外設組成。這就使得不同設計公司之間可以復用設計。

　　在這樣的背景下，產生了一類IP供應商。這些IP供應商為設計公司提供充分驗證過的成熟的IP模塊。設計公司向IP供應商支付可觀的費用（仍然可能低于設計公司自行開發模塊的成本）。最典型的IP供應商就是ARM了。這家公司通過向全球的SoC廠商提供處理器核、片內總線等相關IP核，不僅成功的存活了幾十年，還牢牢占據了全球嵌入式處理器的市場，不容Intel染指。當然，ARM的IP稅也是讓各大公司有苦難言。Synopsys和Cadence也在IP供應市場產生可觀的份額。

　　IP核的出現、成熟和豐富，產生了一種新的芯片設計形式，即“攢”芯片。設計公司只需要專注于自己的芯片中獨到的部分，并做到有亮點盈利。其他部分都可以通過購買各種IP獲得。比如一款實現某種算法的SoC，其中的算法模塊是公司的獨到專利，由設計公司自己設計、驗證并優化。這款SoC中的CPU核（作為交互控制接口，運行固件）、片內互聯、視頻編解碼、內存接口以及視頻接口都可以通過購買IP獲得。

　　總而言之，集成電路設計流程的最大的特點就是分散和專精。從設計到制造，需要經過很多公司的接力才能完成。從IP提供商、EDA工具商、設計公司到制造商，每家公司都可以決定最終芯片的質量，卻又不能保證最終芯片質量。反過來，對于設計公司來說，使用已經經過充分驗證的流程和IP，可以顯著降低公司自己的研發成本和風險成本。對于小公司以及創業公司，尤為如此。對于大公司而言，出于供應鏈安全性和定制化的考慮，可能會在IP核上進行布局，但是一般不會布局EDA工具。

　　在片上系統的設計流程中，模型的地位得到了重要的提升，尤其是對于完整系統的建模。相對于單一功能的芯片，片上系統的復雜度空前的提高，完整走完一塊芯片的“前端+后端”流程是非常耗時而且非常昂貴的。設計公司顯然不能為所有的設計方案都實際做一次流片，也不可能用一次次流片來修正設計方案的缺陷。因此，設計公司紛紛用模型研究來進行設計方案的探索和評估。一方面，開發建模的成本要低得多了，而且模型的靈活性高，迭代速度快。另一方面，模型能夠反映設計特性。基于模型仿真的分析結果能夠反映設計的實際情況。

　　2.設計流程向前延伸——建模

　　“前端+后端”的設計流程是以詳細的和完整的設計規格書為起點的。前端工程師將設計規格書轉化為HDL描述，繼續完成整個設計流程。這確實是一個很完備的設計流程。

　　不過，如果設計規格書就定義錯了或者定義不完善呢？在芯片功能較為簡單、設計規格較為明確的時代，可以在驗證階段（前端驗證或者后端驗證）發現設計規格不能滿足設計需求。進而反過頭來修改和完善設計規格書，再重新進行設計和驗證的迭代。但隨著集成電路規模的不斷提高，“設計+驗證”的迭代周期變得很長。如果到了驗證階段才發現技術路線錯誤，這樣浪費的人力和時間成本就太大了。因此，如何驗證設計規格是否正確就變得至關重要了，因為這決定了后續的工作是否在正確的道路上前進。

　　2.1建模的目的

　　在進行復雜集成電路設計時，對將要設計的集成電路進行建模驗證成為了保證集成電路設計不犯“方向性錯誤”的不二選擇。對集成電路進行抽象建模的目的可以歸納為三個方面。

　　第一個方面，通過軟件仿真研究建模對象的性質和規律。這里需要研究的規律包括物理特性的規律，比如晶體管的電路模型、功耗模型等。還需要研究的是需要實現的功能的參數特性。通過模型仿真，可以得到某一個參數與某個性能指標的定量關系。對于復雜的系統，這種定量關系往往都是無法通過公式直接計算得到顯性的解析結果，必須要依靠仿真模型經過多次迭代和逼近后得到數值結果。

　　舉一個分析截斷誤差的例子，以Cordic算法進行單精度浮點數的開方運算（僅作為舉例，浮點數開方一般不用Cordic算法）。單精度浮點數有23位尾數，組成1位整數和23位小數的定點數。如果直接以這樣的精度計算，那么平均誤差相當于最后4個比特是無效的。為了能夠降低誤差，需要對參與中間計算步驟的定點數擴展為1位整數和30位小數的定點數。計算完成后，再截斷為符合單精度浮點數定義的尾數。中間計算步驟的位擴展具體參數就需要通過建模和仿真來加以驗證。

　　另舉一個片上互聯的例子。在片上網絡中，路由器中的緩存大小對于網絡吞吐率的影響雖然可以用一些理論模型來加以描述，但是這類模型通常只能給出吞吐率的上界。通過模型仿真，可以明確的得到緩存大小與網絡吞吐率的量化對應關系。

　　第二個方面，建模可以對設計方案和設計規格進行初步驗證或并以此為基礎探索更優的設計方案。在架構設計階段，可以快速實現多種設計方案的模型，并且通過模型仿真設計方案的特性，明確哪種設計方案最具有繼續研究的價值。在這一方面的應用中，模型驗證多用于參數選擇，比如確定算法中參與運算的各個變量的精度、網絡中緩存的大小、神經網絡的規模等等。

　　再舉一個架構設計的例子。多核異構芯片中的片上互聯結構設計時，需要滿足一些核心之間高密度數據流傳輸帶寬需求。這就使得，同構的片上網絡結構和路由算法不適用，而設計新的拓撲結構和路由算法能否真正達到設計需求就需要模型仿真來為其背書。

　　另外一個例子和工程密切相關。商業公司雖然可以從公開發表的學術論文中尋找設計方案，但學術論文在應用環境和驗證環境上常常語焉不詳。雖然學術論文都宣稱自己取得了顯著的參數提升，但是并不意味著這些方法都可以利用到的某個特定的設計中。如何甄別出對具體設計有價值的方案，也是模型的重要作用。

　　第三個方面，超前軟件開發。當下的大部分芯片都不再是完成某個固定功能的簡單模塊，而是一個集成在芯片上的完整系統。即便是為某一個單一功能的芯片，其中也通常集成了某種輕量級的CPU核來實現參數配置、數據交互以及功能管理，如藍牙芯片CC2640、充電器管理芯片SE8A等。所以，當下的芯片，大多常常需要固件、BIOS、OS等軟件配合。

　　按照傳統的開發模式，這些軟件的開發都只能在集成電路設計完成之后進行，最早也需要在FPGA原型驗證時進行。這不但造成軟件開發進度的延遲，軟件工程師也無法對集成電路的設計提出有效的意見。只能是硬件有什么，軟件就用什么。這顯然不是一種最優的開發方法。

　　而基于硬件模型可以將軟件開發的工作提前到與硬件同步進行。在硬件工程師按照模型設定的設計規格進行硬件開發的時候，軟件工程師也可以在這種模型上開發相應的軟件，并且運行調試。

　　更為重要的是，由于軟件工程師通過模型在設計早期就參與了芯片的設計，軟件工程師可以對芯片的軟硬件功能劃分和軟硬件接口提出有價值的建議。這些改動對于芯片設計完成后的軟硬件聯合優化可以起到非常重要的作用。

　　2.2建模對于設計流程的影響

　　建模可以貫穿在集成電路的設計流程，但是建模工程師則更多的出現在設計流程的早期，也就是在設計方案確定之前。

　　下面以實現某種算法型的SoC芯片為例來看一下建模工程師如何參與集成電路的設計。

　　2.2.1建立算法模型

　　在這款芯片的研發早期，建模工程師對芯片使用的算法建立模型，并且對算法模型進行仿真。這一過程中，驗證了算法的正確性和可行性。這時的算法模型是理想的。

　　接下類，考慮電路計算過程中引入的截斷誤差，也就是引入計算的精度。通過調整參與計算的數據的寬度，保證最終結果的精度也滿足要求。這樣就得到了算法的功能模型。也就說，這個功能模型輸出的結果應該是實際硬件電路輸出的結果相同。

　　再次對模型進行細化，考慮到計算電路的時序特性，并且補充算法模塊的輸入和輸出接口時序。這樣就得到的算法的時序模型。

　　通過上面的建模過程，完成了對算法的探索，得到了算法的設計規格。接下來，就可以接入集成電路設計的前端流程了。硬件工程師可以根據模型探索得到的設計規格重新編寫HDL描述。隨著高層語言綜合技術（HLS）的發展，硬件工程師也可以通過HLS工具將模型直接轉化為HDL描述。

　　2.2.2建立架構模型

　　這款算法芯片其實是一款SoC芯片。公司設計的算法模塊需要添加到一種CPU框架中，作為CPU核的一種外設或者協處理器。這里需要取舍的架構問題，例如：算法模塊集成到CPU核的哪一個層次（可以作為CPU核內部運算單元、CPU外部共享私有內存的協處理器、CPU核外部總線上掛載的獨立設備等）？CPU核如何調用該模塊（中斷/查詢/DMA/獨立訪存）？SoC需要為算法模塊提供多大的內存帶寬？架構模型可以對這些問題給出量化的評估。

　　硬件工程師可以使用IP核來復用成熟的設計。建模工程師也可以使用虛擬IP（VIP）來復用成熟的設計。虛擬IP由IP提供商、EDA廠商或“第三方”針對某種IP提供。VIP應與IP功能和時序相同。建模工程師將VIP與公司自己的算法IP的模型組合在一起，就得到了SoC的架構模型。基于架構模型進行各種仿真，例如運行各種標準的測試程序，就可以對于以上提到的各種問題加以驗證和評估。

　　同時，軟件工程師也會參與到這一個過程中。軟件工程師開發的固件可以在架構模型上運行，并且模擬對算法模塊的調用過程。因此，軟件工程師能夠對硬件和軟件功能的劃分和接口給出有價值的改進意見。

　　2.2.3 建立驗證模型

　　模型并不是只用于設計流程早期進行算法設計和架構設計的時候，算法模型和架構模型適當加以改造后還可以成為驗證階段的黃金（golden）模型。在相同的激勵下，如果模型和設計提供相同的結果，那么設計是正確的；反之，設計存在缺陷。黃金模型也提供了設計中的關鍵點的中間結果。這些中間結果在模型和設計中都可以找到，可以方便用來調試設計的缺陷。

　　還有一種模型的目的是為了實現軟硬件聯合仿真驗證。在設計流程中，除了使用測試向量驗證設計模塊是否正確，還需要驗證模塊能否使得實際系統滿足設計要求。對于流水線上的一個隊列緩存，測試向量只能驗證這個緩存能夠正確的讀寫數據，但是無法驗證這個緩存是否會成為流水線的瓶頸，進而影響流水線的吞吐率。

　　此時，系統中的其他模塊也同樣處于開發和驗證流程當中，顯然不可能為了驗證這一個模塊而搭建一個完整系統。另一方面，隨著集成電路規模的擴大，FPGA原型平臺的性價比越來越低。能夠容納大規模設計的FPGA原型平臺的價格也是相當可觀的。因此，最好的驗證辦法是將模塊放到由軟件模型構成的系統中。被測模塊以RLT代碼和FPGA原型的形式出現在驗證平臺中，系統中的其他模塊以軟件模型的形式出現在驗證平臺中。軟件模型向被測模塊注入符合實際情況的激勵，并且響應被測模塊的輸出。通過軟硬件聯合仿真環境，建模工程師可以獲得設計模塊對于完整系統的影響，評估設計模塊能否使得完整系統滿足設計要求。

　　2.3使用系統建模優勢

　　系統建模的核心優勢就在于一個“快”字。

　　系統建模仿真速度快是因為模型省略了一些功能特性和物理實現細節，那么系統模型仿真的速度肯定快于RTL編碼仿真的速度。這是因為RTL仿真是比特級別的，而軟件模型仿真是信號級別的。比如，RTL仿真需要仿真加法器中每一個比特的動作；軟件模型則只需要一條加法語句即可。其次，對于非定長結構，軟件可以用循環實現，并且只進行必要的循環；硬件不支持非定長結構，只能按照最大可能的結構展開，再通過使能關閉不需要的單元或者放棄不需要的結果。這導致RTL仿真時需要做大量冗余的運算。最后，RTL仿真是4值的（0,1,X,Z），軟件仿真是二值的（0,1）。

　　當然，模型的精度（尤其是時序的精度）和速度是一對矛盾體，在提高仿真速度時必然會導致精度有一定損失，需要建模工程師根據建模的目的進行平衡。

　　開發速度快也是“快”的另外一方面。編寫軟件的成本要小于編寫硬件實現的成本。軟件和硬件開發的時間可以分為編寫代碼和調試bug。由于HDL不能支持可變循環等不定結構，所以硬件HDL的表達能力要遠小于軟件的表達能力。而且，由于調試方法的限制，調試軟件錯誤要比調試硬件錯誤容易得多。尤其是對于編碼過程中引入的bug，軟件調試要比硬件調試簡單很多。

　　3. 系統建模工程師

　　最后回到系統建模工程師的話題。系統建模工程師在設計公司中的人數不多，但是很重要。設計公司擁有的建模團隊的實力從一定程度上可以反映公司未來技術演進的實力有多強。有些公司沒有獨立的建模團隊，而是在架構團隊、設計團隊和驗證團隊中分散設置建模崗位或者人員。崗位的名稱也并不統一，只能通過崗位職責和技術要求判斷。附錄中列出部分公司的建模工程師的崗位。

　　3.1 系統建模工程師的主要職責

　　系統建模工程師的日常工作是主要是通過模型仿真對設計方案進行評估，完成“建模-仿真-評估”的迭代。首先，根據項目需要建立模型。然后，進行仿真，收集數據。為了能夠反映出設計的正面和負面影響，仿真要涵蓋盡可能多的應用環境（測試程序或測試向量）。最后，分析仿真數據，評估設計方案能否滿足設計需求、評估模塊或者系統設計方案有無缺陷等。

　　系統建模工程師的具體工作方向可以分為架構建模和驗證建模兩個方向。架構建模評估的是想法；驗證建模評估的是具體設計。

　　在架構建模方向，建模工程師的主要輸出就是用大量的仿真數據評估設計方案。當設計不滿足需求或存在缺陷時時候，架構建模還要被用來驗證改進方案能否修正設計缺陷并且不引起更多的問題。在仿真結束后應給出改進方案是否可行的結論，并反饋給方案的制定者（設計方案通常為資深架構師或設計主管共同協商確定）。

　　在驗證建模方向的工程師的主要職責是將電路仿真的結果與架構模型和算法模型的仿真結果進行對比，可以判斷電路功能是否正確。而仿真的結果要反饋給RTL設計人員，用于檢驗其RTL設計中存在什么問題。驗證方向的建模工程師還會為驗證模型和系統搭建軟硬件聯合驗證環境，提供作為激勵和收集被測模塊響應的軟件模型，開發信號交互的驅動。

　　3.2 系統建模工程師的能力

　　為了適應建模工作，系統建模工程師的能力要求與硬件開發工程師和軟件開發工程師有很大不同。

　　從技術方面，系統建模工程師需要具備廣闊的技術涉獵范圍，但是不要求樣樣精通。除了對于軟件設計和硬件設計的技術，系統建模工程師還要了芯片功能的相關知識，比如計算機原理、信號處理和AI等等。快速學習和快速上手能力是系統建模工程師區別于其他崗位最大的不同。

　　從人際交往方面，系統工程師不僅需要較好的人際溝通能力，還需要較強的技術溝通能力。為了獲取系統的特性并且反饋模型研究的結果，系統建模工程師需要與硬件和軟件開發工程師進行反復的交流。良好的人際溝通能力自然會使這一過程變得更高效。

　　另一方面，硬件工程師和軟件工程師的技術語言和體系是完全不同的。前端工程師和后端工程師的觀點和想法也會有不同。系統建模工程師要能夠以對方熟悉的方式與硬件或軟件工程師進行交流，這就是技術溝通能力。技術溝通能力建立在建模工程師對于技術的充分了解的基礎上，也建立在建模工程師的同理心和換位思考的角度上。

　　從個人性格方面，系統建模工程師需要對于技術保有單純的好奇和興趣。系統建模工程師需要學習很多方面的知識，而且每一個新項目都不是對之前項目的重復。如果沒有個性支撐，系統建模工程師也會陷入疲憊。

　　對系統建模工程師真正的挑戰在于，如何在沒有參考的情況下，確認模型實現和分析是正確的。如果模型有錯誤或者缺陷，那么會直接導致仿真結果和分析結果乃至決策結果錯誤。在沒有對應硬件系統的時候，系統建模工程師是沒有辦法對模型進行校準的。系統建模工程師必須要能夠根據對設計的理解，設計巧妙的測試程序，驗證模型是否正確。要做到這一點，需要建模工程師具有足夠的技術積累，并且深入理解被建模的設計。同時，建模工程師要具有縝密的思維和清晰的邏輯。

　　系統建模工程師“站得高，看得遠”。系統建模工程師可以學習到設計流程中各個環節的知識，不僅有邏輯設計的技巧，還有物理設計的體系，更有芯片用途的重要背景知識。最終，系統建模工程師是可以將這個系統講清楚的人。

　　系統建模工程師雖然可能接觸很多技術領域，不過沒有明確的技術提升路徑。如果系統建模工程師不能夠主動思考，認為完成建模和驗證的工作就夠了，那么系統建模工程師就在設計流程中陷入了被動的角色。系統建模工程師的技術提升依賴于工程師自己多想一點。對遇到的有趣現象的刨根問底，才使得系統建模工程師不斷夯實技術，提升技術。系統建模工程師可以通過建模來充分理解現有設計以及設計的內在規律，從而自己提出設計優化方案，在設計流程中占據主動。

　　附錄：部分公司對于集成電路建模工程師任職要求

　　職位1：RISC-V CPU設計/建模資深工程師

　　崗位職責

　　1.研發高性能RISC-V CPU Core；

　　2.制定/參與RISC-V處理器模塊微結構設計規范；

　　3.負責/參與開發RISC-V CPU性能/功耗模擬器、模型和測試集；

　　4.對性能、功耗、面積進行分析和權衡，選取RISC-V CPU優化設計方案；

　　5.負責/參與開發處理器模塊的RTL；

　　6.與驗證團隊協作，驗證CPU設計的正確性；

　　7.與物理設計團隊協作，實現時序收斂和功耗優化。

　　崗位要求

　　1.計算機科學、計算機工程或電子工程等相關專業學位；

　　2.有以下至少一項經驗：計算機體系結構知識；CPU微架構知識；CPU周期精準性能模擬器，如GEM5等；Power management, security等領域知識；

　　3.有工業界處理器研發經驗者優先；

　　4.良好的團隊合作精神，工作態度積極。

　　職位2：x86系統建模&性能分析工程師

　　崗位職責

　　1.針對CPU、Cache、系統總線、DDR控制器等關鍵部件構建性能模型；

　　2.仿真、分析現有系統架構的性能瓶頸；

　　3.探索新的架構設計方案、提供架構改進方面和初步性能評估參數；

　　4.搭建系統功能級仿真平臺，為固件、驅動開發提供支持。

　　崗位要求

　　1.計算機或電子工程相關專業；

　　2.具有良好的C/C++編程能力；

　　3.對計算機體系結構有較深入的了解，特別是CPU微架構、Cache設計及DDR控制器；

　　4.有計算機系統架構或SoC設計經驗者優先；

　　5.有SystemC開發經驗者優先；

　　6.熟悉計算機仿真技術者優先，如Bochs，Qemu，GEM5等；

　　7.有RTL設計經驗者優先；

　　8.熟悉x86匯編和體系結構這優先。

　　職位3：SoC性能模擬工程師

　　崗位職責

　　1.CPU微架構性能模擬器開發；

　　2.系統級性能模擬器開發；

　　3.基準測試程序性能分析和研究；

　　4.面向微架構的基準測試程序開發。

　　崗位要求

　　1.熟悉CPU微架構；

　　2.了解計算機體系結構；

　　3.了解linux kernel；

　　4.具備一定編譯器和指令集知識；

　　5.熟練C/C++以及python開發。

　　職位4：ESL架構師

　　崗位職責

　　1.芯片核心算法到整體架構的建模，ESL仿真平臺搭建，應用場景用例構建；

　　2.性能仿真數據分析，大數據自動化到智能化處理；

　　3.基于ESL流程負責完成IP建模、平臺構建和仿真，負責完成套片或芯片軟硬件調試和性能分析，實現架構探索和驗證；

　　4.負責芯片架構ESL需求和端到端計劃管理；

　　5.ESL平臺仿真速度和指令以易用性持續提升；

　　6.為有競爭力、高質量的芯片架構方案提供可靠依據和數據，能提供優化改進架構方案；

　　7.先進ESL開發流程、方法技術的探索。

　　崗位要求

　　1.具有良好的業務抽象和芯片系統分析能力，能夠使用SystemC/C+C/CSystemVerilog等語言已經芯片ESL建模和驗證。

　　2.熟練使用C或C++語言。

　　3.熟練使用腳本語言，比如perl、tcl、python等中的一種；

　　4.微電子、通信、計算機等理工類本科及以上學歷；

　　5.了解數字電路設計、微機原理；

　　6.善于溝通，具有很好的團隊協作能力。