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

Is it worth the cost?

The same idea holds true today. The United States, after all, is the center of electronic design. Where are the majority of the EDA companies that expose engineers to the latest methodologies? The U.S. Where are the majority of the software vendors that expose engineers to the latest development tools? The U.S. Where are the significant hardware development companies that introduce engineers to the "real" system of silicon design? The U.S.

Granted, many significant companies exist in other parts of the world; I don't by any means want to take anything away from them. My point is that the employer who's trying to choose between accommodating experienced virtual development teams and hiring skilled immigrant workers should heed that age-old axiom: You get what you pay for. What's the real cost to a Silicon Valley company to mentor and train "low-cost" immigrant workers for two years before they can really be productive? As usual, the answer to seemingly easy questions are often intricate and complex. The real question here is how you can get the highest-quality product to market in the fastest time and at the lowest cost--not how you can fill up cubes in the engineering department with EE degrees who will tolerate 90-minute commutes on U.S. 101 and outrageous housing prices.

Why did Sun recently move 2,000 jobs to Boulder, Colo.? It realized that it needs to take the task to the resource--and Web-based project management technologies make the accommodation easy.

Dan Ganousis
President
Questmark Design Services
Boulder, Colo.

An H1B engineer speaks up

I've just read your July editorial. I am a "young, lower-paid foreign national," having H1B status at a company in Silicon Valley. I don't think I'm abused or low-paid, though--and at 31, I'm not all that young anyway.

I have a Ph.D. in electrical engineering and I work in the field of mixed-signal IC design. Before I came to the United States, I worked on mixed-signal high-speed and mobile communications, published some papers in IEEE journals, and presented papers at IEEE conferences on topics in my field.

Though I'm a member, I don't agree with the IEEE's opinion on H1B regulation. It could be that the United States is producing as many engineers as its high-tech industry requires. However, if they aren't willing to accept the pay and the work conditions, they're simply not available. Telecommuting would help things a little bit, but I'm skeptical about the possibility for the moment because the physical location of the job doesn't seem to be the whole problem.

I'm not that highly paid, considering the high cost of living in the Bay Area, but I like my job. If I can make it, others can, too. If a U.S. citizen can't live here, it could simply be because the person doesn't want to move or the company doesn't want to pay enough for the person to live in this area. Hence, regulating H1B immigration isn't good for the United States, and doing so fails to address the issues at hand.

H1B immigrants don't necessarily take jobs away from U.S. citizens. Rather, each H1B takes one high-tech job away from a U.S. citizen (if one even exists) who can't carry out the job properly under the given circumstances or who doesn't want to. Meanwhile, that H1B engineer creates jobs. For example, I'm the only H1B engineer among three chip designers in my company, which in turn provides about 40 jobs to U.S. citizens.

Potential abuses of the law could occur partly because of the temporary nature of H1B status and partly because the foreign engineer isn't acclimated--but that's no reason to limit H1B immigration. If H1B is bad just because the engineer may be abused, the United States should get rid of it, not limit it. Limiting it means that the government allows selected companies to abuse a limited number of foreign engineers.

For lawmakers to limit H1B, then, would just be a token gesture to be remembered in the next election. It's not good for the industry, and it actually blocks the many jobs that imported engineers create--so it's not good for the country, either. Instead, if abuse is a serious problem, the best thing for the government (or the IEEE) to do is to protect the H1B engineers in some way.

The claim that importing engineers lowers the average salary level is a bit more persuasive. However, that's representative of competition on which the capitalistic U.S. economy is based. If H1B were to allow an engineer to hop from one company to another, the salary problem could be easily solved. All the problems are caused not by the law itself, but rather by its restrictive and temporary nature.

In my case, the troubles that I had when I came to the United States stemmed mainly not from work, but from such headaches as ridiculously high car insurance and mortgage rates and the difficulty in getting a credit card because I haven't lived here long enough. In the United States, being a newcomer seems almost as bad as having a criminal record.

For me, the real issue is the effect such limited status has on H1B immigrants' personal lives. I can't bring my parents here until I obtain U.S. citizenship, for H4 visas (for families of H1B immigrants) are only valid for spouses and children. So my parents can visit me for a while, but not more than six months. I wish the INS would realize that though I'm a temporary worker, above all I'm a human being who wants to take care of and support my parents--right here where I'm working.

Name withheld on request

Grab your pens (or word processors) . . .

Thank you for your editorial raising the awareness of Senate bill 1723.

With 50,000 more high-tech immigrants allowed on top of the 65,000 every year, Silicon Valley will be choked, as many of them will work there. Rents will skyrocket (again) because corporations bringing in immigrants have to secure corporate apartments. I'm afraid that old workers like myself may be pushed out. Many of my old engineer friends have already been pushed out of the market--and out of being engineers.

Corporations contribute money to senators, but we have the vote. We engineers should organize a massive letter-writing campaign. Engineers and their families should write to their congressional representative and the White House. Engineering students should also join this campaign because they too will have to compete with those immigrants.

In order to mobilize opposition to SB 1723, every engineer should write to the editors of the other magazines he reads and ask them to create a forum for the issue. Every engineer who's aware of the bill should contact his colleagues and friends and ask them to join the fight.

Hiroshi Seto
Senior electrical engineer
Animatics Corp.
Santa Clara, Calif.

. . . Or stop worrying and keep up-to-date

I own a small consulting firm in the San Diego area that specializes in ASIC, FPGA, and board design. There's an enormous shortage of engineering workers, competent or incompetent, in my field of work. My organization can't meet the demand, and I can't hire enough qualified people to expand. To keep talented people, I'm forced to pay 24-year-olds a $100,000-plus salary. Anyone who argues that the world (let alone San Diego) is producing enough ASIC or FPGA designers that can do state-of-the-art, complex design is terminally confused and not connected to reality. Allowing more immigration isn't going to significantly hurt high-tech employment anywhere in the United States.

Dan Ganousis is welcome to find as many competent engineers doing plumbing in the backwoods as he can, but I bet I can count on one hand the number of qualified people he's going to find. As far as the IEEE is concerned, it's traditionally been a weak, virtually useless organization. Most of my friends describe it as a standing joke. I've never felt a compelling reason to join. Now the leadership is beginning to sound like a bunch of out-of-work union activists--in a field that's currently 100 percent employed at high pay. Please count me out of that demagoguery; it doesn't do the field of engineering any good.

Finally, a whole lot of older engineers can't do what's required in today's faster-moving design environment. In ASIC and FPGA design, for example, an engineer who hasn't learned Verilog or VHDL is almost useless. That type of job requires an engineer to relearn everything he knows every 18 months. It's very easy, thus, to fall off the high-tech train. I'm annoyed at older engineers that do fall off, get bruised, and then whine about it. We're no longer in a DOD-intense industry where the old saying, Nothing working, never, with no schedule applies.

Name withheld on request

Aren't we forgetting something?

I'm a little disconcerted by the Unix versus NT debate that has recently raged in the press, for it completely misses the point. Having just gone through a very large 0.25-µm ASIC development project that utilized both Unix and NT, we found that the OS was completely irrelevant. The critical issues were always with vendor libraries, CAE tools (they're all bug-ridden to the max), and the lack of a reliable way to relate physical design information back into logic synthesis.

One of the most important issues facing our industry is the quality of the tools available. The mind-set of "ship it now and patch it" later wreaks havoc on anyone trying to do real work.

Furthermore, when I hear EEs complaining about the lack of source code for the kernel, I just want to cringe. The last thing I want any of my engineers doing is tweaking an OS.

Apparently a large number of EEs are completely unfamiliar with the NT design environment and have made assumptions about what is and isn't available. To set the record straight, Perl, awk, grep, and other useful Unix utilities are available for NT--and they work just fine. In addition, NT's version control and source code editors tend to be vastly superior. Though those tools aren't free of charge, the cost isn't significant.

As someone who controls the purse strings of an engineering department, I'd switch to Linux or what ever OS it took to get tools that work. Unfortunately, that's not the issue or the solution. I'd greatly appreciate a dialogue on how we can move our industry forward with quality tools and interface standards so that our engineers can do design work rather than tweak OSs and write Perl scripts.

Michael West
Vice president of technology
Pixelworks, Inc.
Tualatin, Ore.

Scripting and the kernel

The Linux versus NT debate might be more informative and responsible if it were a real review, rather than the obviously biased opinions of a bunch of engineers who seemingly have never used NT. Here are examples of some claims:

Free on-line technical support--Linux has it, Microsoft doesn't.

Usenet contains as many, if not more, Microsoft and Windows newsgroups than Linux newsgroups, including a bunch actually hosted by Microsoft. Given that Microsoft software runs 80 to 90 percent of the world's computers, it seems reasonable that there's more freely available help out there.

Kernel source code--Linux has it, Microsoft doesn't.

The IS department just loves it when people compile their own kernels. The presence of dynamically loadable drivers means you never need to recompile the NT kernel (and hopefully also removes the need to recompile the Linux kernel).

How about an NT-centric list, with things like ease of configuring network and hardware settings, no .mumble files, and applications that don't crash because of silly things like changing fonts or more than 256 colors in the palette?

Before you color me a Linux basher, let me say that I love the Linux guys. I was a charter subscriber to the Linux Journal, and I used to have Linux installed at home. I like it, but I just don't use it. The success of Linux, though, could be good for NT as far as driving Microsoft to improve some of its admittedly lacking functions, such as scripting and remote process execution.

Most of the correspondents in your article ["Engineers Speak Out: Linux vs. NT," July , and August ] praised the scripting ability of Unix. Such scripts are necessary to "link the EDA flow." The truth is, better written tools would minimize or eliminate the need for scripting. I don't need a script to transfer data between Office applications. Every script that an engineer writes means that an engineer is acting in the capacity of an IS professional rather than an engineering professional. Think how productive we'd be if engineers could spend almost all of their time engineering rather than programming.

Steve Ravet
Electrical engineer
International Meta Systems
Austin, Texas

James Lee replies:

You mention several subjects: compiling kernels, configuration-setting files, and scripting in the EDA.

Fortunately, Unix machines usually allow kernel modification only at hardware installation and configuration time. On Windows machines, however, each installation of a user application modifies operating system files, installs or changes DLLs, and adds and modifies registry and configuration files. In the area of OS security, I think any Unix will beat NT hands down.

At least Unix contains well-documented files for the configuration setting. Any modern Unix also includes GUI programs to modify the setting for people of the GUI generation. Here again, many system administrators prefer Unix because of the well-known nature of the files and the ability to use a GUI they prefer. In Windows, it's all in the "registry"--and good luck if you have any problems.

Both the kernel and configuration issues can fall into the area of personal preference, so feel free to disagree with me. However, I think that you and Microsoft are way off base on scripting.

In the Linux versus NT forum I participated in at DAC [www.isdmag.com/dac/linuxtext.html], Daniel Small from Microsoft made a similar statement about not needing scripting, and I disputed his claims right then and there: Perhaps in word processing or mechanical CAD, just mousing around is enough. After over a decade of EDA and design experience, though, I can certainly say that EDA very much needs scripting or programming.

Why is scripting so important? Test vectors, for example, are either hand-coded or generated by a script, perhaps from the output of some other tool. How about synthesis? Since no one-button synthesis tool currently offers a "press here for the perfect circuit" button, scripting is used to continuously refine the process. Of course, let's not forget regression testing. If you're going to run the same tests many times to ensure that design enhancements don't break existing functionality, it's much better to automate those tasks.

I've listed just a few tasks in EDA that scripting makes more productive. As we move into the 21st century and design complexity continues to increase, we continue to need scripting as a way to speed the design process.

Finally, Steve and the folks at Microsoft: Please try to understand EDA and its differences from other markets before placing feet in mouths by saying that scripting isn't needed.

Not on my box

I find the practice of telnetting to a Linux box from an NT workstation unrealistic. I administered a Linux Web server for some time, and I too would telnet into the box from an NT workstation. One person you quoted, Jeffrey Watts ["Engineers Speak Out: Linux vs. NT, Part 1," July], must be a very patient and tolerant man; I found that telnet under Windows NT was just not stable enough to suit my needs.

Mike Kallies
Independent IT specialist
Toronto, Ont.

Linux under the table

The NT versus Linux issue can be easily resolved if you take a can-do attitude. I'll repeat what I said in an e-mail I sent to the Linux Journal:

Do you want to have 10 times as many people using Linux? If so, promote back-box Linux with the slogan, Linux under every desktop! What's "back-box Linux"? A back box is a computer with an Ethernet card, preloaded with Linux. It costs a couple hundred dollars. You stick it back under your desk somewhere and run the Ethernet cable into the back of your PC. Voila! You can run Windows and Linux simultaneously. Who benefits from back-box Linux?

• Chip manufacturers, with Intel on top of the list--Intel sells two CPUs per desktop instead of one.
• High-volume box sellers--it's the easiest box to make, as it's almost empty.
• UPS--boxes fly in every direction.
• Users--they get the joy of Linux, without having to worry about device drivers, dual booting, or giving up Windows.
• Win X server companies--they sell huge numbers of Win X servers.
• Linux developers--they have 10 times as many users.

Who loses? Nobody.

Since back-box Linux is so cheap, it shouldn't be hard for EDA gurus to get them as NT add-ons. They can then use Linux to massage their NT files, etc. No problems--just solutions. If the Linux community can get Intel to realize that it can sell millions more CPUs by having users run NT and Linux on separate CPUs at the same time, Intel will do the rest.

Lee MacDonald
Software engineer
Synergy Microsystems
San Diego, Calif.

End the sanctioned whining

The "Linux vs. NT" series is ISD-sanctioned whining. Why can't engineers resolve their issues?

Reluctance among EDA users to switch to NT is understandable. Unix power users are often wizards who put in years of effort to fashion a superworkable EDA solution. The complexity and abstract generality of Unix allows those power users to make their system work.

Engineers are great problem solvers when they're young. Later on, they use their expertise and knowledge to maintain their own static engineering world. They shout: "Resist change!" "If it isn't broken, don't fix it." "Unix forever!"

Back in the good old days, those same engineers would make it work. They'd hone their Unix boxes into fire-breathing killer machines. Now they say, "I open Outlook and my computer crashes; hence NT is unusable in all situations. Give me my old Unix box." I say to them: "Innovate. Make it work, engineer. Face the challenge." NT can be honed. Why resist learning something new?

Resistance to change is the bane of computer science. It's what causes people to learn COBOL and utter such statements as "The Internet is just a fad," "PCI will never replace ISA," and "Plug and play will never work."

Like beta machines, NT isn't the future because it's superior--it's the future because it already is the future. Get on the bandwagon while you still can.

Antiquated competence won't be a job skill forever.

Tony Stratton
Developer
Pagemasters
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  October 1998