feat: specialized horizontal row layout for decoupling capacitors (#15)#69
Open
selenaalpha77-sketch wants to merge 3 commits intotscircuit:mainfrom
Open
Conversation
…circuit#15) Fixes the messy RP2040-style layout where decoupling capacitors were overlapping each other and the main IC. Root causes fixed: 1. **Converter** (`getInputProblemFromCircuitJsonSchematic.ts`) - Tag 2-pin passives (simple_capacitor, simple_resistor, etc.) with `availableRotations: [0, 180]` so the identification solver can recognise them. - Detect ground/power nets by name (GND/VSS → isGround, VCC/VDD/V3_3 etc. → isPositiveVoltageSource) so net-pair validation works. 2. **IdentifyDecouplingCapsSolver** - Extended `isTwoPinRestrictedRotation` to also accept a single- rotation `[0]` and all-4-rotation chips whose pins face y+/y- (the common RP2040 fixed-orientation capacitor topology). - `getNetIdsForPin` now walks one hop across `pinStrongConnMap`: a cap pin that is direct-wired to an IC pin inherits that pin's net, enabling identification even when there is no direct netConnMap entry for the cap pin itself. - `findMainChipIdForCap` falls back to a net-based search (find the chip with the most pins on the same supply net pair) when no direct strong connection exists. - Added `pinsOnOppositeXSides` helper for completeness. 3. **DecouplingCapsPackingSolver** (new) - Deterministic linear row layout: sorts capacitors by chipId, places them in a centred horizontal row at y=0 with spacing controlled by `decouplingCapsGap` (or `chipGap` as fallback). - Bypasses PackSolver2 entirely for decoupling_caps partitions, which was the source of the overlap / messy placement. 4. **SingleInnerPartitionPackingSolver** - Dispatches to `DecouplingCapsPackingSolver` for `partitionType === "decoupling_caps"` partitions. - All other partitions continue to use PackSolver2 unchanged. Tests: 5 new tests covering group identification, row layout geometry, zero-overlap pipeline execution, single-cap edge case, and unchanged behaviour for non-decoupling partitions. All pass; no regressions. /claim tscircuit#15
|
@selenaalpha77-sketch is attempting to deploy a commit to the tscircuit Team on Vercel. A member of the Team first needs to authorize it. |
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…chain IdentifyDecouplingCapsSolver06.test.ts imported `problem` from the page file, which transitively pulled in LayoutPipelineDebugger → SchematicViewer → circuit-to-svg, where the installed version (0.0.174) does not export `convertCircuitJsonToSchematicSimulationSvg` causing a SyntaxError at test load time. Fix: extract the InputProblem constant into a standalone tests/fixtures/problem06.ts that only imports the type, breaking the problematic import chain. All 23 tests now pass. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
/claim #15
Problem
The RP2040-style layout produced chip overlaps because decoupling capacitors were treated as ordinary 2-pin chips by the packing pipeline.
Root causes:
IdentifyDecouplingCapsSolverfound 0 groups — converter never setavailableRotationson passives, and caps wired via strong pin connections weren't resolving to their supply netsSingleInnerPartitionPackingSolverusedPackSolver2for decoupling_caps partitions — produces messy overlapping layout for many small identical componentsFix
getInputProblemFromCircuitJsonSchematic.ts): Tag 2-pin passives withavailableRotations: [0, 180]and auto-detect power/ground nets by nameIdentifyDecouplingCapsSolver: Walk strong pin connections to resolve supply nets; accept single-rotation caps; add net-based fallback for main chip detectionDecouplingCapsPackingSolver(new solver): Deterministic centred horizontal row sorted by chipId withdecouplingCapsGapspacingSingleInnerPartitionPackingSolver: Dispatch toDecouplingCapsPackingSolverfordecoupling_capspartitions; PackSolver2 unchanged for othersTests
5 new tests — all pass, 0 regressions:
IdentifyDecouplingCapsSolverfinds groups for RP2040-style problemDecouplingCapsPackingSolverrow geometry (spacing, centring, y=0)