AmalGUI:A User Interface for a Clustered

Programmable-ReconfigurableProcessorSimulatorChi-Wei Wang,DerekB. Gottlieb, Jeffrey J. Cook, NicholasP. Carter

University of Illinois at Urbana-Champaign�cwang12, dgottlie, jjcook, npcarter� @crhc.uiuc.edu

Abstract— In order for researchers to cope with the designdevelopmentof increasinglycomplex processorarchitectures,ar-chitecture simulators must be able to output more information inan efficient and concisemanner. AmalGUI is a Tcl/Tk graphicalfr ont-end for the Amalgam architecture simulator, AmalSim.Its multip le-window interface provides an effective method ofpresenting the AmalSim output to the user. Furth ermore, itshows how Tcl/Tk can be used to create graphical interfacesfor processorarchitecture simulators and presentsa frameworkfor such a tool.

I . INTRODUCTION

Researchersmust be able to keeptrack of numerous pro-cessorstatesin order to verify proper applicationexecutionon increasingly complex processorarchitecturesduring designdevelopment. Designverification andperformanceevaluationof a new processorarchitecture usually requires the creationof a simulator. Such a simulator can provide the user withdebugging informationontheconfigurationandthestateof thearchitecture’s components as the simulatorstepsthrough theexecution of application codeon thearchitecture. Theamountof state information, though, depends on the complexity ofthearchitecture, which affectsthenumber of components thatthe usermustobserve during the execution of an application.Furthermore,this stateinformationis quickly invalidatedasasimulatorstepsto anothercycle. As a result, the amount ofinformationandoutput generated by thesimulatorcanbecomesubstantialandwill only grow as architectures become morecomplex.

Text basedcommand-linesimulatorsdo not offer a methodto output complex stateinformation intuitively andcanoftenimpedethe user’s ability to comprehendthe informationtheyprovide.They especiallylack theability to efficiently representcomplex organizations of components.As a result, thereis aneedfor graphical interfacesthat canpresentthis informationin an effective manner.

AmalGUI is a Tcl/Tk graphical front-end to AmalSim,our Amalgam architecture simulator, that provides the userwith a multi-window environment. Output from AmalSimis presentedin the appropriate windows as either text or agraphical representation(image).AmalSim implements high-level models for every major component in the Amalgamarchitecture in C andrunsasa command-line shell.The shellsupports commandsfor printing debugging information andsteppingthrough theexecution of anapplication on Amalgam.

Bank Bank Bank Bank �

Network �

PCluster �

Cache �

(multi-banked) �

Memory

PCluster �

PCluster �

PCluster

RCluster RCluster RCluster RCluster

Fig. 1. AmalgamArchitecture[1]

I I . AMALGAM ARCHITECTURE

Amalgam is a clusteredprogrammable-reconfigurablepro-cessorthat integratesmultiple memory, programmable, andreconfigurable units onto a singlechip, asshown in Figure1.Eachprogrammable or reconfigurableunit is an independentprocessingresourceknown asa cluster. Global communicationbetweenclusters and the memory systemis handledby aflexible on-chip network. The global memory systemconsistsof a multi-banked cache and the off-chip memory. Everycluster also incorporates a 32-entry register file for localstorageandcommunicationwith the network.

Whenexecutinganapplication, theapplicationis distributedamong the clustersin orderto exploit the application’s paral-lelism. Furthermore,the critical regions of the application areimplementedin the reconfigurable clusters,which can resultin large speedups in performance[2].

However, in order to verify the execution of a distributedapplication, the user must track the execution on eachclus-ter. This increasesthe amount of information the user mustprocess since each cluster is independent and has its ownregisterfile. In addition,AmalSim’s network modelis flexible

Register File �

i-cache

ALU ALU

NIC �

Network

Fig. 2. ProgrammableCluster [1]

enough to offer different configurationsthat could impact theperformanceof Amalgam. As a result,theusermustalsotakethenetwork into considerationandobserve its behavior duringapplication execution.

Each programmable cluster (PCluster) is a conventionaldual-issuein-order microprocessorasshown in Fig. 2. Whena programmable clusterexecutesaninstruction, thestateof allthe componentsin the programmableclustermay be affectedand will needto be observed. The network interface/buffer(NIC) directsincoming andoutgoing network data.The dualarithmeticlogic units (ALUs) and their pipelinesexecute in-structionsandsendtheresultsbackto theregisterfiles.Finally,the instruction cachestoresrecentlyexecuted instructions.

Amalgam’s reconfigurable units (RClusters) increasethecomplexity of thearchitecture.Thearchitecture of Amalgam’sreconfigurableclusteris shown in Fig. 3. At the coreof eachreconfigurable unit is a reconfigurable array (RA). The RAis a versatilefabric of logic blocks (LB) and wires that canbeusedto implementmultiple circuitsduringanapplication’sexecution. The RA is interleaved with the cluster’s registerfile and then folded to form an unbroken ring that allowscomputationto flow in a counter-clockwisedirection. This re-duceswire congestionandwire lengths [1]. EachRA segmenthas8 rows andeachrow has32 logic blocks. The segment’slogic blocksreadinput datafrom the8-entryregisterbankthatproceedsthe segment(source) andwrite to the register bankthat follows the segment(destination). For example, in Fig 3Segment 0 readsdata from Register Bank 0 and writes datato Register Bank 1. Activities on the RClusterare directedby the cluster’s Array Control Unit (ACU). The ACU alsomanages the Configuration Cache(CC), a local memory for

Register Bank 0

Register Bank 3

Register Bank 1

Register Bank 2

Segment 0

Segment 1

Segment 2

Segment 3

NIC �

CC �

ACU

Fig. 3. ReconfigurableCluster [1]

4-LUT �

A �

input crossbar �

optimized carry chain

B D �

0 � 1

2

3 �

C

OUT

COUT CIN

global clk

INV

input muxes �

secondary signals

DREG R S

CE Q

D

Fig. 4. Logic Block Architecture [1]

storingrecentlyusedRA configurations.The logic blocks (Fig. 4) are the fundamentalcomputa-

tional units of the reconfigurable cluster. Each logic blockcan implement any function of its inputs using its look-uptable (LUT). The logic block inputs, which the input muxesdetermine by selecting the appropriate wires, serve as theindex of the corresponding output value in the LUT. Aroundeachlogic block is a complex and flexible systemof wires,which areconfiguredto routedatafrom logic blocksandthesourceregister bank of the segment to the input muxes ofother logic blocks andthe destinationregisterbank. For each

Fig. 5. AmalGUI Screenshot

application, theconfigurationof thelogic blocks(LUT values,input muxes, crossbar, and mode) and the wire routing canvarygreatly. In total,eachreconfigurable clustercontains1024logic blocks and4096wire segments.The complexity of thereconfigurableclustersdemonstratesthe needfor an efficientpresentation of informationto the user.

I I I . AMALGUI

AmalGUI displays the output from AmalSim as text oras graphical representations in a multi-window environment.Suchanenvironment lets theuserquickly find theinformationpertaining to aparticularclusteror otherAmalgam component.Rather than outputting all of the AmalSim output in onewindow, the information is organizedin specificwindows thatarepositionedon thescreenaccording to theuser’s preference.AmalGUI primarily consistsof a main window with multiplecomponent/cluster windows that the user can create (Fig.5). Eachmajor architectural component in Amalgam has itsown window (clusters,network, andmemory/cache),althoughmultiple instancesof eachcomponentwindow canbe createdto allow the userto simultaneously query different attributesfor the samecomponent.

The main window, shown in Fig. 6, displays importantinformation from AmalSim in a text widget while the cycle

andprogram counter (PC) informationis displayedin a labelwidget. In addition, a canvas widget is usedto createa mapof the Amalgam architecture.

AmalGUI uses canvas widgets extensively to efficientlyshow the organizationof the architecture and the statusofits components.This givesAmalGUI the ability to take largeamountsof textual informationandpresent it asa imagethatisboth conciseandunderstandable. The main window’s canvasmapquickly lets usersbecomefamiliar with the architectureandits configuration, includinghow many programmable andreconfigurable clustersarebeingusedby the application run-ning on Amalgam. Themapalsoallows theuserto createnewwindows corresponding to the component the userclicks on.Of thesewindows, the programmable cluster, reconfigurablecluster, andnetwork windows eachusecanvaswidgets.

Programmable Cluster Windows:

Thewindows for the programmableclustersconsistmainlyof a text widget,a canvas widget,andvarious button widgets(Fig. 7). The canvas is againusedas a map . Once a com-ponent is clicked, the canvas is hidden andthe correspondingAmalSim output is sent to the text widget. The buttons cansendAmalSim commandsthat do not have a logical placeinthe mapandalsogrid or ungrid the map.

Fig. 6. AmalGUI Main Window

Fig. 7. AmalGUI ProgrammableCluster Window

ReconfigurableCluster Windows:Reconfigurable cluster windows (Fig. 8) are similar to

programmable clusterwindows.However, anadditional canvaswidget is often usedin placeof the default text widget. Thissecondcanvas andthegraphical representationit createsallowthe userto easilyandquickly comprehendthe large amountsof RCluster information outputted by AmalSim. The canvasis especiallypowerful whena single imagecanrepresenttheoutput of several AmalSim commands.

The use of graphical representations producesa reconfig-urableclusterwindow with multiple levels of detail asshownin Fig. 8. Initially, the user is presented with the top mostlevel of theRClusterarchitecture (Fig. 8(a)). If theuserclickson a component, such as Segment 0, the user goesdeeperinto the architecture andthe canvasis redrawn at a lower andmoredetailedlevel asshown in Fig. 8(b),which shows all theLB outputs in Segment 0. If the usercontinuesclicking on aLB, the userwill reachthe lowest level wheredetailsaboutthe LB’s configuration and state are displayed(Fig. 8(d)).Bindings to mouse events allow the user to easily traversebetweenlevels to attain the level of detail desired.

(a) AmalGUI Reconfigurable Cluster 4 Window

(b) View of RCluster 4’s Segment0

(c) View of Segment0’s LB(2,22) andsurrounding wires

(d) View of LB(2,22) and detailed information

Fig. 8. Exampleof multiple levels in RClusterwindows.

Fig. 9. AmalGUI Network Window

Fig. 10. PClusterWindow with highlighting

Network Windows:The network windows use a canvas to representthe con-

figuration of the on-chip network as shown in Fig. 9. Allcanvas objects are createdas a result of bindings with thelayout engine in AT&T’ s GraphViz Tcl extensions. Using thenetwork connection information attainedfrom the output ofseveral AmalSim commands, GraphViz’s graphdatastructureis created. GraphViz then createsa view of how the graphshould be displayedby using a incremental layout engine(dynadag,geograph,orthogrid, or fdpgraph) to determine theproper locationof graphnodesandedges.Creation,deletion,and changes in the position of a node or edgeare bound toTcl proceduresthatcreate,destroy, or move thecorrespondingcanvasobject accordingly.

Updating Windows:After a step or run command, the information in each

window is updated by re-sending the most recent AmalSimcommand(s)whoseoutput wassentto eachwindow. If Amal-Sim output is sentto updatea text widget, the new output iscomparedto the invalidatedoutput storedin the text widget.Differences betweenthe two are highlighted to let the userknow thatvalueshavechanged.Fig. 10showsaprogrammableclusterwindow displaying its registerfile after an update.

Interface: Windows, Buttons, ����� t Widgets, Canvases, etc

AmalSim

AmalGUI

Process_Data

Get_Amalsim _Output

Update_Windows

Send_Command_Line

Send_Amalsim _Command

Various ProcessingProcedures

Command_Q

Fig. 11. AmalGUI Architecture

IV. AMALGUI IMPLEMENTATION

