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
There was a problem hiding this comment.
Yes, I will actually review each diff in detail once we define an integration strategy to keep the PR in scope. However, good catch
| #[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.
There was a problem hiding this comment.
I gated it with slang because what this tool basically does is to map the outcome of a slang pass (the CST, or the typed AST if one also "elaborates" a single top to resolve param widths etc) into a graph on-disk that can be queried, so in my taxonomy they are closely related.
However, I would agree that any fronted that can produce an AST would also work, since the graph is populated from a frontend-agnostic data structure. If we make this a separate plugin, we probably need to keep tool-agnostic interfaces as it is right now, but this conditional dependency problem in Cargo would be solved (i.e., it is now a "separate" tool/crate)
Hi @micprog, thanks for the comments and initial review. I agree that this feature is not a cheap add-on, although I tried to re-use as much as what bender was offering already and only conditionally add differentiating features in a tool-agnostic way (basically, mapping the simple CST or the typed AST from slang to a generic data structure that could be generated from other fronteds, and then upsert an on-disk graph database from this data structure). I am fine with having this live in a different repo, however I understand this plug-in idea does not exist yet in Bender, or is there a reference example already? If not, we can build it by leveraging this use case, making sure it is generic enough to work with other examples, and then integrate this use case itself. What do you think? Can draft a proposal and we can iterate on it. I'll probably re-use this PR |
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: