國立中山大學資訊工程所碩士論文Processor-OpenOCD整合之 ...

，

國立中山大學資訊工程所

碩士論文

Department of Computer Science & Engineering

National Sun Yat-sen University

Master Thesis

Processor-OpenOCD整合之軟硬體協同驗證

Hardware/software co-verification for processor-OpenOCD integration

研究生：黃士桐 Shih-Tung Huang

指導教授﹕黃英哲教授

Prof. Ing-Jer Huang

中華民國102年8月 August 2013

國

立

中

山

大

學

資訊工程研究所

碩士論文

Pro

cessor-O

penOC

D 整

合之軟硬體協同驗證

研究生：黃士桐

101學年度

，

國立中山大學資訊工程所

碩士論文

Department of Computer Science & Engineering

National Sun Yat-sen University

Master Thesis

Processor-OpenOCD整合之軟硬體協同驗證

Hardware/software co-verification for processor-OpenOCD integration

研究生：黃士桐 Shih-Tung Huang

指導教授﹕黃英哲教授

Prof. Ing-Jer Huang

中華民國102年8月 August 2013

論文聲明書

本論文內容與技術承接自國立中山大學資訊工程學系黃英哲教授指導之嵌

入式系統實驗室，本論文可由指導教授或所指定之第三人，作為研發、推廣、

學校教學教材等使用，或依其需要進行改作、重製、散布、發行或公開展示等

等。本論文作者同意不對指導教授或所指定之第三人行使智慧財產權(包括專利

及著作權)。

(簽章)

論文作者：黃士桐

中華民國 102 年 8 月 19 日

致謝

終於到了這時刻，我要先感謝老師的指導，給我很多的啟發與研究態度，

之後我要感謝我的父母親無條件的支持，使我能無後顧之憂的拼到現在並成功

畢業，在此將這篇論文獻給我的父母。

在實驗室的四年當中也發生許多事情許多曲折，也差點想要放棄，最重要

的是感謝建宏學長與宗正學長的支持，俊宏學長也給予我非常多的幫助，我只

能說，沒有他們我可能就沒辦法畢業了；小胖經常待我出去吃東西、子銘學長

幽默有趣的互動總是讓我哈哈大笑，猴子哥雖然很機掰，但總的來說也是很有

趣的，允 B 哥總是扮演被猴子哥欺負的角色，然後在偷婊猴子哥，靖驊在我最

後畢業時間內總是陪我騎腳踏車，達哥找吃宵夜與吃冰、庭萱找食物的能力也

是讓我大吃一驚，喔，對了，我一定會記得去年 10月 10號，猴子、我、KKL

與庭萱去墾丁遊玩，遽然在早上 10點抽到 10號小杜包子號碼牌，真是非常有

紀念意義的，只可惜號碼牌丟了，許許多多的回憶，族繁不及備載，不管如何

我還是畢業了，也要準備開啟人生的下一階段，最後也祝福達哥之後一定要順

利畢業。

學年度： 101

學期： 2

校院：國立中山大學

系所：資訊工程學系

論文名稱(中)： Processor-OpenOCD整合之軟硬體協同驗證

論文名稱(英)： Hardware/software co-verification for processor-OpenOCD integration

學位類別：碩士

語文別：中文

學號： M983040048

頁數： 113

研究生(中)姓：黃

研究生(中)名：士桐

研究生(英)姓： Huang

研究生(英)名： Shih-Tung

指導教授(中)：黃英哲

指導教授(英)： Ing-Jer Huang

關鍵字(中)：協同驗證

關鍵字(中)： GNU除錯器

關鍵字(中)：電路擬真器

關鍵字(中)：整合

關鍵字(英)： OpenOCD (Open On-Chip Debugger)

關鍵字(英)： GNU Debugger

關鍵字(英)： Co-verification

關鍵字(英)： JTAG

關鍵字(英)： EICE (Embedded In-Circuit Emulator)

中文摘要中文摘要中文摘要中文摘要

現今的 ARM program debug都是需要藉由 ARM 開發的 RVDS [18]

(RealView Development Suite)以及 MULTI-ICE (protocol converter)環境以

控制 ICE 控制 CPU，來達到對程式的偵錯，現在我們有新的選擇，就是

Eclipse、GDB與 OpenOCD (Open On-Chip Debugger)所組合起來的 debug

tool chain，配合 FIDI 公司出品的 protocol converter型號為 ft2232進行程

式的偵錯。

然而對於本身實驗室有開發 ARM7-like 的 CPU，即 SYS32TM，與可

控制 CPU的 ICE 模組，不管是 ARM 本身開發的 RVDS 或者 OpenOCD

都無法可以簡單的看到 debugger與 ICE的互動，造成不管是為了驗證 ICE

或 OpenOCD的正確性都非常的難，為了解決此問題我們思考了，使用

PLI(Program Level Interface)與 RTL simulator溝通再連接 OpenOCD，或使

用 Platform Architect本身的 co-simulation環境連接 OpenOCD，最後決定

採用 Platform Architect環境，並找到 embecosm EAN5裡面的 JTAGSC [3]

當成 protocol converter 放入Platform Architect環境，並藉由 shared memory

機制與 OpenOCD溝通已達到協同驗證的目的。

關鍵字：協同驗證,電路擬真器, GNU 除錯器, 整合, JTAG

Abstract

We usually use RVDS [18] (RealView Development Suite) and MUlTI-ICE

(protocol converter) as ARM program debug environment by controlling ICE

module for controlling CPU. But now we have another choice, ie the debug tool

chain that Eclipse, GDB and OpenOCD (Open On-Chip Debugger)

combination. We achieve program debugging by using a protocol converter

called ft2232 that FIDI Company produced to connect ICE module with JTAG

port.

However, for ARM7-like CPU, ie. SYS32TM, ICE can control the CPU

module that our laboratory develops. No matter the ARM RVDS or OpenOCD

can not observate the interactive of debugger and ICE, it such that the

verification of ICE and debugger is a difficult thing. In order to solve this

problem, we consider PLI (Program Level Interface) to communicate with the

RTL simulator and then connect to OpenOCD, or use the Platform Architect

itself co-simulation environment connected OpenOCD. Finally, we chose

Platform Architect environment and find the JTAGSC [4] as a protocol

converter that come from embecosm EAN5 that can put into the Platform

Architect environment. To achieve the purpose of co-verification, we ued shared

memory mechanism to communication with OpenOCD and Platform Architect

environment that JTAGSC had put into.

Key word: GNU Debugger, OpenOCD (Open On-Chip Debugger) , Co-

verification, JTAG, EICE (Embedded In-Circuit Emulator)

i

Index

Chapter 1 簡介簡介簡介簡介 ......................................................................................... 1

1.1 背景................................................................................................................. 1

1.2 動機................................................................................................................. 2

1.3 提出的解法..................................................................................................... 3

1.4 本研究貢獻..................................................................................................... 4

Chapter 2 相關技術與文獻相關技術與文獻相關技術與文獻相關技術與文獻 ..................................................................... 6

2.1 雛型階段應用程式除錯方法......................................................................... 8

2.1.1 目標監督程式...................................................................................... 8

2.1.2 邏輯分析儀.......................................................................................... 8

2.1.3 電路擬真器（In Circuit Emulator） .................................................. 9

2.2 嵌入式系統應用程式除錯架構................................................................... 10

2.2.1 即時追蹤除錯器................................................................................ 10

2.2.2 嵌入式電路擬真器............................................................................ 11

JTAG 架構 ........................................................................................ 13

嵌入式電路擬真器............................................................................ 15

2.3 用於控制電路擬真器之除錯器................................................................... 17

2.3.1 Open On-Chip Debugger [2] .............................................................. 18

2.3.2 GDB [6] .............................................................................................. 20

2.4 SC-RTL 協同模擬平台 ................................................................................ 21

Chapter 3 SYS32TM-OpenOCD 協同驗證平台協同驗證平台協同驗證平台協同驗證平台 ................................. 22

3.1 協同驗證平台開發動機............................................................................... 22

3.2 協同驗證平台研究方法............................................................................... 25

3.3 OpenOCD與 JTAGSC如何連接 ................................................................. 27

3.3.1 基於共享記憶體技術的溝通機制.................................................... 28

3.3.2 補足 JTAGSC不足之處的修改 ....................................................... 30

3.3.3 OpenOCD新增 JTAGSC驅動程式與初始化流程修改 .................. 33

3.3.4 協同驗證平台總觀............................................................................ 39

3.4 協同驗證平台如何重複利用....................................................................... 39

3.4.1 SC-RTL 協同模擬平台內部用到的元件與接線說明 ..................... 40

3.4.2 如何使用協同驗證平台.................................................................. 43

Chapter 4 實驗實驗實驗實驗 ....................................................................................... 47

4.1 SC model (JTAGSC)和 RTL model (SYS32TM+EICE) 可以正常執行協同

ii

模擬...................................................................................................................... 47

4.2 OpenOCD與 SC+RTL model互動驗證 ...................................................... 49

4.3 GDB 需要 EICE幫助的除錯動作 .............................................................. 51

4.4 Semihosting 機制.......................................................................................... 60

4.5 在協同驗證平台執行應用程式除錯範例................................................... 62

4.6 實際範例-以 JPEG編碼程式與 3DG SoC程式為例 ................................ 72

4.6.1 JPEG 編碼程式 ................................................................................. 72

4.6.2 3D graphs SoC 應用程式 .................................................................. 78

Chapter 5 結論與未來發展結論與未來發展結論與未來發展結論與未來發展 ................................................................... 81

Appendix A OpenOCD 架構架構架構架構 ................................................................. 84

A.1 OpenOCD 架構與運作流程........................................................................ 84

A.1.1 OpenOCD內部模組.......................................................................... 84

A.1.2 OpenOCD 初始化與運作流程 ........................................................ 86

A.1.2.1 OpenOCD 初始化流程.................................................................. 86

A.1.2.2 OpenOCD 運作流程...................................................................... 87

A.2 ITRI’s Project – PACDUO（高效能平行架構核心採用 ARM9 以及雙

DSP為發展平台） ............................................................................................. 88

A.2.1 PACDUO [15] .................................................................................... 88

A.2.2 PACDUO除錯效能與使用 GDB控制問題 .................................... 90

A.2.3 尋找 PACDUO 問題所使用的方法 ................................................ 90

A.2.4 PACDUO問題解決與最後結果 ...................................................... 92

Appendix B EICE_control_event/JTAG 轉換器說明轉換器說明轉換器說明轉換器說明 ........................ 95

B.1 JTAGSC 介紹 .............................................................................................. 95

B.2 JTAGSC檔案目錄列表與編成元件可在 SC-RTL協同模擬平台使用 .... 97

B.2.1 JTAGSC 檔案目錄與結構 ............................................................... 97

B2.2 JTAGSC如何可以被當成元件在 SC-RTL協同模擬平台上使用 . 98

B.3 JTAGSC運作流程 ....................................................................................... 99

B.3.1 JtagSC.cpp and JtagSC.h ................................................................. 100

B.3.2 JTAGSC API運作流程 ................................................................... 104

B.3.3 TapStateMachine .............................................................................. 106

Appendix C 藉由協同驗證平台所找到的藉由協同驗證平台所找到的藉由協同驗證平台所找到的藉由協同驗證平台所找到的 OpenOCD與與與與 EICE 錯誤錯誤錯誤錯誤

................................................................................................................. 108 C.1 SYS32TM 無法被停止.............................................................................. 108

C.2 EICE無法控制 SYS32TM寫入記憶體 .................................................... 110

iii

C.3 中斷點觸發之後停止的位址不是設定中斷點得位址 ............................ 112

iv

Figure 圖圖圖圖 2-1 Debugging tool chain classify.......................................................................... 6

圖圖圖圖 2-2 Traditional ICE connection .......................................................................... 10

圖圖圖圖 2-3 Real-Time Trace architecture ....................................................................... 11

圖圖圖圖 2-4 Embedded ICE connection ........................................................................... 12

圖圖圖圖 2-5Board level Boundary Scan architecture ...................................................... 14

圖圖圖圖 2-6 JTAG architecture ......................................................................................... 14

圖圖圖圖 2-7 TAP Finite State Machine ............................................................................. 15

圖圖圖圖 2-8 Embedded ICE component ........................................................................... 16

圖圖圖圖 2-9Breakpoint Detection Unit architecture ....................................................... 17

圖圖圖圖 2-10 OpenOCD retarget idea .............................................................................. 18

圖圖圖圖 2-11 OpenOCD modules ...................................................................................... 19

圖圖圖圖 2-12 Platform Architect ....................................................................................... 21

圖圖圖圖 3-1 Traditional find bugs between debugger and EICE ................................... 22

圖圖圖圖 3-2 ideal of this thesis ........................................................................................... 23

圖圖圖圖 3-3 traditional program debug method .............................................................. 25

圖圖圖圖 3-4 propose co-verification platform .................................................................. 25

圖圖圖圖 3-5 propose framework with PLI and RTL simulator ...................................... 26

圖圖圖圖 3-6 propose framework with JTAGSC and co-simulation platform ............... 27

圖圖圖圖 3-7 shared memory communication working flow............................................ 28

圖圖圖圖 3-8 EICE control event context ........................................................................... 29

圖圖圖圖 3-9 feed back data from hardware ..................................................................... 30

圖圖圖圖 3-10 RUNTEST API working flow ..................................................................... 31

圖圖圖圖 3-11 the architecture of Co-verification platform ............................................. 31

圖圖圖圖 3-12 the arch. working flow after modification ................................................. 32

圖圖圖圖 3-13 the algorithm of JTAGSC communication with OpenOCD by shared

memory .............................................................................................................. 33 圖圖圖圖 3-14 OpenOCD initial flow and working flow ................................................... 34

圖圖圖圖 3-15 scan data structure in OpenOCD ............................................................... 35

圖圖圖圖 3-16 JTAG cmd structure in OpenOCD ............................................................ 35

圖圖圖圖 3-17 scan data to EICE control event algorithm ............................................... 36

圖圖圖圖 3-18 feed back data to scan data algorithm ....................................................... 37

圖圖圖圖 3-19 how to add interface driver......................................................................... 37

圖圖圖圖 3-20 the final framework of co-verification environment ................................ 39

圖圖圖圖 3-21 the component and connection in Platform Architect .............................. 40

圖圖圖圖 3-22 the architect compile argument setting flow ............................................. 44

v

圖圖圖圖 3-23 the architect simulation flow ...................................................................... 45

圖圖圖圖 3-24 OpenOCD connect to JTAGSC successfully ............................................. 45

圖圖圖圖 3-25 location of shm address ............................................................................... 46

圖圖圖圖 4-1 final frame work with GDB .......................................................................... 47

圖圖圖圖 4-2 the basic emulation connection graph ......................................................... 61

圖圖圖圖 4-3 the example program will be debugged by GDB on co-verification

platform ............................................................................................................. 63 圖圖圖圖 4-4 the OpenOCD configuration file context ..................................................... 64

