VHDL Simulation #2, DUE Tuesday June 15, classtime



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

Unpack the file sim2.zip in the directory in which your 'src' and 'obj' directories are located for your VHDL environment . The archive contents are:

  ./src/sim2           --- VHDL source code for elements of the sim2 library
  ./src/Makefile/Makefile.sim2   --- makefile for the sim2 library
  ./src/sim2.do        -- wave command file
  ./src/cpu0_f11-18.dat  -- data file
  ./src/cpu1_f11-18.dat  -- data file
  ./src/cpu0_f11-19.dat  -- data file
  ./src/cpu1_f11-19.dat  -- data file
  ./src/cpu0_f11-20.dat  -- data file
  ./src/cpu1_f11-20.dat  -- data file


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

 
  % cd src
  % qhmap sim2 ../obj/qhdl/sim2
  % mkdir ../obj/qhdl/sim2/ts
  % make -f Makefiles/Makefile.sim2

This will modify your local 'modelsim.ini' file so that it knows the directory mapping for the 'sim2' library.

MBUS Operation

The components in the 'sim2' 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). A value of -1 means that no request is to be made.

  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: