从fail到pass，DDR调试到底经历了什么？

caroline11

做DDR的调试无非以下三种结果：调试fail、调试pass和调试很久才pass。你可能永远也想象不到PCB工程师花几天设计出来的DDR模块在加工出来后调试就多久才pass，一天？一周？一个月？甚至……

高速先生近几年来在DDR设计仿真取得了长足的进步，这要得益于AI（人工智能）的热潮，作为该领域的核心产品，AI算力卡成为近年来各大通讯公司和芯片公司争相研发的产品。而其中DDR模块则是AI算力卡里最核心的模块，支撑着算力卡大容量、快速的运算能力。

高速先生在和各大公司合作的情况下，也有机会接触到了形形色色的AI算力卡，它里面的DDR模块虽然实现的功能类似，但是具体的结构却有着很多的变化。例如容量的不一样导致颗粒数量的不同；板子的大小不一样导致采用的拓扑不同；PCB层数的不一样导致DDR模块的布局和密度也不相同；有的由于功耗电流大小不一样导致DDR走线参考层也不相同，有的需要参考电源层，有的需要相邻层走线；当然还有的就是需要跑到的目标速率不同，我们在设计上的设计裕量也会有所差异等等。因此对于我们高速先生来说，每一块算力卡的DDR设计都是不同的，当然设计加工出来之后，我们和客户配合着去调试的难度也是不一样的。这一块高速先生在近几年的研讨会上也和大家分享过一些经典的案例，让大家对DDR的设计和调试难度都有了新的认识，AI产品的一些特点关于它的设计使得比以往任何产品的DDR难度都要大一点，当然我们也就会有很多测试和仿真的案例了。这里关于DDR调试的案例，我们再给大家分享一个从fail到pass的经历哈。

在一个安静祥和的午后，高速先生刚刚还略带点午睡的困意开始下午的工作，就突然收到了客户一份很“提神”的邮件，让大家立马精神了起来。

原来是客户在我们公司设计加工的一款主力的AI算力卡出现了调试fail的问题，客户本身是一家很有研发能力而且很严谨的公司，它们对硬件原理和调试都是具有丰富的经验，然而这款产品的DDR模块他们调试了几周都依然没办法成功。由于是我司PCB工程师设计的板子，因此高速先生肯定是临危受命，去负责介入到他们的调试中去。

高速先生打开PCB文件，看到了FPGA和C1这个DDR通道的连接，这个通道是由9个DDR颗粒组成，也就是我们所说的1拖9的DDR拓扑。由于板子的密度很大，因此只能采取正反贴的形式进行布局布线，如下图所示。

由于FPGA芯片是有关于DDR的设计指导文档，我司的PCB工程师和客户在投板前也反复确认了该DDR模块的设计是完全按照文档上面每一条细致的指导去布线的。例如下图的L0，L1，L2等每段长度文档上都是有要求。

客户就是因为觉得都按照了上面的设计指导进行布局布线，认为设计其实是达到了要求，因此才坚持着花费了近一个月的时间进行调试，希望能从调试中去解决问题。高速先生介入后，发现客户的调试其实已经做了很多内容，包括驱动内阻的变化，ODT电阻的变化，电源电压的微调，VTT电阻的改变，飞线等等，但是仍然无法达到额定的2400Mbps的速率。由于这个项目当时是没有进行过我们高速先生仿真的，因此我们首先建议做一个debug形式的仿真，也就是在基于调试结果的仿真，看看仿真的测试的拟合度到底高不高，从中找出问题。

由于我们对xilinx的FPGA仿真模型和DDR颗粒的仿真模型都比较有信心，之前也做过很多仿真测试的对比，发现仿真和测试波形的拟合度是比较高的，再加上高速先生看到这个拓扑还是非常的复杂，因此有信心在客户调试的配置参数下得出一个“差”的仿真结果！你没听错，我们这种debug的仿真就是希望得到一个差的仿真结果，这样才能和实际上调试fail的情况吻合上。

果然，高速先生希望的事情发生了，我们对地址控制信号进行仿真的时候，发现了距离FPGA最近的DDR颗粒的信号质量是不满足要求的，为什么要看距离主芯片最近的颗粒，这个高速先生已经说过很多次了哈，这里就不再重复了。

同样，根据客户调试的情况，我们在仿真中选择不同的驱动内阻和VTT电阻的阻值，的确也和调试的情况类似，都不能得到一个很好的信号质量。到这里，我们开了一个好头，至少能在仿真中得到了和测试结果相对应的结论。

但是高速先生在仿真中还能做些什么呢？我们虽然通过仿真找到了差的波形，但是这对于调试却起不了太多指导的作用。因此我们继续去通过仿真模型来看看，到底会不会还有什么驱动的配置我们可以尝试过。我们打开FPGA的ibs模型，看到可选择的以下驱动配置中，其实我们和客户只用到了左边的这种配置，上面有40到60欧姆内阻的选择，我们仿真和客户调试都试过了，没有明显的改善。

但是我们惊讶的发现，原来模型上还有绿色的两列基本和之前红色列的配置几乎一样的驱动内阻可以选择，但是唯一不同的是F，M和S的区别，因此高速先生再花点时间去扫描一下同样是40欧姆驱动内阻的情况下，F，M和S下面这三种buffer到底会不会有差异呢？

结果让高速先生感到惊讶的同时又感到兴奋，原来在FAST，MEDIUM和SLOW模式下，对于同一个驱动内阻的波形是有着明显的差异。我们看到MEDIUM和SLOW模式下，信号的上升沿slew会变缓，这样反而避免了部分的反射，使得信号的ringback减小，眼高的裕量变高。

根据上面的扫描结果，我们选用MEDIUM的模式进行全通道的仿真，看看和之前fast模式的结果相比到底有没有改善。

结果给高速先生带来了喜悦，我们用MEDIUM模式去仿真的结果能够得到明显的改善，同样的颗粒信号质量变得可以接受了。

高速先生从FPGA模型的选择上解决了问题，选取上升沿slew比较缓的驱动反而能够获得比较好的信号质量。

到这里，我们就只剩下最后一个问题了，那就是到底我们能不能让客户在调试的参数配置中选择MEDIUM的模式呢？客户把他们调试的软件界面发过来给我们，我们从下拉菜单中看到了的确有这种模式可以选择，然后就让客户从默认的FAST模式自动换成MEDIUM的模式，看看效果有什么改善。

在大概等待了一天之后，客户的一封报喜的邮件让我们大家都轻松了下来，客户调试了一个月之后，终于通过这个手动调试的buffer切换快速解决了问题。