1 - University of Toronto



ECE532 Project:

Virtual Chess Opponent

Mandheerej S. Nandra

Eugen Tkachenko

Tuesday, April 13, 2004

Table of Contents

1. Overview 4

1.1 Objective 4

1.2 Component Overview 4

1.2.1 Video Recognition System 4

1.2.2 Chess Control System 4

1.2.3 Chessboard 5

1.3 Overall System 5

1.4 Project Block Diagram 6

2. Video Recognition System 7

2.1 Vidcap core 7

2.1.1 Hardware design 7

2.1.2 Simulation 7

2.2 External Memory Controller 8

2.3 GPIO for Controlling Video Capture (2 bits) 9

2.4 GPIO’s for Chessboard Registers 9

2.5 Recognition Software 10

2.5.1 Camera Setup 10

2.5.2 Piece Recognition 11

3. Chess Control System 12

3.1 ZBT Controllers 12

3.2 GPIO’s for Chessboard Registers 12

3.3 GPIO for Controlling VGA Port 12

3.4 Timer and Interrupt Controller 13

3.5 Chess Control Software 13

4. Chessboard 15

4.1 Power Supply 15

4.2 Control Electronics 15

5. Project Outcomes 16

5.1 Video Recognition System Outcomes 16

5.2 Chessboard and Control System Outcomes 16

5.3 Unresolved Issues 16

5.4 Further Work 17

6. Design Tree Description 18

Appendix A: Video Capture Core 19

A1: vidcap.vhd code listing: 19

A2: vidcap_v2_1_0.mpd listing: 23

Appendix B: Video capture core simulation 24

B1: OPB bus functional language test script (vidcap.bfl) 24

B2: Modified device instantiation 25

B3: Video test sequence 26

B4: Sample simulation results: 27

Appendix C: Electronics 28

C1: L298 dual H-bridge IC 28

C2: LM741 op-amp 29

C3: VGA connector pinout 29

C4: Motor signal decoder circuit and operation 30

1. Overview

1.1 Objective

The goal of this project is to produce a fully autonomous chessboard. It will not only be able to recognize when and how a human player physically moves a piece, but will also compute a reply and move the appropriate piece(s) unassisted.

1.2 Component Overview

There are three main components to this project: the video recognition system, which determines the user’s movement of a piece; the chess control system that calculates the computer’s move and controls piece movement; and finally, the chessboard itself.

1.2.1 Video Recognition System

The video recognition system consists of a camera and video capture hardware coupled with an image recognition processor. Details of this system are in section 2, and a diagram can be found in section 1.4.

