2011年4月22日 星期五

Code Snaps


(請不要刪! 這是論文要用的reference!)

Click to see the original resolution.



張貼者： 於 沒有留言:

2011年4月8日 星期五

Jserv: from Source to Binary -- How GNU Toolchain Works

大神的最新力作, 有用到的人自己去研究研究吧.... :)
from Source to Binary -- How GNU Toolchain Works

引用一下簡介
一開始的切入點是簡單的 "Hello World" 程式，觀察其編譯的方式，探討 GCC 這個 compiler driver 的行為，進而擴展到 binutils 與 libc。不同於教科書的理論呈現方式，我們探討實務上面對的議題，比方說，GCC 設計初期就考慮到多個前端與後端，以及繁複的優化機制，光是 IR (中間表示式) 就歷經多次變革。在 gcc4 之後，再次大幅強化，而議程中則適時給予簡要的案例探討。另外，組譯器也並非我們預想一般單純，實務上還得充分考慮到 relocation 與位址處理的機制，最後才是連結器 / 動態連結器的引入，我們實地觀察了 x86 架構上，GNU/Linux 的執行時期行為。
張貼者： 於 沒有留言:
標籤： ,

2011年3月23日 星期三

Stages of Sleep

Dear all,
有關於這星期一的meeting,
我上網找了 stages of sleep相關的文章

ref:
http://www.sleepdex.org/stages.htm
http://www.sleepdisorderchannel.com/stages/index.shtml

NREM: stage 1-4
REM: stage 5 (deep sleep)

REM是屬於 stage5,
Normal sleep cycle: waking, stage 1, 2, 3, 4, 3, 2, REM.
所以針對showmin學長以及偉翔的問題 (REM之後的stage?)
應該只有REM stage(deep sleep stage沒有再細分下去)

這是我目前所找到的資料
或許有其他文獻有更詳細的說明
如果大家有看到 也可以更新我的資訊! ^^
張貼者： 於 4 則留言:

2011年3月20日 星期日

Qin Synthesis and SW tools - 仕偉

---------------2011.03.20---------------------

將圖片顯示部分改好，並修改排版。

主要功能：

將輸入的字串轉換成中序排序法，並顯示出輸入的文字減字。




---------------2009.12.23---------------------
實驗可變長度的digital waveguide.

結構圖如下:



input為white noise共44100個samples.
取樣頻率:44100Hz
設z的delay:N=44

gain值a,b變化如下:


意思是從N=44(頻率1000Hz) 變成 N=45(頻率980Hz)再變回N=44(頻率1000Hz)
從音檔可聽出音高有改變.

1000Hz到980Hz音檔


---------------2009.12.7----------------------

因為用論文方法的friction model效果不彰,
因此著手於建立古琴滑音的physical model.
大致流程如下圖：
1.錄製只有指甲刮弦的Noise並紀錄Waveguide長度與滑動速率.
2.調整Noise pitch.
3.餵入可變長度的digital waveguide.
4.得到古琴滑音.




投影片內另有不同的摩擦音可聽,按此下載.



---------------2009.11.26---------------------

更新friction model內部參數,實作後圖片如下.
更新音檔及提供matlab原始檔.









音檔下載:
R1, R2, R3, Lowpass, R1+R2+R3+Lowpass.
matlab原始檔:
friction2.m
friction model原論文:
Model-based sound synthesis of the guqin

---------------2009.11.25---------------------

friction model implement

friction model structure :


主要是由Rnd產生的noise經過三個resonator與一個lowpass filter之後輸出.

Resonator 1的頻譜圖:




Resonator 2的頻譜圖:




Resonator 3的頻譜圖:




Lowpass filter的頻譜圖:



將R1,R2,R3和Lowpass filter相加後的頻譜圖:



---------------2009.10.28---------------------

如果將"大九勾三","[大]*[九]+[勾]*[三]",圖片,分別在視窗顯示的話,複製時還要三個視窗分別複製,有些麻煩.因此想說把視窗合併,就跟以前的排版一樣，這樣會比較整齊。






---------------2009.10.8----------------------

論文報告

投影片

---------------2009.9.23----------------------

將ParserDialog中的括號拿掉,並新增英文介面.
















---------------2009.9.20----------------------

現在終於把古琴的減字譜Parser改寫完成,剩下圖形部分.


















---------------2009.8.22----------------------

現在進行程式改寫，由於同時還有另一個project：

Polyphonic Computer Music Authoring Tool 進行，

是用Java寫的；鑒於之後程式碼移植方便，

所以就用Java來改寫古琴程式，目前已做好介面，

code改寫約完成5分之1，會繼續來寫。
















↑ 上圖是程式介面圖，中間三個的視窗可以放大縮小或隱藏，如下圖所示：
















↑ 此圖為顯示ParserTree放大，隱藏另兩個視窗。

















↑ 這張是以後完成的示意圖。

現在左邊的輸入介面已完成，中間ParserTree尚未實作，

圖中是直接輸入進去的，減字圖形要再修改大小，

另外會有新功能：

cut, copy, paste ; 英文介面 ; 英文輸入 ;

修改字型 ; 還有老師提議的功能-輸入字後出現可選項目，

也會加入，不過現在還在摸索中，繼續改寫程式！

---------------2009.8.10----------------------
論文報告
Model-based sound synthesis of the guqin

投影片

---------------2009.7.28----------------------

