Photonics

Correction, 15 September 2026. The claim below — that the fold beats Apollo and beats the hand layout — is narrower than it reads, and this page carries the narrowing rather than restating it. Apollo's Table 1 has twelve rows; the fold was run on its four easiest (the Clements meshes, where a layered drawing has no crossings by construction) and none of its eight ADEPT tensor cores, which are unobtainable. Apollo's routability shortfall on those rows is at a compact die its paper does not size and this tree did not match: on LiDAR's shipped die every placement of the mesh routes 100%, a random order included, so the routability column is a die artefact. Apollo does not report the MMI chips; the hand layout the fold beats there is the netlist order (--order none reads the same 33), so 21% fewer crossings is 21% fewer than a layout nobody optimised. The four chips the suite ships that had not been run: the three MRR weight banks fail at read — a ring on a bus is a four-port pass-through the layering cannot place — so the placer handles five of LiDAR's eight chips; the MMI 32×32 places in 8 s at 111 crossings against the hand layout's 121 (8%, not 21%), and at the placer's own column spacing (half the die) LiDAR cannot route net n_182 and stops in its own code, as it does for the netlist order at that spacing; stretched to the hand layout's width, order and rows untouched, it routes 447/447, 111 crossings, 0 DRV, 31.20 dB and 282,774 µm against the hand layout's 447/447, 121, 0, 36.24 dB and 330,798 µm. The judge is fragile at dense fan-outs (15 September, evening). Three near-identical placements of one MMI-to-MZI fan-out on the 16×16 — the hand's, one that routed clean, one 15 µm away from it — and LiDAR routes two and crashes on the third writing a 2.43 µm bend. Part of what the day's entries attribute to placement choices is this; a single LiDAR verdict on a single placement is not firm, and pic_perturb.py is the instrument for saying how firm. The honest sentence: a one-second placer for feed-forward photonic circuits, zero crossings on interferometer meshes where a GPU placer takes twenty to thirty times longer, and fewer crossings and less waveguide than the layouts shipped with the benchmark. Not "beats the state of the art." The CHANGELOG entry of 15 September has the runs.

The fold places a photonic chip from its netlist alone, and LiDAR routes every net of it. On Apollo's own Clements benchmarks the placement routes 100% where Apollo publishes 98.85% and 95.05%, with no crossings; on the multiport-MMI tensor cores it has 21% fewer crossings than the hand layout that ships with the benchmark. Measured 2026-09-10; the tools are tools/pic.py, tools/pic_place.py, tools/pic_perturb.py and tools/pic_report.py, and tests/test_pic.py holds them.

Why a photonic chipCopy Anchor Link

On a board a crossing costs a via. On a photonic chip it costs a device: two waveguides cross through a 10 µm crossing that loses about 0.5 dB, so a placement is judged first by its crossings and then by whether the router can reach every port at all. The placers the field has are analytic (DREAMPlace, Cypress) and Apollo (ICCAD 2025), which models crossings by counting straight-line intersections every hundred iterations and turning them into a spacing penalty. The where-else research of the same day named this the field where the fold's exact reading could beat what is used.

The judgeCopy Anchor Link

LiDAR (ScopeX-ASU, ISPD 2025, MIT) is the curvy-waveguide detailed router Apollo's paper evaluates with. It is cloned to .cache/lidar with its own Python 3.12 venv (its pinned numba and numpy do not install on this tree's Python), and tools/pic.py runs it and reads its log: nets routed, crossings, design-rule violations, worst-path insertion loss, waveguide length. Its suite ships four chips with hand placements: Clements 8×8 and 16×16 interferometer meshes, multiport-MMI 8×8 and 16×16 tensor cores. Every hand layout routes 100%, DRV-free, the meshes with no crossings and the MMI chips at 33 and 63.

Apollo's repository, which its paper calls open-sourced, is empty as of 2026-09-10. Its numbers here are its published Table 1, on the same netlists, with a die and a router setting the paper does not state. They are the published claim, not a rerun.

What the fold becomes on a chipCopy Anchor Link

tools/pic.py reads LiDAR's YAML the way LiDAR does (its orientation transforms copied: position is the lower-left corner, FN mirrors about the vertical axis and turns every port round, FS is the vertical flip that keeps a port facing) and gives three readings of the crossings:

