前言组合表达式经过 proc 和 opt 后，通常会变成 mux、比较器和算术 cell。但状态机和数组存储包含更高层的设计意图： 12状态机：状态集合、转移条件、复位状态、控制输出memory：容量、端口数量、读写时序、碰撞语义 如果综合器只把它们当成普通寄存器和 mux，就很难执行状态重编码，也很难把数组映射到 SRAM macro、FPGA block RAM 或 LUT RAM。Yosy

前言Verilog 有四种基本逻辑状态：0、1、x 和 z。前两种很直观，x 可以理解为未知值，但 z 经常被误解成“另一种未知值”。事实上，z 的本意不是一个可以参与计算的数字，而是：这个驱动器现在没有驱动线路。 这个区别直接决定了综合器应当如何处理它： 12x：数据值未知，可能进入普通逻辑表达式z：驱动器释放线路，应当用三态结构表达 对于 Yosys 来说，问题还要再细分一层。RTLIL 的

前言设想这样一个层次化设计： 子模块 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