In Chapter 6, we discussed the issues and approaches in specifying and modeling a design at the ES level. The main ideas discussed in that chapter were multiple domains of specification, the notion of executable specifications, model-based design and development, and some of the main languages for specification, including SystemC, the UML, and XML. Other specification notations that are important include The MathWorks tools MATLAB and Simulink, multimodel notations such as Ptolemy, and dataflow notations such as SPW and COSSAP. The recent SysML profile based on UML is also attracting interest.

In this chapter we discuss the analysis of systems based on the specifications and models built in the previous chapter. We start with pre-partitioning analysis. Prepartitioning analysis refines the system specification models and defines additional or elaborated design constraints derived from the high-level requirements, before the main partitioning of the design into hardware and software; into hardware blocks and software functions; and, in the case of multiprocessor systems, into a specification of multiple processors and their interconnection. However, the division of the ESL design process into rigid pre-partitioning and partitioning phases, although allowing easy explanation of a design flow, is not very representative of real design. First, a product design may be based on a platform, where part of the design is prespecified and pre-implemented and validated, and the new (or derivative) design adds new or modified functionality. In this case, of course, many of the partitioning decisions are already made, although for the new functions, it may be unclear at first how much might be implemented in hardware blocks and how much in software code, or the way in which communications between the blocks will be established. Second, for any design, it is quite unrealistic to prevent all implementation-level decisions, including partitioning ones, to creep into the mental design process while analyzing the specifications. No matter how much one may attempt to defer partitioning decisions, human nature always seeks to divide the complex specification into an agglomeration of simpler functions, to think along software lines when reading software code, to think of hardware communications choices when looking at the data and control information that must be transferred in a complex algorithm. Notwithstanding human nature, it is best at least to attempt to defer partitioning decisions until the analysis is done, because non-obvious yet superior decompositions may be missed with a premature rush to a decomposed and partitioned specification.

Although static analysis methods are useful, dynamic analysis based on executable models and specifications is far superior in its ability to give the design team a firmer grasp on specification details and design constraints, so every attempt should be made to ensure that at least part of the specification consists of executable models. We end this chapter with the discussion of a case study that deals with the analysis of a simple media processing application, and after some provocative thoughts, give our prescription for pre-partitioning analysis.

7.1 Static Analysis of System Specifications
    7.1.1 The Software Project Estimation Heritage—Function Point Analysis
    7.1.2 Analysis of Hardware and Hardware-Dominated System Specifications
    7.1.3 Traditional “ility” Analysis of Systems
    7.1.4 Requirements Analysis
    7.1.5 New Specification Methods—Rosetta
    7.1.6 Conclusions on Static Analysis
7.2 The Role of Platform-Based ESL Design in Pre-Partitioning Analysis
7.3 Dynamic Analysis
7.4 Algorithmic Analysis
    7.4.1 Commercial Tools for Algorithmic Analysis
    7.4.2 Research Tools
        7.4.2.1 Ptolemy
        7.4.2.2 POLIS/Metropolis
        7.4.2.3 SpecC
7.5 Analysis Scenarios and Modeling
    7.5.1 Example of Analysis of Signal Processing Algorithms
    7.5.2 Filter Design Example
    7.5.3 Complete System Specification to Silicon Methodology for Communications and Multimedia Signal Processing
    7.5.4 Software Radio Example
    7.5.5 How Much Analysis Is Enough?
7.6 Downstream Use of Analysis Results
7.7 Case Study: JPEG Encoding
7.8 Summary and Provocative Thoughts
7.9 The Prescription

Errata

Feedback