Update xilinx-hints.txt from Larry.

This commit is contained in:
steve 2000-02-13 04:06:49 +00:00
parent e58be1b128
commit 2bc8f79e0f
1 changed files with 34 additions and 30 deletions

View File

@ -1,21 +1,14 @@
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 (no arithmetic, 600 equivalent gates) designs
through this setup, targeting a Spartan XCS10.
run some admittedly simple (2300 equivalent gates) designs through this
setup, targeting a Spartan XCS10.
Verilog:
As of Icarus Verilog 19990814, you still can't have logic buried
in procedural (flip-flop) assignment. I use a hacked workaround
copy of ivl that allows 1-bit wide logic. The other approach
is to use temporary wires, assign them to the logic, and assign
the reg to that wire. For example, instead of
always @ (posedge Clk) Z = ~Q1 & ~Q2 & ~Q3 & ~Q4;
you can write
wire newZ;
assign newZ = ~Q1 & ~Q2 & ~Q3 & ~Q4;
always @ (posedge Clk) Z = newZ;
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
@ -27,36 +20,29 @@ Verilog:
Z = newZ;
end
I had reason to use a global clock net. I used this snippet of
Verilog code to make it happen:
primitive BUFG ( O, I );
output O;
input I;
table
0:0;
1:1;
endtable
endprimitive
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 );
$attribute(BUFG,"XNF-LCA","BUFG:O,I")
Oh, yes, you probably also want to choose I/O pins! Try this:
wire d1;
$attribute(d1, "PAD", "i45"); // input
wire vsync;
$attribute(vsync, "PAD", "o67"); // output
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:
-Fxnfio -Fnobufz -Fsigfold -Fxnfsyn
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.
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:
@ -76,6 +62,23 @@ Running the Xilinx back end:
.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 < $<
scp ${ALLIANCE_HOST}:${REMOTE_DIR}/$@ .
and the remote_alliance script (on ${ALLIANCE_HOST})
/bin/csh
cd $1
cat >! $2.xnf
xnf2pcf <$2.xnf >! $2.pcf
./backend $2
There is now a "Xilinx on Linux HOWTO" at
http://www.polybus.com/xilinx_on_linux.html
I havn't tried this yet, it looks interesting.
Downloading:
I use the XESS (http://www.xess.com/) XSP-10 development board, which
@ -90,3 +93,4 @@ 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 <LRDoolittle@lbl.gov> August 19, 1999
updated February 1, 2000