Travel & Places

A framework for simulating heterogeneous virtual processors

A framework for simulating heterogeneous virtual processors
of 10
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  Abstract This paper examines the layered software modules of a heterogeneous multiprocessor simulator and debugger,and the design patterns that span these modules. Lucent’s LUxWORKS simulator and debugger works with multiple processor architectures. Its modeling infrastructure, processor models, processor monitor / control, hardwarecontrol, vendor simulator interface and Tcl/Tk extensionlayers are spanned by the following design patterns: 1)build and extend abstract virtual processors, 2) build reflective entities, and 3) build a covariant extensiblesystem. Together these modules and patterns define a processor execution architecture that encourages reuseand dynamic extensibility. 1. Introduction Our group within Bell Labs provides software toolsfor cosimulation of embedded hardware and softwaresystems [1], and for the debugging of distributedapplications running on simulated and actual hardware, incommunication systems using Lucent digital signalprocessors and assorted microcontrollers. Since 1995 wehave been designing and building a software framework that addresses the needs of the following groups of users:• Processor architects who use simulation toevaluate prospective processors.• IC designers who combine processorcores, custom input-output circuitry andinterprocessor communication circuitryinto custom integrated circuits.• System developers who build and debugdistributed and embedded applications.• Software tools engineers who buildprocessor models and develop new toolsfeatures.• Field application engineers who need toprototype custom circuitry and customtools features rapidly by using theframework’s Tcl extension language [2,3].Lucent Technologies markets the current productimplementation of this framework as luxdbg —theLUxWORKS simulator / debugger for Lucent embeddedprocessors [4,5]. Luxdbg satisfies the definition of aframework as “a system that can be customized,specialized, or extended to provide more specific, moreappropriate, or slightly different capabilities.” [6] Theframework solves two problems often found in otherprocessor simulators. First, processor simulatorarchitectures usually over-couple a specific processor’ssimulation model to a simulator and debugger. Over-coupling yields a simulator that can control simulations of only one processor architecture. Over-coupling also yieldsa debugger that can debug programs for only onearchitecture. When a simulator / debugger must support anew processor architecture, the only form of reuseavailable consists of ad hoc, cut-and-paste source codehacking. This hacking produces yet another processor-specific simulator / debugger. Subsequent maintenance of cloned, near-duplicate copies of code requires duplicationof effort. We call this the reuse problem .The second problem is the extensibility problem . Inaddition to new instructions, a new processor may add newfeatures never before seen in supported processorarchitectures. A Harvard memory architecture, whichseparates program memory from data memory, is oneexample. Hardware support for software multi-threading isanother. New processor dimensions such as these do not fitthe cut-and-paste style of simulator / debugger evolution.There may be no place to put new feature dimensions in astatic, hard-coded simulator / debugger. New processordimensions require modular extension interfaces.We have solved the reuse and extensibility problemsfor multiple processor architectures by designing asimulator / debugger that configures itself to A Framework for Simulating Heterogeneous Virtual Processors Dale Parson Paul Beatty John Glossner Bryan SchliederLucent Technologies Lucent Technologies Lucent Technologies Lucent TechnologiesAllentown, Pa. 18103 Allentown, Pa. 18103 Allentown, Pa. 18103 Allentown, Pa.  heterogeneous multiprocessors at run time. Luxdbg buildson the abstraction of a virtual machine [1, p. 15-17]. Thisframework is structured as a set of simulation, debugging,profiling and hardware-monitor-control modules thatoperate on an abstract virtual processor. A processordesigner refines the definition of an abstract virtualprocessor into a concrete processor via C++ inheritanceand composition. When the designer has added theserefinements, that designer is rewarded with a powerfulsimulator, profiler, graphical debugger, and interfaces tovendor circuit simulation frameworks.This paper unfolds as a series of examinations of luxdbg’s framework  modules and design patterns . Thelayered modules provide the major capabilities of thesystem. The design patterns provide the rules forconnecting modules and designing new modules. Thesepatterns solve the reuse and extensibility problems.Without the patterns this framework would becomegridlocked and brittle over time.We treat luxdbg as a matrix of modules and designpatterns. Section 2 lays out the horizontal strata of modules and their interactions within luxdbg. Sections 3through 5 explore design patterns as vertical spans of thestrata. Section 6 summarizes our results and examinesfuture directions. 2. Luxdbg framework overview Figure 1 shows the major modules and theirinteractions within the luxdbg framework. Down arrowsand right arrows indicate flow-of-control in client-to-server transactions. Labeled up arrows indicate server-to-client callbacks. Numbers give cardinality of associationsof instantiated objects, where “0..1” signifies zero or oneobject and “*” signifies zero or more objects. This sectionstarts at the bottom of Figure 1 and works its way up.  Modeling infrastructure is a C++ class library. Itprovides base classes that support the abstract virtualprocessor pattern through inheritance. It also providesutility classes for building processor signals, registers,memory, IO ports and monitor / driver probes throughcomposition. A processor architect or other modeler buildsa processor model by using the classes of modelinginfrastructure, along with C or C++ operations and otherlibraries. A specific processor is not a hard-coded part of the framework.Luxdbg processors are reflective . Reflection is amechanism that allows client code to query a processor atrun time to discover the identity of state-bearinginfrastructure objects such as registers within theprocessor. The client can then retrieve and set values forthese objects. Processor monitor / control is a class library Modeling infrastructureProcessor modelProcessor monitor / controlTcl processor monitor / control commandsHardware interfaceTcl subsystemscript callback Tcl/Tk graphical user interface Tcl/Tk subsystemwidget event callback Vendor simulator interfacecosimulate 0..111*111*0..110..1* Figure 1: Luxdbg simulation and debugging architecture IO callback   for simulating, debugging and profiling processor objectsthrough the reflective processor query interface.A processor model acts both as a simulation statemachine and as a database . As a state machine it simulatesprocessor execution. As a database it stores stateinformation for its query interface. Processor monitor / control can supervise execution of real processor hardwarevia the hardware interface module. When a hardwareprocessor reaches a breakpoint, monitor / control uploadshardware state into a model. A user can then interact withstate by interacting with its model. When the user hascompleted interaction, monitor / control downloads statefrom the model to hardware and resumes hardwareexecution.The Tcl subsystem provides luxdbg’s interpretedextension language [2,3]. Tcl supports inclusion of application-specific primitive commands written in C orC++. Luxdbg’s Tcl processor monitor / control commands provide a textual command layer on top of processormonitor / control. Users, Tcl extension scripts, andauxiliary tools use Tcl as a query language for interactionwith processors via monitor / control. Processor events cantrigger recursive callbacks into Tcl for nested scriptevaluation.The Tcl/Tk subsystem is a separate process that housesour Tcl/Tk graphical user interface (GUI). This optionalclient tool uses Tcl queries to communicate with luxdbg’smain process. It provides a source debugging window foreach processor instance in a luxdbg session, as well asoptional register, memory, breakpoint and data watchwindows. A watch window can use user-supplied Tclexpressions to provide derived views of processor data.The vendor simulator interface is an optionalprocedural interface for integrating luxdbg models intovendor simulation frameworks such as ModelTechnology’s VHDL circuit simulator or Math Works’Simulink  ® arithmetic function simulator. Luxdbg modelscan run as components within these frameworks. Luxdbgserves as a loader, debugger and model extender. Usersemploy the capabilities and model libraries of theseenvironments while retaining luxdbg for interaction withLucent processors. The vendor simulator advances modelstate via this interface.Luxdbg’s normal flow-of-control goes down fromlayered client modules to their supporting server modulesas shown in Figure 1. Clients invoke servers. Servers donot contain hard-coded dependencies on specific clients. Aclient may request a callback  from a server when theserver detects an event. The IO callback  of Figure 1, forexample, occurs when a read from an input port object or awrite to an output port object takes place within a model.These port objects are from modeling infrastructure. If monitor / control has registered itself for a port callback,then an input port will fetch a value from monitor / controlvia the callback, and an output port will send a value tomonitor / control via the callback. In this way monitor / control can route processor IO events to file sources andsinks opened by Tcl commands, or up a script callback  toa Tcl extension procedure. IO callbacks eliminate the needto model all connecting circuitry. Port infrastructureobjects act as generic circuitry, and attached custom filesor Tcl procedures manipulate input-output values at a highlevel. Embedded application developers can concentrateon programs while ignoring the details of connectingcircuitry. 3. Design pattern: Build and extend abstractvirtual processors This design pattern is the main element of oursolution to the reuse problem . Luxdbg has distilledproperties that are common to all instruction streamprocessors, and placed them into a set of virtual processorbase classes. This pattern solves problems that are common to all processors. Subsequent patterns solveproblems that are not-common , i.e., problems whosesolutions vary as processor architectures vary. 3.1 Virtual processor infrastructure Figure 2 shows the layers of processor models that amodeler can build from the modules of Figure 1. Eachprocessor appears as a nested set of machine definitions.Luxdbg users have interactive access to these processorlayers.A processor at the lowest level is a circuit machine —acollection of signals, registers, memory cells, andtransition rules for advancing processor state. The modeling infrastructure module of Figure 1 suppliesbuilding blocks for constructing a circuit machine. At thenext level is the machine code processor  or instructionstream machine . It fetches, decodes and executes a seriesof programmed binary instructions. A processor model of Figure 1 is a machine code instruction stream processor.Next, assembly code and procedural code processors result from augmenting a bare machine code processorwith symbolic programs. Processor monitor / control of Figure 1 contains loader and symbol table objects thatimplement these symbolic machine layers. At the top, the Tcl subsystem of Figure 1 supports the Tcl extended  processor  . A user or tool can invoke Tcl procedures thatextend and provide views into lower-level machines.Each processor instance name becomes a Tclcommand prefix that sets the current processor  to thenamed processor for the duration of that Tcl command.  For example, in command “p1 load myprog.e,” “p1” is aprocessor instance into which luxdbg loads program“myprog.e.” The Tcl command may be a Tcl extensionprocedure that temporarily changes the current processorto a different named processor. For example, “p1 r0 = [p2r1]” retrieves the value of register “r1” from processor“p2” and stores it into register “r0” of processor “p1.”When the instance name prefix is missing from acommand, that command uses the current processoralready in effect. A user or tool can set the currentprocessor at a top level, and all commands and scripts thatdo not temporarily override this processor, will simplyoperate on this processor. In this way generic scripts thatapply to multiple, possibly heterogeneous processorinstances become possible. Commands that explicitlyname processor instances can achieve interprocessorcommunication.The remainder of this section focuses on abstractprocessor base classes from the infrastructure library thatsupport the machine code virtual processor abstraction.Later sections on reflection and covariant extension showhow luxdbg supports the outer layers of Figure 2.Figure 3 shows two luxdbg virtual processormodeling hierarchies. The left side shows a class inheritance hierarchy . Derived class InterfaceProcessorinherits from Circuit, and class DriverProcessor inheritsfrom InterfaceProcessor. Circuit, InterfaceProcessor andDriverProcessor are abstract classes from theinfrastructure library. They specify behavior and providemachinery for reuse by processor-specific concreteclasses . Figure 3 shows the place of processor-specificconcrete classes.The right side of Figure 3 shows a processor object containment hierarchy. A concrete DriverProcessor objectcontains nested concrete InterfaceProcessor and Circuitobjects. C++ composition of modeling objects into acontainment hierarchy supports building block-basedconstruction of processor and multiprocessor models.Hierarchical composition is similar to netlist constructionin circuit design languages such as VHDL [7]. Luxdbg’sC++ model composition is similar to structural VHDLcomposition in the interconnection of circuit buildingblocks. Circuit  represents an executable block of circuitry. Amodeler defines a block of circuitry by deriving a circuit-specific class from Circuit and implementing the circuit’s eval() function. Eval() reads circuit-specific input and stateand writes circuit-specific output and state. Detailedrepresentation of input, state, and output are left up to themodeler. They may be simple C integers. A Circuit clientcalls eval() after changing circuit inputs or state variables.  InterfaceProcessor  represents an instruction streamprocessor. A modeler defines a specific instruction set byderiving an instruction-specific class fromInterfaceProcessor. InterfaceProcessor adds three mainmechanisms to those inherited from Circuit. First, aninstruction-specific processor always contains a registerthat the processor identifies as its instruction pointer  (IP,also known as program counter  ). With the IP comesidentification of a program memory . This memory holdsan executable stored program, and the IP gives the locationof the next instruction to begin execution.Second, class InterfaceProcessor contains a querytable and C++ query interface into it. The query interfacesupports reflection . A modeler connects model state withina specific InterfaceProcessor or contained Circuit—signals, registers, pins and memory—to the queryinterface by attaching named probes provided by theinfrastructure library to the contained state-bearingobjects. The simplest state-bearing object is a C integer. In circuitmachine code processorassembly code processorprocedural code processorTcl extended processor Figure 2: Layers of luxdbg virtual machines  the query table the probe provides a symbolic name for itsstate-bearing object (e.g., “r0”), type information (e.g.,register, input pin, memory), and methods for client readand write access. The query table also collects exceptionmessages from within an InterfaceProcessor for usercommunication and methodical exception handling.Third, class InterfaceProcessor provides an event trigger interface for simulation control, profiling anddebugger breakpoints. Method “virtual eventHandletriggerEvent(unsigned long type, long count, long*triggers)” provides basic breakpoint capability.InterfaceProcessor supports a set of predefined event types such as TRIGGER_IP, which triggers an event on aninstruction pointer value. InterfaceProcessor alsoimplements IP range events for entering or leaving asection of program, as well as data access events. Array triggers supplies actual values for testing and count  supplies their count. A specific class derived fromInterfaceProcessor can redefine triggerEvent() to handleevent types supported by a custom model or hardwareprocessor.  DriverProcessor  represents a uniprocessor  or multiprocessor chip . In clock-based modelsDriverProcessor controls global clock and reset logic.DriverProcessor specifies abstract function reset() thatresets a chip to its starting state, and abstract function strobe() that advances the chip one state quantum. Amodeler defines a specific processor chip by deriving achip-specific class from DriverProcessor that implementsreset() and strobe(). For a simple uniprocessor instructionmodel, a modeler can derive an instruction-set modeldirectly from DriverProcessor. The modeler codes theeval(), reset() and strobe() functions and attaches probeswithout using any hierarchical Circuit orInterfaceProcessor objects.The right half of Figure 3 illustrates a more complexstructure for a multiprocessor IC (a so-called superchip or system on a chip ). Each InterfaceProcessor is really aninstruction-set processor derived from InterfaceProcessor.They need not implement the same instruction set. Figure3 also shows some connecting circuitry outside of theseprocessor cores but within the superchip. EachInterfaceProcessor houses a query table for its respectiveinternal circuitry probes. The outer DriverProcessor, byvirtue of also being an InterfaceProcessor, also houses aquery table. The nested InterfaceProcessors appear in thequery table of the outer DriverProcessor.Each DriverProcessor object is a Tcl-accessibleprocessor instance. Nested InterfaceProcessors receivehierarchical names starting with the outer processor’s Tclname. Thus if a user constructs a superchip model called  p1 that contains two nested processors dsp and uC  , the Circuit eval() = 0 InterfaceProcessor instruction stream DriverProcessor reset() = 0strobe() = 0probe query table DriverProcessorInterfaceProcessorCircuitCircuitCircuitCircuitInterfaceProcessorCircuitCircuit Figure 3: Virtual machine inheritance hierarchy (left) and containment hierarchy (right) Circuit event triggersA concreteclass derivedfrom Circuit implementsa circuit.A concreteclass derivedfrom InterfaceProcessor implements aninstruction set.A concreteclass derivedfrom DriverProcessor implements aprocessor chip.
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks