1 / 32

SDRAM Arbiter

SDRAM Arbiter. EECS150 Fall 2008 - Lab Lecture #9 Chen Sun Adapted From Slides by Greg Gibeling and Allen Lee. Diagrams by Chris Fletcher. Agenda. Checkpoint 3 Introduction Administrivia SDRAM Arbiter Interfaces FIFORAM.v Notes about Checkpoint 2 Design Tips.

darrellb
Télécharger la présentation

SDRAM Arbiter

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Agenda • Checkpoint 3 Introduction • Administrivia • SDRAM Arbiter • Interfaces • FIFORAM.v • Notes about Checkpoint 2 • Design Tips 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 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 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 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! EECS150 Lab Lecture #9

  7. Checkpoint 3 Introduction (5) • TA Checkpoint 3 Black-box 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 EECS150 Lab Lecture #9

  9. Administrivia (1) • Checkpoint 1: • 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) EECS150 Lab Lecture #9

  10. Administrivia (2) • Submission 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 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 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. 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 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 EECS150 Lab Lecture #9

  15. SDRAM Arbiter Interfaces (4) EECS150 Lab Lecture #9

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

  18. FIFORAM.v (3) 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 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! 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 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 EECS150 Lab Lecture #9

  23. Checkpoint 2 Comments (3) • What would happen if RAM_CLK = Clock? • Setup or hold times potentially violated 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 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 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)! 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? 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; 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! 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!) 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 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! EECS150 Lab Lecture #9

  32. Questions? EECS150 Lab Lecture #9

More Related