cmodel模擬器開發
對于一個公司來說，產品的設計周期就是生命線，一般來說都會在設計功能級仿真的c-model后直接轉向RTL設計。
在目前的技術下，做cycle-by-cycle的設計和直接RTL設計的時間，感覺是差不太多的。nVidia同時維護functional and timing 的simulators。
第一個model是否能跑流行的game也是一個問題。
需要快速的開發，debug，不然就又到下一代產品了。
維護一個好的team，做算法，做架構的，做電路的，做實現的，互相討論，互相了解彼此的領域。
用什么語言倒是無所謂，在大家討論出結果時，各個工作組都有實現方案了，而且每組都可以用自己最熟悉的工具。
對于一個公司來說，產品的設計周期就是生命線，一般來說都會在設計功能級仿真的c-model后直接轉向RTL設計。
對于GPU性能分析(Graphics Pipeline Performance Turing)，就不一樣了。用RTL來跑的話，不但占用License，而且比較耗費時間。對于一個不是特別大的公司來說，License還是比較貴的。如果RTL跑起來比較浪費時間的話，做性能分析的，一定會多開幾個不同參數的RTL同時運行，一般來說，開個七八個任務同時運行測試場景是很正常的，如果一個組有好幾個Performance Turing工程師，就要占用好幾十個NCverilog License，而且還要占用相同數量的CPU時間。除了NV/AMD/Intel這種不在乎license數量的公司以外，小公司里別人還干不干活了。
Cmodel又不帶時序，需要一個帶有時序的Cmodel，對于公司內部某些特定需求的團隊（比如性能調優相關的項目組）還是有意義的。
如果只是function 驗證，可以用 verilator 來跑, 可用 systemc 來加速模擬 verilog 的行為, 之后再根據synthesis RTL 后的結果，分析出 critical path 部份. 就可以根據這結果修改 RTL verilog 再模擬. 其實就是不斷的模擬驗證… ps: 不過也先要有前端的design 跟驗證。
如果只是function 驗證，可以用 verilator 來跑, 可用 systemc 來加速模擬 verilog 的行為。
對verilator很久經驗么？跟別的工程師說過verilator，可能更相信carbon，更愿意花10w塊美刀去買license……。
在傳統的HW Design上，不外乎通過verilog 驗證，跑跑RTL 的Function Check, 等Function 確定好后，用Design Compiler 轉出Gate Level, 在驗證Time 是否滿足 setup time and hold time, 如不符合，就改Design，或者是改變設定的 constrain，就一直不斷的Try and Test。相對的，會花很多時間在Debug上面。軟件不像硬件一樣，可以由斷點分析，用software break 的方式，做Inside Register的 Debug。除非在HW中加入JTAG的機制。用ICE 來Emulator HW內部的flip-flop所暫存的值, 但在HW Design 初期, 根本不可能會把JTAG做進去，能不要每天加班就好了。在初期只能用NC-SIM 來模擬，看看Waveform寫些TestBench去測。這樣一來一往就話費了不少時間，如果能夠用更快速的驗證方式，通過軟件來驗證硬件的結果, 就可以減少在Design所花費的時間。
性能模型用處不大。
在設計中考慮性能的地方主要有：
1.設計方案的時候，這時候是要把性能計算好的。如果這里沒有計算好，后期就麻煩大了。
2.開發時候，嚴格按照方案來做，可能會有一些方案沒有想到的地方，及時反饋，修改。這時候按照方案里面的計算框架應該對開發有指導意義的。
3.測試的時候。在功能測試完畢后，但是這時候對于性能已經幾乎沒有什么能改進的了。

