Profile - TW083

TW083

具資料安全的電子閱讀器

Project Paper - view as Preliminary(2010/07/21), Final(2010/11/01), Draft, Latest

1. 設計介紹 (Preliminary Paper)

近年來嵌入式系統發展改變了人們的生活習慣，像是手機、平板電腦等手持裝置均整合許多功能，是嵌入式系統應用相當成熟的產品。也因上雲端技術的崛起，手持裝置可發展成網路的終端，大量的資源均可從遠端獲得，所以本專題實作具資料安全的電子閱讀器朝著整合多功能應用以及支援網路連線的能力開發。

我們的競賽題目為電子閱讀器，就是可將閱讀的資料存放在SD卡裡，而電子書的資料經過加密，可在閱讀時即時的做硬體解密處理，如此就可以達到資料的安全和製作權的保護。且作品定位成手持系統，是日常生活中的可攜裝置，但就如同手機的道理，若是可以外出隨身使用也增加遺失的風險，所以本專題的3DES硬體加密就能以防遺失所造成重要資料外洩。另外網路的通訊也可經過硬體的即時加密在送出，資料再傳送的途中即使被攔截也無法輕易得到明文資料，對於通訊介面作安全的防護。

而人機的互動我們朝向較友善的介面設計，選用觸控式的LCD增加其更直覺的輸入模式。我們將LCD Touch Panel作為電子書的輸入輸出裝置，操作時只需要去點選螢幕便可輕鬆使用，並加入螢幕觸控鍵盤來取代傳統的鍵盤輸入，並提供手寫塗鴉板作留言、畫圖或照片美功能(拍貼繪畫)等功能，此外也提供以觸控方式進行的照片小遊戲，和手寫辨識密碼的功能等多功能的設計可以使用。

系統規格中更值得一提的是開放性架構，客製化適合此設計的作業系統on FPGA，就可以使系統獲得相當多的資源，且上層的程式開發就更具移植性。作業系統的環境也更加適合多媒體的嵌入式系統應用，像是現在的android手機就是個Linux base的作業系統。如此也提供支援多元程式的環境，系統也更加有彈性(完整的檔案系統、TCP stack)和階層架構，如此開發就能更分工，效率更好。

而手持裝置的重要議題就是克服能量耗損和低發熱，所以我們客製化合適的硬體增加效率，並加入OS對各IO裝置作管理，尤其LCD螢幕的監控，可以用軟體來手動或自動的關閉LCD Controller和display的memory buffer降低電容的充放電，來達到省電的目的。

透過Altera  DE2-70平台的大邏輯數FPGA、充足的記憶體單元和完整的周邊，專案就成做到系統的最佳化，已符合嵌入式系統的低成本，低耗電且效率良好的訴求。

(Revision: 6 / 2010-09-17 21:40:50)

2. 功能描述 (Final Project Paper)

1. 將電子書(加密過的TXT文字檔)作資料解密，並將字型做放大或縮小到適合4.3吋的LCD輸出，並提供多組字形可自由變換。

2. 所有閱讀的電子書都以3DES 64bit-key 做加密的處理，來保護重要資料或版權，在閱讀時以本專題實作的triple DES(三組64bits的keys)加解密硬體，即時解密後在4.3吋的LCD Touch Panel閱讀。

3. 可將使用本專題實作的小鍵盤輸入文件，加密後儲存置SD卡中，使非本電子閱讀器無法看到真正的明文。

4. 使用者可以自由選擇是否加密SD卡內的資料

5. Ethernet網路通訊界面的傳輸透過3DES的即時硬體加解密來達防止資料傳輸過程遭攔截、竊取。

6. 利用觸控式螢幕提供更方便的使用者介面。

a.    用手指在觸控面板作翻頁的功能。

b.    螢幕顯示SD卡中可以閱讀的所有電子書，讓使用者觸控點選播放。

c.    可觸控電子書來話重點或做筆記的螢光筆功能。

d.    利用觸控螢幕提供螢幕的小鍵盤或互動按鍵使輸入更加直覺。

7. 提供塗鴉版的功能，可利用提供的調色盤變化各種顏色，使用者可以用觸控手寫的方式畫圖或寫字，且可將塗鴉的畫面儲存到SD卡中。

8. 提供小遊戲以觸控螢幕點選來進行：

將20張使用者的照片或原先設定的圖片顯示在LCD Touch Panel，遊戲倒數十秒後會將照片蓋上，玩家可利用觸控螢幕點選照片，找出兩兩相同的圖案，若成功找出所有10組(20張)照片後，系統會顯示勝利訊息。若找不出所有的照片也可點選放棄功能，系統會翻開所有的答案。

9. 提供大頭貼(拍貼)的功能，使用者可利用觸控螢幕在照片寫字、貼圖或畫邊框等美工編輯。系統提供多組美工圖片可以使用。

10.Porting OS for NIOSII on FPGA
使系統可以同時執行多項程式(multi-tasking)，並使用一個SD RAM當OS管理的主記體，程式編譯成可重新定位的執行檔，日後需要擴充其他的功能時，透過OS的記憶體管理和多元程式(multi-task)，在應用程式開發或移植時，程式效能與軟硬體成本上比較容易 Optimization。且多元程式的環境可讓使用者，可以同時執行多個程式功能，且隨時可以中斷或暫停某個功能。

11.以軟體控制LCD Controller，可讓自動或手動關閉Controller的畫面更新，使其不做資料搬移，減少電容的充放電，達到省電的功效。當使用者長時間沒有使用電子書，系統自動會關閉LCD的顯示，當有觸控到面板時再重新開啟LCD。並定可依使用者的習慣來調整自動關閉的時間。

(因為FPGA上無法中斷內部Controller的供電，所以裡用軟體使控制器reset，停止LCD顯示畫面更新，使記憶體不作充放電來節省能源)

12.可以使用ethernet連接網路，讓電子書可從遠端透過網路取得，如此系統能得到的資源也更加寬廣。

13.透過網路獲得即時的焦點新聞，使電子書取得最新的資訊。

14.讓電子書定時自動翻頁的功能。

15.可自動撥放使用者存放在SD卡裡的照片，並可自動偵測人臉部位作中新點位移的放大顯示。

16.系統可以將書籍做分類，將相同類型的書籍放置在同一個集合，讓使用使方便的找到想要看的書。

17.提供手寫辨識，確認使用者輸入的密碼。把使用者寫入的數字與設定的密碼作比對，如果密碼正確則可以登入系統或是開啟文件。

(Revision: 6 / 2010-09-17 21:41:56)

3. 效能參數 (Final Project Paper)

本專題各系統功能運作在uClinux OS之下，可支援多元程式平行運作，並提供檔案系統配置和TCP/IP的網路協定。

LTM LCD系統：

    工作時脈33MHz，輸出解析度為800*480*24bits，以SDRAM作display buffer，而一張800*480*24bits的顯示畫面便需要約1.5MB的資料量，所以在畫面資料的搬移需要暫掉相當大的bus頻寬，所以會佔用大量的bus cycle，而本專題實作的特點在於運行OS的多工處理的環境，所以CPU必須執行多種服務、IO的管理(例如網路)和核心程式。所以對於LTM IP的設計做了Bus domain的切割，讓資料交換時avalon bus的使用率降低，已確保CPU可取得高優先全來執行程式需要的大量記憶體存取，另外也模組化LCD的硬體元件使LTM可reuse。

