W13: AX7203+AN430 LCD bring-up VICTORY — Trap I documented

[gHashTag]

Summary

After a 20+ hour marathon spanning 35+ bitstreams, the AN430 4.3" TM043NBH02 LCD
now displays color bars driven by the AX7203 board through the openXC7
opensource toolchain (yosys → nextpnr-xilinx → prjxray, no Vivado).

Root cause

Used the AN430-shipped Altera Cyclone IV E demo (sd_sdram_lcd, Quartus 14.1,
2015) as reference for a Xilinx Artix-7 port. Three vendor-specific electrical
conventions carried over silently:

1. assign lcd_dclk = clk_lcd (non-inverted) → correct is ~lcd_clk
2. assign lcd_hsync = 1'bz (high-Z) → correct is active hsync_r
3. H_BackPorch = 45, V_BackPorch = 16 → correct is 2, 2

Fix: import ALINX-official AX7103 08_lcd_test
Vivado/Xilinx demo instead of the ported Altera one.

What survived from sandbox investigation

• openXC7 build flow verified against scripts/fpga/build.sh in t27 — no bugs.
• All 30 XDC pins verified on XC7A200T-FBG484-2 via prjxray-db.
• J11 pinout verified 28/28 against ALINX AX7203 UM page 49.
• Nothing in the pin-map, package, or toolchain was wrong. The pixel-level
  fault was in Verilog conventions, not in the flash pipeline.

New skill entry — Trap I: Vendor-Reference Anchor

Documented in docs/W13_LCD_BRINGUP_VICTORY.md §Lesson learned:

Symptom: hardware exhibits identical failure across 30+ config permutations,
LEDs and other GPIO work fine, reference code "looks right" and was ported
carefully.

Mechanism: reference project uses a different FPGA vendor. Pin numbers were
re-mapped but vendor-specific electrical conventions (clock polarity, high-Z
vs. active drive, blanking) were not.

Diagnostic (30 min, zero cost): check the reference project file extensions.
.qsf/.qpf/.sof = Altera. .xdc/.xpr = Xilinx. .lpf/.ldf = Lattice. If
the reference is not for the target vendor, STOP and find the vendor-native
reference before iterating on hardware.

Discipline hooks

• no-fabricated-metrics — color bars observed on-panel, first working-hardware
  result of this workstream. No -sim tag needed for this claim.
• Vendor-anchor rule adds to anti-anchor-audit skill patterns (candidate for
  a v1.1 update to that skill in a follow-up PR).
• SHA-advance rule — approval binds to 31c97c6; branch advance requires
  explicit re-review at any new SHA.

Follow-ups (queued, not in this PR)

1. Add Trap I to tri-net-hardware-bringup skill v-next.
2. Add "vendor-reference check" as a static rule to any future FPGA reference
   we adopt.
3. Import the working lcd_official_port.v and its build script into
   t27/fpga/verilog/an430_lcd/ so the recipe is reproducible from this repo.

phi^2 + phi^-2 = 3

[gHashTag]

CI status — pre-existing failure, unrelated to this PR

build + test (-sim baseline) red because cargo fmt --check cannot parse
gen/rust/adaptive_routing.rs — the file contains invalid Rust generated by
t27 codegen (let; statements without identifiers on lines 73, 81, 97, 120,
128, 134, 148, ...). This is a pre-existing baseline bug on main, not
introduced by this docs-only PR.

Reproduction:

gh run view 29201187805 --log-failed

This PR touches only docs/W13_LCD_BRINGUP_VICTORY.md — no Rust code paths.

Recommended: owner merges via GitHub UI with admin override, OR t27 codegen
let; bug is closed in a separate PR before this one is auto-merged.

phi^2 + phi^-2 = 3

[gHashTag]

Baseline CI context — main is red since 2026-07-07 (SHA f608dad)

The build + test (-sim baseline) check has been failing on main for 5 days,
across all 14 open PRs. Root cause is a t27c codegen bug that drops
identifier names from let statements — 12+ affected files in gen/rust/,
hundreds of let; occurrences across ~50 modules.

Open tracking PR: #44 W7.1 investigation — E0425 root cause is dropped let statements in t27c Rust emitter
(DRAFT since 2026-07-05, not advanced in 7 days).

Last green CI on main: SHA 2b28312 (2026-07-07T12:29Z, before f608dad).

Implication for this PR: #78 is docs-only (single new file
docs/W13_LCD_BRINGUP_VICTORY.md), touches zero Rust modules, and cannot pass
the required baseline until t27c is fixed. Blocking a documentation PR on an
unrelated codegen regression indefinitely is not a good use of the gate — but
also not something I should override silently.

Recommended action — owner-side admin merge via GitHub UI, OR temporary
required-checks relaxation until #44 (or its successor) closes the codegen
bug. Both are owner-only calls.

phi^2 + phi^-2 = 3