2009年6月26日 星期五

SCREAM Lab ESL tools to be Open Sources

2009/6/26

Since SCREAM OpenESL will be announced this month, I decide to have a new blog for the open sources developed at SCREAM Lab. For such information, please go to :

http://screamlabopensource.blogspot.com/

I would expect that new SLIM will be released soon.

--------------------------------------------------------

For some reasons, I decide that we will make our ESL tools open. They include our past efforts on Eclipse based SystemC IDE with GUI, Matlab/Simulink Co-simulation, FPGA Co-simulation, and all other heterogeneous mixed-level tools.

Before the 0.1 version is announced, there are some features to be added.

1. TLM 2.0 compatible interfaces.

This includes Buses and interfaces to heterogeneous tools. This will be taken care of by Buffett, ruru, and Garystone.



2. Matlab/Simulink and FPGA related examples and codegen and change of communication models from socket to shared memory.

This will be taken care of by Buffett and DNA.

3. Profiling tools and its visualization

This will be taken care of by ruru and Garystone.

4. Integration of GtkWave and Icarus (or Modelsim)

This will be taken care of by long, Buffett and Garystone.

5. User menu, technical menu, powerpoint and book.

This will be taken care of by Garystone, ruru, long and Alvin.

Let me know if I miss anything and there is something wrong.

Let me toss some options that should be done after the first version is released

1. Debugger under Eclipse

2. 8051 and DSP16 utilities

Last night, I felt so relieved and free that I made everything clear. There is no need to make 700K NTD while losing our freedom to make the best ESL tools in the world. AND, it is open and free.

2009年6月22日 星期一

Welcome new SCREAM members, 2009

Training Course 7/2009

由於有同學在7/13有事, 所以Training courses就星期二7/14開始到周末的7/18.

講師的練習7/6開始, 請在7/6前上來post你的power point.

------------------------------------------------------

6/19  9:10AM進行Training course以及SCREAM Lab的計劃說明與討論. 課程的投影片在2009訊號與系統那串.

另外請以下四位學長參與討論.

garystone

87showmin

smallnew

D.N.A.

塞公

如有同學不會Matlab的, 我再請學長來講解.

----------------------------------------------------------

6/3 周五上課取消

看來這周五無法上課, 那麼6/19可以嗎?

請New Members上來回個話或寄email給我.

另外, 我們在七月上旬會辦實驗室的Programming Training courses, 這次就由碩一的Gray, 塞公與阿凡以及碩零的vivian, ruru, 小龍擔任講師. 內容包含Gary 負責C++/threads/processes的複習, ruru 與小龍負責的SystemC/OpenESL, 阿凡負責的Eclipse 開發環境, 塞公負責的SLIM/OpenMax, 與vivian負責的cuda.

請講師在7/6前將投影片, Lab以及Homework放到blog上來, 請各自開各自的串, 串中請簡述你的內容. SystemC的投影片可以沿用舊的但要加上TLM2.0的部分, 請跟DNA與Gary拿舊的資料. 我先規劃一下課程如下:

Day 1 AM: C++/threads/processes

Day 1 PM: SystemC

Day 2 AM: OpenESL

Day 2 PM: SystemC/OpenESL Lab

Day 3 AM: SLIM/OpenMax

Day 3 PM: SLIM Lab

Day 4 AM: Eclipse

Day 4 PM: Eclipse Lab

Day 5 AM: cuda

Day 5 PM: cuda Lab

其中, SystemC/OpenESL , SLIM/OpenMax 與cuda要設計Homework來當大家的暑假工作. 至於要出什麼樣的作業請講師找時間來跟我討論.



---------------------------------------------------------

5/30 道歉啟事

看到Aaa的留言, 我才知道我之前說的要在5/28開始介紹其他東西. 請原諒我年老昏庸, 記性不佳. 只想到說端午節要帶孩子回家去看父母親, 忘了這件事. 真是抱歉! 請那天有來了學校要上課的同學跟我說一下, 我請客道歉.

至於下一次上課, 因為假如可以, 就下星期五(9AM, 6/5). 我預計把Signals and Systems講完, 順便給大家問一下問題, 然後講一下請學長講一下Video Coding, 如有時間就加Matlab一下. Audio Coding就之後在找時間.

最後, 真的很抱歉. 我以後會注意, 也請同學提醒我.

假如有人不能來上的, 請留言一下, 我會再找時間.



---------------------------------------------------------

5/20

5/22上午九點開始上課

地點: 資訊系館4201

---------------------------------------------------------

5/6

那麼我們就定在5/22上午九點開始, 講到我累到不行為止. 我會講得快一點, 因為時間大概不會太多, 聽過我一次訊號與系統的人會比較easy. 沒聽過的請隨時問問題. 我基本上就是先上到訊號與系統的一到五章. 請先到訊號與系統那串下宰我的手寫投影片.

假如我可以講完訊號與系統, 那麼5/28上午九點開始, 我會請lab的學長姐介紹一下目前跟訊號有關的projects. 另外簡單地上一下Matlab.

至於實驗室的programming training courses就定在七月上旬來進行.

---------------------------------------------------------



5/3

這次的meeting, ruru因為時間的限制, 報告比較不完整, 小龍大概覺得是有點像以前的專題的每次進度review, 所以有一點簡略, 其他的都不錯. 因為小龍已經完成了GtkWave與OpenESL的整合, 我們下星期來review一下. 以下是請各位同學接下來可以做的.

ruru: 繼續先前的工作. 但是請開始找OCP的code來trace. 另外也可以參考CoWare的AMBA2的code, 但是希望看完後, 假如要改, 可以更符AMBA2的規格, 以及採用標準的TLM2.0, 此一部分, 我們會跟電機系合作.

小龍: 可以請你去看一下HDL simulator嗎? 例如Icarus或ModelSim. 接下來, 我們希望ESL可以跟HDL Simulator一起運作. SLIM的介面的工作請先擺一邊.

孇孇: 接下來請你實做IDCT, 我想知道用了SIMD後, bbb的系統可以快多少. 此外, 我該給你上一下video coding的一些東西. 我們blog上有一些smallnew寫的東西, 也許你可以先看.

