Chipscope - pleasantly surprised

I have been using Chipscope since I started working with Xilinx FPGAs a few months back. At first I was very disappointed by it's inability to detect custom types and state machines. I think it would be nice if they could find a way of adding this feature, but all in all I have become very satisfied with it's performance and abilities.

Caveat: If you change the signals from Inserter then it's worthwhile creating a new Analyzer project instead of letting Chipscope detect and try to deal with the changes. That has never worked well for me.

Chipscope is Xilinx's attempt to build a true logic analyzer. They avoided trying to delve too deep into what your project was about (ie they don't learn custom types or even buses), and instead they work generically with the project and this allows Chipscope to be very stable.

The analyzer allows you to import the signal names from the Inserter project. The names could've been inserted automatically but that would have required some form of matching scheme to know that the FPGA is compiled with specific signal information.

Background comparison of alternate FPGA logic analyzer:
Lattice's Reveal:
Reveal allows you to do the same basic things as chipscope. One main difference is that Reveal will learn the types you are adding in it's inserter, and it's analyzer will automatically detect those types and states. This allows Reveal's analyzer to automatically build buses, and support state machines, and even show state names in the logic window. There are numerous disadvantages to this scheme. Reveal doesn't support all types of signals. For example integers, and custom types other than state machines aren't supported from what I've seen. Those signals are kept grey within the Inserter program. Another major issue is that Reveal needs to use some form of matching scheme between the compiled core and the inserter project used to create it. If Reveal detects that there isn't a match then it won't open the core for analysis at all. This can easily happen if I add a single signal to the end of the data list and then I want to analyze both the new compiled FPGA and the old one. The old compiled FPGA will no longer be able to be analyzed without the old Reveal project files which match it.

Back to Xilinx:
Chipscope allows you to add every signal that exists in the design, regardless of how it is created. It is listed in XST format so that multi-dimensional buses become signal_0_0 and signal_0_1 and so on. At least this way I can add them, and I can create the buses properly within Chipscope Analyzer. Regarding bus-creation I find that Chipscope 11.1 has a huge advantage over previous versions with it's Auto Create Buses option. It builds buses based on their names. If it builds it incorrectly then of course the bus can be recreated properly, but I have yet to see it build a bus incorrectly. It doesn't yet manage to build bus arrays so build them myself. The biggest set-back is it's lack of support for simple state machine's, but Chipscope does have a good way of working around this. You need to use token files. If you give your state machine's set values for their states then you can use a token file to tell the Analyzer what each state's value means, and to display it with the token (ie name) in the logic window.

Chipscope has all the basic support like many other analyzers, plus some nice advanced ones. It supports multiple analysis cores, multiple match units, triggers, sequencers, counters, and many other functions. Although what makes it stand out beyond Lattice's Reveal is it's ability to store information based on a match unit, and display it only after a distant trigger. This is a very useful function. I have just recently used this to great success in debugging what turns out to be an XST compiler issue (that's discussed in my post about for-loop and exit support). I triggered 65000 clocks in the future but still had the information I needed to debug the issue.

Nice job Chipscope team - keep up the great work!

ISE 11.1 stability issues

I have been using ISE 11.1 for about a month now. There are numerous stability issues from crashes and freezes to messages no longer being updated in the Design Report view. I find that running Rerun All is always a crap shoot as it brings ISE down much of the time. I have gotten coregen to freeze on occasion when invoking it within the ISE project. ISE's tracking of source file states and build states is hit or miss. Sometimes it decides that Synthesis isn't up to date, but shockingly Map and P&R are. I change source files and it's completely unwilling to restart the process of compilation. This requires the infamous Rerun or Rerun All commands. Then it has those times when the compilation just won't work unless you "Cleanup Project Files" and then try again. I know that there are lots of temporary files being used during FPGA synthesis, and plenty of intermediate files created, but is it so difficult to check the state of the source files and if one has been updated recently to set build state back to zero?

These issues only strengthen the argument against ISE keeping an open handle to its configured external editor. See my post on problems when using an external editor from ISE.

Seems to me that Xilinx needs their GUI team updated.

Xilinx XST for loop and disable keyword support

Xilinx once again fails bady when it comes to quality of tool issues. Recently I converted my PCI Express block from static to parametrized. This required lots arrays and multi-dimensional arrays, lots of parameters, and plenty of assign statements to take arrays out of and into modules (since module ports don't support multi-dimensional arrays). I implemented plenty of generate statements for conditional instantiation of FIFOs and also for loops for conditional processing of blocks.

The language specific way of breaking out of loops in Verilog is by using the "disable" statement. Sadly XST 11.1 doesn't support the disable statement from within a "for loop". The recommended workaround as shown in AR #22177 is to increment the "for loop" iterator to it's exit value. This works some of the time, and doesn't work other times. I stronly recommend against doing this as it clear to me that support for exiting a for loop early is shaky at best. I found that using a while statement with manual iteration worked better. I set the iterator to the exit value and it actually exited the loop properly.

Hoping that your experience is better than mine,

Xilinx ISE using an external editor (not a good idea)

I like to use GViM for editing files in Windows. Given that ISE supports using an external editor I immediately went about setting it to use my preferred editor. What I discovered with ISE 10.1 was that ISE keeps an open handle to the editor when editing files. This is stupid! The issue is very problematic because ISE has a tendency to crash, and with an open handle to the editor, it brings the editor down with it (at least with gvim.exe). ISE 11.1 was recently released and sadly it has the same issue. The CR (Change Request) I got filed with Xilinx to fix it will only be done with ISE 12.1. What I do for now is open gvim outside of ISE, and then double clicks in ISE will open in the same gvim that I'm using without having that handle connecting gvim's existence with that of ISE.

ISE crashes - gvim lives :)

This relates to my post about ISE stability issues.