1. 项目概述为低端嵌入式设备量身打造的后量子签名加速方案在物联网设备、工业控制器这些资源捉襟见肘的低端嵌入式系统里搞安全一直是个让人头疼的难题。传统的RSA、ECC数字签名算法虽然在过去几十年里撑起了互联网安全的半边天但量子计算的阴影已经笼罩下来——这些基于大数分解或椭圆曲线离散对数问题的算法在量子计算机面前变得不堪一击。这就是为什么全球的密码学家和工程师们都在紧锣密鼓地推进后量子密码学PQC的标准化和落地。在NIST美国国家标准与技术研究院这场“后量子密码选秀”中FALCON算法脱颖而出成为了最终的标准签名算法之一。它最大的魅力在于在同等安全级别下它能产生最小的“公钥签名”数据包。这对于通信带宽和存储空间都极其宝贵的嵌入式设备来说简直是天降福音。想象一下成千上万的传感器节点每次通信都能少传几百甚至上千字节省下的电量和带宽是实实在在的。但FALCON有个“甜蜜的负担”它严重依赖双精度浮点运算。这对于没有硬件浮点单元FPU的廉价微控制器MCU来说简直是性能灾难。软件模拟浮点运算慢得令人发指直接让实时签名生成变成了奢望。因此为FALCON设计专用的硬件加速器成了让它能在嵌入式世界扎根的关键。然而给FALCON做硬件加速路子不能照搬其他算法。我们团队在深入剖析FALCON的签名生成流程后发现它不像DilithiumNTT运算占大头或SPHINCS哈希运算占大头那样存在一个绝对的、耗时占比超过60%的性能瓶颈函数。FALCON的耗时相对均匀地分布在FFT/IFFT、SamplerZ和Split/Merge/LDL等几个核心函数上。这意味着如果你只给其中一个函数做豪华的硬件加速整体性能提升会非常有限因为其他函数还是慢吞吞的软件执行成了新的瓶颈。这就引出了我们这项工作的核心挑战与目标如何在极其有限的芯片面积对于成本敏感的低端嵌入式设备面积就是金钱内对FALCON进行全面的、高效的硬件加速传统的“抓大放小”的函数级软硬件协同设计思路在这里失效了。我们必须另辟蹊径从更细的粒度去思考优化这就是我们提出“EFX”加速器及其背后“操作级协同设计”理念的由来。2. 核心设计思路从“函数级”到“操作级”的范式转变2.1 传统方法的困境与FALCON的特性分析在硬件加速领域一个经典的设计哲学是“二八定律”找到那个消耗80%时间的20%代码然后用硬件猛攻它。这种方法对于存在明显热点Hotspot的算法非常有效。工程师们可以集中火力用并行计算、深度流水线、定制数据通路等手段把这个热点函数的性能提升几个数量级从而带动整体性能飞跃。但FALCON打破了这一规律。我们对运行在Cortex-M4一款广泛用于嵌入式领域的中端ARM处理器上的FALCON参考实现进行了精细的性能剖析Profiling得到了一个反直觉的结果FFT/IFFT运算约占26%的执行时间。SamplerZ采样器约占24%的执行时间。Split/Merge/LDL矩阵分解等函数合计约占28%的执行时间。可以看到没有任何一个单一函数消耗超过30%的时间。三个主要部分的耗时比例相当。如果你只把FFT/IFFT用硬件加速到极致理论上整体加速比上限也只有不到1.4倍根据阿姆达尔定律。这显然不符合我们对一个专用硬件加速器的性能期待。更棘手的是FALCON的这些函数内部充斥着大量的双精度浮点运算加、减、乘、除和数据类型转换浮点数与整数之间。在硬件上实现一个高吞吐率的双精度浮点运算单元FPU本身就会占用可观的芯片面积。如果为上述三个主要函数分别设计三个独立的、包含完整FPU的硬件模块那么总面积开销将变得难以承受完全背离了为“低端嵌入式系统”设计的初衷。2.2 操作级协同设计Operation-Level Co-Design的提出既然在函数级别找不到一个“银弹”我们就把目光投向更微观的层面操作Operation。这里说的操作是指最基本的计算单元比如一次双精度浮点加法FP_ADD、一次双精度浮点乘法FP_MUL、一次浮点到整数的转换Type_Converter等等。我们重新审视了FFT/IFFT、SamplerZ、Split/Merge/LDL等所有耗时函数发现了一个关键现象尽管这些函数的高层算法逻辑各不相同但它们底层依赖的核心计算操作是高度重合的。经过统计以下四种操作占据了整个FALCON签名生成过程约90%的计算时间类型转换Type_Converter在浮点数和定点整数表示之间切换。浮点加法FP_ADD。浮点乘法FP_MUL。浮点除法FP_DIV。我们将这组被多个函数高频调用的基础操作块定义为“公共操作块”Common Operation Blocks, COBs。我们的设计思路随之发生了根本性转变不再以“函数”为单位进行软硬件划分而是以“操作”为单位。我们将所有函数拆解把其中包含的COB操作剥离出来交由一个统一的、高度优化的硬件模块——公共计算单元Common Computing Unit, CCU——来执行。而函数中那些非COB的、控制逻辑复杂或顺序性强的部分则仍然留在软件运行在主处理器Cortex-M4上中完成。这样做带来了两大核心优势面积效率极大提升我们只需要实现一套FP_ADD、FP_MUL、FP_DIV和Type_Converter硬件电路。无论FFT、SamplerZ还是LDL分解需要做浮点运算都来调用这同一套硬件资源。这避免了为每个函数复制FPU逻辑实现了硬件资源的极致复用显著降低了总面积。性能提升潜力全面覆盖由于COB操作覆盖了90%的计算时间加速它们就相当于加速了整个算法的绝大部分。只要CCU的设计足够高效我们就能获得接近理论上限的整体性能提升。这个“操作级协同设计”是EFX架构的灵魂它使得在有限面积内对FALCON进行近乎全域加速成为可能。2.3 针对SamplerZ函数的特殊优化策略在COB的全局优化之外SamplerZ函数因其特殊性获得了我们额外的关注。它在算法上本质是一个拒绝采样过程内部包含大量的条件判断和循环顺序性很强并非所有部分都适合或容易用硬件实现。我们的策略是软硬件流水线并行。具体来说SamplerZ中耗时的COB操作如计算拒绝概率所需的浮点乘法和指数近似计算被剥离到硬件CCU中加速。同时该函数需要大量的随机数用于高斯采样和均匀采样。我们让软件提前在后台异步地生成这些随机数并填充到一个共享的硬件缓冲区PQC RAM中。这样硬件CCU在执行当前采样所需的COB计算时软件可以同时为下一次采样准备随机数。两者并行工作消除了软件生成随机数带来的等待延迟。此外我们还设计硬件能够同时测试多组例如4组预生成的随机数候选对只要其中任何一组通过测试就立即输出结果这进一步降低了因采样失败需要重试而导致的平均延迟。注意这种软硬件并行设计需要精心设计同步机制。我们通过一组控制状态寄存器如STATUS_REG和RANDOM_REG来协调软件和硬件。硬件通过STATUS_REG告知软件采样状态成功/失败/随机数不足软件据此决定是继续生成随机数还是进行下一步操作确保了数据的一致性和流程的正确性。3. EFX硬件架构深度解析3.1 整体系统架构与数据流EFX作为一个硬件加速IP通过标准的AHB总线与主处理器Cortex-M4连接。其顶层架构可以清晰地分为控制流和数据流两部分。控制流始于主机处理器。当软件需要执行一个已硬件加速的函数或其中的COB部分时它会通过写入FUNC_CTRL_REG控制寄存器来配置EFX指定要执行的操作类型如FFT、采样等和多项式维度512或1024。同时通过START_ADDR_REG告诉EFX输入数据在共享PQC RAM中的起始地址。指令解码器Instruction Decoder解析这些命令并将其传递给函数单元Function Unit, FU。函数单元FU是EFX的“大脑”。它不是一个执行计算的单位而是一个精细的调度器。FU内部为每个支持的函数见表3FFT, IFFT, Split, Merge, LDL, SamplerZ的核心计算等维护一个有限状态机FSM。当收到执行某个函数的命令后相应的FSM被激活。这个FSM的工作是将该函数的算法流程分解成一系列对底层硬件资源的微操作Micro-ops。数据流则围绕公共计算单元CCU、通用目的寄存器GPR和PQC RAM展开。PQC RAM是一个单端口SRAM作为EFX内部的专用数据缓冲区存储输入多项式、中间结果和最终输出。GPR是一组快速的寄存器文件用于存储CCU计算过程中急需的临时变量减少对低速RAM的访问。我们的分析表明12个64位寄存器足以满足所有COB操作并行时的数据暂存需求。FU生成的微操作命令最终会调度CCU中的具体计算单元如FP_ADD模块从GPR或PQC RAM中读取操作数执行计算并将结果写回。所有计算完成后EFX向主机发出中断信号通知任务完成。3.2 公共计算单元CCU的匠心设计CCU是EFX性能的核心它集成了那四个关键的COB硬件模块。我们的设计原则是为高频操作设计深度流水线以实现高吞吐为低频但必要的操作设计紧凑的非流水线电路以节省面积。浮点加法器FP_ADD与乘法器FP_MUL这两种操作在FFT、多项式乘法等核心计算中无处不在调用极其频繁。我们为它们分别设计了2级和5级流水线。采用流水线意味着每个时钟周期都可以吃进一组新的操作数尽管从输入到输出有延迟Latency但吞吐率Throughput可以达到每个周期完成一次运算这对于计算密集型的FFT蝴蝶操作至关重要。浮点除法器FP_DIV与加法和乘法相比除法在FALCON中仅出现在少数特定步骤如标准化计算调用频率很低。实现一个全流水线的除法器硬件开销巨大。因此我们选择了一个非流水线、迭代式的设计。它基于经典的“减法并移位”算法通过复用3个53位有符号减法器经过55次迭代在19个周期内完成一次双精度除法。虽然延迟高但由于调用少对整体性能影响微乎其微却节省了大量的芯片面积。类型转换器Type_Converter这个模块处理定点整数与IEEE 754双精度浮点数之间的转换。浮点转整数FP-to-INT涉及根据指数移位尾数、以及舍入round、截断trunc、向下取整floor等操作。我们设计了一个可复用的核心移位与处理部件针对不同的转换模式进行配置。对于需要舍入的操作额外增加一个63位加法器部件形成一个2级流水。而截断和向下取整则可以在单周期内完成。整数转浮点INT-to-FP则是一个标准的2级流水过程规格化-舍入。实操心得FPU设计中的面积-性能权衡在设计CCU时最大的权衡在于浮点除法器。一个全流水线的双精度除法器面积可能是加法器的10倍以上。我们通过详细的性能剖析Profiling确认除法操作在总周期中占比不足0.5%因此果断选择了面积优先的迭代设计。这种基于真实数据驱动决策的方法是嵌入式硬件设计避免过度设计Over-engineering的关键。3.3 函数单元FU的智能调度FU的卓越之处在于它如何将高级函数映射到低级的COB操作和内存访问上并最大化硬件利用率。多项式常规运算对于系数的逐点加、减、类型转换FU采用简单的顺序调度。它依次从PQC RAM中读取一对系数送入CCU的相应端口等待结果再写回。虽然简单但通过CCU的流水线依然能保持较高的计算吞吐。多项式乘法这是最复杂的操作因为每个输出系数都是所有输入系数两两相乘再累加的结果存在大量的数据重用和中间累加。FU为此设计了专门的调度逻辑。如图5所示它采用了一种“滑动窗口”式的流水线调度。FU会预取多组操作数让FP_MUL流水线持续充满。FP_MUL的结果源源不断地送入FP_ADD流水线进行累加。通过精心安排数据加载的顺序和计算时序FU确保了FP_MUL和FP_ADD这两个流水线单元以及内存总线几乎始终处于忙碌状态消除了空闲气泡Bubble实现了计算资源的饱和利用。FFT/IFFT运算我们采用了经典的Cooley-TukeyFFT和Gentleman-SandeIFFT算法。FU将每一级的蝴蝶Butterfly操作分解为对CCU的FP_ADD和FP_MUL的调用序列。更重要的是我们观察到FFT的合并merge阶段和IFFT的分裂split阶段其数据流与蝴蝶操作的第一级高度相似。因此FU将poly_merge_fft和poly_split_fft函数的计算与FFT/IFFT的第一级蝴蝶操作融合在了同一个硬件逻辑里。通过一个专门的内存地址生成模块对FP_ADD的输出进行复用我们避免了为这两个单独函数设计额外硬件进一步节约了面积。4. 实现细节、性能评估与对比分析4.1 实验平台与评估方法为了客观评估EFX的性能与效率我们建立了一套完整的评估体系软件基线SWB在意法半导体的STM32F407VG开发板基于168 MHz的Cortex-M4内核上运行NIST官方提交的FALCON优化代码。该平台被NIST推荐为PQC算法的标准评估环境。我们使用ARM CoreSight中的DWT数据观察点与跟踪单元来精确测量时钟周期数。硬件实现使用Verilog HDL编写EFX的RTL代码分别采用三星的28nm和45nm工艺库在300MHz的目标频率下进行逻辑综合以评估其面积和功耗。我们使用周期精确的模拟器来估算EFX加速下的性能。对比对象我们与纯软件优化方案如Kannwischer等人的pqm4项目、以及学术界最新的FALCON专用硬件加速研究如Karabulut和Aysu的软硬件协同设计工作进行对比。4.2 性能结果分析表5和表6的对比数据清晰地展示了EFX的威力相对于纯软件基线SWBEFX在FALCON-512和FALCON-1024参数下分别实现了305.8倍至1093.7倍和309倍至1096.9倍的加速。这个巨大的提升主要归功于两个因素一是硬件CCU对双精度浮点运算的极致加速相比软件模拟二是我们的操作级优化覆盖了90%的计算热点。相对于其他硬件加速工作与同样针对Cortex-M4平台的纯软件汇编优化版本相比EFX将时钟周期数减少了5.78倍FALCON-512到9.7倍FALCON-1024。与目前已知的唯一一个完成完整FALCON签名生成的软硬件协同设计加速器相比EFX在FALCON-1024上减少了3.58倍的时钟周期。这充分证明我们的“操作级协同设计”策略在性能上显著优于传统的、仅加速SamplerZ等单个函数的“函数级协同设计”方法。EFX通过对算法计算本质的深度解构实现了更全面的加速。4.3 面积与功耗效率面积是嵌入式硬件设计的生命线。表7展示了EFX与同类PQC硬件加速器研究的面积对比。面积在28nm工艺下EFX核心面积仅为38K平方微米µm²在45nm工艺下为74K µm²。这个面积远小于许多其他仅加速部分功能的PQC硬件模块甚至与一些只做签名验证的加速器相当。这得益于我们极致的硬件复用CCU和针对低频操作如除法器的紧凑型设计。功耗在300MHz频率下EFX的功耗与同类DSA数字签名算法加速器处于同一水平或更低。考虑到签名生成的计算复杂度远高于验证在Cortex-M4上高150-160倍EFX在完成如此复杂任务时能保持这样的功耗水平体现了其优秀的能效比。注意事项工艺与频率的选择我们选择28nm/45nm工艺和300MHz频率是面向主流低端嵌入式芯片的典型配置。在实际流片中可以根据性能-功耗-成本需求进行缩放。在更先进的工艺如22nm下面积会进一步缩小或在同等面积下达到更高频率。但需注意更先进的工艺可能带来更高的静态漏电功耗需要系统级权衡。4.4 软硬件接口与系统集成EFX通过一组精确定义的寄存器与主机软件交互这使得它能够像一个协处理器一样被灵活调用FUNC_CTRL_REG功能控制寄存器。软件在此写入命令字指示EFX执行何种操作如FFT_512,SAMPLERZ_CORE等。START_ADDR_REG起始地址寄存器。指向PQC RAM中输入数据的地址。RANDOM_REGSTATUS_REG专门为SamplerZ的软硬件并行设计的同步寄存器。RANDOM_REG指示缓冲区中可用的随机数数量STATUS_REG反馈采样状态成功、失败、需要更多随机数。软件驱动的流程大致如下主机软件将待处理的多项式数据通过DMA或内存映射方式写入EFX内部的PQC RAM。软件配置START_ADDR_REG和FUNC_CTRL_REG启动EFX。EFX开始工作FU进行调度CCU执行计算。对于SamplerZ软件在EFX计算的同时并行运行随机数生成器填充缓冲区并监控RANDOM_REG。EFX完成计算后触发中断。软件读取状态并从PQC RAM指定位置取出结果。这种设计使得EFX可以相对容易地集成到现有的嵌入式SoC中作为安全子系统的一个IP核通过总线与主CPU协同工作。5. 总结与展望回顾整个EFX的设计过程其成功的关键在于跳出了“加速函数”的传统思维定式深入到“加速操作”的层面。通过识别并硬件实现跨函数的公共计算块COB我们用一个相对小巧的公共计算单元CCU撬动了FALCON算法90%的计算负载实现了面积与性能的绝佳平衡。针对SamplerZ的软硬件流水线并行优化则是解决顺序性算法瓶颈的一个经典案例通过提前计算和并行测试有效隐藏了软件随机数生成的延迟。这项工作表明对于像FALCON这样计算负载相对均衡的后量子密码算法细粒度的、基于操作分析的软硬件协同设计比粗粒度的函数级划分更为有效。EFX的设计方法论可以扩展到其他具有类似特性的复杂算法上特别是在资源受限的嵌入式领域。从工程实践的角度来看有几点经验值得分享 第一** profiling性能剖析必须贯穿始终**。正是最初细致的profiling数据揭示了FALCON没有单一热点的特性才催生了操作级优化的思路。在硬件架构确定后持续的周期级模拟和性能分析又帮助我们优化了FU的调度策略消除了流水线停顿。 第二硬件设计必须服务于算法特征。双精度浮点是FALCON的性能瓶颈也是面积瓶颈。我们的CCU设计没有追求一个“全能”但庞大的FPU而是根据操作频率差异化设计高频操作流水线化低频操作面积最小化。这种“看菜下饭”的务实态度是嵌入式硬件设计的精髓。 第三软硬件边界需要创造性划分。SamplerZ的优化完美体现了这一点。不是简单地把整个函数扔给硬件而是让软件做它擅长的生成随机数、控制流让硬件做它高效的密集浮点计算并通过巧妙的同步机制让两者重叠工作从而获得一加一大于二的效果。随着NIST后量子密码标准化的最终落地像FALCON这样的算法将逐步从实验室走向亿万物联网设备。EFX及其背后所代表的设计哲学为在这些资源受限的设备上实现高安全、高效率的后量子密码保护提供了一个切实可行的硬件蓝图。未来的工作可以探索将CCU进一步扩展以支持其他也依赖浮点运算的格密码算法或者研究在更极端的工艺节点如55nm甚至90nm下的低成本实现以覆盖对成本更为敏感的大规模部署场景。