vivian: 你這次的demo讓我很有信心, 我想我要找時間跟你談一下我們實驗室在用的additive synthesis如何架在cuda上了. 基本上他就是一堆sin加起來而以. 我會請showmin在下星期一起來討論. 此外, 我們計畫讓SLIM可以呼叫cuda做的process, 所以會以後請你來參加SLIM/OpenMax/Cuda工具的開發, 目前這部分是塞公在做.

最後感謝大家的努力, 下一次的meeting時間就定在五月底, 希望可以有新的成果可以給大家看. 另外我計劃五月份給大家溫習一下訊號與系統, 我一向在星期三與五比較有時間, 請各位把你可以的時間post上來一下. 碩一的同學也可以一起來再聽一次.

----------------------------------------------------------



4/13/2009

孇孇希望有多一點時間準備, 以便可以demo一下他實做的程式, 所以我們就暫定4/28上午. Lab的報告就由9AM開始, New members的報告及Demo就10AM開始. 請大家準時, 並不吝提出問題, 假如時間不夠, 我們叫便當進來吃.

---------------------------------------------------

4/9/2009

因為小龍, Vivian, 孇孇都已經研究了一段時間, 我寄話在4月中到四月底之間找一段時間, 約半天的時間, 請我們的new members來替大家上一下課, 順便做一下demo.

期間ruru因為ocp會員的一些問題, 卡了一段時間, 所以我請他改看CoWare裡的AMBA2的實做. 我會請ruru加一篇文章來講這個topic. 希望ruru也可以在四月底前的這個Seminar來講一下.

這個Seminar不是要各位new members要講出什麼了不得的東西, 只是驗收一下自己獨立研究的成果以及讓學長姐們可以對大家做的東西提出一些看法與改進的方案, 請大家好好準備, 但是不要覺得好像壓力很大的樣子.

比較恰當的時間是利用Lab星期二上午的meeting時間, 但是考慮到孇孇的遠道的不方便, 我想以孇孇的時間為準, 請孇孇提出幾個方便的時間, 周末也OK.

--------------------------------------------------

實驗室預計增加以下幾位生力軍:

rurume

小龍

Vivian

孇孇

passtaiker

另外還有一位還沒跟我聯絡, 所以我先空著, 要是真的來了我再加上來.



經過一個星期的Training courses, 我想幾位應該跟目前實驗室的學長都有認識, 所以我在training courses的最後一天請幾位吃午餐, 順便交代一下要給各位的工作. 我在下面簡述一下, 以免我自己都忘了.

rurume: 研究OCP與 TLM, 並且實做出一符合OCP的Bus與NOC所需的interface, router與switch. 你的Mentor是Gary.另外, 我計劃請你, 小龍與Gary合作來寫一份投影片, 內容有關簡單的C++教學, SystemC入門, TLM, 以及OpenESL的用法, 預計以後當大學部上課教材用.

小龍: 研究GtkWave的Linux與Windows版, 以便加到OpenESL裡面, 並且研究GEF的使用與開發方法. 你的Mentor是阿凡. 此外, 我想請你多了解eclipse開發環境, 所以也要請你將SLIM搬上eclipse. 這方面請Gary當super mentor.

Vivian: 研究cuda, 目前這是實驗室要看的新東西, 大家都不太熟, 所以你要靠自己, 希望過一個月後你可以幫大家上第一次課. 因為我請塞公在研究OpenMax, 尤其是在cuda上的OpenMax, 所以我請塞公當妳的Mentor, 又因為Aaa目前也在看cuda, 所以我也請忠和來當super mentor. 不過你還是要多靠自己. 我希望未來SLIM可以連上OpenMax與cuda, 所以在一段時間後, 我想請你跟小龍合作一下SLIM的開發環境.

孇孇: 研究cell programming. 這是目前實驗室在多核心處理器開發程式上的另一個重點. 目前最大的應用程式是MPEG-4 decoder, 請你花時間了解如何用cell來開發程式, 另外的重點是學習與利用SIMD指令來加速她. 你的Mentor是逼逼逼. 等實驗室的Data Flow Programming tools成熟時, 我們會進行開發環境的實做, 請你要多問問題, 不要擔心會麻煩道逼逼逼.

passtaiker: 研究Verilog語法. 我的計劃是先讓你做一顆CPU, 因為能寫一顆CPU, 而且此CPU能有一定程度的Performance的話, 那麼你的Verilog的功力就不錯了. 我會請你先看8051的Verilog code, 然後請你來報告此一code的結構與語法分析, 然後會請你自己implement忠和學長定義的32-bit RISC (Simulator已經做好了). 你的Mentor是Daphne, 我會請她send email給你, 也會請她叫你FPGA的使用. 另外請你在這學期複習一下Compiler與找一些Verilog Simulator的論文與實作來看, 這方面的Mentor是Aaa. 我也會請Aaa跟你聯絡.

如我所說, 各位並不需要去鑽研所有training courses裡所有的東西, 取你所需即可, 有問題就跟我與你的Mentor說.

最後, 請各位在三月中以前上來開一串屬於你現在工作的文章, 內容再怎麼簡單都無所謂. 然後每周至少上來更新一次資料. 更新的目的在讓Mentor與我了解你的進度與問題, 同時也讓你更了解你自己, 假如你有用心在研究, 一陣子過後你一定會看到自己的進步.

我們預計在春假前後請各位到台南來做第一次報告. 順便請各位與你們的Mentor喝coffee.

----------------------------------------------------------

請注意! 請諸位New members在三月中上來開有關你的工作的串. 請諸位Mentors盡一下Senior的督促之責.

2009年6月19日 星期五

Harmonic Transform

這是一個由F.Zhang, G. Bi與Y.Q. Chen於2001在ICASSP上所提出的一種轉換,它是延伸自Fourier Transform而來,它在FT的公式中加入unit phase function,而這個function即為fo的phase function除上fo的結果。當 unit phase function = t 時,HT就會退化成FT。

在2007年另一篇EUSIPCO論文中,他提出了一種訊號的特例:chirp signal。一般DFT在分析chirp signal時結果會如圖:

image

因此,在論文中便針對這一類的訊號特性去說明如何設計unit phase function,以至於HT的結果會如下圖:

image

FT 雖能幫助我們分析訊號在頻域上的現象,不過對於一些樂器常見的特性諸如gliding , vibrato,分析時常有解析度難以訣擇的問題。HT 開啟了一道門,讓我思考是否針對unit phase function的設計可以更精確的做好某些特殊演奏手法的f0 detection or partials tracking。

投影片: 點我下載

reference:

F Zhang, G Bi, YQ Chen, Y Zeng, Harmonic Transform, ICASSP IEEE INT CONF ACOUST SPEECH SIGNAL PROCESS PROC, 2001

P Zubrycki, A Petrovsky, ACCURATE SPEECH DECOMPOSITION INTO PERIODIC AND APERIODIC COMPONENTS BASED ON DISCRETE HARMONIC TRANSFORM

2009年6月18日 星期四

二胡音樂的分析合成以及夢想的延伸

幾年前, 我的學生AL的碩士論文做的是二胡音樂的分析與轉換合成, 其工作是將一般的二胡路因經過分析, 取出其瞬時的音高與音量的資訊, 再用合成的方式照原樣合成出來. 合成的時候, 可以選用其他樂器的音色, 也就像是同一個人換了一把樂器一般, 當然, 也可以將錄音中的樂器的音色做成音色庫, 而用元音色再合成, 不過會跟原錄音有一點差異. 我做了簡單的投影片如下:

二胡分析與合成

請下載再解壓縮即可.

AL是拉胡琴的, 所以可以知道這樂器眾要的地方在哪裡, 加上他的程式功力一流, 對我的啟發是很大的, 所以一值以來, 我們希望將此一技術再進一步發揚光大, 希望可以Apply在其他樂器上面.

以下是他在Youtube上的一些影片介紹.

AL除了論文本體之外, 也開發了一些人機介面, 提供使用者"玩"音樂, 師大的趙菁文老師也用過這的工具做了一首曲子, 據說非常受到歡迎, 這是我們做工程研究的人的莫大榮幸, 也就是可以受到音樂家的喜愛.

目前我們較不滿意的是合成的音色還不盡理想, 而主要是頭音部分, 目前我的另一位學生showmin還在努力當中.

未來, 我們還希望擴充道可以處理整個管弦樂團, 也就是用虛擬合成的方式來合成整首交響樂, 其中每一把樂器都付與其一個個別的合成器, 讓每一把樂器都有其特別的音色與表情變化, 而且可以讓使用者即席指揮, 不過這牽涉到龐大的計算量的問題, 所幸除了現在的cuda外, 成大電機系與資工系正在合作開發多核心(Multi-core)的CPU與GPU, 希望在不久的將來, 我們可以從演算法到計算用的引擎都用自己開發的東西來完成.

相關的研究或資訊可以在以下看到:

Pitch/Partial Tracking

Musical Information Retrieval

cuda

Multi-core

 

2009 訊號與系統

這是Signals and Systems 課程第一章的投影片, 字跡潦草, 請大家見諒. 我找到時間後會把它整理整齊.

投影片PDF在此.

投影片PPT在此.

因為第一章已經上完了, 請助教可以開始整理一下此一power point檔案了. 整理完請傳給我一下

第二章講的是連續性訊號的一些基本操作. 基本上請大家把訊號看成函數就好. 請多注意他在時間軸上的轉換, 這不是用來刁難大家的, 以後許多定理以及應用會需要他們的. 還有就是注意一下系統的定義以及基本的系統怎麼由其block diagram算出他的transfer function或system equations.

最後提醒大家多去了解與注意impulse function. 這個defined by property的函數對未來是很重要的.

第二章的PPT在此.

第三章的用意在於了解各式的系統表示方法以及利用Transfer function來簡化對Complex Exponential Input的解法. 請多注意不同表示法之間的異同.

第三章的PPT在此.

第四章從Fourier Series著手, 以便將來進入Fourier Transform. 請多注意Linear Algebra的一些基本概念, 如內積, Basis, Orthogonal,...., 等觀念.

第四章的PPT在此.

第五章進入Fourier Transform, 其實跟Fourier Series沒差太多, 但是把Periodic的限制拿掉了. 這樣對訊號分析來說理論上更完整了.

第五章的PPT在此.

2009年6月16日 星期二

Cell Programming 工作報告 - 逼逼逼



我發的前幾篇標題都不好,所以另開一篇標題。


11/24 報的paper:Optimizing Assignment of Threads to SPEs on the Cell BE Processor





請點此



另外進度報告
我們切的方式是要在QP=25,INTRA_PERIOD=30才能得到最好比較好的Performance

----------------------------------我是分隔線--------------------------------
12/01

請點此


測了幾個Block的時間~
最先一開始是讓SPE去讀檔案,然後扣掉檔案的讀取時間。
所測得的時間非常不穩定,時間上下抖動的範圍太大。
之後就想到,疑?是不是讓PPE去讀進來放到External Memory,
然後再去從External Memory去抓這些資料就好。

試了之後效果還不錯,
不過這又產生一個大問題了。
當PPE去讀取很大筆的資料放到Memory,例如要花了兩百多MB。
當我去測它的執行時間時,它的執行時間範圍就有時2秒、有時51秒。
差距非常大。我想了一想,也許是用到虛擬記憶體導致變慢。
所以我將要讀進來的檔案切成五等份, 每一等份是23681筆資料。
每一次我就只做一等份,之後再將這所有的五等份時間相加,得到每一個component時間。
之後所測得的時間就蠻穩定的。

註:老師說時間很奇怪,建議只接收一筆資料,同一筆資料做很多次。
再測其時間看看有沒有變。

----------------------------------我是分隔線--------------------------------
趕緊來記一下跟老師討論的文件大綱

第一章 Overview(大綱,提到Toshiba)
第二章 Cell BE硬體架構
第三章 編譯環境
3.1 PS3上的作業系統 - Yellow Dog Linux
3.1.0 安裝作業系統
3.1.1 介紹Toolchain
3.1.2 如何編譯
3.1.3 其他Compiler (XLC compiler)
3.2 Cell Simulator
3.2.0 安裝Simulator
3.2.1 介紹Simulator的各種mode
3.2.2 如何編譯
3.2.3 各種mode跑幾個範例
第四章 Library的使用:寫程式介紹很多API
第五章 自製Toolchain

---------------------------我是20081208分隔線-----------------------------
投影片內容說明了我們怎麼測SPE的時間
另外還有Queue的實作方式,未來會越改越好地。(希望)

註:拿GNU Pofiler測試一下時間,確定各個block時間的合理性

Future work就是把Queue通通的改成漂亮的Queue,
然後做小實驗。

我是投影片

---------------------------我是20081222分隔線-----------------------------

今天報了有關Cell B.E. blocking, non-blocking channel的介紹
Intro: 每一個SPE上MAILBOX或Signal或其實都是一個個的channel。
透過MMIO(Memory Mapped I.O.)去抓取任何一個channel都將是non-blocking。
SPU讀寫channel的話,要根據channel的type決定是blocking或non-blocking。

我是投影片

進度報告:
實作了將DMA做成多筆一次傳,跑出的數據是多少。
實作了另一種版本的Queue,此版本Queue只有一次DMA,測出數據是沒有達到預期效果。
未來要再解一些bug。

刪了某些圖的投影片

---------------------------我是20081229分隔線-----------------------------

1.
今天報告另外一種切割的方法,簡單的說就是做os的task分配的意思,讓每一個block都能
夠滿滿的、負擔都差不多,不要一直只等著事情做。

2.
報告程式流程

Future work:
解決在一開始的初始化時資料被蓋掉的情況


註:下星期與忠和學長討論有關SystemC的部份

投影片

---------------------------我是20090105分隔線-----------------------------
一. paper的outline
data-flow for mpeg4 decoder on cell
1. Introduction
i) multicore programming
ii) data-flow, Pipelined
iii) MPEG4 on cell
iv) cell architecture, programming thread communication
v) Related Work Difference (only MB-level parallelism)
vi) Contribution
2. Design Methodology
i) mpeg-4 component graph
ii) profiling computation communication
iii) Task Allocation
3. Queue Implementation
i) Mailbox/Signal/DMA Synchronization
ii) Batch Transfer
4. Experiment Results
第一個是不同傳輸方式
第二個是不同切法
第三個是不同node數
5. Conclusion

二. 書的outline
當然是還沒有...
目前我有稍微看過阿六仔寫的書,我還沒有看的很仔細。因為看簡體字也需要想一下。
個人觀感是書的前半部份感覺像是英翻中的手冊,例如講一下SPE的架構,然後列出有哪些指令可以用,感覺比較稍微草率一點,後半部份的某些章節我覺得還不錯,例如它有一章列出你可能會遇到哪三樣錯誤,然後這錯誤大概是因為什麼。
我覺得這章節很不錯,如果使用者遇到的錯誤都能在這本書找到所以然,這本書的價值也許會比較高。





---------------------------我是20090108分隔線-----------------------------


Toshiba SpursEngine
Toshiba所出的這塊媒體串流器(SpursEngine)與Cell B.E.的不同點有






1. Cell B.E有8顆SPE,SpursEngine只有4顆


2. 為了Low Power的設計,將減少的4顆SPE換成MPEG-2與MPEG-4/H.264 Encoder/Decoder


3. 不採PPE為主CPU,可用PC上的Intel Processor


4. IO變更





以上4點摘自 東芝半導體公司披露繼承Cell設計構思的處理器真面目





reference:


[1] Full HD趨勢化的波濤,掌握加工編輯關鍵的影像處理引擎


提到了各種影像處理的加速卡優缺




---------------------------我是20090217分隔線-----------------------------


1. 本書導覽

2. Cell BE 硬體架構
2.1 PowerPC Processor Unit
2.2 Synergistic Processor Unit
2.3 Element InterConnect Bus

3. Cell BE 工具列
3.1 安裝Yellow Log Linux
3.2 安裝軟體開發工具列SDK3.0
3.2.1 Cell Simulator
3.2.2 compiler
3.2.3 Eclipse IDE

4. Cell Programming基本概念
4.1 Process and Thread
4.2 Create SPE Thread
4.3 Create PPE Process
4.4 編譯程式

5. Direct Memory Access
5.1 MMIO concept
5.2 DMA concept
5.2.1 mfc_put, mfc_get
5.2.2 barrier和fenced
5.2.3 alignment
5.3 DMA List
5.4 Double buffer
5.5 Atomic Method

6. 訊息傳遞與同步
6.1 Mailbox
6.1.1 介紹SPE的Mailbox種類
6.1.2 PPE與SPE之間的通信
6.2 Signal
6.2.1 介紹SPE的Signal種類
6.2.2 PPE與SPE之間的通信
6.2.3 OR-mode與Overwrite Mode
6.3 使用DMA達到SPE之間訊息傳遞
6.4 使用Queue達成資料資料傳遞

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

8. 錯誤解決

---------------------------我是20090224分隔線-----------------------------
今日報告,
完成Queue Type II的Doble Buffer,
我們交互使用兩個不同的參數與標籤(TAG),以節省Communication time。

未來要做的事
1. channel(queue) code generator
2. scheduler code generator

欲先完成第一件事,在經過簡單的程序建立如下的Graph後,
能夠幫我在每個core build channel,並在consumer core初始化queue。















scheduler code generator要等到我把這個先弄完才會繼續,

目前怕參數太多,產生出來的code很複雜。



老師的comment:

1. 未來Cell Programming搭配OpenESL GUI,拉幾下就就可以build connection (這點應該沒問題)

自動產生scheduler,需要user告知scheduler額外資訊。



今天我誤會老師問我的問題?老師問說scheduler寫在哪裡?

scheduler的code當然是另外寫的一支程式,產生的code是跑在componenet裡。

我以為老師是問產生的code跑在哪。



我們目前是想說scheduler會產生一張圖,什麼時候哪個core該做什麼事,都在這張圖上。











目前大概就是這樣,萬事都想好,只欠一步一步完成。



---------------------------我是20090303分隔線-----------------------------

















欲用一個Graph來代表Core與Core之間的溝通機制,
所以我們建一個Graph,經由加Vertex與Directional Edge(有向邊),
語法
1. Add Vertex ex: myGraph.AddEdge(VLD);
2. Add Edge ex: myGraph.AddEdge("VLD","IMC1","IQ_para","IQ_ARRAY");
Vertext 代表module name,Edge代表channel,如同我們在SystemC語法宣告一個channel,
必須給它一個channel type和channel name,後面這兩個變數就是這個Edge的Feature(屬性)。

依據這個圖我們可以分析每個Vertex,它是當了幾個Core的Producer,自己是誰的Producer。
根據這樣的資訊建立channel initialize Code。
下一步就是scheduler code generator,而scheduler code還在改,希望能簡單到可以自動產生,不然原本的code太複雜了。

-----------------------我是20090317分隔線-----------------------------

User一開始會給我們以下幾個資訊

0. DataFlow的流程圖


1. Core的數目,Ex: 現在要跑在6個core上面

2. 每一個Task的loading Ex: VLD必須花500 ms,IMC花2000ms等等的資訊



我們根據以上的資訊,找出最好的Duplication

演算法我們這邊就不提,以後補上。

根據演算法我們會產生每一個Core的Scheduler Graph,如下圖11個duplication分給6core




















根據這張scheduler graph,我們能夠建一張Table描述core與core之間的communication關係之後根據這張Table我們就能跟建立之前我們所說的communication graph,之後就能使用communication(channel) code Generator。目前只做channel code Generator,接著再將code改一改就能完成codeGen了。
老師今天的comment:
1. Eclipse GUI與阿凡討論,列出規格與規劃進度,之後meting拿出來討論進度
2. 4月之後希望能開始改SIMD,然後將改完的SIMD的時間再來重新build graph,讓大家知道不一樣的load會產生不同的scheuler graph
3. 希望未來能再porting一個codec上去,希望這個scheduler code generator是夠general的




















































































































































































































































































































































































































Core 0 VLD0VLD1VLD2VLD3VLD4IQ3VLD5IQ4VLD6IQ5VLD7IQ6IDCT2VLD8VLD9IQ8VLD10IQ9IQ10
Core 0 0~419419~838838~12571257~16761676~20952095~27052705~31243124~37343734~41534153~47634763~51825182~57925792~80658065~84848484~89038903~95139513~99329932~1054210542~11152
Core 1 IDCT3IMC0IDCT5IMC1IMC2IMC3IMC4IDCT8IMC5IMC6IMC7IMC8IMC9IMC10
Core 1 2705~49784978~54845484~77577757~82638263~87698769~92759275~97819781~1205412054~1256012560~1306613066~1357213572~1407814078~1458414584~15090
Core 2 PB0PB1PB2PB3PB4PB5PB6IQ7PB7IDCT7PB8PB9PB10IDCT10
Core 2 419~11621162~19051905~26482648~33913391~41344134~48774877~56205620~62306230~69736973~92469246~99899989~1073210732~1147511475~13748
Core 3 IQ0IQ1IDCT0IQ2IDCT1IDCT4IDCT6IDCT9
Core 3 419~10291029~16391639~39123912~45224522~67956795~90689068~1134111341~13614








---------------------------我是20090401分隔線----------------------------




今天報的是有關IBM所開發的Accelerated FrameWork(ALF)




附上投影片




---------------------------我是20090408分隔線----------------------------




今天提出兩個問題,其中之一已能妥善解決,以下描述我遇到的問題。




1. 初始化中,Race Condition的問題。解決方式:使用PPE做主端控制,將控制權依順序交給各個SPE做初始化。同時間只有一個SPE能做寫入的動作。這樣雖然初始化會慢了一點點,但是卻能不用變更到現層的架構所提出的方法。




2. 遇到架構上的缺限,scheduler所產生的排程,應用在core與core之間的channel對應會有問題存在。




目前先寫論文,目前要兩步驟方式,




第一 產生scheduler圖




第二 檢查schduler圖可否產生code,可以的話gen code。




---------------------------我是20090414分隔線----------------------------




解決conflict的問題。Future work: 當candidate list為空的時候,找尋workload此少的core去assign。




數據看起來不make sense,目前要固定某種變量,看數據跑出來的狀況。




1. 為什麼相同Duplication, 比較多Core卻較差




2. 為什麼相同Core, 比較多Duplicatoin卻較差。




是不是因為Queue SIZE未達到最佳的臨界點。




我目前打算產生兩樣數據




1. 固定每一個core的Queue Size,測出數據圖。




2. 紀錄每張圖的最佳Queue size是多大。




---------------------------我是20090429分隔線----------------------------




老師的comment




1. 更改演算法,讓4core在1個duplication下的時間能比3core在1個duplication的時間少




2. 產生出來的數據有多點疑問,必須一一釐清




2.1 Estimate的時間怎麼會比Real跑出來的還慢?必需再去確認這方面的code有沒有錯,還有就是Estimate的時間要再精確點,例如使用SystemC去model整個執行環境。




3. codeGen有一些bug存在,必須把它解掉




4. mplayer那部份的code要重寫,整合Eclipse IDE部份




5.列出論文大綱




第3,4,5點的部份我會先把它做掉,之後再從第1、2點開始解。







---------------------------我是20090512分隔線----------------------------










根據這張圖,老師的疑問說,為什麼4core在1個duplication會比3core的執行時間長。




我們更改程式分配行為,每一顆core上有兩種時間,一種是current time,另一種是workload time。workload time本來是紀錄是此核心上的所有的Task的時間總和。我們現在加上idle time。current time是目前該核心的時間。我們是根據最小的workload來分配Task。



此圖是更改後。


老師的comment,解釋3,4core在1個duplication的時間為什麼會一樣,5,6core為什麼在1個duplication的時間會一樣,而且會比3,4core好。


解釋1. 4 core的執行時間會一樣,是因為task的之間有dependency的關係。如IDCT0要等到IQ0做完才可做,所以雖然多了一顆核心,但是最長的執行時間仍然坐落在做IDCT0與IMC0的核心上。


解釋2. 5,6 core的執行時間會一樣,是因為在1個duplication的狀況下,Task有5個,所以剛好可以分配給五個core。但是多了一顆core其實是沒有做事的。


小新的問題:為什麼4,5core同樣的Estart Time,5core卻會比較好?


解釋 5core在1個duplication的狀況下會比4core好,是因為剛好每一個task都分配給一個核心做。而沒有dependency的Task,可以自由的先執行,例如VLD1不用等IMC0執行完才做,所以這樣的時間就會重疊起來。所以執行時間是該核心最後一個task的結束時間減去第一個Task開始的時間。


小新的問題: duplication的名詞有點怪,以為是要等到1個Macroblck都做完才能輪到下個Macroblock做。


阿拉給我的旨意: 想辦法取每一個Module的最佳的程式時間,但分配用的是平均時間。




-------------------------------------------------------------------------------------------

