企业官网建设流程全解析

• 开发工具
• Lint
• 静态分析
• 硬件开发

Verible 是 CHIPS Alliance 维护的一套 SystemVerilog 开发者工具集，其核心使命是解析符合 IEEE 1800-2017（SV-LRM）标准的 SystemVerilog，并将解析能力扩展为风格检查、格式化和语言服务等多种应用。与常规工具链的解析器只接受预处理后源码不同，Verible 的解析器直接面向**未预处理（un-preprocessed）**的原始源文件——这使风格检查与格式化这类单文件应用成为可能，同时也能适配真实编译器所需的预处理输入。读完本篇，你将掌握 Verible 各命令行工具的定位与用法、verible-verilog-syntax的 JSON 导出格式、lint 规则的配置与豁免机制、formatter 的核心参数，以及基于 Bazel 的完整构建、安装与测试流程。

项目定位与设计理念

Verible 诞生的直接动机，是开发者社区反复造"SystemVerilog 解析器"这个轮子——由于语言的语法复杂度，开发一个标准合规的解析器是极其庞大的工程。Verible 希望任何人都不必再为自己的应用重复开发解析器；其解析器还定期对照一套不断增长的、工具无关的语言合规测试（sv-tests）进行验证。

此外，Verible 有一个次级目标：其语言无关（language-agnostic）的组件应当可以独立复用，用于快速开发其他语言的支持工具。从源码目录结构可以直接看到这一设计的落实：

• verible/common/：与具体语言无关的基础设施，包含 lexer/parser 适配层（verible/common/lexer/、verible/common/parser/）、具体语法树（CST）定义（verible/common/text/）、格式引擎（verible/common/formatting/）、风格检查框架（verible/common/analysis/）、LSP 支持（verible/common/lsp/）与字符串/区间工具（verible/common/strings/、verible/common/util/）；
• verible/verilog/：SystemVerilog 专属实现，包括 CST 查询库（verible/verilog/CST/）、词法/语法分析（verible/verilog/parser/）、lint 规则（verible/verilog/analysis/）、格式化（verible/verilog/formatting/）、预处理（verible/verilog/preprocessor/）以及各可安装工具（verible/verilog/tools/）。

所有可安装工具的清单在顶层 BUILD 的install-binariesfilegroup 中集中声明，包含verible-verilog-syntax、verible-verilog-lint、verible-verilog-format、verible-verilog-ls、verible-verilog-diff、verible-verilog-obfuscate、verible-verilog-preprocessor、verible-verilog-project与 Kythe 提取器等目标，与下文的工具清单一一对应。

安装方式

二进制发布与包管理器

对简单安装，Verible 提供针对 Linux 和 Windows 的常规二进制发布，包含 x86 与 Arm 的静态链接二进制，可在几乎任何 Linux 发行版上运行。部分发行版也已收录 Verible：Nix 提供 Linux x86 与 Arm 二进制包，Homebrew 提供 macOS 包。

本地源码构建

Verible 代码库使用 C++ 编写（C++20）。构建需要 Bazel 构建系统与一个 C++20 兼容编译器；依赖可通过系统包管理器安装，或者——若已安装 Nix——直接在仓库根目录运行nix-shell即可获得完整的构建环境。仓库根目录的 shell.nix 定义了该环境：它固定使用bazel_8，并附带flex、bison（供可选的本地 flex/bison 构建）、gnused（bzl 规则与测试内脚本使用）、ripgrep、python3及anytree（用于手动运行 JSON 导出示例）、lcov（覆盖率 HTML 生成）、bazel-buildtools（buildifier）、clang-tools（clang-tidy/clang-format）等。它支持通过可选的./user.nix追加个人定制包。

# 构建全部工具与库 bazel build -c opt //...

构建产物位于bazel-bin/下。例如语法检查器位于bazel-bin/verible/verilog/tools/syntax/verible-verilog-syntax，对应 Bazel 目标名//verible/verilog/tools/syntax:verible-verilog-syntax。

如需不依赖系统共享库的静态链接可执行文件，可使用自定义配置create_static_linked_executables（该配置下使用bfd链接器替代默认的gold链接器）：

