〇、前言前两篇分别讲了 GitHub 权限分层和几种 token 的身份模型。 这一篇把它们落到一个完整的自动发布场景里： 1234example-org/web-client→ GitHub Actions 构建资源→ 发布到 example-org/resource-assets→ 用户或程序下载 release asset 这条链路看起来只是一个普通 CI/CD： 1push m

〇、前言上一篇主要讲了 GitHub 的权限不是一句“我是 member”能解释的。它至少要看用户、组织、团队、仓库、分支保护、rulesets 等多层关系。 这一篇进入自动化里最容易混乱的部分：token。 在 GitHub 里，我们经常会看到很多种 token： Classic PAT； fine-grained PAT； GITHUB_TOKEN； GitHub App installat

〇、前言我以前看 GitHub 权限的时候，总觉得它应该很简单： 我是不是这个组织的 member？我是不是这个仓库的 admin？我能不能 push？ 后来真正把 GitHub Actions、跨仓库 release、PAT、GitHub App 放到一起用的时候，才发现这个理解太粗了。 GitHub 的安全模型不是一层，而是很多层叠在一起。一个人可能是 organization 的 mem

前言很多工程报告会把 smoke test 写成“跑了几条命令，看到 PASS”。这种写法对没有环境的读者不友好，也讲不出测试设计的价值。 更好的讲法是：smoke test 在验证跨层契约。CoolDA 这种 SoC demo 的 smoke test 应该证明： 固件能构建； SoC 能仿真； shell 能接收脚本输入； runtime 能调度任务； BSP 能驱动 APB NPU； NP

前言硬件 demo 如果只能在 testbench 里改输入，系统感会很弱。CoolDA 这类 SoC 仿真更进一步：让 CPU 启动一个精简 shell，用户或脚本通过 shell 触发 runtime，runtime 再驱动 NPU。 这样 Verilator 就不只是“跑 RTL”，而是变成一个可交互的系统实验环境。 交互链路整个交互链路可以写成： 123456789host termin

前言硬件核只会做 4x4，但用户想算的矩阵可能是 8x8、16x16，甚至更大。解决方法不是让 CPU 直接操作每一个寄存器细节，而是分两层： BSP：把寄存器表包装成薄函数； runtime：把大任务拆成 4x4 tile，并调度硬件核反复执行。 BSP：越薄越好BSP 的职责是硬件寄存器访问。它应该非常薄。 最底层是 MMIO helper： 1234567891011static in

前言CPU 眼里的 NPU，不是一堆乘法器，而是一组寄存器。只要寄存器契约设计清楚，软件就能驱动硬件；只要契约设计混乱，硬件再能算也很难用。 这一篇拆 CoolDA 的 APB NPU：寄存器怎么排，A/B 数据怎么打包，start/busy/done 如何工作，4x4 乘法核如何完成计算。 APB 外设的基本形状一个 APB 外设大致会接收这些信号： 123456

前言单独写一个 NPU 矩阵乘法模块，只能说明硬件会算。真正有系统意义的问题是：CPU 怎么使用它？ CoolDA 这类 SoC demo 要讲的就是这条路径： 1234567用户命令 -> 操作系统 shell -> runtime -> BSP 驱动 -> APB 总线 -> NPU 寄存器 -> 4x4 INT8 矩阵乘法核 这篇先建立系统视

前言RTL 设计最怕“看起来能跑”。一个 NPU 小 demo 如果只做一次端到端输出，很难定位问题。真正稳妥的方式是分层验证： 12345单 PE -> PE Array -> Control Unit -> NPU Top -> 算子链 每一层都锁住一部分语义，最终整机才可信。 第一层：单 PE 验证单 PE 要验证的不是“能不能输出一个数”，而是乘加合约是

前言PE Array 负责算，Unified Buffer 负责存，但 NPU 还缺一个“指挥系统”。这个系统就是 Control Unit。 Control Unit 不做乘法，却决定： 什么时候接收命令； 什么时候从 buffer 读数据； 什么时候启动 PE Array； 什么时候做激活和池化； 什么时候把结果输出。 32 位命令格式一个最小 NPU 可以使用 32 位命令： 123