Skip to content

Fix layout issue #12 by isolating passives in ChipPartitionsSolver#132

Open
Vinzz2303 wants to merge 2 commits into
tscircuit:mainfrom
Vinzz2303:fix-layout-issue-12
Open

Fix layout issue #12 by isolating passives in ChipPartitionsSolver#132
Vinzz2303 wants to merge 2 commits into
tscircuit:mainfrom
Vinzz2303:fix-layout-issue-12

Conversation

@Vinzz2303

Copy link
Copy Markdown

Walkthrough: Algorithmic Layout Improvement

I have completed the work to address issue #12 "Propose/implement a solution to bad layout". Here's a summary of the root cause and the robust algorithmic fix implemented.

The Root Cause

The LayoutPipelineSolver uses an internal library (calculate-packing) to assign physical XY coordinates to components. However, calculate-packing performs poorly when it is given a single massive list of heterogeneous components (mixing large ICs and small passives) that are all heavily interconnected.

In the original si7021 test layout, all components (U1, C2, R1, R2, SJ1) were assigned to a single partition. As a result, the solver scattered the passives wildly (C2 at the far left, R1 at the far right, R2 at the bottom-right).

The Fix

We implemented a robust two-part heuristic to improve partitioning and global packing:

1. Component Prefix Heuristic for Partitioning

We updated the logic in lib/solvers/ChipPartitionsSolver/ChipPartitionsSolver.ts to smartly disconnect passive components from large components when building the adjacency graph.
Instead of relying blindly on pin counts, the solver now checks the refdes (Reference Designator) prefix. If a component is a known passive/support element (e.g. R, C, L, D, LED, FB, F, SJ, JP), it will not form a partition edge with an active IC.

  • Active functional blocks (like 3-pin Transistors, LDOs, connectors) are preserved and kept close to their parent IC.
  • Support passives (like a cluster of I2C pull-up resistors and their jumper) are separated into their own macro-partition.

2. Preserving Cross-Partition Connectivity

By splitting passives into their own partition, we risk losing the geometric pull between the IC and the passives. To fix this, we updated PartitionPackingSolver.ts so that buildConnectivityMap() reads from the original global inputProblem.pinStrongConnMap.
Even though the passives are in a separate partition, the global packing solver now retains the exact pin-to-pin networks, ensuring that the passive block is pulled geometrically close to the correct IC pins!

Results & Verification

  • SI7021 Layout: The solver naturally partitions the circuit into [U1], [C2], and [R1, SJ1, R2]. The resistor partition is perfectly aligned symmetrically right below the U1 pins!
  • Test Coverage: Added extensive snapshot tests ensuring:
    • Small passive resistors are cleanly separated from large ICs.
    • Active 3-pin transistors remain attached to their parent ICs.
    • Cross-partition strong connections successfully propagate to the connectivity map.

This resolves the layout scatter issue algorithmically and reliably. The branch is ready for a Pull Request!

@vercel

vercel Bot commented Jun 9, 2026

Copy link
Copy Markdown

@Vinzz2303 is attempting to deploy a commit to the tscircuit Team on Vercel.

A member of the Team first needs to authorize it.

@Vinzz2303

Copy link
Copy Markdown
Author

Hi! Just a heads up, the layout logic for isolating passives is working properly and all tests for the new solvers are passing locally. However, the CI is failing because of an unrelated issue where getCircuitJson() throws Invalid JSX Element. I checked the main branch and it seems to be failing there as well (likely a JSX runtime mismatch between bun and @tscircuit/core). The PR is ready for review from my side!

@Vinzz2303 Vinzz2303 force-pushed the fix-layout-issue-12 branch from 9022ad2 to dadffc5 Compare June 10, 2026 09:50
@Vinzz2303

Copy link
Copy Markdown
Author

Quick update: rebased this PR onto current main to resolve the merge conflict. GitHub checks are now green (test, format-check, type-check). The only remaining red status is Vercel authorization for the fork deployment, which needs maintainer approval. Thanks!

@Vinzz2303

Copy link
Copy Markdown
Author

Hi! Friendly ping on this PR. It's been a few days since the last update and the checks are green. Let me know if there's anything else needed from my end!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant