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

2. 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

3. The Big Idea(1)
3/9/2007
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
3/9/2007
EECS150 Lab Lecture #8

5. 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

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
3/9/2007
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.
3/9/2007
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
3/9/2007
EECS150 Lab Lecture #8

9. 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

10. 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

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.
3/9/2007
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
3/9/2007
EECS150 Lab Lecture #8

13. SDRAM Arbiter (2) You will need to add more states to this 3/9/2007
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
3/9/2007
EECS150 Lab Lecture #8

15. How is the video data stored?
3/9/2007
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.
3/9/2007
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
3/9/2007
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.
3/9/2007
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.
3/9/2007
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.
3/9/2007
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.
3/9/2007
EECS150 Lab Lecture #8

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