HDL Simulator with ESL Platform - 哲榮

----------------------------
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
可以成功跑出模擬

cuda for slim - 塞公

--------------- 2009/08/25 ---------------

這次是主要要改寫slim 能讓cuda 在slim以multiprocess方式呈現並測試cuda在multiprocess的支援能力與正確性。可是上次是利用fork搭配system()函式(類似shell呼叫執行檔執行的方式) 來達成multiprocess的效果，是覺得有點不太恰當。所以又改回用fork的方式搭配execve()的方式把外部程式呼叫起來。不過所遇到的問題是cuda process有成功叫起來，不過執行到cudamalloc時，程式似乎異常終止，今天請DNA幫我看一下，發現是segfault問題，現在是繼續嘗試去解決。

另外，在未來要繼續實做上學期難產的waveguide model。計畫是先從介面下手，讓CAD製圖工具所畫出來的3D moudel可以讓我載入到opengl中使用。目前是先決定要以哪一種CAD輸出的檔案格式來當作我input的資料，較廣泛被使用的格式有DXF, DWG, IGES, STEP，不過前兩個檔案格式都是屬於AutoCAD公司所擁有，目前到底有沒有版權問題我看不太懂，不過wiki上面講好像有打過官司的樣子。不過現在好像很多公司都用逆向工程試著去讀寫.dwg格式，另外有一個是叫Open Design Alliance的團體自己出了一套軟體叫做DWGdirect試著去讀寫dwg檔案http://www.opendwg.org/，因為目前我有需要的是類似parser部分，所以可能會去參考一些opensource的東西。另外還有一個網頁是有自己寫了簡單的parser部分http://www.bearcave.com/dxf/ 如果要拿DWGdirect的lib或者source似乎有一點麻煩。都不太open的樣子。http://www.opendwg.org/education

因為這幾天也只是稍微涉略一下，另外還有IGES和STEP格式有在這個網站找到http://www.gcad3d.org/看起來好像很open的樣子而且像是用openGL寫的(沒仔細看)，不過對於我...只要挖出parser部分,code部分可能需要下一點功夫...找這麼多,最主要目的是可以找一個現成的parser可以讓我讀進CAD檔案格式的內容就好。希望是能讓我不要對於讀檔部分花太多時間。


--------------- 2009/08/17 ---------------

上禮拜提到:
1.在執行cuda程式時候，像是其他cpu工作是否真的會被block住?可以利用播放影片或者聲音檔來測試看看
　　實驗後的結果，發現在播放聲音mp3之類的，並不會因為執行cuda運算程式後被block住。而畫面依然是block的狀態。另外撥放影片時，只有影像部分會被block住，而當cuda程式結束後，影像就直接跳過cuda執行期間應該撥放的影像部分。

2.利用thread priority設定方式來調整各thread在cpu執行所占的比例。
　　實際測試，將執行cuda的cpu thread priority設低一點後，沒有改善畫面停滯的情形。

3.重新改寫multi-processes 程式。利用類似一支shell同時呼叫多個已經編譯好的cuda運算程式。目前還沒測試到錯誤的值出現。

4.之後想繼續研究人家是如何去寫cuda程式，使計算與顯示方面能無法察覺停頓的方式。

--------------- 2009/08/06 ---------------

問題應該只是顯示卡在處理資料運算時造成cpu一直等待資料回應使電腦暫時沒有回應。因為試過開兩個cpu thread跟一個cuda thread，在cpu thread 中每一秒就印一次計算的秒數，而cuda thread中就讓gpu thread做大量迴圈運算。單獨執行cuda thread約5.6秒。而三個thread同時運行時。雖然一開始畫面都沒有顯示，可是約五秒後，所印出的資料如圖:
也就是說，其實CPU thread也有在進行print out的動作，並沒有被等待回傳cuda結果的thread所卡住，只是可能有影響到I/O的動作，使得在kernel function結束之前output被卡住了。另外，利用multiprocess，實作相同程式方式也有類似的情況。

--------------- 2009/08/04 ---------------

利用mutex方式控制 gpu resource的分配，可是在故意將cuda運算量稱大一點後，讓他做一次kernel function需要花約3秒時間，可是在這3秒內。電腦幾乎不太能做其他事情，觀察cpu loading 都跑到100% 。所以猜想是這個kernel function thread 沒有被OS切換出去讓其他thread進來工作的關係還是有其他原因。之後確定之後，在想看怎麼解決。

--------------- 2009/07/29 ---------------

在meeting後對於怎麼把cuda放進去slim當中，有幾個重點或方向可以去做。

