Split RP2040 board into centered routable subcircuits

[0hmX]

Summary

• split the RP2040/Pico board into nine functional nested subcircuits, each in its own module under subcircuits/
• center every child circuit in its local PCB world, size bounds from the full pad envelope, and prevent sibling-world overlap
• move internal traces and shared-rail connections into their owning child circuits while keeping true cross-subcircuit signals at the parent
• preserve component types, values, and footprints; align the USB differential resistors and the IOVDD capacitor bank for clean local routing
• add structural, geometry, connectivity, and isolated-routing regression coverage

Why

The RP2040 implementation was one flat routing unit. The initial hierarchy still left most traces parent-owned, and child group bounds were centered on their declared anchors rather than their physical pad envelopes. This caused pads to appear outside child worlds and prevented the children from behaving as independent routing units.

Impact

The board is now organized into independent RP2040 core, USB, flash/boot, clock, regulator, analog, run-control, status, and SWD modules. Each child world is centered, contains its pads with clearance, and does not overlap its siblings. Internal child routing completes without errors.

Validation

• bun test: 17 tests passed, 3,377 assertions
• bun run build:lib: ESM and declaration builds passed
• routing-disabled tsci build of MicrocontrollerRP2040WithUsbC passed through the evaluator
• all nine isolated child routing probes completed with zero *_error records
• formatting and git diff --check passed

Known limitation

The outer parent capacity router can still exhaust its iteration budget while solving the remaining 14 cross-subcircuit signals plus shared rails. Child-level routing is clean; this limitation is isolated to the final parent interconnect phase.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
tscircuit-common	Ready	Preview	Jul 31, 2026 3:03am

[seveibar]

Hmm snapshot? Seems a bit odd to me to break it up like this-

[seveibar]

Basically, I'm just rejecting because the AI generated PR description really doesn't justify it. You have to give some form of motivation for something like this.

[0hmX]

This is just an experiment, not something I want to merge. I only wanted you to take a look at it—nothing more. I’m testing subcircuits, and the main motivation is placement. There are basically no other improvements yet.

It did get the differential-pair resistor placement right:

I’m just happy that subcircuits kind of work!

These are the problems I faced while trying to use subcircuits to split the design:

1. If you ask the AI to use only subcircuits, it will just define all the subcircuits inside the same file, which is not ideal. Also, if autorouting fails, it fails silently i could not make an auto router bug!.

2. You have to explicitly ask it to split the subcircuits into separate files, but it does this in the dumbest way possible. Some footprints end up outside the board bounds. It basically just splits the design without trying to make each subcircuit clean or correct on its own.

3. The AI is much worse at placement than we think. Even inside separate subcircuit files, it places components using their original relative positions instead of centering and arranging them properly. I think this is really bad. A subcircuit should be self-contained. Ideally, the API should let you position the entire subcircuit relative to the board it is being used in, rather than positioning every component individually.

4. Autorouting reroutes a lot of traces unnecessarily.

5. I also think we need MST-based simplification to remove unnecessary connections within a net. I suspect the current behavior could create an electrical loop, but that is only speculation—I have not actually confirmed it.