对于IC开发工程师我们可能都有这样的痛苦经历，经常需要手动为不同工艺库替换Mem。有些团队的MemWrapper可能是有专门的脚本来生成，内部会用宏来区分不同工艺，相对来说还比较省事一点，即便这样MemWrpper的集成也是需要你手动连线。但是如果你是IP提供商，不同的团队或者公司的MemWrapper的信号命名也各不相同。同样替换Mem是一件极其无聊并且容易出错的事情。

另外我发现SpinalHDL自带的mem类型并不适合直接拿来做例化，所以需要为此创建一个新的解决方案来满足IC设计中这种常见的需求。spinal的mem模型我会放到Blackbox内部做为行为模型，这样在仿真的时候你可以clearBox来使用mem参考模型来仿真，不需要真正的去包含一个memwrap.v文件，这样在前期设计中非常方便。

因此对于设计者来讲，我本来只需要关心这地方例化的Mem类型（双口，真双口，单口），数据位宽，mem深度即可。除此之外工艺相关的事情对设计者应该是透明的。

可以总结为两点诉求

• MemWrap替换不应修改HDL代码， 对开发者透明
• 添加新的Vendor memWrap不应修改Spinal源码，保持前向兼容

因此，对于开发者来讲，只需要知道统一的RAM例化接口，为此为Spinal设计常见的3种MEM类型.

鉴于被chisel的peek poke test愚弄以后，我一度对Scala上的仿真环境不是特别有信心，当看到spinal.sim的时候觉得可能只是一个能work的demo而已，并没有足够重视。

我用Spinal开发的前几个模块依然走的传统的验证流程，先生成Verilog，然后再用scala生成激励，最后打包丢到Linux服务器上, 用Verilog/SV编写tesbech， 搭建测试比对环境，仿真工具不是VCS就是NcSim这些老牌商业软件。

直到一个偶然的机会，有一些很零碎的模块需要测试，不想再为此搭建一整套仿真环境，我想干脆用spinal.sim 简单做个测试，不测不知道，一测一发不可收拾。

SpinalHDL就是这样的汉子，一次又一次的轻视它，但它又不时的给你惊喜。

• 不同于iotest的peak poke， 它的后台是verilator, verilator非常强大，性能比起商业软件VCS、NC毫不逊色。
• spinal.sim 通过包装verilator提供的VPI，能够很方便灵活，实时的跟dut交互通信, 加上Scala本身语言的灵活性，它能做的不比UVM少。

今年chisel貌似后知后觉的回过神了，摒弃iotest，重新设计iotester2, iotester2和spinal.sim的思路很类似了, 后台是verilator, 有兴趣的可以自己试试

接下来我主要借助通信基带的两个模块来介绍一些如何使用SpinalHDL进行仿真测试，以及如何构建组织管理回归你的测试CASE。

对于spinal.sim的基础操作和使用请浏览官方文档Spinal-sim，这里不再赘述。

最近花了点时间基于Jupyter-notebook做了一个SpinalHDL教程.
方便立即运行查看一个Spinal用法和对应生成的verilog代码，大多数例子来源于SpinalHDL的官方文档，也新增了一些实例和Scala的高级用法，这些可以帮助你理解SpinalHDL如何工作。

目前可以直接点击运行，国内访问Binder速度有点慢，也可以
clone到本地运行。

为什么做这个事情

• 提供一个SpinalHDL的在线环境，方便测试功能用法，直接查看verilog，而不用新建工程
• 提供一个Scala的在线环境，方便你测试一些Scala的用法