2026年，全国大学生集成电路创新创业大赛，做‘基于开源RISC-V核与FPGA的SoC安全扩展’这类题目，团队应如何分工，并实现诸如物理不可克隆函数（PUF）、真随机数发生器（TRNG）等硬件安全模块？

分工基本合理，但建议微调。三人团队：一人主攻CPU核集成、总线互联和系统集成（软硬件接口要清晰）；一人专攻安全模块硬件设计（PUF/TRNG/密码学加速器的RTL实现与优化）；一人负责软件驱动、系统测试与协同验证（包括裸机程序、安全用例）。关键是要定期联调，硬件设计者需为软件提供清晰的寄存器映射文档，软件人员尽早写测试代码验证硬件功能。

对于FPGA上实现PUF和TRNG，虽然FPGA是数字平台，但可以利用其固有的物理差异。PUF常用基于SRAM上电状态的SRAM PUF，或者利用查找表（LUT）的环路振荡器PUF，通过测量路径延迟差异生成指纹。TRNG可利用环形振荡器的抖动或亚稳态作为熵源。重点在于后处理，比如用哈希或提取器提升随机性质量。验证时，需在FPGA上多次上电测试PUF的稳定性和唯一性，用NIST测试套件评估TRNG的随机性。

软硬件协同验证的关键：1. 先搭建最小可运行系统（CPU+总线+内存），确保软件能跑起来。2. 为每个安全模块设计简单的内存映射寄存器，软件通过读写寄存器控制并获取数据。3. 使用统一的仿真环境（如Verilator+软件）进行早期功能验证。4. 在FPGA原型上，从单元测试到系统测试逐步集成，用C代码测试安全模块的实际功能。注意记录测试用例和覆盖率。

你们的分工模式是经典的三人组，很合理。我补充一点：负责安全模块硬件设计的同学任务最重，因为PUF和TRNG在数字FPGA上实现需要一些技巧。

对于PUF，建议实现基于环形振荡器（RO）的PUF，利用FPGA内部LUT和布线延迟的细微差异。设计多个RO对，比较它们的频率，生成1位响应。关键在于布局约束，要确保RO对布局靠近，以减少环境噪声影响。还需要设计校准机制，因为温度电压变化会影响频率。

TRNG的实现，可以用多个环形振荡器异或，利用其抖动作为熵源。或者用亚稳态电路，但设计更复杂。一定要做后处理，比如用冯·诺依曼校正器或简单的CRC，确保输出符合随机性标准。

软硬件协同方面，一定一定要尽早开始联合调试。硬件设计的同时，软件同学就可以根据规划好的寄存器地址，编写基础驱动函数。上板后，先测试每个模块的独立功能，再测试集成后的系统。验证关键点包括：安全模块的寄存器访问是否正确、中断是否能正常触发和处理、数据通路是否畅通。建议用串口打印调试信息，比较直观。

另外，别忘了考虑性能评估，比如TRNG的生成速度、PUF的响应时间，这些可能是比赛的加分项。

分工基本合理，但建议动态调整。三人分别负责CPU/总线、安全硬件、软件驱动，覆盖了主要环节。但实际开发中，模块间耦合度高，比如PUF/TRNG需要软硬件协同验证，负责安全硬件的同学必须和写驱动的同学紧密沟通，甚至一起调试。建议每周固定时间联调，而不是完全各干各的。另外，CPU核集成的人也需要了解总线如何安全扩展（比如加入访问控制），不能只关注连通性。

关于PUF和TRNG在FPGA上的实现，这是个经典难题。纯数字FPGA缺乏模拟特性，但可以利用其固有的工艺偏差和布线延迟。对于PUF，可以尝试基于查找表（LUT）的环形振荡器PUF或仲裁器PUF。关键是要利用FPGA上布线的不对称性来产生芯片指纹。你需要写脚本在不同位置实例化大量相同的路径，测量频率或延迟差异。验证时，需要在同一块板卡上多次上电测试稳定性，还要在不同温度下测试可靠性。

对于TRNG，可以利用FPGA的亚稳态现象，比如用多个环形振荡器采样，或者用时钟抖动。但要注意，赛用FPGA环境相对理想，产生的随机性需要严格测试（比如NIST测试套件）。建议前期集中精力找到一个在你们板卡上可重复实现的稳定方案，不要追求最复杂的方案。

软硬件协同验证的关键点：1. 尽早建立统一的仿真环境，比如用Verilator+软件一起跑，验证硬件模块的寄存器访问是否正确。2. 为每个硬件安全模块设计简单的裸机驱动测试用例，比如读取TRNG数值并统计，验证PUF响应。3. 注意安全模块的地址映射、中断信号对接，这些容易出错。4. 系统集成后，跑一些小型安全应用（比如密钥生成、加密）来验证端到端功能。

你们的分工模式是经典的三人小组打法，没问题。我补充几个实操细节。

第一，负责CPU和总线的同学，任务很重。除了集成蜂鸟E203，更要设计好安全模块的互联架构。比如，PUF和TRNG这类模块，是作为外挂APB设备，还是直接紧耦合？建议先用简单总线（如APB）挂上，降低初期复杂度。但要注意，这些模块产生的密钥或随机数，如何安全地传递给密码加速器？可能需要设计一个受保护的数据通路，避免被总线嗅探。这个需要和安全硬件同学商量。

第二，安全硬件同学，如果之前没做过PUF/TRNG，建议直接从开源项目入手，比如OpenTitan或PUFsec里的相关IP。但一定要理解原理，因为你要针对FPGA做适配和优化。在FPGA上做PUF，重点不是设计RTL，而是布局布线约束。你需要用Xilinx或Intel的约束文件，把关键路径固定下来，确保每次编译产生的偏差是一致的。这是个体力活，需要反复编译测试。

TRNG的实现，可以尝试用FPGA内的锁相环（PLL）的抖动，或者用未初始化的Block RAM内容作为熵源。但后者可能在不同编译次数下行为不同，需要验证。

第三，软件驱动与测试的同学，不要等到硬件都做完了再动手。应该先用虚拟模型（比如用C模型模拟PUF行为）开发驱动框架。验证的关键在于：硬件随机性如何被软件安全地调用。比如，TRNG驱动不能一次性输出所有随机比特，应该加入健康测试（连续比特相同检测）。PUF的响应需要纠错码（如BCH码）辅助，这部分算法是软件实现还是硬件实现？要提前定好接口。

最后，软硬件协同验证，我建议用FPGA原型验证为主，仿真的话速度太慢。可以设计一个统一的测试框架：上电后，软件自动运行一系列安全模块自检，并通过UART打印结果。这样能快速迭代。特别注意中断处理，安全模块的中断优先级和响应时间要测试清楚。

分工基本合理，但建议微调。三人团队：一人主攻CPU核集成、总线互联和系统集成（软硬件接口要清晰）；一人专攻安全模块硬件设计（PUF/TRNG/密码学加速器的RTL实现与优化）；一人负责软件驱动、系统测试与协同验证（包括搭建测试框架、编写裸机程序、验证安全功能）。关键在于第三人的角色不能只写驱动，必须承担大量验证工作，否则后期联调容易扯皮。

对于FPGA上实现PUF和TRNG：PUF可以利用FPGA底层资源的细微工艺偏差，比如基于查找表（LUT）的环形振荡器PUF或基于触发器初始值的SRAM PUF。重点是要设计出对温度、电压变化相对稳定的结构，并通过大量上电测试来统计唯一性和稳定性。TRNG则常用振荡器采样法（两个振荡器互相采样）或亚稳态电路，在FPGA上注意避免布局布线导致的确定性，需要后处理（如哈希）来改善随机性。验证时，要用逻辑分析仪抓取大量数据，进行NIST测试套件等统计测试。

软硬件协同验证关键点：1. 尽早定义好安全模块的寄存器接口，让软件人员能提前编写驱动和测试用例；2. 利用FPGA的软核（如MicroBlaze）或集成好的RISC-V先搭建一个可编程测试环境，实现自动化测试；3. 特别注意安全模块的中断、DMA等机制与CPU的协同，避免死锁或竞争；4. 最终演示时准备好可视化展示，比如TRNG实时波形、PUF密钥生成过程，能大大加分。

