Chapter 8 Refining Hardware models

Chapter 5 looked at the creation of a system level virtual prototype that was used primarily for software and system level functional verification. It addressed many of the issues associated with adding major architectural elements, such as processors, busses and memories. Many of the issues associated with HW/SW partitioning were also dealt with in chapters 6 and 7. These chapters took a top down approach to the problem. They started from the highest level of functional description and refined the models by adding information associated with the major architectural decisions. In this chapter we will introduce a flow in which the hardware is modeled incrementally and integrated into a system that may then be used for hardware verification, more detailed architectural exploration and software integration. These platforms, are created at the behavioral transaction level and often referred to as transaction level platforms (TLP)s.

In this chapter we will look at the creation of such a platform, how it can link with software and discuss the adaptation of the hardware models to include concepts such as timing and power. These will be used to make further tradeoffs in the architecture and micro-architecture of the blocks. The TLP model that is created can represent the actual hardware, rather than just the functionality of it. Chapter 9 will carry some of these concepts further by looking at the hardware implementation path using high-level synthesis, but in this chapter we will focus on the manual transformations and the integration of blocks into a transaction level platform.

The goal with any model is to contain just enough information such that the relevant decisions can be made. If the model does not contain enough information, then the accuracy or fidelity of the results obtained is unreliable. If it contains too much information, then performance suffers to the point that it may not be possible to extract enough relevant data to correctly make decisions. Thinking back to the definition for ESL, it is the use of appropriate abstractions to reach comprehension and to improve the success rate of an implementation.

If we need to make architectural decisions about the hardware, then we need something that can adequately model the flow of information through and between the major architectural blocks in the system. This is already somewhat different from the prototypes that were introduced in the previous chapters, in that this prototype starts to create the structure of a solution, rather than containing just a functional decomposition of it. This is an important distinction and one that is essential to most hardware implementation flows.

The reason for this is that the structure creates a model hierarchy which is an essential element in all of the hardware description languages. It is this hierarchy that enables multi-abstraction modeling, since the structure can be preserved while substituting blocks at different levels of abstraction with the aid of interface models, usually called transactors. When changes in this structural hierarchy are made, we lose some ability to comprehend the transformations that are made, or the ability to execute tools that cross this boundary without a lot of tedious and error prone name mapping. For example, if a design becomes flattened during a synthesis operation, then equivalence checking would have to work out, or be told, all of the name mappings between the pre and post synthesized models. It also then becomes impossible to replace part of the post-synthesized design with an abstract model because the interfaces have been removed. The interfaces thus become contracts between the blocks.

In this chapter we will also examine the concept of positive and negative verification. While many people may be familiar with block level verification, those blocks have to be integrated into the system. In many cases these blocks may be IP blocks that come from a third party. While a block may have no known bugs, this is not a sufficient requirement for it to work correctly within the context of a system. The block must match the expectation of the system specification. This creates several different verification needs. The use of such a transaction level prototype can ensure that the interface specifications are correct before embarking on the implementation of the blocks. In this way it eliminates the possibility of integration errors, and this is highly beneficial in terms of time and quality. When IP blocks are being re-used, or brought in from outside of the organization, it provides the platform within which they can be evaluated and integrated early in the development process, rather than waiting until the end to find such problems. It also provides a suitably fast platform such that the low level software interfaces can be exercised and verified.

Another important aspect of such a platform is that it supports incremental refinement and verification. In this chapter we will show how timing and power information can be annotated onto the platform without the necessity to modify the functional model itself. This allows many choices to be evaluated and verified within the system level context. When architectural problems are found late in an implementation, it can create severe project delays while the impacts of those problems are assessed. Changes that are necessary in one block often influence many of the surrounding blocks. The notion of immediate verification of decisions provided by a hardware platform prototype means that there are less potential problems to be found down the road to implementation.

8.1 Introduction
8.2 Transaction Level Modeling comes of age
8.3 Model abstractions
     8.3.1 Terminology
     8.3.2 Model Taxonomy
8.4 Roles of the TLM platform
8.5 Contextual verification
8.6 Creating models
     8.6.1 Model Refinement
     8.6.2 Multi-abstraction
     8.6.3 Verification
8.7 Timing
     8.7.1 Timing Policies
     8.7.2 Delay
     8.7.3 Split
     8.7.4 Sequential
     8.7.5 Pipelining
     8.7.6 Putting it all together
     8.7.7 Timing Callbacks
8.8 Power
8.9 Creating a model
     8.9.1 Using Model Builder
     8.9.2 Synchronization
     8.9.3 Importing models
     8.9.4 Model Abstraction
     8.9.5 Building a System
     8.9.6 Navigating a System
8.10 Example
     8.10.1 Building the system
     8.10.2 Running the simulation
     8.10.3 Analyzing the system |
     8.10.4 Inserting an ISS model
8.11 Conclusions
8.12 References

Errata

Feedback