Skyeye对其它cpu的模拟讨论, 目前是框架讨论,请进!
还没什么思路, 先发起这个讨论. 想要为Skyeye对其它类型(非ARM)的cpu模拟订立一个好的框架需求:
1.周期精确的cpu模拟意义大吗? 大家觉得目前skyeye这样周期不精确的模拟够用吗?
2.新模拟的cpu要能够试用现有的模拟外设,这个应该问题不大.
3.框架包括数据结构,指令,mmu,cache四大部分, dsp类型的cpu需要其它部分吗? 有指令模拟就够模拟dsp了吧?
4.如果用QEMU类似的技术不能够支持调试的话, 我觉得不太好.
随便说了几句,大家多讨论! 4. 即使不能够支持调试, 但如果性能有大幅提升, 我觉得还是很有意义的. 不同的用户关注点不同, 但我们可以通过配置文件来选择 嗯,你说的是, 看用在什么场合了. 但是问题在于维护两套模拟代码会很麻烦. 最好是有一个同时支持两种类型的cpu模拟的架构. willyyang，您好，我现在做的是一个DSP模拟器，这种DSP不是像您说的“哈佛结构是内部实现的”(arm好像就是您说的这种吧)，而是标准的哈佛结构,片外ram是分开的。因此在做模拟器时，分别模拟了data与code两片RAM，现在遇到的问题就是，用DSP提供的编译器编译出来的ELF文件是扁平结构的，将该ELF文件LOAD进模拟器时需要进行修正。
1)哪些section下载至data ram，哪些下载至code ram?
2).Text中对变量等符号的引用如何修正？
这个模拟器是参考GDB的ARM模拟器写的，但是ARM不存在这样的问题，不知道怎么处理，看看您有没有什么好的建议？ 嗯,这种情况就比较复杂了, gdb目前的模拟框架可能需要修改. 你要先把你的dsp硬件搞清楚, 象你提的两个问题都是要通过研究你的dsp编译器才能明白的.你的elf既然是扁平的, 就是说烧在flash里时是扁平的? 那么是由谁把它载入ram的? 对这个载入器研究一下也许会有帮助. 感谢willyyang的回答。
“就是说烧在flash里时是扁平的?那么是由谁把它载入ram的? ”
编译器与载入器是厂家提供的，没有源码。
下载到flash中，是通过仿真器的，仿真器通过命令切换来操作是写入data ram，还是写入code ram，此时肯定不再是扁平的，而下载部分是我们自己写，问题就就出在这里。这就是问题1)哪些section下载至data ram，哪些下载至code ram? 呵呵，自己写的模拟器也遇到同样的问题，就是load文件时的data/code section的区分。
看了GDB部分，大概可以通过symfile.c中generic_load来实现扁平elf文件的下载，不过下载时需要上述的转换。 要想做到周期精确，难度还是比较大的，恐怕要改动得太多。
对于希望使用周期精确仿真的用户来说，肯定希望能够得到确切的软件运行时间，而这除了与CPU有关外，与各外设的时序关系也很大。
就拿CPU举例吧，除了CPU内部的流水线以及预取指队列（含分支预测）外：Cache算法首先要实现，否则无法精确仿真Cache命中情况，时序上会差不少。
如果确实要实现一个精确仿真，可能还是另开一个项目会比较合适。首先实现CPU/RAM系统的周期精确仿真。 Skyeye for 龙芯应该是个好主意，起码CPU内部的一些算法和结构都有人熟悉，写出的周期精确仿真代码应该能做到很精确。
(for MIPS 应该也行) 可能和主题无关，但是能不能支持flashmemory仿真呢，大多数实际的板子都有，对学习有好处呢。 不知道楼主是否考虑对Powerpc类CPU的模拟呢？我觉得除了ARM Core，Powerpc用的人应该是非常多的了吧 我觉得最重要的是模拟外围设备
要不，就和一般的软件仿真就没差别了 我觉得最重要的是模拟外围设备
要不，就和一般的软件仿真就没差别了
同意这个说法。 问楼主一声，TI OMAP 仿真目前有什么进展吗? 建议增加对ADI ADuC70XX arm7tdmi core的mcu的仿真。它虽然很新，但是很不错！
页:
[1]
2