SoC savvy

Seven habits of highly effective system-on-a-chip makers

By Bill Roberts -- EDN, March 1, 2001

Sections

Think system, not chip
Market-driven products
Refine system architecture
IP reuse
Ride herd on IP providers
Verify early and often
Orchestrate cross-function teams

The TX39 is a system on a chip (SoC) from Toshiba America Electronics Components Inc., Irvine, CA, a unit of Toshiba Corp., Tokyo. With a 32-bit RISC microprocessor core and a million gates, it's designed for set-top boxes, Internet appliances and other consumer devices. The TX39 is now in volume production, but getting there was no cakewalk.

"It was a painful design process," recalls Jim Smith, director of business development for microprocessors for Toshiba. "The chief difficulty was the time it took to complete the design." It took more than two years-about a year longer than expected, Smith says. There were some technical issues and the specifications kept changing in a fast-moving market. The longer the project dragged on, the more specs needed to be changed, which underscores a fundamental truth for SoCs. "As the design time stretches out, incorporating the increasing number of changes that come from the market becomes an escalating problem," says Smith.

Welcome to the real world of SoCs. The concept is appealing, but designing one is harder than many people think.

Do it right and the benefits are many. Manufacturing advances allow chip developers to build increasingly complex devices with far more functions. What once took several circuit boards and chips, can now be etched into a single piece of silicon. An SoC offers more efficient performance than a stack of boards wired together. An SoC also can speed time to market, especially in the cutthroat consumer appliance business where many SoCs are used. However, as Toshiba discovered, an SoC speeds time to market only if the device meets its market opportunity on time.

Experts say the challenges in SoC development are daunting. Chip companies typically do not approach their craft with the systems perspective that SoCs require. They also don't take enough time to understand end markets or design system architecture. Reusable intellectual property (IP) cores are crucial, but getting all the IP together isn't easy.

Verification also is extremely vexing. While a typical chip might be developed by two or three engineers, SoC projects can take 10 or more engineers with diverse talents in systems, hardware, software and verification. Managing cross-functional teams like these can be akin to herding cats.

Savvy companies are learning to handle these challenges. As a result of its TX39 experience, Toshiba revamped its design methods. A new generation SoC, the TX79, will benefit from a myriad of changes, Smith says. He thinks Toshiba will be able to reduce the design cycle by nine months.

Despite the difficulties associated with designing them, SoCs are only going to grow in importance to the electronics industry and more companies are likely to tackle them. Here then are seven habits that experienced SoC companies practice. Executives at these companies, some of which pioneered the SoC concept, say these practices have helped them do a better job of managing a complex design problem.

1. Think system, not chip

Effective SoC developers place the emphasis on the system, not the chip.

"A chip company is not a systems company," says Don Schrock, president of the CDMA technologies division of Qualcomm Inc., San Diego. "Qualcomm is a systems company that reduces systems into silicon." He says the systems perspective pervades everything Qualcomm does.

Qualcomm develops digital wireless communication technologies. It has built SoCs since the early 1990s, notably for its code division multiple access (CDMA) digital wireless technology for cell phone handsets and base stations. It introduced its first SoC in 1994, placing a microprocessor, digital signal processor, memory and logic all on one chip, and has since developed several SoCs.

The systems perspective affects the way the chip division, formed in 1995 (and preparing to spin off sometime this year), organizes into teams of engineers that include systems, hardware and software expertise. "When we set up this division, we knew we had to supply a complete solution: hardware, software, reference platforms-anything the customer needs," Schrock says. "When we ship hardware samples, we have to ship software the same day." Systems, including SoCs, almost always require software, yet chip companies in most instances haven't had to develop software for traditional chips.

A chip company, one that has built SoCs longer than just about anyone else, is LSI Logic Corp., Milpitas, CA, which also develops chip systems for the cell phone industry. Ronnie Vasishta, senior director of technology product marketing, agrees on the importance of the system perspective.

LSI views itself as a silicon maker that delivers a systems solution, he says. The differences between this and traditional chip making are numerous, he adds. SoCs require a keener focus on end-market applications than the traditional chip business does, a different development organization, as well as closer ties to customers.

"Traditional chip companies are not typically organized in a fashion that lends itself to end markets," he says. "This is one of the biggest challenges."

