Abse - @Seve

pico route but static reachability when routing the rest

https://github.com/tscircuit/tscircuit-autorouter/pull/1440 I have a PR that visualizes static reachability failures. I was planning to merge it, but the performance degraded, so I couldn’t proceed. You can just put the SRJ in the preview of this PR and see the failing problem visually. i will also try to debug this and see what i can do. but also sharing because its useful just not merged yet

Can we get a bug report abse

Can you move the speaker jst outside the subcircuit

I think subcircuits are sensitive to overlap-

one sec

<@757706909351411845> https://api.tscircuit.com/autorouting/bug_reports/view?autorouting_bug_report_id=5ab690a0-4f08-4d32-b671-1d0860afdd0a

<@757706909351411845> <@400684445054795796> can this have something to do with the issue ? https://github.com/tscircuit/core/pull/2538

I'm so lost

<@400684445054795796>

<@756504518417711104>

<@756504518417711104>

it's interesting (incorrect) that the SRJ has pointsToConnect inside the subcircuit

<@398467566588264449> can you use the Solvers tab? I suspect you downloaded the wrong bug report

one sec

then again, maybe this is actually just a core bug with how it generates SRJ 🤔

for a subcircuit- shouldn't the pointsToConnect be on the outside? Maybe not- it's a cool feature for it to not be- but it seems to overcomplicate the routing-

why now it worked before ?

I'm in the solvers tab

is there a way to bug report from here

sorry, you may be able to download from there

it looks like you probably filed the bug report properly tho

<@400684445054795796> any progress on figuring this out?

this is the gameboy!

I have the last parts we only need the autorouter to work

i have an fix but its in core; https://github.com/tscircuit/core/pull/2547/changes i am trying to understand the solution; i am not familiar with this code on this files;

<@757706909351411845> can you check <@400684445054795796> 's pr ?

oh

this code was altered by <@809856037376491570> recently

We may want to revert <@809856037376491570> 's fixes, we are very likely stacking hacks and this code is very important

Reverting

tyty

let's approach the SRJ generation cautiously

<@398467566588264449> you should be aware that subcircuit routing has a bug that Rishabh reproduced- you'll want to make sure your `exposedNets` are _actually_ connecting

<@398467566588264449> After this if you can create a small repro test in Core about the issue you faced, it would be better to make `core` robust and not break it again

<@809856037376491570> that's not really possible unfrotuantely because it causes an autorouter failure

Ohh ok