Co Simulation Approaches - Cosimulation I - Lecture Slides | CPSC 689, Study notes of Computer Science

Download Co Simulation Approaches - Cosimulation I - Lecture Slides | CPSC 689 and more Study notes Computer Science in PDF only on Docsity! Mahapatra-Texas A&M-Spring'02 1 Cosimulation II Cosimulation Approaches Mahapatra-Texas A&M-Spring'02 2 How to cosimulate? • How to simulate hardware components of a mixed hardware-software system within a unified environment? – This includes simulation of the hardware module, the processor, and the software that the processor executes. • How to simulate hardware and software at same time? • What are various challenges? – Software runs faster than hardware simulator. How to run the system simulation fast keeping the above synchronized? – Slow models provide detailed and accurate results than fast models. How to balance these effects? – Use of different platforms for simulations. Mahapatra-Texas A&M-Spring'02 5 Some basic approaches • Instruction Set Architecture Model: – ISA can be simulated efficiently by a C program. C program is an interpreter for the embedded software. – No hardware mode. Software executed on ISA model. Execution on ISA model provides timing (clock) details of the cosimulation. – Can be more efficient than detailed processor modeling because internals of the processor do not suffer the expense of discrete-event scheduling. ASIC Model (VHDL Simulation)software ISA Modell C program (Backplane) Program Running on Host Mahapatra-Texas A&M-Spring'02 6 Some basic approaches • Compiled Model: – very fast processor models are achievable in principle by translating the executable embedded software specification into native code for processor doing simulation. (Ex: Code for programmable DSP can be translated into Sparc assembly code for execution on a workstation) – No hardware, software execution provides timing details on interface to cosimulation. – Fastest alternative, accuracy depends on interface information. ASIC Model (VHDL Simulation) (Backplane) Software compiled for native code of the host Program running on host Mahapatra-Texas A&M-Spring'02 7 Some basic approaches • Hardware Model: – If processor exists in hardware form, the physical hardware can often be used to model the processor in simulation. Alternatively, processor could be modeled using FPGA prototype. (say using Quickturn) – Advantage: simulation speed – Disadvantage: Physical processor available. ASIC Model (VHDL Simulation) (Backplane) FPGA Processor Mahapatra-Texas A&M-Spring'02 10 Migration across cosimulation • Consider the system simulation at different levels of abstraction throughout the design process: – In the beginning of design process, hardware synthesis is not available. Hence use functional model to study the interaction between HW and SW. – As design progress with more implementations, replace functional model of hardware by netlist level. – Once detail operation of hardware is verified, swap back the high level description of HW design to gain simulation speed. • The cosimulation environment should have this migration support across the levels of abstraction. • Off-the-shelf Components: design is not a part of the current design process. Functional model is enough, no need to know internal details. Mahapatra-Texas A&M-Spring'02 11 Master slave cosimulation • One master simulator and one or more slave simulators: slave is invoked from master by procedure call. • The language must have provision for interface with different language • Difficulties: – No concurrent simulation possible – C procedures are reorganized as C functions to accommodate calls HDL HDL Interface C simulator Master Slave Mahapatra-Texas A&M-Spring'02 12 Distributed cosimulation • Software bus transfers data between simulators using a procedure calls based on some protocol. • Implementation of System Bus is based on system facilities (Unix IPC or socket). It is only a component of the simulation tool. • Allows concurrency between simulators. VHDL Simulator VEC Interface to Software Bus C program Interface to software Bus Cosimulation (Software) Bus Mahapatra-Texas A&M-Spring'02 15 Heterogeneous Environment: Ptolemy • Ptolemy supports different design styles encapsulated in objects called Domain. – Domain realizes a computational model appropriate for a particular sub- system. Ex: SDF, Dynamic Dataflow(DDF), Discrete Event(DE) and Digital hardware modeling environment (Thor). • Domain consists of a set of Blocks and Schedulers that confirm to a common computational model. Block Geodesic Plasma PortHole Block PortHolePortHolePortHole Block: •setup •go() •wrapup() Geodesic •initialize() •numlnit() •setSourcePort() •setDestPort() Particle Particle •readType() •print() •operator <<() •clone() PortHole •initialize() •receiveData() •sendData() Block objects send and receive data encapsulated in particles to outside world through PortHoles. Buffering: by Geodesic Garbage Collection: Plasma Mahapatra-Texas A&M-Spring'02 16 Heterogeneous cosimulation: Ptolemy • Any model can be used at the top of hierarchy. Within each level of hierarchy, it is possible to have Blocks containing foreign domain. • Hierarchy heterogeneity is quite different from the concept of a simulation backplane (that imposes a top-level models of computation through which all subsystem interact). • Active objects in a Domain are Stars. They perform computation and communications with other objects through PortHoles. SDFSched SDF Star SDF Star SDF Star SDF Domain Mahapatra-Texas A&M-Spring'02 17 Heterogeneous cosimulation: Ptolemy • Domain XXX can contain foreign Domain YYY in it. Call it XXXWormhole • To the stars of Domain XXX, the XXXWormhole appears as another star. Though, inside the Wormhole, it is entirely another domain. DE Sched SDFSched SDFStar SDF Domain SDFWormhole DE Domain DE Star DE Star SDFStar