INTRODUCTION

We will begin by giving an overview of the entire system. In general, we will approach the overall system issues by separately addressing each of the functional units that comprise the system. We will describe the requirements, design and issues of each unit. We will also analyze how well the unit can perform its task and we will describe test approaches we use.

System Functional Overview

This project consists of three major components: a Spectronix black and white video camera, an FPGA-based control/analysis device, and a VGA monitor for image display. The camera’s image capture is controlled by a small, onboard microprocessor that allows it to take in 160 by 120 pixel resolution black and white images at a rate of 30 frames per second.

This video data is then fed into the memory control unit onboard the FPGA, where it is stored into memory for analysis and video output. This memory control unit is responsible for performing double buffering of screen display images, storing frames of interest for the analysis unit, and scheduling memory accesses from the rest of the system.

The analysis unit performs the actual motion detection for the system. To do this, it must communicate with the memory manager to control when images will be stored for analysis. It also performs a basic, subtractive algorithm for image comparison processing that makes up the device’s motion detection capability. This unit can then alert the VGA control unit when motion is detected, at which time the system will respond accordingly for its specific use. In security applications, for example, this might consist of setting off an alarm. Likewise, in a common monitoring application, the system may notify parents that a baby is stirring in its room.

System Layout

The basic layout of this design has been kept simple in an effort to achieve the highest level of modularity for the system. Though this system is specialized, we are hoping to keep it packaged tightly enough to allow for many types of applications to take advantage of its basic structure. This desire for simplicity is reflected in the block diagram for the overall system in figure 1 below.

Figure 1: Overall System Block Diagram

REQUIREMENTS

This system requires that many technical and functional requirements be met to ensure proper functionality. These requirements are listed and discussed in detail in the following sections.

Overall System Requirements

The video monitoring and motion detection system will take 160 by 120 pixel black and white images from the camera at a rate of 30 frames per second, and display these images on the monitor. It will acquire 2 images (frames) per second from the camera for motion analysis, allowing for a sample rate of 2 Hz and detection of objects moving between 2 and 12 ft per sec. Exact motion detection parameters will be adjustable based on system threshold values The overall system also requires its internal units to work with the electrical specifications shown below in table 1.

Table 1: System Requirements

Component	Parameter	Value	Comments
RC-1 Camera	Current Consumption	50 ma	Maximum
	Operating Voltage	9-12 VDC	Good noise de-coupling required
	Absolute Maximum Supply Voltage	15 VDC
	Maximum cable length	3 ft	Maximum length may require static protection
	Frame Rate	30 fps	Pixel rate = 576000 pixels/sec avg.
XSV-300	Supply Voltage	9 VDC
	Absolute Minimum Supply Current	1.5 A
	System Clock	25MHz
	Max SRAM Access Time	4 cycles	To be able to draw 160x120 image on VGA given timing specs.
Additional System Requirements	Motion Detection Frame Sample and Rate	2Hz
	Maximum time to analyze a pair of images	1 sec
	Rate of Motion Detected	2 to 12 feet/sec
	VGA Refresh Rate	60Hz	Pixel rate = 1,152,000 pixels/sec avg. for image drawing
	VGA Display Size	640x480 pixels
	Maximum RAMDAC Programming Speed	15MHz
	Maximum Camera Initialization Speed	100KHz	Over I²C serial communications line

Camera Control Unit Requirements

The Camera Control Unit is also located on the XSV-300’s FPGA, and is used to initialize and operate the camera. The RC-1 camera module has many configurable parameters. Most of the default values for the parameters are suitable for us, but we need to change a subset of parameters in order to have the camera generate a useful data stream for our purposes. The required camera configuration for 30Hz frame rate and single-clocked data transfer is summarized below in table 2. Refer to the VV-5300 chip documentation for more details on these settings.

Table 2: RC-1 Camera Settings

Parameter	Value
Data Format Select	8 wire parallel output
Status Line Data Output Enable	Off
ADC Select	8 bit
FST/QCK pin mode	Normal FST / QCKs pin
QCK Mode Select	Validate image data only

Memory Manager Unit Requirements

The Memory Manager Unit must monitor the continuous stream of data from the Camera Control Unit and store that data in the proper location. It must also provide the correct data to the VGA Control Unit and the Analysis unit upon request. These two situations can be considered separately.

Incoming Data

The Memory Manager Unit must be able to monitor the incoming data stream from the Camera Control Unit and store it for use by the VGA Display Unit and the Analysis Unit. The incoming data stream will have a maximum transfer rate of 576,000 pixels/sec, based on the required 30 frames/sec capture rate. Ram access time for image storage is a minimum of 15 nanoseconds, allowing for at most 50 million accesses/sec. Thus, camera data storage will require just over 1% of system ram accesses.

Once the Memory Manager Unit begins the storage of an image to a particular destination, it must successfully complete the operation. No data can be lost or modified in the process. This requires that at least 1 image pixel be written for every 2 display pixels read, based on the required 30Hz input frame rate, and 60Hz output frame rate.

Also, the unit will be automatically switching video buffers to achieve the desired double-buffering effect for data being displayed on the monitor. The transition from one destination buffer to the other must only happen between image frames, and will thus be based on the frame start signal from the camera. Image data will be interlaced in the memory in an even-odd fashion, to support efficient data storage for this double-buffering scheme and the “2-pixels at a time” analysis algorithm used by the Analysis Unit (discussed in the Analysis Unit Design Section).

Outgoing Data

The Memory Manager Unit must be able to provide pixel data to the VGA Control Unit and the Analysis Unit. Data requested by the VGA Control Unit must always come from the on-screen video buffer, and must have a minimum transfer rate of 1,152,000 pixels/sec to meet the system frame rate spec of 60Hz. Based on the maximum ram access rate of 50 million accesses/sec, output pixel reads will compose just over 2% of total available ram accesses.

Data storage will be requested by the Analysis Unit at a rate of 2 frames/sec, and data will also be read by the analysis unit at a rate of 2 frames/sec. Thus, the Analysis Unit will require a 76,800 pixels/sec transfer rate from the Memory Manager Unit. To maintain a proper ratio of accesses from the memory, at least one Analysis Unit request must be granted for every 8 camera pixels written (and every 16 VGA pixels read).

VGA Control Unit Requirements

VGA Unit Requirements

The VGA Control Unit is located on the FPGA, and thus has the same power requirements as the XSV-300. In addition, it has specific requirements associated with each of its three functional responsibilities.

RAMDAC Initialization

The VGA Control Unit must properly initialize the RAMDAC chip when the system is reset. There are no quantitative requirements associated with this function. The only necessity for this function is that the proper communication protocol and timing requirements are met to properly write values into the RAMDAC chip. This protocol is specified in the documentation for the RAMDAC chip (see the References section). The RAMDAC programming interface has timing requirements that the limit programming rate to at most 15MHz.

VGA Synchronization Signal Generation

The VGA Control Unit must properly generate horizontal and vertical synchronization signals for the attached VGA monitor. The specific timing requirements for these signals are described later in the design portion of this document. The most important parameter to note is that the VGA pixel rate is 25Mhz for a 640x480 display. This is the same speed as our system, which means we must be able to generate a pixel value at each clock cycle. However, we will be storing image data in SRAM, which requires a minimum of two cycle to access. Based on this, we will not be able to fill the entire screen with data from memory. However, the images are one-quarter the linear size of the screen in each dimension. This will allow us up to four cycle to obtain an image pixel from memory.

Pixel Data Management

The VGA Control Unit must obtain pixel information from the Memory Manager Unit and pass this information to the RAMDAC. This sequence of events must happen in the necessary timeframe specified by the VGA specification. It must also meet the system requirements of 60Hz image display of 160 by 120 pixel images, which will require a minimum pixel transfer rate of 1,152,000 pixels/sec.

Analysis Unit Requirements

The Analysis Unit performs the main work on the incoming data stream. It must communicate with the memory control unit in order to perform analysis on the data stream on a frame-wise basis. There is a fine balance between the speed at which the unit must run to ensure efficient motion detection for fast motions, and the speed at which the unit can pull frames from the data stream to ensure detection of slow movements. The requirements that must be met by the unit for communication and data analysis are further discussed below.

Communications

As discussed above, the analysis unit must request for the memory management unit to store 2 frames/sec of image data. Because this data will be stored in memory one pixel at a time, requests must be synchronized with a new frame start in the memory manager unit to ensure that full frames of data are captured. The rate at which frames are pulled from the incoming data stream also is held at 2 Hz, because the frame rate of the camera is too fast to capture slower movements. Once sufficient data has been pulled into the buffer for analysis (two full images), the unit must be able to analyze the data and alert the system of motion detection.

Image Analysis

Once data has been captured, the system must analyze that data. This entire data capture/analysis cycle must be performed in at most 1 sec to ensure that the incoming data stream is sampled and analyzed at an adequate rate for efficient motion detection to occur. This places a requirement on the Analysis Unit to be able to perform 38,400 writes to memory (2 frames), 38, 400 reads from memory (2 frames), and 19,200 subtracts, comparisons and adds per second (analysis portion).

Error handling must also be addressed by the Analysis Unit. Noise and pixel blooming are known problems with the RC-1 camera, and will be remedied by appropriate choice of threshold value for the analysis algorithm (as discussed in the Analysis Unit Design section). The camera has a known random noise rate of –36 dB, which is fairly small but must still be considered in the Analysis Unit Requirements..

DESIGN

The system is implemented with the Xilinx FPGA on the XSV-300 board. The FPGA receives and controls the frame images in pixels from the RC-1, stores and loads the pixels into SRAM onboard the XSV-300, outputs video frames through the onboard RAMDAC to the VGA display, and performs the data analysis. The project is broken down into functional components, each of which can be developed independently of the others. The four different functional modules are:

Camera Control Unit

Memory Manager Unit

VGA Control Unit

Analysis Unit

The specific details for each design unit are as follows:

Camera Control Unit Design

The Camera Control Unit communicates with the camera via the SCL and SDA serial lines to configure the camera. These two signals implement a bi-directional, 2-wire I²C communications interface that allows the video camera to be configured and its operating status monitored. During normal camera operation, it provides a continuous stream of pixel information as well as frame start and pixel clock signals. The Camera Control Unit obtains the pixel data from the camera and sends it to the Memory Manager Unit. The block diagram for the Camera Control Unit is shown below in figure 2.

Figure 2: Camera Control Unit

Configuration Set Up

By using the SDA and SCL signals, the Camera Control Unit sets up and configures the RC-1 so that the frame image is 160x120 pixels and the frame rate is 30 frames/sec.

Pixel Data Transfer

The Camera Control Unit does no processing on the data stream from the camera. It simply passes the data and the control signals to the Memory Manager Unit, which is responsible for reading and storing the image information.

Memory Manager Unit Design

The Memory Manager Unit performs the following tasks:

Collects image data from the camera and store it in SRAM

Provides the Analysis Unit with image data upon request.

Provides the VGA Control Unit with image data upon request.

The Memory Manger Unit will have one source of incoming data (the camera) and must provide data to both the VGA Unit and the Analysis Unit. Since the SRAM will be a shared resource, access to it is controlled with a locking mechanism. When a unit requests data, it signals the Memory Manager Unit and provides the address it is interested in. Then, based upon the state of SRAM access, the manager fetches the data at some later time. The requesting unit will be informed by a one-cycle pulse on the ready line. The block diagram for the Memory Manager Unit is show below in figure 3.

Figure 3: Memory Manager Unit Block Diagram

General Memory Management

The Memory Manager Unit continuously monitors the data stream and the Frame Start line from the Camera Control Unit. Upon seeing a Frame Start signal, the unit begins writing the image data to the SRAM. When the VGA Control Unit or Analysis Unit requests a particular pixel value, the Memory Manager Unit provides the pixel at the earliest opportunity, ensuring that no incoming data is lost. Essentially, SRAM access among the various units is interleaved. Each unit is given a priority which is used by the memory manager to decide the next request to service. More discussion of this approach is found in the analysis section of this document.

VGA Control Unit Design

The VGA Control Unit is responsible for displaying image data on the monitor. It does this by directly controlling the vertical and horizontal synchronization signals to the monitor. The analog color signals for each pixel are generated by using the 8-bit pixel data to look up a corresponding 24-bit color value from a lookup table. The RAMDAC chip on the XSV-300 board implements this lookup table. Because of their close relationship, the VGA Control Unit is also responsible for initially configuring the RAMDAC chip, using the specifications given in the requirements section. The block diagram for the VGA Control Unit is show below in figure 4.

Figure 4: VGA Control Unit Block Diagram

RAMDAC Initialization