將程式部份的名稱改的好看

函式名稱有個DB代表使用Double Buffer機制

DB_funName(para1,para2,para3)

para1用來表示channel是跟誰建立的,如圖中的C_SPE0

表示我是當Consumer,SPE0是Producer。我要接收從SPE0傳遞過來的資料。

ToSPE3(para1,para2,para3);

To後方接的名稱代表我要將計算完的資料重送到哪一個core,例如SPE3。

如果是要傳送給做IMC的core,因為我們使用角色互換的trick。

所以它不是固定給哪個core做,這裡我們使用ToIMC傳遞參數

這個函式會幫我們判斷OutputSel是0或1的時候要送給哪一個Core。

我們的CodeGenerator要寫的適合各種case的話

必須讓User設定很多參數,例如要讓這些code執行多少次,要使用的Function是input、output是什麼。

所以我們原先的使用方式是我們先將程式改成可以Codegen的格式,再來寫code generator

而目前沒有辦法做到任何case都可以適用,最大的問題也許是角色互換的那個trick。

再來就是我們要幫它們的module function 建立Double Buffer機制、然後傳遞資料時要有TAG的資訊,TAG不能都用一樣的,因為會有效率上的問題。

期待學弟了解這些機制後和寫法後能夠改善。

2009年6月9日 星期二

Cloud computing

http://www.bnext.com.tw/LocalityView_7722
http://mr6.cc/?p=2281
http://mmdays.com/2008/02/14/cloud-computing/

好久沒新文章,來灌一下水
大家都嚷著開發雲端運算,
什麼是雲端運算?是不是分散式運算?在第二篇文章有明顯的區分。

2009年6月2日 星期二

Partial Tracking - centcent

20081118
主要是訂正 F0 frequency的精準度。
我們所得到的trajectory主要是由 F0 candidate 所產生出來的。

從Ircam的資料,我們可以明確的得知說每個frame 的 F0 candidate 是否有包含 Estimated F0。
可是從義崧的程式,只能得到上述兩個的Frequency,所以當初這部分的判斷和維城是用討論之後是用FFT bin來判斷。

不過因為義崧程式得到的 Estimated F0 的 bin 是經過權重之後的結果,會有小數,因此將這個bin 四捨五入之後在和F0 candidate的bin 做判斷,因此會有誤差存在。所以才會造成一直線的狀況發生

因為Estimated F0 的 bin經過四捨五入之後為20,包含於F0 candidate的bin,如下圖




解決辦法,如果一個frame的F0 candidate有包含 Estimated F0,這時就將F0 candidate其中的 frequency改成有包含Estimated F0的bin frequency。



投影片

comments:
1. 原先的 pruning 是判斷有無 estimated F0來移除 trajectory。
2. 如果我們沒有estimated F0的資訊,只有F0 candidate,想方法來判斷是否為 partial,移除掉其他非partial的部分,最後再利用找出來的partial來找出F0。
------------------------------------------------------------------------------------
20081125
這星期主要做的就是看能不能從義崧的程式找出更多的 candidate 出來。
改變設定上下限的變數即可找出多一點的 candidate ,不過低頻的地方看起來有很多非真正 candidate 的點。


另外發現如果有太多的 candidate,pruning 這動作好像無法找出真正的F0出來,這部分還要再仔細去看數據才知道哪裡出問題。

投影片

comments:
1. 會造成低頻有這麼多假的node,應該是因為是取最大公因數。要濾掉這些node,除了考慮這些點的weight之外,在去看看這些node有沒有能量存在
2. 如果F0沒有能量,這種例外的狀況,再想辦法來解決

------------------------------------------------------------------------------------
20081202
發現之前用當作 F0 candidate的資料是我找錯了,我找成義崧用來投票的,所以結果就不這麼好看。這次的結果看起來比較正常了。



是否可以試著透過義崧的演算法將已經找到的 partial 的資訊移除,然後再找另一個partial?
partial是經由投票所產生的,而每個bin都有提供各自的 weight,若將每個bin提供的weight記錄下來,每找完一個partial,每個bin就減掉之前提供的weight,再用來找下一個partial

投影片

comments:
1. 增加一些參數給HMM,例如能量以及partial之間的相關性
2. inharmonicity 的狀況:或許不一定要看基頻,而可以只看前一個或二個的partial
------------------------------------------------------------------------------------
20081209
1. 上週提到「是否可以試著透過義崧的演算法將已經找到的 partial 的資訊移除,然後再找另一個partial?」這部分實做的時候移除weight後沒有重算bin的能量。
2. 找到一篇paper提到說freq 和 amp 在顫音的時候,freq 上升,amp會下降。paper中提出可以把 d^2 = [(fi - fj)(ai-aj)]^2 當成 HMM 中transition Prob的參數。

投影片
paper

comments:
1. paper 的假設是錯的,如果整個音源來看是對的,可是如果看單一partial的話,並不是絕對。
------------------------------------------------------------------------------------
20081210
1. 找鋼琴inharmonicity 的曲線,直接套用此曲線即可。
2. 斷掉的partial相連,試著找出一組公式,放進去HMM裡當參數。或者用公式來 implement
3. 由義崧的演算法,找出F0之後,再找F0的倍頻,看看倍頻附近是否有peak存在(能量大的),這個peak則為F0的partial。找出一個F0以及其partial,將這些移除,再找下一組F0和partial。若有鋼琴存在,則套用[1]的曲線公式。
---------------------------------------------------------------------------------
20081216
1. 義崧學長有針對bin下去做平滑化,當初是避免有小突起的peak,不過這樣會造成multiple f0差三根bin會找不到,所以把這部分移除掉。
2. 根據20081210,找出F0之後,再找F0的倍頻,看看倍頻附近是否有peak存在(能量大的),這個peak則為F0的partial,這邊判斷方式用12平均率,f0的倍數上下半個半音是否有能量存在,大約是上下3%。
3. 上面那個判斷方式,在高頻部分,有可能會包含許多bin進來,因此,將最接近f0*multiple的peak視為f0的partial

投影片
----------------------------------------------------------------------------------
20081223
1. 這次完成找出multiple f0了,針對小提琴和長笛下去做處理,找partial的判斷方式為
f0 * mutiple * 0.97 <= peak <= f0 * mutiple * 1.03
找出的結果如下圖

2. piano inharmonicity:根據[H. Fletcher, E. D. Blackham, and R. Stratton, 「Quality of piano tones,」 J. Acoust. Soc. Am., vol. 34, no. 6, pp. 749–761, 1962.]這篇論文,鋼琴的partial 頻率和鋼琴每根弦的直徑、長度、張力、材質有關。

投影片

comments:
1. 判斷partial的範圍:若要找第N個partial,f(N):
(△f + f(N-1)) * 0.97 <= peak <= (△f + f(N-1)) * 1.03
△f = f(N-1) - f(N-2)
------------------------------------------------------------------------------------
20081225
1. 12月23號那張圖的第一段音樂,F0有260HZ和330HZ,可是找出來的結果330HZ沒有找到,這和我們設定上下3%其實沒有關連,會造成這樣的結果是因為義崧的程式有一段是針對二胡的特性來寫的,二胡的最高能量不一定落在f0,可能落在2或3倍頻,因此用這段程式碼來找出F0。將這部分拿掉就可以找到260HZ和330HZ了。
2. 將原本找partial的判斷式改為
(△f + f(N-1)) * 0.97 <= peak <= (△f + f(N-1)) * 1.03
△f = f(N-1) - f(N-2)
結果如下圖:

這邊發現一個問題:原訊號如果兩個partial相當接近,而一個partial 能量遠大於另一個partial,能量較小的那個partial會無法找到。以這張圖為例,F0為260和330,在990和1040附近應該都要有partial,可是990的能量遠大於1040,就無法找到1040這個partial。
我想這是因為一開始要將有peak的bin考慮進來的時候,包含1040HZ的這根bin並沒有特別突出,這根bin就沒有被考慮進來了。
------------------------------------------------------------------------------------
20081230
偷懶了一下,這麼晚才更新
1. 如果兩個音只差一個半音,只能找到一個F0,而且這個F0會落在兩個音頻率的中間。例如Violin:260Hz & Flute:277Hz,找出來的結果大約是269Hz,因此這269Hz的partial都沒有能量也就沒有找到。


投影片

comments:
1. 關於12/25提到的partial能量不夠大,DNA提到可以做類似將高頻的能量平方的動作,或許可以使peak更為明顯。
2. 12/25的結果,高頻部分有些partial斷掉,在HMM中加入是否為partial的condition。
-----------------------------------------------------------------------------------
20090106
comments:
1. 關於F0s差半個音無法辨別出來,可以針對低頻部分提高解析度來做
2. 高頻部分,可以利用影像處理的前處理方式,做一個operator來處理,來辨別出我們所要的資訊
-----------------------------------------------------------------------------------
20090209
1. 之前關於低頻F0s差一個半音無法辨別出來,這段期間有做一些提高解析度(zero padding)以及一些作法來實驗。
a. 經過 lowpass filter
b. 經過 lowpass filter 再做 zero padding
c. 認為高頻有太多的candidate影響投票,所以只拿一半的 candidate 來投票
d. 只拿1.2K以下的candidate來投票
發現都無法找出兩個F0(260Hz、277Hz)。
後來發現原來是義崧學長在找candidate的時候,會根據一個peak的前後兩根 bin 找最大個一根來當作candidate,在samplerate=44100,framesize=8192時,260Hz和277Hz大概差3~4根bin,所以在這個地方就只會把其中一個拉進去當candidate。所以沒有這兩個candidate。
2. 將這地方拿掉之後就可以正確的找到260Hz和277Hz了,只是高頻部分(2.5kHz以上)有點糟糕。

3. spectrum要幾次方以及protrudeValue的threshold會影響 260Hz&277Hz 和 260Hz&330Hz 的結果,第一個結果不錯,第二個就有點糟,這地方還要多測試。
------------------------------------------------------------------------------------
20090212
1. 多設定一個noise floor,將原本的spectrum扣掉這條 noise floor再去做後面的動作。noise floor的做法為往前往後看L點,取平均
s[i] = Σ x[i-k] / (2L+1) , k = -L ~ L
x:原本spectrum
這樣做可以避免若基頻落在高頻的時候,低頻一些peak會影響結果,導致找出來的F0落在低頻。
2. 原本義崧學長程式中protrudeValue表示的是 (magnitude of a peak) / (magnitude of the higher foot),這邊我改成用斜率表示。
260 & 277Hz

260 & 330Hz

1046 & 1108Hz

-----------------------------------------------------------------------------------
20090217
1. 修正bug:原本 F0 * 0.97 < F0 < F0 * 1.03,沒有處理在這個範圍內有兩個以上的bin。新增要找最接近的bin。
2. 在找 candidate 時,新增一個threshold:比最大能量小 48db(約1 / 256)的bin 不考慮進來。針對單純沒有變音的就抓的比較漂亮了。
1046 & 1108 Hz

3. 找了巴哈無伴奏的一段音樂來跑,有六段不同基頻(小明聽出來的),分別是
a. 0 - 1 sec : 830 Hz
b. 1 - 2 sec : 260 Hz & 493 Hz
c. 2 - 2.5 sec : 440 Hz
d. 2.5 - 3 sec : 554 Hz
e. 3 - 3.5 sec : 698 Hz
f. 3.5 ~ sec : 830 Hz
原始的圖如下:

找到的F0:在應該只有單音的地方找到多個F0,應該是換音所造成的,畢竟從能量上來看,這些frequency 以及其倍頻都還有能量存在。

F0 以及 Partial:

----------------------------------------------------------------------------------
20090223
1. 老師提出的對每一根有可能是f0的bin,將五倍以內的bin都取出來投票,若有得到F0以及其
partial,則下一輪投票就不要將這些考慮進來。只是這樣結果好像沒有比較好,跟上次的比較起來,F0少了一點。

2. 用midi產生DoMeSo,結尾加上 reverb,再加上ReFaLa。
Wav:

F0:在有重疊到的地方,找的還不錯

------------------------------------------------------------------------------------
20090225
1. 20090223提到的第一點,做出來效果不好是因為我程式少寫一些判斷式,所以少找了許多F0出來。下面是更改過後的結果。
做法是每個candidate都假設可能是F0,依照這根bin往上看5倍。

