upvote

points

by bb882 days ago |
comments
upvoteby cactacea2 days ago|
next
[-]
PCB 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.
reply
upvoteby 0_____02 days ago|
parent|
[-]
Layout 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.
reply
upvoteby tuetuopay2 days ago|
parent|
next
[-]
High 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.
reply
upvoteby 0_____01 days ago|
parent|
[-]
I 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?
reply
upvoteby fxtentacle1 days ago|
parent|
[-]
Signals 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.

reply
upvoteby 0_____01 days ago|
parent|
[-]
What was the context you had that issue in? RAM bus?
reply
upvoteby numpad01 days ago|
parent|
prev|
[-]
It'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.

reply
upvoteby 0_____022 hours ago|
parent|
[-]
You 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.
reply
upvoteby numpad021 hours ago|
parent|
[-]
Doesn'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.
reply
upvoteby bb8813 hours ago|
parent|
[-]
There'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".

reply
upvoteby 0_____012 hours ago|
parent|
next
[-]
Design 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.
reply
upvoteby bb889 hours ago|
parent|
[-]
I think we agree with that part.

I once thought software constraints were so hard a machine would never be able to program it.

But on the other hand, there are tons of circuit boards designed day after day. If it was super hard, we'd not be able to have the tens of thousands of high speed motherboards that come out year after year.

reply
upvoteby numpad010 hours ago|
parent|
prev|
[-]
So "not everything happen or could be done in literal languages" is the part that got you?
reply
upvoteby bb889 hours ago|
parent|
[-]
18ghz circuits were around since 1973 was the part that got me.

Your response doesn't really add to the conversation so I'll stop here.

reply
upvoteby bogantech2 days ago|
prev|
next
[-]
> 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

reply
upvoteby crote1 days ago|
prev|
[-]
> 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.

reply