← AXO-001

Circuit review & bench-test guide

AXO-001 — LED bar + traffic light PMOD module

Document purpose#

This document explains the axo-001-led-bar module at component level and turns the design evidence into a practical manual-review and bench-test plan. It is based on generate_design.py, README.md, and the schematic/ERC artifacts in this directory.

This board has never been fabricated or assembled. The schematic is reported ERC clean (0/0) and the netlist has been reviewed, but PCB layout has not started, no physical board exists, and there is no first-article bench result of any kind. Every number in this guide is a design target or a datasheet expectation to verify, not a proven result.

1. What the board does#

AXO-001 is the first-blinky board of the AruviX output line: a PMOD Type 1 (GPIO) peripheral carrying 11 LEDs on 8 host pins. Eight discrete 0603 green LEDs (D1–D8) form an 8-bit bar driven by PMOD pins 1–4 and 7–10. Three traffic LEDs — red D9, yellow D10, green D11 — are wired in parallel with bar segments 0, 1, 2 (nets BAR0/BAR1/BAR2), each through its own 330 Ω ballast resistor. PMOD pins 1–3 therefore light the traffic head and the bar LSBs at the same time. That deliberate sharing is the second lesson of the board: one net, two loads, independent ballast so per-LED brightness stays independent.

Every line is host-driven: pin → 330 Ω → LED anode → LED → cathode → GND. The host sources the LED current out of an FPGA/MCU output when it drives the pin high; the LED is active-high. There are no ICs, no decoupling, no regulator, no protection beyond the ballast resistors, and no module-driven lines (so the AruviX 100 Ω sensor-line rule does not apply here). It is a 3.3 V-only module; the host defines the rail.

Functional block diagram#

PMOD plug J1 (2x6, Type 1 GPIO)
  6/12: 3V3   (unused by the LEDs — no active parts to power)
  5/11: GND ──────────────── all 11 LED cathodes

  1: BAR0 ──┬── R1 330R ── D1  green  (bar seg 0) ── GND
            └── R9 330R ── D9  red    (traffic R)  ── GND
  2: BAR1 ──┬── R2 330R ── D2  green  (bar seg 1) ── GND
            └── R10 330R ─ D10 yellow (traffic Y)  ── GND
  3: BAR2 ──┬── R3 330R ── D3  green  (bar seg 2) ── GND
            └── R11 330R ─ D11 green  (traffic G)  ── GND
  4: BAR3 ───── R4 330R ── D4  green  (bar seg 3) ── GND
  7: BAR4 ───── R5 330R ── D5  green  (bar seg 4) ── GND
  8: BAR5 ───── R6 330R ── D6  green  (bar seg 5) ── GND
  9: BAR6 ───── R7 330R ── D7  green  (bar seg 6) ── GND
 10: BAR7 ───── R8 330R ── D8  green  (bar seg 7) ── GND

2. Safety and scope boundaries#

• Voltages are low (3.3 V) and currents are a few milliamps per LED; the hazards are to the board, not the operator. Standard ESD handling applies — the exposed PMOD pins connect straight to the LED ballast network, and the APT1608 LEDs are rated 8 kV HBM but the copper is not.
• 3.3 V only. There is no active part that would care about 5 V, but the AruviX module rules and the PMOD spec fix the rail at 3.3 V and the current math below assumes 3.3 V. A 5 V host roughly doubles per-LED current and can exceed the LED DC rating on the shared pins.
• Do not drive the shared pins (1–3) from a low-impedance source expecting a single LED load — they carry two LEDs in parallel and source roughly twice the single-LED current.
• Confirm your host I/O bank can source the peak simultaneous current (see section 7) before lighting all 11 LEDs at once.
• A lit LED is not proof of the intended logic value or brightness match; the green/red/yellow dice have different forward voltages and luminous efficiencies, so equal current does not mean equal apparent brightness.

3. Power and signal sequence#

1. The host (or bench supply) applies 3.3 V to pins 6/12 with GND on 5/11. Nothing draws from 3V3 — there are no active parts — so 3V3 is present only for PMOD-spec conformance and any future option.
2. Each PMOD signal pin idles at whatever the host drives. An unconfigured (tri-stated) host pin leaves that LED dark; there are no pull resistors, so the default state of an unconfigured input is "off" only because the ballast+LED presents a high impedance to ground, not because anything holds the pin low.
3. Driving a pin high sources current through the ballast into the LED anode; the LED lights. Driving it low (or tri-stating) extinguishes it.
4. On the three shared nets (BAR0/1/2) the same host pin lights a bar segment and a traffic LED together, each through its own 330 Ω. The two branches do not interact except by sharing the pin's total sourced current.

4. Interfaces#

Note the 2×6 header zigzag-vs-PMOD-row numbering translation: on the physical J1 header, PMOD pins 1–6 map to one row of pads and 7–12 to the other (see PMOD_TO_HEADER in the common library and the eventual pcb.connect table). Buzz this out before first power. There are no test points and no jumpers; probe the J1 pins and the resistor/LED pads directly.

5. Component-by-component review#

Every reference designator on the board is covered below: J1, R1–R11, and D1–D11. There are no other components.

5.1 Connector#

5.2 Bar segment channels (green)#

5.3 Traffic-light channels (parallel with BAR0–2)#

6. Datasheet summary and design interpretation#

Primary reference for the green LEDs: Kingbright APT1608SGC, Spec DSAD0932, Rev V.22B, 2023. The red (APT1608SURCK) and yellow (APT1608SYCK) parts are the same 1.6×0.8 mm package in different die; confirm each exact sheet before procurement.

Per-LED current math (the first lesson)#

Ohm's law on the ballast, I = (VOH_host − VF) / R:

All are far below the 25 mA DC rating of the LED — the board is deliberately conservative (~3–4 mA gives a clearly visible indicator without stressing an FPGA I/O). The green die's higher VF makes it draw the least current, which is why the green bar can look slightly dimmer than the red/yellow traffic dots at equal ballast: equal ballast is not equal brightness. That is expected and is itself a talking point, not a defect.

Shared-pin current budget (the second lesson)#

Pins 1, 2, 3 each drive two LEDs in parallel through two separate 330 Ω resistors, so the host pin sources the sum:

• Pin 1 (BAR0): D1 3.3 mA + D9 3.9 mA ≈ 7.2 mA
• Pin 2 (BAR1): D2 3.3 mA + D10 3.6 mA ≈ 6.9 mA
• Pin 3 (BAR2): D3 3.3 mA + D11 3.3 mA ≈ 6.6 mA
• Pins 4, 7–10: one LED each, ≈ 3.3 mA

A Lattice ECP5 I/O in a normal drive setting sources well over 8 mA, so a single shared pin is fine. The number that matters at the bank level is the worst case with all 11 LEDs on at once: 8 × 3.3 mA (bar) + 3.9 + 3.6 + 3.3 (traffic) ≈ 37 mA total sourced from the host across 8 pins. Confirm the host bank's aggregate source budget before an all-on test.

7. Expected values before bench testing#

None of these have ever been measured — no board exists.

8. Manual schematic and assembly review checklist#

Layout evidence does not exist yet (PCB not started); this is a schematic/BOM desk review plus a pre-mate inspection once a board is built.

• Confirm every LED polarity: cathode to GND, anode to its ballast resistor. All 11 cathodes tie to the GND pour; a reversed LED simply stays dark (no protection diode), so a whole-bar polarity error is easy to miss until power.
• Verify the three shared nets: BAR0 feeds R1→D1 and R9→D9; BAR1 feeds R2→D2 and R10→D10; BAR2 feeds R3→D3 and R11→D11. Each branch must have its own 330 Ω — a single shared ballast would make the two LEDs fight and change brightness (that is the failure the design deliberately avoids).
• Confirm R1–R11 are all 330 Ω before first power if any hand-rework happened.
• Verify J1 pin-1 position against the Digilent PMOD spec 1.2.0 and a physical host socket; buzz the header zigzag mapping (PMOD pin ↔ header pad).
• Confirm the traffic head is grouped and silkscreened R/Y/G on the eventual layout, and that the bar order BAR0…BAR7 is legible so the byte reads left-to-right or right-to-left as the HDL expects.
• Confirm the red/yellow MPNs (APT1608SURCK / APT1608SYCK) are stuffed in the right positions — the three traffic dots are the only non-green LEDs and a swap is a silent color error.

9. Ordered bench-test procedure#

Stop at the first abnormal result. Record board serial, host/supply, equipment, and operator for every phase. Two host contexts: standalone (current-limited bench supply driving pins by hand, phases A–C) and PMOD host (FPGA/MCU, phase D). Do standalone first.

A. Unpowered inspection and resistance tests#

1. Complete the section 8 checklist under magnification.
2. DMM each BARn pin to GND, both polarities: ~330 Ω forward / open reverse (pins 1–3: ~165 Ω forward). A hard short means a bridged LED or resistor; an open both ways means an open ballast or missing LED.
3. 3V3 to GND: open both polarities.

B. Standalone first blink (current-limited bench supply)#

1. Bench supply set to 3.3 V, current limit ~50 mA, output off. Wire supply − to J1 GND (pin 5 or 11). Do not connect supply + to 3V3 (nothing uses it); instead use a series 330 Ω-safe test lead from +3.3 V to one BARn pin at a time, or drive pins from a 3.3 V logic source.
2. Touch +3.3 V to BAR3 (pin 4): D4 (a single green segment) lights at ~3.3 mA. This is the true first blink — one pin, one LED.
3. Touch +3.3 V to BAR0 (pin 1): both D1 (green bar seg 0) and D9 (red traffic) light. Confirm the shared-pin behavior directly; measure ~7 mA.
4. Walk every pin 1–4 and 7–10; confirm the correct LED(s) light and nothing else does. Any pin lighting the wrong LED is a net/zigzag-map error.

C. Current verification#

1. Put a mA meter in series with the +3.3 V lead to a single-LED pin (e.g. pin 4): expect ~3.3 mA green.
2. Repeat on a shared pin (pin 1): expect ~7 mA (two branches).
3. Measure VF across a lit green LED (~2.2 V) and across the red (~2.0 V) and yellow (~2.1 V) traffic LEDs; confirm they match the current math.

D. PMOD-host context (FPGA/MCU drives the pins)#

1. Verify the host PMOD socket really supplies 3.3 V and the host I/O bank is 3.3 V. Plug the module in.
2. Run first-blinky: toggle one BARn output, confirm the matching LED. Then a walking-ones (Knight Rider) pattern across BAR0…BAR7 — watch for a stuck or swapped bit that reveals a net error.
3. Binary up-counter on the 8-bit bar: confirm the byte reads in the expected bit order (this is where a reversed header mapping shows up).
4. Traffic-light FSM on pins 1–3: confirm R/Y/G sequence, and note that the bar LSBs mirror it (intended). PWM one pin and confirm smooth dimming.
5. All-on stress: drive all 8 pins high, confirm ~37 mA aggregate and that the host bank tolerates it without VOH droop dimming the LEDs.

E. Release-only tests#

LED lifetime/derating, apparent-brightness matching across colors, ESD, and thermal derating at elevated ambient are out of scope for the first bench pass and must be planned separately before any release claim.

10. Troubleshooting map#

11. Bench record template#

12. Review conclusion#

The circuit is the minimal correct first-blinky board: eleven LEDs, eleven ballast resistors, one PMOD plug, no active parts. The two teaching points are built into the topology — per-LED ballast current math, and the deliberate parallel sharing of BAR0/1/2 between the bar and the traffic head with independent ballast so the loads do not interact. The principal risks are all about assembly and integration rather than circuit correctness: unverified first-article behavior (nothing has ever been built), LED polarity across 11 parts with no reverse protection, the J1 pin-1/zigzag orientation against a real host socket, correct placement of the three non-green traffic MPNs, and confirming the host bank can source the ~37 mA all-on aggregate. There is no decoupling because there is nothing to decouple, and no module-driven line, so the AruviX 100 Ω series rule does not apply.