开发工具Lint静态分析硬件开发【免费下载链接】veribleVerible is a suite of SystemVerilog developer tools, including a parser, style-linter, formatter and language server项目地址https://gitcode.com/gh_mirrors/ve/verible点击查看免费下载Verible 是 CHIPS Alliance 维护的一套 SystemVerilog 开发者工具集其核心使命是解析符合 IEEE 1800-2017SV-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 发行版上运行。部分发行版也已收录 VeribleNix 提供 Linux x86 与 Arm 二进制包Homebrew 提供 macOS 包。本地源码构建Verible 代码库使用 C 编写C20。构建需要 Bazel 构建系统与一个 C20 兼容编译器依赖可通过系统包管理器安装或者——若已安装 Nix——直接在仓库根目录运行nix-shell即可获得完整的构建环境。仓库根目录的 shell.nix 定义了该环境它固定使用bazel_8并附带flex、bison供可选的本地 flex/bison 构建、gnusedbzl 规则与测试内脚本使用、ripgrep、python3及anytree用于手动运行 JSON 导出示例、lcov覆盖率 HTML 生成、bazel-buildtoolsbuildifier、clang-toolsclang-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 --configcreate_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 StudioWindows 构建还需要 WinFlexBison 3 和 Git-bash。使用 chocolatey 包管理器可一键安装choco install git winflexbison3Bazel 在 PowerShell 下可能还需要设置环境变量以使用 git-bash$env:BAZEL_SHC:\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-syntaxverible/verilog/parser/ 目录包含 SystemVerilog 词法/语法分析实现目标是接受全部合法的 IEEE 1800-2017 SystemVerilog 语法进度以 sv-tests 合规测试套件为度量。其设计要点值得展开解耦设计lexer 与 parser 是解耦的——lexer 可独立用于词法切分parser 适配层verible/verilog/parser/verilog_parser.h接受来自任意来源的 token而非只能消费 lexer 的输出。这使得两者之间可以插入不同的处理通路例如集成预处理、以及语言所需的基于上下文的词法消歧支持任意距离的 lookaheadLexer由 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 工作正常问题可能在后续阶段当其本身就报错时则是其他工具无法工作的根源。启动排查时请优先使用它。其完整命令行选项摘自 READMEusage: 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 的NodeEnumchildren为子节点数组或null与 Token 对象start/end字节偏移、tag、可选text组成token 的tag有三类来源具名 token如SymbolIdentifier、字符串字面量如module、、单字符如;、获取 token 文本时若text键不存在算子与关键字 token 不携带可从源文件按[start, end)读取官方示例给出了 Python 的按字节切片读法Error 对象包含 0 基的line/column、触发错误的text、phaselex/parse/preprocess/unknown与可选的message。核心工具之二风格 Linterverible-verilog-lintverible-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 集成截图。由于它读取的是未预处理输入可以直接检查注释、擅长检查未展开宏的使用但不会尝试理解预处理条件分支也没有语义分析连通性等需要预处理、多文件分析与抽象语法树。其命令行选项摘自 READMEusage: 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 --rulesenum-name-style,line-lengthlength:80,-no-tabs ... verible-verilog-lint --rulesundersized-binary-literalhex:true;lint_zero:true ...命名风格类规则可使用 RE2 正则配置官方给出常见命名风格与正则的对照命名风格正则表达式lower_snake_case[a-z_0-9]UPPER_SNAKE_CASE[A-Z_0-9]Title_Snake_Case[A-Z][a-z0-9]*(_[A-Z0-9][a-z0-9]*)*Sentence_snake_case([A-Z0-9][a-z0-9]*_?)([a-z0-9]*_*)*camelCase([a-z0-9][A-Z0-9]*)PascalCase([A-Z0-9][a-z0-9]*)verible-verilog-lint --rulesenum-name-stylestyle_regex:[a-z_0-9](_t|_e) ...对命名风格规则来说正则无需处理以数字开头的情况——词法/语法分析阶段已经保证了这一点。--rules_config则从文件读取同样语法的配置可换行分隔官方建议各项目维护自己的配置文件以保证成员间一致。豁免waiver机制文件内注释豁免支持四种形态注释下方一行的豁免// verilog_lint: waive rule-name、同行尾注豁免、多条 waive 注释跨行累积、以及waive-start/waive-stop区段豁免。外部 waiver 文件通过--waiver_files逗号分隔多文件等效于按出现顺序拼接指定每行一条waive --rulerule-name-1 --line10 waive --rulerule-name-2 --line5:10 waive --rulerule-name-3 --regex^\s*abc$ waive --rulerule-name-4 --line42 --location.*some_file.*--line支持单行或:分隔的行区间--regex可动态匹配需要豁免的行对存在自动生成文件的项目特别有用--location用正则限定 waiver 只作用于匹配的文件名。语法错误不可豁免应改用替代解析模式见上一节。自动修复autofix一些琐碎违规行尾空格、重复分号等可自动修复--autofix控制修复的呈现/应用方式--autofix 取值说明no不展示、不应用任何修复patch-interactive交互选择修复以 unified diff 写入--autofix_output_fileinplace-interactive交互选择修复并就地修改原文件会修改输入patch将全部可用修复写成 unified diffinplace将全部可用修复就地应用到原文件会修改输入generate-waiver为每条违规生成 waiver 规则作为临时修复未指定--autofix_output_file时patch/waiver 输出到 stdoutgenerate-waiver模式可生成waive --rulerule_name --linenumber --locationfile_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直接生成。核心工具之三Formatterverible-verilog-formatverible-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默认 autoauto按输入观测决定输出换行风格显式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 Serververible-verilog-lsverible-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词法级 Diffverible-verilog-diff比较两个输入文件是否等价并报告第一个词法差异。等价性由--mode决定--modeformat忽略空白差异检查文本等价即格式化后是否相同--modeobfuscate连同空白一起比较并校验标识符长度一致。等价性分析还会递归地查看宏定义体与宏调用实参内部。退出码约定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.ccverible/verilog/CST/ 的class.cc/module.cc/statement.cc等同样各自配对_test.cc。为新增功能假设在foo.cc时应同步更新或新增对应的foo_test.cc。写完测试后可用.github/bin/generate-coverage-html.sh复核是否覆盖全部代码路径把覆盖率运行收窄到目标测试可避免覆盖率来自恰好使用了该库的无关测试的假象MODEcoverage .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-devgooglegroups.com用户 verible-usersgooglegroups.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静态分析硬件开发【免费下载链接】veribleVerible is a suite of SystemVerilog developer tools, including a parser, style-linter, formatter and language server项目地址https://gitcode.com/gh_mirrors/ve/verible点击查看免费下载相关推荐Verible项目中的SystemVerilog格式化器开发指南Verible项目中的SystemVerilog格式化器开发指南 前言 在数字电路设计领域SystemVerilog作为主流的硬件描述语言其代码格式一致性对开发工具Lint静态分析硬件开发Verible项目中的SystemVerilog格式化器开发指南Verible项目中的SystemVerilog格式化器开发指南 前言 Verible项目中的SystemVerilog格式化器是一个强大的代码风格统一工具它开发工具Lint静态分析硬件开发LaTeX语言服务器实现TexLab安装与使用指南LaTeX语言服务器实现TexLab安装与使用指南 项目介绍 TexLab 是一个实现了 Language Server Protocol LSP 的跨平台工创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/14 16:45:28 · 阅读 1.2k Verible 全栈指南：SystemVerilog 解析器、风格 Linter、Formatter 与语言服务器的实现与使用
开发工具Lint静态分析硬件开发【免费下载链接】veribleVerible is a suite of SystemVerilog developer tools, including a parser, style-linter, formatter and language server项目地址https://gitcode.com/gh_mirrors/ve/verible点击查看免费下载Verible 是 CHIPS Alliance 维护的一套 SystemVerilog 开发者工具集其核心使命是解析符合 IEEE 1800-2017SV-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 发行版上运行。部分发行版也已收录 VeribleNix 提供 Linux x86 与 Arm 二进制包Homebrew 提供 macOS 包。本地源码构建Verible 代码库使用 C 编写C20。构建需要 Bazel 构建系统与一个 C20 兼容编译器依赖可通过系统包管理器安装或者——若已安装 Nix——直接在仓库根目录运行nix-shell即可获得完整的构建环境。仓库根目录的 shell.nix 定义了该环境它固定使用bazel_8并附带flex、bison供可选的本地 flex/bison 构建、gnusedbzl 规则与测试内脚本使用、ripgrep、python3及anytree用于手动运行 JSON 导出示例、lcov覆盖率 HTML 生成、bazel-buildtoolsbuildifier、clang-toolsclang-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 --configcreate_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 StudioWindows 构建还需要 WinFlexBison 3 和 Git-bash。使用 chocolatey 包管理器可一键安装choco install git winflexbison3Bazel 在 PowerShell 下可能还需要设置环境变量以使用 git-bash$env:BAZEL_SHC:\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-syntaxverible/verilog/parser/ 目录包含 SystemVerilog 词法/语法分析实现目标是接受全部合法的 IEEE 1800-2017 SystemVerilog 语法进度以 sv-tests 合规测试套件为度量。其设计要点值得展开解耦设计lexer 与 parser 是解耦的——lexer 可独立用于词法切分parser 适配层verible/verilog/parser/verilog_parser.h接受来自任意来源的 token而非只能消费 lexer 的输出。这使得两者之间可以插入不同的处理通路例如集成预处理、以及语言所需的基于上下文的词法消歧支持任意距离的 lookaheadLexer由 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 工作正常问题可能在后续阶段当其本身就报错时则是其他工具无法工作的根源。启动排查时请优先使用它。其完整命令行选项摘自 READMEusage: 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 的NodeEnumchildren为子节点数组或null与 Token 对象start/end字节偏移、tag、可选text组成token 的tag有三类来源具名 token如SymbolIdentifier、字符串字面量如module、、单字符如;、获取 token 文本时若text键不存在算子与关键字 token 不携带可从源文件按[start, end)读取官方示例给出了 Python 的按字节切片读法Error 对象包含 0 基的line/column、触发错误的text、phaselex/parse/preprocess/unknown与可选的message。核心工具之二风格 Linterverible-verilog-lintverible-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 集成截图。由于它读取的是未预处理输入可以直接检查注释、擅长检查未展开宏的使用但不会尝试理解预处理条件分支也没有语义分析连通性等需要预处理、多文件分析与抽象语法树。其命令行选项摘自 READMEusage: 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 --rulesenum-name-style,line-lengthlength:80,-no-tabs ... verible-verilog-lint --rulesundersized-binary-literalhex:true;lint_zero:true ...命名风格类规则可使用 RE2 正则配置官方给出常见命名风格与正则的对照命名风格正则表达式lower_snake_case[a-z_0-9]UPPER_SNAKE_CASE[A-Z_0-9]Title_Snake_Case[A-Z][a-z0-9]*(_[A-Z0-9][a-z0-9]*)*Sentence_snake_case([A-Z0-9][a-z0-9]*_?)([a-z0-9]*_*)*camelCase([a-z0-9][A-Z0-9]*)PascalCase([A-Z0-9][a-z0-9]*)verible-verilog-lint --rulesenum-name-stylestyle_regex:[a-z_0-9](_t|_e) ...对命名风格规则来说正则无需处理以数字开头的情况——词法/语法分析阶段已经保证了这一点。--rules_config则从文件读取同样语法的配置可换行分隔官方建议各项目维护自己的配置文件以保证成员间一致。豁免waiver机制文件内注释豁免支持四种形态注释下方一行的豁免// verilog_lint: waive rule-name、同行尾注豁免、多条 waive 注释跨行累积、以及waive-start/waive-stop区段豁免。外部 waiver 文件通过--waiver_files逗号分隔多文件等效于按出现顺序拼接指定每行一条waive --rulerule-name-1 --line10 waive --rulerule-name-2 --line5:10 waive --rulerule-name-3 --regex^\s*abc$ waive --rulerule-name-4 --line42 --location.*some_file.*--line支持单行或:分隔的行区间--regex可动态匹配需要豁免的行对存在自动生成文件的项目特别有用--location用正则限定 waiver 只作用于匹配的文件名。语法错误不可豁免应改用替代解析模式见上一节。自动修复autofix一些琐碎违规行尾空格、重复分号等可自动修复--autofix控制修复的呈现/应用方式--autofix 取值说明no不展示、不应用任何修复patch-interactive交互选择修复以 unified diff 写入--autofix_output_fileinplace-interactive交互选择修复并就地修改原文件会修改输入patch将全部可用修复写成 unified diffinplace将全部可用修复就地应用到原文件会修改输入generate-waiver为每条违规生成 waiver 规则作为临时修复未指定--autofix_output_file时patch/waiver 输出到 stdoutgenerate-waiver模式可生成waive --rulerule_name --linenumber --locationfile_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直接生成。核心工具之三Formatterverible-verilog-formatverible-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默认 autoauto按输入观测决定输出换行风格显式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 Serververible-verilog-lsverible-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词法级 Diffverible-verilog-diff比较两个输入文件是否等价并报告第一个词法差异。等价性由--mode决定--modeformat忽略空白差异检查文本等价即格式化后是否相同--modeobfuscate连同空白一起比较并校验标识符长度一致。等价性分析还会递归地查看宏定义体与宏调用实参内部。退出码约定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.ccverible/verilog/CST/ 的class.cc/module.cc/statement.cc等同样各自配对_test.cc。为新增功能假设在foo.cc时应同步更新或新增对应的foo_test.cc。写完测试后可用.github/bin/generate-coverage-html.sh复核是否覆盖全部代码路径把覆盖率运行收窄到目标测试可避免覆盖率来自恰好使用了该库的无关测试的假象MODEcoverage .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-devgooglegroups.com用户 verible-usersgooglegroups.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静态分析硬件开发【免费下载链接】veribleVerible is a suite of SystemVerilog developer tools, including a parser, style-linter, formatter and language server项目地址https://gitcode.com/gh_mirrors/ve/verible点击查看免费下载相关推荐Verible项目中的SystemVerilog格式化器开发指南Verible项目中的SystemVerilog格式化器开发指南 前言 在数字电路设计领域SystemVerilog作为主流的硬件描述语言其代码格式一致性对开发工具Lint静态分析硬件开发Verible项目中的SystemVerilog格式化器开发指南Verible项目中的SystemVerilog格式化器开发指南 前言 Verible项目中的SystemVerilog格式化器是一个强大的代码风格统一工具它开发工具Lint静态分析硬件开发LaTeX语言服务器实现TexLab安装与使用指南LaTeX语言服务器实现TexLab安装与使用指南 项目介绍 TexLab 是一个实现了 Language Server Protocol LSP 的跨平台工创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考