Steam-powered Turing Machine University of Washington Computer Science & Engineering
 CSE 378 Fall 2006
  CSE Home     CSE 378 Fall 2006  About Us    Search    Contact Info 

 Home
Administrative
 Syllabus
 Office Hours
 Mailing List
Assignments
 Reading
 Homework
 Labs
 Exams
Resources
 Lecture Slides
 Handouts
 Wiki
 MIPS Resources
 AHDL Resources
Anonymous Feedback
 Feedback Form
   

Lab 2: Taking Control - HW 

Assigned: 10/17/2006
Due: 10/27/2006

Description

The goal of the hardware portion of Lab 2 is to synthesize and implement your design, then place it on the board so that it can run a recursive program that solves the  "Towers of Hanoi" for the case of 3 discs. 

Do NOT start this portion of the lab until you have verified that your design works in all the tests for the software portion.

Phase 0: Administration

  1. Download lab2-hw.zip and expand it to some temporary location
  2. Copy hanoi.spim and hanoi.s into the Assembly directory under lab2
  3. Copy the files from lab2cores into the lib378cores directory used in lab1

Phase 1: Towers of Hanoi

The Towers of Hanoi is a simple puzzle that follows simple rules. (Towers of Hanoi). For this lab, the goal is to move 3 discs from peg 1 to peg 2 using peg 3 as a temporary.  The files we've provided call the hanoi function, and print output using the print function.

Part A: Implementation Background

In the files hanoi.spim and hanoi.s the main program simply sets up the stack pointer and arguments and makes the initial call to hanoi. Hanoi takes four arguments:

hanoi(int n, int src, int dest, int temp)

n = number of disc to move ( 1, 3, 7 ) 
src = number of the source peg (1,2,4)
dest = number of the destination peg (1,2, or 4)
temp = number of the temporary peg (1,2, or 4)

Encodings

For this lab we will be using only the LEDs as output. Therefore, we have to make the following changes:
  1. The discs 1,2,3 are encoded in unary. (i.e. 1 = 0001, 2 = 0011, 3 = 0111)
  2. The source, destination, and temporary pegs are encoded one-hot. (i.e. A=0001, B=0010, C=0100)

The encoding of the pegs has no impact on the code. Your program will rearrange them for the recursive calls, but should not modify the initial values. The encoding of the discs calls for one change: see #1 in Part B for more info.

Output

The difference between hanoi.s and hanoi.spim is the implementation of the print function. For the board the print function does the following:

  1. uses a two-part pattern to signal the start of a move ( currently 0110 followed by 1001 )
  2. displays the disc (0001,0011, or 0111) then sets LEDs to 0000.
  3. displays the source peg, (0001, 0010, or 0100)  then sets the LEDs to 0000
  4. displays the destination peg, (0001, 0010, or 0100)  then sets the LEDs to 0000
  5. uses a two-part pattern to signal the end of a move ( currently 0110 followed by 1001 )

The discs are numbered 1,3,7, (ie. 0001, 0011, 0111)  

The pegs are numbered 1, 2, 4  (i.e. 0001, 0010, 01000) 

For an example, the LED pattern to move disc 2 from peg 3 to peg 1 would be:

0110
1001
0011
0100
0001
0110
1001

Feel free to change the start and end patterns, but please don't change the peg and disc patterns.

Part B: Implementing hanoi for SPIM

The initial call to hanoi is to move 3 discs from peg 1 to peg 2 using peg 4 as a temporary. Using the encoding described above, the call in C would be hanoi(7,1,2,4). Your tasks:

  1. Implement the function hanoi in hanoi.spim using the recursive solution from the wikipedia page (Note: n - 1 becomes n >> 1 because of the encoding)
  2. Test your solution in SPIM
  3. Copy the working hanoi code into hanoi.s

Part C: Making hanoi.ucf

Download asm_to_hex.pl and save in the Hardware folder of your design

To start this step, type the following command in the console:

> do $DSN\src\Hardware\lab2_make_ucf.do $DSN\src\Assembly\hanoi.s hanoi.ucf 

This will produce a new file called "hanoi.ucf" in $DSN\src\Hardware\UCFs. 

Phase 2: Synthesis and Implementation

In order to properly synthesize your design, the Flow Settings for your design must be correctly set. Click on the Flow Settings button in the Design Flow Manager and verify that the following settings are correct:
  • HDL Synthesis: Synplicity Synplify Premier 8.6 with Design Planner
  • Implementation: Xilinx ISE/WebPack 8.2
  • Family: Xilinx8x Virtex2P

Part A: Setting Synthesis Options:

There are several options that you must set before synthesis can take place. A step by step tutorial that points out each of these settings is available here. Once you have completed setting the options for synthesis, you can run Synplify to begin the process. This is also covered in the tutorial.

  1. Verify that pcaddresscomputer.v, controller.v, cpu.bde, Lab2_components.v,  and board.bde are all included for synthesis
  2. Right-click the lib378.adf icon and select "Add all files to library"
  3. Go to the Generics/Parameters tab and verify that SYNTHESIS is in the "Verilog Compiler Directives" Box
  4. Close the options by hitting OK

Part B: Synthesis

Be sure that you check the warnings produced by Synplify as some warnings may indicate significant problems with the design that could cause it to fail to implement correctly. A list of warnings grouped by severity can be found here. If you have run into a warning that is not listed on that page and are unsure about whether or not it is going to be a problem, contact one of the course staff.

Now that you have completed synthesis, verify that you have the required files for implementation. You should have a .edf and optionally, a .vm file that have been selected in the file list.

Part C: Implementation Options

As with synthesis, you will need to set several options before beginning implementation. A detailed tutorial on setting up and running the implementation process is available here
  1. Open the Implementation Options
  2. Change the .ucf file to be hanoi.ucf generated in Phase 1
  3. Go to the Translate tab and set the "Macro Search Path" to the directory where the core files are stored.
  4. Check the following boxes:
    • "Do Not Run Post-Map STR" in tab Post-Map STR
    • "Do Not Run Post-PAR STR" in tab Post-PAR STR
    • "Do Not Run Simulation" in tab Simulation
    • "Create Bit File" in tab BitStream
  5. Hit OK to confirm the options

Part D: Implementation 

This process can be time consuming, so be prepared to wait anywhere from 10 to 30 minutes for it to complete. For this reason, please do NOT perform implementation on workstations that have XUP boards attached, as this will tie them up when others could be using them.

Once implementation is completed, you will have a .bit file that can be used to program the board.

Phase 3: Testing

Part A: Configuring the board

The final step in getting your design onto the board is using Impact to program the board using the initialized .bit file. A detailed tutorial on using Impact is available here.
  1. Logon to a machine with an XUP Board
  2. Click-thru the "Found New Hardware Wizard"
  3. Open Impact via the XUP programmer icon on the desktop
  4. Right-Click the white window and select "Initialize Chain"
    1. If step 4 succeeded, go to step 5
    2. Otherwise, right-click and select "Cable-Setup"
    3. Choose the "Platform Cable USB" in the upper right, hit OK, and retry step 4
  5. Hit "Bypass" for the first two windows
  6. Find your board.bit file
  7. Right-Click the "Virtex2p" and select "Program", followed by OK

When the little hourglass disappears the pattern should start. At the end of the moves, the program turns on all the lights and enters an infinite loop. To make it start from scratch, toggle the little white switch closest to the LEDs.

Once you have successfully programmed the board, you should see the lights on the board blink according to the pattern described in part B of Phase 1. If so, you are ready to have your lab checked off.

Part B: Changing the program

If your board does not function as expected and you believe that the problem is with the program that you wrote rather than with your design, you can save time in changing the program through the following steps:
  1. First, go to the implementation directory and locate the .ncd file that corresponds to the top level design that you used during implementation. Either rename the file or move it out of the implementation directory.
  2. Check the options for implementation and select the Map tab. Set the "MAP Guide Design File (.ncd)" option to the file that you just renamed or moved. Set "MAP Guide Mode" to Exact. Now select the Place & Route tab. Set the "PAR Guide Design File (.ncd)" option to the same file as before. Set "PAR Guide Mode" to Exact.
  3. Modify your program as necessary, then repeat Phase 1, Part C. 
  4. Restart the implementation process and configure the board with the new bit file.
If done correctly, this will save a significant amount of time as the implementation tools will not reimplement the entire design but will just reimplement the memory portions that were changed.

Demonstration

To demonstrate that you have successfully implemented your design on the board, let one of the course staff know and they will verify that this is the case. If you are unable to find someone to check off your work, come in during office hours or email cse378-tas@cs to schedule a time when one of us can check off your work.
 


CSE logo Computer Science & Engineering
University of Washington
Box 352350
Seattle, WA  98195-2350
(206) 543-1695 voice, (206) 543-2969 FAX
[comments to Course Staff]