Veryl 的發展史#

Veryl 是一個年輕的語言：它的故事從 2022 年才開始，但每一個決策都有清晰的脈絡可循。理解它的發展史，就是理解一個個人專案如何在開源世界裡長出社群。

起點：dalance 與 2022#

Veryl 由日本工程師 dalance（Naoya Horiguchi）於 2022 年開始開發，2023 年以 veryl-lang/veryl 為名在 GitHub 公開，全程以 Rust 撰寫。dalance 是資深的系統軟體開發者，在此之前已有 procfs 等知名的 Rust 開源作品。Veryl 的動機直接來自第一線的痛點：SystemVerilog 缺少好的工具鏈支援——沒有 rustup 式的版本管理、沒有內建的 formatter、沒有語言伺服器、沒有套件管理。當軟體工程在 2010 年代被 Rust/Go/TypeScript 重新定義了開發體驗，硬體工程師卻還在用文本編輯器裸寫 Verilog。

Veryl 的回答是一整套工具而非僅僅一個語言：verylup（版本管理與工具鏈安裝器，對標 rustup）、veryl build/check/fmt/doc/test 等子命令（對標 cargo）、package registry（發布與版本鎖定，對標 crates.io）、以及 LSP（語言伺服器，編輯器內的即時診斷與補全）。這種「把 cargo 的開發體驗搬進硬體」的雄心，是 Veryl 與其他新 HDL 最鮮明的差異。

設計決策：一條不妥協的路線#

發展過程中，幾個關鍵決策塑造了今天的 Veryl：

獨立語言、編譯到 SystemVerilog。不是嵌入 Python/Scala 的 DSL，而是一個有自己語法的語言，產出人類可讀、可直接 review 的 SV。這保證了與既有 EDA 工具鏈（Vivado、Vcs、Verilator）的零成本相容。
語法經過深思：always_ff (clk, rst) { if_reset {...} } 把 reset 樣式寫進語法；let/var 區分單一賦值與可變；generics 統一參數化；interface/modport 強制方向。
開發過程本身開源：語言的演進透過公開的討論與提案進行，重大語法變更在 issue 與討論區留下完整的決策紀錄。這種「設計決策文件化」的文化借鑑了 Rust RFC 流程——回頭翻閱，可以看見每個語法為什麼長成今天的樣子。

里程碑式的成長#

以概括的方式描述 Veryl 的演進軌跡：最早是轉譯器與基本語法的成形；接著是 fmt（格式化）與 doc（文件產生）讓團隊協作變得現實；LSP 與 verylup 把開發體驗拉到現代水準；cocotb 支援（embed (cocotb) sv { ... } 配 #[test]）把 Python 驗證生態接進來；package registry 讓 IP 重用成為可能；隨後幾年持續有語法擴充與後端修正。精確的版本時間軸以官方手冊與 GitHub release 為準——本書不虛構日期，但趨勢是清楚的：從一個人的語言實驗，長成有外部貢獻者、有公司在內部評估採用的社群專案。

個人專案如何獲得貢獻者#

Veryl 的成長路徑對所有開源硬體專案都有參考價值。第一，工具先於語言：很多人是被 fmt 與 LSP 吸引進來的，然後才愛上語法。第二，輸出可讀：產出的 SV 長得像人寫的，讓保守的團隊敢在生產環境嘗試。第三，文件與範例完善，降低首次貢獻的門檻。第四，作者的回應迅速，issue 不積壓——開源社群的本質是信任的複利。

對照上一節的開源 EDA 生態：Yosys、SKY130、RISC-V 打開了工具與標準，Veryl 這類現代 HDL 則要打開「描述硬體的語言體驗」。它們共同回答一個問題：如果晶片設計民主化了，用什麼語言寫？下一節，我們把 Veryl 放進現代 HDL 的全景中比較。