Unified Modeling in C++ & SystemC

by Shanthamoorthi Velusamy & Anurag Mehta
Wipro Technologies
Bangalore

Abstract

Embedded processors in electronic systems are tuned to few application and with the increase in design size and complexity the time available for System Verification and Software Development is falling short and with next few decades seeing a rapid progress in the area of multimedia and gaming application whose time of development is very short seeing the market constraints. So for design falling in this category there should be a fast and efficient approach for the Product Development so that ends product is successful and does not fall prey to short development time available.
This Paper tries to present the usefulness of modeling for system simulation, and Product Development and presents and practical use of modeling in simulation of a general purpose processor.

1 Introduction

Many design project teams and research and development groups are working to significantly reduce system verification runtimes and perform system verification earlier in the design process. One solution successfully being used to address both issues at once is the creation of higher abstraction models of important system components, typically using regular C/C++ or enhanced or modified flavors of C, such as SystemC.
Once a library of models is available, a home-grown or commercial C or mixed simulation environment can be used to execute the C-based system design. Then, high-level hardware-software co-verification can be performed if an interface mechanism exists to run embedded host code on a processor core model in conjunction with the external C modeling environment. This, of course, also requires the availability of a model of the embedded processor that can run code and be instanced in the design.
With a mixed, C and HDL simulation environment, the high-level models can facilitate faster system verification runs at many stages in the design process for many purposes. This allows C models to become useful before everything in the design is modeled in C.
As designs are getting more complex in terms of functionality, Application supported and gate count it is getting difficult to translate the Architectural model in to behavioral model using hardware languages seeing the effort and time involved. Model provides application developers the ability to evaluate without the necessity of hardware platform. As design get more complex, system architects model in Software languages to iteratively refine from an architectural model to hardware implementation. Modeling helps in translating theoretical thinking into practical application.

2 Modeling

Modeling in past has been an approach to emulate the efficiency and feasibility of System. The foremost question modeling poses is what platform to use should it be some hardware language or should we use our conventional software languages because software languages being sequential in nature how do we emulate the parallelism found in hardware and if we use hardware language then up to what level can we seeing the design complexity. Another question modeling poses is how much effort do we need to put in because any effort put into one activity should materialize in to reduce effort into another activity otherwise that is just an another overhead to the design’s development cost.

So to materialize the effort put into modeling we need to modify our approach in modeling so that the design can be reused with little modification or if we possible no modification and also aid into reduced effort in design and verification and also software development.

2.1 Classification

Modeling is also a stage by stage activity

Architectural Model
This stage contains very abstract level of details and only deals with architectural issues and is used to freeze the System Architecture

A typical application of high-level model simulation is the verification of system performance against the targeted throughput speed, which might be dependent on, for example, memory configuration, bus topology, or hardware-software partitioning decisions. These high-level models can contain enough timing detail to give the designer a good estimate of the cycle counts for system processes split between hardware and software.

Developmental Model
The model in this stage is very close to hardware implementation and is used to develop software, evaluate system performance and deals with interoperability issues.
If assessing throughput is the main goal of a particular simulation, then the models at this stage do not need to correctly perform the required processing. They can simply pass back data of the correct type and consume the right number of cycles. This can be refined to a more accurate model later in the design process

Product Model
This Stage assumes that model is exact replica of hardware unit so it can be used by other team members for developing there system
Once the main architecture decisions have been made, this same high-speed simulation environment can be used as a firmware development platform.

2.1 Advantages

Figure: 1

Early start of Software development can be done with the availability of Development models and Verification team can reduce there effort in developing logic to get the right results the design can be passed if both the outputs of RTL and model match.
The biggest advantage of developing models is to come with the references which are exactly the replica of the Architecture document these references helps in validating the RTL implementation. The biggest pitfall of developing a reference model is if there is same bug in both RTL and model so that bug goes undetected. So this can be avoided to a certain extent by have independent implementation approaches.

Figure: 2

2.2 Disadvantages

Models developed are not synthesizable
How much comfort is there in reusing the design

With the present technology available the model might not be synthesizable but if later down the time if they can be synthesizable then it is just the reuse of the models available. Reusing the design puts constraint on the level of abstraction we put in our design so with greater reusability there will be higher amount of abstraction in the model

3 Programming Languages

What programming language to be used should it be Hardware language or Software language. Both of them have there own advantages and disadvantages.

3.1 Hardware Language

3.1.1 Advantages

Language being parallel in nature so resembles hardware nature
Can be used to easily transported to Synthesis format

3.1.2 Disadvantages

Lot of effort involved in complex design
Limited data types.
Very limited scope of reusability.
Slower simulation speed for large designs.
Limited Debug Capability

Due to nature of language it is very easy to achieve observe parallelism in the design but very limited availability of data types and constructs poses the biggest challenge and debugging is very limited on you need to write down your custom debuggers and interface with the Simulator so that involves a lot of effort.

3.2 Software Language

3.2.1 Advantages

Higher simulation speed
Ease in developing complex designs
Large number of data types available
Higher scope of reusability
Ease of migration from hardware to software
Enhanced Debugging features

3.2.2 Disadvantages

Sequential nature of language
With present automation in synthesis available only hardware languages are synthesizable

So there has been a recent push towards C++ modeling of IC and System designs through the use of libraries like System C. System C helps in integrating various hardware blocks which communicates to each other at every clock cycle it is because of System C which makes Cycle accuracy achievability easy.

C++ being a well known programming language so a large number of communities are available for coding that. Saving money by making use of publicly available and thoroughly tested compilers. C++ provides ease of transportation to different platforms. Object oriented Programming allows us to implement true system refinement because we are able to instantiate the way the Object communicates with one another through classes and methods.
The biggest advantage is the single greatest source of intellectual property for reusability is algorithms written in C and C++.

3.2.3 Challenges in C/C++ based design
A growing number of embedded system developers are either implementing or investigating these methodology changes. A shift of this significance should not be expected to be trouble-free. Some of the typical problems to be faced by these pioneers are:

Modularity of the compile and link process. There's evidence that this can be a significantly time-consuming process in some environments, especially within a tight verify->modify->re-verify loop.
Model creation resource and expertise.
Maintenance of the simulation environment. The impact of this depends on whether an in-house or commercial environment is used. The normal make-versus-buy decision must be made here. The availability of quality commercial solutions is critical.
Maintenance of the models as the design progresses. Keeping the system-level models in synch with the detailed RTL is important if they are to be reused at the detailed verification level and if they are to be used by software development teams. This also helps with reuse between product generations.
Availability of models from third-party IP suppliers.
Interfacing models from different suppliers (both internal and external), at different abstraction levels (for example, signal versus transaction), or in different languages.
Accuracy concerns. Those who are used to working at the RTL level and below are not concerned about making major design decisions based upon less detailed hardware models. This also comes into play when reusing the abstract models in a mixed environment.
Links to actual implementation. If the usefulness of the abstract models begins and ends with the high-level system simulations, then the ROI of the modeling work starts to look less attractive for some applications.

3.2.4   Accuracy concerns
The question as to whether seasoned hardware engineers trust a C-model to be a good representation of the design intent has come up often in the author's discussions with design teams, especially if that model is externally sourced. Alternatively, the concern might be that the C descriptions and the HDL descriptions do not match or will diverge over time, especially if the two simulation environments are very different.
Having an environment that allows the C-models to be run in the same simulation tool with the same test bench certainly helps alleviate these fears and bridge the gap between abstract system modeling and real design implementation. Whatever solution is chosen, some thought needs to go into a verification strategy that ensures the consistency of the different abstraction models, just as is done today between the RTL and gate level.

4   Implementation

4.1 Simulation Cycle

Figure: 3 Simulation Cycle

4.2 Design Hierarchy

The foremost thing in implementing any design is the design hierarchy needs to be formed out on the basis of communication between different hardware blocks.

4.3 Memory Allocation

a) Register Files and Memory

All the Register files and Memory units are given fixed memory allocation till the time simulation is running. They are passed from top as reference pointers and made available to lower units.
All the register files have to keep track of there data hazard status and they maintain there individual pipe for data to be made available in forwarding stage. Depth of the Pipe is decided by the maximum number of forwarded data that can be made available at any stage.
Special care has to be taken care in choosing the data type of the Register and memory because C and C++ convert a negative number into its 2’s complement so all the register files should be declared as unsigned data types and union type of unsigned and signed can be used to do operations.

