1. EECS150 Fall 2008 - Lab Lecture #9
SDRAM Arbiter
EECS150 Fall Lab Lecture #9
Chen Sun
Adapted From Slides by Greg Gibeling and Allen Lee. Diagrams by Chris Fletcher
8/26/2018
EECS150 Lab Lecture #9

2. Agenda Checkpoint 3 Introduction Administrivia SDRAM Arbiter
Interfaces
FIFORAM.v
Notes about Checkpoint 2
Design Tips
8/26/2018
EECS150 Lab Lecture #9

3. Checkpoint 3 Introduction (1)
First real design checkpoint
No datasheets!
Only requirement is that the arbiter must support a valid/ready handshake interface
SDRAM Arbiter
Video/Audio data in SDRAM
FIFO Queues
8/26/2018
EECS150 Lab Lecture #9

4. Checkpoint 3 Introduction (2)
Fundamental Problem:
You have a bandwidth limited device (SDRAM) that several things want to talk to
What to do if both things want to talk to it at the same time?
Solution: Arbiter
Dictates who gets to talk to the device
Makes sure that all requests are eventually served
8/26/2018
EECS150 Lab Lecture #9

5. Checkpoint 3 Introduction (3)
SDRAM Arbiter
Sits between SDRAM controller and the rest of your system
Only 1 request is sent to the SDRAM Controller at a time
Decide which request to service if multiple requests happen at the same time
Turn the ugly checkpoint0bb interface  clean Ready/Valid interface
8/26/2018
EECS150 Lab Lecture #9

6. Checkpoint 3 Introduction (4)
FIFO: Keeps modules happy
Video encoder will always have data to read.
Audio / Video Decoder will always have a place to put more data while that data is waiting to be written to SDRAM.
The Arbiter must guarantee that these FIFOs never underflow or overflow!
8/26/2018
EECS150 Lab Lecture #9

7. Checkpoint 3 Introduction (5)
TA Checkpoint 3 Black-box
8/26/2018
EECS150 Lab Lecture #9

8. Checkpoint 3 Introduction (6)
What we will give you:
Black-boxed video decoder that takes in data from the camera
checkpoint0bb
FIFORAM.v
Check-off:
Local video from camera onto the TV screen
If that does not work, show that checkpoint0bb is working for 50% partial credit
8/26/2018
EECS150 Lab Lecture #9

9. Administrivia (1) Checkpoint 1: Checkpoint 2: Checkpoint 3: Midterm 2:
Due beginning of lab lecture!
Checkpoint 2:
Due Friday, 10/31 (Halloween)
Checkpoint 3:
Design Reviews week of 10/27
Checkoff Friday, 11/7
Midterm 2:
11/4 (2:10 p.m. 125 Cory)
8/26/2018
EECS150 Lab Lecture #9

10. Administrivia (2) Submission Policies Design Review Policies
Checkpoint 2
You must submit your code via SVN
Checkpoint 1
We will accept s for checkpoint 1
Design Review Policies
Slight format change will go into effect next week
Check the website over the weekend for updates
8/26/2018
EECS150 Lab Lecture #9

11. Administrivia (3) Start thinking about extra credit ideas!
Detailed extra credit doc will be posted on Sunday: 10/26
2x $7000 FPGA boards given as prizes
8/26/2018
EECS150 Lab Lecture #9

12. SDRAM Arbiter Interfaces (1)
Arbiter selects between different modules to serve
Fixed priority scheme
I.E.: Always serve the video encoder if both video encoder and audio/decoder have requests at the same time.
Round-robin
I.E.: If I just served the video encoder, the video decoder now has top priority.
8/26/2018
EECS150 Lab Lecture #9

13. SDRAM Arbiter Interfaces (2)
SDRAM Controller interface not Valid/Ready
Arbiter abstracts away that awful interface
Arbiter exposes the much simpler valid/ready interface to the video encoder/decoder
SDRAM arbiter has a “request” port and a “data” port for each module it services
“Request” port is used by the module to send the request (reads or writes) and the address
“Data” used to take in write data or give read data
Both ports transfer information via valid/ready
8/26/2018
EECS150 Lab Lecture #9

14. SDRAM Arbiter Interfaces (3)
Each of the “request” or “data” ports have a FIFO attached
Allows modules to send in multiple requests for different addresses before any of the requests even get serviced
Allows modules to send in a lot of write data before any writes get served
Allows the SDRAM to give back a lot of read data before any read data is needed
Your arbiter serve requests such that none of these FIFOs underflow or overflow
8/26/2018
EECS150 Lab Lecture #9

15. SDRAM Arbiter Interfaces (4)
8/26/2018
EECS150 Lab Lecture #9

