做5G LDPC开发，有一个参数肯定绕不开：提升因子Z。
它决定了那张小小的基图矩阵，怎么“扩展”成为真正用来编码的校验矩阵；也直接关系到译码器能跑多快、占多少资源。
但协议里给了51个可选值，到底怎么挑？本期我们就来探讨这个问题。
5G的LDPC码有个巧妙的设计：先定义一张很小的基图矩阵，里面只有0和1。然后，把每一个“1”替换成一个Z×Z 的置换方阵，把每一个“0”替换成一个Z×Z 的全零方阵。这个Z，就是提升因子。
可以把它理解成一张图纸的放大倍数。基图是那张小图纸，Z是放大倍数，扩展之后得到的才是编码所用的校验矩阵。
可以说：基图决定了码的拓扑结构，而Z决定了单个码块最多承载多少信息比特；最终编码码长也由基图校验列与Z共同决定。
当然，Z也不是随便取的。协议规定它必须是一组特定数值集合中的一个，最大到384。
那么Z究竟要如何选择呢？
在选择Z之前，需要先等一等：
Z的选择并不是孤立的，而是跟一个更基础的决定绑在一起——用哪张基图。
大家都知道，5G定义了两张基图，BG1和BG2。BG1适合大块数据、高码率场景；BG2适合小块数据、低码率场景。
所以，我们需要先根据业务需求把基图选定，这时，Z的选择才有依据。
基图定下来，对应的信息列也就明确了：BG1固定是22列信息列；BG2原生为10个信息列（可根据目标码率做基图列截断，信息列可选6、8、9、10）。这个信息列数量，就是计算Z的起点。
而Z的计算逻辑其实也很简单：对于待传输数据，需要选定Z，使得：
打个比方：
现在有一块数据，长度是6,168个比特；
基图选了BG1，有22个信息列；
那么每个信息列需要承载的比特数就是6168÷22，约等于280.4；
协议Z表里大于该值的最小合法Z是288；
所以这块数据对应的提升因子就是Z=288。
注：通常码块信息比特包含码块CRC比特，示例为简化示例，未计入CRC。
这里有个细节要留意：Z确定之后，
码块可承载信息比特总数＝信息列数×Z
而不是原本的数据长度。
比如22×288＝6336，比6168多了168个比特。这168个比特位置填充填充比特，不携带业务信息，在编码后会被移除，不参与传输。
所以选Z的时候，不能只看“容量够不够”，还得看填充比特带来的开销。
第一件事，要跑多快
Z越大，译码器并行处理粒度就会越大，吞吐量上限也就越高（Z做并行架构时）。
但代价是硬件资源随之增加：Z从64增加到384，Z扩大6倍，校验矩阵行列维度同步放大6倍，存储和计算单元开销会显著上涨。
也就是说：高吞吐场景Z值可以选大一点；而面积、功耗较为敏感的场景，就需要谨慎控制Z的大小了。
第二件事，浪费了多少
前面提到，算出的Z往往会让可承载比特大于原始数据长度，多出部分填充比特。
但填充比特越多，有效编码效率也就越低。所以在可选范围内，优先选填充量最小的Z。
第三件事，硬件实现与调度权衡
同一张基图下，Z本身不会改变LDPC码理论译码收敛特性。而工程上不同Z观测到的性能差异大多来自硬件实现、填充比特带来的有效码率变化。
在工程中，一般来说在满足数据长度前提下，也都会优先选择填充开销最小的Z。
Z这个参数，看起来只是协议表里的一个数字，但它实际上是连接基图设计与硬件实现的一座桥梁。
它向上决定了基图能“扩展”出多长的码块，影响系统支持的速率；向下决定了译码器里有多少节点可以并行工作，直接影响硬件能跑多快、占多大面积。
也只有将它和基图选择、硬件规划放在一起考虑，整套方案才能在目标平台上跑出更好的效率。
