Hardware Script

Text-Based Hardware Design Language

What is Hardware Script?

Hardware Script (.hw) is a plain-text hardware design language that compiles to multiple industry-standard formats. Design PCBs, silicon chips, and entire systems all from human-readable, Git-friendly text.

The Goal: Bring the npm/software workflow to hardware. Write hardware like code, compile it deterministically, and manufacture real boards from a single source of truth.

space MyBoard:
    dimensions: 20mm by 20mm by 2.0mm
    grid: 200 by 200 by 4
    profile: JLCPCB_2Layer
    origin: tl by t

    add Transistor_NPN named Switch at [x: 5mm, y: 5mm, layer: l1]

    route Switch.Collector to Power.Out:
        path:
            - [x: 5mm, y: 6mm, layer: l1]
            - [x: 15mm, y: 6mm, layer: l1]
            - [x: 15mm, y: 15mm, layer: l1]

Compiles to:

✅ Gerber X3 (PCB manufacturing)
✅ GDSII (silicon foundry)
✅ DXF (2D CAD, viewable in LibreCAD)
✅ OBJ / GLB (3D models, viewable in Babylon.js Sandbox)
✅ SPICE netlist (analog simulation)
✅ Drill files (viewable in Gerbv Viewer)

Why Hardware Script?

The Problem

Traditional EDA tools (KiCad, Altium, Eagle) were built for clicking GUIs. This creates several problems:

Poor version control — Binary and XML files don't diff or merge well in Git.
No programmatic access — You can't script, template, or parameterize a GUI.
Slow iteration — Manual placement and routing takes hours.
Tool lock-in — Binary formats make sharing and collaboration difficult.

The Solution

Hardware Script treats hardware like software:

✅ Plain text — Write your design by hand, just like any source file.
✅ Deterministic compilation — Same input = same output, every time.
✅ Physics validation — Catch electrical errors at compile time.
✅ Multi-format export — Gerber, DXF, GLB, SPICE from one source.
✅ Package ecosystem — Reusable components like npm packages.
✅ Optional LLM assistance — Because designs are plain text, you can paste a .hw file into any LLM and ask it to generate or modify hardware for you.

Quick Start

Create a Design

Create my_board.hw:

space FirstBoard:
    dimensions: 20mm by 20mm by 2.0mm
    grid: 200 by 200 by 4
    origin: tl by t

    route A to B:
        path:
            - [x: 5mm, y: 5mm, layer: l1]
            - [x: 15mm, y: 5mm, layer: l1]
            - [x: 15mm, y: 15mm, layer: l1]

Compile

hwc build my_board.hw

Preview Live

hsm build/my_board.hsx

Hardware Script Monitor (hsm) opens and hot-reloads your board in under 50ms whenever you recompile.

Generate Manufacturing Files

hwc build my_board.hw --target pcb   # Gerber + drill files
hwc build my_board.hw --target viz   # OBJ + GLB 3D models
hwc build my_board.hw --target spice # SPICE netlist

The Vision: npm for Hardware

Imagine if hardware development worked like software:

# Install a component package
hpm install @power/5v-regulator

# Use it in your design
import Regulator5V from "@power/5v-regulator"

space MyRobot:
    dimensions: 100mm by 100mm by 2.0mm
    grid: 1000 by 1000 by 4
    origin: tl by t

    add Regulator5V named PowerSupply at [x: 50mm, y: 50mm, layer: l1]

    route Battery.Plus to PowerSupply.VIN
    route PowerSupply.VOUT to ESP32.VIN

That's where we're headed. v0.1.7 proves the Rust compiler works end-to-end.

The "Matrix Moment"

Hardware Script uses a discrete 3D tensor grid instead of continuous geometry. This single architectural decision unlocks capabilities impossible in traditional tools:

$O(1)$ collision detection — Mathematically impossible to create short circuits.
Scale invariance — Same tool for PCBs and silicon chips (just change the materials database).
Deterministic routing — Same input always produces the same physical output.
Plain-text access — Any tool or person that can read text can read, edit, or generate .hw files.