1. 利用對於cpu multithread的呼叫cuda kernel function 就多一個 cpu thread透過它來呼叫kernel function。也就是放到slim kernel中讓kernel來做呼叫的工作。
2. 利用semaphore的機制。控制每個component的kernel function呼叫。
3. 創一個child process讓他專門來做呼叫kernel function的工作，而scheduler部分就是交給device driver。

--------------- 2009/07/28 ---------------

這篇主要是維護 如何使slim能有效利用cuda的運算能力，目前研究的是如何在multithread架構上利用 cuda的運算。之前學妹有測試過一個 process只能一次跑在GPU device上，也就是一次只能執行一個 kernel function。如果是在 multithread 上執行會發生錯誤。

而接下來老師希望測試的是利用動態連結的方式做測試，也就是先將要放進cuda運算的function(也就是kernel function)先製作成動態連結資料庫(ex: .dll or .so)，然後在runtime時，再將kernel function動態載入到記憶體中。看看是否能達到multithread的效果。

我基本上大概測試是kernel function 是用來做矩陣的乘法。測的結果是透過每個thread都執行一次kernel function所算出來的結果是錯的。結果都是零(這部分我還要看一下)。而循序執行kernel function結果是正確的。

　
　

ESL BUS Module -ruru

======2009/08/17======

總合目前要做的幾件事情

1. ocp-ip bus module

ocp 官方的規格書,在閱讀過後,接著trace Coware的simple ocp bus. coware所提供的並非完全符合標準規格的bus,其中有滿多的部份沒有實行.

於是在ocp官網發現有發佈完整的ocp systemC module 目前已經看了一些部份

2. ARMA bus

以上的兩樣都是以systemC TLM2.0 去建立module,所以首先的工作是熟悉TLM2.0的相關寫法,早先所使用的interface都是屬於TLM1.0的部份,TLM2.0則改用socket去實現,因此在這段時間內TLM的部份大致如下：

Tlm 2.0 主要統一process之間的溝通 如何去實做 function call

1.首先include tlm.h 官方有提供

2. simple_initiator_socket 只是簡單範例的socket 實際在使用則會使用
tlm_initiator_socket and tlm_target_socket

The simple initiator and target sockets are so-called because they are simple to use. They
are utility classes derived from two underlying socket types tlm_initiator_socket and
tlm_target_socket.

3. 簡易的兩個模組 是tlm傳輸最簡單的想法 Initiators, Targets, and Sockets(interface 1.0)

4. 在兩模組的溝通上soket會建立好雙向的管道 傳輸卻只需一次的function call

5. 在傳輸的使用上 要先 setting 一些參數 如address bits 之類的

6. 在傳輸後 target 可以 response status

7. DMI (Direct Memory Interface) 利用socket的第二種傳輸 使用一個直接指向的pointer用以增
快模擬的速度 使用方法 則多了一些 fuction call

8. Debug Transport Interface 是socket的一種傳輸 和DMI最大不同就是主要用於debug

9. 也另外提供 non blocking transfer interface

10. Base protocol checker 可於兩個模組中間 去做確認傳輸的準確性

TLM2.0部份大致OK 目前已經著手在寫code的部份

======前提======

一顆SoC裡可能會有一顆到多顆CPUs, 還有周邊, 記憶體,...,等什麼的. 靠什麼來把資料在這中間搬來搬去呢? 太特殊的東西不談, 大概就是屬Bus以及NoC (Network on Chip). OpenESL比不上CoWare的有幾點, 但是最主要的就是我們缺乏一些IP的ESL Models. 其中又以Bus與CPU為最重要.

CPU方面, Aaa的32-bit RISC拿來做研究可以, 但是想必沒人真正會拿來用在產品上, 所以品皓的8051與DSP16(實際上是AD2191的clone)會是我們的主角, 至於32-bit RISC就要靠電機系陳中和老師的研究了.

Bus方面, Gary按照TLM2.0做了一版堪用的Bus, 不過這不太切合實際, 同樣也是拿來做研究而已. 我們需要的是標準的Bus models. 所以ruru的重點是:

1. OCP

2. AMBA2 or even AMBA3

這是短時間我們要弄出來的. 再加上一些週邊介面所常用的Model如I2C, 以及利用PC的resources來做simulation的呈現也是方便在simulation時可以watch結果的好工具.

ruru的工作的定義很簡單, spec都在標準裡, 請加油!

2005 WOCMAT/2005 電腦音樂與音訊技術研討會記錄

2005年, SCREAM Lab與數位學術界的前輩決定舉辦一次國內的研討會, SCREAM Lab負責論文與網頁的部分, 雖說做得不是太專業, 但總算完成任務, 這一次的會議辦得很成功, 就好像好朋友聚在一起相互切磋一樣, 所以WOCMAT就這樣年年辦下來, 而且也漸漸轉變成為一個國際會議了. 今年WOCMAT要辦第五屆了.

