CircuitJSON Schematics Overview

• CircuitJSON is a structured, machine-parsable schema that defines electrical circuits with both flat and hierarchical representations for diverse design workflows.
• It supports robust workflows including vision-based schematic parsing, LLM-aided synthesis, and differentiable simulation to ensure electrical and schema consistency.
• Its applications span analog circuit sizing, automated schematic synthesis, and simulation analytics, bridging raw images and text to computable hardware artifacts.

CircuitJSON is a structured, machine-parsable schema for representing electrical circuits, designed for maximum interoperability across vision-language modeling, differentiable simulation, and language-model-aided design. It underpins state-of-the-art workflows in both analog and digital domains, allowing faithful serialization of schematic connectivity, device parameters, subcircuit hierarchy, and application-specific constraints. CircuitJSON has become the substrate for automated analog sizing (as in VLM-CAD), multi-agent design frameworks (CircuitLM), and differentiable graph-based simulation, providing a bridge from raw images or natural language descriptions to computable hardware artifacts (Pan et al., 12 Jan 2026, Hasan et al., 8 Jan 2026, Long et al., 2024).

1. Schema Specification and Core Structure

CircuitJSON’s top-level schema consists of well-defined, typed fields, with some variants depending on the target workflow. Major schema patterns include:

• Flat (“atomic netlist”) form: An object with fields such as components, nets, ports, metadata (VLM-CAD/Image2Net (Pan et al., 12 Jan 2026)), or version, author, components, nets, constraints (CircuitLM (Hasan et al., 8 Jan 2026)).
• Hierarchical (“module-library”) form: A dictionary whose keys are subcircuit names and whose values are module definitions supporting deep compositionality (differentiable simulation (Long et al., 2024)).

Common elements appear in all variants:

Key	Type	Purpose
components	array/object	List/map of discrete circuit devices
nets	array	List of topological networks (“nets”)
ports	array (opt.)	Explicit I/O or external terminals
metadata	object (opt.)	Detection/session/image or model info
constraints	object (opt.)	Design/electrical domain constraints
(hierarchical keys)	dict	Subcircuit/module specifications

Example: Flat CircuitJSON (VLM-CAD fragment)

{ "components": [ { "id": "M1", "type": "NMOS", "attributes": { "W": 10.0, "L": 0.5 }, ... }, ... ], "nets": [ { "id": "net1", "name": "VIN", "type": "signal", "nodes": [ ... ] }, ... ], "metadata": { "image_width": 600, ... } }

Example: Hierarchical CircuitJSON (Computational-Graph variant)

{ "RCseries": { "ExternalNodes": ["n1", "n2"], "InputParams": ["R", "C"], "Schematic": { ... } }, "TopRC": { "ExternalNodes": ["Vin", "Gnd"], "Schematic": { "rc1": { "MasterName": "RCseries", ... } } } }

Fields such as attributes (for device sizing), pins (pin connectivity and mapping), and SubModel (for behavioral models and gradient-enabling constructs) enrich the expressivity for downstream inference and optimization (Pan et al., 12 Jan 2026, Long et al., 2024).

2. Generation Methodologies and Pipelines

The CircuitJSON representation is the output of various automated workflows:

• Vision-based Schematic Parsing: Image2Net (VLM-CAD) processes binarized, high-resolution schematics via CV primitives (Otsu thresholding, morphological closing, Harris/SIFT/ORB/BRISK corner detection), YOLOv8-Pose object detection, and wire-junction inference. A connectivity graph clusters pins and corners, ultimately resolving net structures (including power, ground, and signal nets) before assembling the JSON document with detected components, pins (bearing pose/confidence scores), and metadata (Pan et al., 12 Jan 2026).
• LLM-Aided Schematic Synthesis: CircuitLM applies a five-stage pipeline: (i) natural-language prompt → component NER, (ii) pinout retrieval, (iii) stepwise chain-of-thought reasoning for connection logic, (iv) structured JSON synthesis, (v) automated SVG visualization. Component mapping is grounded in an embedding-powered knowledge base, avoiding schema violations and electrical inconsistencies. Downstream validation (Dual-Metric Circuit Validation, DMCV) quantifies both syntactic and electrical consistency (Hasan et al., 8 Jan 2026).
• Hierarchical Decomposition for Simulation: In the computational graph representation, CircuitJSON specifies both atomic and nested modules (e.g., parameterized RC, inverter, or differential pair subcircuits), capturing parameter dependency maps, submodel instantiation, and full inter-module port binding (Long et al., 2024).

3. Hierarchical Representation and Module Composition

CircuitJSON supports both flat and deep hierarchy. The hierarchical model is central to differentiable simulation and design, as described in (Long et al., 2024):

• ModuleDefinition: Each entry details formal ExternalNodes (ports), InternalNodes (private nets), InputParams (design variables or parameters), an optional SubModel (describing behavioral relations, possibly as analytic expressions or external loaders), and a Schematic mapping instance names to instance definitions.
• InstanceDefinition: Binds a module (primitive or subcircuit) to parent nodes and parameter values; allows literal constants, upward-propagated parameters, or intrinsic outputs from parent SubModels.
• SubModel: Specifies intrinsic parameter computation and (optionally) analysis modes—enabling parametric gradients and Jacobians for differentiable workflows.

Example: Nested Netlist (inverter within differential pair)

"DiffPair": { "ExternalNodes": ["VinP", "VinM", "Vout", "Vdd", "Gnd"], "Schematic": { "invP": { "MasterName": "Inverter", "ExternalNodes": { ... }, "InputParams": { ... } }, ... } }

Module composition rules:

