共同设计协作与设计版本管控 (DVC: Design Version Control)

—— 让团队永远在同一份版本上协作
     - 提供**统一的设计树结构**，约定 phase / block / stage / version 等层次。  
     - 与 SVN/Git 等版本工具集成，在其之上补充**与芯片设计流程相关的语义**。  
     - 让每一次关键修改都形成**可追溯的版本记录**（时间、作者、变更说明等）。

在采用共同设计协作模式进行 ASIC/SoC 设计时，一个项目往往会同时经历：

  • 多个设计阶段（试验版、稳定版、最终版）
  • 多个功能模块并行开发
  • 多个地点、多角色工程师同时参与

如果只依赖「人工约定」和「各自维护的目录结构」，很容易出现：

  • 不同人手上拿着不同版本的设计资料
  • 某个版本被修改过，却找不到变更记录
  • Tapeout 或 CID 审查时，无法确认哪一版才是“正式”版本

这些问题不会立刻爆炸，但会通过反复 ECO、反复签核，慢慢变成项目的时间与风险成本。

DVC（Design Version Control） 设计的目标，是在不打乱现有 SVN/Git 使用习惯的前提下：

为芯片设计资料建立一套统一、可追踪、与设计流程紧密对齐的版本管理体系。

它不替代底层的版本控制系统，而是作为其之上的一层**「设计版本语义」与目录规范**，让团队可以用「设计语言」来谈版本，而不是只记一串仓库路径和 revision 号。

DVC 在 DOP 中的定位

在 DOP 的四个子系统中：

  • DVC 负责回答： 现在团队到底在用哪一版设计资料？它处在项目的哪个阶段？
  • DQI 负责回答： 这一个版本的质量状况如何？能不能作为后续工作的输入？
  • DFA 负责把已有的版本与质量检查，串成可复现的自动化流程。
  • TLM 负责保证使用的 PDK、库、IP 等技术资料也是受控版本。

因此，DVC 是 DOP 的起点：
只有先把「版本」讲清楚，DQI 的质量指标、DFA 的流程自动化，才有可靠的锚点。

在典型项目中，推荐的部署顺序是：

  • 先建立 DVC 目录结构与基本命名规则
  • 再在 DVC 版本基础上，接上 DQI 质量指标
  • 最后再将常用设计步骤固化为 DFA 流程

统一的设计数据四层结构

为避免每个项目、每位工程师各自发明目录规则，DVC 规定了一套四层次的设计数据结构，用来统一表达设计进展与版本关系。

  1. 设计阶段层（Phase Layer）
    反映项目在整体上的推进阶段，例如：
    • trial：试验阶段
    • stable：稳定阶段
    • final：最终签核阶段
  2. 设计模块层（Block Layer）
    按功能模块或层级划分设计，如：cpu、usb、ddr 等。
    设计师可以在这一层进行模块拆分和责任分工。
  3. 工作阶段层（Stage Layer）
    对应设计流程中的关键环节，例如：
    • 000-DATA：输入数据准备
    • 200-SYN：综合
    • 400-APR：布局布线
    • 800-SIGNOFF：签核等
  4. 版本层（Version）
    每一次重要变更形成独立版本，例如：
    2025_0618-init、2025_0720-fix-ddr 等，
    通常包含时间标签与简要说明，便于追踪。
DVC阶层结构范例


通过按照DVC提供的统一设计数据目录结构进行设计数据的管理，团队成员可以轻松地探索设计数据并跟踪设计历史，内置版本控制机制。DVC数据管理的一个重要特点是，它可以向用户建议每个设计阶段所需的正确输入数据。当与DFA Ticket执行机制结合时，DFA Flow可以自动选择正确的设计资料版本。这减少了使用错误数据版本的机会。

DVC工作阶段

 

通过这样的结构，任何一份设计资料都可以用一条清晰的路径来标识：
ex: testcase / P3-final / cpu / 400-APR / 2025_0720-fix-ddr

工程师只要看到路径，就能快速判断这份资料：

  • 是哪一次修改、由谁在什么时候提交
  • 属于哪个项目 / 阶段
  • 属于哪个模块 / 哪个工作阶段

DVC 的工作模式与典型场景

本系统服务于两个主要使用角色：工程师与项目经理（PM）。系统架构分为本地暂存区（Local Zone）与中央版本区（Central Zone），各自对应工程师开发过程与PM阶段性版本管理的需求。

在一个典型项目中，DVC 的使用通常会经历三个层面：

  1. 本地开发阶段：DVC Local
    • 工程师在本地工作目录中，使用 dvc local 命令创建、上传、删除文件。
    • 这一层主要服务于个人 / 小组开发与测试，数据视为暂存状态。
  2. 项目集中管理阶段：DVC Central Wrapper
    • 当某一版本通过内部审查（如 CID），项目经理可使用 dvc central 封装命令，
      将该版本提交到中央版本区（SVN 仓库），并标记为里程碑版本。
    • Wrapper 命令提供更简洁的语法和安全检查，适合日常项目管理使用。
  3. 系统深度集成阶段：DVC Central Native
    • 对于需要更细粒度控制或与其他系统集成的场景，可直接使用 Native 命令。
    • DVC Native 命令与底层 SVN 操作一一对应，保留全部高级功能，
      同时又在语法中嵌入 DVC 的设计路径与阶段语义。

这种三层封装方式，有几个好处：

  • 一线工程师只需掌握简单的 Local 命令，就可以完成日常版本操作；
  • 项目管理使用 Wrapper 命令，可以更安全地管理里程碑版本；
  • 进阶用户或系统集成场景，可以直接使用 Native 命令；
  • 底层仍然是熟悉的 SVN/Git 仓库，不会与现有工具链冲突。

系统架构与操作流程

A 段：工程师（Engineer）作业区

工程师日常将设计资料放置于：

/projects/<proj_code>/DVC/<PHASE>/<BLOCK>/<STAGE>/<VERSION>/

资料的操作采用 dvc local 指令完成文件的创建、上传、删除等动作。此处数据视为暂存状态，仅供本地开发、测试与初步整合使用。

常用指令：

  • dvc local create 建立指定阶段的本地版本目录（4层结构）。
  • dvc local put 上传文件至版本目录，可指定目标子路径、重新命名或建立符号链接。
  • dvc local delete 删除本地资料，可针对单一文件、目录、链接，甚至删除整个阶段、区块或阶段。

范例：

dvc local create top/usb/000-DATA/20250618_init
​
dvc local put top/usb/000-DATA/20250618_init ./netlist.v
​
dvc local delete top/usb/000-DATA/20250618_init/netlist.v --force

B 段：PM 阶段版本管理

当某一版本设计经CID审查通过后，PM将其作为关键里程碑版本，使用以下 dvc 指令将其纳入 DVC 中央版本区（SVN）：

  • dvc project checkout
  • dvc folder create
  • dvc folder checkout
  • dvc object copy
  • dvc dvcpath checkin

此流程将确保版本资料具备正式版本标签、记录完整路径、并支援后续检索与回滚操作。

1. DVC Local Command

  • 说明： 资料的操作采用 dvc local 指令完成文件的创建、上传、删除等动作。
  • 功能：
    • 此处数据视为暂存状态，仅供本地开发、测试与初步整合使用

这张图显示了DVC Central Command三层命令的关系，代表 DVC（Design Version Control）系统指令封装与执行流程：

2. DVC Central Wrapper Command

  • 说明： 这是提供给PM流程使用的命令，语法简洁，参数简单, 我们将用户常使用的几种情境包裹成DVC Central Wrapper命令, 以方便初学者上手。
  • 功能：
    • 隐藏底层复杂度（如 DVC native 语法与 SVN 操作细节）
    • 加入默认参数、自动路径解析、错误提示等

3. DVC Central Native Command

  • 说明： 这是 DVC 系统内部理解并执行的原生指令格式。它会根据 wrapper 的参数展开成标准化语法, 若用户想使用进阶功能也可以直接使用DVC Native命令。
  • 功能：
    • 执行实际版本控制操作（如比对、汇出、合并）
    • 提供中间层的错误处理与验证

互动关系总结：

这样的封装层级设计，有助于：

  • 提高用户接口的一致性与易用性
  • 减少使用者对版本控制工具的学习成本