技術文章 Archives - Page 2 of 2

中斷處理模式：外部中斷處理和內部中斷處理的差異性

Post author:Lee Claire
Post published:2013-07-05
Post category:技術文章

江繼堯，資深工程師，晶心科技股份有限公司

在現今 SOC 設計中，當周邊裝置(Peripheral IP)想要和中央處理器(CPU) 溝通時，最常使用的機制是透過中斷(Interrupt)。周邊裝置可觸發中斷給中央處理器，當中央處理器接收到中斷後，則可判斷是由那個周邊裝置觸發些中斷，接著處理相對應的中斷處理程式(ISR，Interrupt Service Routine)，藉此達到彼此溝通的目的。
而 AndesCore™在中斷處理方面，共支援兩種模式：內部中斷處理器(IVIC Mode，Internal Vector Interrupt Controller)和外部中斷處理器(EVIC Mode， External Vector Interrupt Controller)。其中最大的差異性，即是中斷控制器所存在的位置。在內部中斷處理模式下，AndesCore™本身即設置了一個中斷控制器存在於 CPU 內部，經由此中斷控制器來處理相關中斷的工作。而在外部中斷處理模式下，使用者必須在 CPU 外部實做一個中斷控制器來處理相關中斷工作。
除了上述的差異性之外，在硬體方面的整合和軟體方面的應用，也存在些許差異性。本文之目的除了介紹這些差異性外，也提供一個簡單的設計平台供使用者參考。期望能對使用者有所助益，也希望讀者不吝指教提供您寶貴的意見。

1. 中斷處理模式介紹
AndesCore™共支援兩種中斷處理模式：內部中斷處理器(IVIC Mode， Internal Vector Interrupt Controller)和外部中斷處理器(EVIC Mode，External Vector Interrupt Controller)。以下的介紹將架構於 AndesCore™ N968A-S 這顆中央處理器。帶領使用者循序漸進地，了解這兩種中斷處理模式的差異。

1.1 Definition
AndesCore™ N968A-S支援兩種中斷處理模式，首先，我們先介紹關於這兩種模式的定義。

1.1.1 IVIC Mode
AndesCore™ N968A-S內部設計了一個中斷控制器，所支援的中斷來源數目可透過配置來決定。目前最大可支援16個中斷來源，但可擴充至32個。請參考圖表 1。若使用這存在於CPU內部的中斷控制器來處理相關中斷工作時，則為IVIC模式。假若SOC的中斷來源大於32個時，使用者還是可以使用IVIC模式，但是需要將多個中斷來源合為一個中斷訊號線(ex: OR function)，且中斷處理程序(ISR)在該中斷訊號線觸發時，需要去判斷是由那個中斷來源所觸發。在N968A-S的IVIC mode之下，每個中斷來源可以選定值為0~3的優先權(priority). 優先權高的中斷來源可以打斷優先權低的中斷來源。

1.1.2 EVIC Mode
假若IVIC模式不符合使用者所設計的系統，使用者就需要選用EVIC模式。在此模式下，使用者需要額外設計一個中斷控制器，用來處理周邊裝置和中央處理器之間相關中斷的工作，做為兩者間溝通的橋樑。

1.1.3 Interruption Vector Entry Points
為了加速中斷處理的時間，AndesCore™ N968A-S內部實做了一個Interruption Vector Table。將不同的中斷事件分別對應到不同的Vector Entry，當中斷發生時，CPU即可判斷中斷是由那個周邊裝置所觸發，並跳到該中斷所對應的Vector Entry，進而執行相關的中斷處理程式(ISR)。
在前面章節有介紹AndesCore™ N968A-S支援兩種不同的中斷處理模式。因此，在不同的中斷處理模式下，也對應了不同的Interruption Vector Table。

1.1.3.1 Interruption Vector Table of IVIC Mode
在IVIC模式下，所支援的中斷來源可由使用者來配置，支援的數目由2個到
32個。Interruption Vector Table相關資訊如下：
• 41 entry points (9 exceptions + 32 interrupts)
• Address = IVB.IVBASE + (entry number) * IVB.ESZ (VEP: Vector Entry Point)

1.1.3.2 Interruption Vector Table of EVIC Mode
在EVIC模式下，所支援的中斷來源數目可達到64個中斷。Interruption Vector Table相關資訊如下：
• 73 entry points (9 exceptions + 64 interrupts)
• Address = IVB.IVBASE + (entry number) * IVB.ESZ

1.2 Signal Descriptions
AndesCore™ N968A-S 提供相關中斷訊號線，使得 CPU 可與周邊裝置或是外部中斷控制器溝通。在 EVIC 模式下，除了中斷來源訊號線之外，還包含了和外部中斷控制器相互溝通的訊號線，詳細訊號線敘述如下：

其中，evic_ireqval 和 evic_ireqack 這兩個訊號線用來和外部中斷控制器溝通。在 IVIC 模式下，周邊裝置的中斷訊號可和 int_req[N:0]直接整合。當周邊裝置觸發中斷時，相對應的 int_req 訊號會拉起，告知 CPU 該周邊裝置觸發了中斷，CPU 即會跳到所對應的 Vector Entry 來執行相關的中斷處理程式。
而在 EVIC 模式下，外部中斷控制器會負責處理周邊裝置的中斷訊號。當周邊裝置觸發中斷時，外部中斷處理器會負責和周邊裝置溝通，並將相對應的中斷訊號(int_req)和中斷需求訊號(evic_ireqval)發給 CPU，當 CPU 接收到中斷時，會將中斷接收訊號(evic_ireqack)拉起，告知外部中斷處理器收到中斷，並去處理相關中斷處理程式。
相關處理程序可參考圖表 5。在 ARC a 時，當 ireqack 訊號為 low 時，CPU 可等待周邊裝置觸發中斷。當周邊裝置觸發中斷，外部中斷控制器將相對應中斷訊號 int_req 和 ireqval 拉起，告知 CPU 有中斷發生。在 ARC b 時，當 CPU 收到中斷，則將 ireqack 訊號拉起，告知外部中斷控制器已收到中斷。在 ARC c 時，外部中斷控制器將 ireqval 訊號拉下，並等待 CPU 將 ireqack 訊號拉下(在ARC d 時)，表示 CPU 可接收新的中斷觸發。

圖表5. EVIC Interrupt Request Level Transfer Sequence

1.3 System Register Setting
關於上述兩種中斷模式的選擇，使用者可透過設定 AndesCore™ N968A-S內部的一個 system register 來達到目的。
該 system register 為 Interruption Vector Base Register(ir3)。其中的第 13個 bit 決定不同的中斷模式。其格式如下：

2. Reference Design Architecture
在介紹完中斷處理模式相關定義之後，本章節提供在實際整合與應用上的範例，讓使用者可更了解在不同中斷處理模式下的差異。

2.1 主要架構
本次所實作的 Reference Design 主要是架構在 Andes mini-platform 上，搭配 AndesCore™ N968A-S 為主要 CPU 來控制相關周邊裝置。其主要架構如下圖：

圖表 8. Architecture of Reference Design

將 AndesCore™ N968A-S 整合在 AHB-Lite Bus 上，藉由 APB Bridge 和 APB Bus 溝通，而相關的周邊裝置則整合在 APB Bus 上。在本次範例中，主要會用到GPIO 和INTC(中斷控制器)這兩個周邊裝置，在不同的中斷模式下，利用GPIO 來觸發中斷，再透過 INTC 與 CPU 溝通，觀察不同中斷模式下中斷的處理方式。

2.1.1 Design Scenario in IVIC
在 IVIC 模式下，由 GPIO 觸發中斷(gpio_int signal)，直接將中斷傳遞給CPU(int_req signal)。當 CPU 接收到中斷時，即可去處理相關的中斷處理程式。相關裝置之間的整合如下圖所示：

圖表 9. Design Scenario in IVIC

2.1.2 Design Scenario in EVIC
在 EVIC 模式下，由 GPIO 觸發中斷(gpio_int signal)，INTC 收到中斷後，會將中斷訊號和相關溝通訊號傳遞給 CPU(int_req signal & evic_ireqval signal)。當 CPU 接收到中斷時，會將回應訊號拉起(evic_ireqack signal)，告知INTC 收到該中斷，並去處理相關的中斷處理程式。相關裝置之間的整合如下圖所示：

圖表 10. Design Scenario in EVIC

2.2 Example Code
以下將 Reference Design 中，就本次中斷處理模式相關的整合程式部分和測試程式部分，摘要出來說明。

2.2.1 整合程式部分
在系統整合部分，包含 AndesCore™ N968A-S 和 INTC 在不同的模式下，整合相關的訊號線，其中透過 EVIC_MODE 參數來進行不同模式間的切換。

AndesCore™ N968A-S 相關 RTL 片斷：
evic_ireqval 訊號在 EVIC 模式下由 INTC 觸發給 CPU，在 IVIC 下可直接給予 0 值。int_req 由 INTC 或中斷來源傳遞給 CPU，告知 CPU 中斷產生。evic_ireqack 在 EVIC 模式下由 CPU 觸發給 INTC，告知 INTC 收到中斷。

INTC 相關 RTL 片斷：
此中斷控制器可透過 evic_mode 這個輸入訊號，來決定該裝置是處於 IVIC 模式或是 EVIC 模式，因此，在 EVIC 模式下，給予 1 值，設定為 EVIC 模式，在 IVIC 下，給予 0 值，設定為 IVIC 模式。ireqack 訊號在 EVIC 模式下由 CPU 觸發給 INTC，告知 INTC 已收到中斷，在 IVIC 模式下則給予 0 值。

2.2.2 測試程式部分
在測試驗證部分，包含 AndesCore™ N968A-S 在不同中斷模式下的設置、INTC 相關中斷狀態的設置和 GPIO 觸發中斷的設置。

AndesCore™ N968A-S 相關程式片斷：
AndesCore™ N968A-S 支援兩種中斷處理模式，透過 CPU 內部的 system register 來設置。主要為設置 Interruption Vector Base Register，該 register 的第 13 個 bit 用來定義 CPU 處在何種中斷處理模式。在 EVIC 模式下，需將該 bit 設置為 1，在 IVIC 模式下，則將該 bit 設置為 0。

INTC 相關程式片斷：
INTC 通常支援不同的中斷觸發方式，包含 Interrupt Masking、Interrupt Trigger Mode、Interrupt Trigger Level …等。在開始使用每個中斷來源之前，這些控制選項都必須在 INTC 上設定正確。

3. 模擬結果
將上述的 Reference Design 整合完成後，搭配測試程式進行模擬，並藉由波形圖來觀察不同中斷模式下，相關中斷訊號線的變化。

3.1 IVIC 模擬結果
在 IVIC 模擬環境中，主要測試程序如下：
• 由 GPIO 觸發一中斷，並將中斷傳遞給 CPU
• CPU 接收到中斷後，執行相對應的中斷處理程式
模擬結果如圖表 11 所示，當 GPIO 觸發中斷後，將中斷直接傳遞給 CPU，在CPU 端的 int_req 訊號線會觸發，表示有中斷發生。當 CPU 收到中斷訊號後，接著會處理相對應的中斷處理程式。

圖表 11.Simulation Waveform of IVIC

3.2 EVIC 模擬結果
在 EVIC 模擬環境中，主要測試程序如下：
• 由 GPIO 觸發一中斷
• 此時 INTC 設罝為 EVIC 模式，並將中斷訊號和相關溝通訊號傳遞給CPU
• CPU 接收到中斷後，會將回應訊號拉起，告知 INTC 收到該中斷，並執行相對應的中斷處理程式
模擬結果如圖表 12 所示，當 GPIO 觸發中斷後，INTC 將中斷和相關溝通訊號(ireqval)傳遞給 CPU，在 CPU 端的 int_req 訊號線和 evic_ireqval 訊號線會觸發，表示有中斷發生。當 CPU 收到中斷訊號後，會將 evic_ireqack 訊號線拉起，告知 INTC 收到中斷。模擬結果如同章節 1.2 和圖表 5 所論述。

