1 / 46

Good Design & Network Audio

Good Design & Network Audio. EECS150 Fall2004 – Lab Lecture #5 Udam Saini. Today (1). Synplify Warnings ChipScope Administrative Info. Today (2). Lab #5: Network Audio Network Organization Ethernet Packets Eth2Audio Async FIFO. Synplify Warnings (1). Why Bother?

Download Presentation

Good Design & Network Audio

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. Good Design & Network Audio EECS150 Fall2004 – Lab Lecture #5 Udam Saini EECS150 Lab Lecture #5

  2. Today (1) • Synplify Warnings • ChipScope • Administrative Info EECS150 Lab Lecture #5

  3. Today (2) • Lab #5: Network Audio • Network Organization • Ethernet Packets • Eth2Audio • Async FIFO EECS150 Lab Lecture #5

  4. Synplify Warnings (1) • Why Bother? • Part of your project grade • Major warnings will cost points • Knowing these will make your life easier • Saves debugging Incomplete Sensitivity List • ModelSim will use the sensitivity list • Synplify pretty ignores it EECS150 Lab Lecture #5

  5. Synplify Warnings (2) input Clock; reg [31:0] Count; // Counter always @ (posedge Clock) Count <= Count + 1; OK! input [15:0] A, B; output [31:0] Sum; output COut; // Adder always @ (A) {Sum, COut} = A + B; input [15:0] A, B; output [31:0] Sum; output COut; // Adder always @ (A) {Sum, COut} = A + B; input [15:0] A, B; output [31:0] Sum; output COut; // Adder always @ (A or B) {Sum, COut} = A + B; Incomplete Sensitivity OK! EECS150 Lab Lecture #5

  6. Synplify Warnings (3) • Latch Generated input [1:0] select; input A, B, C; output Out; reg Out; // Mux always @ (select or A or B or C) begin case (select) 2’b00: Out = A; 2’b01: Out = B; 2’b10: Out = C; endcase end input [1:0] select; input A, B, C; output Out; reg Out; // Mux always @ (select or A or B or C) begin case (select) 2’b00: Out = A; 2’b01: Out = B; 2’b10: Out = C; default: Out = 1’bx; endcase end EECS150 Lab Lecture #5

  7. Synplify Warnings (4) • Combinational Loop • Must remove the loop or add a register • Synplify wont show you the loop • Comment out code till it goes away 0 1 0 1 2 3 ∞?? ∞?? 0 1 2 EECS150 Lab Lecture #5

  8. Synplify Warnings (5) • FPGA_TOP2 always has warnings • Un-driven Input • Unconnected Output • These are truly unneeded pins • Things like the audio chips… • In your modules these are a problem • Synplify will optimize your design • Unconnected modules removed EECS150 Lab Lecture #5

  9. Synplify Warnings (6) • Why bother? • Getting rid of warnings saves debugging • Synplify warnings will result in lost points • Warnings are the only syntax check • Verilog is a forgiving language • Undeclared variables default to 1 bit wires • This isn’t a good thing EECS150 Lab Lecture #5

  10. ChipScope (1) • Software based logic analyzer • Get results on the computer • Put a logic analyzer right into the FPGA • ICON – Connects FPGA to software • ILA – Does the actual analysis • More flexible than the bench analyzers • But not as timing accurate EECS150 Lab Lecture #5

  11. ChipScope (2) • Steps to use ChipScope • Generate an ICON • Generate an ILA • Connect the ILA to the ICON • Synthesize, and implement your design • With the ILA and ICON • Program the CaLinx board • Run the ChipScope Pro Analyzer • Runs over the JTAG not Slave Serial EECS150 Lab Lecture #5

  12. ChipScope (3) • Logic Analyzer Similarities/Differences • Triggering is similar • Can be set to show waves before trigger • Can trigger on repeated or combined events • Data/Trigger can be MUCH bigger • Up to 256bits wide • As many samples as Block RAM on the FPGA • Data is captured synchronously • Can’t look at clocks • Much easier to view waveforms EECS150 Lab Lecture #5

  13. ChipScope (4) • ChipScope is useful to verify • In this lab we’re using it just to make absolutely sure • You will NEED ChipScope • You cannot debug a large design without it • Bench analyzers wont show enough signals • Detailed ChipScope Tutorial • http://inst.eecs.berkeley.edu/~cs150/fa04/Documents.htm#Tutorials EECS150 Lab Lecture #5

  14. Administrative Info • Midterm I • Midterm I completely graded • Some have been handed back in discussion section. • We will hand them out after Lab Lecture EECS150 Lab Lecture #5

  15. Lab #5: Network Audio • Play Audio off Ethernet • Receive Ethernet packets • Decode and remove header • Filter packets • Play audio data payload • A Major Project • Given: Ethernet, Audio, ETC • To be written: Packet Decode & Filtering EECS150 Lab Lecture #5

  16. Network Organization (1) EECS150 Lab Lecture #5

  17. Network Organization (2) DO NOT MODIFY THE PRODUCTION NETWORK EECS150 Lab Lecture #5

  18. Ethernet Packets (1) • We’re using raw Ethernet • No TCP/IP, its too complex • Cant use this on the internet • Raw Ethernet: • 48bit Destination MAC Address • 48bit Source MAC Address • 16bit Ethernet Type • Payload • 32bit CRC EECS150 Lab Lecture #5

  19. Ethernet Packets (2) • A Little Theory of Ethernet • Bit Serial 100Mbps Link • 4/5bit Encoding takes 20% overhead • Bit5 is used for Data-Valid and Error • Preamble used for clock extraction • Inter Frame Gap ensures packets aren’t back-to-back • CRC used to avoid errors from transmission EECS150 Lab Lecture #5

  20. Ethernet Packets (3) EECS150 Lab Lecture #5

  21. Ethernet Packets (4) • A Good Packet • Total: 1028x 32bit Words • 48bit Destination (0xFFFFFFFFFFFF) • 48bit Source (0x0090c2001c50) • 16bit Packet Type (0x0101) • 16bit Padding (0x????) • 1024x 32bit PCM Audio Data EECS150 Lab Lecture #5

  22. Ethernet Packets (4) • A Bad Packet • Who knows how long? • Source and Destination could be anything • Packet Type probably not 0x0101 • Coping with bad packets • Do NOT send them to AudioTop • Just keep dropping data until end of packet • InPacketValid & InPacketInvalid EECS150 Lab Lecture #5

  23. Lab #5: Eth2Audio EECS150 Lab Lecture #5

  24. Lab #5: Eth2Audio EECS150 Lab Lecture #5

  25. Lab #5: Eth2Audio • Design • Word Counter • How many bits wide? • Efficient Comparisons? • Valid Register • Stores whether the packet is valid or not • Reset • When do you reset word counter and valid register? • Short and Long Bad Packets EECS150 Lab Lecture #5

  26. Lab #5: Eth2Audio • Testing • We give you a very nice testbench • Read Lab5Testbench.v • Read Lab5TestPackets.txt • Fix your module in simulation • Checkoff • We should hear nice clean audio • Show us your module using ChipScope EECS150 Lab Lecture #5

  27. Lab #5: Async FIFO • Buffer to match two data rates • Great for data path clock domain crossings • Write on one clock • Read on another • Good place to buffer audio EECS150 Lab Lecture #5

  28. Verilog Tips & Tricks 9/28/2007 EECS150 Lab Lecture #5 28

  29. Running a New Simulation without Closing ModelSim In the ModelSim console, press the up arrow to see the previous command: {do xyzTestbench.fdo} This command will “recompile” your Verilog files and rerun the simulation. Rerunning without recompiling: restart –f; run 10us; EECS150 Lab Lecture #5 29

  30. Viewing Signals in Submodules Expand submodules in Workspace pane Click-and-drag signals to waveform Type “restart –f; run 10us;” in console. Do not use the “do” command! EECS150 Lab Lecture #5 30

  31. Declaring reg for outputs. Suppose count needs to be assigned a value in an always blocks. output [3:0] count; reg count; What’s wrong here? output [3:0] count; reg [3:0] count; What’s the best way of fixing this? output reg [3:0] count; EECS150 Lab Lecture #5 31

  32. Explicitly Connect to Module Ports We’ve been calling this “dot notation” Good: adder my_adder(.A(A),.B(B),.Sum(Sum)); Bad: adder my_adder(A,B,Sum); EECS150 Lab Lecture #5 32

  33. What Can Go Wrong? (1) Suppose David and Randy are working on a project. David writes module foo(A,B,F) Randy instantiates it in his design: wire w1,w2,w3; foo my_foo(w1, w2, w3); EECS150 Lab Lecture #5 33

  34. What Can Go Wrong? (2) • David needs to add port C to foo: • module foo(A,B,C,F) • David tells Randy about the new port: • wire w1,w2,w3,w4; • foo my_foo(w1,w2,w3,w4); • Now w3 connects to C instead of F! EECS150 Lab Lecture #5 34

  35. Use Meaningful Wire Names • Bad • wire w1, w2, w3; • foo my_foo(.A(w1), .B(w2), .F(w3)); • Good • wire foo_a, foo_b, foo_f; • foo my_foo(.A(foo_a),.B(foo_b),.F(foo_f)); • More helpful when using ModelSim EECS150 Lab Lecture #5 35

  36. Synthesis Warnings In particular, watch out for these Combinational loop detected Latch generated Incomplete sensitivity list If any of these appear in your synthesis warnings, your synthesized design will most likely not match simulation. EECS150 Lab Lecture #5 36

  37. One Module per File Module name should match file name Otherwise, it’s difficult to find the file containing your module. EECS150 Lab Lecture #5 37

  38. always @ blocks For state machines, use 2 or 3 always blocks. Recall the Mealy Machine: Inputs Outputs Output and Next State Combinational Logic State Current State Next State EECS150 Lab Lecture #5 38

  39. always @ blocks Inputs Outputs Output and Next State Combinational Logic State Current State Next State always @ (posedge Clock) if(Reset) CurrentState <= STATE_Init; else CurrentState <= NextState; always @ (CurrentState or Inputs) begin NextState = CurrentState; Outputs = 0; case(CurrentState) STATE_Init: begin (Next state and output calculations here) end … endcase end EECS150 Lab Lecture #5 39

  40. always @ blocks What about a Moore Machine? State transition part is the same May use three always blocks: always @ (CurrentState or Inputs) begin NextState = CurrentState; case(CurrentState) [Calculate Next State] endcase end always @ (CurrentState) begin Outputs = 0; case(CurrentState) [Calculate Output] endcase end EECS150 Lab Lecture #5 40

  41. More Moore Machines Suppose output “foo” is only high in state STATE_Foo: always @ (CurrentState) begin foo = 0; case(CurrentState) … STATE_Foo: foo = 1; … endcase end • May also use assign statements: assign foo = (CurrentState == STATE_Foo); EECS150 Lab Lecture #5 41

  42. Parameters as State Names Bad case(CurrentState) 3’b000: NextState = 3’b101; 3’b001: NextState = 3’b100; … endcase • Good parameter STATE_Init = 3’b000, STATE_Foo = 3’b001, … case(CurrentState) STATE_Init: NextState = STATE_Bar; STATE_Foo: NextState = STATE_Baz; … endcase • Parameters make your code easier to read, debug, and change. EECS150 Lab Lecture #5 42

  43. Use defparam Suppose you need a 6-bit register. In Register.v: Parameter width = 32; … Output [width-1:0] Out; • Do not simply make a file called Register6.v and change the width! • Instead, use defparam: Register MyRegister( … ); defparam MyRegister.width = 6; EECS150 Lab Lecture #5 43

  44. Use Register.v and Counter.v Suppose you need a counter that increments to 42 before resetting. // Without Counter.v always @ (posedge Clock) if(Reset || (Count == 41)) Count <= 0; else if(Enable) Count <= Count + 1; // With Counter.v Counter MyCounter(.Clock(Clock), .Reset(Reset || (Count == 41), .Set(1’b0), .Load(1’b), .Enable(Enable), .In(0), .Count(Count)); defparam MyCounter.width = 6; • Cleaner “always” blocks • Don’t forget defparam! EECS150 Lab Lecture #5 44

  45. Avoid this Loop Observe error on board Make guess about source of error Make small change to verilog files Generate programming file (may take up to 20 minutes) Surf Facebook Go back to step 1 • This is why some projects take 100+ hours • Instead, review your synthesis warnings and use Chipscope to debug. EECS150 Lab Lecture #5 45

  46. Questions? EECS150 Lab Lecture #5 46

More Related