你们的分工没问题，但实际做起来会发现边界模糊。我当年参赛也是三人，类似分工。我的经验是：负责CPU和总线的人最好也懂点软件，因为总线地址映射、中断控制器配置这些硬件设置，直接影响到软件驱动能否跑通。安全模块设计的人不能只闷头写RTL，必须和软件人员一起制定验证计划，比如PUF需要软件调用多少次、TRNG的随机数怎么被软件读取。

在纯数字FPGA上搞PUF和TRNG，确实是挑战。但这也是比赛的亮点。PUF建议用基于LUT的环形振荡器阵列，因为资源丰富，容易调频率。关键是要做校准，比如通过环境变化下的多次响应来生成可靠密钥。TRNG可以用环形振荡器加异或的方式，但一定要加后处理，比如用LFSR或者简单的压缩函数，否则随机性可能通不过测试。验证时，一定要在板子上跑，不能只靠仿真。因为这类模块的随机性、唯一性依赖实际物理特性，仿真看不出来。

软硬件协同验证，最怕各搞各的。我们当时吃了亏：硬件改了一个接口，软件没同步更新，浪费一周。所以，每天同步进度，共用一份接口文档（比如用Excel或Google Sheets记录寄存器定义）。另外，尽早搭建一个统一的测试平台，比如用Python脚本自动生成测试向量、抓取FPGA输出，并调用软件程序进行比对。安全模块的异常情况（如TRNG熵不足、PUF响应错误）也要设计处理流程，让软件能检测并报告。最后，注意性能评估，比如密码学加速器的吞吐量，这往往是评分项。

分工基本合理，但建议微调。三人中，负责CPU核集成与总线的同学任务最重，他需要搭建整个SoC的框架，把总线（比如AXI）调通，让CPU能访问各个外设和安全模块。负责安全模块硬件的同学，要专注PUF、TRNG等具体模块的RTL设计。负责软件驱动的同学，不仅要写驱动和测试程序，后期还要承担大量软硬件联合调试的工作。我建议前期硬件搭建时，软件同学可以辅助硬件同学做一些简单的仿真测试脚本，减轻负担。

对于FPGA上实现PUF和TRNG，这是个关键。纯数字FPGA确实缺乏真正的模拟电路，但我们可以利用其固有的工艺偏差和延时特性。PUF常用基于环形振荡器（RO）或基于锁存器的结构。比如，设计一组环形振荡器，利用每个振荡器因工艺偏差产生的微小频率差异来生成芯片“指纹”。TRNG则可以利用多个环形振荡器之间的抖动或亚稳态来产生随机比特。重点在于后处理，比如用冯·诺依曼校正器或哈希函数来消除偏差。验证方面，除了功能仿真，必须在实际FPGA板卡上大量采集数据，进行统计测试（如NIST测试套件）来评估随机性和唯一性。

软硬件协同验证的关键点：第一，尽早建立统一的验证环境。比如用Verilator等工具搭建一个能同时运行硬件仿真和C测试程序的平台。第二，定义清晰的硬件-软件接口（寄存器映射），并保持文档同步。第三，制定分阶段的测试计划：先做每个模块的单独测试，再做总线集成后的模块访问测试，最后运行完整的应用测试（比如用PUF生成密钥，TRNG为加密算法提供种子）。特别注意中断和异常的处理，安全模块经常需要用到中断来通知CPU。

你们的分工是经典的三段式：架构、硬件、软件，没问题。我主要聊聊在FPGA上搞PUF和TRNG的实战经验以及容易踩的坑。

PUF实现上，别想得太复杂。赛腾或者一些学术论文里那种复杂的模拟PUF在FPGA里很难搞。建议从最简单的SRAM PUF入手。很多FPGA的Block RAM在上电后，初始值是不确定的，这就是天然的PUF源。你们可以让CPU通过总线去读取一块未初始化的RAM区域，得到一串随机值作为原始响应。当然，直接用它可能不稳定，需要配合纠错码（比如BCH码）在软件端做后处理，生成稳定密钥。这个方法实现快，容易验证。

