Things have deteriorated lately, and the population does not see the justice system as effective.

It is completely expected that we see vigilantism, but it is in no way extrajudicial.

I'm saying this because I need this information, and the fastest way to get information is to state that it's impossible or doesn't exist.

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’.

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?

Yeah, that was the first step in creating the netlist for the backplane. Simulated annealing on the 8196 nets. TO BE FAIR, this would be a lot easier to route if I didn't explicitly want each of the 16 cards to be identical, but I think that's the most cost-effective way to do it.

As far as an FPGA.... I don't know if I see the point. The nodes in the original CM-1 were basically _only_ ALUs. Very little processing power. The CM-5 was a little better, but this entire thing is batshit crazy. I might as well go for four thousand individually programmable cores. Like, what even is a MISD computer? I have no idea, so lets build one. See what it can actually do.

I was inspired by this video: https://www.youtube.com/watch?v=HRfbQJ6FdF0 from bitluni that's a cluster of $0.10-0.20 RISC-V microcontrollers. For ten or twenty cents, these have a lot of GPIOs compared to other extremely low-cost microcontrollers. 18 GPIOs on the CH32V006F4U6. This got me thinking, what if I built a cluster of these chips. Basically re-doing bitluni's build.

But then I started thinking, at ten cents a chip, you could scale this to thousands. But how do you connect them? That problem was already solved in the 80s, with the Connection Machine. The basic idea here is to get 2^(whatever) chips, and connect them so each chip connects to (whatever) many other chips. The Connection Machine sold this as a hypercube, but it's better described as a hamming-distance-one graph or something.

So I started building that. I did the LEDs first, just to get a handle on thousands of parts: https://x.com/ViolenceWorks/status/1987596162954903808 and started laying out the 'cards' of this thing. With a 'hypecube topology' you can split up the cube into different parts, so this thing is made of sixteen cards (2^4), with 256 chips on each card (2^8), meaning 4096 (2^12) chips in total. This requires a backplane. A huge backplane with 8196 nets. Non-trivial stuff.

So the real stumbling block for this project is the backplane, and this is basically the only way I could figure out how to build it; write an autorouter. It's a fun project that really couldn't have been done before the launch of KiCad 9; the new IPC API was a necessity to make this a reality. After that it's just some CuPy because of sparse matrices and a few blockers trying to adapt PathFinder to circuit boards.

Last week I finished up the 'cloud routing' functionality and was able to run this on an A100 80GB instance on Vast.io; the board wouldn't fit in my 16GB 5080 I used for testing. That instance took 41 hours to route the board, and now I have the result back on my main battlestation ready for the bit of hand routing that's still needed. No, it's not perfect, but it's an autorouter. It's never going to be perfect.

This was a fun project but what I really should have been doing the past three months or so is grinding leetcode. It's hard out there, and given that I've been rejected from every technician job I've applied to, I don't think this project is going to help me. Either way, this project.... is not useful. There's probably a dozen engineers out there in the world that this _could_ help.

So, while it's working for my weird project, this is really not what hiring managers want to see.

Comments URL: https://news.ycombinator.com/item?id=45970391

Points: 220

# Comments: 29

Yeah, it's a very expensive hobby project, but I can see some applications for similar pathological backplanes and BGA escape routing. Of course it doesn't do impedance control, length matching or differential pairs, but this could be useful on a _very small subset_ of _very complex boards_.

Basically I accidently stumbled into one of the hardest routing problems I've ever seen, and decided to build an autorouter. And that might be useful for other people.

This is a KiCad plugin with a few different algorithms, the coolest of which is a 'Manhattan routing grid' autorouter that routes along orthogonal traces. The basic idea was to steal an algorithm from FPGA routing and apply it to PCBs. I'm using CuPy for speeding up the routing; CPU-bound is at least 10x slower than the GPU version.

This is in a very pre-alpha state, but it does _technically_ work. It's not great by any measure but then again it is an autorouter.

I have a writeup with the how and why it was made: https://bbenchoff.github.io/pages/OrthoRoute.html

And a video showing it route a 512-net backplane in just over 2 minutes: https://www.youtube.com/watch?v=KXxxNQPTagA

This is very cool and one of the first good uses of the KiCad IPC API that was released a few months ago. If this sounds interesting and useful, PRs and issues welcome.

Comments URL: https://news.ycombinator.com/item?id=45750356

Points: 8

# Comments: 6

That's absolutely false. Do you know why MCM furniture is characterized by bent plywood? It's because we developed the glues that enabled this during world war II. In fashion you had a lot more colors beginning in the mid 1800s because of the development of synthetic dyes. Really odd that oil paints were really perfected around Holland (major place for flax and thus linseed oil), which is what the dutch masters _did_. Architectural mcmansions began because of the development of pre-fab roof trusses in the 70s and 80s.

How about philosophy? Well, the industrial revolution and it's consequences have been a disaster for the human race. I could go on.

The issue is that engineers think they're smart and can design things from first principles. The problem is that they're really not, and design things from first principles.

https://bbenchoff.github.io/pages/MacSSL.html

Comments URL: https://news.ycombinator.com/item?id=44236900

Points: 174

# Comments: 37

Comments URL: https://news.ycombinator.com/item?id=43004810

Points: 2

# Comments: 0

https://twitter.com/ViolenceWorks/status/1335382435031252992...