Read the full vision: VISION.md

Features

✅ Implemented (v0.1.x)

Text-based design — Write hardware like code.
Unified 3-File Architecture — hw.toml, hw.lock, and .hw source.
Rust compiler — hwc workspace with logos lexer and miette errors.
Unified syntax — Bare identifiers, [] lists, : properties, = logic.
Z-axis abstraction — Physical layer names (layer: l1) or physical units (z: 1.5mm).
Native SI unit parsing — 254µm, 4.7kΩ, 100nF parsed directly in the lexer.
Auto-routing — 3-phase pipeline (Constraint Manager, A* Geometry Router, DRC).
Logic synthesis — logic: block translates operators to gates and D-flip-flops.
Clock domain tracking — CDC violation detection.
Analytic traces — Continuous mathematical line segments (fast, memory-efficient).
Cylindrical vias — PTH, via drills, and annular rings.
Multi-format export — Gerber X3, GDSII, DXF, OBJ, GLB, SPICE.
Live preview — hsm (Hardware Script Monitor) with Babylon.js, PixiJS, and uPlot.
Standard library — SI units and physical constants auto-loaded.
Parallel routing — Rayon-powered domain partitioning.
LVS checking — Physical extracted netlist vs. logical schematic comparison.

🔄 In Progress (v0.2)

Formal UHWSL language specification freeze.
Full public HPM package registry.
Parametric component generics.
Complete Gerber package (all layers, silkscreen, solder mask).
hwsd documentation generation from ## comments.

The Unified File Architecture

Hardware Script uses exactly 3 file extensions:

File	Purpose
`hw.toml`	Project manifest — metadata, targets, dependencies
`hw.lock`	Lockfile — reproducible builds, hashed dependencies
`.hw`	Universal source — materials, profiles, components, modules, spaces, tests

The compiler produces a compiled exchange binary (.hsx) which the live monitor (hsm) watches and hot-reloads.

Project Structure

├── hwc/                     # Rust compiler workspace
│   ├── Cargo.toml
│   ├── crates/
│   │   ├── hwc-cli/         # Command-line interface
│   │   ├── hwc-parser/      # Lexer + AST parser
│   │   ├── hwc-compiler/    # Two-pass compiler
│   │   ├── hwc-engine/      # Voxel grid + routing engine
│   │   ├── hwc-physics/     # DRC, LVS, thermal, electrical
│   │   ├── hwc-export/      # Gerber, GDSII, DXF, GLB emitters
│   │   ├── hwc-materials/   # Materials database
│   │   └── hwc-stdlib/      # Standard library prelude
│   ├── stdlib/              # .hw standard library files
│   └── tests/               # Integration tests (written in Hardware Script)

Technical Stack

Compiler: Rust (logos, miette, rayon, rustc-hash, compact_str, smallvec)
Live Monitor: Tauri v2 + SolidJS + Babylon.js + PixiJS + uPlot + dxf-viewer
Testing: Hardware Script .hw integration test files
Viewing: Babylon.js Sandbox (3D), LibreCAD (DXF), Gerbv Viewer (Gerber/Drill)

Roadmap: The 5 Critical Problems

1️⃣ Hardware Description Language ✅ (v0.1.x)

A clean, text-based, unified language for describing hardware at any scale.

space Board:
    dimensions: 20mm by 20mm by 2.0mm
    grid: 200 by 200 by 4

2️⃣ Component Knowledge Database 🔄 (v0.2)

A universal component library with electrical limits, pins, footprints, and 3D meshes.

Strategy: GitHub-based registry (like Homebrew or Go modules).

3️⃣ Physics/Electrical Validation ✅ (v0.1.x)

Compiler-level physics validation with structured errors and fix hints.

Error E0042: Voltage mismatch
  Expected: 3.3V  Got: 5V
  Hint: Insert a 3.3V LDO between Battery.Out and ESP32.VIN
  Install: hpm install power/ldo_3v3

