仪器：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和固件找麻烦，来看看这个减少芯片错误的利器是什么？
（查看更多内容，扫描下图二维码，阅读原著和以上大图。）
