當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

关于工业级GPU C-model所使用的性能模拟器(preformance simulator)

發(fā)布時(shí)間：2023/12/14 编程问答 39 豆豆

生活随笔收集整理的這篇文章主要介紹了关于工业级GPU C-model所使用的性能模拟器(preformance simulator) 小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

http://www.opengpu.org/forum.php?mod=viewthread&tid=2935

關(guān)于工業(yè)級GPU C-model所使用的性能模擬器(preformance simulator)?[復(fù)制鏈接]

ic.expert

管理員

注冊時(shí)間

2007-7-11

積分

32646

串個門
加好友
打招呼
發(fā)消息

電梯直達(dá) 1^# ?發(fā)表于 2010-7-4 06:58:20?|只看該作者?|倒序?yàn)g覽

最近考慮這個問題，主要是針對一款芯片更早的性能調(diào)整和性能分析（performance analyzing & tuning）。在傳統(tǒng)的固定功能圖形水流線（fixed function graphics pipeline）上，我們可以依照簡單的帶寬計(jì)算公式和經(jīng)驗(yàn)來設(shè)計(jì)芯片，而不需要更多的測量流水線之間是否滿足于性能平衡。因?yàn)樵诠潭ü芫€下，圖形API調(diào)用程序的行為變換是很有限的，而存儲器帶寬和固定功能的計(jì)算公式就可以獲得很好的預(yù)估精度。

但是在當(dāng)前GPGPU的角度越來越近的情況下，這一情況發(fā)生了很大變化，面向通用計(jì)算（或是說流計(jì)算）后，無論是OCL還是Shader程序行為不再像固定功能圖形流水線API那樣的死板，變得非常靈活，從而使得可編程圖形流水線（programmable graphcis pipeline）使得程序可以寫出千變?nèi)f化的效果。這導(dǎo)致傳統(tǒng)的靠手工靜態(tài)計(jì)算的性能分析變得不再可靠，我們必須更細(xì)致的更量化的考慮當(dāng)前大部分程序的行為，以及未來可能出現(xiàn)的程序行為，從而決定如何改進(jìn)GPU，如何分配片上門電路資源（resource of gate-level circuit on-chip）給不同的流水線階段（pipeline stage）。這就使得設(shè)計(jì)一個性能模擬器在編寫下一個版本的RTL之前是非常有必要的事情，對于IP供應(yīng)商來說，這也有助于在制作好RTL釋放包（release package）后，針對客戶不同應(yīng)用，給出不同的IP配置建議。

但是這里又有一個新問題，就是傳統(tǒng)來說，我們在設(shè)計(jì)GPU C-Model的時(shí)候一般都不會加cycle信息在上面，因?yàn)閭鹘y(tǒng)的GPU c-model主要就是作為驗(yàn)證流程（verification flows）中黃金參考模型（golden reference model）來使用，驗(yàn)證平臺（testbench）只需要針對不同的流水線階段（或是模塊）寫出來不同的無周期行為級模型（或是硬件算法模型）就可以，不需要帶有任何周期信息。所以，一般來說當(dāng)前部分GPU設(shè)計(jì)公司都指揮維護(hù)一個不帶有周期信息的GPU c-model。但是這個cmodel只能做功能仿真（functional simulation），并不不能做性能仿真（performance simulation）。

對于一個公司來說，產(chǎn)品的設(shè)計(jì)周期就是生命線，一般來說都會在設(shè)計(jì)功能級仿真的c-model后直接轉(zhuǎn)向RTL設(shè)計(jì)，而不是在進(jìn)行一個時(shí)鐘精確（cycle-accurate cmodel）的性能模擬器設(shè)計(jì)，在產(chǎn)品進(jìn)度上這是不允許的。而且維護(hù)兩個c-model這也會導(dǎo)致公司運(yùn)營的成本增加，并且項(xiàng)目管理的難度也大大增長！所以我們需要一個快速的性能模擬器方案。我的考慮是使用功能模擬器跟蹤（trace）出來每個GPU獨(dú)立模塊模塊所接受到的圖形軟件程序的代碼流，比如那些三角形觸發(fā)了切割（cliping）操作哪些觸發(fā)了剔除（culling）操作。這個trace出來的信息被送入一個單獨(dú)的性能模擬器，這個性能模擬器不能執(zhí)行程序，只能根據(jù)trace出來的代碼流來積累時(shí)鐘周期，從而計(jì)算出來流水線延遲和瓶頸。這樣，我們就可以在原有的c-model上利用原有的資源來最小程度上獲得一個早期的性能分析數(shù)據(jù)。并且把管理和維護(hù)成本做到最小。

