Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OrthoRoute – GPU-accelerated autorouting for KiCad

bbenchoff.github.io

Post reply on HN
Print view View original

21–30 of 30 posts

Re: OrthoRoute – GPU-accelerated autorouting for KiCad

#21

Post by tecleandor »

wanderingjew wrote: post #10
morellt wrote: post #5

I would love to know the application of this ludicrous PCB, and I'd be even more interested to see the quote price

Hey, guy who made this here. This probably deserves a little explanation. First off, I'd like to tell you I'm really, really unemployed, and have the freedom to do some cool stuff. So I came up with a project idea. This is only a small part of a project I'm working on, but you'll see where this is going. I was inspired by this video: https://www.youtube.com/watch?v=HRfbQJ6FdF0 from bitluni that's a cluster of $0.10-0…

Oh, interesting! For a second I thought you were playing again with SXM sockets...

Re: OrthoRoute – GPU-accelerated autorouting for KiCad

#23

Post by X-Ryl669 »

I don't get why you process the whole connector board at once. If I understand correctly, you're connecting individual & identic boards to your board. So each connector on you giant board is actually dealing a bunch of small board right?

In that case, can't you exploit the inherent symmetry in the design here to only route a quarter of your connectors and then mirror/rotate the result for the other one? Or, if you have a X*X matrix, route one size minus the corners and replicate to the other sides?

Also, with such a huge connection board, it smells a NIH issue here. I think you'd better serialize the IO to a bus (whatever) and few lines and perform the connection in software (in a GoWin FPGA for example, both extremely cheap and quite powerful). Just think of the harness you'll need to build to fit the connectors in. The obvious routing bugs, and so on. Any maintenance will be a nightmare, if you need to swap 2 pins on a connector or re-run the routing.

Re: OrthoRoute – GPU-accelerated autorouting for KiCad

#24

Post by actionfromafar »

X-Ryl669 wrote: post #23

I don't get why you process the whole connector board at once. If I understand correctly, you're connecting individual & identic boards to your board. So each connector on you giant board is actually dealing a bunch of small board right? In that case, can't you exploit the inherent symmetry in the design here to only route a quarter of your connectors and then mirror/rotate the result for the other one? Or, if you ha…

But then you need 4096 CPUs plus 4096 FPGAs?

Re: OrthoRoute – GPU-accelerated autorouting for KiCad

#25

Post by wanderingjew »

X-Ryl669 wrote: post #23

I don't get why you process the whole connector board at once. If I understand correctly, you're connecting individual & identic boards to your board. So each connector on you giant board is actually dealing a bunch of small board right? In that case, can't you exploit the inherent symmetry in the design here to only route a quarter of your connectors and then mirror/rotate the result for the other one? Or, if you ha…

Hi, author here, for this project, the backplane is as much of the computer as the 'daughter cards'. Think of it like the wire-wrap boards of _really old_ minicomputers. I'm using the PDP straight-8 as an analogy here because that's the oldest computer I've been inside of, but the backplane connects the different daughter cards together in a way such that the backplane _is_ the computer.

As far as symmetry goes, there really isn't any. For example, Board 0 conects to 1, 2, 4, and 8. Board 1 connects to 0, 3, 5, and 9. Board 3 connections to 1, 2 , 7, and 11.

There's one way I can think of to make this routing easier. Of of the 16 daughter boards, make the pinout unique to each daughter board. If I was doing this as a product, for manufacturing, this is exactly what I would do. I'd rearrange the pins on each daughter card so it would be easier to route. The drawback of this technique is that there would be 16 different varieties of daughter cards; not economical if you're just building one of these things.

So, with those constraints the only real optimization I have left is ensuring that the existing net plan is optimal. I already did that when I generated the netlist; used simulated annealing to ensure the minimal net length for the board before I even imported it into KiCad.

And yeah, serializing the IO would be better, but even better than that would be to emulate the entire system in a giant black box of compute. But then I wouldn't have written a GPU autorouter. I'm trying not to, but there is some optimization for _cool_ here, you know?

Re: OrthoRoute – GPU-accelerated autorouting for KiCad

#26

Post by wanderingjew »

bsder wrote: post #18

Was there a particular reason why "Think real hard on the symmetry and write a Python script." wouldn't do the job? Or was it simply "It would be cool to abuse some GPUs"? Either option is cool, though.

Author here – I did do the ‘think real hard and write Python’ part, but at the netlist level. I used simulated annealing on the 8196 nets to minimize total length / crossings before importing into KiCad.

Where the GPU router comes in is the geometric part: obeying layer stack, via rules, keepouts, blind-via constraints, etc. You can absolutely hand-encode one or two nice symmetric patterns in code; this board is ‘what if we made the search space big enough that you want Dijkstra + PathFinder + sparse GPU data structures to do it for you’.

Re: OrthoRoute – GPU-accelerated autorouting for KiCad

#27

Post by glaslong »

wanderingjew wrote: post #10
morellt wrote: post #5

I would love to know the application of this ludicrous PCB, and I'd be even more interested to see the quote price

Hey, guy who made this here. This probably deserves a little explanation. First off, I'd like to tell you I'm really, really unemployed, and have the freedom to do some cool stuff. So I came up with a project idea. This is only a small part of a project I'm working on, but you'll see where this is going. I was inspired by this video: https://www.youtube.com/watch?v=HRfbQJ6FdF0 from bitluni that's a cluster of $0.10-0…

i aspire to this level of unemployment. fantastic!

Re: OrthoRoute – GPU-accelerated autorouting for KiCad

#28

Post by wanderingjew »

glaslong wrote: post #27
wanderingjew wrote: post #10

Earlier quoted context omitted.

Hey, guy who made this here. This probably deserves a little explanation. First off, I'd like to tell you I'm really, really unemployed, and have the freedom to do some cool stuff. So I came up with a project idea. This is only a small part of a project I'm working on, but you'll see where this is going. I was inspired by this video: https://www.youtube.com/watch?v=HRfbQJ6FdF0 from bitluni that's a cluster of $0.10-0…

i aspire to this level of unemployment. fantastic!

you'd think so, man. you'd really fuckin think so.

Re: OrthoRoute – GPU-accelerated autorouting for KiCad

#29

Post by vrinsd »

actionfromafar wrote: post #20
vrinsd wrote: post #13

Earlier quoted context omitted.

If you're open to technical feedback your last comment, I've worked on these kinds of systems, have architected and built things even far "weirder" and these products have shipped and out in the real world, in silicon, in FPGAs and things between. The reason an FPGA is a more suitable platform is you can translate "physical effort of making PCBs" into "creating a design in an infinitely re-programmable platform" and…

I dunno. Each of these physical processors have 8 kilobytes SRAM and 62 kilobytes of some kind of flash or something. Multiply by 4096, wouldn't that be one hell of an FPGA?

If you look at modern FPGAs they have prodigous amounts of on-chip memories (BRAMs and URAM in Xilinx speak).

You can buy Xilinx FPGAs on PCIe cards that could easily handle THOUSANDS of RISC-V cores.

Almost all FPGA dev boards include DDR memory so you could also put code there if you needed to.

Re: OrthoRoute – GPU-accelerated autorouting for KiCad

#30

Post by actionfromafar »

vrinsd wrote: post #29
actionfromafar wrote: post #20

Earlier quoted context omitted.

I dunno. Each of these physical processors have 8 kilobytes SRAM and 62 kilobytes of some kind of flash or something. Multiply by 4096, wouldn't that be one hell of an FPGA?

If you look at modern FPGAs they have prodigous amounts of on-chip memories (BRAMs and URAM in Xilinx speak). You can buy Xilinx FPGAs on PCIe cards that could easily handle THOUSANDS of RISC-V cores. Almost all FPGA dev boards include DDR memory so you could also put code there if you needed to.

Interesting, thanks.
Post reply on HN