A Bit of Z80 History (2021)

In an unrelated Z80 testing situation, my son in college was asked to verify a gate-array implementation of a Z80 for a NASA project. He wrote an opcode-by-opcode comparison of a real Z80 and the DUT and stored internal state on both before and after. The DUT failed to set flags consistently on some opcodes! It was some gate-array implementation for custom hardware (a radar unit with a built-in FFT processor). He did some other projects, but still tells the story of getting a part stepped for NASA.

Anyway years later I'm gratified to see a short animation posted here on HN, of the Juno space probe flying by Jupiter. Some of his code (unrelated to testing) was flying on that!

The author's relationship with the machine reminds me of Scotty in Start Trek. In the age of "the cloud" that kind of engineering intimacy feels like something lost in days of yore.

“It was a beautiful machine, I loved it, and it broke every day.”

Lots of tiny scandals, in addition to the exotic 100MHz ECL logic!

> here were two red and two green lamps. These are a go-no/go set for parametric failures such as continuity and leakage, and a second pair of Red/Green lamps for functional failures.

Interesting idea to have separate parametric and functional test indicators. I've made a few custom production test setups in the past years (nothing as nearly as complicated as the one described here) and always went with the greatest simplicity possible - start button and a single red/green go/no go, exactly to avoid the kind of problem described later in the article.

I can see why they would do that though. When reviewing test runs, it's always the parametric tests that give the most false-positives. If a parametric test fails, the part functions as intended, but some measured parameters are outside of the designed range. Parametric failures are often not failures in the parts themselves, but failures in the test procedure (e.g. bad connections to test points due to dirt or worn out contacts in the fixture, etc.).

A separate indicator for parametric failure would give the operator an early indicator that excessive failures might be false positives and re-test the parts, or clean or exchange the test fixture.

Even today testers cost millions of dollars, chip designers spend ages optimising their test vectors to minimise how long each chip spends on that expensive tester (or testers, often you do die sort to weed obvious bad dies before packaging)