Overview to the KressArray

In the following the usage of the KressArray Xplorer user interface is explained. It is considered that the reader has general knowledge of the application domain and the tools utilized by the KressArray Xplorer framework.
Throughout this overview a implementation of a complex multiplication is used to illustrate the usage. The application domain consists therefore only of this application. The relevant parts of the file are marked red. The files used for the example can be downloaded in the according sections.
Remark: If actions seem not to produce any visible response, you should have a look into the browser window, since the output may have been redirected to it.
Demo application: An example application (complex multiplication) is used as a demo application throughout this document. It can be found in the "demo" project in your home directory. However, all files are linked on this page and can be downloaded using the "Save link as..." function of your browser. As all those files are pure ASCII, you can also view them by clicking the links.

User Filespace

For each new user a home directory is created on the server. New users may register themselfs within the applet, by choosing the Login menu item, and pressing the new user button. After that an initial password is created, and a mail is sent to the administrator of this server, and to the user. For the administrator it contains the data entered from the user, for the user it contains the users login name and his password. Within the created directory the user created files are stored. No quota restriction is imposed on the user.

The Tree View of User Files

User files are presented within a tree view representing the users file space on the server, illustrated on the right. The users data can be structured by the means of folders. Therefore application domains can be set up by creating an unique folder for each application domain. Each folder may contain an arbitrary number of applications. New applications can be created by selecting the Create Application menu item of the popup menu of folder nodes. After the menu item has been selected a popup window opens asking for an application name, the name entered must not exist in the folder. Each application node contains five subnodes, according the different stages applications may be in the exploration process. These are: the hardwarefile view, the ALE-X view, the alpha view, the beta view, and the gamma view. The views are initially empty. To start the exploration at least one version of a hardwarefile and one ALE-X file must be uploaded to the server filesystem.

By default each folder contains a Ruleset. Rulesets are not structured by views, rather by rulesets. An arbitrary number of rulesets can be defined. A ruleset can be added by selecting the according menu item on the Rules node popup menu. Each ruleset may contain an arbitrary number of rules. Rulesets are used by the analyser tool. Single rules are uploaded as any other file. As comment a statement should be added describing the rule. For the generation of rules the graphical tool FOX is available.

File Upload

Files can be uploaded by selecting the Upload Version menu item on the view popup nodes. They are uploaded to the view on which the upload menu item has been selected. After selecting the menu item a popup window is opened asking for an initial comment for the uplaoded file. For convinience the comment already contains the date and time, and a statement that the file has beeing uploaded by the user. After the comment has been confirmed by pressing the OK button, the upload HTML page is shown to the user within the browser window. At least the file to upload is specified within the browser window, and sent to the server by pressing the Submit button.

Versioning System

The Xplorer user interface contains a simple versioning system. Uploaded or new created files are stored as versions of the according application and view. That means, older versions must not be deleted. The versions are numbered from 0 upwards automatically. The user is responsible to support meaningful comments to different versions of a view. Within each view an arbitrary number of versions is supported. The popup menus of the version nodes differ with the views. As a help for the user only reasonable menu items according to the view are shown. The popup menu is activted by clicking with the right mouse button on a node. If a version node is selected by a left button click information about that version is shown on a info tab beside the tree view.

Calling the Graphics Editor

The graphics editor can be called only from Gamma view "Version x" by the command "Edit mapping visual"via the right side mouse button.

Copy, Paste, Delete

Copy, paste, and delete operations are available on folder and application popup menus, where for version nodes only the delete operation is supported.

[ go to top of page ]

Compiling ALE-X Files

The ALE-X (Arithmetic and Logic Expressions for Xputers) language allows the description of a complex datapath consisting of one or more data flows which are also referred to as subnets. The ALE-X compiler extracts a dataflow graph representation from such a description and generates an according representation in a file in alpha-intermediate format. The compiler uses also a hardware file describing the initial operator set.
An example ALE-X description for the computation of the complex multiplication C=A*B is shown here.
An example hardware file containing the integer operators of C is shown here.
Using the given ALE-X code and hardware file, the compiler extracts the following datapath:

The resulting alpha-file can be viewed here.

Compiling single files:

The ALE-X compiler can be executed on version nodes of the ALE-X view. After the menu item has been selected a popup window is opened to chose the hardwarefile version to compile the ALE-X file with. After selecting the according hardwarefile the ALE-X compiler is executed on the according version with the specified hardwarefile. The compile results are shown within a tab beside the tree view, from which it can be saved as a new version to the alpha view, or be discarded.

Compiling a whole Application Domain:

