| name | external-db |
| description | 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).
|
| priority | 80 |
| activation | {"keywords":["external db","external database","reference db","reference design","knowledge base","reuse","rtl reuse","prior art","existing rtl","previous project","previous-project","reference rtl","proven design","andes","ip reuse","uart","spi","i2c","iic","gpio","dma","dmac","bus matrix","apb","ahb","bridge","timer","watchdog","wdt","rtc","pit","fifo","local memory","lmbrg","peripheral","soc integration"],"file_patterns":["*.md","*.yaml","*.yml","*.sv","*.v","*.txt"],"auto_detect":true} |
| requires_tools | ["external_db_query"] |
| related_skills | ["verilog-expert","testbench-expert"] |
⚠️ 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
