Vivado ILA Debugging

I want to introduce another topic today this one involves debugging a Verilog design that's running on an FPGA and I'm going to start with the same blinky light project that we developed in the last lab there's there's been no change to it and what I want to be able to do is inspect the signals that are on the internal signals other in the design and be able to verify that they're functioning correctly now I could use theoretically I could use an oscilloscope or an external logic analyzer and I could wire up the the scope to the board and I would be able to see the voltages that are present on the i/o pins if I'm not seeing any i/o all I know is that I'm not seeing any i/o I know that there's some kind of a problem internal to either the logic of the verilock module out of design or in the assignment of the Verilog module to the pins or that there's been an electrical fault so for example maybe there is a dead short on a line and I'm actually risking damage to the part or there's a broke or break in the line and I'm just not going to get the signal so there's a number of things that we can do but knowing where to start looking to resolve those as more than half of the battle in many cases so to get started what I want to do is I want to look at the internal state and to do that I'm going to use a piece of intellectual property that comes with the vivido tools it's called the ILA the integrated logic analyzer and I'm going to add this to my design and so I'm going to start over here and use the IP catalog and this brings up a browser window that I can browse through and I'm going to look for debug and find debug here I'm going to look for the ILA we can have any up to 64 probes defined in our Iowa core each probe would correspond to some set of resources that I want to be able to trigger on for this simple example we're just going to go ahead and use the one probe the monitor type is allowing me to either inspect native Verilog code or to inspect the communications that are happening between two different devices in the AXI bus this is the communication between the ARM processor core and verilock modules but we'll look at that separately we'll do a whole other series of videos on that integration the sample depth is allowing me to configure how much memory I want to be able to dedicate toward collecting the samples for every bit that I store I'm going to be able to store up to in this case a thousand 24 samples of that bit so once I start to trigger the trigger is going to start recording the data and I'll have up to a thousand 24 entries we can easily change that and go you know up to quite a large amount of memory here Oh 131,000 samples we don't need anything close to that the memory is coming from onboard memory in the fabric of the FPGA what they call block Rams there are static Rams that are available they're scattered throughout the fabric of the FPGA or is going to use the flip-flops that are built into the logic cells of the FPGA we don't really have a whole lot of configuration control over that but certainly the more memory that I'm using for the ILA the less memory I would have for design and so for these very simple designs it's hard to imagine that there would ever be memory pressure but as your designs start to get larger and you start to use those block rams for things this does become a limitation we can use comparators this is going to define how we compare values on the probes with this one's more sense here in just a moment and then I can have a trigger out or a trigger in port so this would allow me to for instance have a trigger out that I could connect to a pin on the FPGA and then I could connect that to this port on my oscilloscope and I could actually have hardware or software code debugging where when I trigger on the logic in here it starts this oscilloscope to trigger an oscilloscope but then watch the data lines on the electrical side and then I could very easily compare the two and look for differences similarly I could have an external trigger in port where if the oscilloscope is determined to a rut frame that would trigger the ILA to start capturing the data and allow me to actually look at what was happening right before that run frame was generated on the oscilloscope and so when you have these differences that can be very desirable to be able to lock these two together we can have an capture control that allows me to essentially just decide what data goes into the memory so for instance once we start triggering we could maybe not actually store all data we could define conditions that the data have to be the data have to meet an order piece to be recorded in a memory and then we can decide if we want an advance trigger the base trigger allows me to do things like izl a signal high or as a signal low advance trigger allows me to do things like edges pulse widths and things of that nature we'll just turn that on just to go and get us see what's going on here so now I'll go into the debug probe ports and I can now configure the different values that are associated with these ports as we see here this probe I can specify the number of bits and we could actually just use the one probe and then connect each bit of the probe to one of our signals or I could make multiple probes so if we think back to the blinking light example for instance we had the LED out all eight of those we had the clock divider and then we had the input clock let's just go ahead and capture what the eight LEDs and that divider clock look like so I'm going to have nine four sorry two different probes one probe will be eight bits wide and that would be the LEDs and then the other probe of course will be the div clock so at this point it has created a IP instance and it's now going to generate Vera log stubs that I can use to instantiate a module all right if I look at this I allow xci this is the kind of template file that's used to generate the rest of the files if i zoom into it what I see is a vera log file and this is useful because if I open this Vera log file we see all of the kind of parameter Pro kind of preamble but really what I'm interested in is right here this is the module declaration and so if I copy that I can go back to my blinky light example I'll just paste in this module module declaration and I'll turn this into a unit instantiation now the clock that we want to run on is going to be div class and the probe here is going to be the LEDs at the LED out and so that would be LEDs and div clock so it turns out the Xilinx tools have a limitation on the sign links or the ILA clock and it has to be at least as fast as the JTAG cable in this case I'm going to go ahead and take out the clock divider I was unaware of that limitation if you generate the module you won't get any errors but at the very end when you program the device you also don't get a debugger so we'll go ahead and just use the high-speed clock 100 megahertz clock and what I've done is I've turned on let's go back here to the project manager I've turned on advanced triggering and this will allow us to turn on and look for more advanced patterns in our debugging and I've also included now the direction port so I'll go ahead and regenerate and once this is all done we should have a hardware debugging window okay so after some wailing and gnashing of teeth we finally have our Hardware programmed and configured and an Iowa core is available and it's it's kind of a a great deal so this is the ILO window and what we see here is the trigger configuration and so we can choose the trigger mode we can see the capture mode and we can see the refresh rate which is going to configure how fast this refreshes we see the status of the debugging core and capture status and here we see that the rules for setting up the triggers and the captures so turn we could do a very simple trigger and say that I want to trigger on LEDs instead of having it be bit one I want to have it be on bit four and now if I click on run we'll see that it takes just a few extra seconds and there was waiting for trigger and then once that trigger condition happened and it shows you the remaining 32,000 samples so the basic trigger allows me to define a trigger condition of one particular value whether it's equal to or not equal to or less than or greater than the more advanced trigger options are available here under trigger mode if I so to create an advanced template or an advanced trigger we actually had to use the Xilinx advanced rigor and Xilinx have created a entirely new language to define the trigger mechanism for an advanced trigger just what we needed yet one more different programming language when I switch over to this this trigger setup window turns into a text editor I'll click on this maximize button to be able to bring it to full screen and I can use these little ideal light bulbs here to get an idea of what the syntax for this language looks like and this is a trigger on the fourth rising edge I want to trigger on the falling edge of LED six since LED seven is not turning on I want to find out what's going on when that happens so I'll just copy and paste this as a starting point and what we can see here is a kind of a basic grammar where we have a state defined and we give it a name and a colon and everything that belongs in this state is kind of underneath of it we have an if syntax which is pretty familiar for us we have the same kind of vera log ease for defining different conditions only we have some weird symbols here for our and if we were a gas for a rising edge F for falling edge so if I wanted to capture the riot the falling edge of my LEDs and that was just a signal OPA is an 8-bit wide field and I don't care about any of the other values we could define the trigger like this I'm getting rid of the counters I really just want to get the falling edge so we'll trigger and if it's not that then we go back to the the the trigger state so this little language here allows us to essentially say if you find the falling edge on bit six trigger otherwise go back and rearm the trigger and look for the next signal it's kind of the short end of it I'm going to save this and I'm going to run this this trigger and we see right away that it did happen we got to the falling edge of our trigger here at the very beginning oh I had it set for a rising edge so we'll change that the falling edge and we'll rearm okay so this time we get to see the the falling edge happen and so that when the trigger happens trigger led six went off and led five came on yep I do see the problem so in direction is equal to zero [Applause] I'm shifting only bits six through one down never bits seven and so that would actually be the problem with that rotation so this was only a six bit wide field and our concatenation here didn't fit it so that's one problem with concatenations and Vera log is you have to make sure that they're the right width so one last thing I want to show as far as using the ILA core for debugging is to set up that trigger out or the trigger in let me go ahead and do a trigger out here and the idea now is when we regenerate this module the vera log header is actually going to have another port that i can use and that will allow me to specify an external connection on the on the z board that i can then hook up to my oscilloscope and have that trigger on the ilyich or trigger the oscilloscope to also capture okay so after the core is regenerated I can go and open up the vera log stub for our our module here and I actually get to see a new template to go my blinky logic here I can paste this new new version of our I love the bugger into it so neither of those change now I have my trig out is going to be my alcoholic text trick just to keep the signals a little bit different and then our trig out act would be the acknowledgement that the trigger has happened now if you're using a conventional oscilloscope you may not be able to generate that acknowledgement signal and so we're going to generate that ourselves so first thing I can do here will make a register called triggered out and it will initially be zero a syntax here here Oh cleared and of course we don't have that extra signal so here and trig and now the only thing I've got to do is I'll add an always block here so always a positive edge fig in straight path back equals zero now that would always turn the clock on [Music] we might want to do is have this be at the positive edge of the clock trig equals one there so there's a little logic block that would essentially raise the acknowledgment whenever the external trigger goes high and drop it whenever the trigger goes low we could add something more sophisticated for example we could hold it high for some number of clock cycles if the scope was relatively slow whatever the situation is just to kind of give you the idea that this will clear the acknowledgement signal and make us ready for the next trigger and not have to have a be handled externally if I were to generate this then I could go through the process that we've used before to assign this to an external pin give it a location on the FPGA and then hook up my oscilloscopes external trigger wire to it and be able to trigger the oscilloscope whenever the hi liqueur triggers or the internal trigger condition matches so there you go there's just some brief ways of using the onboard eyelid debugger

Channel: BOPV

Views: 33,471

Rating: 4.9780221 out of 5

Keywords: xilinx, vivado, ila, tutorial

Id: _ljXMoGJ5iM

Length: 20min 15sec (1215 seconds)

Published: Thu Mar 02 2017