AmalSim is executed as a child processof AmalGUI viathe use of two command pipelines,one for stdin/stdoutandtheotherfor stderr. This allows AmalSimto bekeptasa standalonecommand-lineshell.Thegeneralapplication architectureof AmalGUI is shown in Fig. 11. The interactionsbetweenthe userand AmalGUI typically result in AmalGUI sendingcommands to AmalSim to get the necessaryinformation itneeds.Thesecommands are executedby AmalSim, whichsendstext output backto AmalGUI. AmalGUI thentakestheAmalSimoutput andpresentstheinformationbackto theuser.

Sending AmalSim Commands:The architecture that AmalGUI useswhen sendingcom-

mands to AmalSim can be describedas a two-tier structurethat allows for efficient checking of a command’s arguments.Before commands can be sent to AmalSim, they must havevalid argumentsanda destinationwindow for their AmalSimoutput. Theargumentsareimportantsincethey areoftenusedto helpAmalGUI directinformationto theproperwindow. Theverification of argumentsanddestinationwindows, aswell asany otherpreparation neededfor AmalSim output processing,are managed by two main procedures:SendCommand LineandSendAmalsim Command (Fig. 11).

Thesetwo procedures take advantage of the fact that thecommandsAmalGUI sendsto AmalSim can be classifiedaseitherexternal or internalcommands.External commandsareany commands with at leastoneargumentspecifiedexplicitlyby the user. Typically these are commands that the usertypes in and wants to sendto AmalSim through AmalGUI.AmalGUI’s mainwindow hasanentrywidgetthatallowsusersto typein commands.However, userscanmakemistakeswhenentering commandsandasa result,external commandsrequireverification of the command itself and its arguments.

Internal commandsareAmalSimcommandsthatAmalGUIgenerates.All the command’s argumentsare correct and noverification is required.Generally, whenAmalGUI hasto send

an AmalSim command to get information on the state ofAmalgam, it can generate the proper argumentsitself basedon the configurationinformation andthe window from whichthe command was invoked. For example, when a commandis invoked from a cluster’s window, the cluster number canbe determined from the cluster window’s nameand passedas an argument. The destinationwindow is often the win-dow that invokes the command. It can also be generatedbyinspecting the command and its arguments. Since internalcommandsarealwayscorrect,they do not needto be verifiedby SendCommand Line.

SendCommand Line performs the verification of exter-nal commands and tries to correct command arguments ifthey are incorrect or missing. Basedon the command, thedestinationwindow for the command’s AmalSim output isalso determined. If AmalGUI is unable to determine thecorrect argumentsor destinationwindow for a command, theAmalSim command is not sentand an error messageis sentto the main window. SendAmalsim Commandsetsup datastructures and performs any other actions neededto processthe command output, suchas the creationof the destinationwindow. Finally, the commandand its argumentsare placedin the command pipe and sent to AmalSim (stdin). Thecommand, its arguments,and the destinationare thenplacedinto a global queue, Command Q.

The CommandQ represents the current AmalSim com-mands that have been sent to AmalSim, but have not yetcompleted.SincemultipleAmalSimcommandscanbequicklyplaced into the command pipeline (stdin) and buffered, thequeue allows AmalGUI to correctly associateoutput with thecorrect commands. This is very useful when a destinationwindow requirestheoutputof multiplecommandsor whentheuserdecidesto queue up subsequentcommandswhile waitingfor the completion of the current command.

ProcessingAmalSim Output:Once an AmalSim command is sent,AmalGUI waits for

AmalSim’s output to arrive via thecommand pipe(AmalSim’sstdout).By default, the child process’stdoutis buffered untilit is terminated.However, this would render it uselessfor ourpurpose since the two applications must interact with eachother. Whenbuffering wasdisabledthough, the output from asingleAmalsimcommand wasbrokenup andsentasmultiplelines of output. AmalSim senta new line to AmalGUI when-ever a new line characterwas outputted. Sincea command’soutput is received oneoutput line at a time, parameterssuchas the destinationwindow must be determined before thecommand is sent. Otherwise,redundant computations occurwheneverAmalGUI receives a new line of output.Consideringthenumber of linesprocessed,suchanoverheadcouldquicklybecome significant.