LSI started working on SoCs around 1993 and over the years has built up this experience, he says. No single project was the turning point; rather LSI learned slowly over a period of years. One result: It established its Coreware methodology and team (more about this later) to supervise the reuse of intellectual property.

2. Market-driven products

Others agree that effective SoC developers are more market driven than most chip makers. This dynamic often results in healthy tension between engineering and marketing. "The hard work up front is in marketing and product definition," says Matthew Perry, vice president and general manager of the embedded processor division at Cirrus Logic Inc., Fremont, CA, which makes analog circuits and advanced mixed-signal chipsets.

Cirrus Logic has developed SoCs for magnetic storage, Internet appliances and various consumer devices. One of the great things about SoC development, Perry says, is the wide availability of peripherals and peripheral interfaces that can be designed onto a device. This also presents a risk. "When you're doing SoCs, it's easy to get carried away with features. If you're not very clear about what you're marketing, you can get sucked into the kitchen-sink approach."

"On Beryllium, we took the high-work-load, low-risk approach-to manage [suppliers] day to day." -Mike Gulett, president, Virata Corp.

At Cirrus, a small team of engineers and marketing experts spends a few months stipulating a product for a specific market. The result of this work is a marketing plan and a general system description. "At Cirrus, we define the hundreds of products we're not going to make and winnow down to the ones that allow us to hit a particular market," Perry says.

The process involves many meetings-often contentious-and a lot of brainstorming. "We hire people who are comfortable with the brainstorming strategy and people who think more about systems," says Perry. "The world renowned expert in hardware widgets who doesn't appreciate the challenges of programming doesn't work well in this environment." It also helps that most Cirrus marketing professionals have technical experience.

One device that resulted from this process is the EP9312, an SoC for the home audio player market. It has an embedded microprocessor, licensed from ARM Holdings Plc, of Cambridge, England, several internal peripherals and many peripheral interfaces. It also includes Cirrus Logic's own MaverickCrunch math co-processor for faster file compression.

The EP9312 was a trailblazing product, so Cirrus decided to invest the time to develop the infrastructure and architecture, knowing these would be reused in later products. For example, it took extra time to design the math co-processor in such a way as to relieve software programmers of the need to write a lot of code. "Software developers don't have to pay any attention to this feature now. If they want to exploit it, they just have to write a few lines of code," says Perry.

3. Refine system architecture

Once marketing and engineering reach agreement, the design team in an effective SoC project usually takes another chunk of time to define the system architecture before features and attributes are committed to silicon.

Schrock credits Qualcomm's success to the amount of time his staff devotes to this detailed planning. "Our systems engineering teams spend tremendous time looking at the total system before we ever think about silicon." It's not uncommon for engineers to spend three or four months of a 12- or 18-month project defining the system architecture.

	"Reuse is like the weather. Semiconductor companies talk about it a lot, but don't do much" about it. -Jim Lipman, director of the SoCNet Web site of TechOnLine Inc.

A customary project milestone is a meeting that takes place after the design team thinks it's finished. The entire project team, usually 20 to 30 people, gathers to hear the design team explain what it has in mind. Then the entire project team criticizes their assumptions. "We make the team that designed the system stand up and demonstrate the value of what they have developed," says Schrock. "The process can take several days and is very intense."

One result: The entire team reaches agreement on tradeoffs between adding features and meeting deadlines. It's essential to make the project deadline, so Qualcomm's customers can go to market as planned, Schrock says. If the design engineers overreach, they can fail. They also must avoid going to market with a product containing outdated features.

A Qualcomm SoC now in use in Korea and soon to be used in Japan and the United States is the CDMA 2000 1x. These systems are comprised of two SoCs actually, one for the handset and one the base station. The SoCs are faster and simultaneously can handle twice as many calls as the chips in earlier generations of cell phones, Schrock says.

Even with a ground-breaking technology like this, tradeoffs were hammered out in the system planning phase. One was what data speed the device would accomplish. The team decided on 153 kilobits per second, saving the next level-300 kbps-for the next version. The team also decided to design the handset and the base station in tandem. This took extra time, but was necessary to prove the technology worked from end to end.

4. IP reuse

Effective SoC developers make a conscious effort to reuse intellectual property (IP). Yet the concept has not caught on widely. "Reuse is like the weather. Semiconductor companies talk about it a lot, but don't do much" about it, says Jim Lipman, director of the SoCNet Web site of TechOnLine Inc., Bedford, MA, which provides online training to electronics engineers.

It takes time to reuse internal IP or acquire it from third parties, but done properly, it takes less time than building the IP from scratch. Lipman says that a small but growing number of semiconductor companies are putting incentives and programs in place to encourage the reuse of internal IP.

Reuse accounts for much of LSI Logic's success, Vasishta says. "SoCs tend to be high-volume applications with a tight time to market requirement," he says. "To meet deadlines you have to reuse your IP across the entire company, not just within one division."

Several years ago, LSI established its Coreware methodology, which spells out strict rules for developing and maintaining IP cores. Development teams must abide by these rules and there's a Coreware group of 10 to 15 engineers dedicated to developing and enforcing them. Its team leader is a senior director, who reports to the vice president of customer engineering. The aim is to build a library of reusable cores. LSI has accumulated more than 600 and used them in about 700 designs. "If you try to develop everything from scratch, you'll never get to market," Vasishta says.

At Agere Systems Inc., Allentown, PA, reuse means different things to different divisions, says Gene Scuteri, general manager of optical networking solutions. Some macros can be used off the shelf. Others need a lot of refining. Since most SoCs require the use of a heavy dose of software, Agere tries to reuse as much of that as possible, and to write code that is both backward and forward compatible. "We write the code or do the design in a way that allows us to simply recompile and scale up without having to redesign it," he says. Agere (formerly the microelectronics group of Lucent Technologies Inc., Murray Hill, NJ) has focused on this effort for about four years.

5. Ride herd on IP providers

Even with effective reuse programs, SoC developers cannot possibly create all the IP they need. As SoCs grow more complex, their developers will produce an even smaller portion of the IP. Developers must license IP from third parties, which raises compatibility issues, legal complexities and other perils (see "IP Poker," EB, November 2000, page 130). Once they've licensed IP, effective SoC companies manage the providers as if they were part of the in-house design team.

Virata Corp., Santa Clara, CA, learned this habit during the design of Beryllium, an SoC and software for asynchronous digital subscriber line (ASDL) network routers. It was the most complicated product Virata ever designed and included IP from seven outside providers on three continents. Virata knew it would have to keep close tabs on those parties if the project were to succeed. "We had to actually bring them inside the company and treat them as if they were part of Virata," says Mike Gulett, president.

"We make the team that designed the system stand up and demonstrate the value of what they have developed. The process can take several days and is very intense." -Don Schrock, president of the CDMA technologies division, Qualcomm Inc.

The design manager, based at Virata's design center in Cambridge, England, met regularly with each provider's project manager. Together they set deadlines and agreed upon what results would be expected. Then the Virata staff managed the project, monitoring what was submitted by suppliers. On earlier projects, Virata had given suppliers their specifications, and then had little or no contact with them until the work was done. "That's the high-risk, low-work-load approach," says Gulett. "On Beryllium, we took the high-work-load, low-risk approach-to manage them day to day."

The relationships with each supplier lasted from two to six months. Gulett believes that, with this approach, the company minimized the risk of bugs being found late in the project. Because the providers were not located where the design team was, Virata put its contractors on its e-mail system, collected pertinent phone numbers and put in place feedback mechanisms. "We used the same management techniques we use with our own engineers," Gulett says.

This practice is now standard at Virata. If an IP provider doesn't want to play this way, Virata considers it a red flag. "Either they don't understand the need for it, or they don't want to be monitored," says Gulett.

Synergetic Microsystems Inc., Downer's Grove, IL, is another chip maker that learned the importance of monitoring IP providers. With only 20 staffers, it was impossible to develop all the IP and do all the work on its EC-1, an embedded communications SoC for industrial, medical and transportation markets, says Rick Goldstein, chief operating officer.

Synergetic acquired IP from two sources and put one of its engineers on site at each location for the duration of the project, Synergetic's first SoC effort. "We also used a private Web site to manage the project on a daily basis, with each day's milestones posted, and access given to everyone, including the outside providers," Goldstein says.

6. Verify early and often

