6 ms·
> I don't see circuit-as-code taking off with humans anytime soon I don't agree with this. Circuits aren't really anything more complex than anything else hum
by bb88 1y ago
> I don't see circuit-as-code taking off with humans anytime soon
I don't agree with this. Circuits aren't really anything more complex than anything else humanity has had to figure out. Most knowledge in this area seems solvable.
Maxwell's equations have been known for a century.
For whatever reason, Software Engineering and Hardware Engineering even though they rely upon the same fundamental physics, are so very different? And apparently can't be reconciled? No. I don't believe it.
- cactacea 1y agoPCB layout is as much art and black magic as it is science. I'm not sure why you dismiss the complexity so easily, this definitely is not just a matter of applying Maxwell's equations.
- 0_____0 1y agoLayout is a puzzle, especially with particularly high density layouts, but some of this is ameliorated by high layer count and fine trace/space boards becoming cheaper. Definitely not black magic. RF layout is black magic, let's not steal their thunder here.
- tuetuopay 1y agoHigh speed PCBs are RF. At high enough frequencies, traces become waveguides, and the result cannot be predicted analytically. Simulation is your only light in this mess.
- 0_____0 1y agoI have been lucky to not have to lay out anything that had frequencies of interest over 1Ghz or so. What's your experience been? E.g. types of signals, frequency range, issues you ran into?
- fxtentacle 1y agoSignals that arrive faster than what the speed of light should physically allow for that trace length because you made the corners too sharp and then instead of flowing along your path the electricity creates a magnetic field which then induces a current and that allows the signal to tunnel through non-conductive walls. High speed boards cannot be simulated well. Because they are far from deterministic. That's what makes them so different from coding.
- 0_____0 1y agoWhat was the context you had that issue in? RAM bus?
- numpad0 1y agoIt's just across-modal. The list of components are linear list, connections between components are graphs, placements are geometrically constrained, and overall shape is both geometric and external to the board. So you can't just mechanically derive the board from mere linear textual descriptions of it. A lot of automagic "AGI achieved" LLM projects has this same problem, that it is assumed that brief literal prompt shall fully constrain the end result so long it is well thought out. And it's just not how it - the reality, or animal brains - works.
- 0_____0 1y agoYou need a LOT of context about what the components are and how they're being used in order to route them. Extreme case is an FPGA where a GPIO might be a DAC output or one half of a SERDES diff pair.
- numpad0 1y agoDoesn't even have to be that extreme: there is no way port placements of a Mac Mini can be mathematically derived from a plain English natural language prompt, and yet that's what they're trying to do. It's just the reality that not everything happen or could be done in literal languages. I guess it takes few more years before everyone accepts that.
- bb88 1y agoThere's nothing new in EE under the sun. Hasn't been for 40 years really. EE's min/max a bunch of mathematical equations. There's a lot of them, but it's not nearly as difficult as people think it is. They end up being design constraints, which can be coded, measured, and fed back into the AI. It's not even been three years since Github Copilot was released to developers. And now we're all complaining about "vibe-coding".
- 0_____0 1y agoDesign constraints that have so many factors that people still don't use autorouters for most stuff. You're not getting it, drawing the wires isn't the hard part, understanding the constraints is.
- bogantech 1y ago> For whatever reason, Software Engineering and Hardware Engineering even though they rely upon the same fundamental physics Software engineering isn't a thing besides being an ego title. Software is "ship now, patch later" Hardware is engineered, it must be correctly designed from the beginning and cannot be easily modified in the field
- donkey_brains 1y ago[dead]
- crote 1y ago> For whatever reason, Software Engineering and Hardware Engineering even though they rely upon the same fundamental physics They are completely different. Software is pure mathematics: you know exactly what goes in, you know exactly what operations it is going to do, and you know exactly what will come out. There are no surprises here, it's just a mechanical translation. If you want to, you can even prove that your code is doing the right thing. Hardware is physical. Your components don't neatly follow mathematical models - the model is just a rough approximation. Everything interacts with everything else: a signal in one trace will impact a signal in the next trace over - or even on the other side of the board. Your PCB will behave differently if you hold your hand above it - without even touching it. Worst of all, most of your components are black boxes, and you don't have accurate models describing them! What good are Maxwell's equations if there's no way you're ever going to solve them? You can make a reasonable estimate of how a PCB is going to behave, and you can occasionally do a reasonably-close simulation of some part of your circuit-to-be in isolation. But you need to physically manufacture it to find out whether it behaves the same in practice, and it takes weeks of time and thousands of dollars to manufacture a single prototype. You can't "move fast and break things". You can't afford to do the usual "hit a bug, change tiny thing, recompile, check" cycle you're used to from software programming, and some fancy tooling isn't going to change that reality.