圖圖圖圖 4-5 GDB debug quick sort and binary search (#1) ........................................... 66




圖圖圖圖 4-9 OpenOCD infomation for executing quicksort with binary search .......... 71

圖圖圖圖 4-10 Full Example environment ......................................................................... 72

圖圖圖圖 4-11 tool chain usage flow .................................................................................... 73

圖圖圖圖 4-12 GDB control flow #1 of JPEG encoder ...................................................... 75



圖圖圖圖 4-15 JPEG encoder result of after GDB controlling ......................................... 78

圖圖圖圖 4-16 the flow of SYS32TM driving GPU to draw a picture ............................. 78

圖圖圖圖 4-17 GDB control flow of 3D graphs SoC .......................................................... 79

圖圖圖圖 4-18 3D graphs SoC result of after GDB controlling ........................................ 80

圖圖圖圖 A-1 OpenOCD framework and operation flow graph...................................... 86

圖圖圖圖 A-2 OpenOCD initial flow ................................................................................... 87

圖圖圖圖 A-3 PACDUO architecture .................................................................................. 89

圖圖圖圖 A-4 PACDUO view ............................................................................................... 89

圖圖圖圖 A-5 the different between OpenOCD and USB_driver .................................... 91

圖圖圖圖 B-1 JTAGSC reset code example ........................................................................ 95

圖圖圖圖 B-2 JTAGSC IRScan code example ................................................................... 96

圖圖圖圖 B-3 JTAGSC DRScan code example .................................................................. 96

圖圖圖圖 B-4 JTAGSC file relation .................................................................................... 98

圖圖圖圖 B-5 file list need to be compiled .......................................................................... 99

圖圖圖圖 B-6 input and output port of JtagSC ............................................................... 100

圖圖圖圖 B-7 initail part of JtagSC .................................................................................. 100

vi

圖圖圖圖 B-8 JTAGSC operation flow ............................................................................. 102

圖圖圖圖 B-9 working flow chart JTAGSC operation flow ............................................ 103

圖圖圖圖 B-10 example of JTAG EICE control event ..................................................... 104

圖圖圖圖 B-11 flow chart of IR or DR working flow ...................................................... 105

圖圖圖圖 B-12 TAP FSM decision table ........................................................................... 106

圖圖圖圖 B-13 TMS decision table .................................................................................... 107

圖圖圖圖 C-1 EICE architecture ....................................................................................... 108

圖圖圖圖 C-2 scan chain2 connection with BDU before modification ........................... 109

圖圖圖圖 C-3 scan chain2 connection with BDU after modification ............................. 110

圖圖圖圖 C-4 EICE control event activities form OpenOCD ........................................ 111

圖圖圖圖 C-5 the cpu control signals path in EICE ........................................................ 113

vii

Table

表表表表 3-1 time spending compared between traditional and proposed verification 23

表表表表 3-2 signal number and trace length comparing ................................................ 24

表表表表 3-3OpenOCD JTAGSC driver ............................................................................ 38

表表表表 3-4 the environment component description ..................................................... 41

表表表表 3-5 JTACSC component description .................................................................. 42

表表表表 3-6 the RTL component description ................................................................... 43

表表表表 3-7the architect compile argument setting value .............................................. 44

表表表表 4-1 JTAGSC IR API experiment result .............................................................. 48

表表表表 4-2 JTAGSC DR API experiment result ............................................................ 49

表表表表 4-3 JTAGSC RUNTEST API experiment result ............................................... 49

表表表表 4-4 GDB debugging activities with OpenOCD and RTL EICE ....................... 56

表表表表 4-5GDB debugging activities with OpenOCD and RTL EICE result ............. 60

表表表表 4-6 common semihosting type table.................................................................... 62

表表表表 A-1 Target Handle function list .......................................................................... 92

表表表表 A-2 testing result .................................................................................................. 93

表表表表 A-3 ft2232d Load speed from YAGARTO ......................................................... 94

1

Chapter 1 簡介簡介簡介簡介

本章將會介紹有關此論文之研究主題的背景、研究的動機、研究的方法以及

論文的主要貢獻，並且在本章的最後會對整篇論文的組織架構進行逐一地探討，

藉此讓我們在正式進行研究主題的討論前，先有初步的具體概念。

1.1 背景背景背景背景

近年來隨著製程不斷的進步， IC 設計也朝著 SoC (System On a Chip)的方

向設計，而在製程進入深次微米的時代，我們可以將許多不同的硬體電路整合

到同一個系統單晶片中，所以在系統單晶片中的電路會越來越複雜。因此要針

對這樣一個龐大且複雜電路進行除錯且驗証，對於系統設計者是一個非常大的

挑戰。而在 Embedded system核心，微處理器(microprocessor)或數位訊號處理

器(DSP)是系統最為重要且複雜的電路，所以針對微處理器的除錯與驗証是最耗

費時與精力的一個環節。

而 Embedded In-Circuit Emulator (EICE) 的觀念建立在日趨複雜的晶片設計

上，透過 Embedded ICE電路可以針對複雜嵌入式微處理器來進行除錯，而

Embedded ICE的除了硬體除錯機制之外，也需要搭配軟體應用，所以針對這項

問題 ARM 公司所推出 RealView debugger tools和 Multi-ICE protocol

converter，可以提供設計者在軟體端可以監控微處理器的內部狀態，然而

RealView debugger tools與 Multi-ICE protocol converter都不是 Open Source，對

於要研發配合不同 CPU的 EICE模組軟體端方面就成了問題。

針對微處理器的驗證與除錯，目前我們有下列幾種主要的方法：

1. 電路模擬器電路模擬器電路模擬器電路模擬器(Simulator)

電路模擬器是一個最為簡單、迅速用來初步驗證我們微處理器設計的作

法。通常我們在定義好電路的規格之後，在實際設計完成硬體電路之前，

我們會先撰寫好一個使用高階程式語言所描述的電路模擬器來做初期的

功能驗證。等到硬體都實作完成之後我們可以拿模擬器以及實際的硬體

電路進行功能的比對，用來確保我們在硬體設計上與原先訂出的規格是

一致的[20]。

2. 電路擬真器電路擬真器電路擬真器電路擬真器(In Circuit Emulator)

電路擬真器是一個用來取代並且模擬電路中微處理器行為的硬體電路，

搭配上軟體的支援通常可以提供除錯者設定中斷點(Breakpoint)、單步執

行(single step)、觀察內部暫存器狀態等除錯的功能。使用電路擬真器可

2

以非常完整的針對微處理器進行除錯，是一般微處理器系統最為普遍的

除錯方式[14]。

3. 即時追蹤除錯器即時追蹤除錯器即時追蹤除錯器即時追蹤除錯器(Real-Time Trace)

及時追蹤除錯器是一種嵌入於微處理器系統當中，不需要停止除錯之目

標微處理器而可以達到除錯效果的硬體電路。使用及時追蹤除錯器來對

於微處理器除錯的最大優點在於因為不需要將微處理器的時脈停止下來，

因此可以追蹤出更真實的微處理器際執行狀態[21]。

1.2 動機動機動機動機

在一個大型複雜的數位電路開發的過程中，最耗時是在於 IP 的功能驗証及

除錯，所以這將會影響到整個晶片的開發時程。所以設計工程師必須在能夠有快

速且有效率的對於自行開發的晶片進行驗証及除錯，來達到 time to market。

而嵌入式微處理器是整個 SoC 晶片中最複雜的電路。嵌入式電路擬真器

(EICE)是目前微處理器最常見的也是最普遍使用的除錯技術。因為 ICE 本身可

以提供良好的除錯與測試機制，像是：單步 (Single Step) 除錯、中斷點

(Breakpoint) 的設定與偵測、內部資源的監督與修改。使用 ICE 的主要優點是可

以提供良好的系統控制能力，而且只要使用四個訊號線的 JTAG Port 以主從模

式的靜態除錯 (Static Debug) 方式即可控制整個除錯系統。所謂的靜態除錯指的

是要將微處理器的資訊 (如：暫存器的狀態)傳出前，必須先終止微處理器的時脈，

然後透過慢速的 JTAG 串列介面來傳遞測試樣本 (Test Patterns)。

而一般在使用嵌入式電路擬真器必須配合 PC端的軟體除錯工具來進行除錯，

在目前的微處理器系統中之嵌入式電路擬真器的設計都是符合PC端的軟體除錯

工具也就是 debugger，所以當我們對於在不同的微處理器上所自行開發的嵌入式

電路擬真器，在設計實作上都會被限制在 debugger上，所以當 debugger升級或

是改變就會造成自行開發的嵌入式電路擬真器功能無法使用。因為是商用軟體套

件，無法針對軟體部分進行修改，所以就必須要修改嵌入式電路擬真器的硬體模

組，來符合新的 debugger規範。所以這就表示，硬體的設計都被限制在軟體的規

範。

3

RVDS Multi_ICE CPU+EICE

FT2232

USB JTAG

GDB+OpenOCD CPU+EICEJTAGUSB

debugger

Can not modify

Can modify

Adapter

Cost NT$100k

Cost NT$2k

Commercial

Open source

FPGA

GDB+OpenOCD JTAGSC CPU+EICE

Co-simulation platform (Platform Architect )

processor/OpenOCD Co-verification platform

SHM JTAG

Can not observe signal

Can observe signal

RTL simulationSystemC

圖 1-1 comparison of commercial and open source debugger

所以為了不要將硬體的設計被限制在軟體，我們軟體將會採用 open source

software稱作 Open On-Chip Debugger[2](以下簡稱 OpenOCD)來取代 commercial

debug tool，使得硬體不用被軟體所局限住，除此之外每當硬體因應效能調升而硬

體架構有所變動時，也不需要擔心無法符合 commercial debug tool，只要修改

OpenOCD來符合硬體架構就好，如此一來，就可以減少與減免為了與 commercial

debug tool相容而導致硬體架構開發的時間與妥協。

而為了達到提高驗証嚴謹度和有效率的除錯，則是藉由 Platform Architect co-

simulation的應用，可以直接將 host端 OpenOCD的 EICE control event透過 shared

memory方式，連接到 Platform Architect中的 RTL level的硬體直接驗証，減少在

FPGA合成驗証時間。

針對以上議題，本篇論文的目的主要是針對軟體的部分深入討論，配合軟硬

體協同設計理念，以及 debug tool chain debugger採用 OpenOCD，這樣可以掌握

軟體和硬體的開發環境，希望可以探討出對於 Embedded ICE的開發並應用

Platform Architect co-simulation環境，達到有效率的除錯及加強驗証的嚴謹度，

而且掌握軟體也可以達到不修改 Embedded ICE硬體，可以容易且快速應用在不

同的嵌入式電路擬真器。

1.3 提出的解法提出的解法提出的解法提出的解法

關於這項研究，我們將會細分為下列數個步驟逐一實現我們的研究工作。

1. 系統分析系統分析系統分析系統分析(System analysis)

4

針對我們的研究，主要分成硬體和軟體二個部分來探討：

在硬體方面，在不同的微處理器的硬體架構，所支援嵌入式電路擬真器

(Embedded In-Circuit Emulator)設計上也有所異同。一般來說，針對不同

微處理器所使用的嵌入式電路擬真器在硬體的設計上會有許多的不同

之處。舉例來說，微處理器的掃瞄串列 (Scan Chain)的實做方式就可以

分為內部掃瞄串列 (Internal Scan Chain)以及包覆式掃瞄串列 (Boundary

Scan Chain)兩種，而在不同的硬體架構下，所設計出來的嵌入式電路擬

真器在控制上就要給予不同的除錯資訊。所以，我們必須歸納出不同微

處理器所設計出來的嵌入式電路擬真器之間所具有共通的部分以及不

同的部分，以及那些不同的設計會影響除錯軟體的可重複使用性。針對

不同的嵌入式電路擬真器，來找出設計異同處的特性，可以幫助我們在

軟體端的開發。

在軟體方面，使用 OpenOCD，主要可以掌握軟體端的 source code，可

以針對不同的嵌入式電路擬真器，由軟體端來設計符合的溝通介面及連

接機制，不用再重新改寫 Embedded ICE硬體架構。

2. 實作及驗證實作及驗證實作及驗證實作及驗證(Implementation and Verification)

將己經評估且分析完成的軟硬體架構進行實作。

(1) 使用 open source debugger tool (OpenOCD)：

掌軟體端的技術，修改軟體端的 debugger來符合硬體需求

(2) 使用不同的 JTAG protocol converter(例如：parallel port 或 USB

interface)：

我們可以不用關心 JTAG protocol converter支援 parallel port或 USB

interface，因為掌握了軟體端，所以我們可以修改軟體來支援所使用

的 protocol converter。

(3) 硬體和軟體的 co-verification platform或是新的驗証方法：

我們可以透過使用 Platform Architect co-simulation 環境，可以使嵌

入式電路擬真器在 RTL level 與 debugger直接進行驗證，可以節省

FPGA在合成驗証的時間。

1.4 本研究貢獻本研究貢獻本研究貢獻本研究貢獻

此篇論文的主要貢獻在於將理想化作實際的研究探討並加以實現。在目前的

嵌入式微處理器的除錯是藉由嵌入式電路擬真器(Embedded In-Circuit Emulator)

配合商業軟體套件來進行除錯及驗証。因此，只要是自行設計開發的 EICE或是

商業軟體套件停產或是升級時，EICE 硬體就必須重新修正來符合最新的商業軟

5

體套件，由於升級新的套件也會造成 COST提高。

所以針對此問題，本篇論文是要運用目前最普遍的 IEEE 1149.1測試除錯通

訊埠做為基礎架構，將商業軟體套件改成開源碼的 OpenOCD，來達到 cost down

的目的，而且應用 OpenOCD可以掌握軟體端的資訊，而且配合 Platform Architect

co-simulation環境，對於自行開發的硬體架構，可以 RTL level直接進行驗證，

可以節省 FPGA 在合成驗証的時間，可以達到快速除錯及提高驗証嚴謹度的目

的。

6

Chapter 2 相關技術與文獻相關技術與文獻相關技術與文獻相關技術與文獻

微處理器的除錯在電腦系統中一直是一個相當重要的議題，一個好的除錯環

境可以幫助軟體開發者迅速的找出程式設計上的錯誤，進而降低了軟體開發的困

難度。由於除錯的重要性，對於不同時期、不同架構的微處理器皆發展出不同的

除錯方式，所以近十幾年來有相當多的研究在探討有關微處理器的除錯方法。而

在除錯軟體方面，由於除錯架構的快速變遷，從早期使用純軟體的方式進行除錯，

中期使用 In-Circuit Emulator將所有微處理器的訊號拉出來控制與觀察到目前進

入到系統單晶片時代後大家所致力於的嵌入式除錯電路，對於除錯軟體端而言是

一個相當大的改變。除錯硬體對於微處理器的除錯能力一再地提升，除錯的軟體

提供的除錯功能上亦有所不同。在本章我們將會針對過去幾年來，國內外學者在

微處理器之除錯的硬體以及軟體上所做的研究進行整理。

我們先介紹一般除錯工具軟體在分類上有什麼不同的區別，以及硬體在整體

工具鍊上扮演哪種角色，另外我們還會分析目前常見除錯軟體所提供的一些除錯

功能並且在最後蒐集目前市面上的一些個人電腦端的除錯軟體，對其做一些簡單

的介紹。 SoC application code debugging tool

CPU is simulator (ISS)

ARMulator MIPS simulator

CPU do not execute OS

Real time trace[9]

BDMEICE[1]

Debug sof tware(OpenOCD[2])

USB/JTAG protoc ol

converter [7]

CPU with EICE

USB

JT

AG

FPGA

HOST

Adapter (H/W)

program

GDBR SP on TCPIP

...

CPU execute OS

GDB[6] not remote type

GDB remote type

GDB remote

H/W

Linux kernel

GDB APP

Tartget

program

...

H/W

RTOS kernel

GDBServer APP

Tartget

program

... HOST

GDBRSP on TCP/TP

Debug software(OpenOCD[2])

JTAG protocol

converter[4]

CPU with EICE

SHM JTAG

RTL

HOST

Adapter (SC)

program

GDBRSP on T CPIP

Systemc RTL co-simulation platform

圖 2-1 Debugging tool chain classify

在進入除錯工具軟體與硬體討論之前，先對除錯工具軟體骨架與類別作大概

介紹與分類，如圖 2-1 Debugging tool chain classify所示，基本上如果要對

Application program除錯，可以依”SoC發展階段”來作除錯工具的分類，分為三

階段分別為模擬階段、雛型階段、成熟階段，所以分類與說明如下：

� 模擬階段：CPU is simulator，還未有硬體雛型出來之前，通常使用 CPU

7

模擬器來除錯 Application program，觀察重點在於 program與 CPU執行

流程是否是符合預想，主要採用 ISS (Instruction Set Simulator)為模擬方

式，program編譯成執行檔之後，透過 ISS在不同的 CPU上執行，以了

解 program流程與 CPU執行流程，缺點是速度慢，以及無法真實的模

擬 SoC實際狀況，頂多像 multiprocessor frontends [13]將 simulator架構

成可模擬 multi-core情況的 simulator，屬於初步想法驗證階段。

� 雛型階段：CPU do not execute OS，經過模擬階段驗證完想法，雛型階

段會先將 CPU與暫時的週邊實環境作出來，通常這階段由於週邊環境

還未確定，所以不會有 OS，驗證該 CPU與暫時的週邊環境通常會使用

RTL 模擬驗證，當 RTL 驗證完後會燒入 FPGA進行接近 gate level實體

驗證，然而由於沒有 OS的幫助，FPGA相當於封閉的環境，所以 CPU

沒有 OS的幫助的話要作 program 除錯有下列方式：

� Real Time Tracer or ROM monitor：不外乎原理就是當 program在

CPU 執行的時候抓取預先定義的特徵值已達到除錯的目的，在

program執行期間不需要 HOST 提供額外的幫助，屬於是 off-line

trace，缺點也是顯而易見的，就是追蹤長度不會太長。

� EICE：可以使用 JTAG訊號透過 EICE控制 CPU，使 FPGA不再是

一個封閉環境，以便可以控制 CPU達到對週邊開發與除錯，由於

控制 EICE的 JTAG序列太過複雜，基本上會使用軟體來輔助使用

者控制，該軟體稱為 debugger，常見的有 RVDS[18]、HJTAG[3]、

OpenOCD[2]，而該軟體我們採用 OpenOCD，採用的原因是 Open

source所以方便修改、可使用不同的 Adapter不會被侷限高成本的

Adapter，在此採用的 Adapter是 FTDI 公司出產的 ft2232d晶片，

再者可以支援GDB送出的RSP命令，相當於GDB server輔助GDB

以 JTAG方式控制 CPU達成 on-line program除錯的目的，本論文

就是以這架構再行更進一步的探討，以下 GDB 與 OpenOCD被歸

類成 debug tool chain software部份，而 Adapter與 EICE和 CPU則

歸類在 debug tool chain hardware部份。

� 成熟階段：CPU execute OS，雛型階段完成後，所有的週邊除錯與開發

均完成，由於開發過程中週邊環境一定會越來越複雜，所以成熟階段通

常也會開發 OS 來輔助管理週邊硬體，在 CPU 有 OS 的幫助下執行

program除錯，可以依照 Target資源多或寡在進一步的分類：

� Target資源多：可以或得較多的 CPU時間執行 GDB 除錯 program

的動作，那麼就可以直接開啟 GDB除錯 program。

� Target資源少：有些硬體支援比較少，或者 OS 像 Real Time OS

(RTOS)有嚴格的限制使得被分配到的 CPU時間很難滿足 GDB 運

行，所以就必須要有 HOST幫助，將大部分 GDB內部較為複雜的

工作（例如管理程式碼與程式碼位址的對映）交由資源較多的

8

HOST端完成，而 Target則運行負擔較小的 GDB server，GDB server

主要目的就是接收與執行 GDB來的除錯命令，至於較複雜的反組

譯和程式碼對映交由 HOST GDB端執行。

綜合以上所述，只要雛型階段完成對週邊的開發與除錯，那麼在開發 OS也

會順利許多，雛型階段對週邊的開發與除錯成敗對成熟階段的 OS開發有很大的

影響，本論文主軸在於雛型階段使用 EICE為探討，主要發現的想法是 EICE與

debug software驗證這部份可以進一步的改良，以下描述雛型階段硬體方法的除

錯介紹，之後進入到除錯軟體的輔助介紹與分類。

2.1 雛型階段應用程式除錯方法雛型階段應用程式除錯方法雛型階段應用程式除錯方法雛型階段應用程式除錯方法

在本節中，我們將會介紹三種雛型階段較為常見的除錯機制，並且會在後面

的章節當中針對各種不同的除錯機制進行分析比較[4][9]。

2.1.1 目標監督程式目標監督程式目標監督程式目標監督程式

使用目標監督程式(Rom Monitor)在微處理器系統中進行除錯也是一種

相當常見的除錯作法。目標監督程式的作法是將監督程式嵌入到微處理器

系統內可以存取的記憶體空間當中，並且透過串列連線與個人電腦上的除

錯程式通訊。我們可藉由此程式幫助程式開發者讀寫記憶體及暫存器，並且

可藉由此程式將我們所設定中斷點位置的指令替換成 Interrupt 指令或是單

純的 Function Call，當執行到此被替換的指令時便會將使用權交給 ROM

Monitor程式。

整體來說，使用目標監督程式可以提供強大的除錯能力，因為研發人員

可於終端系統工作時查詢目標元件的狀態，但另一方面，這種方法卻須佔用

目標系統的使用者資源來提供串列連線和命令界面。除此之外，儲存於

ROM 記憶體的程式碼也無法以這種方法進行除錯，因為監督程式必須修改

程式記憶體以取得執行控制。由於監督程式通常是目標系統上的中斷驅動

型軟體程序，所以使用者並無法在中斷服務常式內設定中斷點；在複雜的嵌

入式系統中，中斷常式可能是整個程式的重要部份，因此無法在中斷常式內

除錯就成為很嚴重的缺點。

2.1.2 邏輯分析儀邏輯分析儀邏輯分析儀邏輯分析儀

在傳統上，當我們一旦將微處理器實際下線做成晶片之後，我們便很難

直接對此微處理器進行除錯。然而，這時候我們可以使用邏輯分析儀將晶片

9

外部腳位的訊號擷取出來觀察。

在早期的設計與除錯環境中，由於軟體設計人員通常都不太熟悉硬體

工具，所以他們通常會盡量避免使用這些工具來幫助程式進行除錯。軟體設

計人員在通常會在個人電腦或工作站上用 C++、VB 及高階的程式語言編寫

程式原始碼，並希望使用這些平台完成整個設計、除錯和評估過程。但由於

現在系統日趨複雜，相互之間影響也越來越大，這種狀況正在漸漸改變。

一般來說，邏輯分析儀由於性能的不同價錢也有天壤之別。而影響邏輯

分析儀性能的因素包含了取樣頻率(Sample Rate)、通道數目(Channel)、記憶

體大小、觸發功能(Trigger)等等。取樣頻率對於邏輯分析儀來說就是一個重

要選擇因素，對於微處理器的除錯而言，由於微處理器的執行時脈同常較

高，因此我們需要邏輯分析儀提供足夠的取樣頻率來對微處理器進行除錯。

若是無法提供足夠的取樣頻率的話，我們將無法從多個匯流排得到的結果

將他們正確聯結起來，當有問題出現時我們也會難以分辨出原因和結果之

間的關係。雖然從技術上說，得到的波形和儲存的內容是即時追蹤結果，但

是如果它不夠精確的話，對硬體和作業系統的故障判斷沒有多大幫助。

使用邏輯分析儀來進行除錯的時候，除了取樣頻率的問題以外，數據採

樣必須既要夠寬、夠深(能儲存大量儲擷取所得到的數據)。針對微處理器除

錯的時候我們通常需要觀察微處理器存取記憶體的狀況，因此我們需要一

個較寬的通道來擷取這些訊號。另外由於微處理器所執行程式經常需要跑

大量的時脈週期，因此針對微處理器來除錯我們需要一些較為高階的邏輯

分析儀帶有擴展記憶體的組合式邏輯分析儀來滿足除錯的需求。

由於儲存的記憶體容量通常相當有限，我們通常無法完整的擷取出欲

除錯程式的波形，因此邏輯分析儀通常會提供一些觸發功能，使用者可以設

定一些觸發的條件。在一般的狀況下，邏輯分析儀只是在監視擷取出來的訊

號，一旦遇到觸發的條件之後，邏輯分析儀才會開始記錄波形。一般來說觸

發的條件可以分為單階觸發、雙階觸發跟多階觸發等等，其中，我們還可以

使用預先觸發、延遲觸發、多次觸發等等進階的觸發條件。若是邏輯分析儀

可以提供複雜的觸發條件，配合上有經驗的程式設計師來進行除錯的話，程

式設計師可以很迅速的找出程式錯誤，達到有效率的除錯。

2.1.3 電路擬真器電路擬真器電路擬真器電路擬真器（（（（In Circuit Emulator ））））

近年來，對於微處理器的測試及除錯，許多的學者及業界都提出了許多

作法。其中，對於一個微處理器電路在首度生產製造出來的晶片進行測試及

10

除錯時，我們最常見的除錯機制就是使用電路擬真器(In-Circuit Emulator; ICE)。

傳統上，電路擬真器是做成一個外接的黑盒子，當我們要進行除錯的時候，

我們將系統中的微處理器抽換掉，而改由電路擬真器直接控制。我們通常會

使用個人電腦透過 printer port或是 COM port連接到這個外接的除錯器，然

後透過這個外接的除錯器來進行除錯的工作。其架構如圖 2-2所示。

由於我們必須要觀察微處理器的內部行為來幫助我們進行除錯，所以傳

統上電路擬真器必須要將微處理器中除錯所需要的腳位拉到外接的電路擬真

器黑盒子中進行偵測、除錯。然後再將除錯的資訊（例如中斷點的發生、某

個內部暫存器的值）透過 printer port或是 COM port傳送到個人電腦或工作

站，以便開發人員進行除錯的工作。

ICE BoxM icroprocessor Co re

圖 2-2 Traditional ICE connection

2.2 嵌入式系統應用程式除錯架構嵌入式系統應用程式除錯架構嵌入式系統應用程式除錯架構嵌入式系統應用程式除錯架構

2.2.1 即時追蹤除錯器即時追蹤除錯器即時追蹤除錯器即時追蹤除錯器

即時追蹤除錯器（Embedded Real-Time Trace Circuit）這樣的概念最早

是由 Motorola 以及其他幾家電子大廠所領導的 IEEE-ISTO Nexus 5001

Forum所提出[10]，在 1999年時制訂出有關動態除錯 (Dynamic Debug) 的

相關標準。所謂動態除錯指的就是我們的除錯電路有能力在不停止微處理

器的時脈之下，依然可以提供系統開發者對於系統晶片的良好觀察能力。雖

然這個標準在 1999年的時候就已經被制訂出來，但是其中動態的除錯在實

際應用上仍然面臨了許多相當艱難的設計挑戰。其中一個最主要的問題是

在於如何不去破壞晶片原本的結構與狀態並且在不去降低處理器的運算速

度的條件下，仍然可以將微處理器執行程式時的相關資訊完整即時地擷取

出來。

11

與傳統的邏輯分析儀(Logic Analyzer)相比，即時追蹤除錯器與傳統邏

輯分析儀在訊號的追蹤能力上可說是各有所長。一個功能強大的邏輯分析

儀雖然可以對高速的邏輯訊號做即時性的捕捉，但是他只能針對晶片外部

的訊號腳位進行捕捉，對於嵌入在系統晶片內部的微處理器，由於非常多的

訊號並不會直接接到外部的晶片腳位上，因此我們無法針對內部匯流排的

訊號存取 (例如：微處理器與記憶體整合在同一個晶片上)。此時，唯有透

過嵌入式的即時追蹤除錯器的處理，才有辦法將系統單晶片內部匯流排的

訊號完整的擷取出來給系統除錯者。換言之，若系統開發者想要針對一個系

統單晶片中內部的微處理器模組進行即時的除錯，則一個嵌入式的即時追

蹤除錯器可以提供這樣的除錯能力

一般來說即時追蹤除錯器可以使用硬體或是軟體來設計。使用硬體來

設計追蹤除錯器的主要考量因素在於它的即時性。舉例來說，我們若想要對

所設計中斷常式 (Interrupt Service Routing; ISR) 進行除錯，必須考量到中

斷本身只會發生在系統單晶片中(Chip Level)，若使用軟體模擬的方式去設

計追蹤除錯器，不僅會影響中斷常式設計的正確性 (如：所設計的中斷常式

的執行時間要小於某段時間，但是軟體的追蹤方法會造成執行時間的延遲)，

系統本身也有可能無法有效的模擬中斷的發生(如：電話線路的插撥)。所以

使用硬體的設計方式來進行追蹤除錯器的開發是在於希望能在不影響處理

器行為之下，忠實地將程式跑過的位址資訊予以記錄。一個即時除錯追蹤器

的架構如圖 2-3 Real-Time Trace architecture所示

On Chip DebugWindows PC

Debugger Software

Debugger Box Trace Block Processor Core and IP Logic

Parallel Interface

Internal Bus

JTAG

圖 2-3 Real-Time Trace architecture

2.2.2 嵌入式電路擬真嵌入式電路擬真嵌入式電路擬真嵌入式電路擬真器器器器

在前面我們曾經提過傳統的電路擬真器可以提供微處理器系統相當完

12

整的除錯功能，但是由於目前積體電路的製程越來越先進，系統單晶片已成

為下一代晶片發展的趨勢，將來微處理器系統將會包含在單一個系統晶片

當中，對於系統單晶片中的的嵌入式微處理器，我們想要利用傳統的電路擬

真器來進行除錯上將會遇到一個很大的問題。

傳統上我們將微處理器放置在電路板上，因此我們可以針對除錯的需

求將需要的腳位拉到晶片外部來觀察。一旦我們將微處理器嵌入到系統單

晶片之中，由於微處理器的接腳只會有少部分連接到晶片的外面，因此傳統

的電路擬真器也無法對嵌入在系統單晶片中的微處理器進行除錯。針對這

樣的問題，現在普遍的作法是將電路擬真器直接嵌入至系統單晶片中。在

此，我們稱之為「嵌入式電路擬真器」，其基本架構如圖 2-4 Embedded ICE

connection所示[1]。在圖中，我們可以看到微處理器被嵌入至一個系統單晶

片之中，只有少數的腳位連接到晶片的外部。此時，針對這樣的微處理器，

我們在電路中加入了 TAP Controller以及 Embedded ICE的電路並且使用

JTAG來控制嵌入式電路擬真器進行除錯。

針對這樣嵌入於系統單晶片之電路擬真器，我們依然必須透過一個特

定的傳輸介面與嵌入式電路擬真器進行控制，包括將測試的指令送至嵌入

式電路擬真器中以及將測試的資料送至嵌入式微處理器執行。目前的作法

都是重複使用 IEEE 1149.1 Test Access Port and Boundary Scan Architecture的

電路，使用串列輸入的方式將測試、除錯的資料送到系統單晶片當中[11]。

SoC

Processor Core

IP Core

IP Core

IP Core

IP Core

IP Core

Embedded ICE

TAP Controller

JTAG 圖 2-4 Embedded ICE connection

13

一般來說，電路擬真器本身可以提供良好的除錯與測試機制，像是：單

步執行 (Single Step) 除錯、中斷點 (Breakpoint) 的設定與偵測、內部資源

的監督與修改...等等。此外，由於嵌入式電路擬真器重複使用了 JTAG接腳，

因此其最主要優點即在於測試者只需使用四條線的 JTAG Port (TCK, TMS

TDI, TDO)就可以提供相當良好的系統控制能力（IEEE 1149.1的規格中本

身提供五條訊號線，但一般只需要用到四條即可），而且以主從模式的靜態

除錯 (Static Debug) 方式控制整個除錯系統。所謂的靜態除錯指的是在我們

要將微處理器的資訊 (如：暫存器的狀態)傳出前，我們必須先將微處理器

的時脈停止下來，然後透過慢速的 JTAG 串列介面來傳遞測試樣本 (Test

Patterns)。

� JTAG 架構架構架構架構

IEEE Std. 1149.1 Boundary Scan Architecture（或稱之為 JTAG）是由

Joint European Test Action Group於 1985年所發表。隔年，此組織將北美

的研究團隊納入其中，正式改名為 Joint Test Action Group [12]。

JTAG最主要的目的是要制訂一個標準化的測試連接埠以及邊界掃瞄

(Boundary Scan)的架構。透過 IEEE 1149.1 Boundary Scan Architecture的實

現，我們針對一個電路板要進行測試的話，我們只需要多規劃出五根 JTAG

所需要用的腳位，透過電路板上的 TAP controller控制、傳送 testbench。

其概念如圖 2-5Board level Boundary Scan architecture所示。我們使用 JTAG

對電路板做測試時，首先要將電路板上的邏輯電路的接腳使用邊界掃瞄包

起來，然後再將各個掃瞄串列(Scan chain)以串接的方式串起來。接下來，

我們就可以透過這一條串列的通道將測試資料由 serial data in傳送至待測

的邏輯電路之中。而另外，我們可以藉由 serial data out輸出腳位觀察待測

邏輯電路的執行結果。

14

Logic circuit Logic circuit

Logic circuitLogic circuit

Serial data in

Serial data out

圖 2-5Board level Boundary Scan architecture

傳統上，JTAG的電路架構如圖 2-6 JTAG architecture所示。除錯者將

要除錯的指令或是資料透過 TDI 傳送至電路中。而要決定目前是送的是

除錯的指令或是除錯的資料則是由 TMS 所控制的有限狀態機的狀態來決

定。

TAPController

InstructionRegister

Decode Logic

Internal Logic

Data Register 1

Bypass Register

TCK

TMS

TDI

MUX TDO

Data Register 2

圖 2-6 JTAG architecture

圖 2-7 TAP Finite State Machine即為一個標準 IEEE 1149.1所定義的

TAP 有限狀態機，狀態機中各種狀態的轉移皆由 TMS 所輸入的訊號所決

定。當我們的電路重置時，此有限狀態機會處於 Test-Logic-Reset的狀態。

15

而此有限狀態機有一個非常良好的設計，就是不管目前的有限狀態機是處

於什麼樣的狀態，只要除錯者對 TMS 連續輸入五個以上的邏輯 1 時，此

有限狀態機就回到 Test-Logic-Reset的狀態，相當於輸入一個 TRST的訊

號。藉由這樣的設計，我們便可以依據我們的需求考慮省去 TRST的腳位。

當此 TAP 有限狀態機進入到在圖中靠左邊的那一排狀態時代表目前除錯

者從 TDI 輸入的是除錯的資料，而當進入到在右邊的那一排狀態時則是

表示目前除錯者從 TDI 所輸入的是除錯的指令。

Select-DR-Scan

Capture-DR

Shift-DR

Exit1-DR

Pause-DR

Exit2-DR

Update-DR

Select-ER-Scan

Capture-IR

Shift-IR

Exit1-IR

Pause-IR

Exit2-IR

Update-IR

Run-Test/Idle

Test-Logic-Reset

1

1

1

1

1

1

1

1

1

1

1

1

1 1

1

0

0

0

0

0

0

0

0

11

00

0 0

00

0 0

圖 2-7 TAP Finite State Machine

由於 IEEE Std. 1149.1的架構相當的簡單，並且在設計上面不會對電

路造成太大的負擔，不管是面積上、速度上亦或是耗電上。因此目前大部

分的測試及除錯的機制都是採用 JTAG 作為測試及除錯資料的基礎傳輸

介面。

� 嵌入式電路擬真器嵌入式電路擬真器嵌入式電路擬真器嵌入式電路擬真器

在嵌入式電路擬真器中，我們可以把其中負責控制、偵測微處理器狀

態的電路稱之為嵌入式電路擬真除錯電路，這個電路主要包含了中斷偵測

16

單元(Breakpoint Detection Unit)、微處理器介面(Processor Interface)、識別

暫存器(ID Register)、測試資料輸出選擇器(TDO selector)以及一條特殊結

構的掃瞄串列。如圖 2-8 Embedded ICE component所示

圖 2-8 Embedded ICE component

� 微處理器界面微處理器界面微處理器界面微處理器界面

微處理器介面最主要是用來與微處理器溝通的橋樑。由於每一種微

處理器所定義用來除錯的訊號以及其時序皆有所不同，因此嵌入式電路

擬真器當遇到觸發事件時（如遇到中斷點）要通知微處理器時，我們必

須透過這樣的一個電路做訊號與時序轉換的動作。

以 ARM 的例子來說，當 Embedded ICE遇到中斷點的時候，

Embedded ICE會透過此介面發出一個中斷訊號通知微處理器遇到中斷

點事件，然後再等待微處理器處理完除錯的前置處理之後回應的訊號，

表示微處理器已經可以進入除錯的狀態了。最後，此介面會將狀態調整

至除錯狀態，並且通知 Embedded ICE更新狀態暫存器，讓使用者能夠

透過狀態暫存器知道微處理器已經準備好進行除錯了。

� 中斷偵測單元中斷偵測單元中斷偵測單元中斷偵測單元

中斷偵測單元是嵌入式電路擬真器最為重要的一個部分，負責偵測

17

偉處理器的執行狀態是否與除錯者所設定的中斷條件相符合。若是偵測

到相符合的資訊，則此中斷偵測單元就會發出中斷訊號給微處理器，通

知微處理器將控制權交給嵌入式電路擬真器。圖 2-9Breakpoint Detection

Unit architecture是一個中斷偵測單元的基本架構圖，在圖中最左邊的區

塊是一個掃瞄串列。除錯者透過 TDI 將測試的資訊送入這個測試串中，

等到 TAP 有限狀態機進到 Update-DR的狀態時，除錯者的除錯資訊將

會被送進中斷偵測單元。在此掃瞄串的低位元部分存放的是要送入的暫

存器位址，而高位元部分存放的是要送入暫存器的除錯資訊。圖中的右

下方大的區塊是一個暫存器的集合，主要是存放除錯者要對微處理器進

行除錯的資訊。當微處理器在執行的時候，中斷偵測單元會去監視處理

器的位址匯流排以及資料匯流排並且將這些資訊與內部的暫存器所儲

存的資訊作比對。一旦比對到與除錯者除錯資訊相符合的資料，中斷偵

測單元就會發出中斷訊號。此時，微處理器會進入到除錯模式，由除錯

者經由嵌入式電路擬真器控制微處理器的運作。

Breakpoint Detection Unit

Configuration data

R/WB

reakpoin

t register IDB

reakpoint reg

ister info

rmation

TD

O

Breakpoint ID Decoder

Va

lue 1

Mask 1 ...

Microprocessor core

address

data

control

Breakpoint matched

Update

TD

I

Brea

kpoint co

nfiguration

registe

r

To M/I interface

Comparator

圖 2-9Breakpoint Detection Unit architecture

2.3 用於控制電路擬真器之除錯器用於控制電路擬真器之除錯器用於控制電路擬真器之除錯器用於控制電路擬真器之除錯器

上述已對傳統除錯的硬體架構有大概了解，在此節中，我們將介紹一般除錯

18

工具軟體，另外我們還會分析目前常見除錯工具軟體所提供的一些除錯功能並且

在最後蒐集目前市面上的一些個人電腦端的除錯軟體，對其做一些簡單的介紹。

2.3.1 Open On-Chip Debugger [2]

OpenOCD是一個 open source software，它是用 emulator來做 debug tool

chain的軟體端，相當於 ARM 公司出品的 RVDS [18] (RealView Development

Suite)或者或者另外一套商業化除錯軟體 HJTAG[3]，但是都不是 OpenSource，

OpenOCD可以接受來自 GDB經由 RSP (Remote Serial Protocol)方式連接與使用

telnet方式來連接。

OpenOCD本身也支援相當多的 protocol converter，例如 FTDI 公司出產的

ft2232D與 ft2232H，和別家公司的 USBprog 、USB – Prest、Versaloon-Link、

ARM-JTAG-EW、Buspirate等等…。

OpenOCD本身的特色是可以藉由撰寫 configuration file來 retarget到不同的

processor如圖 2-1所示，而不用因為要支援別的 processor而重新編譯

OpenOCD，OpenOCD本身支援的 processor種類有 ARM 720t、ARM 7tdmi、

ARM 920t、ARM 926ejs、ARM 9tdmi、ARM 11、Cortex等等…。

圖 2-10 OpenOCD retarget idea

OpenOCD模組如圖 2-11 所示，可以分為六個模組，分別是 Daemon、

OpenOCD GDB server、OpenOCD CLI server、Target、Flash和 JTAG。

19

圖 2-11 OpenOCD modules

� 各模組說明如下：

A. Daemon：由於 OpenOCD對外與 GDB或者 telnet 溝通的管道皆

是藉由 TCP/IP網路協定方式來溝通，所以在 OpenOCD六個模組中必

定會有一個模組負責監聽網路的傳輸，把屬於 OpenOCD的封包抓進來

OpenOCD處理，而這個模組就是 Daemon 模組，其意義就是常駐於

PC作業系統中監聽屬於 OpenOCD的網路封包，OpenOCD通常開啟

telnet TCP/IP port是 4444，GDB TCP/IP port是 3333，TCP/IP port的選

擇可以透過修改 OpenOCD configure file來達成。

B. OpenOCD GDB server：當使用者藉由 GDB 方式來操控 OpenOCD

時，GDB與 OpenOCD溝通方式是採用 RSP協定來溝通，所以在

OpenOCD裡面一定要有一個模組來解譯從 GDB來的 RSP命令以及組

織 RSP回傳的命令給 GDB；所以 Daemon模組傳來的封包資料組合成

一個完整的命令之後，判斷是屬於 RSP協定，就會將該 RSP命令傳給

OpenOCD GDB server來做解析。

C. OpenOCD CLI server：同理當使用者使用 telnet方式來操控

OpenOCD時，也需要一個模組來解譯 telnet協定，所以當 Daemon模

組傳來的封包資料組合成一個完整的命令之後，判斷是屬於 telnet協

20

定，就會將該 telnet命令傳給 OpenOCD CLI server來做解析。

D. Target：此模組可以說是 OpenOCD裡面最重要的模組，因為針對

對不同的 processor會有不同的 JTAG訊號的設定與取方式，其因是

ICE scan-chain組態不一樣，例如 IR 的長度與 command會不一樣或者

DR 長度也會不一樣，以至於如何針對連接不同 processor，還可以提供

正確的組態來存取，是一個重要的課題，所以 Target模組提供不同且

豐富 processor組態來支援不同的 processor，OpenOCD會依照

OpenOCD configure file內容來決定使用哪個 processor組態，其組態內

容可以細分為兩大類：

1. Target Handle function：處理針對從 GDB來的不同 debug

event對應到相對應的處理函式，主要針對不同的 processor提供

不一樣的 JTAG存取次序。

2. Target HW information：針對不同 processor提供不一樣的

scan-chain組態，例如提供某 processor IR長度與命令或 DR 的長

度等…。

E. JTAG：當組態都設定好之後，真正需要與外部 processor溝通之

時就需要 JTAG模組，主要掌管如何使用 protocolconverter的 API 來達

到跟外部 processor溝通的目的。

2.3.2 GDB [6]

GDB是 GNU 計畫所發展的一套標準的除錯器[6]，它支援了多種程式

語言的除錯功能，諸如 C, C++, Fortran, Java等 GDB都在能支援除錯的功

能。在支援的程式語言中，其中支援最完整的就是 C 與 C++，至於其他語

言的支援目前來說也正在持續在改進中。我們可以這麼說，只要是 GCC [5]

編譯器所支援的程式語言，其除錯的部分或多或少都可以使用GDB來完成。

GDB與一般常見的編譯器以及除錯器的運作方式一樣，當我們要使用

GDB 來進行程式除錯之前，我們必須下特別的參數給編譯器，對於 GCC

編譯器而言，此參數便是「-g」。此時，編譯器在編譯程式時會加入一些除

錯的資訊，如此編譯完成的程式在 GDB 下除錯時，GDB 才能從中解析出

每個程式位址所代表的變數名稱，以及它們在程式的原始碼中的位置，以方

便我們的除錯工作。

由此可見，一個支援原始碼層次的除錯工作並不是只需要除錯器的配

21

合的，事實上要完成這樣的除錯工作還必須編譯器與除錯器互相配合才行。

如果編譯器的編譯結果內含了不適當的除錯資訊，則除錯器仍然無法對該

程式進行除錯的工作。這也是為什麼 GDB對於其他語言如 Fortran 等的支

援仍不足的原因，除了 GDB本身要改進，編譯器那邊也需要配合改進才行。

除此之外，編譯器在編譯程式時，其產生目的碼的方式也直接影響了程式能

否在除錯器中除錯，例如對於 Chill 與 Modula-2 而言，GDB 目前只能接

受來自 GCC 家族編譯器所編出來的程式碼，至於其他的編譯器則還沒有

辦法。

2.4 SC-RTL 協同模擬平台協同模擬平台協同模擬平台協同模擬平台

Platform Architect由 synopsis公司發行，主要目的用來分析與模擬硬體架構

效率，是以 systemc方式模擬，內部提供許多元件給使用者架構硬體環境，例如

小至時脈產生器、reset產生器、反向器，大至 AHB BUS、ARM7、ARM9 等大

型元件。

此平台除了純粹以 systemc方式模擬外，亦可加入 RTL code與 systemc協同

模擬，此功能在本論文相當重要，主要用來虛擬化 CPU+EICE端。

圖 2-12 Platform Architect

22

Chapter 3 SYS32TM-OpenOCD 協同驗證平台協同驗證平台協同驗證平台協同驗證平台

此章介紹有關協同驗證平台的動機、研究方法、架構和原理，即為什麼需要

協同驗證平台、如何實做出來、協同驗證平台的架構與原理最後，會詳細介紹如

何使用協同驗證平台。

3.1 協同驗證平台開發動機協同驗證平台開發動機協同驗證平台開發動機協同驗證平台開發動機

EICE

CPUJTAGJTAG

pattern we thought

1.RTL simulation for EICE verification

EICE

CPUJTAGdebugger

2.In FPGA,we control EICE by debugger

Spend RTL Synthetize time

By readdebuggermessage

3.Try to find bug

OK not OK

4.Add monitor to RTL design

Msg is not

enough

EICE

CPU

monitor

1.Spend RTL Re- synthetize Time2.witch signal real want3.break original Design4.monitor length is limited

Maybe find root problem

圖 3-1 Traditional find bugs between debugger and EICE

由於實驗是有自主開發的 CPU，當研發到雛型階段需要 debugger與 EICE輔

助開發週邊，但是 debugger與 EICE本身開發驗證也是個問題，傳統上 debugger

與 EICE本身開發驗證分 4個步驟：

� 1.會先在 RTL 模擬階段模擬預想的 JTAG pattern，直到模擬結果正

確之後。

� 2.花費一段合成時間後，EICE與 CPU燒入到 FPGA內與 debugger

相接，以控制 EICE模組，但是通常時候都會發生無法控制的型況。

� 3.為了解決，由於 FPGA內部訊號無法觀察，首先會去查看 debugger

message去猜想 bug在何處。

� 4.有時候只有 debugger message是不夠的，會希望能看到 FPGA內

部訊號，所以只好插入 monitor模組，但是插入模組有以下缺點：

� 花費重新合成時間。

� 只能猜想可能發生問題的訊號，但這訊號不一定是造成問題所

在。

� 加入 monitor模組會破壞原先硬體設計，造成新問題。

23

� monitor追蹤長度有限。

執行完 4 這動作，得到可能造成問題的 pattern，在回到 1 把新 parrten模擬

後，重複執行 1～4，這顯得非常的花費時間。

EICE

CPUJTAGdebugger

1.RTL simulation for EICE verification

圖 3-2 ideal of this thesis

所以本論文的主要想法是在 RTL 模擬階段就可以連接 debugger，一同執行

模擬使之得到以下好處：

� 節省合成時間。

� 不會破壞原本設計去加入 monitor。

� 不用擔心 monitor追蹤長度。

� 不用思考要抓取哪些訊號給 monitor。

預計省到多少時間，可以依照下列分析：

Time Traditional verification Proposed

verification

Synthesize time 30 mins

(CPU+EICE+BUS+mem)

none

Time of Monitor adding 1 hr. none

Simulation time < 2 mins 20 mins

Iteration for finding root bug 2~5 times 1 times

Total cost 3~7.5 hr. 20 mins

表 3-1 time spending compared between traditional and proposed verification

上表主要第一項是合成時間，傳統方法指的是需要將欲驗證的硬體合成並

燒入 FPGA進行驗證，而提出的方法是 debugger可以直接與 RTL simulator相

接，所以傳統方法需要合成時間，大約合成一次需要 30分鐘的時間，而本論文

提出的方法不需要成時間，第二項是加入 monitor發費的時間，由於傳統方法

要抓取 FPGA內部訊號，必須在待驗證的硬體內部加入 monitor，所以需要去思

考要觀測哪些訊號，決定之後還要去更改硬體內部設計加入 monitor，這過程大

約要花費 1小時，而本論文提出的方法是使用 RTL simulator所以不用擔心要抓

取哪些訊號，直接將所有訊號擷取出來成波形檔就可以了，所以這部份的時間

花費不需要，第三項是模擬時間，由於傳統方法是使用 FPGA來模擬，所以每

次模擬只花費小於 2分鐘的時間，而提出的方法由於是使用 RTL simulator模

擬，所以每次模擬花費時間大約是 20分鐘左右，第四項是如果要找到 root bug

24

的話，需要第一項到第三項重複執行幾次，傳統方法無法第一次決定哪些訊號

加入 monitor就可以找到 root bug，通常需要 2～5次的重複來決定哪些訊號要

加入才能找到 root bug，而本論文提出的辦法由於是使用 RTL simulator，所以

只需要一次就可以擷取所有訊號，所以不需要重複只需要執行一次。

傳統的方法合成時間最快也要 30分鐘，還僅僅只是最簡單的環境，然後出

了問題還要安插 monitor，安插 monitor包含思考要觀測哪些訊號與安插動作最

起碼也需要 1小時，通常這程序找到一個 bug通常需要執行 2～5次，所以花費

時間大概需要 3～7.5小時；至於本論文所提到的方法優點是不用合成時間與安

插 monitor發費時間，但所需要的模擬時間比傳統驗證方法還長，大約是 20分

鐘，但是也就只花費 20分就可得到原本在 FPGA看不到的訊號，所以解決一個

bug發費時間大概也就 20分鐘左右比傳統驗証方法快上 9～22.5倍。

FPGA執行 RTL simulation移動到使用 RTL simulator執行 RTL simulation，

最主要的的差別是無法觀測到實際硬體訊號的 timing delay，但是本論文主要領

域是專注於前端設計邏輯錯誤的除錯上，而不是後端 timing delay除錯，希望在

前端就可以將所有邏輯錯誤解決。debugger與 EICE無法正常運作絕大多數是

因為設計邏輯上的錯誤，傳統的驗證方法是把前端的邏輯錯誤放置到後端，會

變得難以解決，debugger直接可以連接 RTL simulator是解決大部分問題最好的

時間點。

至於 monitor有多少有訊號可以量測，又可以追蹤多長，做了 monitor (以

chip scope為例) 與本篇論文採用的 RTL simulator (NC-verilog) 追蹤訊號量與長

度分析：（以 chip scope可挑選的最大值為例）

Compared item Chip scope NC-verilog

Signal number 4,096 bits A mount of entire chip signal number

Trace length 131,072 cycles As long as simulation time

表 3-2 signal number and trace length comparing

上表第一項所比較的是追蹤的訊號量，Chip scope最大值只能追蹤 4,096

bits，而 NC-verilog由於是 RTL simulator所以可以追蹤的量就是硬體內所有訊

號，第二項比較的是追蹤長度，Chip scope追蹤長度最大值是 131,072 cycles，

而 NC-verilog追蹤長度是從模擬一開始到結束，

可以看到，原本採用的傳統方法不管是訊號個數或者追蹤長度都是受限

的，而且基於 FPAG的容量有限情況下，也不一定能達到這麼多的訊號個數與

追蹤長度，而本論文所採用的 RTL simulator就沒有此限制。

25

3.2 協同驗證平協同驗證平協同驗證平協同驗證平台研究方法台研究方法台研究方法台研究方法

A.Debuger

B.USB/JTAG protocol

converter

C.RTL

(download in FPGA)USB JTAG

hardwaresoftware

圖 3-3 traditional program debug method

現行的 debug tool chain可以分作 software與 hardware兩側，如圖 3-3，A.

Debugger例如 ARM RVDS 或 GDB+OpenOCD提供 GUI 或 command方式給使

用者使用，hardware端可以分作 B.連接 debugger與 RTL 的 USB/JTAG protocol

converter，例如 ft2232，也就是 adapter，其目的是協助 debugger與 RTL（硬體）

溝通，與 C.目標硬體，必需要有 EICE幫助以解析 JTAG訊號的硬體，例如 ARM

7或者實驗自主開發之 SYS32TM，以上均有 EICE幫助的處理器。

以上的 debug tool chain必須確定 debugger與 EICE是可以正常工作，在研

發 debugger與 EICE 之中必須重複的花費合成時間燒入進 FPGA再與 debugger

相接，非常的花費時間且不容易找出問題所在，所以本論文提出 EICE與 CPU在

RTL simulation階段就可以與 debugger相連接，以減少合成時間，在這樣需求下

也有尋找一篇相關論文 Virtual Development Environment [22]，可惜的是他全是採

用商業軟體建構而成，無法觀察 debugger與 EICE互動，不符合需求。

A.Debugger

(OpenOCD)

B.USB/JTAG protocol

converter

C.RTL

(RTL simulator)USB JTAG

hardwaresoftware

圖 3-4 propose co-verification platform

如圖 3-4，在 debug tool chain方面 A. software我們採用 Open source 的

OpenOCD，原因是 OpenOCD可以修改，不採用 HJTAG[3]與 RVDS[18]的原因它

們是商用 debugger，無法針對需求修改，OpenOCD方便以後可以配合不同的 RTL

目標或是使用不同的 USB/JTAG protocol converter控制 RTL，hardware裡面的

C.RTL變成在 RTL simulator上執行就可以，不用合成之後燒錄進 FPGA，達成節

省合成時間，與可以知道 Debugger（OpenOCD）與 RTL 互動情況；在一般情況

下是由 Debugger將 EICE control event（IRScan、DRscan和 RUNTEST）以 pattern

的方式傳給 RTL 執行模擬，所以接下來的問題就是：OpenOCD與 RTL simulator

要如何溝通。

在emulation時OpenOCD是透過實體的USB/JTAG protocol converter (ft2232)

26

與已載入到 FPGA的硬體溝通，所以 OpenOCD要與 RTL simulator溝通的關鍵

在於 2.USB/JTAG protocol converter，我們尋找了兩個可能解法分別如下，希望可

以將 EICE control event傳遞給 RTL simulator：

� PLI (Program Level Interface)

PLI 原先設計目的在於提供比 RTL 較高層次來撰寫 pattern的方法

（C code來撰寫 pattern）撰寫 pattern， PLI pattern撰寫完成後是

一併和待測 RTL 在 RTL simulator 上模擬，所以我們認為 PLI 合適

當為 OpenOCD與 RTL 的溝通橋樑。

1Debug software

(OpenOCD)

2USB/JTAG protocol

converter(PLI)

3RTLJTAG

Hardware (RTL simulator)software

P

P

C

C

圖 3-5 propose framework with PLI and RTL simulator

如上圖，是 protocol converter是採用 PLI 的方式，所以必須撰寫

PLI 程式碼使之可以接收從 OpenOCD來的 EICE control event並將

該 event轉換成 JTAG序列，以及收集從 RTL 來的 JTAG序列將之

轉換成以 16進位的資料型態回傳給 OpenOCD。接收 EICE control

event以及回傳 16進位的資料型態給 OpenOCD的實做方法我們採

用 IPC的 shared memory方式，P表示 producer表示將 EICE control

event或回傳的 16進位的資料傳送給 PLI converter或 OpenOCD；

C 表示 consumer表示從 OpenOCD或 PLI converter接收 EICE

control event或回傳的 16進位資料。

當 PLI 收到 EICE control event後，必須將之轉換成 JTAG序列執

行 RTL 模擬，之後接收 RTL 上 JTAG的回應，轉換成 16進位的資

料回傳給 OpenOCD，所以若採用 PLI 方式當 converter必須完成下

列幾件事：

� 以 PLI 方式實做出 producer與 comsumer功能模組

� 將 EICE control event轉換成 JTAG序列

� 將從 RTL 回來的 JTAG序列轉成 16進位的資料型態表示

� 知道 PLI 如何控制 RTL simulation停止與運作

� embecosm JTAGSC

此 embecosm JTAGSC是參考 embecosm EAN5 [4]而來的，提供

Reset、IRScan和 DRScan API給使用者使用，由 SystemC程式碼

撰寫，由於是由 SystemC組成所以必須在 SC-RTL co-simulation平

台上才能與 RTL 模擬，如下圖所示：

27

1Debugger

(OpenOCD)

2USB/JTAG protocol

converter( JTAGSC)

3RTL

(RTL simulator)JTAG

SC-RTL co-simulation platformsoftware

P

P

C

C

圖 3-6 propose framework with JTAGSC and co-simulation platform

由於 SC-RTL co-simulation平台執行 systemc與 RTL co-simulation，

所以與 RTL simulator溝通的是 JTAGSC，而 OpenOCD溝通的才是

JTAGSC，與 PLI 圖不同的是 OpenOCD溝通的對象是 JTAGSC而

不是 RTL simulator。為了達到 OpenOCD與 JTAGSC溝通，JTAGSC

採用透過 IPC 的 shared memory方式將 OpenOCD的 EICE control

event接收，並呼叫 API 轉成 JTAG序列透過 SC-RTL co-simulation

平台執行 RTL 模擬，之後收集從 RTL 來的訊號（即 TDO 訊號）

轉成 16進位的資料，回傳給 OpenOCD，所以若採用 JTAGSC只需

要達成幾件事：

� 以 SystemC方式實做出 producer與 comsumer功能模組

� 參照現有 API 把缺少的 JTAG功能（RUNTEST）實做出來

綜合以上所述，較若採用 embecosm JTAGSC會比較方便，因為本身已內建

產生 JTAG序列的方法，只要呼叫 Reset、IRScan和 DRScan API就可以將 Reset、

IRScan和 DRScan的資料轉成 JTAG 序列形式執行 RTL 模擬，而 co-simulation

platform又已經解決控制 RTL simulation的停止與運作問題，剩下要做的是只要

將缺少的 JTAG 功能加進 JTAGSC 當成 API 給使用者使用，以及實做 shared

memory的方式與 OpenOCD溝通，所以在此我們選擇 embecosm JTAGSC當成

OpenOCD與 RTL simulator溝通的橋樑。

3.3 OpenOCD與與與與 JTAGSC 如何連接如何連接如何連接如何連接

由於現在 USB/JTAG protocol converter轉換的對象已經不是 USB而是 EICE

control event，所以後續將稱為 EICE_control_event /JTAG protocol converter或者

直接稱呼為 JTAGSC，主要目的是當作 OpenOCD與 RTL simulator溝通界面。

在此章節會介紹若要將OpenOCD連接上JTAGSC透過SC-RTL co-simulation

平台幫助執行 co-verification 的話要如何修改，以下章節分別為基於 shared

memory的溝通方法設計、JTAGSC修改、OpenOCD修改；基於 shared memory

的溝通方法設計：說明 OpenOCD與 JTAGSC溝通需要怎樣的資料以及機制，

JTAGSC修改：說明要修改些什麼才能接收從 OpenOCD來的 EICE control event，

並且將 TDO來的值回傳給 OpenOCD，OpenOCD修改：說明應該修改些什麼才

28

能使 OpenOCD傳送 EICE control event給 JTAGSC並接收 JTAGSC回傳的的 16

進位資料。

3.3.1 基於共享記憶體技術的溝通機制基於共享記憶體技術的溝通機制基於共享記憶體技術的溝通機制基於共享記憶體技術的溝通機制

這一小章說明 OpenOCD與 JTSGSC如何溝通，基本上所採取的方法是基於

shared memory技術，其運作如下圖所示：

OpenOCD shm JTAGSC shm

RTL(RTL simulator)

SC-RTL co-simulation platformSoftware

P1

P2

C1

C2

1. turn 8 bit array into

EICE control event

3.turn debug event into JTAG

sequence

4.collect TDO signal to hex

data

5.pass the hex data by shm

producer

2.recive EICE control event by shm consumer

2.wait for Reply form consumer

6.hex data turn into 8 bit array

passed to OpenOCD

圖 3-7 shared memory communication working flow

圖 3-7可以分作兩邊，software部份主要就是 OpenOCD shm，表示 OpenOCD

採用以 shared memory為基礎的溝通機制，SC-RTL co-simulation平台部份就是

JTAGSC shm也就是 JTAGSC shm也採用以 shared memory為基礎的溝通機制；

SC-RTL co-simulation平台這邊則是 JTAGSC（EICE_control_event /JTAG protocol

converter）以及 RTL，主要執行 JTAGSC與 RTL co-simulation， RTL simulation

執行的 pattern是藉由 JTAGSC以 shared memory的方式從 OpenOCD得來的，達

成將 OpenOCD與 RTL 執行協同驗證目的。主要可以分作六個步驟與兩種不同

的 shared memory的資料，下列會依照這六個步驟逐一說明，並且敘述不同的

shared memory的資料，分別是 EICE control event以及 16進位資料（hex data）。

第一步驟：在 OpenOCD端，先把欲要與 RTL 執行協同驗證的 EICE control

event由 8bit array轉成 16進位的 array，並且將一些資訊，如：是否是 IR Scan、

欲要 Scan的位元數、是怎樣的 JTAG指令等等…，集合在一個 shared memory的

結構體裡面，稱之為 EICE control event的結構體，並藉由 shared memory機制中

producer 傳給 EICE_control_event/JTAG protocol converter，也就是上圖的 P1與

29

C1，P表示 producer，C 表示 consumer，1表示共享 index 同為某值（假設為 t）

的記憶體空間，該記憶體空間放置的就是 EICE control event。

第二步驟：OpenOCD等在資料從 C2回來， JTAGSC藉由 shared memory機

制中 consumer將 EICE control event從 index為 t 的 shared memory讀進來，也就

是 C1。

第三步驟：使用 JTAGSC提供的 API 將 EICE control event轉換成 JTAG序

列執行 RTL 模擬，並且一併將 RTL TDO的值收集起來，並轉換成 16進位的資

料表示，也就是步驟四。。

第五步驟：將轉換完成的 16進位資料以 shared memory機制中 producer傳

給 OpenOCD，也就是 P2，P表示 producer，C 表示 consumer，2表示共享 index

為同為某值（假設為 u）的記憶體空間，該記憶體空間放置的就是 TDO轉換的 16

進位的資料。

第六步驟：當 OpenOCD透過 C2得知已有資料從 JTAGSC回來後，就會執

行此步驟，也就是將 16進位表示的資料轉換成 8bit array給 OpenOCD使用。

接下來講述 EICE control event的組成以及 TDO 經由轉換後以 16進位表示

的資料組成：

圖 3-8 EICE control event context

上圖是 EICE control event的組成，共有五筆資料分別是：

� write_by_you：控制 P1與 C1互斥機制的訊號。

� is_ir：此 debug enent是否是 IR Scan或 DR Scan；為 1表示是 IR Scan、

為 0表示是 DR Scan、為 3表示是 RUNTEST。

� num_bit：紀錄此 EICE control event需要 Scan多少位元。

� scan_type：紀錄此 EICE control event是否需要藉由 JTAGSC回傳從 RTL

回來的 TDO值。

� s_out_data：紀錄此 EICE control event要藉由 JTAGSC 進 RTL TDI 的

值。

30

圖 3-9 feed back data from hardware

上圖是 TDO經由轉換後以 16進位表示的資料組成，以結構體表示，也就是

P2與 C2共享的資料，裡面共有兩筆資料說明如下：

� write_by_you：控制 P2與 C2互斥機制的訊號。

� fb_data：存放著從 RTL 回應的 TDO 值，已經將之整理成 16進位資料

的形式，存放在 fb_data裡面，藉由 JTAGSC以 producer方法回傳給

OpenOCD。

3.3.2 補足補足補足補足 JTAGSC 不足之處的不足之處的不足之處的不足之處的修改修改修改修改

在附錄已經很明確的講解有關於 JTAGSC的檔案結構、運作架構、API 使用

與 API 運作原理；內建的 API 就只有 IR、DR、以及 Reset，若是要支援 OpenOCD

的連接是不夠的，在加上 OpenOCD本身會去控制 TAP FSM state移動到

RunTest/Idle狀態，所以依照目前 JTAGSC運作架構是不敷使用的，也必須做一

些更改，所以此章節會分成三大部份—API 新增、JTAGSC缺點和如何使用 shared

memory方式與 OpenOCD連接。。

� API 新增—RUNTEST

RUNTEST功能主要是先將 TAP FSM state移動到 Run-Test/Idle狀態，TMS

為 0 停留在 Run-Test/Idle數個 cycle，cycle數由 OpenOCD決定，其目的在於讓

CPU多走數個 cycle，執行由 boundary scan chain給 CPU的指令，因為只需要將

TAP FSM state移動到 Run-Test/Idle，在該 state停留數個 cycle，所以 runtest API

主要設定為兩個狀態，—移動到 Run-Test/Idle以及停留在 Run-Test/Idle數個 cycle。

RUNTEST API 運作狀態圖：

31

圖 3-10 RUNTEST API working flow

� JTAGSC缺點：描述 JTAGSC缺點，主要有分架構缺點以及運作架構的

缺點。會先說明架構缺點以及如何修改，之後會說明運作架構的缺點以

及如何修改。

� JTAGSC架構缺點：

JTAGSC在 SC-RTL co-simulation平台上的架構圖以及更新後的架

構圖：

SYS32TM+EICE(RTL)

EICE_control_event/JTAG signal

converter(JTAGSC)(systemC)

Platform Architect(before modify)

Clk_gen

TCKTCK

TMSTDITDOTRST

SYS32TM+EICE(RTL)

EICE_control_event/JTAG signal

converter(JTAGSC)(systemC)

Platform Architect(after modify)

Clk_gen

TCK

TCKTMSTDITDOTRST

圖 3-11 the architecture of Co-verification platform

上圖是 SC-RTL co-simulation平台上建造的架構簡易圖，主要有三

個區塊 JTAGSC、SYS32TM和 clk_gen；SYS32TM是我們實驗室開發

的 ARM7-like CPU，由於有 EICE 幫助可以接收 IEEE1149.1所定義的

TCK、TMS、TDI、TDO、TRST等五根腳位，進而達成控制 CPU的目

的，clk_gen是 clock產生器，是內建在 SC-RTL co-simulation平台裡面

的 library之一主要產生 clock的脈波。

上圖左邊的部份是一開始原先 JTAGSC 的架構，JTAGSC 主要將

clk_gen來的 clock 當成參考用的 TCK，只要在相對應的時間上傳送對

應的 TDI 與 TMS 的值，並且接收 TDO 就可以了，但是缺點是這樣一

來 JTAGSC無法藉由 TCK 控制 EICE的運作，EICE屬於一直在運作的

狀態，如果 JTAGSC暫時沒有 EICE control event需要轉換時會處於等

待狀態，所以輸出的 JTAG訊號是無意義的，但 EICE還繼續運作這樣

就會出錯，所以希望將架構更改成 EICE的 TCK 是由 JTAGSC來控制，

而 clk_gen就相當於 JTAGSC的振盪器，驅動 JTAGSC運作，將每筆的

EICE control event轉成 JTAG序列執行 RTL 模擬，如上圖右邊。

� JTAGSC運作缺點：

由圖 B-8可以看到，JTAGSC的運作是先執行 API決定 TMS與 TDI

後才去設定 current TapAction，接下來就將 TMS 與 TDI 執行一個

週期的 RTL 模擬，最後再判斷該 EICE control event是否結束，所

以這樣就會造成一個錯誤—當舊的 EICE control event結束停留在

32

JTAG的 Update state1後，新的 EICE control event開始執行應該由

Update state開始，但是實際狀況卻是由Update state的下一個Select-

DR-Scan開始。

Execute API process() function

Read next pattern from

FIFO

YES

Current event is finish?

NOFor getting TMS

and TDO of current TCK cycle

Set currentTapAction=

null

API return true

API return false

By ref.

currentTapAction(null:event is finish)

Update stateMachine and

active JTAG signal to RTL

圖 3-12 the arch. working flow after modification

為了解決上述問題，所以將 JTAGSC的運作修改成上述運作流程，

當 API return為 true時，就直接跳回判斷 EICE control event是否結

束，就可以使當 EICE control event結束後使 TAP FSM正確的停留

在 Update state。

� JTAGSC如何使用 shared memory方式與 OpenOCD連接：

在這部份，為了使 JTAGSC可以接收 OpenOCD的 EICE control event，

以及將 RTL TDO 值回傳給 OpenOCD，必須將上面所說的 JTAGSC shm機

制加入；當 JTAGSC 開始運做的時候給給 RTL 的 pattern 是被放置在

JtagSC::driver()裡面，所以在該函式內運行 shm_consume，其目的是要讀取

從 OpenOCD來的 EICE control event，就是圖 3-13第 7行 shm_consume。

1 以 DR Scan來說，就是停留在 Update-DR；IR Scan來說，就是停留在 Update-IR

33

Algorithm communication_with_OpenOCD #handle_EICE_control_eventinput：EICE_control_eventoutput：fb_databegin #get the EICE_control_event through shared memory, #i.e. scan_out_data[],total bit,scan->ir_scan,need_fb_fdata(scan) info call shm_consumer(FLAG1,scan_out_data[],talbit,ir_scan,need_fb_fdata); if ir_scan is 1 do call IR_SCAN_API(scan_out_data[],talbit); else if ir_scan is 0 do call DR_SCAN_API(scan_out_data[],talbit); else if ir_scan is 3 do call RUNTEST_API(talbit); endif

if need_fb_fdata is true do call get_data_from_scan_chain(scan_fb_data[]); #return TDO feed data to OpenOCD through shared memory call shm_producer(FLAG2,scan_fb_data[]); endifend

12345678910111213141516171819202122

圖 3-13 the algorithm of JTAGSC communication with OpenOCD by shared memory

上圖第#5~7行對應到圖 3-7 JTAGSC shm步驟 2，藉由 shared memory方式

從 OpenOCD讀取 EICE control event，第#9~15對應到圖 3-7 JTAGSC shm步驟 3

和 4，負責執行從 OpenOCD來的 EICE control event，並收集 TDO值，第#17~20

對應到圖 3-7 JTAGSC shm步驟 5，負責將 TDO值返回送給 OpenOCD以 shared

memory方式。

由上圖可以看到，#7 行會去讀取記憶體位址特徵為值 t 的位址，紀錄在

FLAG1變數內，該位址內容就是存放 EICE control event，也就是圖 3-4 P1與 C1

共享的位址。

在讀取之後，可以獲得想要 scan進硬體的 scan_out_data、總共 scan多少 bit

的 talbit、判斷是何種 scan的 ir_scan、和判斷是否需要將硬體 scan回來的資料回

傳給 OpenOCD的 need_fb_fdata。

在之後就會依照 ir_scan的值來執行不同的 API，最後再由 need_fb_fdata判

斷是否需要將硬體 scan出來的值回傳給 OpenOCD，若需要回傳其機制也是使用

shared memory的方式將 16進位資料回傳給 OpenOCD，透過寫入特徵值為 u 的

位址，紀錄在 FLAG2 變數內，將資料回傳給 OpenOCD，就是圖 3-7 P2與 C2共

享同一個記憶體位址。

3.3.3 OpenOCD新增新增新增新增 JTAGSC 驅動程式驅動程式驅動程式驅動程式與與與與初始化流程修改初始化流程修改初始化流程修改初始化流程修改

此章節會講到如何修改 OpenOCD使之可以使用 shared memory機制與

JTAGSC溝通以達到 co-verification的功能。

34

在進入修改之前，會先說明 OpenOCD如何使用，詳細範例請參考圖 4-4：

� 用上面的命令來開啟 OpenOCD，開啟 OpenOCD必須給予 cfg

file，cfg file 是用來設定 OpenOCD，主要設定三項：

� A.開啟 OpenOCD RSP的 TCP/IP port提供 GDB連接。

� B.通知 OpenOCD目前使用的 interface也就是 USB/JTAG

converter型號並初始化 converter。

� 使用 interface指定使用的 converter。

� interface ft2232 指定 ft2232為 converter幫助 OpenOCD

與 FPGA溝通。

� interface JTAGSC 指定 JTAGSC為 converter幫助

OpenOCD與 RTL simulator溝通。

� C.通知 OpenOCD目前要連接的 CPU型號(SYS32TM)。

� OpenOCD初始階段會透過 check TAP id code確定設定的

CPU＋EICE+型號與目前連接的 CPU＋EICE是否一致。

圖 3-14 OpenOCD initial flow and working flow

上圖左方是 OpenOCD初始化流程，以及初始化完成之後 OpenOCD控制流

展示在上圖右方，詳細部份請參照 Appendix A，在 OpenOCD初始化階段，Check

TAP id code會使用 DR scan輸入 50筆的 id code長度（也就是 50*32bit），確保

兩件事，第一：確定目前所連接的 CPU+EICE是否是是使用者設定的 CPU+EICE

型號，第二：確定 EICE DR scan chain是連通的。目前由於 EICE模組 id code是

採用暫存器形式而非 DR scan chain形式，所以先修改成只 DR scan輸入 1筆的

id code 長度來確定連接的 CPU+EICE，也就是說先將第二的功能關掉，使

OpenOCD可以成功完成初始化。

在 JTAG部份負責所有連接 CPU+EICE的 interface，所有的 interface驅動程

式均集合在這。OpenOCD透過 JTAGSC連接 CPU+EICE，所以 JTAGSC的驅動

也要撰寫在 JTAG模組裡，接下來描述的重點有 JTAGSC的驅動撰寫，與如何加

./openocd –f conf.cfg

35

入 JTAG模組使 OpenOCD可以使用 JTAGSC驅動。

JTAGSC驅動撰寫：

在開始 JTAGSC驅動撰寫之前，必須先了解在 OpenOCD裡面 JTAG cmd與

scan data如何定義，才好將 JTAG cmd或 scan data轉為 EICE control event存放

在 shared memory上以驅動 JTAGSC。

圖 3-15 scan data structure in OpenOCD

上圖是 OpenOCD對於 scan data的描寫，定義在 openocd/jtag/commands.h裡

面，結構體成員分別是：

� is_scan：辨別該 scan data是否是 IR 或 DR scan。

� num_fields：紀錄有多少個 fields在這 scan data裡面。

� fields：存放欲 scan進硬體的 data與從硬體 scan回來的 data，本身是陣

列所以要用 scan->fields[i]描述來存取（num_fields >i >= 0），每個 field

分別有三個結構成員 out_value、in_value和 num_bits：

� out_value：是陣列，每個單位大小為 8bit ，以 scan-

>fields[i].out_value[j]方式來存取（( num_bits/8+1)>j>= 0），存放欲

scan進硬體的 data。

� in_value：是陣列，每個單位大小為 8bit，以 scan->fields[i].in_value[j]

方式來存取（( num_bits/8+1)>j>= 0），存放從硬體 scan回來的 data。

� num_bits：紀錄該 fields有多少 bit 的資料。

� end_state：紀錄該 scan data完成後 TAP FSM該停留在那一個 state。

接下來說明 OpenOCD對於 JTAG cmd的描寫：

圖 3-16 JTAG cmd structure in OpenOCD

36

上圖是 OpenOCD對於 JTAG cmd的描寫，定義在 openocd/jtag/commands.h

裡面，結構體成員分別是：

� cmd：指標，指向該 cmd內容的結構體，例如如果是 scan應用，則會指

向上述所說的 scan command(即上述所說的 scan data)結構體。

� type：說明現在的 JTAG cmd是 scan command(即上述所說的 scan data)，

還是 runtest指令。

� next:指標，連接下一個 JTAG cmd。

當得知 OpenOCD對於 JTAG cmd與 scan data的描寫後，可以依照下面的演

算法將 JTAG cmd或 scan data轉成 EICE control event放置在 shared memory上，

驅動 JTAGSC接收。

Algorithm product_EICE_control_event (cmd, scan)input：struct jtag_command cmd, scan_command scanoutput：scan_command scanbegin #identify the cmd is scan or RUNTEST #if is scan, then get the total scan bit, IR or DR…info to EICE control event #else pass the cycle number and RUNTEST event as EICE control event to # JTAGSC by shared memory if cmd.type is scan do begin count_total_bit(talbit,scan); for i=0 to i<scan.num_fields step i++ do begin if scan->fields[i].out_value is not NULL do call 8bitary_to_64bitary(tmp[i][],scan->fields[i].out_value); else do call 8bitary_to_64bitary(tmp[i][],0x0); endif call 2d64bitary_to_1d64bitary(scan_out_data[],tmp[i][]); end #pass EICE control to JTAGSC by shared memory, #and get the TDO value form JTAGSC if needed shm_producer(FLAG1,scan_out_data[],talbit,scan->ir_scan,need_fb_data(scan)); if need_fb_data(scan) is true do call handel_fb_data(scan); endif end else if cmd.type is runtest do call shm_producer(FLAG1,bit_numberof(runtest),runtest_event); endifend

12345678910111213141516171819202122232425262728293031

圖 3-17 scan data to EICE control event algorithm

上圖#10~22對應到圖 3-7 OpenOCD shm步驟 1，主要目的是將 OpenOCD上

層來的 cmd轉換成 EICE control event並以 shared memory方式傳送給 JTAGSC，

#24~25對應到圖 3-7 OpenOCD shm步驟 2和 6，主要目的等待並讀取從 JTAGSC

返回的 TDO值，並將 TDO值傳送至 OpenOCD上層的 cmd。

37

該演算法首先先判斷該 cmd哪種命令，若是 scan data，則將 scan data總共

需要多少 scan bit計算出來，之後將 scan data要 scan到硬體的資料先轉換成二

維的 64bit 陣列，之後在將該二維 64bit 陣列轉換成一維的 64bit 陣列，也就是

scan_out_data[]，之後在透過 shared memory中的producer 機制將 scan_out_data[]、

total_bit、是 IR 或 DR 的資訊與需不需要將硬體傳回來的資料傳回給 OpenOCD

等等這些資訊寫入 EICE control event並放入特徵值為 t 的記憶體位址裡面，t 存

放在變數 FLAG1裡。

若 need_fb_data(scan)為 true時候，表示需要 JTAGSC將從硬體 TDO回來的

16進位資料往 OpenOCD回傳，此時 OpenOCD必須要有機制將 16進位資料轉

換成 scan data的描寫，由於 16進位資料是以 64bits陣列形式存放，所以也就是

將 64bits陣列轉換成二維的 8bits陣列。

若 cmd是 runtest的話就將，這 runtest需要多少 bit 以及將該 cmd是 runtest

的資訊放入 debug_event裡面。

Algorithm handle_fb_data (scan)input：scan_command scanoutput：scan_command scanbegin call shm_consumer(FLAG2, fb_data[]); for i=0 to i<scan.num_fields step i++ do if scan->fields[i].out_value is not NULL do call 64bitary_to_8bitary(scan->fields[i].out_value, fb_data[]);end

123456789

圖 3-18 feed back data to scan data algorithm

以上演算法主要目的等待並讀取從 JTAGSC返回的 TDO 值，並將 TDO 值

傳送至 OpenOCD上層的 cmd。。

可以由上面演算法看出規則，首先先藉由 shared memory中 consumer機制

將特徵值為 u，存放在變數 FLAG2裡面，也就是存放 16進位資料的位址，將裡

面的資料讀進 OpenOCD內，之後在轉換成二維的 8bits陣列。

新增 JTAGSC驅動到 OpenOCD JTAG模組：

Return ERROK

Openocd/src/jtag/JTAGSC.c

Openocd/src/jtag/interfaces.c

圖 3-19 how to add interface driver

38

接下來我們已經有了如何驅動 JTAGSC 演算法，那麼接下來的問題是說如

何加入 OpenOCD成為眾多 interface driver之一：

� 開啟 openocd/src/jtag/interfaces.c將 JTAGSC_interface加入。

� JTAGSC_interface是一個 jtag_interface結構體，提供處理 OpenOCD

JTAG cmd的所有函式，定義在每個驅動程式碼裡面，以此例來講就是

在/openocd/src/jtag/JTAGSC.c裡面。

� JTAGSC_interface說明：

成員指到的內容說明

.name “JTAGSC” Interface 命令就是依

照 .name 內容尋找使

用的 driver。

.commands JTAGSC_command_handlers 指定 TCL 命令處理函

式

.init &JTAGSC_init converter組態設定，由

於這是對於實體

converter設定的內容，

JTAGSC不需要這些，

所以基本上直接

retrun ERROR_OK;

.quit &JTAGSC_quit

.speed &JTAGSC_speed

.speed_div &JTAGSC_speed_div

.khz &JTAGSC_khz

.execute_queue &JTAGSC_execute_queue JTAGSC 的驅動就是

實作在這函式裡面。

表 3-3OpenOCD JTAGSC driver

經由上述的修改後，OpenOCD已經可以使用 JTAGSC為 interface跟 RTL

simulator溝通，用新增的方式加入 JTAGSC driver的好處是：以後要使用不同

的 converter當 interface只要修改 conf.cfg內容 interface描述就可以切換不同

converter不用重新編譯 OpenOCD。

39

3.3.4 協同驗證平台協同驗證平台協同驗證平台協同驗證平台總觀總觀總觀總觀

Debugger(OpenOCD)

EICE_control_event/JTAG protocol

converter( JTAGSC)

EASY_ENV

SC-RTL co-simulation platformSoftware(host)

Product_EICE_control

_event P1

P2

C1

C2

SYS32TM

AHB

ICE

Memory

SYS_clkTCK_clk

TCK

Hanlde_fb_data

圖 3-20 the final framework of co-verification environment

最後的架構圖如上圖所示，左方是運行 degugger一端主要由 OpenOCD以

shared memory方式與 JTAGSC溝通，右方是 SC-RTL co-simulation platform，在

SC-RTL co-simulation平台環境下把實驗室開發的 EASY 環境放入，以達到

SystemC與 RTL co-simulation 功能，EASY 環境下有實驗室自己開發的 ARM7-

like CUP也就是 SYS32TM，SYS32TM外面由 EICE模組所包，EICE模組實現

使用者可以設下 break point、watch point、read/write memory…等等的 debug指

令，EASY環境也內含從 CIC 參考並修改的 AHB 與 memory模組。

另外在 SC-RTL co-simulation平台上也放入修改過的 JTAGSC，將轉換後的

TDI、TDO、TMS、TCK 等訊號接入 EICE模組，另外在 SC-RTL co-simulation平

台裡面使用兩個內建的 clock模組，分別當作系統時脈（SYS_clk）作為整個 EASY

環境的時脈，以及 TCK 時脈（TCK_clk）當作 ICE 模組的時脈，TCK 時脈是系

統時脈的五分之一。

在 JTAGSC則是分別使用 shared memory 機制中的 consumer與 producer 從

OpenOCD接收 EICE control event與傳送從硬體 RTL 回傳的 16進位資料。

在OpenOCD方面則是使用 product_EICE_control_event以 shared memory 機

制中的 producer將 scan data轉換成 EICE control event傳送給 JTAGSC，再藉由

handle_fb_data以 shared memory 機制中的 consumer，接收從 JTAGSC回來的 16

進位資料轉換為 scan data。

3.4 協同驗證平台如何重複利用協同驗證平台如何重複利用協同驗證平台如何重複利用協同驗證平台如何重複利用

上述已描述 OpenOCD與 JTAGSC連接原理與 SC-RTL co-simulation平台內

40

部大概的接線，這章會詳細描述 OpenOCD與 JTAGSC如何操作才能連接，以及

SC-RTL co-simulation平台內部詳細接線與元件描述。

3.4.1 SC-RTL 協同協同協同協同模擬平台內部用到的元件與接線說明模擬平台內部用到的元件與接線說明模擬平台內部用到的元件與接線說明模擬平台內部用到的元件與接線說明

上述部份對 SC-RTL co-simulation平台內部主要元件與接線已有大概的認識，

所以這章描述 SC-RTL co-simulation平台內部用的的所有元件說明與接線，以便

以後方便連接不同的 RTL 模組。

RTL module

SYS_clkinverter

Reset generator

TCK_clk

Always low generator

inverter

Scan_data/JTAGconverter

圖 3-21 the component and connection in Platform Architect

開啟 SC-RTL co-simulation平台（專有名詞稱為 Platform Architect）後開啟

sthuang_new.xml就會得到上面的元件與接線圖，也是 SC-RTL co-simulation平台

內部詳細的架構，下面依照所有元件說明主要分三個部份，第一部份：clock, reset

和 inverter環境元件以及接線說明，第二部份：JTAGSC元件以及接線說明，第

三部份：RTL module元件以及接線說明。

第一部份：clock, reset和 inverter，屬於設定環境訊號的元件，第一欄為元件

的名稱、第二欄是元件功能或目的說明、第三欄是該元件 input port名稱、第四

欄是該 input port的輸入來源、第五欄是該元件的 output port名稱，第六欄是該

output port會接到哪的元件的 input port：

元件名稱功用說明 input

port 名

稱

輸入來源

(元件名稱

/port 名

稱)

output

port

名稱

輸出目標(元件名

稱/port 名稱)

41

i_C

lock

Gen

erat

o

r

RTL module主要

時脈

- - CLK i_sys32tm/XCLKI

N i_

Res

et

Gen

erat

or

Reset訊號產生元

件 (high active

reset)

- - RST i_inv/in

i_JtagSC/sysReset

i_C

lock

Gen

erat

o

r_1

i_JtagSC驅動時

脈

- - CLK i_JtagSC/tck

i_in

v

輸出是 low

active reset訊號

in i_ResetGe

nerator/RS

T

out i_sys32tm/nReset

i_in

v_1

輸入是 high

active trst訊號，

輸出是 low active

ntrst訊號

in i_JtagSC/t

rst

out i_sys32tm/ntrst

i_R

eset

Gen

erat

or_1

always low 訊號

的產生元件2

- - RST i_sys32tm/TESTR

EQA

i_sys32tm/TESTR

EQB

i_sys32tm/DBGR

Q

i_sys32tm/GDBB

REAK

i_sys32tm/EXTE

RN

i_R

eset

Ge

nera

tor_

2 always low 訊號

的產生元件 2

- - RST i_inv_2/in

i_in

v_2

輸入為 always

low 訊號，輸出為

always high訊號

in i_ResetGe

nerator_2/

RST

out i_sys32tm/DBGE

N

表 3-4 the environment component description

第二部份，i_JtagSC，也就是 EICE_control_event/JTAG converter，OpenOCD

2本來是 high active reset訊號產生元件，但因為沒有設定 reset時間點，所以是一直為 low 訊號

的產生元件

42

與 RTL 溝通的界面。說明 port功能與接線：

Port name Port說明輸入來源或輸出目標(元

件名稱/port 名稱)

sysReset input port（high active）：reset i_JtagSC，

使內部訊號獲得初始值

輸入來源：

i_ResetGenerator/RST

tck Input port(clock)： i_JtagSC運作時脈輸入來源：

i_ClockGenerator_1/CLK

tdo Input port(scan data)：從 RTL module scan

EICE out data的值

輸入來源：

i_sys32tm/TDO

tdi Output port(scan data)：輸入 RTL module

EICE scan in data的值

輸出目標：

i_sys32tm/TDI

tms Output port(JTAG FSM)：控制 RTL

module EICE內部 JTAG FSM移動訊號

輸出目標：

i_sys32tm/TMS

trst Output port(reset)：控制 RTL module

EICE reset訊號，因為是 high active所

以必需經過 i_inv_1轉成 low active訊號

才能接到 RTL module

輸出目標：i_inv_1/in

Tck_out Output port(clock)：控制 RTL module

EICE運作時脈

輸出目標：

i_sys32tm/TCK

表 3-5 JTACSC component description

第三部份，i_sys32tm是 EASY環境，也就是 RTL module，內含 sys32tm(EICE

與 sys32tm CPU), BUS與 memory RTL module。說明 port功能與接線；值得注意

的事情是 RTL module接線的重點在於 input port必須接線，而 output port可以視

情況而接，也就是說 output port接或不接均可，是需求而定，舉例來說 i_JtagSC

需要知道 i_sys32tm output port TDO值，所以 i_sys32tm的 TDO必需接到 i_JtagSC

的 tdo。

Port name Port說明輸入來源或輸出目標(元

件名稱/port 名稱)

XCLKIN Input port (clock)： i_sys32tm運作時

脈

輸入來源：

i_ClockGenerator/CLK

nReset Input port (low active reset)：

i_sys32tm reset訊號

輸入來源：i_inv/out

TESTREQA

TESTREQB

Input port： i_sys32tm TIC訊號，沒

有用到時候必須維持為 low

輸入來源：

i_ResetGenerator_1/RST

nTRST Input port (low active reset)：

i_sys32tmEICE reset訊號

輸入來源：i_inv_1/out

TDI Input port (scan data)： i_sys32tmEICE

scan in訊號

輸入來源：i_JtagSC /tdi

43

TMS Input port (JTAG FSM) ：

i_sys32tmEICE JTAG FSM移動控制

訊號

輸入來源：i_JtagSC /tms

DBGRQ Input port (trigger)： i_sys32tmEICE

cross trigger 訊號，使 EICE立即停止

sys32tm，沒有用到時維持為 low

輸入來源：


DBGBREAK Input port (trigger)： i_sys32tmEICE

cross trigger 訊號，使 EICE 控制

sys32tm完成執行當下 fetch到的指令

後停止，沒有用到時維持為 low

輸入來源：


DBGEN Input port (enable signal) ：

i_sys32tmEICE控制訊號，控制 EICE

是否運作，若要運作則要為 high

輸入來源：i_inv_2/out

TCK Input port (clock)：i_sys32tmEICE運

作時脈

輸入來源： i_JtagSC

/tck_out

EXTERN Input port：多個 CPU情況下前一級的

EICE設定輸入，如若沒有用到預設給

0

輸入來源：


TDO Output port (scan out data)：

i_sys32tmEICEscan out data，要連接到

i_JtagSC，才能知道 scan out的值

輸入來源：i_JtagSC /tdo

表 3-6 the RTL component description

3.4.2 如何使用協同驗證平台如何使用協同驗證平台如何使用協同驗證平台如何使用協同驗證平台

在得知如何接線後，些下來這章重點在於如何使用平台，使用平台主要有三

個步驟，第一：Platform Architect平台架構 export，第二：開啟 scsh使 SC-

RTL co-simulation平台開始執行 co-simulation，第三：開啟 OpenOCD連接

Platform Architect平台。

44

圖 3-22 the architect compile argument setting flow

第一步驟：基本上只要 Platform Architect內部架構出來的元件與接線不變，

此步驟只要作一次就可，此步驟目的是將 Platform Architect內部架構出來的元件

與接線產生可以讓 scsh執行的檔案，以便 scsh可以模擬運作此架構。

首先 Export->Export Design呼叫出 scsh模擬調整視窗，需要調整的參數與

說明如下：

設定欄位設定參數設定說明

Export Directory /home/sthuang/ICE_test/export_new_0618 指定產生出檔案

存放的資料夾，

以供 scsh執行

Linker Flags -ljtagsc 由於有用到

jtagsc元件，所以

必須指定參照

jtagsc的函式庫

HDL Library Map myLib=./hdl_lib Platform

Architect 使用

systemc 與 RTL

（使用 ncsim

simulator ） co-

simulation 固定

設定

HDL simulator ncsim

Verilog Compile

Options

-nowarn DLCLAP -mess -status -logfile

myvlog.log

HDL Elab Options -timescale 1ns/1ps -nowarn DLCLAP -

mess -status -logfile myvlog.log

HDL Run Options -nowarn DLCLAP -mess -status -logfile

myvlog.log

Verilog Timescale ps

表 3-7the architect compile argument setting value

第二步驟：export完成後，就可以開啟 scsh（systemc shell）模擬執行設計的

架構，進入 export的資料夾並開啟 scsh，輸入 source sim.tcl，讓 scsh開始編譯架

構的平台，順利編譯後打入 r (run)開始執行設計的架構模擬，設定完要觀測的

RTL 訊號後，打入 c (continue)執行模擬，此時 shm通道已打開等待 OpenOCD連

45

接，用圖解如下：

圖 3-23 the architect simulation flow

A：開啟 systemc shell。

B：編譯架構的平台。

C：編譯成功畫面。

D：開始執行 SC-RTL co-simulation，設定要觀測的 RTL 訊號後啟動 RTL

simulator。

E：啟動 RTL simulator之後，scsh繼續執行 SC-RTL co-simulation。

F：SC-RTL co-simulation執行中，已開啟 shm通道等待 OpenOCD連接。

第三步驟：架構模擬執行中，之後就可以開啟 OpenOCD以 shm通道連接，

OpenOCD連接成功就會顯示以下畫面，開啟 OpenOCD需要 jtagkey.cfg檔案，

該檔案內容請參考圖 4-4：

圖 3-24 OpenOCD connect to JTAGSC successfully

顯示表示已成功連接 JTAGSC（Platform Architect）並成功執行 DR scan的

46

到 EICE id值。

接下來講述之前提及的記憶體位址特徵為值 t 或 u 的位址要在哪裡修改，記

憶體位址特徵為值 t 是 P1與 C1共享的記憶體位址，而 u 是 P2與 C2共享的記

憶體位址。

ab

圖 3-25 location of shm address

如上圖表示：

� 記憶體位址特徵為值 t 修改，依此例 t =1124：

� P1是位於 shm.c #36行。

� C1是位於 JtagSC.cpp #520行。

� 記憶體位址特徵為值 u 修改，依此例 u =1321：

� P2是位於 JtagSC.cpp #686行。

� C1是位於 shm.c #2241行。

47

Chapter 4 實驗實驗實驗實驗

完成 OpenOCD與 RTL（SYS32TM）透過 JTAGSC

（EICE_control_event/JTAG converter）連接之後，此章節用四部份證明 co-

verification是可以運作的，第一部份呼叫 JTAGSC的 API 證明 JTAGSC是可以

產生正確的 JTAG訊號與 RTL 一起模擬，第二部分 OpenOCD執行 EICE control

event即 IR scan, DR scan和 RUNTEST功能，證明 OpenOCD與 JTAGSC溝通

正常，第三部份說明 GDB（GNU debugger）命令（read/write memory/register

之類的功能，由 EICE control event組合），證明 GDB命令透過 OpenOCD幫助

下是可以使用的；最後，第四部份用兩個例子證明並且說明 GNU compiler,

GDB與 OpenOCD如何使用。

Debug software(OpenOCD)

Scan_data/JTAG protocol converter

( JTAGSC)

EASY_ENV

Platform Architect (co-simulation)Software(host)

Product_EICE_control

_event P1

P2

C1

C2

SYS32TM

AHB

ICE

Memory

SYS_clkTCK_clk

TCK

Hanlde_fb_data

Debug software(GDB)

r/w memr/w reg

break pointWatch point

High level debug cmd

圖 4-1 final frame work with GDB

上圖說明跟圖 3-20 一樣，唯一不同的是現在有 GDB控制。

用圖片解釋：第一部份就是右邊虛線 Platform Architect部份，驗證

JTAGSC API是否可經由 JTAG訊號與 RTL 一起執行模擬，當第一部份可以正

常與 RTL 執行模擬之後，緊接著第二部份則著重在中間虛線部份–IPC驗證，

也就是 OpenOCD與 JTAGSC互動通道，其驗證角度在於當 OpenOCD執行

EICE control event （IR, DR scan與 RUNTEST動作）後 RTL 是否可以正確的

執行模擬，如果可以則表示通道可運作，反之則無，當第二部份驗證完成後，

就可以驗證第三部份，也就是 OpenOCD內部的高階除錯命令，例如讀寫記憶

體、讀寫暫存器、設定中斷點等等…，均是由 EICE control event組合而成，部

份則藉由 GDB以 RSP命令驅動 OpenOCD執行。

4.1 SC model (JTAGSC)和和和和 RTL model (SYS32TM+EICE)

48

可以正常執行協同模擬可以正常執行協同模擬可以正常執行協同模擬可以正常執行協同模擬

此章目的在於證明可以使用 JTAGSC API產生 JTAG訊號與 RTL 執行模

擬，第三章描述的 API 有用處的主要有三項—IR scan, DR scan 以及自行新增的

RUNTEST API，會證明這三個 API 是因為 EICE與 OpenOCD的互動全部都是

由執行這三種 API 組合而成。

� JTAGSC’s IR scan API：

JTAGSC API呼叫：IR scan

JTAGSC’s IR API, scan 0xc 4bit IR instruction.

It mean scan 4 bit scan, and value is 0xc.

IR scan RTL 結果：tap_instruction is change to 0xc

表 4-1 JTAGSC IR API experiment result

� JTAGSC’s DR scan API：

JTAGSC API呼叫：DR scan

JTAGSC’s DR API, scan 0x0 32bit DR for getting id code.

After get the id code then print it. it mean we can get the scan out data through

JTAGSC’s DR API.

DR scan RTL 結果：TDO get the value of 0x1f0f0f0f

49

表 4-2 JTAGSC DR API experiment result

� JTAGSC’s RUNTEST API：驅動 TAP FSM移動到 Run-Test/Idle state

JTAGSC API呼叫：RUNTEST

JTAGSC’s RUNTEST API, the TAP FSM will move to Run-Test/Idle state.

RUNTEST RTL結果：TAP_STATE (TAP FSM)移動到 Run-Test/Idle

d：Update-IR

c：Run-Test/Idle

表 4-3 JTAGSC RUNTEST API experiment result

4.2 OpenOCD與與與與 SC+RTL model互動驗證互動驗證互動驗證互動驗證

此章節會證明 OpenOCD IR,DR scan和 RUNTEST功能是有效的，依序說

明 IRscan,DR scan和 RUNTEST，上一章證明 JTAGSC與 RTL 協同模擬是有用

的，那麼這個實驗主要是從 OpenOCD端執行 IR,DR scan和 RUNTEST功能，

如果可以正確與 RTL 協同模擬，表示 OpenOCD與 JTAGSC的溝通 IPC通道是

有用的：

� IR scan：主要從 OpenOCD執行一筆 IR scan，觀察 RTL 是否有正確的將此

筆 IR 命令寫入。

OpenOCD 命令：irscan s3c4510.cpu 0xc

50

OpenOCD IRscan命令的 RTL 結果：tap_instruction is change to 0xc

� 開啟 OpenOCD後輸入 OpenOCD命令，測試 IR scan功能，從右圖顯

示 IRscan功能確實有正確與 RTL 協同模擬。

� DR scan：在 OpenOCD一開啟就會去使用 DR scan的到硬體 ID code，所以

當 OpenOCD成功啟動就表示 DR scan功能可以正確的與 RTL 協同模擬。

OpenOCD 啟動：自動執行 DR scan取得 id code

DR scan取得 id code的 RTL 結果：

� 當 OpenOCD開啟時候會使用 DR scan得到 id code，所以當 OpenOCD

可以成功開啟，表示可以透過 IPC呼叫 JTAGSC DR API成功取得 id

code。

51

� RUNTEST，從 OpenOCD下命令驅使 JTAG FSM移動到 Run-Test/Idle：

OpenOCD 命令：

runtest 1 RTL 結果：TAP_STATE (TAP FSM)移動到 Run-Test/Idle

� 經由 OpenOCD呼叫 RUNTEST功能，也成功反應在 RTL。

在第一部份已經證明 JTAGSC與 RTL 協同模擬是有作用的，那麼這次直接

從 OpenOCD執行 IR, DR scan和 RUNTEST功能，從上述展示結果來看也是可

以與 RTL 協同模擬，這表示 OpenOCD與 JTAGSC的 IPC溝通機制是可以正常

運作。

4.3 GDB 需要需要需要需要 EICE 幫助的除錯動作幫助的除錯動作幫助的除錯動作幫助的除錯動作

之前只是對單一 EICE control event執行實驗，接下來將 EICE control event

組合作更進一步的實驗，至於要如何組合才有意義，則採用實現高階除錯命令

的組合，例如該組合可以實現控制 EICE 讀寫 SYS32TM 暫存器、讀寫記憶體

之類的高階除錯命令，而該命令可以透過 GDB以 RSP方式觸發 OpenOCD執

行。

接下來描述在 OpenOCD內部的高階除錯命令內容，這些命令會與 RTL 協

同驗證，而驗證出來的 BUG說明與修改紀錄在 Appendix C內，這章節只是描

述與證明高階除錯命令已可正確無誤執行；這些命令都是由 IR,DR與

RUNTEST組合而成，OpenOCD高階除錯命令的執行必須藉由 GDB以 RSP命

令(透過 TCP/IP網路協定)觸發，舉例來說，當 GDB執行讀取記憶體的命令時

就會透過 RSP觸發在 OpenOCD內部一連串的 IR,DR與 RUNTEST組合，而那

些組合就會幫助 GDB 實現讀取記憶體的功能，那一連串的組合就稱作讀取記

憶體高階除錯命令；換句話說當 GDB需要執行高階除錯命令時 GDB只是將需

求往外丟給 OpenOCD，由 OpenOCD來幫 GDB實現高階除錯命令內容。

52

GDB命令主要分為三種：第一種是 GDB組態設定，主要用來控制 GDB內

部組態設定，例如 set remotetimeout命令主要是設定當 GDB用 TCP/IP連接

OpenOCD後，GDB判斷 OpenOCD是否有繼續連接的 time out 極限值，第二

種是 GDB控制設定，主要控制 GDB要對哪個目標作除錯，例如 target remote

localhost:3333命令，就是控制 GDB以 TCP/IP方式對本機端 port為 3333的裝

置為遠端除錯的目標，而那目標就是 OpenOCD，以上這兩種命令基本上都不會

觸發 OpenOCD內部的高階除錯命令，充其量只是當 GDB執行 target remote命

令後，OpenOCD回應可以連接並保持在連接狀態而已，而第三種命令才是會觸

發 OpenOCD內部的高階除錯命令，例如 x/1命令是讀取記憶體，會把討論的重

點放在第三種命令，第三種需要 EICE幫助的命令，只要能全部執行成功，

OpenOCD與 CPU+EICE就驗證完成。

以下會表格由左到右欄位說明依序是第一欄：編號、第二欄：GDB 執行哪

些命令、第三欄：透過 TCP/IP發出哪種 RSP命令、第四欄：觸發到何種內建

在 OpenOCD高等除錯命令、第五欄：高等除錯命令執行哪些 IR,DR與

RUNTEST組合、第六欄：EICE經過這些 JTAG組合後會會被調整成怎樣的組

態：

編

號

Gdb 除錯

命令

RSP命

令

OpenOCD

處理函式

JTAG命令序列

(IR,DR與 RUNTEST組合)

embedded ICE configuration

1

- -

Che

ck

ID

� 32 bits DR:0x0 � ID had been scan out

2

Mon

hal

t

(sto

p C

PU

)

qRcm

d,ha

lt

(hal

t will

be

enco

de to

Hex

form

)

Arm

7_9_

halt

� (1)4 bits IR: scan n cmd

� (2)4 bits DR:0x2

� (3)4 bits IR: intest cmd

� (4)37 bits DR: write BDU

data mask=0xffff_ffff

� (5)37 bits DR: write BDU

address mask=0xffff_ffff

� (6)37 bits DR: scan out

status for checking CPU

stop or not

� The step (1)~(5) will

enable Break signal(output

of BDU) for stopping CPU

immediately

� (6)Update status when is

stoped for OpenOCD

detection

53

3 M

on r

eg #

reg

dat

a_va

l

(writ

e re

g)

qRcm

d, r

eg #

reg

dat

a_va

l

(reg

#re

g da

ta_v

al w

ill b

e en

cod

e to

Hex

form

)

AR

M7_

9_w

rite_

core

_re

g


� (2)4 bits DR:0x1


� (4)33bits DR:LDMIA

instruction to CPU

� (5)RUNTEST, let LDMID

move to decode state

� (6)RUNTEST, let LDMID

move to execution state

� (7) 33bits DR: give the

data_val of #reg

� (8) RUNTEST, let data_val

into #reg

� Use scan chain 1 to let

data_val into #reg by using

LDMIA instruction

4

Mon

reg

#re

g

(rea

d re

g)

qRcm

d, r

eg #

reg

(reg

#re

g w

ill b

e en

cod

e to

Hex

form

)

AR

M7_

9_re

ad_c

ore

_reg


� (2)4 bits DR:0x1


� (4)33bits DR:STMIA

instruction to CPU

� (5)RUNTEST, let STMID

move to decode state

� (6)RUNTEST, let STMID

move to execution state

� (7) 33bits DR: read the

contest of #reg

� Use scan chain 1 to read

#reg contest by using

STMIA instruction

54

5 S

et *

(int*

)add

ress

=d

ata

(writ

e m

emor

y)

M,a

ddr,

len,

data

AR

M7_

9_w

rite_

mem

ory

� (1)call write reg such that

R0=addr,R1~R15=data

� (2) 33bits DR:NOP

instruction to clean

execution state of CPU


instruction to clean decode

state of CPU

� (4) 33bits DR:STMIA,

STRH or STRB instruction

to CPU depend on len and

bit33 be 1

� (5) 4bits IR: Resume cmd

� (6)RUNTEST, let CPU

access memory through

BUS (enter normal mode)

� Step (1)~(4) set the

address and data to CPU

by EICE for writing

memory

� (5)~(6) CPU enter normal

mode by EICE. After CPU

finish execution

instruction of step (4),

CPU will stop (enter to

debug mode) because of

bit33has been poll up

6

x/1

addr

(rea

d m

emor

y)

m,a

ddr,

len

AR

M7_

9_re

ad_m

emor

y

� (1)call write reg such that

R0=addr


instruction to clean

execution state of CPU


instruction to clean decode

state of CPU

� (4) 33bits DR:LDMIA,

LDRH or LDRB instruction

to CPU depend on len and

bit33 be 1

� (5) 4bits IR:Rsume cmd


access memory through

BUS (enter normal mode)

� (7)call read reg such that

we get the memory context

� Step (1)~(4) set the

address to CPU by EICE

for read memory

� (5)~(6) CPU enter normal

mode by EICE. After CPU

finish execution of step

(4), CPU will stop (enter

to debug mode) because of

bit33has been poll up

� (7) get the read memory

result by calling read reg

55

7 B

reak

fun_

nam

e

(sof

t bre

ak p

oint

)

Z,0

,add

r,si

ze

AR

M7_

9_ad

d_br

eakp

oin

t


� (2)4 bits DR:0x2


� (4)37bits DR: data

value=0xdeee_deee(arm

mode i.e. size ==4), or

0xdeee(thumb mode i.e.

size ==2)

� (5) 37bits DR: data

mask=0xffff_ffff

� (6)call write memory such

that addr=0xdeee_deee(arm

mode), or 0xdeee(thumb

mode)

� (7) 37bits DR:BDU control

mask=0xff


value=0x100 (enable BDU)

� Setting and enabling BDU

for break point(use watch

0xdeee_deee value way)

8

hbre

ak fu

n_n

ame

(har

d br

eak

poin

t)

Z,1

,add

r,si

ze

AR

M7_

9_ad

d_br

eakp

oin

t


� (2)4 bits DR:0x2


� (4)37bits DR: addr

value=addr

� (5) 37bits DR: addr

mask=0xffff_ffff

� (6) 37bits DR: data

mask=0xffff_ffff


mask=0xff


value=0x100 (enable BDU)

� Setting and enabling BDU

for break point

56

9 W

atch

va

r_s

(Wai

tch

poin

t)

Z,2

,var

_s_a

ddr,

size

Z,4

,var

_s_a

ddr,

size

Arm

7_9_

add_

wat

chpo

int


� (2)4 bits DR:0x2


� (4)37bits DR: addr

value=var_s_addr

� (5) 37bits DR: addr

mask=0xffff_ffff


mask=0xf7 or 0xf6


value=0x108 or 0x109

� (1)~(7)Setting and

enabling BDU for watch

point

� (6) If BDU control

mask=0xf7, mean do not

consider read or write var.

0xf6 mean consider that.

� (7) If BDU control

value=0x108 mean enable

BDU and trigger watch

point when read var_s.

0x109 enable BDU and

trigger watch point when

write var_s.

10

Del

ete

(rem

ove

brea

k an

d

wat

ch p

oint

)

z,0,

addr

ess,

size

z,2,

valu

e_va

l,siz

e

Arm

7_9_

rem

ove_

bre

ak

poin

t

Arm

7_9_

rem

ove_

wat

c

hpoi

nt


� (2)4 bits DR:0x2



value=0x0(disable BDU)

� (5)call write memory to

recover soft point

� disable BDU and recover

the memory context that

sot break point changed

11

c

(con

tinue

) c

Arm

7_9

_res

ume � (1) 4bits IR: Resume cmd


enter to normal mode

� Let CPU enter to normal

mode

12

s

(sin

gle

step

)

s

Arm

7_9_

step


� (2)4 bits DR:0x1


� (4)33 bits DR: nop

instructions with bit33 is1

� (5) 33 bits DR: branch

instructions such that

branch to pc=pc-8

� CPU branch to last 2

instructions for beginning

to execution. After execute

the last 2 instructions CPU

will stop because of bit33

is high

表 4-4 GDB debugging activities with OpenOCD and RTL EICE

第一項 chick id：當 OpenOCD開啟透過 apatper連接硬體時候第一件事情

就是會執行 DRscan讀取 id code以確定目前連接的硬體 CPU是否是使用者預想

的，第二項停止 CPU：CPU一開始是屬於持續運作狀態，debugger要透過

EICE控制 CPU就要先將 CPU停止下來，進入 debug mode（即 CPU不依照系

統時脈運作，改由 EICE控制 CPU運作），第三項寫入暫存器：debugger透過

57

EICE更改 CPU內部暫存器的值，第四項讀取暫存器：debugger透過 EICE讀

出 CPU內部暫存器的值，第五項寫入記憶體：debugger透過 EICE控制 CPU寫

入某值在記憶體某位置內，第六項讀取記憶體：debugger透過 EICE控制 CPU

讀取憶體某位置的內容值，第七、八項設定中斷點：debugger透過 EICE設定

中斷點，使 CPU執行應用程式的時候，EICE可以幫助使用者監測是否跑到使

用者設定的中斷點，如果是則 EICE停止 CPU執行，反之則不干擾 CPU，第九

項設定觀測點：debugger對某個變數設定觀測點，只要應用程式執行過程中對

該變數有存取的動作 EICE就會停止 CPU，第十項刪除所有中斷點與觀測點設

置：debugger刪除 EICE內部所有中斷點與觀測點的設置，使 EICE不干擾

CPU執行應用程式，第十一項命令 CPU開始或繼續執行應用程式：當

debugger設置完所有中斷或觀測點之後，透過該命令使 CPU執行應用程式，進

入 normal mode（即 CPU依照系統時脈運作，不再被 EICE控制），第十二項單

步執行：debugger透過 EICE控制 CPU只執行應用程式內部程式碼的一個敘述

或運作。

接下來會依據這 12個 GDB命令在 co-verification platform上面實際運作，

以證明這些命令可以在 OpenOCD幫助下正確執行，下表格為 GDB顯示的結

果：

編

號

Gdb 除錯命令命令說明 GDB view

1

-

當 OpenOCD開啟

後就會去讀取

EICE的 id code

注：此為 OpenOCD視窗

58

2

Mon halt

透過 EICE停止

SYS32TM

(gdb) mon halt

3 Mon reg #reg

data_val

寫入暫存器

A part：write register

B part：read register

4

Mon reg #reg

讀取暫存器內容

值

5 Set

*(int*)address=data

寫入記憶體

A part：write memory

B part：read memory 6

x/1 addr

讀取記憶體

7

Break fun_name

設定中斷

（軟體中斷）

A part：set software break

point

B part：continue(start program

execution)

C part：meet break point

59

8

hbreak fun_name

設定中斷

（硬體中斷）

A part：set hardware break

point

B part：continue(start program

execution)

C part：meet break point

9

awatch ver_name

設定觀察點在哪

個變數，只要變

數有被讀寫則中

斷執行

A part：set watch point

B part：show source code

C part：continue(start program

execution) and meet watch

point

10

Delete

移除所有 break

point與 watch

point

A part：set watch point

B part：delete all bp and wp

C part：continue(start program

execution)

D part：program finish without

meeting any break point

60

11

c

(continue)

使 application

program開始執行

直到遇到中斷點

或程式結束

GDB view：

A part：continue(start program

execution)

B part ：program finish

12

s

(single step)

單步執行：一行

一行的執行

application

program

A part：show source code

B part：single step

表 4-5GDB debugging activities with OpenOCD and RTL EICE result

以上的結果說明這 12個 GDB指令透過 OpenOCD幫助之後，執行都正確

無誤，所以基本上已經可以經由 GDB透過 OpenOCD幫助來偵錯 application

program，接下來用 JPEG encoder與 3D graph為範例來證明 co-verification

platform是有效的，即是證明：經過 co-verification platform驗證的 OpenOCD與

RTL，如果將 RTL 合成燒錄進 FPGA，OpenOCD也是可以正確與 RTL(已燒錄

進 FPGA)運作。

4.4 Semihosting 機制機制機制機制

semihosting機制是由兩種高等除錯命令所組成，是 break point以及

read/write memory。

當在寫在 CPU上執行的應用程式的時候難免會用到 printf 或者 file

operation的功能，因為這些功能會需要透過作業系統存取螢幕的顯示或者硬碟

讀取，一般處理情況程式會啟動 SWI（SoftWare Interrupt），這是通知作業系統

開始幫程式實現 printf 或者 file operation的功能；在 embedded system如果有作

業系統的當然是不成問題，但是當使用 embedded ICE控制 CPU來執行應用程

式通常不會有作業系統來輔助，所以通常會使用 semihosting的技術來達成。

61

Host(x86-PC)

USB_TO_JTAGconverter

Embedded system

SYS32TM

EICE

MEM

USB

圖 4-2 the basic emulation connection graph

semihosting指的是：當 embedded system沒有作業系統的幫助下，透過

host端的幫忙實現需要作業系統幫助的功能，如 printf 或者 file operation；原理

就是當 embedded system需要作業系統的幫助，那麼就由 host端作業系統來輔

助，host執行 GDB與 OpenOCD，且 GDB以連接 OpenOCD。

semihosting詳細步驟：

� Step1：在 GDB命令列打上 mon arm7_9 semihosting enable，功能是命

令 OpenOCD將 semihosting功能啟動，詳細設定就是設 break point在

SWI的中斷向量的位址（0x8）。

� Step2：當 SYS32TM執行 application program遇到 printf 之類需要 host

端輔助顯示 printf 內容的指令時，會把 R0放要處理的 semihosting type

（以 printf 為例就會是 0x5），R1放要處理的參數位址（以 printf 為例

R1指到的 embedded system memory address就是要顯示的字串），又例

如如果是要執行 fopen則 R0 會是 0x1，而 R1所指的位置內容則是

fopen現在要開檔的檔名，讀寫的設定等等，之後再執行 SWI

0x123456這指令，表示現在要執行 semihosting服務。

� Step 3：因為 SYS32TM執行 SWI 0x123456這指令，就會跳要到 0x8

這個位址，所以就會遇到在 Step 1設定的 break point因而停下來，

host端（運行 OpenOCD）會檢查目前的 PC值是否是 SWI的中斷向量

位址，以及進入 SWI的中斷向量位址是否是因為要執行 semihosting

（檢查進入 SWI的中斷向量位址是否是因為 SWI 0x123456這指令）。

� Step 4：host端呼叫 read register把 R0和 R1讀進來，呼叫 read

memory以 R1內容為位址讀取要處理的參數，之後 host端依照

semihosting type與參數作相對映的處理，例如 semihosting type是

fopen就呼叫 host端的 fopen功能，參數來源使用以 R1內容為位址讀

取回來的參數。

� Step 5：處理完成後，host端呼叫 continue讓 embedded system繼續執

行應用程式。

解釋完 semihosting工作原理後，會在詳細說明常用到的代號以及代表的意

62

義：

semihosting type number

will in R0

說明（以下記憶體指的是 embedded system的

記憶體）

SYS_OPEN 0x1 開啟位於 host端檔案服務，檔名與讀寫屬性會

存在 R1指向的記憶體位置。

SYS_CLOSE 0x2 關閉目前在 host端所開的檔案，檔名會存在

R1指向的記憶體位置。

SYS_WRITEC 0x3 寫入一個字元到 host端螢幕上，字元存在 R1

指向的記憶體位置。

SYS_WRITE0 0x4 寫入一連串的字元到螢幕上，一連串的字元存

在 R1指向的記憶體位置。

SYS_WRITE 0x5 寫入字串到

host端已開

啟的檔案。

*(R1+0) 指定在 host某個已開

啟的檔案。

*(R1+4) 欲寫入資料存放的記

憶體位址。

*(R1+8) 寫入的長度，以 byte

為單位。

SYS_READ 0x6 讀取在 host

端已開啟檔

案的內容

*(R1+0) 指定在 host某個已開

啟的檔案。

*(R1+4) 讀取後的資料要放在

記憶體的哪個位址。

*(R1+8) 寫入的長度，以 byte

為單位。

SYS_READC 0x7 從 host端的鍵盤按一字元顯示在 host端螢幕

上。

SYS_HEAPINFO 0x16 從 host端取得 stack point與 heap point的值。

angel_SWIreason_

ReportException

0x18 說明 program目前運作的情況，R1如果是

0x20026表示 program結束。

表 4-6 common semihosting type table

以上表格說明常用的 semihosting type，如果想更仔細了解請參照 ADS

semihosting說明書，或者 OpenOCD原始碼裡面的 Arm_semihosting.c實作內

容。

4.5 在協同驗證平台執行應用程式除錯範例在協同驗證平台執行應用程式除錯範例在協同驗證平台執行應用程式除錯範例在協同驗證平台執行應用程式除錯範例

經過以上的驗證之後證明所有除錯功能階正常運作，接下來使用 GDB對

某一應用程式使用除錯功能來觀察或改變執行順序，此例子是使用協同驗證平

台來對該應用程式執行除錯以及觀察。

63

Step 1 :Give 10

value into a array

Step 2 : Sort that value by using quick sort algorithm

Step 2a :Sort 0 to

j-1

Step 2b :Sort j+1

to 9

Recursive calling

… … … …...

.

.

.

.

.

.

.

.

.

.

.

.

Step 3 : Find a given

value by using binary search

圖 4-3 the example program will be debugged by GDB on co-verification platform

上圖是將要被 GDB除錯或觀察的程式流程圖，主要分成三步驟，第一步

驟：給予 10個數值並儲存在陣列內部，第二步驟：對該陣列內部數值執行排

序，採用的排序法是 quick sort演算法，該演算法採用得想法是 divide and

counter，使用遞迴呼叫實現，第三步驟：從已排序好的陣列內部尋到某數值，

採用的一樣是 divide and counter想法的 binary search演算法，採用迴圈實現。

接下來說明要對該程式作怎樣的觀察與除錯修改：首先會先下中斷點在

main主程式，之後會去觀察到底在陣列內部放了哪階數值，然後下中斷點在

step 2a位置，觀察接下來要排序的是哪幾個陣列成員，使用 step over停止在

step 2b位置，觀察要排序的陣列成員，使用 step over之後使用 read memory讀

取排列之後陣列內部數值結果，之後在 binary search函式下中斷點，修改要尋

找的數值，使之找到別的陣列成員，而不是原本所設想的陣列成員，以下是

GDB操作與說明，在開啟 GDB連接之前要先啟動 co-verification platform執

行，如何啟動請參考 3.4.2 ，OpenOCD使用的 cfg內容如下：

64

圖 4-4 the OpenOCD configuration file context

上圖是開啟 OpenOCD必須的參數檔案（jtagkey.cfg），大致上分為三個部

份：

� A part：命令 OpenOCD開啟兩個 TCP/IP port分別是 4444給 terminal

使用，3333給 GDB連接。

� B part：告知 OpenOCD目前的 adapter是什麼，目前是使用 JTAGSC

作為 adapter，如欲使用 ft2232為 adapter就將#刪掉，將 Interface

JTAGSC加上#，#號表示的是註解：

� Interface JTAGSC：指定 JTAGSC為 adapter，如果是 ft2232就是

指定 ft2232為 adapter。

� Jtag_khz 1000：指定 TCK 頻率為 1MHZ，只有使用 ft2232當

adapter才需要設定。

� ft2232_device_desc "Dual RS232 A"：設定 ft2232要用那個 port當

JTAG訊號輸出，只有使用 ft2232當 adapter才需要設定。

� ft2232_layout jtagkey：告知 OpenOCD目前的 ft2232 layout是那種

格式，只有使用 ft2232當 adapter才需要設定

� C part：主要設定 EICE id code以及 CPU型號，詳細內容可參照

65

OpenOCD操作手冊，以下只針對 jtag newtap與 target create說明。

� jtag newtap主要命令 OpenOCD在內部建造出一個 jtag結構體，

主要目的是為了對某個 CPU作控制的時候應該對哪個 tap存取，

參數說明如下：

� $_CHIPNAME cpu：命名欲連接的 EICE名稱，

$_CHIPNAME內容值為 s3c4510。

� -irlen 4：告知 OpenOCD該 EICE IR scan chain長度為 4。

� -ircapture 0x1：告知 OpenOCD如欲驗證 IR scan chain是否導

通的話，要用 0x1當驗證數值。

� -irmask 0xf：告知 OpenOCD如欲驗證 IR scan chain是否導

通，要檢查哪些 bit，此例為全部都要檢查。

� -expected-id $_CPUTAPID：告知 OpenOCD檢查 id code時

候，正確數值是多少，此例$_CPUTAPID為 0x1f0f0f0f。

� target create主要命令 OpenOCD在內部建造出一個 target結構

體，該結構體內部敘述如何存取 scan chain的方法，參數說明如

下：

� $_TARGETNAME arm7tdmi：命令 OpenOCD創造一個 target

結構其內容是 arm7tdmi存取控制方法，而該 target結構體別

名為$_TARGETNAME，及 s3c4510.cpu

� -endian $_ENDIAN：告知 OpenOCD目前 CPU是大值還是小

值，此例為小值。

� -chain-position $_TARGETNAME：告知 OpenOCD arm7tdmi

存取控制方式要套用到哪個 tap，此例是剛剛所創造的 tap其

存取方法採用 arm7tdmi方式。

66

圖 4-5 GDB debug quick sort and binary search (#1)

� A part：開啟 GDB。

� -x ~/gdb_init：當 GDB 開啟後自動執行 gdb_init內部撰寫的命

令，相當於 GDB script，主要內容如下：

� set remotetimeout 99999999：設定 GDB檢查 OpenOCD是否

有回應的時間 timeout值，設定為該值表示不檢查。

� show remotetimeout：展示所設定的 remotetimeout數值。

� target remote localhost:3333：命令 GDB連接 OpenOCD。

� mon halt：命令 CPU停止。

� test2.elf：表示要載入的程式是哪個程式。

� B part：CPU已停止。

� C part：載入應用程式碼。

67

� D part：開啟 semihosting功能，semihosting詳細設定步驟請參考

4.4 。

� E part：設定中斷點，在 main的地方，並使 CPU開始運作執行應用程

式。

� F part：進入 main之後遇到中斷點，CPU停止下來。


� G part：使用 l（list）展現出應用程式的原始碼，可以看出來未排序前

68

陣列內容：

data[0]=25;data[1]=10;data[2]=25;data[3]=62;data[4]=89;data[5

]=2;data[6]=48;data[7]=39;data[8]=24;data[9]=44;。

� H part：設定中斷點在圖 4-3 step2a的地方。


� I part：c (continue) 使 CPU開始運作，繼續從上次中斷點的地方繼續

執行，並遇到中斷點在 step2a的地方。

� J part：使用 p (print) 讀取變數（記憶體）內容值，得知接下來要排序

的陣列元素是 data[0]~data[3]，接下來刪除所有中斷點，避免當使用

step over功能時停在設定的中斷點。

� K part：n (next) 執行 step over功能，之後程式停在 step2b的地方，表

示 data[0]~data[3]已排列完成，之後再使用 p (print) 讀取變數（記憶

體）內容值，得知接下來要排序的陣列元素是 data[5]~data[9]，並把排

序前的 data[5]~data[9]數值顯示出來，之後執行 step over將

69

data[5]~data[9]排序完成。


� L part：觀察 data[5]~data[9]發現均已排序好。

� M part：將新的中斷點設置在 binary_search函式的位置，使用 c使

CPU繼續執行直到遇到中斷點停留在 binary_search函式位置。

� N part：使用 l (list) 將 binary_search函式的原始碼顯示出來，之後使

用 s (single step or step into) 使 CPU執行到原始碼的第 96行得出欲比

對的第一筆陣列 index，也就是 mid 值。

70

� O part：使用 s (step into)直到決定 mid 直為止，使用 p讀取變數值，發

現第一筆比對的陣列內容值就是欲尋找的值也就是 25，這樣無法驗證

binary_search是否正確執行，所以使用 p data[mid+2]也就是讀取

data[6]的值，得出是 44，更改欲尋找的值為 44以確定 binary_search

是可以運作的，以就是更改 pivot 的值，已寫入記憶體方式更改，更改

完成後刪除所有的中斷點並使 CPU繼續執行程式直到結束為止。

� P part：顯示程式已結束。

71

圖 4-9 OpenOCD infomation for executing quicksort with binary search

上圖是 OpenOCD視窗，semihosting訊息（例如 printf 結果）都會展示在這

裡，可以看到主要有三個訊息，說明如下：

� A part：印出已排序好的 data[0]~data[9]值。

� B part：印出 binary search結果，顯示找到該資料在 data[6]的地方，如

果不經由寫入記憶體方式更改欲尋找的值，則會顯示尋找到該值在

data[4]的地方，表示修改記憶體與 binary search是有效的。

� C part：顯示現在程式已經結束。

72

4.6 實際範例實際範例實際範例實際範例-以以以以 JPEG 編碼程式與編碼程式與編碼程式與編碼程式與 3DG SoC程式程式程式程式為為為為例例例例

Debug software(OpenOCD)

USB/JTAG protocol converter(FT2232)

FPGA

Software(host)

SYS32TM

AXI

ICE

Memory

Debug software(GDB)

r/w memr/w reg

break pointWatch point

High level debug cmd

GPU

VS FS

MDK3D(on board)

AHB

CLCD

圖 4-10 Full Example environment

上圖 host端依然是使用 GDB來控制 OpenOCD，adapter則採用 ft2232將

USB package轉換成 JTAG signal控制硬體，而 FPGA內部的硬體主要組成有

SYS32TM+EICE、AXI BUS、GPU，而 AXI BUS 也連接到實驗版上的 AHB

BUS主要藉由 AHB BUS存取實驗版上的記憶體以及 CLCD。

用上面的架構圖來作實驗，將 RTL 燒錄進 FPGA之後在使用 GDB 和

OpenOCD來除錯 JPEG Encoder與 3D graphs SoC application，以證明 co-

verification platform是有效的的；跟 co-verification platform不同的在於兩點，

第一：不是使用 Platform Architect虛擬平台，而是將 RTL 合成並燒錄進

MDK3D 的 V5 FPGA裡面，FPGA燒錄內容包含 AXI BUS, SYS32TM（可經由

JTAG控制）以及 GPU，並且可以用 on board的 memory以及 CLCD（用來顯

示 GPU畫出的結果），第二：不是使用 systemc撰寫的 JTAGSC而是使用

USB/JTAG converter (FT2232)將轉換後的 JTAG訊號打進 FPGA內部。

兩個例子分別是 JPEG Encoder與 3D graphs SoC實驗，前者是將原先未經

壓縮圖片的 RGB值取出來後經由 SYS32TM執行 JPEG Encoder壓縮成 JPEG形

式，並經由 OpenOCD幫助以 semihosting功能將壓縮後圖片由 embedded system

的記憶體取出並儲存在 host端，後者是由 SYS32TM設定別間實驗室開發的

GPU並驅使 GPU畫出 texture cube，GPU內部又分成 VS 與 FS，VS (vertex

shader) 主要工作在於將使用者給予的三維座標轉化成平面二維座標，FS

(fragment shader)主要工作在於對每三個頂點圍出來的面執行塗色功能。

4.6.1 JPEG 編碼程式編碼程式編碼程式編碼程式

在開始說明此實驗前先說明一下 JPEG encoder功能以及此實驗目的，JPEG

73

encoder功能就是將原本未經壓縮的圖片壓縮成 JPEG格式，而此實驗目的是展

示 break point, read/write memory, semihosting, continue, single step等功能，說明

流程會先講解如何將 JPEG encoder編譯成可執行檔以供 SYS32TM執行，之後

會使用 GDB展示 break point, read/write memory, semihosting, continue, single step

等功能。

Host(x86-PC)

USB/JTAGconverter

MDK3D

CPU

EICE

MEM

USB

APP.c1.GNU

compilerAPP.o

2.GNU linker

APP.elf

3.GDB

LOAD

RSP 4.OpenOCD USB．．．APP(binary)

:FPGA:on board

圖 4-11 tool chain usage flow

基本上在 Host端會先將 application code(APP.c)透過 GNU compiler編譯成

object file(APP.o)，再經過 GNU linker連結 library可執行檔(APP.elf)。

GDB(GNU debugger)將 APP.elf載入並去掉 debug與檔頭資訊得到 binary code，

可經由 RSP將 binary code傳到 OpenOCD，OpenOCD使用 write memory方式

控制 CPU(SYS32TM)將 binary code寫入 memory等待 CPU執行，以上是 Host

端大概執行的工作，接下來會詳細介紹 1～4步驟的操作(以 JPEG為例)：

� 1.GNU compiler：首先先將 JPEG application code與 ISR code編譯，

在命列列輸入

� 參數說明：-c只將 application code作編譯成 object file的動作，-o

命名產生出來的檔案名稱，-g 加入 debug資訊以供 GDB使用。

� 2.GNU linker：接下來作連結動作，目的將 ISR code map在 address 0

開頭位址，JPEG application code在 ISR code後面，以及連結必要的函

式庫。

./arm-elf-gcc -c ENC.C image.h JGLOBALS.HJTABLES.H

JTYPES.H-o jpeg.o -g

./arm-elf-gcc -cisr.c -o isr.o -g

74

� 在命列列打上這樣的命令表示將預設的 linker script擷取出來，

linker script是決定每個 object file在執行檔裡面的位置，目標是將

isr.o放置在 address 0開頭位址，jpeg.o緊接 isr.o之後放置，所以

不能使用預設 linker script，必須修改。

� linker script修改：

� 把 linker script第 12行位置的數值修改成 0x0，表示 object

file 擺放位置從 address 0開始擺放。

� linker script第 49～52行修改成上面那樣，表示使用該 linker

script它會自動去放置 isr.o的執行程式碼在執行檔 address 0

開頭位址。

� 在命令列輸入上面指令，就可將之前的的 object file連結必要的函

式庫並產生出執行檔(jpeg.elf)，此執行檔擁有一些 debug與區段

資訊並不是單純可供執行的 binary code，經由 GDB讀取後才能得

到 binary code，才可透過 OpenOCD幫助將 binary code寫入到記

憶體中，-e指示程式開始執行的進入點是從哪個函式開始，以上

面的例子就是以 Reset_Handler為進入點，亦可使用下述命令把

GNU compiler與 linker 動作一併執行完。

� 4.OpenOCD：在使用 GDB之前，必須先開啟 OpenOCD，如果成功開

啟就會顯示像圖 3-24 OpenOCD connect to JTAGSC successfully 這樣的

資訊。

./arm-elf-ld –verbose > link.script

./arm-elf-ld ./jpeg.o -T ./link.script -e Reset_Handler -o jpeg.elf -g

./arm-elf-gcc ENC.C image.h JGLOBALS.H JTABLES.H

JTYPES.H -T ./ link.script -e Reset_Handler -o jpeg.elf -g

75

� 用上面的命令來開啟 OpenOCD，開啟 OpenOCD必須給予 cfg

file，cfg file 是用來設定 OpenOCD，主要設定三項：

� A.開啟 OpenOCD RSP的 TCP/IP port提供 GDB連接。

� B.通知 OpenOCD目前使用的 USB/JTAG converter型號並初

始化 converter。

� C.通知 OpenOCD目前要連接的 CPU型號(SYS32TM)。

� 3.GDB：接下來開啟 GDB載入 jpef.elf，並連接 OpenOCD執行 debug

工作，接下來的 GDB 操作會展示 break point, read/write memory,

semihosting, continue, single step等功能，也就是此實驗的目的，這些

功能將會轉成 RSP形式通過 TCP/IP傳給 OpenOCD，由 OpenOCD實

現；執行以下命令會開啟 GDB並將 jpeg.elf載入 GDB，此時 GDB內

部已擁有 jpeg.elf的 binary形式，可供載入進 MDK 實驗版上面的記憶

體。

� 接下來要描述的是 GDB的操作流程：

圖 4-12 GDB control flow #1 of JPEG encoder

� A part：連接 OpenOCD。

� B part：從 GDB呼叫 OpenOCD命令，使 CPU停止。

� C part：執行 mdk3d.log檔案，主要功能是 write memory，目

的是為了設定 MDK 實驗版的 DDR memory組態。

./openocd –f conf.cfg

./arm-elf-gdb jpeg.elf

76

� D part：將 jpeg.elf的 binary載入 MDK 實驗版 DDR

memory，GDB使用 write memory方式將 binary寫入，實際

寫入的動作由 OpenOCD完成，GDB只是傳送 write memory

格式的 RSP給 OpenOCD。


� E part：從 GDB呼叫 OpenOCD命令，開啟 semihosting功

能，詳細步驟請參照上一章。

� F part：設定 break point在開始取出 RGB原值以供壓縮的地

方。

� G part：使 SYS32TM開始執行 JPEG程式，之後遇到 break

point停止。

77


� H part：執行 single step直到把第一個 pixel RGB值讀出來為

止。

� I part：由於第一個 pixel 是白色所以 RGB值全為 255，以

write memory方式將第一個 pixel 的 R 和 G全改為 0，所以第

一個 pixel 就換變為藍色；p是 GDB命令 print 之意，亦可使

用 p R=0方式改變 R 變數之值；這只是改變一個 pixel 的顏

色，輸入”so ~/draw.txt”可畫出一條藍線且舌頭變藍色，是基

於同樣的原理，draw.txt裡面的內容都是更改某 pixel RGB值

使之變成藍色。

� J part：將所有的 break point刪除掉。

� K part：繼續執行 JPEG程式將所有 pixel 壓縮完後，以

semihosting方式將壓縮完的圖片以寫檔案方式存到 Host端。

78

圖 4-15 JPEG encoder result of after GDB controlling

可以從上圖明顯的看到，左邊是正常沒經過修改的圖，中間是經過把第一

個 pixel 修改成藍色的圖，第一個 pixel 變成藍色的，右邊是執行 draw.txt畫出

一條藍線與把舌頭改成藍色的。

4.6.2 3D graphs SoC 應用程式應用程式應用程式應用程式

經過上述講解如何使用 tool chain之後，此實驗不再累述，而是直接講述使

用 GDB控制流程以及控制之後的結果，此實驗目的主要是使用 write memory

功能將旋轉角度改變，以證明經由 GDB+OpenOCD控制的 EICE可以透過

SYS32TM與其他 IP 溝通。

這例子是 SYS32TM使用 GPU將畫出 texture cube，GPU內部可分為 VS 與

FS，VS 主要工作是將三維頂點座標轉換成二維座標，透過 FIFO將轉換後的二

維座標傳給 FS執行貼圖動作，SYS32TM驅動 GPU的流程如下：

Step 1Set these value on memory for VS:VS_instructionVertex_value

VS_Uniform_value

Step 2 SYS32TM write

VST value(start VS)

Step 3 Set these value on memory for FS:FS_instructionTexture_data

FS_Uniform_value

Step 4 SYS32TM write FST and GPR bank value

(start FS)

Step 5 SYS32TM polling

FS status for checking GPU finish

drawing a graph

圖 4-16 the flow of SYS32TM driving GPU to draw a picture

� SYS32TM驅動 GPU有幾個步驟：

� Step 1：給 VS 的指令、要讓 VS 轉換的頂點資料以及物件呈現出

來的角度(uniform)，SYS32TM先將這些資料放在 memory裡面。

� Step 2：SYS32TM驅動 VS 開始讀取 step 1所設定的資料，也就

是驅動 VS 開始運作。

� Step 3：給 FS的指令、要讓 FS貼圖的資料以及如何貼的設定，

SYS32TM先將這些資料放在 memory裡面。

79

� Step 4：SYS32TM告知 FS哪個位置讀取資料，並初始化 FS。

� Step 5：SYS32TM讀取 FS狀態，判斷 FS是否運作完成。

� 在下面的 GDB操作會先將中斷點設定在 Step 2，在 VS 還沒開始作時

候，將物品呈現的角度(uniform)作修改，改而呈現另一種角度

(uniform)，下面會對 GDB操作作說明。

圖 4-17 GDB control flow of 3D graphs SoC

80

� A part：GDB連接 OpenOCD。

� B part：透過 OpenOCD幫助，命令 SYS32TM停止。

� C part：設定實驗版(MDK3D)memory組態。

� D part：將 3D graph程式載入實驗版(MDK3D) memory。

� E part：命令 OpenOCD開啟 semihosting功能

� F part：設定中斷點在驅動 VS 開始運作之前，也就是在執行 Step

2之前。

� G part：開始執行 3D graph程式，並遇到中斷點停止。

� H part：修改物件本來要顯示的角度，從角度(uniform)0宿改成角

度(uniform)2（如果沒有修改預設將會顯示角度 0）。

� I part：修改完後移除所有中斷點，並使程式繼續執行，直到程式

結束將結果展示至 CLCD螢幕上。

當結束程式運作後就會將結果展示到 CLCD螢幕上，下圖則是程式執行完

在 CLCD上的結果，左邊是沒有經過角度修改會產生的結果，右邊則是經過角

度修改之後得結果，可以很明顯的看到經過角度修改後的圖明顯旋轉了。

org after modify uniform

圖 4-18 3D graphs SoC result of after GDB controlling

81

Chapter 5 結論結論結論結論與未來發展與未來發展與未來發展與未來發展

在一開始本論文描述了 SoC發展的三個階段，模擬階段、雛型階段以及成

熟階段，雛型階段對週邊元件的開發與除錯對成熟階段架構 Operation System

非常重要，而雛型階段對週邊元件的開發與除錯非常仰賴 debugger與 EICE以

達到控制 CPU對週邊元件讀寫，所以對週邊元件開發前提條件是 debugger與

EICE可以正常運作，然而以往對 debugger與 EICE驗證都是合成成 FPGA再與

debugger相接，一旦發生問題解決的方法就是去猜問題之後再重新合成，非常

的耗費間。

本論文目的就是在減少合成時間以及加入 monitor後會造成的問題，其解

法就是 EICE與 CPU不用再合成成 FPGA才能與 debugger相接，在 RTL

simulation 就可以與 debugger相接，達成驗證目的；實驗部份證明協同驗證平

台是可以運做的，之後將 EICE與 CPU以及週邊元件合成成 FPGA，再與

debugger相接，執行複雜的 Jpeg encoder與 3D SoC graphs證明平台是有效的。

82

Reference [1] I. J. Huang, Tai-An Lu, ”ICEBERG: An Embedded In-circuit Emulator

Synthesizer for Microcontrollers” Proc. of the 36’th Design Automation Conference, June 1998.

[2] OpenOCD: Open On-Chip Debugger, http://openocd.berlios.de/web/, 2006.

[3] Debugger tool chain for ARM, H-JTAG company, http://www.hjtag.com/. [4] embecosm EAN5-JTAGSC, EMBECOSM company

http://www.embecosm.com/, 2006. [5] GNU ARM compiler, http://www.gnuarm.com/, 2004. [6] GDB: The GNU Project Debugger,

http://www.gnu.org/software/gdb/gdb.html, 2006. [7] USB to JTAG converter, FTDI chip Company, http://www.ftdichip.com/,

2004. [8] NS Manju Nath, “On-chip debugging reaches a nexus”, EDN,May 11,

2000, page 95, http://www.edn.com/article/CA46888.html?text=on%2Dchip+and+debugging+and+reaches+and+a+and+nexus.

[9] Mark W. Klingensmith, “Digital System Debug Techniques”, WESCON-IC EXPO, 1997,IEEE, Page(s): 98-120.

[10] IEEE-ISTO 5001™-1999, the Nexus 5001 Forum™ Standard for a Global Embedded Processor Debug Interface, http://www.ieee-isto.org/Nexus5001, 2010.

[11] Dae-Young Jung, Sung-Ho Kwak and Moon-Key Lee, “Reusable embedded debugger for 32 bit RISC processor using the JTAG boundary scan architecture”, Proceedings 2002 IEEE Asia-Pacific Conference on ASIC Aug. 2002.

[12] “IEEE Standard Test Access Port and Boundary-Scan Architecture”, IEEE Std. 1149.1-2001.

[13] A. Wieferink, T. Kogel, O. Zerres, R. Leupers, and H. Meyr, "SoC multiprocessor debugging and synchronisation using generic dynamic-connect debugger frontends", International Journal of Emerging Sciences, 2008, pp.109-118.

[14] Bradford G. Van Treuren and Jose M. Miranda, “Embedded Boundary Scan”, IEEE Design & Test of Computers, Mar. –Apr. 2003, Volume 20 Issue 2, Page 20 ~ 25.

[15] Chih-Wei Chang, D. , I-Tao Liao, Shau-Yin Tseng, Chein-Wen Jen, "PAC DSP Core and Its Applications", Solid-State Circuits Conference, 2006. ASSCC 2006. IEEE Asian, page 19~22.

[16] The ARM7TDMI Debug Architecture, ARM Ltd., http://infocenter.arm.com/help/topic/com.arm.doc.dai0028a/DAI0028A_arm7tdmi_debug_appsnote.pdf, Application Note 28, Dec. 1995.

[17] ARM7TDMI Data Sheet, ARM Ltd., http://www.heeltoe.com/weararm/pdf/ARM7vC.pdf, 1995.

[18] ARM RVDEBUG V1.8 Application, ARM INC., 1995 [19] 孫清華,”JTAG測試原理與應用” ,全華科技圖書股份有限公司,1999,

Chapter 2 [20] Braun, G.; Nohl, A.; Hoffmann, A.; Schliebusch, O.; Leupers, R.; Meyr,

83

H., “A universal technique for fast and flexible instruction-set architecture simulation” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, Pages: 1625- 1639, 2004.

[21] Shyh-Ming Huang; Ing-Jer Huang; Chung-Fu Kao , “Reconfigurable real-time address trace compressor for embedded microprocessors”, Proceedings of IEEE International Conference on Field-Programmable Technology (FPT), Pages: 196- 203, 2003

[22] Sang-Young Cho, Yoojin Chung, Jung-Bae Lee. "Virtual Development Environment Based on SystemC for Embedded Systems", Computational Science – ICCS 2007

[23] 俞甲子/石凡/潘愛民,” 程式設計師的自我修養-連結.載入.程式庫,碁峰資訊有限公司” ,2009

[24] 陳柏舟, “ 應用於嵌入式電路擬真器之可參數化的軟硬體控制模組” , 國立中山大學資訊工程研究所碩士論文, 2005

84

Appendix A OpenOCD 架構架構架構架構

在本章節中，我們將會針對 OpenOCD架構做分析與與探討。首先我們會先

針對 OpenOCD這個 open source software的架構與運作流程作探討與分析，並且

針對 OpenOCD幫業界解決了什麼問題以及 OpenOCD對我們實驗室做了什麼貢

獻，為了達到那些貢獻又有什麼困難需要突破。

A.1 OpenOCD 架構與運作流程架構與運作流程架構與運作流程架構與運作流程

前文有提及，OpenOCD可以接受外部藉由 GDB或者 telnet方式來連接與操

控 OpenOCD，如果要了解 OpenOCD首先就要針對 OpenOCD內部六個模組分

別負責什麼工作，以及當使用者藉由 GDB 或者 telnet下命令給 OpenOCD時候

OpenOCD是如何找到相對應的動作來回應使用者所下的命令。

A.1.1 OpenOCD內部模組內部模組內部模組內部模組

在圖 A-1 可以清楚的看到 OpenOCD模組與運作流程，我們首先來談論

OpenOCD裡面的每個模組的功能與特色，OpenOCD主要有六個模組：

F. Daemon：由於 OpenOCD對外與 GDB或者 telnet 溝通的管道皆

是藉由 TCP/IP網路協定方式來溝通，所以在 OpenOCD六個模組中必

定會有一個模組負責監聽網路的傳輸，把屬於 OpenOCD的封包抓進來

OpenOCD處理，而這個模組就是 Daemon 模組，其意義就是常駐於

PC作業系統中監聽屬於 OpenOCD的網路封包，OpenOCD通常開啟

telnet TCP/IP port是 4444，GDB TCP/IP port是 3333，TCP/IP port的選

擇可以透過修改 OpenOCD configure file來達成。

G. OpenOCD GDB server：當使用者藉由 GDB 方式來操控 OpenOCD

時，GDB與 OpenOCD溝通方式是採用 RSP協定來溝通，所以在

OpenOCD裡面一定要有一個模組來解譯從 GDB來的 RSP命令以及組

織 RSP回傳的命令給 GDB；所以 Daemon模組傳來的封包資料組合成

一個完整的命令之後，判斷是屬於 RSP協定，就會將該 RSP命令傳給

OpenOCD GDB server來做解析。

H. OpenOCD CLI server：同理當使用者使用 telnet方式來操控

85

OpenOCD時，也需要一個模組來解譯 telnet協定，所以當 Daemon模

組傳來的封包資料組合成一個完整的命令之後，判斷是屬於 telnet協

定，就會將該 telnet命令傳給 OpenOCD CLI server來做解析。

I. Target：此模組可以說是 OpenOCD裡面最重要的模組，因為針對

對不同的 processor會有不同的 JTAG訊號的設定與取方式，其因是

ICE scan-chain組態不一樣，例如 IR 的長度與 command會不一樣或者

DR 長度也會不一樣，以至於如何針對連接不同 processor，還可以提供

正確的組態來存取，是一個重要的課題，所以 Target模組提供不同且

豐富 processor組態來支援不同的 processor，OpenOCD會依照

OpenOCD configure file內容來決定使用哪個 processor組態，其組態內

容可以細分為兩大類：

3. Target Handle function：處理針對從 GDB來的不同 debug

event對應到相對應的處理函式，主要針對不同的 processor提供

不一樣的 JTAG存取次序。

4. Target HW information：針對不同 processor提供不一樣的

scan-chain組態，例如提供某 processor IR長度與命令或 DR 的長

度等…。

J. JTAG：當組態都設定好之後，真正需要與外部 processor溝通之

時就需要 JTAG模組，主要掌管如何使用 protocol converter的 API 來達

到跟外部 processor溝通的目的。

86

圖 A-1 OpenOCD framework and operation flow graph

A.1.2 OpenOCD 初始化初始化初始化初始化與運作與運作與運作與運作流程流程流程流程

OpenOCD flow可以分為兩個階段，分別是當 OpenOCD開啟時的

OpenOCD initial flow，以及當 OpenOCD initial完之後的 OpenOCD operation

flow。

A.1.2.1 OpenOCD 初始化流程初始化流程初始化流程初始化流程

在 OpenOCD開啟時候必須讀取變參考 OpenOCD configure file，而

OpenOCD configure file必須包含三類的資訊：

1. TCP/IP port information：此設定主要是要讓 OpenOCD知道 GDB

與 telnet連結是會透過 TCP/IP那個 port以方便 OpenOCD來監

聽。

2. processor information：主要讓 OpenOCD知道現在想要連接

processor是哪個 Processor以方便 OpenOCD依照不同的 processor

建立 Target Handle function與 Target HW information。

3. protocol converter information：主要是要讓 OpenOCD知道目前採

用的 protocol converter以方便 OpenOCD使用相對應該 protocol

converter的 driver。

87

當 OpenOCD configure file決定好之後，開啟 OpenOCD，當下 OpenOCD

就會讀取並參考 OpenOCD configure file，將上述三種資訊讀進 OpenOCD裡面

之後將會執行 Daemon模組裡面監聽 TCP/IP port的更新，依照 OpenOCD

configure file決定的 port做監聽的動作，再來會去建立 OpenOCD configure file

裡面指定 processor的 Target Handle function與 Target HW information，最後

OpenOCD會去建立 OpenOCD configure file裡面指定 protocol converter的驅

動。

當以上述三類資訊建立好之後，會針對 processor做 check ID的動作，其目

的在於確認目前連接的 processor是否是 OpenOCD configure file裡面所設定的

processor，詳細流程圖如圖 A-2 所示。

圖 A-2 OpenOCD initial flow

首先開啟 OpenOCD之後，會去讀取給予的 cfg檔，針對 cfg檔設定的 CPU

型號去建立與初始化 target structure，target structure包含如何控制 EICE的所有

處理函式，之後 OpenOCD會去檢查硬體 id code以確定建立的 target structure

是否適用在該硬體上，最後當檢查通過後，OpenOCD再去執行必要的硬體初始

化或者獲得硬體目前的狀態。

A.1.2.2 OpenOCD 運作流程運作流程運作流程運作流程

當 OpenOCD initial flow完成之後 OpenOCD將會進入 operation mode等待

外部 GDB或者 telnet藉由 TCP/IP方式的連接，當有外部連接 OpenOCD時

Daemon會依照 port number來判斷目前連接的是 GDB還是 telnet，下列分成

GDB連接與 telnet連接來說明 OpenOCD的 operation mode，其流程如圖 A-1 所

88

示：

GDB連接 OpenOCD：當 Daemon判斷是 GDB連接後，會將封包傳遞給

OpenOCD GDB server解譯 RSP訊號（G1G1G1G1），得出 RSP命令後，呼叫相對應在

Target模組裡的 Target handle function（G2G2G2G2），Target handle function會去參考

Target HW information（G3G3G3G3)，之後 Target handle function會呼叫在 JTAG模組裡

面 core的 IR 或者 DR scan來達成 RSP的命令（G4G4G4G4），JTAG模組裡面 core再將

接收到的 IR 或者 DR scan轉成一連串了 API 來控制 ft2232d（G5G5G5G5）

telnet連接的 Data flow：當 Daemon判斷是 telnet連接後，會將封包傳

遞給 OpenOCD CLI server解譯 telnet訊號（T1T1T1T1），得出 telnet命令後，呼叫相對

應在 JTAG模組裡 Tcl.c的 handle function（T2T2T2T2），handle function會去呼叫在 JTAG

模組裡面 core的 IR 或者 DR scan來達成 telnet的命令（T3T3T3T3），JTAG模組裡面 core

再將接收到的 IR 或者 DR scan轉成一連串了 API 來控制 ft2232d（T4T4T4T4）

A.2 ITRI’s Project – PACDUO（（（（高效能高效能高效能高效能平行架構核心採用平行架構核心採用平行架構核心採用平行架構核心採用

ARM9 以及以及以及以及雙雙雙雙 DSP為為為為發展平台發展平台發展平台發展平台））））

在這節中我們將會專注說明工研院所委託的專案工研院遇到什麼困難，以及

我們如何找到問題的徵結點，首先一開始我們換先描述工研院PACDUO的平台，

接下來會說明工研院委託的內容，最後會描述如何找出問題的徵節點與解決之後

的結果。

A.2.1 PACDUO [15]

PACDUO 是工研院近幾年來研發的項目之一，屬於異質多核心的平台，在

PACDUO系統裡面有一顆 ARM 9ejs以及兩顆工研院研發的數位訊號處理器 (稱

作 PACDSP)，其架構圖與外觀如圖 A-3 與 A-4 所示。

總共有三條 BUS分別是 AXI、AHB 以及 APB，在 AXI BUS 上的 IP 主要有

兩個工研院自行開發之 PACDSP，以及 PACDSP運作時應付 PACDSP資源飢渴

的 DDR RAM 和 SDRAM，並有 BUS bridge連接 AXI 與 AHB 以使用 AHB BUS

上面的資源；AHB BUS上有的 IP 是 ARM9ejs、FLASH、LCD、camera…等等比

較常見且對傳輸頻寬要求沒那麼渴望的裝置，並有BUS bridge連接高速BUS AXI

以及低速 BUS APB；APB BUS主要的 IP 都是一些低速 IP，例如 UART，也有

連接到 AHB BUS bridge。

89

圖 A-3 PACDUO architecture

圖 A-4 PACDUO view

如圖 A-4，可以看到整個發展平台的輸出入，其中 ARM ICE port與

90

PACDSP ICE port，就是 OpenOCD透過 adapter (ft2232) 連接的 JTAG port，達

到控制 ARM9 與 PACDSP之效果。

A.2.2 PACDUO 除錯效能與使用除錯效能與使用除錯效能與使用除錯效能與使用 GDB 控制問題控制問題控制問題控制問題

工研院 PACDUO主要有兩個問題，其一：由於如何有效降低 Debug

Hardware Cost，同時提昇 Debug performance且採用 USB介面，另外在維護及

更新觀點上要能持續精進及發展，並且容易擴充功能及彈性的相容於

Microprocessor或 DSP Debug，所以使用新的 protocol converter ft2232d替原本

protocol converter轉換板 OkBoard，軟體方面也要跟著改變，必須由 OpenOCD

取代配合 OkBoard的軟體即 USB_driver，然而在更改的過程中工研院發現在

OpenOCD實現的 load program速度沒辦法達到原本 USB_driver的 load program

速度；接下來會先介紹一下 OpenOCD與 USB_driver的差別，再列出可能的問

題關鍵點，針對哪些關鍵點做解法，最後在將修改完的程式做測試與驗證。

其二：由於 OpenOCD裡面 Target模組並不支援 PACDSP processor，以至於

無法透過 GDB 來控制 OpenOCD，為了使用圖形化介面 Eclipse可以透過 GDB

控制 OpenOCD，所以必須在 Target 模組裡面新增 PACDSP的 Target Handle

function以及 Target HW information。

A.2.3 尋找尋找尋找尋找 PACDUO 問題所使用問題所使用問題所使用問題所使用的的的的方法方法方法方法

在速度方面，因為想要使用 OpenOCD取代 USB_driver，但是 OpenOCD

速度不及 USB_driver，所以自然的會去想要比較 OpenOCD與 USB_driver差

別，在開始說明差別之前，我們會先簡單描述簡易的 OpenOCD與 USB_driver

的運作流程，之後依照運作流程比較出差別後，依據這些差別來規劃比較的方

位。如圖 A-5 所示，上半部是 USB_driver簡易的運作流程，USB_driver從

GDB接收 RSP訊號經過 USB_driver解譯 RSP的訊號後，再去呼叫 OkBoard的

API 對 OkBoard下命令，把 RSP透過 OkBoard以 JTAG訊號方式跟外邊的

PACDUO溝通；同理下半邊是 OpenOCD簡易的運作流程，OpenOCD從 GDB

接收 RSP訊號經過 OpenOCD解譯 RSP的訊號後，再去呼叫 ft2232的 API 對

ft2232下命令，把 RSP透過 ft2232以 JTAG訊號方式跟外邊的 PACDUO溝

通。

91

圖 A-5 the different between OpenOCD and USB_driver

從圖 A-5 中 A line 可以看出來 OpenOCD與 USB_driver差別在於 API 使用

的層級不同，USB_driver呼叫 API時只要傳送 IR 或者 DR資料給 API 就可以了，

而 OpenOCD使用的 API 是會直接去控制 JTAG的信號，也就是說 OpenOCD所

使用的 API 控制較 USB_driver底層，然而 USB_driver所使用的 API 不是 open

source 的，在維護及修改功能過程中很容易受到限制，所以比較點上以

USB_driver使用 API 層級來做比較的基準點也就是 A line；另一不同點在於使用

的轉換板不一樣，所以 B line與 C line也是比較的對象。

在 OpenOCD與 GDB連接方面必須新增 PACDSP的 Target Handle function，

所新增的 function如 Table 1所示，左欄是從 GDB 來的 RSP命令，右欄是 RSP

命令對應到的 Target Handle function，如果要將 OpenOCD可以接受從 GDB來的

命令，即是要將 Table 1的 function全部都實現。

RSP command function name

H Initial()

g read_regs()

P Write_regs()

m read_memory()

M write_memory()

s Step()

c Resume()

? Poll()

Z0 add_breakpoint()

z0 remove_breakpoint()

Z1 add_watchpoint()

92

z1 remove_watchpoint()

F Semihosting_end()

M load program()

表 A-1 Target Handle function list

A.2.4 PACDUO 問題解決與最後結果問題解決與最後結果問題解決與最後結果問題解決與最後結果

當初接下工研院案子時 USB_driver Load speed 是 30kb/s而 OpenOCD只

有 8kb/s，預估問題在於傳輸是有 bug，所以切成以下抽象層次由上而下的 4個

問題關鍵點：

I. 圖 A-5 從 A line 比較 USB_driver與 OpenOCD write memory

function，由資料傳輸量進行評估。

II. 在圖 A-1tcl.c所使用的 API 是否比較沒效率(不需要 scan_in卻使

用 scan_inout的 API)。

III.在圖 A-5B line比較 USB_driver與 OpenOCD傳出去的 USB訊

號，是否 OpenOCD USB設定 ft2232比較沒效率。

IV. 在圖 A-5C line比較 USB_driver與 OpenOCD傳出去的 JTAG訊

號，是否 OpenOCD JTAG訊號比 USB_driver多傳了不必要的訊

號。

綜合以上關鍵點是由抽象層次（操作流程）由上而下分析出來的問題關鍵

點，只要由上而下解了其中一個問題關鍵點，則下層大致沒有問題，我首先選

擇解決上面關鍵點 I，觀察 USB_driver與 OpenOCD的 write memory function，

結果如下：

OpenOCD部份：

irscan :0

irscan :6 //把 scan chain切到 MSU

drscan :0x9:addr //設定寫入的位址

drscan :0xA:data //設定寫入的資料

drscan :0xC:0x00000020 + mask //設定資料的 mask與觸發 write_mem

//執行

drscan :0xb:0x00000000 //將 read data的 scan清空

drscan :0xC:0x00000000 + mask //結束 write_mem觸發

USB_driver部份：

WriteJtagInstr(xem, 0x06); //把 scan chain切到 MSU

WriteDR36(xem, 0x01, W_Addr); //設定寫入的位址

WriteDR36(xem, 0x02, W_Data); //設定寫入的資料

93

WriteDR36(xem, 0x04, 0x2f); //觸發 write_mem

WriteDR36(xem, 0x04, (0x20|mask));//設定資料的 mask

WriteDR36(xem, 0x03, 0x0); //將 readdata的 scan清空

WriteDR36(xem, 0x04, 0x0f); //結束 write_mem觸發

WriteDR36(xem, 0x04, mask); //設定資料的 mask

結論：表達方法不一樣，但是實際上的動作差不多。

接下來，選擇問題關鍵點 II，修改 tcl.c的 load function使用的 API，將不

需要 scan_in的 scan command使用的 API 從 scan_inout改成 scan_out。

結果：確實改善 load speed，在 TCK 6M 情況下，load speed可達到 30kb/s

以上，並且我們將一系列的 PACDUO開發版做測試，以確定每個版本均可達到

30kb/s以上的速度，結果如 Table 2所示。

PACDUO

version

Protocol converter TCK speed

（HZ）

Load speed(kb/s)

V2.0 External ft2232h 30M 120

V2.0 External ft2232h 3M 100

V2.0 External ft2232d 3M 28

V3.1 Internal ft2232d 6M 31

V3.1 Internal ft2232d 3M 27

表 A-2 testing result

第一欄是不同的 PACDUO板本，V2.0是沒有 protocol converter ft2232晶片

在上面，需要外接的 protocol converter ft2232，但是較 V3.1穩定；V3.1上有

protocol converter ft2232晶片在上面所以不需要外接 protocol converter ft2232只

要插入 USB port就可以了，穩定性較 V2.0差。第二欄是不同的 protocol

converter，可分成三種，高階的 ft2232h、低階的 ft2232d以及焊在 PACDUO實

驗板上的 ft2232d；ft2232h提供較快得 TCK 速度（至少有 30MHZ）以及支援

RTCK機制，ft2232d最高 TCK 速度只有 6MHZ 且沒有支援 RTCK。第三欄是

選擇不同的 TCK 速度測試，有 30MHZ、6MHZ 和 3MHZ 可以選擇。第四行是

測試出來的 load speed。

我們亦參考由第三方 YAGARTO 測到的 Load speed說明已到達 ft2232dLoad

speed所能達到的極限，如 Table 3所示，Table 3顯示 YAGARTO 所做的測試，

連接 STR7 USB-MSDboard，第一欄顯示使用不同的轉接板 FT2232指的就是

ft2232d而 FT2232-fast指的就是 ft2232h，第二欄顯示不同的 TCK 速度，第三

行顯示 YAGARTO 測試出來的 Load speed，由上面結果來看，我們對 Load

94

function做的改良已趨近 ft2232d的 Load speed極限(26kb/s)，如果還要提昇速

度，就只有換比較高階的轉換板也就是 ft2232h。

表 A-3 ft2232d Load speed from YAGARTO

95

Appendix B EICE_control_event/JTAG 轉換器說明轉換器說明轉換器說明轉換器說明

此章節目的介紹 JTAGSC也就是 EICE_control_event/JTAG signal converter，

其目的在於將 OpenOCD透過 shared memory傳來的 EICE control event轉換成

JTAG序列（TDO、TDI、TMS 與 TCK）的表示方式，在進一步的與 RTL 執行協

同模擬；反之若有 TDO從 RTL 方面回來 converter，他會將以 JTAG序列表示的

資料整理成 16進位資料型態透過 shared memory方式傳回給 OpenOCD。

會依照下列 introduce JTACSC、the file list of JTACSC、the operation flow of

JTACSC等三個章節來介紹 JTACSC。

B.1 JTAGSC 介紹介紹介紹介紹

此 JTAGSC是參考 related work [11] （embecosm EAN5）而來的，提供 Reset、

IRScan和 DRScan API給使用者使用，由 SystemC程式碼組成，基本上無法直接

在 Platform Architect上使用，使用者可以藉由簡易的 API 使用，達成把 Reset、

IRScan和 DRScan的 EICE control event轉換成 JTAG訊號，以下簡介 API 的用

法與結果。

Reset()函數 EICE control event用法：

圖 B-1 JTAGSC reset code example

＃3：宣告 SystemC event的指標，並指到新創的 event物件（SystemC

本身就有的）。

＃4：宣告 Reset event的旗標。

＃6：宣告 Reset 旗標指向新創的 Reset物件，並把 SystemC event當

作參數，好讓 Reset event完成後可以透過 SystemC event通知事件完

成。

＃7：將 Reset event寫入佇列裡面，等待執行。

＃8：等待 Reset event執行完後再往下執行別的程式碼。

＃9、10：刪除之前宣告的物件。

IRScan()函數 EICE control event用法:

96

圖 B-2 JTAGSC IRScan code example



＃4：宣告 IRScan event的旗標。

＃6：宣告 IRScan旗標指向新創的 IRScan物件，其中有三個參數說明

如下：

� actionDone：SystemC event當作參數，好讓 Reset event完

成後可以透過 SystemC event通知事件完成。

� CHAIN_SELECT_IR：欲將 scan到 RTL IR Scan Chain的

資料。

� JTAG_IR_LEN：RTL IR Scan Chain的長度。

＃7：將 IRScan event寫入佇列裡面，等待執行。

＃8：等待 IRScan event執行完後再往下執行別的程式碼。

＃10：刪除之前宣告的物件。

DRScan()函數 EICE control event用法：

圖 B-3 JTAGSC DRScan code example

＃3：宣告以 64Bit 為長度的變數，並指定初值為 0x4。



＃5：宣告 DRScan event的旗標。

＃7：宣告 DRScan旗標指向新創的 DRScan物件，其中有三個參數說

明如下：

� actionDone：SystemC event當作參數，好讓 Reset event

完成後可以透過 SystemC event通知事件完成。

97

� dReg：欲將 scan到 RTL DR Scan Chain的資料，此

例就是 0x4。

� DrLen：RTL DR Scan Chain的長度。

＃8：將 DRScan event寫入佇列裡面，等待執行。

＃9：等待 DRScan event執行完後再往下執行別的程式碼。

＃11、12：刪除之前宣告的物件。

到此，JTACSC介紹到此結束，此章節簡單介紹關於 JTACSC的基礎用法，

下一章節將介紹 JTACSC file list 的組成，以及關於要做些怎樣的變更才能使

Platform Architect上能使用。

B.2 JTAGSC檔案目錄列表與編成元件可在檔案目錄列表與編成元件可在檔案目錄列表與編成元件可在檔案目錄列表與編成元件可在 SC-RTL 協同模協同模協同模協同模

擬平台使用擬平台使用擬平台使用擬平台使用

此章節分成兩小章，分別介紹 JTACSC內的檔案構成，以及了解檔案構成後，

基於怎樣的想法將 JTACSC改寫成可以在 Platform Architect使用。

B.2.1 JTAGSC 檔案目錄與結構檔案目錄與結構檔案目錄與結構檔案目錄與結構

此章將介紹 JTAGSC 檔案組成，將逐一說明每個檔案的作用，檔案列表如

下：

|-JtagSC.cpp(.h)

|-TapAction.cpp(.h)

|-TapActionDRScan.cpp(.h)

|-TapActionIRScan.cpp(.h)

|-TapActionReset.cpp(.h)

|-TapStateMachine.cpp(.h)

|-Makefile

JtagSC.cpp(.h)是主要驅動整個 JTAGSC 運作的檔案，上一章節的 Reset、

IRScan和 DRScan的 EICE control event就是撰寫在此檔案裡面的 JtagSC::driver()

裡面，在模擬開始時就會去讀取 JtagSC::driver()裡面的 EICE control event，轉成

JTAG序列與 RTL 模擬，TapAction.cpp(.h)主要宣告實做 JTAGSC所會用得到元

件，例如 virtual boolprocess()的原型宣告，此原型宣告會被實做在個別的 API 裡

面，即 TapActionDRScan.cpp、TapActionIRScan.cpp和 TapActionReset.cpp此三

個 API 檔案都會實做 process()裡面的內容，而此三個 API 檔案主要工作在決定

98

模擬時當下每一個 TCK cycle所要傳送的 TDI 和 TMS，TapStateMachine.cpp(.h)

主要掌管 TAP FSM移動的資訊，即紀錄當下 RTL 裡面 TAP FSM走到什麼狀態，

和往某個特定的狀態前提下，TMS 要為多少，而 Makefile則是將上述的這些檔

案編譯成連結檔，以方便使用者呼叫與使用。

下圖為上述這些實做 converter的檔案的關聯圖，以及檔案間互相的關係：

圖 B-4 JTAGSC file relation

如上圖 B-4 所示，TapStateMachine提供紀錄目前 RTL 的 TAP FSM機制以

及 TAP FSM移動的機制，當成 API 提供 TapActionDRScan、TapActionIRScan、

TapActionReset給 JtagSC使用。

TapAction 裡面宣告的是最基礎的類別，提供給 TapActionDRScan、

TapActionIRScan和 TapActionReset繼承最主要是宣告 process() 函數的原型。

TapActionDRScan、TapActionIRScan和 TapActionReset等三個 API file 繼承

TapAction，主要目的在於實做 process() 函數，主要功能是描述此三個 API 在每

一個 TCK cycle該如運作，另外此三 API file 也將 TapStateMachine當成如何移

動 TAP FSM 的 API 使用，此三個檔案主要是實現 TapActionDRScan()、

TapActionIRScan()和 TapActionReset()函數的檔案。

JtagSC主要內容是如何驅動 JTAGSC的方法以及 IRScan、DRScan和 Reset

的 EICE control event 就放置在此檔案內。

B2.2 JTAGSC 如何可以被當成元件在如何可以被當成元件在如何可以被當成元件在如何可以被當成元件在 SC-RTL 協同模擬平台上協同模擬平台上協同模擬平台上協同模擬平台上

使用使用使用使用

在此章會介紹如何將 JTAGSC在 Platform Architect上使用；原先 JTAGSC只

99

能做一般的 SystemC模擬，並不能在 Platform Architect上當作一般的 libary 使

用，為了達到此目的我們必須做一些修改使得 JTAGSC可以在 Platform Architect

上使用。依據上一章節有關描述 JTAGSC架構的說明，其實 TapActionDRScan、

TapActionIRScan和 TapActionReset不常被修改，反而 EICE_control_event組成內

容經常被改變，基於這樣的想法，將 JtagSC與其他的檔案分開編譯是比較合適

的，也就是說 TapActionDRScan、 TapActionIRScan、 TapActionReset、

TapStateMachine和 TapAction 會先被編譯成動態連結檔，再由 JtagSC裡面的

pattern 呼叫動態連結檔裡面的 API，而 JtagSC會被加入 Platform Architect元件

裡面當成眾多元件之一，擔任 OpenOCD與 RTL simulation 溝通的介面。

所以接下來有兩件事情要做：

� 使用 Platform Architect從外部將 JtagSC加入，成為元件之一

� 將 JtagSC除外的所有檔案編譯成動態連結檔

欲達成此目的，我們要去修改 Makefile，修改如下：

圖 B-5 file list need to be compiled

將 Makefile修改成向上圖一樣，將 JtagSC.o移除掉，如此一來 make之

就可以編譯成檔名為 libjtagsc.a的動態連結檔，並將此動態連結檔移到

Platform Architect編譯模擬平台時會去參考的動態連結資料庫裡面，如下兩

個路徑：

� /CADtools/Platform Architect/V2010.1.1/PAMD/linux/gnu/gcc-

3.4.4/lib

� /CADtools/Platform Architect/V2010.1.1/PAMD/linux/common/lib-

any

如此一來當 Platform Architect編譯模擬平台，編譯完成後，在連結階段，

位於 JtagSC裡面的 EICE control event，就會自動去搜尋上述資料庫裡面的

libjtagsc.a動態連結檔，以實現 IRScan、DRScan和 Reset的功能。

B.3 JTAGSC運作流程運作流程運作流程運作流程

有了 JTAGSC的基礎認識之後，在這章節會介紹 JTAGSC細部運作原理、

流程，將會講解 JTAGSC內部程式碼的解釋；其順序會以 JtagSC最先介紹，在

之後是 TapActionDRScan、TapActionIRScan、TapActionReset等三個 API 檔案，

最後是基礎構成檔案的 TapStateMachine。

100

B.3.1 JtagSC.cpp and JtagSC.h

此小章會說明 JtagSC.cpp和 JtagSC.h需要注意的部份，例如從哪邊描述有

幾個輸出、輸入阜，以及驅動整個 JTAGSC運作的流程的程式碼，最後是 EICE

control event 要放置在哪裡。

� JtagSC模組輸出、輸入阜宣告：

圖 B-6 input and output port of JtagSC

� 上圖是 JtagSC.h裡面的一段 code，主要描述當 JtagSC放入 Platform

Architect當成 libary後，總共有多少個阜，即共有三個輸出阜和兩

個輸入阜，分別是 TDI、TMS、TRST和 TCK、TDO。

� JtagSC模組初始化：

圖 B-7 initail part of JtagSC

� 上圖是 JtagSC的建構式，＃94是產生 SystemC內建的 FIFO元件，

當由運用 TapActionDRScan()、TapActionIRScan()、TapActionReset()

三個 API 函數所構成的 pattern 要運做在 RTL 時，會先把 pattern

寫入該 tapActionQueue FIFO 之內，之後執行

SC_METHOD(processActions)由 processActions()把 tapActionQueue

FIFO 裡面 pattern 讀出來後，依照 TapActionDRScan、

101

TapActionIRScan、TapActionReset API檔案的描述將 pattern 轉成

JTAG序列訊號。

� ＃95是創造一個 TapStateMachine的物件，主要目的在於紀錄 RTL

目前的 TAP FSM移動到哪個狀態，以及提供 RTL TAP FSM移動

到特定某個狀態的方法。

� ＃97 和＃98 的目的在於執行 processAction()這個函數，此函數作

用在於把 FIFO的 pattern 讀出來後，依照不一樣的 pattern 讀取相

對應的 API，將 pattern 轉成 JTAG 序列；converter的運作方法就

寫在該函數裡面。執行該函數的頻率以 TCK 為依據，當 TCK 上緣

觸發時就會執行一次。

� ＃101和＃102主要是執行 driver()函數，主要給 RTL 模擬的 EICE

control event 是撰寫在此函數裡面，其觸發方式是第一個 TCK 上

緣觸發後就一直執行到整個模擬結束，而不是每一次上原處發就執

行一次；因為所有的 EICE control event只需要執行一次就可，不

必重複執行，所以才選擇使用 SC_THREAD()的方法，不像

processAction()這個函數它負責 JTAGSC的架構運轉，所以需要重

複的執行來確定每一個 TCK cycle下的 TMS 與 TDI 的值，基於這

樣的理由才採用 SC_METHOD()的方法。

� JTAGSC運作(由 processAction()函數負責)：

102

圖 B-8 JTAGSC operation flow

� 上圖是 JTAGSC運作程式碼，每當 TCK上緣觸發時都會執行一次，

以確定當下的 TCK cycle下 TMS 和 TDI 輸出數值，順便讀取 TDO

的值。

� ＃184和＃185宣告當下 TCK cycle想要給 RTL模擬的 TMS和 TDI

值，在此地方只是宣告，並不表示當把值給 tms_o和 tdi_o後就相

當於真正的 TMS 和 TDI 輸出。

� ＃187～197目的在於讀取之前提到的 tapActionQueue FIFO；先判

斷是否已經把之前的 TapAction 做完（就是判斷 currentTapAction

是否為 null），換句話說就是判斷當下要給在 RTL 模擬的 EICE

control event 是否完成，若完成則讀取下一筆 event ，反之則不讀

取，繼續把未做完的 event 完成。

� ＃200～＃204目的在於運作 API 決定當下的 TMS 與 TDI 並接收

TDO的訊號；currentTapAction所指向的 process()函數就是每個API

103

運作的核心，原型宣告在 TapAction 檔案裡面，實做的描述在

TapActionDRScan、TapActionIRScan和 TapActionReset API檔案裡

面，要開發 API 檔案則要去繼承 TapAction類別，所以當＃200行

執行時會得知當下TCK cycle所需要的TDI 與TMS並暫存在 tms_o

和 tdi_o裡面，return為 true時表示 EICE control event已做完，所

以在#201 與＃202 分別通知 SystemC事件已完成，以及把

currentTapAction指標清空，表示目前 event 已完成，下一次執行

processAction()時可以把新一筆的 event讀進來，return為 false時

表示該 event還未完成，下一次執行 processAction()時在一次運作

process()函數以得知下次的 TMS 與 TDI。

� #207是當決定 TDI 與 TMS 並暫存在 tms_o和 tdi_o裡面後，先更

新 JTAGSC裡面 stateMachine物件，該物件目的在於紀錄 RTL TAP

FSM以及接下來 RTL TAP FSM會停在哪個狀態上。

� ＃210與＃211則是依據 tms_o和 tdi_o去驅動 JTAGSC的 TMS 與

TDI 訊號阜給 RTL 執行模擬。

所以依據上面的說明，可以將這些流程用圖形表示，可以更加清楚的了解

converter的運作。processAction()函數運作圖如下：

Execute API process() function

Read next event from

FIFO

YES

Current event is finish?

NOFor getting TMS

and TDO of current TCK cycle

Set currentTapAction=

null

API return true

API return false

By ref.

currentTapAction(null:event is finish)

Update stateMachine and

active JTAG signal to RTL

圖 B-9 working flow chart JTAGSC operation flow

首先依照 currentTapAction是否有值來判斷目前 EICE control event 是否結

束，若是，則先去讀取 tapActionQueue FIFO把下一筆 event讀出來，再執行 API

104

得到當下 TCK cycle對應的 TMS 與 TDI 的值，依據執行 API 後 return的值來判

斷目前 event是否結束，若是，則設定 currentTapAction為 null，以方便下一次執

行processAction()函數時，判斷是否需要從 tapActionQueue FIFO讀出新的pattern，

最後則驅動 JTAGSC訊號作給 RTL 模擬。

圖 B-10 example of JTAG EICE control event

上面的程式碼是位於 JtagSC.cpp裡面的driver() 函數，要與RTL模擬的EICE

control event就是撰寫在這裡，上面程式碼的範例就是依序執行 Reset，之後執

行 IR scan將 0xE的指令下給 RTL EICE，最後執行 DR scan，將 128 bit全為 0

的資料打進 RTL DR scan chain裡面，並將 scan out的資料讀出來；其中

tapActionQueue->write ();就是將 event 寫入 tapActionQueue FIFO，並由

processAction()函數來讀出，並呼叫API處理，wait(*actionDone)就是等單筆event

完成的指令，當 processAction()函數執行 currentTapAction->getDoneEvent()-

>notify();後，就是通知 driver()裡面的 wait(*actionDone);此 pattern已完成，可以

繼續把下一筆 pattern寫入 FIFO了。

B.3.2 JTAGSC API 運作流程運作流程運作流程運作流程

此章會描述 TapActionDRScan()、TapActionIRScan()、TapActionReset()三個

API 函數如何實做，實做部份在 TapActionDRScan.cpp(.h)、

105

TapActionIRScan.cpp(.h)、TapActionReset.cpp(.h)此三個 API 檔案上；由 B.2節可

以看到，此三個檔案繼承 TapAction的類別並且實做 process()這個函數；每當執

行 API 時就會執行 process()函數（如圖 B-7＃200所看到的，看當下的 event是

IR、DR 或是 Reset pattern，執行實做內容不同的 process()函數），所以會將此章

節的重點擺放在此三個 API 檔案如何實做 process()這個函數。

TapActionReset：其 process()函數主要實做成連續 5 個 TCK cycle，TMS 均

為 1，讓 RTL TAP FSM重新移動到 Test-Logic-Reset，reset RTL Tap control。

TapActionDRScan、TapActionIRScan：主要運作架構如下圖

圖 B-11 flow chart of IR or DR working flow

此兩個 API 檔案實做的 process()函數架構主要分三個階段：

� SHIFT PREPARING：準備要執行 scan shift 動作，即是將 TAP FSM

移動到 Shift-DR或 Shift-IR，準備將資料或是指令 scan到 scan chain

裡面，當移動到 Shift-DR 或 Shift-IR 後，就會執行第二階段—

SHIFTING，此階段內 return都是為 false，表示該單筆 pattern還未

完成。

� SHIFTING：TMS 均為 0，將指令或資料寫入 IR 或 DR scan chain

裡面，並且將 TDO回來的值記錄下來，當把指令或資料完整 scan

進 IR 或 DR scan chain後，將會移動到下一個階段—SHIFT

UPDATING，此階段內 return都是為 false，表示該單筆 pattern還

未完成。

� SHIFT UPDATING：當把指令把資料 scan完畢後，就會從 Shift-DR

或 Shift-IR 移動到 Update-DR或 Update-IR，將指令或資料更新，

當 TAP FSM state移動到 Update-DR或 Update-IR就會 return true

106

表示單筆 pattern已完成。

當執行 API 時就會執行 process()函數，而執行 process()函數就會執行上述的

process()架構流程一步，至於如何決定 TMS 與紀錄 RTL JTAG state的辦法將在

B.3.3節 TapStateMachine and TapAction介紹。

B.3.3 TapStateMachine

這裡會介紹基礎元件，例如如何紀錄 RTL TAP FSM和如何移動 TAP FSM

state的方法，在圖 B-7 可以看到當 JtagSC初始化的時候會創造 tapStateMachine

的物件，此物件裡面有個 state 變數就是用來紀錄 RTL TAP FSM；當執行

stateMachine->nextState (tms_o);時，就可以改變 state狀態值，其意義是依據接下

來的 TMS 值來更改 state變數後，再將 TMS 作用在 RTL 上（如圖 B-7＃207～＃

211），其更改 state機制如下圖程式碼：

圖 B-12 TAP FSM decision table

此機制主要分成兩大塊陣列—＃99 的 TMS=1 的移動陣列以及＃103 的

TMS=0的移動陣列，在＃108行主要判斷目前 TMS為 0還是 1，依照不同的 TMS

值參照相對的移動陣列以更新 state。

上述已說明如何紀錄與更新 RTL TAP FSM，接下來說明如何決定 TMS，程

式碼如下：

107

圖 B-13 TMS decision table

決定 TMS 的方法是用一個二維陣列來描述，將目標 state與 TMS 當參數，

由＃151參照在＃129的二維陣列決定 TMS為何值，當目前 state移動到目標 state

後就會 return true，表示目前已移動到目標 state。

這陣列的用法是先從右邊的註解看，例如 map[RTI][X]的那一列，指的就是

從 Run-Test/Idle移動到個別 state所需要的 TMS 值，例如 map[1][0]=1 就是

map[RTI][TLR]，從 Run-Test/Idle到 Test-Logic-Reset第一次的 TMS 要為 1。

所以給個簡單的範例來了解如何使用 map 這個陣列，假設目前 state停在

Run-Test/Idle，目標是 Shift-DR：

� map[RTI][SDR]=map[1][4]=1，TMS 為 1，return false表示還未移動到目

標 state，進行一個 TCK cycle，state更新到 Select-DR-Scan，。

� map[SDRS][SDR]=map[2][4]=0，TMS 為 0，return false表示還未移動到

目標 state，進行一個 TCK cycle，state更新到 Capture-DR。

� map[CDR][SDR] = map[3][4]=0，TMS 為 0，return false表示還未移動到

目標 state，進行一個 TCK cycle，state更新到 Shift-DR。

� map[SDR][SDR] = map[4][4]=0，TMS 為 0，return ture表示還已移動到

目標 state，進行一個 TCK cycle，state停留在 Shift-DR。

108

Appendix C 藉由協同驗證平台所找到的藉由協同驗證平台所找到的藉由協同驗證平台所找到的藉由協同驗證平台所找到的 OpenOCD

與與與與 EICE 錯誤錯誤錯誤錯誤

此章附錄會描述我們使用 co-verification platform找到哪些 OpenOCD高階除

錯命令與 EICE 之間的 bugs，這些 bugs發生的主要原因都是由 OpenOCD來的

EICE control event內容錯誤，或者 EICE本身狀態更新規則有錯，導致 OpenOCD

無法得知 EICE狀態，

C.1 SYS32TM 無法被停止無法被停止無法被停止無法被停止

在表 4-4項目 2，要停止 CPU主要動作是要將 BDU 組態設為馬上拉高

break訊號，當 CPU收到 break拉高之後，會馬上停止運轉將運轉的控制交給

embedded ICE，BDU 組態設定方法就是將 address mask與 data mask都設為

0xffff_ffff ，意義是現在不管監測到何種 data或者 address馬上視為符合條件將

break訊號拉高給 CPU通知 CPU將運轉控制權交給 ICE管理，我們稱之為將

CPU停止。

sc2

TDI

TDO

BDU

R/Waddrdata

Address mask

data mask

Address value

data value

ctrl value

ctrl mask

Status_reg

decoder

Break(to CPU) CPU

GCU

Break_ackICE_Break

CLK

EICE

圖 C-1 EICE architecture

上圖為 EICE簡易架構圖，主要有 BDU 模組，負責監測 CPU執行，BDU

內部設定（例如 Address valus, data value…負責觀測條件設定的數值）均由 scan

chain 2設定，當一設定好之後，BDU 就會進行觀測 CPU運作，只要觀測條件

成立（例如 meet break point）就會拉高 Break訊號命令 CPU停止，CPU停止之

109

後會拉高 Break_ack通知 GUC模組，GCU模組是負責管理現在 CPU是參考系

統時脈運作或是參考 TCK 在運作，GCU模組收到 Break_ack之後就會把 CPU

運作時脈從系統時脈切換至 TCK 並由 EICE控制 CPU（進入 debug mode），並

更新 BDU 內部 status_reg。

當 CPU確認運轉控制權可以交給 ICE管理變會將 Break_ack拉高通知

GCU模組，GCU模組是負責控管現在 CPU運轉權是由外部 wrapper來控制還

是 ICE來控制，當 GCU收到 Break_ack拉高便會將運轉控制權交由 ICE控

制，並且拉高 ICE_Break通知整個 EICE模組現在控制權在 ICE（已進入 debug

mode），並且更新 BDU Status_reg以便 OpenOCD得知已進入 debug mode。

sc2

TDI

TDO

R/Waddrdata

decoder

BDU

ICE_Break

Dstatus

R/Wdata[4:0]

ENStatus_reg

UpdateStatus_val

1111

2222

圖 C-2 scan chain2 connection with BDU before modification

OpenOCD如何取得 debug_status？首先 OpenOCD先將 scan chain選擇掉二

條 scan chain 2，也就是 SC2，之後下讀取 status的序列（R/W=0,

address=status_addr, data=0x0），之後 TAP FSM經過 UPDATE-DR將序列作用於

硬體上，此時 status_val已在 sc2上面，再對 sc2作 scan動作就可取得當下的

status_val數值。

可是在現有硬體設計上有兩點問題：

1. 當 decode選到 status_reg（當 Dstatus為 1），如果 status_valus要

更新必須從 sc2來的 R/W bit為 1；也就是說 JTAG序列必需下寫

入 status_reg的序列 status_reg才會更新 status_val，但是

status_reg的作用是讓驅動 JTAG序列的外部軟體（OpenOCD）知

道目前 CPU環境，不該會有寫的動作發生，所以當寫才更新是錯

誤的，應該讀的時候就要更新。

2. 當 status_reg更新 status_val的時候更新來源是從 sc2來的 data而

非外部來的 ICE_Break，如此會讓外部軟體一直不知道實際外部

的 ICE_Break，這關係著能否告知外部軟體 CPU的運轉權是否在

ICE，只有當運轉權落在 ICE，外部軟體才能透過 JTAG序列控制

CPU。

110

sc2

TDI

TDO

R/Waddrdata

decoder

BDU

ICE_Break

Dstatus

R/Wdata[4:0]

ENStatus_reg

UpdateStatus_val

1111

2222

圖 C-3 scan chain2 connection with BDU after modification

關於這兩個問題的解法：

1. 將 Updata作反向，當讀取就會更新的動作。

2. 將外部的訊號（如 ICE_Break）拿來作更新的來源。

C.2 EICE 無法控制無法控制無法控制無法控制 SYS32TM寫入記憶體寫入記憶體寫入記憶體寫入記憶體

在使用 ICE執行 write/read memory的動作都很相似（CPU目前控制權在

ICE）：

Step 1：選擇 scan chain 1

� IR：scan n IR command

� DR：0x1，選擇 scan chain 1

Step 2：呼叫 write register功能

� R0：存放要存取的 address

� R1~R15：如果是 write memory，則存放要寫入記憶體的資料；是 read

memory則將會存放讀取回來的資料

Step 3：存取 scan chain 1

� Write memory：先給 CPU兩次 nop指令清除 decode和 execution state

最後在給 STMIA（寫入 4個 bytes）, STRH（寫入 2個 bytes) or STRB

（寫入 1個 byte）指令給 CPU，並且當給 STMIA, STRHor STRB指令

的時候也將 scan chain 1的第 33bit拉為 1，目的是當 CPU做完

STMIA, STRHor STRB指令後可以立即停下來將運轉控制權交回

ICE。

� Read memory：動作與 write memory相似，差別在於給予的指令是

LDMIA （讀取 4個 bytes）, LDRH（讀取 2 個 bytes） or LDRB（讀取

1個 byte）

Step 4：將 CPU進入 normal mode（CPU運轉控制轉移給 wrapper，目的是

111

為了能讓 CPU與 memory能夠溝通）

� IR：Restart IR command

� TAP DSM：經過 RUN-TEST/IDLE

Step5：CPU與 memory溝通完成後，馬上將控制權交給 ICE，原因是 step3

將 scan chain 1的第 33bit拉為 1

Step 6（read memory才需要）：呼叫 read register將讀記憶體取回來存放在

R1~R15的記憶體內容透過 scan chain 1讀回給 OpenOCD

圖 C-4 EICE control event activities form OpenOCD

上圖是 sacn chain 1部份架構之一，主要由 scan chain 1第 33bit決定進入

normal之後完成該指令是否要返回 debug mode。

問題：

現行 OpenOCD在 step3控制 scan chain 1給予 bit33為 1的時間點是在給予第二

