This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

IPC例程中关于cycle的问题



1、我在测试IPC例程(0--7核依次相互触发中断,即core0触发core1,然后core1触发core2,依次类推)时,软件仿真时打印出的cycle数约为30万,,在6678评估板(频率为1Ghz)上的输出结果约为1秒(计时起点:core0写IPCGR1前,计时终点:core1收到中断),无论软仿还是硬仿,触发中断的时间都太长了,请问这是什么原因?如何改进?

下面为我在评估板上的程序测试结果截图:

 

2、请问在实际应用中核间通信利用IPC方式可以吗?

  • IPC中断中分别读取两个核的TSC寄存器的方式来记录IPC通信耗时,此时如果由于两个核的不同步会导致记时的不准确。所以建议可以采用如在收到中断后再向对方法中断响应的方式,这样都由一个核来读取时间从而得到最终的两次IPC耗时。

    采用何种核间通信方式与具体应用有关,IPC是一种可供选择的方式。

  • Andy Yin:

          你好!

          谢谢你的回答。

          我现在利用触发核间中断进行多核程序设计,实现了以下功能:0核先向1、2、3、4核生成中断,当这四个核响应中断后,再触发0核中断,0核响应中断后再触发5、6、7核的中断,当这三个核响应中断后再触发0核中断,这个过程在评估版上的测试时间约为0.5秒,均在0核中计时,这个时间显然太长了,请问这是什么原因?如何才能将核间响应时间提升至微秒级别?谢谢

  • 请问你的问题解决了吗 ? 我也遇到了同样的问题,而且我的测试时间比你的还多,都使TSCL寄存器溢出了,而在培训资料里面的IPC例程中的测试时间是:

    请高手们指点下:

     
  • 有没有可能打印语句使用的时间太长了?

  • 楼上说的对,我也跑过相同的示例程序,remove 所有的printf 或者System_printf, 改用全局变量观测cycle delay ,结果在几十个cycle的数量级。单独一个System_printf 应该不会耗费多少cycle,可能几百个左右,但这种console输出机制去测算us级以下的时延是不准的。建议System_printf的模式用Sysmin 的方式而不是sys std, 亦或者bios 里log函数来trace cycle。