# 生成静态链接可执行文件 # 使用 bfd 链接器，需要系统中存在相应的静态库 bazel build -c opt --config=create_static_linked_executables //...

从源码结构看，create_static_linked_executables与use_local_flex_bison都是 bazel/BUILD 中声明的bool_flag构建设置，分别派生出static_linked_executables与use_local_flex_bison_enabled两个config_setting，供各BUILD文件中的select()切换链接行为与 flex/bison 工具链。

可选：使用本地 flex/bison 构建

解析器生成所需的 Flex 和 Bison 默认作为构建过程的一部分被编译（对应 bazel/flex.bzl 与 bazel/bison.bzl）。如果出于任何原因希望使用系统本地的工具（例如遇到它们的编译问题时——此时请先提交 bug 报告），可在 Bazel 命令行追加--//bazel:use_local_flex_bison：

# 测试/安装命令同样追加该选项 bazel build -c opt --//bazel:use_local_flex_bison //...

在 Windows 上构建

除了 Bazel 与 Visual Studio，Windows 构建还需要 WinFlexBison 3 和 Git-bash。使用 chocolatey 包管理器可一键安装：

choco install git winflexbison3

Bazel 在 PowerShell 下可能还需要设置环境变量以使用 git-bash：

$env:BAZEL_SH="C:\Program Files\Git\git-bash.exe"

顶层 BUILD 中还定义了x64_windows-clang-cl平台，说明仓库支持通过 clang-cl 在 Windows 上构建。

安装构建产物

bazel build -c opt :install-binaries # 安装到用户目录 .github/bin/simple-install.sh ~/bin # 安装到需要 root 权限的系统目录时，用 sudo 调用脚本 sudo .github/bin/simple-install.sh /usr/local/bin

仓库内的 .github/bin/simple-install.sh 会mkdir -p目标目录，然后把bazel-bin/verible/verilog/tools下的各工具二进制与bazel-bin/verible/common/tools/verible-patch-tool逐一install进目标目录（脚本头注明这是在部分平台installtarget 不可用时的替代方案）。前提是先执行过bazel build :install-binaries；若系统缺少合规的install工具，也可以直接把bazel-bin/下的二进制复制到目标位置。

核心工具之一：解析器与 verible-verilog-syntax

verible/verilog/parser/ 目录包含 SystemVerilog 词法/语法分析实现，目标是接受全部合法的 IEEE 1800-2017 SystemVerilog 语法，进度以 sv-tests 合规测试套件为度量。其设计要点值得展开：

• 解耦设计：lexer 与 parser 是解耦的——lexer 可独立用于词法切分，parser 适配层（verible/verilog/parser/verilog_parser.h）接受来自任意来源的 token，而非只能消费 lexer 的输出。这使得两者之间可以插入不同的处理通路，例如集成预处理、以及语言所需的基于上下文的词法消歧（支持任意距离的 lookahead）；
• Lexer：由 Flex 生成，token 枚举来自 verilog.y 中的语法定义；生成的实现被 verilog_lexer.h 的适配层包装，使其返回 token 对象而非单纯的int。token 流具有连续性（前一 token 的文本区间终点等于下一 token 的起点）与完整性（首末 token 覆盖的区间等于被扫描原文的区间）——因此空白、换行、注释等"不显著"文本也都表示为 token，可在送入解析阶段前轻易过滤；
• Parser：由 Bison 生成的 LALR(1) 解析器，输出具体语法树（CST），其通用节点用 verible/verilog/CST/verilog_nonterminals.h 中的枚举来"标注类型"；
• Lexical Context：解析 SystemVerilog 面临许多常规 LR 文法无法处理的问题。LexicalContext 是一个 token 变换通路，通过消歧"在多种语法上下文中使用的 token"、执行 LR 文法无法表达的远距离 lookahead 来帮助 Bison 生成的解析器，其行为可看作一组扫描并改写 token 的状态机组合。

verible-verilog-syntax 是一个独立的语法检查与结构可视化工具，非常适合排查问题以及理解其他工具看到的内部表示。当其输出正确时，说明 lexer 和 parser 工作正常，问题可能在后续阶段；当其本身就报错时，则是其他工具无法工作的根源。启动排查时请优先使用它。

