Show HN: Atopile – Design circuit boards with code

Hacker News Discussion ↗

A new open-source tool called Atopile aims to let engineers design circuit boards as human-readable code instead of traditional schematics, promising better reuse, version control and automated generation of netlists, BOMs and KiCad layouts. Commenters are excited about modular, shareable hardware “packages” and future features like equation-based component selection, simulation, and smarter auto‑layout, but many experienced engineers are skeptical that text can replace visual schematics or solve hard problems like routing, EMI and complex analog design. The debate centers on whether code-centric workflows can meaningfully improve real-world PCB workflows without sacrificing readability, verification and existing ecosystem integration.

Overall Reception

  • Many commenters are enthusiastic about code-driven PCB design, especially for reuse of common circuits, fewer copy‑paste errors, and better collaboration via Git/CI.
  • Others, especially experienced EEs, are skeptical that text-based schematics solve their main pain points, which they see more in layout, libraries, and manufacturing integration than in schematic capture.

Language and Approach

  • Atopile is a custom, largely declarative, Python‑inspired DSL aimed at readability, units/tolerances, and constrained expressiveness (vs full Python/HDL).
  • It introduces “interfaces” (grouped signals like I²C, SPI) that can be connected between modules; current matching is name‑based and directional roles (master/slave, UART TX/RX) are still rudimentary.
  • Some argue an existing language (Python, Lisp s‑exprs, Verilog/V‑AMS) would be better; others prefer a lighter, domain‑specific markup.

Reuse, Libraries, and Ecosystem

  • Strong focus on reusable modules (e.g., regulators, ESP32, keyboards), a package registry, and sharing designs like packages on PyPI/NPM.
  • Integrated part lookup: given a JLC part number, Atopile can fetch footprints and create component definitions; plans to grow a richer, open component database.

Integration with Existing Tools

  • Today it generates netlists/BOMs and relies on KiCad for layout; some layout snippet reuse already exists.
  • Importing from other schematic formats is possible in principle but currently seen as low value; exporting back to traditional schematics is not yet supported.

Layout, Autorouting, and Simulation

  • Team explicitly postpones full autorouting/placement, arguing current tools lack the design intent (currents, voltages, constraints) they aim to encode in code first.
  • Ideas discussed: physics‑inspired placement (springs/repulsion), differential pairs/impedance-aware types, and later SPICE/simulation integration with CI.

Concerns and Critiques

  • Several EEs stress the enduring value of visual schematics for understanding, review, analog/power design, and debugging; fear code‑only views will be unusable on large, complex boards.
  • Visualizer is requested often; maintainers agree it’s important but expensive to build, so deprioritized vs language, solver, and tooling.
  • Some see Atopile as “just a nicer netlist” or a reinvention of existing HDL/netlist flows; others counter that the real novelty is in workflow, reuse, and ecosystem.

Future Directions and Wishlist

  • Equation solver with units/tolerances, BOM-aware optimization (cost, availability, BOM line count), temperature effects.
  • Better language server, editor support, LSP, and educational material.
  • Higher‑level layout constraints, floorplanning hooks, and more domain‑specific checks (over‑voltage/current, regulator loading, EMC/EMI hints).