When the Reset button (SW4) on the XSV-300 board is pressed, the VGA Control Unit initializes the RAMDAC. This initialization process will set the values in the RAMDAC lookup table to allow the output of 224 grayscale colors and 32 other, more vivid colors. The RAMDAC lookup table has room for 256 entries, and the camera generates 8-bit grayscale values. However, of the possible 256 pixel values, the camera only uses the range of 10h to F0h to actually represent color values. The remaining 32 values (00h to 0fh and F1h to FFh) are used by the camera to encode metadata. From the perspective of image generation, this gives us 32 values that we can arbitrarily encode in the RAMDAC. We will use these entries to encode vivid colors to be used for additional display information, such as to indicate the occurrence of motion.

Synchronization Signal Generation

The VGA Control Unit uses two signal-generation blocks to produce the horizontal and vertical synchronization signals for the VGA monitor. Each block is made of two counters that work together to properly generate the required synchronization signal waveforms required by the monitor. Figure 5 below shows the signals that are generated for controlling the VGA monitor.

Figure 5: VGA Timing

Pixel Data Display

To display the pixel data, the VGA Control Unit asks the Memory Manager Unit for the appropriate pixel. The pixels are stored in memory in an interleaved format. So, for an image of 160 by 120 pixels, the pixel addresses will be every even or every odd address in the range from zero to 38399. When the VGA Control Unit needs a pixel, it places the address on the Address Bus and raises the request line. The Memory Manager Unit will fetch the value at that address and make it available on the Data bus. The VGA Control Unit will then read the data when it seen the one-cycle ready signal and apply it to the RAMDAC pixel bus. It will then cycle the RAMDAC pixel clock to output this color mapping to the monitor.

Analysis Unit Design

The Analysis Unit performs the following tasks:

Gathers data for two complete video frames by communicating with memory manager.

Controls the rate at which this data is gathered to ensure sufficient operation.

Runs a discrete subtractive analysis algorithm over the images to detect the motion of objects in each scene.

The block diagram for the Analysis Unit is shown below in Figure 6.

Figure 6: Analysis Unit Block Diagram.

Data Gathering and Storage

The Analysis Unit continuously monitors the incoming data stream, watching the stream for the beginning of incoming frames. Upon seeing a frame start signal, the unit signals the memory management unit to begin filling the first analysis buffer (even addresses 39400 through 76796) with the first frame. The unit then waits for 15 frames (about 1/2 second) to go by, using the frame start signal as a count. Upon seeing the 15th frame signal, the unit signals the memory manager to begin filling the second analysis buffer (odd addresses 39401 through 76797) with the second frame. This is accomplished by properly setting the ADDR[14:0] and REQ signals on the Analysis Unit, and resetting the counter to 0 each time 15 frames are seen (READ on FRAMECNT = 0).

Data Rate Control

As stated above, the Analysis Unit will use the frame start signal to control data capture rate, by counting 15 frames between read requests. This both ensures that the data will not be sampled too quickly, and that the Analysis unit will have sufficient time to perform analysis inline.

Subtractive Motion Detection Analysis

Once two frames have been stored, the Analysis Unit will immediately begin analysis on those frames. It will travel through the frames pixel by pixel, looking at relative pixel locations in each frame (i.e. position 0,0). This is simplified in our design, by the fact that the memory values are interleaved, and the outgoing 16-bit data bus from memory allows us to look at 2 pixels at once. Therefore, a single ram access will give us the two pixels needed for each check. The unit will perform a simple subtract on each set of two pixels to get the absolute value of the intensity difference between them. If this intensity difference is greater than a preset threshold value a differing-pixel counter will be incremented. After both images have been scanned completely, the total count of differing pixels will be compared to another preset threshold value to determine if enough pixels are different to imply motion in the scene. The rest of the system is then notified if motion was detected.

Though this algorithm is susceptible to noise-induced error, it is extremely fast and simple to build in hardware. For the design requirements of the machine, this algorithm seems to be the most efficient and hardware friendly one that meets the given specifications.

ANALYSIS

This section describes the design choices that were made for each portion of the project, and the reasoning behind those choices.

Overall System Analysis

We have chosen the XSV-300 board for our project because it provides a Virtex FPGA with a suitably large number of Control Logic Blocks (300K). This serves all our design purposes. The XSV-300 board also includes the RAMDAC device, which provides a 256-entry, 24-bit color map that is used by the FPGA to output grayscale video to a VGA monitor.

Since the XSV 300 board serves all our purposes, all we need to do is program the functional units and put them together. As long as we can setup and configure the RC-1 in order to pass images into the memory and display the image data on the monitor, we would already have a video monitoring system. The other half of the project is to detect the motion, which can be done with our analysis unit. In the following sections, we describe the analysis of each functional unit.

Camera Control Unit Analysis

The Camera Control Unit simply serves as a data and control signal conduit between the camera and the rest of the system. If we configure and set up the RC-1 in the right mode, as specified in the RC-1 documentation (see the References section), the camera should operate as expected and provide a continuous image data stream. The main constraint when dealing with the camera is ensuring that we do not exceed the initialization programming rate of 100KHz. Since we know our system is operating at 25Mhz, we can build in the proper delays into the initialization routine to ensure that this requirement is met.

Memory Manager Unit Analysis

The Memory Manager Unit must direct incoming data from the Camera Control to the appropriate memory block. The data will appear as a stream of bytes. The maximum pixel-rate the camera will generate when operating at 30 frames per second is 576000 pixels/sec on average. Our system will be operating at approximately 25MHz, which is sufficient to capture the incoming data. This large difference in speed guarantees that we will be able to process a given byte of data before the next arrives.

VGA Control Unit Analysis

The VGA Control Unit consists of the following major phases.

RAMDAC Initialization

The process of programming the RAMDAC is specified in its documentation. Assuming that the chip operates as described, the initialization of the RAMDAC will be successful.

Normal Operation

The VGA Control Unit must properly generate the horizontal and vertical synchronization signals for the monitor. Also, during the correct portion of the horizontal signal, the unit must fetch pixel data and apply it to the RAMDAC to generate the correct analog color value for a particular pixel. These signals are all generated by counters, which are incremented on each clock cycle of the FPGA. So, given a detailed timing specification that we must meet, we only need to choose proper values to count up to. This will be a function of out FPGA clock frequency and is a straightforward calculation.

Analysis Unit

The Analysis Unit must record two scenes from the incoming data stream and analyze them to see if motion occurred. We will be taking samples from the data stream at a rate of 2 samples/sec, which will provide enough speed to capture human motion in the required range of speeds, and maintain a very conservative time frame for the analysis process occur. The analysis algorithm provided will ensure that motion detection can occur quickly and efficiently, while still maintaining a level of adjustability through user- defined threshold values. These adjustable thresholds will also help to compensate for the random noise and pixel blooming that will be present in the RC-1 camera circuitry. This combination of a fast algorithm and a large time frame to work in ensure that the Analysis Unit will be able to perform its specified task successfully.

DESIGN ISSUES

There are certain elements of our design that we are still investigating. These issues primarily have to do with specific technical details and do not affect the overall system feasibility.

Camera Control Unit Design Issues

The camera is the source of the image data that we will display on the VGA monitor and analyze in order to detect motion. We will have to properly initialize and use the camera to collect meaningful data. It is necessary to fully understand the capabilities and operation of the video camera we are using. The biggest issue will be the correct initialization of the camera. The VV-5300 chip documentation gives a cursory description of the I²C interface to the camera. This lack of thorough documentation could lead to difficulties initializing the camera.

Memory Manager Unit Design Issues

The Memory Manager Unit will be able to concurrently perform the tasks of data intake and storage, data lookup for the VGA Control Unit and data lookup and storage for the Analysis Unit. The unit will handle performing these tasks in parallel, but care must be taken to prevent any conflicting actions. Specifically, a particular memory bank cannot be written to and read from at the same time. This will not be a problem for the video memory since the Memory Manger Unit will implement a double-buffering scheme that continually maintains the mutually exclusive feature of the video memory. However, since there is only a single analysis memory, there could be a situation where there are concurrent read and write requests. The Memory Manager Unit must be aware of this possibility and handle it accordingly. The most likely solution will be to implement blocking memory access operations that serialize access requests by only allowing one operation to be active at a time.

VGA Control Unit Design Issues

The design of the VGA Control Unit faces potential problems in two areas: when to select the proper data to display and how to obtain the data. We will first consider problems related to data timing and then discuss data selection.

Timing

When operating, the VGA Control Unit continuously generates a repeating sequence of horizontal and vertical synchronization signals. This signal pattern repeatedly refreshes the entire 640 by 480 pixel display 60 times each second. However, the images we will be displaying are 160 by 120 pixels, which is one quarter the size of the display area. To properly display an image in its true size, the VGA Control Unit will have to intelligently insert blanking signals for areas of the screen that are not displaying image data. Another possible approach is to dynamically scale the image so that it covers the entire display area.

Data Selection

