第二部分：架构与详细设计阶段

第二部分：架构与详细设计阶段

1. 阶段概述与目标

本阶段的目标是将系统需求转化为可执行、可验证、可追溯的详细技术规格 。这是一个从"做什么"到"怎么做"的关键转换阶段，需要硬件、软件、验证、文档团队深度协同，确保所有设计决策都有据可依，且能够完全满足上一阶段建立的系统需求。本阶段产出的质量直接决定了实现阶段的效率和最终产品的可靠性。

2. 核心流程框架与协同设计流

本阶段通过严格的并行设计和评审机制，确保硬件、软件、验证、文档四个维度的设计始终保持同步和一致。下图展示了本阶段的完整设计流，突出了各团队间的交互和依赖关系。
项目经理/系统架构师 硬件架构师 RTL设计工程师 软件架构师 SDK设计工程师 验证架构师 验证设计工程师 技术文档工程师 配置管理 所有团队负责人 所有团队 相关团队 **阶段输入：Gate 1通过的基线化需求包** 获取基线化需求包 (SRS, SAD, IP-XACT等) 提供基线文档 启动硬件微架构设计 启动SDK详细架构设计 启动验证详细计划 启动UM详细章节开发 **并行设计活动（第1-3周）** 1. 制定《芯片微架构设计文档》 2. 制定《硬件设计规范》 3. 更新IP-XACT寄存器描述 4. 制定《时钟/复位/电源架构规范》 5. 制定《DFT设计策略》 传递设计规格 6. 启动RTL模块设计 7. 执行模块级形式验证 1. 制定《SDK详细设计文档》 2. 制定《软件API规范》 3. 制定《驱动层设计规范》 4. 制定《中间件架构设计》 传递设计规格 5. 设计SDK模块接口 6. 制定《模块单元测试计划》 1. 制定《验证详细计划》 2. 设计验证环境架构(UVM) 3. 定义覆盖模型(覆盖组) 传递验证计划 4. 搭建模块级验证环境 5. 开发验证IP(VIP) 1. 制定《UM详细大纲》 2. 撰写《架构概述》章节 3. 准备自动生成素材 (从IP-XACT) 请求技术细节澄清 提供技术解释 par [硬件详细设计流] [软件详细设计流] [验证详细设计流] [文档详细设计流] **关键设计接口对齐（第4周）** 硬件-软件接口对齐会议 （讨论中断、DMA、寄存器映射） 软件-验证用例对齐 （确认关键场景） 验证-硬件可测性对齐 （确认DFT接入点） 完成关键模块RTL设计 执行Lint/CDC检查 完成核心驱动接口设计 制定MISRA C合规计划 完成模块验证环境 编写初始测试用例 完成核心章节初稿 par [详细设计完善（第5-7周）] **设计整合与正式评审（第8周）** 提交《硬件详细设计包》 提交《软件详细设计包》 提交《验证详细设计包》 提交《UM详细设计文档》 组织Gate 2设计评审会议 召开正式设计评审会 提供评审意见 记录评审发现和行动项 指令基线化所有设计文档 创建设计基线 宣布Gate 2通过 进入实现阶段 发出设计修改请求 执行设计修正 重新组织Gate 2评审 alt [评审通过] [评审不通过] 项目经理/系统架构师 硬件架构师 RTL设计工程师 软件架构师 SDK设计工程师 验证架构师 验证设计工程师 技术文档工程师 配置管理 所有团队负责人 所有团队 相关团队

3. 详细设计活动、标准与产出物

3.1 硬件详细设计流程

3.1.1 活动：芯片微架构设计

• 输入：《系统需求规格说明书》（SRS）、《系统架构设计文档》（SAD）、IP-XACT寄存器描述。
• 执行步骤 ：
  1. 模块粒度划分：基于SAD，将系统分解为可独立设计的子模块，定义每个模块的精确功能边界。
  2. 接口详细定义 ：为每个模块定义：
     • 输入/输出信号列表（命名、位宽、方向）
     • 时序要求（建立/保持时间、时钟域）
     • 协议要求（握手、流控）
  3. 微架构决策：对关键路径和复杂功能，评估并选择实现方案（如：选择流水线深度、算法实现方式、存储器架构）。
  4. 性能预算分配：为每个模块分配时序、面积、功耗预算。
