前言

       接上一篇文章：LiteDram仿真验证（一）：安装、配置及导出Verilog，上一篇文章，在搭建好环境，导出Litedram_core.v文件后，原本计划是使用镁光的DDR3模型在Vivado或Modelsim上对这个内核进行仿真。
       但是，用AXI接到内核的AXI用户接口，对模型进行testbench仿真，发现，DDR3一直无法完成初始化(即init_done，一直没有被拉高），于是乎，我查阅了GitHub项目中多个讨论。

一、讨论

1、init_done never goes to 1 in simulation #145

        这个问答中，提问者的问题大概是，litedram在仿真过程中一直没有被拉高，即使后面被拉高，也是花了很长的仿真时间。litex的作者表示可以禁用部分功能，比如串口在仿真时会花很长时间。

2、Add ECP5 support to standalone core generator #106

        在这一问答中，提问者的问题大概是，他想单独使用litedram作为控制器来控制DDR，但是他又不想使用CPU，问有没有办法避开CPU执行控制器的初始化。
        litex作者的回答：大概意思是，对于SDRAM使用纯逻辑来实现初始化不会太复杂，但是DD3/DD4，读写很复杂，CPU来初始化可能比自己写Verilog完成初始化占用更少的逻辑资源，要尽可能的使用CPU。然后又说，VexRiscv 的精简版已经很好了，将来我们可能会有更小的变体或内核，我们可以使用它，切换到它会非常容易。因此，除非您不打算使用 DDR3 和 DDR4，否则我不确定是否值得在纯逻辑中这样做。

3、Help generating DDR3 Verilog module for Digilent NexysVideo Artix-7 FPGA #281

       这个问答者，想生成一个litedram_core.v运用在 Digilent NexysVideo Artix-7 板卡上，但是也遇到了初始化问题。从问答中看，问答者自己写了个wishbone的py文件，但是我还没去验证他在这个是什么。有空可以看看。

结论：

       内核的有个CPU总线（wishbone）是需要控制的，不然无法完成Litedram的初始化。并且自己手写的wishbone初始化，占用的逻辑资源可能比他的精简版VexRiscv 占用的资源多。

       下面有个项目用VHDL对litedram进行了初始化，可惜笔者能力有限，对VHDL代码不是很所熟悉没有进行解读，读者有兴趣可以自己看。
https://github.com/antonblanchard/microwatt/tree/master/litedram/gen-src

       另一个项目：https://epsilon537.github.io/boxlambda/exit-mig-enter-litedram/，使用system Verilog设计了litedram的外包装，实现初始化，但是很不幸，sv代码，笔者也不熟悉，看了一段时间，没能解读。有兴趣的，自己看。值得一提的是，这个作者也遇过这个初始化的问题，并且向litex作者提问了。

二、关于DDR3初始化问题

https://github.com/enjoy-digital/litedram/blob/master/litedram/init.py

https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/liblitedram/sdram.c

Sdram_init（）
       Sdram_phy.h 还包含一个名为 init_sequence（）的函数。此函数作为名为 sdram_init（）的更精细初始化函数的一部分被调用。但是，Sdram_init（）不是生成litedram的代码的一部分。它是sdram.c的一部分，sdram.c是liblitedram的一部分，liblitedram是基本Litex存储库的一部分，而不是LiteDRAM存储库。（也就是说，如果你单独生成litedram_core.v，并不会包含sdram_init，即没有初始化）

       在做Litedram项目中，我跟前文讨论的问答者一样，也是想单独使用litedram来控制DDR，但是也遇到一样的问题，做了很多工作，都没办法完成仿真，我也尝试过对wishbone进行读写，奈何不熟悉，暂时还没用完成，后面要是完成，我会继续出一篇文章讲解。
       我也尝试生成带vexriscv的arty vivado板级工程，通过testbench进行反向仿真，但是不知道为什么，仿真总是会报错，进入死循环。
       接着，我尝试按照官方仿真进行仿真，发现别有洞天：
       装好verilator，运行仿真脚本，可以根据指令实时仿真，并且产生VCD波形，通过gtkwave可以看波形，一个几秒的仿真，只需要几分钟，又快又实用。还不用自己写testbench。

       输入litex_sin --help，可以看到各种配置的仿真工程，可以根据自己需要产生仿真工程。

       我这里激活了sdram，并且定义了sdram型号，将CPU设置为vexriscv，并打开了仿真波形追踪功能，还有寄存器文档生成。

生成完，可以看到，进入了bois

       在命令行输入help，可以看到，支持的一些仿真：
       这里支持能哪些仿真，主要是看你在产生工程的时候，激活了哪些功能，我这里有CPU+SDRAM。

我运行了一个sdram_init，然后产生了vcd波形文件。

       打开波形，这里就是sdram的初始化。值得一提的是，我在检查仿真工程的时候，没有看到DDR仿真模型，他的phy接口都是内部信号，可能在内部调用了某些函数，然后接到了模型上（代码有上万行，我暂时还没看完）

-------因为我周五下班的时候，就干到这里，工程较大，波形我还没去研究，等下周上班看看（目前的想法是从bios中的main.c文件进行调试看看，砍掉一些我用不到的功能，比如一些串口打印信息会特别浪费仿真时间），我会对这篇文章进行补充。

未完，待续。。。。。

三、Linux环境问题

问题1：终端拉不了GitHub资源

       之前留下一个问题，后来有几个网友问起，如果在wget或者git clone，一直连接不上资源，或者显示拒绝连接时，建议在最前面加上：proxychains

       简单来说，Proxychains可以帮助你绕过网络封锁或限制，访问被封锁的网站或服务。通过选择可用的代理服务器，你可以获得更自由的网络访问。有些网络资源可能对特定地区或IP地址进行了限制，使用Proxychains可以通过连接到代理服务器来获取对这些资源的访问权限。用proxychains，可以解决99%的问题。

问题2：Python版本

       Litex要求Python3.7，太低的版本经常报错，我的系统Python是3.6经常报错，后来装了个3.7，因为多个版本存在系统里面，很混乱，然后就去百度，有垃圾文章就说把系统版本指向Python3.7，改了之后，系统各种问题，连apt都不能用了。后来在师兄的推荐下，装了anaconda，可以创建各种Python，要用的时候，激活一下就行。特别好用。

创建：conda create --name 名称 python=3.7
激活：conda activate --name

       像这里，我就激活了一个litex_new_0525的环境，是Python3.7。不用的时候，再切回base就行。

想装的，可以自己百度看看教程，还有其他指令。