芯片设计者正在面对一个从未有过的局面把多个第三方芯粒Chiplet拼到一起像搭乐高一样构造一颗大芯片同时拿着大模型生成的 RTL 代码考虑要不要直接放进工程主干。两者听起来都很高效但叠加在一起出现了一个容易被忽略的问题——安全边界变了。传统 SoC 的安全模型建立在“一颗芯片一家代工一套信任根”之上。而 Chiplet 的引入把多个来源、多套工艺、多个知识产权的芯粒集成在一起信任问题从单点变成了一张网。大模型又把原来的代码审查、验证、设计流程变成了“AI 辅助生成 人工复核”的新模式。模型输出的代码是否可信是否引入了隐藏的结构性缺陷会不会成为旁道攻击的入口这些问题在今天的硬件设计流程里还没有成熟答案。这篇文章想讲清楚的正是 Chiplet 和 LLM 两个变量同时影响硬件设计时安全到底发生了哪些变化哪些坑是真实存在的以及工程上如何落地信任根、安全启动、访问控制和 LLM 代码审查。它会用一个可执行的最小实验流程把一个“LLM 辅助 安全检测”的 RTL 审查环境搭起来帮助你理解安全在芯片设计流程中的具体位置。1. 这篇文章真正要解决的问题Chiplet、LLM 与安全为什么必须放在一起看很多人会把 Chiplet、LLM、硬件安全拆成三个独立领域来看Chiplet 是封装和架构问题LLM 是设计效率问题安全是攻防问题。但这种拆分在今天的工程实践中已经行不通了。一颗 Chiplet 芯片的诞生流程通常是这样的设计团队从 A 公司买一个计算芯粒从 B 公司买一个 IO 芯粒从 C 公司买一个安全控制芯粒自己设计一个加速芯粒最后通过 UCIe 或自定义 D2D 接口连在一起。每个芯粒都有自己的固件、安全能力和信任假设。如果底层芯粒的安全能力很弱即使上层软件做得再好整颗芯片的信任链依然存在缺口。这已经不是在“设计一颗芯片”而是在“集成一支有各自安全边界的组件队伍”。与此同时LLM 正在进入芯片设计工具链。从公开讨论和行业实践看目前使用最多的场景有三个自然语言生成 RTL 代码、辅助生成测试用例、解释复杂仿真波形。这个趋势节约了重复劳动但也带来了新的不确定性。芯片设计与普通软件有一个根本区别软件发布后可以通过补丁修复问题而芯片一旦流片硬件阶段引入的结构性缺陷几乎无法修复只能通过后续改版承担高昂成本。因此当 LLM 生成的代码进入芯片设计流程时必须有比软件工程更严格的审查机制。从这个背景看真正的核心问题不是“Chiplet 好不好”或“LLM 能不能写 Verilog”而是在引入 Chiplet 和 LLM 之后硬件设计者如何重新定义信任边界并确保整条链路的安全可控。这篇文章适合芯片设计工程师、FPGA 开发者、嵌入式安全工程师以及正在尝试用大模型辅助硬件设计的团队阅读。读完以后你会得到一套判断框架和一组工程实践而不是一堆零散概念。2. 基础概念Chiplet、LLM 辅助设计与硬件安全在进入实践之前先把三个关键概念讲清楚否则后面看到代码和配置时容易产生误解。2.1 Chiplet从单片 SoC 到芯粒集成Chiplet 的中文常被称为“芯粒”或“小芯片”。它的核心思想是把原来一颗完整的大规模 SoC 拆分为多个功能相对独立的小芯粒再通过先进封装技术如 2.5D/3D 封装、硅中介层重新组合在一起。传统 SoC 设计追求的是在单一裸片上集成更多功能。随着工艺制程推进到 5nm、3nm单片大芯片的开发成本和良率压力越来越大。Chiplet 的立场是与其把所有功能挤在一块大芯片上不如按功能分成几个中等尺寸的芯粒每个芯粒选择合适的工艺再通过高速互连通信。比如计算逻辑用先进工艺IO 和模拟部分用成熟工艺这样既能优化性能又能分摊成本和风险。在具体实现中芯粒之间的互连标准比较受关注的是 UCIeUniversal Chiplet Interconnect Express。它定义了物理层、协议层和软件模型目标是让不同厂家生产的芯粒可以顺利互连。不过互连协议解决的是通信兼容问题不是安全信任问题。即使两个芯粒物理上能通信也不代表它们之间传递的数据是可信的。这是 Chiplet 架构里一个容易被低估的安全缝隙。2.2 LLM 在硬件设计工具链中的角色大模型在硬件设计里的角色本质上是把“自然语言描述”转成“硬件描述语言”或“验证意图”的辅助工具。它并不能完全替代 EDA 工具链中的综合、布局布线、形式化验证等环节。当前比较常见的使用方式如下使用层次输入输出典型场景代码生成自然语言设计描述Verilog/VHDL 代码小模块状态机、简单接口逻辑验证辅助设计文档、RTL 代码测试用例列表、断言建议UVM 测试点生成、覆盖率分析调试解释仿真日志、波形摘要缺陷定位建议FIFO 溢出、时序违例排查安全预审RTL 代码片段潜在安全风险清单未初始化寄存器、越界访问、密钥硬编码一个容易出现的误区是LLM 生成的代码看起来逻辑清晰就误以为它已经经过验证。实际上大模型生成的是“符合语法的概率输出”它可能在状态转移、跨时钟域、异步复位等细节上出错。硬件语言里一个最隐蔽的问题——组合逻辑环路——LLM 可能完全察觉不到因为代码在语法层面是健全的只有在静态时序分析或逻辑综合阶段才会暴露。2.3 硬件安全的核心框架信任根、安全启动与 D2D 安全硬件安全与软件安全的根本差异在于软件安全可以在运行时检测和修补硬件安全必须在设计和制造阶段提前规划。三个概念必须理解信任根Root of TrustRoT。这是硬件中一个绝对可信的最小集合通常是芯片内部的只读 ROM、熔丝或一次性可编程存储器。信任根存储根密钥和初始信任代码是整个安全启动链的起点。它的设计假设是攻击者可能控制 CPU 上运行的任何软件但无法篡改信任根内部的数据。安全启动Secure Boot。安全启动是一条逐级验证的引链信任根验证 Boot ROMBoot ROM 验证引导加载程序引导加载程序验证操作系统内核。每一级都把前一阶段的信任向后传递。只要信任根不被攻破启动链上的代码都经过签名验证。D2D 安全。这是 Chiplet 架构中的特殊问题。芯粒之间的数据通路是裸露的高速接口攻击者可以通过恶意芯粒、探针或中间人方式截获、篡改芯粒间数据。D2D 安全需要保证传输数据的完整性、真实性和机密性常见手段包括加解密、MAC消息认证码、访问控制列表。这三个概念将贯穿后续内容是判断 Chiplet 和 LLM 安全问题的基本坐标。3. Chiplet 时代的安全信任边界发生了什么变化理解了基础概念后再看 Chiplet 引入的具体安全冲击。传统单片 SoC 的安全假设是“整个芯片由同一家设计、同一家制造”而 Chiplet 把这个假设完全打破了。以下四个维度的变化最值得关注。3.1 多供应商信任问题在 Chiplet 生态中一颗芯片往往集成多个供应商的芯粒。每个供应商的安全水平不同资产管理方式不同甚至固件更新策略也不同。设计团队必须对每个芯粒来源做安全评估这个芯粒的供应链可信吗它的固件签名机制是什么如果某个供应商的系统被攻破是否会导致整个芯片的信任链崩溃跟软件领域的第三方依赖非常像。你在代码里用了很多开源库一旦某个库传来恶意更新整个应用的安全性都会被波及。Chiplet 的“第三方依赖”是物理级的你的 SoC 里集成了别人的硬件 IP这个 IP 的漏洞很难通过软件补丁修复。从工程角度看芯片设计团队应该建立芯粒供应商的安全评级台账要求供应商提供安全白皮书、固件更新机制和漏洞报告渠道。不能因为一个芯粒功能满足需求就直接集成还需要评估它在安全体系里的角色。3.2 D2D 通信的完整性与真实性风险芯粒间通信是 Chiplet 架构最关键的物理链路。数据在芯粒间高频传输如果缺少完整性校验恶意模块可以篡改数据。如果缺少真实性校验伪造模块可以冒充合法发送方。这里可以类比云平台入口的 Bot 管理策略。在 Web 系统中异常流量会在访问后端服务之前先经过 Bot 检测和拦截在芯粒网络中一个芯粒向另一个芯粒发出的请求也应该经过类似的访问控制和完整性校验而不是等到数据被消费之后才发现异常。D2D 通信防护通常包括三件事一是建立会话级密钥确保只有授权的芯粒才能参与通信二是在每个数据包上附加 MAC 值确保数据在传输中未被篡改三是根据安全策略配置访问控制列表限制每个芯粒能访问的地址空间和资源。3.3 供应链安全与硬件木马硬件木马是指在芯片设计或制造过程中被恶意植入的微小电路它可以静默地改变芯片行为例如降低加密强度、泄露数据或触发拒绝服务。传统单片 SoC 已经受到硬件木马威胁而 Chiplet 生态扩大了攻击面——你不仅担心自己设计的模块里是否存在恶意逻辑还要担心从外部采购的芯粒里是否存在后门。针对这个问题比较务实的做法是建立 SBOMSoftware Bill of Materials软件物料清单的硬件对应物——HBOMHardware Bill of Materials。对每一颗集成的芯粒记录它的供应商、版本、安全配置、授权用途和更新策略。当供应链上游出现安全事件时能够快速定位哪些芯片受到影响。3.4 安全启动在异构芯粒中的难题传统 SoC 的安全启动是一组固定的 Bobt ROM 到 OS 的链条。Chiplet 架构中每个芯粒可能有自己独立的启动顺序和验证机制。它们之间可能存在互相等待的启动依赖也可能存在安全能力不对等。一个实际场景是主计算芯粒启动很快它需要访问一个 IO 芯粒的加密引擎但那个 IO 芯粒仍在启动过程中尚未建立安全服务。这里的安全风险在于主计算芯粒可能选择“先启动后安全”的策略在 IO 芯粒的安全服务准备好之前就通过不安全的接口传输数据。正确的做法是让启动流程具备安全等待机制所有芯粒完成可信状态确认后再允许业务数据流通。因此Chiplet 环境下的安全启动不再是一条直线而是一张多节点并行的启动网。设计者需要定义主信任关系、从信任关系和跨芯粒授权方式。4. LLM 给硬件安全带来的机会与风险LLM 对硬件设计的影响会直接传导到安全领域。机会是明显的它能把安全设计规范快速转换为代码和测试点能辅助找出潜在的密钥硬编码、越界访问等问题。但风险同样需要正视。4.1 LLM 提升硬件安全效率的三个层次第一层安全代码生成。把安全设计规范转成 Verilog/SystemVerilog 模板例如 Trinity 的状态机模板、安全寄存器访问控制逻辑。这可以省去大量重复抄写。第二层验证测试点生成。给定一个 RTL 模块让 LLM 根据功能和安全要求生成测试点列表比如“未授权访问是否被拒绝”“异常复位后寄存器是否恢复默认值”“敏感数据是否从未加密通路经过”。这些测试点有助于验证工程师查漏补缺。第三层安全问题解释。当静态安全检查工具输出难以理解的报告时让 LLM 结合 RTL 代码解释问题发生路径给出修改建议。这能显著降低分析门槛。4.2 LLM 做安全审查时的典型误判不过用 LLM 做安全审查要格外小心。它擅长的是模式识别而不是逻辑证明。芯片安全里许多问题需要精确的状态空间分析LLM 不具备这种能力。举几个典型误判场景场景一LLM 审查一段带有密钥修复逻辑的 RTL发现代码里出现硬编码字符串直接判定为密钥泄露。但实际上该字符串只是在测试模式下使用并且综合时会通过宏开关去掉。LLM 没有综合上下文无法判断这是真实漏洞还是测试痕迹。场景二LLM 看到一个寄存器没有被显式复位警告存在未初始化风险。但该寄存器可能位于一条启用时才可见的数据路径上且上游逻辑保证数据先写后读。LLM 不一定能推理出这个跨模块的数据流约束。场景三LLM 不理解时钟域交叉的同步器结构把合法的两级触发器同步器误报为跨时钟域缺陷或把不安全的单级同步器漏报。因此工程上的纪律是LLM 的安全审查结果只能作为候选问题清单必须经过 EDA 工具的静态检查、动态仿真、形式化验证来确认。4.3 LLM 工具链自身的供应链风险大模型本身也是供应链节点。无论使用商用闭源模型还是开源模型都需要考虑三个问题一是训练数据是否包含敏感设计信息。如果你把公司内部的核心 IP 代码复制到云端对话接口这些数据可能被记录和用于模型训练。硬件 IP 是比软件源码更需要保护的资产一条 RTL 逻辑可能就是一项专利的核心。二是模型推理过程不透明。你无法得知模型生成这段代码时参考了什么数据源也不知道它是否复制了某个开源项目里带安全漏洞的旧代码。三是模型输出可能包含“幻觉”它会生成看起来合理但并不存在的寄存器名、协议字段或 IP 调用方式。硬件设计里一个错误的寄存器地址轻则导致功能异常重则破坏总线安全隔离。解决方案是将 LLM 部署在私有化环境或公司内部网关中对涉及核心 IP 的代码进行脱敏处理设置严格的权限审计并且永远把模型输出当成“外部意见”而非“可信结果”。5. 落地实践搭建一个“LLM 辅助 安全检测”的硬件设计环境现在把前面讲的框架转成实际操作。这一节会搭建一个最小可复用的流程用 LLM 对 RTL 代码做安全预审再用静态检查规则对候选问题进行筛选最后生成安全验证测试点。整个过程可以在本地开发环境中运行。5.1 环境准备与前置条件建议准备以下环境具体版本以当前项目实际情况为准Linux 环境或支持 Docker 的 macOS/Windows 环境Python 3.9 以上版本Verilog/SystemVerilog 语法解析工具如 Verilator、Icarus Verilog一个可以通过本地 API 端口访问的 LLM 服务可以是私有化部署的开源模型也可以是公司内部网关使用 LLM 服务时请确认该服务的部署位置和访问权限避免将敏感 RTL 代码发送到不受控的外部服务。下面以本地网关为例说明调用方式。5.2 用 LLM 接口对 RTL 代码做安全预审先编写一个 shell 脚本把 RTL 文件内容发送给本地 LLM 服务请它输出安全风险候选清单。为了减少幻觉提示词要限定输出格式并明确要求“只找问题不重写代码”。# 文件路径scripts/llm_security_review.sh #!/bin/bash # 用法./scripts/llm_security_review.sh path/to/module.sv RTL_FILE$1 RTL_CONTENT$(cat $RTL_FILE) read -r -d PROMPT EOF 你是一名硬件安全审查助手。请审查下面这段 RTL 代码。 要求 1. 只列出安全问题不要重写代码。 2. 按以下 JSON 格式输出 {issues: [{severity: high|medium|low, description: 问题描述, line_hint: 行号或模块名}]} 3. 如果未发现明确问题输出 {issues: []} 4. 要特别关注未初始化寄存器、密钥硬编码、缺少同步的跨时钟域信号、未授权的寄存器访问路径。 RTL 代码如下 $RTL_CONTENT EOF curl -s -X POST http://127.0.0.1:8080/v1/chat/completions \ -H Content-Type: application/json \ -d $(jq -n --arg p $PROMPT {model: local-llm, messages: [{role: user, content: $p}], temperature: 0.2})这个脚本通过curl调用本地大模型服务把 RTL 文件和审查要求一起发送给模型然后输出 JSON 格式的候选问题清单。5.3 静态安全检查与规则配置LLM 输出的候选问题需要一个机器规则来筛选。工程上可以建立一个安全规则配置文件把硬件设计中的常见问题固化成检查项再结合现有 lint 工具执行。# 文件路径config/security_lint_rules.yaml rules: - id: NO_HARDCODED_SECRET description: 禁止在 RTL 中硬编码密钥或敏感常量 pattern: assign.*key|parameter.*PASSWORD|localparam.*SECRET - id: CLOCK_CROSSING description: 跨时钟域信号必须经过同步器 pattern: always_ff.*posedge clk_a.*data_from_clk_b|domains: clk_a, clk_b - id: RESET_INIT description: 复位后寄存器必须进入已知状态 pattern: always_ff.*negedge reset_n|no_reset - id: ACCESS_CONTROL description: 安全寄存器访问必须检查权限位 pattern: reg_bank.*write_en|if !(apb_prot.*ack)这个 YAML 配置文件并不是某个特定 EDA 工具的官方 schema而是一个团队内部的规则约定。实际项目中可以把这些规则映射到 Verilator 的 lint 配置、SpyGlass 或开源 Verible 风格的规则中。5.4 生成安全测试点清单获得模型输出和安全规则匹配结果后下一步是用 Python 脚本把它们整理成可执行的安全测试点清单供验证团队使用。# 文件路径scripts/gen_testpoints.py import json import sys def load_llm_issues(path): with open(path, r, encodingutf-8) as f: data json.load(f) return data.get(issues, []) def map_to_testpoints(issues): testpoints [] for issue in issues: severity issue.get(severity, medium) description issue.get(description, ) hint issue.get(line_hint, ) tp { testpoint: f验证 {description} 的相关路径是否被有效阻断, severity: severity, source_hint: hint, type: negative_test, } testpoints.append(tp) return testpoints if __name__ __main__: issues load_llm_issues(sys.argv[1]) testpoints map_to_testpoints(issues) with open(testpoints_security.json, w, encodingutf-8) as f: json.dump(testpoints, f, ensure_asciiFalse, indent2) print(f已生成 {len(testpoints)} 条安全测试点)运行流程是先执行llm_security_review.sh保存模型输出再运行gen_testpoints.py生成测试点 JSON。这些测试点进入验证团队的管理系统后会被转换为 UVM 用例或定向测试用例。6. 安全启动与信任链的工程实现芯片级安全设计的落地不能只停留在审查阶段。还需要从架构上构建信任链。这里演示安全启动配置和 D2D 完整性校验的简化实现思路。6.1 安全启动的流程设计安全启动的流程可以概括为四个阶段信任根校验 Boot ROM、Boot ROM 校验引导程序、引导程序校验内核、内核确认后的安全服务启动。在 Chiplet 场景中每个芯粒都需要声明自己的启动状态。下面是一个简化的启动状态配置文件# 文件路径config/secure_boot_chain.yaml boot_chain: root_of_trust: source: rom_fuse key_store: fuse_mac stage1_bootloader: signature_verification: true hash_algorithm: sha384 expected_digest: 从安全服务器获取或写入芯片配置 stage2_loader: signature_verification: true allowed_kernel: [linux-6.6.sec, rtos-2.1.sec] chiplet_sync: wait_for_all_trusted: true max_wait_cycles: 10000 timeout_policy: abort_boot这个配置传递了一个核心信号Chiplet 启动必须等待所有芯粒完成可信状态确认而不是“谁先启动谁先用”。若某个芯粒在超时周期内未完成验证系统应中止启动避免进入不安全状态。6.2 D2D 通信完整性校验示例D2D 通信的完整性通常用对称密钥 MAC 实现。下面是一段 SystemVerilog 风格的简化代码目的是展示如何在数据包发送前计算 MAC、在接收端验证 MAC。实际工程中 MAC 计算通常由专用加密硬件加速模块完成这里仅演示接口逻辑。// 文件路径rtl/d2d_secure_link.sv片段 module d2d_secure_link import pkg_d2d::*; ( input logic clk, input logic rst_n, input logic [31:0] data_in, input logic data_valid, output logic data_ready, output logic [31:0] data_out, output logic secure_error ); logic [127:0] session_key; logic [31:0] mac_value; logic [31:0] recv_mac; // 对应数据包中携带的 MAC 字段 // 简化示意发送端计算 MAC hmac_sha256 mac_calc ( .key(session_key), .data(data_in), .mac(mac_value) ); // 接收端比较若 MAC 不匹配则产生安全错误 always_ff (posedge clk or negedge rst_n) begin if (!rst_n) begin secure_error 1b0; data_out 32h0; end else if (data_valid) begin if (recv_mac ! mac_value) begin secure_error 1b1; // 数据被篡改或来源不合法 end else begin secure_error 1b0; data_out data_in; end end end endmodule这段代码的实际功能是在芯粒间传输的每个数据包上追加 MAC 值。接收端用同一会话密钥重新计算 MAC与收到的值比较不一致即产生安全错误。该逻辑虽然忽略了包序号、重放保护等细节但体现了 D2D 安全的核心思想——先验证后处理。6.3 运行与验证方法在有 Verilator 或 VCS 的环境下把该文件编译成仿真模型并用一个简单的 testbench 分别输入正确和错误的 MAC观察secure_error是否按预期拉高。验证命令参考verilator --lint-only -Wall rtl/d2d_secure_link.sv python3 -m pytest test_secure_link.py如果收到“信号未声明”的报错请先确认模块头部已经include对应的包文件。如果 MAC 比较逻辑在仿真中不生效优先检查data_valid和mac_value的时序关系确认 MAC 在数据有效期间已经完成计算。7. 常见问题与排查思路在实际搭建这套流程时最容易遇到的几个问题如下问题现象可能原因排查方式解决方案LLM 返回 JSON 格式错误模型生成了多余文本或注释查看完整响应内容确认是否被提示词限制改用结构化输出解析或对响应做子串提取后再 json.loads静态规则误报过多YAML 规则 pattern 过宽对照 RTL 模块逐条确认细化规则增加白名单或排除注释安全启动卡在等待超时某个芯粒未完成信任状态验证检查每个芯粒的 boot_status 寄存器调整启动时序延长等待窗口或优化芯粒固件启动路径D2D 链路持续报 secure_error会话密钥不一致或 MAC 计算接口时序错误添加仿真波形检查密钥加载和数据有效信号统一密钥分发流程确保各芯粒使用相同的会话密钥模型返回的安全建议与 RTL 实际不符LLM 不理解综合和物理实现上下文将宏定义和约束文件一并提供给模型让工具发挥“候选问题发现”作用用 EDA 工具二次确认还有一个反复出现的问题是团队把 LLM 输出直接写进验证计划导致验证资源被无效用例占用。这里要再一次强调LLM 输出是候选信息不是验证结论。8. 最佳实践与工程建议结合前文的概念与实验整理几条硬件设计场景下的最佳实践。8.1 安全优先的架构决策在项目早期就要确定信任根属于哪颗芯粒、安全启动的等待策略是什么、D2D 通信的密钥如何分发。把这些决策写进架构设计文档而不是等流片前才发现安全无法覆盖。芯片不比软件后期补安全的能力非常有限。建议为每个 Chiplet 芯片建立一份“安全责任矩阵”明确每个芯粒在信任链中的角色、需要满足的安全属性和对应的验证责任人。矩阵表格可以用团队共享文档管理并自动关联到缺陷追踪系统。8.2 LLM 辅助开发的约束纪律使用 LLM 时建议制定以下团队纪律核心 IP 代码不上传外部模型服务只使用私有化部署或内网网关。LLM 生成代码必须经过 lint、仿真、形式化验证后才能合入代码仓库。LLM 生成代码必须保留提示词、模型版本和生成时间等信息用于追溯审计。LLM 审查报告只能作为候选问题清单不得直接作为安全漏洞提交依据。这四条纪律如果做不到LLM 带来的效率提升会被随后出现的返工成本完全抵消。8.3 供应链与配置管理Chiplet 生态中HBOM 是安全审计的重要抓手。建议从第一个芯粒选型开始就记录供应商、版本、许可证、已知漏洞和更新渠道。同时把每个芯粒的固件版本纳入统一配置管理确保芯片出厂后的安全补丁能够准确对应到每一批硬件。在 CI/CD 流程中可以加入“供应链扫描”任务定期检查 HBOM 与已知漏洞库的匹配情况。如果某个芯粒在发布后暴露出安全问题设计团队要能快速定位到哪些产品受影响、需要如何升级固件或硬件改版。8.4 生产环境的监控与安全更新芯片出厂后安全工作并没有结束。对部署在边缘设备、自动驾驶系统或云服务器中的 Chiplet 芯片应保留运行状态监控能力例如安全事件日志、芯粒间通信错误计数、启动链完整性状态上报。这些监控数据可帮助运营团队尽早发现异常芯粒或恶意攻击行为。同时要建立固件和微码的安全更新通道。Chiplet 中相当一部分逻辑由微码和配置寄存器控制当发现或 D2D 高层安全漏洞时可以通过更新微码临时缓解为硬件改版争取时间。8.5 验证工作的双轨制推荐把验证拆成两条轨道一条是功能验证强调模块是否按设计规格工作另一条是安全验证强调在异常输入、越权访问、故障注入场景下模块是否仍然安全。两条轨道的测试点在早期可以分开但报告应当统一汇总。安全验证的典型用例包括非法总线事务、寄存器越权读写、篡改数据包、无效签名启动等。9. 总结与下一步Chiplet 把硬件从“单芯片信任”带进了“多芯粒组网信任”LLM 则把硬件设计从“纯人工推导”推进到“人机协同生成”。这两个趋势同时出现让安全从一种验证环节升级成了架构级约束。这篇文章讲清楚了三个层次的问题Chiplet 为什么重构了信任边界LLM 在硬件安全中的价值和边界以及如何在工程中落地安全启动、D2D 校验和 LLM 辅助安全审查。建议你下一步先从一个内部模块开始把文中的 LLM 安全预审脚本跑通再把它接到现有的 lint 和仿真流程里逐步形成团队自己的硬件安全测试基线。在真实的芯片开发中安全与效率往往互相拉扯。Chiplet 和 LLM 都指向更高的设计效率但安全这条底线永远不能因为效率而让步。如果你的团队正准备引入 Chiplet 架构或正在大范围使用 LLM 生成 RTL建议先把本文的安全清单过一遍再决定下一步怎么走。