单片机萌新我们去年集创赛做的就是这个方向，用的也是Artix-7。核心矛盾就是多项式运算和片上存储。我们的思路是彻底拥抱“串行化”，别想着一个时钟周期算很多点。把NTT/INTT模块做成高度可复用的单一计算单元，比如一个蝶形运算器，通过状态机控制，循环处理所有点。这样DSP用量能压到个位数。BRAM是大头，用来存多项式系数，但Artix-7的BRAM块不多，所以内存访问模式必须精心设计。我们采用“乒乓操作”加系数重排，让蝶形运算单元读取的数据尽量连续，减少随机访问，这样能有效隐藏访问延迟，提高单元利用率。测试向量可以用官方提供的Known Answer Tests (KAT)，用软硬件协同验证，先在电脑上用C语言参考代码算一遍结果，再把输入灌给FPGA，比较输出。抗侧信道是另一个维度，最简单的可以从固定时间算法入手，避免条件分支和索引依赖，但这会额外增加面积和周期，初赛可能不强制，但进决赛的话这是亮点。
平衡的关键在于‘分层优化’和‘精准评估’。不要一上来就抠RTL代码，先做高层次建模和资源预估。第一步，用C/C++或Python实现一个位准确的Kyber软件模型，这是你的黄金参考。第二步，基于这个模型，分析计算热点和内存访问模式。你会发现NTT和点乘是核心。架构上，建议采用‘混合并行度’设计。对于最内层的模乘模加，可以用少量高度优化的DSP流水线（比如2-4个），外层通过循环展开和迭代来控制吞吐量。这样既不是完全串行（太慢），也不是完全并行（面积爆炸）。BRAM优化有个技巧：Kyber的多项式系数是12位或13位，而Artix-7的BRAM是18Kb，位宽可配。你可以将多个系数打包进一个BRAM字宽里，比如一个18Kb BRAM配置成1024深 x 18位宽，可以存两个1024长度的12位系数数组，通过适当的地址映射和数据选择逻辑来存取，能大幅提升BRAM利用率。验证方面，除了KAT，一定要做随机大量测试，覆盖边界情况。抗侧信道评估对本科生比赛可能要求过高，但可以提一下未来工作方向，比如恒定时间实现（避免条件分支）、盲化技术等，这会是加分项。
我们去年集创赛做的就是Kyber在Artix-7上的实现，资源平衡是最大的挑战。核心思路就是‘串行化’和‘复用’。NTT模块是资源消耗大户，我们没做全流水线的并行NTT，而是设计了一个可配置的蝶形运算单元，通过状态机控制，分多个时钟周期完成一个完整的NTT变换。这样DSP用量能减少70%以上，用逻辑资源和时钟周期去换。BRAM主要存多项式系数，我们仔细计算了每个步骤所需的最大存储深度，将一些临时存储用分布式RAM（LUTRAM）实现，进一步节省BRAM。关键优化点：1. 将Kyber的K-PKE和KEM流程分解，共用同一个NTT/INTT核心模块，通过顶层状态机调度。2. 内存访问模式优化，确保蝶形运算单元读取系数的地址是规律且连续的，减少控制复杂度。3. 模乘和模加运算，能用查找表预计算的就用查找表（比如Barrett约减的常数），减少实时计算量。测试向量可以用官方提供的Known Answer Tests (KAT)，用软硬件协同验证，在PC上用Python或C生成输入和期望输出，通过UART发给FPGA，再比对结果。抗侧信道是另一个维度，如果时间充裕可以加一些简单的防护，比如操作时序随机化，但会额外增加资源。
分享几点实际踩坑经验。第一，别一上来就搞全模块集成，先逐个攻破小模块（如模乘、模加、NTT蝶形单元），每个模块单独仿真并和软件模型（如用C或Python写的参考代码）对比结果。第二，资源评估要尽早，综合后看DSP和BRAM用量，如果超了，优先把耗DSP多的运算（比如模乘）改成用LUT和寄存器实现的查找表或串行方法。第三，内存访问优化太重要了。我们当时把多项式系数按位交错存储，配合流水线访问，提升了吞吐率。第四，测试向量不仅要功能对，还要测性能。用ChipScope或ILA抓取实际运行周期数，和理论值对比。抗侧信道如果没基础可以先不做，但答辩时可能会被问到，至少要知道常见攻击类型和基础防护思路，比如平衡功耗的伪操作插入。最后，建议选Kyber-512或768，别碰1024，资源肯定不够。
平衡复杂性和资源，你得从算法层面下手。Kyber的多项式运算在环R_q上，q=3329，不是2的幂，直接做NTT需要预处理将q扩展为支持NTT的模数，这会增加复杂度。一个优化点是采用修改的NTT算法，比如使用Montgomery模乘和Barrett约减，在FPGA上高效实现。另外，矩阵向量乘法中的点乘可以分解，复用同一个乘法器。架构上，考虑模块的时分复用，比如加解密和密钥生成共享NTT模块。内存访问优化关键：将频繁访问的数据放在分布式RAM中，减少BRAM消耗。测试验证，除了标准测试向量，一定要做随机化测试，用软硬件协同验证，确保边界情况（如零值、最大值）也正确处理。抗侧信道是加分项，但集创赛时间紧，建议重点关注能量分析（DPA）的简单防护，比如操作数随机化掩码，但注意掩码本身也会消耗资源。
我们去年做过类似题目，用Artix-7实现了Kyber-768。核心思路就是串行化+复用。NTT模块是资源大头，我们只实例化了一个蝶形运算单元，通过状态机控制完成整个NTT/INTT。虽然速度慢了，但节省了大量DSP。BRAM主要存多项式系数，我们用了双端口RAM并精心安排访问顺序，避免冲突。测试向量可以用官方提供的CAVP测试集，用Python脚本转成coe文件初始化BRAM。侧信道的话，时间有限，我们只做了简单的时间恒定化处理，比如模乘运算不管操作数是否为零都执行相同周期。建议你们先保证功能正确，再考虑抗攻击。
平衡复杂度和资源，我觉得得从算法和硬件协同设计入手。Kyber的运算本质是在多项式环上，硬件架构要围绕这个来设计。几个关键点：第一，模乘和模加是基础，可以用基于DSP48的流水线设计，但要注意控制流水线深度和频率的平衡。第二，内存访问优化至关重要。多项式系数存储尽量用双端口BRAM，并设计成可以同时读取操作数对（比如NTT的蝶形操作所需的一对系数），这能极大提升数据吞吐。第三，模块复用。NTT和INTT的硬件结构高度相似，完全可以复用同一个计算单元，通过控制逻辑来切换模式。验证方面，除了标准测试向量，一定要做大量的随机测试，并和软件参考模型（比如PQClean里的C实现）进行比对。抗侧信道是加分项，如果时间紧，可以先实现基础功能，再考虑加入简单的掩码或隐藏技术。
我们去年集创赛做的就是Kyber的FPGA实现，用的也是Artix-7。核心痛点确实是BRAM和DSP不够用。我们的思路是彻底拥抱“串行化”，把NTT这个最耗资源的模块做成高度复用的单蝶形单元。别想着一个时钟周期算完整个多项式，那不现实。用一个蝶形单元，配合一个深度优化的乒乓RAM调度，把多项式系数一点点喂进去算。这样DSP用量能压到个位数，BRAM也主要用来做系数存储和转置，而不是存中间结果。关键优化点在于RAM的访问模式要和NTT的蝶形图完美匹配，避免冲突，这需要精心设计地址生成器。测试的话，NIST有官方测试向量，一定要跑通。侧信道我们当时没做，但建议你们至少做一下简单功耗分析（SPA）的评估，看看关键操作（比如采样、解密）的功耗轨迹有没有明显泄露。