所以做方案的時候一定要把性能計算好。越到后期修改的可能性越小。
在上面三個階段中，第一階段主要是計算（計算可以用模型來仿真，覺得得不償失，超大邏輯除外）。第二階段是沒有時間和精力來做性能仿真的。第三階段應該fpga/asic已經完成了，性能仿真模型其實沒有什么意義了，在實際的芯片上測試，比仿真模型要真實/快速/實際多了。
隨著GPU可編程越來越靈活，人工計算的靜態性能評估已經不那么有用了。很多時候性能和程序的特性相關，必須要針對主流應用來做優化，沒有統計的方法，很難量化這個數據。只有拿到了主流應用的量化數據，才能優化和分配流水線上的資源。比如大多數應用對于“存儲器訪問”和“數據計算”比例是平均訪問一次存儲器后計算50條指令，那就要分配計算資源和緩存資源的比例，包括考慮到Cache尺寸多大才能滿足一個合適的命中率，要支持多深的Non-blocking Cache訪問才能隱藏延遲，并且不至于耗費太多的帶寬，而這些都和應用的特性有關。如果這個比例在未來的主流應用中改變了行為，那還要變換參數。這個通過手工沒有辦法算出來，只能實際測試。
如果非常容易手工計算的話，那么像NV這樣的公司，有上千個GPU架構師（GPU Architect）。設計的第一代卡性能也是非常不靠譜的，往往要等到第二代第三代卡的時候才能有一個比較滿意的設計，包括功耗和性能權衡。而這種優化離不開性能模擬器。
對很多GPU供應商來說，同樣如此，比如客戶需要更高性能的芯片，那好，為了使性能提高一倍，需要把流水線寬度（注意是寬度不是長度）增加4倍，并且顯存帶寬（bandwidth of video memory）增加數倍才可以。但是這里面就有一個落差，就是性能不能隨著并行度的增加線性增長，這里面必然有瓶頸。那此時怎么辦？怎么調整流水線的負載平衡（load banlance），靠手算么？流水線上每一級都是程序控制的，如果不分析程序在不同Stage都耗費了多少Cycle的話，那怎么知道哪里是瓶頸呢？首先，第一步要找到性能瓶頸，然后第二步才是改進。
怎么找？用手上的ASIC來找性能瓶頸，也許可以，但是這需要足夠數量的performance counter,這個在設計制造之初有么？現在就算假設有，那么第二步，怎么知道那種改進方案是最優的呢？可能需要不斷地嘗試，比如，增加或者減少不同片上資源的數量，比如某個Cache的尺寸，某個FIFO的深度，或者是BUS上某個Local memory的容量，等等。從而調節流水線的負載平衡。而ASIC都是定制好的，怎么調？怎么觀察性能的改變？難道用加速器么，加速器的編譯時間本身就是很長。也許可以增量編譯。但是加速器大家都在搶，首先要保證功能驗證的需求，可能分給性能調試組的機時都非常少了，根本不夠用。 如果在服務器上面仿真還要占用License，會導致很多麻煩，仿真時間長不說，而且七八不同參數嘗試的實例同時跑，性能調試組N個人一起這么干，別人就別干活了。
性能模擬器就是為了完善這個而產生的，第一代產品只是為了搶市場，而第二代和第N代等后續產品，才是真正成熟的產品。而憑經驗給參數的做法，在可編程器件上不那么好使，雖然不到和拍腦袋的那個級別，但是也是不夠用的。架構級別不優化，結果產品出來功耗性能差，上面要發飆的。所以，做精細的性能模擬器，也是不得已而為之的事情。因為這是真正的可編程設備（programmable device），不是一個視頻編解碼那種不可編程的專用集成電路設計（ASIC Design）。
之前以為靠流片來改進性能很笨拙，一個MP4的公司，改進性能/驗證性能改善結果的做法是頻繁流片，瘋狂的時候一個月流一次。
（又是一個不用C Model來改進性能的例子）
不過，比較好奇這種做法：