To compile the most recent versions of the ALE-X views of an application domain (-> folder). The according menu item of the folder nodes can be used. For each compiled version a new tab is opened containing the compilation results from which they may be saved or discarded.

[ go to top of page ]

Architecture Estimation

The task of the architecture estimator consists in determining an initial architecture for a set of applications. The resulting architecture is added to the alpha-intermediate format, rendering a file in beta-intermediate format. The architecture estimation process takes place in two steps: In the collection phase, the architecture requirements of the alpha-file(s) of the application(s) in the domain are analyzed and the global minimum is determined. In the second phase, the global minimal architectural requirements are actually incorporated in the alpha-file in order to get the beta-file with an initial architecture for the exploration.
For the example complex multiplication datapath, the minimal architecture determined consists of a three by three KressArray with rDPUs featuring one bidirectional nearest neighbor link in horizontal and vertical direction, as sketched below:

The according beta-file can be found here.

Estimation of single files:

The estimation of versions can be executed on alpha versions for that single version, or on the folder node for all applications within the folder. The data from the last version of the alpha menu is used for estimation in the latter case.

Estimation of an Application Domain:

As for the compilation above the estimation for the most recent alpha view files can be performed, by selecting the according menu item from the folder nodes.

[ go to top of page ]

Mapping of the Expression Tree

The mapper performs the task of placement and routing of the datapath The objective of the placement consists in assigning each operator to a rDPU in a way, that the necessary routing between all operators is optimized. The mapper takes as input a file in beta-intermediate format, containing a datapath and an architecture description. The output consists in a file in n gamma-intermediate format, which features additional placement and routing information.

The execution of the mapper can be issued on the popup menu of versions from beta-view. The options for the mapping tool are specified within a popup window shown below. The mapper tool of the Xplorer framework is started within an own thread on the server, since it requires a relatively long time to terminate. Therefore the log within the GUI is updated every three seconds. The execution of the mapping can be stopped by pressing the discard button. After the mapper has terminated the resulting intermediate file containing the mapping section is shown in the Xplorer window, and may be saved as a new version into the gamma-view, or be discarded.

The mapping of the example datapath onto the initial architecture looks like this (Gamma view version 0 of the demo application):

By default, the I/O is handled over the global bus, which explains the ten bus connections to outside. The according gamma-file for this mapping can be found here.

[ go to top of page ]

Text Editor

The editor can be used to edit files within the applet. It features basic editor functionality, like copy and paste (also between editor instances, on different tabs), and jump to line. To save a file the old version can be overwritten, or a new version be created. On either action the user is asked if he would like to edit the comment, in order to add or change an annotation to it.

[ go to top of page ]

Graphical KressArray Editor

The following imge servers as an Legend to the graphical view of the KressArray as shown within the KressArray Xplorer window. In the following the usage of the graphical Xplorer is described.

Calling the Graphics Editor

The graphics editor can be called only from Gamma view "Version x" by the command "Edit mapping visual" via the right side mouse button.

The Xplorer Toolbar

The Xplorer toolbar contains icons to change the zoom factor of the graphical representation of the KressArray, to exchange two rDPUs, to exchange regions of rDPUs, to colourize expressions within rDPUs, to remove the expression colour, to edit the fixing of a rDPU, and to undo actions. In the following each will be discussed further (from left to right according to the image).

Zoomfactor

By clicking the icon with the magnifier glass the scaling of the drawn DPU field can be changed. Reasonable values range from 0.7 to 2.5. If the icon is clicked a popup window opens within which the scalefactor to be used can be entered. After selecting the O.K option of the window the selected scaling is applied to the rDPU field.

Exchange two rDPUs

Two rDPUs can be exchanged by selecting the first rDPU, then selecting the second rDPU, and after the second has been selected to press the exchange rDPUs button. After the button has been pressed a confirmation dialog is shown containing the selected rDPUs. If confirmed, the rDPUs are exchanged. See The confirmation dialog shown if the user requested to exchange two rDPUs. shows the confirmation dialog.

Exchange Regions of rDPUs

To exchange regions of rDPUs at first the upper left rDPU of the source region must be selected, after which the lower right rDPU must be selected. At last the upper left rDPU of the destination region must be selected. After the button is pressed the selected regions are checked for not to overlap each other, and that the upper left specified rDPU is really above and left of the lower right rDPU for the source region. If the check revealed no errors, a confirmation dialog is shown. After the exchange is confirmed it is performed, and the graphical view is updated.

Colorize Expression

