fpga4fun.com

I thought it might be helpful to others to post a few of the "gotchas" to look out for when using the great ISE tools from Xilinx. For the most part, ISE is an amazing tool, but there are a few things I found that threw me for a loop.

1) After making too many changes to your UCF file, ISE sometimes "remembers" old pins that no longer exist. Go to "project" and select "cleanup project files" to instantly solve this problem. This also seems to work for a few other bugs when cutting and pasting code blocks.

2) Nesting too many "If Then" statements can sometimes make the compiler gobble up all of your system ram and then chug for 10-15 minutes on a compile. By removing only a single level of nested "If Then" statements, this error can instantly disappear. On several projects, I reduced system ram usage from 2GB (all available) down to 200MB by just taking away a single level! Compile time also went from 10-15 minutes to under a minute.

3) When using large arrays such as "reg [7:0] palette[255:0];", ISE will sometimes make a block ram as intended, and other times, it will decide that 2048 flip flops is a swell idea. There is no rhyme or reason to this, and often a recompile without any code changes will make it decide differently. Sometimes using the initial begin to put a start value in the array will help, but be prepared for the "random factor here".

4) Once and a while you may have an "ahah..." moment after starting a compile, but the "stop" command will cause a crash about 1 out of 10 times, so beware! I just wait now.

Other than those few gotchas, I have found the ISE software to be top notch, and very easy to work with.

Brad

Here is the error you will see if you have to many "If Then" statements in ISE (any version)...

ERROR:Portability:3 - This Xilinx application has run out of memory or has encountered a memory conflict. Current memory usage is 2090552 kb. You can try increasing your system's physical or virtual memory. For technical support on this issue, please open a WebCase with this project attached at http://www.xilinx.com/support.

I just generated this code by adding one single "If Then" around a block of code that had 3 "If Then" statements in it already.

So to fix this "crash" I had to take something that looked like this...

if (a == b) then
// some code
if (c == d) then
// some code
end
if (e == f) then
// some code
end
if (g == h) then
// some code
end
end

and turn it into this...


if (c == d & a == b) then
// some code
end
if (e == f& a == b) then
// some code
end
if (g == h& a == b) then
// some code
end

Seriously!

That makes "Current memory usage is 2090552" drop to 10 times less and the error goes away. The code is basically the same thing.

This happens on versions from 8 to 10, but I have not had earlier versions.

Just thought I would point that out in case someone else here receives a smack in the head by the infamous "ERROR:Portability:3" error.

Xilinx does make a note of this problem, but I can't see why it is left in the software, when it is such a simple bug to fix...

http://www.xilinx.com/support/answers/15336.htm

Brad

Just found another "odd" error message today...

WARNING:HDLCompilers:217 - "SyncGen.v" line 1622 Integer constant '2147483648' is too large to represent in 32 bits.

Now unless my binary calculator is on the fritz, 32 bits can hold a value from 0 to 4294967295, so the number it is complaining about is only half the size.

I am not sure about this one yet, so I will dig in and report back.

A day typically = 25% coding, 25% human error, and 50% software craziness.

Brad

Integer type in verilog is a signed 32-bit type, so it can represent 4294967296 different values but not the value 4294967295. Try making the signal unsigned and it should work.

very nice infooo...


ISE

Version 12.1 Report...

So far many bugs have vanished with version 12.1 of ISE. You can actually stop a compile when you have an "aha!" moment without a crash.

Old UCF pin assignments are not ghosted as much. although you still have to run "cleanup project files" once and a while for some mysterious reason.

The issue with running out of PC memory when using nested IF THEN statements has been fixed as well, or at least enough that my old code can now compile without resorting to stupid syntax tricks.

About the only issue left is this inherent random behavior when using block ram. I have worked on several projects where one day the ram synthesizes as dual port and then a week later ISE makes the decision for you that 8192 flip flops is a better idea then bangs away for 30 minutes trying to make them all.

For instance, during one compile today, I was told...

Code: Select all

HDL ADVISOR - 3200 flip-flops were inferred for signal <linemem>. You may be trying to describe a RAM in a way that is incompatible with block and distributed RAM resources available on Xilinx devices, or with a specific template that is not supported.


To fix this bizarre bug, I usually REM(/*) out random blocks of code and keep trying to compile until it goes back to block ram. I then unREM the code and all is well for days. I do not have to actually change the code!

So as a sanity check, I copied only the .V and .UCF files to another PC running the exact same software and I ended up with the expected block RAM. So I began the ridiculous effort of REMming out random lines of code and retrying compile until block RAM was once again a "good idea" to ISE. Again, making absolutely no code changes!!...

Code: Select all

Synthesizing (advanced) Unit <syncgen>.
INFO:Xst:3031 - HDL ADVISOR - The RAM <Mram_linemem> will be implemented on LUTs either because you have described an asynchronous read or because of currently unsupported block RAM features. If you have described an asynchronous read, making it synchronous would allow you to take advantage of available block RAM resources, for optimized device usage and improved timings. Please refer to your documentation for coding guidelines.
    -----------------------------------------------------------------------
    | ram_type           | Distributed                         |          |
    -----------------------------------------------------------------------
    | Port A                                                              |
    |     aspect ratio   | 400-word x 8-bit                    |          |
    |     clkA           | connected to signal <clk>           | rise     |
    |     weA            | connected to signal <_and0000_0>    | high     |
    |     addrA          | connected to internal node          |          |
    |     diA            | connected to signal <viddat>        |          |
    -----------------------------------------------------------------------
    | Port B                                                              |
    |     aspect ratio   | 400-word x 8-bit                    |          |
    |     addrB          | connected to signal <hcount>        |          |
    |     doB            | connected to internal node          |          |
    -----------------------------------------------------------------------
Unit <syncgen> synthesized (advanced).


So don't always believe the errors that you are thrown!

There are a few other quirks that are not issues with code, but I will say that 12.1 is certainly much better!

Brad