2009年5月1日 星期五

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測試結果正確。

19 則留言:

SCREAMLab 提到...

感謝!

我說的, 這個blog是記錄你所做過的事的軌跡, 很重要.

請把你的title裡的"進度報告"拿掉吧! 以後這不必要. 讓Title speaks for itself.

另外, 你是說, 用daphne的8051 RTL, 在modelsim裡run DCT是對了嗎?

SCREAMLab 提到...

請開 一個CPU的類別, 以後 RISC32也可以加進來, 過一陣子我再請學長把DSP放過來.

此外你之前Multiple 8051也可以.

匿名 提到...

品皓, 怎麼覺得你的解法是治標不治本?
這樣會不會改到最後整個8051都怪怪的?

SCREAMLab 提到...

學長說得好, 是我的疏忽, 沒仔細看你的report.

你要不要檢查一下學姐那裡沒做對, 把它改好, 然後給她知道.

SCREAMLab 提到...

第一個問題.

這是學姐在計算New PC時錯了嗎? 為甚麼錯呢? 你這樣改了後, 會影響到PC的正常運作以及其他branch指令嗎? 可以跟學姐溝通一下嗎?

第二個問題.

假如是學姐在計算carry時錯了, 那麼是真算錯呢? 還是在不對的T cycle計算呢? 還是在不對的T cycle時update呢? 假如是後兩者, 那麼應該在對的T cycle做對的動作才對, 也就是應該在FSM裡改. 可以也跟Daphne聯絡嗎?


再次說抱歉, 我沒盡到好好指導的責任. 學長講得很好, 替我把關, 我很感謝他. 希望你以後改掉過去頭痛醫頭的問題. 這樣你會進步快一點.

品皓 提到...

是的,改完那兩個問題後,在modelsim裡run DCT,我用了幾個測試數據,結果都是正確的。

至於carry那邊的修改方式,確實不太好。
本來這樣的修改方式只是方便印證我找到的問題是否是導致DCT算錯的原因之一,所以沒考慮到這麼遠。我之後會再想想怎麼修改。

SCREAMLab 提到...

感謝你的即時更新, 請這兩天提出你的改法再跟 Daphne討論一下, 下周前更新.

另外你忘了今天另一個主題, 那就是Modelsim對了, 可是上了FPGA卻錯了. Why? 我提供你兩個方向, 試一下, 一樣在試了之後上來更新.

品皓 提到...

關於FPGA方面,目前結果正確了。
之前錯誤的原因只是因為我下載錯誤的verilog code。
另外一個問題是,我接下來要做什麼?
是不是要把verilog code改寫成一個FPGA有兩個8051 core作DCT的運算?

SCREAMLab 提到...

請先跟Gary的TLM bus接起來到正確動作為止. 我晚上再上來講未來要做的工作.

謝謝!

SCREAMLab 提到...

Hi:

你可以把要為8051做的東西的項目做一次整理嗎? 這樣我可以逐條檢驗.

另外給我一個時間表吧!

此外, 不要忘了問電機系的同學有關GDB的做法, 這些功夫當初是AAA與BBB教他們的, 尤其是BBB, 現在趁BBB還在, 你多一個人問, 要不然就禮失求諸野了. 那很Orz的.

SCREAMLab 提到...

還是老話一句.

設法檢視與記錄出過的bug以及解決方式.

逼逼逼 提到...

我請品皓去survey有沒有porting好的8051 debugger,我認為8051是蠻general的case,應該是有現成的Open Source可以下載。還有請他看了GNU debugger spec其中一章節,了解一下remote debug。

因為我不太清楚老師想做什麼,所以我只能根據品皓給我的資訊跟他說該怎麼做。如果方向有錯還請老師和學長修正,免得白走了冤枉路。

SCREAMLab 提到...

我的用意是讓學弟自己摸熟GDB, 當然有人家做好的來參考是很好, 不過他要自己會才可以. 我預計8051做完, 另外再做DSP16. DSP16應該就沒有現成的了, 所以要自己來.

匿名 提到...

你好:
能否將8051 core的Source code傳給我嗎?
jlian168@yahoo.com.tw

謝謝.

buffett 提到...

we don't provide source code of 8051 core.
It's not open-source.

SCREAMLab 提到...

Who is jlian168?

buffett 提到...

I don't know, but he asked for codes in many sites.

Zhong-Ho Chen 提到...

找東西居然找回到實驗室的Blog!

87showmin 提到...

XDD 不過blog report的風氣也只到品皓這屆了