During normal image display, the VGA Control Unit gets image data from the Memory Manager Unit and presents this information to the RAMDAC for conversion to 24 bit analog color values. However, to allow for additional colors, the lower three RAMDAC table entries are reserved for special color mappings. So, any incoming image data that corresponds to one of these values must be scaled up to the fourth entry. We suspect that the results of this operation will be imperceptible, but there could be a noticeable effect.

We would like to be able to arbitrarily control the location on the screen where the image is displayed. Also, we want to be able to display additional information such as text, borders and indicators. To do this, we will have to have additional control logic in the VGA Control Unit that controls the actual byte stream sent to the RAMDAC for decoding. Most likely, the pixel data manager will be extended to perform this duty.

Analysis Module Unit Design Issues

Two major difficulties arise in the design process for this unit. The first of these obstacles is the memory management portion of the module. Communications with asynchronous rams can be quite difficult if timing restraints are not taken into account. While the brunt of this problem will be placed on the memory management unit, the analysis module will be required to communicate with this module effectively and respect its accessing protocols. Thus, this is one of the areas that will require close attention during the design process.

The other difficult portion of the Analysis Unit design will be ensuring proper functionality of the motion detection algorithm. While this is a fairly simple procedure, it may prove more difficult due to random errors in the camera, and variable distances of objects. Much testing will be necessary to ensure that the system can meet the given specifications. This is the most time consuming portion of the analyzer’s job; therefore it must be designed to be as efficient and as precise as possible.

TEST STRATEGIES

Testing strategies must be developed for any successful digital system. This section discusses the test strategies that will be used to ease the development process for this system.

Overall System Testing

We will test the overall system by splitting it up into two stages. The first stage is to test if the VGA can display the taken data images and the second stage is to test if the analysis can detect any motion from the data images.

First stage

When the camera and the VGA are setup, we will try to download one set of image data taken from the camera, store it in the FPGA memory, and display this image data on the monitor. After the system can display one image, we will allow the camera to keep taking snapshot images and verify that the monitor can display these images as a video monitor. When the first stage works perfectly, we will proceed to the second stage.

Second stage

In the second stage, we will connect the Analysis Unit to the first stage system. The purpose of the second stage is to verify that the analysis algorithm works with the rest of the system. To verify the algorithm’s correctness, we can read the analysis output signal and display it with the LEDs on the XSV-300 board.

Camera Control Unit Testing

For the Camera Control Unit, first we need to verify that it can output the data with the right frame format. We verify that it can send 19,200 pixels between two asserted frame start signals. Next, we have to wait until the VGA Control Unit and the Memory Control Unit are done and being tested. Similarly, we do the test for the Camera Control Unit like the first stage of the overall system testing.

Memory Manager Unit Testing

Testing of the Memory Management Unit will be performed during its development. The first test will use a test unit that simulates the output of the Camera Control Unit. The Memory Management Unit will be expected to monitor the data and implement the proper double-buffering behavior, as the data is stored in the video buffers. To verify proper operation, we will use the VGA Control Unit to display the data stored in the video buffers. The result should be an alternating pair of test patterns.

Next, we will test integration with the Analysis Module. We will use a test unit that simulates the Analysis Module. This test unit will verify proper operation of the three types of operations associated with the analysis unit: store an image, read a value, write a value. Proper operation of this functionality will be determined by using a special test block that can read the analysis memory block and report its contents via LEDs on the XSV-300 board.

VGA Control Unit Testing

The VGA Control Unit is tested in stages during development. Initially, the horizontal and vertical synchronization signals were tested while analog color values were directly generated, bypassing the RAMDAC. This test properly produced a test pattern on the monitor.

The next step in testing is to run the RAMDAC initialization routine and send test data to the RAMDAC. The test data will be chosen so as to access every entry in the RAMDAC lookup table. If the RAMDAC initialization works properly, we should see a test pattern generated by the RAMDAC. The test patterns should correspond to the color distribution that we programmed into the lookup table.

Finally, to test the entire VGA Control Unit, we can construct a test unit that imitates the Memory Management Unit. This test unit will respond exactly as the specified Memory Management Unit, but the resulting data will be a generated test pattern. Again, if this test passes, we expect to see the appropriate test pattern appear on the monitor.

Analysis Unit Testing

