current PCB design best practices are stone-age

[tggzzz]

With software, I have the option of basically designing the rules, and as long as I design good rules and apply them properly, everything works. With hardware, the laws of physics are the rules, and you must respect them.

Actually, there are analogous problems with software...

Statically compiled languages (especially C/C++) can only optimise based on what can be determined at compile time. There are many hints that can be given by the programmer, but the compiler may or may not be able to use them. C/C++ is full of problems w.r.t. optimising in the presence of aliasing. I remember the "should we allow the possibility of casting-away-constness" wars for a couple of decades ago. Dynamically compiled languages (e.g. Smalltalk, Java, Self) can make optimisations at runtime that C/C++ cannot.

Then look at the hand-written optimisations for inner-loops in, e.g. high-performance computing (HPC) and cryptography.

And, of course there are cache problems. Often the HPC mob rearrange their entire program so as to minimise cache misses. (Consider latencies: "cache is the new RAM, RAM is the new disk")

And then there are NUMA and network characteristics to be dealt with.

Nope, software doesn't "just work".

[chris_leyson]

He created small building blocks and then wrote some Python scripts to automatically create a Spice model, run a simulation and verify output values

.

Probably spent the best part of a week shuffling small circuit blocks around on a pair of PCBs that are stacked one on top of the other, generate 3D model, inspect 3D model for clearances, move or rotate circuit blocks, repeat etc. Some scripts would probably speed up the 3D file generation but it would be nice if I could lay out both PCBs simultaneously in 3D and then click a button and generate a map showing the clearance between components.

As far as 3D layout goes my PCB design tools are stone-age. The 3D modeling constraints probably wouldn't be too difficult to set up, just put bounding boxes around things that have to be constrained to an aproximate area or constrain things to a single axis if things needed to line up, quite a lengthly procedure with todays PCB tools and I would still have to generate a 3D model. Then there are the electrical constraints to consider but I've taken care of most of those by grouping things into small blocks, I've got three switched mode power supplies and 1000Base-T ethernet to consider, thank God there isn't any high performance low noise analog or RF stuff.

It's all constraint driven and with todays tools it's quicker to do it manually.

[tggzzz]

I've got three switched mode power supplies and 1000Base-T ethernet to consider, thank God there isn't any high performance low noise analog or RF stuff.

Considering EMI from SMPSs and that the 1000base-t PHY uses 5-level PAM plus adaptive equalisation, I would have thought you did have analogue and RF circuits!

[chris_leyson]

Power supplies sit on the lower PCB and ethernet differential pairs are routed on the top layer of the upper PCB. Transformers are shielded and there are two 35u ground planes between the transformer and ethernet routing, so that should help reduce the effects from leakage inductance. My biggest worry is using 0.5mm flat flex as co-planar wave guide.

[FrankBuss]

You're configuring a specific piece of hardware to make a processor. Do you expect that the best processor you can make comes from randomly scattering stuff all over the place? Is that how Intel makes a processor?

That's only a limitation of the synthesizer. There are many CPU designs on OpenCores which work without problems and which are pure VHDL or Verilog. I guess the tweakings for Microblaze optimize some parts to allow a higher clock rate. I wouldn't be surprised if they are not even needed anymore with improvements in the synthesizer, but of course, nobody changes a running system.

There's a huge difference between software and hardware. When you're dealing with hardware, you're dealing with physical devices that have to respect the laws of physics. With software, I have the option of basically designing the rules, and as long as I design good rules and apply them properly, everything works. With hardware, the laws of physics are the rules, and you must respect them.

There is not much difference, just other rules. With (current) software you have some kind of linear processing unit with limited parallel capabilites, temporary (RAM) and permanent (flash/harddidsk) storage, with its own sets of rules how it works and interacts. When you write software, you design it on top of these rules and you can test it on computers if it runs.

With something like Keysight ADS, you can design circuits, and simulate and verify it in depth with testbenches. The rules are the physical attributes of the components and how they interact, but you can create a lot of interesting things by combining these components. It is a bit more complicated than software, because it is all parallel and software is more flexible, because software can change software, or learn (neuronal networks etc.) but this is not possible (so far) with circuits: a resistor can't clone and wire itself at runtime but then most software is very boring and not flexible, too.

[FrankBuss]

As other processes (e.g. Occam [2]) emerge, manual layout will become much more difficult and the benefits of automatic layout will be overwhelmingly clear. I see automatic layout becoming the conventional practice as an eventuality, not a mere possibility as most suggest.

Not very related to the topic, but Occam sounds very cool. Would be nice to see a video of it in action, it's a bit difficult to visualize all the steps described on the Wikipedia page. Does it already work or is it just a concept, or is there a prototype? Does it work for multilayer high density PCBs with big fine pitch BGAs?

[tggzzz]

There is not much difference [between hardware and software], just other rules. With (current) software you have some kind of linear processing unit with limited parallel capabilites, temporary (RAM) and permanent (flash/harddidsk) storage, with its own sets of rules how it works and interacts. When you write software, you design it on top of these rules and you can test it on computers if it runs.

A key difference is the order of the complexity, and of emergent behaviour (classic example: which "rule" defining individual grains of sand leads to sand piles being conical with a half-angle of 35 degrees?)

1) In the kind of software system you outline, complexity rises vaguely proportionately to the number of components. There are exceptions, of course, especially in a large system made from many components produced by multiple manufacturers , e.g. banking, telecoms, (i.e. more like a typical hardware system)

2) With hardware-on-a-PCB system or inside an FPGA, however, the complexity rises as a power (min 2!) of the number of components, simply because there is, in general, a much higher "random" interconnectivity between components. There are exceptions, of course, especially where there is a uni-directional dataflow in the architecture, (i.e. more like a simple software system).

(For simplicity, I've ignored the important "abstraction leakages" which make the issues even less tractable. Software examples: cache capacity, page thrashing, NUMA, resource contention. Hardware examples: high clock fanout switching problems, speed of light, analogue effects in nominally digital circuits, component parasitics, non-lumped component behaviour)

But don't worry, other people with lots of money to spend have noticed the same routing problems. So, if it is a soluble problem, new tools are just around the corner. But note that caveat!