Feedback IC design isn't software design

To the Editor:
I'd like to comment on Mark Vancura's "DSM Needs Rich Infrastructure" in the January issue [p. 14]. I feel strongly that though infrastructure is very important for designing deep-submicron ICs, Mark is totally off the point.

He first compares IC design with software design. In software, though, if a compiler is available, a designer can use the same code for both the original IBM PC and today's 300-MHz Pentium II PC. The difference will be in the speed of the CPUs.

A software engineer doesn't not need to worry when her code is executed by the CPU or what other code written by other people will be doing. Also, it's OK for software engineers to keep most of the code idle at any time. Furthermore, I wonder how many will write their code worrying if the subroutines they call will reside in cache or not.

IC design is very different. The beauty is in the balancing. An IC designer should keep all the hardware components busy fetching and cranking out data. As technology, density, speed, and pin count improve, IC designers can choose to put the same design in the new technology to gain a linear improvement in performance or they can re-architect the design to gain an exponential performance improvement.

If software is to be compared to hardware, Mark should first check how much improvement we have seen in parallel programming. I bet a large program will need lots of rewriting if the number of CPUs goes from 1 to 10, to 100, and to 1,000, if it can be done at all.

Mark makes a good point about the locality of software being 1D and standard-cell placement being 2D. More research and development is needed in this area for today's engineers to design meaningful circuits for million-gate ASICs.

Name witheld on request

Mark Vancura replies:
I appreciate the writer's comments. I think I understand the criticism about the uniprocessor (or von Neumann) model for computing and how it differs from the concurrent activity of many machines on an IC.

Yes, a lot of code is idle, but it is also relying on the operating system to keep the most active code in the cache. And designers of large, complex, high-performance software, such as some of our EDA tools, do in fact worry about whether the right code will be kept in the cache. If it isn't, then, for example, the simulation will thrash and take 10 times as long to run.

The way they can ensure that the right code is in the cache is by managing the modularity of their programs--that is, the hierarchy of their designs--and by taking advantage of the software design infrastructure in the form of the operating system. As the writer notes, the same source code can run on an 8086 and a Pentium II, and that's true largely because modularity solves the locality problem and because the code relies on the software design infrastructure.

In contrast, a design that has been reused as often as the Intel 8051, one of the most popular "core" designs, requires new, interactive synthesis; new, interactive floorplanning; and new, interactive layout in each technology and library, because the 2D information hasn't been captured in a portable manner.

The observation that software hasn't been very portable from uniprocessor to multiprocessor architectures is accurate. We can speculate together that it is because processing parallelism is rarely captured in a uniprocessor program and because it can't be easily and automatically extracted by a compiler. These are analogous points to those I have made about 2D information in IC capture: It is not captured and hard to compute.

The final comment suggests that though we may misunderstand each other at times, when we are sure we are talking about the same thing, we actually agree.

ASIC benchmark inconsistencies

To the Editor:
There are some inconsistencies in your high-speed ASIC benchmark report in the February issue [p. 48]. The total power column in the Benchmark Circuit 1 table bears no relation to the internal power consumption column in the ASIC Product Information table. In the latter table, for example, NEC's spec is roughly a third of Samsung's, yet in the former, NEC's total power is about 60 times lower.

Nate Goldshlag
Development engineer
ICD Division
Teradyne, Inc.
Boston, Mass.

Tets Maniwa replies:
I am sorry that we can't always provide accurate information in our Focus Reports. One of the problems is that all of the vendors don't fill out the table completely.

Here, NEC didn't supply power values for any individual net, and its total power number didn't account for the 50-pF load. The latter is true of all the other vendors with small power numbers, since the power dissipated in a 50-pF load is about 25 mW. I estimate about 25 gate equivalents in the circuit, ignoring the power for the fanout and the buffer, so the circuit uses gate power (µW) X 2,500, or about 0.75 mW for NEC. The detailed numbers are in the magazine archive section on our Web site: www.isdmag.com/EEdesign/Focus-Report9802.html.

In the future, we won't include any entries in our Focus Report tables for which the vendor doesn't supply all the information in appropriate form.

To voice an opinion on this or any Integrated System Design article, please email your message to miker@isdmag.com.

integrated system design  June 1998