原本大多數的顯示的Controller(ex: VGA Controller)在移植NIOS SPOC須依賴Master IP來提升畫面交換的效率，雖然不需CPU去做資料搬移，但如果以此架構做LTM的IP設計，會照成大量的Bus佔用率。LTM不斷向SDRAM取得畫面作更新時，就會占用CPU使用avalon bus頻寬，照成OS執行的順暢度下降，或LTM畫面的不穩定。

所以利用友晶提供的Multi Ports 的SDRAM contoller和LTM controller作整合，達到bus的切割，使得LTM的display buffer可以直接向SDRAM取得。換句話說，有一個SDRAM contoller並非屬於avalon bus下的元件，達到切割bus區域的效果。所以此SDRAM可看做是LTM內建的記憶體，後續可以將此控制器做更多影像演算的功能，而模組化後控制器便可自行最內建記憶體的SDRAM做存取，達到切割架構和解除Bus使用壅塞。

LTM IP的示意圖

LTM和SDRAM Chip 1的資料交換就透過紅色的internal bus，不會占用avalon bus的頻寬。

 

 

3DES CODE：

因為DES的演算法需要很大量的計算，必須耗費很多CPU的時間，而在低時脈的嵌入式系統中並不適合以軟體來跑此加解密複雜演算法的運算。且DES屬於區塊性的加密方法，很多步驟的演算都是重複的動作，所以用硬體的方式來做相當適合，同樣長度的資料在一個特定設計的硬體電路上完成，使得花費更短的cycle time就可以做完一段資料的加解密，且硬體的時間相當的精確，在即時處理較可掌握。CPU只需要把資料送進去給DES的硬體後，就可以執行其他的工作，等待DES運算出結果就好。則CPU的就可以用於執行OS和跑user interface和其他使用找程式。達到FPGA增加修改硬體的彈性，並整合CPU共同運作。

 

規格:

1.    使用三個KEY，提供高安全性資料保存

2.    KEY的SIZE：64bits

3.    加解密處理的DATA SIZE：64bits

4.    3DES平行快速的加解密處理

5.    支援加密和解密雙向的功能

6.    clock rate：100MHz

7.    加解密1.5MB的DATA約1秒，加解密檔案可作到real time的處理

 

SD Card:

    因為本專題以設計開放式的架構為前提，所以用SD卡作電子書和圖片的檔案來源可輕易的讓使用者作檔案的擴充和交換。而SD卡的讀取方式是採用ATLERA MMC SPI Controller，並在uClinux下驅動使用，使其成為OS下的一個I/O裝置，在透過OS下個檔案系統，抽象化了SD卡的使用方式。此時SD可便可以看作掛載在檔案系統下個目錄，應用程式不需要了解SD卡的結構和協定就可用FILE的檔案結構來是用SD卡。

目前使用SD作大量的檔案存取(例如取出一張1MB的照片)，測試約要數十秒的時間。主要瓶頸還是SD卡的結構和MMC Controller慢速裝置的因素，效率無法有大幅度的提升，所以目前以程式作分段的讀取和常用資料預先載入的動作來減少SD卡的讀取等待時間。

 

記憶體的使用：

    DE2-70上的記憶體算是相當足夠，LTM由於需要大量資料交換所以獨立使用一顆32MB的SDRAM，而執行OS核心和系統程式時就需要約4MB，且應用程式也必須跑在OS之上，所以分配另一顆32BM的SDRAM給OS作主記憶體使用，另外的2MB的SSRAM則作各系統可自由分配共享記憶體。DE2-70上的8MB FLASH可用於OS image的存放，因為FLASH為非揮發性的記憶體，斷電後仍可將存放在記憶體中，當power on就從FLSH作載入。

1.    SDRAM：32MB (for OS main memory)

2.    SDRAM-2：32MB(frame buffer for LTM Touch Panel LCD)

3.    SSRAM：2MB (各系統自行分配共享記憶體)

4.    FLASH：8MB　(存放 OS image)

5.    external：SD (存放使用者的電子書或圖片)

 

LTM LCD顯示器規格

1.    觸控式LCD

2.    大小為4.3吋

3.    buffer size：800*480 RGB

4.    全彩16777216 畫色(24bitsRGB)

 

Ethernet網路控制器規格

1.    使用DM9000A Controller

2.    工作時脈：up to 100MHz

3.    支援4-byte checksum

 

DE2-70之FPGA使用情形

Total logic elements	11,132/68,416(16%)
Total PLLs	3/4(75%)

目前CPU未加入成除法指令

 

Software 參數:

1.    OS kernel size為1.45MB，經解壓縮載入SD RAM約4MB

2.    函數庫為標準的C函式庫、glibc函式庫、uClinux的系統函式庫和使用者設計的3DES、LTM IP驅動程式。

3.    3DES的解密1MB的DATA約1秒，加解密檔案可作到即時處理

註：

軟體的系統各功能在OS下多工執行，CPU資源必須受OS的工作分配和工作環境有多少成式平行運行等因素，所以測試時間和pure machine code有所誤差。

 

 

(Revision: 3 / 2010-09-17 23:09:03)

4. 設計架構 (Preliminary Paper)

一、   硬體架構

1.  以NIOSII CPU來執行uClinux和應用程式，為主要的master元件。

2.  LTM LCD system主要以LCD controller和Touch panel controller組成，LCD controller主動在SDRAM的buffer中存取欲顯示的畫面，Touch panel controller會取的外部的觸控訊號，將相對做標回傳給系統，再透過CPU做對應處理。

3.  電子書以CPU將資料轉換成BMP資料寫入SDRAM的顯示buffer，則LCD controller會主動去抓取顯示畫面。

4.  加入DES(data encryption standard)硬體元件作資料的加解密，CPU會送欲解密的資料和三把64bits的金鑰給DES元件，DES元件做完指定的資料解密再存到資料的buffer。利用此方法可以將一連串的XOR和資料重新排列法則以硬體方式實現，此外還可以引入管線化的概念，如此可以提升加解密複雜的演算法速度達到即時解密的效果，且可有效的利用FPGA的可程式化單元和設計彈性。

5.  使用ALTERAavalonMMC SPI元件來做SD卡的Controller來改善以PIO的方式連接SD scoket的效率。

6.  以DM9000A Controller來連接Ethernet MAC Chip，其工作時脈為100MHz，提供連接到網際網路的溝通管道，以OS建構TCP Stack來開起聯外的socket，使系統擁有網路通訊的功能。

7.  使用Avalon Memory-Mapped Bridges的元件使架構更加清晰，且切割出address map的區域及較慢的IO元件，使avalon_bus上不需要所有連接原件都有master和slave的controller，使邏輯閘數量降低。並且簡化FPGA的routing使整體fmax可以提升。

目前的架構圖

1.  主要架構可由上圖看出，系統由SOPC產生的硬體燒入至FPGA後，往上層再建構作業系統，使用者的應用程式則建構在各硬體元件的驅動程式之上。次外，以此軟硬體階層式架構，我們從硬體支援至軟體之間的關係做整合客製化，上層應用也透過OS做系統呼叫、裝置驅動以及TCP stack的分層做開發的分工。

