Journal of Global Research in Computer Sciences
MenuISSN: 2229-371X
ISSN: 2229-371X
Gajendra Kumar Ranka*1, Dr. Manoj Kumar Jain2
|
| Corresponding Author: Gajendra Kumar Ranka, E-mail: Gajendra_ranka@hotmail.com |
| Related article at Pubmed, Scholar Google |
Visit for more related articles at Journal of Global Research in Computer Sciences
The design of modern embedded systems requires automated modelling tools for faster design and for the study of various design tradeoffs. Such tools put together constitute an integrated environment where the designer can write the high level design specifications in a language and use these tools for automatic generation of system specific tools. The major contribution of this paper lies in design and development of retargetable simulator and validation of the simulator with different simulators like OVPSim {Open Virtual Platform}. Proposed simulator measures cycle count for application executed on processor. This paper discusses the OVP Simulators, its working and the different customisations that are required to execute the benchmark application on this Simulator.
Keywords |
| ASIP, Application Specific Instruction Processors, Retargetable Simulator, Embedded Systems, Processors, ASIP Simulators, Design Space Exploration, OVP Simulator |
INTRODUCTION |
| Modern electronics are controlled by processors that must meet strict constraints in terms of performance, cost, size and power consumption. In a competitive market place, performance and cost are critical in differentiating one product from another. In addition, low cost and superior performance increases the likelihood of broad consumer acceptance of new electronic products. Size constraints limit the amount of functionality that can be incorporated into product design. Finally low power consumption is necessary for portable electronic equipment that is battery operated. |
| An ASIP is a processor that is designed to efficiently execute the software for a specific application. Regardless of whether a newly designed ASIP or a pre-existing processor core is used, the selected processor should be well suited for the given application. Although incorporating a complete system on a single IC may improve performance, cost, and power consumption requirements, such a high level of integration constraints the size of the system components. |
| Steps in ASIP Synthesis |
| Various methodologies have been reported to meet these requirements. All these have been studied and five steps are suggested for synthesis of ASIPs [1] |
| Application Analysis: |
| Application is normally written in High level language. Proper analysis of this application under consideration is done and the output of the information is stored in some suitable intermediate format. Sometimes SUIF can be used as intermediate format. Analysis of the application is essential as it provides the essential requirement from the application that can guide for hardware synthesis as well as instruction set generation. |
| Architectural Design Space Exploration: |
| Output of the Application analysis step along with the range of architecture for Design Space Exploration is used to select a suitable architecture. Possibility of suitable architecture is explored and the best architecture is selected that satisfy the different characteristics like minimum hardware cost, performance and power. |
| Instruction Set Generation: |
| Till this step we have identified application requirements and the suitable architecture. Based on this input instruction sets are generated in terms of required micro operation. This instruction set is used during the further steps for code synthesis and hardware synthesis. |
| Code Synthesis: |
| Till this step, architecture template, instruction set, and application are identified. This step generates the code. Generated code can be retargetable code generator or compiler generator. |
| Hardware Synthesis: |
| In this step the hardware is generated using the ASIP architectural template and instruction set architecture using standard tools |
| Architecture Design Space Exploration |
| System on Chip designs has various goals and objectives. Design space consists of a set of parameters. The main focus of designers lies on minimal cost and maximal performance, low power, high reliability etc. Architecture under consideration requires a range of good parameter to explore. These parameters may take up the different values. Some of the parameter suggested can be functional unit of different type, Storage units, interconnect resources, number of memory units etc. Further the parameters can also be extended to size of instruction cache and size of data cache. This has been a very crucial step for ASIP design. Design Space exploration helps the SOC designers to make the trade-offs between these goals and arrive at the "optimal" design. Designers explore changes to the architecture or the instruction-set of the processor-memory system. Designers select a suitable architecture that satisfy the performance and power constraint and having minimum hardware cost. Architecture is defined using some suitable architecture description language (ADL). |
| Techniques for Performance Estimation |
| Two major techniques have been used for performance estimation. They are scheduler based and simulator based. In Scheduler based approach, application is scheduled to generate the output like cycle count. Architectural component is already identified at this stage. Target processor architecture can be given in the form of description file. |
| In Simulator based approach, application under consideration runs on a simulator. Depending upon the architecture selected in above steps, application is simulated to compute the performance. |
| Processor Models are extensively used in system design process. The system design process starts with an application and its implementation. Then the model is tested for its performance and other aspects. In such a scenario an integrated environment is required for the designer where several tools exist like simulator, assembler, compiler etc. Rewriting the tools after each design change is a tedious job. Hence automatic generation of these tools is more desirable according to the design changes. |
| Existing Retargetable Simulators Approaches |
| Retargetable functional simulator (Fsimg) [2] focus on tools that deal with the machine language of processors, like assemblers, disassembler, instruction set simulator etc.Retargetable Function Simulator (Fsimg) was designed using Sim-nML language which is primarily an extension of the nML [3] language for processor modeling. Fsimg takes the specification of the processor in the intermediate representation [4] and an executable for the processor in ELF [5] format and generates a functional simulator (Fsim) which in turn gives the functional behaviour of the processor model for the given program. |
REALTED WORK |
| Over the past several decades a considerable amount of research has been performed in the area of computer architecture simulation. These simulators can be broadly divided into several categories: full-system simulators, Instruction Set Architecture (ISA), and retargetable Simulators. Each category serves an entirely different purpose, but all have been used for the advancement of computer architecture research. The purpose of full-system simulators is to model an entire computer system including the processor, memory system and any I/O. These simulators are capable of running real software completely unmodified just like a virtual machine. There are many simulation suites that take this approach, including PTLSim [6], M5 [7], Bochs [8], ASIM [9], GxEmul [10] and Simics [11]. Simics has several extensions that constitute their own full-system simulators such as VASA [12] and GEMS [13]. |
| ISA simulators are less descriptive than full system simulators. Their objective is to model processor alone.ISA simulators performs the various functionalities. It simulate and debug machine instructions of a processor type that differs from the simulation host, it also emphasis on investigating how the various instructions (or a series of instruction) affect the simulated processor. Hence modeling of the full computer system is unnecessary and would impose additional delay and complexity. Example of this type of simulator includes SimpleScalar [14], WWT-II [15], and RSIM [16]. Over the past decade, a few interesting ADLs have been introduced together with their supporting software tools. These ADL include MIMOLA, UDL/I, nML, ISDL, CSDL, Maril, HMDES, TDL, LISA, RADL, EXPRESSION and PRMDL. |
CHALLENGES IN ASIP DESIGN` |
| The development of a processor is a complex task, involving several development phases, multiple design teams and different development languages. The key phase in processor design is architecture specifications since it serves as the basis for all remaining design phases. Although Hardware Description Languages (HDLs) are designed for architecture implementation, in a traditional design flow, these languages are also often used for the initial specification of the processor. In this design phase tasks, such as hardware/software partitioning, instruction-set and micro-architecture definition is performed. Based on the architecture specification, both the hardware implementation and development of software is triggered. Both tasks are basically independent and therefore performed by different experts and design methodologies. |
| Hardware designers use HDLs such as VHDL or Verilog, while software designers mostly utilize the C/C++ programming language. In addition, the target processor needs to be integrated into the SoC and the application software needs to be implemented. Communication between the design teams is obviously difficult because of the heterogeneous methodologies and languages. Considering the traditional processor design flow, the strong dependencies between the design phases imply a unidirectional design flow and prevent even minor optimizations. Due to the different development languages, changes to the architecture are difficult to communicate and inconsistencies are very likely to appear. The Complexity of processor design even increases in ASIP design, since optimizations targeted to particular applications are mandatory. Mapping an architecture to a given application means moving through a design space by axes such as flexibility, power consumption, clock speed, area and more. |
| Every design decision in one dimension constraints other decisions, for example Architectural features Vs design time, |
| Design time Vs physical characteristics, |
| Physical characteristics Vs flexibility |
| Flexibility Vs verification effort |
| Verification effort Vs architectural features |
| It is obviously not possible to move through this design space by applying the traditional processor design methodology. A unified design methodology is required, which provides a common basis for all design phases. It must be suitable for all design engineers involved. |
EXISTING RETARGETABLE SIMULATORS |
| Anahita Processor Description Language (APDL), APDL [17] is one of the most recent contributions in the area of retargetable simulator. The language was introduced in 2007 by N. Honarmand et al. from the Shahid Beheshti University, IRAN. The Primary difference between APDL and other ADLs is the addition of Timed Register Transfer Level (T-RTL), which enables the simulation designer to define the latencies and hardware requirement of the processor operations. This separation of configuration data enables APDL to better integrate with external software for analysis as the T-RTL data is organized separately from the remainder of the processor description. Moreover, APDL can describe both instruction and structure descriptions of a target processor. |
| The Pascal-like syntax of APDL is clearly more intuitive than many other ADLs such as LISA and EXPRESSION. While the language is easier to read and understand, the researchers have not yet implemented a compiler to produce simulations. Furthermore, despite APDL's relative ease, users are still faced with the task of learning the details of the syntax. |
| ISDL [18] was introduced in 1997 by G.Hadjiyiannis, S.Hanono, and S. Devadas from Massachusetts Institute of Technology. The purpose of ISDL was to provide a language for describing instruction sets along with a limited amount of details of a processor structure for the automatic construction of compilers, assembler, and simulators. ISDL enables users to define their target processors in several ways. First, users can define operations, their format, and the associated assembly language instruction. Second users can define the storage resources available to the processor, including the register file and memory. Third users can define constraints in the processor such as instructions requesting the same data path, or restrictions regarding assembly syntax. |
| ReXSim [19] was introduced in 2003 by a computer architecture research team at Irvine. ReXSim is an extension of EXPRESSION language which sought to improve simulation speed by integrating a novel method of decoding instructions of the simulated program before execution of the simulation. As a result, the instruction decoding process was removed from the execution loop of the simulator, and thus improved the simulation speed significantly. Using this method, the team was able to produce retargetable simulations that showed performance in excess of major simulators like SimpleScalar, which is widely considered to be a simulation performance benchmark. |
| Reduced Colored Petri Net (RCPN) [20] was introduced in 2005 by M.Reshadi and N. Dutta from University of California, Irvine. RCPN takes a vastly different approach to retargetable simulation, in which pipelines are modeled using a simplified version of Colored Petri Nets (CPN). Petri Nets are graph based mathematical method of describing a process. The nodes of the graph represent particular discrete events, states, or functions, and the graph edges represent the transitions of data between nodes. The transitions can be enabled or disabled based on conditions specified at the nodes. |
| The purpose of RCPN is to provide retargetable simulations for modeling of pipelined processors. RCPN reduces the functionality of a regular CPN by limiting the capabilities of the nodes in the graph for the purpose of increasing simulation speed and usability. Additionally, RCPN takes the advantage of some of the natural properties of CPNs to prevent structural and control hazards. |
| Retargetable functional simulator (Fsimg) [21] focus on tools that deal with the machine language of processors, like assemblers, disassembler, instruction set simulator etc. The objective was to have a single processor model for all the tools. Hence Retargetable Function Simulator (Fsimg) was designed using Sim-nML language which is primarily an extension of the nML language for processor modeling. Fsimg takes the specification of the processor in the intermediate representation and an executable for the processor in ELF. Format and generates a functional simulator (Fsim) which in turn gives the functional behaviour of the processor model for the given program. Around 237 instructions have been specified with the resource usage model and pipeline. Macro Preprocessor (nMP) for processing Sim-nML macros is implemented. |
| It has some limitation. Fsimg is imposing a strong restriction on specification writing. Current bit-operator library supports only integer data types. The trace produced by Fsim is not compressed. It makes it difficult to handle and process trace files. It is very slow. |
| The LISATek [22] processor design flow is based on LISA 2.0 processor models. Given a LISA model, the LISATek tool is able to generate instruction-set simulators for the processor under design. Typically, the debugger in form of a dynamic library directly uses the generated simulator. However, a compiled static simulator library is also generated, and specifications exist to integrate it into the system environment. The system environment would be the MPARM. All the core models generated by the LISATek suite, regardless of the nature of the ASIP at hand, have the same interface. The interaction is based upon four key pillars: |
| A. The simulated core can be cycled by calling specific functions. If the processor is modelled in an instructionaccurate fashion, then the generated model can be stepped on an instruction basis. On the other hand, a model derived from a cycle-accurate LISA description can be stepped on both instruction and cycle basis. |
| B. Core-initiated communication (e.g. reads, writes) is performed through a specific Application Programming Interface (API). It is the task of the external program to provide an implementation of said API. |
| C. System-initiated communication (e.g. interrupts), if any, can be forwarded to the core when cycling it, and therefore on a fine-grain cycle-by-cycle basis, by proper flipping of extra pins. Of course the LISA core model must be made aware of the meaning of these extra pins to take proper action. |
| D. An external LISATek Debugger tool can be interfaced to the core via the IPC (Inter-Process Communication) mechanism. The external program must simply invoke the Debugger with proper references; subsequently, the LISATek model and the Debugger interact autonomously. |
| The implementation of these function calls depends completely on the communication method used in the system. The implemented API will translate the requests into SystemC signals which can be understood by the MPARM [23] platform. The Assessment of the performance of alternative hardware communication is not addressed. Retargetability is poor. |
| All of these simulators use techniques to speed up the execution of application programs. This is achieved by minimizing the amount of details about the processor, needed for program execution on the simulator. Even though some of these previous approaches target ADL-based automatic toolkit generation and DSE, not much work has been done in bringing together these elements in an early DSE environment. Furthermore, previous approaches are restricted to certain classes of processor families and assume a fixed memory/cache organization. For a wide variety of such processor and memory IP library, the designer needs to be able to specify and analyze the interaction between the processor instruction set and architecture, and the application and explore the different points in design space. This problem is addressed in SIMPRESS simulators. The EXPRESSION ADL captures both the instruction set and architecture information for a design draw from an IP library. The library contains a variety of parameterizable processor cores and customizable memory / cache organizations. Simpress produces a structural simulator capable of providing detailed structural feedback in terms of utilization, bottle-necks in the processor architecture. The processor-system description is input using a graphical schematic capture tool, called V-SAT, that outputs an Expression Description which is fed into the toolkit generators to produce DSE tools. The SIMPRESS generated simulator provides feedback information which is backannotated to the same V-SAT graphical description. |
| Though SIMPRESS Simulators addresses many issues, it has certain limitation. The application having function calls are not supported. Compilation steps exist in three passes: PcProGUI, Expression console, acesMIPS console. Basically it is very complex to understand the process of compilation and simulator. The Application needs .proc and .def file. The .c program generates these files. There is no clear cut method as how .c is converted to .proc and .def, especially in case of windows environment. This is strong limitation as we can not simulate our own program written in .c. this has to be first converting to .procs and .defs and for that we need to depend on their servers to provide for the same, which is not functional right now.` |
| In order to overcome all these complexities, we suggest a simple and elegant solution. Just there is a need to provide the standard application program in the form of scheduled and optimized code along with the processor description to our Simulator and you will get the cycle count as an output of the simulation. |
OVERALL APPROACH |
| Application or a set of application in the form of High Level Language is taken as input and it given as input to retargetable compiler. Architecture description is also given input to retargetable compiler. Retargetable compiler generates the schedule and optimized code. This code is given as input to Simulator. None of the existing simulator provides and easy GUI to enter the processor components and simulate the code for target host. |
 |