• 遵循标准 ：ISO 26262-5（硬件设计）、公司《硬件微架构设计规范》。
• 输出物 ：《芯片微架构设计文档》
  • 内容大纲 ：
    *
    1. 文档控制信息
    • 2. 设计概述（设计目标、主要特性）
    • 3. 顶层模块划分与互连
    • 4. 模块详细规格（每个模块一节）：
      • 4.X.1 功能描述
      • 4.X.2 接口信号定义（信号列表、时序图）
      • 4.X.3 内部架构框图
      • 4.X.4 关键算法/状态机描述
      • 4.X.5 性能预算（时序、面积、功耗）
      • 4.X.6 与系统需求的追溯性（需求ID列表）
    • 5. 全局时钟、复位、电源架构
    • 6. 跨时钟域设计策略
    • 7. 可测性设计（DFT）策略

3.1.2 活动：RTL详细设计与编码

• 输入：《芯片微架构设计文档》、更新后的IP-XACT寄存器描述。
• 执行步骤 ：
  1. RTL模块设计：基于微架构文档，开始编写RTL代码。
  2. 设计规则检查 ：遵循公司《RTL编码规范》，包括：
     • 可综合代码风格
     • 同步设计原则
     • 低功耗设计技巧（时钟门控、电源门控）
  3. 形式验证：对关键控制逻辑（如状态机、仲裁器）进行模块级形式验证，使用工具如JasperGold或VC Formal。
  4. 静态检查：运行Lint检查（如SpyGlass）和时钟域交叉（CDC）检查。
• 遵循标准 ：公司《RTL编码规范》、MISRA RTL 指导原则、ISO 26262-5硬件设计要求。
• 输出物：《RTL设计文档》、RTL源代码、形式验证报告、Lint/CDC检查报告。

3.2 软件详细设计流程

3.2.1 活动：SDK详细架构设计

• 输入：SRS、SAD、《软件需求规格》（来自需求阶段分解）。
• 执行步骤 ：
  1. 驱动层详细设计 ：设计硬件抽象层（HAL）和底层驱动（LLD）。
     • 定义驱动API函数原型
     • 设计中断服务例程框架
     • 定义DMA传输接口
  2. 中间件层设计：设计操作系统抽象层（OSAL）、协议栈接口、库函数。
  3. API设计 ：设计面向应用开发者的API，确保：
     • 一致性（命名规范、参数顺序）
     • 易用性（合理的默认值、清晰的错误码）
     • 可扩展性（版本兼容性考虑）
• 遵循标准 ：ASPICE SWE.1 （软件需求分析）、MISRA C:2012预备设计。
• 输出物 ：《SDK详细设计文档》
  • 内容大纲 ：
    *
    1. SDK架构概述（层次图、数据流图）
    • 2. 驱动层详细设计：
      • 2.1 寄存器访问层设计
      • 2.2 中断管理框架
      • 2.3 DMA控制器驱动设计
      • 2.4 电源管理驱动设计
    • 3. 中间件层详细设计：
      • 3.1 操作系统抽象层接口
      • 3.2 文件系统接口（如适用）
      • 3.3 网络协议栈接口（如适用）
    • 4. API详细定义：
      • 4.1 API分类（初始化、控制、数据、状态）
      • 4.2 每个API的函数原型、参数说明、返回值、错误码
      • 4.3 使用示例伪代码
    • 5. 内存管理策略（堆、栈、缓存配置）
    • 6. 与硬件需求的追溯矩阵

3.2.2 活动：模块接口与单元测试设计

• 输入：《SDK详细设计文档》。
• 执行步骤 ：
  1. 模块接口设计 ：为每个软件模块设计详细接口，包括：
     • 数据结构定义
     • 函数调用序列
     • 错误处理机制
  2. 单元测试设计 ：基于接口设计，制定单元测试计划：
     • 正常功能测试用例
     • 边界条件测试用例
     • 错误注入测试用例
  3. MISRA合规规划：制定代码编写规则，确保符合MISRA C规范。
• 输出物：《模块接口规范》、《单元测试计划》、《MISRA C合规检查清单》。

3.3 验证详细设计流程

3.3.1 活动：验证环境架构设计