TRNG的话，用环形振荡器（RO）阵列是主流。但注意，FPGA工具链会努力优化你的设计，让时序一致，这恰恰会破坏随机性！所以你必须用综合指令（比如Vivado里的KEEP、DONT_TOUCH）来防止工具优化掉那些精心设计的延时路径。另一个坑是，片上生成的随机数可能通过电源等渠道被侧信道攻击分析，作为比赛项目可以不深究，但要知道这个点。

软硬件协同方面，最大的痛点往往是调试。当程序跑飞，你很难确定是CPU软件写错了，还是总线访问安全模块的地址错了，或者是安全模块本身挂了。因此，强烈建议在设计中加入一些调试基础设施：比如，为每个关键的安全模块设计一组可读的状态寄存器；在总线上挂一个简单的日志模块，记录最近的几次访问。软件同学写驱动时，要养成先读ID寄存器验证模块存在，再逐步测试功能的习惯。最后，一定要在板卡上尽早进行端到端的测试，别只在仿真里过家家。

分工基本合理，但要注意交叉验证。你们三人分别负责CPU/总线、安全硬件、软件驱动，覆盖了主要环节。但安全模块硬件设计和软件驱动测试之间必须有紧密配合，比如TRNG的随机性测试需要软件配合采集大量数据做统计检验，PUF的响应稳定性也需要软件反复读取比对。建议每周至少同步两次，硬件设计同学要提前给软件同学定义好寄存器接口。

关于PUF和TRNG在FPGA上的实现，虽然FPGA是数字电路，但可以利用其固有的模拟特性。对于PUF，常用基于SRAM上电状态的SRAM PUF，或者利用布线延迟的仲裁器PUF。Xilinx FPGA的BRAM上电值具有芯片差异，可以提取为指纹。实现时注意控制环境因素（电压、温度）的影响，需要在不同条件下测试稳定性。TRNG可以利用环形振荡器的抖动，或者利用亚稳态电路。关键是要在后端加健康测试和后续处理（比如用哈希函数提取熵）。

软硬件协同验证的关键点：一是尽早建立统一的测试平台，比如用Verilator或QEMU做软件仿真，配合硬件RTL仿真；二是定义清晰的硬件-软件接口（寄存器映射、中断机制），并编写对应的驱动框架；三是制定验证计划，包括单元测试（每个安全模块）、集成测试（模块接入总线后）、系统测试（运行真实安全应用）。特别注意随机数生成器的随机性测试（NIST测试套件）和PUF的重复性测试，这些都需要自动化脚本。

你们的分工模式是经典的三段式，没问题。但根据我带队的经验，硬件安全模块在FPGA上的实现和验证是难点，我重点说这个。

PUF在FPGA上，我推荐用基于查找表（LUT）的PUF，或者利用时钟网络偏移。比如把两个相同的路径布置到不同位置，由于布线延迟的微小差异，通过仲裁器（比如D触发器）会产生不可预测的输出。这个实现起来是纯数字的，但利用了物理差异。关键是要做大量位测试，筛选出那些在不同温度电压下都稳定的位作为密钥源。

TRNG的实现，可以用多个环形振荡器采样，或者用FPGA内嵌的ADC（如果有的话）采样热噪声。纯数字方案常用的是亚稳态触发器，但设计不好容易出偏差。建议找开源的FPGA TRNG设计参考，比如用AIS 31标准评估过的。

验证方面，硬件模块单独仿真时就要注入各种扰动（模拟电压温度变化）。上板后一定要做长时间测试，TRNG跑几百万个样本看分布，PUF在不同环境（比如用吹风机加热）下重复读取。软件同学要配合写测试脚本，自动收集数据并分析。

另外提醒一点，安全模块集成到SoC总线后，注意访问控制，非安全域不能直接访问这些敏感模块，这需要在总线架构上设计。