2.  應用OS的IO管理，在硬體裝置的管理也更加強化，像是SD卡、UART或網卡的控制，雖然在FPGA上無法直接關閉某個硬體區塊的電源，但以作業系統的觀點便可關閉各層級硬體，達到省電的功效。

軟體架構

DES也為區塊性的解密的演算法，所以就可以使電子書閱讀的系統做軟體上的管線執行，如果是大量資料的處理加快效能，而以電子書或一張800*480*24bits RGB的圖片作加解密，DES硬體的速度以可作到real time，不需要等待。顯示的明文資料就寫入LCD display的buffer即可，LTM controller會自動取初顯示畫面。

LTM Library

DES Library

 

 

1.  Porting uClinux:

a. 使用uClinux的優點

本實作專題移植了以Linux核心為基礎的uClinux有幾個主要原因和好處，因為Linux為open source的OS，所以在開發上的成本相對較低，且開放原始碼的核心程式可以彈性的對於各種不同硬體的系統作修改和調整。而linux的核心相當小，kernel和sell也分層架構的相當清晰，不需要跑而外的user interface(像是windows 的圖形化介面)，在低耗電的嵌入式可以使核心執行的較為流暢，使用者介面的設計也可以對於實作需求作專一的特定設計。

b. uClinux與linux

而uClinux與linux最大的差別在於憶體管理單元(MMU)，在標準的NIOS示沒有MMU的CPU，且在很多嵌入式的設備中也不需要管理大量的記憶體，所以uClinux就是針對記憶管理單元的部分作修正，但仍然對標準的linux相容。

沒有MMU的uClinux也可以利用此特性，直接對任意記憶體作存取，所以在可修改硬體FPGA嵌入式系統或微控制系統，便可以透過C程式直接對address mapping的I/O作控制，像是本專題的LTM IP和DES Core等就可以快速的開發驅動程式。而有了OS之後，使用者程式也可以可重訂位的載入記憶體，在一般的應用程式設計就可以針對應用功能作設計，底層的硬體使用方式就由OS核心來負責，簡化應用程式的開發難度。

c. 裝置驅動、抽象化硬體使用環境

移植uClinux後，驅動程式的開發就可以和應用程式做切割，像是SD卡和網路的使用。應用程式可以輕易以fopen()函數，則SD卡驅動程式與檔案系統就抽象化整個動作，應用程式不需要設計如何溝通MMC SPI Controller，也不需要自行建立檔案系統，則透過OS的檔案結構便可對SD卡內的資料作存取。網路開發也是利用OS提供的API撰寫Socket程式，則不需要了解網路控制器實際如何將封包送出，且TCP/IP的協定也可透過OS的支援得到。

(Revision: 7 / 2010-10-23 02:54:02)

5. 設計方法 (Final Project Paper)

(因網路編輯器關係，有些版面畫跑掉)

一、   主要步驟

1.  利用Altera 提供的SOPC軟體工具來產生給DE2-70使用的硬體架構。在SOPC底下提供了豐富的硬體元件，利用Altera提供的NIOSII的CPU可以做為系統最主要的處理器，可以快速的產生一個簡易的計算機架構。而除了CPU外，SOPC也提供了很多先進的軟硬體元件，可以視功能需求的任意修改架構來提升效能，使設計更加有彈性。

2.  使用Altera提供的QuartusII軟體編譯DES(data encryption standard)資料加解密的硬體描述語言，使演算法用硬體來實現，增加系統效能。且QuartusII提供了很多工具可以驗證及模擬其硬體行為的正確性。

3.  在利用SOPC的客製化CPU指令或增加客製化avalon bus IP，使我們設計的元件可以與NIOSII得系統做溝通。

4.  使用Altera提供的API對avalon bus IP的register作存取方式，製作LTM Controller和DES Core的HAL驅動程式，並驗證整合於NIOS SOPC的系統下的正確性和效率。

5.  完成硬體架構後再使用Linux的作業系統環境來編譯一個適合我們設計的uClinux的OS kernel，如此就可以量身訂做一個屬於此系統需要的功能和裝置驅動的作業系統環境。

6.  使用NIOSII GCC的交叉編譯器來編譯適合執行於uClinux的應用程式。

7.  使用Altera 的Nios II Command Shell  燒錄硬體SOF檔，以及下載OS  kernel至DE2-70，並執行作業系統。

8.  設計使用設介面、各個應用程式的功能項目

9.  整合所有系統作最佳化的調整

 

二、   LTM IP設計

1. LCD部分

以友晶範例Multi Port SDRAM Controller([1] 友晶科技，LTM LCD User manual與實驗範例)作為LTM的FIFO，使其同時扮演硬體的Master和Slave的腳色，達到bus的切割。但利用Multi Port SDRAM Controller的方式連接還必須克服無法支援隨機存取的問題，因為其內部包含一個自動控制讀寫address的硬體，而CPU以avalon bus連接僅為介面通道，無法mapping到另一端的SDRAM address，所以在寫入時必須做整個display buffer連續的寫入。但如果畫面只需要更新一小部分，例如手寫輸入時只有點選到的區塊需要做變色，若仍將整個display buffer寫入就相當沒有效率，且會照成下一個手寫延遲讀入的現象，使手寫效果不連續。

▲LTM IP設計示意圖

所以實做LTM IP時又修改了原本Multi Port SDRAM Controller的內部控制機制，並在LTM Avalon IP加入控制的訊號線。其內部的動作，主要是兩個read/write FIFO、SDRAM controller和內部的address控制。而read/write FIFO在讀寫時的地址控制就是由內部的硬體做主動的調整，達到對read/write port兩端的硬體做非同步的傳輸。

所以修改了原先用來控置硬體自動位移的start address、max address、讀寫的length這些值，將這些訊號改成以NIOS CPU發送的data，以達到動態的參數化調整。將LTM IP增加四個訊號線，主要功能改變寫入的起始位置、寫入的最大位置、一次FIFO寫入的長度，並加入reset訊號。當NIOS CPU發出重制訊號時，硬體就重新初始化這些參數，並清掉write port的FIFO，這樣一來就可達到特定區塊的寫入。

這樣的架構不僅可達到bus的切割，也可以對LTM端的SDRAM做random access，在即時畫面和小區域的寫入更加快速，且手寫輸入的效果也因此大大提升，並可以不需每次都refresh 整個display buffer，減少avalon bus端的bus 的資料傳送。另外，因為LTM原先的時序產生為友晶範裡提供([1] 友晶科技，LTM LCD User manual與實驗範例)，一個Pixel為兩個16bits的data input，而所有在系統上執行的BMP為24bits RGB所組成，所以我將一個pixel的RGB資料包裝成32bits的DATA做傳送，因為avalon bus的data width為32bits，所以這樣的方式在一個800*480*24RGB的frame buffer就可以用比較少的cycle time。

規劃如下圖：

BMP Pixel

7…………………0

B

G

R

NIOSII  CPU 送出的DATA

31………………24 23………………16 15…………………8 7…………………0

unused

B

R

G

送入Multi Port SDRAM Controller和LTM controller讀出的DATA

 

LTM_READ_DATA2

15…………………8 7………………….0

unused

B

 

LTM_READ_DATA1

15…………………8 7………………….0

