RASSP virtual prototyping of DSP systems
Proceedings of the 34th annual conference on Design automation conference - DAC '97
This paper describes a top-down hierarchical simulation process that dramatically accelerates the design-evolution of DSP systems when compared with traditional physical prototyping methods. A summary of the model abstraction hierarchy and purposes for the various types of models provides critical guidance in selecting appropriate abstractions to achieve accurate yet efficient simulations. The simulations enable rapid exploration of many more alternative software and hardware solutions than
... solutions than would be practical using conventional gate-level simulation technologies. The result is improved design adaptations and quality. I. Introduction Comprehensive simulation of the internal logic of individual integrated circuits (ICs) has reduced the number of design errors to the point where the majority of design faults now occur in the IC requirements specification. It is now expedient to focus on the system verification process where the IC requirements are developed. Digital signal processing (DSP) systems are growing ever more complex. In particular, multiple processor elements are harnessed to extend processing power beyond that of single processor technology. Conventional design methods, such as physical prototyping or gate level simulation, become prohibitively costly and time consuming for such complex systems. Therefore, virtual prototyping methods are needed for verifying all functional aspects of a complete integrated system early in the design process. The RASSP (Rapid Application Specific Signal-processor Prototyping) program addressed the DSP prototyping problem to reduce typical system development times from months to weeks. The resulting approach described in this paper is beneficial for designing either custom processor based or commercial-off-theshelf (COTS)-based DSP systems. For efficient design, the prototyping process must be initiated at an abstract level, and it must proceed to more concrete descriptions as details are resolved. The process must be supported by models at each level to verify distinct aspects of the system and its components. The resulting hierarchical model set supports future model-year upgrades of the system by providing various degrees of implementation independent description of the system's functionality. The wide range of effective model execution rates underscores the need to carefully select the appropriate abstraction level for the design task at each level. Prototyping simulations must return results in a matter of minutes to permit designers to iteratively explore, optimize, verify, and ultimately converge on a valid DSP system design in the short time frame. The following sections describe the purposes of the three primary virtual prototype models summarized in Table I . II. Token-Based Performance Model A performance model describes a DSP systemÕs time-related aspect, including response time, throughput, and utilization. Neither the actual application data nor the transforms on it are described other than what is required to control the sequence of events. A. Purpose of Token-Based Performance Model The purpose of the token-based performance model is to: ¥ Help users optimize mapping the software tasks to the processor nodes ¥ Verify that the required throughput is sustained with appropriate margins, ¥ Measure resource usage, such as memory buffer requirements, and communication and processing load balancing. Network-performance modeling determines the system size, network architecture, software-to-hardware mapping, and performance requirements for each major component of the DSP system. The ultimate processing latency, throughput, and physical constraints on the DSP system drive the optimization of the DSP architecture design. The system size is determined in terms of the number and type of processing elements, and the memory and buffer requirements for each network and processor elements. Specific mixtures of specialized processor element types are optimally determined. The network architecture specifies the topology of the network, as well as the bandwidth and protocol requirements for the individual network links. Designers select topologies to match the particular data transfer patterns of the specific application. Performance simulations provide information concerning link and processor utilization for specific topology, processor element, and software mapping combinations. The software-to-hardware mapping partitions the application algorithm into tasks, which are allocated to the individual processor elements. The tasks are then scheduled according to their relative data dependencies and the overall processing latency constraints. Designers can test and select various combinations of mapping and scheduling methods. For example, depending on the application, the mapping and scheduling can be assigned statically at design-time or dynamically at run-time. Performance models facilitate both of these methods. [1,2,3] The regularity of many DSP applications allows static scheduling as this paper describes. B. Performance Model Description Unlike testing an individual IC design, which typically requires thousands of clock cycles or a fraction of a second of simulated time, DSP-system simulation typically requires simulation of significant portions of a DSP algorithm spanning several seconds or minutes of simulated time. The simulation of multiple cooperating processor elements, each executing tens of millions of instruction cycles per second (MIPS) over such time spans, represents the execution of an extraordinarily large number of events. Simulation of a multi-processor DSP system at or below a chip-behavior level is impractical due to the large memory and simulation run-time required.