根據學長的連結來解釋一下連結內容

第一個連結是來自Google 所舉辦的計畫 Summer of Code

主要是讓世界的學生參與撰寫開放原始碼軟體的project,從2005年開始舉辦.
目的是讓參予者能從中接觸到業界軟體的開發方法與就業機會相關領域的學術活動,並且寫越多的免費原始碼,就能越造福全人類.

此篇的project是'Qin' notation web generator:古琴減字線上產生器

作者致力於此研究原因有兩點
1.中國字較複雜需2bytes組成,不像英文只是26字母的排列組合簡易,中國字需花較多的時間創建font set.

2.在網路上瀏覽網頁,如果其字元並不符合用戶端電腦的font set,那就無法顯示.

因此作者想要做一個能在線上組合的古琴編碼網頁,讓人輸入所需的圖樣代碼後,
能在網頁上顯示相對應的減字譜.

主要使用的文法如下:

顯示全圖


並依每個指法自行畫出減字,又分為左右手兩類,左手有87個,右手有47個減字.

程式輸入範例:
san_c gou_a yi_a @ =;
er_b;
san_a;
ti_a_b san_a @;
ming_b shi_b_b | tiao_a liu_d @ =;
da_d jiu_c | si_d = liu_d =;
po_a da_d qi_a liu_d = | qi_a = san_c liu_d = | =;
jiu_d lun_b = qi_a =;
tao_a_qi_c;
tao_a_qi_c;
shi_b_a qi_a | tiao_a si_d @ =;
cuo_d da_d qi_a | tuo_a_b liu_d @ = @ zhong_a qi_a | gou_a yi_a @ = @;
shao_c_xi_b;

由於每個san_c,gou_a等等都是圖的檔名,所以要使用一定要配合圖片跟代碼一起看.

例:

san_c

gou_a


程式方面:

網頁上的Demo連結已無效,但有提供檔案下載,
好像只能在Linux環境下執行,但我執行時還是有出錯,可能是因為沒有下載圖檔的關係.
執行環境需求:Metapost, Perl, Convert

Metapost是個語言可讓人用數學描述畫圖,語法來自Metafont.
Metapost-wiki : http://zh.wikipedia.org/wiki/MetaPost

網路上還有附上解說的網頁投影片:http://web.pdx.edu/~candy/qin/tug05/open.html

** ** ** ** ** ** **

第二個連結內容是中國音樂學(季刊) 2008年第2期,應該是大陸那邊的雜誌.

標題是:古琴減字譜的編碼與編輯方法

內容前段介紹古琴歷史,中間主要介紹老師所研究的減字譜編碼方式,

後面提到他們所希望建構出軟體所具有的功能:

包含

1. 文件操作:新建,打開,保存,列印,關閉等
2. 文件編輯:剪下,複製,貼上,查找,取代,全選,調整字體或字型等.
3. 減字分類:將減字按照"散音","按音","泛音","其他減字"分成四大類,
每一大類下又將它們按照不同的彈奏方法分成各個小類.
4. 選擇減字:通過選擇某類減字,能顯示該類所有的減字,並按照需求再次進行選擇,
並可對選擇的減字實現文件編輯功能,即複製貼上等.

----------------2009.7.23----------------------

我把我的那一串的內容貼過來, 原來的就讓它沉下去吧! 我順便把維城學長的回應記錄在這裡:

無事google了一下，發現兩個有趣的相關的連結：
1. Project Title: Chinese music instrument: 'Qin' notation web generator, http://web.pdx.edu/~candy/qin/index.html
使用Metapost系統設計。
2. mac.xmu.edu.cn/Chinese/document/attachment.asp?id=39
這個比較無言一點，算是另類介紹我們實驗室的成果吧...

請你參考一下, 再跟我說這是什麼, 尤其是第一個link.

你目前的這個程式畫面跟我以前看到瑋倫所完成的不太一樣, 我記得左邊是打中文輸入後的結果, 右邊是減字譜. 我們當時似乎是有幫忙標一下簡譜的.

很好! 謝謝你這麼快的就有回應.

----------------2009.7.22----------------------

首先就先來簡介一下古琴減字譜軟體的功能。


１。軟體主要介面


顯示全圖



２。輸入介面，目前只支援中文輸入


顯示全圖


３。輸入後，預設輸出Parser Tree為Infix


顯示全圖


４。另外還有Posfix顯示


顯示全圖



５。英文顯示，不過目前好像有錯誤


顯示全圖


６。輸入法目前只支援中文，英文功能未定


顯示全圖


７。關於


顯示全圖


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

2009,7/14

這是一個未完成的研究, 我們在未來一到兩年要把它完成. 最早是瑋倫學姊的古琴減字譜軟體的完成, 這是一個國科會數位典藏計劃的成果, 事實上受到許多人的重視, 不過跟多數的國科會計劃以及因為學生畢業的關係, 這個成果那時沒能延續下去. 多年來一直有人問, 連中研院院士都來問.

當時未能延續下去的一大原因是雖然古琴減字譜的輸入法很好, 可是聲音的合成一直沒能突破, 直到最近, 小明學長對起頭音的分析, 文森學長的pitch/Partial Tracking有了一些成果, 看來應該是東山再起的時候了. 在此我向眾多關心的朋友說聲道歉.

以下是相關的link:

古琴減字譜數位化

Centcent's Pitch and Partial Tracking

等小明過幾天把減字譜軟體頁面的圖準備好, 我再來更新.



由於古琴聲音與演奏的特性, 文森學長的pitch/Partial Tracking事實上需要一定程度的修改, 或者正確一點的說是Customization, 也就是量身訂做.

同樣的, 我來起這一串, 接著就由仕偉來接續. 第一個工作當然是把減字譜軟體回復, 這一部分比較簡單. 但是聲音的部分就困難一點. 整個軟體要怎麼做, 我會跟相關的人討論. 而要做的事情如下:

1. 琴音的分析, 也就是pitch/Partial Tracking, 這一部分會比較簡單, 因為我可以把音一個個分開來彈.

2. 分析結果的修正, 這一部分恐怕暫時需要人工來做, 不過SW工具還是需要的, 這部分可以跟authoring tools那邊合在一起, 所以這部分建議做成一個外掛. 我們再來討論要怎麼分工.

3. 根據輸入的減字將每個音合成出來, 這部分要動用additive synthesis以及起頭音合成, 我還不知道小明對提琴的起頭音那部份的成果是否可以直接用過來, 不過值覺是可以的.

4. 根據使用者對演奏articulation上的需求(多半指的是滑音, 少數是其他技法), 重新在合成.

5. 將每一個合成的音照使用者指定的時間排好.

至於其他的事就等這些做好再說!好吧! Let's go!

對了, 請以後將這串同時update到: 古琴減字譜數位化. 感謝!

張貼者： 於 12 則留言:
標籤：

2011年3月1日 星期二

[課程] 高速運算應用與多核心系統

2011/05/19
==========================================
Server 已經好了，請大家連線寫程式。
之前提供的 library 有 Bug，已經修改好，麻煩同學重新下載。

有同學說他在 console 下不能執行 spcishell，那應該是權限問題，
請開啟 console，移動到 spcishell 所在資料夾，輸入 "chmod 755 spcishell"，即可。


2011/04/11
==========================================http://www.blogger.com/img/blank.gif
請同學下載這份文件，並且根據內容練習一下用
SCREAM Processor-Cluster Simulator 寫程式吧，
如果有任何問題，請聯絡陳威佐。

http://ludwig.csie.ncku.edu.tw/members/Longest/SPCIshell_new.rar

2011/03/29
==========================================
上次老師講課的投影片(MIT Course)
http://ludwig.csie.ncku.edu.tw/members/Longest/MIT_courses.rar

2011/03/08
==========================================
請於下周一 3/14，11:59:59 PM 前繳交 CUDA 作業。

下周易聰、翊臺將會講解他們要開發的 Application，

威佐也會講解 SCREAM Processor Cluster Platform。


2011/03/01
==========================================
課程老師: 蘇文鈺
Email: alvinsu@mail.ncku.edu.tw

課程助教: 陳孇瑀 (Cuda)
Email: bbh4747@hotmail.com

課程助教: 陳威佐 (Scream Multicore)
Email: prodigyjerry@gmail.com


本次上課內容: 講解 CUDA，以及各位同學報告想作的應用。

今天上課上的 CUDA 教學可以到此下載:
http://0rz.com/hj3aC1

FTP為:
140.116.82.184:21
course/course
張貼者： 於 沒有留言:

新一學期group meeting報告順序

教室我一路借到8月了，不過碩二口試時間通常在七月底，因此我只排到七月初。碩二同學請每週報告進度。

2011年group meeting 報告成員
日期
報告成員
3/7
翊臺、易聰
3/14
威佐、玉琳
3/21
大鈞、依諴
3/28
君宇、偉翔
4/4
兒童節
4/11
翊臺、易聰
4/18
威佐、玉琳
4/25
大鈞、依諴
5/2
君宇、偉翔
5/9
翊臺、易聰
5/16
威佐、玉琳
5/23
大鈞、依諴
5/30
君宇、偉翔
6/6
端午節
6/13
翊臺、易聰
6/20
威佐、玉琳
6/27
大鈞、依諴
7/4
君宇、偉翔

張貼者： 於 沒有留言:
標籤： ,

2011年2月28日 星期一

Multi Arm - 哲榮

-------------------------------------
2011.02.28
-------------------------------------
1.
原本DPSRAM在CPU端與FPGA端的Memory map空間是同一塊,但是有byte addressing與word addressing的差異
但是依照上述方式測試時有錯,後來發現在Driver中已經先行把輸入的address*2
使的FPGA端與CPU端的都是以word addressing的方式存取DPSRAM

2.
測試並確定
FPGA的4 bit address (0x0~0xF) 對應到CPU的address為(0x180~0x18F)

3.
DPSRAM Interface電路完成但尚未測試完全

-------------------------------------
2011.02.19
-------------------------------------
MVC100透過IDE HDD與FPGA進行溝通
溝通方式是在MVC100版子有塊Dual Port SRAM(DPSRAM)
CPU跟FPGA皆可以存取此塊DPSRAM再加上介面提供的Interrupt機制
CPU與FPGA便可以透過DPSRAM交換資料

但是交換資料的協定必須要自己設計
目前的規劃是以CPU主動下命令給FPGA
CPU把read / write command、address、size寫入到DPSRAM上,並且發出interrupt給FPGA
FPGA收到interrupt後,便讀取DPSRAM上的命令,依據讀取到的命令做動作:

1. CPU發出Read指令 :
FPGA將CPU要讀取的資料寫入到DPSRAM上,並且發出Interrupt給CPU來讀取

2. CPU發出Write指令:
FPGA等待第二次CPU發出的interrupt通知 (第一次interrupt是Read/Write命令)
收到Interrupt,便讀取DPSRAM上的data,並寫入到FPGA的SRAM

目前正在以上述的協定改電路以及Driver





-------------------------------------
2011.01.23
-------------------------------------
因為目前MVC100的板子還在測試
因此士敦學長希望可以試著在friendly arm上跑MPI測試
但由於需要額外安裝MPI所需的物件 如:python、ssh
再加上士敦學長使用的arm-linux-gcc版本不同
因此需要重編他修改過的MPI
後來直接借他一顆friendly arm移植MPI

MVC100目前已經可以跑一輝學長的sram與fpga溝通範例
OS: linux2.6.28 (沒有android)
因為排線目前只接出部分sram的address與data腳位
只能使用4個bit address[3:0]、data[3:0]
範例執行結果:













接下來會試著修改driver以及範例電路為我的InterConnect架構


-------------------------------------
2011.01.17
-------------------------------------
Friendly arm已經把傳輸的protocol寫入到driver
並且也已經改成士敦學長的架構 （每個connection對應一個file descriptor）
剩下system call poll()還沒有實做

MVC100用廠商附的linux 2.6.28加上driver編譯完成
但是廠商附得file system是read-only的,所以在開機完後drvier掛不上去
這部份文森學長還要花點時間幫忙
所以就先換跑android版本的範例,但是一輝學長給的kernel image在開機的時候會有kernel panic的問題,我會再去問一下或者我目前有也有重編的android版本的linux kernel（2.6.27）再測看看


-------------------------------------
2011.01.10
-------------------------------------
friendly arm更改linux char driver的kernel function
原先使用memcpy()去存取fpga對應的virtual address
改成宗胤學長建議的ioread() , iowrite()
發現read指令的CS , OE訊號會有兩個low trigger的情況 沒有了

把呼叫driver的file descriptor函式換成linux system call 
int open(const char *pathname, int flags)
ssize_t read(int fd, void *buf, size_t count);
ssize_t write(int fd, const void *buf, size_t count);
不使用c lib提供的fopen fread fwrite
就會解決driver command延遲的問題

mvc100目前正試著執行一輝學長的範例
目前順利編譯好linux kernel 2.6.28
但是開機後掛載driver的步驟還有問題 要再請教一下學長


-------------------------------------
2010.12.29
-------------------------------------
搞定第三顆ARM了 (把sdcard的資料刪一刪後就又可以使用了)
另外還有跟士敦學長討論MPICH2 Multi-Arm driver的部分
因為學長目前的架構是每個connection各有一個file descriptor負責處理傳輸
如下圖























因此使用者呼叫Driver時不需要給driver 目的ARM對應的memory map addr
driver自行根據fd的minor number判斷目的ARM的memory map addr
呼叫driver的方式使用linux system call :
ssize_t write(int fd, const void *buf, size_t count);
ssize_t read(int fd, void *buf, size_t count);


而我目前的架構是一個file descriptor負責所有的connection傳輸
如下圖




















因此使用者呼叫Driver時要給driver 目的ARM對應的memory map addr
呼叫driver的方式使用C Lib的:
size_t fwrite ( const void * ptr, size_t size, size_t count, FILE * stream );
size_t fread ( void * ptr, size_t size, size_t count, FILE * stream );


目前會再做一版driver配合MPICH2的修改
還有跟文森學長借MVC100測一下InterConnect Circuit、Driver、EBI...


-------------------------------------
2010.12.20
-------------------------------------
Driver裡的read , write函式
write(struct file *filp, const char *buff, size_t count, loff_t *offp)
read(struct file *filp, char *buff, size_t count, loff_t *offp)
其中count可以拿到使用者API要存取的總size大小 bytes
例:
fwrite(DataBuf , size , cnt , fd);
則driver裡收到的count大小為 size * cnt (單位bytes)

並且測試後發現說fwrite(DataBuf , size , cnt , fd);
cnt並不能決定write(struct file *filp, const char *buff, size_t count, loff_t *offp)被呼叫的次數
是write()的return值決定呼叫次數
例:
fwrite(DataBuf , size=1 , cnt=10 , fd); //總共10 bytes資料要寫入
write(struct file *filp, const char *buff, size_t count, loff_t *offp)
{
...
return 5; //假設每次呼叫都只寫入5 bytes
}
則OS會去呼叫write()兩次來符合總大小10 bytes

因此做過一個測試就是故意讓write()只return 0;
發現write()函式會一直被呼叫

但是read(struct file *filp, char *buff, size_t count, loff_t *offp)
不論fread(DataBuf , size , cnt , fd); 的 size * cnt 值為多少
count的值始終是4096
在無法得知總bytes的情況下,我改成從FPGA上的PacketSize取得要讀取的總bytes

歸納一下目前做的
1. write(struct file *filp, const char *buff, size_t count, loff_t *offp)
a . OS會一直呼叫write()直到return value總合等於API要求的大小
b . 測試發現不能寫成只呼叫一次write()就把所有資料(比如10bytes)寫到FPGA電路上
假設呼叫write()一次,寫8 bytes,則只有前2 bytes被寫出去
所以後來寫成每次呼叫只寫2 bytes
c . blocking , 直到寫完API要求的大小才停止