WOCMAT2009

以下是WOCMAT2005主辦人鄭士康教授為此次會議所寫的報告, 原文可在下面的Link看到.

2005 電腦音樂與音訊技術研討會

「2005 電腦音樂與音訊技術研討會」主辦報告

鄭士康

個人原先的研究偏重數值電磁計算，1995年開始加入音樂訊號處理的主題；1999年受國科會補助，至史丹福大學電腦音樂與聲學研究中心(Center for Computer Research in Music and Acoustics，CCRMA)進修半年，回國後成立電腦音樂研究小組(Jeng’s Computer Research Group，JCMG)，五年下來，已有六、七十位大學部專題研究生及碩士班學生進行電腦音樂方面的研究。在這同時也認識了幾位國內相關的教授，並成為好友，如師大音樂系的趙菁文教授、成大資工系的蘇文鈺教授、清大資科系的張智星教授等。

去年六月，張智星教授來擔任我碩士班學生的口試委員時，提到音樂和電腦科技的結合日漸受到重視，這方面的研究人口也日漸增加，但一直沒有一個可供藝術與科技創作人員互相觀摩對談的平台，有必要來舉辦一個結合音樂和音訊技術的研討會，並極力鼓勵我來主辦第一屆，他會盡力協助。我覺得張教授的分析很有道理，而且這也是很有意義的一件事，因此與蘇教授和趙教授聯繫，得到他們的認同，並允諾幫忙，於是就組成了四個人的籌備小組，開始籌辦，並商定與中華電腦音樂學會合辦，會議名稱為2005 電腦音樂與音訊技術研討會(2005 Workshop on Computer Music and Audio Technology)，簡稱WOCMAT 2005。

由去年八月開始，籌備小組大約一個月開會一次，蘇教授每次都從台南自費搭飛機來回台北，認真投入的精神令人欽佩。籌備小組首先決定日期為2005年3月12日舉行一天，接著就要籌措財源，除申請教育部經費補助外，並由張智星教授情商廠商義隆電子及凌陽科技贊助。此外，蒙電信所陳銘憲所長慨允由電信所、電信中心提供部份經費，網媒所吳家麟所長及國科會延續卓越計畫「多媒體生活環境的數位內容科學」同仁陳宏銘教授補助，不足之數再由報名費補足。在給教育部的補助申請書中，我們寫道：

人類物質生活日見進步，對於藝術精神層面的需求也快速增強。音樂及多媒體藝術之創作與消費不斷提高，使用電腦為輔助創作工具與欣賞媒介成為普遍趨勢，數位內容之研發創作也早成為我國未來”兩兆雙星”經濟發展的重點領域。在這種風潮之下，國內外電腦音樂的創作研究及音響技術的研發均日漸蓬勃。然而以往國內之音樂創作者多半缺乏科技背景，而音響技術研發人員之藝術修養一般較弱，而且兩方面的人員各行其是，缺乏對話討論機會，造成整合的困難。

有鑑於此一領域發展之瓶頸，我們幾位電腦音樂創作研究以及音訊技術研發的相關工作者，包括(以姓氏筆劃順序排列)台南藝術大學應用音樂系主任及中華電腦音樂學會理事長吳疊、清華大學資訊工程系教授張智星、台師大音樂系教授趙菁文、台大電信研究所教授鄭士康、成功大學資訊工程系教授蘇文鈺，決定發起舉辦台灣第一次的電腦音樂與音訊技術研討會，並且預期今後每年舉行一次。

大致說出了我們的發起動機與理想。

