Scope: IEDM, software-debugging via hardware

Scope previews the International Electron Devices Meeting, ponders why hardware designers now have to worry about software debugging, and looks at a page from EDN 50 years ago.

Edited by Ron Wilson -- EDN, 10/25/2007

Looking Ahead: To the International Electron Devices Meeting

For more than half a century, the place to find out about the next generation of electronic-circuit elements, from the FET to the latest in quantum-dot technology or alternative nonvolatile memory, has been IEDM (International Electron Devices Meeting). This year’s edition, from Dec 10 through 12 in Washington, will headline an in-depth discussion of high-k/metal-gate transistors for 45-nm processes, including Intel’s first detailed public description of its apparently industry-leading process. TSMC (Taiwan Semiconductor Manufacturing Co) will counter with a description of its 32-nm CMOS-foundry process, which includes the first 2-Mbit SRAM test chip. And STMicroelectronics will describe a process that allows local use of fully depleted silicon-on-insulator technology within a bulk-CMOS die. In keeping with the growing concern over low power and the environment, a novel session on emerging technologies will feature energy-harvesting devices. The conference is an invaluable window into the near future of electronics.

A super-high-speed memory device, which responds in a hundred-millionth of a second, utilizes a miniature printed circuit of metallic lead at temperatures close to absolute zero (–459.7F). International Business Machines developed the unit based on the unusual properties of special superconducting materials. Even after developers remove the energy source, current continues to flow in the circuit without diminution. The device requires only one-third the current needed to drive conventional ferrite memory units, while providing an increase in speed of about 100 times.

—Electrical Design News, October 1957

Before SOCs (systems on chips), software was not a hardware engineer’s problem. Then, along came chips with microprocessors on them, and it was suddenly hardware engineering’s responsibility to make sure that code executed on the silicon. Making sure the code was correct to begin with was still somebody else’s problem. But now, with the differentiation in end systems increasingly coming from—often hardware-dependent—software, both teams share the responsibility for getting the code right. We are seeing rapid development in hardware features that assist in software debugging, from debugging engines embedded in processor cores to specialized logic analyzers within the SOCs.