UNIVERSITY OF CALIFORNIA AT BERKELEY COLLEGE OF ENGINEERING DEPARTMENT OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE EECS-150 FINAL PROJECT SPRING 2003 Change notes: Date Name Version Description 2/26/03 Sandro Pintz 1.0 First Release Introduction This document describes the final project for the Spring 2003 semester of EECS-150. Upon completion of this project, students will have built a simple video processing systems and they will have become familiar with: • A modern development CAD tool flow for FPGA design. • Design with hardware description languages • Issues and design with asynchronous clock domains crossing • Lab debugging techniques • Digital video processing • Basic knowledge off networking This projects has a set of required elements and some optional features that can be added for extra credit and ONLY if time allows. Extra credit will only be given if ALL the required elements are correctly implemented. 2. Objectives The final project for this semester is a basic video special effects design. The block diagram below shows the major components of this system. The instructor will provide some of the blocks and others will be designed, tested and debugged by students. We will also require some basic video effects to be working by the end of the project. Other video effects will be suggested but not required and can be implemented as extra credit.VideoDecodeAsyncFifoSdramControlVideoEncodeSync FifoNetworkInterfaceSpecialEffectsSDRAMControlData3232 323232 3288Control27 MHz (Camera)27 MHz (VideoEncoder)25 MHz(Network)27 MHz (VideoEncoder)ADV7194ADV7185ITU 601/656ITU 601/656compositevideocompositevideoPHYcontrolcontrolcontrolcontrolFPGA 3. Description Composite video will come from an external camera into Analog Devices’ ADV7185 video decoder. The digital output from this device conforms to ITU656 and ITU601 whose specification you can find on the class website. The video decoder device will also extract a 27MHz clock signal from the analog signal and will generate its digital output on the rising edge of this clock (see specification on class website). This 8 bit wide digital stream will be captured on this clock in the FPGA and taken by the Video Decode module who will parse the stream and extract the synchronization (EAV, SAV) information and then the color information (4:2:2 format, Cr, Y, Cb, Y as seen in class). The actual video information will be formatted into 32 bit quantities (Cr, Y, Cb, Y) and presented to the special effects module. Initially, this module will do absolutely nothing and will pass the received information directly into the Fifo. The special effect module will be modified in the later stages of the project only, i.e. the whole project will initially be nothing more than an expensive wire. Up to this point, all the logic is synchronous to the 27MHz extracted by the video decoder. The sdram controller and the rest of the video encoding pieces are based on the video encoder 27 MHz clock which is generated externally by an oscillator. No assumption can be made about the phase or frequency relationship of these two clocks. Therefore, at this point we need to synchronize the stream to the encoder clock. We use an asynchronous FIFO for this purpose. This will also help us as a buffer to manage rate changes and bottlenecks accessing the system RAM implementing the Frame Buffer. Anasynchronous Fifo provide for an easy and clean way of transferring data from one clock domain to another. Since it is so widely used, it is usually an easy drop-in for the designer. The penalty is paid in additional latency. The sdram controller provides the core control logic for this system. It constantly monitors the asynchronous Fifo (write fifo) for data availability to be written. It also checks to see if the read fifo has enough room for a new read burst to the RAM. The sdram controller will read and write 16 bytes in bursts of length 4. Given that we are running with a 27MHz clock, only 8 clock cycles are needed for a burst, i.e. the maximum memory bandwidth is calculated as: MBsondbyte 54sec/10*5416*810*2766== The video requirements are 30 frames per second, 507 active lines per frame (for the provided cameras), 720 pixels per line and 2 bytes per pixel: 30 * 507 * 720 *2 = 21,902,400 MBs22≈ Since we are reading and writing full frames, we need about 44MBs for our project. The implications of this is that the sdram controller has to make very good use of the bandwidth available and that there is no bandwidth left for other special effects (anything that would require multiple reads from sdram or reading the same data in less time, etc). Another consideration is that the read operation cannot start before there is some data in the frame buffer. For this purpose we will wait at least until a whole field is in memory before allowing the read and display operation to begin. The data read from the frame buffer is loaded into a synchronous Fifo. The purpose of this Fifo is to smooth out the data rate into the video encoding logic. The final portion of the project includes the design of special effects and networking interface. A very simple protocol is defined to send command from the linux servers to your calynx board. Every project group will have its own MAC address assigned which will be kept secret by the team. Any attempt to use or misuse another teams MAC address will be considered a severe violation of the course code of ethics. The network interface will receive the Ethernet packets from the on board PHY device, will decode them and present a command with a VALID pulse to the special effects logic. The networking interface runs at 25MHz which implies a new clock domain crossing. Since the special effects section is running at the video decoder rate, the VALID pulse (and not the whole command) needs to be synchronized to the video decoder clock. New special effects commands need to work without resetting the board, i.e. when a new command is received, the transition should be clean. The system will wait for the next vertical blanking before implementing the new command.3.1. Special Effects You will have to implement a few required special effects and we will suggest a few additional special effects for extra credit. Also, if you have any additional ideas, let your TA’s know and they will add the new commands. The required commands are: • Freeze: Upon reception of this command the current image on
View Full Document
Unlocking...