Local Video System: Overview EECS150 Spring 2007 - Lab Lecture #8 Allen Lee 3/9/2007 EECS150 Lab Lecture #8

Welcome to Checkpoint 2 First real design checkpoint Video in SDRAM No datasheets! Video in SDRAM Motivation Storage FIFO Controllers SDRAM Arbiter 3/9/2007 EECS150 Lab Lecture #8

The Big Idea(1) 3/9/2007 EECS150 Lab Lecture #8

The Big Idea(2) Combining checkpoint 0, checkpoint 1, and a video decoder We’ll give you the video decoder Video Decoder writes a frame into SDRAM Video Encoder reads the frame from SDRAM Arbiter sits between SDRAM Controller and Decoder/Encoder to make sure the SDRAM Controller sees only one request at a time 3/9/2007 EECS150 Lab Lecture #8

Checkpoint 2 Part I: Encode/Decode FIFO Controllers Part II: Arbiter Address Counters determine read/write addresses FSM determines when to request read/write Part II: Arbiter Handles writes from decode processor Handles reads from encode processor Ensures that one request is given to SDRAM Controller at a time 3/9/2007 EECS150 Lab Lecture #8

FIFO Controllers (1) Decoder FIFO Controller Store active video data from decoder into FIFO Write to SDRAM when FIFO has enough data Assert a write request when FIFO has at least 8 words Ensures that FIFO does not underflow Controls the write address counter Similar to encoder FIFO controller 3/9/2007 EECS150 Lab Lecture #8

Dual Clocked FIFO The FIFO on the decoder side uses two independent clocks: one for reading, one for writing. The camera runs on its own 27MHz clock. You can use ModelSim to figure out how to interpret each of the control signals. 3/9/2007 EECS150 Lab Lecture #8

FIFO Controllers (2) Encoder FIFO Controller Reads active video data from SDRAM Reads from SDRAM when FIFO has enough space Assert a read request when FIFO is less than ¾ full Must ensure that FIFO never overflows Controls the read address counter Sends data from FIFO to VideoEncoder 3/9/2007 EECS150 Lab Lecture #8

More on FIFOs Why a FIFO? Data Rate Matching Buffering SDRAM handles data at 32 bits per cycle Encoder handles data at 32 bits per 4 cycles Buffering Encoder needs a continuous stream of data SDRAM might be busy The FIFO “Predicts” what data the video encoder will want and supplies it upon request 3/9/2007 EECS150 Lab Lecture #8

Announcements Checkpoint 0 and 1 No late policy for Checkpoints 2-4 Can turn it in one week late for 20% penalty Knowledge of SDRAM Controller timing is essential for checkpoint 2 No black boxes for not finishing! No late policy for Checkpoints 2-4 If you don’t finish on the due date, you will get no credit. This is because you will only fall further behind. 3/9/2007 EECS150 Lab Lecture #8

Lab Policy Please don’t play loud music/noise in lab, especially when it’s late. Please use your “indoor” voice. Please throw unfinished food away outside. The lab’s trashcan only gets emptied out about once a week. Be careful with the boards and wires, especially with the parallel wire – pull it by the plastic, not the wire. We’ve had to replace 10+ wires already. 3/9/2007 EECS150 Lab Lecture #8

SDRAM Arbiter (1) Controls interface with SDRAM Controller Sets priority between Decoder and Encoder SDRAM Controller thinks there is only 1 port SDRAM Arbiter allows multiple access ports Funnels control signals selectively to each port 3/9/2007 EECS150 Lab Lecture #8

SDRAM Arbiter (2) You will need to add more states to this 3/9/2007 EECS150 Lab Lecture #8

Arbiter Handshaking Protocol Once the SDRAM Controller has finished initializing, the arbiter will start polling the decoder and encoder for requests (simultaneously). If both modules are ready, the arbiter should give priority to the encoder. If neither module is ready, the arbiter should poll again. If either module is ready, the arbiter must appropriately assert read/write requests to the SDRAM controller, and control signals to the FIFO controllers YOU MUST REVIEW THE TIMING FOR HANDLING REQUESTS IN YOUR SDRAM CONTROLLER. THE CONTROL SIGNALS MUST BE TIMED PERFECTLY OR YOUR PROJECT WILL NOT WORK 3/9/2007 EECS150 Lab Lecture #8

How is the video data stored? 3/9/2007 EECS150 Lab Lecture #8

Modifications Needed for CP0 Recall from Checkpoint 0: RAM Address = {Row, Bank, Column} In this checkpoint: RowAddress = {4’h0, PixelRow, Field} BankAddress = 2'h0 ColumnAddress = {BurstColumn, 3'h0} You will modify your address counter to accommodate exactly the right amount of active video data. 3/9/2007 EECS150 Lab Lecture #8

Modifications Needed for CP1 ITU 601 vs. ITU 656 Standard In Checkpoint 1, you implemented ITU 656, which uses 487 active lines. The video camera follows the ITU 601 standard, which has 507 active lines. Odd Field (262 Lines) 6 Vertical Blanking, 254 Active, 2 Vertical Blanking Even Field (263 Lines) 7 Vertical Blanking, 253 Active, 3 Vertical Blanking 3/9/2007 EECS150 Lab Lecture #8

Modifications Needed for CP1 Recall that the VideoROM sends video data as {Y, Cr, Y, Cb}. The provided video decoder sends it in the reverse order {Cb, Y, Cr, Y}. You will need to modify your CP1 to accommodate this. 3/9/2007 EECS150 Lab Lecture #8

Tips, Hints, & Common Pitfalls Timing for writing is tricky. Recall from Checkpoint 0 that the black box puts data on the DQ line based only on WriteRequest timing. You’ll have to take care of this timing yourself now. 3/9/2007 EECS150 Lab Lecture #8

Tips, Hints, & Common Pitfalls Make your arbiter design very clean You’ll need to extend your arbiter to accommodate four ports in Checkpoint 4 Your encode and decode processors should be almost identical. They are basically the same module. 3/9/2007 EECS150 Lab Lecture #8

Tips, Hints, & Common Pitfalls Long synthesis Now that your design is a lot more complicated, putting your design on the board can take up to 10 minutes. Avoid the vicious cycle of: Changing one line Generating the programming file Fail Repeat If you catch yourself doing this, make ModelSim testbenches. Yes, you can simulate the blackbox FIFOs. 3/9/2007 EECS150 Lab Lecture #8

Questions? 3/9/2007 EECS150 Lab Lecture #8