The camera is mounted above the chessboard that sends a live video signal to the multimedia board’s video decoder (Analog Devices ADV7185[1]) which outputs YCbCr data in digital format. The data is then sent to the video capture core, which writes the data to off-chip ZBT memory via an On-chip Peripheral Bus (OPB #1).

The contents of the memory (the framebuffer) is analyzed with a Microblaze processor that runs simple image recognition software, and the results are written to the chessboard registers, which are in fact two instances of the GPIO IP[2] connected to OPB #1.

1.2.2 Chess Control System

The chess control system consists of a processor with significant software as well as the hardware needed to output the appropriate signals to the chessboard. Details of this system are in section 3, and a diagram can be found in section 1.4.

The processor is a second instantiation of the Microblaze IP, with two banks of ZBT memory connected to another OPB bus (OPB #2). A GPIO instance attached to this bus is connected to the various pins of the VGA encoder (Fairchild Semiconductor FMS3810[3]). The software on this processor reads the chessboard registers from two GPIO instances connected to OPB #2, and using a third party chess engine determines the computers move. The correct signals needed to move the chess pieces are then written to the GPIO instance controlling the VGA encoder, and the process repeats when the chessboard registers have changed.

1.2.3 Chessboard

The chessboard was built as part of a high-school project by Mandheerej Nandra and his former classmate, Nelson Hu, in 2000. The majority of this project, then, is focused on the previous two systems; nevertheless, some additional electronics were required to accept input from the VGA port of the multimedia board, as the chessboard was originally designed to interface with the parallel port of a PC. These can be found in section 3.

1.3 Overall System

Section 1.4 below contains the block diagram, illustrating the entire project and how its components are interconnected. The first two components are implemented on the Xilinx FF896 Microblaze and Multimedia Development Board (henceforth referred to as the multimedia board). The board contains all the components necessary to implement these two systems, but since it does not have any general purpose digital output ports, the VGA output signals of the board were used to interface with the chessboard.

The video recognition system is entirely independent from the chess control system, even using a different bus. They are only connected together by four 32-bit registers, each holding the required information for two rows of the chessboard (see section 2.4 for the storage format). Only 2-bits are needed for each square; therefore, only 128 bits are required to describe the standard 8x8 chessboard. The chess control system polls these registers for any change.

1.4 Project Block Diagram

[pic]

2. Video Recognition System

This system is based on the zbt_test system supplied to us by Leslie Shannon, and is located in the vicap directory. A video capture core was created and added to the system, as well as several GPIO instances (see sections 2.3 and 2.4). Finally, the program code in the zbt_test system was replaced with image recognition software.

2.1 Vidcap core

The vidcap core is a custom core that takes the raw data from the video decoder chip and stores the valid data in external memory that is attached to the same OPB bus as this core.

2.1.1 Hardware design

The input video stream from the video decoder has special codes that identify horizontal and vertical blanking signals, as well as whether the current field contains the even or odd lines. The code in XAPP286[4] from Xilinx has the ability to decode these inserted codes, and hence was used as the base for this core. The video core was written in VHDL, so this code was converted from its original Verilog format.

The video core is also required to write image data to memory, and to do this it must be a master device that issues requests on the OPB and follows the OPB data transfer protocol, as defined by IBM[5]. This is the main addition that was made to the XAPP286 code.

Appendix A1 contains the vhdl code used in the video core, and is commented to explain the various sections. Of particular note is that the Mn_request signal (used to request a transfer on the OPB) will go high as soon as the data is ready, but will only go low synchronous to the OPB clock. This is accomplished through the use of MstReq2 and MstReq3, as explained in the code. This reduces the latency of the bus transfer. Since the core tries to write one 32-bit value every 4 cycles of the video clock, this extra time can be crucial. This code makes no attempt to start writing at the beginning of a frame and stop at the end of one. This is because chess is a very slow game with a mostly static image being captured. Whether or not the core writes the same image over itself several times is irrelevant for the purposes of this project.

Appendix A2 shows the corresponding MPD file. This is used to let Xilinx Platform Studio know how the signals in the VHDL file are to be connected with the rest of the system. The C_FBADDR parameter is the only additional parameter in this core beyond those needed to be an OPB device, and it specifies the address of the framebuffer. For this project, it was set to 0x80105000.

2.1.2 Simulation

The vidcap core was thoroughly simulated before it was downloaded to the FPGA and tested. To do this, the IBM OBP Toolkit[6] was used to simulate the OPB bus interface. This toolkit has an VHDL entity called “opb_device” that is a model for either a master or a slave device. The model engages in OPB bus transactions as described by commands in a simple bus functional language (BFL). A script converts these commands to a ModelSim .do file, and the commands in this file are executed during simulation to define the behaviour of each “opb_device” instance.

Appendix B1 shows the listing of the test BFL script “vidcap.bfl” that was used in the simulation. This particular script initializes the arbiter as well as one OPB slave device, namely “opb_device2”. The latter is then set up to accept many transactions, as the vidcap core will be making many writes to memory. Different delays are used to observe the behaviour of the hardware under various circumstances. After conversion to a .do file, some additional commands were added to control the enabling of the

Appendix B2 shows a section of the “opb_complex”, the master testbench file provided by the toolkit, that was modified to incorporate a “vidcap” instance as opposed to another “opb_device” instance. There are some signals there that are either not part of the Xilinx implementation of OPB or have no usage in this testing scenario, so they are simply set to the appropriate constant.

Finally, the “opb_complex” entity was modified so that it would provide stimulus to the “vidcap” instance through its “YCrCb_in” and “vidcap” ports. The stimulus was generated through a custom Perl script that outputs VHDL code for each byte of input to “YCrCb_in”. A portion of this code is listed in Appendix B3.

Running the simulation in ModelSim yielded results similar to those found in Appendix B4. After some debugging, the various signals were found to behave as expected, and when this core was connect to the system, it functioned without any problems.

2.2 External Memory Controller

The video system employs an obp_emc[7] (external memory controller) core that controls a single memory block (memory block 2) of external ZBT memory on the multimedia board. In this project, the C_MEM0_BASEADDR parameter is set to 0x80100000, and the C_MEM0_HIGHADDR parameter is set to 0x801FFFFF. This creates a 1 MB address space that is big enough to hold the framebuffer, which is about 0.8 MB. C_SYNCH_MEM0 is set to 1, and C_OPB_CLK_PERIOD_PS is set to 37037 to match the OPB clock.

A dcm_module[8] (digital clock manager module) core is also needed to synchronize the memory’s clock with the data. Default parameters are used with the exception of C_CLKFX_MULTIPLY, C_CLKIN_PERIOD, and C_EXT_RESET_HIGH, which were set to 1, 37.037, and 0 repectively.

All the necessary pin assignments are located as usual in system.ucf.

2.3 GPIO for Controlling Video Capture (2 bits)

A 2-bit GPIO core (opb_gpio_1) is used to control video capture core of the program. The “GPIO_d_out” port is connected to the “inflags” port of the vidcap core. Although only one bit is used to enable and disable the vidcap core, the vector definition makes it easy to add more configuration flags should the need arise in the future.

Since this GPIO instance is used strictly for output, the C_TRI_DEFAULT parameter must be set to 0, and the C_DOUT_DEFAULT should also be set to 0 to avoid framebuffer writing on startup. Of course, C_WIDTH is set to 2 to make this 2 bits wide.

2.4 GPIO’s for Chessboard Registers

Because chess is a game where only one piece can be moved at a time (except for certain easily identifiable circumstances), only three states are necessary to describe each square: black piece present, white piece present, or no piece present (empty). Adding an additional error state, only two bits are required for each square:

|State |Binary value |

|Empty |00 |

|Black piece |01 |

|White piece |10 |

|Error |11 |

Table 2.1: Possible states for each square

A square has the error state associated with it when the program cannot recognize the color of this particular square. This situation can arise when the user moves his own piece and his hand is over the board. Categorizing each square into one of these four categories is a simple task, and the algorithm is explained in the next section (2.5).

After all 64 squares are checked, the 2-bit values are packed into four 32-bit variables. These values must be transferred to the independent chess control system. This is achieved by using additional GPIO instances. Two are attached to the video system’s OPB, and two are attached to the chess control system’s OPB. The GPIO_d_out ports of the former are connected to the GPIO_in ports of the latter.

Only two 32-bit GPIO instances (board_gpio1 and board_gpio2 in the design) are required to store four 32-bit variables, as a single 32-bit GPIO instance holds two 32-bit registers when the C_IS_DUAL parameter is set to 1. Figure 1 (obtained from the GPIO datasheet) below shows how this parameter effectively doubles the GPIO hardware. The C_TRI_DEFAULT and C_TRI_DEFAULT_2 parameters are also set to 0 to indicate output ports.

[pic]

2.5 Recognition Software

The video recognition software accesses the chessboard image that is located in the ZBT memory at the address specified in the vidcap core parameter C_FBADDR. Video data in the memory consists of 263 horizontal lines. The real picture has 525 horizontal lines in it, composed of 263 odd lines (line 1, 3, 5, etc.) and 262 even lines (number 2, 4, 6 and so on). In the usual case, these lines get interlaced with each other to get the final picture. In this project it is not necessary to use all 512 lines into memory. Using only the odd lines results in an adequate picture of the board (Figure 2).

For the purposes of this project, each horizontal line consists of 360 pixels, with each pixel containing four data elements: two Y (luminance) elements, one Cr (red difference) element and one Cb (blue difference) element.

[pic]

Figure 2: Odd lines of a test image captured using the video capture core

2.5.1 Camera Setup

The camera is fixed to a slanted tripod so that it is directly over the chessboard without interfering with its moving parts. Once fixed and oriented correctly, the axes of the board are aligned with the axes of the camera image. This allows the vertical boundaries of all squares in a row to be marked by top and bottom Y values, and likewise the horizontal boundaries of all squares in a column are marked by left and right X values.

In vidcap.c, the left and right boundaries for each column are stored in the arrays xmin and xmax respectively, and the top and bottom boundaries are stored in the arrays ymax and ymin respectively. These values do not cover the entire square so as to allow for some movement of the board, and prevent a tall piece from overlapping another square via perspective.

2.5.2 Piece Recognition

The piece recognition code scans values of Y, Cr and Cb of all dots in one square. Black pieces have red squares attached at the top and white pieces have green squares attached to them. It is much easier to recognize green and red colors on a black-and-white board.

The values of color signals are being checked for each individual dot in the square and then compared to preset values of Y, Cr and Cb signals for particular type of square. The program does not compare all three signals for each square. For example, in order to determine if there is a black (red) piece standing on the square, it is only necessary to check Cr values from all dots in the square. Cr value represents red color signal, thus square with red piece in it will have much higher average value of Cr signal than other types of squares. Similarly, green dot has much higher average value of luminance (Y) signal than other dots, and value of Cr and Cb signals are approximately equal. Therefore, it is only necessary to check for high Y value and for difference in values between Cr and Cb signals. Dots in empty squares are determined by checking particular range for all three video signals, because beige (white) and dark-brown (black) colors of squares on the board represent combination of three main signals.

Also, margin of error is introduced when comparison of signal values to preset values is being done. This margin of error is required due to unequal lighting of different squares. Squares of the same color will look different from each other because of light from the lamp falling onto them at different angles.

After the square is fully scanned, the program checks counters of red, green, black and white dots in this square. Then, the square is assigned two-bit value based on which counter is prevailing, which in turn is being shifted onto 32-bit variable. Following all these operations, the program will move onto next square and complete scanning of all 64 squares. When scanning of the entire board is complete, four 32-bit variables containing information about all squares are being shifted into memory using two 32-bit dual GPIO cores.

3. Chess Control System

The chess control system is, for the most part, just a software system, and located in the ChessAI directory. Other than a Microblaze instantiation and external memory there are only a few GPIO instances to connect this system with the video control system and chessboard. The greatest complexity of this system lies in the software.

This software, however, is complicated enough that it requires two banks of ZBT memory to reside in, mostly occupied by the third party chess engine used to compute moves. The MP3 decoder example from Xilinx was used as a base system for this reason, and all the hardware added for MP3 decoding and sound capability was removed. Any basic elements, such as a UART instantiation for remote debugging, that are present in a system built with the “Base System Builder” feature of Xilinx Platform Studio were also added and connected appropriately. The result is a basic system with two banks of ZBT memory. Other peripherals that were added to this system are described in the following sections.

However, this system was not tested at all, as effort was directed towards making a much more simple system work alongside the video system. The chess engine was removed and replaced with pre-programmed moves so that the ZBT memory would not be necessary. The only significant code that remained was that controlling the board. Unfortunately, it seems this effort was misguided as many unusual errors arose even when this basic system was compiled in the presence of the video system.

The following sections describe the final untested chess control system (including ZBT controllers, derived from the MP3 example) that was created late in the project timeline, and not the basic test system.

3.1 ZBT Controllers

Two instances of the opb_zbt_controller core from Xilinx were created to control the two banks of memory. The C_ZBT_ADDR_SIZE parameter size was set to 19 in order to control 2 MB (512k x 32bit) of memory, and the C_EXTERNAL_DLL parameter was set to 1 to indicate the use of a digital clock manager.

Two digital clock managers were used in this design, but they were not the same as in the video system. Here, they are instances of the dcm_block core found in the pcores directory. They serve the same function as those mentioned in section 2.2, and are connected similarly.

3.2 GPIO’s for Chessboard Registers

As explained in section 2.4, GPIO instances were used to transfer the chessboard information from the video system to this system. The two GPIO instances on this system, however, only need to receive input. Thus the only parameters that needs to be set are C_ALL_INPUTS, C_ALL_INPUTS_2 and C_ISDUAL, each to a value of 1.

3.3 GPIO for Controlling VGA Port

The multimedia board has a FMS3810 VGA encoder, and it’s input pins (connected to the FPGA) control the voltage level of the red, blue, and green pins of the VGA port (see Appendix C3). The h-sync and v-sync pins are directly connected to pins on the FPGA. In the chess control system, all these pins are accessed by connecting them to the GPIO_IO port of a GPIO instance.

This GPIO instance is 29-bits and used strictly for output. For these reasons, the parameters C_TRI_DEFAULT and C_WIDTH are set to 0 and 29 respectively. The GPIO_IO port is added and made external so that it can connect to the required FPGA pins.

3.4 Timer and Interrupt Controller

An instance of the opb_timer core is used to keep track of time. This is needed so that the chess engine knows when it must finish calculating its move. An interrupt controller (and instance of the opb_intc core), while not necessary, is added so that other events in the future can trigger the chess engine to stop thinking.

3.5 Chess Control Software

The chess control software is the main component of this system. It has two main parts: one controls the signals to the chessboard and the other controls the gameplay.

The code that controls the chessboard is contained in the class cBoardControl. It borrows a lot of code from the original chessboard, but is rewritten in C++ for better organization. The chess pieces used are small enough that they can move between each other when moving from one part of the board to the other. This is especially useful in the special cases of piece capture, knight moves, and castling. All these special cases are accounted for in this class. The GPIO device controlling VGA output is written to in the “UpdatePort()” function, and the values used to set the voltages on the red and green pins are stored in the array named “step”. These values were determined experimentally so that the circuit in Appendix C4 functioned correctly.

Two other classes that were created are a cBoard class and a cChessAI class. The former is used to store a chessboard in a similar form as that mentioned in section 2.4. It is also capable of determining which piece was moved by comparing two such boards. The cChessAI class is simply a wrapper for the third party chess engine. It updates the chessboard data structures in the chess engine, acquires computed moves, and runs the “PonderPosition()” function while waiting for the user move. This will assist the computer when it is time for it’s own move.

The chess engine used was Beowulf[9], a capable third party open source chess engine. It was chosen for its strength and ease of integration relative to other chess engines. Many modifications had to be made to the some 20,000 lines of C code included in this engine, most importantly the elimination of all file access. Since all chess engines require an opening book, this data had to be stored in a fixed array instead. Dynamic memory allocation was also eliminated since there is very limited memory on the multimedia board, and errors on allocation was very likely. Of course, the user interface had to be completely removed also so that the engine would work with game flow of BoardControl.cpp, the parent C++ file for this project that contains the program entry point “main()”. Other system calls, such as those to the windows timer, also needed replacing. Overall, this was a very large task.

This system was tested and debugged on a PC first. All writes to GPIO were disabled, and the chessboard registers were manually changed in the debugger rather than by the video system. Through the use of #ifdef _WIN32 … #endif constructs, minimal code changes were necessary when porting the debugged PC version of the software to the Microblaze system.

4. Chessboard

The chessboard is constructed like a plotter beneath the playing surface. Stepper motors control the x and y position of a strong magnet that is mounted on a solenoid. When current passes through the solenoid, the magnet moves close to the board, allowing it to hold and move the piece directly above it when the plotter moves. When there is no current, it is far enough from the board that the plotter mechanism moves the magnet without affecting the position of any pieces.

4.1 Power Supply

While the chessboard already had electronics to control the stepper motors, it used an unorthodox setup needing both +12V and -12V power sources with significant current supply to drive the motor coils in different directions. The better solution is to use a H-bridge circuits, which allows the use of a single 12V power supply to drive the motors, easily obtainable in any computer power supply. This was easily accomplished through the use of L298 H-bridge IC’s (see Appendix C1 for pinouts).

The power could now be supplied with a standard AT power supply. The newer ATX power supply standard requires loading the +5V terminals in order to turn on, adding unnecessary complication.

4.2 Control Electronics

The larger design issue is interfacing the chessboard to the multimedia board. Since there are no general purpose digital output ports, the VGA port was used to deliver the required information to the board. The VGA port consists of red, green, blue, h-sync and v-sync signals. The chessboard needs two signals for each of the two motors, one signal to control the magnet, and one signal to disable current through the motors. The last signal is desired because stepper motors dissipate energy even when they aren’t turning, and can thus get very hot, especially during a lengthy chess game.

Therefore six signals are needed, but only five are available. Furthermore, our particular multimedia board had a malfunctioning blue signal. This problem is circumvented by multiplexing two signals on the red and green signals. Using 4 voltage levels on these pins, two bits of information can be carried on each. Appendix C4 shows the details of the circuit used to decode the voltage from one of these pins into four digital TTL-compatible signals. These output signals are connected to the corresponding input pins of the L298 (pins 5, 7, 10, and 12). The stepper motors have two coils: one is driven by pins 2 and 3, and the other by pins 3 and 4. The remaining pins are connected as suggested in the upper diagram of Appendix C1. This entire circuit was duplicated for the

The h-sync signal controls the magnet via a TIP29 power transistor, and the v-sync signal controls the two enable inputs (pins 11 and 6 on the L298) of the two H-bridge circuits. The VGA signals thus have full control of the chessboard.

5. Project Outcomes

All components of this system work well separately, and the connection between the chess control system and chessboard electronics is also flawless. The major problem encountered that prevented completion of this project occurred when merging the chess control system with the video recognition system.

5.1 Video Recognition System Outcomes

The video capture and pattern recognition system works well. The image is captured from video inputs into external memory, each square on the board is scanned and assigned the correct value based on the type of piece standing on it. The values are all packed correctly as well into the chessboard registers. There was a minor issue in this system that was given low priority; see section 5.3 for a description of this issue.

5.2 Chessboard and Control System Outcomes

The chess control system also functioned correctly, although the complete system with AI was never fully tested on the multimedia board. As explained in section 4, efforts were concentrated in getting the basic control system without the chess engine or external memory to merge with the video recognition system, but to no avail. Nevertheless, the VGA port of the multimedia board was outputting the correct signals, and the software controlled the chessboard perfectly.

The chessboard itself was also completely functional. Although this is to be expected since the board was functional prior to embarking on this project, there were new electronics added that were by no means trivial. These circuits functioned perfectly, and demonstrated a creative and successful workaround for the limited means of outputting arbitrary signals from the multimedia board. This allowed the chess control software to correctly control the movement of pieces on the chessboard. The only major problem encountered was some sort of short circuit at the power supply plug when presenting the project, resulting in the inability to properly showcase the piece movement.

5.3 Unresolved Issues

As mentioned above, problems with adding another Microblaze system to the video recognition system prevented further integration of all system components. We were able to have two simple Microblaze systems work after hours of searching through the many files generated by XPS as well as the online ISE documentation, but could not do the same with the video recognition system.

There was a minor problem with the video recognition system. The video capture would only work if the vidcap code was enabled and disabled by manually stepping through the code that asserted and deasserted the 2-bit GPIO signals (see section 2.3). When a delay loop was used instead to allow the vidcap core enough time to capture a frame, nothing was written to memory, even with long delay times. One theory as to the cause of this problem is that the delay loop causes the Microblaze to saturate the OPB when incrementing the counter, thus blocking the video data from being written. Another theory is that the debugger is constantly polling the UART, and saturates the system in that way. There was not enough time to test either theory, unfortunately, as other aspects of the project had higher priority.

5.4 Further Work

The obvious direction for further work is to complete the integration of the video recognition system with chess control system. If the minor problem with the video recognition system was also fixed, then the resulting system would be a complete chess-playing computer, which can recognize opponent’s moves, find the best move to answer using the Beowulf chess engine, and move required pieces on the board, thus satisfying the project’s goals.

However, should this task be too difficult, it is possible to run the video capture software and chessAI software on one Microblaze processor, provided there is enough external memory available. However, there won’t be any pondering ability (see section 3.5), since there is only a single execution thread now. In hindsight, this would have been a better course of action when it was discovered that multiple processors were causing problems.

6. Design Tree Description

ChessAI\ – Contains the chess control system.

ChessAI\code\ – The source code for the software component of the chess control system

BoardController.cpp – Parent file containing the entry point

cBoardControl.cpp/h – Class controlling input to chessboard electronics

cBoard.cpp/h – Chessboard class

cChessAI.cpp/h – Chess engine wrapper class

Beowulf\ - Directory containing chess engine source code. The following files were significantly modified from the original Beowulf source:

main.c – Added the initialization of the chess engine

parser.c – Added functions called by the wrapper class

computil.c – Modified time measurement and user input functions

vidcap\ – Contains the video recognition system

vidcap\sst2 – A TCL script used to download the framebuffer into a file.

vidcap\chdump.txt – A partial memory dump of the framebuffer showing a chessboard

vidcap\code\vidcap.c – The source code for the video recognition

FrameBufferViewer\ – Contains an application created for the PC to view a framebuffer dump. “chdump.txt”, mentioned above, can be viewed with this application. Both the source code and the executable are included in this directory.

sim\ – Contains simulation files

sim\OPB_TOOLKIT2X_052401\ – The IBM OPB Toolkit

sim\OPB_TOOLKIT2X_052401\vidcap.bfl – BFL script for OPB simulation

sim\OPB_TOOLKIT2X_052401\vidcap.do – Generated ModelSim .do script

sim\vidcap.do – ModelSim script used for simulation

sim\gen_vid_tb.pl – Perl script to generate video stream stimulus

sim\stimvhd.txt – Output of gen_vid_tb.pl

sim\opb_complex.vhd – Modified testbench using the vidcap core

sim\vidcap.wlf – ModelSim waveform containing simulation results

Appendix A: Video Capture Core

A1: vidcap.vhd code listing:

library ieee;

use ieee.std_logic_1164.all;

use ieee.std_logic_arith.all;

use ieee.std_logic_unsigned.all;

entity vidcap is --USER-- change entity name

generic

(

C_OPB_AWIDTH : INTEGER := 32;

C_OPB_DWIDTH : INTEGER := 32;

C_FAMILY : string := "virtex2";

C_FBADDR : std_logic_vector(0 to 31) := X"00005000"

);

port

(

--Required OPB bus ports, do not add to or delete

Mn_ABus : out std_logic_vector(0 to C_OPB_AWIDTH - 1 );

Mn_DBus : out std_logic_vector(0 to C_OPB_DWIDTH - 1 );

Mn_request : out std_logic;

Mn_busLock : out std_logic;

Mn_select : out std_logic;

Mn_RNW : out std_logic;

Mn_BE : out std_logic_vector(0 to C_OPB_DWIDTH/8 - 1 );

Mn_seqAddr : out std_logic;

OPB_Clk : in std_logic := '0';

OPB_Rst : in std_logic := '0';

OPB_DBus : in std_logic_vector(0 to C_OPB_DWIDTH - 1 ) := (others => '0');

OPB_MGrant : in std_logic := '0';

OPB_xferAck : in std_logic := '0';

OPB_errAck : in std_logic := '0';

OPB_retry : in std_logic := '0';

OPB_timeout : in std_logic := '0';

--User ports

led1 : out std_logic;

led2 : out std_logic;

YCrCb_in : in std_logic_vector(9 downto 0);

vid_clk : in std_logic;

inflags : in std_logic_vector(0 to 1)

);

end entity vidcap;

architecture imp of vidcap is

signal Mn_select_s : std_logic := '0';

signal Mn_request_s : std_logic := '0';

signal pixeldata : std_logic_vector (31 downto 0) := X"00000000";

signal vidcount : std_logic_vector (0 to 31);

signal cnt : std_logic_vector (0 to 31) := X"00000000";

signal write_ena : std_logic;

signal H_rg : std_logic_vector (4 downto 0);

signal H_rising : std_logic;

signal TRS : std_logic;

signal V_falling : std_logic;

signal V_rising : std_logic;

-- the next 5 signals act as a fifo for video data

signal YCrCb_rg1 : std_logic_vector (9 downto 0);

signal YCrCb_rg2 : std_logic_vector (9 downto 0);

signal YCrCb_rg3 : std_logic_vector (9 downto 0);

signal YCrCb_rg4 : std_logic_vector (9 downto 0);

signal YCrCb_rg5 : std_logic_vector (9 downto 0);

signal Fo : std_logic;

signal Ho : std_logic;

signal Vo : std_logic;

-- These signals are used to request a bus transfer asynchronously

-- wrt the OPB clock (i.e. as soon as video data is ready)

signal MstReq2 : std_logic;

signal MstReq3 : std_logic;

signal NewData : std_logic;

begin

-- These signals should be hooked up to LEDs

-- led1 is high when writing is enabled

-- led2 flashes about 7 times per second when a valid

-- video source is hooked up

led1 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download