Once the design has been partitioned into the basic blocks targeted for implementation (as discussed in Chapter 8), many of the fundamental aspects of both the modeling space and the management space change drastically.

There are now both hardware and software models that need to be executed together. There are also functional and architectural models—the former often expressed as modified executable specification models that may represent functions that have been mapped to hardware or software implementations; the latter often representing hardware block behaviors. When the hardware block is a processor, the architectural model is usually some kind of instruction set simulator. In addition, there is a requirement that the models collectively support the desired kind of analysis and debug—too much detail and the analysis will be too slow or too late; not enough detail, and it will not provide the necessary information.

Also, for verification—and performance—purposes, it is very useful if the hardware and software models of the partitioned components can be executed with the pre-partitioned models—for example, functions mapped onto architectural components that implement or support the implementation of those functions. Chapter 10 discusses in more detail the post-partitioning, pre-implementation verification processes and the use and reuse of models in that regard.

Finally, the management of the design and verification teams also needs to be carefully considered. Clear responsibilities for the different aspects of the design must be maintained. As we know, at this stage the software and hardware teams are often totally separate, with very little communication between them. However, it is not just the hardware and software teams that need to have clear responsibilities for their parts of the design: there will be many aspects of the design that should remain the responsibility of the pre-partition system design team or architect. For example, the interfaces between the partitioned components (hardware or software) are a result of the overall system design, and there may also be pre-partition components still used for verification. The system architects also retain the best overall view of the design and product intent and the responsibility for this, and should be consulted as the post-partitioning analysis, and then implementation and verification processes, proceed. This is because tradeoffs do not end with system partitioning.

9.1 Roles and Responsibilities
9.2 Hardware and Software Modeling and Co-Modeling
    9.2.1 Single Model
    9.2.2 Separate Model: Filtered/Translated
    9.2.3 Separate Hosted Model
    9.2.4 Modeling Infrastructure and Intermodel Connections
9.3 Partitioned Systems and Re-Partitioning
9.4 Pre-Partitioned Model Components
9.5 Abstraction Levels
    9.5.1 Standardizing Abstraction Levels for Interoperability
    9.5.2 Moving between Abstraction Levels
9.6 Communication Specification
9.7 Dynamic and Static Analyses
    9.7.1 Metrics and the Importance of Experience
    9.7.2 Functional Analysis
    9.7.3 Performance Analysis
    9.7.4 Interface Analysis
    9.7.5 Power Analysis
    9.7.6 Area Analysis
    9.7.7 Cost Analysis
    9.7.8 Debug Capability Analysis
        9.7.8.1 Observability
        9.7.8.2 Controllability
        9.7.8.3 Correctability
9.8 Provocative Thoughts
9.9 Summary
9.10 The Prescription

Errata

Feedback