R

G

▲LCD Controller RGB Pixel規劃示意圖

 

2. 觸控介面部分

利用友晶提供的範例(注[1])，將可以讀入LTM XY座標的硬體區塊ADC_SPI_ Controller取出，以Avalon Slave IP掛上SOPC做為NIOS System溝通LTM ADC_SPI_Controller的介面。

▲友晶的範例示意圖(注[1])

主要有三個訊號線需要連接至NIOS系統的Bus介面上，分別是X、Y座標和讀入新座標的訊號。友晶LTM螢幕端的IC將座標規劃成X、Y各從0到0xFFF，所以我將X_COORD、Y_COORD兩座標的訊號值合成24bits的DATA，以Avalon Slave 的介面用CPU一次讀入32bits，再利用程式拆解回X、Y兩座標。

31………………24 23……………………………12 11………………………….…0

unused

Y_COORD

X_COORD

 

▲友晶LTM LCD螢幕座標規劃示意圖(注[1])

   

如此便可讓程式讀入觸控螢幕座標來開發應用功能，但由上圖也可發現一個問題，就是兩座標值均為0到0xFFF，可是實際畫面並非1:1的矩形，所以需要將座標以螢幕比例做X:Y=5:3(LCD解析度800*480)的調整。如此一來，觸控座標的二維方向就可以全部以同一單位量計算，則上下與左右移動速率就會相等。另外，因為控制器送出的訊號為精準度為0xFFF (4095)，而LCD實際解析度僅為800*480(最大邊為800)，造成觸控座標的刻度大於LCD的一個Pixel的刻度，所以觸控時有微小的移動就會讓XY座標的值改變巨大。因此，我就將兩座標的值在適當的縮小，以符合LTM解析度大小，則點選位置完全對應到螢幕的BITMAP Display Buffer。

 

 

三、   LTM電源管理

手持裝置在現今仍需克服耗電的問題，這些可攜式的嵌入式系統常使用電池做為系統的供電，所以必須盡量做到節省電量的消耗。在筆記型電腦這類的產品中常有電源管理的設計，本專題實作時也針對此應用做軟硬體的設計，透過OS的裝置管理，所有裝置的使用便可從上層關閉非使用中的硬體。

由於FPGA尚無法獨立關閉晶片中的某一硬體元件，為實現裝置管理和省電設計，我將FPGA裡的各硬體系統做切割，使獨立的單一系統擁有各自的reset訊號。如LTM控制器和SDRAM控制器所組合的顯示輸出的系統，做獨立的reset。這樣就可以達到FPGA上的Controller停止運作，並停止對LTM所使用的SDRAM的記憶體單元做refresh，以減少資料搬移和電容的充放電。同時也發送reset的訊號給外部的LTM螢幕的驅動電路，讓LCD螢幕關閉。

▲電源管理硬體設計示意圖

    設計方法是將與LTM溝通的avalon bus IP加上可程式化的暫存器，利用此暫存器做為LTM Controller和SDRAM Controller的reset signal，如此就可以用CPU來送reset訊號至LTM IP關閉螢幕的顯示、內部控制器和記憶體的更新。

另一個特點是透過可程式化控制的架構，來開發類似power manager的功能。本專題利用此電源管理的系統，提供使用者可以手動關閉LTM LCD的顯示，讓不須使用螢幕顯示時，可以將其關閉來節省電源。並提供使用者依習慣設定自動關閉時間的功能，當觸控螢幕閒置一段時間沒有輸入時，系統會自動關閉LTM顯示，並亮起LED燈提示目前狀態為閒置，只要按下按鈕便可重新開啟LTM LCD，類似手機可在待機時自動關閉螢幕顯示。

 

四、   3DES (Triple Data Encryption Standard)CORE

由第三章的已有說明3DES的基本規格、使用的理由和好處，本章節針對實作的方法，與細節做詳細的說明。

選用3DES是為了增進DES的標準，在九零年代時期，DES是公開的加密標準，當時證實是計算上的安全加密技術。但由於現今電腦的速度大幅提升，加上使用集合網路共同破解的技術，DES以可在有效時間內被破解。所以本專題實作時採用3DES的方式增加安全性，另外，該架構又可引入管線化的執行概念，定可學習客製化硬體與軟體整合使用。

    3DES屬於對稱性的加密，key為192bits，而單一DES為64bits key。其中原始的金鑰每8個位元會丟棄一個，所以DES增減Key後會變為56Bits。經過金鑰轉換，產生子金鑰送到加密的演算區塊。而主要的加密動作為XOR，與S-BOX的替換盒取代，再以P-box選取排列，將資料做打亂。一個64bit的資料會被拆解成左右兩個區塊，連續做上述一連串得動作16回合，如此就相當安全的加密。以下為主要的步驟概述，

1.  金鑰轉換(56 to 48bits sub-key)

2.  擴增排列

3.  S-box替代

4.  P-box排列

5.  XOR和交換

▲DES區塊流程圖

([2]趙子羽，Triple-DES及AES加密演算法的硬體設計與實現，國立交通大學電信工程研究所論文)

▲3DES區塊流程圖

([2]趙子羽，Triple-DES及AES加密演算法的硬體設計與實現，國立交通大學電信工程研究所論文)

    而3DES則是利用DES的流程做三次加密，其主要實作方式有兩種，一為以multi cycle的循序電路產生狀態機，依序將DATA和KEY送入加密。二為透過重複產生三個不同的DES硬體，以管線化的方式串聯，增快加密速度。其中第二個方式成本較高，但相對效率較好。

▲3DES multi cycle type示意圖       ▲3DES pipelined type示意圖

([3]CAST, Inc ，Triple Data Encryption Standard Megafunction，PDF)

    而DES核心的加密F函數架構由下圖說明其運作流程。F函數有兩個輸入資料:一為32 位元的中間密文R，另一部份是48 位元的子金匙K。32 位元的中間密文R 先經過擴增排列E後，即擴增至48 位元。接著，再與另一輸入資料，即48 位元的子金匙K做互斥或XOR 運算。所得的結果，再平均分配給8 給替換盒S1,S2,S3……S8。

▲DES Function 流程圖，[2]李彥橋，高效能Triple DES加解密晶片之設計與實作，國立東華大學資訊工程學系碩士論文，民91

其中裡面的一個重要運作為替換合的選取，S1~S8即是替換的規則，以此做替換bits。交換盒的輸入為6個bits，經交換後輸出4bits。有8個交換盒，所以可以對應輸入48bits 進f函數，則輸出32bits的結果。所以可以了解當初IBM開發此加密演算時，在替換盒的設計必考量到某些攻擊的手法，而找出這八組替換盒。SBOX為公開的標準，在此就不全部一一列出。

透過Quartus II將3DES的演算法以VHDL實現，編譯後用Quartus II的模擬工具做硬體功能的驗證。

 

以下列一組資料測試，Key1=0102030405060708

                                        Key2=A20FD79CE02945BD

                                        Key3=0123456789ABCDEF

 

首先是加密處理，將DATA和KEY送入，再分別送入load key ready和load dataready使DES core狀態改變，由圖可以看到原先的明文0000000000000000變為114447585FD579D1。其中function_select為加密或解密的設定。

▲3DES加密模擬波形圖

 

再以得到的密文114447585FD579D1反向解密，可看到又還原成原本的明文0000000000000000，表示硬體的功能正確。

▲3DES解密模擬波形圖

    確定3DES的硬體可以正常運作後，下一步要做的就是將此硬體與本專案的NIOS SOPC System做整合。要使其硬體可以用NIOS CPU來送資料作加解密有兩個主要的方法。第一個為CI(Custom Instruction)的使用，將硬體整合至CPU內部，增加CPU內部指令來實現。第二則是以Avalon bus作為CPU與3DES的溝通介面。原先我已CI為設計方法，但因為CI須配合CPU指令的格式，本專題實作的3DES為三組64bits的DATA和KEY，所以用CI的方式需要多道指令才可完成，且為配合多元程式環境，讓CPU停在加解密的指令太浪費CPU時間，並不划算，所以我後來採用Avalon bus Slave IP的方式掛上Bus。如此一來，CPU只需要送DATA至3DES Core後，就可以繼續執行其他的工作。在大量資料加密時，此方法比較適合。

▲3DES整合示意圖

    3DES經由此方法整合後，就可以用CPU以程式來送資料，將DES加密功能應用在各種不同的介面或資料上，本專題以實作解密文字檔或圖片，使資料安全的存放或傳送至網路。

 

    實作圖片加密時有又一個主要的問題必須解決，由於DES屬於區塊式的加密技術，所以明文會被切割成一定的大小進行加密或解密。這樣的方式在圖片加密時便會產生漏洞，本專題以探討加密結構造成的瑕疵，所以圖片格式均已BMP為例，來顯現相同明文會對應到相同的密文。這樣的問題造成加密效果降低，也增加破解的可能性。

  

▲相同明文區塊對應相同密文區塊問題圖片

由上圖可以發現，大部分的區塊均可良好的加密，但連續相同區塊同一數值加密後，卻會照成全部對應到相同數值的問題，這樣一來就沒有加密的效果，也增加不斷嘗試明文密文對應的暴力破解可能。所以勢必要有解決的方法，我採取的策略以下有兩種。

 

以CBC的流程改善：

    利用鏈結模式，讓第一次加密後的密文與下一次要加密的明文組合再加密，這樣一連串的動作，產生回饋的動作，使同一區塊在第二次加密時，明文的資料會因上一次加密結果而改變。這樣就可以解決相同明文對應相同密文的問題。

▲以CBC流程加密示意圖，[4]A. Kahate網路安全與密碼學，學貫

    但是利用此方式，加密的次數會增多。若大量資料加密時，付出的時間成本將當高，且要解密的步驟就更加複雜。所以我又想其他的方式來解決。

 

加入亂數種子來改善：

因為我在規劃LCD顯示的暫存區時，為了減少BUS的使用，我以32bits DATA傳送RGB pixel，所以事實上在Display buffer的每一個pixel中仍有8bits未使用。我就利用此空間，在所裡面加入亂數的值，而加密時就將兩個32bits的資料組合成64bits的DES加密前的明文，也就是說，每兩個Pixel裡就包含兩個8bits的亂數值，這樣一來既使原本為一樣Pixel value，加密前還是會參雜亂數，使兩點就不會是一樣的值。

所以即使將同顏色的圖片區塊，經過加入亂數加密後就不會對應到一樣的顏色，且要以大量試驗的方式破解也比較困難。但此方式也會造成而外的負擔，實際加密也會使原本的圖片運算完容量變大，約多出四分之一的大小，但整體計算上比用CBC的方式較快，且解密的流程也較單存。如果將這個額外多出來得密文pixel切割，再以DES的KEY組合，就可以產生本專題獨自的加解密金鑰。

▲加入亂數種子加密示意圖

 

五、   移植uClinux

由第四章設計架構中的軟體架構已提到移植作業系統的好處，本章節要說明如何在FPGA的客製化系統中執行OS。

1.編譯uClinux OS

本專題實作於NIOS的SOPC系統，而在FPGA中嵌入CPU軟核的一大重點就是可以移植作業系統以獲得更完整的計算系統架構和多工的處理等支援。本專題選用linux base的uClinux以利使用開放原始碼在自行建構的系統中編譯並客製化，實作時主要移植的步驟如下：

1.       因為要支援OS的執行，在SOPC下也需要做硬體的支援，像是獨立的timer提供OS分時多工地中斷使用。

2.       取得uClinux-dist和Nios II cross-gcc compiler。因為編譯核心受編譯環境和編譯器的影響，所以需要在linux系統下編譯。我選用Fedora 7(最新的系統環境不見得最好)執行於VMware的虛擬機器上作為編譯環境，除了Nios II cross-gcc compiler外還需要gcc和yacc compiler，以及git-core等許多不同的套件，視各系統環境不同需要額外安裝。在環境設定上較為麻煩，可能缺少編譯需要的套件而使編譯失敗，所以第一次編譯時會耗費大量的時間在設置環境。

3.       編譯uClinux核心。用make menuconfig以uClinux-dist提供的選單來做內核的配置、選取驅動、系統元件、檔案系統等等的修改。

4.       再以make vendor_hwselect SYSPTF修改MAKEFILE的硬體選項，來選擇DE2-70執行OS的CPU、memory和OS Image存放的memory等，提供編譯時的參數。

5.       編譯核心、ROM File System及映像檔

以上步驟就可編譯一個屬於NIOS System的uClinux OS，若還需要而外的內核修改或裝置驅動，可再藉由make menuconfig從選單裡挑選，或者自行修改source code再重新編譯。

 

2.加入SD MMC裝置驅動及DM9000A網路控制器驅動

    因為DE2-70有提供SD卡的socket，所以專題實作時也針對此IO做驅動，讓使用者可以將資料存放在SD卡內。但原先友晶科技範例所提供的使用方式是利用PIO的方式，對SD卡的四個PORT做存取。因為要整合作業系統的裝置驅動和檔案系統，所以改用ALTERA提供的MMC SPI Controller。

    所以修改SOPC下的配置，再使用Quartus II修改SD Card Socket和MMC SPI Controller的連接，重新編譯FPGA硬體。並在OS驅動加入MMC SPI的驅動程式、FAT檔案系統及語系的支援等，並重新編譯OS kernel。

    而網路也是OS支援的一大利器，在DE2-70上也提供DM9000A的網路控制器，但原先友晶科技所提供的範例為DM9000的Controller for DE2，所以一開始花了很多時間測試一直無法驅動網路。後來重新選用DM9000A Controller並先以NIOS IDE測試是否能正確送出封包，載至OS端加入網卡驅動及TCP/IP Stack等支援。其中，在SOPC下DM9000A的名稱要修改為DM9000，以符合uClinux原先驅動默認的名稱，或者在編譯前要修改kernel code 的config.c對應裝置的硬體名稱。而測試驗證網路驅動時也花了很多時間去尋找各種遇到的問題，因為在客製化的FPGA中，軟硬體都可以自行增加或修改，而軟硬體間的設計必須互相配合，所以一旦出現不如預期的效果，就不能以硬體不會錯誤的假設為前提去修正，較難測試。

 

六、   FONT建立

1.理由