圖表 12. Simulation Waveform of EVIC

結語
在 AndesCore™ N968A-S 所提供的兩種中斷模式裡，其中的 IVIC 模式使用 CPU 內的中斷控制器來處理中斷，此模式對使用者來說，只要將中斷來源和CPU 端的中斷訊號連接即可，相當容易整合。若使用者所設計的系統裡，中斷來源數目超過 IVIC 模式所支援，或者系統需要更複雜的優先權選擇時，則可選用 EVIC 模式。在 EVIC 模式下，使用者需額外設計外部中斷控制器，並整合相關溝通訊號。因此，使用者可根據本身系統的複雜度和整合的難易度，來選擇適合的中斷處理模式。

如何應用 AndesCore™ EDM 安全存取機制

Post author:Lee Claire
Post published:2013-01-18
Post category:技術文章

沈永勝，技術副哩，晶心科技股份有限公司

EDM 安全存取是 AndesCoreTM 內建的功能(option)，應用在安全存取的控管。EDM 安全存取有二種的控管方式:debug access indication 和 EDM access restriction。第一種控管方式(debug access indication)提供了一個 sideband signal 用於指示從調試器(Debug host)的請求。第二種控管方式，控制AndesCore^TM 的 input port (edm_restrict_access )達到 EDM 存取的限制。更詳細的內容在後續章節會有更深入的介紹。

1. EDM功能介紹
一個 debug system 包含一個 debug host 和一個 target system。EDM 主要的功能就是 translate debug host 發出的 TAP 指令來存取系統 memory 或是 CPU。
圖表 1 為基本的 debug 系統方塊圖：

圖表 1 基本的 debug 系統方塊圖

圖表 2 說明 TAP 指令的種類：

圖表 2 TAP 指令的種類

2. 控制EDM存取的限制
使用 EDM 的訪問方式會被一個 sideband signal (edm_restrict_access) 所影響。當這個 signal 值是 high，僅僅只能對 EDM MISC registers 做讀取的動作。而想要存取CPU/System Bus/Local Memory 的動作將會被封鎖住並且會得到下面的結果：

讀為零寫忽略
不正確的 JTAG instruction(JTAG ICE debugger 會 timeout)

圖表 3 說明 EDM 限制存取方塊：

圖表 3 EDM 限制存取方塊圖

在啟用存取限制功能後，圖表 4 說明出每個 TAP 指令的行為：

圖表 4 TAP 指令的行為

如何實現 EDM 存取限制，在系統設計上有很多種實現方法，以控制 edm restrict access 的 signal。兩種基本的設計方案說明如下：

eFUSE 方式使用 Chip 重新編程管理控制
SOC 方式使用軟件管理控制

圖表 5 所示為 hardware 實現控制 edm_restrict_access 的示意圖如下：

software 實現控制 edm_restrict_access 的例子如下：