Get Amalsim Output is bound to the event of new dataarriving in thecommand pipelines,aswell asbrokenpipes.Ifthe output line is a messagefrom a watchpoint or breakpoint,it is sent to the main window’s text widget. Otherwise,it isthe output of the command at the headof the CommandQand is sent to ProcessData, which directs the processingof

output lines. ProcessData also is responsible for initiatingwindow updates.ProcessData sendsthe output line to theappropriateprocessingproceduresbasedonthesentcommand,its arguments,and the destinationwindow. The processingprocedures,which use regular expressionsextensively, sendthe output line to the destinationwindow’s text widget, parsethe output line for the dataneededto createcanvas objects,or set their attributes, such as color. Sometimes,multiplecommandsneedto besentin orderto gatherall thedataneededto createa canvas. Once all the data is gathered,AmalGUIcreatesor updatestheentirecanvas.If thewindows needto beupdated,Update Windows is calledandsendsthemostrecentAmalSim Command(s) for eachwindow. Suchinformation isstored in a global array with window namesas the index.Output lines thatarenormally sentdirectly to a window’s textwidget are insteadcomparedto the existing text lines in thetext widget.Using text tags,thenew output line is highlightedwhenit is differentfrom thecorresponding text thatit replaced.

Oncea command’s output is finished,a marker is outputtedthat lets AmalGUI know that the command at the front ofCommand Q is doneexecuting andcanbe removed.

V. CONCLUSION

For this application, Tcl/Tk hasmany advantages.As manyhave statedbefore, Tcl/Tk is a powerful language for mak-ing user interfaces. It provides most of the necessarydatastructures and commands for such a task. One of Tcl/Tk’sgreatestadvantagesis the number of widget operations andattributes each widget has. This allows AmalGUI to havegreatcontrol over eachwidget,which is necessaryfor creatinga successfulinterface.This is especiallytrue for the canvaswidgets,which AmalGUI extensively used.For our approach,Tcl/Tk’s support for efficient regular expressionsis alsoveryimportant, sincemany different lines of AmalSim output areparsedfor information.Finally, asAmalGUI’s codesizegrew,Tcl/Tk wasstill able to run with reasonable speed.

However, by calling AmalSim as a child process andmaintaining AmalSim’s command-line shell, AmalGUI is de-pendent on the format of AmalSim’s output. Changes inAmalSim’s output format could causeAmalGUI to functionincorrectly. Another drawback is with double substitution.Many global variables are specific to a particular window,especiallythe bindings for the buttons, canvas, and mouseevents. Sincemany windows have the sameset of variables,the variable namesoften included the nameof the windowthey are relatedto in order to distinguishthem apart.As aresult,whenbeingusedasanargument,thenameof a variablewould often contain the value of another variable(i.e. nameof the window). Arrays were sometimes usedinstead,sincethe embedded variable, suchasa window name,canserve asthe index.

A problem with creatingmany differenttypesof windows isthat the codesizebecomesratherlarge becauseeachwindowtype is so different. A general approachwhereoneprocedurecould produceall the windows was initially attempted.How-ever, it was soonrealizedthat therewas too much variance

betweenparameters. This includedthe names,attributes,andnumber of widgets,bindings, andwindow layouts.

Overall, Tcl/Tk was suitablefor creatinga user interfacefor processorarchitecture simulators. AmalGUI helped reducethe architecture and application development time by beingeffective at organizinglarge amounts of information in a waythat the usercanquickly understand.

REFERENCES

[1] J. D. Walstrom, “The design of the amalgamreconfigurable cluster,”Master’s thesis,University of Illi nois at Urbana-Champaign, 2002.

[2] D. B. Gottlieb, J. J. Cook, J. D. Walstrom, S. Ferrera, C.-W. Wang,andN. P. Carter, “Clusteredprogrammable-reconfigurableprocessors,” inProc. of the 1st IEEE International Conference on Field ProgrammableTechnology (FPT), Hong Kong, China, Dec. 2002.