CSE 362M Lab #3
CSE 362 LAB 3
INTRODUCTION
The video subsystem used with Labs 0, 1, and 2 (implemented in vga.vhd) uses a “simple
dual-port RAM,” i.e., a Xilinx block RAM dual-port memory with one “write” port and
one “read” port, to implement the video framestore. The port map for the simple dual-
port RAM inside the video module is shown below.
myram:blk_mem_gen_0
PORT MAP(clka => src_clk ,
ena => ena ,
wea => wea ,
addra => addra ,
dina => dina ,
clkb => vga_clk ,
addrb => addrb ,
doutb => doutb) ;
The RAM does have independent read and write clocks, and in Labs 0, 1, and 2 the
RSRC writes into port “A” with timing based on the 50 MHz src_clk, while the output
video circuitry reads from port “B” with timing based on the 25 MHz vga_clk.
As generated for Labs 0, 1, and 2, the “write” or “A” port has ena (enable) and wea (write
enable) control inputs, along with addra (address) and dina (data) inputs. The “read” or
“B” port is configured to be “always enabled,” and thus it has just an addrb (address)
input and a datab (data) output.
Jumping up a level and looking at the decoding logic in the top-level VHDL module,
testbench.vhd, we find the following logic:
vga_ena <= '1' WHEN address(31 DOWNTO 21) = "00000000001" ELSE '0' ; vga_wea <= "1" WHEN write = '1' ELSE "0" ; The vga_ena signal implements the address decode, while the vga_wea signal is connected directly to the RSRC “WRITE” signal. The strange “vector” assignment is needed because the RAM wea control signal is defined as a vector by the Xilinx Vivado IP tool when the RAM is generated. In many cases, the RAMs generated by the tool have byte enables, i.e., one enable for each byte in a larger word. A 32-bit word would have four (4) byte enables, for example. This makes things a bit more complicated, but once understood it’s easy to handle. In labs 0, 1, and 2, vga.vhd entity is port-mapped into the top-level design as shown below. vga1:vga PORT MAP(src_clk => src_clk,
ena => vga_ena,
wea => vga_wea,
addra => address(20 DOWNTO 2),
dina => d(8 DOWNTO 0),
vga_clk => vga_clk,
r => r,
g => g,
b => b,
hs => hs,
vs => vs);
While the video subsystem provided works fine for Labs 0, 1, and 2, it is lacking a
significant feature built into almost every video subsystem: The ability for the CPU to
read from the framestore.
One way to add readback capability from the framestore would be to use a “true dual-port
RAM” instead of a “simple dual-port RAM.” With this approach, the both the “A” and
“B” ports of the RAM would have write and read capability. Most framestores are
implemented with single-port RAMs, however, due to the fact that single-port RAMs are
available with far higher densities than dual-port RAMs. In this laboratory, you will add
readback capability using the original single-port RAM.
Since the single-port RAM used for the framestore has twice the bandwidth needed on
the “B” side, i.e., it is clocked at half the rate of the “A” side in Labs 0, 1, and 2, the “B”
port can be used to read data both for the video output circuitry and for the CPU by using
the 50 MHz clock and timesharing the “B” port.
At the top level of the hierarchy (inside testbench.vhd), our vga entity would have to be
modified to support both “write to” and “read from” capability as shown below.
COMPONENT vga
PORT(src_clk : IN STD_LOGIC ;
reset_l_sync : IN STD_LOGIC ;
ena : IN STD_LOGIC ;
wea : IN STD_LOGIC_VECTOR(0 DOWNTO 0) ;
oea : IN STD_LOGIC ;
addra : IN STD_LOGIC_VECTOR(18 DOWNTO 0) ;
d : INOUT STD_LOGIC_VECTOR(31 DOWNTO 0) ;
done : OUT STD_LOGIC ;
vga_clk : IN STD_LOGIC ;
r : OUT STD_LOGIC_VECTOR(3 DOWNTO 0) ;
g : OUT STD_LOGIC_VECTOR(3 DOWNTO 0) ;
b : OUT STD_LOGIC_VECTOR(3 DOWNTO 0) ;
hs : OUT STD_LOGIC ;
vs : OUT STD_LOGIC);
END COMPONENT ;
With this definition, the top-level design can be modified to support both framestore
“write to” and “read from” functionality. A new “output enable” signal, oea, is needed,
but this is not all that is required: There is a one-clock-tick latency when reading from the
RAM implemented using Xilinx block RAM that also has to be taken into consideration!
To support the read latency, a “done” signal has been added to the entity. This new
“done” signal will be driven by the VGA module on both reads and writes to simplify the
logic implemented in testbench.vhd. Note, too, that the data (D) port must be
bidirectional, i.e., defined as “INOUT,” instead of just “IN.” A reset will also be required
to initialize the state of the necessary control components inside the modified vga.vhd
module.
For this lab, it is required that you use the vga entity defined above.
STEP 1
Make a copy of your original Lab 0 Vivado project folder or recreate your Lab 0 project
folder. This laboratory will use the basic hardwired control unit design from Lab 0.
STEP 2
Assemble the program below using the JAVA assembler, then use the eprom.exe
program supplied by the instructor to convert the eprom.bin file produced by the
assembler to a new EPROM.VHD file for simulating your Lab 3 design. It is
recommended that you do this step before you run Vivado or with Vivado closed (you
will be replacing EPROM.VHD outside of the tool flow).
Make sure to remember to run EPROM.EXE after generating new a new eprom.bin file
using the JAVA-based assembler: This program will automatically generate a new
eprom.vhd file when run from the directory with the eprom.bin file.
.org 0
la r31,LOOP
la r29,TOP
la r1,0
lar r2,MYVGA
TOP: lar r30,MYVGA
LOOP: ld r1,0(r30)
addi r1,r1,1
st r1,0(r30)
addi r30,r30,4
and r3,r30,r2
brnz r31,r3
br r29
.org 2097152
MYVGA: .dw 524288
This new program repeatedly reads/increments/writes back each pixel in the framestore.
To keep the program as simple as possible, the framestore is not initialized. Here, we will
rely on the fact that Vivado will create the simple dual-port RAM initialized to all zeroes.
Once you have a new EPROM.VHD file in place, run Vivado and continue to Step 3.
STEP 3
Modify testbench.vhd to properly wire up the modified vga entity. You will need to
create the vga_oea signal to connect to the oea port on the vga entity and define a new
“vga_done” signal to connect to the done port on the vga entity. Remember, you cannot
connect “done” in testbench.vhd directly to done on the vga entity because they are
different signals: “done” in testbench.vhd connects to the RSRC, while “done” from the
VGA module is an indication that the data transfer to/from the VGA memory is ready to
complete at the next rising clock edge. This may seem a bit confusing at first, but it is
very important that you understand how VHDL uses and reuses names, etc. Your VHDL
assignment for “DONE” in testbench should end up looking like this:
done <= '1' WHEN (eprom_ce_l = '0' OR sram_ce_l = '0' OR vga_done = '1') ELSE '0' ; STEP 4 You now have to engineer/architect vga.vhd to support port “B” reads from both the video circuitry and from the RSRC. Since the video circuitry needs data on every rising 25 MHz clock edge, it should be obvious that the “B” port will need to be clocked at 50 MHz and modifications made to the datapath to support the additional functionality. Document the datapath for your final design in block diagram form you can submit to Canvas for grading. Once the datapath has been modified, you will need to develop the control circuitry needed to control the datapath properly. The FSM you design must be implemented using formal methods as outlined in the VHDL tutorial. Note: Significant time will be spent in lecture discussing Step 4. STEP 5 Simulate your modified design from STEP 4 running the assembly code you used to create EPROM.VHD in STEP 2. Verify that your design works as expected, and fix any issues you find. Repeat the simulation from STEP 4 of Labs 1 and 2, this time dragging reg1, reg2, reg3, reg30, and reg31 up under the “done” signal in the waveform display. Run the simulation long enough to see all five registers being updated. Set the Zoom so that you can clearly see all five registers being set and then updated and so that the values in each register can clearly be read for grading. Take a screenshot of the properly zoomed simulation waveform display showing reg31 being updated (see tutorial slide 73) with the yellow cursor placed at the exact instant reg31 is first updated and submit it to Canvas for grading. STEP 6 Implement your design using the Vivado tools and generate a .BIT file for testing. STEP 7 Upload a copy of your datapath block diagram from STEP 4 to Canvas for grading. Upload a Zipped copy of your full Vivado project folder to Canvas for testing and grading. Note: Only .ZIP files will be accepted (no .TAR or .RAR files please). Project folders not created so that they are completely transportable between machines will result in a 50% point deduction. GRADING RUBRIC 1) Properly created eprom.vhd file: 10% 2) Properly modified testbench.vhd file: 20% 3) Properly architected video system datapath from STEP 4: 20% 3) Properly implemented vga.vhd file (datapath and FSM)*: 30% 4) Functioning .BIT file*: 20% *Correct implementations will result in no visible “flashes” or other visual artifacts in the video display. Submissions will be tested extensively to check for proper circuit operation, and deductions will be made for implementations that do not meet the full lab specification.