cool book

I've operated at the other end of the spectrum -- startups, proof of concept designs, etc. I am often "The Engineering Department" for clients. And, almost always, the System/Product Architect, even if some work has to be delegated to others (e.g., mechanical designs, packaging, etc.). In that role, I can make the decisions as to how a solution should be implemented -- where to spend recurring and nonrecurring dollars (and time).

I find this exciting as it lets me explore lots of different application domains and tackle a wide range of problems and products in novel (as in "new") ways.

How would you design a device to tell you if the mailman has come? (note, I didn't ask you to tell me if you *had* mail delivered) Or, remind you that you haven't yet put your trash out at the curb for pickup -- and, the "garbage truck" will be at your house in 3.5 minutes (because it was just seen at a neighbor's house and past observations indicate that it will arrive at your house in 3.5 - 4 minutes)? Or, that the oranges have to be harvested in the next few days? Or, the ground beneath them soaked with water to protect against the predicted hard freeze, later tonight?

This is *infinitely* more intellectually challenging than designing version N+1 of some product which, itself, is a

My exposure to drafting, woodshop and metalshop was limited to junior high school (7&8th grades). In high school, "shop" (of any kind) was too much of a distraction from the courses more likely to contribute to college.

OTOH, having had some (limited) prior experience meant I had an appreciation for industrial processes and the disciplines they imposed. E.g., knowing that you need to be able to make a *second* one of anything that you've made (and, thus, can't just "wing it")

I try to design products that can diagnose their own faults. And, misapplications (e.g., when a user/installer may have done something incorrectly that affects functionality). This enhances availability and maintenance, after the sale as many products can't be placed in the back seat and driven to a repair depot (or "returned to the store").

Sadly, this "tradition" seems to have disappeared. Even as devices have more capabilities to convey information to their users (instead of having to rely on light flashes and beep codes).

I was interested in computer graphics early in my career -- when designing hardware of that type was interesting (before you could buy hardware/software to do it for you). There, relying on knowledge of the hardware you're designing to exploit efficiencies that generic algorithms would ignore. (e.g., if multiple pels can be accessed in a single memory reference, then you want to update ALL of them in that same reference and not require up to a reference-per-pel -- think: drawing horizontal/vertical lines and other non-degenerate cases)

It was fun because you could *see* your results and directly compare performance of different design implementations.

There's an outfit out on Trash Island in Puget Sound that schedules all the rail freight in the country and manages about 1/3 of the harbors.

I'm a practicing procrastinator - to that end the qualities of repeatability, reliability, and robustness, are usual sorts pragma of quality.

The diagnosibility of systems is a key sort of thing, it's agreeable the diagnosibility and the debug-ability.

I think that waterfall and design-build are better sorts of accounts of "defining spec" for "meeting spec" than other often-found organizational and management techniques in software development, which suffer a sort of lowest-common- denominator type problem. I'm not saying I don't trust business, just they're not reliable subject matter experts, and usually enough more the "tradesman" than "craftsman".

There's a great account for modularity and standards - it's the usual sort of account of mass production and interchangeable parts.

There is a real upside to writing beautiful code, or drawing beautiful schematics. The beautification process is its own sort of design review, another chance to look it over and think about it, and improve it or spot bugs.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

I always want to "move on" -- to learn something new. So, don't want to have to remember how I did something or be called back to *fix* something. (While I pledge lifetime bug fixes, I make NO commitment to enhancements, modifications and follow-on projects)

When your devices are physically large and capital intensive, you can't tell the customer to ship it in for service. Or, shut down production until you can ship a technician out to diagnose the problem.

So, the device has to be able to tell the user what *it* thinks is wrong -- in enough detail that they (or a factory rep) can prescribe a remedy.

This is particularly challenging when the device has continuous run time ("reboot" isn't a practical option) or considerable state ("reset" can represent a huge step backwards in terms of usability).

Most of the "fad-ish" development paradigms arise out of a need to address stakeholders who don't know (or can't express) their requirements. "Show me something and I will tell you what I *don't* want!" That does nothing to improve the quality of the codebase; rather, it is just another way of accommodating Manglement's risk aversion.

In practical terms, it is highly unlikely that the developer/team will be able to identify EVERYTHING that was incorrectly assumed when they undertook the "failed attempt". So, there is high risk of bad assumptions propagating through subsequent iterations of the design cycle. (you're unlikely to "start from scratch" each time you are told that something "isn't what was wanted")

If, instead, you insist on investing the time in the development of a specification BEFORE you start the actual product development, it forces you to think about the product that you are developing, instead of some vague notion of what it might (or, might NOT!) be. This also lets you begin work on test criteria, test fixtures, documentation, sales material, etc.

I worked for a firm that tried to take that approach to software development. We had "standard product" -- which was a catalog of existing, tested modules that could be redeployed to new projects. And, augmented with specific additions to "fit" the new goal.

The problem is, most standard product needs to be tweaked (often due to resource constraints) for new applications. This often led to a false sense of confidence in those tweaks because "it USED to work and I just made a TINY change..."

Should the math library support 754? ALL of it? If so, will the developer be prepared to address NaNs? Underflow/overflow? Denormalized numbers? If not, why include those capabilities in the library/subsystem? Can those conditions exist? If so, then how ELSE will we address them?

The capabilities of modern hardware allow you to ignore the false economies of "penny pinching" and concentrate on designing more robust products. Do you know if your memory subsystem is reliable? How do you address detected flaws? How do you alert the user and what remedies can you suggest? Can you upgrade parts of the system (hardware/software) without requiring a reboot/reset? Will the new components be able to interpret data created under the old?

When gigabucks are involved, they buy a lot of spares.

Envison 200%.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

Some of our military customers use the equation

spares = 1 + sqrt(units in field)

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

This rather misses the point. Microprocessors manipulate numerical data, and that data controls their peripherals which can control kilovolts and amps, and shift pulses by picoseconds (in places where this matters).

Shiftng a pulse by a picosecond might involve changing a gap by a 0.3 micron, or changing air pressure to change the permeability across the gap (and the speed of light) over a larger gap.

We once received the "schematics" for the SPARC processor our parent company was producing (under strict NDA, as this was shiny-new), so we could simulate it along with our design. I had a peek - they were incomprehensible. Clearly generated mechanically from some HDL compiler output. A simple netlist would have been more efficient, as that was all we really needed.

Fujitsu?

It's hard to "visualize" things from a netlist.

OTOH, if all of the "components" are depicted as rectangles, THAT doesn't add much value, either!

I worked on a 600-pin tester. Each of the "logic boards" were 18x72", wire-wrapped with large copper bus bars running the length to distribute the various power supplies across the panel. Endless arrays of DIPs (this was the 70's) packed side-to-side over the entire surface. The pin drivers were PCBs owing to the amount of analog circuitry on each, much smaller, but far more numerous.

The schematics for the logic boards were in the form of 11x17" drawings in 11x17" binders. At times, nothing more than two chips on a sheet with everything coming onto the page from elsewhere and going off the page to some equally distant destination. You spent all of your time flipping pages to trace the origins of signals as they passed through the devices scattered on those pages! Horribly inefficient.

The CPU was considerably better presented as many of its "components" were gates, terminations, connectors, etc. So, groups of components could be colocated to resemble some sort of functionality (e.g., this is the PC, this is the MAR, here is the PSW, etc.) But, still an exercise in flipping pages.

OTOH, nowadays, we have single chips that don't fit on a single page...

Oh. That's not the way we do it.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

IBM used to draw their CPU schematics on a line printer. That was the precursor to Ascii Art, I guess.

We print ours on a laser printer, on B-size (11x17") paper. That's really nice. Various boards run from one sheet up to maybe 30.

I'm doing a design and PCB layout myself now, 1 sheet schematic and a

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

Pin drivers can still be fun.

Good net names help a lot. If our net name is

DACDAT_F

we know it comes from the FPGA so we don't need to hunt down the other end.

I don't miss TTL in sockets, with wire-wrap connections, one little bit.

I once wrote a Basic program that inputted a netlist (on punched cards) and outputted a paper tape to a giant wire-wrap machine. That involved the unsolvable "traveling salesman" len min thing.

Ugh.

Amp's Termi-Point was even worse.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

Me neither. But it is a remarkably subtle adjustment.

Avondale Shipyards used to design ship hulls with 1:1 drawings. The drafting rooms were huge and engineers walked on the drawings in their socks.

They had little robot thing that walked the lines and controlled a flame cutter a mile away that cut hull sections out of steel plate.

I think some airplane makers did 1:1 drawings too.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

Airplanes seemed mostly 12 sections nose to tail or fore to aft, the wings being symmetrical and mirror images of each other L/R, the miles of wiring diagrams were mostly logical, while software units are their own sorts packages.

Parts and assemblies, parts and carts, jigs and the bone, in some worlds anything that's not a tool or material is a flange or a jig.

Parts and assemblies are parts and assemblies are parts and assemblies, ....

It's similar sometimes with buildings, "there's 12 systems".

Of course most people's first experience with assembling airplanes is plastic models or after model rockets, where an important first lesson is "don't sniff the glue".

When I was doing customs, we would typically print the layers on a large-format plotter on E-size (~3x4') paper. But, mostly as "wall art". Eventually, this was discouraged as it leaked information -- you knew who was working on custom silicon and could get a general idea of the functionality they were trying to embed by an overall "impression" from the layouts. (e.g., memory, register files, and other repetitive structures)

I think if a piece of software could be rendered, in its entirety, pictorially, certain types of bugs would be more evident. It's amazing how much better one can grok a design when you can see it in its entirety instead of through a small peephole.

Funny, all these posts are entirely plain text, ....

Making for quick graphical checks and the side-by-side and usual accounts of the graphical as representing both the logical and the physical, is of a usual account of human interface design, while though somehow it's supposed to be explainable in five minutes to a five-year-old if it's actually "understood".

Often called the flowgraph, we all know that a usual model of operation of usual procedural or functional routine vis-a-vis signal processors or the more the real-time sort, has a "natural" graphical depiction.

(It's much like the fluid models of current in electricity and liquids, those looking the same, until it's introduced that skin effect and core effect are opposites.)

The component-based drag-and-drop one-from-column-A one-from column-B insert-tab-A-into-slot-B the "rapid application development" and "dynamic prototyping" was around since the '90's or so.

These days the "shapes" of the models or after schema the user-defined-types or schema-defined-types properly, there's much made of "schema" what makes for the logical sort of account of bounaries and interfaces. Often enough "the interfaces" is whatever the logical and physical interfaces are.

Basically some people's screen is the size of a phone, and other people's screen is the size of a monitor, then furthermore, some people tend to horizontal aspect ratio for side by side, while others the vertical monitors for the code and the pages.

"API" is a term I learned in 1994 sitting at "The Email Assocation".

It's amazing how light itself actually makes camera obscura, and the entire scene goes through any pinhole, if inverted.

You need a means of representing the "structure" of an algorithm (mechanism) devoid of all of the detail that obfuscates that.

E.g., when I design a DFA or a Petri net or any other graphical design aid, I can "defocus" my vision and look for aberrations between one section and another section -- as there is usually a symmetry in how different aspects/paths are implemented.

If I see something extra or missing, in one place vs. another, I can explore in greater detail to understand why that difference exists and if it *should*.

I think that only really works well for graphical interfaces where controls/widgets have well-defined behaviors and just need to be "wired" to the application -- with small bits of code. Similar to basic electronic components whose behaviors can easily be generalized for the majority of applications.

Yup.

I don't think we were meant to understand it. I suspect we only got "schematics" because that's what a well-meaning, but non-technical, manager asked for on our behalf - a netlist would have done the job. Our DA team had to write a tool to translate the schmatics to a netlist for our mainframe-based simulator anyway. All bespoke at this time, of course, 30+ years ago.

Not sure how much use we made of it after all that. We had parameters for the primitives used, as we were designing our own ASICs using the same process, but without placement and routing any timing simulation would only be approximate. Maybe we just wanted functional simulation - my biggest part in it was reading in the QIC-150 tape that it arrived on.