news 2026/8/25 21:28:40

LPDDR6 JEDEC 原文解读学习—2.4 Data Packet Format(3)(~持续更新)

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
LPDDR6 JEDEC 原文解读学习—2.4 Data Packet Format(3)(~持续更新)

插播:2025年马上就结束啦,今天更新一篇,预计12/17号再更新一篇(给自己立flag),然后2025年就休假咯~2026年继续努力码文章,如果有任何问题,欢迎大家评论区评论,交流。

2.4.4 Write Burst Chunk and Order

上一篇介绍了Read Burst在数据传输过程中如何分块(Chunk)以及这些Chunk的Order,这一节讲的是Write Burst的Chunk和Order,我们来看看有什么不同。

2.4.4.1 Write Data and Meta Data

Write data burst assigned the same as Read operation. Write meta data includes Link Protection and system Meta.

写入数据的Burst分配方式与读操作一致,也是采用burst -> chunk切分策略(包括chunk大小,序号标记等都一致)。这样做的目的是保持数据面的一致性,简化发送端/接收端的设计。可以理解为驱动/控制逻辑只实现“一套流水线”,读/写都走同样的数据chunk与order路径;差别主要在数据请求类型(写是把数据推过去,读是请求后再收回数据)和meta data上。

例如上层产生一个写256Byte的burst。

- Chunk:按照与读相同的规则,例如每32B一个chunk,那么一共8个chunk。

- Metadata:在每个chunk或在burst的头尾/聚合处,携带链路保护字段(如CRC,order)。

- Order:按既定的order发送这些chunk(写与读一致的order)

- 错误处理:若链路保护检测出错误(例如CRC失败),出发重传/回放机制。

2.4.4.2 Write Burst Chunk and Sequence

LPDDR6 SDRAM supports 32byte (BL24) and 64byte (BL48) chunk.Details are shown below.

LP6 Write的Burst Chunk大小规定和顺序,与Read一致,如上述。

2.4.4.2.1 Write BL24 Operation: 32byte Access

LPDDR6 Write burst chunk is defined 32byte data, Enhanced Data bus Inversion flag and Metadata mapped to 24beats as unit. There is no write burst start address selectable with in 24beats access. lt means that LPDDR6 Write BL24 operation supports only fixed burst order. Write data input scheme is the same as Read operation.

Write burst chunk = 32byte,除此之外,chunk还包括:

- Enhanced Data bus Inversion(EDBI)标记位,数据总线反相的增强版标记(用于降低功耗/噪声,写入方向需要由控制器生成并随数据传输);

- Meta Data:伴随数据的控制/描述性信息。

这些内容(32byte数据+EDBI标记+metadata)在物理链路上以“24个beat”为一个单位映射。简单说就是,控制器准备一个32B的chunk,并为其计算/附带EDBI标记与Meta字段,随后在DQ上用24个连续的beat发出去。与读burst一样,在这24个beat的访问窗口内,不能选择“写突发的起始位置/起始拍”,必须从固定的起点 beat 0 开始,并按照顺序走到 beat 23.

这里补充一个内容,不知道大家还记不记得之前有简单介绍过DBI,那么这里的enhanced DBI和普通DBI有什么联系和区别呢?首先,两者的核心目的相同,就是减少同时翻转的位数与平均切换次数,降低功耗,噪声,EMI,改善眼图/时序裕量。基本机制都是:当满足某一“反相更优”条件时,把数据做按位取反,并告诉接收端“本次数据是反相后的”,以便接收端还原。

两者的关键差异在于,颗粒度不同,DBI多为每字节或每半字节组,且每个beat都可独立决定是否反相;而EDBI是以一个固定写突发单元(BL24=24 beat)作为映射单元,是面向一个完整的chunk。DBI常见为专用/复用的pin,而EDBI是随某次burst的meta data内嵌到24beat的序列中,不依赖额外独立pin脚。

LP6中这样设计的原因有如下三点:

1. 更大的决策范围:如果反相决策在更大的粒度(如整个32B的chunk/24个beat)上做优化,可以同时考虑位密度和拍间切换模式,从而在峰值同时翻转(SSO)和平均功耗上取得更好的整体折衷。

2. 带内携带减少pin脚压力:把EDBI标志位与Meta内嵌在24beat的mapping中,避免额外的pin -> 即减少复用复杂度,对超高速LP6的pin预算和信号完整性更加友好。

3. 与固定顺序的协同:固定的BL24顺序使得接收端可以确定性地在正确拍位上取出/还原EDBI与Meta,再做数据还原,简化PHY的重组状态机。

2.4.4.2.2 Write Operation: 64byte Access

