请问有谁知道C6000多核常见问题有哪些吗？

本帖最后由 一只耳朵怪 于 2018-6-25 11:11 编辑

ARM Part

1. ti Keystone系列产品包含哪几类ARM的处理器？

A: TI Keystone系列产品按照其产品定位以及应用领域主要采用ARMv7 Cortex-A架构的处理器，目前主要有包含单核Cortex-A8的产品以及包含多核（1, 2, 4核）Cortex-A15的产品。
2. TI产品集成的ARM处理器是否有功能上的裁剪？

A: TI产品内集成的ARM处理器基本保留Cortex-A架构内的所有特性，最新的集成Cortex-A15的KeystoneII产品继承了Cortex-A架构的所有属性，包括安全扩展的TrustZone以及硬件虚拟化功能的支持。
3. TI是否提供其产品中ARM上的编译器或是推荐用哪种编译器？

A: 目前TI没有相关ARM编译器的开发及支持计划，TI推荐使用开源交叉编译链Launchpad（Linaro组织下的编译非Linux ABI的编译器），由于ARM是这个组织的主要贡献者和开发者，所以该编译器对于ARM部分能够有很好的版本演进以及优化支持。
4. TI的CCS是否可以像编译DSP那样通过图形界面编译ARM的工程？

A: TI的CCS自v5.4.0开始集成基于了GCCv4.7.3的Luanchpad开源交叉编译链（CCS后续版本会随GCC版本演进而集成更新版本）， 用户可以不需要手工编写Makefile而通过CCS的图形界面来进行代码修改及编译。
5. TI的CCS是否可以运行及调试其相应产品中的ARM工程？

A: TI提供其集成ARM的产品的软件仿真器（Simulator），可以通过CCS进行加载及运行以进行代码仿真；并且支持在安装相应版本的Emulation packet及驱动后连接TI相应产品的EVM板以在硬件上运行和调试代码。在使用相应仿真器之后可以实现软件、硬件断点，全局、局部变量查看，核内寄存器及反汇编代码查看等类似于DSP下使用的调试手段。


Linux Part

1. TI是否有相应产品中的ARM使用的Linux及U-boot版本及源码？

A: TI提供其相应产品中ARM所使用的Linux Kernel及U-boot，由于新特性支持需要以及日后功能扩展考虑，目前提供的Linux Kernel及U-boot都是基于3.X版本的LinuxKernel且支持DTS，相关源码发布在arago的开源平台上，具体链接见下：
66AK2H12 U-boot:
http://arago-project.org/git/projects/?p=linux-keystone.git;a=summary
66AK2H12 Linux Kernel:
http://arago-project.org/git/projects/?p=u-boot-keystone.git;a=summary
相关Git目录都包含多个版本，这些版本对应着（Keystone I）SC-MCSDK v2.X或是（Keystone II）MCSDK v3.X的相应发布版本号，这些SDK安装之后会包含相应版本Linux Kernel预编译好的uImage，root file system，Image，zImage和U-Boot预编译好的bin文件以及带SPL的bin文件，如果用户不需要修改的话可以直接将这些编译好的成品文件进行启动和运行。
2. 如何使用Git下载TI的ARM相关产品的Linux及U-boot源码并切换到相应版本？

A: Git是常用的代码开发时使用的版本维护工具，具体使用请参考如下链接：http://www.deyisupport.com/question_answer/dsp_arm/c6000_multicore/f/53/t/25078.aspx
3. 如何编译，烧写及运行TI的ARM相关产品的Linux及U-boot代码？

A: 这部分操作与不同硬件平台以及不同Linux及U-boot版本而有所不同，如果用户使用的是TI的TCI6638K2K及66AK2H12的EVM的话，可参考如下链接（其他硬件平台的操作指南会陆续更新）：
http://www.deyisupport.com/question_answer/dsp_arm/c6000_multicore/f/53/t/23812.aspx
另外，TI推荐使用Linaro组织的Linaro开源交叉编译链来编译相应产品上ARM部分Linux ABI的编译，目前发布的版本是基于GCC4.7.3的，下载链接请见上述链接内文档。
4. TI是否提供其集成ARM相关产品的用于Linux及U-boot的驱动？

A: 这部分TI只能提供基于TI相关产品EVM板上的配置及驱动，在U-boot（主要在 /arch/arm/cpu/armv7/相应EVM或是架构，/board/ti/相应EVM或是架构）和Linux Kernel（主要在/arch/arm/mach-相应架构）中都包含相应源码，用户可以根据自己硬件板配置进行修改及裁剪。

PCIe Part

1. TI Keystone PCIE 有几条Lane, 最大带宽是多少? 最多有几个port？

答：有2条Lane,每个Lane的最大带宽是5Gbps，所以在2个Lane都使用的情况下，最大带宽是10Gbps。PCIE只有1个port，即无论使用1条Lane或者2条Lane，都只能外挂一个PCIE设备。
2. TI Keystone PCIE 支持和PCI设备相连吗?

答：支持，但由于电气特性的差别，与PCI设备相连时，需要通过桥片或者Switch进行转换
3. TI Keystone PCIE 支持热插拔吗?

答：暂时还不能支持 Hot Plug功能
4. 对于Inbound操作, 如果 TLP的 PCIE address满足多个BAR的匹配要求, 那么inbound 规则应该选取哪个BAR对应的IB_BAR配置呢？

答：对于有TLP address落在多个BAR空间内的场景，TI PCIE IP所选取的Inbound 翻译的机制是选择和TLP PCIE address 最接近的BAR地址所映射的IB Region寄存器组。这里最接近可以理解为比TLP PCIE address 小的BAR地址中的最大值。
5. 对于RC作为64bit空间配置时, 是否BAR0和BAR1全作为Address space0空间?

答：是的，在这种模式下BAR0和BAR1会映射local application registers, local configuration accesses, remote configuration accesses and remote IO accesses 。因此RC不能通过BAR的映射规则来访问data 空间，一个变通的办法是可以通过设置Base/limit 寄存器来访问data空间
6. 通过Keystone PCIE做数据访问时需要做Cache一致性维护吗?

答：PCIE 协议有 Cache Snoop这一特性，但目前就Keystone PCIE 而言，如果设置PCIE data空间为可cache空间，则需要软件来完成Cache一致性维护
7. 我测试的Keystone PCIE速度怎么达不到手册宣称的带宽? TI实测的带宽是多少?

答：请确保测试outbound侧是通过EDMA进行，并且选用EDMA的DBS为128bytes的通道，以满足outbound的最大payload size为128bytes的要求。就Keystone 器件而言，采用CC0通道进行传输。TI 实测的带宽为 PCIe Read Throughput Performance 为6.45Gbps/Lane（DBS=128bytes）PCIe Write Throughput Performance 为5.91Gbps（DBS=128bytes）
8. 如果采用TI的 PCIE EVM板连接到PC的主板上, 应该做些什么修改和操作?

答：a. 将IBL升级为MCSDK2.0GA及以上版本。可以参照MCSDK目录下toolsboot_loaderibldocevmc66xx-instructions.txt中的步骤，需要特别注意的是在执行第一步“Programming IBL on the EEPROM at bus address 0x51”时，应确保toolswritereepromevmc66xxlbineepromwriter_input.txt 中的“swap_data = 0”
b. 参考 toolsboot_loaderexamplespciedocsreadme.pdf 将EVM板设置为PCIE BOOT模式
c. 将电脑主板电源关闭
d. 通过TMDXEVMPCI转接卡将6678EVM插入到主板的PCIE插槽中，注意：此时不需要有任何外接电源供给EVM板
e. 将主板电源打开
f. 在WINDOWS操作系统中，在Device manager中，您将会看到如下画面  


Misc Part


1. 将MCSDK相关例程导入后编译不通过，可能都有哪些原因导致?


答：工程编译出错的原因很多，下面列出两点通用的原因，具体问题还得具体分析：
a）由于工程中可能使用绝对路径，所以工程更换路径后需要作出相应修改，可以通过project->properties->CCS Build->C6000 Compiler->include options下面的include search path确认是否符合当前工程的头文件所在路径；如果在工程中包含lib，则需要同时确认修改C6000 linker->file search path中的library search path；
b) 工程中可能使用link的方式加入源文件，所以在工程路径变更后，源文件路径可能变化，此时需要将link的源文件从工程中删除，然后将文件拖到工程中选择link即可。
2. 在进行程序性能测试时, 发现运行cycle很长，可能的原因有哪些?


答：a) 在工程中加入正确的PLL及DDR初始化配置，可以加入gel文件，也可在源文件中加入相应初始化代码；
b) 使能cache配置，包括配置L1/L2 cache，数据存放的memory通过配置MAR寄存器使能cache；
c) 尽可能将常用的大块数据放在LL2，降低数据读写时延；
d) 修改optimization level为-o3。
关于各函数的性能分析可以使用如下链接的工具，对于关键的算法代码可以参考C6000优化手册。
C6000 function profile tool：http://www.deyisupport.com/question_answer/dsp_arm/c6000_multicore/f/53/t/25048.aspx
C6000优化入门指南：http://www.deyisupport.com/question_answer/dsp_arm/c6000_multicore/f/53/t/19044.aspx
3. 使用MCSDK中的IPC进行核间通信测试时, 发现核间通信时间很长，该如何解决, TI推荐的核间通信方式有哪些?

答：a) 首先确认时延测试方法的正确性，需要确认记录时间点基准一致，如在保证发送和接收core同步的基础上，记录发送和接收时间点；
b) 核间通信的方法有很多，如shared memory、semaphore、IPC register、QMSS等，前三种方法相对简单，但是各有限制，相对来说QMSS灵活性更高，容错性更高，所以QMSS是Keystone中推荐的一种常用核间通信的方式。
4. TI EVM都有IBL，这个IBL的作用是什么, 是否所有的Keystone板子设计都需要EEPROM，并且在上面烧写IBL呢?

答：EVM上存在IBL主要有两个作用：a）解决C667x PG1.0芯片中PLL unlock的问题，具体可参考Errata Advisory8，即首先进入IBL对PLL进行重配并lock，之后再跳转到二级boot；b）支持Norflash、Nandflash及Ethernet二级boot。在设计板子时，如果不需要二级boot，则EEPROM及IBL不是必须的；考虑到C667x PG1.0 PLL Unlock的问题，建议在设计时带上EEPROM。
5. Keystone 对CVDD的参考电压设计都要求smartreflex，如果对功耗要求没有那么严格，是否可以使用固定电压供电呢?

答：从芯片的功耗、寿命及稳定性考虑，推荐使用smartreflex。如果使用固定电压供电，当电压低于smart reflex 要求的电压，芯片不一定能正常工作。 当电压高于CVDD额定电压，不仅芯片的功耗可能会急剧上升，也不排除芯片可能出现不可预知的问题。关于smartreflex推荐参考方案，一种是如EVM使用UCD，还有一种是使用LM10011+TPS的方案：http://www.ti.com/tool/pmp7256。
6. 对于多核编程，每个核可以运行不同的程序，如果多核运行同一个程序，对于不同的核该如何区分代码和私有变量呢?

答：多核编程时，对于代码段可以将共享代码放在共享memory，代码中通过DNUM区分核；对于数据段，堆栈必须每个核私有，全局私有变量，可以通过MPAX单元配置达到各核看到相同的逻辑地址但是对应不同的私有物理地址。具体可以参考multicore program guide：http://www.ti.com/lit/an/sprab27b/sprab27b.pdf。
7. JTAG连接不上目标板怎么办?

A： JTAG连接不上目标板，有可能是硬件信号有问题，也有可能是软件配置不对。 下面这个WIKI网页总结了各种连接问题以及调试方法：
http://processors.wiki.ti.com/index.php/XDS_Target_Connection_Guide
http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems
8. DSP死机了，有哪些手段去查找原因?

Ａ：DSP死机主要分以下几种场景：
1)       出现死机时，仿真器不能连接上DSP，也不能通过外设对DSP进行访问。
2)       出现死机时，仿真器不能连接上DSP，但还可以通过外设（PCIe,SRIO等）对DSP进行内存访问
3)       出现死机时，仿真器能连接上DSP进行调试。这种情况下，通常是代码跑飞了，DSP core并没有跑死。

      对于场景1， 最有效的方法还是检查代码，比较出错版本和正常版本之间的差异，找出可疑点进行分析。
      另外，可以并将DDR设置成self-refresh模式， 把一些调试信息记录到DDR。 死机后，复位 DSP， 但不要重新初始化DDR，这时候通常可以从DDR中读到上一次死机记录的信息进行分析。

       对于场景2和场景3，可以分别用外设和仿真器进行调试信息的分析。

       另外，TI的多核DSP支持trace功能，可以记录DSP的运行轨迹进行错误分析。 关于trace的使用方法和例子可以参考如下链接：
        http://processors.wiki.ti.com/index.php/Debugging_With_Trace

0