2. read(struct file *filp, const char *buff, size_t count, loff_t *offp)
a . OS同樣會一直呼叫read()直到return value總合等於API要求的大小
但是在return value總和還沒達到API要求的大小時 , 出現return 0
則OS不會再繼續呼叫read()並且fread()的return size為目前的總bytes(不一定等於API要求的大
小)
但是write()並不會因為有return 0出現,OS就停止呼叫write()
而是會繼續呼叫write()直到return值符合為止
b . read()可以一次呼叫就把所有的資料讀進來
假設呼叫read()一次,讀10 bytes,可以正常讀取
因此read()我實作成呼叫一次就讀完8 bytes(看API層要求的大小決定)資料
c . blocking , 直到讀完API要求的大小才停止

但是寫完上述的driver function
發現在每次讀寫memory前,必須先去檢查PacketSize的值的動作會有錯誤
(PacketSize就是記錄目前這塊memory裡面有多少bytes的資料)
原因是因為driver command延遲的問題
driver呼叫write()後memory bus應該要馬上有訊號發出
但是mini2440的卻會延遲直到read()被呼叫後memory bus才發出write()的訊號
但是write()的實作動作為 , 寫memory前要先檢查PacketSize是否為0
否則就要block , 等待PacketSize = 0時才可以做寫入的動作
但是延遲的關係 , 當下抓到的PacketSize值並不是memory bus有動作所抓到的值
例:
fwrite(); //block在迴圈裡 一直檢察PacketSize
fread(); //memory bus的訊號發出write()的訊號
如上 PacketSize的值並不是實際電路上的PacketSize值
而且也無法抓到 因為block住的關係 fread()無法被呼叫

同樣read()也有此問題


-------------------------------------
2010.12.13
-------------------------------------
跟楊老師實驗室借了兩條USB轉RS232,目前可以看到同時執行的過程
所以直接開始改driver,把傳輸的protocal寫在driver裡面
以及實做Send()和Receive()兩個API函式 作為之後SPCI使用的傳輸函式

目前driver的write function可以正常執行
但是read function從OS收到的傳輸byte數的值還有問題 還在找是什麼原因

另外還有發現先前memory bus的address 0不能用的問題
並不是不能用 是因為bus沒有byte enable的控制
因此一次傳輸一定是2 bytes的data （16 bit)
因此要寫奇數的address時,bus會從address-1 寫16 bits

然而那時後的誤認,把address先往左shift 1位 (乘2)
然後在電路裡面再取addr[6:1]來使用
讓原本是byte addressing的mini2440變成是word addressing
如下所示

原先：
11111111 0x00
11111111 0x01
11111111 0x02
11111111 0x03

*2後,並且只取addr[6:1]作為address：
11111111 11111111 0x00
11111111 11111111 0x01

目前就先不修改這部份




-------------------------------------
2010.12.02
-------------------------------------
測試過後發現是V4 FPGA的 GPIO有問題 (J2.8 botton )
J2.8 botton剛好接到friendly arm2的CS pin
目前把ARM2移到J1 botton的位置
目前三顆可以正常存取FPGA上的memory

接下來會開始測大量資料的傳輸

-------------------------------------
2010.11.28
-------------------------------------
兩顆friendly arm接上fpga的GPIO了
兩顆分別測試存取InterConnect的ram可以正常存取
但是還沒有測同時跑的狀況 , 因為只PC有一條com port...
我會再寫個java層的ap去call linux driver
直接在LCD上操作來測試兩顆ARM同時跑的情況
沒問題就繼續接第三顆


-------------------------------------
2010.11.25
-------------------------------------
因為在連續讀取多筆資料時產生錯誤
後來實際去看邏輯分析儀發現讀取多筆資料時
每次的讀取訊號之間會夾雜一個單一的CS和OE的low trigger
如圖所示 : 這是連續讀兩筆的訊號







紅色框圈出來的就是夾雜的訊號
紅色框的部分系統總線給的address並不是driver所下的address
並且在這段時間任意給系統總線data值也不會影響driver實際讀到的值

實際在測時發現紅色框的訊號有時不會出現= ="
原因不明...

因此我的fifo的架構抓不準何時該讀出資料
若要解決需要改很滿多地方...
後來就還是換回用ram當儲存空間的InterConnect circuit
arm與arm之間交換資料的ram的大小為 16bit data , 0~4 address


-------------------------------------
2010.11.09
-------------------------------------
測試我的InterConnect circuit正確性
InterConnect circuit的memory用的是Xilinx ip gen產生的fifo (16bit data , 0~1024 address)
目前可以正常執行單筆資料(16bit data)的讀和寫
(friendly arm以word address來看,單一address有16bit的資料)

memory map的部分又有再更動 , 因為Friendly arm的系統總線提供的address pin
LADDR24 – not continue
LADDR0 - specific capability 要使用的話必須再去更改driver的設定 詳細我沒有去探究
總之就只剩LADDR1~LADDR6 可以用 因此調整packet size從2個word改成1個word
(1 word = 16 bit)


說明一下系統總線的存取memory的時脈波形圖
以SMIMS USB在使用的APP_CLK (48Hz)為InterConnect circuit的clk

Write :









當CS和WE為low trigger時
大約在第四個clock 系統總線Data和Address Pin的值才會開始是正確的
因此我的做法是在第四個clock去抓正確的address和data
第五個clock才把我電路fifo的write enable拉起來寫入值

Read :









當CS和OE為low trigger時
大約在第五個clock 必須把正確的data值給系統總線讀取
因此我的做法是在第三個clock去抓要讀取的address 並且把fifo的read enable拉起來
讓fifo能夠在第四個clock讀出值並在第五個clock把值給系統總線

要注意的是系統總線發出的單筆16bit的read訊號會有兩個low trigger
原先北翰的範例使用ram當儲存空間時,這兩個low trigger的讀取並不會改變ram裡面的值
但是我的InterConnect是使用fifo,因此再遇到這兩個low trigger時會讀出連續兩個address的值
並且由於是fifo,讀出的資料便會從fifo消失 因此會有問題

我的解決辦法是只再第一個low trigger時才去讀取fifo的值
並且把讀出來的值存再flip flop中維持兩個low trigger的時間
(因為兩個low trigger都要提供系統總線一樣的值,否則friendly arm讀到的值會不完整)


電路圖因為放上來有點模糊
參考投影片的82,83頁


-------------------------------------
2010.10.27
-------------------------------------
成功把北翰公司提供的範例跑起來了

範例是Friendly ARM透過系統總線(com)以排線與Xilinx V4 FPGA版的GPIO相接
fpga上的電路組成是一個state machine與一塊的 ram(16bit data , 10 bit address)
不過因為系統總線的address pin只能夠使用6 bit,因此fpga上的memory只有使用address;0~63
Friendly ARM上boot android並且在linux kernel新增driver來存取fpga上的ram
此外還有bcb實作的ui可以透過usb顯示fpga上ram的每個address的值
但是此ui在執行open實會將範例電路的bit檔燒進fpga,我又懶的再去裝bcb去改code後來就直接在friednly arm上呼叫driver去驗證ram上的值是否正確

範例發現三個問題:
1. 讀取memory的值時一些address會讀到不是我剛剛寫入的值
已解決--->因為read的時脈沒有對準,以APP_CLK為基準大約在第四個clock,friendly arm才會讀取ram的值

2. CS、OE、WE會有雜訊出現
減少雜訊--->用一個clock generator產生一個較快的時脈去過濾訊號,讓雜訊持續的時間不到一個clock

3. 對driver下的read和write指令會延遲到下一個指令系統總線才會發出訊號
比如說下兩個指令
fwrite(Buffer , 1 , DataSize , fp);
fread(...);
則在fwrite當下 系統總線並不會發出寫入ram的訊號
此訊號會在fread當下才發出
而fread的訊號只會在fwrite之後才會發出
像這個例子就是會在fread時系統總線連續發出兩個指令 : 寫入 讀取

而當連續下fread指令時只有第一個接在fwrite後的fread系統總現有讀取訊號發出
如: fwrite fread fread fread... 只有第一個fread的訊號有效

找不到原因 因此在使用driver時必須讓read write交錯呼叫才能正常運作


-------------------------------------
2010.06.18
-------------------------------------
完成SystemC model與四個Qemu相接的模擬器
其架構圖如下


















使用宗胤學長修改的android QEMU
其QEMU能透過driver去存取PC上的Posix Shared Memory
利用此功能,我再寫了四個wrapper SystemC model負責把Shared Memory的資料傳給InterConndet Module以及把InterConndet Module要丟給QEMU的資料寫入到Shared Memory

實作兩個傳輸使用的C++ API :
Void Multi_ARM_Send(int CoreID , char* Buf , int DataSize);
CoreID : 目的地ARM的ID
Buf : Data buffer
DataSize : 欲傳輸的資料大小( bytes )

Int Multi_ARM_Receive(int SourceID , int Total_Size);
SourceID : 來源ARM的ID
Total_Size : 欲接收的資料大小( bytes ) ,必須收滿Total_Size此函式才會return
Return int : 實際接收的資料大小 ( bytes )

上述兩個API會去呼叫底層的driver完成傳輸的動作
若fpga上的傳輸空間尚有資料無法寫入或者沒有資料可以讀取------------(a)
此兩個api便會以blocking的方式等待,直到空間空出來
不過後來跟張老師LAB討論過之後這兩個API會拿掉,把傳輸的動作移到driver裡
並且若發生(a)的狀況,直接return 不等待 回傳實際寫入、讀取的資料大小
以(a)的狀況而言回傳的值為 0


-------------------------------------
2010.06.02
-------------------------------------
因為考慮到每顆ARM只有接Addr、Data、control signal到傳輸會用到的Sram上
整個memory map的大小是16KB,但是實際可以存取的只有7KB
我想把空下來沒用到的memory map拿掉

比如說
Arm0所能看到的memory map 為0x4000~0x7FFF
但是Arm0實際硬體有接線的addr為
0x4000~0x4FFF : 4KB
0x5000~0x53FF : 1KB
0x6000~0x63FF : 1KB
0x7000~0x73FF : 1KB
其它硬體沒有接線的addr且Driver必須限制不能存取的addr共有9KB

我的想法是既然只有接線到部分的sram
那沒接線的sram就不要配入Memory map裡面
所以讓每個Arm看到的Memory map都一樣而且只有8KB
比如說
Arm0所能看到的memory map 為0x1000~0x2FFF,共有8KB
[只能Write的部分]
0x1000~0x13FF :　要傳給Arm0的資料 (1KB)
0x1400~0x17FF :　要傳給Arm1的資料 (1KB)
0x1800~0x1BFF :　要傳給Arm2的資料 (1KB)
0x1C00~0x1FFF :　要傳給Arm3的資料 (1KB)

[只能Read的部分]
0x2000~0x23FF :　收來自Arm0的資料 (1KB)
0x2400~0x27FF :　收來自Arm1的資料 (1KB)
0x2800~0x2BFF :　收來自Arm2的資料 (1KB)
0x2C00~0x2FFF :　收來自Arm3的資料 (1KB)

其中0x1000~0x13FF、0x2000~0x23FF對Arm0的實際硬體來說是同一塊Sram
如下圖所示




這張圖是Arm0的memory map所對應的實際硬體
每個長方型都是一個實體的sram
裡面的兩個數字是 起始Addr 與 結束Addr
有數字的部分就是Arm0實際有接線的sram
其中左上角那塊有重複的Addr (0x1000~0x13FF 和 0x2000~0x2FF)
因為這塊是屬於Arm0丟資料給Arm0的區塊
這部分我希望直接在Driver中做判斷,假如是要丟資料給本身
即不經過硬體做資料交換,直接丟給Arm0的local memory
然後發個Interrupt告訴自己有資料進入



下面這張圖則是Arm1的memory map實際對應的硬體
Arm1同樣的也是看到8KB的Memory Map且Memory Map跟其他Arm都一樣
只是接到不同的實體Sram
[只能Write的部分]
0x1000~0x13FF :　要傳給Arm0的資料 (1KB)
0x1400~0x17FF :　要傳給Arm1的資料 (1KB)
0x1800~0x1BFF :　要傳給Arm2的資料 (1KB)
0x1C00~0x1FFF :　要傳給Arm3的資料 (1KB)

[只能Read的部分]
0x2000~0x23FF :　收來自Arm0的資料 (1KB)
0x2400~0x27FF :　收來自Arm1的資料 (1KB)
0x2800~0x2BFF :　收來自Arm2的資料 (1KB)
0x2C00~0x2FFF :　收來自Arm3的資料 (1KB)
同樣的也是會有一塊Sram是屬於丟資料給自身的部分
也就是0x1400~0x17FF、0x2400~0x27FF






下圖是Arm2的Memory對應到的實際Sram
同樣的也是會有一塊Sram是屬於丟資料給自身的部分
也就是0x1800~0x1BFF、0x2800~0x2BFF




下圖是Arm3的Memory對應到的實際Sram
同樣的也是會有一塊Sram是屬於丟資料給自身的部分
也就是0x1C00~0x1FFF 、0x2C00~0x2FFF





而上面四張圖合起來就是整個實際16塊Sram的架構
也就是說每顆Arm所能看到的Memory Map都一樣
但不一定接線到相同的實際Sram上

這樣一來Memory Map就只有8KB的大小
不會有Access到不屬於傳輸所允許的Addr
只需要判斷Addr是否在這8KB的範圍內

目前正在進行的工作:
1.SystemC model與四個Qemu相接(給張老師LAB測試修改的MPI)

2.Friendly Arm(mini2440)與FPGA(v4)相接

3.如果確定架構沒問題就開始寫Verilog



------------------------------------
2010.05.19
-------------------------------------
由於後來發現S5PC100的SRAM Controller最多只能控制6塊SRAM
所以後來把FPGA上的16塊SRAM改成四塊
第1塊SRAM (最上方) 是儲存Arm0要Send給其他Arm的資料
第2塊SRAM (下一塊) 是儲存Arm1要Send給其他Arm的資料
....以此類推


每一塊SRAM的第0KB~(1KB-1bit)的資料是儲存Arm0要Receive來自其他Arm的資料
每一塊SRAM的第1KB~(2KB-1bit)的資料是儲存Arm1要Receive來自其他Arm的資料
...以此類推

即是比照之前的Memory Map,只把之前16塊SRAM的每一個橫排併起來成一塊

















但是這樣的架構會在多個Arm同時Read同一塊Memory時出問題
之前會切成16塊SRAM就是為了解決同時Read Write的問題


後來品皓有個點子,如果讓Arm以為只有4塊SRAM
但是實際電路上是有16塊SRAM這樣或許可以維持原來的16塊的架構
而且原本是預計每顆Arm都可以Access到這16塊SRAM
但是這樣每個Arm就都必須拉線到16個SRAM上這樣之後Layou可能面積會很大
所以打算每個Arm都只拉線到傳輸會用到的SRAM上
但是Arm本身的Memory Map還是會保留沒有用到的Address

所以就改成以下架構:























1. Tag的更動
由於Xillinx V4的Block Memory支援Dual port(Write的同時也可Read)
所以原本用來仲裁"Write的同時是否可Read"的Tag就不需要了(原本有定memory map且用register實做)
原本Tag還有紀錄SRAM中的Data Size的功能和做為判斷SRAM是否有資料,來控制Read/Write是否允許
所以改成每個SRAM的起始4Byte作為儲存Data Size的空間,取代原本的Tag

然後Tag也作為是否該發出Interrupt通知Arm來讀取資料的依據
現在改為用Adddr以及Data值來判斷(假如Addr為Data Size的位址且Data不為0則發出Interrupt)