個 nop指令，而不是在給予 STMIA, STRH , STRB, LDMIA, LDRHor LDRB指

令才給予 bit33為 1，這議會造成當 CPU進入 normal mode完成 STMIA, STRH ,

STRB, LDMIA, LDRH or LDRB指令後法將控制權交還 ICE，而導致 OpenOCD

無法繼續透過 JTAG序列來控制沒有把控制權交還給 ICE的 CPU。

解決方法：

只要當要給予 CPU STMIA, STRH , STRB, LDMIA, LDRHor LDRB指令順便給

予第 33bit為 1，這樣當 CPU完成指令後馬上就會將控制交還給 ICE。

112

C.3 中斷點中斷點中斷點中斷點觸發之後停止的位址不是設定中斷點得位址觸發之後停止的位址不是設定中斷點得位址觸發之後停止的位址不是設定中斷點得位址觸發之後停止的位址不是設定中斷點得位址

當要設定 break point的步驟有：

Step 1：選擇 scan chain 2

� IR：scan n IR command

� DR：0x2，選擇 scan chain 2

Setp 2：設定 break point，可分為 soft break point與 hard break point

� soft break point：是以 watch point方法實現 break point：

� 呼叫 read/write moeory將要設定 break point的 address內容保存

下來，並將內容更改為 0xdeee_deee。

