Introduction

This simulation looks at the SPARC MBUS interface and tests the student's ability to create a VHDL model that duplicates observed functional behavior. In other words, it tests MODELING ability rather than mastery of syntactical language elements.

To Do

  ./obj/qhdl/reese      --- VHDL object code for the 'reese' library
  ./src/reese           --- VHDL source code for elements of the 'reese' library
  ./src/Makefile/Makefile.reese   --- makefile for the reese library
   

After unpacking the file, you will need to do the following:

 
  % cd src
  % qhmap reese ../obj/qhdl/reese

MBUS Operation

The components in the 'reese' library model the MBUS access protocol as discussed in class. The important entities/configurations are as follows:

1. 'cpu' -- an entity used emulate a CPU's MBUS accesses. The CPU model reads a datafile specified by the 'infile' generic that determines how long the cpu component is to retain the bus, the address to place on the address bus during the MBUS access, and when the next request should take place. The 'cpu_behv.vhd' contains the architecture for the CPU; currently this architecture is empty and it is your job to supply the needed code. There will be more discussion on the CPU entity later in this document.

2. 'arbiter' -- an arbiter entity that implements a round robin priority scheme. This version of the arbiter is currently limited to only four pairs of bus request/bus grant lines.

3. 'tb' -- an entity testbench that connects two CPU components to an arbiter component.

4. 'stim' -- a stimulus entity that provides the clock signal for the simulation.

5. 'cfg_tb_f11_18' -- configuration whose simulation should produce a waveform equivalent to Figure 11-18 of the HyperSparc User's guide. Associated CPU data files are cpu0_f11-18.dat, cpu1_f11-18.dat. The simulation waveform is shown below:
   
   
   
   

6. 'cfg_tb_f11_19' -- configuration whose simulation should produce a waveform equivalent to Figure 11-19 of the HyperSparc User's guide. Associated CPU data files are cpu0_f11-19.dat, cpu1_f11-19.dat. The simulation waveform is shown below:
   
   
   
   

7. 'cfg_tb_f11_20' -- configuration whose simulation should produce a waveform equivalent to Figure 11-20 of the HyperSparc User's guide. Associated CPU data files are cpu0_f11-20.dat, cpu1_f11-20.dat. The simulation waveform is shown below:
   
   
   
   

What You Must Do

You are to complete the 'cpu_behv.vhd' code such that the waveforms associated with the three configurations discussed above can be duplicated. The timing must be 'clock phase accurate'; this means that the signals must transistion in the same clock phases as they do in the reference wave forms but the signals DO NOT have to transistion at exactly the same time as the reference waveforms (in these simulations, all signals transition after the rising clock edge and are stable before the falling clock edge).

The CPU architecture must read a data file defined by its 'infile' generic; the definition of the data file contents are:

1. The first line contains an integer which defines the clock cycle in which the FIRST mbus request is made (a value of '1' indicates the MBUS request should be made in first clock cycle).

2. Each line after the first contains three numbers. The first number specifies how many clock cycles the processor is hold the bus after it has been granted the bus (how many clock cycles the 'bbusy' line to be held low). The third number specifies the address to be placed on the address bus during assertion of the 'bbusy' line. The second number specifies how many clock cycles from the CPU's assertion of 'bbusy' to the next assertion of its bus request line. If you look at the reference waveform for 'cfg_tb_f11_20' and the associated data files, you can see how this works. If the second number is a '-1', then this means that no further requests are to be made.

The port definition of the CPU entity is as follows:

• clk, input clock
• breq, output, connected to 'breq' input of arbiter.
• bgrant, input, connected to 'bgrant' output of arbiter.
• bbusy, output, modeled as an 'open drain' driver. The CPU component can only drive this line with a '0' or 'Z' value; this line is shared by other CPU components in the system and has a pullup on it.
• addr_strobe,output, modeled as an 'open drain' driver. The CPU component can only drive this line with a '0' or 'Z' value; this line is shared by other CPU components in the system and has a pullup on it.
• addr, output, modeled as a tri-state driver. This is the common address bus for all CPU components. When the CPU does not have ownership of the bus it should drive this output with a 'Z' value.
• active, output, modeled as an 'open drain' driver. The CPU component can only drive this line with a '0' or 'Z' value; this line is shared by other CPU components in the system and has a pullup on it. The 'active' output is not part of the MBUS interface. It is a shared line monitored by the 'stim' entity. The default output value of the 'active' output should be a '0'; the CPU component should drive the 'active' output with a 'Z' after it has finished with its last transaction (released 'bbusy' and detected that it needs to generate no more bus requests). As long as any CPU is generating bus requests, the 'active' line will be a '0'. When all CPU components have finished generating requests, the 'active' line will be pulled to a 'H'; this will be detected by the 'stim' component and the 'stim' component will stop generating clock pulses.

  To Turn In

  The only file I am interested in is 'cpu_behv.vhd'. Create a directory called 'sim2' and place the 'cpu_behv.vhd' file in this directory. From the directory above 'sim2', execute the script '~reese/bin/submit_sim2.sh'. This will create a compressed tar file of your 'sim2' directory and will mail it to me.