明修栈道，暗度陈仓：NAND 为什么要让“数据”和“命令”分开走？

点击蓝字 关注我们

因为公众号平台更改了推送规则。记得点下右下角的大拇指“赞”和红心“推荐”。这样每次新文章推送，就会第一时间出现在订阅号列表里。

很多年前，阿呆还只是阿呆。

那时候的他，是一名普通工程师。白天在客户现场看问题，晚上在实验室里抓波形。包里常年放着电脑、转接线、协议分析工具，以及一堆“不知道什么时候就能救命”的线缆。

遇到项目紧张的时候，白天陪客户开会，晚上回酒店分析 log，第二天一早再假装自己精神很好。

那时候的阿呆，眼里看到的是信号、时序、寄存器、fail case。

多年以后，阿呆成了阿呆总。

身份也变了。

他不再只盯着某一个 bug、某一条波形、某一份 test report，而是开始看行业、看公司、看技术路线、看供应链格局。今天参加存储论坛，明天拜访控制器公司，后天去看 NAND 颗粒厂、模组厂、服务器客户和数据中心。

工程师时代，他关心的是：

“这个问题怎么修？”

投资人时代，他更关心的是：

“这个技术为什么会出现？它背后代表了什么趋势？”

上个月，阿呆总下榻宝鸡。

白天是论坛，晚上是饭局。席间觥筹交错，灯红酒绿。酒过三巡，阿呆总望着窗外的夜色，忽然想起了一个非常古老的故事：

明修栈道，暗度陈仓。

当年韩信表面上修栈道，让人以为大军要从正面走；真正的主力，却悄悄绕道陈仓，打了对手一个措手不及。

阿呆总忽然一拍大腿：

“这不就是 NAND 接口现在干的事吗？”

以前的 NAND 接口，命令、地址、数据，很多时候要挤在同一条路上。数据要走，命令也要走，地址也要走。

路是越来越快了，但车也越来越多了。

于是，SCA 出现了。

SCA，全称 Separate Command Address。名字听起来很技术，思路其实很直白：

数据继续走数据总线这条“大路”；                    
命令和地址，单独开一条 CA 专线，提前绕过去。

明面上，数据还在浩浩荡荡地跑。                    
暗地里，下一条命令和地址已经从旁边的小路出发了。

这就是 NAND 接口里的“明修栈道，暗度陈仓”。

一、传统 NAND 接口：命令、地址、数据挤一条路

要理解 SCA，先要理解传统 NAND 接口的尴尬。

在传统 NAND 接口里，Command、Address、Data 很多时候是分时复用的。简单说，就是同一组总线资源，一会儿传命令，一会儿传地址，一会儿传数据。

它有点像这样：

Command → Address → Data → Command → Address → Data

这条路不是不能走，而是大家要排队走。

命令负责告诉 NAND：

“接下来要干什么？”

地址负责告诉 NAND：

“从哪里读？写到哪里？”

数据则是真正的大部队，体积最大，占路也最久。

所以传统模式下，常见流程就是：

先发命令，                    
再发地址，                    
然后传数据。

等这批数据传完，下一笔命令和地址再继续上路。

在低速时代，这种方式问题不大。那时候路不宽，车也不多，大家排队还能接受。

但到了高速 NAND 时代，情况变了。

数据总线越来越快，NAND 内部并行度越来越高，Controller 要调度的 die、plane、block、page 越来越多。SSD 不再是慢悠悠地“读一笔、写一笔”，而是尽可能把各种 NAND 操作流水线化。

这时候，如果命令、地址、数据还挤在同一条路上，Controller 就会遇到一个问题：

上一批数据还在传，下一批命令却没法提前安排。

这就像大军已经在栈道上行进，但下一道军令还堵在队伍后面。                    
不是士兵跑不动，而是调度跟不上。

很多时候，高速系统的瓶颈不只是：

数据跑得够不够快。

还有一个更隐蔽的问题：

调度能不能提前到位。

二、SCA 做了什么：数据走 DQ，命令和地址走 CA

SCA 的思路，就是把这件事拆开。

以前是：

一条路：

Command → Address → Data → Command → Address → Data

SCA 之后，更像是：

两条路：

Data Bus：数据继续传数据

CA Bus：  命令和地址单独传

也就是说，数据继续走原来的数据通道，命令和地址则走独立的 CA bus。

这样一来，当上一笔数据还在传输时，Controller 就可以通过另一条命令/地址通道，提前把下一笔操作安排下去。

这就是 SCA 最核心的价值：

不是简单把数据路修得更宽，而是让军令不要再堵在大军后面。

数据是大部队，负责真正搬运内容。                    
命令和地址是军令，负责告诉下一步怎么打、往哪里打。

如果军令总是被大部队堵住，整个系统就会出现等待。                    
如果军令能提前到位，下一轮动作就能接得更顺。

三、SCA怎么实现

参考以下示意图。注意，它不是严格的标准 timing diagram，而是帮助理解 SCA 思路的简化图。

传统模式：命令、地址、数据共用通道，分时排队

在这种模式下，CMD、ADDR、DATA 都在同一条路上排队。                    
DATA1 传输期间，CMD2 和 ADDR2 很难提前插进来。

所以系统会出现一种隐性的等待：

数据通道忙着传数据，下一笔调度只能在后面排队。

SCA 模式：数据走数据总线，命令/地址走独立 CA 通道

这就是 SCA 的变化。

数据还在 DQ 总线上跑，命令和地址已经从 CA 总线上提前出发。

用一句话概括：

传统模式像单车道：数据、命令、地址轮流走；                    
SCA 像双通道：数据继续跑，命令和地址提前调度。

这就是“明修栈道，暗度陈仓”的技术味道。

明面上，数据大军还在主路上行进。                    
暗地里，下一道军令已经从旁路送到了前线。

四、SCA 到底有哪些命令？

讲到这里，专业一点的读者可能会问：

“所以 SCA 是不是新增了一堆命令？”

这个问题要分两层看。

第一层，NAND 该做的事情并没有变。

它还是要读数据、写数据、擦除 block、查状态、设置参数，也还是会有 multi-plane、cache program、copyback 这类更复杂的操作。

也就是说，SCA 不是让 NAND 突然学会了一堆完全陌生的新技能。

第二层，SCA 改变的是这些命令的“发车方式”。

在 ONFI 5.2 里，SCA 不只是口头上说“命令和数据分开走”，而是定义了新的 SCA Protocol Command Set。它和传统协议命令集并存，目的是让命令/地址可以通过独立 CA 通道进行调度。

可以粗略理解为：

传统模式：

命令、地址、数据都在同一路径上按顺序出现

SCA模式：

数据继续走 Data Bus

命令/地址通过 CA Bus 以 SCA command packet / command cycle 的方式提前下发

对于一些复杂操作，比如 multi-plane page program、page cache program、multi-plane copyback program 等，SCA command set 里还可能引入额外的 command cycle。

但这篇文章不展开 opcode。

因为对理解 SCA 来说，最关键的不是背出某个命令编号，而是抓住这一点：

SCA 的重点不是“多了某个神秘命令”，而是“命令的发车方式变了”。

以前，命令要跟着数据排队。                    
现在，命令可以走自己的路。

这才是它真正的变化。

五、SCA 解决的不是“能不能跑”，而是“能不能少等”

很多人听到新接口、新标准，第一反应是：

“是不是速度又变快了？”

这个理解只对了一半。

SCA 的重点，不只是让数据本身跑得更快，而是让 NAND 接口的整体调度更高效。

高速系统最怕什么？

不是某一个模块不强，                    
而是强模块之间接不上。

数据总线很快，NAND 内部并行度很高，Controller 调度能力也越来越强。                    
但如果命令和地址必须等数据传完才能继续安排，系统里就会出现空泡（也叫 pipeline bubble，就是流水线里某个环节在干等）。

所谓空泡，就是产线明明很快、设备明明很贵、能力明明很强，但某个时刻却只能等。

等命令，等地址，等下一笔 NAND 操作准备好。

SCA 的意义，就是尽量减少这种等待。

让数据传输和命令/地址下发并行起来，让 NAND channel 少一点空转，让 Controller 的调度更顺。

一句话：

SCA 不是让士兵跑得更快，而是让军令先到。

六、为什么现在更需要 SCA？

因为 NAND 越来越快以后，老问题会被放大。

低速时代，命令、地址、数据挤一条路，大家还能忍。                    
就像小路上本来就没几辆车，排一排也没什么。

但高速时代不一样。

数据路越来越快，NAND 内部并行度越来越高，Controller 也越来越会调度。这个时候，如果命令/地址调度还被数据传输挡住，问题就会变得越来越明显。

这背后其实是一条很朴素的工程逻辑：

当数据路已经越来越快，调度路也必须跟上。

否则就会出现一种尴尬：

数据能跑，设备能干，Controller 也想安排，但命令和地址还堵在路口。

所以 SCA 的出现，不只是接口标准里的一个小改动，它反映的是高速 NAND 时代的一种趋势：

系统性能不只靠单点加速，也靠流程分流。

七、SCA 不是魔法，真正难的是系统配合

当然，SCA 也不是一句“分开走”就万事大吉。

技术最怕讲成神话。                    
真正落地时，SCA 至少需要几件事配合。

第一，Controller 要支持这种调度方式。

不是有了 CA bus，就一定能用得好。Controller 要知道什么时候提前发命令，什么时候安排地址，如何和数据传输配合。

第二，NAND device 本身也要支持对应协议。

接口两端要说同一种语言。否则一边想暗度陈仓，另一边还在原地等栈道。

第三，验证复杂度会上升。

当命令/地址和数据可以更并行地工作后，状态机、时序、异常处理、corner case 都要重新看。比如上一笔数据还在走，下一笔命令已经来了，中间如果遇到 reset、busy、error、retry，系统必须处理清楚。

第四，硬件实现也不能掉链子。

多一组独立通道，不只是协议变化，也会带来实现、时序和信号完整性上的新要求。

所以，SCA 的本质不是“加一条路就结束”。

它真正考验的是：

Controller 调度能力、NAND 协议支持、硬件实现和验证覆盖，能不能一起跟上。

陈仓不是随便暗度的。                    
地图、粮草、兵力、时机，一个都不能少。

饭局散场后，阿呆总回到酒店。

他没有立刻打开电脑，而是靠在椅背上，看了一会儿窗外的夜色。宝鸡已经安静下来，车流不多，远处灯光像一串缓慢移动的信号。

他想的不是 SCA 的命令集，不是 CA bus 的引脚定义，而是一个更简单的问题：

如果下一代 NAND 接口的瓶颈不在带宽，在调度——那卡脖子的地方，到底在 Controller，在颗粒，还是在系统设计？

< 长按识别二维码添加好友 >

加入上述群聊

长按并关注

带你走进万物存储、万物智能、万物互联信息革命新时代

微信号：SSDFans