Chapter 5 Virtual Prototypes and mixed abstraction modeling

In the preceding chapters we talked about models and the strengths and weaknesses that they posses. In this chapter, and the chapters that follow, we start to see how those models are combined and applied to solve some of the problems associated with ESL. Unsurprisingly, most ESL methodologies that have been constructed start with a model that is generally called a [ACR] System-Level Virtual Prototype (SLVP). This is the closest thing that the electronics industry has to an executable specification.

A SLVP is a fully functional software model of a system, including the processors, memories, I/O and user interface, and is capable of running unmodified production code, including the drivers, OS or application. Speed is of the essence with these prototypes as they must run as close to real time as possible so that execution times for long operations are kept to a reasonable length. Other concerns that users may have about SLVPs are time of availability, accuracy, development cost, bring up cost, debug insight, execution control and system interfaces to the environment in which a system resides. We will talk about these later in this chapter.

Early SLVPs were proprietary and constructed for a particular purpose, such as hardware-software partitioning, architectural exploration or to enable early integration and testing of software. Each of those posed different requirements on models where certain types of decisions required specific accuracy of models. For example, a SLVP designed for early software development may only make sense if it is available early enough prior to silicon or physical prototype or if it offers significant advantages like debug insight and execution control. We have already talked about the problems that this caused, primarily related to the inability to migrate models from one SLVP to another or promoting an effective 3rd party IP business. Thus these SLVPs were also targeted to one or a small number of industries such that the quantity of models required was limited.

While we tend to think of the SLVP as something new, the software community has been using similar concepts for quite a while. These earlier prototypes were not fully functional and often were less useful for the lower layers in the software stack. But the software community has shown that it is very willing to adopt these systems. For example, when Apple released the [ACR] software development kit (SDK) for the iPhone [BIB Apple 0803], which includes a software simulator, it was downloaded 100,000 times in the first four days of its availability, and that number reached 250,000 [BIB Apple0806] over the following three months.

SystemC and TLM 2.0 changed this dynamic, in that the industry now has a respectable way of integrating models together and promoting interoperability. What we see today are SLVPs that are in transition from being closed proprietary systems to open systems based on standards. This transition cannot happen overnight, not just because of the tool development that is required, but because of the large number of models that were created using the old languages. Models are one of the biggest roadblocks when it comes to the adoption of SLVPs, so enormous value is still attached to these legacy models.

In the next few chapters we will see that there are still many different types of SLVP, each one targeting a specific task within an ESL sub-flow. Each of these in effect becomes the anchor for a sub-flow with, for example, very specific requirements on model accuracy, which has yet to be fully integrated into one continuous flow. It is thus important to decide what you want to accomplish with a SLVP for before deciding if one or another approach is the right one.

In this chapter, we will be looking at a SLVP of the hardware system that is specifically intended to be used for the development and testing of software. It thus concentrates on processors, busses, memories and abstract notions of hardware blocks. By performing this early integration it enables architectural choices to be made in both the hardware and software architectures maximizing the utilization of resources, optimizing power consumption and ensuring that the interface between the hardware and software is well constituted. Perhaps even more importantly, it enables the development and testing of software a lot earlier than has been possible in the past. Hardware / software co-simulation started this migration path, but this modeling technology makes it possible to start platform development at the same time as the hardware is being designed. As soon as this has been completed, the software team has a full binary compatible model on which they can start to develop and debug the software, shaving months off of the schedule and in many cases taking software off the critical path in the development flow.

In addition, this chapter will demonstrate some of the process of change in the industry. Aspects of the SLVP described here preceded the introduction of SystemC and TLM 2.0 and were thus proprietary and closed. Synopsys has always been an adopter and promoter of standards and thus when a suitable standard emerged they knew the importance of following it and converting the systems that they had to be compliant to those standards. This is not an easy process. Legacy is an important part of this industry, not only in terms of tool support, but also in the models that have been created. Synopsys had a huge library of models which have often been cited as one of the main holdbacks in ESL adoption. To lose those models would have been a setback, not only to Synopsys but potentially to the industry adoption of SLVPs in general.

It should thus be noted, that aspects of both the old and the new will be discussed in this chapter, but that Synopsys is dedicated to the future based on standards. At the time of the actual publication of this book, it is likely that more of the legacy capabilities will have been transferred into the System/TLM features of the environment.

5.1 Introduction
     5.1.1 Historical perspective
     5.1.2 Use Models
     5.1.3 Technology
     5.1.4 Interfaces
     5.1.5 Processor Models
5.2 System Prototypes
     5.2.1 Development environments for software development
     5.2.2 Hybrid Hardware - Software Based Development Platforms
     5.2.3 Hybrid System Prototyping use models
5.3 Constructing a System Level Virtual Prototype
     5.3.1 Modeling Languages
     5.3.2 Model Creation
     5.3.3 Model Import
     5.3.4 Model libraries
     5.3.5 Virtual devices
     5.3.6 Modeling the Environment
     5.3.7 Tying it all together
     5.3.8 Documentation
5.4 Running the prototype
     5.4.1 Debug
     5.4.2 Analysis
5.5 Verification
     5.5.1 Platform Deployment
     5.5.2 Verification Methodology Manual
     5.5.3 Building the RTL testbench
     5.5.4 Regressions
5.6 Example
     5.6.1 The application
     5.6.2 The bottom line
5.7 The Future
5.8 References

Errata

Feedback