嵌入式小白菜参加过类似比赛，分享点经验。
分工可以，但建议负责安全模块的同学和负责集成的同学紧密合作，因为PUF/TRNG这类模块可能需要直接连接到总线或特定的控制逻辑，不是简单挂上去就行。软件同学任务很重，不仅要写驱动，还要设计测试用例来评估安全模块的性能指标（如TRNG的熵、PUF的误码率）。
在FPGA上实现PUF，除了环形振荡器，还可以考虑仲裁器PUF（Arbiter PUF），利用对称路径的延迟竞争，但设计要更小心。TRNG可以用LFSR后处理加熵提取，但熵源还是要靠物理随机现象，比如时钟相位抖动。一个实用建议：去查学术论文，很多论文提供了在FPGA上实现这些模块的开源代码或详细结构，可以借鉴（注意版权）。
软硬件协同验证，关键点是建立清晰的测试计划。硬件模块在仿真中就要用随机测试向量验证；软件则需要编写分层测试代码，从寄存器读写测试到完整功能测试。一定要在FPGA板卡上做长时间运行测试，观察PUF响应是否稳定，TRNG是否会出现随机性不足。另外，注意资源使用，别因为安全模块把FPGA资源用爆了，影响整体系统。
你们的分工是经典的三段式：硬件、集成、软件，没问题。我重点说一下PUF和TRNG在FPGA上怎么搞。FPGA是数字电路，但内部有模拟特性可以被利用。
PUF实现，推荐用基于查找表（LUT）的环形振荡器PUF（RO-PUF）。方法很简单：用多个LUT和触发器搭成环形振荡器，由于布线延迟的细微差异，每个RO频率都不同。通过比较一对RO的频率快慢，输出0或1，多个比较结果就构成一个唯一ID。关键是要在布局布线时加位置约束，让RO对布局得很近，减少环境噪声影响。验证时要测不同电压温度下的稳定性。
TRNG可以用自由振荡的环形振荡器采样法，或者用时钟抖动积累法。更简单的是用FPGA内部的一些原生元件，比如Xilinx的XADC模块中的噪声源，但需要查手册看是否支持。
软硬件协同方面，一定要先做仿真验证。用SystemVerilog搭个简单的测试平台，把CPU的软件行为用总线事务模拟出来，先验证硬件模块功能正确。上板后，先让软件读出原始数据，再做后续处理。三人要经常同步接口定义和测试进度。
分工基本合理，但建议微调。三人团队：一人负责SoC集成（RISC-V核、总线、外设互联），一人专攻安全硬件模块（PUF/TRNG/密码加速器的RTL设计），一人负责软件（启动代码、驱动、系统测试）。关键在于负责安全模块的同学需要深入研究FPGA上实现PUF/TRNG的“数字替代”方法，比如基于环形振荡器或锁存器结构的PUF，以及基于亚稳态的TRNG。软件同学要尽早介入，为硬件模块编写验证驱动和裸机测试程序。
对于PUF/TRNG在FPGA的实现，核心思路是利用FPGA制造工艺的细微差异或数字电路的随机性。PUF可以用多个环形振荡器（RO）组成阵列，比较它们的频率差异来生成芯片指纹；TRNG可以利用多个RO的抖动或触发器的亚稳态。验证时，需要用大量实验数据统计其唯一性、随机性等指标。
软硬件协同验证的关键点：1. 尽早定义硬件模块的寄存器接口，让软件可以访问和控制。2. 搭建统一的仿真环境（如用Verilator+软件），进行联合仿真。3. 在FPGA原型上，软件要能读取原始PUF响应、TRNG数据，并进行功能与性能测试。注意，安全模块对时序可能敏感，需要在实际板卡上充分测试。
你们的分工模式是经典的三段式，没问题。但根据我带队的经验，硬件安全模块在FPGA上的实现和验证是难点，我重点说这个。
PUF在FPGA上，我推荐用基于查找表（LUT）的PUF，或者利用时钟网络偏移。比如把两个相同的路径布置到不同位置，由于布线延迟的微小差异，通过仲裁器（比如D触发器）会产生不可预测的输出。这个实现起来是纯数字的，但利用了物理差异。关键是要做大量位测试，筛选出那些在不同温度电压下都稳定的位作为密钥源。
TRNG的实现，可以用多个环形振荡器采样，或者用FPGA内嵌的ADC（如果有的话）采样热噪声。纯数字方案常用的是亚稳态触发器，但设计不好容易出偏差。建议找开源的FPGA TRNG设计参考，比如用AIS 31标准评估过的。
验证方面，硬件模块单独仿真时就要注入各种扰动（模拟电压温度变化）。上板后一定要做长时间测试，TRNG跑几百万个样本看分布，PUF在不同环境（比如用吹风机加热）下重复读取。软件同学要配合写测试脚本，自动收集数据并分析。
另外提醒一点，安全模块集成到SoC总线后，注意访问控制，非安全域不能直接访问这些敏感模块，这需要在总线架构上设计。
分工基本合理，但要注意交叉验证。你们三人分别负责CPU/总线、安全硬件、软件驱动，覆盖了主要环节。但安全模块硬件设计和软件驱动测试之间必须有紧密配合，比如TRNG的随机性测试需要软件配合采集大量数据做统计检验，PUF的响应稳定性也需要软件反复读取比对。建议每周至少同步两次，硬件设计同学要提前给软件同学定义好寄存器接口。
关于PUF和TRNG在FPGA上的实现，虽然FPGA是数字电路，但可以利用其固有的模拟特性。对于PUF，常用基于SRAM上电状态的SRAM PUF，或者利用布线延迟的仲裁器PUF。Xilinx FPGA的BRAM上电值具有芯片差异，可以提取为指纹。实现时注意控制环境因素（电压、温度）的影响，需要在不同条件下测试稳定性。TRNG可以利用环形振荡器的抖动，或者利用亚稳态电路。关键是要在后端加健康测试和后续处理（比如用哈希函数提取熵）。
软硬件协同验证的关键点：一是尽早建立统一的测试平台，比如用Verilator或QEMU做软件仿真，配合硬件RTL仿真；二是定义清晰的硬件-软件接口（寄存器映射、中断机制），并编写对应的驱动框架；三是制定验证计划，包括单元测试（每个安全模块）、集成测试（模块接入总线后）、系统测试（运行真实安全应用）。特别注意随机数生成器的随机性测试（NIST测试套件）和PUF的重复性测试，这些都需要自动化脚本。
你们的分工是经典的三段式：架构、硬件、软件，没问题。我主要聊聊在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核集成与总线的同学任务最重，他需要搭建整个SoC的框架，把总线（比如AXI）调通，让CPU能访问各个外设和安全模块。负责安全模块硬件的同学，要专注PUF、TRNG等具体模块的RTL设计。负责软件驱动的同学，不仅要写驱动和测试程序，后期还要承担大量软硬件联合调试的工作。我建议前期硬件搭建时，软件同学可以辅助硬件同学做一些简单的仿真测试脚本，减轻负担。
对于FPGA上实现PUF和TRNG，这是个关键。纯数字FPGA确实缺乏真正的模拟电路，但我们可以利用其固有的工艺偏差和延时特性。PUF常用基于环形振荡器（RO）或基于锁存器的结构。比如，设计一组环形振荡器，利用每个振荡器因工艺偏差产生的微小频率差异来生成芯片“指纹”。TRNG则可以利用多个环形振荡器之间的抖动或亚稳态来产生随机比特。重点在于后处理，比如用冯·诺依曼校正器或哈希函数来消除偏差。验证方面，除了功能仿真，必须在实际FPGA板卡上大量采集数据，进行统计测试（如NIST测试套件）来评估随机性和唯一性。
软硬件协同验证的关键点：第一，尽早建立统一的验证环境。比如用Verilator等工具搭建一个能同时运行硬件仿真和C测试程序的平台。第二，定义清晰的硬件-软件接口（寄存器映射），并保持文档同步。第三，制定分阶段的测试计划：先做每个模块的单独测试，再做总线集成后的模块访问测试，最后运行完整的应用测试（比如用PUF生成密钥，TRNG为加密算法提供种子）。特别注意中断和异常的处理，安全模块经常需要用到中断来通知CPU。
你们的分工没问题，但实际做起来会发现边界模糊。我当年参赛也是三人，类似分工。我的经验是：负责CPU和总线的人最好也懂点软件，因为总线地址映射、中断控制器配置这些硬件设置，直接影响到软件驱动能否跑通。安全模块设计的人不能只闷头写RTL，必须和软件人员一起制定验证计划，比如PUF需要软件调用多少次、TRNG的随机数怎么被软件读取。
在纯数字FPGA上搞PUF和TRNG，确实是挑战。但这也是比赛的亮点。PUF建议用基于LUT的环形振荡器阵列，因为资源丰富，容易调频率。关键是要做校准，比如通过环境变化下的多次响应来生成可靠密钥。TRNG可以用环形振荡器加异或的方式，但一定要加后处理，比如用LFSR或者简单的压缩函数，否则随机性可能通不过测试。验证时，一定要在板子上跑，不能只靠仿真。因为这类模块的随机性、唯一性依赖实际物理特性，仿真看不出来。
软硬件协同验证，最怕各搞各的。我们当时吃了亏：硬件改了一个接口，软件没同步更新，浪费一周。所以，每天同步进度，共用一份接口文档（比如用Excel或Google Sheets记录寄存器定义）。另外，尽早搭建一个统一的测试平台，比如用Python脚本自动生成测试向量、抓取FPGA输出，并调用软件程序进行比对。安全模块的异常情况（如TRNG熵不足、PUF响应错误）也要设计处理流程，让软件能检测并报告。最后，注意性能评估，比如密码学加速器的吞吐量，这往往是评分项。
分工基本合理，但建议微调。三人团队：一人主攻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和总线的同学，任务很重。除了集成蜂鸟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需要软硬件协同验证，负责安全硬件的同学必须和写驱动的同学紧密沟通，甚至一起调试。建议每周固定时间联调，而不是完全各干各的。另外，CPU核集成的人也需要了解总线如何安全扩展（比如加入访问控制），不能只关注连通性。
关于PUF和TRNG在FPGA上的实现，这是个经典难题。纯数字FPGA缺乏模拟特性，但可以利用其固有的工艺偏差和布线延迟。对于PUF，可以尝试基于查找表（LUT）的环形振荡器PUF或仲裁器PUF。关键是要利用FPGA上布线的不对称性来产生芯片指纹。你需要写脚本在不同位置实例化大量相同的路径，测量频率或延迟差异。验证时，需要在同一块板卡上多次上电测试稳定性，还要在不同温度下测试可靠性。
对于TRNG，可以利用FPGA的亚稳态现象，比如用多个环形振荡器采样，或者用时钟抖动。但要注意，赛用FPGA环境相对理想，产生的随机性需要严格测试（比如NIST测试套件）。建议前期集中精力找到一个在你们板卡上可重复实现的稳定方案，不要追求最复杂的方案。
软硬件协同验证的关键点：1. 尽早建立统一的仿真环境，比如用Verilator+软件一起跑，验证硬件模块的寄存器访问是否正确。2. 为每个硬件安全模块设计简单的裸机驱动测试用例，比如读取TRNG数值并统计，验证PUF响应。3. 注意安全模块的地址映射、中断信号对接，这些容易出错。4. 系统集成后，跑一些小型安全应用（比如密钥生成、加密）来验证端到端功能。
你们的分工模式是经典的三人组，很合理。我补充一点：负责安全模块硬件设计的同学任务最重，因为PUF和TRNG在数字FPGA上实现需要一些技巧。
对于PUF，建议实现基于环形振荡器（RO）的PUF，利用FPGA内部LUT和布线延迟的细微差异。设计多个RO对，比较它们的频率，生成1位响应。关键在于布局约束，要确保RO对布局靠近，以减少环境噪声影响。还需要设计校准机制，因为温度电压变化会影响频率。
TRNG的实现，可以用多个环形振荡器异或，利用其抖动作为熵源。或者用亚稳态电路，但设计更复杂。一定要做后处理，比如用冯·诺依曼校正器或简单的CRC，确保输出符合随机性标准。
软硬件协同方面，一定一定要尽早开始联合调试。硬件设计的同时，软件同学就可以根据规划好的寄存器地址，编写基础驱动函数。上板后，先测试每个模块的独立功能，再测试集成后的系统。验证关键点包括：安全模块的寄存器访问是否正确、中断是否能正常触发和处理、数据通路是否畅通。建议用串口打印调试信息，比较直观。
另外，别忘了考虑性能评估，比如TRNG的生成速度、PUF的响应时间，这些可能是比赛的加分项。
