Webpack ISE

FPGASynth.WebpackISE History

Hide minor edits - Show changes to markup

July 29, 2008, at 02:51 PM by 71.189.44.199 -
Changed lines 45-60 from:

When ISE crashes, it is a good idea to use the task manager to make sure that _pn.exe has exited the system. 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.

to:

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.
July 29, 2008, at 02:37 PM by 71.189.44.199 -
Added line 30:
Added line 37:
Added line 44:
July 29, 2008, at 02:36 PM by 71.189.44.199 -
Changed lines 3-6 from:

Some frustrations encountered using Webpack ISE...

Webpack ISE:

to:

Some frustrations encountered using WebPACK ISE...

WebPACK ISE:

Changed lines 9-16 from:

This applies to Spartan-3E Starter Kit and Webpack ISE:

The good part is that I figured out what was messed up and fixed it. The bad part is it sucked up 3.5 hours today AND I don't know how it happened. Maybe it's my old brain, I thought that I set this default when I installed the software, however, as I said, my brain is old and apparently befuddled.

to:

This applies to Spartan-3E Starter Kit and WebPACK ISE:

Added lines 27-28:

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.

July 29, 2008, at 02:35 PM by 71.189.44.199 -
Changed lines 3-4 from:

Some frustrations encountered using Webpack ISE and KCPSM3...

to:

Some frustrations encountered using Webpack ISE...

July 29, 2008, at 02:35 PM by 71.189.44.199 -
Changed lines 34-35 from:

Webpack ISE:

to:

WebPACK ISE:

Changed lines 38-42 from:

KCPSM3:

Here are a few tidbits regarding KCPSM3.exe, the free assembler for the PicoBlaze soft microcontroller.

I use a Linux server running Samba because it gets backed up automatically, so I have a directory where I like to keep my Spartan-3E Starter Kit projects. Note that some or all of my problems may be due to using Samba instead of a local volume on my Windows 2000 machine. That said, I've noticed that when I first open a command prompt window, CD to the mapped drive location of a project that needs the compiler, the compiler will fail the first time I execute it with "Access Denied". If I simply execute it again, it works and continues to work for the rest of the session. I noticed that the default directory changes magically to the 8.3 DOS filename format, so it may be that KCPSM3.exe was compiled using something very old that doesn't like long filenames. I also found that if the filename of the PSM file is long format, it won't assemble, even if the 8.3 version of the name is used. For now until someone discovers a solution for this, I will start naming my PSM files as 8.3. This presents a small problem because the the name of the file determines the name given to the module by the assembler. I know it's klunky, but being aware of this, you should be able to make it work.

to:

WebPACK ISE: 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.

Changed lines 44-50 from:

Webpack ISE:

It is possible for Webpack ISE to screw up the configuration of source files in a working project, rendering it useless. This can cause the design to appear to compile, but the manifestation of changes may not be apparent. This happened to me with a PicoBlaze design in which the PicoBlaze assembler's output file (a Verilog file) became disassociated from the project is a strange way. Looking at the top left window, I saw that the module was declared, but the icon was a question mark and there was no file name associated with the module. Whatever causes this pretty much invalidates the project, I could neither remove the source file (there was no source file association!), nor could I add it (Webpack claimed it was already added!). I tried restarting Webpack to no avail. The only way I could fix the problem was to delete all files but the necessary source files and recreate the project. The moral of this story is, that one should occasionally look at the top left window to make sure things look right, especially if you're having problems where changes you make to the code (in my case, it was changes made to assembly language source and reassembly) don't seem to affect what the design does.


Webpack ISE:

I've discovered yet a problem that can be avoided and had I known what I just now learned... anyway, I am working on a design that needs troubleshooting. So today I thought it would be good to give the simulator a try. I found a nice Xilinx tutorial and began to follow it. Everything worked until I actually wanted to run a simulation (on a simple and gate project that is part of the tutorial) and I got a 222 error. At the end of the tutorial, there is a note about 222. The note indicates the WebPack can have problems if there are spaces in the project path OR in the application's install path. Well, I had BOTH. So now I have to yank out ISE and reinstall it. It is best to leave the installation path to default, i.e., c:\xilinx\

