Feedback

A forum for readers to speak their mind on issues that are important to the design community

No free CPU

To the Editor:

Concerning your editorial about the Freedom CPU in the December issue ["Free the PC!" p. 6], I'd like to correct your description of one of the team members, Andrew Derrick Balsa. Balsa said that he built a microcomputer--not a microprocessor--when he was 15. He probably means, then, that he built a computer kit or an IBM clone. That's a very, very different task from designing and building a microprocessor.

I hope that none of your readers will join the project thinking they would be working with a genius who created his own microprocessor at the tender age of 15. I myself have read the project's Web page very carefully; the fact is, the team has no previous experience designing any integrated circuits--except for the gentleman who has EDA experience in FPGA placement and routing--let alone a microprocessor, which is one of the most complicated devices ever developed. Microprocessor design requires an extensive set of tasks (and I'm simplifying a little to keep the list short): architecture, microarchitecture, RTL/logic design, verification, VLSI circuit design, physical design, timing analysis, noise analysis, power rail analysis, packaging and thermal design, and fabrication. Such complex operations demand a very large investment in tools and experienced design engineers.

The team wants to extend the Linux/GNU software development model to hardware design and development, which I think won't work for a project of this magnitude. There's a big difference between a hacker tweaking the Linux kernel at home and design engineers doing design reviews to make sure that their unit meets timing. If not, they have to employ novel circuit techniques to shorten critical paths and verify that the logic performs correctly at the unit level and also at the full-chip level.

The Web site indicates that the team hasn't grown and that engineers with the skills that the project definitely requires won't volunteer their time--given that they're already overworked. In any case, if those engineers could put together a team to produce a "Pentium killer," they would form their own company and produce the processors for a profit (for instance, Transmeta in Santa Clara, Calif., which employs Linux creator Linus Torvalds as well as several other designers from projects like UltraSparc). For numerous reasons, thus, I think that the Pentium killer project--though certainly a noble idea--will never be completed.

Chris Gomez
Development engineer
Neucom Intelligent Systems
Gainesville, Fla.

Jonah McLeod replies:

Thank you for your well-thought-out response. I know the group of four is probably tilting at windmills, but what's interesting about their approach is the notion of collaborative design. If every engineer on the Web added something to the kernel of a design, would the result be something far greater than the sum total of all their contributions?

Marriage makes heavenly EDA

To the Editor:

After reading James Lee's "Linux Has What It Takes for EDA" [September, p. 60], I want to contribute a few of my own (and not my employer's) thoughts. Could you have a middle ground between NT and Linux, where NT handles the user interface aspects and Linux is the "batch engine" for time-consuming nongraphical tasks such as simulation and routing? I suggest that possibility because EDA providers probably don't want to support yet another graphical user interface. From personal experience (with Sunview and X Windows), user interfaces are an incredible time-sink in terms of development, maintenance, and support. With X Windows you have to deal with OS and compiler system differences, as well as quirks in X clients and tool kits. Issues also arise in maintaining and documenting interfaces written for X Windows versus Microsoft Windows.

However, if users can interface in NT and buy inexpensive licenses for Linux "batch engines" (which do the nongraphical crunching), then they have the best of both worlds. The EDA vendors are assured that people will still buy seats for their product, and they can make money off low-maintenance "accelerator" licenses for batch processing. Need to get more simulations done? Set up some cheap PCs running Linux and pay the EDA vendor a fee for each machine, then let them run night and day. Since that method involves nongraphical code, maintenance costs should be minimal, and people smart enough to link Linux with the network should require little hand-holding. Users would get more work done, and EDA vendors would earn a nice cash flow. Of course, such a scenario assumes modular code and an EDA vendor sophisticated enough to write "network-aware" software.

Bruce McKee
Senior project engineer
Innovative Dynamics, Inc.
Ithaca, N.Y.

James Lee replies:

First, the idea of batch versus interactive/GUI-based tools: Most people (including me) would agree with you that porting a tool without a GUI is easier; however, most modern EDA tools are tightly married to their GUIs, so the porting issue might not be so simple. Regarding your second suggestion, using Linux for batch, I definitely agree with you that any flavor of Unix, including Linux, is far superior to NT for batch runs.

If the EDA vendors port their tools to Linux, the Linux community will happily use it. The main issue is the port, independent of use, although I agree that Linux makes an excellent backroom batch server.

Your third comment was "low cost." Having worked with EDA vendors, I wouldn't expect any price breaks based on port. They might even try to charge you a premium for the new port.

In any case, whatever the use model, it's clear that Linux has the underpinnings to be an EDA OS, but the OS doesn't make EDA--the porting of the tools by the EDA vendors does. How do you make a vendor port your favorite tool? Easy--you and 100 friends from 100 companies place orders for the Linux port of your tool at full list price. Sorry, but EDA vendors tend to listen only to money.

The OS debate continues

To the Editor:

I've enjoyed your ongoing coverage of the Linux versus NT debate and would like to add my five cents. I've been working and playing with computers since 1977 (the days of CP/M) and have been working with Microsoft OSs since 1982. I've never liked them, but there was no alternative--any Unix was too expensive because it ran only on very expensive hardware.

I've been exploring Linux for almost three years now and making progress in learning it. Having gone through NT's teething stages, I found that Linux had far fewer of them. I've breathed easier ever since I switched my file server to Linux, since I didn't have to babysit it anymore. I use dual-boot Linux and NT on my workstations--I have no choice, since all my CAD software runs on NT. Believe me, the day I can get Linux replacements for them, NT is history.

Why Linux? A small example: Start formatting a floppy in NT and then try to do something else. No go. Now try the same in Linux. If not for the limitation of the floppy controller, Linux could format both floppies at once, as it can do with hard drives. Crash recovery in Linux takes only a fraction of the time that it takes me in NT (which I've been using since its 3.1 beta release). One more curious thing: Take NT with Word from Office 95, load a 50-Mbyte document containing many .bmp pictures, start your stopwatch, and then start document editing and count the seconds until you run out of all your resources. When I edit one of our manuals of that size, my NT with 128 Mbytes of RAM and 130 Mbytes of swap space runs out of memory in no time. I've concluded that NT doesn't know how to use its swap file. Linux, in contrast, uses its swap file very effectively, needing no more than 120 Mbytes. Unfortunately, I'm stuck until some company comes up a with word processor that will do a good job of translating Word documents.

Yes, I'm proud to admit that I'm a very strong Linux promoter.

Nick Torys
President
Cybertor Enterprises, Ltd.
Markham, Ont.

Cover your own code

To the Editor:

I'd like to express just a little concern about the idea that techniques such as code coverage "improve" the quality of a design ["HDL Verification Coverage," June, p. 46; "Streamlining HDL Code Coverage Analysis," December, p. 20].

I work in an industry (avionics) in which concerns regarding system, hardware, and software safety do (and should) dominate. I've watched the software industry really struggle to improve the quality and thus, hopefully, the safety of their systems. With every project, the time and effort required to produce software seems to rise dramatically. Unfortunately, so does the number of unresolved, or "open," problem reports.

I believe that the software community needs to step back and re-evaluate whether or not its process assurance techniques truly add to quality or safety. I'm convinced that it adopted code coverage out of a pure desire for some metric that would determine how thoroughly it tests its code. As a result, many in the industry have overstated the benefits of code coverage. Consider the simplest example: Say, a design really needs an OR gate but instead contains an AND gate. All of the tests would reveal that the AND gate was thoroughly tested. So we've caught nothing.

We in hardware must move very carefully in adopting anything that the software community says adds quality. Rather than suggesting we inherit their baggage, software designers must look more toward hardware design assurance techniques to determine quality. I see only one good outcome otherwise: If software techniques win, many more engineers will have jobs.

Steve Thompson
Senior staff engineer
Company withheld on request
Phoenix, Ariz.

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

integrated system design  February 1999