What is Agni

Agni began as a way to learn hardware design by building tooling for it. I am a software engineer, and I tend to learn a domain by reading its files and reasoning about them in code. The idea was to read real schematics and board layouts and turn them into a representation that a program can work with. Then I could see what ordinary software techniques can say about a hardware design. Those techniques include an intermediate representation, static checks, queries, and structured diffs.

So Agni is closer to a playground than a finished product. It is useful for looking at a design, running some analysis over it, and understanding what is there. It is not trying to replace a professional EDA suite, and it does not claim to catch everything a real design review would. The interesting part is learning the domain by making software analysis work on real files, and adding more analysis as the understanding grows.

The whole thing is built for a software engineer’s eyes. Hardware has its own vocabulary, and most of it maps onto something a programmer already knows. A netlist is a graph. A bill of materials is a lockfile. A datasheet is a type definition with runtime limits. These mappings matter here. The docs explain hardware through them, and someone from software can use them to pick up a real design and reason about it. The software analogy collects them in one place, and the concepts page in the user guide is the read-first version.

What it does today ¶

• reads EDIF, KiCad, IPC-2581, xschem, gEDA and Lepton, and Telesis netlists into one neutral representation,
• runs a catalog of electrical and integrity checks, each finding cited to its evidence,
• compares two revisions as a structured diff,
• answers datalog queries about nets, parts, copper, and datasheet limits,
• renders schematics and boards in the browser, where the demo also runs the engine itself with nothing installed.

Two ways in ¶

• You want to look at or check a design. Start with Use it. No Go required.
• You want to add analysis, a new format, or a rule. Start with Build on it.

How these docs are organized ¶

• Tutorials take one board from its first read to a checklist gating CI.
• Use it covers running the tool on a design, one feature per page.
• Build on it covers adding readers, rules, or an extension.
• Understand it covers how the internals fit together, by subsystem.
• Learn the domain is thirteen chapters on what a hardware engineer knows, each ending in the rules that encode it.
• Reference holds the rule and relation catalogs, the glossary, the software-to-hardware analogy and the format primers.
• Demos says what the in-browser demo is and why it runs there.