這個性能模擬器可以使用systemc來實(shí)現(xiàn)，其實(shí)他就是相當(dāng)于一個大的計(jì)數(shù)器，針對不同的執(zhí)行來累加不同的時(shí)鐘消耗，而不需要填寫任何與時(shí)序和執(zhí)行流水線無關(guān)的無關(guān)的功能算法。systemc的TLM可以很容易的實(shí)現(xiàn)這個功能~~

以上看法是我從我的項(xiàng)目的需求角度來考慮的，一家之言，多多批評，不知道大牛怎么看呢？？
：〉

分享0收藏010

回復(fù)

使用道具?舉報(bào)

simplescalar

武騎尉（從七品）

注冊時(shí)間

2010-8-2

積分

串個門
加好友
打招呼
發(fā)消息

2^# ?發(fā)表于 2010-8-2 19:19:22?|只看該作者

對于一個公司來說，產(chǎn)品的設(shè)計(jì)周期就是生命線，一般來說都會在設(shè)計(jì)功能級仿真的c-model后直接轉(zhuǎn)向RTL設(shè)計(jì)

很同意這個觀點(diǎn)
在目前的技術(shù)下，做cycle-by-cycle的設(shè)計(jì)和直接RTL設(shè)計(jì)的時(shí)間，感覺是差不太多的~~

回復(fù)

使用道具?舉報(bào)

maxiaohan

版主

注冊時(shí)間

2009-6-8

積分

2425

串個門
加好友
打招呼
發(fā)消息

3^# ?發(fā)表于 2010-8-7 14:36:18?|只看該作者

nv好像就同時(shí)維護(hù)者functional and timing 的simulators.
不過他們積累比較深了。

回復(fù)

使用道具?舉報(bào)

zhangcheng

云騎尉（正七品）

注冊時(shí)間

2010-8-21

積分

串個門
加好友
打招呼
發(fā)消息

4^# ?發(fā)表于 2010-8-26 21:39:19?|只看該作者

但是第一個model是否能跑流行的game也是一個問題。
需要快速的開發(fā),debug，不然就又到下一代產(chǎn)品了

回復(fù)

使用道具?舉報(bào)

michael.xu

云騎尉（正七品）

注冊時(shí)間

2010-8-15

積分

串個門
加好友
打招呼
發(fā)消息

5^# ?發(fā)表于 2010-8-29 15:33:06?|只看該作者

我的觀點(diǎn)是維護(hù)一個好的team，做算法，做架構(gòu)的，做電路的，做實(shí)現(xiàn)的，互相討論，互相了解彼此的領(lǐng)域...

用什么語言倒是無所謂，在大家討論出結(jié)果時(shí)，各個工作組都有實(shí)現(xiàn)方案了，而且每組都可以用自己最熟悉的工具

Michael Xu

回復(fù)

使用道具?舉報(bào)

ic.expert

管理員

注冊時(shí)間

2007-7-11

積分

32646

串個門
加好友
打招呼
發(fā)消息

6^# ?發(fā)表于 2010-9-5 00:56:13?|只看該作者

對于一個公司來說，產(chǎn)品的設(shè)計(jì)周期就是生命線，一般來說都會在設(shè)計(jì)功能級仿真的c-model后直接轉(zhuǎn)向RTL設(shè)計(jì)

...
simplescalar 發(fā)表于 2010-8-2 19:19?

是啊，不過對于作GPU性能分析(Graphics Pipeline Performance Turing)的人來說，就不一樣了。用RTL來跑的話，不但占用License，而且比較耗費(fèi)時(shí)間。對于一個不是特別大的公司來說，License還是比較貴的。而且如果RTL跑起來比較浪費(fèi)時(shí)間的話，那做性能分析得兄臺一定會多開幾個不同參數(shù)的RTL同時(shí)在跑，一般來說，開個七八個任務(wù)同時(shí)跑測試場景是很正常的，如果一個組有好幾個Performance Turing哥們，那就要占用好幾十個NCverilog License，而且還要占用相同數(shù)量的CPU時(shí)間。除了NV/AMD/Intel這種不在乎license數(shù)量的公司以外，小公司里別人還干不干活了……

