处芯积律 RISC-V SoC 进阶版（SoC V2.0）
在 V1.1 基础上扩大系统规模与工程复杂度，训练中型 SoC 的集成与调试能力。
/project/SOC2.0/soc
SoC V2.0 是从「基础闭环」走向「中型工程维护」的关键阶段：在 V1.1 之上扩展系统规模与验证复杂度，训练跨模块联动分析与工程化调试；重点是有节奏地定位、验证和收敛，而不是盲目扩大改动面。
导读：这是什么 · 能学什么 · 怎么学
一、这是什么项目？
进阶版仍围绕单核 RISC-V SoC，但在顶层集成度、外设丰富度或互连复杂度上高于 V1.1；实践仍在 VNC 个人副本中完成，只读母本路径见本页命令区。
工程重点从「跑通一条主路径」升级为「维护一套可增量演进的中型 RTL + 仿真体系」：你必须建立 V1.1→V2.0 的差异地图，否则会把新问题误判为局部 bug。
下文框图突出「增量模块/路径」相对基础闭环的位置；实例化名以仓库顶层与讲义为准。
二、能学到什么？
建议对照 V1.1 笔记，逐项补齐下列能力维度。
架构与增量理解
- 输出书面「差异清单」：新增/改动的子系统、总线层级、存储或外设分支；标注每一增量点对仿真与软件可见性的影响。
- 地址映射变化：是否有新从设备、别名区间或仲裁策略调整；能在框图上标出新增主从路径。
- 启动与复位路径是否因增量改变（更多时钟/复位域或上电序列）。
设计与 RTL 维护
- 阅读增量模块接口契约：与旧版兼容的握手、反压与错误路径；避免「局部修好了、系统约束被破坏」。
- 参数化与生成脚本（若有）：理解哪些常量在多处联动，改动需同步评审。
- 代码评审视角：一次合并请求应附影响面说明与最小回归范围。
验证与回归策略
- 定向用例设计：为主增量链路写「短而尖」用例，先于全量盲目回归。
- 三线联动：日志关键字、波形时间戳、脚本参数三者对齐后再下结论。
- 建立「差异回归集」：仅包含受增量影响的模块相关用例 + 冒烟集；记录每次命令与 diff。
三、怎么学？
推荐路径：先冻结 V2.0 基线 → 画差异地图 → 定向验证 → 控制改动 → 分层回归。
- 副本就绪后先零改动跑通讲义指定基线用例，归档 log，命名 baseline_v2。
- 并列打开 V1.1 笔记：左侧差异清单，右侧 RTL 顶层例化树，逐项打勾。
- 为每一条「架构增量」绑定至少一个定向 case 或参数开关，避免只用默认 demo。
- 改动遵循「一次一类」：接口类 / 参数类 / 逻辑类分开提交与回归。
- 任何跨模块异常必须画简易时序草图再开波形，减少无效拉长仿真时间。
- 阶段结束前更新差异地图版本号，便于下次迭代对接 V3.0。
分周节奏（可按个人情况伸缩）
- 第 1 周 基线 + 差异清单初稿 + 顶层走读；标注三条最高风险增量链路。
- 第 2 周 定向用例矩阵与首轮回归；完成至少一次边界场景（仲裁、反压或异常响应）。
- 第 3 周（可选） 收敛一处真实缺陷或性能/时序疑点；沉淀命令模板与复盘文档。
V2.0 增量视角下的 SoC 示意
在 V1.1 单核闭环基础上叠加「增量子系统」示意；真实层次与命名以 RTL 为准。
「增量区」代表差异地图中要优先验证的挂载点；连线抽象自教学模型，请在工程中核对实例化名与协议。
片上 IP / 增量外设（对照差异地图）
在 V1.1 常见 IP 类别之上，V2.0 往往在「外设分支、存储扩展、桥与仲裁」出现增量；下表便于与差异清单逐条对齐。
典型功能块说明
下表按教学视角归纳常见职责与设计/验证关注点；具体层次名、信号名与协议细节以你手中的 RTL、顶层例化与课程讲义为准。
差异地图（元模块）
职责概要：贯穿本项目的核心工件：列出 RTL/TB/脚本相对 V1.1 的所有实质差异。
设计侧：新增接口、参数化常量、时钟域变化；需标注依赖关系与回滚策略。
验证侧：差异项与定向用例一一可追溯；每项差异都有 pass/fail 证据。
增量互连与外设分支
职责概要：承载 V2.0 扩展的外设或桥接逻辑，是中型的故障高发区。
设计侧：译码冲突、片选重叠、窄宽转换；注意与既有主路径的兼容性。
验证侧：边界地址、背靠背传输、异常访问（若 TB 覆盖）波形可解释。
存储子系统演进
职责概要：容量、端口或控制器行为相对 V1.1 的变化。
设计侧：对齐关系、读写 hazards、镜像装载接口是否改变。
验证侧：关键地址区间比对测试；必要时对拍检查与 V1.1 行为差异文档化。
脚本与回归入口
职责概要：编译列表变长、条件编译增多；需维护「最小构建」与「全量构建」。
设计侧：Makefile/脚本参数与目录规范；避免隐式依赖导致他人无法复现。
验证侧：新同事按 README 可在限定时间内复现 baseline_v2。
项目核心内容（完整范围）
- V1.1 与 V2.0 架构差异拆解：新增模块、互连变化、映射差异。
- 中型 SoC 定向用例与边界场景：仲裁、反压、异常路径。
- 日志 / 波形 / 脚本三线联动定位跨模块问题。
- 改动影响面评估与最小分层回归：冒烟集 + 差异集。
关键难点与常见卡点
- 系统复杂度提升后，问题来源更容易「跨模块漂移」。
- 调试时一次改太多，根因不清晰。
- 缺少差异化分析，容易把 V2.0 当成「更大号 V1.1」。
模块级深度讲解（做什么、看什么、怎么验）
V1.1→V2.0 差异地图
重点：列出新增/改动模块、互连与映射差异；标注验证优先级。
验收：差异项与定向用例一一对应，并能解释「为何该差异会改变验证策略」。
增量互连与外设分支
重点：译码、仲裁、窄宽桥；重点看与主路径的耦合点。
验收：边界地址与反压场景 waveform + log 可追溯。
中型定向验证
重点：为主增量链路设计短用例；避免一上来全芯片随机扫。
验收：用例选择书面说明覆盖意图与已知未覆盖风险。
跨模块收敛
重点：日志—波形—RTL 三角互证；禁止单点猜。
验收：同一 bug 报告含跨模块证据链与最小回归记录。
分阶段执行方案（讲义级节奏）
下面四段与上方「导读 / 分周节奏」一一对应，但颗粒度更细，方便你按天排期：阶段 1 只谈「基线 + 差异地图」；阶段 2 只收「定向证据」不混改动；阶段 3 才动刀并坚持冒烟+差异回归；阶段 4 把个人经验变成可交接资产。每段都给了「讲义节奏（参考）」、物证与过关标准，请按自己周几可实践时间成比例伸缩。
本阶段目标：得到「可签名」的 V2.0 baseline_v2，并把相对 V1.1 的增量写成可检索、可评审的差异地图（否则后续回归没有靶心）。
与导读的衔接：对应导读「差异清单」「冻结基线」；本阶段结束前禁止未记录在案的 RTL/脚本改动。
讲义节奏（参考）：建议 4～7 天：前两天专注零改动跑通与日志留存，中间两天填差异表与顶层走读，末段核对映射与脚本入口并做一次自查评审。
任务分解：
- 「第 0 步」列出本副本使用的工具链 fingerprint（仿真器版本、顶层 compile 命令来源、是否与讲义一致）。
- 在个人目录零改动执行讲义指定的基线用例全集或「官方最小集」，保存完整 stderr/stdout，命名为 baseline_v2_YYYYMMDD。
- 并排打开 V1.1 笔记与本工程顶层例化树：从左到右记录「新增模块 / 改名模块 / 删除连线」三类条目。
- 差异表建议三栏：**模块路径**（RTL）、**映射/参数**（译码区间、常量宏）、**脚本/Makefile**（新增目标、默认用例名）；每项附「验证优先级」A/B/C。
- 画出「三条最高风险增量链路」示意图：每条从 Core 发起经互连到新外设或桥，标注可疑仲裁点与备份路径。
- 核对 TB：默认装载镜像、复位顺序、是否与 V1.1 行为假设冲突（尤其在新增从设备映射上）。
- 阶段末开 15 分钟自检：若没有差异表，禁止进入阶段 2；若 baseline 不稳，先修环境问题而非写新用例。
建议产出（物证）：
- baseline_v2 原始日志（或校验哈希）
- 差异表 v0.x（表格或 Markdown）
- 风险链路草图（可手绘扫描）
- 环境与命令一页备忘
过关标准：第三者只看文档能口头复述「V2.0 相对 V1.1 多了哪几块」；同一天内重复跑基线两次，关键打印一致或在讲义允许误差内。
本阶段目标：每一条 A 级差异都有「定向短用例 + 预期行为 + 实际日志/波形」三组证据；未覆盖的条目明确列入风险登记而非假装完成。
与导读的衔接：衔接导读「定向用例先于全量」；本阶段的产出是后续「改动—回归」的论据库。
讲义节奏（参考）：建议 5～10 天：按链路分批交付，每两天至少收敛一条 A 级链路；每天保留「最小复现切片」备份。
任务分解：
- 为每条 A 级链路编写或启用**独立命名**的定向 case（命名建议含功能关键词，便于 Makefile 筛选）。
- 对每个定向 case 先写「预期摘要」一句：谁在什么条件下发起何种事务，期望在哪个从端口结束。
- 仲裁 / 反压：设计至少一类「背靠背读写」或「交替主设备」激励（若工程允许）；记录是否出现饿死、异常长 stall。
- 异常路径：若有非法访问 / 解码冲突类场景，对齐讲义是否要求 X 响应或断言；波形上标出首错 beat 的时间。
- 整理**对照表**：列「差异项｜定向 case｜结果 Pass/Fail｜证据路径（log 行号或波形截图编号）」。
- Fail 不归零不得进入下一阶段：挂上 issue（现象、重现命令、seed、已知怀疑模块），先做最小切片再扩展。
- 可选：每周一次「五分钟串讲」，向镜子或同伴口头讲一条链路，强迫自己用语准确。
建议产出（物证）：
- 定向矩阵（CSV/Markdown 均可）
- 每条 A 链路的对照表一行或多行证据
- issue/triage 列表（含暂缓项）
过关标准：对照表中所有 A 级条目状态为 Pass 或有书面豁免理由；任一 Fail 均有可复现命令与下一步实验计划。
本阶段目标：在授权范围内完成**一次类别清晰**的工程改动（接口 / 参数 / 逻辑三类勿混在同一提交意念里），并用「冒烟 + 差异回归」证明未破坏主干。
与导读的衔接：对应导读「一次一类」「closing_summary」中的分层回归叙事；此处训练的是企业里最常见的 merge 口径。
讲义节奏（参考）：建议 4～8 天：第 1 天只做动机与影响面文档；第 2～4 天实现与自检；第 5 天起跑分层回归并修尾巴。
任务分解：
- 「改动申请书」一页：动机、触及文件列表、预期影响的功能点、明确**非目标**（声明本次不改什么）。
- 划分回归集：**冒烟集**（<10 分钟）、**差异集**（与改动文件拓扑相关的定向 case）、必要时 **宽测**（讲义规定的夜间或周末跑）。
- 实施改动；每个逻辑块提交前本地跑冒烟；禁止「先堆代码再想起来回归」。
- 保留 `diff`（或截图）、两次完整日志摘要：**改动前 baseline** vs **改动后**；若有性能或仿真时间劣化一并记录。
- 若引入新参数或宏：同步更新 README 或个人 cheat sheet，并注明默认值与覆盖方式。
- 复盘一次「若没有差异集，只靠全量 pass 会如何漏问题」的思考题，写成三句话放进笔记。
建议产出（物证）：
- 改动申请书
- git diff 或补丁文件
- 冒烟+差异回归命令串
- 前后对照日志摘要
过关标准：同伴根据你的补丁与命令可在干净环境中复现实验结论；冒烟与差异集全绿或有已登记 waiver。
本阶段目标：把隐性判断显性化：**别人接手或你六月后自己回看**仍能继续维护；并明确「本项目与 V3.0 的预期衔接点」。
与导读的衔接：对应导读复盘与「迁移说明」——不是作文，是可执行清单。
讲义节奏（参考）：建议 3～5 天：前两天写主体文档，第三天做「盲人测试」（请同伴按文档操作），第四天修补漏洞。
任务分解：
- 撰写结构化复盘：**架构增量 → 验证策略 → 遇到的问题类 → 遗留风险 → 推荐的下一版关注点**。
- 整理个人 FAQ：三条最常见环境坑、三条最常见仿真坑、最常忘记 source 的路径变量。
- 列出「已知 waiver / 暂不修」清单：每条写明业务理由、重现条件、责任人（可写自己）、计划复查日期。
- 附录：给未来的自己一段「如何从本仓库过渡到 V3.0」的检查表（目录差异、脚本差异、推荐的保留资产）。
- 可选：录制 10 分钟屏幕 walkthrough（打开目录 → 跑一条冒烟 → 打开一处增量 RTL）。
建议产出（物证）：
- 复盘正文（建议 Markdown/PDF）
- FAQ 一页
- waiver 清单
- 可选 walkthrough 链接或脚本
过关标准：一位未全程参与的同伴在 FAQ+复盘指引下，可在约定时间内跑通冒烟并打开关键增量 RTL；你本人能脱稿讲清三条差异价值。
避坑手册
- 把所有问题都当局部 bug，忽略架构增量带来的系统性影响。
- 测试用例覆盖广但无重点，导致调试效率低。
- 定位结论没有证据链，难以复审与复现。
完成标准（你做到这些才算真正做完）
- 完成一份架构差异与验证策略对照说明。
- 至少 1 个关键问题从发现到修复全链路闭环。
- 回归结果可复现且有记录。
答辩与简历：V2.0 增量维护叙事
突出「差异驱动」与「分层回归」，避免只描述「做过仿真」。
能力证据（建议写入项目经历）
- 独立维护一份 V1.1→V2.0 差异地图，并与定向用例矩阵对照。
- 展示一次跨模块问题：从日志怀疑 → 波形证实 → RTL 定位 → 最小回归收敛。
- 说明「冒烟 + 差异回归」策略如何节省团队时间。
相对 V1.1 的增量价值
- 证明你能承接「他人交付后的中型 SoC」而非仅跑课程 demo。
- 体现影响面意识与评审语言，贴近企业集成岗位日常。
向 V3.0 / 专题深化的衔接
- 差异地图方法论可直接迁移到更大规模主线工程。
- 定向用例习惯为后续专题（总线/DMA 等）打样。
建议产出（可用于复盘/求职）
- V2.0 核心链路的差异化笔记（相对 V1.1）。
- 至少 1 个功能点的修改验证闭环（修改 -> 回归 -> 结论）。
典型实验任务清单（1-2-3 步）
- 对比 V1.1 和 V2.0 顶层差异，先确定目标验证链路。
- 执行定向仿真并补充至少一个边界场景。
- 整理“架构差异 + 验证结论 + 待优化点”小结。
快速开练命令
cd /home/USER/soc3_practice
cp -a /project/SOC2.0/soc ./soc-v2-0_my
cd ./soc-v2-0_my && ls -la
建议前置基础
建议已完成 SoC V1.1 或具备同等 SoC 仿真经验。