Project, Phase 4

CMSC 411 / Olano, Fall 2015

In this phase of the project, you will improve your robot processor design from Phase 3, write assembly code for your robot, and get it to run in the game simulator

Design Changes (extra credit)

You are allowed to make one change to improve the execution speed of your robot processor, either one level of cache or pipelining. This is not required, but there will be some additional extra credit points for the team that wins the final tournament, so doing the project extra credit could help. You are only allowed to make one change, so any team implementing (say) both cache and pipelining, or pipelining and branch prediction, or any other combination of multiple architectural changes will be disqualified from the final tournament, and only one of your changes will be evaluated for extra credit.

Since the total memory size is just 4KB, if you choose to add cache, it should have a data size no larger than 64 bytes. You should include separate instruction and data caches.

If you choose to add pipelining, you can assume that both memory accesses and robot operations can be pipelined. Do not forget detect hazards and resolve them by either stalling or forwarding. Since adding pipelining and separate intruction and data caches are not an option, you will have a structural hazard between instruction fetch and data memory access on any load or store. You will need to resolve this hazard by stalling the instruction fetch by one cycle.

Assembly Code

On the final day of class, your robot will compete against the robots created by the other teams. Your assembly code should attempt to scan and fire at the other robots to kill them. The scan will report the closest thing in a cone in front of you, including walls or dead robots, so you will need to move around to locate the other robots. Remember that the distance scan returns a negative value for walls and dead robots, and a positive value for live robots. When you fire, it will kill any robot within one unit of the target location.

Compile this code into your robot program and test it on the game simulator to be sure it will work and not kill itself.

Running with the game simulator

The game code has changed somewhat since the version described in phase 1, so refer to these directions to run it. You will need to make sure your robot can successfully run in the game.

You can get a copy of the game simulator code to build on your own system from https://bitbucket.org/olano/robotmachine. It should work on Linux or Mac. If you build it, it will make RobotDriver, which is the main game program. You can also run it on a GL server from the copy compiled in my ~olano/robotarena directory. In either case, you should create a robots.txt file listing one or more copies of your robot program. There is a sample in the directory with the RobotDriver program. By default, it will look for the robots.txt file and robot programs in your current directory when you run the program. You can tell it to look someplace else for the robots.txt file with the "-r" option. You can tell it to look someplace else for the robot programs by giving the full path to the robot program locations in the robots.txt.

When you run RobotDriver, it will create a standalone web server running the game, by default on port 8080. For a local copy on your own computer, run RobotDriver then point a web browser to 127.0.0.1:8080. Only one program can use the same port number at the same time, so if 8080 is in use by something else, you can change it with the "-w" option (e.g. "-w 8081"). The GL servers block network traffic like web servers, so if you run there, you need to tunnel the web connection through your ssh connection from the GL server to the computer you used to log in. From a Unix system, you'd do something like this:

ssh <user>@gl.umbc.edu -L8080:localhost:<port>

Where <user> is your GL username, and <port> is a reasonably unique port in the 50-60000 range. From Windows, you can specify the port tunnelling for TeraTerm on the command line. To do that, you either need to execute TeraTerm from a command shell, or create a shortcut with the full command line. To create a shortcut, right-click on the desktop and select the option to create a new shortcut. You can enter the entire command line (with arguments) as the shortcut location. This would be the TeraTerm command line:

"C:\Program Files (x86)\TeraTerm\ttssh.exe" gl.umbc.edu:22 /ssh /ssh-L8080:localhost:<port>

In either case, once you are logged into GL, you will need to launch the robot with the -w flag specifying your port:

~olano/robotarena/RobotDriver -w <port>

Then visit 127.0.0.1:8080 in a web browser on your local computer to see the robots fight it out. The step button does one cycle at a time, while the play and fast forward buttons keep running steps until all but one robot is dead.

You can see some additional options by running RobotDriver -h. These allow you to change things like the arena size, scan angle, radius around the target that is obliterated when you fire, etc.

Submitting

Commit and push everything for this assignment in the same directory you used for phase 1 and 2. Write a new readme called readme-4.txt with anything you think I should know. Definitely include notes on any chages to your datapath and RTL, in addition to notes about your simulation.