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