sethi $r2,#0x80000
ori $r2,$r2,#0x8c
sethi $r3,#0x04030
ori $r3,$r3,#0x201
swi $r3,[$r2+#0]

3. EDM 存取指示
AndesCoreTM 增加一個額外的 sideband signal，xdebug_access(active-high)，根
據此 sideband signal 來決定 request 的 host 是否為 EDM。而 device 就能根據此
sideband signal 決定是否要把 request 的 data 內容傳回到host。
sideband signal 的名稱根據 bus interface 的類型而有所不同。對於AndesCoreTM
處理器，基本的信號名稱如下所示：
• AHB/AHB-Lite => hdebug_access
• APB => pdebug_access
• EILM => eilm_debug_access
• EDLM => edlm_debug_access

3.1. debug 存取識別信號控制
當 debug exception 發生後，CPU 將進入debug mode。然後 CPU 將會留在 debug access mode 直到CPU 執行到 IRET instruction 並且 trusted_debug_exit 是處於high 後CPU 將離開 debug access mode，反之 trusted_debug_exit 如果是low， CPU 將會保留在debug access mode。
實現控制 trusted_debug_exit 信號，有二種可供選擇的方式如下：
• trusted_debug_exit 信號總是給 high
增加一個權限管理邏輯去控制trusted_debug_exit 信號是high 或是 low 權限管理邏輯方塊圖如圖表 6 所示：

如何控制 trusted_debug_exit 信號時序圖如圖表 7 所示:

如下例子說明了如何產生 trusted_debug_exit 控制信號的verilog code：

The code example (Verilog) of trusted_debug_exit generation is described below:
//
//— Utilize passcode to generate trusted_debug_exit in AHB Bus Controller

//* assume zero-wait-state AHB access
…
parameter AUTH_CODE = 32’h0a0b0c0d;
…
always @(posedge hclk or negedge hreset_n) begin
if (!hreset_n) begin
passcode_reg <= 32’d0;
end
else if (passcode_wen) begin //debugger enters passcode through debug access
passcode_reg <= hwdata[31:0];
end
end
…
//validate passcode to generate trusted_debug_exit
assign trusted_debug_exit = (passcode_reg == AUTH_CODE);

3.2. debug 存取指示應用
圖表 8 說明 AHB bus 如何使用 hdebug_access 和驗證邏輯來防止惡意的 debug
存取

如下 verilog code 說明了如何使用 hdebug_access 信號：

//— Use hdebug_access to prevent malicious debug access in AHB Bus Controller
//* assume zero-wait-state AHB access
…
parameter IRRELEVANT_DATA = 32’hcafe0001;
parameter AUTH_CODE = 32’h01020304;
…
always @(posedge hclk or negedge hreset_n) begin
if (!hreset_n) begin
dbg_acc_d1 <= 1’b0;
end
else begin // data phase indication of debug access
dbg_acc_d1 <= hdebug_access;
end
end
…
always @(posedge hclk or negedge hreset_n) begin
if (!hreset_n) begin
passcode_reg <= 32’d0;
end
else if (passcode_wen) begin //debugger enters passcode through debug access
passcode_reg <= hwdata[31:0];
end
end
…
//validate passcode to check authentication
assign auth_check_fail = (passcode_reg != AUTH_CODE);
//return irrelevant data if the authentication check of debug access fails
assign hrdata_out = {32{data_read_en}} &
((dbg_acc_d1 & auth_check_fail) ? IRRELEVANT_DATA : normal_data_out);

4. 實際的應用
使用者經由上面的介紹完成了權限管理邏輯後，並且掛在 AndesCoreTMAHB bus 上，再經由模擬器(Cadence)模擬此權限管理邏輯的行為，如下面幾張圖所示：

• edm_restrict_access 信號控制
圖表 9 說明由 sw code 把 edm_restrict_access signal disable

• trusted_debug_exit 信號控制

• debug_access 信號
圖表 11 說明經由 debug host 來做存取時，debug_access signal 會從 low 變成 high：

圖表 12 說明經由執行 IRTE instruction 時，debug_access signal 會從 high 變成 low：

5. 結語
EDM 安全存取是 AndesCoreTM 保護周邊裝置內容不被竊取的功能，也因為越來越多客戶使用到此功能，所以撰寫此技術文章讓客戶更能進一步了解到此功能的用途，讓客戶能夠很快速的上手，並且使用晶心開發的 EDM 安全存取是一件愉快與簡單的工作。

當高速 AndesCore 遇上低速Embedded Flash 的晶片效能提升方法

Post author:Lee Claire
Post published:2012-10-29
Post category:技術文章

陳群旻，技術副理，晶心科技股份有限公司

AndesCore™除提供 AHP，APB ，HSMP 介面外，亦可透過 EILM 介面與記憶體整合，使 AndesCore™可以不透過 AMBA BUS 直接透過 EILM 介面擷取指令。然而嵌入式 Flash 的執行速度目前，並不能趕及 AndesCore™的工作頻率， AndesCore™的執行效能將受限於嵌入式 Flash 的執行速度。此時可透過在AndesCore™與 Flash 間的 EILM 介面之間加入一個預取模組，減少 AndesCore™ 因為 Flash throughput 跟不上 AndesCore™ 效能，使執行效能下降的影響。文章中所提供的參考預取模組，以 data width 32 bits 的 Flash 為操作對象，預取 buffer size 為兩道 Instructions (32bits*2)提供一預取機制的設計參考。
本文之目的在提供與介紹一個預取模組的參考設計作為使用者設計預取模組的參考。期望能對使用者有所助益，也希望讀者不吝指教提供您寶貴的意見。

1. Prefetch design 介面介紹
AndesCore™透過 EILM 介面可與外部 external local memory 整合,為了透過Prefetch 模組根據前一道指令擷取時的位址，以 AndesCore™將循序擷取指令為預測邏輯來預取下道指令，並儲存該指令內容於 Prefetch 模組，供 AndesCore™ 循序擷取指令時使用，我們將原本 AndesCore™與 EILM 的整合方式(如圖一所示)，改為在 AndesCore™與 EILM 之間加入 Prefetch 模組的整合方式(如圖一所示)。
AndesCore™透過 EILM 介面跟 Prefetch 模組提交 request，Prefetch 模組透過eilm_wait 告知 AndesCore™該 request 執行是否需要 wait，並在對應的時序提供AndesCore™欲擷取的指令內容。
Prefetch 模組另有介面與 memory (Flash or ROM)整合，透過該介面進行對memory 的讀取。由於坊間 Flash or ROM 有各種 protocol，Andes 提供的 Prefetch reference design 主要專注於提供 prefetch 機制的參考設計，memory 介面以一pseudo Flash 介面為設計對象，使用者後續可根據所使用的 memory 的 protocol 進行調整設計。

1.1 Block Diagram

1.2 Signal Descriptions
Prefetch 模組的 clock 與 reset，與 AndesCore™使用相同的 clock，reset 訊號源作設計，此外有一 input 訊號“ratio”用以設定 AndesCore™與 memory 工作頻率倍率關係。其餘訊號，我們分作兩個群組”EILM”與”MEM”分別說明。

1.2.1. Global signals

1.2.2. EILM
Prefetch 模組透過 EILM 介面與 AndesCore™整合，依循 AndeStar 所定義的 protocol 與 AndesCore™溝通。

以下時序圖說明 EILM 介面 Read/Write 時的訊號

1.2.3. 本次模擬使用的 Flash 介面的訊號
Prefetch 模組的 memory 介面以一 pseudo Flash 介面為設計對象。並以此memory 的 behavior module 與 Prefetch 模組整合後模擬。以下圖表介紹此pseudo Flash 之訊號與工作之時序。

2. Prefetch 模組的主要功能介紹
透過 Prefetch 模組來提升 AndesCore EILM 擷取指令時的效率，減少AndesCore 提出指令 request 後，等待 read data 自 Flash 回覆有效值的等待時間，來增加 AndesCore 的執行效能。
實現方式是以前次 AndesCore 提出指令 request 時，所發出的 address 來預測後續 AndesCore 提出指令 request 的 address 為遞增方式，在 AndesCore 提出指令 request 前，Prefetch 模組先將該遞增 address 的指令內容由 Flash 取回並儲存於 Prefetch 模組中，當 AndesCore 提出指令 request 的 address 確為遞增方式，且指令內容已在 Prefetch 模組中，AndesCore 將不需 wait，可在下一時序即可自Prefetch 模組擷取指令內容。
若 AndesCore 提出指令 request 的 address 為非遞增方式，或是 AndesCore 提出指令 request 的頻率高過 Prefetch 模組預取資料的頻率，Prefetch 模組中已無事先預取的指令內容時，則依然透過 wait 訊號來延遲 AndesCore 擷取指令內容。

2.1 預取功能說明
圖表 10 所示為 Prefetch 模組自 Flash 擷取指令內容的 function 示意圖

Reset 後, Prefetch 模組內並無預取的指令內容，於是執行 general prefetch function，後續當 AndesCore 提出指令 request 為遞增方式，若指令已預取完成，則將指令內容傳給 AndesCore，若指令預取未完成則拉 wait 訊號來延遲AndesCore 擷取指令內容。再以目前 request 的 address 遞增來預取指令。當AndesCore 提出指令 request 不為遞增方式(本文後續稱為 branch)，則拉 wait 訊號來延遲 AndesCore 擷取指令內容，同時 Prefetch 模組自 Flash 擷取該指令，當Prefetch 模組得到有效資料時，撤回 wait 訊號，並將有效資料傳給 AndesCore。再以目前 request 的 address 遞增來預取指令。

2.2 主要程式說明
以下我們剪輯 Prefetch 模組 RTL 程式中幾個重要部分來做說明

2.2.1 branch 判斷:
當一個 AndesCore™ request (instruction fetch)被 Prefetch 模組接受時，若此時的 address 不等於預設的遞增 address，表示一個 branch 發生，Prefetch 模組將跟據 branch 時應有的動作來對 Flash 讀取指令，使用 wait 訊號來延遲 AndesCore，選擇 read data 等。

相關程式片斷:
assign branch= eilm_read_req_valid&((lastest_eilm_ifetch_addr_inc1!=eilm_addr)|eilm_ifetch_n);

2.2.2 prefetch 判斷:
當 Prefetch 模組處於 idle 狀態時，若需要被預取的指令內容，未儲存於Prefetch 模組，則進行 prefetch 的動作，對 Flash 讀取指令，並存放至 Prefetch 模組。 Prefetch 模組預取深度我們設計為 2，故我們會預取下一道(lastest_eilm_ifetch_addr_inc1)及下下一道(lastest_eilm_ifetch_addr_inc2)指令。

相關程式片斷:
assign prefetch_next1= (state_cnt==4’h0)& (~wait_for_write)&
(~((lastest_eilm_ifetch_addr_inc1==addr0)&addr0_valid )&
~((lastest_eilm_ifetch_addr_inc1==addr1)&addr1_valid ));

assign prefetch_next2= (state_cnt==4’h0)& (~wait_for_write)&
(~((lastest_eilm_ifetch_addr_inc2==addr0)&addr0_valid )&
~((lastest_eilm_ifetch_addr_inc2==addr1)&addr1_valid ));

2.2.3 選擇執行 branch, prefetch 或 idle
當 Branch 發生時,不論需要被預取的指令內容是否已儲存於 Prefetch 模組，執行 branch 時應有的動作，若有 prefetch 的動作執行中則放棄。
當Branch 未發生時，需要被預取的指令內容未儲存於 Prefetch 模組，執行 prefetch 時應有的動作，若需要被預取的指令內容已儲存於 Prefetch 模組，Prefetch 模組處於 idle。

如何在晶心平台實作 ROM patch

Post author:Lee Claire
Post published:2012-07-24
Post category:技術文章

賴歆雅，技術經理，晶心科技股份有限公司

筆者曾協助多家公司工程師，在 AndesCore™上發展 firmware。我們發現，當客戶開發 Non-OS 的程式碼，最常遇到的問題在於開發者不知如何撰寫 linker script。網路上有 GNU ld 的使用文件，但是 linker script 的範例太少，尤其開發者需要撰寫進階的 linker script，常常不知如何下手。

本篇文章我們分享如何實作 ROM patch。使用晶心 CPU 建構的 embedded system，一般具有 CPU、週邊 IP 及 RAM、ROM。部份客戶使用 ROM code 開機，程式碼放在 ROM 內，data section 放在 SRAM 裡。ROM code 的特性是成本低，跟著 IC 光罩一起生產，當 IC 製作完成即不可修改，若有製作上的錯誤或是程式碼邏輯上的錯誤，只能用 ROM patch 的方式修補。也就是將需要修補的程式碼放到小容量的 flash 裡。這就是我們今天要分享的技術。

1. 主程式架構
首先介紹主程式的架構。IC 的 Memory layout 如下圖

紅色框線的部份，為主程式編譯的範圍。主程式 main 會呼叫到 func1、func2
和 func3 這 3 個 function。

在上圖中，黃色區域是 IC 的 ROM，這部份的程式是 IC 製作出來即不可以改變。綠色部份是 flash。在圖中，flash 分成 2 區，一個是 jump_table，存放 func1~func3 的位址。剩餘的空間 FUNC_PATCH，預留給 patch 使用。

為了要修補 ROM 內的 function，所以規劃出 jump_table 區域，原本都是指向ROM 的 function。如果 ROM 裡的部份 function 損壞或是需要改寫，就把jump_table 改為指向 FUNC_PATCH 裡新建的 function。

1.1 原始程式碼
主程式的程式碼如下：(main.c)

1.2 主程式 linker script (僅列需要修改的部份)

Flash 的位址由 0x510000 起，將 FUNC_TABLE 固定在 flash 的最開頭，語法如上。

1.3 主程式執行結果

2. 經過Patch之後的架構圖
假設 ROM 裡的 func2 損壞，要改用 flash 裡的 func2。需要更改指向 func2 的指標，及 func2 的內容。如下圖：

用紅色框線標起來的地方，表示為 patch 編譯的範圍。其中 jump table 在這裡重新編譯，指向新的位址。

2.1 實作方法圖
(1) 匯出主程式的 symbol table。
在主程式的 Linker flags 加上-Wl,–mgen-symbol-ld-script=export.txt ，ld 會產生 export.txt 這個檔案, 這個檔案包含了一個 SECTION block 以及許多變數的位址。如下圖所示

Linker script 在 import Main program 的 symbols 時，除了需要修改的 func2 不要 import 之外，其他的 symbols 全部要 import 進來。(將 export.txt 刪去這一行： func2 = 0x005001c4; /* ./main.o */)
(2) patch 在編譯之前，先匯入主程式的 symbol table。(將 export.txt 檔案放在一起編譯)。Patch 的 linker script 要匯入主程式的 symbol，寫法如下面紅色字體。

(3) patch 的程式碼裡如下，沒有 main function，也不要加入 startup files。改寫 func2。func2 放在 flash 的 FUNC_PATCH section。並且將 jump_table 裡的 func2，改成指向新的 func2。

(4) patch 的 linker script，加入 FUNC_PATH 在 jump_table 之後。

3. 如何除錯
首先，將程式碼存放在 IC 的 ROM 及 flash 裡。(本文為了示範，我們的做法是在 AndeShape™ ADP-XC5 的 FPGA 板上，用 RAM 模擬 ROM 及 flash，分別將主程式和 patch 的 bin 檔 restore 到板子上。)

當 gdb debug 時，載入 patch 的 symbol。以下節錄 gdb 指令。

上面過程中，先載入 main 的 symbol，再載入 patch 的 symbol 及 debug information。”add-symbol-file patch.adx 0x500000 -s FUNC_TABLE 0x510000 -s FUNC_PATCH 0x510020″是將 patch section 的 symbol 及 debug information 也載入 gdb 以 debug。讀者可以在 gdb 裡，打”help add-symbol-file” 查閱 add-symbol-file 的用法。

3.1 主程式 patch 後的執行結果

4.結語
目前晶心科技使用GNU的toolchain，其功能非常強大。讀者可多動手試試不同的linker script寫法，使得開發firmware更有彈性及效率。

如何移植 Linux 到晶心平台

Post author:Lee Claire
Post published:2012-03-06
Post category:技術文章

沈智明，資深技術經理，晶心科技股份有限公司

有鑑於越來越多使用者將 Linux 移植在晶心平台(Andes Embedded™)的上(AndesCore™ N12 或 N10)，本文之目的在協助使用者快速、有效率的將 Linux 移植到自建的 FPGA 板子上(CPU 是 AndesCore™ 的 N12 或 N10)。筆者曾協助多家公司工程師進行 Linux 移植到晶心平台的工作，將 Linux 移植過程容易遭遇的問題與盲點進行實務說明，期望能對使用者有所助益，也希望讀者不吝指教提供您寶貴的意見。

在進行實務的 Linux 移植時會發現，使用者的晶心平台可能會有各式各樣的組合，除了 CPU 是使用 N12 或 N10 外，使用者對於其他的周邊(如 RAM，ROM， Timer…..)之搭配各有所好，為了有系統性說明 Linux 移植的要領，將選定一明確的硬體，軟體，與開發工具(toolchain)環境做演練說明，除了讓讀者可以實作明瞭文中之敘述，當使用者的周邊非原設計之硬體(使用者自己的 IP)時，可以運用移植的基本原則，更改希望移植 IP 的 Linux 驅動程式，其他原始碼不動，逐一的將使用者的周邊驅動程式移植到晶心的平台。

在 Linux 移植過程中，使用者須建立一基本觀念，那就是整個 Linux OS 可分為兩部分，第一部分是與硬體相關的 HW dependence code，這部分的程式碼會因對應不同的硬體而造成軟體部分需做不同程度的改寫；第二部份是與硬體無關的 generic code，這部分的程式碼與硬體無關，純軟體運作，不會因平台(Andes, X86, Arm..)的改變而有差別。移植 Linux 的工程師第一步需要能區分出哪一部分程式碼是 HW dependence code，另外部分的程式碼就是 generic code，如果在這階段對程式碼判斷錯誤(HW dependence code/generic code)會拖延 Linux 移植的時程與增加除錯時的困難。

Linux 移植到晶心平台過程中，首先須先做到 Linux 基礎架構移植成功。在除錯時，Linux 的基礎架構元件是 CPU，timer，interrupt 與 UART，當 CPU 與這 3 項周邊移植成功後，scheduler 可以運行了，printk 也可以運行了 Linux 系統已經可以正常的運作了。接下來的工作只需將需移植的驅動程式一個一個移植即可，基礎骨架移植完成後，除錯也有 printk 可用，接下來只需將肉 (需要加的device drivers) 填上即可。Linux 移植比較困難的地方是 Linux 基礎架構尚未完成之前(Linux 移植的初期階段)的除錯，所幸晶心提供的標準除錯工具與AndeShape™的除錯器 AICE，可以一步一步找出問題之所在，讓初期移植 Linux 的除錯也變得很簡單，具體得作法，後文會詳細說明。本文敘述著重在如何建立Linux 基礎架構在晶心平台，至於個別 Linux 驅動程式的移植，坊間有許多的書在介紹，本文就不多加贅述。

1. 開發環境與程序
使用者開始進行 Linux 移植到晶心平台，首先須先選定一版晶心的 Linux 原始碼作為基準再進行軟體移植，修改原始碼以符合使用者的開發平台，經由工具列的compile 與 link 所產生的 Linux 的映像檔，再放上 FPGA 板子以驗證程式編寫的正確與否，依此開發程序:軟體編寫->FPGA 板子驗證，再回到軟體編寫程序直到所有周邊IP 在FPGA 板子驗證完全，Linux 移植才完成，如圖表 1 所示，Linux 移植過程中，AICE 除錯可以有效加快 Linux 移植的速度。

選定一組 Linux 原始碼，工具列，FPGA 板子與 netlist 作為晶心的平台(於1.1,1.2,1.3 中所述)，作為使用者的平台的對照組，經由使用者的平台與晶心的平台比對可以有效縮短產品開發時程。

1.1 晶心版 Linux 原始碼
目前晶心最新版本的 Linux 原始碼在 AndeSoft™的 BSP310 中，Linux 原始碼放在 BSP310 套件位置: BSPv310/source/Linux/linux-2.6.tgz。使用BSP310 中的 ramdisk ”xc5_glibc_ramdisk.img”作為 filesystem。

1.2 工具列
此晶心平台選用的工具列是 AndeSoft™的 nds32le-linux-glibc-v2。

1.3 FPGA 板子與 netlist
FPGA 板子是晶心 AndeShape™的 XC5 開發板。Netlist 是選定晶心AndesCore™的 N10 production version.

移植平台是指使用者要移植 Linux 的平台，也就是移植 Linux 的目標平台。將移植平台與晶心平台的比較列表如下: (其中所列之軟體皆屬於 BSP310 中之套件)。

2. Boot loader
如果使用者有自己慣用的 boot loader，可以使用慣用的 boot loader 以加快開發時程，如果沒有 boot loader 的開發經驗，可以選用 u-boot 作為系統的 boot loader.。u-boot 的 source ocde 位置在BSPv310/source/Standalone/u-boot/u-boot.tgz。

2.1 U-boot
AndeSoft™的 BSP310 中 u-boot source code 是需要 EBIOS boot up 後再執行的 u-boot 版本。直接 boot up 不需要其他軟體協助的 U-boot 版本(ROM 版) 是比較符合使用者的需要，晶心版的 u-boot 使用方法請參考 BSP310 User
Manua。l 如果要 ROM 版的 u-boot 需要在 BSP310 中的 u-boot 軟體做 patch，
其指令如下:
# patch -p1 <burn-mode.patch
 patching file arch/nds32/cpu/n1213/ag101/cpu.c
 patching file arch/nds32/cpu/n1213/start.S
 patching file arch/nds32/include/asm/u-boot-nds32.h
 patching file arch/nds32/lib/board.c
 patching file board/AndesTech/adp-ag101p/config.mk
 patching file include/configs/adp-ag101p.h

patch 完成的 u-boot source code 可以產生 ROM 版的 u-boot image，直接開機後的執行結果如圖表 3 所示。

3. 除錯環境
在移植 Linux 到晶心平台之前，先架設好除錯的環境，尤其對底層 Linux 原始碼的移植，有莫大的助益，在 printk 尚未正常運作前，需依靠 AndeShape™的 AICE 與 AndeSoft™的 GDB 來進行除錯。

3.1 設定 Linux kernel 除錯選項
Linux Kernel 需要設定一些除錯選項，才能順利的運用 AndeSoft™的 GDB 進行除錯。晶心平台中 Linux kernel 除錯選項設定如圖表 4 所示，增加這些選項會增加 kernel 映像檔的空間，如果空間佔用過大以至於不符合設計需求時，可在除錯工作完畢後將除錯選項關閉以節約不必要的空間浪費。

3.2 Linux kernel 除錯的程序
Build 成 kernel bootpImage (含 kernel debug message 如圖表四選項) 後， Linux 的映像檔放到 FPGA 板子上，PC host 端的 AndeSoft™的 GDB 透過網路(socket)與 AICE 連接至 FPGA 板子，進行除錯的工作。

3.2.1 編譯鏈結成映像檔
設定好 AndeSoft™的 cross-compiler 路徑後，利用下列指令經由 compiler and linker 後可以得到 bootpImage，指令如下:

#CROSS_COMPILE=”nds32le-linux-” ARCH=”nds32″ make xc5_defconfig
#CROSS_COMPILE=”nds32le-linux-” ARCH=”nds32″ make menuconfig
# CROSS_COMPILE=”nds32le-linux-” ARCH=”nds32″ make bootpImage
INITRD=xc5_glibc_ramdisk.img

將生成的 bootpIamge 放到 FPGA 板子上，將 AICE 連接到 FPGA 板子啟動
ICEman，指令如下:

#C:\Andestech\AndeSight200MCU\ice>ICEman.exe –p 1234

PC host 端的 AndeSoft™的 GDB 透過網路(socket)與 AICE 連接至FPGA 板子，進行除錯的工作，示範指令如下:

#ddd –debugger nds32le-linux-gdb vmlinux
gdb>target remote 10.0.2.164:1234

其中IP 值 10.0.2.164 是一個應用範例，使用者可依環境實際 IP 值進行設定。環境設定完成後，可以開始進行除錯工程。

4. 移植Linux至晶心平台關鍵點經驗傳承
4.1 Kernel 載入程式除錯實作
kernel 載入程式目的將 kernel 主程式進行解壓縮並載入正確位置，此程式與kernel 主程式是兩個不同程式，但會一起包在 zImage 中只是 kernel 載入程式會 attached 在 zImage 的前面。除錯時需 file 不同的 ELF file 才能進行正確的除錯工作，kernel 載入程式的位置在
arch/nds32/boot/compressed/vmlinux，指令如下所示。
#ddd –debugger nds32le-linux-gdb arch/nds32/boot/compressed/vmlinux

kernel 主程式的 ELF file “vmlinux”在 kernel source code 的根目錄下指令如下所示。
#ddd –debugger nds32le-linux-gdb vmlinux

4.2 Linux kernel 除錯實作
kernel 載入程式執行完畢後會跳到 kernel 主程式執行。進入點是arch/nds32/kernel/head.S 的 assembly code 執行完後會進入 kernel 的主要函數 “start_kernel”。

4.2.1. RAM offset patch
晶心版 Linux 原始碼搭配 XC5 平台，RAM 的起始位置(指的是 PA)是 0x0，使用者 FPGA 開發板的 RAM 起始位置如果不是 0x0，必須要修改 FPGA 板子中 RAM 的起始位置，做法是在晶心版的 Linux 原始碼中進行 RAM address patch，將原始碼中 RAM 位置調整到 FPGA 開發板中 RAM 的真實位置。

4.2.2. PA/VA remap table
當 FPGA 板子 IO 的 PA 設定正確後，使用者需要設定 PA/VA remap table，作法可參考 arch/nds32/include/asm/spec-ag101.h，依照 apec-ag101.h 中PA/VA 對應的關係去增減使用者自己 IO device 的 PA/VA remap table。

4.2.3. Kernel 解壓縮與 software breakpoint
在進行 kernel 除錯時，如果在低位址處，例如:head.S 中進行除錯，當設定software breakpoint 時，會有 breakpoint 無法停下來與 AICE 斷線的情況發生。原因是當使用者設定 software breakpoint 時，breakpoint 處的 instruction 會修改並加入 break instruction。但 kernel 解壓縮時會將除錯的程式碼覆蓋造成與 GDB 除錯不一致性而產生錯誤。解決的方法就是原設定 software breakpoint 改為 hardware breakpoint，這樣就可以避免因 kernel 解壓縮所造成除錯的錯誤，降低除錯時的困難度。

4.2.4. PA/VA 觀念說明與除錯要領
在原始碼 arch/nds32/kernel/head.S 中
la $lp, mmap_switched
mtsr $lp, $IPC
iret

執行完 iret 後，系統就會從 PA 轉成 VA，MMU translation status 從translation off 轉為 translation on 在此分界處除錯規則如下所述，如果觀念不清楚及容易產生除錯時的錯誤，請務必牢記。

4.2.4.1. MMU translation off 時期除錯
在這個時期除錯，VA 是不存在的。所有的 IO address 與 memory 都是 PA 沒有 VA，如果除錯位址設成 VA，容易 hit illegal address 而造成 exception。

4.2.4.2. MMU translation on 時期除錯
在這個時期除錯，PA 是不存在的。所有的 IO address 與 memory 都是 VA 沒有 PA，如果除錯位址設成 PA，容易 hit illegal address 而造成 exception.

4.2.5. 移植 Linux 的基礎元件
MMU translation on 後，很快就會進入 start_kernel 函數，接下來移植的重點就是移植 Linux 基礎元件，那就是 interrupt，timer and UART。當這 3 個device 移植成功後，Linux 的架構就建立起來了，printk 也可以用了，Linux 已經可以正常的運作。如果沒有意外，可以執行完 kernel 甚至將 filesystem 帶起來。接下來使用者可以將自己的周邊元件一個一個的 device driver 移植入系統。當周邊元件移植完成後，Linux 系統移植到晶心平台就完成了。

5. 結語
Linux作業系統運作在晶心平台已有多年的時間。各式各樣的Linux軟體運作在晶心平台不計其數。皆可證明Linux作業系統運作結合晶心平台是一個穩定與成熟的產品，只要能明瞭熟悉Linux 移植的技巧與重點，使用晶心平台開發Linux的產品將是一件愉快與簡單的工作。

µC/OS-II 在AndesCore N1033A-S 上的移植

Post author:Lee Claire
Post published:2011-08-02
Post category:技術文章

周傑，應用工程師，晶心宏科技（杭州）有限公司

µC/OS-II 是一種代碼公開、可裁剪的嵌入式即時多工作業系統。該內核通過實現搶佔式任務調度演算法和多工間通信等功能，使之具有執行效率高、即時性能優良等特點。另外，其佔用空間非常小（最小可裁剪至 2KB）並且具有高度可攜性，因此被廣泛的應用於微處理器和微控制器上。

晶心科技 (Andes)作為亞洲首家原創性32 位元微處理器IP 與系統晶片平臺設計公司，推出的 AndesCore™ N10 系列產品 N1033A-S，搭配應用廣泛的嵌入式即時操作系統 µC/OS-II 以及相關的軟硬體開發資源，有效的説明客戶降低現有成本、提升系統效能、減少系統功耗，並縮短產品開發上市時程。本文將介紹如何將 µC/OS-II 移植到 AndesCore™ N1033A-S 處理器上。

1. 開發環境及處理器介紹
1.1 軟/硬體開發環境
本移植過程使用的軟體環境是 AndeSight™ v1.4 集成開發套件，它是晶心科技最新推出的針對各種 AndesCore™的軟體整合式開發環境，包括編譯器、調試器、分析器以及強大的 ESL 工具。硬體平臺採用晶心科技的 FPGA 評估板ADP-XC5，該評估板採用 AndesCore™ N1033A-S 作為處理器內核，並具有豐富的片上資源。

AndesCore™ N1033A-S 介紹
AndesCore™ N10 系列產品 N1033A-S 是一款哈弗結構的 32 位RISC 處理器內核，具有 5 級流水線(pipeline)及動態分支預測(Dynamic branch prediction) 架構。N1033A-S 新加入了最新 AndeStar™ V2 指令集，把 CPU 效能推至1.66DMIPS/Mhz 之上。同時還實現完整的 Audio 指令集，達到完全整合 CPU 與 DSP 功能的目標。N1033A-S 還支援向量中斷模式以及 2D 直接記憶體存取(DMA)功能，更為即時信號處理添增效能。

2.µC/OS-II 在 N1033A-S 上的可攜性分析
µC/OS-II 具有高度可攜性，目前已經移植到近 40 多種處理器體系上，涵蓋從 8 位到 64 位的各種 CPU（包括 DSP）。
µC/OS-II 的正常運行需要處理器平臺滿足以下要求： 1)處理器的 C 編譯器能產生可重入代碼；2)用 C 語言就可以打開和關閉中斷；3)處理器支援中斷，並且能產生定時中斷；4)處理器支援能夠容納一定量資料的硬體堆疊；5)處理器有將堆疊指標和其它 CPU 寄存器讀出和存儲到堆疊或記憶體中的指令。
AndesCore™ N1033A-S 內部提供了 32 個通用寄存器，其中 R31 被用來做專門的堆疊指標。32 根位址線最多可訪問 4GB 存儲單元，因此只要系統 RAM 空間允許，堆疊空間理論不會產生限制。N1033A-S 處理器提供的 AndeStar™ V2 指令集包含了豐富且十分高效的對堆疊進行操作的指令。例如指令 SMW（store multiple word）可實現僅使用一條指令將多個寄存器的值存儲到堆疊中並同時更新堆疊指標位置，而且還能很好的處理位址非對齊字的存取。N1033A-S 支援中斷並能產生計時器中斷，處理器中的 PSW（Processor Status Word）寄存器中包含一個全域中斷禁止位 GIE，控制它便可實現打開和關閉中斷。此外， AndeSight™整合式開發環境中內置的編譯器可以產生可重入代碼，並且支援內聯彙編，C 環境中可以任意進行開關中斷的操作。綜上所述，µC/OS-II 完全可以移植到 N1033A-S 上運行。

3. 移植步驟
為了方便移植，大部分的 µC/OS-II 代碼是用 C 語言寫的，使用者只需要用 C 語言和組合語言寫一些與處理器相關的代碼就可以實現移植。這部分工作的內容包括：一個完成基本設置的標頭檔 os_cpu.h、一個與處理器相關的彙編檔os_cpu_a.S 和一個與作業系統相關的 C 代碼檔 os_cpu_c.c。

3.1 在 os_cpu.h 中完成基本的配置和定義
3.1.1. 定義與處理器相關的資料類型
為保證可攜性，µC/OS-II 沒有直接使用 C 語言中的 short、int 和 long 等資料類型的定義，因為不同的處理器有不同的字長。對於 N1033A-S 這樣的 32位處理器，其資料類型定義實現如下：

3.1.2. 定義中斷禁止/允許宏
做為即時內核，µC/OS-II 需要先禁止中斷再存取碼臨界區，並且在訪問完畢後重新允許中斷。µC/OS-II 定義了兩個宏來禁止和允許中斷： OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()。在N1033A-S 處理器上的實現代碼如下：

GIE_SAVE 和 GIE_RESTORE 的實現如下：

中斷禁止時間是判斷系統即時性的重要指標之一。中斷禁止時間能否達到最短，不僅與作業系統的設計有關，還依賴於處理器結構和編譯器產生的代碼品質。

從上面的實現代碼看到，由於 Andes 處理器提供了 setgie.d 和 setgie.e 兩條直接控制中斷的開關的指令，整個禁止/允許中斷的過程經過編譯器產生的機器碼只有 3/2 條，最大限度地減小了中斷禁止時間。

3.1.3. 定義棧增長方向
µC/OS-II 使用結構常量 OS_STK_GROWTH 來指定堆疊的增長方式，設置為 0 表示堆疊從下往上增長，設置為 1 表示從上往下增長。這裡我們定義成後者，即堆疊的增長方向是從記憶體高位址向低位址方向遞減並且堆疊指標總是指向棧頂數據：

3.1.4. 定義 OS_TASK_SW()宏
OS_TASK_SW()是一個宏，它在 µC/OS-Ⅱ 從低優先順序任務切換到最高優先順序任務時被調用的。任務切換只是簡單的將處理器寄存器保存到將被掛起的任務的堆疊中，並且將更高優先順序的任務從堆疊中恢復出來。可採用兩種方式定義這個巨集，使用軟中斷將中斷向量指向 OSCtxSW()函數；或者直接調用 OSCtxSW() 函數，這裡我們採用後者(OSCtxSW()函數的實現將在後面介紹)：

3.2 處理器相關部分彙編實現
µC/OS-Ⅱ 的移植需要使用者編寫三個最基本的組合語言函數： OSStartHighRdy()，OSCtxSw()，OSIntCtxSw()。它們會共用一些代碼，為了方便閱讀將它們寫在同一個彙編文件 os_cpu_a.S 中。

3.2.1 OSStartHighRdy()：運行優先順序最高的就緒任務。
OSStartHighRdy()函數是在 OSStart()多工啟動之後，負責從最高優先順序任務的 TCB 控制塊中獲得該任務的堆疊指標 SP，並通過SP 恢復 CPU 現場以啟動最高優先順序的任務執行。另外 OSStartHighRdy()還必須在最高優先順序任務恢復之前和調用 OSTaskSwHook()之後設置OSRunning 為 TRUE。其實現代碼如下：

3.2.2 OSCtxSw()和OSIntCtxSw()
OSCtxSw()是任務優先順序切換函數，它的作用是先將當前任務的 CPU 現場保存到該任務的堆疊中，然後獲得最高優先順序任務的堆疊指標，並從該堆疊中恢復此任務的 CPU 現場，使之繼續執行，該函數就完成了一次任務切換。
OSIntCtxSw()是中斷級的任務切換函數。由於中斷可能會使更高優先順序的任務進入就緒態，因此為了讓更高優先順序的任務能立即運行，在中斷服務副程式最後會調用 OSIntCtxSw()做任務切換。這樣做能夠儘快的讓高優先順序的任務得到相應的處理，保證系統的即時性能。
OSCtxSw()和OSIntCtxSw()都是用於任務切換的函數，其區別在於，在OSIntCtxSw()中無需再保存處理器寄存器，因為在OSIntCtxSw()之前已發生中斷，所以可以保證所有的處理器寄存器都被正確地保存到了被中斷的任務的堆疊之中。OSCtxSw()和OSIntCtxSw()實現代碼如下：

N1033A-S 處理器定義了四級（0-3）中斷，在各級中斷的轉換時需要保存當前中斷層級的寄存器。調用 OSCtxSw()時，中斷將由 0 級（即沒有中斷）轉到 1 級，所以需要將第 0 級的寄存器 PSW 和 PC 保存到第 1 級的寄存器 IPSW 和 IPC 中。CtxSave 和 CtxRestore 兩個宏用來保存和恢復任務上下文。需要保存或恢復的寄存器包括 32 個通用寄存器（R0-R31）的值、程式計數器(PC)的值以及處理器狀態字寄存器(PSW)的值。宏IntlSwitch n 通過修改 PSW.INIT的值來切換中斷層級。CtxSave 和 IntlSwitch的彙編實現如下（由於 CtxRestore 與CtxSave 過程類似，這裡不做贅述）：

3.3 移植 C 語言編寫的幾個與作業系統相關的函數
µC/OS-Ⅱ 有六個與 CPU 相關的函數：OSTaskStkInit()、OSTaskCreateHook()、OSTaskDelHook()、OSTaskSwHook()、 OSTaskStatHook()、OSTimeTickHook()，它們被定義在 ucos_ii.h 中。其中唯一必須移植的函數是任務堆疊初始化函數 OSTaskStkInit()，其它五個函數必須的得聲明但沒必要包含代碼。因此這裡我們只介紹 OSTaskStkInit()，其代碼的實現如下：

OSTaskStkInit()在任務創建時被調用，負責初始化任務的堆疊結構並返回新堆疊的指標，使得堆疊看起來就像剛發生過中斷並將所有的寄存器保存到堆疊中的情形一樣。除了要保存任務的位址、變數的指標以及處理器狀態字的值外， Andes N1033A-S 處理器還要求用戶保存所有 32 個通用寄存器（R0-R31）、四個用戶寄存器(d0.hi, d0.lo, d1.hi, d1.lo)。還有一點需要注意，在 N1033A-S 處理器中，堆疊指標的地址必須滿足 8Byte 對齊，程式最後一段邏輯即將堆疊指標調整到正確的位置，這一點在編寫其他代碼例如在宏 CtxSave 中同樣需要注意。

4. 結語
基於 AndesStar™架構的優勢，可以很容易的實現 µC/OS-Ⅱ 在 N1033A-S 處理器上的移植。不僅 µC/OS-Ⅱ ，其它嵌入式作業系統也可以很方便地移植到AndesCore™相應的處理器上，例如 Nuclues、FreeRTOS 以及 Contiki。
晶心科技利用 AndesCore™ N1033A-S 高效能的Audio ISA 和 FPGA 開發平臺彈性的設計架構，基於各種 RTOS，為客戶提供了豐富的軟體資源（中介軟體、優化的函式程式庫、應用實例等）以及完整的多媒體語音解決方案，從而説明客戶更快地在Andes 平臺上進行產品開發。

32 位元 CPU 在SoC 設計中的機會與挑戰

Post author:Lee Claire
Post published:2011-04-01
Post category:技術文章

由於 IC 製程的演進，使得系統單晶片（SoC）成為一個趨勢。而 SoC 的複雜度隨著摩爾定律（Moore’s Law），不斷的以加倍的方式成長，IC 設計所面臨的難度也日益增加。另外，由於競爭越來越激烈，產品的價格不斷降低，產品週期不斷縮短，許多 IC 設計公司已經開始深刻的感受到市場挑戰的嚴峻。

一個 SoC 如果用模組化的方式呈現，通常包含了處理器（CPU）、系統匯流排（System bus）、特殊的硬體加速器、數位或類比的週邊、作業系統，以及相關的應用軟體。許多 IC 設計公司為縮短開發時程，降低研發成本及風險，便採用委外的方式取得 SoC 的關鍵技術。最明顯的例子便是 SoC 中最複雜，也最重要的 CPU 核心，而智財授權（IP Licensing）的商業模式便因此產生。MIPS 和 ARM 分別於 1980 及 1990 年代成立，開始 CPU IP 授權的商業模式，如今這兩家公司已是全球前兩大智財授權公司，而這樣的商業模式，也確實為 IC 設計公司帶來了許多好處，它代表半導體產業進一步分工，許多 IC 設計公司開始大量使用已驗証過的模組，加速新技術的導入，產品推陳出新的腳步不斷加快，開發成本卻因此降低，開發時程也縮短。而這樣的模式，更進一步發展出另一個趨勢，也就是平台式設計（Platform-based design）方式。藉由成熟的平台，SoC 設計似乎變得簡單了。但是這樣的發展卻未必是正向的。許多公司開始發現，使用平台式的設計方式，大部份的技術都來自於第三方。雖然成熟的平台可以有效的降低研發成本及風險，但也讓公司遠離了創新之路，產品的規格與競爭者大同小異，為了維持競爭力，許多公司只好不斷往降低成本思考，甚至犧牲毛利，以爭取生存空間。在這樣環境下，思考產品的差異化（differentiation）便成了每個產品規劃者與研發工程師最重要的課題。

晶心科技成立於 2005 年 3 月，主要業務是 32 位元的 CPU IP 授權。公司成員來自四面八方，研發團隊都是國內外在 IC 設計及嵌入式軟體產業非常有經驗的工程師。台灣的 IP 技術發展，一直是整個半導體產業最弱的一環，很少有公司在這個領域耕耘。以 CPU IP 為例，目前都是由國外公司主導，而台灣 CPU 的發展，過去都停留在學術性計劃，直到晶心科技成立，台灣才有第一家以 IP 授權為主要商業模式，提供原創性 CPU 技術的公司。當然晶心科技的使命並不只是為台灣創造出第一個原創性的 CPU IP，更重要的是希望能藉由晶心研發團隊的技術，架構出一個更適合 SoC 使用的 CPU，並幫助 IC 設計公司於規劃及開發產品時，從 CPU 的架構思考，尋找產品的差異化與利基，提升產品的競爭力與價值，創造更大的利潤。為了達成這個目標，晶心科技成立三年多至今，積極投入產品開發的同時，也深切的體認到傾聽客戶的聲音，了解客戶問題的重要性。從我們多次與客戶訪談的經驗中發現，許多 IC 設計公司已經跳脫傳統思維，不再把 CPU IP 當成一個黑盒子（black box）使用，他們希望 CPU IP 具備可客製化的彈性，可以讓他們根據不同應用的特性，調整 CPU 的架構並籍此創造產品的差異化。晶心科技的 CPU 從一開始便以其可組態（Configurable）功能為訴求，主要便是著眼於客戶在選擇 CPU IP 時，並非一味的只追求最佳性能（Performance）在很多應用中，性能、功耗、以及成本的平衡，才是設計的最終目標，也惟有透過 CPU 可組態的特性，客戶才能很方便的根據市場分析的資訊，調整產品性能、功耗、成本之間的 trade-offs，使產品的價值最大化。

