riscv-sodor-rv32_1stage(5)_rtl & simulation

为了更直观学习riscv-sodor-rv32-1stage的代码，我直接用它们自带的仿真进行分析。

首先看得是riscv-sodor-rv32-1stage的整体框图：

然后看的是core层次的框图：

接下来我们以它们自带的memdian例子来说明riscv-sodor-rv32-1stage是如何运作的。先看下面的图：

我们先看黄色箭头，黄色箭头是什么意思呢？
第一个黄色箭头指的是SimDTM，它是一个仿真模块，模拟我们将代码download到memory的过程。所以实际上SimDTM–>debug–>memory就是我们的下载代码过程，这部分涉及RISCV-DEBUG协议的说明，暂时不展开说明。右边黄色箭头就是它们download的过程。

可以看到在download过程中，reset是一直拉高的，所以我们的core是一直被复位的，只有完成download了，才被释放出来。

红色箭头就是core运行的情况，实际上是core–>memory的运行过程。io_mem_*端口是core向memory请求执行指令的数据，而pc_*就是core里面pc的变化情况，还有in_data_inst就是当前执行的指令。

我们再放大一下波形：

蓝色箭头中，io_debug_port_req_bits_fcn只有在debug模式下才会被拉起，也就是只有download过程中被拉起，在core正常运行期间是拉低的。

我们进一步放大波形：

这就是core正常运行期间的波形。再重复一遍：实际上是core–>memory的运行过程。io_mem_*端口是core向memory请求执行指令的数据，而pc_*就是core里面pc的变化情况，还有in_data_inst就是当前执行的指令。通过波形可以看到core执行期间是同步取指令的，即pc_reg是什么地址就去memory相应的地址取执行指令，而且是当拍有效，不存在数据的延迟。

下一步我们看生成的rtl代码，找找io_imem_req_bits_addr代表的是什么？

可以看到，assign io_imem_req_bits_addr = pc_reg;也就是说，我们请求的数据就是当前需要运行的pc地址，而且数据是一请求就有的，不存在延迟的，这点可以通过看波形得知。

最后我们看看pc为什么最开始是0x8000_0000。

可以看到，core模块的d(DatPath)模块中唯一的always块中有对pc_reg的赋值，复位后为0x8000_0000，其他为运行指令期间的变化。至于0x8000_0000地址的指令是什么意思，大家可以对照反汇编文件来一一学习。我简单说两个，0x0000_0113是对应li ra, 0(将立即数0装载至通用寄存器ra中，是32位的指令，没有使用压缩指令)。0x0000_013是对应li sp, 0(将立即数0装载至通用寄存器sp中，sp为栈的通用寄存器，是32位的指令，没有使用压缩指令)。

riscv-sodor-rv32-1stage的运行先说明到这，后面再慢慢补充。有问题的可以私信或者评论留言，谢谢。