| We are assuming the scheduled and optimize code to be generated from retargetable compiler and this code along with the Processor description or Architecture description is given as input to the Simulator. The Simulator generates the data in the form of cycle count. |
WHAT IS OVPSim |
| It is simulator to develop software on: Fast Simulation, Free open source models, easy to use. Imperas developed some virtual platform and modeling technology to enable simulating embedded systems running real application code. These simulations run at speeds of 100s and 100s of MIPS on typical desktop PCs and are completely Instruction Accurate and model the whole system. OVP has three main components - the OVP APIs that enable a C model to be written, a collection of free open source processor and peripheral models, and OVPsim a fast, easy to download and use simulator that executes these models.OVP put together a simulation model of a platform, compile it to an executable, and connect it to your debugger to provide a very efficient fast embedded software development environment. |
| The focus of OVP is to accelerate the adoption of the new way to develop embedded software - especially for SoC and MPSoC platforms. If any software is developed to run in an embedded system we would normally be using an Instruction Set Simulator (ISS). As there are multiple processors or cores in design we need more than just a single ISS. What is needed is a model of your platform that includes models of all the processors or cores and models of the peripherals and behavioral components that the software communicates with. This is a Virtual Platform, or more simply just a simulation model of your design. OVP provides the different libraries of processor and behavioral models, and APIs for building you own processors, peripherals and platforms. This is just what is needed to use existing models or build your own, and OVP is easy to use, open, flexible, and importantly, free for non-commercial use. |
INSTALLATION AND CUSTOMISATION FOR OVPSim |
| The Imperas professional tools and the OVP simulator is installed on Windows Platform. The Imperas tools are a superset of the OVP tools. Either delete the OVP installation before installing or install to a different directory. The Windows versions are provided as installers as an executable, either |
| imperas.<version number>.<dot release>.exe or OVPsim.<version number>.<dot release>.exe or OVPsim.Windows.exe (for current version from (www.OVPworld.org). |
| The following environment variables are automatically set by the installer: |
| IMPERAS_HOME Points to the root of the installation . |
| IMPERAS_VLNV Points to the compiled Library |
| IMPERAS_ARCH Set to the Host architecture ie Windows |
| IMPERAS_RUNTIME Specifies which simulator, Imperas |
| (CpuManager) or OVPsim, to load at runtime |
| PATH modified to include IMPERAS_HOME/bin/IMPERAS_ARCH |
 |
| The development of platforms, processor and peripheral models on the Windows operating system has been validated in an environment using MSYS and MINGW. A default build environment is provided with both the Imperas tools and OVPsim installations that will allow models and platforms to be built in this environment. We need the installation files of either OVPSim or from Imperas tools and atleast one compiler toolchain. In order to cross compile applications under windows the installation of MSYS/MinGW is done. In our Demo we use the openCores openRISC MIPS32 as the target embedded processor. |
 |
| The OVP and Imperas tools are licensed using FLEXlm. Tool execution needs a license file. A license file bounds to individual computer through computer's host ID. OVPsim looks for its license file in $IMPERAS_HOME/OVPsim.lic Imperas provides pre-built tool chains for processors by OVP. The Processors include MIPS32, OR1K and ARM. The Makefile is available to provide a default build environment for an application onto a processor. The Makefiles is in the format <Processor Type>.Makefile.include. |
| We need to perform some customization to work on MIPS32 processors. We are required to create a folder that contains the entire required file required for execution process. |
| (a) Copy the different files to a suitable folder as shown in Figure 3. Each file is needed as each file has its own significance. |
| (b) Change the Makefile to point to MIPS32 processor. |
| i.e Change the line |
| CROSS?=MIPS |
 |
| (c) Create the application.c file and copy the program in application.c. View the application program as shown in Figure 2. |
 |
| (d) Compile the program as shown in Figure 4. Check for any error and remove it. |
| (e) Run the program as shown in figure 5. |
| (f) The program will generate the different statistics as shown in Figure 6. |
 |
| Different programs can be run by altering the contents in application.c |
DEVELOPMENT OF RETARGETABLE SIMULATOR |
| Electronic devices built nowadays are often built with a single IC composed of multitude of hardware blocks that implement the device functionality. In most cases such circuit contains one or more processors that enable to implement a part of the circuit functionality as software that runs on that processor rather than as a specific hardware component. Such IC is commonly referred to as a systemon- a-chip (SoC). |
| The main CPU features are: |
| a. 101 instructions with possible addressing modes |
| b. CPU with independent stack pointer registers |
| c. Eight 32-bit data, eight 32-bit address and 32-bit status registers |
| d. 16-bit external memory interface |
| Main assumptions for the ISS were: |
| a. Developed in pure Visual basic 6.0 language for high performance. |
| b. Crystal Report is used as a reporting tool to display the different status. |
| c. MS Access is used to Store the different schedules and optimized code. |
| d. Single-instruction accuracy, without taking internal architecture under consideration. |
| e. Fully static design with the support of loop / wait statements. |
| f. Usage of native VB types to gain high simulation speed. |
| g. Communication interfaces separated from functionality. |
| The main part which contains implementation of main processor's logic (ALU, instruction fetch, decoding and execution routines) together with fields corresponding to the internal resources (all registers). Sub-module features: |
| a. Fetching and decoding instructions |
| b. Instruction processing routines |
| c. Handling interrupts and exceptions |
| d. Register implementation and registers read/write access |
| e. Instruction counter |
| Simulators are critical components of the exploration toolkit for the system designer. Simulators can be used to perform a variety of tasks such as verifying the functionality and / or timing behavior of the system, and generates quantitative measurement, for e.g. Cycle count etc. As per our design Methodology and hypothetical assumption of the Architecture we have taken MIPS Architecture as a base to develop our Retargetable simulator. We have given a Nomenclature to our Simulator as SIM-A {Simulators for Architectures}. |
| We will be using Expression Language for Architecture Description. We have developed the GUI Interface for the same. We have also provided the GUI for easy evaluation and analysis. |
| SIM-A- Basics |
| SIM-A is a 32-bit datapath, every instruction is 32 bits wide, and data comes in “words” which are also 32 bits wide. Memory in SIM-A, however, is addressed in bytes. SIM-A is load-store architecture that is, the only instructions that access memory are LW and SW. |
| Memory Organization |
| We are considering Two-level memory. The levels are main memory and cache(s). We are assuming main memory as Shared Memory. Cache memory is assumed to be local to each processing element. We are also considering logical partitions with in that memory. Data begins at virtual address 0x10000000 and grows in the direction of increasing virtual addresses (this data is called dynamic data because the machine doesn’t know how much of it will be used at runtime). In SIM-A, there is also a concept of stack – that is, data that starts just below virtual address 0x80000000 and grows in the direction of increasing virtual addresses. |
| SIM-A Register Set |
| Registers are a small set of fast memory that the datapath has available at its disposal for most immediate operations. All registers are 32-bit wide. SIM-A contains thirty two user registers (that is, registers that the user can access/use in the assembly program) and four special-purpose registers that are hidden from the user. |
| SIM-A Instruction Set |
| This section describes in detail all the SIM-A instructions. |
| Rs and Rt are source registers – the datapath should fetch their values whenever they are used. Source registers are usually treated as twos-complement signed 32-bit numbers. In some special cases they are treated as unsigned numbers (the note that follows explains such circumstances) |
| Rd is the destination register – the datapath will write the result to that register number. |
| Immediate values may either be treated as signed or unsigned values, and may either be zero-extended (in which case the padding bits are all zero), or sign extended (in which case the padding bits are all equal to the most significant bit of the immediate value). |
| SOC designs have various design goals. These goals include minimal cost, maximal performance, low power, high reliability, etc. Design Space Exploration allows the SOC designer to make trade-offs between these goals and arrive at an “optimal” design.SOC designer would like to explore changes to the architecture or the instruction-set of the processor-memory system. Common examples of such changes include, but not limited to: |
| a. Changing the pipeline structure. e.g., increasing (or decreasing) the number of stages to increase ( or decrease) the clock frequency, adding forwarding paths to reduce pipeline stalls. |
| b. Changing the data path structure. e.g., changing slow units to fast units in order to increase performance, changing connectivity between units and storage elements (like register files) in order to decrease power consumption. |
| c. Increasing parallelism. e.g Adding more functional units that can execute in parallel in order to increase performance. |
| d. Changing the instruction-set. e.g Adding new operations which can be exploited by particular applications. |
| e. Changing the memory component. e.g Changing the size of register file, changing the associativity of the cache, etc. |
| f. Changing the memory hierarchy. e.g Adding a cache between the processor and off-chip memory, changing the on-chip memory hierarchy etc. |
| SIM-A Look and Feel |
| This is the first and main form which helps us to calculate the cycle count of any program as shown in Figure7.First section allows us to select the different programs that we are required to simulate. |
 |
| This is the interface through which user will enter the processor description and will mimic the behaviour of the processor. If you click on the option “Select Program to Run” , it contains all the list of programs. Just select the program that we need to simulate and Click the button “Run Simulator and Provide Result ….” Others buttons are not used right now. Second Section provides the output of the program. It contains information like total Arithmetic instruction, Shift rotate, Logical, Jump Branch etc. It also gives the pop up when the program finishes by providing the cycle count. |
| User will first enter the processor description details as shown in figure 8. Submit the form to update the processor description file. Then it browses to the GUI form where he can select the programs that he/She needs to simulate. |
 |
| The above is the brief description of the SIM-A Simulator that has been developed in our Embedded System Lab. |
PERFORMANCE ESTIMATES AND VALIDATION OF SIMULATOR |
| The Framework is based on MIPS 4K like processor architecture. The architecture contains five pipeline stages – fetch, decode, operand read, execute and writeback. There are five parallel issue paths corresponding to two ALU Units, one for floating point unit, a branch unit and a Load/store unit. The memory hierarchy consists of two L1 data caches for instructions and data, a unified L2 cache and a DRAM main memory. There is a 32-bit wide general purpose register file and a 32-bit wide floating point register file, each containing 32 registers. |
 |
| Table 1 lists all the benchmarks programs that have been used to validate the simulators. After running this benchmark program on the SIMPRESS as well as SIM-A Simulator, following results are obtained. |
 |
CONCLUSION AND FUTURE DIRECTION |
| In this paper we presented a validation of OVPSimulator for MIPS32 processor with SIM-A Simulator. This also discuss in detail the OVPSimulator. The different customisation needed to run the application program has been discussed in detail. SIM-A Simulator developed at our embedded Lab generates the performance estimates for the application under consideration. Processor description is captured in the form of GUI, which allows the user to specify the architecture in visual form. The cycle accurate, structural simulator generated using SIM-A allows the user to collect statistics called cycle count. It definitely helps the designer to analyze the design and modify the critical portions. he goal of this project is to allow modeling of a wide variety of processors and memory systems. In order to achieve this goal, the simulator generator includes very general mechanisms for capturing processor architectures. But its usage has to be extended for other class of processors. |
| The SIM-A environment has been designed to allow modeling of diverse range of processors. This has been demonstrated to an extent through the modeling of RISC processor with traditional memory hierarchies. In future, it should be used to model novel memory hierarchy and other classes of processors such as DSP’s. |
References |
|