本專題以實作電子閱讀器為應用主題，所以必須讓使用者可以顯示文字檔案，所以就需要一套字碼提供LTM顯示的輸出字型。程式由TXT FILE電子的檔案讀出，資料全由0和1組成，所以要表示一個文字就需要一文字的編碼法，可能是ASCII、BIG5或UNICODE。以ASCII為例，一個字母由8個bits所組成，所以讀入的字元在程式的處理都用此編碼做處理。而本專題實作的嵌入式系統是一個小型的計算機系統，所有的資源必須視此平台來使用最佳的方式處理，且LTM LCD的顯示也是自行開發的系統，一旦要將TXT FILE的字碼輸出成文字影像就需要建立一套適合此系統的字碼檔和做轉換的程式。

 

2.客製化適合的字碼

    而需要自行開發字碼的主要原因有兩個。第一，因為現在先進的電腦系統中的字型大多以UNICODE編碼，而儲存的格式為TTF(Ture Type Font)向量字型，但此型態字碼檔的容量相當大，且在做向量圖型的轉化需要大量的計算，在本專題的系統中較不適合。第二的原因則是螢幕顯示的輸出裝置，由於LTM LCD的規格不像大螢幕LCD需要TTF可以善用向量影像放大成很大的字形，且LTM控制器的使用方式和規格都是自行開發的規格，所以自製字碼檔在特定用途的系統和自行開發的應用程式上的處理也較為方便。

    基於以上兩的主要的原因，實作時自行建立出一套適合LTM大小、NIOS系統速度和小記憶體的嵌入式系統的字碼檔。以ASCII為例，將TTF的字形檔輸出成約30pixel*30pixel大小(最大30*30個點)的BITMAP圖形，而格式設定為黑白雙色的顯示，則每一個pixel記錄此點為黑色或白色，BITMAP的資料則為連續的二進位資料，如此一個32bits的資料就可以存放32個點，記憶體的使用就較為節省。如以下一連串30個32bits的資料就可以存放一個ASCII碼的FONT。

圖形為一個字元’a’字型的記憶體存放方式

 

▲BITMAP FONT存放於記憶體的形式

    將所有的字碼以二進制bit font形式存放後，還需要一個寬度表的紀錄才能讓連續得字母顯示的間距一至。主要是因為每個英文字母和符號的寬度都不一樣，當所有的字碼都以一定大小30pixel*30pixel顯示時，一個單字的顯示就會變得零零散散。所以在TTF檔轉成的BITMAP圖形的大小也都不一樣，在建立時我將每個字母或符號圖形的寬度全都記錄下來，製成一個寬度的查詢表。輸出一個字元時就在查詢此字元所佔寬度的大小，做為下一個字元輸出時的位移量。如此就可以對應到LTM bits mapping的frame buffer。

▲不定長度字碼示意圖

上圖說明各字元不同寬度和存放的方式。由圖可以看出’w’字母的寬度較寬，而’j’這類的字母則窄許多。另外由於小寫字母的g、j、y等較一般字母的高度水平也不同，所以在建立字碼時，以30pixel存放並非一個每個字母均占滿整個高度，上下會有一部分的bits做為不同字母高度水平的位移調整。

 

3.中文字碼的支援

    支援中文更是另一個問題，目前的系統多採用UNICODE做編碼，其中也包含中文字碼的支援。但UNICODE包含多國語言和特殊符號的字碼過於龐大，如果使用此編碼標準記憶體的使用肯定過於龐大，所以時做時採取BIG5做編碼。BIG5字碼包含繁體中文的範圍，省略的不必要的語言、符號和不常用的罕用字。

 

我一開始選用BDF(Bitmap Distribution Format)字碼檔格式，是一種BITMAP的FONT，而存放的方式為TXT FILE，內容記錄字碼的BIG5編碼、字碼的寬和高、和一組以binary方式存放的BMP字型資料。

 

說明如下：

 

STARTCHAR Cc667//start token ENCODING 50791       //big5 code ‘讚’ SWIDTH 666 0 DWIDTH 16 0        //font size BBX 16 16 0 -2 BITMAP                         //font data 0000 0294 3bde 0294 7fef 014a                        //bit mapping→ 3d6b 0210 3cfc 0084 24fc 3e84 24fc 2484 3cfc 2586 ENDCHAR            //end font token

圖片顯示一個字碼的存放方式，整份BDF由約14000個這樣的文字檔還有一個BDF檔案資訊組成。

 

 

 

 

□□□□□□□□□□□□□□□□ □□□□□□■□■□□■□■□□ □□■■■□■■■■□■■■■□ □□□□□□■□■□□■□■□□ □■■■■■■■■■■□■■■■ □□□□□□□■□■□□■□■□ □□■■■■□■□■■□■□■■ □□□□□□■□□□□■□□□□ □□■■■■□□■■■■■■□□ □□□□□□□□■□□□□■□□ □□■□□■□□■■■■■■□□ □□■■■■■□■□□□□■□□ □□■□□■□□■■■■■■□□ □□■□□■□□■□□□□■□□ □□■■■■□□■■■■■■□□ □□■□□■□■■□□□□■■□

……………

 

 

 

 

 

 

 

▲BDF字碼格式說明

 

其中所有的字形以同一大小16pixel*16pixel存放以減少資料量，而整個BDF為文字格式，所以其BITMAP的資料需要再轉化成無符號的整數型態，再將其bit資訊轉換成LCD frame buffer的pixel。另外BIG5的編碼為2個BYTE，和ASCII的編碼格式不同，所以在做文字檔讀取時必須一次抓取兩個2個BYTE做一個字的編碼，再到此字碼檔搜尋對應BMP FUNT。以C語言為例，對檔案的存取必須連續做2個fgetc()，再將兩char型態的資料組合成一個unsigned short。

 

4.改良BDF容量和字碼搜尋問題

    取得已有BDF字形檔便可省去自行建立大量字型的麻煩。然而，有了此以BIG5編碼的字碼檔看似省去UNICODE的龐大內容，但其一份BDF檔也需要2.3MB的大小，如要要支援中文字碼就需要佔掉約2MB的記憶體空間，在小型的嵌入式系統中也是相當大的負擔。而且，其TXT FILE的存放方式，在搜尋字碼的效率也不是相當好，當要找某一個字碼時，必須以字元方式，一個一個將charter讀入，在做字串解析的處理，來比對BDF的TXT的標註。這樣的方式，每次要尋找一個字碼時都要做複雜的字串比對，非常浪費cpu時間。

    所以為了使字碼容量可以再縮小，且增快搜尋一個字碼的速度，便要將BDF檔轉換成較低成本的格式(對於CPU和memory，時間和空間)。

修改的方式如下：

1.       因為中文的字碼寬度都相同，所以字碼黨無須再紀錄每個字形的寬和高，便將此部分省略。

2.       將bitmap的字碼data改成以binary的方式存放，如此一個16*16pixel的字碼只需要16*16bits，以C語言而言就是16個unsigned short的陣列(32byte)就可存放。這樣一來約140000字的BIG5字碼只需要14000*32byte≒448KB1，比起原先TXT需要2.3MB

 

3.       以單一變數存放字碼，改善程式搜尋流程。

a.  使用此方式的理由