其完整命令行选项（摘自 README）：

usage: verible-verilog-syntax [options] <file(s)...> --error_limit (限制报告的语法错误数量，0 表示不限); default: 0; --export_json (使用 JSON 输出，意图作为其他工具的输入); default: false; --lang (选择解析的语言变体: auto: SystemVerilog-2017，但可自动检测替代解析模式 sv: 严格的 SystemVerilog-2017，显式替代解析模式 lib: Verilog library map 语言 (LRM Ch. 33) ); default: auto; --printrawtokens (打印全部词法 token（含被过滤的)); default: false; --printtokens (打印全部词法与过滤后的 token); default: false; --printtree (是否打印语法树); default: false; --verifytree (验证所有 token 均被解析进树中，打印未匹配的 token); default: false;

它对module foo(input a, b, output z);这类代码用--printrawtokens输出的 token 流是无损的：每个 token 都以(#<tag> @左-右: "文本")形式给出字节偏移区间，空格、换行、注释全部保留，末尾以$end收尾。--printtree输出的 CST 中，Node @N/Leaf @N的N是该节点相对其直接父节点的子序（从 0 计，空节点会被跳过），节点用语言专属枚举（如kModuleDeclaration、kModuleHeader、kPortDeclaration）标注，叶子内嵌 token 及其原文偏移。

需要注意的是，SystemVerilog CST 的确切结构是脆弱的、不应视为稳定 API：节点枚举随时可能被增删，子树结构可能被重塑；例如kModuleHeader只是模块定义组合的实现细节，并不直接映射 SV-LRM 中的某个命名语法构造。因此程序化访问应通过 verible/verilog/CST/ 库提供的抽象函数进行。

替代解析模式

解析器支持替代解析模式（alternative parsing modes）：当文件本意是被包含在其他上下文（如 module body 片段）中时，可在文件顶部附近用注释触发，例如// verilog_syntax: parse-as-module-body。这在 lint 场景尤其重要——如果文件不是 LRM 意义上可独立成立的 Verilog 程序（比如 module/class/task/function 的 body 片段），语法错误无法被豁免，而应通过选择解析模式让解析器把它当作片段处理（详见 verible/verilog/tools/lint/README.md 的 "Syntax errors" 一节）。

JSON 导出：让外部工具消费 CST

--export_json把 CST 以 JSON 对象输出，方便被外部工具利用；verible/verilog/tools/syntax/export_json_examples/ 提供了 Python 包装模块verible_verilog_syntax.py与若干示例脚本。JSON 结构要点：

• 根对象把每个输入文件名映射到一个解析结果对象；
• 解析结果对象包含按需出现的键：tokens（--printtokens时，过滤空白后的 token 数组）、rawtokens（--printrawtokens时）、tree（--printtree且解析未失败时的解析树）、errors（存在错误时）；
• 树由 Node 对象（tag取值见 verilog_nonterminals.h 的NodeEnum，children为子节点数组或null）与 Token 对象（start/end字节偏移、tag、可选text）组成；token 的tag有三类来源：具名 token（如SymbolIdentifier）、字符串字面量（如module、==）、单字符（如;、=）；
• 获取 token 文本时，若text键不存在（算子与关键字 token 不携带），可从源文件按[start, end)读取，官方示例给出了 Python 的按字节切片读法；
• Error 对象包含 0 基的line/column、触发错误的text、phase（lex/parse/preprocess/unknown）与可选的message。

核心工具之二：风格 Linter（verible-verilog-lint）

verible-verilog-lint依据风格指南识别代码中被认为不理想的构造或模式，主要目标是把人工审查风格合规的负担从人身上卸下来。许多 lint 规则基于语法树模式匹配来发现违规——verible/verilog/analysis/checkers/ 目录下单文件一规则（如line-length-rule.cc、no-tabs-rule.cc、always-ff-non-blocking-rule.cc等近百个实现），配套的规则注册在 verible/verilog/analysis/lint-rule-registry.cc。它的关键特性：

• 诊断信息中附带风格指南引文；
• 规则组（rule deck）可配置；
• 豁免机制：文件内注释豁免 + 外部 waiver 文件；
• 有可用于 GitHub 的 SystemVerilog linter action（见上文 GitHub 集成截图）。

由于它读取的是未预处理输入：可以直接检查注释、擅长检查未展开宏的使用；但不会尝试理解预处理条件分支，也没有语义分析（连通性等需要预处理、多文件分析与抽象语法树）。

其命令行选项（摘自 README）：

usage: verible-verilog-lint [options] <file> [<file>...] --rules (逗号分隔的待启用 lint 规则。无 '+' 前缀或 '+' 前缀启用，'-' 禁用。 各规则的配置值放在 '=' 之后); default: ; --rules_config (lint 规则配置文件路径。设置后禁用 --rule_config_search); default: ""; --rules_config_search (从每个被分析文件的位置向上查找 '.rules.verible_lint'); default: false; --ruleset ([default|all|none]，linter 使用的基础规则集); default: default; --waiver_files (waiver 配置文件路径（逗号分隔）); default: ""; --autofix (自动修复模式; [no|patch-interactive|patch|inplace-interactive|inplace|generate-waiver]); default: no; --autofix_output_file (patch/waiver 输出文件); default: ""; --check_syntax (是否检查词法/语法错误); default: true; --generate_markdown (以 Markdown 打印每条规则的描述并退出); default: false; --help_rules ([all|<rule-name>], 打印规则描述); default: ""; --lint_fatal (发现违规时以非零状态退出); default: true; --parse_fatal (存在语法错误时以非零状态退出); default: true; --show_diagnostic_context (额外打印诊断所在行与位置标记行); default: false;

诊断输出格式为FILE:LINE:COL: text...，例如：

path/to/missing-endmodule.sv:3:1: syntax error (unexpected EOF). path/to/bad-dimensions.sv:114:43: Packed dimension range must be in decreasing order. http://your.style/guide.html#packed-ordering [packed-dimensions-range-ordering]

规则名出现在每条诊断消息末尾的[]中，可据此填写豁免。

规则配置与命名风格正则

--rules接受逗号分隔的规则名列表：-前缀禁用，无前缀或+前缀启用，=之后传配置。多参数用分号分隔，因 shell 会把分号当特殊字符，需加引号：

verible-verilog-lint --rules=enum-name-style,+line-length=length:80,-no-tabs ... verible-verilog-lint --rules="undersized-binary-literal=hex:true;lint_zero:true" ...

命名风格类规则可使用 RE2 正则配置，官方给出常见命名风格与正则的对照：

verible-verilog-lint --rules="enum-name-style=style_regex:[a-z_0-9]+(_t|_e)" ...

对命名风格规则来说，正则无需处理"以数字开头"的情况——词法/语法分析阶段已经保证了这一点。--rules_config则从文件读取同样语法的配置（可换行分隔）；官方建议各项目维护自己的配置文件以保证成员间一致。

豁免（waiver）机制

文件内注释豁免支持四种形态：注释下方一行的豁免（// verilog_lint: waive rule-name）、同行尾注豁免、多条 waive 注释跨行累积、以及waive-start/waive-stop区段豁免。外部 waiver 文件通过--waiver_files（逗号分隔多文件，等效于按出现顺序拼接）指定，每行一条：

waive --rule=rule-name-1 --line=10 waive --rule=rule-name-2 --line=5:10 waive --rule=rule-name-3 --regex="^\s*abc$" waive --rule=rule-name-4 --line=42 --location=".*some_file.*"

--line支持单行或:分隔的行区间；--regex可动态匹配需要豁免的行，对存在自动生成文件的项目特别有用；--location用正则限定 waiver 只作用于匹配的文件名。语法错误不可豁免（应改用替代解析模式，见上一节）。

自动修复（autofix）

一些琐碎违规（行尾空格、重复分号等）可自动修复，--autofix控制修复的呈现/应用方式：

未指定--autofix_output_file时，patch/waiver 输出到 stdout；generate-waiver模式可生成waive --rule=<rule_name> --line=<number> --location=<file_name>形式的规则文件。交互模式对每条修复提供y（应用）、n（拒绝）、a/d（应用/拒绝该规则的全部剩余修复）、A/D（应用/拒绝全部）、p（展示修复）、P（展示已应用修复）、?（帮助）等操作键，README 附有一整段真实的inplace-interactive会话示例（含多条可选修复时按1,2,...选择替代方案的情形）。

规则文档是动态生成的：verible-verilog-lint --help_rules输出文本、--generate_markdown输出 Markdown；仓库顶层 BUILD 中的lint_docgenrule 即执行verible-verilog-lint --generate_markdown并把结果写入bazel-bin/documentation_verible_lint_rules.md，因此也可以bazel build :lint_doc直接生成。

核心工具之三：Formatter（verible-verilog-format）

verible-verilog-format按特定风格管理空白，目标让人不再手动管理空白、换行与缩进，并让任何编辑器都能获得编辑器无关的一致性。README 列出的能力（处于不同程度的完善中）：修正缩进、带语法上下文感知的 token 间距修正、按列宽限制折行、增量格式化（只触及变更行）、交互式格式化（接受/拒绝变更）、表格化对齐，以及配套的 GitHub formatter action。

其通用参数（摘自 README 的 usage 段）核心包括：

• --column_limit（默认 100）：格式化时尽量不超过的目标行宽；
• --indentation_spaces（默认 2）：每级缩进增加的空白数；
• --line_break_penalty（默认 2）、--over_column_limit_penalty（默认 100）：折行/超宽的代价参数——从实现看，折行决策由 verible/common/formatting/line-wrap-searcher.cc 的代价最小化搜索驱动，--max_search_states（默认 100000）即限制该搜索探索的状态数；
• --line_terminator（默认 auto）：auto按输入观测决定输出换行风格，显式CR/CRLF可固定；
• --wrap_spaces（默认 4）：开分组后首元素折行时每个折行层级增加的空白数；
• 大量对齐/缩进风格参数，取值统一为{align,flush-left,preserve,infer}或{indent,wrap}：--assignment_statement_alignment、--case_items_alignment、--class_member_variable_alignment、--formal_parameters_alignment、--formal_parameters_indentation（默认 wrap）、--module_net_variable_alignment、--named_parameter_alignment、--named_port_alignment、--named_port_indentation（默认 wrap）、--parameter_declaration_alignment、--port_declarations_alignment、--port_declarations_indentation（默认 wrap）、--struct_union_members_alignment、--distribution_items_alignment等，默认均为infer；
• 其他行为开关：--compact_indexing_and_selections（默认 true，索引/位选择内使用紧凑二元表达式）、--wrap_end_else_clauses（默认 false，把end与else拆到两行）、--alignment_group_boundary（默认 none，控制何种内容打断模块项/语句/类项的对齐组：none/blank-lines/separator-comments/blank-lines-and-separator-comments）、--try_wrap_long_lines（默认 false，短期降低"造成损害"风险的措施）、--expand_coverpoints（默认 false）；
• 运行方式：--inplace成功后覆盖输入文件；--lines指定格式化行（1 基、逗号分隔、支持N-M闭区间，可重复累积）——这是增量格式化、只格式化变更行的入口，verible/verilog/tools/formatter/ 目录下还附带git-verible-verilog-format等针对 git 变更行的包装脚本（见顶层 BUILD 的install-scripts）；--failsafe_success（默认 true）使输入/内部错误时仍以 0 退出且原文保留，便于在部署服务中把失败安全行为视为成功；
• 诊断开关：--show_token_partition_tree、--show_inter_token_info（附 token 间间距/断行代价信息）、--show_largest_token_partitions、--show_equally_optimal_wrappings，用于观察折行优化内部过程。

核心工具之四：Language Server（verible-verilog-ls）

verible-verilog-ls是 Verible 的语言服务器，把命令行工具的功能直接带入编辑器：实现标准化的 Language Server Protocol（由 LSP 协议 schema 生成，见 verible/common/lsp/lsp-protocol.yaml），支持众多编辑器/IDE；提供格式化、lint，并在可能时提供 quick-fix。

按 README 的进度清单，当前已完成的 LSP 功能包括：

• 发布语法错误与 lint 规则的诊断，且 lint 配置优先采用项目内的.rules.verible_lint（而非全量启用规则）；
• 为 lint 规则的 autofix 提供 code actions；
• 生成文件符号大纲（navigation tree）；
• 提供文档格式化；
• 高亮与光标下符号相同的其他符号（作用域/类型感知仍待完善）；
• 跨文件查找定义（go to definition）与查找引用（find references）；
• 悬停（hover）信息为实验特性，需--lsp_enable_hover开启；
• 尚未完成：跨文件查找声明、Document Links（如打开 include 文件）、符号重命名重构。

项目级配置

verible.filelist：语言服务器默认只加载并分析编辑器中正在编辑的文件。要启用跨文件的 go-to-definition、find-references、hover 等功能，可在项目根添加verible.filelist——每行一个设计文件的清单，语言服务器据此构建符号表。若项目已有文件清单，直接以verible.filelist之名链接到项目根即可；否则可用find之类工具生成：

find . -name "*.sv" -o -name "*.svh" -o -name "*.v" | sort > verible.filelist

其中路径可以是相对verible.filelist位置的相对路径或绝对路径；默认文件名可用--file_list_path <new-file-name>修改。

项目根判定：语言服务器在项目根中寻找verible.filelist。项目根通常由编辑器决定（编辑器启动目录、按.git等项目根特征发现、或用户在编辑器设置中指定）；若无有效项目根，回退到当前目录；环境变量VERIBLE_LS_PROJECTROOT_OVERRIDE可覆盖编辑器提供的项目根且优先级最高。

.rules.verible_lint：语言服务器默认发布一份文档的全部 lint 问题，可用.rules.verible_lint按项目禁用/启用规则——逗号或换行分隔的规则名设置，如：

-module-filename +posix-eof -no-tabs

辅助工具集

verible-verilog-diff：词法级 Diff

verible-verilog-diff比较两个输入文件是否"等价"，并报告第一个词法差异。等价性由--mode决定：

• --mode=format：忽略空白差异检查文本等价（即"格式化后是否相同"）；
• --mode=obfuscate：连同空白一起比较，并校验标识符长度一致。

等价性分析还会递归地查看宏定义体与宏调用实参内部。退出码约定：0文件等价；1文件不同或存在词法错误；2文件读取错误。

verible-verilog-obfuscate：代码混淆

verible-verilog-obfuscate把代码中的标识符替换为等长的混淆名，保留其余全部文本（含空格），输出到 stdout，结果文件与原文大小一致——因此混淆版文件上的诊断位置（行、列）与原始文件一一对应，非常适合向工具厂商提交可能敏感的测试用例。其选项：

--decode (与 --load_map 联用时反向应用翻译字典以还原，且不对未见标识符做混淆); default: false; --load_map (预加载 --save_map 写出的翻译字典，用于复用既有变换); default: ""; --preserve_builtin_functions (保留 sin()、ceil() 等内建函数名); default: true; --preserve_interface (保留模块名、端口名与参数名，映射表中写入恒等映射); default: false; --save_map (把翻译保存为字典，供未来 --load_map 复用); default: "";

用法形如verible-verilog-obfuscate [options] < original > output。其底层由语言无关的 verible/common/strings/obfuscator.cc 与语言绑定的 verible/verilog/transform/obfuscate.cc 共同实现。

verible-verilog-preprocessor：预处理工具集

verible-verilog-preprocessor是一组预处理风格工具的实现（但尚未包含功能完备的 Verilog 预处理器），对应 verible/verilog/preprocessor/ 库。这也呼应了 README 开篇所述：Verible 解析器既能吃未预处理源码（服务单文件应用），也可适配解析预处理后的源码（服务真实编译器与工具链）。

verible-verilog-project：项目级多工具

verible-verilog-project作用于"文件清单 + 相关配置"组成的整个 Verilog 项目，作为分析（乃至潜在转换）项目级源文件的诊断工具：

verible-verilog-project COMMAND [options...] available commands: file-deps help symbol-table-defs symbol-table-refs --file_list_path (SystemVerilog 文件清单路径，文件应按定义依赖排序); default: ""; --file_list_root (文件清单中相对路径的前缀绝对位置); default: "."; --include_dir_paths (逗号分隔的 include 文件搜索目录，顺序重要， 在第一个命中的目录中停止搜索); default: ;

子命令：symbol-table-defs在全部项目文件上构建统一符号表并打印人类可读表示（不解析引用）；symbol-table-refs进一步尝试把符号引用解析到定义；file-deps打印文件间依赖，例如：

"foo.sv" depends on "bar.sv" for symbols { bar baz } "bar.sv" depends on "baz.sv" for symbols { quux }

其项目/符号表相关实现位于 verible/verilog/analysis/verilog-project.cc 与 symbol-table.cc，文件清单解析见 verilog-filelist.cc。

verible-verilog-kythe-extractor：源码索引

verible-verilog-kythe-extractor按 Kythe 架构从 SV 源码中提取索引事实，可增强 IDE 的符号交叉引用，从而更方便地导航源码。Kythe 所需的存储/分析 schema 已 vendored 在 third_party/proto/kythe/；kythe-browse.sh 与 vnames.json 则服务于本仓库自身的 Kythe 浏览。此外，顶层 BUILD 的install-binaries中还有verible-verilog-kythe-kzip-writer，用于写出 Kythe kzip 包。

测试与覆盖率流程

README 强烈建议使用 Bazel 运行测试套件：

# 运行全部测试 bazel test -c opt //...

仓库的代码组织体现了"每个实现文件必有对应测试"的约定：例如 verible/verilog/analysis/checkers/ 中每个*-rule.cc都伴随同名*-rule_test.cc，verible/verilog/CST/ 的class.cc/module.cc/statement.cc等同样各自配对_test.cc。

为新增功能（假设在foo.cc）时，应同步更新（或新增）对应的foo_test.cc。写完测试后可用.github/bin/generate-coverage-html.sh复核是否覆盖全部代码路径；把覆盖率运行收窄到目标测试，可避免覆盖率"来自恰好使用了该库的无关测试"的假象：

MODE=coverage .github/bin/build-and-test.sh //foo/bar:foo_test .github/bin/generate-coverage-html.sh

需要说明：当前仓库快照的.github/bin/下保留的是simple-install.sh与install-bazel.sh、install-kythe.sh、install-kythe-tools.sh等脚本，README 引用的build-and-test.sh与generate-coverage-html.sh属于贡献流程文档（CONTRIBUTING.md 同样引用了它们），以仓库上游实际内容为准。

社区参与与未来方向

• 贡献前请阅读 CONTRIBUTING.md 与开发资源文档 doc/development.md；风格 lint 规则的开发指南另见 doc/style_lint.md。
• 邮件列表：开发者 verible-dev@googlegroups.com，用户 verible-users@googlegroups.com。
• 未来方向：Verible 团队有意探索为其他工具开发者提供 SystemVerilog 前端，例如输出抽象语法树（AST），甚至提供更高阶的 UHDM 格式；README 中提到的解析器/格式化 demo 动画（上游 issue #528）等仍标注为 TODO。

小结

Verible 以"一次解析、处处受益"的架构，把 SystemVerilog 词法/语法分析（解耦的 Flex lexer + Bison LALR(1) parser + LexicalContext 消歧通路 + 无 loss 的 CST）沉淀为 verible/common/ 下的语言无关基础设施，再在其上生长出 syntax 检查、风格 lint（规则匹配 + 配置 + waiver + autofix）、格式化（代价最小化折行 + 对齐组）、LSP 服务、词法 diff、混淆、项目级符号分析与 Kythe 索引这一整套工具链。无论是排查"为什么我的文件解析失败"（先用verible-verilog-syntax），还是搭建"提交即检查格式与风格"的自动化（verible-verilog-lint/verible-verilog-format或verible-verilog-ls），本仓库的 verible/verilog/tools/ 各目录 README 都提供了可复制的完整命令与参数语义，配合 BUILD 中的install-binaries/install-scripts清单即可完成构建、安装与测试的完整闭环。

• 开发工具
• Lint
• 静态分析
• 硬件开发