2009 . 8 . 30
----------------------------
之前試著把這整個放入到SystemC library提供的simplebus範例裡面
master用nonblocking的方式傳data給負責跟ModelSim溝通的module
可以正常跑
現在要把它放入宗胤學長寫得TLM2.0.1 SimpleMultiCoreBus
然後作個跑DCT的範例
目前還在看TLM2.0.1的傳輸
----------------------------
2009 . 8 . 18
----------------------------
因為先前的架構在client端必須等待pipe傳輸完畢後才繼續動作 擔心會影響模擬的速度
所以就想說在client端多一條thread來跑pipe,然後把SystemC module想丟的資料暫存到linking list
之後thread在逐一從linking list上讀取並用pipe傳送
Server端也一樣用一條thread跑pipe,把收到資料先暫存到linking list上,然後module需要資料時再自行讀取
但是老師提到說,由於SystemC 的kernel沒有multithread,所以這樣可能還是會影響模擬速度
我目前還感覺不太出來速度上有沒有比較快,可是改成這樣之後有個優點是
ModelSim的module收到的每一筆data,間隔的時間比較短,都可以控制在下一個clock就能收到下一筆資料,因為data都暫存在linking list上,所以只要pipe收的速度夠快,每筆data進入verilog module的時間就可以控制為每個clock都收到一筆data
原先的架構 - verilog module收到的每筆資料時間間隔比較大 :
目前的架構 - verliog module能在每一個clock收到一筆：
----------------------------
2009 . 8 . 14
----------------------------
上次那個波形圖只有收到0和11的值,其實是因為我直接按Zoom full
然後中間那些值都疊在一起看起來像沒有值.........抱歉是我呆了........
原圖一直Zoom in後就可以看到那些值了：
後來才發現說只會掉一兩個值,然後原因是我pipe部份的bug,當client偵測到server正在忙碌或尚未有server在等待client時,整個client pipe要關掉重連,不然會有錯誤
SystemC module裡面要確定上一筆資料送出後才送下一筆,不然還是會有data沒收到的情形
這邊我寫成在Server收到資料後就先把pipe鎖起來,等到module送出data後,再將pipe解開
目前已經可以正常傳資料並顯示波形圖
----------------------------
2009 . 8 . 11
----------------------------
為了要測試OpenESL和ModelSim之間的連接 , 做了以下的測試
在ModelSim裡面跑一個SystemC module與Verilog module的System(簡稱MS_system)
MS_system沿用7.17號的架構,並在main_sysc.cpp裡面加入 win32的 thread來執行pipe,
以便於跟另外一個SystemC module組成的系統(簡稱SysC_system)溝通
大致上整個的架構圖如下：
我原先是希望SysC_system裡的fsm module一直丟int的data給SysC_to_MS module
然後SysC_to_MS module透過pipe將data送給MS_system , 並由MS_system的main_sysc.cpp接收
PIPE分成Server端和Client端 , 這邊我把SysC_system裡的SysC_to_MS module視為Client端
MS_system裡的main_sysc.cpp視為Server端
Server端寫在thread中 , 一直block住等待Client端的連接 , 一旦有Client連接上 , 並立即接收資料
然後將接收的資料丟給load.v
Client端原本我是寫成當有資料要傳遞時 , 就產生一個thread來傳資料 , 傳完後此thread就關閉
然後因為怕說會有因為等待Server接收的時間 , 造成傳送的順序打亂的情形 , 我加入了Semaphore在 Client端控制 , 但是順序一樣還是亂的 , 後來發現說Semaphore只能確保一次只有一個thread進行傳送 , 不能確保thread的傳送順序
所以後來就把thread和Semaphore拿掉,變成Client端的整個系統要等待PIPE傳輸完資料後才繼續執行
PIPE目前我寫成一次只傳一筆的資料 , 目前只是測試 , 之後如果有影響執行速度的話會在改成
累積多筆data再一起傳送
[目前遇到的問題是]
MS_system裡負責跑PIPE Server的thread能夠正常的接收到Client傳送的資料
我是寫成當Server接收到一筆資料就立刻丟給跟load.v相連的port
然後load.v在clk的posedge時接收 , 進行處理後在丟給接下去的module
但是波形圖跑出來卻實際上在MS_system裡面傳送的只有部份的data
也就是說 Server接收到每一筆資料 , 並丟給verilog module 但是verilog module卻沒有接收到完整的資料
如下圖:
跑PIPE的thread確實接收到每一筆資料 1～11
波形圖跑出來卻只有收到兩個 0和11
我猜測 應該是Server傳送給load.v的速度太快 導致它來不存取
我有試著用Sleep去卡Client端的傳送速度 發現說有比較改善 load.v有收到較多的資料
所以可能會看看加入一個port來判斷說load.v確實接收到Server的資料後才允許Server繼續丟下一筆來自client的資料
----------------------------
2009 . 7 . 17
----------------------------
補充一下測試的方式
連接的架構如下:
cclk使用SystemC產生的clock
main_sysc.cpp用finite state machine不斷的把值從aadder送出去
然後load.v單純接收 再丟給decrease.v
decrease.v接收到資料後 把值減1 將結果存在 dec
跑出來的波形圖如下:
找到 modelsim 6.3 g
modelsim裡面使用的gcc compiler版本 ： modelsim-gcc-3.3.1-mingw32.zip
（安裝方法:直接解壓縮把資料夾丟入modelsim的安裝路徑即可）
單純測試在modelsim中連接verilog module和SystemC module
可以成功跑出模擬
23 則留言:
很棒! 謝謝你這麼就有結果. 接著我想做一個例子跟OpenESL接起來. 然後再跟FPGA接起來. 就像我說的, 用OpenESL來當中介, 而事實上, 我們現在用的FPGA可以自由地讓我們在一定的現至下像使用HDL Simulator一樣來用. 我們一起來想個Example吧!
一但成功後, 我們來做一個Code Gen, 自動讓User把RTL code加output, bridge 到SystemC裡, 再用FPGA公司提供的介面, 自動生一個SYstemC module把兩邊連起來.
有幾點可以試的:
1. 用blocking的方式
2. 建立一塊shared memory與Mutex
3. Hand-shake機制, 這點跟blocking類似
詳細的實作方式可以跟DNA討論
老師我後來發現那個波形圖
其實是有收到資料的...哈
只要一直Zoom in就可以看到中間接收的那些值
因為SystemC的clk跑很快
所以前面那一大段 0 的值是等待另一個process連接的時候花得時間
後面那一大段11也就是收到的最後一個值,
因為後來沒有值再進來了,所以一大段都是11
我在想這樣子雙方的運作方式是否會讓模擬速度變慢呢? 還是這是不得不然的方式呢?
會變慢 因為client沒有用thread去跑Pipe
所以整個SystemC會等pipe傳完才開始動
然後ModelSim那邊應該是不會影響
我想試看看,如果client改成把module想丟給pipe的資料存到linking list上之後就不管pipe送資料的情形
再讓一條thread去讀取linking list上的資料用pipe丟出去,這樣就不需要等待pipe傳完
ModelSim那邊也多一條linking list先把收到的資料存起來,等module可以接收時再自行取用
不知道這樣的想法合適嗎？
我们的經驗是:
也許不行.
這是因為SystemC的Kernel其實不是真正multi-thread在執行的. 不過你可以試試看你的方法. 這一點請DNA或出來講講話.
我們現在請敬倫與佳殷學弟在traceKernel. 希望有一些新的information來提供改進的空間.
我的意思是你可以做一版, 要是沒效, 你會知道為何沒效, 這比我們講要記憶深刻多了. 不過要認真做, 不要因為我說可能沒效就輕易放棄, 這樣就失去我的原意了.
用來跑pipe的thread是win32的thread
(不是sc_thread )
因為pipe的server端有一個函式會block住直到有client的連接進入才會繼續執行
至於client也用win32 thread跑pipe的原因是,他有可能會因為server端正在處理上一筆資料而等待,如果不用thread去跑,會卡到整個SystemC system
請教一下你說的non-blocking是指TLM的protocol嗎？
如果是的話，那它的timing mapping到modelsim時，是如何做的？
SystemC的和ModelSim的clock是各自跑的
兩邊的clock沒有同步
SystemC這邊的module會把要丟給ModelSim的資料先存到link list裡面
然後再交由thread(不是sc_thread)去負責丟
所以丟給ModelSim的資料只是順序正確,沒有做到cycle accurate
你說的是指原本在modelsim就如此了嗎？
(不是我們現在用的透過pipe的方式)
不是的
是透過pipe的兩邊,clock是沒對上的
ModelSim裡面的SystemC module和Verilog
module他們是吃同一個clock
也就是說ModelSim內的SystemC 是Cycle-based的，我的理解有錯嗎？
那在ModelSim裡可以用TLM嗎？
謝謝回覆 :)
我也想知道.
另外我們提到過, 兩邊如果要sync, 那要如何處理呢?
ModelSim 在 6.x 版之後就改成Single-Kernel Simulation, 能Support Verilog/VHDL/SystemC, 而且都遵照Standard.
看它的文件有說到sc_port<>的部分,要做一些修改後才能在ModelSim跑,我沒有看很詳細,不過應該是跟aaa學長講的一樣可以跑TLM
如果兩邊要sync,可能就需要抓time stamp的資料丟給MoedlSim,但是模擬速度可能會變慢
沒問題, 要求Timing自然慢一點, 這是user可以選擇的.
哈囉~~
請問一下，最近使用linux 上的modelsim與systemc做連結，會出現Failed to open design unit file "*.cpp" in read mode的問題，不知道各位能提供一些意見或經驗嗎?感恩
哈囉~~最近使用linux版本的modelsim與systemc做連結，會出現這個問題Fail to open design unit file "*.cpp" in rea mode，想請問能否提供一些建議或者是經驗幫忙解決呢?感恩
Hi JOJO:
我們會把這個tool整合到我們的OpenESL裡面去, 近期內會更新, 問題也會在那邊描述.
我可以知道您的身分嗎? 我們雖然很Open, 但是還是想知道用我們的東西的人是哪些人.
哈囉~~
我是研究所專班的同學
最近想試著在centos4的modelsim6.3a裡籤入systemc code，發現原本在windows下可以compile的東西在centos裡會一直有問題，所以上網找看看有沒有人有這方面的經驗。不知道你們是否有遇到過相同的問題，或是有成功在linux上跑modelsim嵌systemc的環境呢?
謝謝囉
^^
clock的問題
剛剛看到的，不知道是不是你所想要的
Simulation Time Units
You can specify the time unit for delays in all simulator commands that have time arguments.
For example:
force clk 1 50 ns, 1 100 ns -repeat 1 us
run 2 ms
Note that all the time units in a ModelSim command need not be the same.
Unless you specify otherwise as in the examples above, simulation time is always expressed
using the resolution units that are specified by the UserTimeUnit variable.
By default, the specified time units are assumed to be relative to the current time unless the
value is preceded by the character @, which signifies an absolute time specification.
謝謝cent學長,但是不是我要的XD
不過到是提醒了我在卡clock的時候要注意一下時間單位
張貼留言