Final Project Report

1. Final Project Report Double buffer SDRAM Memory Controller Project Number: D0713 Presented by: Yael Dresner Andre Steiner Instructed by: Michael Levilov

2. Project Description • Implementation of a device that receives a video stream from a digital video camera, performs a simple pixel processing and transfers it to a CPU through a double buffer SDRAM memory.

3. Blocks Diagram CAMERA CPU FPGA SDRAM controller read part SDRAM controller write part Pixel Processing Unit Switch FIFO Data Bus SDRAM B SDRAM A Control signals

4. Camera Module • This module is implemented by a test-bench process, which simulates a digital video camera. Pixels Data Test Bench synch 2 us interval between lines Start pulse reset 1024 pixels * t clock period Clock – 100MHz

5. Pixel Processing Module Pixels Data Processed Pixels Data synch Simple image processing synch reset clock

6. Write Controller Module Input Data Pixels Data DataPath Addresses Start pulse synch Moore State Machine Control reset clock Switch control lines

7. Write Controller Module

8. Write Controller Module Refresh Algorithm • One refresh cycle : 80ns (8 clock periods) • Time interval between 2 lines : 2us • 2us/80ns = 25refresh cycles • In order to refresh all the4096lines we need4096/20 (204.8)time intervals • Refreshing the whole memory takes204.8*(2us + 1024*10ns) = 2.5msec • Each line should be refreshed every64 msec

9. Read Controller Module Wrreq to FIFO Wrusedw DataPath Addresses Start pulse Moore State Machine Control reset clock Switch control lines

10. Read Controller Module

11. Switching Procedure Switch Control lines from Read Controller Control lines from Read Controller SwitchingMux SwitchingMux Data & Control lines from Write Controller Data & Control lines from Write Controller SDRAM A SDRAM B Pixels from A Pixels from B Output Mux Data to FIFO

12. CPU Module • This module is implemented by a test-bench process, which simulates a CPU Pixels Data Test Bench rdempty from FIFO Read Request to FIFO Cpu_Clock 100MHz

13. Design considerations CAMERA simulator: • BMP file is loaded into a buffer and cyclically transferred • Simulates a stream of photo images, as a digital video cam. • we used a small BMP file. • The ModelSim performs poorly as bigger the source files are, therefore we used a small BMP file (similar to a medium quality video image).

14. Design considerations CPU simulator: • Always reads (even if burst size is bigger than data stored in FIFO) • Achieves maximum throughput • Efficiency of 84% equal to the camera’s. achieved by specific burst lengths and delay time • Ensures Best performance under the same frequency as the camera’s

15. Design considerations FIFO: • Double Clocked, can store up to 4k (four lines). • Adapter unit between 2 clock domains. considering the small difference between the CPU clock and the camera clock, the FIFO in that size doesn’t get full • Always kept full by the Read Controller. • Ensures maximum availability of data for the CPU

16. Design considerations SDRAMs management • One bank used • simplicity • Full page mode • Minimum clock cycles for both reading and writing access • Switching during intervals when camera is idle • The simplest way not to loose data

17. Design considerations Controllers management • The write controller refreshes the SDRAM lines during the camera’s idle interval. • refreshing is done with no cost.

18. Testing Procedures • Internal white box testing for each module • Black box testing • System Performance testing

19. Black Box Testing • We check the system’s correctness by comparing between : • Data from the camera represented as a source bmp file • Data received by the CPU represented as a target bmp file This comparison is done for different CPU clock rates, which were chosen in order to cover the ordinary and some special cases that affect the behavior of the internal design

20. System Performance Testing Test 1 :Activity under normal circumstances Camera’s clock rate: 100 MHZ CPU’s clock rate: 100 MHZ or more Expected Results: Since the CPU Reads the same or faster than the camera, switching will occur after every line, each SDRAM will contain one line.

21. System Performance Testing Test 1 : Activity under normal circumstances Actual Results:

22. System Performance Testing Test 2 :Activity under extreme circumstances Camera’s clock rate: 100 MHZ CPU’s clock rate: 66.6 MHZ Expected Results: Since the CPU Reads slower than the camera, the FIFO gets full, the read controller gets stuck and the switching occurs less frequently. Each switching, more data is written to the SDRAM than before.

23. System Performance Testing Test 2 : Activity under extreme circumstances Actual Results:

24. System Performance and Design Considerations CPU clock When CPU’s clock is smaller than the camera’s, pixels accumulate in the system The number of pixels that accumulate is constant Example: CPU’s clock = 99.5MHZ. Therefore, a clock cycle lasts 10.0502ns While camera writes 1024 pixels, CPU with same efficiency as camera’s will read total of 1010 pixels: ((1024*10ns + 2000ns) / 10.0502 ) * 0.83 = 1010 Transfer of 1024 pixels 2us idle time CPU’s clock cycle CPU’s efficiency Total pixels that CPU reads, while camera sends a line of 1024 pixels For every written line, the system accumulates 14 pixels!

25. 100 99 97.5 95 92.5 90 80 70 62.5 CPU’s clock 0 11 26 52 77 103 206 308 411 Accumulated bytes for each line received from camera ----- 1490 630 315 212 159 79 53 40 Number of lines that will be received until FIFO gets full System Performance and Design Considerations The accumulated pixels eventually fill the FIFO. Once the FIFO gets full, the SDRAMS start to fill to higher line numbers. The following table examples how many pixels are accumulated in the system for each line of 1024 pixels that is received from the camera

26. System Performance and Design Considerations • Putting this details into a graph shows us that once the CPU’s clock frequency is more similar to the camera’s, the systems performance is better by several orders of magnitude. • The following graph shows for different CPU clock frequencies, the number of line received in the system, when the FIFO got full. Once FIFO is full, switching occurs less frequently and the system accumulates pixels in the SDRAM. • Therefore better performance is measured by how long it takes to the FIFO to get full. The longer, The better.

27. System Performance and Design Considerations

28. System Performance and Design Considerations FIFO size Since for every line that is received from the camera the system accumulates a constant number of pixel (dependent of the CPU’s clock cycle), the time until the new FIFO will get full is linearically proportional to it’s size. The following chart presents the performance under a constant CPU clock and different FIFO sizes. The X axis represents the size of the FIFO and the Y axis represents the number of line that was written, when the FIFO got full. We can see that the change in time until FIFO fills is linearic and proportional to the FIFO’s size.

29. Alternatives • Instead of two SDRAMs, we could have used a two clocked FIFO which could enable simultaneous reading and writing. • Drawback: FIFO is usually a lot smaller than SDRAM • Instead of two SDRAMs, we could have used one and alternately perform writing and reading. • Drawbacks: SDRAM’s clock has to be faster than the camera’s and less efficient

30. High consideration has to be given to right scheduling between different modules • Dividing each unit into separate modules and each module into separate simple processes simplifies both the implementation and the debugging Summary & Conclusions

31. Summary & Conclusions • The design permits use of a camera and a CPU that work with different clocks. • The data stream passed without overflow will be longer when: • - Clock rates difference is smaller • - SDRAMs and/or FIFO are bigger • - CPU reads longer bursts and has shorter delay time. • We enjoyed, ahla project!