如果所有的字碼存放成獨立的變數名稱，這樣在搜尋上必須以if else的程式流程的方式來判斷字碼，或者用字串方式去比對搜尋。因為中文字碼相當龐大，所以用前者的方式會造成程式碼相當龐大(原先用此方式，程式碼多了2MB)，後者會使搜尋時間過慢。

b.  解決方法

因為以上的原因，所以單一變數連續存放整個bitmap font，然後還需要再建立一個offset table來對應每個字碼和連續bitmap font所在位置的關係。這樣一來，在輸出字碼時，只要查詢offset table並可找到字碼的bitmap font，且用index的方式直接存array裡取出，減低了字碼的搜尋的複雜度。

原先包含約14000字BDF字碼檔2.3MB的容量，透過轉換存放的格式後，只需要一個以binary是存放的BMP FONT和一組查詢的offset table，大約是400KB左右的大小，足足縮小了五倍的大小。這樣電子書執行時，只需第一次和程式碼一同載入，就不用已BDF不斷做開檔，且耗費2MB的記憶體，又增加OS在分配和釋放大量空間的負擔。所以本專題在實作時，不僅是設計讓DE2-70的NIOS執行的程式，在做各種功能的支援上，還需要設計而外的程式來客製化電子書所用到的元件，使效能得到最佳的平衡。

 

七、   事件驅動的人機介面

    本電字書以LTM Touch Panel LCD做輸出設備，所以也將所有的人機互動的INPUT以Touch Panel來輸入。而整個應用程式的使用就依賴自行建立的user interface做溝通，所以介面程式就必須不斷讀取Touch Panel的座標值，在到某個表格做查詢相對應的動作，來產生按鈕的概念。

如此應用程式的執行就變成一個是件驅動(event trigger)的程式流程，因為強調人性化介面，及特殊的觸控輸入方式，所以需要撰寫許多UI的程式。在應用程式的設計上有很高的比例是在處裡使用者輸入和輸出介面的畫面處理和按鍵抓取。

 

後續開發：

所以另一個後續開發的目標則是將整個系統做更完善的規劃，訂定出一套處理GUI使用的API，設計出類似JAVA GUI設計的framework，應用程式開發可以透過API的呼叫，來產生一個按鈕的元件。而內部產生一個專門處理GUI的程式，當產生一個按鈕實在LTM對應的座標上顯示，並對此按鈕的範圍作偵測觸控輸入，回傳給應用程式。這樣一來，開發應用程式就可以更加的快速，且結構化和階層的關係也更加清晰。

▲GUI API與系統呼叫程式示意圖

圖形說明：透過建立GUI system program層的系統程式，AP可以直接使用GUI API來做類似add button()的動作，然後GUI system program就會畫出一個按鈕的圖形，並記錄其座標位置，當LTM讀入座標後就去查詢記錄座標的table，如果有對應的按鈕就回傳給AP，表示某一個按鍵被驅動，則AP觸發某一個事件功能。所以就具體化一個按鈕的元件，應用程式就開發應用功能，GUI的使用就透過GUI system program對LTM Driver做呼叫。

 

 

 

 

八、   手寫密碼辨識

如何達成辨識使用者寫入的字的方法：

先記錄好每個字的特徵，然後再掃描使用者手寫輸入的字去比對看看是否符合那些特徵。

如何記錄字型的特徵：

由左到右和上到下分別各掃三條線，當掃到pixel為黑色（0-0-0）時，則表示那條線有經過數字的其中一個點，當從0-0-0變為白色（255-255-255）時則表示結束經過那一點，而這時就記錄有經過一點，以4舉例來說（如圖一）：圈起來的那些點即是6條掃描線會經過的點，4統計起來是經過10個點。

另外，掃描4的最下面那條線和最右邊的那條線分別也各有掃描到一點，這個特徵也會記錄下來以供辨識用。

＜圖一＞

    ▲手寫辨識方法示意圖

所以當掃描完使用者手寫入的4之後如果經過統計也是10個點並且在最下面那條線和最右邊的那條線都有掃描到一個點的話即表示使用者寫入的數字是4。當使用者把4個密碼都輸入完後，如果掃描完和正確的密碼吻合，則使用者可以繼續的使用此電子書系統，否則就要重新輸入一遍。

 

 

 

 

九、   進度分配表

余永暉：

2010年前主要是學習個工具與實驗版知識和技術，並建立客製化SOPC。

項目	月	1	2	3	4	5	6	7	7.5	8	8.5	9	9.5
移植uClinux
DM9000A網路控制器
MMC SPI SD卡控制器
3DES設計驗證
3DES移植整合SOPC
LTM LCD IP設計
LTM觸控功能
LTM驅動及API
數位相框
小畫家手寫功能
ASCII、BIG5 FONT
電子閱讀器
螢幕小鍵盤
即時新聞網路程式
圖片小遊戲功能
GUI介面整合各功能

 

李冠儒：

三上：與組員找專題老師，並初擬題目。

三下：

1.  練習由DE2-70廠商提供的lab，以便知道如何初步的使用版子上的資源。

2.  試著把組員的包裝好的Linux Kernel燒到DE-2裡，並成功運行了OS。

3.  裝好nios2 專用的cross compiler，並且確定經過這個compile後的程式可以順利的在DE2-70的uClinux上執行。

暑假：

1.  初步達成PC 與 DE2-70的NFS，往後就可以直接把編譯好的程式直接傳到PC端與DE2-70 uClinux端NFS的資料夾中。

2.  先以DE-2版子上的小LCD做實驗，試著在linux的環境下，用程式直接對LCD的記憶體作存取，使其可以直接對LCD下指令，如一個一個的寫入字元、清除螢幕…等等。

3.  成功的一個個輸入字元後，接著嘗試直接寫入字串，並且成功達成換行。

4.  經指導老師的提議，開始嘗試將printf()函數的最終輸出端導向到LCD上，因為假設能在LCD上成功的導向，如此即可較輕鬆的移植到LTM觸控螢幕上使用。

5.  後來發現輸出端都是經由stdout去做定向，因此決定客製化自己的stdio.h，並重新命名為CustomStd.h，目的是當要使用printf()這個函數時，不用引入stdio.h，反而是先引入CustomStd.h使printf()的輸出重新導向到要輸出的目的端（如：LCD、觸控螢幕）。

6.  因為要用軟體直接去操控LCD，因此寫了一個簡單的LCD的驅動程式，用來初始化LCD（對其做清屏幕、開啟屏幕等動作），並在CustomStd.h這個程式中呼叫此驅動程式。

遭遇問題：

    要重導向到LCD端顯示，需要特別寫出printf在LCD上的顯示規則，例如遇到什麼語法要換行、什麼語法是要顯示字元、怎麼輸出一個字串…等，換言之要重新導向到觸控屏幕上也是需要重新寫適用於那個屏幕的輸出規則。

最後決定：

    這部分因為時間緊迫，加上硬體那端後來有做出類似的處理，因此決定先停止這項工作。

四上：

1.  因為硬體方面的架構已完成，故經組員討論後決定開始撰寫應用程式。

2.  負責手寫密碼辨識的部分（未完成）。運作原理為藉由紀錄手寫數字的特徵，與圖片上的數字密碼比對特徵，假設特徵符合，則表示密碼正確。

遭遇問題：

    現階段尚未完成密碼辨識的部分，估計於學校專題發表前會完成這一塊的製作，並嵌入於應用程式中。

 