to:

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. 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.

November 15, 2006, at 03:24 PM by 63.138.50.162 -
Added line 49:
November 15, 2006, at 03:23 PM by 63.138.50.162 -
Changed lines 46-49 from:

It is possible for Webpack ISE to screw up the configuration of source files in a working project, rendering it useless. This can cause the design to appear to compile, but the manifestation of changes may not be apparent. This happened to me with a PicoBlaze design in which the PicoBlaze assembler's output file (a Verilog file) became disassociated from the project is a strange way. Looking at the top left window, I saw that the module was declared, but the icon was a question mark and there was no file name associated with the module. Whatever causes this pretty much invalidates the project, I could neither remove the source file (there was no source file association!), nor could I add it (Webpack claimed it was already added!). I tried restarting Webpack to no avail. The only way I could fix the problem was to delete all files but the necessary source files and recreate the project. The moral of this story is, that one should occasionally look at the top left window to make sure things look right, especially if you're having problems where changes you make to the code (in my case, it was changes made to assembly language source and reassembly) don't seem to affect what the design does.

to:

It is possible for Webpack ISE to screw up the configuration of source files in a working project, rendering it useless. This can cause the design to appear to compile, but the manifestation of changes may not be apparent. This happened to me with a PicoBlaze design in which the PicoBlaze assembler's output file (a Verilog file) became disassociated from the project is a strange way. Looking at the top left window, I saw that the module was declared, but the icon was a question mark and there was no file name associated with the module. Whatever causes this pretty much invalidates the project, I could neither remove the source file (there was no source file association!), nor could I add it (Webpack claimed it was already added!). I tried restarting Webpack to no avail. The only way I could fix the problem was to delete all files but the necessary source files and recreate the project. The moral of this story is, that one should occasionally look at the top left window to make sure things look right, especially if you're having problems where changes you make to the code (in my case, it was changes made to assembly language source and reassembly) don't seem to affect what the design does.


Webpack ISE: I've discovered yet a problem that can be avoided and had I known what I just now learned... anyway, I am working on a design that needs troubleshooting. So today I thought it would be good to give the simulator a try. I found a nice Xilinx tutorial and began to follow it. Everything worked until I actually wanted to run a simulation (on a simple and gate project that is part of the tutorial) and I got a 222 error. At the end of the tutorial, there is a note about 222. The note indicates the WebPack can have problems if there are spaces in the project path OR in the application's install path. Well, I had BOTH. So now I have to yank out ISE and reinstall it. It is best to leave the installation path to default, i.e., c:\xilinx\

July 13, 2006, at 11:50 AM by Scott Gravenhorst -
Changed line 42 from:

I use a Linux server running Samba because it gets backed up automatically, so I have a directory where I like to keep my Spartan-3E Start Kit projects. Note that some or all of my problems may be due to using Samba instead of a local volume on my Windows 2000 machine. That said, I've noticed that when I first open a command prompt window, CD to the mapped drive location of a project that needs the compiler, the compiler will fail the first time I execute it with "Access Denied". If I simply execute it again, it works and continues to work for the rest of the session. I noticed that the default directory changes magically to the 8.3 DOS filename format, so it may be that KCPSM3.exe was compiled using something very old that doesn't like long filenames. I also found that if the filename of the PSM file is long format, it won't assemble, even if the 8.3 version of the name is used. For now until someone discovers a solution for this, I will start naming my PSM files as 8.3. This presents a small problem because the the name of the file determines the name given to the module by the assembler. I know it's klunky, but being aware of this, you should be able to make it work.

to:

