Seve - @Abse i think you need flash and psram?

I belive I have both

<@757706909351411845> https://github.com/tscircuit/jscad-electronics/pull/356

<@757706909351411845> https://github.com/tscircuit/circuit-json-to-footprinter/pull/115

https://github.com/tscircuit/jscad-electronics/pull/363

https://github.com/tscircuit/high-density-repair03/pull/131

https://github.com/tscircuit/repair04/pull/15

https://github.com/tscircuit/tscircuit-autorouter/pull/2577

got this repro can you take a look too https://github.com/tscircuit/tscircuit-autorouter/pull/2606

You need to fix drc evaluation to understand whether buried is allowed

Dont rewrite routes

In the drc eval, if buried isnt allowed, every via is through hole

I get what is going on with a dual representation issue, because from/to on the via represents the path traveled NOT the via extent, i get that this representation is a bit flawed

We will eventually need to reconcile that, which is going to be annoying, we will have to say drill_start_layer and drill_end_layer or something

<@757706909351411845> for this pr do you mean the model is not right ? I have seen that there is two shapes so we don't want the mushroom like pins right ?

we want something like this ?

Either way, but rn youve got two floating disjs

this one will be easier to produce (didn't notice the floating pins sry)

<@757706909351411845> https://github.com/tscircuit/jscad-electronics/pull/363

Ur good

IoU target is 60% so we dont need to worry about small differences

In some case 40% looks fine but usually not

sg it's 88% tho

I had to do a whole visual comparison to see which IoUs were like close enough

ur in Texas ?

I am in texas!!!

good luck

<@757706909351411845> https://github.com/tscircuit/high-density-repair03/pull/136

https://github.com/tscircuit/tscircuit-autorouter/pull/2609

<@757706909351411845> The router treats a trace’s minimum width as a preference. It can choose a path using the smaller board minimum, then narrow the trace to fit. That’s how a requested 1.0 mm trace became 0.15 mm in issue [#1721](https://github.com/tscircuit/tscircuit-autorouter/issues/1721). PR [#2606 ](https://github.com/tscircuit/tscircuit-autorouter/pull/2606)shows that a wider detour can exist. The router should first look for a path using the larger of the board and trace minimums. If it can’t find one, it should keep routing but show a warning with the trace, requested width, and actual width. Tests should cover both the wider detour and the narrowed route with a warning.

right, so my recommendation here is to have a solver after the portPointPathingSolver that attempts to reroute traces that meet the minTraceWidth AND/OR add cost to ports that can't support adjacent traces

this is a tricky issue because adding the costs could have a performance penalty. Also large traces can sometimes be broken into smaller traces to achieve a higher effective trace width (this is uncommon!). So my recommendation is to add the additional stage that operates on a hypergraph to improve trace widths because it ensures we don't reduce completeability. Adding the cost etc. could impact completeability, but adding a new stage shouldn't have an impact

it is also prevents optimizing hypergraph solving for different objectives- that would suck. We can just optimize for improve trace widths if it's a separate stage

<@757706909351411845> https://github.com/tscircuit/tscircuit-autorouter/pull/2609

https://github.com/tscircuit/high-density-repair03/pull/136

https://github.com/tscircuit/tscircuit-autorouter/pull/2630

<@757706909351411845>

taking a look

<@398467566588264449> your PRs seem correct, the only issue is the small bug they seem to introduce in the autorouter PR

<@398467566588264449> this improves build speeds without changing output because high density nodes are parallel processed in cloud

<@757706909351411845> https://github.com/tscircuit/high-density-repair03/pull/136 should have no regression on the autorouter benchmark ( we have a 78 drc now on srj18) PS the drc was 37 before resolving the conflict so must have been some other pr with drc regression the repair03 was integrated on https://github.com/tscircuit/tscircuit-autorouter/pull/2609

i'm not aware of a drc regression

i would confirm that there was a drc regression independently

ok

confirmed no regression on main

<@757706909351411845> We have now integrated Repair03 into the autorouter. The additional DRCs are real existing routing issues exposed by the corrected DRC detection, rather than regressions caused by Repair03. Repair03 fixes one affected route: SRJ18 sample 10 now passes DRC, improving the SRJ18 DRC pass rate from 56.3% to 62.5%.

Fixes have to be introduced separately from the drc change

To maintain sanity

Ie we should never change drc eval in the same pr as fixes

https://github.com/tscircuit/tscircuit-autorouter/pull/2664

this is the eval side only in a clean pr

<@757706909351411845>

<@757706909351411845> this was merged by the ai can you review if its ok or need a revert https://github.com/tscircuit/high-density-repair03/pull/143

it was benchmarked on this pr https://github.com/tscircuit/tscircuit-autorouter/pull/2666 with no regression on dataset 01 and 2 drc improvments on srj18