next up previous contents
Next: 2 Introduction Up: Appnotes Index Previous:Appnote TOKEN Index

RASSP Token-based Performance Modeling Application Note

1.0 Introduction

RASSP application notes augment course modules and case studies about digital system design. The material is applicable to the design of complex systems such as digital signal processing (DSP) or control systems and other multiprocessor systems. The application notes serve to document the design methods that were developed on the RASSP program. This application note describes the purposes and methods for token-based performance modeling. Additional details regarding processor types, model hierarchy and abstractions, common language and vocabulary can be found in the VHDL Terminology and Taxonomy document.

1.1 What is Token-based Performance Modeling

Computational Performance is a collection of measures relating to the timeliness of a system design in reacting to stimuli. Measures associated with performance include response time, throughput, and utilization. The generic term performance model refers to a model of any abstraction level that describes the timing relationships without resolving non-time-related aspects, i.e. values, formats or functions.

A highly abstract performance model could resolve the time consumed by cluster of processors to perform major system functions like search, FFT or FIR. A less abstract performance model could describe the time required to perform detailed tasks such as a single CPU memory access. In the context of Lockheed Martin Advanced Technology Laboratories (ATL) RASSP system design, the typical abstraction level of a token-based performance model is at the multiprocessor network level; sometimes called a network architecture performance model.

Token-based performance modeling is defined in the RASSP Taxonomy as a performance model of a system's architecture that represents data transfers abstractly as a set of simple symbols called tokens. Neither the actual application data nor the transforms on it are described other than that required to control the sequence of events in time. The application-data is not modeled, while only the control-information is modeled. For example: answer = 5 is not modeled, but control node = search is modeled.

Typically, the token-based performance model resolves the time for a multiprocessor networked system to perform major system functions. It keeps track of the usage of resources such as: memory buffer space, communication linkages, and processor units. The structure of the network is described down to the network node level. The network nodes include processor elements, network switches, shared memories, and I/O units. The internal structure of the network nodes is not described in a Token Based Performance Model.

1.2 Why and when is Token-based Performance Modeling needed

The growing reliance on commercial-off-the-shelf (COTS) processing components and state-of-the-art comprehensive simulations of the internal logic of individual integrated circuits (ICs) have reduced the number of design errors to the point where the majority of design faults now occur in the component requirements specification. It is now becoming expedient to focus on the system verification process, where the IC requirements are developed.

Digital systems are growing ever more complex with improving technology and integration densities. In particular, multiple processor elements are harnessed to extend a system's 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 systems.

Unlike the testing of an individual IC design which typically requires on the order of thousands of clock-cycles or a fraction of a second of simulated time, digital system simulation typically requires the simulation of significant portions of an application algorithm spanning several seconds or minutes of simulated time. The simulation of multiple cooperating Processing Elements (PEs), each executing many millions of instruction cycles per second (MIPS), over such time spans represents the execution of an extraordinarily large number of events. Therefore, simulation of a multi-processor system at or below a chip-behavior level becomes impractical due to the large memory and simulation run-time that would be needed.

However, full-system simulations are required to validate the overall system concept; to jointly optimize the hardware and software; and to investigate the interactions between cooperating subsystems prior to embarking on time-consuming and detailed designs that could unknowingly be misguided. Fortunately, the number of events can be reduced by adroitly using abstractions without jeopardizing the accuracy or validity of the model. Therefore, selecting an appropriate modeling abstraction level is crucial for timely design.

Simulations must execute and return results from simulation runs in roughly an hour or less to permit designers to rapidly explore, optimize, and verify system design solutions. Such a turn-around time allows several design iterations per day and ensures convergence on a valid system design in a matter of days instead of months. Therefore, more abstract prototyping methods are needed for verifying all functional aspects of a complete integrated system early in the design process.

Token-based performance modeling is an abstract form of system modeling that addresses these challenges. The simulations help identify bottlenecks, validate early system expectations or coarse timing requirements, and highlight initial design options.

1.3 How it fits into overall design process

Token-based performance modeling supports Lockheed Martin ATL's System Design and Architecture Design process as shown in Figure 1 - 1.

As the overall system requirements are established by the System Design process, the architecture design process decomposes the overall requirements into a set of requirements for the constituent building-blocks that together satisfy the overall system requirements. Figure 1 - 1 shows the relationship of performance modeling to the overall design process.. The architectural building-blocks consist of software tasks, processing elements, memories, I/O units, and a network that connects them together.

Figure 1 - 1: The RASSP design process consists of system definition, architecture definition, and detailed design. The shaded area indicates where token-based performance modeling occurs.

The architecture design process proposes candidate solutions that consist of combinations of specified processor elements, linkages, memories, network configurations, and application-software mappings. The components are specified in terms of their relevant performance ratings. The token-based performance model is used to test how well various candidate solution combinations meet the overall requirements.

Feed-back from the token-based performance model is used to optimize the architectural selections and eventually to select the best architecture for meeting the given requirements. As a result of the performance modeling, the selected architecture is specified in terms of performance requirements for each of its constituent building-blocks.

The requirements for each building-block from the architectural specification are passed down to the detailed hardware/software design processes as shown in figure 1 - 2. As the component designs are realized or acquired for testing during the detailed design process, the actual parameters of the component's specification become known to a higher degree of confidence and accuracy. In some cases, the proposed requirements for a component cannot be met. In other cases, the requirement can be met or exceeded more easily than expected. In either case, the resolved specifications from the detailed design process are periodically injected back up to the architecture design process's token-based performance model to investigate component requirement reallocations and to ensure that the emerging design still meets the overall requirements.

Figure 1 - 2: Levels of the Design Process.


next up previous contents
Next: 2 Introduction Up: Appnotes Index Previous:Appnote TOKEN Index

Approved for Public Release; Distribution Unlimited Dennis Basara