pcb layout

Ah!, who needs etching?

Veroboard is cool, even use it for GHz stuff:

I had some old mylar tapeups in the basement. Some folks were cleaning up and found them. They plan to frame them and hang them in the lobby.

I remember when checking a layout took two people two days. Now it takes two seconds.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

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.

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

It will probably come in handy when SF embarks on that $100 billion flood control wall they're contemplating.

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

The schematics probably also had all capacitors put together

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.

Flood control? Most of SF is well above sea level, and sea level is rising about 2mm per year. No cause to panic.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

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

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

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?

"Type theory" is the usual idea that "type inference" makes guarantees.

"Library design" is a different or wider praxis than "logic design".

If it's not guaranteed, it's not guaranteed.

The matters of "input validation" are usual, and Postel's principle, then it's usually type-safety and type-inference which make it possible to interpret code in the language of a runtime of a model of computation its "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.

All those details will have to be specified to the AI layout thing.

Yes. I don't always see some of the issues, or catch mistakes, until I review the schematic and layout.

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

If you rely on usually enough a C binding, as with regards to entry point ordinal offsets and then the parameter marshalling convention or calling convention, then a usual idea might be that the library design basically needs make the interface as according to the machine types so in the various (for examples) CDECL, FASTCALL, STADPI kinds of the calling conventions: then that the parameters or arguments are integer types, then that the called routine always has to validate its own inputs.

I.e., there is a sort of "typing" even of a C interface.

Various languages that are more loosely typed, often enough have other languages that are more strongly typed, as compile to them, for example the usual idea of higher-level and lower-level languages.

Here there's a perceived requirement for a sort of "typing and templating assembler language", as what emits assembler as an intermediate representation, while having the behavior of the language according to the guarantees after type interface of the type safety in the type theory.

Yes, he used multilayer boards with a 5-volt plane and a ground plane.

The planes are better caps than any discrete part you can buy. Scatter a few polymers here and there if you expect big low-frequency load steps.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

And there won't be until the Greenland and West Antarctic ice sheets start sliding off into the oceans, as they have done in earlier interglacials. That will happen quite rapidly once ot gets under way.

When Kicad got decent control of differential pair routing, I switched from Altium to Kicad. It's alright; I wouldn't design cellphone boards with it, but for those I'm not prepared to pay the hassle-tax for Cadence (even if we do get it cheap on academic licence), and the hassle of dealing with Altium licensing is enough friction to just use Kicad instead. Also Kicad works on Linux and Macs which Altium doesn't (I used to run Altium in a VMWare VM on Mac and it worked ok, but it was a PITA).

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.

Theo

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.

I draw "gesture" templates in Adobe Illustrator as it's a nice, convenient GRAPHICAL way to manipulate 2D "paths". And, because .ai files are largely text, I can find the few lines of PostScript that correspond to the path I've drawn out. These, I extract and store in my "gesture database". Much easier than building my own tool to provide this editing ability!

The early versions of Ventura Publisher used intuitive text formats (like a crude SGML) for the files they created. I could use a text editor with macro capability to systematically parse and alter them according to my needs -- as the GUI tool didn't consider the changes I wanted to be make worth developing an interface to accommodate.

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

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!

Yes -- assuming the tool/library interfaces are known and frozen.

Exactly. There are no "universal libraries" as schematic depictions, footprints, keep-out zones, etc. all vary.

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.

There is no incentive for a vendor (even FOSS) to make it easy for you to LEAVE their tool.

Like industrial toilet paper suppliers who go to lengths to ensure the "free dispensers" they gave you will only accommodate THEIR rolls of toilet paper. (and, of course, you will standardize on