Coresight介绍

目录

一、coresight简介

1、 典型的一个coresight的环境

1.1、trace通路

1.2、debug的通路

1.3、trigger通路

2、coresight组件的种类

2.1、control component

2.2、trace sources

2.4、trace sinks

2.5、debug access port

二、coresight寄存器

三、APB,ATB总线

1. APB总线

2. ATB总线

2.1 全局信号

2.2 flow control

2.3 flusing

四、 channel interface

1. channel interface信号

2. CTI

2.1 对于CIT内部逻辑的CTIAPP

2.2 外部的CTM

2.3 CPU发送的input trigger

五、参考


一、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信息

trace信息传递过程中所需要的中间coresight组件:

  • trace funnel : 将接收的多个ATB总线数据合并成一个ATB总线数据
  • trace 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寄存器,在这一个空间的最后位置。

  •  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寄存器

  •  DEVAFF,device affinity register 组件关联功能寄存器。 有时候,组件需要和其他组件,联合起来工作,这样,就需要指示该组件是和另外的什么组件进行关联,就可以用这寄存器。 比如一个ETM,追踪一个core的trace信息,那么这个寄存器,就保存core的MPIDR寄存器信息,这样debugger就可以通过DEVAFF寄存器,得知这个ETM是关联的哪一个core。 DEVAFF0寄存器:

  •  DEVAFF1寄存器:

  • lock 寄存器 对于coresight组件的寄存器,ARM定义了如下的一些访问方式:

可以分为两类访问:

  • 系统寄存器访问:通过MSR,MRS指令(aarch64),MCR,MRC指令(aarch32),通常是自定义访问接口
  • external debug接口访问:DAP访问,或者是memory-mapped访问,也就是软件通过load store访问,通常是APB接口

对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个。这些接口是debug功能的总开关。

  • DBGEN: invasive debug enable
  • SPIDEN: secure invasive debug enable
  • SPNIDEN:secure non-invasive debug enable(If FEAT_Debugv8p4 is implemented, this
    signal is not implemented.)
  • NIDEN: non-invasive debug enable(If FEAT_Debugv8p4 is implemented, this
    signal is not implemented.)

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

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

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

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

  • DEVID1寄存器:

  • DEVID2寄存器:

  • DEVTYPE,device type identifier register 组件的具体类型信息。依靠MAJOR位域和SUB位域来表示。

以下是组合情况:

可以看出,arm对组件分成了7大类:

  1. miscellaneous: 杂散类,
  2. trace sink: 最终接收trace信息的组件,包括有TPIU,ETB,router。
  3. trace link:trace信息传递过程中需要的中间组件,包括有router, filter, FIFO
  4. trace source: 产生trace信息的master
  5. debug control:debug的控制器
  6. debug logic: 具有debug功能的master
  7. performance monitor: 性能的检测器检测的master
  • 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 

  • 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上。

在这里插入图片描述

五、参考

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

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值