圖一為 Andes Core ^TM 的架構方塊圖及其可組態選項。晶心科技從 2007 年10 月到 2008 年 8 月，陸續推出 N12、N10、及 N9 CPU 核心系列，大致完成產品的高、中、低階的佈局（如圖二所示）。Andes Core 的基本設計理念在於追求最高的效能（efficiency）。所謂的效能，指的是性能（performance）、功耗（power）、及成本（cost）的平衡。因此 Andes Core 的設計，只有最常被使用的功能才會出現在基線架構（baseline architecture）中，其他功能則是以可組態的模組呈現，客戶可依照應用的不同，將需求的功能於設計時選入，並利用晶心科技提供的開發工具，分析不同的組態對性能及成本的影響，以決定該組態是否以最低的成本，達到產品的規格。以 MCU 的應用為例，目前很多公司仍使 8 位元的處理器，主要原因便是成本考量。但由於消費性產品演進，許多公司開始思考從 8 位元升級到 32 位元的處理器。在這我們特別強調“升級＂，因為 8 位元的處理器有它不可取代的市場及優點，IC 設計公司使用 32 位元處理器必定有其技術上不得不然的因素，這些因性包括了以下：

1. 對 I／O bandwidth 及記憶體容量的需求急速增加，以固態硬碟（SSD）應用為例，許多低階產品，其控制器依然採用 8 位元處理器。但許多 IC 設計公司也開始意識到 8 位元處理器的設計瓶頸，為了大幅突破資料讀取速度及記憶容量的門檻，採用 32 位元處理器便成為勢在必行。

2. 整合性功能成為消費性電子產品的趨勢：我們發現越來越多的消費性電子已經整合了多媒體的功能，其使用者介面（User interface）也越來越精緻與複雜。而很快的，我們也可以看到很多家電整合上網及智慧型監控的功能。面對這樣的趨勢，很多 IC 設計公司已經意識到惟有 32 位元處理器才能提供足夠的性能與彈性來滿足消費性電子產品功能越來越強大的需求。

然而 IC 設計公司在思考 8 位元到 32 位元的升級時，成本仍然是一項重要因素，因為消費性電子市場的特性就是如此。晶心科技推出 N9 系列 CPU 核心，瞄準的市場便是 MCU 市場中 32 位元的應用。N9 CPU 核心若以 0.13 微米製程，頻率可達 150MHz，CPU 核心的面積只有 0.4mm²，功耗小於 0.038mW/MHz，相較於一般 8 位元處理器，晶片大小（die size）與功耗增加並不多，卻能夠提高 4 倍以上的運算能力，非常適合高速 I／O 控制或網路型家電的應用。同時透過 N9 CPU 核心可組態的特性，客戶可以很容易的用產品線的概念，規劃一系列特性（feature）不同的產品，以區分出不同應用在價格及產品規格上的差異，將利潤最大化。同時 Andes Core 具備指令集可延伸（extendable instruction set）的特性，例如在多媒體應用中，客戶可選用晶心科技所開發的 audio extension，以最經濟、最省電的方式提供如 MP3 播放功能。晶心科技的 audio extension 包含了 40 多個指令，這這個指令集延伸是以可組態方式呈現，透過這個指令集，Andes Core 在使用不超過 15MHz 頻寬的情況下，便可順暢播放一般 MP3 歌曲。

除了 CPU 的架構及性能，另一個評估 CPU IP 的重點是開發工具。相較於 8 位元，32 位元應用的一個明顯的特色是軟體的複雜度。以上網型產品為例，CPU 除了扮演控制器的角色外，還需要同時處理網路協定及透過網路所傳輸的資料，這些不同的應用軟體，通常需要一個嵌入式作業系統擔任管理者的角色，以協助CPU 有效的執行多重任務（multi-tasking）。當軟體架構越來越複雜時，CPU 所提供的工具鏈（tool chain）（如 compiler、assembler、debugger）、以及分析 CPU執行效率與每個執行緒（thread）行為的相關工具就變得非常重要。晶心科技的開發環境 AndeSight 採用 Eclipse-based IDE 介面，整合了 GNU-based 工具鏈，分析 CPU 效能的量測工具（profiler），以及模擬 CPU 及 SoC 行為的電子系統層級（ESL）模擬器AndESLive^TM（如圖三所示），能夠讓軟硬體工程師在 SoC 計劃初期，藉由分析不同的 CPU 組態及 SoC 架構對系統性能的影響（如圖四所示），著手系統設計最佳化的工作，實現軟硬體同步開發，縮短整合時間，提高產品研發成功的機率，掌握 SoC 計劃中 Time-to-Market 及成本兩大關鍵。

展望未來，晶心科技將會在既有 N9、N10、及 N12 的基礎上，提出許多更接近應用端的解決方案，豐富產品內容。以晶心科技目前的規模，不可能包山包海什麼都做。我們會選定幾個應用領域，朝垂直整合的策略發展，推出具高度彈性及競爭力的平台式 SoC 解決方案。目前晶心科技鎖定的兩個主要應用為Internet-Enabled MCU 及行動運算平台（Mobile Computing Platform）。在 Internet-Enabled MCU 的應用上，我們將以 N9 為基礎，選用小型的 real-time OS（RTOS）架構軟體平台，結合合作夥伴的技術，開發網路相關的特殊應用軟體。同時我們也會利用指令集延伸的優勢，開發高效能的音訊解壓縮應用程式，並進一步開發高度整合的網路平台，而鎖定的應用便是像網路型數位相框或是上網型家電之類的產品。而在行動運算平台的應用方面，我們在今年底將推出雙核心SoC 平台，整合兩個俱備浮點運算處理單元（Floating Point Unit）的 N12 核心，透過軟體協助的方式提升其平行運算能力。Multi-core 架構是 High performance CPU 的趨勢，晶心科技會持續朝此方向發展，以彰顯我們的技術能力。另外晶心科技也已經開始著手佈局先進的省電技術，於今年底提出電源管理（power management）的解決方案，透過此一技術可大幅降低 SoC 的功耗，解決高階行動運算裝置的電池壽命問題。結合 N12 雙核心及先進電源管理技術，晶心科技所瞄準的應用便是像 Ultra Mobile PC（UMPC）或 Mobile Internet Device（MID）概念的產品。我們將以雙核心架構開發一個 Linux-based 示範性平台（reference platform），整合晶心科技本身或是合作夥伴所開發的多媒體及網路技術及軟體，提供完整的網路多媒體解方案（如圖五所示）。

CPU IP 事業須以持久的承諾經營，晶心科技選擇了一條多重挑戰的路，在這條路上有許多人對晶心不斷的支持與協助，且寄予厚望。無論如何，晶心科技會一直堅持 CPU IP 這條路，以創造品牌的使命感與雄心，搭配專業的市場行銷與技術服務，在我們涵蓋的領域，為 SoC 產業提供更好的解決方案，相信在不久的將來，就會看到已經投入設計之客戶的產品開出、量產，並引領更多專業的SoC 設計公司勇於創新，共同耕耘高科技新市場，達到晶心科技與客戶長期的雙贏。

介紹如何移植 bento4 到 Andes 平臺上

Post author:Lee Claire
Post published:2010-08-03
Post category:技術文章

隨著當今市場對於音訊電子產品功能的需求越來越高，8 位和 16 位的 MCU 逐漸向 32 位的MCU 轉型已經成為市場趨勢。晶心科技(Andes)作為亞洲首家原創性 32 位元微處理器 IP 與系統晶片開發平臺的設計公司，面向 32 位 MCU 市場推出了 Andes Core N9, N10, N12 三个系列的低功耗高性價比的 32 位處理器軟硬核 IP。基於各个系列處理器,晶心科技針對不同音訊應用提供了多種解決方案。包括各種音訊格式的編碼和解碼，如 AAC，MP3，MP4，G729 等移植到 Andes 平臺上。再加上 nds32 架構的優勢和音訊的擴展指令集，以及演算法上的改進，所以編碼解碼器有了進一步的優化，使其代碼空間變小，運行性能變高。本文以MP4 的音訊解碼器為例，介紹如何 bento4 移植到 Andes 平臺上。

1. MP4 簡介:
MP4 為 MPEG‐4 Part14，按照正規的 ISO/IEC 14496‐14:2003 標準，其作為 MPEG－4 的一部分是一個多媒體存儲格式專用的標準。一般常常用來存放數位音訊和數位視訊串流檔(音訊可以是：AAC， MP3，MP2 等,視頻可以是 H.264，MPEG‐4 AVC 等)，也可以存放其他特殊的資料像字幕和靜止圖像。更很多現在的儲存格式一樣MPEG－4 Part14 允許在網際網路上傳輸. 這些檔的尾碼名是.mp4。
MPEG－4 Part14 是基於蘋果公司的Quicktime 儲存格式來實現。MPEG－4 Part14 是基本上和 QuickTime MOV 格式相同，但是它有專門支持 Initial Object Descriptors(IOD)格式和其他的MPEG 特徵。
下面我就詳細的介紹下 MP4 怎樣在我們 Andes 提供的 AndeSight 集成開發工具上解碼。

2. 環境與軟體:
2.1 系統環境:
Linux Fedora8

2.2 開發環境:
AndeSight1.4
AndeSight 是晶心科技提供的一種基於 nds32 架構開發嵌入式工程的圖形化的整合式開發環境。主要由 AndeSight IDE, AndESLive 和 nds32 工具集 3 個部分組成。
AndeSight IDE 為工程師提供了各種友好的介面，包括編輯，編譯，運行，除錯或者評測等操作。
AndESLive 提供了基於 nds32 架構的模擬器和一種圖形化的虛擬 SoC 構建模型，它與AndeSight IDE 相結合為使用者提供了一個虛擬的硬體平臺。這個虛擬評估平臺提供 Andes 自行定義 ISA 的多組系列 32 位 CPU IP 以及各種週邊設備 IP，並且支援用戶自訂 IP 模型。
AndESLive 配合 AndeSight IDE 不僅使得 SoC 設計者能在計畫初期就開始軟體設計、偵錯、最優化等工作，並對系統架構及功能進行檢驗，而且使硬體工程師和軟體工程師具有一樣的能力去製作和修改他們各自的系統模型，可以有效的控制 NRE(NonRecurring Engineering)成本，讓軟體工程師在拿到硬體原型之前，即可以進行軟體的開發和優化。

2.3 交叉編譯器:
nds32le‐linux‐gcc
nds32 工具集中對應不同的Andes Core 型號，不同的系統函式程式庫以及大小端形式等條件，提供了各種對應的交叉編譯器。這裡我們選用 nds32le‐linux‐gcc。

2.4 套裝軟體:
首先要從 http://sourceforge.net/projects/bento4
和 http://sourceforge.net/projects/melo 下載 Bento4‐0.9.4.002 和 Melo‐1.0.0.tar.gz 這兩個包，把他們存放到指定目錄下。

