前言设想这样一个层次化设计： 子模块 A 只在输入为奇数时输出 1； 子模块 B 只在输入为偶数时输出 1； 顶层把两个结果做或运算。 对任何普通二进制输入，一个数不是奇数就是偶数，所以顶层输出必然为 1。源码里明明写了两个子模块、一个取反和一个或运算，综合器最终能不能发现“整个设计其实只是常量 1”？ 答案是：能，但不是 flatten 单独完成，也不是第一次 opt 就能完成。 真正发生的

前言上一篇建立了从 Verilog、RTLIL、通用网表到技术映射网表的整体坐标。这一篇进入带状态的设计，研究一个更具体也更容易产生错觉的问题： 1always @(posedge clk or posedge rst) 它在综合后到底是什么？if/else 如何变成 MUX？opt 为什么会把 $adff 变成 $adffe？把优化结果手工写回 RTL 是否有意义？交换 load 和 en 的

前言第一次接触 Yosys 时，我最先困惑的不是某条命令，而是几个看似简单的问题：Verilog 到底是在写程序还是在画电路？Yosys 输出的 .v 文件为什么仍像 RTL？RTLIL 是不是类似编译器 IR？技术映射又把什么映射成了什么？ 这些问题其实指向同一件事：逻辑综合不是把一段程序翻译成另一段程序，而是在不同抽象层次上不断改写一张电路图。 下面直接从两个完整的小模块出发，展示 Yosys

前言最近讨论 Linux 的 swap、SSD、NAND flash、控制器和固件时，我发现一个很容易误解的地方：操作系统把 SSD 看成一个很普通的块设备，但 SSD 内部其实是一个很复杂的小系统。 从 Linux 看，读写 SSD 只是对 /dev/nvme0n1 或 /dev/sda 发起读写请求；从 SSD 内部看，它要做地址翻译、错误纠正、坏块管理、磨损均衡、垃圾回收、温控、掉电保护和统

〇、前言前两篇分别讲了 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