EECS150 Fall 2008 - Lab Lecture #9 SDRAM Arbiter EECS150 Fall 2008 - 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

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

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

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

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

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

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

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

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

Administrivia (2) Submission Policies Design Review Policies Checkpoint 2 You must submit your code via SVN Checkpoint 1 We will accept emails 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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; always @(posedge 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

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

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

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

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