Author: Scott Gravenhorst
Some frustrations encountered using WebPACK ISE...
When things were going just dandy and all of a sudden, new projects just won't work:
This applies to Spartan-3E Starter Kit and WebPACK ISE:
Somehow, the project settings for new projects got messed up. I created a new project and when I tried to compile it, I got very weird errors, errors that made no sense. After 3.5 hours of screwing with it (creating several new projects from known working source files), I finally noticed when I started yet another new project experiment that the target device type was incorrect. Then it took a while to discover how to change the target device (and package type, speed grade, etc.) so that it is a Spartan-3E, FG320, -4, etc.
You do this by looking in the upper left corner window that shows the component tree. The second line should say: xc3s500e-4fg320. If it doesn't, you have the wrong device selected (please note the first line of this post). Click on the second line (whatever it says) and then right click and select properties. Change to Spartan3e, XC3S500E, FG320 and -4. That fixed the problem and now I know what that second line in that window is for.
Particular attention must be paid to this if you develop for more than one device using ISE, always make sure the correct device is selected.
A strange thing happened to me yesterday. While editing a project that had been working, all of a sudden, Webpack ISE would no longer compile this project (I checked, other projects would compile), claiming "Map failed". The output window suggested that I look at project.map.mpr for details. Since the error box was empty (indeed the summary also said zero errors), I looked and found only the usual warnings and no errors. After attempting to reverse the last changes I had made to no avail, I decided to do what I thought was drastic - I closed Webpack ISE, made a backup copy of the project and then deleted all of the ISE created folders and files, all that was left were my source files. I also deleted the project.ise project file. I then opened Webpack ISE and recreated the project from scratch, adding the source files. To my utter amazement, the same files which would not compile in the original project now compiled and worked. This may not be the only way to fix this kind of problem, but it worked for me. Your milage may vary.
Sometimes ISE will get confused when it's been used to compile a design several or many times. Often using the Project menu's "Cleanup Project Files" can help. This action deletes the generated internal temp and report files. The design will then be forced to rerun all parts of the compile which can often eliminate errors.
Version 10.1 can also fail to compile a project that has no problem with it's source code. I've noticed that if I exit ISE and restart it, the project will compile.
WebPACK ISE Crashes:
When ISE crashes, it is a good idea to use the task manager to make sure that _pn.exe has exited the system. The stuck ISE process seems to be able to cause problems with a new one started. I've seen it get stuck where it displays a panic dialog, but refuses to finish it's exit. You can force it to exit using task manager.
WebPACK ISE Warnings:
ISE can generate a large number of warnings, so it can be difficult to tell if specific warnings are an indication of a problem or if they can be ignored. ISE makes message filtering available, but depending on what messages and message types you filter out, you may be allowing a problem to successfully hide. It's always a good idea to understand why each of the warnings are present and make a decision as to whether it affects your design or not.
To the end of easier problem location, I've developed some bash shell scripts (I use Windows for compiling, but the projects are stored on a Samba share on a Linux server) to parse the report files looking for specific phrases. For example, I like to know when one or more states in a state machine can never be accessed due to a coding error. This is noted in the warnings (I think this should be flagged as an error...), but there are usually so many that it may be difficult to spot. The scripts make this much easier. For users with only Windows, you could use batch files or other methods such as BASIC or VB to parse through the warnings.
The use of these scripts does not eliminate the need to peruse the warnings, just that glaring problems such as the one I just described are immediately obvious.
Specifically, several things my scripts look for:
- Inaccessible states in a state machine.
- Arrays which can be accessed beyond their size (RAM address supplied to the RAM has too many bits for the size of the RAM).
- Arrays for which not all elements can be accessed (RAM address supplied to the RAM has too few bits for the size of the RAM).
- Large fanout.