浅谈英飞凌上下文与存储空间

A picture is worth a thousand words --- 鲁迅

/*

* 图多字少

*/

初来乍到，如有问题 请多指教。

存储空间

The address map includes the following memories:

• Program Flash Interface (PFI):

– Program Flash Memory (PF)

• Data Memory Unit (DMU):

– Data Flash Memory for CPU EEPROM (DF0)

– User Configuration Blocks (DF0)

– Configuration Sector (DF0)

– Data Flash Memory for HSM EEPROM (DF1)

• CPU0 and CPU1:

– 64 Kbyte of Program Scratch-Pad SRAM (PSPR)1)

– 240 Kbyte of Data Scratch-Pad SRAM (DSPR)1)

– 32 Kbyte of Program Cache (P-Cache)

– 16 Kbyte of Data Cache (D-Cache)

– 64 Kbyte of Local Memory Unit (DLMU)

• CPU2 to CPU5:

– 64 Kbyte of Program Scratch-Pad SRAM (PSPR)1)

– 96 Kbyte of Data Scratch-Pad SRAM (DSPR)1)

– 32 Kbyte of Program Cache (P-Cache)

– 16 Kbyte of Data Cache (D-Cache)

– 64 Kbyte of Local Memory Unit (DLMU)

• Local Memory Unit (LMU):

– LMU SRAM (CPU DLMU or LMU LMURAM)1)

– DAM SRAM (DAMRAM)

• Boot ROM (BROM)

 

英飞凌Tricore 32位寻址。寻址空间是2的32次方工4个GB. 4G 空间分为16个segment （段） 每个segment 共 256M

注意下面说到的地址0x00000000 - 0xFFFFFFFF 都是逻辑地址

这里提到的缓存访问段 与 非缓存访问段 0x8xxxxxxx 和 0xAxxxxxxx 实际上对应的物理地址是同一片。区别在于访问方式。8开头的地址可以用catch方式访问，效率高于非catch方式访问。及8开头的里面的数据和A开头里面的数据一样。只是访问方式不一样。速度不一样。

夸核访问

CPU0 不仅可以访问自己的数据也可以访问CPU1 的RAM,Flash等，如上图可以理解为Core0 也可以访问segment6，core1的segment8,9,A,B. 只不过core0 访问自己的数据速度较快。访问其他core需要通过XBAR， 速度会慢于访问自己的core.

上面提到4G 被分为16个段，下面每个段又会被分成若干个扇区，以上图的PF0区域为例。共3M 区域 被分成不同的16k, 32k, 等扇区。DF0 也会被分成若干个扇区。下面简单列一下PF 和DF 的区别。

上下文查看

上下文保存了一些数据寄存器，地址寄存器以及程序状态字和链接字。上下文分为高级context和低级context, 高级context自动保存，低级context需要用户手动保存。这里以高级context为例。看一下怎么查看context使用情况。

连接好调试器，打开CPU 寄存器，这里会有高级context, 低级context以及一起其他的系统寄存器。

从芯片系统架构手册可知上下文的数据结构和内容如下图。

我们在调试器打开CPU 寄存器能找到PCXI，这个是链接字。这里以链接字为0x00370B70 为例。

通过取中间可用的信息来计算链接字对应RAM 空间位置。具体计算方式来自英飞凌系统架构手册，比较详细的介绍。实际上就是数据段加上偏移量。填零。

微软自带计算器 计算出 ram位置这里计算出来的是0x7002DC00 是上文我们提到的core0 的 ram空间。文档搬运工。。。

这时候可以使用调试器我这里使用的是Lauterbach可以查看内存信息。dump... 工具搬运工。。。

通过英飞凌系统架构手册里面对context的解析，可以看到上下文使用情况，以及具体数据。需要对每一个寄存器进行调查 可以查看手册。

上下文在任务切换过程中总是保存或者读取。新任务抢占老任务，老任务的上下文会被抢占，新任务结束，继续执行老任务，老任务的上下文会被重读恢复读取使用。后进先出的过程。那么下面看一下在哪些情况下上下文会被操作。

和上面说的一样，高级context保存是系统自动保存。在中断发生，进入trap，函数调用，换句话说 当系统发生需要使用另一个context的时候。高级context就会被自动保存。然而lower context则需要相应的指令去保存。这里提一下，lower 和 upper 对应的地址，对应的链接字，大小格式，都是一样的。比如配置了64个上下文位置，那么这是lower + upper 一共可以用的空间。所以可以通过程序状态字去查看这个context具体指的是lower or upper.

FCX, PCX 这两个分别的 free context List 和 Previous context List 对应的就是用过了的和可用的链接字的位置。那么问题来了，会不会存在用超了的现象，用超了会有措施吗。这里就到提到LCX 这个寄存器，指向的是最后的某个context 所以 当系统认为的 free context  和 LCX 相等时 就需要注意了。Context 马上就要超了。

举个梨子

当前在用的context时CSA2， 那么FCX 指向下一个可用的context就是CSA3, 在CSA3 里面指向的链接字就是CSA4，以此类推 直到LCX和最后一个。手册搬运工。。。

往前的话，上一个使用了的context的链接字就是CSA1.

新建一个context后，前一个用过了的 和 下一个可用的 context都会被更新，但是下一个可用后面的链表还是原来的样子。当CSA3被new出来之后就变成了这样。

对于上下文里面的具体每一个寄存器状态位 这里不 抄手册了，需要的可以自己去瞅一瞅。

锁步核

主核 与 锁步核架构完全想相同。 主核取来指令，这个指令也会传给锁步核执行，只不过中间延迟了两个时钟周期。由于主核和锁步核执行差了两个时钟周期，这也使得同一流水线上的相同状态在同一时刻 执行 不同的指令，能有效的避免 系统出现相同的干扰 使得 主核 和 锁步核 发生同样的错误 而检查不出来的情况。然后主核的运算结果会延迟两个时钟周期和锁步核同时输入给比较器。如果比较器输出结果不相同，那么会触发alarm 发送给SMU。

完结撒花---第一次写

作者：Z-ONE_00751242454
文章来源：上汽零束SOA开发者论坛 
原文链接：https://bbs.z-onesoft.com/omp/community/front/api/page/mainTz?articleId=7685