Testing of the Analysis Unit will require multiple tests. First, the memory control portion of the analysis unit will be tested by simply performing communications with the working memory manager, to ensure that, data flow and scheduling are handled properly and efficiently. Knowing the timing specifications for the data retrieval portion of the machine will also aid in building the analysis portion of the machine.

Once memory accessing is working properly, the motion detection portion of the machine will be tested by feeding the unit two dummy images, and monitoring the results acquired. Threshold settings will be tested exhaustively to determine the best range of settings for maximum performance of the system.

After the unit is tested on dummy images, we will use actual camera-acquired data, and retest threshold settings and algorithm reliability. We will test on various sized objects, at variable distances and lighting conditions. This will ensure that the camera is able to detect motion, and meet the given specifications.

RESPONSE TO REVIEWER FEEDBACK

In this section we respond to the specific issues raised during the technical review of our Preliminary Design Document. For each issue, we provide the original reviewer comments in italics and then we give our response.

Space on FPGA

We are concerned about the amount of space available on the FPGA of the XSV-300 board. Given the current design, space is needed for the following:

3 grayscale images from the camera, 160 x 120 pixels at 8 bits per pixel

2 edge detection images for analysis, 160 x 120 pixels at 1 bit per pixel

The motion detection algorithm

Group F was able to produce a 22k RAM (enough to hold one of the grayscale images) that used 1320 slices on the FPGA. Given that the FPGA has just over 3000 slices available, we conclude that there might not be enough room on the FPGA. Even if all of the images do fit on the FPGA, enough room must be available for the rest of the project. The complexity of the motion detection algorithm, and hence its usefulness, will be directly proportional to how much space is left on the FPGA for it.

One possible solution would be to use the SRAM banks available on the XSV board to hold the images. Unfortunately, SRAM allows only one read or write access to a bank at a time. It would be difficult to run the design units in parallel without using some handshaking to avoid memory access overlaps. Also, from what we have heard from other groups, SRAM is just difficult to use.

Our suggestion is to use the XS-40 implementation of the VGA interface that is already available. Using this instead of double buffering on the XSV-300 board would remove two of the large grayscale images from the board. We believe this should leave enough room for the rest of the project to be implemented on the XSV board.

We agree with our reviewers that space on the FPGA is a key limitation, especially when synthesizing memories. In fact, it turns out that further testing on our part has revealed that we cannot even create a RAM large enough to contain a single image (19200 pixels x 8 bits/pixel). In response to this fact, we have decided to use one bank of the SRAM for our image storage and analysis needs. Our reviewers are correct in that we have had to implement a request/response scheme in the Memory Manager Unit to broker access among the various units. However, our interleaved access to the SRAM, along with the different data rates of the units will allow us to effectively use the SRAM as our sole memory resource. Also, regarding the anecdotal difficulty of using the SRAM, we have already performed simple tests that show we can successfully store and retrieve data from the SRAM.

Finally, we are not taking up the suggestion of using an XS-40 board for the VGA portion of the project. First of all, we would still have to rely on an external memory source for image storage if we wanted to perform double-buffering of images. The other reason we decline to use the XS-40 board is that it does not provide a RAMDAC for driving the VGA monitor. Since it only provides three color channels (red, green and blue) and each channel is two bits wide, we would be limited to only four grayscale colors.

Edge detection algorithm

First, we are wondering whether an edge detection algorithm is the best way to approach motion detection. We did some research on motion detection algorithms, and found that there are many other ways to detect motion. One such algorithm that we discovered is motion subtraction. We suggest that some other possible algorithms be considered before a final choice is made.

If edge detection is chosen, the sampling rate will need to be carefully chosen, so that the motion detection is not only useful, but also feasible to compute. According to the preliminary design package, an analysis will be done once per second. This gives a sampling frequency of 1 Hz. At this rate, there should be more than enough time to do overhead processing and motion detection before the next frame is gathered for further analysis.

While timing is not an issue, space is still an issue (as stated before). Because of limited space available on the XSV-300 board, the complexity and usefulness of the edge detection algorithm will need to be traded off for space.

Lastly, there is also the question of how motion will be detected based on the edge bitmap. How many pixels does an edge have to move before it is considered as motion? We suggest a threshold value should be used to determine this.

Again, we agree with our reviewers. We have decided that edge-detection was not the most suitable approach for implementing motion detection in our system. As described earlier, we have decided to use a simpler subtractive motion detection algorithm.

Camera noise

