Local Video System: Overview

1. Local Video System: Overview EECS150 Spring 2007 - Lab Lecture #8 Allen Lee EECS150 Lab Lecture #8

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

3. The Big Idea(1) EECS150 Lab Lecture #8

4. 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 EECS150 Lab Lecture #8

5. Checkpoint 2 • Part I: Encode/Decode FIFO Controllers • 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 EECS150 Lab Lecture #8

6. 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 EECS150 Lab Lecture #8

7. 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. EECS150 Lab Lecture #8

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 EECS150 Lab Lecture #8

9. More on FIFOs • Why a FIFO? • Data Rate Matching • 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 EECS150 Lab Lecture #8

10. Announcements • Checkpoint 0 and 1 • 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. EECS150 Lab Lecture #8

11. 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. EECS150 Lab Lecture #8

12. 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 EECS150 Lab Lecture #8

13. SDRAM Arbiter (2) • You will need to add more states to this EECS150 Lab Lecture #8

14. 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 EECS150 Lab Lecture #8

15. How is the video data stored? EECS150 Lab Lecture #8

16. 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. EECS150 Lab Lecture #8

17. 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 EECS150 Lab Lecture #8

18. 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. EECS150 Lab Lecture #8

19. 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. EECS150 Lab Lecture #8

20. 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. EECS150 Lab Lecture #8

21. 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. EECS150 Lab Lecture #8

22. Questions? EECS150 Lab Lecture #8