16. FIFORAM.v (1) 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
AddressCounters “predict” what values you want  the Arbiter will get those values ahead of when you actually request for them.
8/26/2018
EECS150 Lab Lecture #9

17. FIFORAM.v (2) FIFORAM.v interface Valid/ready handshake
One set of handshake signals for FIFO reads
One set of handshake signals for FIFO writes
Also maintains counts of how many free spaces it has or how full it is
Compatible interface should allow you to just plug it into your arbiter
8/26/2018
EECS150 Lab Lecture #9

18. FIFORAM.v (3)
8/26/2018
EECS150 Lab Lecture #9

19. FIFORAM.v (4) Guarantee never to overflow/underflow
Use the counts of how much data the FIFO has
Don’t service a write request unless you have enough write data
Don’t service a read request if you don’t have enough empty spaces in your FIFO to store the read values
8/26/2018
EECS150 Lab Lecture #9

20. Final Word on Checkpoint 3
Remember: your design is open ended!
Only restriction is that arbiter must support valid/ready interface
Caution: interface to SDRAMController is awful. Your arbiter must time the WriteData and OutputEnable signals correctly!
8/26/2018
EECS150 Lab Lecture #9

21. Checkpoint 2 Comments (1)
Auto-Refresh
Don’t worry about this to begin with, as you will most likely never need to refresh memory for your project
EXTREMELY difficult to implement auto-refresh and pass with checkpoint0bb
Advice: get everything completely working first if you want to do this
8/26/2018
EECS150 Lab Lecture #9

22. Checkpoint 2 Comments (2)
Why RAM_CLK = ~Clock?
Has to do with setup and hold times
tCMS and tCMH must be met
8/26/2018
EECS150 Lab Lecture #9

23. Checkpoint 2 Comments (3)
What would happen if RAM_CLK = Clock?
Setup or hold times potentially violated
8/26/2018
EECS150 Lab Lecture #9

24. Checkpoint 2 Comments (4)
Why does setting RAM_CLK = ~Clock fix it?
Now we get 18ns where the data is stable on both sides of the rising edge of RAM_CLK
18ns is much longer than any of the setup or hold times
8/26/2018
EECS150 Lab Lecture #9

25. What NOT to do in Verilog (1)
You are not writing a computer program!
Everything you write gets turned into physical hardware on the FPGA
Try to keep in mind what is efficient and what is not
Only applies for verilog code synthesized into hardware
Testbenches are exempt, but regular software restrictions on array sizes apply
8/26/2018
EECS150 Lab Lecture #9

26. What NOT to do in Verilog (2)
Extreme Combinational logic
input wire [31:0] A;
input wire [31:0] B;
output wire [63:0] C;
assign Out = (A * B) / C + A % 5
Avoid multipliers, dividers, and modulo division in your code (unless it is by a power of 2)!
8/26/2018
EECS150 Lab Lecture #9

27. What NOT to do in Verilog (3)
Very big wire or reg declarations
wire [32999:0] A;
wire [44999:0] B;
reg [1999:0] C [4999:0];
Reason is obvious: how are you going to be able to route those wires?
8/26/2018
EECS150 Lab Lecture #9

28. What NOT to do in Verilog (4)
Trying to be smart with how you code
example: asynchronous reset register
input wire [7:0] A;
output reg [7:0] C;
Clock or Reset) begin
if (Reset) C <= 8’b0;
else C <= A;
end
Please follow the guidelines in FSM.pdf or you will NOT GET WHAT YOU WANT!
8/26/2018
EECS150 Lab Lecture #9

29. What NOT to do in Verilog (5)
Putting the Clock signal into Chipscope
Chipscope samples on the positive edges of Clock
The Clock signal will just look like a constant 1;
Chipscoping signals that is synchronized to a Clock different than the Chipscope Clock will give you wrong data (be careful with ~Clock in Checkpoint 2!)
8/26/2018
EECS150 Lab Lecture #9

30. What NOT to do in Verilog (6)
Making 300-bit trigger/data ports in Chipscope, then sampling 9999 data points
Do the math: How many bits does it take to just store all these Chipscope samples?
Chipscope IS hardware! Adding Chipscope to your design will take its toll on Synthesis/PAR times!
Do any long tests in Modelsim
8/26/2018
EECS150 Lab Lecture #9

31. What NOT to do in Verilog (7)
Consequences
Unreasonably long Synthesis/Place and Route times (1hr+ for really screwed up designs)
Tools might even give up immediately and error
Unexplained “Heisenbugs” that creep up
Logic violating setup and hold times because tools simply can’t make your logic fast enough to meet Clock period
But some paths through your logic will not, and work fine
Design might work only on some boards
Read your static timing report to see if you violate any timing constraints!
8/26/2018
EECS150 Lab Lecture #9

32. Questions?
8/26/2018
EECS150 Lab Lecture #9