转载: (9条消息) coresight(一)coresight简介_nuoweishizi的博客-CSDN博客_coresight

 

第一章: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:表示这个组件,占用4k空间的块数。如果只占用一个块,那么值是0,如果占用两个块,值是1。占用的块数为 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上。

在这里插入图片描述

 

posted on 2021-08-05 18:06  dahere  阅读(4573)  评论(1编辑  收藏  举报