b) Execution or Process Units

All the Execution units are allocated memory only when they are called and memory is freed as soon as they are in wait state.
The depth of the Pipe in execution units is determined by num of simulation cycle the data takes to get processed.

4.3 Process or Execution Unit

This is the unit which actually schedules all the events of Data Manipulation, Register write and memory write backs. Process can be categorized into four states

Active: currently being processed by the simulator
Ready : not currently active, but ready to be active
Holding: waiting for an interval of simulated time to pass
Waiting : waiting (Queue) for an event to happen

A Process is a C++ procedure which executes the created statement several simultaneously active instances of the same process, executing in parallel (Simulation time) even though there is a single processor executing event sequentially.
For achieving this kind of behavior there is a need for proper queuing of events so a wise selection has to be made while choosing Data structure. All the data structure should have a valid field which is propagated through the pipe and all the process are triggered seeing this field.

4.4   Queuing

Queuing of events is the most critical decision to exactly simulate the hardware behavior. Especially in the processor design where multi- forwarding paths are available and there is inters thread dependencies to be taken care on data.

All the register files are array have to keep track of the stage in which data is there and a status has to be made available on data hazard. As soon as data is available in Data forwarding state the busy status of that register address is reseted and data made available to further stages if any consequent stage sees the data hazard flag set for that address he makes the valid bit of the data structure to zero that is equivalent inserting a hold state in Process.

4.5   Signaling Exceptions

All the Exceptions in data manipulation stage can be done by specific algorithms only so here lays the greatest reusability of intellectual property.

4.6   Instantiation

The most advantageous feature of using C++ modeling approach is it’s ease of portability for simulation of a specific block whole of the system need not be instantiated only particular block whose performance is to be evaluated can be instantiated this helps in having much faster simulation.
As C++ executables are available they just need to be integrated in any hardware simulator and can be used and almost all the commercial simulator provide feature for that.

4.7   Software Development

Software development can simultaneously start as soon as Architectural model is available so with architectural model the application can be tested for functionality and implementation algorithms can be tested later on as development model are made available it can be evaluated for Performance.

4.8   Test Case Development

Architectural model can be used for testing the verification plan in the initial stages and later on with the availability of developmental model test vector verification can be done and results of test vectors can be evaluated and later as product model is available whole of the system can be tested for exact hardware behavior and then it is just comparing the results produced by RTL and Model for full System Verification.

5   Results

The results available till now are only theoretical because the hardware design is yet to fully implemented but using the software model of the design application development and verification vector development and testing has gone way ahead as compared to if only RTL were used to do the job.

"Seaway has developed virtual prototyping techniques using VTOC to gain the commercial advantages of starting and completing software development and system verification earlier in the design cycle", according to Jeremy Bennett, Tenison EDA CEO.

6   Acknowledgements

I would like to thank Sanjeev Patel, Mahesha Puttanna, Rajesh Kumar Neermarga, Venkatasubramanian Seetharaman, Sivakumar Balasrinivasan and Ajay Kesava Chandran for there valuable advice and support through this work.

References

[1]   ICCAD 2000 Roundtable Participants: Rahul Bhatt (Intel), Giovanni De Micheli (StanfordUniv.), Daniel D. Gajski (Univ. of California, Irvine),Christopher K. Lennard (Cadence), Stan Liao (Synopsys), John Sanguinetti (CynApps), and Patrick Schaumont (IMEC).

[2]   Presentation on Methodology for Hardware/SoftwareCo-verification in C/C++ by Luc Séméria   Computer System LaboratoryStanford University and Abhijit Ghosh from Synopsys Inc.

[3]   Presentation on Resolution of Dynamic Memory Allocation andPointers for the Behavioral Synthesis from C by Luc S.m.ria Giovanni De Micheli Computer Systems Laboratory Stanford University and Koichi Sato System LSI Design Engineering Division NEC Corporation and

[4]   Presentation on Simulation with CSIM by E. J. Kim CS Dept. TAMU

[5]   Instruction Encoding Synthesis for ArchitectureExploration using Hierarchical Pocessor Models by Achim Nohl, Volker Greive,Rainer Leupers, Oliver Schliebusch, and Heinrich Meyr