• straight: pairs of nets whose straight flightlines intersect. Apollo's estimator. A straight crossing can be routed around, so it is neither a bound nor a count.
• floor: pairs of nets whose x-spans overlap and whose ends interleave in y. For waveguides that run left to right this is the fold with the channel as its backbone, and it is exact: two such nets must cross however they are routed.
• displaced: fold.displaced on the centroid backbone, which reads 41 pseudoknots on a mesh that has none. The angular order about a centroid is the wrong backbone for a pipeline; the channel is the right one.

to_board() also maps the chip onto a one-layer board for the mould. That reading does not transfer, and the page says so below.

The placerCopy Anchor Link

Every chip in LiDAR's and Apollo's suites is feed-forward, and a placement of such a chip is three decisions. tools/pic_place.py makes them in order:

1. Stages by longest path from the couplers, a net at a time; a net that skips a stage gets a virtual node in it, and every sink sits on the last stage as the output couplers do on the die edge.
2. Order within a stage by the channel floor: sifting (every free device tried at every position of its stage, and flipped) on the two channels it touches, from the netlist's own order, with no channel allowed more crossings than that order gives it. A fixed coupler keeps its rank. Until 15 September the sifting started from barycentre sweeps and several shuffled starts; measured, the sweeps piled crossings into the hardest channel (74 where the order has 63 on the 64×64) and the router could not take it.
3. Rows by isotonic projection of each device's barycentre onto the ordered, gapped set (pool adjacent violators with gap offsets), so a stage whose targets collapse onto one row spreads about it rather than up from it; then columns, read off the rows: a channel gets 15 µm for every net that bends across it (the rule LiDAR's own generator lays the hand layouts on) and 12 µm more per crossing its worst net makes, and a channel whose nets run straight stays at 100 µm. Until 15 September the channel was 100 µm plus the crossing room alone, and the 32×32's fan-ins were unroutable at it; the CHANGELOG entry of that day has the three rules tried.

A 287-net chip places in 1.4 s.

MeasuredCopy Anchor Link

Every placement routed by LiDAR at its 5 µm bend radius (Apollo's S) and DRV-free except the 64×64, whose 50 violations sit on 12 nets in one fan-out channel where the placer's 55 µm heater pitch crowds the crossings (the hand's is 100); the placer's rows are under the channel rule of 15 September, with the 16×16's earlier row kept because the rule cost it waveguide. python tools/pic_report.py prints the full table.

At the 10 µm radius (Apollo's L, where it publishes 98.85% and 96.04%) both meshes again route every net with no crossings. The MMI 8×8 at that radius is the one like-for-like row with violations on both sides: this placer 111/111, 26 crossings, 4 violations, 15.86 dB; the hand layout 111/111, 33, 5, 18.00 dB.

What the ordering buys, same coordinates and judge, Clements 8×8: the netlist's own order 8 crossings; a random order 127 and 134 crossings with 12 and 9 violations and 40 to 44 dB; this tree's own board annealer, which never looks at which way a port faces, produces placements LiDAR stops on inside its own A* search, which is the port-blind failure Apollo's DREAMPlace column measures at 44 to 64%.

Why a hand layout can be beaten on crossings at all. A stage whose devices each have one input and one output cannot lower the total by reordering: Kendall distance is a metric, so what is removed at one channel reappears at the next. The seven the fold removes on the 8×8 MMI come from vertical flips of the MMIs and the free order of the output couplers, which a human left as the netlist named them.

What transfers and what does notCopy Anchor Link

tools/pic_perturb.py bends the hand layout thirteen ways (columns squeezed, rows squeezed, rows shuffled within a stage, everything jittered, devices mirrored), routes each, and scores it with every reading. Over the variants LiDAR finished, the channel floor and the straight count track its crossings and its violations at Spearman +1.00, displaced at +0.77, the coarse mould's saturation at +0.34, and the windows' blocked-pin count at −0.64. The mould does not read a waveguide field: an MMI's two outputs sit 1.25 µm apart, closer than any pitch a pad-field model accepts, and escape() calls 118 of 158 ports blocked on a chip LiDAR routes clean, whatever the port margin. Routability itself was 100% on every placement LiDAR did not crash on, so no reading can predict it on this family.

What this is notCopy Anchor Link

Not a general placer: it takes the feed-forward structure every chip in these suites has, and a chip with feedback would need the layering broken somewhere. Not a rerun of Apollo: its rows are published numbers on the same netlists under a die and settings its paper does not state, and its ADEPT benchmarks are not obtainable. And not a routability predictor: LiDAR routed everything it did not crash on, so the claim is crossings, loss and length, judged by the router, and 100% where Apollo reports less.