2. 只接線到傳輸相關的SRAM
如上圖所示
Arm0只接線到第一欄和第一列
然後透過Addr某幾個bit和CSn作為SRAM Enable的依據
這樣即使Arm0的程式寫資料到不正確的Addr
在實際電路上依然會寫在第一欄和第一列的範圍內

3. 實際有16塊SRAM,但每顆Arm以為只有1塊
Arm的SRAM controller會接出CS[0:5]做為每塊SRAM的Enable
以Arm0的觀點來看只有一顆SRAM
所以CS只會用到CS0

透過判斷Addr線、Write Enable、Output Enable , 連到不同的SRAM上

4. Initial Tag

因為本來儲存Size的Tag換成在SRAM中(原本是Register),因此需要初始化
所以我希望在每顆Arm boot好OS之後必須去把Size初始化為0
每顆Arm各自去把儲存Send資料的SRAM的Size部分歸零,然後才把Initial Tag設為1
再確認每個Initial Tag皆為1後才開始進行資料傳輸

[這邊有個問題]
就是每次Send資料時都需要去確認Initial Tag嗎?
如果確認Initial Tag是為了要確定目的Arm是否存活
但是一顆無法執行的Arm,無法去修改對應的Initial Tag,就無法判斷目的Arm是否仍然存活



------------------------------------
2010.04.07
-------------------------------------
之前定的memory map
因為要把儲存資料大小的單位換成byte比較直覺
所以重訂了一下Tag的部分(Packet Size)






Initial : 每個欄位1byte







Packet Size : 每個欄位4byte























Memory Space(Receive data from Arm) : 每個欄位 1 K byte






















-------------------------------------
2010.03.29
-------------------------------------
原本為了方便替EBI BUS加Driver
就把MVC100重新PO上linux

後來板子先借給文森學長
要先測山寨機的Android AP能不能在MVC100上跑
所以我又重PO了Android上去

可是新PO的Android螢幕左下角還是一樣會顯示Safe mode
不知道是廠商提供的Android kernel本來就是safe mode,要自己另外抓
還是其它問題,目前還在找




-------------------------------------
2010.03.11
-------------------------------------
Memory Map的部分暫定如下
Initial有四個byte 0x00~0x03分別用來儲存四個Arm是否initial完成
Tag To ArmX為就是架構圖裡面的16個Tag紅色區塊
ArmX Receive為架構圖中 , 每個Arm底下的四塊Memory

































































































-------------------------------------
2010.03.09
-------------------------------------
目的在於把四顆Arm透過FPGA上的Memory來進行溝通

1 . 架構

[架構圖]















如架構圖所示,每個Arm透過Memory Bus連接FPGA上的16塊memory
透過這16塊memory進行Arm之間的資料溝通
每個Arm下方的四塊memory是用來接收來自其它Arm的資料
比如Arm0下方的四塊memory , From Arm2這塊memory即是用來儲存來自Arm2的資料

每個Arm都可以看到這16塊Memory以及其Tag

每塊memory的總大小為1k byte , 且各自有一塊專屬的Tag , 用來紀錄儲存在此memory中的資料大小 , 而當memory中沒有資料時 , Tag儲存的資料大小為0

Initial Tag為一個大小為1 byte的register , 共有四塊 , 用來記錄四個Arm的initial是否完成
而當四塊Initial Tag的直接為initial完成時 , 才能進行Arm之間的資料傳輸
每個Arm都可以存取到這四塊Initial Tag


2 . 傳輸方式

假如Arm0希望丟一筆資料到Arm1
Arm0必須先將資料丟到FPGA上Arm1底下的From Arm0的那塊memory
然後將From Arm0的Tag設為資料的大小
此時FPGA送出Interrupt訊號給Arm1 , 告知有資料進入memory中
Arm1再主動去FPGA中抓取來自Arm0的資料


3 . boot

單顆Arm的boot動作為:
Arm裡面有個Rom , 儲存一小支程式 , 這個小程式會去抓Flash的前幾個byte看看是否Flash中有合法的可執行程式 , 如果有的話就會把Flash中的資料抓進SDRAM中 , 然後Arm在去執行SDRAM中的程式 , 如果Flash中沒有程式 , Rom中的小程式變會換成等待USB傳送PC端的資料過來 , 然後將接收到的程式分入SDRAM中讓Arm去執行

但是這樣會有個疑問就是說 , 如果四個Arm只有第一顆Arm有Flash , 那其它三顆Arm的SDRAM該如何拿到boot所需的程式?


4 . initial

當四個Arm確定都boot完成後 , 便要開始去initial FPGA上每塊Memory的Tag , 每個Arm各自去initial對應的memory的Tag , initial完成後便將對應的Initial Tag值設為1 , 直到四塊Initial Tag全部的值皆為1時 , 才能開始進行資料傳輸


5 . Memory Bus

Memory Bus有三種訊號要輸入Address , Data , Control Signal


6. Arm資料傳輸Function

Receive(int SrcCoreID , int* Buf) : 用來接收來自SrcCoreID 的資料 , 用sc_event來等待interrupt
Send(int DesCoreID , int* Buf) : 傳送資料給DesCoreID


7. 目前工作

a. 定出每塊Arm的memory map
b. 完成SystemC model
張貼者： 於 16 則留言:
標籤： , ,
訂閱： 文章 (Atom)