Introduction

Simulation is performed in order to give insight to problems which cannot be efficiently analyzed via an analytical approach. The objective of this assignment is use our 'arbiter' and 'cpu' entities to answer some quantitative questions about the importance of implementing round-robin priority and overlapped bus grants in the central arbiter.

Setup

   ROUND_ROBIN :boolean := TRUE; -- do round_robin priority if true
                                 -- else do Fixed priority

   OVERLAP_GRANT :boolean := TRUE; -- overlap grant requests if true
                                   -- else do NON-OVERLAPPED grant request.

Assumptions/Definitions

1. Assume that every bus transaction takes 8 clock cycles (the Busy line is held low for 8 clocks once a bus grant has been made in response to a bus request).
2. Define request rate as the rate at which Bus requests are generated by a CPU. A request rate of 1% would mean that 1 bus request would be generated for every 100 clock cycles in which the external bus is NOT being requested (or utilized). Assume that all of the CPUs in the system have the same request rate. In the CPU model which is provided, the 'LOCAL' state is the state in which the CPU is performing local operations and is not in the process of a bus request.
3. Define total clocks as the total number of clocks during the simulation. This number applies to the entire simulation.
4. Define idle time for a CPU as the total number of clocks spent waiting for a bus grant (corresponds to the 'GRANT' and GRANTACK states of the provided CPU model). Each CPU can have a different idle time.
5. Define bus utilization as the number of clocks in which the 'bbusy' line is asserted (had a '0' value) divided by the total number of clocks.

To Do