Experts agree: The most difficult aspect of completing an SoC design is verifying that all the functions actually work. When you put all these varied functions into one piece of silicon, shrinking them down many times and just getting to them to test them is hard.

Even the SoC-savvy companies in this article struggle with verification and spend inordinate amounts of time on it. The tools are lacking, the test suites have to be written for each project, and developers can't put this off until they have first silicon from the foundry. Effective SoC developers verify early, often and simultaneously with other project activities.

Agere's Scuteri estimates that his company spends more than 60% of its SoC development time on verification. "One of the problems is we're still in the Dark Ages with tools. I tell this to every CAD vendor I meet," he says. "We've developed some of our own tools, and we experiment with just about everything that's out there."

Agere recently developed an SoC called TADM (for transmission add-drop multiplexer), a device with 6 million gates that helps existing optical networks handle greater bandwidth. The design was so big that existing CAD tools were limited, Scuteri says. "There was no CAD tool that we did not break. We worked with vendors to fix them to work, but that probably added 30 to 45 days to the project."

Like other effective developers, Agere verifies an SoC as it unfolds, rather than waiting until the end. One team of engineers was mocking up TADM even while the design team was still at work. The mockup allowed them to anticipate problems long before final verification.

	"SoCs are the way to go in the market, but they require a lot of discipline, the right methodology and teamwork. It requires discipline, but it's a discipline that you can master." - Gene Scuteri, general manager of optical networking solutions, Agere Systems Inc.

Generating a test suite for an SoC can be more difficult than designing the hardware itself, says SoCNet's Lipman. "It is really hard to write correct test routines when the SoC is complex and the cores are all internal to the chip," he explains. "Just getting to the internal nodes is difficult." With a circuit board, a test engineer could access every pin on the chip. On an SoC, those pins are shrunk down to nodes inside the silicon making them much harder to get to, says Lipman.

Through the life of a project at Qualcomm, from 20% to 50% of the assigned engineering resources are involved in verification, depending on what phase the project is in, says Schrock. On the CDMA 2000 1x, these efforts included emulating the handset and base station early in the project, so software programmers could start to write code before the hardware was done. Qualcomm also completed field tests using phones and base stations its engineers built just for that purpose. "You can do 98% of software verification in emulation, but the last 2% comes by means of field testing," Schrock says.

7. Orchestrate cross-function teams

The first six habits mean little if the SoC developers can't orchestrate the talents of systems, hardware, software and test engineers. This is easier said than done because these groups historically have had little to do with each other. "Our hardware engineers and software engineers used to exchange business cards in the hallway," says one executive who requested anonymity.

About four or five years ago, Agere recognized the need to break down the traditional internal silos that separated functional groups and get the different disciplines to work together. The company wanted cross-functional product teams that each operated as their own small business. This took a conscious effort to change the organizational structure, with the various disciplines brought under one point of control. "We've built an entire business strategy now around cross-functional teams," says Scuteri.

Product development teams include members from each discipline-software, hardware, systems and verification. A team typically numbers 30 to 40 engineers. Before the reorganization, Agere had problems getting people to work together. One common problem was that the design team was not engaging the verification team until late in the process.

Now, Scuteri says, everyone is involved from the beginning and responsible for the project's success. Profit-and-loss responsibility also falls under the same control as the cross-functional team, he adds. "There is a challenge to get people to trust one another," he reflects. "The organizational structure has helped. This all seems very simple, but we had to formalize it."

Still, things don't always work smoothly, he admits. Software and hardware engineers have a hard time communicating. It's management's job to get these people to talk to each other and work together. Agere often has the chip designers work alongside the software programmers so they can see what problems software people have, Scuteri says. Agere also routinely rotates hardware engineers among the design, verification and customer support teams so over a period of time they become better educated and sensitive to diverse issues. Agere also sends hardware engineers directly to customer sites to witness what they have to deal with.

Effective SoC development takes discipline on many fronts, Scuteri admits. "SoCs are the way to go in the market, but they require a lot of discipline, the right methodology and teamwork," he says. Pointing to Agere's own experience, he adds optimistically: "It requires discipline, but it's a discipline that you can master."

Bill Roberts is a contributing writer for Electronic Business. You can reach him at brobert1@ix.netcom.com.