CS150 Spring 2007 Wireless Video Conferencing Final Project Report Eudean Sun Nan Yu April 29 2007 Contents I II Overview 3 System Description 3 1 SDRAM Controller and Arbiter 1 1 Initialize and Load Mode Register 1 2 Read Request 1 3 Write Request 1 4 SDRAM Arbiter 4 5 5 5 5 State Machine 8 8 8 9 10 10 11 11 11 11 11 3 Wireless Communications 3 1 Transceiver 3 1 1 Transceiver State Machine 3 1 2 SPI Controller 3 2 Communications Ports 3 2 1 Recieving Processor RR Processor 3 2 2 Sending Processor SS Processor 3 3 Communications Protocol 3 3 1 Master 3 3 2 Slave 12 13 13 15 15 15 16 18 19 20 2 Video Capture and Display 2 1 Video Encoder 2 1 1 Counter 2 1 2 Counter Controlled 2 1 3 Data Generator 2 1 4 Data Clipper 2 1 5 Data Feeder 2 2 Video Ports 2 2 1 VD Processor 2 2 2 VE Processor 2 2 3 Compressor 4 User Interface 20 4 1 Text Module 20 1 CONTENTS III 2 Conclusion 21 5 Design Metrics 21 6 References 21 7 Conclusion 21 8 Suggestions 22 3 Abstract The CS150 project for the Spring 2007 semester consisted of designing and implementing a wireless video conferencing system in Verilog The final functionality consists of two boards communicating through wireless and displaying both their own local video as well as the remote video from the other node on a monitor The design of this system necessitated some compromises first there is no audio functionality second the video that is sent over wireless is low resolution and grayscale third the remote video has a low frame rate about one frame per second The overall system comprises five ports to read write local video and send receive remote video An arbiter module controls which of these ports has control at any time By properly designing each of the read write and send receive ports and properly controlling these ports through the arbiter module we have achieved a working wireless two way video conferencing system Part I Overview Our project is a two way wireless video conferencing system Each of the nodes in the system has a monitor camera and wireless interface Both of the nodes display the following on their screens in the main part of the screen local video in full color in the upper left hand corner local video that is compressed in the upper right hand corner remote video that is compressed Since each node can see both video from itself and video from the remote node via wireless we can describe this system as a two way wireless video conferencing system An important distinction is that this system lacks audio communications presumably due to the limited time available to complete the design as well as the limited bandwidth available in the wireless channel Figure 1 shows a high level diagram of the system we ve designed and how two of these systems communicate via a wireless channel The system is comprised of three primary building blocks an arbiter the ports controlled by the arbiter and a communications system Since the ports must communicate with SDRAM performing either reads or writes only one port can have control at any given time The arbiter decides which port has access to SDRAM ensuring that no two ports try to read write to SDRAM at the same time but also ensuring that none of the ports experience starvation We ve designed our system to include five of these read write ports two to read write full local video two to send receive compressed remote video and one to write compressed local video To explain the functionality of these ports let s consider a typical conference between two nodes A and B Both A and B are continuously writing and reading local video and displaying it on the monitor There is an exchange between A and B with remote video A writes a compressed frame then sends it to B Upon receiving this frame B displays it locally then writes its own compressed frame and sends that to A who receives it and displays it locally This exchange continues until communications is lost either by resetting the Xilinx chip or as a result of packet loss The communications module is the enabler of the sending and receiving mentioned previously The ports controlled by the arbiter interface with the communications module to allow compressed frames to be written sent and received at the appropriate times to enable proper video conferencing functionality In addition the communications module is in charge of an initial handshake between the two nodes A and B This handshake allows A and B to identify each other as a pair that is communicating The communications module also controls which of the nodes is acting as the Master or the Slave This distinction is important for the initial handshake as well as for error conditions due to packet loss and will be described in detail later in this report Part II System Description In this section we describe each of the parts of our system in detail These correspond more or less to the checkpoints designated in this project 4 1 SDRAM CONTROLLER AND ARBITER System A SDRAM Controller SDRAM Arbiter Video Decoder Processor Compressor Sender Receiver Communications Controller Tranceiver Communications Controller Tranceiver Wireless Communication Video Encoder Processor Video Encoder Processor Video Decoder Processor Compressor Sender Receiver SDRAM Arbiter SDRAM Controller System B Figure 1 System overview 1 SDRAM Controller and Arbiter The SDRAM controller is our interface to the Micron Technologies MT48LC16M16A2TG SDRAM module Since our other sub systems interface heavily with SDRAM we needed some type of interface that could handle reading and writing to SDRAM so that the timing details of these operations could be abstracted 1 SDRAM CONTROLLER AND ARBITER 5 out of the rest of the video conferencing system In designing the SDRAM controller we had to consider how much of the Micron Technologies datasheet we needed to implement The datasheet provides timing information for many special cases of writing and reading We also had to consider whether we needed to refresh memory periodically to ensure data wouldn t decay We decided that we only needed to implement basic reading and writing in bursts into SDRAM without consideration for being interrupted in the middle of a read write operation this was ensured by the arbiter described later We also concluded that we did not need any special logic to handle refreshing memory since we constantly read all of the data we need from memory and reading from memory automatically refreshes the data Figure 2 shows the state machine we designed for the SDRAM
View Full Document
Unlocking...