This function can be used to colorize certain rDPUs, to keep track of their position during the exploration process. The color information is stored within the intermediate file. The button colorizes the selected rDPU.

Decolorize Expression

Removes the color from with the above function colored expressions (works for the selected rDPU).

Edit rDPU Fixing

With this toolbar button the fixing of the selected rDPU can be edited. Only the defined operands for the selected rDPU are shown to be fixed.

Undo

With this button actions like the editing of routings can be revealed.
WARNING: After the remapping of the architecture, the undo stack is cleared !!

Tabbed Panels

Below the graphical view of the KressArray a tabbed pane is located. The tabs provide information to the array, and allow to change architectural parameters. The panels are explained in the following.

Information Tab

On the bottom of the graphical view of the KressArray a tabbed panel is located. The info tab shows informations about the actual select rDPU, See Info panel, showing information to the selected rDPU. shows an example.

Parameter Tab

Within this tab the parameter values can be adjusted, useful parameters include the arraysize parameters and those controlling the simulated annealing process performed by the mapper. For an explanation of the parameters, see the description of the intermediate file format.

Variable Tab

Defined or referenced variables can be edited by clicking the referenced variables or defined variables tab panel to the front. By clicking on a variable declaration shown in the list, the type of the variable can be changed. The possible types are explained in detail in appendix A. New values are set by using the set values button. Any change to the variables require a remapping of the expressions. Therefore a popup menu is shown that allows to perform the remapping directly. If more variables should be changed the remapping can be cancelled, and be started after the last change has been performed.

Architecture Tab

The architecture tab panel is used to change the current KressArray architecture by adding, removing or editing nearest neighbor connections and row/column backbuses. For nearest neighbor connections, the type (uni- or bidirectional), the torus structure (NONE, SAME, PREV, NEXT) and the cost factors On-chip cost and Off-chip cost can be set. For backbuses, the type (row or column), the segment length, and the maximum numbers of writers can be defined. Note, that a segment length of 0 describes a bus with a single segment spanning the whole array. Furthermore, the cost parameters base cost, cost per distance step, and cost per writer can be set. For a more detailed description of the cost parameters, consult the description in the intermediate file format.

Changes to the architecture require a remapping of the expressions. Therefore a popup menu is shown that allows to perform the remapping directly. If more than one architectural property is changed the remapping can be deferred until the last change has been performed.

Arraycapabilities Tab

This advanced feature allows to create arrays with different operator sets in different array areas. An explanation of this mechanism can be found here. Changes to the array capabilities require a remapping of the expression tree. Therefore a popup menu is shown that allows to perform the remapping directly. If more than one capability is changed the remapping can be deferred, and be started after the last change has been performed.

Edit Routing Tab

Within this tab the routings of the actual selected rDPU can be edited. RDPUs with dangling links are shown with a slightly darker background colour. Please note, that the mapper cannot process files with corrupted routings.

For the example complex multiplication datapath, the Parameter Tab has been used to change the array size from 3 x 3 to 4 x 2. Also, the Variable Tabs have been used to set the the I/O ports from global bus to the array borders. The input ports have been set to the left edge by selecting the according variable and selecting "Edge Port" and "West" from the multichoice field in the tab. Accordingly, the output ports have been set to the east. The result after a remapping is shown in the picture below (Gamma view version 1 of the demo application). The according gamma-file can also be found here.

It should be noted, that doing a remappin in the Architecture Editor does not optimize the datapath. An optimized mapping with only two global bus connections left is shown in this picture:

This mapping appears as gamma view version 2 of the demo application. The according gamma-file can also be found here.

[ go to top of page ]

Analyzer

The analyzer extracts statistic data from the mapping result contained in the gamma-intermediate format and generates design suggestions using a fuzzy inference engine FOX. The suggestions consist in ratings for possible design architecture changes. An example is shown here.
At the time, this feature is not fully implemented and therefore restricted to six possible architecture changes. However, there will be a possibility for extensions to the rule base, allowing to define customized rules.

The analyser is invoked on the popup menu of versions of the gamma-view. The results are shown within the browser window.
If the analyzer is applied to the example mapping (version 2) shown above, the followint result appears:

There are six possible architecture changes considered (at this time). A rating of 50% indicates a indifferent decision, which neither encourages nor discouraging the according action. A higher value encourages the action, while a lower value shows discouragement. As can be seen, the analyzer thinks it to be a good idea to add nearest neighbor connections to the architecture in order to get rid of the global bus links. A horizontal connection is slightly preferred. However, as there are only two global bus links in version 2, the ranking for this architecture change is not that high.

[ go to top of page ]