If all decisions were logical, the decisions in partitioning and implementing a design would be a simple exercise in spreadsheet programming. You could break the system into blocks that maximized homogeneity within the block, minimized I/O traffic and minimized package count. Then you could easily decide whether each block should be done in an ASIC or FPGA or purchased as a standard product based on specifications, design complexity, cost and projected sales volume. It should be a snap.

But in real life, as we explored in the first special section in this series, many issues beyond the quantitative enter into the decision. It is rarely a single-person decision, but rather the outcome of group dynamics. And even within the individuals in the group, there are emotional issues and assumptions at work that would never show up on a spreadsheet.

Consequently our study looked at not just the precursors to the implementation decision — the technologies available, design requirements and shipment volumes — but also the less-tangible dynamics that go on in the decision process.

One of the most important things to understand when modeling the decision process is the number of people involved. Data reveals at least seven interest groups who are involved, to a greater or lesser degree, in every stage of the decision-making process: corporate management, engineering management, system architects, hardware and software engineering teams, contractors and even customers.

Steps in the process
To understand how each group influences the eventual implementation decisions, we broke the decision process down into steps: setting system requirements, partitioning the system into blocks, choosing implementations for the blocks, selecting implementation tools and finding a verification strategy. Each step needs to be considered separately.

Setting requirements appears to be the step with the broadest range of influences. Respondents gave system architects and hardware designers the top billing in this stage, not surprisingly, with engineering management and software design not far behind. This would make the decision appear pretty mutual. But one piece of data not visible in the pie chart is that almost half of the respondents to this question said customers have a major influence on the requirements. Thus, an entirely separate group outside the company plays a key role.

As the process moves from defining requirements to partitioning, the focus shifts more to the architects and hardware designers, as is reflected in the second pie chart. The influence of software engineers, managers and people outside the design process declines sharply as the decisions become increasingly based on technical issues. As an interesting sidelight, the data indicates that in smaller companies, the software engineers retain more influence in this step than they do in large organizations.

This division of labor stays essentially unchanged as the architects and hardware designers — with input — settle on the implementation of individual blocks. Here is the point where the pros and cons of FPGAs, structured or cell-based ASICs and off-the-shelf parts are mulled over and decisions reached. Again, software engineers have more clout in smaller organizations. And, interestingly, in the very highest-volume designs, corporate management asserts itself more in this stage, nearly doubling its incidence of ''very influential'' responses compared with medium- or low-volume designs.

The influence of engineering and corporate management also emerges in the next phase: selecting EDA tools. Finally, the software team gets its turn again, with growing input into the verification process.

It is interesting to compare the perspectives of various players in the process. Looking specifically at the implementation phase, hardware engineers tend to downplay their own, software engineers' and system architects' influence in the decision. For some reason, the hardware engineers think that corporate management has more influence than they apparently have. Corporate managers, by contrast, have a nearly opposite view: They see themselves as not particularly influential in the implementation decisions and overstate the roles of system architects and engineering managers. Even more curiously, only system architects think that software engineers have a big role in implementation decisions. It is fascinating to speculate that these differences in viewpoint reflect exchanges of information between specific groups that are not visible to the rest of the organization. Are architects and software designers meeting in secret?

A matter of perspective
The data suggests that once system requirements are set, the key players in partitioning and implementation decisions are in fact the system architects and hardware designers. Recall that in smaller organizations, these are often the same individuals. It is valuable, then, to look at the attitudes that these players bring to the table.

To begin with, almost everyone in the process agrees that partitioning requires a two-way communication between designers and architects. Architects, however, agree with that to a lesser degree than designers do. Pretty much everyone also agrees on the values of IP and off-the-shelf parts, although designers are more skeptical about buying standard products than are other members of the team.

There is also a lot of disagreement about inertia. Designers agree only moderately with the statement, "It takes a lot to make us change the way we do system design.'' But architects and managers agree much more with this statement. This difference of opinion comes up again on the statement ''Our team doesn't have the experience or skills to do an ASIC.'' Designers tend to disagree, while architects — and the designer/architects in smaller teams — reported significantly stronger agreement.

It is also fascinating to look at the issues that respondents said were critical to their decision process. The results are summarized in our final table. Here the differences between management and engineering are instructive. Designers ranked the top five issues in the order shown in the chart. But to architects, the order was unit cost, performance, time-to-market, risk and reliability. To managers, the order was time-to-market, risk, performance, resources and unit cost. No one else came close to giving risk of failure the strong emphasis that management did.

Given the emphasis on time-to-market, performance and cost, it might seem reasonable that design teams would be gathering all the information they can get on emerging alternatives to traditional cell-based ASICs and FPGAs. But our study indicates that there is remarkably little familiarity with, in particular, structured-ASIC concepts among working design teams.

Overall, fewer than 20 percent of respondents said they were very familiar with structured or platform ASICs. Familiarity was least among designers and greatest among managers, perhaps reflecting a difference in the meaning of ''very familiar'' between the two groups. The rate of very-familiar responses among respondents in small companies was less than a third of the figure for companies over $1 billion in sales, probably in part because of an overall lower familiarity with ASICs.

That contrasts with a virtually ubiquitous familiarity with FPGAs: 92 percent of respondents said they were either very familiar or somewhat familiar with the chips. The highest level of ''very familiar'' responses came from respondents who acted in both architecture and design roles — those small teams again.

The technology with the biggest awareness deficit proved to be ASSPs with embedded FPGA cores — an emerging technology if ever there was one. Fewer than 10 percent of respondents said they were familiar with the technology. Once again, management's wider perspective — or its more casual interpretation of "very familiar'' — was clear: More than 20 percent of managers put themselves in this category.

The overall picture that emerges is a very complex one. Implementation decisions involve a diverse collection of groups, who bring markedly different perceptions and levels of information to the process. Add to this the more-tangible differences in design team resources, experience, volume and design requirements, and it becomes clear how designers working on apparently similar projects could come to quite different decisions. It is also easy to understand how decision-makers could give up on quantitative analysis and become religious about their choices. With all these issues, and with new alternatives on the way, we haven't seen the end of this issue.

See related chart

See related chart