⚠️ MANDATORY: Check the external DB before reinventing
Before generating/hand-writing RTL for a peripheral or bus block — or stating a
"reference" design or convention — FIRST query the external reference database for an
existing, proven source. Reuse interface conventions, module decomposition, register
layouts, and cited facts rather than inventing them.
The external DB is, by design, external and data-source-agnostic — this skill
does not assume any structure, and the DB is optional. If no wiki, builder, or query
hook is configured, say the external DB is unavailable and continue from the active
SSOT/spec. The deployment wires the source via any one of (newer ATLAS_EXTERNAL_DB_*
names are preferred; legacy ATLAS_RTL_DB_* still work):
…_WIKI — a wiki directory (markdown + _graph.json).…_BUILDER — an external converter that builds _graph.json from a foreign corpus.…_QUERY — an external executable that owns the entire query (its own structure /
search / transport: files, DB, HTTP, vector store…).
You never need to know which is configured — always go through external_db_query
for external DB lookup. wiki_query(ip="external-db", ...) is the underlying
compatible path when a caller needs the generic wiki tool.
This activation model is the same style as protocol/reference skills such as
pcie-expert, nvme-expert, or ucie-expert: the skill can trigger whenever the work
needs prior art, but useful answers depend on the configured data source.
How to query
external_db_query(topic="<block / interface / topic>", depth=3)
Equivalent generic form: wiki_query(ip="external-db", topic="<topic>", depth=3).
(ip="rtl-db" / "andes" are accepted aliases on wiki_query for the same source.)
Examples:
external_db_query(topic="uart apb dma fifo", depth=3)
external_db_query(topic="ahb bus matrix interconnect", depth=2)
external_db_query(topic="spi flash bridge", depth=3)
external_db_query(topic="module port parameter fsm datapath register memory clock reset docs datasheet", depth=3)
depth: 1 = id+title, 2 = +status/meta, 3 = +summary. Start broad (a family keyword
or topic=""), then drill into the specific id the first query surfaces.
Workflow
- Identify the block/interface/topic from the SSOT or the user's request.
- Query the external DB with the relevant family + interface keywords. For RTL
reuse/reference work, include AST-level terms when useful:
module, port,
parameter, fsm, datapath, register, memory, clock, reset, docs,
datasheet.
- If a match is found, cite it (id + path) and reuse its conventions:
bus signal set + naming (APB
psel/penable/paddr/…, AHB haddr/htrans/…),
module decomposition, register map, reset/clock conventions.
- If nothing matches, say so explicitly and proceed cleanly — never fabricate a citation.
Rules
- Never claim something exists in the external DB without a
wiki_query result backing it.
- Reuse conventions and structure; the active IP's SSOT remains authoritative on conflict.
- Complements the protocol spec experts ([[verilog-expert]],
pcie-expert, …): use those
for spec semantics, use this for "has someone already built / documented this?".
1---2name: external-db3description: External reference-database expert. Before authoring new RTL — or answering from assumed knowledge — consult the configured external DB for proven, authoritative references instead of reinventing. The DB is typically a prior-project / vendor RTL corpus (e.g. Andes peripherals: UART, SPI, I2C, GPIO, DMA, AHB bus matrix, bridges, timers), but it is NOT limited to RTL: it can hold spec excerpts, reference designs, datasheets, or any prior-art knowledge wired in by the deployment. Trigger on: external db, reference db, reference design, prior art, reuse, existing rtl, previous project, knowledge base, and common peripheral/bus families (uart, spi, i2c, gpio, dma, apb, ahb, bus matrix, bridge, timer, watchdog, rtc, fifo).4---56# ⚠️ MANDATORY: Check the external DB before reinventing78**Before generating/hand-writing RTL for a peripheral or bus block — or stating a9"reference" design or convention — FIRST query the external reference database for an10existing, proven source. Reuse interface conventions, module decomposition, register11layouts, and cited facts rather than inventing them.**1213The external DB is, by design, *external* and **data-source-agnostic** — this skill14does not assume any structure, and the DB is optional. If no wiki, builder, or query15hook is configured, say the external DB is unavailable and continue from the active16SSOT/spec. The deployment wires the source via any one of (newer `ATLAS_EXTERNAL_DB_*`17names are preferred; legacy `ATLAS_RTL_DB_*` still work):1819- `…_WIKI` — a wiki directory (markdown + `_graph.json`).20- `…_BUILDER` — an external converter that builds `_graph.json` from a foreign corpus.21- `…_QUERY` — an external executable that owns the *entire* query (its own structure /22 search / transport: files, DB, HTTP, vector store…).2324You never need to know which is configured — always go through `external_db_query`25for external DB lookup. `wiki_query(ip="external-db", ...)` is the underlying26compatible path when a caller needs the generic wiki tool.27This activation model is the same style as protocol/reference skills such as28`pcie-expert`, `nvme-expert`, or `ucie-expert`: the skill can trigger whenever the work29needs prior art, but useful answers depend on the configured data source.3031## How to query3233```34external_db_query(topic="<block / interface / topic>", depth=3)35```36Equivalent generic form: `wiki_query(ip="external-db", topic="<topic>", depth=3)`.37(`ip="rtl-db"` / `"andes"` are accepted aliases on `wiki_query` for the same source.)3839Examples:40```41external_db_query(topic="uart apb dma fifo", depth=3)42external_db_query(topic="ahb bus matrix interconnect", depth=2)43external_db_query(topic="spi flash bridge", depth=3)44external_db_query(topic="module port parameter fsm datapath register memory clock reset docs datasheet", depth=3)45```4647`depth`: 1 = id+title, 2 = +status/meta, 3 = +summary. Start broad (a family keyword48or `topic=""`), then drill into the specific id the first query surfaces.4950## Workflow51521. **Identify the block/interface/topic** from the SSOT or the user's request.532. **Query the external DB** with the relevant family + interface keywords. For RTL54 reuse/reference work, include AST-level terms when useful: `module`, `port`,55 `parameter`, `fsm`, `datapath`, `register`, `memory`, `clock`, `reset`, `docs`,56 `datasheet`.573. **If a match is found**, cite it (id + path) and reuse its conventions:58 bus signal set + naming (APB `psel/penable/paddr/…`, AHB `haddr/htrans/…`),59 module decomposition, register map, reset/clock conventions.604. **If nothing matches**, say so explicitly and proceed cleanly — never fabricate a citation.6162## Rules6364- Never claim something exists in the external DB without a `wiki_query` result backing it.65- Reuse *conventions and structure*; the active IP's SSOT remains authoritative on conflict.66- Complements the protocol spec experts ([[verilog-expert]], `pcie-expert`, …): use those67 for spec semantics, use this for "has someone already built / documented this?".
together2329