测试SSD芯片，需要很多很多不一样的设备

仪器：Emulator

在SSD主控芯片设计阶段，除了RTL Simulation以外，通常还会进行Verification的工作，而Verification中就会使用到Emulator或者FPGA。

先说一下Simulation和Emulation的区别：

Simulator是做仿真，基于软件，重点是实现芯片的功能并输出结果；

Emulator是做模拟，用硬件实现，通过模拟实现芯片的内部设计，从而实现功能并输出结果；

业界比较知名的Emulator提供商Cadence，旗下的Emulator产品Palladium系列，如图所示。

图1-1 Emulator

按照官方的说法，这货可以做Simulation，Simulation Acceleration和Emulation。

在设计SSD主控芯片时，Emulator和FPGA都可以用于ASIC Verification，那这两者区别有哪些? 个人理解，主要有这么几点：

1. 价格：Emulator大概百万刀级别，FPGA大概是数千到万刀级别 ；

2. 能力：Emulator的逻辑可以到23亿门（这是老款Palladium XP，最新款据Palladium Z1达到了90亿门），FPGA大概是百万门级别。对应到SSD主控里，一块FPGA可能只能模拟前段（PCIe+NVMe)，后端（闪存 Controller）可能需要另外一块FPGA， 而Emulator，只要你想塞，整个ASIC的RTL塞进入也是妥妥的；

3. Debug：Emulator可以比较方便的导出ASIC攻城狮所需要的信号并抓取硬件逻辑波形，而FPGA在连接协议分析仪，逻辑分析仪方面比较方便；

4. 速度：Emulator虽然好，但是速度比FPGA要慢的多 – 来个传说中的例子：如果FPGA上boot一个OS要几个小时，那Emulator上boot一个OS可能要几天

5. 逼格：FPGA是个公司就能有，Emulator则绝对是实力的彰显—有领导，VIP来参观的时候，给参观一下，顿时就跟其他公司拉开差距了；

归根结底，Emulator和FPGA都是很好的工具，需要正确，合理地使用，才能更好地在芯片研发阶段发现更多ASIC问题。

Emulator（或FPGA）另一个好处是，固件团体可以使用这些工具提前开始开发，不用等芯片回来以后，先经历“不死也要脱层皮”的Bringup阶段，然后才开始“遇到问题不知道硬件原因还是代码原因的”开发阶段。

Emulator – 致力于构建SSD主控和谐团队！

仪器：协议分析仪（Analyzer）

要测试SSD，需要很多很多不一样的设备，需要花很多很多的银子。

目前市面上的SSD接口挺多，有什么SATA，SAS，PCIe，U.2, M.2, MSATA, GumStick，其实走的前端协议就两大类： SATA/SAS和PCIe。

一颗SSD主控一般分前、中、后三段，前端就是SATA/SAS和PCIe这些配上AHCI或者NVMe，中段就是FTL，后端就是闪存控制器。

FTL是纯软件实现，测这个基本上不需要什么设备。

后端跟闪存打交道，主要用逻辑分析仪，另一种巨贵的仪器，这里不展开说。

这里先聊两种协议分析仪，SATA/SAS Analyzer 和 PCIe Analyzer。

Analyzer是个啥玩意儿？你可以这么理解，以SATA Analyzer为例， SATA Host和SATA SSD之间传输命令和数据，就像两个人在打电话，不在这个线路上的你，正常情况下是听不到的他们说了什么的。

Analyzer就相当于在他们两之间装了一个窃听器，这样你就可以完完整整的知道他们之间的对话，同时他们俩并不会察觉。

SATA/SAS Analyzer的供应商，平时接触比较多的有两家：SerialTek和LeCroy。

图为SerialTek SATA/SAS Analyzer

图1-2 SerialTek SATA/SAS协议分析仪

连在主机和SSD之间是这么个样子，如图所示。

图1-3 SATA 协议分析仪连接示意图

抓到的Trace是这个样子，如图所示。

图1-4 SATA Trace示例

PCIe Analyzer的供应商，主要有三家：LeCroy，SerialTek和Agilent。

图为LeCroy的PCIe Analyzer：

图1-5 LeCroy PCIe 协议分析仪

配有各种Interposer卡，如图所示：

图1-6 LeCroy PCIe 协议分析仪 Interposer cards

抓到的Trace是这个样子的（这是一个NVMe读写的命令，LeCroy可以帮你解码NVMe，AHCI这种常见的存储协议），图7-14中，软件将PCIe Trace中的NVMe命令解析了出来。

图1-7 PCIe软件解析NVMe指令

使用PCIe Analyzer可以测量PCIe的物理层，链路层，事物层。跟示波器不同，Analyzer可以基于PCIe协议将链路上所有Lane上发生的事务都解析出来，并且还提供Trigger（触发）的功能 。

对于Analyzer的一大挑战就是在链路电源状态切换的过程能够快速适应，越早能够实现正确的抓包并解析越好。

这点在调试的时候尤其重要，看一个实际的例子：对一个寄存器做CfgWr操作，但是结果发现写进去的值不对，而且这个问题只在ASPM enable的时候才会发生。

电源状态切换对于PCIe 发送端和接收端来说是属于压力比较大的操作，因此有时会导致链路不稳定从而发送错误的包。这种问题调试需要抓trace，而analyzer必须在链路从L0s退出进入L0时发送的TLP都抓到，否则就无法查看错误到底在什么地方。而L0S退出的时间非常短，Analyzer需要在链路从electrical idle（空闲状态）退出后非常短的时间内（几十个FTS）就能正确抓包并解析。

工具是死的，人是活的，啥时候抓trace，抓哪个阶段，抓的时候满屏的红色怎么办，怎么设Trigger，trace怎么分析？这些就需要攻城狮们自己花时间琢磨了。

仪器：Jammer

再牛的肖邦，也弹不出SSD厂商的悲伤。

一块SSD到不同客户手上，不知道会接在什么机器，使用什么样的OS和主机驱动，在什么环境下使用，

结合巨大的使用数量，不知道哪天某块SSD就会从主机那边收到一个不按套路出牌的FIS或者Primitive （SATA SSD）。

举个例子: 主机发了一个读命令，SSD二话不说开始干活，辛辛苦苦把数据从闪存里读出来，仔仔细细的进行ECC解码，小心翼翼传到DDR，进行MPECC检查，再全神贯注的传到SATA模块的某个FIFO，这时候SSD抹抹头上的汗，把手擦干净，写了一张字条，上书”X_RDY”, 恭恭敬敬的递给主机， 然后把数据捧在怀里，细心的用SOF包装好，殷切的期盼主机也回复一张小字条“R_RDY”。主机十分感动的看着SSD，然后回复了一句“R_ERR”拒绝了他。

林子大了，什么样的客户都有，但是客户们的要求是一样的——“主机虐你千百遍，SSD你要待他如初恋” ——术语叫做Robustness （健壮性）。

为了保证健壮性，ASIC和固件攻城狮们要花大量的精力，脑补各种错误可能性，在RTL和FW 中加入相应的错误处理（Error Handling）的流程。

这么做有两个问题：

这些错误处理的流程，在实验室里面跑个一礼拜，可能也撞不到一个；

再牛的攻城狮，也没法提前考虑到各种错误可能性。

与其让别人找麻烦，不如自己给自己找麻烦。搞测试的就是平时给ASIC和固件找麻烦，以SATA SSD来说，可以用一种工具——Jammer.

图中小一号的那个就是SATA Jammer。

                        图为SATA 协议分析和Jammer

如果说Analyzer是一个窃听器，让你知道主机和设备之间发生了什么，那么Jammer就是一个邮递员，主机和设备之间所有的通信都必须经过他的手，然后Jammer可以把信拆开，将里面的内容修改或者替换，再转发出去。

结合之前的例子，我们可以把正常主机回复R_RDY改成R_ERR, 从而检查SSD遇到这种情况处理是否正确。

图为Jammer管理软件截图——向一个Data FIS中故意注入CRC Error。

通过在SATA链路上创建各种不同的错误，可以确认各种错误处理的流程是否正确，或者完善，甚至增加新的流程。

Jammer还有别的用处，当你想知道某种场景（Scenario）发生以后主机或者设备的反应时，你可以通过Jammer来知道答案。比如当设备回复的SDB里面Error Bit被置上，或者设备一直不发SDB时，主机是不是会重发命令，重发几次，重发多次设备都没反应的话Driver会不会启动OOB，Application会不会报错?

Jammer -- 你值得拥有。

本文节选自《深入浅出SSD：固态存储核心技术、原理与实战》一书