MEMADDR - A SPLASH2 Tutorial Example

Introduction

MEMADDR is a simple tutorial which adds a memory interface to the LED tutorial. As in LED data is still read from the input file and passed through the SPLASH array. However, as the data values pass each PE, they are added to a value from memory before being passed on to the next PE. In addition, only valid data as signified by the MSB of the tag value are processed in this way.

The code for this example lives in the directory $SPLASH2/tutorial/MEMADDR and consists of the following required files:

memaddr.vhd: This is the VHDL code for this simple processor design. This same design is used for all 16 PE's on a single SPLASH board.
system.vhd: This represents the SPLASH system which must be compiled with any design done for SPLASH for simulation to work. It is simply a copy of the file $SPLASH2/simulator/system/system.vhd.
config.vhd: This is the configuration VHDL file. It pulls together the required library elements along with the MEMADDR entity to make a complete system simulation possible. This is the file where you specify how many boards are in the SPLASH you want to simulate, what files should be used for input to the array, what the initial PE memory contents should be, etc.
xinput: This file contains the data which should be pumped through the array.
xmemory: This file contains the data which is used to initialize the PE memories.
xoutput: This file contains the results which are returned to XR from the SPLASH array..

The VHDL Code

The file memaddr.vhd contains the VHDL code. It has been commented to indicate required elements. There are two main differences between this code and the LED example. First, a memory interface has been added. Note that only the first 16 locations in the memory are ever addressed. Second, the data is only processed when the valid bit in the tag is set.

Each PE takes the incoming valid data, adds a value from memory to it, and passes it on. Thus, each input file data element is added to 32 different memory values as it makes it way around the 32 element PE array.

The Configuration File

The file config.vhd contains the VHDL configuration to create a full SPLASH system for simulation. It has been commented to show how it could be changed to accomodate other designs. Unlike the LED example, this example uses 2 SPLASH boards. Also, the file xmemory has been specified as the initial contents of each PE's memory.

The Input File and the Memory File

The file xinput contains the input data. The file xmemory contains the initial memory contents. The design will operate by having each processor add memory[0] to the first input data item, memory[1] to the second data item, and so on. Since there are 32 PE's in the design the net result is that each output item output[i] will equal

32 * memory[i%16] +
input[i]

Although you have control over whether xinput is decimal or hex, there seems to be no corresponding way to control the format of the xmemory - it is always decimal. This would be a great mini-project for someone to do - simply find the VHDL code for the memory interface and add that capability!

Compiling the VHDL Description

The command to compile the above files to prepare for simulation is:

   vhdlan system memaddr config

This will create the file TOP.sim which is the file which will be simulated using VHDLSIM.

Simulating the Design Using VHDLSIM

For this example, we will simulate without the debugging interface. The easiest way to do this is to type:


   vhdlsim TOP

The only command we need to execute this time is simply:


   run 10000

to run for 10000 ns. Determining why xoutput contains what it does is left as an exercise for the reader.

Compiling Your Design to a BIT File

Once the simulation is working to your satisfaction you may compile it in preparation for downloading it into SPLASH. This is done by:


   vhdl2xnf memaddr.vhd

If all goes well the above should result in the file memaddr.xnf. Currently, I get warning messages about multiple drivers on nets which seem to be harmless. My best guess is that Synopsys is confused.

At this point you may finish the compilation process by typing:

   xnf2bit memaddr

which should result in the file memaddr.bit.

If you use XBLOX elements in your designs, you should refer to Processing Designs with XBLOX to find out how to process the designs.

Executing Your Design on splash

At this point you must move to splash, the host for SPLASH. Ensure that your environment is set up correctly before proceeding.

Copy Over the Needed Files

If your home directory is the same between splash and the HP 700's this step is not necessary. Otherwise, you must copy the files generated in the previous steps to splash. All that is absolutely required to copy over are the files memaddr.vhd, memaddr.bit, memaddr.sym, xinput, and xmemory.

Creating the Symbol Table

To create the needed symbol table, execute the following:

   symtobsym memaddr.sym

The files memaddr.bsym and memaddr.bsym.dis will result and may be used during t2 execution to look up signal values in the SPLASH array.

The SPLASH Driver

A device driver for SPLASH must be running on splash before you may execute on SPLASH. To determine whether the driver is currently loaded, execute:

   /usr/etc/modstat

and look to see if the SPLASH2 driver is listed as running. If not, you may execute:

   /etc/splash2/reload

to load a new one. In order to avoid kicking another user off SPLASH, you should only restart the driver if you are certain one is not running or are certain no-one else is running on SPLASH.

Running SPLASH Diagnostics With `robocop`

It is possible to run diagnostics on SPLASH to determine whether it is operational. This can be done by executing:

   $SPLASH2/bin/robocop -a

on splash. This will run diagnostics indefinitely so you will have to kill it after a while of watching the results.

Executing on SPLASH using `t2`

The program t2 is an interactive program allowing you to execute your design on SPLASH. The alternative, which will be shown later, is to write a C program to drive SPLASH.

A series of commands, contained in the file cmds.t2 which you may use to drive your t2 execution is explained below (you run the commands by executing: source cmds.t2 in t2):

OpenAndInit: This command opens SPLASH and gets it ready to run.
Associate * * memaddr: This will inform t2 that you wish every processor on boards 0 and 1 in SPLASH to execute the design found in memaddr.bit.
Merge *: This will merge the bitstreams for all the processors on boards 0 and 1 of SPLASH into a file suitable for downloading.
SaveRaw memaddr.raw: This will save the merged bitstreams into the file memaddr.raw so that in subsequent runs you may simply execute the command LoadRaw * memaddr.raw rather than doing the association and merging as shown above. Note that when you SaveRaw the file only contains data for one SPLASH board. Thus, if you want different configurations on each board, you must save two raw files and load them separately.
ListPEs: List out which BIT files are associated with each PE in the array.
ConfigArray 0
ConfigArray 1: This will configure boards 0 and 1 of the SPLASH array by downloading the bitstreams.
SetFreq 5.0: Set the clock frequency to 5.0MHz.
Show 0 1 *: Show what register outputs are available for tracing on PE 1 on board 0. Currently, not all register outputs are available for tracing due to problems with the XNF file generation. In this example, however, by looking at the XNF file it is obvious that OUTPUT_*_ is the first register that incoming meets when it enters each PE. Note that since the VHDL code doesn't do anything with bits 16 through 31 of the incoming data, that only the tag bits (32 to 35) and the lower 16 data bits (0 to 15) are available to watch.
Also, not all signals shown can be traced. For example, XP_RIGHT should be trace-able. It always shows 0's due to a bug in the setup. I hope we can come up with a fix for this soon.
Watch 0 1 OUTPUT* in: After every clock cycle, watch a vector formed from all the OUTPUT* bits. This is done using SPLASH's readback capability.
LoadMem * * xmemory: Initialize all PE memories on all boards with the contents of the file xmemory.
StepAscIO xinput xoutput 200: This will read lines of input from the file xinput, pump them into the array one data item per clock cycle, and write any valid results that come out of the array into the file xoutput. In this example, this will be done 200 times or until the input file is exhausted. Since I know of no way in t2 to clock the array and write outputs to an output file, we must pad the end of the xinput with dummy data values to flush the array. Otherwise we may see no output.
CloseStepFile xoutput: Close the output file.
Quit: Exit the program.

Note that in this example, 16 bits of the serial data is not used. Thus, the 16 high data bits in the output file will be all 1's as shown in xoutput.

Executing on SPLASH With a C-based Driver

As in the previous tutorial, you may write a custom C-based driver program. The file drive.c is a sample driver created for this tutorial example. It was written to exactly mimic the operation of the t2 commands above (except for the readback which I currently don't know how to do). The comments in the code should explain its operation. A Makefile is also included to compile the driver code to execute on splash.

Looking Forward

There are still many features of t2 and the use of SPLASH which haven't been explored. As you learn more about SPLASH, please keep me informed via e-mail so that I can add to these tutorials for everyone's benefit.

Last modified: Mon Jul 6 14:36:47 MDT 1998
Brent Nelson

nelson@ee.byu.edu