2010年3月1日 星期一

OPENESL GUI

2010/03/01

OPENESL GUI修正事項

針對使用上的便利性 以便讓更多人習慣以這樣的tool來開發ESL
將對一些使用上的小地方做修正 並加入我認為需要的功能
然而針對這樣的使用tool方式 我期望達到幾個目標

1.讓OPENESL向自動化的方向發展 也就是使用者能碰到越少底層越好
2.更多便利使用的IP 元件等等
3.對TLM的傳輸 製作可觀測的波形圖 (考慮使用既有的為優先)

目前以上以完成第一部分為優先
因此粗略列了一下相關項目
// OpenESL改版預計項目

整體使用

1.wizard add port的部分
2.source code位於OPENESL SHELL之中 修改成一份
3.版本名稱的統一 不修改class name加上版本名稱
4.點擊模組圖開啟檔案.cpp .h .xml
5.製作parser使修改後的code可以直接形成模組圖
6.製作openesl專屬視景圖
7.console部分的bug

針對項目還要評估時間 目前已經著手在處理一些bug的部分

SystemC Kernel- ruru

2010/03/01
針對目前平行化的kernel還有需要加強並修正的部分如下
// SystemC Kernel

Win32
1.開啟多執行緒 並且以OS讀入的處理器數目做為執行緒的數目
2.針對所需執行的工作 以自動排程的方式取代人工排程
3.針對通訊與傳輸資料部分 以thread所提供的mutex 避免重複存取

Linux
1.修改版本讓他可以跑在Linux上

//
1.測試如何使他可以運行在伺服器主機架構上
2.跑數個平行化的範例 (矩陣相乘 OR 影音解碼)

大致上完成預計工作時間





2009/09/01

針對SystemC的執行過程進行trace
近期詳細如下
systemC kernel

前言

目的將systemC的thread改成multi-thread
加速其模擬效率.

System Architecture of ManyCore Simulatorn - 鈞/阿凡/宗胤/品皓

--- 2010/03/01 01:00PM ---

以下是 Y凡的意見,先將其放入主文。我在回應的地方後面有加一些意見。

-----------------------------------
關於core之間的通訊協定部分
我想參考TCP通訊協定,實做這些部分來達傳輸的可靠性,只是不知道這樣做對傳輸效率會有多大的影響

封包中主要定義"來源位址"、"目標位址"、"封包大小"、"剩餘window大小"、"資料sequence"、"偵錯資訊"及"要傳送的資料"

封包的遺失與重傳
設定一個delay time,當收方在收到封包後,送出ack給送方。
而送方在送出封包後,,開始計時,若在delay time前沒收到ack,就自動重送封包
根據收到ack的時間來動態的調整delay time

window advertisement
收送方兩端都約好一個空間大小作資料暫存,在傳送封包及ack時告知對方次空間的大小,當空間已滿時暫停傳送

3-way handshake
利用synchronization segment來建立連線,finish segment來終止連線

congestion control
送方送出封包收到ack後,即將資料傳輸量加倍,直到傳輸量達到收方的window size的一半為止

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


--- 2009/12/02 06:40PM ---

實作方向

1. Using standard ANSI C to implement the loader's functions of processors(Cores) , so they can be cross-compiled to others binary code to run on different core architectures.

2. The Network-Interface and Router's functions are builded by SystemC. They simply do the function of exchanging data between processors(Cores) and Host.
3. The Network implementation should be easy replaced to the Network architecture, using in 8051 CPU, which suggested by 宗胤 today(2009/12/2).

Network Architecture(按我下載)





--- 2009/12/02 10:07AM ---

Function list of Host loader

1. Initialize all Processors, include the stack region size, data
region size, number of code region , code region size.
2. Decide and Partion the Stack size, Data size, and function Code size according the Tasks of the Job.
3. Schedule the tasks of the job according the resource of multicore System.
4. Dispatch Data and tasks to Processor.
5. Infor Processor to execute a task.
6. Sync the task between all processor.
7. Deal with all errors and status of the
multicore System.
8. Collect all the data from Processors and Finalize the Job.


Function list of Processor loader
1. Initialize the stack region size, data region size, number of code region , code region size.
2. Place the Code and Data to their local memory region.

3. Wait the command from Host to execute the code on code region.
4. Pass the data to next processor.
5. Pass the status to next processor.
6. Return data to Host.
7. Return status to Host.




--- 2009/12/01 ---

依據昨日晚上與今日下午與阿凡/宗胤/品皓討論出來的API架構

阿凡整理的API架構Word檔案(按此下載)

*********** 以下是直接節錄阿凡整理的檔案內容 ********
一開始在initial的動作中,會先將整個code與data分成幾段,並且知道每一段的大小,決定好每一個processor要執行哪些code,用到哪些code。

memory中包含幾個code region、幾個data region,以及這些region各自的起始位址及大小,每個processor會維護一個資料結構來存這些資訊。


HOST端
1.InitializeProcessor(ProcessorNo, Information)
將初始化資訊Information傳給指定的processor
2.DispatchCodeToProcessor(ProcessorNo, CodeNo , CodeRegionNo)
將指定的code傳遞至指定的processor的指定code region
3.StartExeCode(ProcessorNo, CodeRegionNo, RelativeStartEXEAddress)
processor開始執行指定位址的程式碼
4.DispatchDataToProcessor(ProcessorNo, DataNo, DataRegionNo)
將指定的data傳遞至指定的processor的指定data region
5.GetDataFromProcessor(ProcessorNo, DataRegionNo)
從指定的processor的指定data region取回資料
6. GetInformationFromProcessor(ProcessorNo, struct Information *)
從指定的processor取回region資訊
7.GetStatusFromProcessor(ProcessorNo, struct Status *)
從指定的processor取回Status資訊
8.定義region資訊
struct Information {
ProcessorNO; // 自己的processor號碼
NumOfCodeRegion; // CodeRegion數量
Struct CodeRegion *;
NumOfDataRegion; // DataRegion數量
Struct DataRegion *;
StackSize;
}
struct CodeRegion {
CodeNo;
CodeSize;
}
struct DataRegion {
DataNo;
DataSize;
}
9.定義status資訊
struct Status {
StatusNo;
}

Processor 端
1.Initialize(Information)
依照Information做初始化
2.ExeCode(CodeRegionNo)
執行指定code region裡的程式
3.InfoHost()
主動通知host,回傳Status
4.InfoProcessor(ProcessorNo, DataNo, DataRegionNo)
主動通知processor,回傳Status
5.SendDataToHost(DataRegionNo)
將指定data region裡的資料傳回host
6.SendDataToProcessor(ProcessorNo, DataNo, DataRegionNo)
將指定的data傳遞至指定的processor的指定data region
7.GetDataFromProcessor(ProcessorNo)
將指定的data傳遞至指定的processor的指定data region

Cloud Computing API
1.HostToProcesssor(Host, ProcessorNo, Data *)
2.ProcessorToHost(Host, ProcessorNo, Data *)
3.ProcesssorToProcesssor(ProcessorNo, ProcessorNo, Data *)




--- 2009/11/26 ---

補充一下昨日課堂上老師談論的一些資料

1. 系統的走向不以HPC為目標,但需兼顧日後的cores角色替換方便性。

2. 擔任cores的角色可以是硬體也可以是軟體。因此,它可以是arm base或8051或Sparc或x86等任一架構。

3. cores的任務很單純,就是接受host指示,執行由host送來的binary code。而且以single thread方式執行,但是其local memory可能同時間存放好幾套不同function的task的binary code,可以方便某一task執行完畢之後,切換至另一個task。

4. host 則是擔任資源與task分配的運籌中心角色。

5. 介於host與cores的網路,則以搭配的cores來對應軟硬體。可以是bus/ring等型式。



--- 2009/11/19 ---

依老師昨日所提,我大概畫了一下系統架構圖,如果有出入,請指正。
系統架構圖word檔案(按此下載)




至於所需的API,我先提出我想到的部分。

HOST Scheduler API
1. EXECodeToProcessor(ProcessorNo, CodeNo, CodeSize, CodeBlockNo )
2. ReplaceCodeFromProcessor((ProcessorNo, CodeNo)
3. DataToProcessor(ProcessorNo, DataNo, DataSize, DataBlockNo)
4. DataFromProcessor(ProcessorNo, DataNo, DataSize, DataBlockNo)
5. GetInformationFromProcessor(ProcessorNo, struct Information *)
6. struct Information {
ProcessorNO;
NumOfCodeBlock;
Struct CodeBlock *;
NumOfDataBlock;
Struct CodeBlock *;
}

Processor API
1. ExeCode(CodeBlockNo)
2. DataToHost(DataBlockNo)

Cloud Computing API
1. HostToProcesssor(Host, ProcessorNo, Data *)
2. ProcessorToHost(Host, ProcessorNo, Data *)

android-SLIM

目的:把SLIM移植到android平台上
實作想法:
1. 先在"application layer"上,建立一個可以讓使用者輸入SLIM指令的類似終端機介面。
2. 再透過"application framework layer"上,建立java library並利用JNI方式,可以讓上層收到使用者輸入的訊息後,傳遞到下層"library layer"中的SLIM library。
3. 實作SLIM library於"library layer"

--------- 2010/03/01 ---------
目前進度:
1. 利用android SDK的環境,將最上層的介面完成如圖:

2. 實作jni部分,目前可以將C++ STL部分,例如:string class 部分可以透過jni對java與C++之間作傳遞。如圖:

3. (未完成) 因為這部份重點跟第二點差不多,重點是在於C++ STL部分的相依性。由於android本身並沒有提供C++ STL library,所以解法是利用stlport library (STLport is implementation of C++ Standard Library),先將stl部分先用靜態聯結方式與SLIM library部分做聯結,然後將整個SLIM library 編譯成動態連結檔,供jni呼叫。目前步驟在SLIM與stlport連接上SLIM makefile修改部分與聯結問題上。

2010年2月28日 星期日

H.264 進度報告 --- 雙魚

== 2010.02.28===

在程式中去找intra prediction幾種比對模式的程式碼
luma有分成16*16和4*4兩種,Chroma提供4種兩個8*8模式

(1)luma 16*16是以一個16*16大小block去作預測,提供4種模式


(2)luma 4*4是把一個16*16 block再切成4個4*4去作預測,提供9種模式


(3)Chroma提供4種兩個8*8模式,分別是DC Mode、Horizontal Mode、
Vertical Mode、和 Plane Mode , 其中DC Mode會把8*8再切成4*4 block
依照每個4*4 block上側和左側資訊而有不同的數學式子去進行預測

這邊有從網路上找資料,資料pdf中有每一種預測模式的數學式子
從式子去推導每一點像素的式子數字,接著再和程式碼的寫法相對照
參考的pdf連結: http://0rz.com/LnhA

這學期理想的進度甘特圖

希望一個月可以完成一個元件的改寫,先從intra prediction開始
下禮拜會看AVS中intra prediction的文件內容

== 2010.02.01===

對quatization後的Y數值來壓縮和解壓縮
利用上次產生出來的codeword table來練習

(1)去找每個數值對應的codeword
ex:有三個數值5,13,-5, 5的codeword是101
13的codeword是0101 ,-5的codeword是1111

(2)codeword累積到8個以1個byte寫入新的檔案
設一個變數unsigned char c去記錄要寫入檔案的數值
a陣列記錄要壓縮數值所對應的codeword
當a[i]=1 , c = c先往左shift一個 再和00000001 作or
當a[i]=0 , c = c往左shift一個
如果c未滿8個 後面也沒有其他數值要壓縮
c=c往左shift讓剩下位置補0到滿8個

ex: 要壓數值5,13,-5 , codeword如(1)
第一次a陣列中是101, 判斷完a陣列中每個位置後 c=00000101
第二次a陣列中是0101, 判斷完a陣列中每個位置後 c=01010101
第三次a陣列中是1111, 判斷完a[0]位置後 c=10101011 已經達到8個
這時候就要把c寫入檔案 , 寫檔後讓c=0 再繼續判斷a陣列中剩下的位置
判斷完剩下的位置 c=00000111 , 因為後面沒有數值要壓縮所以補0
c = 11100000 , 最後再把此值寫入檔案中


(3)把(2)寫入的檔案讀出 , 把1個byte拆成8個bit
讀出1個unsigned char c 後 ,下面的動作要作8次
先 c= c和10000000作and , 再讓c往左shift一位
把解出來的bit放在buf 陣列中

ex: 把(2)產生的檔案數值讀出做完拆解判斷後
buf中會是: 10101011 11100000


(4)到table中找codeword對應的數值
table會先依照codeword大小排序 , 從小到大排序
buf會一個一個位置去找現在停在哪個codeword中的哪bit
如果此codeword下一個bit是'\0' , 代表找到一個對應的數值

ex: 假設table只有三種codeword , 設定如(1)
codeword排序後是: 0101 , 101 , 1111
buf是: 10101011 11100000

當buf[0]=1 , 會停在 codeword 101 中的第0個bit
當buf[1]=0 , 會停在 codeword 101 中的第1個bit
當buf[2]=1 , 會停在 codeword 101 中的第2個bit
codeword 101 第三個bit是 '\0' , 所以就找到一個對應數值5


== 2010.01.22===

建立 huffman tree來產生對應的codeword
拿上禮拜作完quatization後的Y數值來練習

(1)去計算Y數值中每一種數值出現的機率
假設4種節點機率分別為0.15 , 0.2 , 0.25 , 0.4 (圖中紫色點)

(2)開始建立 huffman tree
S為所有節點的集合 , 從S中找出機率最小的兩個 : t1 t2
用t1 t2來產生一新節點N, N 是 t1 和 t2 的 parent節點
而且N的機率為 t1 + t2 , 接著把 t1 t2 從S中刪掉, 把新節點 N 加入S中

圖中用4種節點來說明步驟 , S= {0.15,0.2,0.25,0.4}
先拿0.15 和 0.2 來組合 , 此樹節點機率為0.35 (圖中藍色點)
把 0.15 和 0.2 從S中刪掉 , 把藍色點的樹0.35加入S中
接著拿0.25 和 藍色點的樹 來組合 , 此樹節點機率為0.6 (圖中咖啡點)
把0.25 和 藍色點的樹從S中刪掉, 把咖啡點的樹0.6加入S中
最後拿0.4和 咖啡點的樹 來組合 , 最後root的機率為1


(3)去找每種數值對應的codeword
左邊樹分支填 0, 右邊樹分支填 1
每個分支的 0 或 1 是圖上的黃底綠色字
每種數值的codeword就是從root到該數值節點的 0 和 1 組合

從圖上標記可以看到:
數值0.4的codeword是 0
數值 0.25的codeword是 10
數值 0.15的codeword是 110
數值 0.2 的codeword是 111


== 2010.01.15===

完成 DCT-> quatization -> IDCT 的練習
一樣是用txt檔案中的YUV數值
分別對YUV去作DCT-> quatization -> IDCT

YUV以4:2:0的方式儲存 , 4個Y共用一個U和V
所以 Y 範圍是352*288 , U和V則是 176 *144
先對Y作處理 , 接著就是U和V , 每次都以8*8為單位
流程如下:
(1)用下列的公式去產生DCT 8*8矩陣的數值
Aij = Ci*(cos((2*j+1)*i*pi)/2*N) ,
when i=0 , Ci= (1/N)^1/2
when i>0 , Ci= (2/N)^1/2

因為DCT是8*8 , 所以N=8
Aij代表的是矩陣中第 i行第j列的數值
DCT陣列的數值是double的形態儲存

(2)利用 D=(A)(X)(T)來作DCT
A是步驟(1)產生的DCT矩陣
T是A矩陣的轉置矩陣
X是圖片切出來的8*8方塊
D是AXT三者作矩陣運算後的8*8矩陣
D也是用double的形態儲存

(3)去網路找 YUV的 quatization table
quatization table也是8*8的矩陣
把經過DCT後的數值除以quatization table上的數值
除以quatization後的數值先做四捨五入
接著以 int的型式儲存起來

(4)把步驟(3)儲存的數值再乘上quatization table的數值
再以double的形態把乘完quatization的數值儲存起來

這時候會發現數值和一開始經過DCT後的數值有稍微的不同
ex: 經過DCT後是527.89 , 除以quatization 16 再四捨五入後
會以33的數值存起來 , 再乘回quatization 16 會變成528
雖然會有些微的不同 但是誤差都不會太大

(5)利用 X=(T)(D)(A) 來作IDCT
A是步驟(1)產生的DCT矩陣
T是A矩陣的轉置矩陣
D是步驟(4)儲存的8*8矩陣
X是TDA三者作矩陣運算得到的8*8矩陣

要去判斷X中的每一點的數值
如果數值>255, 要讓它等於255
如果數值<0 , 要讓它等於0
最後把X中的數值轉成 unsigned char 型式儲存起來

等 Y, U, V的範圍都作完上述流程
最後把數值以二進位模式寫入.yuv檔案中即可

如果quantization的數值比較小 , 被忽略掉的訊息比較少
作出來的圖片結果會和原始圖差距較小
如果quantization的數值稍大,被忽略掉的訊息比較多
可以從圖片上看到一些地方會變得比較模糊


== 2009.12.30===

利用之前txt檔案中YUV數值
此txt檔案中只有影片中第0張的YUV數值
將這些數值以frame型式寫入新的.yuv檔
檢查新檔案顯示的畫面是否和原本影片中第0張一樣

接著把txt檔案中YUV的數值轉成RGB模式
YUV是以4:2:0的方式儲存 , 每4個Y會共用一個U,V
一個MB裡面會有16個Y,4個U和4個V
RGB是4:4:4, 所以要先弄成一個MB裡面有16個Y,16個U和16個V

接著套用 YUV->RGB 的公式去計算
如果轉換後的數值>255, 要讓它等於255
如果轉換後的數值<0 , 要讓它等於0
最後再寫入.rgb的新檔案中即可


== 2009.12.24===

寫了一個小程式去判斷抓出的圖片數值是否正確
1.先讀取存在txt檔中的YUV數值
2.直接寫一個函式去讀取圖片的YUV數值
3.最後比較兩者的YUV是否一致



這邊是練習對MB 和 frame的位置概念
參考圖片 , 整張圖是352*288, MB是16*16 (圖中紅色方塊)
txt檔中是把每個MB中16的點 由左至右 由上到下寫入
一個MB寫完在換下一個 , MB也是由左至右 由上到下
frame是一個點一個點讀取 由左至右 由上到下 (圖中紫色方塊)

所以讀出txt檔每一個數值, 都要放回它在圖片的原本位置
步驟2是把圖片一個點一個點的讀入,然後儲存起來
最後再比較這兩個種數值是否有一致


== 2009.12.10===

目前已經把上次提的數值抓出
除了bitrate, 其他數值都以binary型式寫入檔案

1. 每個16*16 (MB) 的數值
圖片大小352*288 , 每16*16切成一塊
把16*16裡每點的pixel數值寫入檔案

2. 每個MB作完intra prediction的different值
intra prediction 分成 4*4和 16*16 兩種
(1) 4*4有9種mode , 每一種mode都會算出一個different值
先用一個陣列暫存每種mode算出來的different值
接著計算每種mode的cost大小, 找出一個最好的mode
這邊也會有個變數去記錄哪個mode是cost最小的
最後把此種mode的different值存進陣列(a4)
以4*4 去算different值 , 但最後要的是16*16
所以每次算完的4*4 要按著順序存進陣列(a4)

(2)16*16則有4種mode , 作法同上
差別在於 這邊是用16*16去算different值
只要把最好mode的different值存進陣列(a16)即可

作完上述兩點 , 每個MB會有 4*4 和 16*16算完的最佳解
會從中選一個來當作這個MB使用的different值
所以最後選出的different值才是要寫入檔案的


3. 每個MB作完 DCT+ quantization 後的數值
程式作完 DCT+ quantization的值存在 nMBQuant_Y變數裡
而且大小也是宣告成 16*16
只要將 此變數中 256個數值 寫入檔案即可
有記錄 Frame_I DCT+ quantization 後的數值
以及 Frame_P DCT+ quantization 後的數值


4. 得到每個MB需要的bits數量
此數值存在nRDBitRate變數裡
只要將此變數的值寫入檔案即可
一樣要記錄 Frame_I 和 Frame_P的BitRate


== 2009.11.18 ===

已經跟小新學長拿了程式
為了達成了解基本的H.264運作流程
計畫先取出下列幾個數值:
1.抓出MB pixel值
2.抓出MB pixel值 做過 Prediction(inter or intra)
3.抓出MB 4x4 DCT值
4.抓出MB 4x4 DCT值做過 quantization
5.得到MB壓縮所需要的bits數量

把這五個項目的數值取出來,分別存成一個新檔
這些檔案裡面的數值是後續步驟會使用到的
存檔的類型沒有限制 , 我想說把每項的數據存成txt檔
就從第一項開始作起 , 現在剛看程式 大略知道第一項要的數值在哪
這邊會再問一下學長 , 希望下禮拜可以抓出第一項的數值