Noise is an inherent problem with any camera, and this could possibly cause problems for the edge detection algorithm. A naïve edge detection algorithm could interpret noise as edges.

Our suggestion is to use an intelligent edge detection algorithm whose first step is filtering and/or smoothing. For example, a median filter is very easy to perform, and this can be done while the data from the camera is being streamed to the FPGA board. The Marr-Hildreth algorithm, one of the more popular edge detection algorithms, uses a Gaussian filter in its first step.

We agree that noise is a problem with the camera we are using. We cannot consider the suggestions provided by our reviewers since we have dropped the edge-detection approach to motion detection. But that does not mean can ignore the possible effects of noise. To account for fluctuations in the image differences due to noise, we will choose a threshold value that will mask low0level motion indications produced by noise.

Analyzing Streams of Data vs. Sets of Data

According to their initial design specifications, group F was going to load two edge-images that were 1 second apart and compare them to detect motion. Then they would load two new images and do the comparison again. We feel that it would be more useful, and not much more difficult, to discard only the oldest image after the comparison of the edge-images and thus only have to load 1 new image per comparison. In this way, they will be able to compare more images in a shorter period of time, with less overhead.

We agree with our reviewers on this point as well. In fact, with the algorithm we will be using, the Analysis Unit will need no more than one complete image stored in memory at any given point. Once we have the initial image in memory, we can look at the pixels of subsequent images as they arrive and compare them to the values of the prior image. Once the difference is calculated, the previous pixel can be overwritten with the new image pixel.

Clock Speed

Another issue we had was that the design was to be run at 40MHz. From previous experience, we feel that it will be difficult to come up with a design that will be able to run at this speed on the XSV-300 board. Achieving such a design would require a lot of pipelining which could lead to a more complicated design. It is our suggestion to plan to run the XSV-300 board at 25 MHz, and to base all design calculations with this clock speed as the assumption. Changing from 40 to 25 later in the design could be troublesome.

We agree with our reviews that our original clock speed estimate of 40Mhz was optimistic. Subsequent tests with our existing system have shown that our final design will be running at a clock speed of 25Mhz. Fortunately, our design will allow our system to operate properly at 25MHz.

PARTS

Table 8 below lists the parts required for this project. All of these parts are available in the hardware lab.

Table 3: Parts

Part	Comments
Spectronix RC-1 Camera Module	Module encapsulating a VV-5300 imager chip
Xess XSV-300 Board	Prototype development board
VGA Monitor	Standard VGA monitor
Parallel Port Cable	Used to program Xess XSV-300 board
Xilinx Foundation Software	Used for design implementation

PIN-OUT LISTINGS

The following tables list the pin-outs for our system. The only custom I/O we have had to provide was for connecting the camera to the right-side expansion header. The remaining pin connections to the RAMDAC, monitor and SRAM are reflected in the top-level schematic of our design.

Table 4: FPGA pin-out to camera via right expansion header (J25)

Signal Name	RC-1 Camera Connector	FPGA pin via J25 (J25 labels)
D0	1	53 (A9)
D1	2	54 (A8)
D2	3	56 (A6)
D3	4	57 (A5)
D4	5	64 (A3)
D5	6	65 (A2)
D6	7	67 (A0)
D7	8	68 (/WE)
SDA	18	81 (D8)
SCL	19	84 (D10)
QCK	11	85 (D11)
FST	12	87 (D13)

Table 5: FPGA pin-out to RAMDAC and Monitor

RAMDAC pin	FPGA pin
PIXELCLK	52
/HSYNC	48
/VSYNC	49
/BLANK	50
P0	70
P1	71
P2	72
P3	73
P4	74
P5	78
P6	79
P7	80
/RD	47
/WR	46
RS0	31
RS1	28
RS2	26
D0	42
D1	41
D2	40
D3	39
D4	38
D5	36
D6	35
D7	34

Table 6: FPGA pin-out to left SRAM bank

SRAM pin same as left expansion header (J26) labels	FPGA pin
/CE	186
/OE	228
/WE	201
D0	202
D1	203
D2	205
D3	206
D4	207
D5	208
D6	209
D7	215
D8	216
D9	217
D10	218
D11	220
D12	221
D13	222
D14	223
D15	224
A0	200
A1	199
A2	195
A3	194
A4	193
A5	192
A6	191
A7	189
A8	188
A9	187
A10	238
A11	237
A12	236
A13	235
A14	234
A15	232
A16	231
A17	230
A18	229