� 並把 BDU 的 data value設為 0xdeee_deee，data mask設為 0x0,

address mask設為 0xffff_ffff ，control value設為 0x100，以及

control mask設為 0x0。

� 做完前兩項設定後，BDU 就會開始監測近來 CPU的 data是否為

0xdeee_deee如果是則會拉起 break通知 CPU已遇到 watch point，

此時 CPU必須將運轉控制權交給 ICE；當監測到 0xdeee_deee的

時候，CPU相當於就去讀取設為 break point 的 address，藉此達

到 break point功能。

� hard break point：設為 break point 的 address設定在 BDU 的 address

value裡面：

� BDU 的 data mask設為 0xffff_ffff ，address value設為 address，

address就是要設成 break point的 address，address mask設為

0x0，control value設為 0x100，以及 control mask設為 0x0。

� 做完設定後，BDU 就會開始監測近來 CPU的 address是否為

BDU address value所設定的 address，如果是則會拉起 break通知

CPU已遇到 break point，此時 CPU必須將運轉控制權交給 ICE。

113

圖 C-5 the cpu control signals path in EICE

上圖是 EICE簡易架構圖，主要有 CPU、BDU、與 Interface模組，BDU 模

組功能已在前面敘述過，主要用來觀測 CPU，而 Interface模組是將 BDU 需要

判斷的訊號收集起來。統一發送給 BDU 判斷。

問題：

當 break point被設定好之後，BDU 便會開始監測，BUD 會需要由 CPU來

的 ctrl_signal（CPnTRANS, CPnOPC, MAS, nRW）來幫助判斷 DBG_break拉起

的時間點，所以當控制 CPU運算的 CLKEN 訊號拉高時表示 CPU運算中，此

時就應該即時的把 ctrl_signal傳給 BDU 而不需要等待 CLKEN 拉低，但是現有

的設計會等待 CLKEN 拉低再把 ctrl_signal傳給 BDU 判斷，這會導致

DBG_break拉高的時間點發生錯誤。

解法：

將把導致 CLKEN 拉低才把 ctrl_signal往 BDU 送的 F.F去除掉，這樣一來

DBG_break拉高的時間點就可以正確了。

SYS32TM

Interface

Ctrl_signal

F.F F.F

GCU

CLKEN

bdu

F.F F.F

CLKEN

DBG_RQ

W0

W1

DBG_break

F.F F.F

CLKEN

國立中山大學資訊工程所碩士論文Processor-OpenOCD整合之 ...

Documents

Transcript of 國立中山大學資訊工程所碩士論文Processor-OpenOCD整合之 ...