User Tools

Site Tools


Xilinx Hints

For those of you who wish to use Icarus Verilog, in combination with
the Xilinx back end (Foundation or Alliance), it can be done.  I have
run some admittedly simple (2300 equivalent gates) designs through this
setup, targeting a Spartan XCS10.


   Older versions of Icarus Verilog (like 19990814) couldn't synthesize
   logic buried in procedural (flip-flop) assignment.  Newer versions
   (like 20000120) don't have this limitation.

   Procedural assignments have to be given one at a time, to be
   "found" by xnfsyn.  Say
       always @ (posedge Clk) Y = newY;
       always @ (posedge Clk) Z = newZ;
   rather than
       always @ (posedge Clk) begin
           Y = newY;
           Z = newZ;

   Steve's xnf.txt covers most buffer and pin constructs, but I had reason
   to use a global clock net not connected to an input pin.  The standard
   Verilog for a buffer, combined with a declaration to turn that into a
   BUFG, is:
       buf BUFG( your_output_here, your_input_here );

   I use post-processing on my .xnf files to add "FAST" attributes to
   output pins.

Running ivl:

   The -F switches are important.  The following order seems to robustly
   generate valid XNF files, and is used by "verilog -X":
      -Fsynth -Fnodangle -Fxnfio

Generating .pcf files:

   The ngdbuild step seems to lose pin placement information that ivl
   puts in the XNF file.  Use xnf2pcf to extract this information to
   a .pcf file, which the Xilinx place-and-route software _will_ pay
   attention to.  Steve says he now makes that information available
   in an NCF file, with -fncf=<path>, but I haven't tested that.

Running the Xilinx back end:

   You can presumably use the GUI, but that doesn't fit in Makefiles :-).
   Here is the command sequence in pseudo-shell-script:
      ngdbuild -p $part $1.xnf $1.ngd
      map -p $part -o map.ncd $1.ngd
      xnf2pcf <$1.xnf >$1.pcf    # see above
      par -w -ol 2 -d 0 map.ncd $1.ncd $1.pcf
      bitgen_flags = -g ConfigRate:SLOW -g TdoPin:PULLNONE -g DonePin:PULLUP \
                     -g CRC:enable -g StartUpClk:CCLK -g SyncToDone:no \
                     -g DoneActive:C1 -g OutputsActive:C3 -g GSRInactive:C4 \
                     -g ReadClk:CCLK -g ReadCapture:enable -g ReadAbort:disable
      bitgen $1.ncd -l -w $bitgen_flags

   The Xilinx software has diarrhea of the temp files (14, not including
   .xnf, .pcf, .ngd, .ncd, and .bit), so this sequence is best done in a
   dedicated directory.  Note in particular that map.ncd is a generic name.

   I had reason to run this remotely (and transparently within a Makefile)
   via ssh.  I use the gmake rule
%.bit : %.xnf
        ssh -x -a -o 'BatchMode yes' ${ALLIANCE_HOST} \
               remote_alliance ${REMOTE_DIR} $(basename $@) 2>&1 < $<
    and the remote_alliance script (on ${ALLIANCE_HOST})
cd $1
cat >! $2.xnf
xnf2pcf <$2.xnf >! $2.pcf
./backend $2

   There is now a "Xilinx on Linux HOWTO" at
   I haven't tried this yet, it looks interesting.


   I use the XESS ( XSP-10 development board, which
   uses the PC parallel (printer) port for downloading and interaction
   with the host.  They made an old version of their download program
   public domain, posted it at ,
   and now there is a Linux port at .

The above hints are based on my experience with Foundation 1.5 on NT
(gack) and Alliance 2.1i on Solaris.  Your mileage may vary.  Good luck!

     - Larry Doolittle   <>   August 19, 1999
                                        updated February 1, 2000
geda/icarus_xilinx_hints.txt · Last modified: 2012/02/20 15:14 (external edit)