3. Bento4 的移植
3.1 編譯工程
操作的步驟：

第一步：先將下載下來的兩個檔案夾解壓到一個指定的目錄。

第二步：運行 AndeSight1.3，創建一個 Andes C++工程，命名為 Bento4‐EL。

第三步：在 Bento4‐EL 工程中導入所有原始程式碼，找到剛才解壓出來的文檔目錄Bento4‐0.9.4.002,到該目錄下的 Source/C++/，將其中的 Core，Codecs，Metadata，Crypto 和System/下的 StdC 導入 Bento4‐EL 工程。

第四步：找到 Ap4AesBlockCipher.cpp 文件，在該文件的第 90 行加入一句： #define AP4_PLATFORM_BYTE_ORDER AP4_PLATFORM_BYTE_ORDER_LITTLE_ENDIAN。

第五步：先選擇一款 Toolchain，然後編譯 Bento4‐EL 工程指定編譯選項‐static 和
‐EL,AndeSight1.33 默認就是‐static 和‐EL 編譯,所以不需要改動。

第六步：新建一個名為 Melo‐EL 的 C 工程的靜態程式庫，庫的名字命名為 melo.a，找到Melo‐1.0.0 目錄，導入 Melo‐1.0.0/Source 下所有的檔,然後用小端編譯。

第七步：導入 Melo‐1.0.0/Apps/MeloDecode 中的 MeloDecoder.cpp 文件，然後把第 128 行的”MLO_SampleBuffer* pcm_buffer = NULL;”搬到第 121 行，然後保存。

第八步：把所有 Melo/Source 下的.h 檔導入到工程 Bento4 中，並且把MeloDecoder.cpp 一併導入，並且在 Andes CPP Linker 的 Libraries 指定‐lmelo 和‐L path，libraryd 的路徑像： “${workspace_loc:/Melo_2/Debug}” ，然後選擇一款 Toolchain, 再編譯(‐EL)。

3.2 運行工程
以上這些步驟就是所有的編譯過程，最終會成長一個 MP4 decoder 的可執行檔。

接下來是運行的部分：

第一步：說到運行首先要開啟我們的 GDBAgent，在 command line 中進入 GDBAgent 這個目錄，在 command line 上輸入：“./GDBAgent ‐v”，開啟 GDBAgent。

第二步：導入和上面的 Toolchain 相匹配的.vep 文件，如 Andes‐demo.vep(一定要可以匹配的)，然後按兩下它,編輯這個檔，設置 cpu 選項,設置 Data endianness 為 little endian，然後到 vep config 模式下修改 System Call Emulation 的 link library 為 Glibc。

第三步：找一個 mp4 的檔放到 AndeSight 的工作目錄下，或者下面直接用絕對路徑。

第四步：Debug Bento4‐EL 這個工程，在 Debug 對話方塊中，在 Arguments 選項內輸入如：“XXX.mp4 XXX.pcm”，如果你的 mp4 檔不在當前工作目錄下就用絕對路徑。

第五步：然後點擊 Debug 按鈕，你的mp4 文件就decoder 成功了，你會看到有個大容量的.pcm 檔在你指定的目錄下，你可以用 mplayer 去運行它，這裡需要設置他的 Sample Rate 為 44100HZ 和 2 channels，你就會聽到動聽的音樂或清晰的視頻了。

3.3 運行時的 Console

3.4 播放 pcm 文檔
在 linux 系统安裝可以運行 pcm 歌曲的播放器，這里我们使用的是 mplayer，然後使用mplayer 播放 pcm 歌曲。

3.5 總结
以上所述方法即可將Bento4成功的移植到 Andes平台。

基於晶心科技 Andes 平臺的 MP3 移植

Post author:Lee Claire
Post published:2010-08-03
Post category:技術文章

晶心科技 (Andes)作為亞洲首家原創性 32 位元微處理器 IP 與系統晶片開發平臺的設計公司，面向 32 位市場推出了 Andes Core N9，N10，N12 三個系列低功耗高性價比的 32 位處理器軟硬核 IP。基於各系列處理器，晶心科技針對不同音訊應用提供了多種解決方案。其中包括將多種音訊格式的編、解碼器（開源），例如 MP3、AAC、WMA、G729 等移植到 Andes 平臺上。並且利用 nds32（基於 Andes Core）架構的優勢和針對音訊效能的擴展指令集，以及演算法上的改進，對這些轉碼器做了進一步的優化，使其不僅佔用的空間較小而且具備了較高的運行性能。本文以 MP3 解碼器為例，介紹如何將 madplay 移植到 Andes 平臺，以及晶心科技基於N903A 處理器提供的 MP3 解決方案。

1. MP3 簡介
MPEG－1 Audio Layer3（簡稱 MP3）是一種有損音訊編碼方式，它利用掩蔽效應（一種心理聲學模型），將脈衝碼調制（Pulse Code Modulation）音訊資料中人耳聽覺系統無法察覺的那部分資料去掉，使得 MP3 能夠在音質損失很小的情況下把音樂檔案壓縮到很小的程度（1：10 甚至 1：12 的壓縮率）。因為其體積小、音質高的特點，MP3 已經成為當今最為流行的音訊格式。madplay 是目前使用較為廣泛的一種 MP3 的解碼器，下面將詳細介紹如何使用 Andes 提供的 AndeSight 集成開發工具將 madplay 移植到 Andes 平臺。

2. 環境及軟體介紹
2.1 系統環境:
Linux：Fedora8

2.2 開發環境:
AndeSight1.4
AndeSight 是晶心科技提供的一種基於 nds32 架構開發嵌入式工程的圖形化的整合式開發環境。主要由 AndeSight IDE, AndESLive 和 nds32 工具集 3 個部分組成。
AndeSight IDE 為工程師提供了各種友好的介面，包括對嵌入式工程做編輯，編譯，運行，除錯或者評測等等操作。
AndESLive 提供了基於 nds32 架構的模擬器和一種圖形化的虛擬 SoC 構建模型，它與 AndeSight IDE 相結合為使用者提供了一個虛擬的硬體平臺。這個虛擬評估平臺提供 Andes 自行定義 ISA 的多組系列 32 位元 CPU IP 以及各種週邊設備 IP，並且支援使用者自訂 IP 模型。
AndESLive 配合 AndeSight IDE 不僅使得 SoC 設計者能在計畫初期就開始軟體設計、偵錯、最優化等工作，並對系統架構及功能進行檢驗，而且使硬體工程師和軟體工程師具有一樣的能力去製作和修改他們各自的系統模型，可以有效的控制 NRE(NonRecurring Engineering)成本，讓軟體工程師在拿到硬體原型之前，即可以進行軟體的開發和優化。
nds32 工具集提供了一套在 Andes 平臺上開發嵌入式應用程式所需要的標準工具，例如編譯器、除錯器、連結器等等。

2.3 交叉編譯器:
nds32le‐linux‐gcc。
nds32 工具集中對應不同的 Andes Core 型號，不同的系統函式程式庫以及大小端形式等條件，提供了各種對應的交叉編譯器。這裡我們選用 nds32le‐linux‐gcc。

2.4 套裝軟體:
除了源碼外，madplay 還需要 MP3 的解碼庫 libmad，以及 zlib 和 libid3tag 來正確的讀取 MP3 頭段信息。這四個套裝軟體都可以在開源網站上獲得。其中，madplay‐0.15‐1b.tar.gz、libmad‐0.15.1b.tar.gz、libid3tag‐0.15.1b.tar.gz 可以在http://sourceforge.net/project/showfiles.php?group_id=12349 獲取，zlib‐1.2.4.tar.gz 可以在http://zlib.net/獲取。

3. Madplay 的移植
3.1 編譯函式程式庫
3.1.1 編譯 libmad庫
進入 libmad 目錄，首先將如下 nds32 架構和目標平臺運行環境的資訊加入到設定檔 config.sub中（可加到第 675 行）：
nds32*)
basic_machine=nds32‐linux os=‐
linux
;;
然後依次執行：
#CC=nds32le‐linux‐gcc ./configure ‐‐prefix=$PREFIX/MP3_Decoder ‐‐host=nds32‐linux
‐‐disable‐debugging ‐‐disable‐shared
#make植
#make check
#make install
編譯成功後，可以在$PREFIX/MP3_Decoder（$PREFIX 是使用者設定的路徑）目錄下的 included和 lib 目錄裡找到相應的.h 文件和.a 文件。

3.1.2 編譯 zlib 和 libid3tag
需要先編譯 zlib。進入 zlib 目錄後，依次執行： #CC=nds32le‐linux‐gcc ./configure ‐‐prefix=$PREFIX/MP3_Decoder #make
#make install
然後編譯 libid3tag。先將 nds32 架構資訊加入到檔 config.sub 中（方法同 libmad），然後執行如下命令，編譯 libid3tag 時需要用到編譯 zlib 生成的標頭檔和庫檔：
#CC=nds32le‐linux‐gcc ./configure ‐‐prefix=$PREFIX/MP3_Decoder ‐‐disable‐debugging
‐‐disable‐shared CPPFLAGS=”‐I/tmp/MP3_Decoder/include” LDFLAGS=”‐L/tmp/MP3_Decoder/lib”
‐‐host=nds32‐linux
#make
#make install
同樣，在編譯成功後 libid3tag 的相關檔也保存在$PREFIX/MP3_Decoder 目錄下面。

3.2 在 AndeSight 中生成 madplay
在進入 AndeSight 圖形化整合式開發環境之前，需要先對 madplay 源碼中的 makefile 進行配置。首先同樣需要將 nds32 架構資訊加入到 config.sub 檔中，然後執行如下配置：
#CC=nds32le‐linux‐gcc ./configure ‐‐disable‐debugging ‐‐disable‐shared ‐‐host=nds32‐linux CPPFLAGS=”‐I$PREFIX/MP3_Decoder/include ‐lmad ‐lid3tag ‐lz” LDFLAGS=”‐L$PREFIX/MP3_Decoder/lib”
‐‐prefix=/Andestech/AndeSight14/ide/workspace/MP3decoder_madplay
接著打開 AndeSight v1.4，建立一個 STD C（標準 C）工程 mp3decoder，並將madplay 目錄下的所有檔導入工程中。選擇 Project 功能表列選擇 Build Project 一項，成功進行編譯和連結後，在指定的目錄下就會生成madplay 的可執行檔，如圖1 所示。這樣madlpay 就成功移植到Andes 平臺上了。

3.3 測試與驗證
為了驗證移植的正確性，這裡我們採用在虛擬的 Andes 硬體平臺上運行的方式，也就是在AndeSight 中通過 AndESLive 提供的虛擬 SoC 平臺進行模擬。這裡選用 Andes_demo.vep 這個虛擬開發平臺，它與真實的 Andes demo 開發板是一樣的。
選取一首 MP3 格式的歌曲“test.mp3＂拷貝到工程 mp3decoder 的目錄下，然後在運行視窗的Arguments 選項中加入指定輸入檔和輸出的檔的格式：
‐‐output=wave:PATH1/test.wav PATH2/test.mp3（輸出格式還可以為.pcm）。

圖 2 在虛擬 SoC 平臺上運行 madplay

這裡 madplay 運行在虛擬開發平臺的 linux 環境下。運行結束後，在工程目錄下會看到“test.wav＂文件，如圖 2 所示。這個檔可以在 Windows Media Player 進行播放，這樣就驗證了 madplay 移植到 Andes 平臺上的正確性。如果希望 madplay 運行在無操作系統的環境中，只需對 madplay 的源代碼做一些修改（處理與系統調用相關的函數），然後使用 nds32le‐elf‐gcc這款交叉編譯器進行編譯即可。

