fpga-development

FPGA 开发

将 HDL 视为对并发硬件的描述，并明确其时序和电气接口。正确的设计需要功能意图、语言语义、时钟/复位行为、实现约束和验证证据保持一致。编译、仿真、综合、时序分析和物理观测分别能证明不同事实。

操作约定

1. 明确所需决策和设计边界：新建 RTL、代码审查、仿真失败、资源问题、CDC/时序分析、实现或硬件发布。针对该决策使用最小且完整的证据集。
2. 在做出特定于目标的判断之前，记录器件/封装、板卡版本、时钟、复位、I/O 电压和引脚约束。若已说明抽象接口，纯 RTL 推理无需假定板卡。
3. 在实现之前，明确事务语义、延迟、吞吐量、背压、丢失/重复策略、初始化和算术行为。波形图不是接口约定。
4. 将可综合设计与仅用于验证的结构分开。HDL 子集和厂商原语模型应与实际仿真器和综合器版本匹配。
5. 在解读时序裕量之前，检查约束覆盖范围和例外约束意图。如果缺少时钟或存在未约束端点，即使汇总结果显示正常，证据也不完整。
6. 在对已连接硬件进行编程、复位、擦除或其他更改之前，先确认目标、操作范围和回滚路径。只读探查无需确认。比特流和编程路径必须与确切目标匹配。
7. 保留与同一组源代码/约束/工具/器件配置相对应的制品。不要将昨天的测试与今天未经验证的比特流拼在一起作为发布依据。

任务路由

只阅读相关深度的参考资料；使用其中的模板保留可审查的决策记录。

任务	参考资料	模板
确定器件和外部接口要求	目标和接口约定	目标约定
审查 RTL 语义、推断和算术	RTL 和算术	RTL 约定
制定自检验证策略	仿真和验证	仿真计划
审查时钟、复位和时钟域交叉	时钟、复位和 CDC	CDC 审查
诊断时序或审查约束	时序和约束	时序审查
权衡流水线、存储器、DSP 和实现方案	实现和资源权衡	RTL 约定和时序审查
发布实现或规划物理上板验证	发布和硬件验证	实现发布

默认设计和验证流程

明确可观测行为

列出顶层端口、位宽、符号属性、单位、时钟域和复位语义。为每笔事务定义何时被接受，以及何时输出有效。明确暂停时的行为、最大持续速率、允许的突发情况和缓冲策略。在提出 FIFO 方案之前，先检查生产者和消费者的速率：有限存储无法解决无界的服务速率差距。

对于数值运算，根据操作数范围和运算推导中间位宽。跟踪乘法、累加、重新缩放和转换过程中的二进制小数点。说明舍入、饱和、溢出和无效输入的处理策略。测试负数极值和边界值，不要只依赖常见的正数示例。

实现并检查推断出的硬件

将契约转换为可综合的组合逻辑和时序结构。检查赋值是否完整、复位是否覆盖全面、寄存器使能是否正确、是否存在多个驱动源、意外锁存器以及位宽／有符号性转换。检查推断报告，确认预期的存储器、DSP、进位链和寄存器结构。行为级实现即使仿真正确，也可能推断出不合适的硬件或不受支持的初始化方式。

避免将一种方法论技能扩展成厂商操作手册。命令、支持的语言、库和器件原语，请以已安装工具的准确文档为准；并将该版本与结果一并保留。与器件无关的示例是教学和回归测试工件，并非可直接用于引脚配置的项目。

验证时序行为

构建包含参考模型或记分板、自行检查的测试平台，并设置明确的超时和诊断性失败信息。覆盖与设计相关的复位、停顿、同时传输、边界条件和参数变体。确保激励和检查过程不会产生采样竞争。使用随机激励时，记录确定性种子。

确认验证确实能够失败：引入一个违反契约的受控本地修改，并确认测试会拒绝它。交付物中移除该修改。没有有效检查器的仿真即使通过，也几乎不能提供有力证据；覆盖率计数只能表明测试已触及相关场景，并不能证明正确性或穷尽性。

当属性、假设、时钟／复位抽象和证明界限都明确时，形式分析可以作为仿真的补充。有界证明通过不等于无界证明；空洞属性不代表验证成功。将求解器／工具／版本信息和反例证据与结果一并保留。

对时钟、复位和跨域进行建模

清点主时钟和生成时钟，并确认它们之间的实际关系。对每个跨域信号，区分单比特电平、脉冲／事件、连贯字、指针或数据流。根据其语义选择同步或传输架构。对每个位分别同步，并不能保证字的数据连贯性。窄脉冲可能消失；如果变化过快，脉冲翻转方案可能丢失事件。

明确每个时钟域中的复位断言和释放行为，包括单侧复位和时钟缺失的情况。器件专用的同步器属性和实现约束应遵循相应的厂商指南。功能仿真无法模拟模拟亚稳态的可靠性。

针对真实接口收敛时序

验证时钟和 I/O 约束、生成时钟、角落、模式、被忽略的命令以及未约束端点。随后检查建立时间和保持时间路径、时钟关系、时钟不确定度、逻辑深度、布线贡献和例外约束。任何假路径或多周期路径都应有架构依据，并验证其适用范围；典型流量中没有活动并不足以构成理由。

修改流水线、位宽、存储器、重定时或时钟时，除了时序，还要重新检查延迟和协议行为。修正约束模型与改进电路是两种不同的操作。记录是哪种操作改变了结果以及原因。

保留发布证据

将源代码和约束的哈希、顶层模块和参数、准确的工具／构建版本、器件／封装、报告、警告、测试和输出工件哈希一并保存。明确说明执行过哪些阶段：展开、功能仿真、综合、布局布线、静态时序分析、CDC 分析、形式分析、编程和实物验证。

对于硬件工作，验证映像身份、开发板和编程传输方式、文档规定的时钟／引脚／I/O 条件、初始状态及恢复路径。观察指定功能以及相关的复位／断电重启行为。编程器成功退出本身并不能证明设计的行为。

可执行验证示例

原始的 就绪/有效缓冲区 和 自检测试平台 展示了一个单条目、单时钟传输协议，并通过同步复位清空缓冲区。使用 Python 3、Icarus Verilog 和 Yosys，运行离线 测试样例检查器：

python3 scripts/fpga_fixture.py --json --output /path/to/new-fixture-results

从技能目录运行，或使用脚本的完整路径调用。输出目录必须为空或尚不存在。更改位宽或种子前，请先阅读 --help。检查器会记录版本、源文件哈希和各阶段结果；请检查结果 JSON 和保留的日志。缺少工具会导致结果不完整，而非验证成功。此测试样例没有引脚约束、布局布线、时序签核、CDC 或物理硬件证明。不要将其视为已确认的板级项目并进行烧录。

检查器测试位于 scripts/test_fixture.py。运行 python3 -m pytest scripts/test_fixture.py --no-cov -q；集成测试需要指定的工具，如果工具不可用，会明确跳过。故意进行的本地修改必须导致测试平台失败；切勿将修改过的 RTL 作为交付内容保留。

何时不应使用

• ESP32 固件、引脚限制、框架 API、烧录和 OTA 应使用仓库的 esp32-development 技能。
• 与平台无关的器件选型、原理图、负载/驱动器和台架测量分析应使用仓库的 electronics 技能。不要根据 HDL 类型或约束名称推断电气兼容性。
• 指定厂商工具的管理、安装和操作手册，需要查阅该工具的最新文档或专用技能。不得假设不同厂商的约束语法或原语等效。
• 高速板级通道、RF、EMC、电源完整性设计和受监管的签核，需要相关专业证据。本技能可以识别依赖项和缺失证据，但不能替代这些审查。

完成标准

交付所需产物和决策；确保检查对应正确的修订版本/配置；明确已知限制；结论不得超出实际执行的验证阶段。对于诊断问题，如果三轮尝试后仍未收敛，应保留证据并升级处理最小的未解决问题，而不是应用推测性的约束或 RTL 补丁。