New tech? Show me: EEs review IP cores

Highly marketed, heavily promoted and widely reported, IP cores received somewhat mixed reviews from our readers. For one thing, only a minority (29 percent) of the respondents said they use IP cores in their designs at all. Not everyone will; the EE Times readership is made up of many types of technologists, managers and executives who simply wouldn't ever be likely to use them.

Not everyone has integrated an IC into a system, either. Nevertheless, there hasn't been any giant leap in the use of IP cores in the past four years of the EE Times survey, although the total has moved up from about 20 percent in 1999 to more than 30 percent last year, then back a bit to 29 percent this year.

The most popular cores are logic cores, with 67.5 percent of respondents using them, followed by memory (57.5 percent), specialty (47 percent) and DSP (34.5 percent). They offer some distinct advantages over "from-scratch" designs, according to readers.

"By not having to design our own core, we've saved time and money," said a principal engineer at a system design company.

"We purchase IP products in order to shorten time-to-market; however, engineers are responsible to assimilate and get it to work properly," a software engineer writes.

A technical director at a consumer electronics company gives a vigorous thumbs-up: "IP saves us from developing, testing and debugging DSP code, so that we can focus our resources on providing value-added features to the customer."

"It can save [time, money or effort], since it prevents the need to do the low-level detailed design verification of common subsystems (USB, PCI, etc.)," a California principal engineer observes, but adds a note of caution: "This assumes the IP is easy to use and functions correctly."

"FPGA cores of the simple memory or DSP type save effort by quickly gaining the advantage of the architecture," a communications design engineer writes. "More complex cores require a great deal of effort to use and are often detrimental to time, money and effort."

A design engineer found "the few we've tried needed a lot of debugging and were a pain to use."

One nonuser of IP cores reports they were "more aggravation" than a help. But he is optimistic that the bugs can be resolved: "When some issues are worked out, there will be improved performance and cost benefits to IP cores."

A components design engineer reports that "on select projects, IP cores have saved tremendously on design time and use of manpower. IP cores reduce the risk factor on a project."

In fact, corporations are placing a higher priority on ease of use and integration in marketing their intellectual property to other companies. Some offer initial engineering help to companies that buy IP from them. Others take the approach followed by this respondent's communications equipment company: "No cores are taken from other companies; just from other (inte rnal) groups."

Readers believe only five technologies will see broad usage:

• System-on-chip: 71 percent
  
• Streaming media: 60 percent
  
• Network processors: 52 percent
  
• Linux: 51 percent
  
• Silicon IP: 47 percent

Readers believe the following have a future as niche technologies:

• Reconfigurable communications switches: 59 percent
  
• Embedded Java: 58 percent
  
• Reconfigurable processors: 54 percent
  
• Direct Rambus memory: 54 percent
  
• Bluetooth: 52 percent
  
• Formal verification: 49 percent
  
• Web-based design tools: 47 percent

None of the technologies listed got a majority under the "will flop" category. But with 26.5 percent selecting it for that dubious honor, direct Rambus memory led the field. Some 22 percent don't see a future for Web-based design tools. And just over 60 percent said the only "online EDA collaboration tool" they're using is e-mail, which hardly qualifies as an "EDA tool." Some 24 percent share databases, 13 percent collaborate with key partners and a mere 6 percent access online EDA tools. Nineteen percent report "no online activity."

A less enthusiastic six out of 10 endorse the statement that the Internet is "an effective way to get design assistance." Interestingly, a majority of the respondents said their companies are not buying many electronic components over the Internet, so purchasing remains a challenge for marketers of Internet services. Of course, we are surveying engineers, and only a minority of them report being actively involved in the purchasing process.

On the whole, readers agree that the Internet will be an important design tool within three years, but 31 percent "disagree somewhat" with that view. Apparently, there's still some missionary work to be done. Nearly half the sample's respondents, by the way, describe their work as primarily hardware-oriented. Some 19 percent call it software-oriented, while 32 percent work both sides of the transom.

As technologists, our respondents wield an impressive array of design skills. But they admit that people skills and business skills are elusive, since such skills can't be easily dissected and inserted into a system of "getting things done."

The primary design and development skills our respondents claim include:

• C/C++: 62 percent
  
• Systems integration: 56 percent
  
• Analog design: 45 percent
  
• ASIC design: 27 percent
  
• DSP: 21.5 percent
  
• RF/wireless design: 19 percent
  
• Optoelectronics: 16 percent
  
• Deep-submicron IC design: 13 percent
  

But technical skills won't get the whole job done. Business and management skills are also absolutely essential to an engineer's career today. Those who rely exclusively on technical expertise will find themselves isolated, unable to get funding for their projects and ideas. Readers tell us which of these skills in particular has proven most difficult to master.

"Team leadership," according to a systems engineer. "It works with the right people, but some are jerks and you can't get them off the project!" About 75 percent of the entire sample say that they possess this skill, but it doesn't come easy.

"It's difficult to get the right chemistry in a team that has individuals with different education/skill levels." That's why they call it "people skills."

"Scheduling: e.g., determining how long a complex project using different technology will take," a senior engineer said. His selection jibes with the 54 percent who checked off the "setting of project deadlines" as a key skill. "Things change after the deadlines have been agreed to," another engineer agrees. "Customers change what they want, engineers leave, software fails, etc., etc." Welcome to the world of engineering.

"Presenta tion abilities-both written and oral," a software engineer writes. "For example, creating documents that effectively communicate complex designs, then presenting the designs to a group of peers." Oral presentations are part of 64 percent of our readership's skill set, while 78.5 percent claim written-presentation skills for internal use. Another 36 percent-particularly those in management-have also written for outside publications.

Also difficult to master is "resolution of technical trade-offs," according to a test engineer. "Whether to test now with older software (but the equipment is available) or wait for newer software; but the equipment may be in use by others." This engineer's experience shows that technical trade-offs occur up and down the corpo rate ladder; such trade-offs are made every day at the bench level.

And here's one that everyone from CEO to designer can relate to: "Communication as to what my group does or plans to do," a software manager writes. "Reorganizations happen frequently, causing change in direction and a need to re-communicate."

One of the business skills that divides the staffers from the managers is responsibility for personnel hiring. Often promoted from the engineering group, managers find that hiring other engineers is not easy.

One project engineer denies finding any of the business skills difficult because " I prefer spending time mastering technical skills and learning computer tools." He may indeed prefer dealing with technology, but in mo st companies the pure technician will run into difficulties getting his or her ideas across and projects funded.

Design cycles
At one time design cycles were measured in years. Today, it's a matter of months. Overall, U.S. respondents report that the typical design-to-production design cycle lasts nine months. For many engineers in the United States and Japan, the cycle is even shorter. For 8.2 percent of the Americans and 9.1 percent of the Japanese EEs, their last design project lasted less than three months. Another 15 percent of the Americans and 22 percent of the Japanese report design cycles (defined as the period between specification and production) of three to six months.

But 45 percent of the Americans-especially those in the military/aerospace arena-work on projects lasting one year or more. Compare that with 31 percent of the Japan ese. Japan doesn't have a strong military/aerospace industry, which typically has longer projects and is less subject to the market-driven frenzies of the commercial world.

In fact, time-to-market, so widely touted as an absolute necessity for today's corporations, has a few engineers worried. There is "too much emphasis on speed and quick introductions," a design engineer in the test industry believes. "Not enough on making systems work reliably. PCs are a classic case of this."

Additional chart:
Hot (and cold) technologies: EEs buy into SoC, cool on Web-based tools