• No shared internal node names across siblings.
• Children can only reference parameters exposed by parent modules or global scope.
• Hierarchical gradient propagation ensures global differentiability for design automation (Long et al., 2024).

4. Downstream Processing: VLM and Simulation Integration

CircuitJSON's structure is optimized for direct ingestion by both language/vision models and circuit simulation backends:

• VLM Integration (e.g., Gemini 3 Flash Preview in VLM-CAD): The JSON is tokenized preserving the key-value and structural delimiters, ensuring that VLMs parse net topology, device types, and sizing attributes without hallucination. System prompts embed the JSON and request block-wise narrative, DC bias extraction, and design initialization, with downstream collaborative agent feedback. The explicit net and pin references guard against logical inconsistencies and enhance explainability for end users (Pan et al., 12 Jan 2026).
• Simulator Coupling: JSON-derived netlists are mapped to SPICE-compatible formats or simulator-native JSONs (such as Wokwi), with hooks for parametric sweeps, layout hints, and constraint classes (e.g., “POWER”, “SIGNAL”, each with voltage/current domains). The hierarchical form directly feeds computational graph simulators, where each module's SubModel produces local contributions to the global remainder function, enabling gradient-based optimization and sensitivity analysis (Long et al., 2024).
• Validation: CircuitLM employs DMCV with formulaic scoring: $S_{\mathrm{DMCV}} = 0.4 V_s + 0.6 V_e$, where $V_s$ penalizes schema violations and $V_e$ aggregates electrical rule violations by severity. This dual-metric approach supports robust LLM-aided circuit generation pipelines (Hasan et al., 8 Jan 2026).

5. Application Domains and Knowledge Base

CircuitJSON underlies diverse workflows:

• Analog circuit sizing: Used in VLM-CAD to bridge schematic images and automated DC/design-space optimization, preserving device granularities such as W/L/mult for each transistor, supporting subcircuit block annotation and sizing propagation, and enabling report generation with blockwise and device-wise targets (Pan et al., 12 Jan 2026).
• Schematic synthesis from NL prompts: CircuitLM grounds schematic generation in a dynamic, extensible component KB, supporting both discrete (MCU, LEDs, passives) and parametric (MOSFET) families. Embedding and fuzzy-matching ensures that both user-facing prompts and LLM agent outputs are always mapped to valid, library-compliant device definitions (Hasan et al., 8 Jan 2026).
• Differentiable simulation and sensitivity analysis: The computational-graph CircuitJSON enables forward and backward passes through hierarchical structures, with support for intrinsic behavioral modeling, ODE encoding, and local/global gradient computation for automated design and parameter sweep studies (Long et al., 2024).

Component Knowledge Base Structure (as in (Hasan et al., 8 Jan 2026)):

• Canonical id and aliases
• Detailed pins with direction, role, and electrical characteristics
• Embeddings for similarity search
• Support for new component addition by embedding and alias extension

6. Design Trade-Offs, Extensions, and Future Directions

Schema design trade-offs:

• Verbosity vs. Parsability: Inclusion of pixel-accurate geometry and detection confidence in certain workflows (e.g., vision-based pipelines) can be eliminated post-CV verification for more compact netlist exchange (Pan et al., 12 Jan 2026).
• Flexibility vs. Standardization: Open-ended attributes allow future device families and custom behavioral models; stricter schemas (including draft-7 JSON Schema/XSD or enforced parameter sets per component type) are possible where tool-chain compliance and validation are critical (Hasan et al., 8 Jan 2026).

Anticipated and supported extensions:

• Hierarchical subcircuit arrays with local net remapping
• Explicit behavioral models (e.g., .lib references, temperature/parametric sweeps)
• Physical/layout constraints for analog/mixed-signal and cross-domain design
• Parametric net class and sweep metadata (e.g., temperature, supply scaling)
• Support for non-linear, time-varying, and behavioral primitives (e.g., VCVS, CCCS)

A plausible implication is that CircuitJSON serves as an abstraction layer not only for schematic exchange and simulation but as a canonical interface for LLM-, VLM-, and agent-driven design flows. Its extensibility supports emerging paradigms in design-automation, explainable AI in EDA, and differentiable, end-to-end circuit optimization.

7. Examples

Flat (VLM-CAD) with annotation:

{ "components": [ { "id": "M1", "type": "NMOS", "attributes": { "W": 10.0, "L": 0.5, "mult": 1 }, "pins": [ { "name": "drain", "pose": [120,260], "net": "net2", "confidence": 0.96 } ] } ], "nets": [ { "id": "net1", "name": "VIN", "type": "signal", "nodes": [ { "component_id": "M1", "pin_name": "gate" } ] } ] }

Hierarchical (computational graph, (Long et al., 2024)):

{ "Inverter": { ... }, "DiffPair": { "ExternalNodes": ["VinP","VinM","Vout","Vdd","Gnd"], "Schematic": { ... } } }

Digital/embedded, with constraint classes (CircuitLM (Hasan et al., 8 Jan 2026)):

{ "version": "1.0.0", "author": "CircuitLM_v1", "constraints": { "maxVoltage": 5, "maxCurrent": 0.020, "netClasses": [ { "className": "POWER", "voltageDomain": 5, "currentLimit": 1.0 } ] }, ... }

• VLM-CAD (Vision LLM-Optimized Collaborative Agent Design) (Pan et al., 12 Jan 2026)
• CircuitLM (Multi-Agent LLM-Aided Schematic Generation) (Hasan et al., 8 Jan 2026)
• Computational Graph Representation in Hierarchical Simulation (Long et al., 2024)