而Cmodel又不帶時(shí)序，所以需要一個帶有時(shí)序的Cmodel對于公司內(nèi)部某些特定需求的團(tuán)隊(duì)（比如性能調(diào)優(yōu)相關(guān)的項(xiàng)目組）還是有意義的~

回復(fù)

使用道具?舉報(bào)

funningboy

云騎尉（正七品）

注冊時(shí)間

2010-9-28

積分

串個門
加好友
打招呼
發(fā)消息

7^# ?發(fā)表于 2010-9-28 22:51:21?|只看該作者

可參考?http://funningboy.blogspot.com/2 ... temc-verilator.html
如果只是function 驗(yàn)證的話可以用 verilator 來跑, 可用 systemc 來加速模擬 verilog 的行為,??之後再根據(jù)synthesis RTL 後的結(jié)果分析出 critical path 部份. 之後就可以根據(jù)這結(jié)果修改 RTL verilog 再模擬. 其實(shí)就是不斷的模擬驗(yàn)證..... ps: 不過也先要有前端的design 跟驗(yàn)證拉

查看全部評分

ic.expert

80 字節(jié)以內(nèi)
不支持自定義 Discuz! 代碼

回復(fù)

使用道具?舉報(bào)

ic.expert

管理員

注冊時(shí)間

2007-7-11

積分

32646

串個門
加好友
打招呼
發(fā)消息

8^# ?發(fā)表于 2010-9-29 23:51:20?|只看該作者

可參考?
如果只是function 驗(yàn)證的話可以用 verilator 來跑, 可用 systemc 來加速模擬 verilog 的行為,??之 ...
funningboy 發(fā)表于 2010-9-28 22:51?

? ? 大牛對verilator很久經(jīng)驗(yàn)么？能不能說說：〉我跟別的工程師說過verilator，可能他們更相信carbon，更愿意花10w塊美刀去買license……

回復(fù)

使用道具?舉報(bào)

ic.expert

管理員

注冊時(shí)間

2007-7-11

積分

32646

串個門
加好友
打招呼
發(fā)消息

9^# ?發(fā)表于 2010-10-1 11:23:54?|只看該作者

可參考?
如果只是function 驗(yàn)證的話可以用 verilator 來跑, 可用 systemc 來加速模擬 verilog 的行為,??之 ...
funningboy 發(fā)表于 2010-9-28 22:51?

? ??
給大牛轉(zhuǎn)過來了，不然還得翻墻看………

[size=180%]System Level Design

在傳統(tǒng)的HW Design上,不外乎透過verilog 驗(yàn)證. 跑跑RTL 的Function Check, 等Function 確定好後,用Design Compiler 轉(zhuǎn)出Gate Level, 在驗(yàn)證Time 是否滿足 setup time and hold time, 如不符合就改Design 或者是改變我們設(shè)定的 constrain. 就一直不斷的Try and Test.相對的會花很多時(shí)間在Debug上面. 因?yàn)橛搀w不像軟體一樣,可以藉由斷點(diǎn)分析,用software break 的方式,做Inside Register的 Debug. 除非在HW中加入JTAG的機(jī)制. 用ICE 來Emulator HW內(nèi)部的flip-flop所暫存的值, 但在HW Design 初期, 根本不可能會把JTAG做進(jìn)去,能祈禱不要每天加班就好了....呵呵.所以在初期只能用NC-SIM 來模擬,看看Waveform寫些TestBench去測.這樣一來一往就花費(fèi)了不少時(shí)間,如果我們能夠用更快速的驗(yàn)證方式,透過軟體來驗(yàn)證硬體的結(jié)果, 就可以減少我們在Design所花費(fèi)的時(shí)間.

[size=180%]SystemC?

目前已走向SOC Design(System on Chip),以前是HW/SW分開測,相對的Coast 較高,也較沒效率.而SystemC 可以解決 HW/SW 間的Gate. 全部都用Software 模擬,且可以用 Eclipse 外掛.程式開發(fā)上也較方便.

