Logic AnalyzersTodayLab #3 Solution (1)Lab #3 Solution (2)Lab #3 Solution (3)Lab #3 Solution (4)Synplify Warnings (1)Synplify Warnings (2)Synplify Warnings (3)Synplify Warnings (4)Synplify Warnings (5)Synplify ErrorsDebugging Hardware (1)Debugging Hardware (2)Debugging Hardware (3)Administrative InfoLab #5: Logic Analysis (1)Lab #5: Logic Analysis (2)Lab #5: Logic Analysis (3)Lab #5: Logic Analysis (4)The Logic Analyzer (1)The Logic Analyzer (2)ChipScope (1)ChipScope (2)ChipScope (3)ChipScope (4)Slide 272/22/2008 EECS150 Lab Lecture #5 1Logic AnalyzersEECS150 Spring 2008 – Lab Lecture #5Ke Xu2/22/2008 EECS150 Lab Lecture #5 2TodayLab #3 SolutionSynplify WarningsDebugging HardwareAdministrative InfoLogic AnalyzerChipScopeChipScope Demo – Not on webcast!2/22/2008 EECS150 Lab Lecture #5 3Lab #3 Solution (1)Simple SolutionUse the standard 2 (or 3) block FSM format1. Always @ (posedge Clock) block that instantiates the register that contains state.2. Combinational logic block that responds to inputs and state changes by updating nextState wire and outputs.3. Optionally, block that updates outputs.2/22/2008 EECS150 Lab Lecture #5 4Lab #3 Solution (2)Cleaning Up Your Verilog FSM Codealways @ (ps) begin case (ps) STATE_Init: begin Open = 1’b0; Prog1 = 1’b0; Prog2 = 1’b0; Error = 1’b0; if (Decode1 & Enter) ns = STATE_Ok1; else if (~Decode1 & Enter) ns = STATE_Bad1; end ... STATE_Ok2: begin Open = 1’b1; Prog1 = 1’b0; Prog2 = 1’b0; Error = 1’b0; ...2/22/2008 EECS150 Lab Lecture #5 5Lab #3 Solution (3)always @ (ps) begin Open = 1’b0; Prog1 = 1’b0; Prog2 = 1’b0; Error = 1’b0; case (ps) STATE_Init: begin if (Decode1 & Enter) ns = STATE_Ok1; else if (~Decode1 & Enter) ns = STATE_Bad1; end ... STATE_Ok2: begin Open = 1’b1; ...2/22/2008 EECS150 Lab Lecture #5 6Lab #3 Solution (4)How about using assign statements for outputs?always @ (ps) begin case (ps) STATE_Init: begin if (Decode1 & Enter) ns = STATE_Ok1; else if (~Decode1 & Enter) ns = STATE_Bad1; end ... STATE_Ok2: begin ... endcaseendassign Open = (ps == STATE_Ok2);assign Error = (ps == STATE_Bad2);...We can exploit the fact that outputs are strictly state-dependent (Moore)2/22/2008 EECS150 Lab Lecture #5 7Synplify Warnings (1)Why Bother?“@W” in the Synthesis Report (Errors are “@E”)Part of your project gradeMajor warnings will cost pointsKnowing these will make your life easierSaves debuggingAlways run synthesis before simulating in ModelSim!Incomplete Sensitivity ListModelSim will use the sensitivity listSynplify pretty much ignores it2/22/2008 EECS150 Lab Lecture #5 8input [15:0] A, B;output [31:0]Sum;output COut;// Adderalways @ (A){COut, Sum} = A + B;Synplify Warnings (2)input Clock;reg [31:0] Count;// Counteralways @ (posedge Clock)Count <= Count + 1;OK!Incomplete Sensitivityinput [15:0] A, B;output [31:0]Sum;output COut;// Adderalways @ (A or B){COut, Sum} = A + B;OK!2/22/2008 EECS150 Lab Lecture #5 9Synplify Warnings (3)Latch Generatedinput [1:0] select;input A, B, C;output Out;reg Out;// Muxalways @ (select or A or B or C) begincase (select)2’b00: Out = A;2’b01: Out = B;2’b10: Out = C;endcaseendinput [1:0] select;input A, B, C;output Out;reg Out;// Muxalways @ (select or A or B or C) begincase (select)2’b00: Out = A;2’b01: Out = B;2’b10: Out = C;default: Out = 1’bx;endcaseend2/22/2008 EECS150 Lab Lecture #5 10Synplify Warnings (4)Combinational LoopMust remove the loop or add a registerMultiple assignments to wire/regNothing should be assigned to in more than one place!000111223∞??∞??2/22/2008 EECS150 Lab Lecture #5 11Synplify Warnings (5)FPGA_TOP2 always has warningsUn-driven InputUnconnected OutputThese are truly unneeded pinsThings like the audio chips…Your modules should not have warnings2/22/2008 EECS150 Lab Lecture #5 12Synplify ErrorsYour design violates timing constraintsRight click on the Synthesize stepGo to propertiesUncheck Auto-constrainSet frequency to 27 (MHz)By default the software uses a 50% duty cycle and excessively restricts the delay of combinational logic.In the future you might still get errors, in which case you might need to pipeline or redesign logic.2/22/2008 EECS150 Lab Lecture #5 13Debugging Hardware (1)Debugging AlgorithmHypothesis: What’s broken?Control: Give it controlled test inputsExpected Output: What SHOULD it do?Observe: Did it work right?If it broke: THAT’S GREAT!If we can’t break anything like this then the project must be working…2/22/2008 EECS150 Lab Lecture #5 14Debugging Hardware (2)Using the logic analyzer / ChipScopeThe most reliable tool you haveWhen used properlyUse the triggers effectivelyTrigger on recurring sequencesTrigger on errorsAn unstable display is uselessCompare synthesis to simulationChipScope is almost as good as simulation2/22/2008 EECS150 Lab Lecture #5 15Debugging Hardware (3)Before you change anythingUnderstand exactly what the problem isFind an efficient solutionEvaluate alternative solutionsAfter the changeFixes may make things worse sometimesMay uncover a second bugMay be an incorrect fixRepeat the debugging process2/22/2008 EECS150 Lab Lecture #5 16Administrative InfoLab/Project PartnersIf you don’t have a partner, stay after lab lecture and we’ll help you get partnered up.Remote access to Xilinx toolsUse Remote Desktop Connection to access kramnik.eecs.berkeley.edu.A link to the kramnik set-up guide is on the documents page.Also useful for transferring files to and from your U:\ drive.2/22/2008 EECS150 Lab Lecture #5 17Lab #5: Logic Analysis (1)Exhaustive FSM TestingVery similar to Part3 of Lab #4You’ll be mapping the whole FSMNo bubble-and-arc to start fromNo single stepTakes an input every cycle at 27MHzMuch too fast to see on the LEDsLogic Analyzer!2/22/2008 EECS150 Lab Lecture #5 18Lab #5: Logic Analysis (2)Logic AnalyzerHP54645D Mixed Signal OscilloscopeAnalog OscilloscopeDigital Logic AnalyzerGraphs Signals vs. TimeLike a timing diagramInvaluable for DebuggingThis is your
View Full Document
Unlocking...