I use a Linux server running Samba because it gets backed up automatically, so I have a directory where I like to keep my Spartan-3E Starter Kit projects. Note that some or all of my problems may be due to using Samba instead of a local volume on my Windows 2000 machine. That said, I've noticed that when I first open a command prompt window, CD to the mapped drive location of a project that needs the compiler, the compiler will fail the first time I execute it with "Access Denied". If I simply execute it again, it works and continues to work for the rest of the session. I noticed that the default directory changes magically to the 8.3 DOS filename format, so it may be that KCPSM3.exe was compiled using something very old that doesn't like long filenames. I also found that if the filename of the PSM file is long format, it won't assemble, even if the 8.3 version of the name is used. For now until someone discovers a solution for this, I will start naming my PSM files as 8.3. This presents a small problem because the the name of the file determines the name given to the module by the assembler. I know it's klunky, but being aware of this, you should be able to make it work.

July 12, 2006, at 11:31 PM by Scott Gravenhorst -
Changed line 46 from:

It is possible for Webpack ISE to screw up the configuration of source files in a working project, rendering it useless. This can cause the design to appear to compile, but the manifestation of changes may not be apparent. This happened to me with a PicoBlaze design in which the PicoBlaze assembler's output file (a Verilog file) became disassociated from the project is a strange way. Looking at the top left window, I saw the module that was declared, but the icon was a question mark and there was no file name associated with the module. Whatever causes this pretty much invalidates the project, I could neither remove the source file (there was no source file association!), nor could I add it (Webpack claimed it was already added!). I tried restarting Webpack to no avail. The only way I could fix the problem was to delete all files but the necessary source files and recreate the project. The moral of this story is, that one should occasionally look at the top left window to make sure things look right, especially if you're having problems where changes you make to the code (in my case, it was changes made to assembly language source and reassembly) don't seem to affect what the design does.

to:

It is possible for Webpack ISE to screw up the configuration of source files in a working project, rendering it useless. This can cause the design to appear to compile, but the manifestation of changes may not be apparent. This happened to me with a PicoBlaze design in which the PicoBlaze assembler's output file (a Verilog file) became disassociated from the project is a strange way. Looking at the top left window, I saw that the module was declared, but the icon was a question mark and there was no file name associated with the module. Whatever causes this pretty much invalidates the project, I could neither remove the source file (there was no source file association!), nor could I add it (Webpack claimed it was already added!). I tried restarting Webpack to no avail. The only way I could fix the problem was to delete all files but the necessary source files and recreate the project. The moral of this story is, that one should occasionally look at the top left window to make sure things look right, especially if you're having problems where changes you make to the code (in my case, it was changes made to assembly language source and reassembly) don't seem to affect what the design does.

July 12, 2006, at 11:30 PM by Scott Gravenhorst - add 4th section
Added lines 43-46:

Webpack ISE:

It is possible for Webpack ISE to screw up the configuration of source files in a working project, rendering it useless. This can cause the design to appear to compile, but the manifestation of changes may not be apparent. This happened to me with a PicoBlaze design in which the PicoBlaze assembler's output file (a Verilog file) became disassociated from the project is a strange way. Looking at the top left window, I saw the module that was declared, but the icon was a question mark and there was no file name associated with the module. Whatever causes this pretty much invalidates the project, I could neither remove the source file (there was no source file association!), nor could I add it (Webpack claimed it was already added!). I tried restarting Webpack to no avail. The only way I could fix the problem was to delete all files but the necessary source files and recreate the project. The moral of this story is, that one should occasionally look at the top left window to make sure things look right, especially if you're having problems where changes you make to the code (in my case, it was changes made to assembly language source and reassembly) don't seem to affect what the design does.

July 10, 2006, at 02:06 PM by Scott Gravenhorst - Addition of middle section
July 10, 2006, at 02:03 PM by 207.178.213.66 -
Changed line 36 from:

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, 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.

to:

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.

July 10, 2006, at 02:02 PM by 207.178.213.66 -
Added line 6:
Added line 35:
Added line 39:
July 10, 2006, at 02:02 PM by 207.178.213.66 -
Changed lines 3-4 from:

Some frustrations encountered using Webpack ISE...

to:

Some frustrations encountered using Webpack ISE and KCPSM3...

Webpack ISE:

Added lines 33-35:

Webpack ISE: 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, 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.


