// Internet Duct Tape

Quotations from The Soul of a New Machine by Tracy Kidder (1978)

Posted in Book Reviews, Hardware Engineering, Technology by engtech on September 04, 2007

I’m going to celebrate Labour Day with the only book I’ve ever read that captured what it’s like to work at building integrated circuits. The Soul of a New Machine is a Pulitzer Prize winning book written in 1978 by a reporter named Tracy Kidder. Hat tip to Scott Rosenberg, or rather to James Fallows, for turning me on to this book by comparing it to Dreaming in Code. If you’ve read the book, you’ll probably find this interview with Wired (2000) interesting, as it catches up with the old team.

soul of a new machine

Rather than pontificate on what the book meant to me, I’m going to cut and paste some quotes from another reviewer on Amazon.

Review by B. Marold (Bethlehem, PA United States)

When it was first published, the book was a narrative of what was then `modern’ technology, where the central processing units (CPU) or `brains’ of commercial minicomputers and mainframe computers were built up on large circuit boards from individual, specialized integrated circuit chips, with each chip integrating dozens or hundreds of discrete components. This compares to today’s microcomputers where the entire CPU is placed on a single chip incorporating tens of thousands of discrete functions, all taking up no more room than the average credit card. Now, the book is more a history of how this technology was developed, and yet its picture of how people work in teams developing technological projects will probably never go out of date.

The irony of this book is that the computer being developed by the team described in this book, a 32 bit Eclipse computer developed by the Data General corporation, a competitor to the larger and very successful Digital Computer Corporation (Digital), did not really achieve any major breakthrough in technology. While it was intended to compete with a new generation of Digital VAX machines, it ended up being just barely faster than VAX’s in a few special tasks. In fact, in a conversation I once had with some Digital engineers, they said that when they went head to head with Data General in bidding for a computer sale, the only thing they had to do was bring out Kidder’s book to demonstrate that the Data General box was yesterday’s news. Data General may have had the last laugh, as ailing Digital was bought out by Compaq, which has since merged with H-P, further submerging the once great Digital presence in the commercial computer world. Meanwhile, Data General is still around, albeit not the presence it once had when the `minicomputer’ was the great alternative to the IBM monoliths in the glass houses.

Favorite Quotations from The Soul of a New Machine

Computer were relatively scare, and they were large and very expensive. Typically, one big machine served an entire organization. Often it lay behind a plate glass window, people in white gowns attending it, and those who wished to use it did so through intermediaries. Users were like supplicants. The process could be annoying. P14

A company was more likely to asphyxiate on its own success. Demand for its products would be soaring, and the owners would be drawing up optimistic five-year plans, when all of a sudden something would go wrong with their system of production. They wouldn’t be able to produce the machines that they had promised to deliver. Lawsuits might follow. P33

A heroic metaphor for success in the computer business: “The major thing is avoiding the big mistake. It’s like downhill ski racing: Can you stay right on that edge beside disaster?” P35

[Seymour Cray and Co.] had come to build what are generally acknowledged to be the fastest computers in the world, he quintessential number-crunchers. Cray was a legend in computers, and in the movie Cray said that he liked to hire inexperienced engineers right out of school, because they do not usually know what’s supposed to be impossible. P77

[On joining a high tech company] Going to work for the Eclipse Group could be a rough way to start out in your profession. You set out for your first real job with all the loneliness and fear that attend new beginnings, drive east from Purdue or Northwestern or Wisconsin, up from Missouri or west from MIT, and before you’ve learned to find your way to work without a road map, you’re sitting in a tiny cubicle or, even worse, in an office like the one dubbed the Micropit, along with three other new recruits, your knees practically touching theirs; and though lacking all privacy and quiet, though it’s a job you’ve never really done before, you are told that you have almost no time at all in which to master a virtual encyclopedia of technical detail and to start producing curcial pieces of a crucial new machine. And you want to make a good impression. So you don’t have any time to meet women, to help your wife buy furniture for your apartment, or to explore the unfamiliar countryside. You work. You’re told, “Don’t even mention the name Eagle outside the group.” “Don’t talk outside the group,” you’re told. You’re working at a place that looks like something psychologists build for testing the fortitude of small animals, and your boss won’t even say hello to you. P79

Wallach had now spent more than a decade working on computing equipment. He’d had a hand in the design of five computers — all good designs, in his opinion. He had worked long hours on all of them. He had put himself into those creatures of metal and silicon. And he had seen only one of them come to functional life, and in that case the customer had decided not to buy the machine. P93

That was what made it fun; he could actually touch the machine and make it obey him. “I’d run a little program and when it worked, I’d get a little high, and then I’d do another. It was neat. I loved writing programs. I could control the machine. I could make it express my own thoughts. It was an expansion of the mind to have a computer.” — Alsing, P126

There’s no such thing as a perfect design. Most experienced computer engineers I talked to agreed that absorbing this simple lesson constitutes the first step in learning how to get machines out the door. Often, they said, it is the most talented engineers who have the hardest time learning when to stop striving for perfection. West was the voice from the cave, supplying that information: “Ok. It’s right. Ship it.” P158

He would bind his team with mutual trust, he had decided. When a person signed up to do a job for him, he would in turn trust that person to accomplish it; he wouldn’t break it down into little pieces and make the task small, easy and dull. P173

“With Tom, it’s the last two percent that counts. What I now call ‘the ability to ship product’ — to get it out the door.” — Rasala P188

Above all, Rasala wanted around him engineers who took an interest in the entire computer, not just in the parts that they had designed. He said that was what was needed to get Eagle out the door on time. P199

The very word, engineer, dulled the spirit. It was something your father might be interested in.

Typically, a machine gets built and sent to market and in its first year out in public a number of small, and sometimes large, defects in its design crop up and get repaired. As the years go by, the number of bugs declines, but although no flaw in a computer’s design might appear for years, defects would probably remain in it– ones so small and occurring only under such peculiar circumstances that they might never show up before the machine became obsolete or simply stopped functioning because of dust in its chips.

“The way to stay on schedule is to make another one.” — Rasala P246

“It doesn’t matter how hard you work on something. What counts is finishing it and having it work.” — Holberger P252

[Small companies would] announce a new product and then for one reason or another they wouldn’t be able to produce it in sufficient quantities to meet their obligations. They’d asphyxiate on their own success. But a small company had to court disaster. It had to grow like a weed just to survive. P312

Almost every commentator has assured the public that the computer is bringing on a revolution. By the 1970s it should have been clear that revolution was the wrong word. And it should not have been surprising to anyone that in many cases the technology had served as a propr to the status quo. P317

Most computer companies have boasted that they aren’t just selling machines, they’re selling productivity. But that clearly isn’t always true. Sometimes they’re selling paper-producers that require new legions of workers to push that paper around.

But maybe a time would come when the computer would run every aspect of a person’s life. “Then we get tired of it. We start growing plants or something. Maybe slowly we will turn around and go away from it. If computers take something away from us, we’ll take it back. Probably a lot of people will get screwed before that happens.” — Holland P325

“I’ll stop asking questions and let you go home. You look tired.”
“It’s a long-term tiredness,” said Rasala.
“Going home won’t solve it,” said Blau. P334

“That’s the bear trap, the greatest vice. Your job. You can justify just about any behavior with it. Maybe that’s why you do it, so you don’t have to deal with all those other problems.” — West P367

Creating HTML documentation of Verilog code

Posted in Asides, Hardware Engineering, Technology, Writing Better Documentation by engtech on July 05, 2006

v2html is a perl script for generating beautified HTML representation of a Verilog design. The outputted HTML can be used to navigate signals throughout the source code (although there are many other commerical tools that can do the same thing now).

The parser can be used as a stand-alone perl module, and could be a useful tool for building custom scripts. Not to be confused with Verilog-Perl, another Verilog parser that supports SystemVerilog.

>> v2html – Rough Verilog Parser

Functional Verification Articles at cdnusers.org

The Cadence User Group has a collection of verification articles, how-to’s and technical papers developed by Cadence.

Functional Verification

Comments Off on Functional Verification Articles at cdnusers.org

Recommended Hardware Verification Books

Yet another page of recommended books. What stood out for me:

  • Debugging by David J. Agans (actually available at the local library for a change)
  • Comprehensive Functional Verification by Bruce Wile

Book Tips

Comments Off on Recommended Hardware Verification Books

Verilog-Perl – Perl modules for interacting with Verilog code

Posted in Hardware Engineering, Links, Perl, Technology by engtech on May 23, 2006

 Verilog-Perl is a collection of perl modules for interacting with Verilog code. I haven't given it much of a look as of yet, but if "vpm" and "vppp" work as the synopsis advertises then it may have some utility. Especially if it can already correctly parse SystemVerilog.

  • Verilog::Getopt parses command line options similar to C++ and Vcs.
  • Verilog::Language knows the language keywords and parses numbers.
  • Verilog::Netlist builds netlists out of Verilog files. This allows easy scripts to determine things such as the hiearchy of modules.
  • Verilog::Parser invokes callbacks for language tokens.
  • Verilog::Preproc preprocesses the language, and allows reading post-processed files right from Perl without temporary files.
  • Vpm preprocesses warnings and assertions for any simulator.
  • vppp preprocesses the complete Verilog 2001 and SystemVerilog language.
  • Vrename renames and cross-refrences Verilog symbols.

Verilog-Perl

Engineering Notebook Guidelines for working with patents

These guidelines are intended if you are working with patents. It may be overkill for general day-to-day usage, but it some of the guidelines could be kept.

– Bound/stitched binding notebook.
– Permanent ink.
– Each new page should have title, project number and book number.
– All data recorded directly into the notebook. Use elaborate data. Strike-out, do not erase/white-out.
– Sign and date all entries. Get witnesses.
– Use both sides of a page and "X"/crosshatch unused space (with initial & data).
– Keep lab book in safe place.

Engineering Notebook

Comments Off on Engineering Notebook Guidelines for working with patents

interfacebus.com – Engineering Design Information

Posted in Hardware Engineering, Links, Technology by engtech on May 18, 2006

interfacebus.com looks like a really good resource for reading up at a high level about information that may be of interest as an engineering professional, especially to become from familiar with new buses and the various components that connect to it at a systems level (as well as specific vendors in that space).

An Indexed listing of Electronic Engineering Web Sites of Component and OEM Equipment Manufactures:
Analog and Digital Integrated Circuits [ICs]; Memory, Processor and Programmable Logic IC’s, Bus Interface IC’s,
Passive, and Mechanical components; Resistors, Capacitors, Inductors and Sensors, EDA Software vendors,
Electrical Engineering Standards and Specifications, On-Line Publications, Computers, Power Supplies,
Electronic Enclosures, Chassis, Racks, Backplanes, Mother Boards, and Test Equipment manufacturers.
Providing detailed electronic design information regarding Interface, Computer, Cable, Processor and Embedded Buses.

Leroys Engineering Web Site, interfacebus.com; Hardware Manufacturers, Computer Bus Descriptions, Engineering Design Information

Comments Off on interfacebus.com – Engineering Design Information

Verilab – verification white paper downloads

Posted in Hardware Engineering, Links, Technology by engtech on May 16, 2006

Verilab has several interesting verification white papers available for download.
Verilab – downloads

How to adopt assertion-based verification (ABV) into standard design flows

Posted in Hardware Engineering, Links, Technology by engtech on May 15, 2006

High level paper written by Chris Komar of Cadence discussing Assertion-Based Verification do's and don'ts.

Do

  • Focus on a productive subset of the assertion language instead of the entire assertion language.
  • Consider using a library that contains common components and design constructs that make it easy to get started with ABV.
  • Consider the big picture and leverage assertions across the entire flow.
  • Consider reuse for common interfaces within your design with components that are parameterizable.
  • In simulation, complement your assertions with coverage. Assertions describe the functionality of the design not how the stimulus is stressing the design.

Don't

  • Spend much time worrying about which assertion language since they offer the same functionality only with different syntax.
  • Corner yourself into one assertion language because assertions will come from multiple places that use multiple assertion languages.
  • Write assertions for all aspects of your design. Focus on areas that are considered higher risk.
  • Be afraid to simplify by using simple VHDL or Verilog/SV to generate easier and more familiar conditions to check.
  • Wait to introduce assertions. Designers should write white-box assertions in their code while verification engineers should write block level assertions and end-to-end transactors.

 Programmable Logic DesignLine | How to adopt assertion-based verification (ABV) into standard design flows

Comments Off on How to adopt assertion-based verification (ABV) into standard design flows

Elements of Verification from SOCcentral

Posted in Hardware Engineering, Links, Technology by engtech on May 14, 2006

This is a pretty decent high-level document describing the modern (2005/03) methods of verification. It would probably be good for introducing someone to verification, although there isn’t enough depth to give a good feel for what everything is.

It describes:

  • Functional verification
  • Conventional Verification (BFM based, directed testing)
  • Hardware verification language (HVL) based verification (constrained random, coverage driven)
  • VIP-based verification (treating verification components as reusable IP)
  • Layered, object-oriented verification methodology for next generation SoCs (getting into reuse methodologies like eRM/RVM/VMM/AVM, although none are specifically mentioned)
  • Assertion-based verification (design for verification)
  • Formal verification (equivalency checking, formal RTL verification)

What is left out:

  • Gate-level verification
  • Wafer testing
  • Chip bring-up verification
  • Manufacturing verification

SOCcentral: Elements of Verification (SOCcentral 12420)

Comments Off on Elements of Verification from SOCcentral

Cool Verification – blog written by a verification engineer.

Posted in Hardware Engineering, Links, Technology by engtech on May 11, 2006

Cool Verification is the blog of JL Gray. He is an Associate Principle with Verilab, Inc. (www.verilab.com), based in Austin, Texas. JL joined Verilab in 2004 and has been traveling around the US and Europe working with clients to develop advanced verification environments using Specman, SystemC, C++, and Vera. He seems to cover a lot of subjects that I personally find interesting, so I figured a link was in order.
 

Comments Off on Cool Verification – blog written by a verification engineer.

SystemVerilog reference verification methodology // EETimes.com

Posted in Hardware Engineering, Links, Technology by engtech on May 07, 2006

This article gives an overview of the Verification Methodology Manual (VMM) developed by Synopsys and ARM. I have the book, it is quite good. They discuss the various layers of a verification environment

Test Testcase
Scenario Generator; Functional Coverage
Functional Driver Self-Check Monitor
Command Checker Checker
Signal DUT

The advantage to the layered approaches is that the interfaces between layers are well defined and the components in a layer can be swapped and replaced without affecting the other layers. Only the test layer needs to be modified to generate a new test. The principal idea behind re-usability is having well-defined interfaces so that components can be switched.

It discussions top-down versus bottom-up approaches. In a top-down approach verification engineers build testbench as a stand-alone self-checking environment. In a bottom-up approach design engineers build block-level pin/cycle-based test-harnesses and then work their way up to a transaction-based environment.

EETimes.com – SystemVerilog reference verification methodology: RTL

Comments Off on SystemVerilog reference verification methodology // EETimes.com

Bringing assertions into hardware-assisted verification

Posted in Hardware Engineering, Links, Technology by engtech on May 07, 2006

This is an article by Richard Newell and Rindert Schutten discussing Design-for-Verification (DFV) using assertions in SystemVerilog. The focus is on hardware acceleration flows and how to use assert/assume/cover in a synthesizable manner so that the hardware acceleration can function in near real-time. The idea is that there are signals feeding back from the synthesized assertions to the software simulator using SCE-MI.

They give these four guidelines when writing assertions to ensure that they are synthesizable:

Guideline 1: In assert statements, do not use a pass statement. Use only the else statement, since this indicates an error condition.

Guideline 2: Ignore assertion control statements when implementing the assertions in hardware unless false failures need to be suppressed.

Guideline 3: Do not implement cover statement accounting functions in hardware-assisted verification; rely on pure software simulation to get this important information for debugging purposes.

Guideline 4: In cover statements, use a pass statement only if it is expected to be executed a few times during the simulation.

They also recommend writing synthesizable transactors so that the bulk of the transactor is on the hardware accelerator.

EETimes.com – Bringing assertions into hardware-assisted verification

Comments Off on Bringing assertions into hardware-assisted verification

John Koza Has Built an Invention Machine

Posted in Hardware Engineering, Links, Technology by engtech on May 04, 2006

They’ve created an invention machine that uses artificial intelligence with genetic programming (algorithms that can mate and produce more successful offspring) to invent things. It actually owns patents that it has created. They’re using it to try and build a better US electoral system.

I’m very interested to see where this goes in the future. The potential to change the way the world works is enormous.

Over the past several decades, Koza has internalized that lesson as deeply as any computer scientist alive and, arguably, made more of the insight than any coder in history. Now 62 and an adjunct professor at Stanford University, Koza is the inventor of genetic programming, a revolutionary approach to artificial intelligence (AI) capable of solving complex engineering problems with virtually no human guidance. Koza’s 1,000 networked computers don’t just follow a preordained routine. They create, growing new and unexpected designs out of the most basic code. They are computers that innovate, that find solutions not only equal to but better than the best work of expert humans. His “invention machine,” as he likes to call it, has even earned a U.S. patent for developing a system to make factories more efficient, one of the first intellectual-property protections ever granted to a nonhuman designer.

John Koza Has Built an Invention Machine – Popular Science

Comments Off on John Koza Has Built an Invention Machine

Verilog HDL On-line Quick Reference, by Sutherland HDL, Inc., Copyright 1997

Posted in Hardware Engineering, Links, Technology by engtech on April 28, 2006

Comments Off on Verilog HDL On-line Quick Reference, by Sutherland HDL, Inc., Copyright 1997