3 ms·
I guess I don't spend enough time laying out tedious-but-straightforwards PCBs to appreciate this. Almost everything I do has some important layout consideratio
by msds 7y ago
I guess I don't spend enough time laying out tedious-but-straightforwards PCBs to appreciate this. Almost everything I do has some important layout considerations like "this loop inductance should be tiny" or "this section needs guard rings" etc. Also, placing components is non-trivial, if you're doing anything dense, fast, or sensitive. I find that's like 90% of layout work: guess where the components should go, try to route the tricky bits, move the components around a bit, route again, etc...
- leoedin 7y agoThis is the part that all the autorouters seem to miss. A board design may be represented in the computer by a schematic, but in reality it's a schematic + a huge amount of engineer knowledge. The person laying out the PCB needs to be able to look at the schematic and know that the switching regulator has very precise layout requirements, but that status LED can be at the end of a long trace. That information simply isn't captured in current schematic software. Until it is I can't see autorouters being effective. I can see a world where every schematic includes simulation models, and the autorouter uses simulation data to know exactly what frequencies are moving down each net and in each location. That requires detailed spice models of every component on your circuit though - so it probably wouldn't save the designer any time anyway as they're just doing different work. I'm not even sure how you'd simulate the signals coming out of a microcontroller - how does the autorouter know that one PWM IO is producing a 500kHz clock into a high current switch and the other PWM IO is producing a fixed 3.3V? So then maybe you need to incorporate not only simulation models, but your actual CPU code. Which then means you need high quality microcontroller and FPGA emulators. There's a new problem! There's probably a middle ground - a designer could annotate each net with a waveform which would be fed into the spice simulation - but even then we're talking significantly more work than just laying it out yourself.
- colechristensen 7y agoMany of your later concerns could be handled with stub functions and unit tests. Have a test where a specific pin on the processor is set to a 500 kHz and have tests for certain conditions, emissions below a certain level, interference with some other trace, etc. Everything with hardware development seems to be at the stage of a neglected codebase with manual testing, poor test coverage, and slow process. We're just at the point where many of those problems are solvable now with pretty good actual EM simulation. Lots of features need to be added but it all just seems very possible at this point.
- deleted 7y ago[deleted]
- sitkack 7y agoWhat you have outlined is a combination of feedback directed optimization, sensitivity analysis, iteration to a fixed point, cosimulation and configuration spaces. https://en.wikipedia.org/wiki/Profile-guided_optimization https://en.wikipedia.org/wiki/Profile-guided_optimization https://en.wikipedia.org/wiki/Sensitivity_analysis https://en.wikipedia.org/wiki/Sensitivity_analysis https://en.wikipedia.org/wiki/Fixed-point_iteration https://en.wikipedia.org/wiki/Fixed-point_iteration https://en.wikipedia.org/wiki/Co-simulation https://en.wikipedia.org/wiki/Co-simulation https://en.wikipedia.org/wiki/Configuration_space_(physics) https://en.wikipedia.org/wiki/Configuration_space_(physics)