CSE141L Lab 2, Part B: Processor Front-End - Fetch Control

CSE 141L Homepage | Lab Overview | Lab Description

Jump to: Lab Files | Steps: Step 1, Step 2, Step 3, Step 4 | Hints and Tips

You will probably need to refer to the datapath frequently for this lab. Here is a quick link to it: datapath.pdf

• The fetch unit uses the given module interface.
• The fetch unit operates at 50MHz.
• Each memory location is pre-initialized to the values descripted in Lab 2, Part A.

For the first set of questions (Q1 - Q6), you will need to examine the given files and understand what they are doing. Make sure you pay attention to the time period that each question specifies. You will need to get screen captures of the results of your simulations. You can limit the screen captures to the parts of the simulations that are of interest, but make sure all of the relevent signals are included and that both their names AND values are clearly visible. Failure to produce readable screenshots will result in you not getting any credit for that question.

test.tfw

branch.tfw

	addr  instruction
	#0    nonbranch_op0
	#1    nonbranch_op1
	#2    conditional branch to #7 (predicted taken)
	#3    nonbranch_op3
	#4    nonbranch_op4
	#5    nonbranch_op5
	#6    nonbranch_op6
	#7    jump to #0

After examining the tfw file and running the simulation, answer the following questions:

Step 3: Create a new testbench

An essential skill in hardware debugging is the ability to create your own testbenches. We need you to create a test bench to test the following important situation: both 'restart' and 'load_store_valid' are simultaneously asserted while the FIFO is full. Assume that the 'dequeue' signal is asserted 2 cycles after 'restart' and 'load_store_valid' are asserted. Make sure to set the timing configuration as the figure below. To meet the setup time requirement, you should assert inputs at the negative (i.e. falling) egdes. You should submit your test bench files(*.tfw, *.tbw) with other Verilog files.

As part of your report, answer the following questions about the test bench you created:

Q7	Fully describe the scenario which you used for your testbench. Make sure you describe when signals are asserted/deasserted and explain why they are changed at those times.
Q8	Show the results of your test bench simulation by taking several screenshots. The screenshots should show all relevant events that occur during your simulation. Of particular concern are the transitions on the output signals (namely, fifo_full, instruction_valid and load_data_valid).

Step 4: Performance Evaluation

Now that we are confident that the fetch unit is operating correctly, it is time to see how we are doing with performance. As you did in Lab 1, you will evaluate performance using the Static Timing Report that is generated by Xilinx ISE. By default, a truncated report is provided to you. In order to get the detailed report, you need to change the reporting properties using the following procedure.

First, expand the "Place & Route" menu then right click on "Generate Post-Place & Route Static Timings" in order to reach the properties (see the following image).

Next, set the report type to "Verbose" and make sure that "Perform Advanced Analysis" is checked, as in the figure below.

Implement your design now and look over the static timing report that has been generated.

Q9	What is the maximum achievable frequency?. If the branch prediction is perfect, what is the maximum number of instructions your fetch unit transfers to the backend in 1 second?

Note that the "critical path" is the path through your processor with the longest delay. Decreasing the length of the critical path would allow you to increase the frequency of your processor.

Q10	Based on your timing report, describe the critical path in your fetch unit. For example, the critical path might be: load_store_addr_r -> mux3 -> sram.addr

---

• To check the sanity of your fetch unit, watch the sequence of 'instruction_addr', 'instruction_data', and 'instruction_valid'. Is it what you expect from a normal processor? If not, there must be something wrong.
• Before diving into postroute simulations, first check your design with behavioral simulations. It takes significantly less time.
• In the simulation, the default is not to monitor internal signals, but you have the option to add them. As shown in the side figure, you can browse the design hierarchy in the 'UUT' item and add signals to the waveform viewer. When you add a signal, however, you should perform the simulation again. Note that you might not be able to watch internal signals in post-route simulations. This is another reason that you should start with behavioral simulations.
  
• For those who are more interested in test bench, read this Verilog Test Bench Primer. You can use '$monitor' or '$display' in your *.tfw file to track how a signal changes over time. For example, if you put '$monitor' command in your *.tfw file as the following example, the behavioral simulator will show how sel_mux[3:0] changes.

  In *.tfw file,
  
       .......
  	fetch UUT (
  		.clk(clk),
  		.deque(deque),
  		.restart(restart),
  		.restart_addr(restart_addr),
  		.load_store_valid(load_store_valid),
  		.store_en(store_en),
  		.load_store_addr(load_store_addr),
  		.store_data(store_data),
  		.load_data(load_data),
  		.load_data_valid(load_data_valid),
  		.instruction_data(instruction_data),
  		.instruction_addr(instruction_addr),
  		.instruction_valid(instruction_valid));
  
  		initial begin
  			$monitor($time, " sel_mux[3:0] = 4'b%b", UUT.sel_mux);
  			// -------------  Current Time:  150ns
  			#150;
  			restart = 1'b1;
  			// -------------------------------------
  			// -------------  Current Time:  160ns
  			#10;
  .........
  

• Sometimes Xilinx ISE shows strange results in the postroute simulation. In this case, start a new project, and perform simulations again.