是有比原本的結果比較好,可是相對的高頻也多出了許多fake的F0,這是因為每個candidate都預先認為可能是F0,高頻部分有些剛好不是先前找到F0的partial,所以再往上看5倍,也有可能會認為當下的這根bin是F0。
2. 如果要用這種辦法,好像無法避免這種狀況。因此在這邊多加了一個threshold,當一個candidate的能量大於最大能量的1/8(約18db),才認為這個candidate可能是F0,再下去投票。
結果如下:高頻部分少了許多fake的F0。

3. 拿真正鋼琴的聲音來做測試
wave:

F0:當一個新的音起來,舊的音還有餘音的時候,而新的音剛好是舊餘音的倍數時,這時候就有可能把F0找成舊的音。

-----------------------------------------------------------------------------------
20090226
上面鋼琴曲的樂譜,原來有這麼複雜, Ballade No. 1 Op. 23,應該是蕭邦的吧

-----------------------------------------------------------------------------------
20090304
1. 我們為瞭解決低頻能正確找到F0,所以FFT的size增加到8192,但是,相對的原音在Vibrato時,會碎成許多小peak(如下圖),所以會找到許多相近的F0。

2. 解決辦法:在一個半音內(94% ~ 106%)只會存在一個F0,因此試著用在這範圍內,找出能量最大的來當作F0。跟20090225的巴哈比起來,第一段有抖音的部分,已經沒有非常接近的F0了。

3. 解決完這問題之後才突然發現,這問題其實可以靠HMM來解決,因為我們HMM要多加入partial和 amplitude 這兩個參數進去。到時候將HMM建構起來之後在和上面提到的方法來做比較。
-----------------------------------------------------------------------------------
20090310
1. 原本定義下列狀況下,candidate不相連。cCandidate:current candidate,rCandidate:往前看的 candidate
(cCandidate is F0) && (rCandidate is Partial)
(cCandidate is Partial) && (rCandidate is F0)
(cCandidate's F0 和 rCandidate's F0 差超過一個半音)
(cCandidate's Freq 和 rCandidate's Freq差超過一個半音)
老師建議將 candidate 的 Frequency 和 magnitude 都放進去 HMM 的 HiddenStateProb 裡。這樣可以讓 model 更加完美,讓人信服。
2. 維城學長是利用 Gaussian function ,△f當變數來算 prob,我們可以利用2維的Gaussian function,△f 和 △magnitude來當變數。function如下



3. 在前端部分,也就是f0 detection 部分,在找partial的部分加入一些 virtual node,可以讓後面的 HMM 的加以參考。要增加 virtual node的條件先假設 F0 往上看10倍,若real node比例達80%以上,再增加 virtual node。virtual node的magnitude為0。
4. 因為有這些 virtual node,magnitude 為0,所以 HMM 那邊多一個只有 △f 的 Gaussian function 給 virtual node 用。
-----------------------------------------------------------------------------------
20090312
1. 用不同的 Gaussian function 來處理node 之間的連線,會有問題,因此還是只用一個Gaussian function,只是virtual node的magnitude,直接用FFT的能量即可。

2. 原本討論要用 α*Decay + β* HiddenProb + (1 - α - β) * PartialFunc,這邊PartialFunc是考慮 Partial 的關係。原本HMM的連線方式是node 對 node,我們可以改成 整組對整組,也就是F0以及其partial視為一組下去做HMM。
-----------------------------------------------------------------------------------
20090318
1. 現在的作法是 α*Decay + (1 - α)* HiddenProb,HiddenProb是用二維的Gaussian function,△f 和 △magnitude來當變數,整組(F0+partials)下去算的。
結果如下:
小提琴 DoMeSo+ReFaLa:

巴哈無伴奏:

2. 接下來就是建立前後兩部分(f0 detect、HMM)的LOOP以及tune HMM 的參數(σ和α)。
-----------------------------------------------------------------------------------
20090325
1. 要training Gaussian function的參數,打算利用八度音來區隔,大略分成6個區段
100 ~ 261 Hz (C4)
261 ~ 523 Hz (C5)
523 ~ 1046 Hz (C6)
1046 ~ 2093 Hz (C7)
2093 ~ 4186 Hz (C8)
4186 ~ 8000 Hz
2. 用midi產生的wav來train這些參數(σ1,σ2,Cov),儘量有Vibrato和滑音。
-----------------------------------------------------------------------------------
20090408
1. 六個區域的參數已經train出來了。
只用一組參數的Bach

六組參數

變化好像不大
2. 皆下來的工作 a.建立loop b.train出attack state的initial weight c.擬出論文大綱
----------------------------------------------------------------------------------
20090421
20090421
1. 原本Loop的動作是
  • 找出f0
  • Tracking
  • Smooth
  • interpolated
  • 利用出來的結果回頭找F0

2. 不過因為smooth的動作經過多次loop之後會讓vibrato趨於平緩,因此這邊改用linear prediction的方式來校正node
  • 找出f0
  • Tracking
  • linear presiction
  • interpolated
  • 利用出來的結果回頭找F0

----------------------------------------------------------------------------------
20090506
1. vibrato 部分顯示出來會像是鋸齒波,而不是sin波,如下圖。

這是因為我們找出來的F0的曲線就是類似這樣子的。

2. 如果我們看f0那張圖在vibrato的時候,有時候在同一個frame會找到兩個點,這是因為在原本的頻譜圖上就有兩個peak存在了,這應該是頻率解析度造成的問題。

3. 既然我們知道它是vibrato了,那我們可以記錄它震盪的大小,經過多次smooth之後,會趨近於sin波,這時候我們再將它放大到原本震盪的大小。
4. 也可以用分bank的方式,低頻用高解析度,高頻用低解析度。
-----------------------------------------------------------------------------------
20090512
1. 記錄vibrato震盪的幅度,最後再修正到原本的位置。我是先用古琴來測試,第一張圖是一開始找到的F0,第二張是經過多次smooth之後的,第三張是是修正到原本的位置。
原本的F0,請忽略那幾條直線,畫線出問題

多次smooth之後

修正至原本位置

2. 用在Bach上,還有些問題,正在找出問題所在,應該是條件設定要調整。
----------------------------------------------------------------------------
20090602
1. 打算加入之前20090225我們討論過的,只往上看五倍下去投票,這樣子的結果比較漂亮。
下圖是沒有加入新的方法。

下圖是加入新的方法,可以看出換音的地方原本的音延長了許多。