1. 每次流片的成本大概多少？
2. 對項目來說，實際效果如何？(畢竟理論上ASIC的可見度，沒有C Model可見度高，也許通過分析算法，在ASIC的某些關鍵點做performance統計)。
   首先，直接silicon級別的性能統計？那需要插很多性能計數器（performance counter）吧，不然怎么觀測呢？分析方法是什么呢？
   其次，投片（tape-out）一次最快流程也要1個月，但是這需要大晶圓廠才可以，比如SIMC或者TSMC，小的成本更低的晶圓廠往往都走三個月的流程。
   以前還有門海（gate-sea）技術實現的投片，就是在襯底上吧晶體管都預先排列好，然后在沒有客戶的情況下預先生產，最后不同的客戶只需要在預先準備好的襯底上，光刻出來不同的金屬連線就可以了（就好像蛋糕店預先生產好蛋糕坯子，不同的客戶就擠出來不同的奶油圖案一樣），所以流程更快（比一個月還要短），不過貌似在深亞微米級別好像沒見過了，是不是因為線延遲增加的緣故。
   最后，投片成本，5平方毫米的MPW一般五萬到十萬，能到0.18個工藝吧（不知道最近行情怎么樣）。不過還有封裝費用（如果管腳不多，可以直接封裝在版子上降低成本），
   另外，覺得如果需要2次MPW投片才能調整出來一個好的性能，那也就是2個月時間。有兩個月時間，都可以直接調好C model性能模擬了，從而改進RTL了。并且方法學可以集成到下個項目中，好處多多。除非大這個項目組身兼好幾個項目，所以這樣做是為了省時間，破財免災，不然老板就冤大頭了。
   性能模擬器能不能得到正確的書性能分析數據，這個在CPU性能模擬器這個問題中很常見。的確是需要按照需求來設計。
   比如，對于傳統的OGL ES1.1來說，沒有復雜的數據回路，流水線基本都是生產者-消費者關系，那么首先對于一個新項目而言，要解決的問題就是在這些Stage 之間插入多少深度FIFO，才能做到流水線復雜均衡（load balance），這就是需求。像之前Cqq大牛描述那種私有框架，在基本的需求就在于此。
   而現代GPU越來越復雜，如果用學術名詞描述GPU架構的話，基本上可以說是“多核心的多線程向量處理器陣列”，不再像傳統圖形流水線，大大增加了性能模擬器的設計難度。從復雜性角度來說，的確在這種情況下就應該把性能模擬器和功能模擬器完全分開做。但兩者不見得是文件級的數據傳遞。從項目進度的角度考慮，還是推崇由性能模擬器調用功能模擬器的方式。對于一個粗粒度的性能仿真來說，也許這需要在功能模擬器中多放置一些bool變量，這些只能標志位用于告訴性能模擬器，那些運算功能被使用到了。
   最近考慮這個問題，主要是針對一款芯片更早的性能調整和性能分析（performance analyzing & tuning）。在傳統的固定功能圖形水流線（fixed function graphics pipeline）上，可以依照簡單的帶寬計算公式和經驗來設計芯片，而不需要更多的測量流水線之間是否滿足于性能平衡。因為在固定管線下，圖形API調用程序的行為變換是很有限的，而存儲器帶寬和固定功能的計算公式就可以獲得很好的預估精度。
   但是在當前GPGPU的角度越來越近的情況下，這一情況發生了很大變化，面向通用計算（或是說流計算）后，無論是OCL還是Shader程序行為不再像固定功能圖形流水線API那樣的死板，變得非常靈活，從而使得可編程圖形流水線（programmable graphcis pipeline），使得程序可以寫出千變萬化的效果。這導致傳統的靠手工靜態計算的性能分析，變得不再可靠。必須更細致的更量化的考慮當前大部分程序的行為，以及未來可能出現的程序行為，從而決定如何改進GPU，如何分配片上門電路資源（resource of gate-level circuit on-chip）給不同的流水線階段（pipeline stage）。這就使得設計一個性能模擬器，在編寫下一個版本的RTL之前是非常有必要的事情，對于IP供應商來說，這也有助于在制作好RTL釋放包（release package）后，針對客戶不同應用，給出不同的IP配置建議。
   但是這里又有一個新問題，就是傳統來說，在設計GPU C-Model的時候一般都不會加cycle信息在上面，傳統的GPU c-model主要就是作為驗證流程（verification flows）中黃金參考模型（golden reference model）來使用，驗證平臺（testbench）只需要針對不同的流水線階段（或是模塊）寫出來不同的無周期行為級模型（或是硬件算法模型）就可以，不需要帶有任何周期信息。所以，一般來說當前部分GPU設計公司都指揮維護一個不帶有周期信息的GPU c-model。但是這個cmodel只能做功能仿真（functional simulation），并不不能做性能仿真（performance simulation）。
   對于一個公司來說，產品的設計周期就是生命線，一般來說都會在設計功能級仿真的c-model后直接轉向RTL設計，而不是在進行一個時鐘精確（cycle-accurate cmodel）的性能模擬器設計，在產品進度上這是不允許的。而且維護兩個c-model這也會導致公司運營的成本增加，并且項目管理的難度也大大增長！所以需要一個快速的性能模擬器方案。使用功能模擬器跟蹤（trace）出來每個GPU獨立模塊模塊，所接受到的圖形軟件程序的代碼流，比如那些三角形觸發了切割（cliping）操作哪些觸發了剔除（culling）操作。這個trace出來的信息被送入一個單獨的性能模擬器，這個性能模擬器不能執行程序，只能根據trace出來的代碼流來積累時鐘周期，從而計算出來流水線延遲和瓶頸。這樣，就可以在原有的c-model上利用原有的資源來最小程度上獲得一個早期的性能分析數據。并且把管理和維護成本做到最小。
   這個性能模擬器可以使用systemc來實現，就是相當于一個大的計數器，針對不同的執行來累加不同的時鐘消耗，而不需要填寫任何與時序和執行流水線無關的 無關的功能算法。systemc的TLM可以很容易的實現這個功能。

總結

以上是生活随笔為你收集整理的cmodel模拟器开发的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。