"[size=180%]SystemC", 是我研究所專題所用到最平凡的語言,想說記錄一下,說不定之後會派得上用場呢.

SystemC 主要可分為 Communication, Computation 兩部分.

communication?: 為Protocl 的部分, 如PCIE, BUS, ...所要的Cycle or Delay...

computation?: 為Module內(nèi)部自己運(yùn)算所要的cycle, Delay. 像是 H.264, MPEG, PMU...、

在藉由這兩個軸,去定義出我們現(xiàn)在所在的Position,如底下所示. 藉由A -> F的過程,可以快速的勾勒出整個系統(tǒng)的架構(gòu).

?

SystemC 是以C++為基礎(chǔ),並加入Hw synchronous/asynchronous/event trigger 的概念進(jìn)去.

TLM (Transaction Level Model 0)
http://www.eettaiwan.com/ART_8800316267_480102_TA_5a6d92f3.HTM

Module : Black Box Name

Port : 接口 In/Out/InOut bit;

Processes: 處理續(xù), 可用 Clock/event trigger, 如加法運(yùn)算...

Interface: 介面, 可為Bus...

Channel : 類似Package, 內(nèi)部可定義 Header/Body ...的相關(guān)Class.

Event : 事件,

回復(fù)

使用道具?舉報(bào)

tianguau

驍騎尉（正六品）

注冊時(shí)間

2010-9-4

積分

163

串個門
加好友
打招呼
發(fā)消息

10^# ?發(fā)表于 2010-10-2 21:02:14?|只看該作者

版主現(xiàn)在想的是不是太多了。
我覺得在開始的時(shí)候不要貪多。
第一個目標(biāo)做的太大，容易失敗，也容易失去信心。
建議還是做一個簡單點(diǎn)的，先把功能完成，性能模型以后再說。
最好能在FPGA上驗(yàn)證一下。

RTL solution & Development

回復(fù)

使用道具?舉報(bào)

ic.expert

管理員

注冊時(shí)間

2007-7-11

積分

32646

串個門
加好友
打招呼
發(fā)消息

11^# ?發(fā)表于 2010-10-2 21:23:46?|只看該作者

版主現(xiàn)在想的是不是太多了。
我覺得在開始的時(shí)候不要貪多。
第一個目標(biāo)做的太大，容易失敗，也容易失去信心 ...
tianguau 發(fā)表于 2010-10-2 21:02?

? ??
多謝大牛提醒：〉不過我討論性能模擬器是因?yàn)楣卷?xiàng)目的需要，不是OpenGPU的，呵呵

以前都是看論文上面怎么怎么做性能模擬，還沒實(shí)際動手做過，還要考慮到環(huán)境的兼容性還有項(xiàng)目人力和進(jìn)度的要求，所以上來問問高人~~~希望大牛多多指點(diǎn)~~~

回復(fù)

使用道具?舉報(bào)

tianguau

驍騎尉（正六品）

注冊時(shí)間

2010-9-4

積分

163

串個門
加好友
打招呼
發(fā)消息

12^# ?發(fā)表于 2010-10-2 23:02:58?|只看該作者

在我的印象里面性能模型用處不大。
在設(shè)計(jì)中考慮性能的地方主要有：
1.設(shè)計(jì)方案的時(shí)候，這時(shí)候是要把性能計(jì)算好的。如果這里沒有計(jì)算好，后期就麻煩大了。
2.開發(fā)時(shí)候，嚴(yán)格按照方案來做，可能會有一些方案沒有想到的地方，及時(shí)反饋，修改。這時(shí)候按照方案里面的計(jì)算框架應(yīng)該對開發(fā)有指導(dǎo)意義的。
3.測試的時(shí)候。在功能測試完畢后，但是這時(shí)候?qū)τ谛阅芤呀?jīng)幾乎沒有什么能改進(jìn)的了。

所以做方案的時(shí)候一定要把性能計(jì)算好。越到后期修改的可能性越小。

在上面三個階段中，第一階段主要是計(jì)算（當(dāng)然計(jì)算不清楚了可以用模型來仿真，不過我覺得得不償失，超大邏輯除外）第二階段是沒有時(shí)間和精力來做性能仿真的。第三階段應(yīng)該fpga/asic已經(jīng)完成了，性能仿真模型其實(shí)沒有什么意義了，在實(shí)際的芯片上測試，比仿真模型要真實(shí)/快速/實(shí)際多了。

查看全部評分

ic.expert

RTL solution & Development

回復(fù)

使用道具?舉報(bào)

ic.expert

管理員

注冊時(shí)間

2007-7-11

積分

32646

串個門
加好友
打招呼
發(fā)消息

13^# ?發(fā)表于 2010-10-3 00:36:47?|只看該作者

在我的印象里面性能模型用處不大。
在設(shè)計(jì)中考慮性能的地方主要有：
1.設(shè)計(jì)方案的時(shí)候，這時(shí)候是要把性能計(jì) ...
tianguau 發(fā)表于 2010-10-2 23:02?

大牛說的很有道理，從前我們也是這么做的。但是隨著GPU可編程越來越靈活，手算的靜態(tài)性能評估已經(jīng)不那么有用了。很多時(shí)候性能和程序的特性相關(guān)，必須要針對主流應(yīng)用來做優(yōu)化，沒有統(tǒng)計(jì)的方法，很難量化這個數(shù)據(jù)。只有拿到了主流應(yīng)用的量化數(shù)據(jù)，我們才能優(yōu)化和分配流水線上的資源。比如大多數(shù)應(yīng)用對于“存儲器訪問”和“數(shù)據(jù)計(jì)算”比例是平均訪問一次存儲器后計(jì)算50條指令，那我們就要分配計(jì)算資源和緩存資源的比例，包括考慮到Cache尺寸多大才能滿足一個合適的命中率，要支持多深的Non-blocking Cache訪問才能隱藏延遲，并且不至于耗費(fèi)太多的帶寬，而這些都和應(yīng)用的特性有關(guān)。如果這個比例在未來的主流應(yīng)用中改變了行為，那我們還要變換參數(shù)。這個通過手工沒有辦法算出來，只能實(shí)際測試。

如果非常容易手工計(jì)算的話，那么像NV這個NB的公司，有上千個GPU架構(gòu)師（GPU Architect），當(dāng)然打醬油的居多……。那他們設(shè)計(jì)的第一代卡性能也是非常不靠譜的，往往要等到第二代第三代卡的時(shí)候才能有一個比較滿意的設(shè)計(jì)，包括功耗和性能權(quán)衡。而這種優(yōu)化離不開性能模擬器。

對很多GPU供應(yīng)商來說，同樣如此，比如客戶需要我們更高性能的芯片，那好，為了使性能提高一倍，也許我們需要把我們把流水線寬度（注意是寬度不是長度）增加4倍，并且顯存帶寬（bandwidth of video memory）增加數(shù)倍才可以。但是這里面就有一個落差，就是性能不能隨著并行度的增加線性增長，這里面必然有瓶頸。那此時(shí)怎么辦？我們怎么調(diào)整流水線的負(fù)載平衡（load banlance），靠手算么？流水線上每一級都是程序控制的，如果不分析程序在不同Stage都耗費(fèi)了多少Cycle的話，那怎么知道哪里是瓶頸呢？首先，第一步我們要找到性能瓶頸，然后第二步才是改進(jìn)。
? ??
怎么找？用我們手上的ASIC來找性能瓶頸，也許可以，但是這需要足夠數(shù)量的performance counter,這個在設(shè)計(jì)制造之初有么？？現(xiàn)在我們就算他假設(shè)有，那么第二步，我們怎么知道那種改進(jìn)方案是最優(yōu)的呢？可能我們需要不斷地嘗試，比如，增加或者減少不同片上資源的數(shù)量，比如某個Cache的尺寸，某個FIFO的深度，或者是BUS上某個Local memory的容量，等等從而調(diào)節(jié)流水線的負(fù)載平衡。而ASIC都是定制好的，怎么調(diào)？怎么觀察性能的改變？難道用加速器么，加速器的編譯時(shí)間本身就是很長。也許我們可以增量編譯。但是加速器大家都在搶，首先要保證功能驗(yàn)證的那幫子哥們的需求，可能分給性能調(diào)試組的機(jī)時(shí)都非常少了，根本不夠用。如果在服務(wù)器上面仿真還要占用License，會導(dǎo)致很多人不高興，因?yàn)榉抡鏁r(shí)間長不說，而且七八不同參數(shù)嘗試的實(shí)例同時(shí)跑，性能調(diào)試組N個人一起這么干，別人就別干活了……。

性能模擬器就是為了完善這個而產(chǎn)生的，第一代產(chǎn)品只是為了搶市場，而第二代和第N代等后續(xù)產(chǎn)品才是真正成熟的產(chǎn)品。而憑經(jīng)驗(yàn)給參數(shù)的做法在可編程器件上不那么好使，雖然不到和拍腦袋的那個級別，但是也是不夠用的。架構(gòu)級別不優(yōu)化，結(jié)果產(chǎn)品出來功耗性能差，上面要發(fā)飆的。所以做精細(xì)的性能模擬器也是不得已而為之的事情~~~因?yàn)檫@是真正的可編程設(shè)備（programmable device），不是一個視頻編解碼那種不可編程的專用集成電路設(shè)計(jì)（ASIC Design）。

回復(fù)

使用道具?舉報(bào)

cqq

版主

注冊時(shí)間

2010-9-18

積分

3881

串個門
加好友
打招呼
發(fā)消息

14^# ?發(fā)表于 2010-10-3 12:16:14?|只看該作者

本帖最后由 cqq 于 2010-10-3 12:18 編輯

回復(fù)?13#?ic.expert?

看來用verilator/carbon來找性能瓶頸，跟用手上的ASIC來找性能瓶頸，具有一樣的局限性。即：
增加或者減少不同片上資源的數(shù)量，比如某個Cache的尺寸，某個FIFO的深度，或者是BUS上某個Local memory的容量，等等從而調(diào)節(jié)流水線的負(fù)載平衡。而ASIC都是定制好的，怎么調(diào)？怎么觀察性能的改變？
RTL-to-C做法碰到這種改變片上資源數(shù)量的需求就比較笨拙了。畢竟需要修改RTL。

functional simulator和performance simulator分離是個很漂亮的設(shè)計(jì)和做法，支持樓主。
我暫未能提供其他觀點(diǎn)，只能密切關(guān)注中...

查看全部評分

ic.expert

80 字節(jié)以內(nèi)
不支持自定義 Discuz! 代碼

回復(fù)

使用道具?舉報(bào)

ic.expert

管理員

注冊時(shí)間

2007-7-11

積分

32646

串個門
加好友
打招呼
發(fā)消息

15^# ?發(fā)表于 2010-10-6 19:08:06?|只看該作者

回復(fù)??ic.expert?

看來用verilator/carbon來找性能瓶頸，跟用手上的ASIC來找性能瓶頸，具有一樣的局限性。 ...
cqq 發(fā)表于 2010-10-3 12:16?

? ? Performance Model在粗粒度調(diào)優(yōu)，RTL可以在細(xì)粒度進(jìn)行調(diào)優(yōu)。粗粒度的好處就是調(diào)優(yōu)速度快，但是不準(zhǔn)。不過verilator還是有個好處的，就是節(jié)約nc/vcs的lic數(shù)量~~，這個有時(shí)候也挺重要的，記得原來有一陣子lic緊張的時(shí)候?yàn)榱说纫粋€license等1個多小時(shí)……

回復(fù)

使用道具?舉報(bào)

cqq

版主

注冊時(shí)間

2010-9-18

積分

3881

串個門
加好友
打招呼
發(fā)消息

16^# ?發(fā)表于 2010-10-18 10:32:20?|只看該作者

本帖最后由 cqq 于 2010-10-18 10:39 編輯
ic.expert: 增加或者減少不同片上資源的數(shù)量，比如某個Cache的尺寸，某個FIFO的深度，或者是BUS上某個Local memory的容量，等等從而調(diào)節(jié)流水線的負(fù)載平衡。而ASIC都是定制好的，怎么調(diào)？怎么觀察性能的改變？ cqq: RTL-to-C做法碰到這種改變片上資源數(shù)量的需求就比較笨拙了。畢竟需要修改RTL。

之前我以為靠流片來改進(jìn)性能很笨拙，但是最近跟一個朋友聊過，他們公司是做MP4的，他們改進(jìn)性能/驗(yàn)證性能改善結(jié)果的做法是頻繁流片，瘋狂的時(shí)候一個月流一次。
（又是一個不用C Model來改進(jìn)性能的例子）

不過我比較好奇這種做法：
1. 每次流片的成本大概多少？
2. 對項(xiàng)目來說，它的實(shí)際效果如何？(畢竟理論上ASIC的可見度沒有C Model可見度高，也許他們通過分析算法，在ASIC的某些關(guān)鍵點(diǎn)做performance統(tǒng)計(jì))

80 字節(jié)以內(nèi)
不支持自定義 Discuz! 代碼

回復(fù)

使用道具?舉報(bào)

ic.expert

管理員

注冊時(shí)間

2007-7-11

積分

32646

串個門
加好友
打招呼
發(fā)消息

17^# ?發(fā)表于 2011-8-21 15:03:37?|只看該作者

cqq 發(fā)表于 2010-10-18 10:32?
之前我以為靠流片來改進(jìn)性能很笨拙，但是最近跟一個朋友聊過，他們公司是做MP4的，他們改進(jìn)性能/驗(yàn)證性 ...
首先，直接silicon級別的性能統(tǒng)計(jì)？那需要插很多性能計(jì)數(shù)器（performance counter）吧，不然怎么觀測呢？大牛說的分析方法是什么呢？

其次，投片（tape-out）一次最快流程也要1個月，但是這需要大晶圓廠才可以，比如SIMC或者TSMC，小的成本更低的晶圓廠往往都走三個月的流程。

以前還有門海（gate-sea）技術(shù)實(shí)現(xiàn)的投片，就是在襯底上吧晶體管都預(yù)先排列好，然后在沒有客戶的情況下預(yù)先生產(chǎn)，最后不同的客戶只需要在預(yù)先準(zhǔn)備好的襯底上光刻出來不同的金屬連線就可以了（就好像蛋糕店預(yù)先生產(chǎn)好蛋糕坯子，然后不同的客戶就擠出來不同的奶油圖案一樣），所以流程更快（比一個月還要短），不過貌似在深亞微米級別好像沒見過了，是不是因?yàn)榫€延遲增加的緣故……

最后，投片成本，5平方毫米的MPW一般五萬到十萬，能到0.18個工藝吧（不知道最近行情怎么樣）。不過還有封裝費(fèi)用（如果管腳不多，可以直接封裝在版子上降低成本），

另外，我覺得如果需要2次MPW投片才能調(diào)整出來一個好的性能，那也就是2個月時(shí)間。有兩個月時(shí)間，我們都可以直接調(diào)好C model性能模擬了，從而改進(jìn)RTL了。并且方法學(xué)可以集成到下個項(xiàng)目中，好處多多。除非大牛說的這個項(xiàng)目組身兼好幾個項(xiàng)目，所以這樣他們做是為了省時(shí)間，破財(cái)免災(zāi)，不然老板就冤大頭了……

回復(fù)

使用道具?舉報(bào)

draziwest

上騎都尉（正五品）

注冊時(shí)間

2009-3-9

積分

752

串個門
加好友
打招呼
發(fā)消息

18^# ?發(fā)表于 2011-8-22 17:02:02?|只看該作者

本帖最后由 draziwest 于 2011-8-22 17:07 編輯

這東西原理上沒啥深奧的。肯砸時(shí)間，砸人，CMODEL上一樣可以加上timing信息。花的精力越多，精度自然越高，當(dāng)然嘛，運(yùn)行速度也會慢下來。不過，總還是比RTL快一些的。

根據(jù)項(xiàng)目需要進(jìn)行取舍吧。對高風(fēng)險(xiǎn)的特性，覺得performance model不靠譜的，可以考慮實(shí)現(xiàn)得精確一些。在項(xiàng)目的不同階段也可以選擇不同的精度的模型。

我覺得，可以針對目前出現(xiàn)的具體問題來考慮該不該做timing simulator。針對某個具體的功能，確實(shí)發(fā)現(xiàn)根據(jù)performance model算出來的結(jié)果和RTL出入很大。先找出來為啥不準(zhǔn)，然后再看是否需要實(shí)現(xiàn)一個簡單的timing simulator。具體做法，我覺得老大提出的抓trace，然后用trace驅(qū)動simulator的辦法就很好了。

有一點(diǎn)要注意的是，對稍微復(fù)雜的系統(tǒng)，正確的timing simulator同時(shí)也要求功能正確性。

查看全部評分

ic.expert

回復(fù)

使用道具?舉報(bào)

draziwest

上騎都尉（正五品）

注冊時(shí)間

2009-3-9

積分

752

串個門
加好友
打招呼
發(fā)消息

19^# ?發(fā)表于 2011-8-22 17:12:58?|只看該作者

ic.expert 發(fā)表于 2010-10-3 00:36?
大牛說的很有道理，從前我們也是這么做的。但是隨著GPU可編程越來越靈活，手算的靜態(tài)性能評估已經(jīng)不那么 ...
手工算出來的一般都不準(zhǔn)。不過這通常都是項(xiàng)目早期大牛們干的事情....

回復(fù)

使用道具?舉報(bào)

ic.expert

管理員

注冊時(shí)間

2007-7-11

積分

32646

串個門
加好友
打招呼
發(fā)消息

20^# ?發(fā)表于 2011-8-23 14:32:47?|只看該作者

draziwest 發(fā)表于 2011-8-22 17:02?
這東西原理上沒啥深奧的。肯砸時(shí)間，砸人，CMODEL上一樣可以加上timing信息。花的精力越多，精度自然越高， ...
大牛的說的很對，大牛說的性能模擬器能不能得到正確的書性能分析數(shù)據(jù)，這個在CPU性能模擬器這個問題中很常見。的確是需要按照需求來設(shè)計(jì)，

比如對于傳統(tǒng)的OGL ES1.1來說，沒有復(fù)雜的數(shù)據(jù)回路，所有流水線基本都是生產(chǎn)者-消費(fèi)者關(guān)系，那么首先對于一個新項(xiàng)目而言，要解決的問題就是在這些Stage 之間插入多少深度FIFO，才能做到流水線復(fù)雜均衡（load balance），這就是需求。像之前Cqq大牛描述那種私有框架，在基本的需求就在于此。

而現(xiàn)代GPU越來越復(fù)雜，如果用學(xué)術(shù)名詞描述GPU架構(gòu)的話，基本上可以說是“多核心的多線程向量處理器陣列”，不再像傳統(tǒng)圖形流水線，所以這大大增加了性能模擬器的設(shè)計(jì)難度。從復(fù)雜性角度來說，的確在這種情況下就應(yīng)該把性能模擬器和功能模擬器完全分開做……但兩者不見得是文件級的數(shù)據(jù)傳遞。從項(xiàng)目進(jìn)度的角度考慮，我還是推崇由性能模擬器調(diào)用功能模擬器的方式。對于一個粗粒度的性能仿真來說，也許這需要在功能模擬器中多放置一些bool變量，這些只能標(biāo)志位用于告訴性能模擬器，那些運(yùn)算功能被使用到了。

回復(fù)

使用道具?舉報(bào)

draziwest

上騎都尉（正五品）

注冊時(shí)間

2009-3-9

積分

752

串個門
加好友
打招呼
發(fā)消息

21^# ?發(fā)表于 2011-8-23 22:31:50?|只看該作者

ic.expert 發(fā)表于 2011-8-23 14:32?
大牛的說的很對，大牛說的性能模擬器能不能得到正確的書性能分析數(shù)據(jù)，這個在CPU性能模擬器這個問題中很 ...
在項(xiàng)目初期通常也不可能構(gòu)建精確的性能模擬器。針對你說的問題，我覺得用c++簡單模擬時(shí)鐘就足夠了。比如，用queue<type>來模擬fifo，用對象來模擬流水線stage。

至于是否需要引入function simulator，就取決于workload，timing和功能正確性有沒有關(guān)聯(lián)了。

回復(fù)

使用道具?舉報(bào)

總結(jié)

以上是生活随笔為你收集整理的关于工业级GPU C-model所使用的性能模拟器(preformance simulator)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。