LPDDR6 Write burst chunk is defined 64byte data, Enhanced Data bus lnversion flag and Metadata mapped to each 24beats as unit. Write 64byte command support only fixed Write burst sequence. When Data Rate is equal or less than 6400Mbps (≤6400Mbps), LPDDR6 supports gapless 64byte. When data rate is higher than 6400Mbps (>6400Mbps), LPDDR6 supports interleaved 64byte access with 24beat gap. Write data input scheme is the same as Read operation too.

与Read burst相同,Write burst也是当chunk size是64byte时,64B的burst会被拆成两个BL24的子单元(每个子单元24个beat),每个子单元也是有各自对应的EDBI+Metadata随数据一起传输。这样做便于在物理上统一处理(每24个beat是一个完整“帧”样的单位),也便于校验与时序对齐。同样的,每个子单元内beat顺序固定,且两个BL24子单元之间的先后关系也总是第一段在前,第二段在后。也是和Read burst一样,是有速率门槛,当速率不高于6400Mbps时,两个子单元之间gapless,没有interleaved,当速度大于6400Mbps时,两个子单元之间必须插入一个24beat的gap,这个gap可以是空闲idle/保留周期,或者用于插入其他访问/链路层必要控制,或者跟Read burst一样,也可以是其他BG的事务(但需注意,同一条64B命令内部不能换BG,但是规范允许的interleave前提下,gap是可以插入其他BG的事务)。

2.4.5 Burst Sequence

这一节直接用三张图,给出读/写BL48时48个beat的顺序,以及每个beat每个DQ的内容。

这里细心的小伙伴发现,正如我们前面说明的,在read时(前两张图),通过C0=0或者1,来决定两个子单元在总线上出现的顺序与映射。C是column bit,C0=0表示起始列地址的最低位等于0,也就是偶数列起点,器件会先输出“前半个子单元”,即beat0开始;C0=1表示起始列地址的最低位为1,也就是奇数列起点,器件会先输出“后半个子单元”,即beat24开始。而Write却没有这个顺序的选择,而是固定下来的,因为前面规定明确“fixed write burst sequence”,也就是同一条写命令的两个子单元顺序固定(先第一个,再第二个),不因C0的奇偶而交换顺序。

至此,第二章Overview终于结束,即将进入第三章WCK Clocking,努力本周三先开个头~。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/8/25 14:49:02

揭秘EF Core索引设计陷阱:90%开发者都忽略的3个关键点

第一章:揭秘EF Core索引设计的核心意义在现代数据驱动的应用程序中,数据库查询性能直接影响用户体验与系统吞吐量。Entity Framework Core(EF Core)作为.NET平台主流的ORM框架,提供了对数据库索引的声明式支持&#xf…

作者头像 李华
网站建设 2026/8/24 21:25:23

揭秘GraphQL性能瓶颈:如何在PHP中强制实施查询复杂度控制

第一章:揭秘GraphQL性能瓶颈:如何在PHP中强制实施查询复杂度控制GraphQL 赋予客户端灵活查询数据的能力,但也带来了潜在的性能风险。深层嵌套或大规模字段请求可能导致服务器资源耗尽,形成 N1 查询问题甚至服务拒绝攻击。为避免此…

作者头像 李华
网站建设 2026/8/25 13:14:54

【协程池优化必看】:精准控制纤维协程并发数的5种高级技巧

第一章:协程池优化的核心挑战在高并发系统中,协程池作为资源调度的关键组件,其性能直接影响整体系统的吞吐能力与响应延迟。然而,在实际应用中,协程池的优化面临多个核心挑战,涉及资源管理、调度策略以及异…

作者头像 李华
网站建设 2026/8/25 9:15:25

为什么你的低代码PHP组件总是更新出错?真相令人震惊

第一章:低代码 PHP 组件的更新机制在现代Web开发中,低代码平台通过封装常用功能模块,显著提升了PHP应用的开发效率。其中,组件的更新机制是保障系统稳定与功能迭代的关键环节。这类机制通常依赖版本控制、自动检测和热更新策略&am…

作者头像 李华
网站建设 2026/8/25 20:55:12

从 “能对话” 到 “能执行”,ZGI 工作流如何让 AI 落地业务闭环

对开发者而言,搭建企业级 AI 业务流程时,最头疼的莫过于跨系统集成的繁琐、业务逻辑的复杂迭代,以及 AI 无法从 “输出分析” 转向 “主动执行” 的局限 —— 比如制造业需对接 IoT、ERP、MES 多系统实现生产调度,金融行业要串联合…

作者头像 李华
网站建设 2026/8/25 21:44:35

农业物联网设备认证失败率下降90%的秘密:PHP服务端优化全揭秘

第一章:农业物联网设备认证的挑战与PHP解决方案在现代农业中,物联网(IoT)设备被广泛用于监测土壤湿度、气候条件和作物生长状态。然而,这些设备的安全认证面临严峻挑战,包括设备身份伪造、通信劫持和数据篡…

作者头像 李华