DOC PREVIEW
Columbia CSEE 4840 - JAY-Cam Design Document

This preview shows page 1-2-3 out of 9 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

JAY-Cam Design Document Version 1.0 Yaniv Schiller Avrum Tilman Josh WeinbergTable of Contents INTRODUCTION 3 System Design 3 Overview 3 Details 3 Data sizes 3 COMPONENTS 4 The Clock 4 Implementation 4 Expected times 4 Ethernet Controller (ASIX AX88796L) 4 Hardware 4 Initialization 4 Transmission details 4 Registers 5 Ethernet Packets 5 SRAM (Toshiba TC55V16256J) 6 Hardware 6 Features 6 Usage 6 Video Out (Texas Instruments THS8133B) 6 Hardware 6 Features 6 Video In (Philips SAA7114H) 6 Hardware 6 Features 6 Initialization 6 Registers 7 OPB Bus 7 Arbiter 7 Memory Mapping 7 Inter-Component Wiring 7Introduction System Design Overview In broad terms, we are using the FGPA and its peripherals to construct a simple video cam. This camera takes in analog video, converts it to a digital stream and broadcasts it through the Ethernet port as UDP packets. The flow of data can be summarized in the following block diagram: Details The input into the Video Decoder is a Split, Differential S-Video(Y/C) Input. Our input is going to be in PAL format. We will configure the decoder to scale (decimate) the input into 128x128 pixels. Each pixel will be represented by 1 byte. As the data streams in, it will reside temporarily in the Video Decoders’s 32 word by 4 Byte FIFO register for Video Output. When possible we will remove the data from the FIFO buffer and move it into SRAM. Concurrently, we will display the data out to a screen buffer. One trick that we hope to employ is to dump the Video-In data into the screen buffer directly. Furthermore, every so often we will create a new packet on the Ethernet card, dumping some UDP, IP and ETHERNET data into the packet data. Then as the data is available in the SRAM, we push the data into the Packet’s data portion and pass it along to the Ethernet controller. Data sizes The following preliminary calculations were made: Data input: 128x128 Bytes = 16384 = 16K This data is moved cleverly into the 640x480=307200= 300K Screen Buffer that is used to display the current image on the screen The Ethernet card creates Ethernet Packets. This includes a 6-byte source, 6-byte destination, 2 bytes of type/length and Data. Philips SAA7114 Video Decoding and Decimation UDP Packet Video Frame Video-Out DAC AX88796 Ethernet Chip SRAM Analog VideoThe data portion of the Ethernet packet will consist of the following: IP Header – 20 Bytes UDP Header – 4 Bytes Screen Position Information – 1 byte 128x4 = 512 bytes of Screen data. With this setup, we send 128x4 bytes each time, requiring the application t send out 32 packets. Components The Clock Implementation Cristian suggested and helped implement a 100 MHz clock that will be used to drive the I/O operations. The System Clock will still run at 50 MHz, and the vga clock will run at 25 MHz. Expected times This design allows us to perform an Ethernet read (16 bit), SRAM read (32 bit), SRAM write (32 bit) in 2 clock cycles. An Ethernet write (16 bit), SRAM read (16 bit), SRAM write (16 bit) will occur in 1 clock cycle. Ethernet Controller (ASIX AX88796L) Hardware We are using the 10/100 Ethernet Interface on the MAC+PHY chip (AX88796). Initialization To initialize this device we will have to write to certain registers setting certain parameters. Transmission details Writing to Ethernet memory is not enough to initiate transmission. In order to send out data, the memory must be moved from the on-chip SRAM into the transmission FIFO. This is accomplished by an on-chip DMA operation, which is controlled by setting certain control registers. The following steps portray a high level view on what is required to transmit a packet: 1) Send Packet data to Ethernet’s on-chip SRAM a. This includes the 128*4 data Bytes, 1 positioning Byte, 4 UDP Bytes and 20 IP header Bytes 2) Send “0x22” to the Command Register to activate the controller. 3) Start a Remote DMA write operation to transfer data from the on-chip SRAM to the FIFO. 4) Send “0x26” to the command register to set the transmit bit, thereby initiating transmission.Registers The Ethernet controller consists of ne2000 compatible control registers. (For a list of these registers see http://www1.cs.columbia.edu/~sedwards/classes/2004/4840/ax88796.pdf, pages 32 and 33). Ethernet Packets As mentioned previously, the Ethernet packets creation involves setting up the packet’s source and destination MAC and filling the packet’s data with 1. IP Header – 20 Bytes a. Version – 4 bits i. Value = 4= “0b0100” b. IHL – 4 bits i. Value = 5 = “0101” c. TOS – 1 Byte i. Value = 0 “0b00000000” d. Total Length – 2 Bytes i. Value =512+1+4+20= 537 = “0x217” e. Identification – 2 Bytes i. A UNIQUE number f. Flags – 3 bits i. Value = “010” g. Fragment Offset - 13 bits i. “0000000000000” h. TTL – 1 Byte i. “11111111” i. Protocol – 1 Byte i. Value = UDP = 17 j. Header Checksum – 2 Bytes i. COMPUTED On the fly k. Source IP - 4 Bytes i. Constant Value to Be Determined l. Destination IP – 4 Bytes i. Constant Value to Be Determined m. Data i. UDP Header - 4 bytes ii. Data – 513 bytes 2. UDP Header – 4 Bytes a. Source Port – 1 byte i. 5001 b. Destination Port – 1 byte i. 5001 c. Length – 1 byte i. 512+1+4 = 517 d. Checksum – 1 bytei. Value = “0”, disable the checksum 3. Screen Position Information – 1 byte a. Because the screen is split into 32 128x4 packets, each packet will have a position number of 0-31 4. 128x4 = 512 bytes of Screen data. a. This is the corresponding data read from the SRAM. Most of the Header information is constant and can be hardcoded into memory. The UDP checksum is hardcoded to 0, thus disabling it. Each Ethernet packet requires a unique Identification Number at the IP layer. Because this changes, the IP header Checksum is recalculated on the fly. SRAM (Toshiba TC55V16256J) Hardware Toshiba TC55V16256J. Features 256K x 16 bits of available memory. This is 512 K. Usage We are using this peripheral to dump the image data from the Video decoder to the frame buffer. We are using 640x480 = 300K of memory for the Frame Buffer for the video output. The Video input will go to only a 128x128 bit subset of this. The rest will be zeroed out. We do this in this way to make the video out easier to implement. Video Out (Texas Instruments THS8133B) Hardware We are using the onboard Texas Instruments


View Full Document

Columbia CSEE 4840 - JAY-Cam Design Document

Documents in this Course
SPYCAM

SPYCAM

91 pages

PAC-XON

PAC-XON

105 pages

lab 1

lab 1

6 pages

memory

memory

3 pages

Structure

Structure

12 pages

Video

Video

3 pages

pacman

pacman

4 pages

Lab 1

Lab 1

6 pages

Scorched

Scorched

64 pages

lab 1

lab 1

3 pages

Video

Video

22 pages

Memory

Memory

23 pages

DVoiceR

DVoiceR

29 pages

MAZE

MAZE

56 pages

PAC XON

PAC XON

13 pages

PACXON

PACXON

13 pages

MP3 Player

MP3 Player

133 pages

Load more
Download JAY-Cam Design Document
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view JAY-Cam Design Document and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view JAY-Cam Design Document 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?