其次就要開始徵集論文稿件及音樂作品。這方面蘇文鈺教授發揮了他的寫作與組織長才，完成了論文稿件及廠商產品展示的徵集通知，另由趙菁文教授補齊了音樂作品的徵集規定。接著蘇教授指導他的「尖叫」實驗室(SCREAM Lab，http://scream.csie.ncku.edu.tw/scream/)接下了吃重的研討會網站架設任務，網站設立於 http://scream.csie.ncku.edu.tw/wocmat/，接受線上投稿與報名。隨後的籌備會議持續召開，各種會議構想與細節被提出與討論，會議輪廓逐漸浮現。此時電信所陳所長又答應讓電信中心認真負責的黃欣梅小姐負責總務，使我們更感振奮。趙教授更利用各種場合，宣揚WOCMAT會議，獲得許多台灣音樂界重量級人物的支持；她並規畫協調會議當天所有音樂活動，備極辛勞。

到今年1月15日音樂作品截稿，2月15日論文截稿後，我們經審查，排定了16篇論文口頭發表，7篇論文壁報發表，另演出音樂作品16首。全天的議程為

活動

註冊報到與開幕

地點：博理館一樓國際會議廳

時間
08:30－09:00

議程決定後即由我的學生林睿敏設計海報及編排秩序冊，其中音樂節目的說明與作曲者、表演者的介紹，當然還是得麻煩趙教授。接下來除將海報寄到各校外，並透過我們的人際網路，把訊息送出。這裏也要感謝工研院的創意中心薛文珍主任幫忙，協助將email轉發給許多先前曾參與創意中心有關電腦音樂活動的人員。

開始接授註冊報名後，一開始報名人數就不少，開幕當天更有許多人現場購買音樂會的票。最後有登記的參加人數達到118人，超過我們七、八十人的預期。參加者的背景除了音樂、電機、資訊之外，還有心理、工業設計以及其他專業但是對電腦音樂有興趣的人士。

到了開幕當天，博理館懸掛紅布條，雖然場外還下著大雨，但不減參加人員的熱情，熙來攘往，好不熱鬧(圖1)。

黃欣梅小姐坐鎮報到處，指揮台大、師大、清大、成大來協助的同學，依照她先前的細密規畫，處理各種雜務及突發狀況，充份顯示大將之風。開幕式在博理館國際會議廳舉行，並且播放可愛的開幕動畫(圖2，由趙教授委託台灣藝大的同學設計)，背景播放趙菁文教授的電腦音樂作品。動畫以黃昏時小女孩盪鞦韆，帶動活塞產生動力，入夜後使尖頂小樓房升空，原地出現閃爍的WOCMAT路標，正式宣告「台灣第一次，全國都在看」的2005 電腦音樂與音訊技術研討會開始，隨即開始論文發表。趙菁文教授同時在視聽教育館與協助音響及錄影錄音的公司忙著架設設備，並且主導音樂會表演人員進行彩排。

博理館國際會議廳的論文發表進行順利，台下坐滿工程背景及音樂背景的聽眾，與台上的論文發表人互動熱烈，每一篇論文發表都是欲罷不能。上午論文發表的主題包括歌曲與音樂哼唱檢索技術、以配樂辨識電影主要場景、MP3音樂摘要擷取技術、MPEG-7簽章(signature)維度降低技術、取樣率改變的有效率演算法、音樂記憶模型、以紙繪鍵盤演奏虛擬鋼琴、國語歌聲合成系統、結構式音訊(structured audio)處理系統等等。對許多音樂相關的工作者來說，這可能是他們第一次在台灣聆聽相關的工程論文發表。很多聽眾紛紛向我表示這是他們難得的經驗，而且獲益良多。我也因此認識了許多相關領域的學者，將來的交流互動可期。

博理館國際會議廳的論文發表進行順利，台下坐滿工程背景及音樂背景的聽眾，與台上的論文發表人互動熱烈，每一篇論文發表都是欲罷不能。上午論文發表的主題包括歌曲與音樂哼唱檢索技術、以配樂辨識電影主要場景、MP3音樂摘要擷取技術、MPEG-7簽章(signature)維度降低技術、取樣率改變的有效率演算法、音樂記憶模型、以紙繪鍵盤演奏虛擬鋼琴、國語歌聲合成系統、結構式音訊(structured audio)處理系統等等。對許多音樂相關的工作者來說，這可能是他們第一次在台灣聆聽相關的工程論文發表。很多聽眾紛紛向我表示這是他們難得的經驗，而且獲益良多。我也因此認識了許多相關領域的學者，將來的交流互動可期。

中午用餐時同時舉行壁報論文展示，展出的論文主題包含FM聲音合成器參數最佳化、利用耳蝸模型辨識音高、旋律辨識的加速與比較、鳥鳴聲的物理模式模擬、MP3樂曲的自動分段、語音加強技術等。特別值得一提的是由我指導的本系大四吳天麟同學(現為電機系碩士班計算機組學生)所張貼的音樂情緒辨識系統論文，引起許多人圍觀。尤其是來自實踐大學工業設計系與輔仁大學心理系所的師生頻頻發問，並表示這正是他們要開始做的研究主題，而我們已經先做了一些核心研究，頗有遇到知音之感。會後一週內，領導該團隊的盧慧楨教授與我們聯繫，並且請吳同學到輔大演講，與實大-輔大的團隊交換心得，我們學到從心理學角度來看，我們的研究還可以改進的地方，這正是WOCMAT會議促進科際整合與校際合作的一個成功實例。吳同學的研究另外也獲得中國工程師學會論文比賽第三名及今年國科會的大學生參加專題研究計畫研究創作獎。

下午的論文發表主題為電腦音樂，聽眾更為踴躍。論文作者涵蓋資訊與音樂領域，主題包括文字與音樂創作的轉譯與互動技術、音準點測音問題等。對許多音訊工程研究人員來說，可能也是第一次在台灣聽到看到音樂研究領域的論文，終於知道音樂研究者的想法與研究重點。

國立台北師範學院的碩士班學生林曉筠，由曾毓忠教授指導，發表關於電子電腦音樂在台灣的發展歷程研究，使大家知道原來在數十年前台灣就有許多前輩，如本系系友林二學長陸續投身於電腦音樂的研究，也讓大家曉得原來近年來台灣也有不少人在作相關研究，只是彼此不知道而已。

成功大學張瑋倫同學(由蘇文鈺教授指導)所發表的古琴減字譜數位化輸入軟體是國內第一個為古琴的記譜方式所開發的電腦軟體，在會中很受矚目。張同學並以此研究獲今年國科會的大學生參加專題研究計畫研究創作獎。

我所指導，去年畢業，現正服役的碩士班畢業生李務熙也發表了一篇指揮家系統論文，並當場利用指揮家系統以滑鼠指揮電腦演奏藍色多瑙河及拉戴斯基進行曲。由於李同學音樂及電腦兩方面均頗有造詣，表達能力又強，因此博得滿場鼓掌喝采。會後有許多音樂界人士紛紛與李同學接觸，希望索取程式或表達合作研究意願。李同學並指出，維也納音樂博物館日前也安裝了類似的系統，參觀者可面對維也納愛樂交響樂團的影像指揮樂曲。就網路搜尋所得，我們研究開始時，尚找不到相關的研究訊息，之後由報導看來，維也納音樂博物館系統的技術水準亦未必高於我們的指揮家系統，但其研究資源顯較我們為豐，因此有較大格局。李同學也提到，先前開發此一系統時純粹是為了興趣，覺得這在台灣應是相當冷僻的題目，沒想到在WOCMAT中遇到這麼多有興趣的同好，顯示我們的研究並不孤單，深受鼓舞。其他的論文發表者亦有多人向我表達類似看法，這也是WOCMAT的一大成果。李同學現在架設了一個指揮家系統的網站 (網址 http://www2.ee.ntu.edu.tw/~b87020/Conductor/Conductor.htm)，並與師大管弦樂團洽談合作可能。

由於午間音樂會和論文發表過於熱烈，無法於預定的時間結束，傍晚我們只能給參加人員很短的時間用晚餐，而且原先構想是只準備工作人員便當，讓其他參加人員到台大附近自行找喜歡的餐廳。很抱歉的是這時因為下大雨，可能使很多人急著參加晚間活動而錯過晚餐，這是我原先沒有考慮到的結果。好在晚上最後還有告別茶會招待，大概大家還不會太介意。

依照原先的議程，要先舉行音樂家與工程師的對話再舉行晚間音樂會。但是因為時間的關係，趙教授邀請來主持對話的台灣藝術大學音樂學院潘皇龍院長建議先舉行音樂會，再舉行對話，比較能讓大家暢所欲言，所以就先舉行音樂會。

下午與晚上的兩場電子音樂會總共演出專為此次研討會所徵求的電子音樂作品16首，被邀請及入選的作曲者來自台灣、大陸及歐、美各地，皆為當代著名之作曲家。而其中林二是台灣電子音樂的先驅，曾興魁、吳疊、趙菁文、曾毓忠、李文彬、Phil Winsor等人，皆為在各大學音樂系所任教，活躍於台灣音樂界作曲家。而林曉筠、林梅芳、石佩玉等人則是正在國內外深造的優秀學子。這些新一代的作曲家，除了具備優秀的作曲理念與技巧外，他們對於電腦技術的熟稔及應用創意，產生出許多優秀的當代電腦音樂，也促使電腦科技更貼近人文藝術領域。

此二場音樂會演出的方式除了主要的電子媒體之外，亦有七首作品結合了聲樂（殘局）、鋼琴（Interaction、幻想山水）、薩克斯風（瀟湘、殘局）、豎笛（蒼白之火II）等「正規」樂器編制，邀請許多傑出的演奏家共同演出。這種新舊融合的音樂風格，也一改「電子音樂」純技術的窠臼印象，呈現科技與藝術結合的多元風貌。音樂會演出同時，配合文字或圖像等視覺表現及說明，並有些許機遇音樂的互動風格，強調音樂演出配合其他藝術及科技領域的多元創意，令當天的與會者驚豔連連。

接著舉行的音樂家與工程師的對話是大家所期盼的重頭戲，由獲得國內外無數大獎的作曲大師潘皇龍院長主持，搭配吳疊主任、張教授、蘇教授在台上與台下的音樂及電機電子資訊工程研究人員互動(圖3)。潘院長幽默的話語很快帶動起氣氛，來自不同領域的聽眾提出種種問題與心得，你來我往，盛況空前，直到已經超過預定結束時間近一小時，視聽小劇場要趕人了，這才結束討論。接著大部份人又回到博理館會場，參加告別茶會，大家拿著餐點繼續交換意見。我也與潘院長交談良久：先了解了音樂家在音樂會前都不吃東西，怕影響演出，所以音樂會後都需要辦一個茶會，作為宵夜，也讓參加的人員交流意見；另外，潘院長也告訴我他教導學生注重啟發，引領學生自動學習，發展所長，而非強制要求學生走自己走過的路，這與我指導學生的理念完全相同。我們分別在音樂與電機資訊這兩個幾乎不相干的領域，而竟發展出相同的教育理念，確實是一件有趣的事。告別茶會參加的人員似乎也都捨不得離開，直到我以時間已近午夜，不得不下逐客令，與會人員才陸續依依告別，並相約明年再見。這裏也要感謝黃小姐和許多同學在來賓都離開後，仍然留下整理會場，至深夜才回去。

會後兩週，我收到一份3月18日出刊的政大新聞系實習報紙「大學報」，在第7版頭條登載了WOCMAT 2005的有關消息，大標題是「音樂交織音訊，突破傳統“音”素」，小標題是「結合影像創作電腦開發新樂聲，藝術融入科技，為音樂家未來作曲趨勢」，同時登載聽眾意見及記者採訪我和蘇教授及張教授的談話(如下圖連結)，顯見年輕大學生族群對此一會議也相當有興趣。

整體而言，雖然因為是第一次舉辦，還有一些地方需要改進，例如論文發表與音樂會排演同時進行，使音樂家錯過某些論文發表、時程安排過於緊湊、會前線上報名註冊時間僅有一週，似嫌太短、以及經費來源有待擴充等，2005 電腦音樂與音訊技術研討會仍可算是一個成功的嘗試，這要歸功趙菁文教授、蘇文鈺教授、張智星教授、與黃欣梅小姐的投入，與許多長官、前輩、好友、同學的協助，更重要的是所有音樂家、作者、聽眾的熱心投稿與參與。明年的WOCMAT 2006已確定由台灣師範大學數位媒體中心主辦，趙菁文教授仍要擔負音樂節目協調的重任，更由於台師大數媒中心的經費較為充裕，明年的盛會將邀請國際重要電腦音樂研究人員與會，使WOCMAT國際化；相信在台師大數媒中心李忠謀主任的卓越領導下，WOCMAT 2006會是一個更成功的會議，也希望WOCMAT今後能每年舉行，而且愈來愈成功*。

誌謝

感謝趙菁文教授撰寫本文描述音樂會的段落，張智星教授提供參加者所拍的圖3相片、蘇文鈺教授撰寫一段論文發表的描述，由本人修改。

*我們還保有一些WOCMAT 2005的論文集光碟及音樂會實況錄影光碟，有興趣的朋友可以附回郵10元寄台北市羅斯福路四段1號 台大電信所 BL501 黃欣梅小姐索取(郵遞區號10617)。

[Book] Multi-core Programming on the PlayStation3 Cell B.E. Platform

1 本書導覽

2 Cell BE 硬體架構
2.1 PowerPC Processor Unit
2.2 Synergistic Processor Unit
2.3 Element Inter-Connect Bus

3 Cell BE 工具列
3.1 安裝作業系統
3.2 軟體開發工具列
3.2.1 安裝步驟
3.2.2 工具介紹 3.2.2.1 Cell Simulator 3.2.2.2 Compiler 3.2.2.3 Eclipse IDE

4 Cell Programming基礎概念
4.1 簡易SPE程式
4.2 創建PPE行程與執行緒
*4.3 事件處理
*4.3 進階實務

5 直接記憶體存取
5.1 記憶體對應
5.2 指令使用 5.2.1 柵障(Barrier)和柵欄(Fence) 5.2.2 直接存取記憶體列表
5.3 多重緩衝
*5.4 Atomic Method

6 訊息傳遞與同步
6.1 郵件傳遞 6.1.1 PPE與SPE的郵件傳遞 6.1.2 使用DMA達到SPE之間的訊息傳遞
6.2 信號傳遞 6.2.1 PPE與SPE的信號傳遞 6.2.2 使用DMA達到SPE之間的信號傳遞
*6.3 使用訊息佇列傳遞資料


7 Vector Programming
7.1 在PPE上使用SIMD
7.2 在SPE上使用SIMD
7.3 PPE與SPE上使用SIMD的異同

8 錯誤解決

附錄
SPE Runtime Management Library
SPU C/C++ Language Extensions

第2,3章塞公負責，第2章deadline 3月底，第3章deadline 4月底~5月中。
第1,4,5,6我負責，第4,5章deadline 3月底，第6章4月底，第1,8章5月底。
第7章看情況要不要交給學妹寫，希望大家都能準時交差而且寫的要好，不要敷衍。
要寫就寫出來，不寫就都不要寫，不要還寫一半，就像上廁所只上一半。
雖然我的希望是可以不要上廁所就不要上..............
===========================================================

我在第四章的部份有說第三章會詳細講SDK包含哪些ex: compiler等，
所以還請塞公那部份要講清楚點。
*字號的部份是我還沒寫的部份，我想那幾個部份可以來討論要不要寫。
4.2節我目前還在寫，等寫完我的部份應該就差不多了。
第8章我希望大家可以合寫, 有遇過什麼問題都可以列出來
問題, 解決的方法等等
也請大家能不吝惜給我們建議


==========================================================
負責寫SDK3.0的人注意一下，
在最初的LibSPE的版本，如果我們開出超過6個SPE thread，
第七個thread會進入等待佇列，會等到六個SPE thtread都執行完後才會開始執行。

那在LibSPE 2.1的版本(也就是我們現在寫程式#include libspe2.h ，以前是#include libspe.h)
有做pre-emptive scheduler，所以現在有做"time-slice"的功能。
至於有沒有那麼神...就看user自己使用了，必須先計算讓SPE context swap-overhead。
swap對的SPE也是一個問題吧。
==========================================================
我整理一下今天我所提的部份，
如果我有闕漏也請各位告知，如果能請各位訂出自己的deadline是最好的。

第一章
等所有章節具雛型再動筆

在第二章到第三章的部份，
1. YDL安裝圖能修整或是重新抓圖。
2. SDK務必附上，告訴使用者有哪些Tool可以使用，必要時附上範例

第四章的部份
是我自己的部份，還少了一個範例。
另外，雖然我們沒有使用到Event Handling的部份，
但是其他書有提到，未來我希望自己能補上這部份。

第五章
修正老師所改的部份

第六章
使用訊息佇列傳遞資料，
此部份還沒有寫，可與老師再討論，如需要可從我的論文截取。

第七章
希望學妹能先出個第0.1版，多增加幾個範例
之後對SIMD越來越有感覺時可再做修改。

第八章
希望各位能提出2~3個會遇到的錯誤，解決的方式如何。
以QA的方式完成此章節。
越多越好。
還記得當初塞公寫的時候說有遇到很多錯誤和問題，現在可能都忘記了
還請各位回想一下，記一下問題。

附錄
請阿凡學弟回去想要如何完成

簽到。water

大家好，我是water。

之前在lab主要做的是H.264 encoder的hardware implementation。在做論文的當下覺得這真是一件艱鉅複雜又難以完成的工作，結果做完之後卻覺得怎麼自己做的這麼的虛弱與單薄。

畢業之後到現在的公司工作。這是一個懷抱有遠大夢想，卻以常人無法理解的方式在實現他的理想的奇怪公司。所幸後來得到目前的工作夥伴，所以還不至於令人待不下去就是了。

在這邊做的事情，先是承接Lab windows mobile版的SMP來作為公司專案開發的基礎。WM版開發至一個階段之後，接著做Symbian S60的版本。(雖然前陣子因為程式龐大維護不易，所以已經將SLIM拔除。不過當時的經驗還是讓我們在其他版本的開發上借鏡不少。)目前S60已經差不多stable，WM也快了。

目前的專長應該是在
Windows Mobile、Symbian S60的C/C++應用軟體開發。
(慘了，很弱的只能列這樣一條)
目前也在研究C#中(為了接WM UI的部份)。
不過如果要再回頭寫寫verilog，應該(希望)也不會需要太久的warm up啦。

這幾年比較有進步的大概是在閱讀、理解程式以及思路清晰的修改程式，這種實做技巧上面。此時就覺得當初verilog的訓練對自己的幫助真是不小。理論方面則是退步再退步，統統忘光啦。逃~

閒暇之餘偶爾也會加減隨便看一點JavaScript或者CSS，或者玩玩ipod touch改機作為娛樂。其實一直想來寫一點iPhone程式，不過一直沒有時間動手。做做這改改那的，大概就是對什麼感興趣就摸一點那樣。

之外就是很合氣道也很久沒練了，一直想要恢復，不過玩樂越來越多、加班越來越多，就越抽不出時間來。所以目前是靠偶爾為之的游泳來避免自己的身材走樣太多。然後今年也跟同事報名了泳渡日月潭喔，Lab要不要也來組一隊參加呀。 :p

最後就是，目前的工作也做了差不多將近三年。好像該再來找點其他有趣的事情做做了的感覺，目前仍在思考摸索中。

附上應該是萬年不變的聯絡方式 pointou＠gmail。com
歡迎來信。

Porting GNU GDB to a new target RISC32-ELF-GDB

Porting GNU GDB to a new target RISC32-ELF-GDB
之前寫了一半文件, 此文件完整度只有30%
不過至少還是有列出大概需要改什麼檔案與編譯時需要注意什麼
留給品皓日後研究與補充
1. 前言
2. 以下所列文件為移值GDB至少必須新增的檔案
3. 編譯GDB
4. 其他



另一份文件是如何使用Eclipse CDT加入自己的toolchain(使用Zylin Embedded CDT)
Using Eclipse CDT and risc32-elf-gdb with RISC32 simulator

發文注意事項

由於昨天我不小心post了篇只有link的文章，所以早上blog被鎖住了。
所以請大家留意一下，以後發文請要有"充實"的內容，不能只有link，不然會被當成spam blog.

ESL裡的SoC轉運站

一顆SoC裡可能會有一顆到多顆CPUs, 還有周邊, 記憶體,...,等什麼的. 靠什麼來把資料在這中間搬來搬去呢? 太特殊的東西不談, 大概就是屬Bus以及NoC (Network on Chip). OpenESL比不上CoWare的有幾點, 但是最主要的就是我們缺乏一些IP的ESL Models. 其中又以Bus與CPU為最重要.

CPU方面, Aaa的32-bit RISC拿來做研究可以, 但是想必沒人真正會拿來用在產品上, 所以品皓的8051與DSP16(實際上是AD2191的clone)會是我們的主角, 至於32-bit RISC就要靠電機系陳中和老師的研究了.

Bus方面, Gary按照TLM2.0做了一版堪用的Bus, 不過這不太切合實際, 同樣也是拿來做研究而已. 我們需要的是標準的Bus models. 所以ruru的重點是:

1. OCP

2. AMBA2 or even AMBA3

這是短時間我們要弄出來的. 再加上一些週邊介面所常用的Model如I2C, 以及利用PC的resources來做simulation的呈現也是方便在simulation時可以watch結果的好工具.

ruru的工作的定義很簡單, spec都在標準裡, 請加油!

Pitch/Partial Tracking的新方向

雖然文森學長的work做得很好, 但是我們的心中有一點點缺憾, 那就是學長的方法, 除了WGCDV是以前AL學長做的之外, 多半還是來自其他世界上其他的研究者的想法, 縱使為bff學長所開發的High Order HMM. 而過去我也曾經講過, 利用HMM來做tracking似乎不做第二人想, 但是我們除了HMM之外, 能有其他的創見嗎?

文森的Pitch/Partial Tracking

這一點, 我跟DNA學長聊過, 在過去, 我們利用Partial Group似乎得到一些效果, 不過一切的方法似乎比較像是在做影像處理或圖形識別的研究, 也就是試著找所謂的Feature(特徵), 然後用HMM的方式把他們在時間軸上連起來. 但是老實說, 我對影像類的特徵找法不是太有好感, Heuristic或Empirical是我一直用來形容這類方法的名詞, 我對Neural Network的感覺也是如此.

這讓我希望回到用Data Decomposition的比較正統的數學方法來定義Features, 可是怎麼做呢? 我沒十足把握, 所以這一篇不好寫.

一般的數學做法是找eigenvectors, 利用eigenvectors來當tracking(可以是HMM也可以不是)用的Features似乎可行, 不過在我們要對付的問題上, 一般的decomposition的方法卻可能會有問題, 要是可以, 那麼PCA(Principle Component Analysis)或ICA(Independent Component Analysis)的方法就可能派得上用場. 不過, 因為八度音, 甚至五度關係都會讓這類方法破功, 其原因我就不在這裡細講. 因此在這裡我們要定義的Feature Vectors一定有別於一般Linear Algebra中的eigenvectors, 而如何找到演算法來算這Feature Vectors以及如何避開八度與五度的問題是關鍵所在.

所以胤要對付的問題的真正解法在哪裡需要我們一起努力尋找, 而這一類問題要做得好, 數學要有一點底子, 別忘了, Higher Order HMM Tracking是數學系出身的bff學長想出來的. 這讓IRCAM與SCREAM首次在MIREX裡勝出.

MIREX2008 Multiple F0s estimation

我想, DNA與我會多花一點心思在這個問題上面, 請胤想法子趕快學好Matlab, 因為我不希望花太多時間自己寫matlab裡已經有的東西.