4. 晶心科技在 MCU 層級的 mp3 解決方案
隨著人們對於音訊電子產品功能的需求越來越高，8 位及 16 位 MCU 逐漸向 32 位 MCU 轉型已經成為市場趨勢。晶心科技基於 Andes Core N903A 處理器對 MCU 層級的音訊應用提供了全方位的解決方案，包括硬體平臺和套裝軟體支援。圖 3 展示了晶心科技提供的完整的音訊開發平臺。

圖 3 晶心科技提供的音訊開發平臺

考慮到從 8 位 MCU 升級到 32 位元帶來的硬體成本的增加，晶心科技推出了 N903A 低功耗高性價比的 32 位處理器。N903A 提供了完全可配置的處理器 IP 核，包括可配置的 I/D cache 大小，I/D local memory 大小，GPR 數量，硬體乘法器等等。這樣，客戶可以根據自己產品的需求，以最小的硬體成本獲得較 8 位元系統更為優化的系統性能。在指令方面，N903A 不僅包含了晶心科技自主智慧財產權的一套高效指令集，而且加入了為提高音訊資料處理能力而特別設計的四十餘條音訊擴展指令。另外，針對現有及可預期未來的大多數軟硬體應用特性，晶心科技還提供一種 16bit/32bit 混合指令集形式，在提供功能之餘，縮小了程式所需的記憶體空間，從而進一步實現降低成本的效益。

軟體方面，晶心科技同樣提供了全方面的支持。包括作業系統、設備驅動、開發工具、中介軟體、函式程式庫以及上層的各種應用程式。對於 MP3 的轉碼器，晶心科技對其代碼大小做了進一步的優化，並利用 nds32 架構的優勢以及音訊擴展指令集，使其在 Andes 平臺上運行的性能達到很高的水準。以 48KHz/128Kbps 的 MP3 歌曲為例，晶心科技優化的 madplay 解碼器正朝著 10MHz 的工作頻率邁進。表 1 為晶心科技優化的 MP3 轉碼器在 N903A 處理器上運行的結果。

語音平台解決方案之AAC格式的移植

Post author:Lee Claire
Post published:2010-08-01
Post category:技術文章

晶心科技是亞洲首家提供原創性 32 位元微處理器IP 的公司，並提供 32 位元處理器系統晶片設計平臺(Processor‐based SoC Platforms)。隨著電子產業產品日趨多功能化，要求處理器及設計平臺有更佳的整合性、設計彈性，以及高效能、低功率。晶心科技以彈性配置平臺(Configurable Platforms)，推出了 Andes Core N9，N10，N12 三种系列的 32 位处理器软硬核IP，其中 N9 主要面向 MCU 市场。基于晶心处理器系统平台，晶心科技針對不同音訊應用為客戶提供完整的解決方案。其中包括將多種音訊格式的編、解碼器（開源），例如 MP3、AAC、WMA、G729 等移植到 Andes 平臺上。利用 nds32（基於 Andes Core）架構的優勢和針對音訊處理的擴展指令集，以及演算法上的改進，對這些轉碼器做了進一步的優化，使其不僅佔用的存儲空間較小而且具備了較高的運行性能。本文以 AAC 解碼器為例，介紹如何將AAC 解碼器移植到 Andes 平臺。

1. AAC 簡介：
AAC 是 Advanced Audio Coding 的簡寫，是數位音訊的一種失真壓縮格式，由 Fraunhofer IIS，AT&T Bell Llaboratories，Dolby，Sony 和 Nokia 等這些公司共同開發。像一些副檔名m4a，m4b，m4p，m4v，m4r，mp4，aac，3gp 都是屬於 AAC 編碼的檔。
AAC 應用很廣泛，它是一些高階數位產品的預設支援音訊格式，如 Apple 公司的 iPhone， iPod，iPad，Sony 公司的 PlayStation 3，Android 作業系統的手機等。AAC 可以在比 MP3 檔案小 30％的前提下提供更好的音質，被手機界評為“21 世紀資料壓縮方式”。

2. 環境與軟體:
2.1 系統環境:
linux：fedora 8
原始程式碼：http://sourceforge.net/projects/faac/ （當前版本 faad2‐2.7.tar.bz2)

2.2 開發環境及流程:
2.2.1 開發環境:
AndeSight 是晶心科技提供的一套基於 nds32 架構開發嵌入式工程的圖形化的整合式開發環境。主要由 AndeSight IDE, AndESLive 和 nds32 工具集 3 個部分組成。
AndeSight IDE 為工程師提供了各種友好的介面，包括對嵌入式工程做編輯，編譯，運行，除錯或者評測等等操作。
AndESLive 提供了基於nds32 架構的模擬器和一種圖形化的虛擬SoC 構建模型，它與AndeSight IDE 相結合為使用者提供了一個虛擬的硬體平臺。這個虛擬評估平臺提供 Andes 自行定義 ISA 的多組系列 32 位元微處理器 IP 以及各種週邊設備 IP，並且支援使用者自訂 IP 模型。AndESLive 配合AndeSight IDE 不僅使得SoC 設計者能在計畫初期就開始軟體設計、偵錯、最優化等工作，並對系統架構及功能進行檢驗，而且使硬體工程師和軟體工程師具有一樣的能力去定制和修改他們各自的系統模型，可以有效的控制 NRE(NonRecurring Engineering)成本，讓軟體工程師在拿到硬體原型之前，即可以進行軟體的開發和優化。
nds32 工具集提供了一套在 Andes 平臺上開發嵌入式應用程式所需要的標準工具，例如交叉編譯器、交叉偵錯器、交叉連結器等等。nds32 工具集中對應不同的 Andes Core 型號，不同的系統函式程式庫以及大小端形式等條件，提供了各種對應的工具集。

2.2.2 開發流程
利用 Andes 提供的上述工具，可以方便的進行開發，下圖是 Andes 平臺開發流程。

3.操作模式
Andes 平臺可以通過命令列模式操作，同時也可以通過AndeSight v1.4 為用戶提供的整合式開發環境（IDE）模式，以方便使用者的開發。

3.1命令列操作模式
3.1.1操作過程
1） : 在命令列模式下，進入到你下載的 faad2‐2.7.tar.bz2 的目錄，解壓這個檔案夾：tar‐jxvf faad2‐2.7.tar.bz2
2）：進入解壓好的檔案目錄裡面，如目錄為 faad2‐2.7,則 cd faad2‐2.7 3）：在正式執行 configure 這個命令之前，先 autoconf 一下，執行 autoconf ‐vif 即可
3）：接下來要執行./configure。預設情況下，它是將檔案安裝在 /usr/local 下面。如果你想安裝到其它地方,如/opt 下面，你只需要在./configure ‐‐prefix=“/opt”,
可以用 ./configure –help 查看其它的設置，我們選擇默認形式。
4）：編譯其中的一個檔案 config.sub（用 vi 或 gedit 等），這是一個 script 檔找到其中的一個 case 語句，是配置 basic_machine 的，加入
nds32*)
basic_machine=nds32‐unknow os=‐
linux
;;
這樣的的 case 語句，然後保存，退出。
5）：在當前的 shell 裡設定一個環境變數，export NDS32_GCC_CFLAGS=‐static，該變數是 Andes 平臺編譯時需要的一個參數。
6）：添加路徑，在~/.bash_profile 中添加你的 AndeSight1.4 所在的路徑到你PATH 變數中去，PATH＝“You AndeSight install path”: $PATH, 再 source 一下這個檔。
7）：配置交叉編譯環境./configure ‐‐prefix=”/usr/local” ‐‐host=nds32le‐elf ‐‐disable‐shared‐‐enable‐static ‐‐without‐pic ‐‐with‐mp4v2 CC=nds32le‐elf‐gcc CFLAGS=‐static LDFLAGS=‐static CXX=nds32le‐elf‐g++ CXXFLAGS=‐static
8） : make
9） : make install。這樣 faad 的解碼器將安裝你/usr/local/下面了，或者在由–prefix 指定的路徑裡。
10）：這時 faad 已經在 Andes 平臺上安裝好了。但是要讓它在我們在平臺運行。還需要借助於模擬器，我們通常稱之為 sid。這個 sid 需要配置一些參數，如：選擇什麼樣的 cpu, 選擇什麼樣的指令集等等，這裡我們把這些配置都寫檔案裡，當執行模擬器時，為了執行的方便，只需要用一個指令檔(script file)，將相關的配置添加進去就行了。在這裡我們在配置文檔‐‐sid‐conf 裡加入
set cpu‐loader file “faad”
這樣的設置
11）：配置完成。運行我們的 sid 腳本就能得到我 wav 檔。
12）：解碼時，產生的圖形如下：
圖 2 命令列模式產生結果
13）：我們完成了將 aac，mp4 等格式的檔解碼成為 wav 等格式的檔，你想要聽到聲音，需要用如 mplayer 這樣的播放機播放出來。

3.2 GUI 介面操作模式
我們用 Andes 平臺最新的整合式開發環境(IDE)AndeSight1.4。
3.2.1 ：操作過程
1）：重複第一部分命令列操作模式的１‐>８步驟，目的是產生 makefile 檔。
2）：建立一個標準 STD C++ project 命名為 faad‐static。
3）：設置環境變數,從 Properities → c/c++ Make Project → Enviroment 中添加：
NDS32_GCC_CFLAGS 值為‐static。
4）：建立編譯目標過程，從 Creat a new Make target 中建立：all，install。
5）：build all，built install。這和命令列模式 make 和make install 有一樣的效果。
6）：建立一個虛擬運行平臺 VEP,也就是在 AndeSight 中通過 AndESLive 提供的虛擬 SoC平臺進行模擬，從 Target‐> Fork VEP Target 我們選擇 Andes‐demo,vep。7）：Run as →Program 欄中的 C/C++ Application 裡添加我們生成的 faad 檔
/usr/local/bin/faad

圖 3 添加執行檔
8）：在 Arguments 欄為這個可執行檔加上適當的參數，如輸入輸出檔案名和路徑等。

圖 4 添加運行參數
9）：點擊 Apply，程式就開始運行了。
10）：運行的過程如下圖

圖 5 IDE 模式運行結果
11）：在我們第 8）步中設置的檔參數路徑中，就得到了想要的 .wav 文件。该 wav 文件可以用 mplayer 进行播放,这就验证了 faad 的移植是正确的。

參考：
1：晶心科技網站：www.andestech.com
2：維基百科：http://en.wikipedia.org/wiki/Advanced_Audio_Coding

2. Reference Design Architecture在介紹完中斷處理模式相關定義之後，本章節提供在實際整合與應用上的範例，讓使用者可更了解在不同中斷處理模式下的差異。

3. 模擬結果 將上述的 Reference Design 整合完成後，搭配測試程式進行模擬，並藉由波形圖來觀察不同中斷模式下，相關中斷訊號線的變化。

相關程式片斷:assign branch= eilm_read_req_valid&((lastest_eilm_ifetch_addr_inc1!=eilm_addr)|eilm_ifetch_n);

相關程式片斷:assign prefetch_next1= (state_cnt==4’h0)& (~wait_for_write)& (~((lastest_eilm_ifetch_addr_inc1==addr0)&addr0_valid )& ~((lastest_eilm_ifetch_addr_inc1==addr1)&addr1_valid ));

assign prefetch_next2= (state_cnt==4’h0)& (~wait_for_write)& (~((lastest_eilm_ifetch_addr_inc2==addr0)&addr0_valid )& ~((lastest_eilm_ifetch_addr_inc2==addr1)&addr1_valid ));

相關程式片斷: