RISCV评估

一、按照xx原架构集成芯来CPU

生成代码时选择ID总线合并，共用基地址0x0000_0000与xx的ram核一致，接口总线选择ahbl总线，总线位宽25bit。不需要ICACHE，DCACHE默认不选择。其他可以默认，实际设置时将debug改到0x7000_0000，timer地址改到0x7200_0000上。

添加define将n300_core_wapper集成进arm_shell上，加入FPGA的filelist，修改run_sim.pl添加-rv选项跑riscv核。为了能够在仿真环境中打印fw中的printf的字符串，在monitor中$write(%c,hwdata[7:0])，与fw协商的打印地址为0x6000fff0。

FW环境由软件提供，调试中遇到的几个难点，一个是数据从ilm拷贝到sram不成功，导致的现象就是定义的变量数据，访问不到，导致变量定义无效，也导致printf打印函数一直无效，芯来cpu可以通过trace来查看当前指令执行情况，最后修改多次尝试ld文件解决内存拷贝问题。printf打印问题，在内存拷贝问题解决后还存在，修改软件代码解决。还有timer不计数问题，添加mtime_toggle_a异步周期性脉冲后可以正常计数。

系统架构如下，core_main.hex文件先force到ROM中，在系统启动后将数据部分cp到sram中，后续通过系统总线访问，测试结果coremark数据为2.66 coremark/MHz，相同测试条件下的ARM的core数据为2.60 coremark/MHz

将core_main.hex文件先force到ROM中，然后将指令和数据全部拷贝到SRAM中，都通过S总线去访问，ARM的core数据为1.65 coremark/MHz。

将core_main.hex文件分别force到ROM和FLASH中，ROM启动后配置cache使能并跳转到flash取指令，数据和堆栈放在sram中通过S总线去访问，与xx芯片的运行模式一致。ARM的core数据结果为1.73 coremark/MHz。

二、按照新架构集成芯来CPU

新的SOC架构按照I和D总线地址分开，但是D总线然可以访问I总线，基地址分别是0x80000000和0x90000000，LM总线选择SRAM总线，勾选N300_CFG _LSU_ACCESS_ILM选项。带上ICACHE，ICACHE大小32KB，其他与之前保持一致。

将生成的cpu核集成在arm_shell里面，ILM使用rom，大小与之前一致，dlm使用sram，cache ram为32KB sram，系统总线保持与原来xx架构一样。要注意的是ILM指令是0x80000000开始，reset_vector信号要设置为0x80000000。

修改测试环境，仍然是通过force rom方式初始化rom，在系统启动之后将数据cp到DLM中，该模式下riscv核的coremark数据为3.40 coremark/MHz，这个数据与芯来提供的FPGA测试结果一致。

修改测试方式，先将core_main.hex force到rom，在系统启动之后将数据cp到系统总线的sram中，该模式下riscv核的coremark数据为2.66 coremark/MHz。与之前ID合并的架构执行运行在ILM，数据运行在系统总线的SRAM一致，说明系统总线的运行效率是低于LM接口的。

综上总结：

1. 搭建了一套评估SOC效率的测试环境，为后续架构提供支持；
2. LM接口的访问效率高于系统总线，系统总线上会有BIU模块，里面有buffer；
3. I、D总线合并影响CPU效率，没有体现哈弗架构优势；
4. ICache都能够大量hit，则通过系统总线flash模式下，效率理论上可以接近LM