• 输入：SRS、《芯片微架构设计文档》、《验证计划》（来自需求阶段）。
• 执行步骤 ：
  1. 验证方法学选择：确定使用UVM、OVM或公司内部方法学。
  2. 验证环境架构 ：设计分层验证环境：
     • 测试层（test）：测试场景
     • 场景层（sequence）：激励序列
     • 环境层（env）：验证组件集成
     • 代理层（agent）：驱动器、监视器、记分板
     • 接口层（interface）：与DUT的物理连接
  3. 验证IP集成：规划需要集成的第三方或内部验证IP。
• 遵循标准 ：UVM方法学指南 、ISO 26262-8（支持过程-验证）。
• 输出物：《验证环境架构设计文档》。

3.3.2 活动：覆盖模型与测试用例设计

• 执行步骤 ：
  1. 覆盖模型定义 ：基于需求，定义：
     • 功能覆盖点：针对每个需求设计覆盖点
     • 代码覆盖目标：行覆盖、条件覆盖、有限状态机覆盖
     • 断言覆盖：关键属性验证
  2. 测试用例设计 ：设计详细的测试用例：
     • 正常功能测试：验证基本功能
     • 边界测试：验证参数边界
     • 错误测试：验证错误处理
     • 性能测试：验证时序和吞吐量
     • 随机测试：使用约束随机验证
  3. 回归测试策略：设计自动化回归测试框架。
• 输出物：《详细验证计划》、《测试用例规格》、《覆盖模型定义》。

3.4 用户手册详细设计流程

3.4.1 活动：用户手册详细大纲设计

• 输入：SRS、SAD、SDK详细设计文档。
• 执行步骤 ：
  1. 受众分析：识别主要读者（硬件工程师、嵌入式软件工程师、系统集成工程师）。
  2. 内容结构设计 ：设计详细的章节目录，确保覆盖：
     • 产品概述
     • 硬件架构详解
     • 软件架构与API参考
     • 应用示例
     • 调试指南
     • 附录（寄存器映射、电气特性）
  3. 写作风格确定 ：根据IEC/IEEE 82079标准，确定：
     • 术语一致性
     • 语气（指导性而非描述性）
     • 示例代码风格
• 输出物：《用户手册详细大纲与写作规范》。

4. 阶段关键交付物清单（Gate 2评审对象）

所有交付物必须使用公司标准模板，在配置管理工具中创建基线，并通过电子签核流程。

1. 《芯片微架构设计文档》 - 含模块详细规格和需求追溯
2. 《硬件设计规范》 - 含RTL编码规则、DFT策略、时钟复位规范
3. 《更新后的IP-XACT寄存器描述文件》 - 包含所有寄存器详细定义
4. 《SDK详细设计文档》 - 含驱动层、中间件、API详细设计
5. 《软件API规范》 - 面向用户的完整API定义
6. 《验证详细计划》 - 含测试用例、覆盖模型、环境架构
7. 《用户手册详细大纲与写作规范》
8. 《设计评审检查表》 - 各团队完成的自检清单
9. 《阶段评审报告》 - 记录Gate 2评审结果与所有行动项

5. 出口标准（Gate 2通过准则）

1. 完整性：上述9项交付物全部完成，符合模板要求，并已签署基线化。
2. 一致性：硬件微架构、SDK设计、验证计划、文档大纲之间保持严格一致，所有接口定义无歧义。
3. 可追溯性 ：
   • 每个硬件模块设计都能追溯到对应的系统需求
   • 每个软件API都能追溯到对应的硬件功能需求
   • 每个测试用例都能追溯到对应的验证需求
4. 可验证性 ：
   • 所有设计都包含明确的验证计划
   • 覆盖模型能够完整覆盖需求
   • RTL设计已通过初步的静态检查
5. 合规性 ：
   • 硬件设计符合安全标准要求（如ISO 26262）
   • 软件设计已规划MISRA C合规路径
   • 文档设计符合IEC/IEEE 82079标准
6. 协同就绪 ：
   • 硬件-软件接口已正式对齐并记录
   • 验证环境已准备好接收首版RTL
   • 文档编写已获得足够的技术输入
7. 风险可控：所有识别的技术风险都有相应的缓解计划。
8. 行动项闭环：评审会议产生的所有行动项均有明确负责人与完成日期。

只有满足以上全部标准，Gate 2才被视为通过。任何例外都必须获得变更控制委员会的正式豁免批准。此阶段的产出构成了实现阶段的"施工蓝图"，任何后续变更必须通过正式的工程变更请求（ECR）流程。