Neither is the financial picture ambiguous: Cell-based ASICs have high initial investment, while FPGAs and standard-product ICs have virtually none. There are also clear differences in unit cost. Once an implementation plan meets the technical requirements, it should be a simple matter to look at the forecast, figure out the total life cycle cost of each viable alternative and pick the most profitable.

But that can't be the whole story. Consistently, one sees competent design teams making what appear to be irrational choices-FPGAs for high-volume products, off-the-shelf chips for what are clearly system-on-chip (SoC) opportunities, cell-based design flows when a structured ASIC would have sufficed at a fraction of the cost. Other things must be going on.

To explore this decision-making process, EE Times conducted a focus group in early May, bringing together members of teams from all the design camps to discuss how they reached their implementation decisions.

The discussion revealed a hierarchical decision process with a rich blend of technical, financial, pragmatic and purely emotional issues.

In large design teams, where an ASIC design is most likely to be undertaken, implementation decisions come down to the team from a separate individual or group of individuals who have been anointed as system architects. These individuals are responsible for identifying and freezing the system requirements. But they also are given the interrelated tasks of partitioning the system into functional blocks, grouping the blocks together and choosing the implementation strategy for the important ones.

"The architects are usually the most senior engineering people," said one participant. Others agreed. To some degree, then, architecture is the reward for experience, or maybe simply for tenure.

Smaller teams don't have the luxury of overlords. "We all wear a lot of hats," another participant observed. "The system architects on our team are the same folks who will do the implementing."

This identity of tasks provides a natural feedback path between the architects and the implementers. If you dig into a block and don't like the way it's going, you only have to change your own mind. But in larger teams, where there seems to be a strong separation between architects and implementers, there is a serious question about whether the implementation decisions are based on current design experience.

In these cases, the feedback path can be more complex. Several participants said that implementation teams would offer feedback to the architects, and might be called in to take part in decisions when the architects needed current experience with a particular technology. But participation-especially uninvited participation-is not always welcome. "Architects do have egos," a participant noted.

The group was split on the question of head count. Not surprisingly, members of teams that were once much larger were more outspoken.

Asked if design teams had become smaller since the recession hit, one response was ". . . uh, that's an understatement."

In many cases, organizations that built large, experienced design teams in 1999 or 2000, with an eye to making cell-based customer-owned tooling designs to hone their competitive edge, now appear to have reversed direction. Teams today include only those who have critical knowledge the company can turn into differential advantage. The solid foundation of cell-based design skills in many teams has eroded to a few timbers, even as cell-based design has grown more challenging.

That means that many teams, if they choose to do a cell-based or even a structured-ASIC design, must plan to rely heavily on either an ASIC vendor or a network of consultants to supply the skills they have lost. This changes the entire picture for cell-based design, from cash flow issues to the perceived risks and the management skills required. "When we look for a qualified skill set to take on a particular approach, we are not finding it," lamented one participant.

Equally as important as sheer numbers is experience, according to the group. Engineers have long been known for their conservatism in adopting new approaches, but the experience of the recession and the battering design teams have taken seem to have intensified that reluctance to change.

"It helps a great deal if you already have someone on staff who's worked with a particular technology," was one comment. Several times it was mentioned that a design team was most likely to apply a familiar implementation solution to a new problem, even if something new looked more attractive.

The tendency toward conservatism is a particular challenge for structured ASICs. Only about half of the focus group members were really aware of this alternative. And the view of the majority was nicely summed up by one comment: "This sounds like it could be a good approach for us. But we will probably wait until there are a few other companies out there with success stories before we look into it."

On the organizational side, the group cited the risks that are widely discussed in the industry. ASIC designs fail to converge or fail to yield. Standard products go out of production. Small vendors fail.

On the personal side, the group provided a window into the way designers think about their craft.

One group was definitely risk-averse. One participant said with a sarcastic grin, "My designs always go perfectly the first time, so I never find myself coming in at night to make changes. Of course, I know other people who might do something like that."

The ability not only to correct errors but also to do so without leaving a trail of modified files, revision documents or invalidated simulation runs was a significant factor expressed by some of the group. Specifically, it was cited as a strong reason to prefer FPGAs when they could be technically justified: Simply put, FPGA revisions leave no paper trail.

A similar notion was expressed by some participants with strong cell-based design experience. It was noted that requirements can change, either through initial miscommunication or simply as marketers and architects develop a better understanding of a customer's needs. Designers are averse to being caught in the middle when such changes occur.

One participant pointed out that even customers can be a source of trouble, becoming involved and making increasing demands. The demands may seem like only incremental changes to existing specifications, this respondent suggested, but viewed in the context of the design work to be done, they are irrational. Once again, field programmability benefits the designer at least as much as it does the organization.

But there was an opposing view as well. For one thing, one of the ASIC designers alleged-and surprisingly, the FPGA users didn't argue-that FPGAs make for sloppy design. "There's the feeling that if you can fix it so easily, why be careful? It's kind of like the difference between driving when you know you have a spare tire and when you know that you don't."

Further, there was concern about the impact of too much conservatism on one's resume. This thought clearly divided the FPGA and standard-product users, who were generally risk-averse, from the large-team ASIC designers. "If you have the chance to significantly reduce cost on a product, even if you aren't sure if the volume will develop, you should go for it," one ASIC manager said.

Thus the implementation decision involves not only technical and financial requirements but also personal issues for both architects and implementers. As EE Times moves from focus research to large-sample global research on the issue, we'll try to tease out such threads and follow them to find patterns.