Tips on Using the Xilinx Design Tools

Pay attention!!  This could save you a lot of time!!

The Xilinx Foundation tools are industrial-strength design tools that are sold by Xilinx for big bucks, but donated to UW so we can use them in our courses.  Used in the right way, they are very powerful and productive.  However, the Xilinx tools have certain quirks that can make them difficult to use at times, and if ignored will lead to hours, yea days, of frustration.  Fortunately, some of these problems can be avoided by following a few simple guidelines and knowing where the possible problems lie. On this page we will attempt to point out these problems, and where possible, give some ideas for avoiding or fixing them. If you come up with new tips, please mail them to us and we will add them to this list.  By the way, this page is written on the assumption that you will follow our advice.  Specifically, we don't talk about what to do with all the bad things that happen if you don't.

General Tips:

• Keep it simple and don't stray from straighforward, proven ways of doing things.  Don't expect the tools to do things the way you think they should be done.  Don't fight the tools, go with the flow.  The tools always win.
• The first thing you need to understand is that the tools are actually many different tools, including DOS programs, that are run by the Project Manager.  You will be safest if you stick to the 8.3 filename convention.  That is, short names, no funny characters.  Hey, I don't like it either. (As Xilinx says:  "Warning: Your directory path <directory_path> should not contain any directory names longer than 8 characters.")
• The second thing you need to understand is that the tools (can but) don't like being run on a network.  They expect that since you are rich enough to buy the tools you are rich enough to have your own fancy workstation.  So you will have to pretend, using the following simple and effective procedure:
• Save your projects as an archive in your home folder.
• When you start up, File->Restore the project from your archive to the local disk in your "private" folder.
• When you are finished, File->Archive the project back to your home folder.
• Delete the project from the local disk.
• 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.
• Backup often.  The way to do this is to make a new archive that you can restore from if necessary.
• 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).
• 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, I never use versions and revisions because of this - I create my 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.")

Naming Issues:

• Don't use case-sensitivity to differentiate names in your design. In other words, assume names are NOT case sensitive.
• Don't name any macros with the same name as the project name, especially Verilog macros. Otherwise "bad things" can happen.

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.

I stay away from Bus terminals and instead connect busses and parts of busses using signal names only.

When you name a bus, you can click the box which allows you to give a bus an arbitrary name, e.g. A[7:0], B[7:0] which makes a 16 bit bus by concatenating the two 8-bit busses A and B. You can put simple names in there as well, e.g. GND.

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.

When implementing a design with two or more top level schematics, creating a netlist in the schematic editor

(options->create netlist) generates a sourceless/loadless warning for every hanging net that runs across the pages.
This is a known problem with the integrity test feature of the Foundation Schematic Editor. Currently, this feature does
not correctly analyze nets across multiple pages. These messages can be safely ignored or disabled.

 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:

• After adding the probes, select "Update Simulation" in the schematic editor
• 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:.

If you edit the UCF constraints file, you may not be editing the current copy of the UCF file used in the implementation.  If your edit doesn't seem to make a difference, do a "Clear implementation data" in the Project menu of the Project Manager and try again. In fact, clearing the implementation data is usually a good thing to try if something weird happens when you implement.

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:

• Sometimes the logic analyzer prints out a lot of data that you don't care about, making it hard to find the useful information. But the logic analyzers can be set to trigger off the rising edge of a signal, and stop collecting data at the falling edge (or a few cycles later). So with a little effort, you can get the device to capture only a few cycles around a particular signal change, and not be inundated with lots of other data you don't care about.