Tips on Using the Xilinx Design Tools

The Xilinx tools have certain quirks that can make them difficult to use at times. You can avoid some of these problems by following a few simple guidelines and knowing where the problems lie. We have listed the known problems, and, where possible, we give some ideas for avoiding or fixing them. If you have any other tips, please mail them to us and we will add them to this list.

General Tips:

• If things happen that you don't understand, first try quitting Foundation and restarting. This often seems to fix things because the tools have to reload the database. You might also try changing computers in case something has messed up the local environment.
• When you save your project on a network drive (you must do this), Foundation will sometimes not keep information about the project up to date. The fix is to restart the Xilinx Foundation tools.
• Don't save your project anywhere in your user profile (this includes the Windows desktop!). Instead, save your projects in your home directory or group directory.
• When you copy a project, don't give it a new name.  If you do want to use a new name, then delete the implementation data first, and don't rely on versions and revisions. In fact, we never use versions and revisions because of this - we create our own using new projects and this seems to work just fine.  (Xilinx: When copying a project in Foundation, you must copy it to the same name as the original in order for the design implementation versions and revisions contained within the Xilinx project (XPROJ) to be copied as well.  The new copy of the project will be in another directory location than the first, but the name must remain the same in order for the Xilinx project to be copied. The Xilinx project, contained within the Foundation project, contains the implementation versions and revisions. If you do not care to copy the Xilinx project information to the new project, then you may ignore this warning.  In this case, your design implementation versions from the original project will not be present in the new project.)
• Make sure your project is set up to implement using the XC-4010XL-PC84 part. To do this, you will probably have to change your project type to XC-4000XL using the Project Type command in the File menu. Using the wrong part number can cause strange problems to appear (such as the mysterious "Cannot read pin descriptors for: EQN" error).
• Make sure the clock on your machine is (close to) correct. If the file server clock is very different from your local clock, the tools get confused about what needs to be done. For example, if the local clock is slow, then it appears that the file server files are always out of date, i.e. too new.

Naming Issues:

• Don't use case-sensitivity to differentiate names in your design. In other words, assume names are case IN-sensitive.
• When giving names to files or directories, pretend you're still using MS-DOS. That is, don't use spaces in any folder or file names. Also, make sure names of files and directories aren't too long (use the old 8.3 filename format). Some of the tools can't handle filenames/paths that don't follow these guidelines.  (Xilinx:  Warning: Your directory path <directory_path> should not contain any directory names longer than 8 characters)
• Don't name any macros with the same name as the project name, especially Verilog macros. Otherwise "bad things" can happen.

Misc. Error and Warning Messages:

• The message saying that some macros are not updated is most annoying. Go to the project window to find out which macros they mean. If it's a LogiBlox macro, you can double click on the macro and rerun LogiBlox. But make sure that it has the parameters right! It will often replace the bus size for example. If it's a Verilog macro, then go to the project window, choose the synthesis tab and click the Update button to update changed macros.

Tool-Specific Issues:

Schematic Editor:

• Unconnected wires are a common problem. Although it may appear that a wire connects two components in the schematic editor, it is very possible they won't actually be connected. To check connections, you can use the "Query" command (Mode menu or Query button) and click wires and macros. You can also click and drag a symbol, making sure the wires follow. Or finally, if you get really frustrated with wiring issues, you might want to turn off auto-wiring by going to View->Preferences->Wires and Buses, and unmarking the Autowiring box.
• The "Integrity Test" command is sometimes useful in uncovering unconnected pins, pins driven from by multiple sources, and other hard-to-find errors. If you're getting an error message when simulating or implementing your design, this is one of the first things you should try.
• The schematic editor is a little indecisive about how it treats terminal directions. Specifically, if you have an output wire in your schematic, and it ends in a terminal, but you accidently put an input terminal on this output wire, there will not be an error. Furthermore, the tools seem to still treat that terminal as an output (regardless of the terminal direction). But be aware that this bug may cause unknown problems, so you'll probably want to try to avoid it.
• If the schematic editor won't let you attach a bus to a bus pin on a block symbol, it may be because of an error in the block's Verilog code. (See the Verilog section of this document for more details).
• Sometimes you may want to re-use a component from one project in another project. But even after you add a particular schematic to your project, that component won't show up in your list of symbols until you create a macro out of it. To do this, you need to open that schematic in the schematic editor, and then select "Hierarchy -> Create Macro Symbol From Current Sheet". You will then be able to use this component as a block symbol in your other schematics.
•  Don't use Vdd/GND symbols in the schematic editor

 Verilog Editor:

• If an input is never used or can be simplified away then updating the macro will remove those pins. (Xilinx says this is intentional, so we can forget them trying to fix this.)  So if you have something like:

always @(inp)
    if (inp) outp = 0;
    else     outp = 0;

then inp will be removed (and outp will be constant). In real situations it may be much more subtle than this example. An output will be removed if you never assign to it. We don't know of a simple way to force it to keep pins. If you are not done with your Verilog code but you want to try synthesising then you should probably answer no when it asks if it should update the macro library.
• If a signal in a bus which is on a pin can be simplified away, then you will get an error when implementing which says that the signal can't be found.  There is currently no workaround for this problem, although Xilinx says that they are fixing it.
• The Verilog compiler will warn you if you mismatch the number of bits you type with the size of the field, but it won't tell you if a value is the wrong size for a bus. For instance, if you have a "reg [2:0] myReg" and somewhere type "myReg = 8'b01010101", the Verilog compiler will accept it without issuing a warning. Results are unpredicatable.
• Another bug it doesn't report is if you have an output bus defined as a different width than the associated reg. For example:

output [7:0] foo;
reg foo;

This will not generate a compile error. As a result of this bug, when you use this macro in the Schematic Editor it won't let you attach a bus to this pin (even though the block symbol will show a place for connecting a bus).
 

 Simulator:

• If you try to place a simulator probe on your schematic, it may disappear once you re-start you simulation script. To avoid this, you need to do two things:
1. After adding the probes, select "Update Simulation" in the schematic editor
2. Make sure you comment-out the "delete_signals" line in your script (if there is one)
Then run the simulation, and things should work fine.
• When using a 'vector', you must put more than one signal in the vector, or else you won't be able to use 'check' statements on that vector.

 Script Editor:

• When you want to make a new script file, it's fine to open an old one from another project and edit it. But make sure you Save As and save it to the current directory. It will use a file name that will change the original file - retype the file name instead.

 Implementation:

• Sometimes implementation will fail, giving the message "Unable to export EDIF netlist". This problem occurs because the local workstation clock is different from the server clock and so the "makefile" analysis is wrong.  Since you can't fix the clock, the solution is to just wait the difference between the clocks.  And tell support about the problem so they can fix the clock.
• If the tools tell you they're "unable to resolve all placement constraints", it may mean that you've assigned the same pin number to more than one pad.

Logic Analyzer Tips: