一、coresight
coresight是ARM公司提出的，用於對複雜的SOC，實現debug和trace的架構。該架構，包含了多個coresight組件。衆多的coresight組件，構成了一個coresight系統。我們也可以根據coresight架構，實現自己的coresight組件。
每個coresight的組件（component），都要遵循coresight架構的要求。
1、典型的一個coresight的環境
以下是一個典型的coresight環境，包含了兩個ARM core，一個DSP，和衆多的coresight組件。這個coresight組件，實現對core，DSP的debug和trace功能。
環境中，總共包括3個通路
· trace通路：將core和DSP內部信息輸出到外部
· debug通路：對core和DSP實現debug
· trigger通路：用於core和core之間，core和DSP之間，傳輸trigger信號
1.1、trace通路
trace通路，實現對master組件的數據追蹤功能，使用ETM來追蹤。
ETM負責追蹤處理器和DSP的信息，將信息打包，通過ATB總線發送到trace bus上。trace bus上有trace funnel，funnel接收多個ATB總線數據，然後合併成一個ATB總線數據，發送給replicator。
replicator接收到ATB數據，根據配置，將ATB數據發送給ETB和TPIU。
1.2、debug的通路
debug通路，用於外部的debugger，對ARM core和DSP進行調試功能。
上圖中，只考慮了JTAG的port。其實還有SW的port。
DAP接收外部端口的JTAG數據，然後轉化成對DAP內部的AP的訪問，然後AP再轉化爲memory-mapped的總線訪問，去訪問soc內部的資源。
上圖中，DAP輸出兩個memory-mapped總線，一個是debug apb總線，連接到debug APB互聯上，用於訪問debug組件的寄存器，一個是system bus，連接到bus matrix，用於訪問soc的內部的資源。
debug APB互聯，連接了有CTI，ETM，HTM，ITM，ETB，TPIU等coresight組件，因此外部的debugger可以通過JTAG port，對這些coresight組件進行訪問。
bus matrix一般是連接soc的一些外設，如memory，串口等，因此外部的debugger可以通過JTAG port對這些外設設備進行訪問。
1.3、trigger通路
trigger通路，用於給指定的組件發送trigger信號，或者接收指定的組件的trigger信號。這個功能由CTI和CTM來實現。
每個core和DSP都有一個CTI組件相連，CTI可以給處理器（DSP）發送trigger信號，也可以接收處理器（DSP）的trigger信號。
所有的CTI和CTM相連，因此可以實現多個CTI之間的trigger信號的相互發送與接收。
2、coresight組件的種類
2.1、control component
trigger的coresight組件
· ECT（embedded cross trigger）
o CTI（cross trigger interface）：接收和發送trigger信號
o CTM（cross trigger matrix）：CTI之間的trigger信號傳遞
2.2、trace sources
trace的coresight組件：
· ETM（embedded trace macrocells）：追蹤指定設備（處理器，DSP）的trace信息，每個設備（處理器，DSP）均有自己的ETM。
· AMBA trace macrocells：追蹤AMBA總線的trace信息。
· PTM（program flow trace macrocells）：
· STM（system trace macrocells）：追蹤總線互聯上的trace信息
2.3、trace links
trace信息傳遞過程中所需要的中間coresight組件：
· trace funnel : 將接收的多個ATB總線數據合併成一個ATB總線數據
· replicator: 將一個ATB總線數據，分發成多個ATB總線數據發送
· ATB bridge: ATB 橋，用於兩個不同的ATB域之間數據傳輸
2.4、trace sinks
最終接收trace信息的coresight組件
· TPIU（trace port interface units）：將ATB數據通過trace port發送給外界
· ETB（embedded trace buffers）：存儲ATB數據的buffer
· TMC（trace memory controller）：
每個trace sink可以有一個trace formatter。
2.5、debug access port
DAP不屬於coresight的組件，但是我們會通過DAP來對coresight的組件進行訪問。
DAP包括以下：
· APB access port(APB-AP)
· AHB access port(AHB-AP)
· AXI access port(AXI-AP)
· JTAG access port(JTAG-AP)
· serial wire JTAG debug port(SWJ-DP)
· JTAG debug port(JTAG-DP)
· ROM table
DAP主要是由DP和AP組件。DP負責接收外部的JTAG或SW數據，然後轉化爲對AP的訪問，而對AP的訪問，是可以發起memory-mapped的訪問。因此就可以對內部的資源進行訪問。
如上圖：
DAP包括了三個AP
· APB-AP：對掛接到debug APB總線上的內部調試設備的訪問
· AHB-AP：對掛載在AHB系統總線上的設備的訪問
· JTAG-AP：對JTAG設備的訪問。這個是兼容以前較早的ARM處理器，如ARM9。這些較早的處理器內部是用JTAG來調試的。但是現在的ARM處理器，已經不用這種方式，統一用memory-mapped方式進行調試。
目前的ARM soc中，一般至少會包括一個DAP。而一個DAP可以包括1-256個AP（access port），AP受DP的控制。只有對AP的訪問，纔可以轉化成memory-mapped總線，對soc的內部資源進行訪問。
DP中有一個SELECT寄存器，該寄存器用來選擇，DP對AP的訪問，是針對於哪一個AP進行訪問。
DAP中，是可以有多個AP的，而每次，只能對一個AP進行訪問。因爲需要對AP進行編號，編號的值就在APSEL位域中。因爲這個位域有8位，因此DAP中可以最多有256個AP。
DAP的內部結構如下圖：
包括了一個DP，和3個AP，依次是AHB-AP，APB-AP，JTAG-AP。
DP通過JTAG或者SW管腳，連接外部的debugger，和外部debugger進行通信。
DP接收到外部debugger發送的JTAG或SW數據，轉化爲對內部AP的訪問。經過decoder模塊，判斷是對哪一個AP進行訪問，然後將訪問信息發送給對應的AP。AP接收到DP的訪問後，轉化爲對應的總線訪問，去訪問內部資源。然後將訪問的信息，纔回送給DP，DP再通過JTAG或SW，將訪問信息返回給外部的debugger。
二、coresight的寄存器
coresight對於每個coresight組件，規定了一些寄存器，這些寄存器的偏移是固定的，這些寄存器，是必須存在的。但是有的，可以不實現該寄存器功能。
1、寄存器一覽
coresight架構，對於coresight的組件，定義了若干個固定的寄存器。第一個寄存器的偏移從0xf00開始，直到0xffc。以下是寄存器列表
以上的寄存器的地址，在coresight的組件中，是不能當作其他功能使用的。如果該寄存器，在該組件沒有實現，那麼該寄存器地址要保留，讀取要返回0，寫被忽略（read must returnzero, and writes must be ignored），而不能當作其他功能使用。
對於coresight的組件，佔用1個4k或者整數倍的4k空間的memory空間。而coresight的寄存器，處於組件佔用空間的最後一個4K空間的最後一部分。
以下是一個coresight組件佔用的memory空間。佔用一個4k空間。
寄存器分爲兩部分：
· device-specific registers：組件自定義寄存器，從0x000-0xeff。coresight組件利用這些寄存器，實現該組件的功能。
· coresight management registers： coresight固定的寄存器，從0xf00-0xfff。這部分寄存器的功能是固定的。
以下是包含了多個coresight組件memory分佈，每個組件，佔用4K空間的整數倍空間。
對於第2個組件，佔用了16k的空間，但是coresight寄存器，是在最後一個空間的最後位置。
而其他3個組件，都只佔用了1個4K空間。因此coresight寄存器，在這一個空間的最後位置。
2、ITCTRL，integration modecontrol register
工作模式寄存器。
對於每個coresight組件，可以工作在兩種模式下：
· functional mode
· integration mode
兩種模式的區別，在於對coresight組件的寄存器的訪問，是否會引發寄存器相應的功能。
integration mode是用來topologydetection的。當一個debugger連接到一個soc後，此時debugger是不知道soc內部有哪些coresight組件的。因此就需要通過查詢，來得知soc中有哪些coresight組件的。而查詢，就是通過訪問coresight組件的寄存器來實現的。此時soc還不知道組件是什麼組件，因此也就不知道組件的寄存器是有什麼功能。因此此時是不能隨意對組件的寄存器進行訪問的。
爲了使訪問的過程中，不影響組件的功能，就可以讓組件工作在integration mode下，此時訪問組件的寄存器，不會引發寄存器相應的功能。待debugger查詢完畢後，獲取到soc中各個coresight組件的信息後，再將組件的模式切換爲functional mode。
復位後，組件必須工作在functional mode下。因此外部debugger對組件查詢完畢後，可以直接對組件進行復位，這樣所有的組件就恢復到了function mode了。
3、CLAIM寄存器
這個寄存器是一個32位的不可見寄存器。只能通過訪問CLAIMCLR和CLAIMSET這兩個寄存器，來設置或者獲取該寄存器的值。
該寄存器，可以用來表示該組件的狀態。這個是由實現來定義的，比如可以規定，該寄存器的最低位，表示最近該寄存器被讀取過，第1位，表示最近該寄存器被寫過。
CLAIMCLR寄存器：
CLAIMSET寄存器
4、DEVAFF，device affinityregister
組件關聯功能寄存器。
有時候，組件需要和其他組件，聯合起來工作，這樣，就需要指示該組件是和另外的什麼組件進行關聯，就可以用這寄存器。
比如一個ETM，追蹤一個core的trace信息，那麼這個寄存器，就保存core的MPIDR寄存器信息，這樣debugger就可以通過DEVAFF寄存器，得知這個ETM是關聯的哪一個core。
DEVAFF0寄存器：
DEVAFF1寄存器：
5、lock 寄存器
對於coresight組件的寄存器，ARM定義瞭如下的一些訪問方式：
可以分爲兩類訪問：
· 系統寄存器訪問：通過MSR，MRS指令（aarch64），MCR,MRC指令（aarch32）
· external debug接口訪問：DAP訪問，或者是memory-mapped訪問，也就是軟件通過load store訪問
對coresight組件寄存器的訪問，是有權限要求的。對於系統寄存器訪問和memory-mapped訪問，ARM定義了software lock這個權限限制。當software lock有效的時候，軟件是不能訪問coresight組件寄存器的。
software lock的目的，是爲了防止軟件意外的修改coresight組件的寄存器，從而修改當前系統狀態，或者獲取一些不該獲取的信息。可以用來防黑客。
software lock提供了兩個寄存器，一個是LAR，一個是LSR。LAR是用來設置software lock狀態，而LSR是保存當前的software lock的狀態。
往LAR寫入0xc5acce55，software lock狀態切換爲unlock， software可以正常訪問coresight組件的寄存器，寫入其他值，software lock狀態切換爲lock，software不可以正常訪問coresight組件的寄存器（實現自定義）。
對於DAP訪問，software lock是沒有用的。因爲要通過DAP訪問，是必須要debugger連接芯片的。
所以coresight組件要能夠區分，當前的訪問是DAP訪問，還是非DAP訪問。
6、AUTHSTATUS，authenticationstatus register
debug功能的認證接口。
debug可以分爲non-invasive和invasive。non-invasive就是self-hosted，而invasive就是external debug。
實際中，可以根據不同的應用需求，可能會需要支持debug，但是也可能需要支持debug中的一種，也有可能不需要支持debug功能。因此考慮到這些需求，ARM定義了認證接口。
認證接口總共包括4個。這4個接口是每個ARM的core要實現的。這些接口是debug功能的總開關。
· DBGEN： invasive debug enable
· SPIDEN: secure invasive debug enable
· SPNIDEN： secure non-invasive debug enable
· NIDEN: non-invasive debug enable
而這個authenticationstatus寄存器，就是保存了這4個接口信號的狀態。
DBGEN使能的時候，NIDEN被忽略，即NIDEN被認爲是使能。
SPIDEN使能的時候，SPNIDEN被忽略，即SPNIDEN被認爲是使能。
7、DEVARCH，devicearchitecture register
這個寄存器，標識了coresight組件的架構信息。
這裏主要關心ARCHID這個位域。
8、DEVID， deviceconfiguration register
這個寄存器的功能，由實現進行定義，總共包括3個寄存器，DEVID，DEVID1，DEVID2，每個寄存器32位，只讀。
DEVID寄存器：
DEVID1寄存器：
DEVID2寄存器：
9、DEVTYPE，device typeidentifier register
組件的具體類型信息。依靠MAJOR位域和SUB位域來表示。
以下是組合情況：
可以看出，arm對組件分成了7大類：
· miscellaneous: 雜散類，
· trace sink: 最終接收trace信息的組件，包括有TPIU,ETB，router。
· trace link：trace信息傳遞過程中需要的中間組件，包括有router, filter,FIFO
· trace source: 產生trace信息的master
· debug control：debug的控制器
· debug logic：具有debug功能的master
· performance monitor：性能的檢測器檢測的master
10、PIDR0-PIDR7，peripheralidentification registers
外設識別寄存器。
這裏面，我們關心的是SIZE，和Part number。因爲其他的值在一個soc中，所有的組件的值是固定的。
· SIZE：表示這個組件，佔用４ｋ空間的塊數。如果只佔用一個塊，那麼值是０，如果佔用兩個塊，值是１。佔用的塊數爲 2^SIZE。
以下是SIZE對應的組件佔用的大小。以及需要訪問這個組件需要的地址寬度。
· part number：組件的唯一編號。soc中有多個coresight的組件，爲了較好方便的管理這些組件，給每個組件分配了唯一的編號。這個編號就保存在part number中。
對於JEP106，這個是JEDEC標準，可以查閱以下網站；
11、CIDR0-CIDR3，componentidentification registers
這四個寄存器，每個寄存器只有最低8位有效。這四個寄存器的組合，用來標識組件的類型。
對於ARM的組件，CIDR寄存器的有些位是固定的。比如對於CIDR0，CIDR1[3:0]，CIDR2，CIDR3，是有固定值的。
CIDR1寄存器中有一個CLASS位域，用來表示組件屬於哪一個類。ARM對自己的組件，也劃分了若個的類。
這裏，我們關心如下的class：
· 0x1： rom table
· 0x9： coresight組件。
· 0xf: corelink組件
讀取組件的CIDR寄存器，即可知道這個組件是屬於哪一類。
對於rom table，固定爲 0xb105_100d
對於coresight組件，固定爲 0xb105_900d
對於corelink組件，固定爲 0xb105_f00d
三、APB，ATB總線
APB和ATB總線，是coresight中常用的2個總線。
對於coresight組件的訪問，使用debug APB總線進行訪問。而對於trace數據的傳輸，使用ATB總線進行傳輸。
1. APB總線
以下是信號列表。
clamp value，是指當一個組件是power down或者是disabled，輸出的固定值。
APB訪問，數據最多是32bit，也就是coresight組件的寄存器的位寬最多是32bit的。
對於PADDRDBG[31]，地址的最高位，表示當前的訪問是internal access，還是external access。
· internal access，是指處理器執行指令的訪問，比如load/store去訪問，或者是外部debugger通過memory map的訪問。
· external access，是指外部的訪問，比如debugger，external access比internal access有更高的權限。
如下圖，兩個處理器，均有自己的coresight組件。每個組件的地址是不一樣的。對於外部的debugger而言，使用地址0x8000_0000和地址0x0000_0000都是訪問的同一個coresight組件的寄存器，要不就是處理器A的組件A，要不就是處理器B的組件A。
但是如果debugger使用地址0x0000_0000訪問，是internal access，此時受限於software lock的影響。而使用地址0x8000_0000訪問，是external access，不受限於software lock。
2. ATB總線
ATB總線用來coresight組件之間傳遞trace信息用。包括兩部分：
· master：在ATB總線上產生trace信息的接口。
· slave：在ATB總線上接收trace信息的接口。
ATB總線以AT作爲信號的前綴。
如以下：HTM和xTM是產生trace信息的master，通過ATB總線，發送給funnel，funnel將收到的兩路ATB數據合併成一路ATB數據發送給replicator，replicator再將接收的一路ATB數據，重複以兩路ATB數據分別發送給ETB和TPIU，TPIU通過trace port發送到外部。
trace信息，通過ATB總線進行傳輸。
· ETB： embedded trace buffer。片內存儲trace數據的大容量設備。
· xTM：trace macrocells。從連接的處理器中，追蹤數據，產生trace信息輸出。
包括兩個：
o ETM: embeddedtrace macrocell，可以產生指令trace信息，也可以產生數據trace信息
o PTM：program flow macrocell，產生指令trace信息
· HTM： advanced high-performance bus tracemacrocell。連接到AHB互聯總線上，產生總線的trace信息
· TPIU： trace port interface unit。接收ATB trace數據，傳輸到trace port上，將trace信息輸出到片外。
· trace replicator: 將一個ATB數據發送給獨立的兩個ATB slave。
· trace funnel：將多個trace源信息，合併成一個trace數據輸出。
2.1 全局信號
時鐘和復位信號。復位信號低電平有效。數據在時鐘的上升沿採樣。
2.2 flow control
數據信號。
master和slave之間的通信，通過ATVALID和ATREADY作爲握手信號。
master將ATVALID拉高，表示master傳輸的數據有效。slave將ATREADY信號拉高，表示slave準備好接收master的數據。如果master發送數據，發現slave的ATREADY沒有拉高，那麼就要將數據重新發送一遍。
時序圖如下：
T1，master發送數據A，ATVALID拉高。但是master檢測到ATREADY沒有拉高。
T2，master檢測到上一次數據傳輸，ATREADY沒有拉高，因此需要將數據A重新發送。此時ATREADY爲1，表示此時數據發送成功。因此下一次可以發送新的數據。
T3，master發送數據B，ATREADY爲1，表示此時數據發送成功。下一拍可以發送新的數據。
T4，master將ATVALID拉低，表示沒有數據發送。
如果slave在master發送數據的時刻，不能及時接收master發送的數據（ATREADY不能在master發送數據時刻拉高），那麼在slave端，建議實現internal buffer，接收master發送的數據。然後再處理。這樣的話，當buffer沒有滿的話，ATREADY信號就可以一直爲高，master就不用一直重新發數據。
對於ATBYTES[m:0] 和 ATDATA[n:0]。
m= log2(n+1) – 4
對於ATID：
trace的數據要伴隨着ATID進行發送的。因爲產生trace的組件有很多，因此需要一個ID來識別這些組件，ID就保存在ATID中發送。
ATID是一個7位的值。0x00和0x70-0x7f是coresight中規定的保留值，在soc實現中，coresight trace組件不應該使用這些ID。
在一個soc中，對於每個trace組件，ID必須是唯一的。對於ID，有兩種選擇：
· fixed ID：在soc設計的時候，就將ID值給固定了。
· programmed ID： trace組件的ID可以通過外部的debugger進行更改，但是debugger要保證，組件的ID必須是唯一的。
ATID和ATDATA，在同一時刻被slave所接收。
2.3 flusing
一般，trace數據都是從trace source發送到trace sink。但是在某些情況下，trace sink需要主動要求trace source發送數據，此時就會用到flusing。sink發送flush信號給source，source將內部所有的trace數據全部發送出去，發送完畢後，迴應sink flushcomplete信號。
flush使用以下兩個信號來作爲握手信號。
如下圖：trace source追蹤處理器的數據，通過trace generation，發送到下一級的buffer中，然後buffer將數據發送給FIFO中進行暫存。FIFO中一旦有數據，FIFO就負責將數據通過output發送給trace funnel。
因此對於一個trace組件，中間是會存在多級的buffer對數據進行緩存的。
假設此時系統要power down，而source的FIFO中還有trace信息，那這些trace信息，就要在power down之前，發送出去。此時funnel就可以向source發送flush信息，也就是將AFVALID信號拉高，trace source接收到該信號，就將自己FIFO中的所有剩餘trace信息，全部發送給funnel，發送完畢後，將AFREADY信號拉高，表示數據發送完畢。此時，就可以將系統給power down。
時序圖：
T1時刻，AFVALID爲高，表示要求master進行flush操作。
T2開始，就進行master的FIFO的trace數據排空操作。
從T2-T6，master將自己內部的FIFO數據發送出去。在T6時刻，master將AFREADY信號拉高，表示master將數據發送外部，也就是flush完成。
四、channel interaface
channelinterface是用來使不同coresight組件之間傳遞event使用。使用兩個組件來實現：
· CTM: cross trigger matrix，接收CTI的channel信號，然後廣播給其他CTI
· CTI：cross trigger interface，接收trigger信號，發送trigger信號，接收channel信號，發送channel信號
channelinterface的典型應用。
每個coresight組件和對應的CTI相連，那這個CTI就可以採集組件的trigger信號，或者發送trigger信號給組件。
CTI將接收的trigger信號，發送到channelinterface上，或者從channel interface上接收trigger信號，發送給和自己相連的coresight組件。
所有的CTI的channel interface和CTM相連，這樣各個CTI就可以通過CTM，相互傳輸trigger信號。
1. channelinterface信號
channelinterface上傳遞的信號，使用握手機制進行信號的傳遞。不同CTI運行的時鐘是不一樣的，因此需要握手機制，來保證不同CTI之間能夠相互傳遞event。
信號總共有以下4個，direction是相對CTI而言的。
clamp value，是指設備power down或者disable，output上的固定值。
以下是時序圖：
兩種連接方式，異步的和同步的。
同步與異步接口之間的轉換。
2. CTI
CTI有input trigger和output trigger。ARM對這些trigger均有定義：
以下是output trigger：
trigger0：連接CPU，debug request請求，當這個信號有效，表示使連接的CPU進入debug state。
trigger1：連接CPU，restart request請求，當這個信號有效，可以使連接的PE退出debug state。
trigger2：連接中斷控制器，CTI interrupt，當這個信號有效，會發出CTIIRQ信號，給中斷控制器發送中斷。
以下是input trigger：
trigger0: 連接CPU，cross-halt trigger，當這個信號有效，表示連接的PE進入debug state。
以下是CTI的內部結構：
CTI左邊連接CPU，有2個通道，一個是接收CPU發送的input trigger，一個是發送給CPU的output trigger。
CTI右邊連接CTM，用於發送output channel，以及接收input channel。
CTI接口信號共有4種：
· Input triggers: trigger event inputs fromthe processor to the CTI。trigger信號從PE發出給CTI。
· Output triggers: trigger event outputs fromthe CTI to the processor。trigger信號從CTI發出給PE。
· Input channels: channel event inputs fromthe CTM(cross-trigger matrix) to CTI。channel信號從CTM發出給CTI。
· Output channels:channel event outputs from CTI to CTM。channel信號從CTI發出給CTM。
input trigger& output channel mapping：根據CTIINEN信號，將input trigger，連接到指定的output channel上。
input channel& output trigger mapping：根據CTIOUTEN信號，將input channel，連接到指定的output trigger上。
對於每一個output trigger，有單獨的寄存器和其對應，如CTIOUTEN0，就和output trigger0對應，控制該寄存器，就可以將指定的input channel連接到output trigger0上，這樣指定的input channel上的trigger就可以傳遞到output trigger0上。
寄存器有32位，表示可以從32個input channel中選擇一個（armv8的輸出trigger最多32個）。如果寄存器的值爲0x1，就表示將output trigger0連接到input channel0，如果寄存器的值爲0x4，就表示output trigger0連接到channel2。
對於CTI，可以接收三種輸入信號，一個是core的trigger inputs，一個是CTM的input channel，另一個就是外部debugger通過APB訪問的寄存器從而產生的trigger信號。
總共有3個來源：
· CTI內部邏輯的CTIAPP，外部可以通過APB總線訪問
· 外部的CTM
· CPU發送的input trigger
2.1 對於CIT內部邏輯的CTIAPP
這部分提供了若干個寄存器，外部通過APB總線可以訪問這些寄存器，從而控制發生，取消trigger信號。
外部的debugger可以控制這些寄存器，從而使對應的internal outputchannel有效，然後控制CTIOUTEN[]，就可以使internal outputchannel的數據輸出到指定的output trigger上。
以下是trigger走向圖。
armv8定義了3個寄存器，CTIAPPSET，CTIAPPCLEAR，CTIAPPPULSE。
· CTIAPPSET：指定的internal channel上產生channel event
· CTIAPPCLEAR：指定的internal channel上取消channel event
· CTIAPPPULSE：指定的internal channel上產生只持續一個週期的channel event
CTIINTACK。這個寄存器，是用來控制將output trigger上的信號給無效掉的。比如，當前output trigger0是有效的，表示debug request，那麼如果要將這個debug request給無效掉的話，那麼就可以往這個寄存器寫0x1，就無效掉了。
寄存器的每一位對應相應的output trigger。
· CTIINTACK[0] 對應 output trigger0
· CTIINTACK[1] 對應 output trigger1
· CTIINTACK[2] 對應 output trigger2
· 。。。
· CTIINTACK[31] 對應 output trigger31
因爲ARMv8規定了，output trigger的最大數目是32，因此也就用一個32位的寄存器就可以表示所有了。
2.2 外部的CTM
從core0發出的input trigger信號，通過output channel，然後通過CTM到達其他所有core的output trigger信號上的。
從core0發出input trigger信號，然後通過input trigger mux（通過CTINEN[]選擇），到相應的internal inputchannel上，如果後面的AND與門打開，也就是CTIGATE信號有效，那麼channel上的trigger信號就會通過output channel interface傳輸到CTM。
CTM將trigger，發送給其他core（這裏是core1）的CTI外部input channel上，如果其他core的AND與門打開，也就是CTIGATE信號有效，就會傳遞到CTI的internal input channel上，通過output triggermux（通過CTIOUTEN[]選擇），通過output trigger，發送給core1。
以上就是CTI的不同core之間的trigger信號傳遞的機制。通過該機制，可以使一個core給另外的core發trigger信號，從而可以控制使其他core進入debug state，退出debug state等。
2.3 CPU發送的input trigger
接收CPU的input trigger，通過內部的output channel，發送給內部的input channel上，然後在發送到output trigger上。
五、 rom table
在一個soc中，有多個coresight組件，但是軟件怎麼去識別這些coresight組件，去獲取這些coresight組件的信息了？這個時候，就需要靠coresight組件中，一個重要的組件，這個組件就是rom table。
ARM規定，在一個soc中，必須要實現至少1個rom table，該rom table，保存了soc中各個coresight組件的信息，包括組件格式以及組件的基地址。
rom table只會佔用一個4K空間大小，也就是PIDR4寄存器的SIZE爲0。
1.entry寄存器
對於rom table，從0x000-0xefc，是entry寄存器。每個entry保存了一個coresight組件的信息。
[31:12]是coresight組件，基於ROM table基地址的偏移地址。例如ROM table的基地址爲0x2000_0000，而[31:12]爲1，那麼這個coresight組件的基地址就是0x2000_1000。
[8:4]和[2]是用來說明該coresight組件所處的power domain。因爲一個soc中，有多個power domain，而每個組件可能會處於不同的power domain中。就依靠這兩個位域說明。
[1]，表示coresight的寄存器的數據有效是8bit，還是32bit。
[0]，表示這個entry代表的組件是否有有效的。
一個rom table中，最多有960個entry，也就是一個rom table中，可以最多保存960個coresight組件的信息，但是在一個entry中，可以指向下一個rom table，這樣，就擴展了保存coresight組件信息的個數。
如果rom table的entry沒有用完，那最後一個有效的entry後的下一個entry，entry值爲全0。
rom table的基地址，保存在DAP的AP的base addr寄存器中，這樣debugger通過訪問DAP的AP，就可以獲取到rom table的基地址，然後在訪問rom table，從而獲取到整個soc中所有的coresight組件的信息。
rom table的entry指向，可以理解是一個鏈表，但是鏈表中，不能有環。如以下的entry指向是錯誤的。
如果一個coresight組件，佔用的空間，超過了4K，但coresight有規定，coresight的寄存器，要實現在最後一個4K的最後1K位置，因此rom table中的該coresight組件的基地址，爲最後一個4K空間的基地址。
2.例子
例如如下的coresight系統，共4個組件，假設第一個組件是rom table。假設rom table的基地址是0x8000_0000。
那麼：
組件 | 基地址 | 佔用4K空間個數 |
rom table | 0x8000_0000 | 1 |
組件1 | 0x8000_1000 | 1 |
組件2 | 0x8000_2000 | 4 |
組件3 | 0x8000_6000 | 1 |
rom table的基地址，存在DAP的AP的base addr寄存器中，外部通過訪問DAP的這個寄存器，獲取到rom table的基地址，然後就可以訪問rom table各個entry 寄存器的值。
組件1，組件2，組件3的基地址信息，存放在rom table的entry0，entry1，entry2中。
對於組件1，entry0的[31:12]爲1，表示組件1的基地址是0x8000_1000，外部根據這個地址，就可以訪問這個組件的coresight寄存器，從而獲取到這個組件的信息。
對於組件2，因爲這個組件，佔用了4個4K空間大小，rom table中存放佔用最後1個4K空間的基地址，因此entry0的[31:12]爲5，表示組件1的基地址是0x8000_5000，外部根據這個地址，就可以訪問這個組件的coresight寄存器，從而獲取到這個組件的信息。通過讀取PIDR4寄存器的SIZE信息，獲取到該組件佔用4個4K空間，從而反推，可以得到該組件的基地址是0x8000_2000。
對於組件3，entry0的[31:12]爲6，表示組件1的基地址是0x8000_6000，外部根據這個地址，就可以訪問這個組件的coresight寄存器，從而獲取到這個組件的信息。
這樣，外部就通過rom table，就可以獲取到soc中，所有coresight組件的基地址。有了基地址，就可以對其進行訪問。
六、 power requestor
power requestor屬於coresight組件。這個組件用來控制系統的power domain，最多可以控制32個。
如果沒有power requestor，通過DAP，只能對整個coresight系統進行上下電操作，但是有了power requestor，可以對某些關心的組件，進行上下電操作，實現power的精細操作。
以下是power requestor的框圖，通過apb總線訪問該組件，該組件通過cpwrupreq信號，向系統power發送請求，通過cpwrupack獲取到系統power的狀態。
以下是power requestor的寄存器。
除了CDBGPWRUPREQ和CDBGPWRUPACK兩個寄存器是requestor的自定義寄存器，其他有用的均是coresight規定的寄存器。
1. CDBGPWRUPREQ
控制對於指定的power domain的請求是否有效。
對於要對power domain1，請求上電，就將bit1置1即可。要對power domain1，請求下電，就將bit1置0即可。
2. CDBGPWRUPACK
只讀的寄存器，保存power domain的狀態。每一bit表示一個power domain。
如這個寄存器值爲0x3，表示domain0和domain1是上電的。
3. DEVID
這個寄存器的低6bit，保存了系統中有多少個power domain。
七、coresight的兩大功能
coresight具有兩大功能，一個是debug，一個是trace。
1、debug
debugger通過DAP，來實現debug功能。
1.1、單core的debug系統：
一個DAP，加上一個AP和APBIC。外部對DP訪問，DAP將DP訪問，轉化爲AP訪問，AP通過APBIC，生成AP總線，通過bridge，對ARM core中的debug資源，或者掛接在debug APB上的coresight組件，進行訪問。
1.2、多core的debug系統：
一個DAP，DAP內實現了多個AP，這些AP實現jtag或memory-mapped方式訪問debug資源。
外部對DP訪問，DAP將DP訪問，轉化爲APB AP或者JATG AP訪問，如果是jtag訪問，直接通過JTAG AP，以jtag方式，對連接到該jtag上的處理器進行訪問。
如果是APB訪問，通過APX mux，判斷對處理器訪問呢，還是掛接在debug APB總線上的coresight組件進行訪問，如果對處理器訪問，經過APB bridge對處理器進行訪問。如果對掛接在debug APB總線上的coresight組件進行訪問，那麼就直接進行訪問。
下圖是debug組件，在coregisht系統中的位置。
2、trace
2.1、單core的簡單trace系統
下圖是單core的簡單trace系統，只有一個trace源。
只有一個trace源（ETM），因此中間都不需要trace link組件，trace源直接將trace信息輸出給trace sink（TPIU）。因爲只有一個trace源，因此也不需要trace formatters。
2.2、單core的高級trace系統
下圖是單core的高級trace系統，擁有用個trace源。
有多個trace源（ETM，STM），因此中間需要trace link組件（funnel），funnel合併trace信息，發送給replicators，replicators再分發給trace sink（TPIU,ETB）。因爲有trace link組件，因此trace sink需要trace formatters，將trace數據格式化，得到真正的數據。
2.3、多core的高級trace系統
有多個core，每個core有自己的trace組件。因此會包含很多trace功能的coresight組件。
3、多cluster的完整coresight系統
下圖是一個多cluster的完整的coresight系統。
系統中有兩個cluster：
· system1，以processor作爲主設備。這個系統中包括了coresight的多個組件，debug組件，trace組件，trigger組件。
· system2，以DSP作爲主設備。這個系統中包括了coresight的多個組件，debug組件，trace組件，trigger組件。
兩個子系統通過interconnect連接到一起，實現相互間的通信以及訪問外部外設。同時兩個子系統的CTM和外部的CTM連接到一起，實現兩個子系統之間的event的相互傳輸。
整個系統中，包括一個DAP，DAP中有一個DP，SWJ-DP（jtag和sw協議轉化），和兩個AP，AHB-AP（產生AHB總線）, APB-AP（產生APB總線）。
AHB-AP產生的AHB總線，直接連接到系統中的interconnect上，就可以訪問連接到interconnect的外部外設（如memory）。
APB-AP產生的APB總線，連接到兩個子系統的debug apb上，實現對子系統的coresight組件的寄存器訪問。如ETM,CTI,HTM，funnel等。同時APB總線還連接到了系統的debug apb上，實現對系統的coresight組件的寄存器訪問。如funnel，ETB，TPIU，CTI等。
兩個子系統的trace信息，通過各自的funnel輸出到系統的funnel上，funnel對兩個子系統的trace信息進行合併，然後輸出給replicator。replicator將接收的trace信息，廣播給ETB和TPIU。TPIU在通過trace port將信息輸出到外部。
八、coresight soc-400
因爲coresight屬於ARM制定的標準，因此ARM針對coresight，設計出來soc-400套件。設計人員可以利用這個套件，快速的生成coresight系統，並且生成相應的case，對coresight系統進行驗證。
coresightsoc-400系統框圖：
這個套件中，可以利用AMBA-designer來自動生成coresight的組件，只需要更改一些配置信息即可自動生成。
1、DAP組件
DAP的一般結構：
SWJ-DP和外部的sw或jtag通信，然後和DAPBUS通信。實現對各個AP的訪問。然後各個AP再對片內內部資源進行訪問。
SWJ-DP包括兩個DP，一個是SW-DP，一個是JTAG-DP。SW-DP負責和外部的sw通信，JTAG-DP負責與外部的jtag通信。
下圖是DAP的內部結構，包含一個DP，5個AP。
DAP將外部接口數據（externalinterface format），也就是SW協議數據或者JTAG協議數據，轉化爲內部的接口數據(internal interface)，也就是AP訪問數據。
1.1、 SWJ-DP
將jtag或sw總線協議，轉化爲dap總線。
接收jtag或sw數據，如果是對DP訪問，直接在內部對DP的寄存器進行訪問。如果是對AP的訪問，轉化爲dap總線，對後級所接的AP進行訪問。
組件，還提供了兩個power域的上電請求（system power和debug power），以及debug域的復位請求。
對於兩個power域的信號，每個信號都是1bit信號。
信號 | 作用 |
cdbgpwrupreq | DAP向power控制器發送的debug power域的上電請求以及時鐘使能信號 |
cdbgpwrupack | power控制器向DAP迴應的debug power域的上電請求以及時鐘使能響應信號 |
csyspwrupreq | DAP向power控制器發送的system power域的上電請求以及時鐘使能信號 |
csyspwrupack | power控制器向DAP迴應的system power域的上電請求以及時鐘使能響應信號 |
debugger通過控制這些信號，來實現對debug power域和system power域的上電以及時鐘使能請求操作。而控制這些信號，是通過寫DA的CRTL/STAT寄存器來實現。
該寄存器的31-28bit。
在實際中，可能power域是斷電，或者時鐘是關掉的。此時debugger要對這個power域中的組件進行訪問，就需要將該power域給開啓以及將時鐘給開啓。此時就需要這些信號。
兩個power域的請求信號是獨立的，因爲兩個power域都是獨立的，互不干擾。
當REQ信號變高後，表示要power up，power控制器應該將ACK信號拉高，表示響應該請求。而REQ信號變低後，表示要power down，power控制器應該將ACK信號拉低。
對於debugger，可以訪問該寄存器，讀取ACK的值，即可知道該power域是否有上電。
reset也是一樣的。DAP可以請求復位debug域的寄存器。也是通過CTRL/STAT寄存器來控制。
時序如下：會驅動PRESETDBGn信號爲低，從而實現debug復位。
1.2、 DAPBUS互聯
連接DP和後續的所有AP。組件會根據DP的select寄存器，決定是對哪一個AP進行訪問，從而生成對該AP訪問的總線。
對於地址dapcaddrs[15:2]：
· dapcaddrs[15:8]：是select寄存器的最高8位的值，也就是AP的選擇
· dapcaddrs[7:2]：訪問AP寄存器的地址
1.3、 AXI-AP
AXI的master，訪問該AP，可以發起AXI訪問。輸入DAP總線，輸出AXI總線。
1.4、 APB-AP
APB的master，訪問該AP，可以發起APB訪問。輸入DAP總線，輸出APB總線。
2、APB互聯組件
APB互聯組件，連接了衆多的coresight組件，外部可以通過APB互聯，實現對連接到APB互聯上的coresight組件的訪問。
以下是APB互聯組件框圖：
APB互聯組件包括以下的一些互聯組件。
2.1、 rom table
每個APB互聯組件，至少連接一個rom table組件，並且該組件的地址爲0x0000_0000，這樣外部通過rom table，在能知道連接到該APB互聯組件上的所有coresight組件信息。
2.2、 APB異步橋
coresight組件，和APB互聯的時鐘，可能是異步的，因此需要一個異步橋，進行轉換。
2.3、 APB同步橋
coresight組件，和APB互聯的時鐘，可能是同步，但是不是同頻，因此需要一個同步橋，進行轉換。
3、ATB互聯組件
ATB互聯組件包括以下的一些互聯組件
3.1、 replicator
replicator用來將上級的master發送的ATB數據，傳輸給下級的兩個ATB slave組件。
結構如下圖所示：
總共有4個port：
· ATB slave port：接收上一級的ATB master的ATB數據
· optional APB port：配置replicator的APB總線端口，外部通過該APB總線設置replicator。
· ATB master port0：輸出給master0的ATB總線
· ATB master port1：輸出給master1的ATB總線
3.2、 funnel
將多個ATB輸入，合併成一個ATB輸出。
結構如下圖所示：
3個port：
· ATB slave port：接收上級的ATB總線，至少有兩組
· optional APB port：配置funnel的APB總線端口，外部通過該APB總線設置funnel。
· ATB master port：輸出給master的ATB總線
3.3、 upsizer
將輸入的數據位寬爲SBW+1的ATB總線，轉換爲數據爲數據位寬爲MDW+1的ATB總線。MDW >= SBW。
ATB_DATA_WIDTH_SLAVE:8,16,32,64
ATB_DATA_WIDTH_MASTER:8,16,32,64
3.4、 downsizer
將輸入的數據位寬爲SBW+1的ATB總線，轉換爲數據爲數據位寬爲MDW+1的ATB總線。MDW <= SBW。
ATB_DATA_WIDTH_SLAVE:8,16,32,64
ATB_DATA_WIDTH_MASTER:8,16,32,64
3.5、 asynchronous bridge
跨時鐘域（異步時鐘）的數據轉換橋。
將時鐘爲clks的ATB總線，轉換爲時鐘爲clkm的ATB總線。
3.6、 synchronous bridge
跨時鐘域（同步時鐘）的數據轉換橋。
將時鐘爲clks的ATB總線，轉換爲時鐘爲clknm的ATB總線。
4、timestamp組件
timestamp組件，用來生成時間信息的。
組件，根據SCLK，產生計數值，然後發送給各個coresight組件，這樣各個組件就有了時間信息。
5、ECT組件
ECT包括CTI和CTM。
5.1、 CTI
CTI用來接收和發送trigger，channel信號用。
· trigger interface：連接需要發送trigger，接收trigger的組件
· channel interface：連接CTM，接收CTM發送的channel，以及發送channel到CTM上
· APB interface：配置CTI的APB總線，外部通過該APB總線，設置CTI
5.2、 CTM
CTM，連接各個CTI。
6、trace sink組件
6.1、 TPIU
trace portinterface ，接收trace信息，發送trace信息到片外。
· debug apb port：配置TPIU的APB接口，外部通過APB總線，設置TPIU。
· ATB slave port：接收trace source或trace link的trace數據
· trace port：芯片的輸出管教，輸出信息給外界
· trigger port：連接CTI。
內部結構如下圖：
接收ATB發送的trace信息，通過formatter，將數據轉化，得到真正的數據信息，保存在FIFO中。
因爲有2個時鐘域，一個是片內的時鐘域，一個是片外的時鐘域，因此該FIFO是異步FIFO，寫是在atclk時鐘域寫入，讀是在traceclkin時鐘域讀取。讀取之後，通過trace out，將數據以串行方式，從接口發送出去。
APB接口，是TPIU向外部提供了配置TPIU寄存器的APB接口。
6.2、 ETB
embedded tracebuffer。存儲trace信息的buffer。
內部結構如下：
接收ATB發送的trace信息，通過formatter，將數據轉化，得到真正的數據信息，然後通過trace RAMinterface，將數據，保存到trace RAM中。
APB接口，是ETB向外部提供了配置ETB寄存器的APB接口。
7、power requestor
power requestor可以讓外部通過APB總線控制指定power domain的上電和斷電。從而控制指定的coresight組件的power。
8、總結
coresight-400，其實就是ARM實現coresight系統的套件，包含了coresight的各個組件，我們利用這個套件，就不再需要自己單獨去設計以及驗證這些coresight組件，直接拿過來，搭建soc環境。並且coresight-400組件，還提供了一些測試case，可以用來驗證搭建的coresight系統，是否正確。