处芯积律 SoC 仿真与验证自动化 yrun 基础版（yrun V1.0）
聚焦仿真流程自动化，把“手工命令”升级为可复用、可扩展的验证流。
/project/multi_core_gui/soc/sim
yrun V1.0 聚焦验证自动化工程能力：把零散手工命令升级为可维护、可扩展的团队入口。围绕 env、yrun 参数、用例组织与批量回归、结果解读展开；通常在 sim 目录 source env.csh 后调用 yrun。
导读：这是什么 · 能学什么 · 怎么学
一、这是什么项目？
本主题不是「又一个 RTL 项目」，而是仿真执行流与回归资产：目标是让你写出他人可复跑的命令矩阵与产出规范。
路径一般为 `/project/multi_core_gui/soc/sim` 的个人副本；具体以讲义与环境脚本为准。
框图采用「工具链 / 配置 / 用例 / 结果」四层，帮助区分「环境问题」与「RTL 行为问题」。
二、能学到什么？
按自动化架构 / yrun 使用 / 团队协作三条线自检。
自动化分层架构
- 区分 env（编译与运行前置）、yrun CLI（单次任务）、批量层（case list / Makefile 封装）、报告层（汇总与归档）。
- 理解单次命令与 nightly 的差异：参数、超时、并行度。
- 目录规范：何人何时写入哪一级 log，避免互相覆盖。
yrun 与仿真器接口
- 常用子命令或参数语义：编译、elab、仿真、波形、seed、筛选用例。
- 错误码与 log 前缀：如何从 stderr 回溯到配置或 RTL。
- 与 makefile 变量的关系：谁在覆盖谁。
回归工程化
- 用例分组：冒烟、功能、边界、长尾；准入准出策略。
- 批量失败 triage：先分类再分配，而非逐个点波形。
- 度量：通过率、耗时、不稳定用例榜单。
三、怎么学？
路径：环境打通 → 单命令模板 → 小批量 → 归档规范 → 文档。
- 进入副本后第一件事：source env.csh（或等价）并打印关键环境变量自检。
- 固化「一条金牌命令」作为团队参照，再在其上参数化。
- 先手工跑通 3 个代表用例，再编写批处理。
- 为 nightly 预留独立输出目录与时间戳。
- 每次工具升级做回归对照表并保留旧日志一周。
分周节奏（可按个人情况伸缩）
- 第 1～3 天 env + 单命令矩阵；整理参数 cheat sheet。
- 第 4～7 天 批量脚本与汇总；做一次失败注入演练。
- 第 2 周（可选） 产出团队 README 与归档规范；复盘一次真实失败批量。
验证自动化流水线（概念）
区分配置、执行、工件与汇总；与实际脚本命名可能不完全一致。
定位问题时先判断卡在 ENV / yrun / SIM 哪一层，再决定是否下钻 RTL。
典型功能块说明
下表按教学视角归纳常见职责与设计/验证关注点；具体层次名、信号名与协议细节以你手中的 RTL、顶层例化与课程讲义为准。
环境脚本 env.csh
职责概要：编译器、仿真器、路径、宏开关的统一入口。
设计侧：与 shell 登录脚本差异；避免污染源环境。
验证侧：新开终端按 README 一步步可复现同一环境。
yrun 命令门面
职责概要：将长命令行折叠为参数化接口。
设计侧：默认值与覆盖规则；向后兼容。
验证侧：帮助信息与 dry-run（若有）可读、可审计。
用例清单与分组
职责概要：case list、tag、目录约定。
设计侧：排序与超时；跳过规则。
验证侧：筛选子集仍能解释覆盖意图。
结果归档与报告
职责概要：日志聚合、diff、失败归类。
设计侧：命名含日期、分支与参数摘要。
验证侧：任意失败可在归档中找到输入命令与 stderr。
项目核心内容（完整范围）
- yrun 基础命令与参数矩阵；env 初始化。
- 单用例到批量回归与汇总；失败 triage 流程。
- 团队可复用模板与文档规范。
关键难点与常见卡点
- 参数多导致命令混乱。
- 自动化失败时定位层级不清。
- 只追求跑通而忽略结果解读与归档。
模块级深度讲解（做什么、看什么、怎么验）
env 与环境指纹
重点：toolchain、PATH、宏；可复现声明。
验收：新 shell 按 README 一步恢复指纹。
yrun 命令门面
重点：参数模板、默认值、帮助信息。
验收：三人用同一模板跑出一致命令展开。
批量与调度
重点：case list、并行度、超时、重试。
验收：批量失败可分类统计而非一团乱麻。
归档与 triage
重点：目录结构、命名、汇总报表。
验收：任意失败可追溯命令与 stderr。
分阶段执行方案（讲义级节奏）
四段：金牌单命令 → 用例矩阵与批量失败分类 → 归档与故障演练 → 可选 CI/无人值守接口。本实践的核心物证是「cheat sheet、case list、汇总表、README」四件套；阶段 2 的 triage 能力直接对应企业 DV 日常。
本阶段目标：沉淀一条经反复校验的 **compile + elaborate + sim**（或等价）最短命令链，任何人按 README `source env` 后在 **30 分钟内**可复现同一 Pass。
与导读的衔接：导读「固定入口」；没有金牌命令，批量只能放大混乱。
讲义节奏（参考）：建议 3～6 天：Day1 环境与路径；Day2～3 固化命令；Day4 他人盲测。
任务分解：
- 严格遵守讲义顺序：`source env.csh`（或等价）并立即执行 **自检四连**：仿真器路径、许可证（若打印）、默认工作目录、Makefile/yrun 是否在 PATH。
- 禁用「口述依赖」：把所有隐式前置（例如要先 `cd` 到哪）写入 cheat sheet 的第 0 步。
- 选一个**最小代表用例**：固定 seed（若随机仿真）、关闭无关 dump 以缩短迭代；跑出第一次「干净的全绿 log」。
- 用 `history` 或脚本工具展开 yrun/Makefile 的实际子命令，贴到备忘里（方便后来 diff 工具升级）。
- 标注「单次预期耗时」与「产物目录结构」，便于以后估算农场并发。
- 做一次 **冷终端重放**：新开 shell，只凭 cheat sheet 输入，要求自己录屏或逐步打勾。
- 门禁：不能把「有时要 export 某某」留在脑子里；必须写入文档。
建议产出（物证）：
- cheat sheet v1.x（一页 PDF/Markdown 为宜）
- 金牌命令展开记录
- 盲测或通过录像
过关标准：第二人在无口头提示下重现 Pass；环境与版本号可查。
本阶段目标：从「能跑」升级到「能批量跑且能解释失败」：建立 case list、冒烟集、night 集三级概念与命名规范。
与导读的衔接：导读「回归工程化」「triage」；企业 DV 日常的主战场。
讲义节奏（参考）：建议 5～10 天：前半搭清单与冒烟，后半跑第一轮 batch 并分类；预留一天专门做「误报清除」。
任务分解：
- 维护 **case list**（CSV/Markdown）：列 case 名、所属设计层级、预估耗时、标签（smoke/reg/nightly）。
- 定义冒烟子集：默认 PR 前必跑；条数与时间上限写死（例如 ≤15 分钟）。
- 编写或改造 batch 脚本：统一日志目录结构 `logs/YYYYMMDD_runid_case/`。
- 首轮批量跑完后，对每一个失败执行 **五类分类**：①环境/许可证 ②编译/语法 ③ RTL 功能 ④ TB/断言 ⑤随机/种子敏感。
- 对「随机敏感」类必须记录 seed 与缩小用例；禁止只写「flaky」了事。
- 生成 **汇总表**：通过率、总耗时、失败 case 列表、下一步责任人（可先写自己）。
- 可选：对接 Makefile `make smoke` / `make nightly` 命名，与团队习惯对齐。
建议产出（物证）：
- case list
- batch 脚本或调用说明
- 首轮汇总表
- 分类统计（饼图可选）
过关标准：≥80% 失败可归入五类之一或登记为已知工具限制；每条失败有日志路径。
本阶段目标：形成可交接的 **流程资产**：新人不看私聊记录也能接着维护；并通过一次故意失败验证 triage 熟练度。
与导读的衔接：答辩「我提升了回归效率」时的物证来源。
讲义节奏（参考）：建议 4～7 天：文档与目录规范占一半，演练占一半。
任务分解：
- README 章节建议：仓库地图、环境、金牌命令、批量命令、日志规范、升级回滚策略（仿真器小版本变更怎么办）。
- 定义归档命名：`run_id = 分支名_日期_序号`，避免覆盖他人结果。
- 故意注入一类可控失败（例如错 seed、临时改 TB 期待），完整走一遍 triage 记录。
- 总结「最常见三类 cmdline 错误」与对应关键词搜索方式，附到 FAQ。
- 若有 nightly：约定保留周期与磁盘配额提醒。
- 交付检查：随机抽取三天前的失败日志，你是否仍能定位到命令与 stderr？
建议产出（物证）：
- README 定稿
- 归档规范一节
- 故障演练报告
- FAQ 附录
过关标准：新同学 30 分钟跑通金牌路径；故意失败可在 15 分钟内走到根因层级分类。
本阶段目标：若团队有 Jenkins/农场：预留「非交互运行」「退出码约定」「邮件/飞书通知字段」；没有也可作为简历延伸话题。
与导读的衔接：从个人脚本走向小团队流程。
讲义节奏（参考）：2～4 天。
任务分解：
- 给批量脚本增加 `--dry-run` 或等同开关，打印将执行命令但不跑仿真。
- 约定 exit code：0 全过、非 0 分类（可选）。
- 写一段「若接入 CI」的检查清单（artifact 上传路径、超时策略）。
建议产出（物证）：
- 可选 CI checklist
过关标准：脚本能无人值守跑完冒烟并返回一致退出码。
避坑手册
- 命令分散无规范，导致维护成本高。
- 回归结果只看最终状态，不看失败分布与模式。
- 没有统一归档，历史问题无法追踪。
完成标准（你做到这些才算真正做完）
- 形成标准化 yrun 命令模板。
- 完成至少 1 次批量回归与失败分类。
- 交付可复用文档与结果归档规范。
答辩与简历：验证自动化叙事
强调「流程资产」而非个人手感。
能力证据
- 一页参数矩阵与典型场景截图。
- 一次批量回归报告：通过率、耗时、失败分类。
- 故障演练记录：如何从 stderr 回到根因层级。
差异化价值
- 岗位匹配度高：企业验证岗大量时间花在回归与 triage。
- 可量化成果：节省人时、缩短反馈周期。
衔接
- 与 SoC/DV 项目结合：同一套 yrun 入口驱动不同设计。
- 为 CI、农场调度等更大规模自动化打底。
建议产出（可用于复盘/求职）
- 可直接复用的 yrun 命令模板与参数说明。
- 至少 1 组批量回归结果与问题清单。
典型实验任务清单（1-2-3 步）
- 进入 sim 目录后加载环境并跑通基础 yrun 命令。
- 增加参数或用例组，验证自动化回归流程。
- 形成“常用命令 + 回归策略 + 结果解读”模板。
快速开练命令
cd /home/USER/soc3_practice
cp -a /project/multi_core_gui/soc/sim ./yrun-v1-0_my
cd ./yrun-v1-0_my && source env.csh && yrun -h
建议前置基础
建议已完成至少一个 SoC 项目的手工仿真流程。