6. Parts that care which way round

This is the shortest chapter in the course, and its failure mode is the most visible.

Read chapter 1 first, for how to read a part from what it connects to.

This page teaches at EE3 and EE4, and the levels page says what each level means.

Most parts do not care (EE3) ¶

A resistor works the same either way round. So does a ceramic capacitor, an inductor, a fuse, most connectors’ shells. You can rotate them on the board and nothing changes, so nobody thinks about orientation most of the time.

A minority do care, and they announce it in the symbol: one pin is marked differently from the other. The recurring ones are diodes of every kind, polarised capacitors (electrolytic and tantalum), and anything with a keyed connector body.

The consequences are not equal. A backwards LED does not light. A backwards rectifier stops the circuit working. A backwards tantalum capacitor matters most, because tantalums fail short and can vent or burn, so the mistake destroys the part and sometimes its neighbours.

Here is one, wired backwards (EE3) ¶

Current flows through a diode from anode to cathode and not the other way. This one has its anode on ground and its cathode on the rail, so the only direction it could conduct is the direction it is blocking.

$ agni check --verdicts --rule led-polarity cmd/agni/testdata/conformance/ledpol.fires.kicad_sch
led-polarity  1 fail
    fail  LED1  LED anode is on ground and cathode on a power rail; it can never conduct

1 verdicts across 1 rule(s), 1 fail

Read the witness rather than the rule name. “It can never conduct” states the entire finding, and you can check it against the drawing without knowing anything about the tool.

The severity is error, consistent with chapter 4, because this is a thing that does not work rather than a reliability risk. The board will be built, the LED will be soldered on, and it will never light on any unit.

It is expensive despite being obvious, and the rule’s own Impact says why. The part passes every connectivity check, because both pins are wired to something. Nothing about the netlist looks wrong. It survives assembly and shows up at bring-up as a dead indicator. Fixing it means a part-level rework for a slip made during capture.

The same wiring, on a different part, is correct (EE4) ¶

led-polarity is deliberately LED-only rather than “diode reversed”, and the reason is on the tutorial board:

$ agni query examples/tutorial-project/designs/gateway/gateway.edn 'component.class(?r, "tvs"), component.net(?r, ?n) => ?r, ?n'
r   n               provenance
D1  GND             designs/gateway/gateway.edn ; designs/gateway/gateway.edn:GND
D1  PMIC_MAIN_12V0  designs/gateway/gateway.edn ; designs/gateway/gateway.edn:PMIC_MAIN_12V0

2 result(s)

$ agni check --verdicts --rule led-polarity examples/tutorial-project/designs/gateway/gateway.edn
No rule reported a considered set. Only some rules state one; see --verdicts.

D1 is a TVS diode sitting between GND and the 12V rail. The rule just called that same topology a defect, a diode across a supply oriented so it does not conduct. On a TVS that orientation is the point. A protection diode sits there doing nothing at all until a voltage spike arrives, at which point it conducts and clamps the spike to a level the rest of the board survives. If a TVS conducted in normal operation, it would be a short across the rail.

Zeners are the same story. A zener is used in reverse breakdown, and ordinary diodes are specified never to enter that region.

So the second command reports nothing, because the rule’s scope is component.class == led and there is no LED on that board. If a rule flagged “diode reversed” generally, it would fire on every TVS and every zener on every design. A check that is wrong most of the time gets muted, and after that it catches nothing at all.

That is worth holding on to as a general point about checks rather than about diodes. A topology means different things on different parts. Deciding correctness needs to know what the part is, and establishing part identity comes before any other question the tool asks.

What the tool has to know (EE3) ¶

To make this judgement at all, two separate facts have to be available, and both come from outside the connectivity graph.

The first is which pin is the anode. That is a pin role, and it comes from the symbol. A symbol that types its pins as two anonymous passives leaves nothing to reason about.

The second is which net is ground and which is a rail, and that comes from naming conventions. Chapter 1 mentioned that layer, and the tutorials cover it in rung 4. A net called GND is ground by convention rather than by anything electrical in the netlist.

Take either away and the check cannot run. That is the limit of what the rule can check. The rule reasons from rail names rather than from current direction, because no netlist carries which way current is meant to flow through an arbitrary diode.

What you can now answer ¶

• Which parts have an orientation, and which of them are dangerous rather than merely broken. (EE3)
• Why a reversed LED passes every connectivity check on the board. (EE4)
• Why the same diode-across-a-rail topology is a defect on one part and correct on another. (EE4)
• What two facts a polarity check needs, and where each comes from. (EE3)

The rules this page explains ¶

Rule	Severity	What it catches
led-polarity	error	an LED whose anode is on ground and cathode on a rail

One rule, hence the short chapter. The general version, covering rectifiers and polarised capacitors, needs a fact about intended current direction that no netlist carries.

The next chapter, reading a datasheet like a type signature, crosses from what a netlist can tell you into what only a document can.