Ron Wilson, Editor-in-Chief, Altera Corporation
Debate rages over the correct methodology for SoC-based system design. Is it the traditional register transfer level (RTL) flow? Or is it high-level synthesis of a C-language behavioral model? What about an intellectual-property (IP) reuse methodology that minimizes any kind of code generation? Every expert has an opinion of how design teams ought to move from requirements definition to manufacturing. Each view is based in preference, past experience, or—in the case of EDA vendors themselves—product availability. But in many real-world situations, all of these views may be irrelevant.
The reason is simple: most system designs—55 percent, according to a recent study by the website embedded.com—are not new designs. They are modifications of some sort of existing design. This fact means that the actual design process depends not on the dictates of some methodology expert, but on the nature of the changes in requirements and on the data available to the design team. The results may be anything from a formally-driven revision process to a mad scramble to contain an epidemic of unanticipated changes. Far too often, the result is in fact—if not in name—a redesign of the entire system: not because of the extent of the changes, but because of the lack of reuse planning and of a methodology that can manage change. In this article we will ask methodology experts and practicing designers to describe a consistent way of discussing what actually happens when system requirements change. Then we will apply that framework to several real-world design situations, and use it to suggest what the design process should be, and how to make it better.
Click here to read more ...