聊到硬件设计很多人的第一反应是时序收敛、面积功耗、验证覆盖率聊到安全第一反应又是熔断、幽灵、侧信道、供应链攻击。当 Chiplet 把一颗大 SoC 拆成多个 Die 之后安全边界已经不再只是芯片引脚上的信任边界当大语言模型开始帮我们生成 Verilog、写断言、做代码审查时安全问题的源头又多了一个“灰色入口”。这篇文章想把硬件设计、Chiplet 架构、LLM 辅助开发与硬件安全放在一起拆开讲Chiplet 时代硬件架构发生了哪些变化LLM 在硬件设计流程里能做什么、不能做什么以及从寄存器到供应链硬件安全到底应该怎么设计、怎么验证。无论你是硬件工程师、验证工程师还是对体系结构感兴趣的软件开发者这篇文章都会给出一个相对完整的思考框架并附带一个可仿真、可扩展的安全外设访问控制模块示例。1. 背景与核心概念1.1 Chiplet 是什么为什么突然成了主流方向传统上一颗 SoC 采用单片设计所有 CPU 核心、GPU、内存控制器、IO 接口集成在同一颗 Die 上。随着制程演进到 5nm、3nm单片大 Die 的流片成本越来越高良率却越来越低。任何一个小模块出错或者有制造缺陷都可能导致整颗芯片报废。Chiplet 思路是把一颗大芯片拆成多个相对较小的芯片Die再用先进封装技术例如 2.5D 中介层、3D 堆叠把这些小芯片组合成一个完整的系统。每个 Chiplet 可以使用更适合自身功能的制程CPU 用先进逻辑工艺IO 用成熟工艺模拟和射频用特殊工艺再通过 Die-to-Die 互连协议进行通信。这样的好处比较明显提升良率降低大芯片制造风险。复用成熟 IP 模块缩短研发周期。异构集成更灵活可以混合不同来源的芯片颗粒。硬件生态从“单芯片自研”走向“多芯片协作”。但从安全视角来看Chiplet 也带来了新的问题芯片不再来自单一可信代工厂不同 Die 可能来自不同供应商、不同封装厂整条供应链的信任边界被拉长了。后面我们会专门分析这个问题。1.2 LLM 在硬件设计领域扮演的角色大语言模型Large Language ModelLLM在软件领域已经展示了很强的代码生成能力。硬件设计同样是代码密集型工作RTL 设计使用 Verilog、SystemVerilog、VHDL验证环境使用 SystemVerilog 和 UVM综合脚本使用 Tcl约束文件使用 SDC。LLM 在硬件设计中的常见应用包括根据自然语言描述生成 RTL 模块代码。辅助编写 SVA 断言和测试用例。分析波形文件、日志中的常见错误。为已有模块补充文档说明。在代码审查阶段检查状态机、位宽、跨时钟域问题。但需要清醒一点LLM 生成的硬件代码和软件代码一样可能存在“看起来合理但实际有缺陷”的问题而且硬件调试成本远高于软件。一次流片周期通常需要数月一个安全漏洞在流片后暴露代价是重新改版。因此LLM 辅助硬件设计必须走“AI 生成 人工审查 形式化验证”三重路线。1.3 为什么硬件安全是一个独立且重要的领域很多人以为安全只是软件层面的事情操作系统负责权限管理防火墙负责网络隔离加密库负责数据保护。但现代安全体系的底层信任都需要硬件支撑密钥必须存储在硬件中启动镜像必须由硬件信任根校验内存访问隔离需要硬件总线防火墙。硬件安全问题一旦发生影响通常是底层且持久的。例如经典的 Spectre 和 Meltdown 漏洞根源就出在 CPU 的推测执行和缓存架构设计上软件补丁只能缓解无法根治。再比如侧信道攻击攻击者通过功耗、电磁辐射、时间延迟来推断密钥信息这种攻击不依赖软件漏洞而是利用物理实现层面的信息泄漏。在 Chiplet 时代硬件安全还需要考虑多 Die 之间的互连信任、第三方 Chiplet 的恶意逻辑、封装环节的物理篡改等问题。这也是为什么我们要把硬件设计和安全放在一起讨论。2. 硬件设计环境与工具准备2.1 RTL 设计与仿真工具如果你只具备软件背景想开始接触硬件设计建议从 Verilog/SystemVerilog 入手。当前主流的 RTL 设计与仿真工具有以下几类工具类型主要用途备注Icarus Verilogiverilog开源Verilog 仿真简单易用适合入门和快速验证Verilator开源Verilog/SystemVerilog 仿真编译为 C 模型性能好适合大型设计预研VCS / Questa / ModelSim商业仿真与验证工程中广泛使用支持完整 UVM/SVAVivado / Quartus商业FPGA 综合与实现面向 FPGA 平台自带仿真器Yosys开源逻辑综合适用于 FPGA 和教学研究本文的示例模块以 Verilog 编写仿真命令基于 iverilog 和 vvp读者无需商业许可证即可复现。2.2 安全验证与评估工具链硬件安全验证不只是跑一遍功能仿真还需要做以下几类评估功能仿真验证正常功能路径是否满足预期。断言验证用 SVA 描述“必须成立的安全属性”例如解锁状态与外设开启状态之间的因果关系。形式化验证穷举证明安全属性在所有输入组合下都不会被违反。开源项目 SymbiYosys 可以配合 Yosys 使用。故障注入仿真模拟电压毛刺、时钟毛刺、单粒子翻转对安全状态机的影响。功耗与电磁分析需要在硬件实物或者高精度功耗模型上进行通常用于侧信道分析。真实项目中这些工作往往需要专业安全工程师参与。本文重点演示 RTL 安全模块设计与功能仿真阶段的方法读者可以在自己工程中扩展。2.3 版本说明EDA 工具链版本更新很快不同工具对 SystemVerilog 的支持程度也不同。例如 iverilog 目前对 SVA 支持有限VCS/Questa 则支持完整语法。因此本文不对具体版本做硬性绑定示例代码主要使用 Verilog-2001 语法保证在多数环境下可以直接仿真。如果你在实际项目中遇到版本兼容问题建议优先查看工具官方文档而不是盲目升级工具链。3. 核心原理拆解Chiplet、LLM 与硬件安全3.1 Chiplet 设计的几个关键技术点从架构角度看Chiplet 设计有四个关键层次第一是互连协议。Die 与 Die 之间要低延迟、高带宽、低功耗地通信必须依赖统一的互连协议。以 UCIe 为代表的 Die-to-Die 互连标准正在成为行业共识它定义了物理层、协议层和管理层的规范。互连协议本身的安全性至关重要如果互连通道没有鉴权和加密机制恶意的第三方 Chiplet 可能窃听甚至篡改其他 Die 之间的数据。第二是片上网络。多 Die 系统中数据不再只走传统的总线结构而是经常采用 NoCNetwork-on-Chip。NoC 把数据打包成数据包在各个网络节点之间路由。NoC 上的安全策略需要与路由策略联动比如为不同安全等级的数据规划隔离路径。第三是封装与物理集成。2.5D 封装使用硅中介层或有机基板3D 堆叠则把多个 Die 垂直连接。物理上Die 之间的信号走线可能暴露在封装表面攻击者有机会进行探针或者侧信道测量。相比传统单芯片Chiplet 的物理攻击面更大、更分散。第四是系统级信任。传统芯片的信任边界在芯片引脚处只要引脚不暴露给攻击者整体安全相对可控。Chiplet 系统中不同 Die 之间的信任边界是动态的。各 Die 可能来自不同供应商整个系统必须建立一套跨 Die 的身份认证和安全启动机制。3.2 LLM 辅助硬件设计能做什么不能做什么先看 LLM 在硬件设计中的实际落地方式。最直接的是自然语言生成 RTL。比如你输入“写一个 8 位计数器带异步复位和使能信号。”LLM 通常能立刻给出类似下面的代码module counter_8bit #( parameter WIDTH 8 )( input wire clk, input wire rst_n, input wire en, output reg [WIDTH-1:0] count ); always (posedge clk or negedge rst_n) begin if (!rst_n) count {WIDTH{1b0}}; else if (en) count count 1b1; end endmodule这一类标准化模块LLM 生成质量很高能显著提高原型开发效率。更复杂的场景比如内部状态机、跨时钟域处理、安全状态判断LLM 的能力就会明显下降。它不了解你的项目中全局的安全策略、已有的访问控制矩阵、SoC 总线的具体带宽和时序要求也不会主动区分安全模块和普通模块。所以LLM 在硬件设计中的边界可以理解为适合做代码生成、断言初稿、文档整理、代码翻译、常见模式识别。不适合做全自动安全关键模块设计、跨模块全局方案设计、最终代码审查。必须补位的专业工程师 code review、形式化验证、覆盖率分析、安全评估。从安全角度看LLM 还有一个需要警惕的问题如果把公司内部芯片架构、寄存器地址、密钥策略喂给 LLM可能造成敏感信息外泄。很多公司的代码补全工具默认会把代码片段发送到云端模型处理硬件团队在使用前必须和法务、安全部门确认数据合规边界。3.3 硬件安全威胁模型与防护框架硬件安全的威胁模型可以从攻击角度来分类攻击类型攻击手段典型目标防护方向供应链攻击恶意 IP 插入、Die 替换、逻辑篡改后门、木马、功能降级供应商审计、硬件指纹、安全启动物理攻击探针、聚焦离子束FIB、芯片开盖密钥提取、总线窃听屏蔽层、防篡改检测、密钥硬件隔离旁路攻击功耗分析、电磁辐射、时序分析加密密钥恒定时间实现、掩码、功耗均衡故障注入电压毛刺、时钟毛刺、激光注入绕过程序判断、提权电压/时钟监测、冗余计算、状态机锁定软件攻击固件漏洞、驱动漏洞、总线非法访问外设控制、内存读写总线防火墙、访问控制、TrustZone 类隔离针对这些威胁硬件安全设计通常依赖几个基础组件信任根Root of Trust作为系统启动的第一级可信来源通常固化在 ROM 中负责校验后续镜像签名。安全启动Secure Boot从信任根开始逐级验证固件和软件的签名确保只运行可信代码。物理不可克隆函数PUF利用芯片制造过程中的随机差异生成唯一身份标识和密钥根。总线防火墙Bus Firewall在总线层面控制不同主设备对外设和内存的访问权限。安全状态机对安全关键操作增加状态锁定、重试次数限制、故障锁定机制。这些机制最终都要落实到 RTL 设计上也就是本文实战案例要演示的内容。4. 硬件安全实战实现一个带防爆破机制的外设访问控制模块4.1 需求与功能拆解我们来看一个非常典型的硬件安全场景SoC 中有某个安全外设例如安全存储控制器默认情况下必须处于锁定状态不允许外部访问。软件需要先写入正确的密钥才能解锁并且为了防止暴力破解连续错误次数达到上限后模块进入锁定状态必须通过系统复位才能恢复。这是一个贴近真实 SoC 安全设计的小模块虽然逻辑不复杂但包含了几个核心安全思想默认拒绝Secure by Default上电后 gate_open 为 0外设默认不可用。密钥校验解锁需要正确写入 64 位密钥。防爆破连续写错达到 MAX_RETRIES 则进入 LOCKOUT 状态。可恢复系统复位后回到初始锁定状态。状态机完整非法状态回到锁定状态。4.2 RTL 模块实现文件路径src/secure_access_gate.vmodule secure_access_gate #( parameter KEY_WIDTH 64, parameter MAX_RETRIES 3 )( input wire clk, input wire rst_n, // 解锁写入端口 input wire unlock_write_en, input wire [KEY_WIDTH-1:0] unlock_data, // 外设门控控制端口 input wire gate_write_en, input wire gate_ctrl, // 输出门控状态和状态指示 output reg gate_open, output reg [1:0] status ); localparam [KEY_WIDTH-1:0] UNLOCK_KEY 64h5A5A_5A5A_CAFE_F00D; localparam STATUS_LOCKED 2b00; localparam STATUS_UNLOCKED 2b01; localparam STATUS_LOCKOUT 2b10; reg [1:0] state; reg [1:0] retry_cnt; // 64 位密钥比较在硬件中天然是恒定时间的 wire key_match (unlock_data UNLOCK_KEY); always (posedge clk or negedge rst_n) begin if (!rst_n) begin state STATUS_LOCKED; retry_cnt 2b00; gate_open 1b0; end else begin case (state) STATUS_LOCKED: begin if (unlock_write_en) begin if (key_match) begin state STATUS_UNLOCKED; retry_cnt 2b00; end else begin retry_cnt retry_cnt 1b1; if (retry_cnt 1b1 MAX_RETRIES) begin state STATUS_LOCKOUT; end end end end STATUS_UNLOCKED: begin // 解锁状态下允许通过 gate_write_en 打开/关闭外设门 if (gate_write_en) begin gate_open gate_ctrl; end // 允许软件主动上锁写错密钥也会回到锁定状态 if (unlock_write_en !key_match) begin state STATUS_LOCKED; end end STATUS_LOCKOUT: begin // 锁定状态等待系统复位实际芯片可触发安全监控中断 gate_open 1b0; end default: begin state STATUS_LOCKED; end endcase end end always (*) begin status state; end endmodule这个模块有几个设计点值得展开。首先是状态定义。LOCKED 是上电默认状态也是所有非法状态的归位点。UNLOCKED 表示密钥验证通过外设门控寄存器可写。LOCKOUT 表示触发防爆破机制不再接受任何解锁尝试。其次是密钥比较。64 位总线数据与常量直接比较在硬件综合后会形成按位异或树属于恒定时间操作不存在软件中常见的“逐字节提前退出”问题。如果将来要实现更高级的防侧信道设计还需要关注功耗均衡这里先不展开。第三是防爆破逻辑。每次错误尝试retry_cnt加 1当retry_cnt 1 MAX_RETRIES时进入 LOCKOUT。MAX_RETRIES 设为 3因此第三次错误会触发锁定。实际项目中这个值一般是 3 到 8视安防等级而定。第四是故障锁定行为。进入 LOCKOUT 后gate_open被强制拉低即使攻击者持续发送解锁信号也无法打开外设。只有rst_n拉低复位才能恢复。在某些高安全场景中LOCKOUT 状态还会配合安全熔丝一旦触发就永久锁定该外设必须更换芯片。这类逻辑不会写在通用 RTL 里而是由系统安全手册定义。4.3 测试平台验证正常解锁与防爆破流程一个安全模块光能写出来还不够必须验证。下面给出一个基于 iverilog 的 testbench覆盖三条主路径错误密钥三次触发锁定锁定后正确密钥无效复位后正确密钥可以解锁并控制外设门。文件路径sim/tb_secure_access_gate.vtimescale 1ns/1ps module tb_secure_access_gate; reg clk; reg rst_n; reg unlock_write_en; reg [63:0] unlock_data; reg gate_write_en; reg gate_ctrl; wire gate_open; wire [1:0] status; secure_access_gate dut ( .clk (clk), .rst_n (rst_n), .unlock_write_en (unlock_write_en), .unlock_data (unlock_data), .gate_write_en (gate_write_en), .gate_ctrl (gate_ctrl), .gate_open (gate_open), .status (status) ); initial clk 1b0; always #5 clk ~clk; initial begin // 初始化 rst_n 1b0; unlock_write_en 1b0; unlock_data 64h0; gate_write_en 1b0; gate_ctrl 1b0; #10; rst_n 1b1; // 第一次错误密钥 #10; unlock_write_en 1b1; unlock_data 64h00000000_00000001; #10; unlock_write_en 1b0; // 第二次错误密钥 #10; unlock_write_en 1b1; unlock_data 64h00000000_00000002; #10; unlock_write_en 1b0; // 第三次错误密钥应该进入 LOCKOUT #10; unlock_write_en 1b1; unlock_data 64h00000000_00000003; #10; unlock_write_en 1b0; // 此时即使输入正确密钥也无法解锁 #10; unlock_write_en 1b1; unlock_data 64h5A5A_5A5A_CAFE_F00D; #10; unlock_write_en 1b0; // 复位回到 LOCKED #20; rst_n 1b0; #10; rst_n 1b1; // 正确密钥解锁 #10; unlock_write_en 1b1; unlock_data 64h5A5A_5A5A_CAFE_F00D; #10; unlock_write_en 1b0; // 打开外设门 #10; gate_write_en 1b1; gate_ctrl 1b1; #10; gate_write_en 1b0; #20; $finish; end endmodule4.4 运行仿真在命令行中执行iverilog -o tb tb_secure_access_gate.v secure_access_gate.v vvp tb如果你使用商业仿真工具也可以用类似流程加载这两个文件。仿真结束后可以通过$dumpfile和$dumpvars生成 VCD 波形文件再用 GTKWave 查看initial begin $dumpfile(tb.vcd); $dumpvars(0, tb_secure_access_gate); end预期的状态跳转顺序是LOCKED连续三次错误密钥后进入 LOCKOUT。LOCKOUT正确密钥写入也无响应。复位后回到 LOCKED。LOCKED正确密钥写入后跳到 UNLOCKED。UNLOCKED控制 gate_write_en 后 gate_open 拉高。4.5 对安全机制的进一步思考这个模块是一个基础示例距离真实 SoC 的安全设计还有几个明显差距。第一个差距是缺少系统级访问控制。真实 SoC 中外设不会只有一个 gate_open 信号。总线防火墙需要根据主设备 ID、传输地址、读写类型做更细粒度的判断。比如普通 CPU 核可以访问外设但 DMA 控制器不能访问密钥寄存器。第二个差距是缺少复位分类。本模块只有统一复位。真实芯片往往区分上电复位、看门狗复位、安全复位。安全复位可能只清除部分状态而把安全熔丝状态保留。第三个差距是缺少异常上报。进入 LOCKOUT 后模块应能通过中断或者安全告警总线通知安全监控处理器。这些在实际工程中都是必须的。读者可以在本模块基础上扩展增加主设备 ID 过滤、增加安全告警输出、增加错误计数溢出保护。5. Chiplet 与 LLM 场景下的安全实践5.1 Chiplet 供应链安全从单点信任到多方共信单片设计中安全信任根基本上来自同一颗芯片、同一家代工厂。Chiplet 改变了这个前提CPU Die 来自厂商 AIO Die 来自厂商 B加速器 Die 来自第三方 IP 供应商 C。任何一家被攻破都可能影响整个系统。因此Chiplet 时代的安全实践需要覆盖整个生命周期供应商评估对 IP 供应商做代码审计、安全能力评估和持续监控。业界常见的做法是要求供应商提供安全设计白皮书、安全验证报告。交付验证对收到的 Die 做身份验证和功能测试。PUF 指纹和不可擦除的芯片 ID 是基础能力。互连安全Die 之间传输敏感数据时要考虑增加认证和加密机制。虽然这会有面积和功耗开销但安全等级需求应该由系统级威胁分析决定。封装后检测X 射线、扫描声学显微镜等物理检测手段可以在一定程度上发现封装后的物理篡改。需要注意的是供应链安全不是出了安全事故之后再做的事。它必须从选型阶段就开始并在产品生命周期内持续维护。5.2 LLM 辅助硬件设计的安全红线LLM 确实提高了硬件设计效率但也带来了新的安全和管理问题。硬件团队应该注意以下几点第一敏感代码不外传。寄存器手册、安全密钥、内部架构文档都不应该直接粘贴到公开或半公开的 LLM 工具中。企业可以考虑部署私有化模型或者在本地搭建代码补全服务。第二LLM 生成代码必须经过代码审查。相比人类工程师LLM 更擅长生成“看起来完整但缺少边界条件”的代码。比如状态机缺 default、位宽不匹配、异步复位没有同步释放这些在硬件设计中都是致命的。第三给 LLM 的提示词也要安全。不要为了“让模型生成更接近内部设计”的代码把完整的 SoC 安全架构写进提示词。提示词本身应该经过脱敏处理。第四项目负责人应当建立一套“AI 生成代码标记机制”。哪些模块是由 LLM 主要生成的要在代码评审系统中标记出来且安全关键模块不推荐直接使用 LLM 生成的代码合入主干。5.3 从软件安全配置理解硬件安全设计最近社区里经常出现各种软件安全配置问题比如“Spring Security 过滤链配置后接口仍然 401”“Windows Security 设置中心打不开”“MySQL view 的 SQL SECURITY DEFINER 权限报错”。这些问题的排查思路其实和硬件安全设计有很强的类比关系。以 Spring Security 为例它的核心是过滤链。接口为什么未授权大概率是过滤链顺序不对或者匹配路径规则过于严格。对应到硬件设计就是总线防火墙的访问控制列表顺序问题。规则匹配顺序如果错误授权主设备可能被误拦截未授权主设备却可能绕过检查。再看 MySQL 里的SQL SECURITY DEFINER它定义了视图或存储过程在执行时使用定义者的权限还是调用者的权限。如果定义者权限不足即使调用者正确也会报错。在硬件 SoC 中安全外设同样存在类似的“权限归属”问题访问某个安全寄存器时总线是看发起访问的主设备 ID还是看当前 CPU 运行的进程权限如果该判断落在错误的安全域会造成越权访问。还有 Windows Security 设置中心打不开常见原因是安全中心服务和注册表策略异常。硬件中如果安全策略寄存器被意外配置到错误状态同样会导致安全系统功能异常。排查时都要按“服务/模块是否启动 → 配置项是否存在 → 策略是否生效 → 权限是否足够”的路径逐层定位。这些跨领域类比说明一个规律不管软件还是硬件安全设计的第一原则都是“默认拒绝按需放行”。在软件里是白名单在硬件里是上电锁定在软件里是最小权限在硬件里是最小访问窗口。6. 常见问题与排查思路6.1 安全 RTL 设计与验证中的常见问题问题现象常见原因解决思路上电后外设仍然可被访问访问控制模块未接管外设门控信号检查外设门控信号是否有默认值确认 RTL 是否存在路径绕过解锁密钥可以被暴力破解缺少重试次数限制或锁定机制增加 retry_cnt 计数达到阈值进入 LOCKOUT错误密钥到达 MAX_RETRIES 后仍可解锁比较逻辑在非 LOCKOUT 状态仍被执行检查状态机在 LOCKOUT 状态下忽略解锁请求状态机进入非法状态case 分支缺少 default所有状态机必须补 default回到安全状态综合后安全逻辑被优化掉综合工具认为部分逻辑无效或没有设置 preserve 属性在 SDC 或综合属性中标记安全关键模块防止被优化仿真通过但上板失败仿真代码和综合代码行为不一致做综合后仿真Gate-Level SimulationLLM 生成的模块缺少复位逻辑生成代码时没有显式要求复位策略人工审查补复位逻辑增加 testbench 覆盖6.2 安全配置类问题排查通用思路不管查什么问题建议统一按下面顺序排查确认模块是否进入工作状态软件里查服务状态硬件里查状态寄存器。确认配置是否真正写入软件里查配置中心硬件里读返回状态。确认权限是否匹配软件看账号角色硬件看主设备 ID / 安全域。确认策略顺序是否正确软件过滤链顺序硬件 ACL 匹配顺序。确认是否需要复位恢复。这套思路在 Spring Security、数据库权限、操作系统安全设置等场景都适用也和硬件总线防火墙的调试流程高度一致。7. 最佳实践与工程建议7.1 RTL 安全设计规范如果团队要从零建设硬件安全设计能力建议优先落地下面几条规范。第一所有安全关键模块必须使用显式状态机。不要用多个 if-else 拼凑安全状态判断。状态机要有定义良好的状态编码、default 分支和非法状态安全归位策略。第二默认值必须是安全值。所有复位后的寄存器初值尤其外设门控、中断使能、访问控制寄存器应以“禁止”“关闭”“拒绝”为默认值。第三安全上下文要按模块隔离。即使整个 SoC 只有一个 CPU也建议在总线层面划分安全主设备 ID 和非安全主设备 ID。硬件隔离的可靠性高于纯软件逻辑判断。第四关键信号要防止综合优化。对安全关键的门控逻辑、比较逻辑建议在综合脚本中设置 preserve 属性或者使用等价约束避免工具误优化。第五要写安全断言。在验证阶段用 SVA 描述安全属性例如// 安全断言示例外设 gate_open 只有在 STATUS_UNLOCKED 下才能被拉高 property p_gate_open_requires_unlocked; (posedge clk) disable iff(!rst_n) gate_open |- (status STATUS_UNLOCKED); endproperty assert property (p_gate_open_requires_unlocked);这段断言可以在动态仿真中检测非法路径也可以在形式化验证工具中做穷举证明。由于 iverilog 对 SVA 支持有限实际项目建议使用 VCS/Questa 或 Verilator 的断言支持。7.2 LLM 辅助硬件开发的 CheckList团队如果想引入 LLM 辅助硬件开发这份检查清单可以贴在评审会议里是否评估过公司机密数据的外泄风险是否明确了哪些模块可以使用 LLM 生成是否禁止 LLM 直接生成安全关键模块是否要求所有 LLM 生成代码打标签是否在合并前执行了代码审查、仿真和形式化验证是否验证了 LLM 生成代码的复位、默认状态和跨时钟域行为7.3 Chiplet 安全性评估的工程建议在 Chiplet 项目立项时建议安全团队提前介入梳理整条供应链明确每个 Die 的信任等级。建立 Die-to-Die 互连的安全策略例如加密哪些关键数据、哪些数据必须走隔离路径。在项目早期做威胁建模形成安全需求文档再映射到具体的 RTL 或者封装设计。把安全验证加入 sign-off 流程而不是当成流片前的附加项。安全设计的最高原则不是“多上一堆防御机制”而是“清楚地知道威胁在哪并有针对性地控制风险”。Chiplet 时代尤其如此。8. 总结与下一步学习路线这篇文章从 Chiplet 架构、LLM 辅助设计和硬件安全三个维度做了展开并通过一个安全访问控制模块完整走了一遍 RTL 设计、测试平台、防爆破机制和验证思路。核心收获可以归纳为三点Chiplet 改变了硬件系统的信任边界安全设计必须覆盖从 Die 到供应链的整个生命周期LLM 能提升硬件设计效率但安全关键模块不能完全交给他硬件安全设计的落地依赖默认拒绝、状态锁、寄存器级访问控制这些具体机制工程师需要能写出并且能验证它们。下一步可以根据你的兴趣和基础选择学习方向。如果你还不熟悉 Verilog建议先看《Verilog HDLA Guide to Digital Design and Synthesis》这类入门材料把基础语法和仿真流程跑通。如果你对 SoC 总线与安全感兴趣可以继续学习 AXI/AHB 总线协议、NoC 设计以及 TrustZone、安全启动这类架构特性。如果你想深入形式化验证可以从 SymbiYosys 开源工具入手把安全属性改写为可证明的断言。有一个很好的练手路线把本文的 secure_access_gate 模块引入一个简单的 SoC 工程给它配置多个主设备 ID再添加“只允许安全主设备访问密钥寄存器”的过滤规则最后用断言验证非法主设备的所有访问请求都无法通过。做完这个实验你对硬件安全设计的理解会比单纯看文章深刻很多。 Chiplet与LLM时代：硬件安全设计框架与Verilog实践
聊到硬件设计很多人的第一反应是时序收敛、面积功耗、验证覆盖率聊到安全第一反应又是熔断、幽灵、侧信道、供应链攻击。当 Chiplet 把一颗大 SoC 拆成多个 Die 之后安全边界已经不再只是芯片引脚上的信任边界当大语言模型开始帮我们生成 Verilog、写断言、做代码审查时安全问题的源头又多了一个“灰色入口”。这篇文章想把硬件设计、Chiplet 架构、LLM 辅助开发与硬件安全放在一起拆开讲Chiplet 时代硬件架构发生了哪些变化LLM 在硬件设计流程里能做什么、不能做什么以及从寄存器到供应链硬件安全到底应该怎么设计、怎么验证。无论你是硬件工程师、验证工程师还是对体系结构感兴趣的软件开发者这篇文章都会给出一个相对完整的思考框架并附带一个可仿真、可扩展的安全外设访问控制模块示例。1. 背景与核心概念1.1 Chiplet 是什么为什么突然成了主流方向传统上一颗 SoC 采用单片设计所有 CPU 核心、GPU、内存控制器、IO 接口集成在同一颗 Die 上。随着制程演进到 5nm、3nm单片大 Die 的流片成本越来越高良率却越来越低。任何一个小模块出错或者有制造缺陷都可能导致整颗芯片报废。Chiplet 思路是把一颗大芯片拆成多个相对较小的芯片Die再用先进封装技术例如 2.5D 中介层、3D 堆叠把这些小芯片组合成一个完整的系统。每个 Chiplet 可以使用更适合自身功能的制程CPU 用先进逻辑工艺IO 用成熟工艺模拟和射频用特殊工艺再通过 Die-to-Die 互连协议进行通信。这样的好处比较明显提升良率降低大芯片制造风险。复用成熟 IP 模块缩短研发周期。异构集成更灵活可以混合不同来源的芯片颗粒。硬件生态从“单芯片自研”走向“多芯片协作”。但从安全视角来看Chiplet 也带来了新的问题芯片不再来自单一可信代工厂不同 Die 可能来自不同供应商、不同封装厂整条供应链的信任边界被拉长了。后面我们会专门分析这个问题。1.2 LLM 在硬件设计领域扮演的角色大语言模型Large Language ModelLLM在软件领域已经展示了很强的代码生成能力。硬件设计同样是代码密集型工作RTL 设计使用 Verilog、SystemVerilog、VHDL验证环境使用 SystemVerilog 和 UVM综合脚本使用 Tcl约束文件使用 SDC。LLM 在硬件设计中的常见应用包括根据自然语言描述生成 RTL 模块代码。辅助编写 SVA 断言和测试用例。分析波形文件、日志中的常见错误。为已有模块补充文档说明。在代码审查阶段检查状态机、位宽、跨时钟域问题。但需要清醒一点LLM 生成的硬件代码和软件代码一样可能存在“看起来合理但实际有缺陷”的问题而且硬件调试成本远高于软件。一次流片周期通常需要数月一个安全漏洞在流片后暴露代价是重新改版。因此LLM 辅助硬件设计必须走“AI 生成 人工审查 形式化验证”三重路线。1.3 为什么硬件安全是一个独立且重要的领域很多人以为安全只是软件层面的事情操作系统负责权限管理防火墙负责网络隔离加密库负责数据保护。但现代安全体系的底层信任都需要硬件支撑密钥必须存储在硬件中启动镜像必须由硬件信任根校验内存访问隔离需要硬件总线防火墙。硬件安全问题一旦发生影响通常是底层且持久的。例如经典的 Spectre 和 Meltdown 漏洞根源就出在 CPU 的推测执行和缓存架构设计上软件补丁只能缓解无法根治。再比如侧信道攻击攻击者通过功耗、电磁辐射、时间延迟来推断密钥信息这种攻击不依赖软件漏洞而是利用物理实现层面的信息泄漏。在 Chiplet 时代硬件安全还需要考虑多 Die 之间的互连信任、第三方 Chiplet 的恶意逻辑、封装环节的物理篡改等问题。这也是为什么我们要把硬件设计和安全放在一起讨论。2. 硬件设计环境与工具准备2.1 RTL 设计与仿真工具如果你只具备软件背景想开始接触硬件设计建议从 Verilog/SystemVerilog 入手。当前主流的 RTL 设计与仿真工具有以下几类工具类型主要用途备注Icarus Verilogiverilog开源Verilog 仿真简单易用适合入门和快速验证Verilator开源Verilog/SystemVerilog 仿真编译为 C 模型性能好适合大型设计预研VCS / Questa / ModelSim商业仿真与验证工程中广泛使用支持完整 UVM/SVAVivado / Quartus商业FPGA 综合与实现面向 FPGA 平台自带仿真器Yosys开源逻辑综合适用于 FPGA 和教学研究本文的示例模块以 Verilog 编写仿真命令基于 iverilog 和 vvp读者无需商业许可证即可复现。2.2 安全验证与评估工具链硬件安全验证不只是跑一遍功能仿真还需要做以下几类评估功能仿真验证正常功能路径是否满足预期。断言验证用 SVA 描述“必须成立的安全属性”例如解锁状态与外设开启状态之间的因果关系。形式化验证穷举证明安全属性在所有输入组合下都不会被违反。开源项目 SymbiYosys 可以配合 Yosys 使用。故障注入仿真模拟电压毛刺、时钟毛刺、单粒子翻转对安全状态机的影响。功耗与电磁分析需要在硬件实物或者高精度功耗模型上进行通常用于侧信道分析。真实项目中这些工作往往需要专业安全工程师参与。本文重点演示 RTL 安全模块设计与功能仿真阶段的方法读者可以在自己工程中扩展。2.3 版本说明EDA 工具链版本更新很快不同工具对 SystemVerilog 的支持程度也不同。例如 iverilog 目前对 SVA 支持有限VCS/Questa 则支持完整语法。因此本文不对具体版本做硬性绑定示例代码主要使用 Verilog-2001 语法保证在多数环境下可以直接仿真。如果你在实际项目中遇到版本兼容问题建议优先查看工具官方文档而不是盲目升级工具链。3. 核心原理拆解Chiplet、LLM 与硬件安全3.1 Chiplet 设计的几个关键技术点从架构角度看Chiplet 设计有四个关键层次第一是互连协议。Die 与 Die 之间要低延迟、高带宽、低功耗地通信必须依赖统一的互连协议。以 UCIe 为代表的 Die-to-Die 互连标准正在成为行业共识它定义了物理层、协议层和管理层的规范。互连协议本身的安全性至关重要如果互连通道没有鉴权和加密机制恶意的第三方 Chiplet 可能窃听甚至篡改其他 Die 之间的数据。第二是片上网络。多 Die 系统中数据不再只走传统的总线结构而是经常采用 NoCNetwork-on-Chip。NoC 把数据打包成数据包在各个网络节点之间路由。NoC 上的安全策略需要与路由策略联动比如为不同安全等级的数据规划隔离路径。第三是封装与物理集成。2.5D 封装使用硅中介层或有机基板3D 堆叠则把多个 Die 垂直连接。物理上Die 之间的信号走线可能暴露在封装表面攻击者有机会进行探针或者侧信道测量。相比传统单芯片Chiplet 的物理攻击面更大、更分散。第四是系统级信任。传统芯片的信任边界在芯片引脚处只要引脚不暴露给攻击者整体安全相对可控。Chiplet 系统中不同 Die 之间的信任边界是动态的。各 Die 可能来自不同供应商整个系统必须建立一套跨 Die 的身份认证和安全启动机制。3.2 LLM 辅助硬件设计能做什么不能做什么先看 LLM 在硬件设计中的实际落地方式。最直接的是自然语言生成 RTL。比如你输入“写一个 8 位计数器带异步复位和使能信号。”LLM 通常能立刻给出类似下面的代码module counter_8bit #( parameter WIDTH 8 )( input wire clk, input wire rst_n, input wire en, output reg [WIDTH-1:0] count ); always (posedge clk or negedge rst_n) begin if (!rst_n) count {WIDTH{1b0}}; else if (en) count count 1b1; end endmodule这一类标准化模块LLM 生成质量很高能显著提高原型开发效率。更复杂的场景比如内部状态机、跨时钟域处理、安全状态判断LLM 的能力就会明显下降。它不了解你的项目中全局的安全策略、已有的访问控制矩阵、SoC 总线的具体带宽和时序要求也不会主动区分安全模块和普通模块。所以LLM 在硬件设计中的边界可以理解为适合做代码生成、断言初稿、文档整理、代码翻译、常见模式识别。不适合做全自动安全关键模块设计、跨模块全局方案设计、最终代码审查。必须补位的专业工程师 code review、形式化验证、覆盖率分析、安全评估。从安全角度看LLM 还有一个需要警惕的问题如果把公司内部芯片架构、寄存器地址、密钥策略喂给 LLM可能造成敏感信息外泄。很多公司的代码补全工具默认会把代码片段发送到云端模型处理硬件团队在使用前必须和法务、安全部门确认数据合规边界。3.3 硬件安全威胁模型与防护框架硬件安全的威胁模型可以从攻击角度来分类攻击类型攻击手段典型目标防护方向供应链攻击恶意 IP 插入、Die 替换、逻辑篡改后门、木马、功能降级供应商审计、硬件指纹、安全启动物理攻击探针、聚焦离子束FIB、芯片开盖密钥提取、总线窃听屏蔽层、防篡改检测、密钥硬件隔离旁路攻击功耗分析、电磁辐射、时序分析加密密钥恒定时间实现、掩码、功耗均衡故障注入电压毛刺、时钟毛刺、激光注入绕过程序判断、提权电压/时钟监测、冗余计算、状态机锁定软件攻击固件漏洞、驱动漏洞、总线非法访问外设控制、内存读写总线防火墙、访问控制、TrustZone 类隔离针对这些威胁硬件安全设计通常依赖几个基础组件信任根Root of Trust作为系统启动的第一级可信来源通常固化在 ROM 中负责校验后续镜像签名。安全启动Secure Boot从信任根开始逐级验证固件和软件的签名确保只运行可信代码。物理不可克隆函数PUF利用芯片制造过程中的随机差异生成唯一身份标识和密钥根。总线防火墙Bus Firewall在总线层面控制不同主设备对外设和内存的访问权限。安全状态机对安全关键操作增加状态锁定、重试次数限制、故障锁定机制。这些机制最终都要落实到 RTL 设计上也就是本文实战案例要演示的内容。4. 硬件安全实战实现一个带防爆破机制的外设访问控制模块4.1 需求与功能拆解我们来看一个非常典型的硬件安全场景SoC 中有某个安全外设例如安全存储控制器默认情况下必须处于锁定状态不允许外部访问。软件需要先写入正确的密钥才能解锁并且为了防止暴力破解连续错误次数达到上限后模块进入锁定状态必须通过系统复位才能恢复。这是一个贴近真实 SoC 安全设计的小模块虽然逻辑不复杂但包含了几个核心安全思想默认拒绝Secure by Default上电后 gate_open 为 0外设默认不可用。密钥校验解锁需要正确写入 64 位密钥。防爆破连续写错达到 MAX_RETRIES 则进入 LOCKOUT 状态。可恢复系统复位后回到初始锁定状态。状态机完整非法状态回到锁定状态。4.2 RTL 模块实现文件路径src/secure_access_gate.vmodule secure_access_gate #( parameter KEY_WIDTH 64, parameter MAX_RETRIES 3 )( input wire clk, input wire rst_n, // 解锁写入端口 input wire unlock_write_en, input wire [KEY_WIDTH-1:0] unlock_data, // 外设门控控制端口 input wire gate_write_en, input wire gate_ctrl, // 输出门控状态和状态指示 output reg gate_open, output reg [1:0] status ); localparam [KEY_WIDTH-1:0] UNLOCK_KEY 64h5A5A_5A5A_CAFE_F00D; localparam STATUS_LOCKED 2b00; localparam STATUS_UNLOCKED 2b01; localparam STATUS_LOCKOUT 2b10; reg [1:0] state; reg [1:0] retry_cnt; // 64 位密钥比较在硬件中天然是恒定时间的 wire key_match (unlock_data UNLOCK_KEY); always (posedge clk or negedge rst_n) begin if (!rst_n) begin state STATUS_LOCKED; retry_cnt 2b00; gate_open 1b0; end else begin case (state) STATUS_LOCKED: begin if (unlock_write_en) begin if (key_match) begin state STATUS_UNLOCKED; retry_cnt 2b00; end else begin retry_cnt retry_cnt 1b1; if (retry_cnt 1b1 MAX_RETRIES) begin state STATUS_LOCKOUT; end end end end STATUS_UNLOCKED: begin // 解锁状态下允许通过 gate_write_en 打开/关闭外设门 if (gate_write_en) begin gate_open gate_ctrl; end // 允许软件主动上锁写错密钥也会回到锁定状态 if (unlock_write_en !key_match) begin state STATUS_LOCKED; end end STATUS_LOCKOUT: begin // 锁定状态等待系统复位实际芯片可触发安全监控中断 gate_open 1b0; end default: begin state STATUS_LOCKED; end endcase end end always (*) begin status state; end endmodule这个模块有几个设计点值得展开。首先是状态定义。LOCKED 是上电默认状态也是所有非法状态的归位点。UNLOCKED 表示密钥验证通过外设门控寄存器可写。LOCKOUT 表示触发防爆破机制不再接受任何解锁尝试。其次是密钥比较。64 位总线数据与常量直接比较在硬件综合后会形成按位异或树属于恒定时间操作不存在软件中常见的“逐字节提前退出”问题。如果将来要实现更高级的防侧信道设计还需要关注功耗均衡这里先不展开。第三是防爆破逻辑。每次错误尝试retry_cnt加 1当retry_cnt 1 MAX_RETRIES时进入 LOCKOUT。MAX_RETRIES 设为 3因此第三次错误会触发锁定。实际项目中这个值一般是 3 到 8视安防等级而定。第四是故障锁定行为。进入 LOCKOUT 后gate_open被强制拉低即使攻击者持续发送解锁信号也无法打开外设。只有rst_n拉低复位才能恢复。在某些高安全场景中LOCKOUT 状态还会配合安全熔丝一旦触发就永久锁定该外设必须更换芯片。这类逻辑不会写在通用 RTL 里而是由系统安全手册定义。4.3 测试平台验证正常解锁与防爆破流程一个安全模块光能写出来还不够必须验证。下面给出一个基于 iverilog 的 testbench覆盖三条主路径错误密钥三次触发锁定锁定后正确密钥无效复位后正确密钥可以解锁并控制外设门。文件路径sim/tb_secure_access_gate.vtimescale 1ns/1ps module tb_secure_access_gate; reg clk; reg rst_n; reg unlock_write_en; reg [63:0] unlock_data; reg gate_write_en; reg gate_ctrl; wire gate_open; wire [1:0] status; secure_access_gate dut ( .clk (clk), .rst_n (rst_n), .unlock_write_en (unlock_write_en), .unlock_data (unlock_data), .gate_write_en (gate_write_en), .gate_ctrl (gate_ctrl), .gate_open (gate_open), .status (status) ); initial clk 1b0; always #5 clk ~clk; initial begin // 初始化 rst_n 1b0; unlock_write_en 1b0; unlock_data 64h0; gate_write_en 1b0; gate_ctrl 1b0; #10; rst_n 1b1; // 第一次错误密钥 #10; unlock_write_en 1b1; unlock_data 64h00000000_00000001; #10; unlock_write_en 1b0; // 第二次错误密钥 #10; unlock_write_en 1b1; unlock_data 64h00000000_00000002; #10; unlock_write_en 1b0; // 第三次错误密钥应该进入 LOCKOUT #10; unlock_write_en 1b1; unlock_data 64h00000000_00000003; #10; unlock_write_en 1b0; // 此时即使输入正确密钥也无法解锁 #10; unlock_write_en 1b1; unlock_data 64h5A5A_5A5A_CAFE_F00D; #10; unlock_write_en 1b0; // 复位回到 LOCKED #20; rst_n 1b0; #10; rst_n 1b1; // 正确密钥解锁 #10; unlock_write_en 1b1; unlock_data 64h5A5A_5A5A_CAFE_F00D; #10; unlock_write_en 1b0; // 打开外设门 #10; gate_write_en 1b1; gate_ctrl 1b1; #10; gate_write_en 1b0; #20; $finish; end endmodule4.4 运行仿真在命令行中执行iverilog -o tb tb_secure_access_gate.v secure_access_gate.v vvp tb如果你使用商业仿真工具也可以用类似流程加载这两个文件。仿真结束后可以通过$dumpfile和$dumpvars生成 VCD 波形文件再用 GTKWave 查看initial begin $dumpfile(tb.vcd); $dumpvars(0, tb_secure_access_gate); end预期的状态跳转顺序是LOCKED连续三次错误密钥后进入 LOCKOUT。LOCKOUT正确密钥写入也无响应。复位后回到 LOCKED。LOCKED正确密钥写入后跳到 UNLOCKED。UNLOCKED控制 gate_write_en 后 gate_open 拉高。4.5 对安全机制的进一步思考这个模块是一个基础示例距离真实 SoC 的安全设计还有几个明显差距。第一个差距是缺少系统级访问控制。真实 SoC 中外设不会只有一个 gate_open 信号。总线防火墙需要根据主设备 ID、传输地址、读写类型做更细粒度的判断。比如普通 CPU 核可以访问外设但 DMA 控制器不能访问密钥寄存器。第二个差距是缺少复位分类。本模块只有统一复位。真实芯片往往区分上电复位、看门狗复位、安全复位。安全复位可能只清除部分状态而把安全熔丝状态保留。第三个差距是缺少异常上报。进入 LOCKOUT 后模块应能通过中断或者安全告警总线通知安全监控处理器。这些在实际工程中都是必须的。读者可以在本模块基础上扩展增加主设备 ID 过滤、增加安全告警输出、增加错误计数溢出保护。5. Chiplet 与 LLM 场景下的安全实践5.1 Chiplet 供应链安全从单点信任到多方共信单片设计中安全信任根基本上来自同一颗芯片、同一家代工厂。Chiplet 改变了这个前提CPU Die 来自厂商 AIO Die 来自厂商 B加速器 Die 来自第三方 IP 供应商 C。任何一家被攻破都可能影响整个系统。因此Chiplet 时代的安全实践需要覆盖整个生命周期供应商评估对 IP 供应商做代码审计、安全能力评估和持续监控。业界常见的做法是要求供应商提供安全设计白皮书、安全验证报告。交付验证对收到的 Die 做身份验证和功能测试。PUF 指纹和不可擦除的芯片 ID 是基础能力。互连安全Die 之间传输敏感数据时要考虑增加认证和加密机制。虽然这会有面积和功耗开销但安全等级需求应该由系统级威胁分析决定。封装后检测X 射线、扫描声学显微镜等物理检测手段可以在一定程度上发现封装后的物理篡改。需要注意的是供应链安全不是出了安全事故之后再做的事。它必须从选型阶段就开始并在产品生命周期内持续维护。5.2 LLM 辅助硬件设计的安全红线LLM 确实提高了硬件设计效率但也带来了新的安全和管理问题。硬件团队应该注意以下几点第一敏感代码不外传。寄存器手册、安全密钥、内部架构文档都不应该直接粘贴到公开或半公开的 LLM 工具中。企业可以考虑部署私有化模型或者在本地搭建代码补全服务。第二LLM 生成代码必须经过代码审查。相比人类工程师LLM 更擅长生成“看起来完整但缺少边界条件”的代码。比如状态机缺 default、位宽不匹配、异步复位没有同步释放这些在硬件设计中都是致命的。第三给 LLM 的提示词也要安全。不要为了“让模型生成更接近内部设计”的代码把完整的 SoC 安全架构写进提示词。提示词本身应该经过脱敏处理。第四项目负责人应当建立一套“AI 生成代码标记机制”。哪些模块是由 LLM 主要生成的要在代码评审系统中标记出来且安全关键模块不推荐直接使用 LLM 生成的代码合入主干。5.3 从软件安全配置理解硬件安全设计最近社区里经常出现各种软件安全配置问题比如“Spring Security 过滤链配置后接口仍然 401”“Windows Security 设置中心打不开”“MySQL view 的 SQL SECURITY DEFINER 权限报错”。这些问题的排查思路其实和硬件安全设计有很强的类比关系。以 Spring Security 为例它的核心是过滤链。接口为什么未授权大概率是过滤链顺序不对或者匹配路径规则过于严格。对应到硬件设计就是总线防火墙的访问控制列表顺序问题。规则匹配顺序如果错误授权主设备可能被误拦截未授权主设备却可能绕过检查。再看 MySQL 里的SQL SECURITY DEFINER它定义了视图或存储过程在执行时使用定义者的权限还是调用者的权限。如果定义者权限不足即使调用者正确也会报错。在硬件 SoC 中安全外设同样存在类似的“权限归属”问题访问某个安全寄存器时总线是看发起访问的主设备 ID还是看当前 CPU 运行的进程权限如果该判断落在错误的安全域会造成越权访问。还有 Windows Security 设置中心打不开常见原因是安全中心服务和注册表策略异常。硬件中如果安全策略寄存器被意外配置到错误状态同样会导致安全系统功能异常。排查时都要按“服务/模块是否启动 → 配置项是否存在 → 策略是否生效 → 权限是否足够”的路径逐层定位。这些跨领域类比说明一个规律不管软件还是硬件安全设计的第一原则都是“默认拒绝按需放行”。在软件里是白名单在硬件里是上电锁定在软件里是最小权限在硬件里是最小访问窗口。6. 常见问题与排查思路6.1 安全 RTL 设计与验证中的常见问题问题现象常见原因解决思路上电后外设仍然可被访问访问控制模块未接管外设门控信号检查外设门控信号是否有默认值确认 RTL 是否存在路径绕过解锁密钥可以被暴力破解缺少重试次数限制或锁定机制增加 retry_cnt 计数达到阈值进入 LOCKOUT错误密钥到达 MAX_RETRIES 后仍可解锁比较逻辑在非 LOCKOUT 状态仍被执行检查状态机在 LOCKOUT 状态下忽略解锁请求状态机进入非法状态case 分支缺少 default所有状态机必须补 default回到安全状态综合后安全逻辑被优化掉综合工具认为部分逻辑无效或没有设置 preserve 属性在 SDC 或综合属性中标记安全关键模块防止被优化仿真通过但上板失败仿真代码和综合代码行为不一致做综合后仿真Gate-Level SimulationLLM 生成的模块缺少复位逻辑生成代码时没有显式要求复位策略人工审查补复位逻辑增加 testbench 覆盖6.2 安全配置类问题排查通用思路不管查什么问题建议统一按下面顺序排查确认模块是否进入工作状态软件里查服务状态硬件里查状态寄存器。确认配置是否真正写入软件里查配置中心硬件里读返回状态。确认权限是否匹配软件看账号角色硬件看主设备 ID / 安全域。确认策略顺序是否正确软件过滤链顺序硬件 ACL 匹配顺序。确认是否需要复位恢复。这套思路在 Spring Security、数据库权限、操作系统安全设置等场景都适用也和硬件总线防火墙的调试流程高度一致。7. 最佳实践与工程建议7.1 RTL 安全设计规范如果团队要从零建设硬件安全设计能力建议优先落地下面几条规范。第一所有安全关键模块必须使用显式状态机。不要用多个 if-else 拼凑安全状态判断。状态机要有定义良好的状态编码、default 分支和非法状态安全归位策略。第二默认值必须是安全值。所有复位后的寄存器初值尤其外设门控、中断使能、访问控制寄存器应以“禁止”“关闭”“拒绝”为默认值。第三安全上下文要按模块隔离。即使整个 SoC 只有一个 CPU也建议在总线层面划分安全主设备 ID 和非安全主设备 ID。硬件隔离的可靠性高于纯软件逻辑判断。第四关键信号要防止综合优化。对安全关键的门控逻辑、比较逻辑建议在综合脚本中设置 preserve 属性或者使用等价约束避免工具误优化。第五要写安全断言。在验证阶段用 SVA 描述安全属性例如// 安全断言示例外设 gate_open 只有在 STATUS_UNLOCKED 下才能被拉高 property p_gate_open_requires_unlocked; (posedge clk) disable iff(!rst_n) gate_open |- (status STATUS_UNLOCKED); endproperty assert property (p_gate_open_requires_unlocked);这段断言可以在动态仿真中检测非法路径也可以在形式化验证工具中做穷举证明。由于 iverilog 对 SVA 支持有限实际项目建议使用 VCS/Questa 或 Verilator 的断言支持。7.2 LLM 辅助硬件开发的 CheckList团队如果想引入 LLM 辅助硬件开发这份检查清单可以贴在评审会议里是否评估过公司机密数据的外泄风险是否明确了哪些模块可以使用 LLM 生成是否禁止 LLM 直接生成安全关键模块是否要求所有 LLM 生成代码打标签是否在合并前执行了代码审查、仿真和形式化验证是否验证了 LLM 生成代码的复位、默认状态和跨时钟域行为7.3 Chiplet 安全性评估的工程建议在 Chiplet 项目立项时建议安全团队提前介入梳理整条供应链明确每个 Die 的信任等级。建立 Die-to-Die 互连的安全策略例如加密哪些关键数据、哪些数据必须走隔离路径。在项目早期做威胁建模形成安全需求文档再映射到具体的 RTL 或者封装设计。把安全验证加入 sign-off 流程而不是当成流片前的附加项。安全设计的最高原则不是“多上一堆防御机制”而是“清楚地知道威胁在哪并有针对性地控制风险”。Chiplet 时代尤其如此。8. 总结与下一步学习路线这篇文章从 Chiplet 架构、LLM 辅助设计和硬件安全三个维度做了展开并通过一个安全访问控制模块完整走了一遍 RTL 设计、测试平台、防爆破机制和验证思路。核心收获可以归纳为三点Chiplet 改变了硬件系统的信任边界安全设计必须覆盖从 Die 到供应链的整个生命周期LLM 能提升硬件设计效率但安全关键模块不能完全交给他硬件安全设计的落地依赖默认拒绝、状态锁、寄存器级访问控制这些具体机制工程师需要能写出并且能验证它们。下一步可以根据你的兴趣和基础选择学习方向。如果你还不熟悉 Verilog建议先看《Verilog HDLA Guide to Digital Design and Synthesis》这类入门材料把基础语法和仿真流程跑通。如果你对 SoC 总线与安全感兴趣可以继续学习 AXI/AHB 总线协议、NoC 设计以及 TrustZone、安全启动这类架构特性。如果你想深入形式化验证可以从 SymbiYosys 开源工具入手把安全属性改写为可证明的断言。有一个很好的练手路线把本文的 secure_access_gate 模块引入一个简单的 SoC 工程给它配置多个主设备 ID再添加“只允许安全主设备访问密钥寄存器”的过滤规则最后用断言验证非法主设备的所有访问请求都无法通过。做完这个实验你对硬件安全设计的理解会比单纯看文章深刻很多。