CSE 378, Winter 2007  Machine Organization and Assembly Language Programming

CSE Home

About Us

Search

Contact Info

Lab 1: Introduction to the Datapath - HW

Out: Monday, 1/29/07
Due: Tuesday, 2/6/07

Description

The goal of the hardware portion of Lab 1 is to synthesize and implement your design, then place it on the board so that it can run a program that makes a light blink on the board. In order to do this, you will use Synplify and the Xilinx ISE to produce a .bit file that can be placed on the board after it has been modified to contain the program that will make the light blink.

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

Writing your program

In order to make the light on the board blink, you will need to write a program that makes stores to a memory address reserved for LED control. This program will be written in MIPS assembly. Keep in mind that the datapath that you have constructed does not support all instructions at this point, so avoid using the instructions that you have not implemented yet.

For the purposes of this lab, we will provide you with a top level board which has components such as a controller and LED control included. The components have been placed in a black box module which will be filled in during implementation. The downside of this is that you will be unable to test your programs in simulation and will have to rely on on-board tests to see if they work.

The LEDs are controlled by a provided LED controller. To turn on the LEDs, store a word or byte to address 0x80000000. The four LEDs will be turned on or off based on the lower four bits of the value that you store. For example, storing the value 3 will turn on LEDs 0 and 1 and turn off LEDs 2 and 3. This corresponds to the binary representation of the lower 4 bits of the store, which would be 0011.

Your task is to write a program that will make the lights blink in a discernible pattern. Use branches to make loops to create delays so that the lights stay in their current state long enough for a person to notice that they are blinking. If you do not do so, the lights will appear to be half on as they will be turning on and off constantly. Save your program into the Assembly directory of the design.

WARNING: This assembler DOES NOT support pseudo-operations. It also complains if you fail to specify all 3 arguments on an ori

Loading your program

When you are satisfied with your program, you will use the files "asm_to_hex.pl" and "lab1_make_ucf.do" to assemble your program and produce a .ucf file. The .ucf file tells the Xilinx tools how to connect up the input and output ports on your design, and how to initialize the memory.

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

> do $DSN\src\Hardware\lab1_make_ucf.do $DSN\src\Assembly\'your .s file' board.ucf

This will produce a new file called "board.ucf" in $DSN\src\Hardware\UCFs. DON'T USE lab1.ucf as the ucf file name. That file is needed as a template and should not be overwritten.

Synthesis

The next step in getting the design onto the board is synthesis. This process will generate a netlist that will be used as the basis for the programming of the FPGA.

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

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. Be sure to inclue board.bde and Lab1_Components.v in the synthesis (these can be found in the hardware folder) and set board as the Top Level Unit. Once you have completed setting the options for synthesis, you can run Synplify to begin the process. This is also covered in the tutorial.

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.

Implementation

Implementation is a multi-step process that takes the netlist generated during implementation and eventually converts it into a programming file that is used to configure the FPGA on the board. In order to complete this section, you will need to download and unpack lab1cores.zip, which contains partially implemented versions of the components in lib378 which are used in lab 1. More cores will be added for future labs.

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. For purposes of this lab, be sure that you use board.ucf for the custom constraint file (you created this file during the "Loading your program" section).

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.

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.

Once you have successfully programmed the board, you should see the lights on the board blink in the pattern that you defined in your program. If so, you are ready to have your lab checked off.

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 rerun the make_rom script. Overwrite the Memory Initialization section in your UCF file with the result.
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.

This work is licensed under a Creative Commons Attribution-Share Alike 2.5 License.	Department of Computer Science & Engineering University of Washington Box 352350 Seattle, WA  98195-2350 (206) 543-1695 voice, (206) 543-2969 FAX [comments to zahorjan]