4️⃣ Integrated Toolchain ✅ (v0.1.x)

Single pipeline from source to manufacturing-ready outputs.

hwc check board.hw      # Validate
hwc build board.hw      # Compile to .hsx
hsm build/board.hsx     # Live preview
hwc build --target pcb  # Manufacturing files

5️⃣ Parametric Hardware Modules 🔄 (v0.2+)

The holy grail: reusable hardware components with parameters.

add BuckConverter (input: 12V, output: 5V, current: 2A) named Converter1

Read the full roadmap: ROADMAP.md

License & Business Model

Open Source (AGPLv3)

Hardware Script is free and open source under the GNU AGPLv3 license.

You own your hardware designs. We own the compiler. Think of it like Microsoft Word: Microsoft owns Word, but you own the documents you create with it.

When You Need a Commercial License

You only need a Commercial License in these specific cases:

✅ Modifying the Compiler — You change hwc source code and want to keep changes private.
✅ Hosting as a Service — You run the compiler on a cloud server accessible via web/API.
✅ Enterprise Support — You need dedicated support and SLA guarantees.
✅ Corporate AGPL Ban — Your company's legal team prohibits AGPL software.

See full details: LICENSE-FAQ.md | COMMERCIAL-LICENSE.md

Contributing

We welcome contributions! This is an open-source project with a clear roadmap.

Priority Areas

Component Library — Define standard parts in .hw format.
Integration Tests — Write tests in Hardware Script.
Export Formats — Drill files, silkscreen, solder mask.
Documentation — Examples, tutorials, and use cases.

How to Contribute

Fork the repository.
Read CONTRIBUTING.md.
Make your changes (and add .hw tests where applicable).
Submit a Pull Request.

Community

GitHub: https://github.com/HardwareScript
Discord: https://discord.gg/G9VBxKpW
Twitter: @hwsl_lang
Email: hwsl.dev@gmail.com

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Hardware Script

What is Hardware Script?

Why Hardware Script?

The Problem

The Solution

Quick Start

Create a Design

Compile

Preview Live

Generate Manufacturing Files

The Vision: npm for Hardware

The "Matrix Moment"

Features

✅ Implemented (v0.1.x)

🔄 In Progress (v0.2)

The Unified File Architecture

Project Structure

Technical Stack

Roadmap: The 5 Critical Problems

1️⃣ Hardware Description Language ✅ (v0.1.x)

2️⃣ Component Knowledge Database 🔄 (v0.2)

3️⃣ Physics/Electrical Validation ✅ (v0.1.x)

4️⃣ Integrated Toolchain ✅ (v0.1.x)

5️⃣ Parametric Hardware Modules 🔄 (v0.2+)

License & Business Model

Open Source (AGPLv3)

When You Need a Commercial License

Contributing

Priority Areas

How to Contribute

Community

Links

FilesExpand file tree

README.md

Latest commit

History

README.md

File metadata and controls

Hardware Script

What is Hardware Script?

Why Hardware Script?

The Problem

The Solution

Quick Start

Create a Design

Compile

Preview Live

Generate Manufacturing Files

The Vision: npm for Hardware

The "Matrix Moment"

Features

✅ Implemented (v0.1.x)

🔄 In Progress (v0.2)

The Unified File Architecture

Project Structure

Technical Stack

Roadmap: The 5 Critical Problems

1️⃣ Hardware Description Language ✅ (v0.1.x)

2️⃣ Component Knowledge Database 🔄 (v0.2)

3️⃣ Physics/Electrical Validation ✅ (v0.1.x)

4️⃣ Integrated Toolchain ✅ (v0.1.x)

5️⃣ Parametric Hardware Modules 🔄 (v0.2+)

License & Business Model

Open Source (AGPLv3)

When You Need a Commercial License

Contributing

Priority Areas

How to Contribute

Community

Links