Add bender kg command and knowledge graph subsystem#306
Conversation
…igns Introduces the `bender kg` command and six supporting crates: - bender-kg-models: IR types (ModuleData, PortInfo, ParamInfo, InstantiationInfo, …) - bender-kg-extract: SystemVerilog → IR extraction pipeline via bender-slang - bender-kg-store: Grafeo-backed graph + HNSW vector + BM25 text store - bender-kg-similarity: dense module embeddings (Model2Vec / ONNX) - bender-kg-core: orchestration layer with typed Engine query API - bender-kg-mcp: stdio MCP server exposing all queries as MCP tools The kg subsystem supports build, incremental update, and a rich query surface (module search, hierarchy traversal, port/parameter/signal tracing, structural similarity, connectivity checks) consumable from both the CLI and AI assistants.
aottavianoTT
changed the title
bender kg command and knowledge graph subsystem
micprog
left a comment
micprog
left a comment
There was a problem hiding this comment.
This looks like a very large change/addition, created with a lot of AI support. I added some initial feedback to encourage separatation of concerns, but I'm sceptical if this can be reasonably integrated. As I see the use of having access to bender's internal information, I'm wondering if it would make more sense to push this into a separate project, extending bender itself to allow running of plugins that have access to some of the internal functions, e.g., WASM plugins with a bender-internal WASM runtime. I don't think we can confidently maintain such a large addition inside bender itself. What do you think?
| slang = [ | ||
| "dep:bender-slang", | ||
| "dep:bender-kg-core", | ||
| "dep:bender-kg-extract", | ||
| "dep:bender-kg-similarity", | ||
| "dep:bender-kg-mcp", | ||
| "dep:bender-kg-models", | ||
| ] |
There was a problem hiding this comment.
I would prefer if we could gate the new bender-kg behind an additional feature flag, disabled by default. This really looks like an AI-first feature, and I would argue we can keep it disabled for most use-cases.
| ``` | ||
|
|
||
|
|
||
| ### `kg` --- Build and query the design knowledge graph |
There was a problem hiding this comment.
In a rebase, this will need to be moved to the book.
| "crates/bender-kg-mcp", | ||
| ] | ||
|
|
||
| [workspace.dependencies] |
There was a problem hiding this comment.
Is there a way to move these dependencies to the corresponding packages, or can we gate them only for when required? Just wondering regarding clutter.
| // `.vh` headers are de-facto SystemVerilog macro files; | ||
| // downstream tools (VCS, slang, verilator) parse them as part | ||
| // of the unit, so classify them as Verilog here too. | ||
| Some("sv") | Some("v") | Some("vp") | Some("svh") | Some("vh") => { |
There was a problem hiding this comment.
This is an unrelated change, if required move to a separate PR
| #[cfg(feature = "slang")] | ||
| pub mod kg; |
There was a problem hiding this comment.
As mentioned by the Cargo.toml, I'd move this to a separate new feature, not the slang feature. This is repeated across several files, I will not explicitly mention everywhere.
2 participants
This PR introduces a knowledge graph (KG) pipeline that parses SystemVerilog designs via
bender-slanginto a queryable graph, exposed viabender kgCLI and an MCP server for AI assistant integration.Architecture
The pipeline is split across six new crates:
bender-kg-modelsModuleData,PortInfo,ParamInfo,InstantiationInfo, …) used as the common data contract between cratesbender-kg-extractbender-slangto parse SV source files and emit structured IRbender-kg-storebender-kg-similaritybender-kg-coreEngineAPI; callers issue structured queries and get typed results backbender-kg-mcpbender-kg-corein a stdio MCP server so AI assistants can call all queries as MCP toolsQuery surface
Once the KG is built (or incrementally updated), it supports: