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.
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:Simulator:
- 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:
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.always @(inp) if (inp) outp = 0; else outp = 0;- 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:
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).output [7:0] foo; reg foo;
- 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:
Then run the simulation, and things should work fine.
- 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)
- 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.