1. Add a generic called 'REQUEST_RATE' (type 'natural') to the 'CPU' entity. Assume the request rate can vary between 0 to 999 which represents request rates of 0.1% to 99%. Modify the CPU code such that random requests (uniform distribution) are generated from a CPU component to match the request rate. This is done by keeping a boolean array of 1000 elements (call this array REQ_ARRAY). A counter which is incremented for every clock cycle spent in the CPU 'LOCAL' state is used to index into the REQ_ARRAY. If the REQ_ARRAY value is TRUE, then a bus request needs to be generated. Each time the counter reaches the end of the REQ_ARRAY, the array values need to first be reset to FALSE, then random elements in the REQ_ARRAY need to be set to TRUE to give a bus request rate over the next 1000 local clocks that matchs the REQUEST_RATE generic ( a bus request rate of '10' would mean that 10 of the 1000 values in the REQ_ARRAY need to be set to TRUE).
2. Add a generic called 'RND_SEED' (type natural) to the 'CPU' entity. This value can vary between 1 and 50 and specifies the array index of starting random seed as specified in the 'rnd2' package. Assign each CPU component a DIFFERENT rnd_seed value (I don't care what values you use). The 'rnd2' package is included in the 'sim3.tar.Z' file. Also included in the 'sim3.tar.Z' file is an entity called 'rnd_test' that illustrates how to use the 'rnd2' package.
3. Add a generic called 'CPU_ID' (type natural) to the 'CPU' entity. This value will be the ID number of the CPU and should be put on the address bus anytime the CPU has the bus. CPU_ID numbers should be assigned sequentially in the simulation (0 to 7 if the simulation contains 8 CPUs).
4. Add a generic called 'CLK_MAX' (type natural) to the 'CPU' entity. The CPU should compare CLK_MAX to the total number of clocks it has seen thus far; when the total clks equals this CLK_MAX then the CPU should set its 'active' output to 'Z' and not generate any more bus requests. The 'active' output should be a '0' value otherwise.
5. Create a test bench called 'tb_cpu8' that instantiates 8 CPU components (the 'tb.vhd' file provided in the 'sim3.tar.Z' file only instantiaties two CPU components).
6. Modify whatever entities are necessary to produce the statistical information required in the following section.

Graphs

I want the following 5 graphs done where the information is based upon simulations of an 8 CPU system. Each simulation should be run for 5000 clock cycles.

1. I would like a plot which shows BUS UTILIZATION percentage (Y-axis) plotted against REQUEST_RATE (x-axis) values of 50, 40, 30, 20, 15, 10, 5 for three different cases:
   1. ROUND_ROBIN = TRUE, OVERLAP_GRANT = TRUE
   2. ROUND_ROBIN = FALSE, OVERLAP_GRANT = TRUE
   3. ROUND_ROBIN = TRUE, OVERLAP_GRANT = FALSE
   All three cases should be plotted on the same graph for comparison purposes.

2. I would like a plot which shows the average CPU Idle Time Percentage (y-axis) plotted against REQUEST_RATE (x-axis) values of 50, 40, 30, 20, 15, 10, 5 for three different cases:
   1. ROUND_ROBIN = TRUE, OVERLAP_GRANT = TRUE
   2. ROUND_ROBIN = FALSE, OVERLAP_GRANT = TRUE
   3. ROUND_ROBIN = TRUE, OVERLAP_GRANT = FALSE
   All three cases should be plotted on the same graph for comparison purposes.

3. I would like a plot which shows the average number of CPU bus requests (y-axis) plotted against REQUEST_RATE (x-axis) values of 50, 40, 30, 20, 15, 10, 5 for three different cases (a request counter must be kept for each CPU that is incremented each time the CPU makes a request. The average number of requests is total # of requests divided by the number of CPUs):
   1. ROUND_ROBIN = TRUE, OVERLAP_GRANT = TRUE
   2. ROUND_ROBIN = FALSE, OVERLAP_GRANT = TRUE
   3. ROUND_ROBIN = TRUE, OVERLAP_GRANT = FALSE
   All three cases should be plotted on the same graph for comparison purposes.

4. For the REQUEST RATE value of 40, produce a bar graph plot which compares the Percent Idle times of EACH cpu for the two cases of ROUND_ROBIN equal TRUE and FALSE (OVERLAP_GRANT = TRUE always). X-axis should be CPU ID #, Y axis is Percent Idle Times.

5. For the REQUEST RATE value of 40, produce a bar graph plot which compares the number of requests made by EACH cpu for the two cases of ROUND_ROBIN=TRUE and ROUND_ROBIN=FALSE (OVERLAP_GRANT = TRUE always). X-axis should be CPU ID #, Y axis is number of requests.

Model Output

# CPU #0  Total Clks: 5000,  Total Requests: 42,  Total Waits: 126, %Wait: 3
# CPU #1  Total Clks: 5000,  Total Requests: 44,  Total Waits: 127, %Wait: 3
# CPU #2  Total Clks: 5000,  Total Requests: 42,  Total Waits: 74, %Wait: 1
# CPU #3  Total Clks: 5000,  Total Requests: 44,  Total Waits: 73, %Wait: 1
# CPU #4  Total Clks: 5000,  Total Requests: 45,  Total Waits: 120, %Wait: 2
# CPU #5  Total Clks: 5000,  Total Requests: 42,  Total Waits: 95, %Wait: 2
# CPU #6  Total Clks: 5000,  Total Requests: 43,  Total Waits: 76, %Wait: 2
# CPU #7  Total Clks: 5000,  Total Requests: 41,  Total Waits: 117, %Wait: 2
# ReqRate: 10, %Bus Util: 54%, Avg Req: 42, Avg Waits: 101, %Avg Wait: 2%

One way to keep the statistics is to define a package that has some global counters in it for each CPU (you can assume that there will be only 8 CPUs). After the 'active' line goes to an 'H', the stimulus module can call a 'report' procedure which you have placed in this package; the 'report' procedure prints the statistics to standard output (use a 'writeline' function to file OUTPUT);

To Turn In

From the directory above your 'sim3' directory (your should be in the 'src' directory of your VHDL development tree), execute the script submit_sim3.pl . This will create a compressed tar file of your 'sim3' directory, along with your 'Makefiles/Makefile.sim3' file and will mail it to me.

Two of the files I have placed in the 'sim3.tar.Z' file are called 'sim3/cfg_tb.template' and 'sim3/cfg_tb.vhd'. The 'cfg_tb.vhd' file references a testbench called 'tb_cpu8.vhd'. The 'tb_cpu8.vhd' file is a testbench you MUST write that implements the 8 CPU system. To test your simulation, I have a perl script that for each set of parameters listed above, will use the' cfg_tb.template' file to generate a new 'cfg_tb.vhd', compile the configuration using 'Makefiles/Makefile.sim3', and then run the simulation. Because of this I am interested in ALL of your VHDL files. Your 'Makefiles/Makefile.sim3' file MUST CLEANLY COMPILE all of the files in your 'sim3' directory, and must include a target for 'cfg_tb.vhd'. I will run your simulation for each set of parameters above and look at the output produced to see if it roughly matches what I expect. I do not expect an exact match with my numbers.

I do not care how many new VHDL packages/entities/configurations that you add to the original files I give you or how you modify the entities/packages which are already there. I just want your code to be compatible with the 'cfg_tb.vhd' configuration I have provided, and I want to be able to execute your 'Makefiles/Makefile.sim3' to recompile your code. If you do not provide this, I can't grade your simulation and you will receive no credit.

Perl Scripts

Here are some two perl scripts that you might find useful for running all of the various test cases - I used them in generating my answers.

This script (sim3_sol.pl) expects the library name to be 'sim3', and needs to be executed in from your 'src' directory (directories 'Makefiles', 'sim3' are subdirectories). The script requires no arguments. This will run your simulation for all of the test cases required, and redirect the output of the simulator to files that are called "sim3.rawsol_1", "sim3.rawsol_2", and "sim3.rawsol_3" that correspond to the three required variations of OVERLAP and ROUND_ROBIN.

The next script reads the data that is in the 'rawsol' files and uses gnu_plot to produce plots. This script (plot_sim3.pl) expects the output to be formatted EXACTLY like what is shown in the lab discussion, so it might not work with your model.

To execute either of the perl scripts, you can do:

  % perl  script_name

Report

In addition to your graphs, write a short 1-2 page report that discusses your simulation results. Attempt to convice me that your simulation results are valid. Your REPORT must be typed and your must turn in your report and graphs in an MSU lab folder.