原文链接：

https://www.cnblogs.com/hilnx/p/15104604.html

 

 

第一章：coresight简介

 

一、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）
CTI（cross trigger interface）：接收和发送trigger信号
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对于每个coresight组件，规定了一些寄存器，这些寄存器的偏移是固定的，这些寄存器，是必须存在的。但是有的，可以不实现该寄存器功能。 1、寄存器一览 coresight架构，对于coresight的组件，定义了若干个固定的寄存器。第一个寄存器的偏移从0xf00开始，直到0xffc。以下是寄存器列表

 

 以上的寄存器的地址，在coresight的组件中，是不能当作其他功能使用的。如果该寄存器，在该组件没有实现，那么该寄存器地址要保留，读取要返回0，写被忽略（read must return zero, 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 mode control register 工作模式寄存器。

 

 

对于每个coresight组件，可以工作在两种模式下：

• functional mode
• integration mode

两种模式的区别，在于对coresight组件的寄存器的访问，是否会引发寄存器相应的功能。 integration mode是用来topology detection的。当一个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 affinity register 组件关联功能寄存器。 有时候，组件需要和其他组件，联合起来工作，这样，就需要指示该组件是和另外的什么组件进行关联，就可以用这寄存器。 比如一个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，authentication status 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

而这个authentication status寄存器，就是保存了这4个接口信号的状态。 DBGEN使能的时候，NIDEN被忽略，即NIDEN被认为是使能。 SPIDEN使能的时候，SPNIDEN被忽略，即SPNIDEN被认为是使能。

7、DEVARCH，device architecture register 这个寄存器，标识了coresight组件的架构信息。

这里主要关心ARCHID这个位域。

8、DEVID， device configuration register 这个寄存器的功能，由实现进行定义，总共包括3个寄存器，DEVID，DEVID1，DEVID2，每个寄存器32位，只读。 DEVID寄存器：

DEVID1寄存器：

DEVID2寄存器：

9、DEVTYPE，device type identifier 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，peripheral identification registers 外设识别寄存器。

这里面，我们关心的是SIZE，和Part number。因为其他的值在一个soc中，所有的组件的值是固定的。

• SIZE：表示这个组件，占用４ｋ空间的块数。如果只占用一个块，那么值是０，如果占用两个块，值是１。占用的块数为　2^SIZE。 以下是SIZE对应的组件占用的大小。以及需要访问这个组件需要的地址宽度。

 

• part number：组件的唯一编号。soc中有多个coresight的组件，为了较好方便的管理这些组件，给每个组件分配了唯一的编号。这个编号就保存在part number中。

对于JEP106，这个是JEDEC标准，可以查阅以下网站； www.jedec.org 11、CIDR0-CIDR3，component identification 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信息输出。
  包括两个：HTM： advanced high-performance bus trace macrocell。 连接到AHB互联总线上，产生总线的trace信息
  • ETM: embedded trace macrocell，可以产生指令trace信息，也可以产生数据trace信息
  • PTM：program flow macrocell，产生指令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 flush complete信号。
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 interface

channel interface是用来使不同coresight组件之间传递event使用。使用两个组件来实现：

◾CTM: cross trigger matrix， 接收CTI的channel信号，然后广播给其他CTI

◾CTI：cross trigger interface， 接收trigger信号，发送trigger信号，接收channel信号，发送channel信号

channel interface的典型应用。

每个coresight组件和对应的CTI相连，那这个CTI就可以采集组件的trigger信号，或者发送trigger信号给组件。

CTI将接收的trigger信号，发送到channel interface上，或者从channel interface上接收trigger信号，发送给和自己相连的coresight组件。

所有的CTI的channel interface和CTM相连，这样各个CTI就可以通过CTM，相互传输trigger信号。

1. channel interface信号

channel interface上传递的信号，使用握手机制进行信号的传递。不同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 from the processor to the CTI。trigger信号从PE发出给CTI。
◾Output triggers: trigger event outputs from the CTI to the processor。trigger信号从CTI发出给PE。
◾Input channels: channel event inputs from the 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 output channel有效，然后控制CTIOUTEN[]，就可以使internal output channel的数据输出到指定的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 input channel上，如果后面的AND与门打开，也就是CTIGATE信号有效，那么channel上的trigger信号就会通过output channel interface传输到CTM。

CTM将trigger，发送给其他core（这里是core1）的CTI外部input channel上，如果其他core的AND与门打开，也就是CTIGATE信号有效，就会传递到CTI的internal input channel上，通过output trigger mux（通过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上。