2009年5月1日 星期五

老師生日快樂

今天中午跟塞公去買了巴肥特推薦的"克林姆之宮"的千層蛋糕。 本來一進門要唱生日快樂歌的,大家實在是鳥掉了... 一群大男生還會拍謝...
加油,好嗎?


老師吹蠟燭~
老師切蛋糕 (老師彷彿知道我們有準備special的,今天穿的特別煙斗~)

老師交待小新要帶學妹做壓縮的部份,小新聽到要負責帶學妹開心的笑了~ 各位看官看小新比當壽星的老師還開心 !!!(疑,什麼是smallnew+呀?)


粗糙相機,當然沒有aaa的大炮好,照的不好請大家包涵啦 :D

8051 core - 品皓

====================6/15===========================
整個8051的debugging分成target 8051的debugging stub和host gdb for 8051兩端。
target端這邊,aaa把8051和rs232等電路都焊好了給我,用來download測試程式和debugging stub。目前是先從stub改起,正在參考gdb的範例sparc-stub和aaa之前做的stub。
host端,bbb覺得我對cross compile gdb不夠了解,所以建議我可以先看看現有的範例arm-elf-gdb怎麼編譯出來的。

====================6/02===========================
先大略了解gdb remote debug的部分,還有劃出gdb和8051的架構圖,
debugging stub的位子等。
投影片
====================5/22===========================
與bbb討論了一下關於gdb,gbd debug stub部分可以找aaa拿,
可是目前的gdb好像沒有支援對8051的debug功能。
我目前還在google這方面的問題,可能還要在找老師討論一下...
====================5/15===========================
目前在FPGA上塞入四顆8051 core,放在gary的bus上執行正確。

之前放在gary bus上出現的錯誤,簡單說是initial板子的問題。
因為我是修改以前bus與altera板子連接的程式,altera當時是一個版子一個8051 core,所以如果接兩個8051 core就需要set up兩個板子。當初是包在8051 class的初始化裡面,bus呼叫兩個core就initialize兩個8051,給個index變數判斷其差別。
然而現在xilinx上是一個版子有多個8051 core,只需set up板子一次,所以最後我是用if else去強制讓set up板子的動作只執行一次,改好後可順利執行,只是這方法不太好,我還在和宗胤討論怎麼改。
====================5/12===========================
目前我在FPGA上塞了兩顆8051 core,自己對任一顆做測試結果是正確的,
但是放到gary的bus上卻會出現錯誤,我目前還在找尋原因。

另外,之前關於降低選擇器的複雜度,老師希望能有選擇器 set up time 的數據。
投影片
====================5/05===========================
單顆8051 core已經與gary的bus接起來且執行正確。
====================5/03===========================
終於找到問題了,是8051 c code寫錯了
因為DCT的C程式中會對input data array的pointer作變動,而執行完後等待下筆DCT input data時沒有更新那pointer,導致第二次執行DCT時資料會算錯,然而reset卻又會正確的的情況。
把這問題解決後,DCT已經可以正常運作了。

接下來就是準備和gary的bus接起來。
====================4/27===========================
上禮拜訊號不穩的問題有了另一解,就是降低選擇器的複雜度。
interface在回傳數值的output port前會有一個選擇器,選擇取哪一個memory(ROM, RAM, xRAM)的output作為回傳的數值,降低其複雜度就可以了。

目前DCT程式可以部分正常運作。每處理一筆8x8的data完後,必須reset才可以處理下一筆。
不確定原因,還在debug。
====================4/20===========================
之前memory的資料可以寫入並讀出來,但是總是有部分讀取的數值錯誤,花了不少時間在處理這問題,因為不清楚是寫入時出問題還是讀取時出問題, 加上合成硬體很花時間,讓我debug速度變得好慢...

最後才發現是 xilinx memory的問題,利用xilinx core gen產生的memory,input options原本我是設定成non registered,這會造成write data時memory寫入的data不穩定,之後改成 registered就解決了部份讀取數值錯誤的問題了。

只是因此又多一個問題,input registered會造成讀取data delay一個cycle,也就是說input address後要等一個cycle才會output出對應的data。但是我的8051 core是設定成沒有那一個cycle delay的。

接下來要做的是處理8051 core因為memory delay而執行錯誤的問題。
====================4/12===========================
學長幫我看了一下架構,認為太複雜了
透過範例程式做修改,盡量不要動到其FSM和interface,也盡量不要修改到原本的控制訊號。

我將架構稍作修改後,目前可以將資料寫到memory並且讀出來。
接下來是測試P51的控制。====================4/11===========================
verilog code是寫好了,只是PC端要求回傳數據完全錯誤...。
我目前正在寫test bench,希望到時能由波形圖看出問題,不然我也不知道哪裡出問題。
====================4/6============================
這禮拜主要是熟析xilinx的FPGA和版子與PC端的溝通方式,還有修改我system controller的架構

原本的system controller,也就是altera的版子,是用一個function call與版子溝通,主要參數是兩個array (read data和write data) 和一個cycle數。
array的每一筆data都是按照cycle數的先後排列,write data array的第一筆data就是第一cycle時FPGA的data input,第二筆data就是第二cycle時FPGA的data input,之後以此類推。
read data array則是FPGA的data output,和write data一樣的方式排列。

現在的xilinx版子,是用多個function call對兩個FIFO讀寫,版子再從FIFO取值或者寫入。
PC端與版子的溝通訊號比較複雜,但由於有一個簡單的範例介面,所以我打算用那範例與system controller相接。
====================3/31============================
速度卡在FPGA的原因: 是一個DCT處理需要大約400k的cycle數跑完,
但是function call的限制是一次只能跑大約300 cycle就必須回傳給PC,
我目前設定是一個function call跑256 cycle,呼叫1700次,
這樣會造成時間全浪費在PC與FPGA的溝通上。

由於這是API的限制,所以後來學長給了我另一個FPGA和API就不會有這限制。
為了能使用新的API,目前正在改寫我的verilog code和PC端的程式。
====================3/30============================
目前整個jpeg encoder跑起來的結果是正確的,不過速度全卡在FPGA上,
一個200X200的圖需要大約30分鐘才能跑完。
增加FPGA數量其實並不能加速,因為systemC是單執行緒,所以多個FPGA也不能同時執行。

我接下來的工作主要有三個:
用systemC寫出8051的module,能在openESL上執行。
8051的toolchain,C program可以從keil直接到FPGA上。
Debugging的功能,尤其是能在FPGA上處理單步執行的能力。

其中對於toolchain,我說明一下我目前DCT是怎麼做的。
首先C code要經由keil的C51 compiler處理,需要對變數的宣告作修改
由於我是用xRAM作為share memory,所以讀取的input和計算的結果都必須指定其位值。
譬如將 short datain [64]; 宣告在type = xRAM的address = 0x10作為起始位值,
寫法就須改成absolute memory location的格式:
short xdata datain[64] _at_ 0x10;
如果不指定type和address,則由compiler和linker分配
無論是自己指定或者compiler分配,都可以在output file的Symbol Listing看到。

接下來是程式大小的問題,原本沒任何optimization,我的程式大約3k byte。
由於FPGA的memory大小和試用版的keil有其限制,在compiler設定上選擇適當的optimization
我把程式壓到小於2k byte。

最後compile後產生的output files,我是選擇用hex file作為下載到FPGA的input code,
因為hex的格式比binary還好理解。
hex file更進一步說明是Intel HEX file format,格式為
:llaaaatt[dd...]cc
: Intel HEX record的開頭.
ll 表示這行記錄了多少byte的data(dd).
aaaa 開始的address
tt HEX record type,我只知道00表示data record,01表示end-of-file
dd 就是程式碼了
cc checksum,將這行所有hex number,兩兩一組相加/256。
舉個例子 :10246200464C5549442050524F46494C4500464C33
表示有0x10 byte的data,data我用綠色的標起來了,
起是位值2462,是為data record,checksum = 33。

有了data和其相對應的address,就可以下載到FPGA了。
====================3/26============================
主要在與Gary的配合,和FPGA的記憶體的限制問題。
目前看來Gary的bus和FPGA的溝通沒問題。
至於FPGA的記憶體的限制問題,首先說明一下我目前8051的記憶體配置,
iRAM + SFR = 256*8 bit
ROM = 4096*8 bit (12 bit address)
xRAM = 1024*8 bit (10 bit address)
根據quartus編譯的結果,在FPGA上 total memory bit = 43,008 / 92,160 (47%)
之前這樣DCT程式就夠用了,xRAM也可以不用這麼大,可是如果要符合8051的規格,ROM和xRAM都需要65536*8 bit,很明顯FPGA一定不夠,所以目前就先維持這樣。

至於能不能在FPGA塞下兩個這樣restricked的P51,目前看起來好像可以,
total logic element 46%, total pins 40%, 所以我正在試。

====================3/22============================
關於ACALL指令執行後位子多跳了兩個,我對FSM做了修改。
我修改成PC晚一個ins cycle跳去ACALL的位值,也就是將conj這控制訊號晚一個ins cycle送出。
由於上傳波形圖會糊掉,所以更詳細一點的說明,我有舉範例在投影片裡。

目前跟Gary的TLM bus接起來結果正確,不過也只測試過一組資料。
我會在星期一和Gary多測試幾組。


====================3/17============================
老師點出我兩個處理方法並不正確,首先ACALL那邊,branch到的位值是正確的, 但是經過兩個ins cycle後(因為ACALL需要2 ins cycle)卻改變了。
不可直接對更新PC的地方做修正,因為branch到的位值是正確的。

第二是ALU carry,不應該多設一個暫存器,而是想辦法讓carry在正確的T時間計算。

開完會後的下午,我將ALU的carry問題修改了一下。
原本T=0時controller還沒設定ALU input,ALU就開始動作,計算出錯誤的carry,
同時也送出錯誤的ALU output,只是controller將他檔住。
我的作法是將ALU carry改的和ALU output一樣,只有在T=5的時候才會接收,
其他時間則擋住。

另一個問題是為什麼ModelSim模擬是正確的,然而下載到FPGA跑出的結果卻是錯誤的?
我將FPGA跑出的錯誤資料作紀錄,總覺得似曾相似......
才發現原來我verilog code弄錯版本了,拿成未修改的verilog code去下載到FPGA。

改完後,目前在FPGA板子上已經可以正常執行了,測試了幾個數據都正確。
====================3/13============================
這幾個禮拜主要是將DCT的C code,透過Keil轉成 8051 assemble code,放到FPGA上。
pre-sim階段,透過Keil debugger支援的單步執行,觀察wave的訊號。

這階段遇到的8051 Bug主要有兩個
一個是ACALL執行後位子多跳了兩個,目前的處理方法就是在更新PC的地方多加個-2。

第二個是ALU計算carry值的問題 ,在不正確的T值計算出carry。
T=0時controller還沒設定ALU input就開始動作,計算出錯誤的carry值用於T=4。
目前處理方法是多設了一個暫存器紀錄控制訊號送達ALU前的carry,用於T=4。

這兩個問題處理完後,pre-sim目前DCT測試結果正確。