[2] Script Based Design Flow
Using a script based design flow is preferable to using the Xilinx Flow Engine for a number of reasons :
(a) The design flow is portable. Anyone ever trying to copy a project from another workstation or PC
realizes that this is much more difficult than it should be. Links to various files are hardcoded
to the source PCs directory structure, so many files have to be copies in just the right fashion.
An alternate script approach reveals that the only two user design files required for the backend
synthesis are the .edf netlist and the .ucf file. So the handoff to synthesis is now simply the script
file, the .edf netlist, and the .ucf file. As an added benefit these three files can be much more
easily archived using standard configuration control tools
(b) The design flow is self-documenting. All optional switches for the various tools (ngdbuild, map,
par, bitgen) are available in a singe file. With the GUI, these some options are visible/settable via
dialog boxes in unobvious locations.
(c) All options accessible via script - not always the case with the GUI. The Xilinx backend tools have
always been command line executables. The Xilinx Flow Engine GUI was added to make these tools more
"pushbutton" in nature, but the underlying executables (ngdbuild, map, par, bitgen) are still invoked.
When new command line options are added to underlying executables, the addition to GUI sometimes lags
the Xilinx toolset releases.
sample script file sample file script
[3] Constrained Designs
Designs must be 100% constrained. This is an iterative task. An examination of the .twr report that
results from running Trace shows % coverage of constraints. In addition, running Trace with the -u
option, will report paths that are unconstrained. Adding constraints to the .ucf file
will eliminate these paths, and boost the % coverage. However, Trace (the Xilinx static timing
analyzer tool) will not always finish up with 100% coverage. The task is done when the -u option
indicates there are no remaining unconstrained paths.
[4] Map Registered I/O into IOBFF
High speed synchronous transfers between FPGA and external clocked device require that data transitions
on input and output have minimal transition window away from sampled clock. This is most easily achieved
by registering I/O signals of FPGA, and in particular to map these registers to the IOB flip-flops of the
FPGA. If these registers are not placed in IOB, then they are subject to significant variations in delay
between consecutive synthesis runs. When the flip-flop is placed in the IOB, the input/output delay is
always fixed. In addition, the I/O path delay skew among all IOB FF is minimial (+/- .5ns for Spartan IIe,
for example). To place flip-flops in IOB, the map option "-pr b" must be used. Secondly, route constraints
on pad to flip-flop paths must be observed. Namely, for inputs, the input signal from pad, must go to one and
only one flip-flop, and for outputs, the output of the flip-flop must go directly to a pad, and can not fanout
to other flip-flops or logic. If the route rules are violated, then a non-IOB flip-flop will be used instead,
but this will occur without warning. It is important to check the .mrp report ( map report output), to look
at the IO assignment section, which indicates whether IOB flip-flops are used for a signal.
[5] Important Xilinx docs
Check the following directory path for some key Xilinx documents : /xilinx/doc/usenglish/docs.
There are three subdirectories of most interest :
(a) /dev contains dev.pdf, the Developers Reference manual. This document describes the command line
utilities for all of the Xilinx synthesis programs, as well as the associated command line options.
(b) /lib contains lib.pdf, this contains the Xilinx Library Guide. A terrific description for the various
Xilinx primitives for the different FPGA families is contained. Some useful tidbits on each of the design
elements are sure to be found. For instance, this manual describes that there are really two types of DLLs,
a fully functional low-frequency band DLL, and a mimimal functional high frequency DLL.
(c) /cgd contains cgd.pdf, the Xilinx constraint guide. Pretty useful for learning to write powerful .ucf
files. An alternative is to use the constraint_editor, a GUI tool, to find the correct syntax. The tool
also modifies the .ucf file directly, but it does it in a pretty verbose fashion. I usually, just get the
base syntax, then make the modifications with an editor.