十、   參考資料

引用:

[1]  友晶科技，LTM LCD User manual與實驗範例

[2]  趙子羽，Triple-DES及AES加密演算法的硬體設計與實現，國立交通大學電信工程研究所論文

[3]  CAST, Inc ，Triple Data Encryption Standard Megafunction，PDF

[4]  A. Kahate網路安全與密碼學，學貫

(Revision: 3 / 2010-10-23 02:52:09)

6. 設計特點 (Preliminary Paper)

1. 提供多元程式(multi-task)架構，使多功能並行使用

2. Porting linux base OS提升程式的移植性和開放性架構，並提供更完善的檔案系統

3. 即時的硬體加解密處理並保護重要資料的安全和智慧財產

4. 通訊介面可利用3DES硬體達到即時加解密處理

5. 觸控式的人性化輸入介面，讓使用者可以輕鬆的使用

6. 提供多組字型可讓使用者做切換或改變大小

7. 可觸控電子書來畫重點或做筆記的螢光筆功能。

8. 使用者可以用觸控面板以手寫方式作塗鴉或寫字留言等功能

9. 操縱更直覺的觸控式圖片小遊戲

10.可以使用ethernet連上網路，提供遠端傳送即時新聞(還可作更多應用)

11.可以讓系統自動撥放SD卡裡的照片，並可自動偵測人臉部位作中新點位移的放大顯示

12.大頭貼(拍貼)的圖片編輯功能，可裡用觸控螢幕插入美工照片或加入邊框

13.手寫密碼辨識，保護電子書的使用權

14.系統可依使用者習慣設定會自動或手動定時關閉LCD的顯示，以關閉Controller的畫面更  新，來達到省電的功效

15.利用觸控螢幕提供螢幕小鍵盤取代傳統鍵盤的輸入方式

16.透過OS管理IO裝置，並可以OS的層級來關閉不需使用的硬體裝置

17.調整軟硬體做最佳化，並提供多樣化的功能應用

 

詳細功能前面的章節，部分已有詳細的介紹，可由前述得知

 

 

WHY DE2-70?

1.      DE2-70使用了 Altera Cyclone II FPGA with 68416 LEs，提供足夠的容量來達到硬體元件的調正和彈性，可以讓我們選擇各式的技術和原件達到軟硬體的整合。

2.      提供ethernet的連接埠，和DM9000A的Ethernet controller，支援IP/TCP/UDP checksum generation and checking。

3.      具備兩顆32M的SDRAM足以運行uclinux作業系統和提供LTM LCD display buffer即多功能的應用設計。

4.      具備USB的介面，可支援多元的輸入裝置。

5.      具備SD卡的插槽，提供使用記憶卡的介面，讓我們實作的多媒體資料可以有而外的儲存空間，且更有通用性。

6.      具備40PINS的IDE連接插槽，可以外接觸控式LCD螢幕，使我們實作的輸入輸出設備做整合。

(Revision: 6 / 2010-09-17 22:17:59)

7. 總結 (Final Project Paper)

李冠儒：

    使用DE2多媒體開發板對於我來說是個嶄新的學習。之前有修習過系上所開設的嵌入式系統相關課程，只是使用的教學板子其內部之硬體架構都是已架構好的，也有現成的驅動程式可以用，因此開發起來較順暢；當拿到DE2開發板時，沒想到FPGA可以如此複雜，並對於如何去操作相關的工具充滿著疑問，後來聽從老師的建議，將附在友晶科技DE2板子套裝裡的tutorial詳細的看過並跟著實作，漸漸的認識工具的操作，爾後實做友晶提供練習用的實驗以便熟悉工具的各功能，且瞭解其好用的地方。

    在製作這專題的途中，當對於方向、技術、創意…等方面有疑問時，多次與組員和指導老師討論，藉由互相的往來檢討，往往可以看到我以往沒注意到的層面，並且產生新的想法，除了對於觀察力有所幫助外，對於如何與一個團隊合作完成一個或多個project也有更深一步的體驗。

    一路下來的進度中，其實負責的領域變動過許多次，到了暑假前才決定好要深入研究的方向，也就是I/O部分，我負責的比較偏向於軟體方面，而另一位組員比較偏向硬體處理，當想試著定向輸出端時，發現單單一個printf函數就做了如此繁雜的工作，牽扯到許多的標頭檔，也因此在解析printf如何運作時費了好大的一番功夫去探究ulibc源碼，找出是哪一個環節控制了一個字元或一列字串的輸出，這樣的過程實在是備感新奇，因為平時我們很順暢的隨意呼叫此函式來幫我們處理事情，殊不知其處理過程別有一番洞天，雖然最後因為某些因素不得使這項環節停下來，但是我也不後悔做了這些事情，畢竟我從裡面學到了不少平常不會特意拿來教的知識。接著處理手寫密碼辨識的部分又是另一塊新的領域，因為嵌入式硬體本身就會有所限制，所以在寫演算法時，必須要顧慮到是否會讓硬體無法負荷其運算，至此也知道凡事不能只注意其中一面而是環環相扣的重要性。

    最後很高興能參加這場競賽，在此也感謝我的組員余永暉、我的指導老師王益文老師、以及舉辦這場競賽的Terasic友晶科技，因為有了參與才了解到大家所擁有的無限創意與意想不到的思維，在與之互動的過程中，不管是技術面，抑或人際面，皆讓我成長了不少，也在我人生的里程碑中畫下了重要的一筆。

余永暉：

    記得在我大二暑假時就開始學習嵌入式系統相關的知識與技術。剛開始我還對DE2-70和相關工具很陌生，所以先從友晶科技所提供的範例，學到很多基本的操作和各種於FPGA上的設計，並參與上屆學長的專題meeting，使我了解和老師溝通的方式。

製作期間，我碰到最大的問題在設計一個Avalon Bus IP，為了將LCD 控制器移植到專題的NIOS系統，我花了將近一個月的時間研究。因為從未處理過這麼複雜的硬體設計，剛開始挫折連連，但經過閱讀許多文件、論文、網路資料，最後經由老師的建議，用已有的範例一步步的實驗、測試、修改，終於使沒有提供IP元件的硬體動了起來。後續還有架構的調整、撰寫驅動程式一連串的過程。這樣一個完整的學習，讓我了解到計算機最底層的技術，看到硬體元件是如何運作、和軟體怎麼溝通，並透過移植作業系統，讓我有完整的電腦系統架構概念。

在一年內我能有所進步，要感謝我的指導老師王益文。老師總是給我們很大的自由度，培養我獨立研究及解決問題的能力，也不時給我專題的方向和靈感。在我遇到瓶頸時，會暗示我如何處理，並要我多方向的思考，發現問題的兩個不同層面。課業外，老師也分享自己的經驗，改變了我對某些事物的看法，同時給予我很多協助。此外，也感謝VLSI實驗室的學長和上屆學長的幫助。最後感謝友晶科技讓我們能有機會在這個舞台中表現，並在賽程聯絡上的用心。整個專題製作過程，我將大學所學的知識做了驗收，也透過多人共同製作專題的機會，學習在大型專案需要的分工與溝通，這是我大學時光中難得的經驗，與重要回憶。

 

(Draft / 2010-10-23 02:23:28)