Leibson's Law

I apologize for the sexism in the title of this blog entry, but the seed crystal for this essay is The Ballad of John Henry, who was a steel-drivin’ man. Here’s the beginning of the version I learned a few decades ago:

“When John Henry was a little bitty baby
No bigger than the palm of your hand
His daddy looked down at Johnnie and said
Johnnie’s going to be a steel drivin’ man
Lawd, Lawdy
Johnnie’s going to be a steel drivin’ man.”

The kernel of this essay’s been rattling around in my head since DAC ’07 held in San Diego last month. During DAC, I repeatedly heard a refrain, plaintively bleated by designers to one or more EDA vendors. That refrain goes something like this:

“I drive tools. Give me a tool that does what I want. Give me the tool that I want and I’ll learn to drive it.”

What deeply concerns me about this statement is that somehow, chip-level engineering seems to have become more like tool drivin’ and less like engineerin’, which is funny because the original “engineers” did little more than drive locomotives (and oil them, in hundreds of spots, frequently).

Design engineering’ is something else entirely, at least in my mind. It’s a highly creative activity. Tool use is definitely involved. Engineers sit at the apex of the tool-users pyramid. But I don’t think tool use alone can define real, competitive engineering. There’s a lot more thought, a lot more knowledge, and a lot more thinkin’ involved, at least to my way of thinking.

I fear there’s far more tool use than thinking going on these days in chip-level design. Far too many designs, at least the ones I see, look like computer-board architectures from the 1980s—major system blocks connected by one or two buses. The board-level architectures were built upon the foundations and limitations of pin-limited LSI chips and the coarse 10- or 15-mil trace-and-space routing geometries of fiberglass FR4 circuit boards. Those limitations coupled with the relatively slow clock rates of the day favored the use of a few multiplexed buses and they shaped system design at the board level. Chip-level design operates with a completely different set of limitations but far too many chip-level block diagrams I’ve seen appear to be based on the no-longer-applicable physical limitations of packaged chips and circuit boards rather than the greatly enhanced abilities of on-chip design.

For example, do the math on the routing ability into and out of a square millimeter of real estate on a 90nm ASIC or SOC. I assumed eight to ten routing layers and used the pitch geometries for the various layers as given by the ITRS 2006 supplemental report. I get a number that exceeds 100,000 potential routes into and out of each square millimeter on the chip (it’s nearly 200,000 for 65nm chips). That number magnitude doesn’t favor multiplexed bus architectures running at high clock rates. It favors multiple, wide interconnects running at greatly reduced clock rates. An architectural approach using many wide, point-to-point interconnections between on-chip blocks running at much lower toggle rates would cut power consumption, reduce crosstalk, and ease the design of interblock communications by eliminating communication-resource sharing and allocation. Yet I continue to see bus-centric designs because “that’s the way we’ve done it” for 35 years. The unwarranted assumptions buy chip-level system designers a bunch of unwanted and unneeded trouble.

The tool-drivin’ design engineer isn’t likely to get to a radically different, technology-appropriate system-level design simply by driving an EDA tool. The brain-drivin’ engineer might.