July 09, 2006, at 03:57 PM by 71.160.203.135 -
Changed lines 1-2 from:

Author: Profiles

to:
July 09, 2006, at 03:57 PM by 71.160.203.135 -
Changed lines 1-2 from:

Author: Scott Gravenhorst

to:

Author: Profiles

July 09, 2006, at 03:54 PM by 71.160.203.135 -
Changed line 31 from:
to:

July 09, 2006, at 03:53 PM by 71.160.203.135 -
Changed line 35 from:

I use a Linux server running Samba because it gets backed up automatically, so I have a directory where I like to keep my Spartan-3E Start Kit projects. I've noticed that when I first open a command prompt window, CD to the mapped drive location of a project that needs the compiler, the compiler will fail the first time I execute it with "Access Denied". If I simply execute it again, it works and continues to work for the rest of the session. I noticed that the default directory changes magically to the 8.3 DOS filename format, so it may be that KCPSM3.exe was compiled using something very old that doesn't like long filenames. I also found that if the filename of the PSM file is long format, it won't assemble, even if the 8.3 version of the name is used. For now until someone discovers a solution for this, I will start naming my PSM files as 8.3. This presents a small problem because the the name of the file determines the name given to the module by the assembler. I know it's klunky, but being aware of this, you should be able to make it work.

to:

I use a Linux server running Samba because it gets backed up automatically, so I have a directory where I like to keep my Spartan-3E Start Kit projects. Note that some or all of my problems may be due to using Samba instead of a local volume on my Windows 2000 machine. That said, I've noticed that when I first open a command prompt window, CD to the mapped drive location of a project that needs the compiler, the compiler will fail the first time I execute it with "Access Denied". If I simply execute it again, it works and continues to work for the rest of the session. I noticed that the default directory changes magically to the 8.3 DOS filename format, so it may be that KCPSM3.exe was compiled using something very old that doesn't like long filenames. I also found that if the filename of the PSM file is long format, it won't assemble, even if the 8.3 version of the name is used. For now until someone discovers a solution for this, I will start naming my PSM files as 8.3. This presents a small problem because the the name of the file determines the name given to the module by the assembler. I know it's klunky, but being aware of this, you should be able to make it work.

July 09, 2006, at 03:51 PM by 71.160.203.135 -
Added lines 31-35:

KCPSM3: Here are a few tidbits regarding KCPSM3.exe, the free assembler for the PicoBlaze soft microcontroller.

I use a Linux server running Samba because it gets backed up automatically, so I have a directory where I like to keep my Spartan-3E Start Kit projects. I've noticed that when I first open a command prompt window, CD to the mapped drive location of a project that needs the compiler, the compiler will fail the first time I execute it with "Access Denied". If I simply execute it again, it works and continues to work for the rest of the session. I noticed that the default directory changes magically to the 8.3 DOS filename format, so it may be that KCPSM3.exe was compiled using something very old that doesn't like long filenames. I also found that if the filename of the PSM file is long format, it won't assemble, even if the 8.3 version of the name is used. For now until someone discovers a solution for this, I will start naming my PSM files as 8.3. This presents a small problem because the the name of the file determines the name given to the module by the assembler. I know it's klunky, but being aware of this, you should be able to make it work.

July 09, 2006, at 03:43 PM by 71.160.203.135 -
Added lines 5-6:

When things were going just dandy and all of a sudden, new projects just won't work:

July 09, 2006, at 03:43 PM by 71.160.203.135 -
Changed lines 1-2 from:

Author: Profiles

to:

Author: Scott Gravenhorst

Some frustrations encountered using Webpack ISE...

July 09, 2006, at 03:41 PM by 71.160.203.135 -
Added lines 1-26:

Author: Profiles

This applies to Spartan-3E Starter Kit and Webpack ISE:

The good part is that I figured out what was messed up and fixed it. The bad part is it sucked up 3.5 hours today AND I don't know how it happened. Maybe it's my old brain, I thought that I set this default when I installed the software, however, as I said, my brain is old and apparently befuddled.

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.