企业官网建设流程全解析

芯片设计者正在面对一个从未有过的局面：把多个第三方芯粒（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 和模拟部分用成熟工艺，这样既能优化性能，又能分摊成本和风险。

在具体实现中，芯粒之间的互连标准比较受关注的是 UCIe（Universal Chiplet Interconnect Express）。它定义了物理层、协议层和软件模型，目标是让不同厂家生产的芯粒可以顺利互连。不过，互连协议解决的是通信兼容问题，不是安全信任问题。即使两个芯粒物理上能通信，也不代表它们之间传递的数据是可信的。这是 Chiplet 架构里一个容易被低估的安全缝隙。

2.2 LLM 在硬件设计工具链中的角色

大模型在硬件设计里的角色，本质上是把“自然语言描述”转成“硬件描述语言”或“验证意图”的辅助工具。它并不能完全替代 EDA 工具链中的综合、布局布线、形式化验证等环节。

当前比较常见的使用方式如下：

一个容易出现的误区是：LLM 生成的代码看起来逻辑清晰，就误以为它已经经过验证。实际上，大模型生成的是“符合语法的概率输出”，它可能在状态转移、跨时钟域、异步复位等细节上出错。硬件语言里一个最隐蔽的问题——组合逻辑环路——LLM 可能完全察觉不到，因为代码在语法层面是健全的，只有在静态时序分析或逻辑综合阶段才会暴露。

2.3 硬件安全的核心框架：信任根、安全启动与 D2D 安全

硬件安全与软件安全的根本差异在于：软件安全可以在运行时检测和修补，硬件安全必须在设计和制造阶段提前规划。三个概念必须理解：

信任根（Root of Trust，RoT）。这是硬件中一个绝对可信的最小集合，通常是芯片内部的只读 ROM、熔丝或一次性可编程存储器。信任根存储根密钥和初始信任代码，是整个安全启动链的起点。它的设计假设是：攻击者可能控制 CPU 上运行的任何软件，但无法篡改信任根内部的数据。

安全启动（Secure Boot）。安全启动是一条逐级验证的引链：信任根验证 Boot ROM，Boot 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 生态扩大了攻击面——你不仅担心自己设计的模块里是否存在恶意逻辑，还要担心从外部采购的芯粒里是否存在后门。

针对这个问题，比较务实的做法是建立 SBOM（Software Bill of Materials，软件物料清单）的硬件对应物——HBOM（Hardware 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", encoding="utf-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", encoding="utf-8") as f: json.dump(testpoints, f, ensure_ascii=False, indent=2) 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 <= 1'b0; data_out <= 32'h0; end else if (data_valid) begin if (recv_mac != mac_value) begin secure_error <= 1'b1; // 数据被篡改或来源不合法 end else begin secure_error <= 1'b0; 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 输出直接写进验证计划，导致验证资源被无效用例占用。这里要再一次强调，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，建议先把本文的安全清单过一遍，再决定下一步怎么走。