UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Reply

Vivado 2017.1 Logic Analyzer persnickety

Highlighted
Explorer
Posts: 364
Registered: ‎06-23-2014

Vivado 2017.1 Logic Analyzer persnickety

Over a few years using ISE 14.7, I became accustomed to the ways in which ChipScope didn't really work for all variations in work flow.  I developed a specific regimen that I followed to make sure I got what I needed and got there on the first build, builds being so slow.  For example, if I rebuilt my bitstream, I always had to create a new project and load the cdc file, recombine my busses and so forth -- every build.  Doing anything shy of that and ChipScope would get confused about which signals were which.

 

So now I'm using Vivado for the first time, version 2017.1.  I'm using Logic Analyzer for the first time.  If I delete all the old logic-analyzer-related lines from my constraints file and then start from scratch, things work.  But if I change my source code and rebuild, on the second time around I get miscellaneous warnings about things missing and eventually at the bitstream and logic analyzing, things misbehave.  Darn.  I thought the old ChipScope problems would be history.  They're just a new set of problems and I don't yet have a regimen figured out to always work.

 

I have attempted to follow at least two different work flows for this.  I've spent most of my time using "Synthesis / Open Synthesized Design / Set Up Debug" and then drag-and-drop nets from the Netlist to the Set Up Debug wizard.  Unfortunately, the second time around, nets that no longer exist in my code seem to not want to go away.  Nets I try to remove with "-" don't actually get removed by the time the wizard finishes and exits -- if I reload the wizard they are back in.  It's all confused.

 

The other flow I've tried is marking nets for debug.  I had little initial success with this, so I haven't tried again.

 

Then there's the Debug window with its tree view of ILA's, probes, and nets.  I don't know about directly editing in here.  

INTERIM QUESTION: Is this Debug window view in essence a visual window into the constraints file?  I believe maybe it .s

 

One other thing.  That Set Up Debug wizard modifies the constraints file, but if the constraints file is also open in the GUI, the GUI's version is neither updated nor informed of a change on disk.  This is a recipe for information loss.  The wizard and GUI should, but don't, cooperate on the content of this file.

 

BIG QUESTION:  So what is a good work flow that will remain well behaved if I have to repeatedly edit my source, re-synthesize, update/add/remove/change nets being scoped, rebuild repeatedly, and then repeat logic analyzing?  I would greatly appreciate and concise handwritten list or a link to a document that addresses the **repeat** nature of all this.

 

SMALL QUESTION:  I see the three different ways already mentioned for configuring the logic analyzer (Set Up Debug, Mark Debug, directly edit Debug window).  I've seen doc describing all three.  Surely I shouldn't be doing all three every time.  Which ***one*** should I learn well how to use and then stick with?

 

Thanks,

Helmut

 

 

Voyager
Posts: 327
Registered: ‎02-12-2013

Re: Vivado 2017.1 Logic Analyzer persnickety

[ Edited ]

Helumt,

 

Welcome to Vivado ILA. It is quite a bit different than ISE Chipscope but, I think, better in most respects.

 

I have tried several way to script the insertion of ILA cores into my build.  I was able to make that work with a lot of fiddling but now I recommend that you just use instantiation.

 

ILA core instantiation works just like the instantiation of any Xilinx core so you won't have to learn anything new.  When you make an ILA core you get an xci file that you can use as source just like any other Xilinx Vivado core.

 

Instantiation is quite simple in Vivado.  There is just the single core to reference in your code.  I often just type in the ILA instantiation as I write my code if it is something I am likely to want to debug.  Verilog instantiation looks like this.

 

    my_ila  ila_inst ( .clk(clk200), .probe0( {sig1, sig2, bus1, bus2}) );

 

Once I have decided how many signals I want to see I go into the core generator tool and make "my_ila". 

 

Good luck.  Often with FPGA programming the only way you succeed is by simply never giving up.

 

  Pete

Explorer
Posts: 364
Registered: ‎06-23-2014

Re: Vivado 2017.1 Logic Analyzer persnickety

@pedro_uno,

 

I half understand and I half do not understand.  I thought I understood you, but as soon as I went to do it, I didn't understand.

 

Specifically:

 

1) You mention "sig1, sig2, bus1, bus2".  I have a complicated multi-source-code-file project.  When in the logic analyzer, I need a single ILA to probe signals from different source code files.  However, if I instantiate the ILA in my TOP level source code file, I will not be able to name signals from down inside lower levels, unless I bring those up on ports.  This will generate too big of a mess.  Is this what you meant, or am I misunderstanding?

 

2) I don't find a "Core Generator" for Vivado.

 

3) Even if I did, it sounds like you have to then (A) manually configure the instantiated ILA to have the correct number of probes and signals, to match your instantiation.  If you decide to use more/less/different signals, then you have to edit the instantation and ALSO reconfigure the core and regenerate it.  This seems like it may be way too much manual work, including duplication of information which therefore makes it very error prone.

 

Either I totally don't get it, or I must ask "are you sure about this?"  Due to the limited resources inside the FPGA for large complex debug widths and capture depths, I have always found myself repeatedly changing which signals need to be seen, and rebuilding between.  As I understand what you're saying, it's far more complicated than even the old ISE 14.7 and ChipScope way.  I find this hard to believe, that Vivado is more complicated to do.

 

 

Voyager
Posts: 327
Registered: ‎02-12-2013

Re: Vivado 2017.1 Logic Analyzer persnickety

Helmut,

 

I think you mostly understand me.  I create an ILA core from the "IP Catalog" of Vivado then instantiate it in my Verilog code.

 

It is very quick to open the core and change the number of signals on the ILA.  I find that more reliable than core insertion.

 

It is true that accessing signals from different parts of the hierarchy is not very convenient this way but normally I am debugging only one part of my design at a time.  I like the ability to just comment out an ILA when I no longer need it in that block.

 

If you really do need to see signal from many parts of your design on the same ILA you could use the hierarchical reference technique of Systemverilog.  That way you could instantiate a single ILA at the top of your design and wire in all the signals from all parts of your design.

 

  Pete

Explorer
Posts: 364
Registered: ‎06-23-2014

Re: Vivado 2017.1 Logic Analyzer persnickety

@pedro_uno,

 

Ok.  Note I'm already using SystemVerilog, so I'll research the hiearchical reference technique you mention.  Then I'll give your method a try.

 

I'll get back to you perhaps tomorrow.

 

Thanks again,

Helmut

Scholar
Posts: 850
Registered: ‎09-16-2009

Re: Vivado 2017.1 Logic Analyzer persnickety

 

Not sure what Pete's referring to with "hierarchical reference technique of Systemverilog".  Cross-module references have been part of verilog since the beginning in Verilog-1995.  Few synthesizers support it - ISE/Vivado do not.  Occasionally folks ask for the feature - it's perfect for debug and what Helmut's trying to do here.  But it's also has all the subtlety of a "goto" statement in software - something easily abused and resulting in spaghetti code.  So the push to support it doesn't get far...

 

Regards,

 

Mark

Explorer
Posts: 364
Registered: ‎06-23-2014

Re: Vivado 2017.1 Logic Analyzer persnickety

[ Edited ]

@markcurry

 

Thanks for saving me time on that "hierarchical reference technique of Systemverilog".  I was getting close to trying it, finally.  To be clear, you're saying I will *not* succeed taking an ILA core instantiated in my Top.sv, and pass it a signal that comes from a lower level *.sv, without passing I/O signals through the instantiation, right?

 

@pedro_uno and @markcurry

 

While on the subject, please allow me to ask additional questions about the ILA, including instantiation.  

 

  1. My state machine variables are defined using an enum.  In the simulator waveform, they nicely show up with named values in the waveform.  Great "usability".  However, most recently using the Logic Analyzer, I saw that I was getting integers rather than words.  Is there an automagic way to make the Logic Analyzer pick this up as well?  Note that I was familiar with the old ChipScope Pro method of creating a value-name table in a separate file, and then importing it.  I quit wasting my time doing that, however, because the only way I could get persnickety ChipScope Pro to work reliably was to re-import my cdc and re-create all my busses every time.  This then required reconnecting that value-name table every time.  Too much of a pain.  It should have "stuck".  So, now that I found Logic Analyzer also persnickety, I wonder the same thing.  If not automagic, there may be a value-name table method as well.  But is it going to stick well?  I don't want to waste my time learning about it if it won't stick.

  2. In the logic analyzer, I don't really understand the reason for multiple probes of multiple bits each.  Why not have a single probe with all the bits in it?  Is it possibly the case that the Logic Analyzer naturally buses signals together by probe?  If so, then this means in a manual instantiation that I would want to use one bus per probe, for example connecting to it all 8 bits of myregister[7:0].  Then single bit signals would each go to a separate probe, unless of course I wanted to gang them together for convenience.  OTHERWISE, if there's not a specific correlation between probes and buses, then why multiple probes of multiple bits each?

  3. I have found that the optimizer or whatever removes many of my signals.  I'm accustomed to this from ISE 14.7.  I have used the verilog (* keep="true" *) directive in the source code.  However, it seems that this does NOT always cause a signal to get kept.  Furthermore, when using "Set Up Debug", I find that many of my signals are missing from the Netlist.  Were they optimized out in spite of the keep?  Or did they get renamed to something funny due to the morass of assigns and other things?  Note that I am highly using (System)Verilog structures for my signals, such as how to define a 65-bit, even 520-bit, heterogeneous FIFO word.  Many of my structure elements are missing from the Netlist and I can't use them in "Set Up Debug".  I have found a workaround that I don't like.  I define a group of lines like:

    (* keep="true" *) wire debug_<signal> = <structure hierarch>

    and then I generally find most of the debug signals in my Netlist.  Perhaps it's because that was the last explicit assign, and so all the vars ended up being there.  (((EDIT: The reason I don't like this is, by the time I go put a dedicated list of debug assigns like this, I could have just directly instantiated my ILA and not had to worry about signals disappearing from the Netlist and so foiling me.  So this though then brings me to direct ILA instantation, as I discuss below.)))

    Anyway, here's what I'm wondering about ILA *instantiation*.  If I do an instantiation and put all of my structure vars into the instantiation, then I *believe* I'll be guaranteed to get them all into the ILA, by definition.  They won't get optimized out because they will have dedicated usage.  

    • IN THIS CASE, first, will Logic Analyzer know the individual names of the signals?  Or will they just be Probe N signal M?  That's pretty darn bad usability!  (I haven't tried instantiation yet to find out, although I have a build running while I write this post...)
       
    • I will have a single structure typedef that has heterogeneous content in the structure.  But the typedef creates a 65-bit object.  In the verilog code, I've been able to assign one such 65-bit object to another.  Should I be able to put that object name in the ILA instantiation probe list and get all 65-bits into the ILA core?  What about seeing names in the Logic Analyzer? (long shot!)  

    • If the above behavior is well developed, and without hierarchical reference from Top.sv, then I'd like to instantiate an ILA core in every module.  I can use `ifdef to bring them in and out.  But then, I may have half a dozen or more ILA's.  They'll likely all have the same clock.  I'd like the capture to be synchronized.  Is there any way to cause these to coalesce into the same ILA?  This would keep the captures synchronized by definition.  Otherwise I'll have to work out some sophisticated multiple module triggering network.

  4. Note, my build finished.  I programmed my target.  I refreshed the target.  I didn't see my ILA.  I had instantiated a single ILA. That's all that UT908 page 45 implied that I need to do. I did NOT explicitly create a "dbg_hub" that I see in the hardware manager as being hiearchically on top of the ILA after using "Set Up Debug", which I'm not doing in this self instantiation case.  So what was I missing on this manual instantiation of the ILA core?

Thanks again,

Helmut

Voyager
Posts: 327
Registered: ‎02-12-2013

Re: Vivado 2017.1 Logic Analyzer persnickety

Helmut,

 

I'm sorry that the hierarchical signal technique doesn't work in synthesis.  You have a lot of things going on at the same time but I can make some comments. 

 

1. ILA uses an ltx file to pass signal names to the hardware manager.  This is much richer than the ISA way.  It might provide textual enum display.  I have not tried it.

 

2. The main reason form multiple probes is to separate signals used for trigger and capture qualification from just data.  For example, the control lines could go into a probe set for DATA and TRIGGER but the wide data busses could be wired to a probe set to just DATA.

 

3. This is another reason I like ILA core instantiation directly in my source code.  If you put it in your HDL the names are shown correctly.  The mark debug, ILA core insertion technique often results in signal name scrambling (unless this has been fixed).

 

4. You shouldn't have to mess with the dbg_hub or anything like that.  Note if the clock connected to the ILA is not running the core will not be detected by the hardware manager.  This is a difference from ISE.

 

I strongly recommend that you try instantiating a single ILA core somewhere in your code.  Make sure the clock to it is running. Try it and you will like it.

 

Many differences between ISE and Vivado seem arbitrary or even backwards but the new Vivado ILA is a big, forward thinking improvement.

 

Good luck.