01 · What RNL is
Netlists rich in circuit semantics
RNL fills the high-level semantic gap between netlists and schematics: structures, intent and drawing
A real RNL case designed by an agent, and the schematic rendered from it
Review needs no line-by-line reading of the netlist, only a check of the semantics it declares. Exact schematic information can be generated by a solver or output directly by a model.
The netlist owns devices and types, parameters, connections, the subcircuit interface
RNL owns structures, intent, the drawing, display symbols; it only references the netlist
The netlist describes the electrical facts, and Rich Netlist describes how to understand and present the circuit
Hidden in comments
Written in the host netlist’s legal comments, such as SPICE’s * @RNL {…}. Simulators skip it; nothing has to be stripped.
Leaves the circuit alone
It only references the netlist’s devices, nets and terminals; it cannot add devices, connections or parameters.
Any level of detail
From “M1 and M2 are a differential pair” down to every coordinate and bend, mixed freely in one file.
RNL is not
- Another netlist language
- A second connection list
- A format that prescribes one drawing
- A pixel-level image archive
02 · Why
Netlists and schematics each miss half the picture
Simulation runs on netlists; understanding a circuit takes a schematic. Each falls short on its own.
| Task | Netlist | Schematic (proprietary format) | Netlist + RNL |
|---|---|---|---|
| Simulator reads it directly | It is made for that | Export a netlist first | RNL is just comments |
| See the circuit’s structure at a glance | Only lines of text | Yes | A viewer draws it |
| Plain text you can diff and keep in Git | Yes | Binary database | Yes |
| AI can read and write it | Text | Graphical format | The drawing is text too |
| Opens without the original tool | Any text editor | Needs the same software and version | Any RNL viewer |
| Carries design intent | No | Only in the picture; machines cannot read it | Pairs and symmetry are statements |
| One source of truth for the circuit | Yes | Drawing and netlist can disagree | Connectivity comes only from the netlist |
New challenges in AI-driven design flows
AI writes netlists people cannot review
A few hundred generated lines do not tell a reviewer what the circuit is.
AI draws schematics unreliably
Drawing a schematic stroke by stroke is hard for language models, and results vary widely between models.
Agents reach schematics only through EDA tools
The schematic is in a proprietary binary database: reading it or changing one wire goes through the tool’s interface.
Today’s workarounds
Redraw by hand
Slow, and every netlist change means redrawing.
Generate automatically
Auto-layout knows the connections but not the structure: you cannot tell which transistors form a pair.
Screenshots and exports
You keep the picture and lose the circuit: no simulation, no further edits.
Relying on EDA APIs
AI can only edit the circuit through the EDA tool’s API, bound by the EDA ecosystem.
RNL’s approach: a plain-text format that people and AI can read and edit directly, independent of any specific EDA tool
03 · Advantages
What you get from writing the meaning down
Meaning first
Say which devices form a differential pair or a current mirror, what is symmetric, where the current flows. These statements stay in the file however the drawing changes.
One plain-text file
Simulators run it as before; it diffs and merges in Git; the drawing and the netlist cannot drift apart.
AI writes, people review
AI writes the circuit together with its structures and drawing; people review the declared structures and intent in a viewer.
Open
A public standard and symbol libraries, open-source tools, a viewer that opens in the browser.
Circuit separate from style
The netlist defines what the circuit is; packages decide how it looks, like HTML for content and CSS for style. Include the public packages eda-symbol and eda-style, and the same file draws as a traditional EDA schematic. Switch the look in the example.
04 · Scenarios
Same task, two ways
Common situations, handled today and with RNL.
Design a five-transistor OTA for me.
The netlist is there, but nothing in it says what the circuit is.
A few hundred generated lines do not tell a reviewer what the circuit is, and models draw its schematic unreliably.
Design a five-transistor OTA for me.
The agent writes the structures and the drawing along with the circuit; a person reviews what it declared in a viewer.
People review the structures and the intent, not the netlist line by line.
The schematic is a binary database, so version control can only say “the file changed”.
A change is one readable line: M2 moved to x = 30. Git, pull requests and CI work on it as on code.
Schematic changes can be reviewed and rolled back too.
The schematic and the netlist each keep their own copy of the connections, and the two can disagree.
Connectivity is defined only by the netlist. Lines that cross, or endpoints that merely land on each other, never become a connection; drawn wires join only where they share a point or a terminal.
The circuit has one source of truth: the netlist.
Every tool has its own schematic format and its own symbol libraries.
Switching tools often means redrawing the schematic; switching simulators means rewriting the netlist dialect.
The comment prefix follows the netlist format; the RNL content stays identical.
RNL content is the same in every netlist format, and symbols are defined in RNL, so they travel with the file or a library.
Switch simulators or viewers, and the drawing is still there.
Traditional formats open only in the EDA tool that wrote them, so the recipient needs the same setup. A screenshot paired with a netlist goes stale as soon as either changes.
- The simulator runs it as usual
- A browser shows the drawing
- Colleagues and AI can read and edit it
RNL is plain text, easy to share and to open-source: the simulator runs the file and a viewer in the browser draws it.
The drawing travels with the circuit, not with the tool.
05 · Vision
An open ecosystem, and a design flow built on it
RNL is the data layer: circuits and their meaning in files that anyone can open.
An open ecosystem
Circuits and symbol libraries published and reused like open-source software.
- A public standardThe language and its packages, openly specified
- Symbol librariesEvery symbol’s drawing and the text that defines it
- A gallery of circuitsDesigns in public repositories, opened in the web viewer
- Open-source toolsThe runtime, the command line and the viewers
A design flow built on RNL
Agents write and change circuits; people review their structures and intent; EDA tools simulate and verify.
Agents
Write and change circuits, with their structures and drawing.
People
Review the declared structures and intent in a viewer.
ota5t.sp
RNL, the data layer: netlist + meaning
EDA tools
Simulate and verify; a simulator skips the RNL comments.
06 · Status
Where things stand
The language is released as standard 0.3; the web and desktop viewers read, draw and edit netlists, and the solver has a first version. Below are the latest released milestones and what comes next; the full timeline lists every released milestone.
- RNL core 0.5.4
Core 0.5.4: rnl solve says the solver is a preview; each object lists the usages and groups it is a member of, in the Document, the snapshot and the new rnl explain; package files and hardware-description files are known by their format; the solver tells supply, ground and port symbols by their drawing. Release notes
- RNL core 0.5.5
Core 0.5.5: the Document carries the parameters of subcircuits, those a definition gives, those an instance writes and the numbers they come to, and a build can bind values to them; an instance of a subcircuit that Auto Include found defined several times lists the definitions. Release notes
- Desktop viewer 0.5.3
RNL Viewer 0.5.3: entering an instance of a subcircuit that Auto Include found defined several times asks which definition to open; a subcircuit shows its parameters in a bar under the path, and a dialog changes them; entering a subcircuit of another file takes the values its instance writes. Release notes
- Full timeline
- Next
- Language standard 0.4
Planned: symbols chosen by the number of terminals; the new
@SOLVER-CONFIG. - The solver’s objectives, second version
Planned: move the standard package’s names out of hardcoded solver logic into its configuration, so the current-direction, ground-direction and signal-flow objectives work on 0.3 files.
FAQ
Will simulators complain about a netlist with RNL in it?
No. RNL is written only in the host netlist’s legal comments, which simulators skip with no preprocessing. Which exact marker is safe in every vendor’s simulator is still being verified.
Will RNL change my circuit?
No. Devices, parameters and connections are defined only by the netlist; RNL can only reference them. When only RNL changes, the netlist body is kept as is.
Do I have to write coordinates?
No. “M1 and M2 are a differential pair, symmetric about the center line” is a valid description on its own; coordinates can be left to the solver or added later.
Will different tools draw the same RNL the same way?
Parts with exact geometry will match. Parts that state only intent may be drawn differently by different solvers while still satisfying that intent; RNL does not promise pixel-identical output.
How is this different from Virtuoso or KiCad schematic files?
Those are each tool’s own graphical formats, stored apart from the netlist. RNL is attached to the netlist, any tool that supports it can read it, and symbols are themselves defined in RNL.
Why does AI come up so often?
Language models are good at reading and writing text such as netlists. RNL turns the circuit’s structure, intent and drawing into text too, so an agent writes a circuit and its meaning in one file and people review what it declared in a viewer. Free text between statements helps people read, but never changes what machines understand.
Can RNL be written in other languages?
Keywords and standard-package names can have aliases in another language. A file can declare individual aliases with @ALIAS in its header record, or load an alias package (a package file collecting the aliases of a language) with @USE-ALIASES(name=…, version=…), or path=… for a custom file. Standard series 0.3 bundles one so far, Chinese (rnl-zh): write @USE-ALIASES(name="rnl-zh", version="0.3") in the header record to use its aliases. An alias is only an alternate spelling: the two can be mixed freely and machines read the same statements; the header record itself always uses standard spelling.
Can I use it now?
For viewing schematics and editing netlist text, yes: the viewers open netlists with RNL in the browser or on Windows, Linux and macOS, draw placed objects, and let you edit the text and re-render. Automatic layout is early: a first solver is in rnl solve and, as a preview, in the desktop viewer. The web viewer does not run it yet, so it lists unplaced objects in its Not drawn view. Drag-and-drop editing is not yet available.
07 · Next
For the details, go to these pages
- →Language tourWhat the language looks like, nine sections and a few examples, all hands-on
- →StandardThe formal text, with a short guide and the principles
- →PackagesHow every symbol is drawn, and the text that defines it
- →ToolsThe web and desktop viewers, and the whole toolchain
- →For agentsThe skill package, llms.txt and how to use them