I've seen a bunch of ads lately for PCB layout people. Salary rangesare impressive, up to $170K.Are you seeing a shortage of PCB design people? I'm thinking that alot of startups with megabucks of investment want to show off productssoon, so are competing for layout folks.John LarkinHighland Tech Glen Canyon Design CenterLunatic Fringe Electronics
john larkin <jl@glen--canyon.com> Wrote in message:r
I've seen a bunch of ads lately for PCB layout people. Salary rangesare impressive, up to $170K.Are you seeing a shortage of PCB design people? I'm thinking that alot of startups with megabucks of investment want to show off productssoon, so are competing for layout folks.John LarkinHighland Tech Glen Canyon Design CenterLunatic Fringe Electronics
There's a bunch retiring now.
Cheers
On Tue, 31 Mar 2026 15:22:06 -0400 (EDT), Martin Rid <martin_riddle@verison.net> wrote:
john larkin <jl@glen--canyon.com> Wrote in message:r
I've seen a bunch of ads lately for PCB layout people. Salary rangesare impressive, up to $170K.Are you seeing a shortage of PCB design people? I'm thinking that a lot of startups with megabucks of investment want to show off products soon, so are competing for layout folks.
There's a bunch retiring now.
Might be an opportunity for unemployed CE grads.
On 1/04/2026 6:59 am, john larkin wrote:
On Tue, 31 Mar 2026 15:22:06 -0400 (EDT), Martin Rid
<martin_riddle@verison.net> wrote:
john larkin <jl@glen--canyon.com> Wrote in message:r
I've seen a bunch of ads lately for PCB layout people. Salary rangesare impressive, up to $170K.Are you seeing a shortage of PCB design people? I'm thinking that a lot of startups with megabucks of investment want to show off products soon, so are competing for layout folks.
There's a bunch retiring now.
Might be an opportunity for unemployed CE grads.
There's quite a strong visual element in the job. Computer science >engineering doesn't call for that. Artificial intelligence might step
in. Automatic layout programs never worked all that well, and human
layout specialists were rarely as careful about stray capacitances and >inductance as they needed to be, though some of them were quick to learn,
On Wed, 1 Apr 2026 16:47:34 +1100, Bill Sloman <bill.sloman@ieee.org>
wrote:
On 1/04/2026 6:59 am, john larkin wrote:
On Tue, 31 Mar 2026 15:22:06 -0400 (EDT), Martin Rid
<martin_riddle@verison.net> wrote:
john larkin <jl@glen--canyon.com> Wrote in message:r
I've seen a bunch of ads lately for PCB layout people. Salary rangesare impressive, up to $170K.Are you seeing a shortage of PCB design people? I'm thinking that a lot of startups with megabucks of investment want to show off products soon, so are competing for layout folks.
There's a bunch retiring now.
Might be an opportunity for unemployed CE grads.
There's quite a strong visual element in the job. Computer science
engineering doesn't call for that. Artificial intelligence might step
in. Automatic layout programs never worked all that well, and human
layout specialists were rarely as careful about stray capacitances and
inductance as they needed to be, though some of them were quick to learn,
The best pcb layout people rarely understand electronics. But CE grads
rarely understand electronics either.
We explain the rules to them and check their work. If something is
especially critical, I sometime find it easier to do that bit of the
layout myself; that's easier than trying to explain all the
constraints.
On 1/04/2026 6:42 pm, john larkin wrote:
On Wed, 1 Apr 2026 16:47:34 +1100, Bill Sloman <bill.sloman@ieee.org>
wrote:
On 1/04/2026 6:59 am, john larkin wrote:The best pcb layout people rarely understand electronics. But CE grads
On Tue, 31 Mar 2026 15:22:06 -0400 (EDT), Martin Rid
<martin_riddle@verison.net> wrote:
john larkin <jl@glen--canyon.com> Wrote in message:r
I've seen a bunch of ads lately for PCB layout people. Salary rangesare impressive, up to $170K.Are you seeing a shortage of PCB design people? I'm thinking that a lot of startups with megabucks of investment want to show off products soon, so are competing for layout folks.
There's a bunch retiring now.
Might be an opportunity for unemployed CE grads.
There's quite a strong visual element in the job. Computer science
engineering doesn't call for that. Artificial intelligence might step
in. Automatic layout programs never worked all that well, and human
layout specialists were rarely as careful about stray capacitances and
inductance as they needed to be, though some of them were quick to learn, >>
rarely understand electronics either.
We explain the rules to them and check their work. If something is
especially critical, I sometime find it easier to do that bit of the
layout myself; that's easier than trying to explain all the
constraints.
Me too, but I've never had much trouble explaining to a layout person
what the electronic constraints are, and the better ones could see what
I meant and cleaned up extra stuff I hadn't got around to objecting to.
At least one of them was the daughter of one of the very clever
technicians who worked at Cambridge Instruments. In a more egalitarian >country he would have been doing my job. The UK sucked from time to time.
What CAD tools is everyone using for schematic capture through PCB layout?
We currently use Altium at work. I used to use the Cadence suite of tools >which were very comprehensive, very expensive, and in my opinion very buggy.
Are any of the open source tools decent?
What CAD tools is everyone using for schematic capture through PCB layout?
We currently use Altium at work. I used to use the Cadence suite of tools which were very comprehensive, very expensive, and in my opinion very
buggy.
Are any of the open source tools decent?
Am 01.04.26 um 19:51 schrieb Buzz McCool:
What CAD tools is everyone using for schematic capture through PCB layout? >>
We currently use Altium at work. I used to use the Cadence suite of tools
which were very comprehensive, very expensive, and in my opinion very buggy. >>
Are any of the open source tools decent?
Altium here. I stopped the yearly support fee when they
would not help me at all when they heard that my Windows
runs under VMware on a Linux host. Their excuse was that
VMware could not handle networks. ROTFL! That's what earns
them their money.
The real problem for Altium as I see it is, that a full
installation with local license file can simply be copied
and you can run as many incarnations of the VM as long as
the virtual machines cannot see each other.
Not a real argument for me as a one man band, but I don't
want to allow access to Internet for the Windows VM.
If I crash the VM badly, I can simply fetch a new copy
from an external drive.
Other than that, the VM sees only C: which is just system
& tools˙ and d: for the user data which is /d under Linux,
mapped by VMware.
BTW, my problem was that I had renamed an old Protel library
from .lib to .pcblib. Altium reads libraries completely
without checking the contents and dies 500ms after startup.
That bug must have been in Altium since the very beginning,
never ever corrected.
For some time we used PADS layout with Orcad STD schematics.
I even wrote a converter to augment the netlist with the
decals, but an island solution.
Never use a CAD program without access to a large user base.
Sometimes I use Genesys / ADS when the customer has a
license, mostly for microstrip filter design / Electromagnetics
etc, but never for board production. Transfer to Altium is
not without problems but can be done. I managed to transfer
some optimized comb line filters so that they looked like
standard PCB decals in Altium.
KICAD ia said to be quite OK, but I have never tried it.
There seems to be a bridge from Qucs Studio / usimmics to Kicad,
(Verilog-A, spice, s-parameters, harmonic balance...)
<˙ https://qucsstudio.de/download/˙˙˙ >
Click on the English flag.
I have played with that a bit, no complaints from my side.
Gerhard
The words out there's absolutely no future in this profession. AI can do so much better and so much more than any human. AI can evaluate prospective partial layouts for things like signal integrity and inter-trace coupling in real time during the layout process. It's only a matter of time for the right
people to be needy enough to develop the specialized training algorithms. Or,
even more spectacular, for AI systems to develop training algorithms for AI applications like this.
The words out there's absolutely no future in this profession. AI can do so much better and so much more than any human. AI can evaluate prospective partial layouts for things like signal integrity and inter-trace coupling in real time during the layout process. It's only a matter of time for the right people to be needy enough to develop the specialized training algorithms. Or, even more spectacular, for AI systems to develop training algorithms for AI applications like this.
STRIDES was, by far, the most productive tool for schematic capture
(assuming you had an adequate library).˙ OrCAD's Layout was annoying
when you tried to manually fix a routing (it would rip it up and
put it back where *it* wanted it to be!)˙ Tools change owners
so it's hard to keep track of each pedigree.
Gerhard
The words out there's absolutely no future in this profession. AI can do
so much better and so much more than any human. AI can evaluate
prospective partial layouts for things like signal integrity and
inter-trace coupling in real time during the layout process. It's only a matter of time for the right people to be needy enough to develop the specialized training algorithms. Or, even more spectacular, for AI
systems to develop training algorithms for AI applications like this.
On 04/01/2026 04:15 PM, someone wrote:
The words out there's absolutely no future in this profession. AI can do
so much better and so much more than any human. AI can evaluate
prospective partial layouts for things like signal integrity and
inter-trace coupling in real time during the layout process. It's only a
matter of time for the right people to be needy enough to develop the
specialized training algorithms. Or, even more spectacular, for AI
systems to develop training algorithms for AI applications like this.
You just draw whatever you want with a resist pen and etch the rest off.
On Wed, 1 Apr 2026 17:06:23 -0700, Ross Finlayson ><ross.a.finlayson@gmail.com> wrote:
On 04/01/2026 04:15 PM, someone wrote:
The words out there's absolutely no future in this profession. AI can do >>> so much better and so much more than any human. AI can evaluate
prospective partial layouts for things like signal integrity and
inter-trace coupling in real time during the layout process. It's only a >>> matter of time for the right people to be needy enough to develop the
specialized training algorithms. Or, even more spectacular, for AI
systems to develop training algorithms for AI applications like this.
You just draw whatever you want with a resist pen and etch the rest off.
No, use a Dremel and remove the parts you don't want.
John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics
What CAD tools is everyone using for schematic capture through PCB layout?
We currently use Altium at work. I used to use the Cadence suite of tools which were very comprehensive, very expensive, and in my opinion very
buggy.
Are any of the open source tools decent?
STRIDES was, by far, the most productive tool for schematic capture
(assuming you had an adequate library).˙ OrCAD's Layout was annoying
when you tried to manually fix a routing (it would rip it up and
put it back where *it* wanted it to be!)˙ Tools change owners
so it's hard to keep track of each pedigree.
I don't know STRIDES but I liked DOS Orcad schematics. Somehow I
still miss it. We must have been one of the very first customers.
They had just tiny ads in EDN.
https://www.flickr.com/photos/137684711@N07/52631074700/in/datetaken/lightbox/
I did this board in DOS Orcad on a Compaq-286, but only the
schematics & firmware part. I had some unlucky guy to do the
layout under time pressure. It is a complete PC-AT in Multibus2
format with 386/387, SCSI, floppy, transputer link, 2*com:, LPT:,
cache and a whopping 8 MBytes of DRAM, dual ported to the Multibus2.
The router routed happily across existing vias etc...
=:( )
At that time we cracked Racal RedBoard that used a laser-
mutilated floppy as copy protection. That was hard because
RedBoard claimed ALL available RAM for itself--- but we had extra
RAM above the video card. The Microsoft CodeView debugger could
be loaded high, so we saw the RMW cycles on the floppy and could
skip them.
That took an entire Easter weekend which was a _very_ bad
investment of time. The software was sooo ugly.
Nostalgia:
<https://www.learnbydestroying.com/jeffl/PCB-Layout/>
All the PCB stuff went in the trash about 5 years ago. I kept the
tools and templates for no obvious reason. (Please ignore the sewing machine).
Jeff Liebermann <jeffl@cruzio.com>wrote:
On Wed, 01 Apr 2026 17:17:09 -0700, john larkin <jl@glen--canyon.com>wrote:
On Wed, 1 Apr 2026 17:06:23 -0700, Ross Finlayson >><ross.a.finlayson@gmail.com> wrote:
On 04/01/2026 04:15 PM, someone wrote:
The words out there's absolutely no future in this profession. AI can do >>>> so much better and so much more than any human. AI can evaluate
prospective partial layouts for things like signal integrity and
inter-trace coupling in real time during the layout process. It's only a >>>> matter of time for the right people to be needy enough to develop the
specialized training algorithms. Or, even more spectacular, for AI
systems to develop training algorithms for AI applications like this.
You just draw whatever you want with a resist pen and etch the rest off.
No, use a Dremel and remove the parts you don't want.
John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics
Nostalgia:
<https://www.learnbydestroying.com/jeffl/PCB-Layout/>
All the PCB stuff went in the trash about 5 years ago. I kept the
tools and templates for no obvious reason. (Please ignore the sewing >machine).
On Wed, 01 Apr 2026 17:17:09 -0700, john larkin <jl@glen--canyon.com>
wrote:
On Wed, 1 Apr 2026 17:06:23 -0700, Ross Finlayson >><ross.a.finlayson@gmail.com> wrote:
On 04/01/2026 04:15 PM, someone wrote:
The words out there's absolutely no future in this profession. AI can do >>>> so much better and so much more than any human. AI can evaluate
prospective partial layouts for things like signal integrity and
inter-trace coupling in real time during the layout process. It's only a >>>> matter of time for the right people to be needy enough to develop the
specialized training algorithms. Or, even more spectacular, for AI
systems to develop training algorithms for AI applications like this.
You just draw whatever you want with a resist pen and etch the rest off.
No, use a Dremel and remove the parts you don't want.
John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics
Nostalgia:
<https://www.learnbydestroying.com/jeffl/PCB-Layout/>
All the PCB stuff went in the trash about 5 years ago. I kept the
tools and templates for no obvious reason. (Please ignore the sewing >machine).
On Wed, 01 Apr 2026 18:20:53 -0700, Jeff Liebermann <jeffl@cruzio.com>
wrote:
On Wed, 01 Apr 2026 17:17:09 -0700, john larkin <jl@glen--canyon.com>
wrote:
On Wed, 1 Apr 2026 17:06:23 -0700, Ross Finlayson
<ross.a.finlayson@gmail.com> wrote:
On 04/01/2026 04:15 PM, someone wrote:
I remember when checking a layout took two people two days. Now it
takes two seconds.
On 3/04/2026 2:11 am, john larkin wrote:
On Wed, 01 Apr 2026 18:20:53 -0700, Jeff Liebermann <jeffl@cruzio.com>
wrote:
On Wed, 01 Apr 2026 17:17:09 -0700, john larkin <jl@glen--canyon.com>
wrote:
On Wed, 1 Apr 2026 17:06:23 -0700, Ross Finlayson
<ross.a.finlayson@gmail.com> wrote:
On 04/01/2026 04:15 PM, someone wrote:
<snip>
I remember when checking a layout took two people two days. Now it
takes two seconds.
We used to check the layouts for cross-talk and long paths to decoupling capacitors. If you supervise the layout carefully enough, or do it
yourself, you may not need to do that. But just making sure that the
netlist matches the circuit diagram isn't enough. I've seen that go
wrong much too often.
On 4/2/26 19:12, Bill Sloman wrote:
...
.. like that time the (remote) lay-out person put all decoupling
capacitors on a huge board full of TTL all together in one corner.
That one taught me a lesson.
Jeroen Belleman
EDN just published an authoritative summary of the state of development of AI EDA design. As usual, it's a free-for-all of profit-hungry jackals. Now is not the best time for an expensive investment. This is going to take a while.
https://www.edn.com/what-is-the-eda-problem-worth-solving-with-ai/
On another note, Meta just revolutionized concrete production with their Bayesian Optimization AI. Concrete is more technical/ scientific/ experimental than people realize. Who knew the U.S. was overly dependent on foreign cement? The fact that giga-producer Amrize is getting behind it pretty much confirms the claims made in the article.
https://engineering.fb.com/2026/03/30/data-center-engineering/ai-for-american-produced-cement-and-concrete/
It will probably come in handy when SF embarks on that $100 billion flood control wall they're contemplating.
On 4/2/26 19:12, Bill Sloman wrote:
On 3/04/2026 2:11 am, john larkin wrote:
On Wed, 01 Apr 2026 18:20:53 -0700, Jeff Liebermann <jeffl@cruzio.com>
wrote:
On Wed, 01 Apr 2026 17:17:09 -0700, john larkin <jl@glen--canyon.com>
wrote:
On Wed, 1 Apr 2026 17:06:23 -0700, Ross Finlayson
<ross.a.finlayson@gmail.com> wrote:
On 04/01/2026 04:15 PM, someone wrote:
<snip>
I remember when checking a layout took two people two days. Now it
takes two seconds.
We used to check the layouts for cross-talk and long paths to decoupling
capacitors. If you supervise the layout carefully enough, or do it
yourself, you may not need to do that. But just making sure that the
netlist matches the circuit diagram isn't enough. I've seen that go
wrong much too often.
.. like that time the (remote) lay-out person put all decoupling
capacitors on a huge board full of TTL all together in one corner.
That one taught me a lesson.
Jeroen Belleman
EDN just published an authoritative summary of the state of development of AI
EDA design. As usual, it's a free-for-all of profit-hungry jackals. Now is not
the best time for an expensive investment. This is going to take a while.
On 4/3/2026 9:45 AM, someone wrote:
EDN just published an authoritative summary of the state of
development of AI EDA design. As usual, it's a free-for-all of
profit-hungry jackals. Now is not the best time for an expensive
investment. This is going to take a while.
The applicaion of AI in EDA/CAE will continue the approach it has taken
for the
past 50 years -- nibbling at the "niggly stuff" along the edges of
design. The
stuff that is a drudge for most designers (and often ignored because of
that
"chore-like nature" -- testing, methodically verifying *implementation* constraints (as *design* constraints are often not available!), etc.
In layout, we see how trace widths are automatically chosen based on their current carrying ability, spacing based on potential differences, netlist verification, device physical characteristics, etc. The sorts of mundane activities that need to be done, can be done methodically and that few
folks really WANT to spend their time doing! (so, they welcome tools
that will do those things FOR them).
ML can work with hardware designs because they tend to be more consistent (within a single design); fewer minds patching them together so biases
are more pronounced.
In software, the same sort of drudgery will be addressed with AI tools
in the same way it has already been addressed with "wizards", parser generators, symbolic execution, etc. Take the dreariness out of the
"9-to-5" coding and do it more methodically and thoroughly. E.g., Anyone
who builds /ad hoc/ parsers in the 21st century is surely not a skilled crafstman!
The problem with all design activities is the need for specification;
some way of conveying your goals and constraints to an agent so that
they are thorough and accurate.
It's easy to say "accept 110VAC 60Hz (with a set of tolerances) and
produce 12VDC at 18A (with another set of tolerances)". Just as it is
to say "accept a series of keystrokes that represent a numerical value between 23 and 1904". But, these don't represent much design *work*.
Trying to infer specifications from an examination of past efforts
really only works for groups of very similar efforts. E.g., the code
on web pages (which is likely already generated mechanically -- a machine learning from another machine?)
E.g., I design hardware (field) interfaces with appropriate protection for the sorts of "unintended" signals/conditions that can likely be expected. Exceed those limits and there's no guarantee my designs will behave or
even survive.
I design software interfaces similarly -- religiously checking all inputs
and verifying outputs are constrained to the domain. Yet, my latest design intentionally avoids all of that by insisting that the data is sourced
from an agency that *ensures* it complies with the constraints of its consumers. E.g., a "date" will always be a valid "date".
This changes the way the rest of the codebase deals with inputs; instead
of verifying that a parameter *is* a date (e.g., 29 Feb 2009 is not but
29 Feb 2008 *is*; there is no "month 13" or "day 82"), I can be assured
that the parameter satisfies ALL constraints for a "date" and need only
worry about whether or not the function under test accurately processes
ALL such dates!
This dramatically changes the complexion of the code. Colleagues familiar with my past design approaches are alarmed to see all of this "runtime checking" elided! Can an AI "understand" this constraint JUST from an examination of the entire codebase? How can I guarantee that other developers
and maintainers of the codebase adopt a similar strategy?
This dramatically changes the complexion of the code.˙ Colleagues familiar >> with my past design approaches are alarmed to see all of this "runtime
checking" elided!˙ Can an AI "understand" this constraint JUST from an
examination of the entire codebase?˙ How can I guarantee that other
developers
"Type theory" is the usual idea that "type inference" makes guarantees.
On 4/3/2026 9:45 AM, someone wrote:
EDN just published an authoritative summary of the state of development of AI
EDA design. As usual, it's a free-for-all of profit-hungry jackals. Now is not
the best time for an expensive investment. This is going to take a while.
The applicaion of AI in EDA/CAE will continue the approach it has taken for the
past 50 years -- nibbling at the "niggly stuff" along the edges of design. The
stuff that is a drudge for most designers (and often ignored because of that >"chore-like nature" -- testing, methodically verifying *implementation* >constraints (as *design* constraints are often not available!), etc.
In layout, we see how trace widths are automatically chosen based on their >current carrying ability, spacing based on potential differences, netlist >verification, device physical characteristics, etc. The sorts of mundane >activities that need to be done, can be done methodically and that few
folks really WANT to spend their time doing! (so, they welcome tools
that will do those things FOR them).
ML can work with hardware designs because they tend to be more consistent >(within a single design); fewer minds patching them together so biases
are more pronounced.
In software, the same sort of drudgery will be addressed with AI tools
in the same way it has already been addressed with "wizards", parser >generators, symbolic execution, etc. Take the dreariness out of the
"9-to-5" coding and do it more methodically and thoroughly. E.g., Anyone
who builds /ad hoc/ parsers in the 21st century is surely not a skilled >crafstman!
The problem with all design activities is the need for specification;
some way of conveying your goals and constraints to an agent so that
they are thorough and accurate.
It's easy to say "accept 110VAC 60Hz (with a set of tolerances) and
produce 12VDC at 18A (with another set of tolerances)". Just as it is
to say "accept a series of keystrokes that represent a numerical value >between 23 and 1904". But, these don't represent much design *work*.
Trying to infer specifications from an examination of past efforts
really only works for groups of very similar efforts. E.g., the code
on web pages (which is likely already generated mechanically -- a machine >learning from another machine?)
E.g., I design hardware (field) interfaces with appropriate protection for >the sorts of "unintended" signals/conditions that can likely be expected. >Exceed those limits and there's no guarantee my designs will behave or
even survive.
I design software interfaces similarly -- religiously checking all inputs
and verifying outputs are constrained to the domain. Yet, my latest design >intentionally avoids all of that by insisting that the data is sourced
from an agency that *ensures* it complies with the constraints of its >consumers. E.g., a "date" will always be a valid "date".
This changes the way the rest of the codebase deals with inputs; instead
of verifying that a parameter *is* a date (e.g., 29 Feb 2009 is not but
29 Feb 2008 *is*; there is no "month 13" or "day 82"), I can be assured
that the parameter satisfies ALL constraints for a "date" and need only
worry about whether or not the function under test accurately processes
ALL such dates!
This dramatically changes the complexion of the code. Colleagues familiar >with my past design approaches are alarmed to see all of this "runtime >checking" elided! Can an AI "understand" this constraint JUST from an >examination of the entire codebase? How can I guarantee that other developers >and maintainers of the codebase adopt a similar strategy?
On Fri, 3 Apr 2026 10:05:16 +0200, Jeroen Belleman
<jeroen@nospam.please> wrote:
On 4/2/26 19:12, Bill Sloman wrote:
On 3/04/2026 2:11 am, john larkin wrote:
On Wed, 01 Apr 2026 18:20:53 -0700, Jeff Liebermann <jeffl@cruzio.com> >>>> wrote:
On Wed, 01 Apr 2026 17:17:09 -0700, john larkin <jl@glen--canyon.com> >>>>> wrote:
On Wed, 1 Apr 2026 17:06:23 -0700, Ross Finlayson
<ross.a.finlayson@gmail.com> wrote:
On 04/01/2026 04:15 PM, someone wrote:
<snip>
I remember when checking a layout took two people two days. Now it
takes two seconds.
We used to check the layouts for cross-talk and long paths to decoupling >>> capacitors. If you supervise the layout carefully enough, or do it
yourself, you may not need to do that. But just making sure that the
netlist matches the circuit diagram isn't enough. I've seen that go
wrong much too often.
.. like that time the (remote) lay-out person put all decoupling
capacitors on a huge board full of TTL all together in one corner.
That one taught me a lesson.
Jeroen Belleman
I knew a guy, at Lockheed as I recall, who did giant TTL boards with
no bypass caps. They worked.
John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics
On 4/3/2026 11:57 AM, Ross Finlayson wrote:
This dramatically changes the complexion of the code. Colleagues
familiar
with my past design approaches are alarmed to see all of this "runtime
checking" elided! Can an AI "understand" this constraint JUST from an
examination of the entire codebase? How can I guarantee that other
developers
"Type theory" is the usual idea that "type inference" makes guarantees.
Not all languages are strongly typed. And, not all developers *refine* specific types. E.g., if a parameter must be an even integer, will
you go to the length of formally defining a type that covers ONLY
the even integers? And, will the language then enforce this?
OTOH, if the *mechanism* that provides the parameters makes these
guarantees, you are free to use languages that DON'T have strict
typing.
On 4/3/26 19:47, john larkin wrote:
On Fri, 3 Apr 2026 10:05:16 +0200, Jeroen Belleman
<jeroen@nospam.please> wrote:
On 4/2/26 19:12, Bill Sloman wrote:
On 3/04/2026 2:11 am, john larkin wrote:
On Wed, 01 Apr 2026 18:20:53 -0700, Jeff Liebermann <jeffl@cruzio.com> >>>>> wrote:
On Wed, 01 Apr 2026 17:17:09 -0700, john larkin <jl@glen--canyon.com> >>>>>> wrote:
On Wed, 1 Apr 2026 17:06:23 -0700, Ross Finlayson
<ross.a.finlayson@gmail.com> wrote:
On 04/01/2026 04:15 PM, someone wrote:
<snip>
I remember when checking a layout took two people two days. Now it
takes two seconds.
We used to check the layouts for cross-talk and long paths to decoupling >>>> capacitors. If you supervise the layout carefully enough, or do it
yourself, you may not need to do that. But just making sure that the
netlist matches the circuit diagram isn't enough. I've seen that go
wrong much too often.
.. like that time the (remote) lay-out person put all decoupling
capacitors on a huge board full of TTL all together in one corner.
That one taught me a lesson.
Jeroen Belleman
I knew a guy, at Lockheed as I recall, who did giant TTL boards with
no bypass caps. They worked.
John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics
Yeah, well, he probably had a couple of full-surface power layers.
Jeroen Belleman
On Fri, 03 Apr 2026 16:45:02 +0000, someone <cffbf4deb9142bce48974efc0e64dede@example.com> wrote:
EDN just published an authoritative summary of the state of development of AI EDA design. As usual, it's a free-for-all of profit-hungry jackals. Now is not the best time for an expensive investment. This is going to take a while.
https://www.edn.com/what-is-the-eda-problem-worth-solving-with-ai/
That's about chip design, which could benefit from a warehouse full of
Nvidia chipa.
The PCB design stuff that I've seen looks silly. The companies are
stuffed with "full stack" programmers mostly. And some hardware
interns.
On another note, Meta just revolutionized concrete production with their Bayesian Optimization AI. Concrete is more technical/ scientific/ experimental than people realize. Who knew the U.S. was overly dependent on foreign cement? The fact that giga-producer Amrize is getting behind it pretty much confirms the claims made in the article.
https://engineering.fb.com/2026/03/30/data-center-engineering/ai-for-american-produced-cement-and-concrete/
It will probably come in handy when SF embarks on that $100 billion flood control wall they're contemplating.
Flood control? Most of SF is well above sea level, and sea level is
rising about 2mm per year. No cause to panic.
On 2/04/2026 4:51 am, Buzz McCool wrote:
What CAD tools is everyone using for schematic capture through PCB layout?
We currently use Altium at work. I used to use the Cadence suite of tools which were very comprehensive, very expensive, and in my opinion very buggy.
Are any of the open source tools decent?
KiCad looks okay, and some people seem to like it. It came from CERN.
I've got it on my computer and used it a bit, but didn't get very far.
I didn't have any problems with the software, but the project stopped
being quite as attractive as it had been when I'd started work on it.
The main nice thing is that the Kicad file formats are just text, so it
plays nicely with other tools like version control. The others would either lock everything behind a horrible proprietary UI (see Cadence Allegro) or
try to build their own tooling (Altium pushed their own SVN when everyone
was adopting git).
The other nice thing is that, being open source, there are decent flows for it from fabs, assembly houses etc.
Main downside is the library management could use some work. I don't really care as I'm just knocking out one-off projects now and then, but if I used
it in production every day I'd want a proper parts database linked to an inventory management system. As Kicad is so easy to interface with I'd not be surprised if there are a third party solution(s) available for that now - I've not really kept up to date.
On 4/4/2026 8:49 AM, Theo wrote:
The main nice thing is that the Kicad file formats are just text, so it plays nicely with other tools like version control. The others would either
lock everything behind a horrible proprietary UI (see Cadence Allegro) or try to build their own tooling (Altium pushed their own SVN when everyone was adopting git).
The advantage of "text" is that YOU can typically sort out how to make changes for which the toolchain hasn't anticipated a need -- assuming
the format/syntax used is intuitive enough that you can suss-out it's
intent.
Of course, the *problem* with this approach is the file format isn't guaranteed to be maintained. So, any efforts you invest in tools to
parse and modify it can be invalidated with the next release (as happened when Corel decided to "improve" VP, altering the file formats in the process)
Libraries are the typical way to bind a user to a product. A considerable investment is required to create and maintain good libraries. These tend
to be non-portable so represent a lot of inertia to keep you with a particular tool.
As AI features increasingly creep into tools, this becomes even more costly as more information has to be encoded in the library (e.g., so a layout or schematic tool can "know" how to swap gates, which inputs are swappable
on a device, etc.).
"Eventually", tools will learn how to do this, much like they can sort out how much current flows down a particular piece of foil that they are
placing on a board (by examining and understanding the "loads" fed by it). But, much easier (and bigger bang for buck) to use data that humans have manually installed *now* without waiting for the tool's ability to do this itself.
The advantage of "text" is that YOU can typically sort out how to make
changes for which the toolchain hasn't anticipated a need -- assuming
the format/syntax used is intuitive enough that you can suss-out it's
intent.
Yes, and it's easy to generate regular patterns like footprints for BGAs. There are Python libraries to generate part structures, so you aren't starting from scratch.
Of course, the *problem* with this approach is the file format isn't
guaranteed to be maintained. So, any efforts you invest in tools to
parse and modify it can be invalidated with the next release (as happened
when Corel decided to "improve" VP, altering the file formats in the process)
Being text, it's easier to extend without having to break the format.
Libraries are the typical way to bind a user to a product. A considerable >> investment is required to create and maintain good libraries. These tend
to be non-portable so represent a lot of inertia to keep you with a
particular tool.
Indeed, something that text helps with (it's not hard to write a converter
to a different tool if needs be).
I'd say the main thing is you need production-ready libraries. eg an SMD part might have different pad sizes depending on the production process.
You want something that's not just the pads according to the datasheet, but is optimised for paste placement, to reduce tombstoning, etc. Those are things that you only really hone after experience with your particular process. A good tool has an IPC compatible library, but you may need to tweak it after experience with production.
Kicad has a lot of libraries kicking around, but there's a difference between one that 'works' and one that is battle-hardened. If doing it every day in production you probably want to manage your own libraries and put new libs
on probation until you've run enough units through your fab.
As AI features increasingly creep into tools, this becomes even more costly >> as more information has to be encoded in the library (e.g., so a layout or >> schematic tool can "know" how to swap gates, which inputs are swappable
on a device, etc.).
"Eventually", tools will learn how to do this, much like they can sort out >> how much current flows down a particular piece of foil that they are
placing on a board (by examining and understanding the "loads" fed by it). >> But, much easier (and bigger bang for buck) to use data that humans have
manually installed *now* without waiting for the tool's ability to do this >> itself.
There's always a tradeoff between telling the tool every little detail about the part so it can run its own checks, and just placing the footprint by
hand where you know no parameter is going to be getting even close to the limits. Unless we get a lot better at data interchange, I suspect for a
good while the latter will remain quicker.
On 4/4/2026 9:49 AM, Theo wrote:
The advantage of "text" is that YOU can typically sort out how to make
changes for which the toolchain hasn't anticipated a need -- assuming
the format/syntax used is intuitive enough that you can suss-out it's
intent.
Yes, and it's easy to generate regular patterns like footprints for BGAs.
There are Python libraries to generate part structures, so you aren't
starting from scratch.
The risk is that a user may find (at least some aspects of) the format
so simple that he doesn't create a tool but, rather, just a little
sed(1) script to do the work. This doesn't help the next guy...
Of course, the *problem* with this approach is the file format isn't
guaranteed to be maintained. So, any efforts you invest in tools to
parse and modify it can be invalidated with the next release (as happened >>> when Corel decided to "improve" VP, altering the file formats in the process)
Being text, it's easier to extend without having to break the format.
I think the real risk is misplaced notions of optimization -- someone >deciding to "compile" the data to cut down on the effort to parse it
the next time the file is opened. There is some value to this
(depending on how large the dataset is) but the one-or-the-other
approach that seems so common is its undoing; compile the file and
save it ALONGSIDE the original. On startup, check timestamps (or
hashes if you don't trust the user to fiddle with the metadata in
the filesystem) to see if the compiled version corresponds with
the original -- if so, use the compiled, if not, recompile!
Libraries are the typical way to bind a user to a product. A considerable >>> investment is required to create and maintain good libraries. These tend >>> to be non-portable so represent a lot of inertia to keep you with a
particular tool.
Indeed, something that text helps with (it's not hard to write a converter >> to a different tool if needs be).
Yes -- assuming the tool/library interfaces are known and frozen.
I'd say the main thing is you need production-ready libraries. eg an SMD
part might have different pad sizes depending on the production process.
Exactly. There are no "universal libraries" as schematic depictions, >footprints, keep-out zones, etc. all vary.
You want something that's not just the pads according to the datasheet, but >> is optimised for paste placement, to reduce tombstoning, etc. Those are
things that you only really hone after experience with your particular
process. A good tool has an IPC compatible library, but you may need to
tweak it after experience with production.
Kicad has a lot of libraries kicking around, but there's a difference between
one that 'works' and one that is battle-hardened. If doing it every day in >> production you probably want to manage your own libraries and put new libs >> on probation until you've run enough units through your fab.
Yes. *You* end up making a big investment in "your" libraries. An investment >that you are loathe to just abandon for another tool, regardless of how
many warts the current tool reveals.
As AI features increasingly creep into tools, this becomes even more costly >>> as more information has to be encoded in the library (e.g., so a layout or >>> schematic tool can "know" how to swap gates, which inputs are swappable
on a device, etc.).
"Eventually", tools will learn how to do this, much like they can sort out >>> how much current flows down a particular piece of foil that they are
placing on a board (by examining and understanding the "loads" fed by it). >>> But, much easier (and bigger bang for buck) to use data that humans have >>> manually installed *now* without waiting for the tool's ability to do this >>> itself.
There's always a tradeoff between telling the tool every little detail about >> the part so it can run its own checks, and just placing the footprint by
hand where you know no parameter is going to be getting even close to the
limits. Unless we get a lot better at data interchange, I suspect for a
good while the latter will remain quicker.
There is no incentive for a vendor (even FOSS) to make it easy for
you to LEAVE their tool.
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 6 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 493396:30:54 |
| Calls: | 141 |
| Files: | 538 |
| Messages: | 76,283 |
