tscircuit community
← Back to community index
# contributor·Active

shibo - @Seve these issues are blocking me from...

mention these issues are blocking me from routing the AM62L board, a lot of progress was made, it's nearly there https://github.com/tscircuit/tscircuit autorouter/pull/2247 https://github.com/tscircuit/tscircuit autorouter/pull/2248 https://github.com/tscircuit/tscircuit autorout

Started by shiboAug 27, 202657 messages

Discussion

Last active 8 days ago · plain text
shibooriginal post
<@757706909351411845> these issues are blocking me from routing the AM62L board, a lot of progress was made, it's nearly there https://github.com/tscircuit/tscircuit-autorouter/pull/2247 https://github.com/tscircuit/tscircuit-autorouter/pull/2248 https://github.com/tscircuit/tscircuit-autorouter/pull/2249 https://github.com/tscircuit/tscircuit-autorouter/pull/2250 https://github.com/tscircuit/tscircuit-autorouter/pull/2251
Seve
no repro?
Seve
only the first PR is mergable
Seve
the remainder are super dangerous
shibo
I have a repro from my board, but I told it to make the repro as small and focused as possible
shibo
i'll use the real thing this time
Seve
yes if i had the result i might know a bit better if this was appropriate, there's no dataset to benchmark on, and we don't have bus routing solved outside of the regular autorouter
Seve
if you show more evidence then that would help, right now all i see is a bunch of ai generated code
Seve
and #2248 is a major bug
Seve
AFAIK
Seve
also i do appreciate the deep dive into this, i think it is the right method, i do this all the time but i often throw out a bunch because of issues doing review.... it is very hard
shibo
<@757706909351411845> please check again: https://github.com/tscircuit/tscircuit-autorouter/pull/2248 https://github.com/tscircuit/tscircuit-autorouter/pull/2249 https://github.com/tscircuit/tscircuit-autorouter/pull/2251
Seve
2248 is definitely better
shibo
it's from the hdmi that would get connected to the am62l, context poisoning ig
shibo
please check the other two: https://github.com/tscircuit/tscircuit-autorouter/pull/2249 https://github.com/tscircuit/tscircuit-autorouter/pull/2251
Seve
these are definitely getting better
Seve
i think minor tweaks and we can start merging
shibo
<@757706909351411845> https://github.com/tscircuit/tiny-hypergraph/pull/173 https://github.com/tscircuit/tscircuit-autorouter/pull/2248
Seve
it seems like you want to make it so that certain connections don't traverse certain zs, `portZ` exists on the GraphTopology https://github.com/tscircuit/tiny-hypergraph/blob/main/lib/core.ts#L90
Seve
it seems like you want to modify the `TinyHyperGraphProblem` to add support for specifying `routeAllowedZ`
Seve
ugh dude i don't think this works
Seve
like do you have any proof that this works?
shibo
only that small repro
Seve
i'm saying
Seve
that limiting the layer of a bus doesn't make sense
Seve
because a bus always starts on the top or bottom layer, and sometimes you seek to have it traverse in the middle
Seve
*traverse without layer changes on a signal layer
Seve
you have no support for that
Seve
you only have support for complete restriction
Seve
even in the infinite cost implementation
Seve
if you can't show me a fully routed board with your custom autorouter, what's the point?
Seve
MAYBE layer restriction makes sense, or maybe we use explicit autorouting phases for it
Seve
idk
shibo
yeah, you need to prove something is usefull otherwise it may slow us down longterm
shibo
is that what you're saying
Seve
but there is a near term performance implicaition
Seve
yes no matter what we are paying in performance
Seve
i like this general direction, it might be ok
Seve
`isPortTransitionAllowed` is being called A LOT, you need to profile this
Seve
if `isPortTransitionAllowed` is effectively 0 cost, then maybe we merge it through
Seve
it is a good feature but i have no idea if it's going to get us to the finish line, it is a good feature
Seve
also stop with the ai generated titles and descriptions for this
shibo
I found out hdmi bus doesn't need to be in only one layer
shibo
soo
Seve
yea it can have transitions, but you need to have the same number of vias on each line generally
Seve
ideally the same layer changes around the same areas of the board
Seve
you're doing good i'm just having a hard time reviewing these
shibo
my issue is that I only focus on getting through the immediate obstacles, I don't think of how these changes would affect the tool as a whole and/or longterm
Seve
you're fine, they're good implementations
Seve
it's hard to get this stuff working
Seve
i'm struggling with managing this because it's hard
Seve
however the autorouter is swappable via `autorouter={{ algorithmFn: ... }}`, so you may find you're able to use a fork or PR build to route a board and that is particularly interesting
Seve
yea everyone is struggling to make progress here i think
shibo
but we are getting meaningful progress don't you think
shibo
worth trying
Seve
yes we're seeing improvements

Want to add to the conversation?

Reply in Discord so your notes stay connected to the source.
Continue in Discord ↗