Unified Modeling in C++ & SystemC

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

1. Models developed are not synthesizable
2. 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

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

3.1.2 Disadvantages

1. Lot of effort involved in complex design
2. Limited data types.
3. Very limited scope of reusability.
4. Slower simulation speed for large designs.
5. 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

1. Higher simulation speed
2. Ease in developing complex designs
3. Large number of data types available
4. Higher scope of reusability
5. Ease of migration from hardware to software
6. Enhanced Debugging features

3.2.2    Disadvantages

1. Sequential nature of language
2. 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