Frequently Asked Questions

Tools Issues

The compilation process pauses for a long time while generating the pad report file

The tools run faster if you copy your project to a local disk (e.g. E:) instead of using a network drive.

iMPACT reports an error about an invalid SDR format and then crashes.

The .bit file generated for your device was probably truncated due to a lack of disk space. Use the E: drive, not C:.

When I add designs to a CF card using iMPACT, the designs that were already on the card no longer work.

When you add designs to a card, iMPACT overwrites the xilinx.sys file in the root directory of the CF card. The new xilinx.sys file only points to the designs that you just added to the card, so the SystemACE chip on the labkit can no longer find the older designs. There are a couple of solutions:

• When you set up things in iMPACT, add all of your old design files.
• Edit the new xilinx.sys file to point to the directories containing your old designs. (Although Windows is unhappy opening a .sys file, xilinx.sys is actually just a text file.
• Create the .ace files using iMPACT, but manually copy them to your card, and manually write the xilinx.sys file. The SystemACE controller datasheet describes how the controller finds design files on the CF card.

The red "error" LED comes on and the FPGA fails to configure itself from a CF card

The CF card is probably corrupted and needs to be reformatted. Be sure to format it as FAT16 (not FAT32). The machines in lab will not, unfortunately, let you reformat a drive.

Persistent corruption: talk to Nathan, who will tell you to run
mkdosfs -v -F 16 -R 1 -s 4 g:

When I try to launch a ModelSim simulation from Project Navigator I get errors that libraries can't be found.

Be sure to add the following libraries in your ModelSim project with the following commands and try again.

vmap unisims_ver S:/6.111/Modeltech/xilinx/unisims_ver
vmap xilinxcorelib_ver S:/6.111/Modeltech/xilinx/XilinxCoreLib_ver
vmap simprims_ver S:/6.111/Modeltech/xilinx/simprims_ver


Loading a .coe file while generating a large CoreGen memory takes a really long time (20 mins for a 55K memory).

The workaround during the debugging phase is to generate the memory of the desired size without the initialization file then replace the .mif that CoreGen generates with the correct initialization values. The .mif files is a text file with the raw memory values (1 per line) in binary format starting at location 0 to Depth-1. The MSB is the leftmost binary digit.

When compiling/mapping a design in ISE, I get the message "Symbol 'foo' is not supported in target 'virtex2'."

The most likely cause for this error is that there is a coding bug that causes modules that use 'foo' to be optimized away. Look at the detailed error listing for a module that maps to zero logic to determine the error.

ZBT Memories

Problems using the supplied DLL code (raclock.v)

The ref_clock input must be driven by an external signal (e.g. clock_27mhz) and no other logic may be driven by that signal (use the fpga_clock output to drive your logic in the FPGA). This is because ramclock.v instantiates a clock input buffer on ref_clock, and hardware constraints in the FPGA dictate that the input to this buffer must come directly from an i/o pin. The clock_feedback_in signal also drives a clock input buffer, and is similarly constrained.

The ram0_clock, ram1_clock, and clock_feedback_out signals are driven by flip-flops integrated into the i/o drivers, so these signals must be connected directly to the i/o pins on the FPGA, and cannot be read by any other logic.