tgt-fpga/iverilog-fpga.man

   1 .TH iverilog-fpga 1 "$Date: 2004/10/04 01:10:57 $" Version "$Date: 2004/10/04 01:10:57 $"
   2 .SH NAME
   3 iverilog-fpga \- FPGA code generator for Icarus Verilog
   4
   5 .SH SYNOPSIS
   6 .B iverilog -tfpga
   7 [iverilog-options] sourcefile
   8
   9 .SH DESCRIPTION
  10 .PP
  11 The FPGA code generator supports a variety of FPGA devices, writing
  12 EDIF output depending on the target. You can select the architecture
  13 of the device, and the detailed part name. The architecture is used to
  14 select library primitives, and the detailed part name is written into
  15 the generated file for the use of downstream tools.
  16
  17 The code generator is invoked with the -tfpga flag to iverilog. It
  18 understands the part= and the arch= parameters, which can be set with
  19 the -p flag of iverilog:
  20
  21         iverilog -parch=virtex -ppart=v50-pq240-6 -tfpga foo.vl
  22
  23 This example selects the Virtex architecture, and give the detailed
  24 part number as v50-pq240-6. The output is written into a.out unless a
  25 different output file is specified with the -o flag.
  26
  27
  28 .SH OPTIONS
  29 .l
  30 \fIiverilog -tfpga\fP accepts the following options:
  31 .TP 8
  32 .B -parch=\fIfamily\fP
  33 The \fIfamily\fP setting further specifies the target device
  34 family. See FPGA FAMILIES below.
  35
  36 .TP 8
  37 .B -ppart=\fIdevice\fP
  38 This specifies a specific device in the form of a detailed part
  39 number. The format of this number is defined by the part vendor. In
  40 most cases, the device string is taken literally and written as is to
  41 the EDIF output.
  42
  43 .SH "FPGA FAMILIES"
  44
  45 The following is a list of architecture types that this code generator
  46 supports.
  47
  48 .TP 8
  49 .B lpm
  50 This is a device independent format, where the gates are device types
  51 as defined by the LPM 2 1 0 specification. Some backend tools may take
  52 this format, or users may write interface libraries to connect these
  53 netlists to the device in question.
  54
  55 The \fBlpm\fP family is the default if no other is specified.
  56 .TP 8
  57 .B virtex
  58 If this is selected, then the output is formatted as an EDIF 2 0 0 file,
  59 suitable for Virtex class devices. This is supposed to know that you
  60 are targeting a Virtex part, so can generate primitives instead of
  61 using external macros. It includes the VIRTEX internal library, and
  62 should work properly for any Virtex part.
  63 .TP 8
  64 .B virtex2
  65 If this is selected, then the output is EDIF 2 0 0 suitable for
  66 Virtex-II and Virtex-II Pro devices. It uses the VIRTEX2 library, but
  67 is very similar to the Virtex target.
  68
  69 .SH "EDIF ROOT PORTS"
  70
  71 The EDIF format is explicit about the interface into an EDIF file. The
  72 code generator uses that control to generate an explicit interface
  73 definition into the design. (This is *not* the same as the PADS of a
  74 part.) The generated EDIF interface section contains port definitions,
  75 including the proper direction marks.
  76
  77 With the (rename ...) s-exp in EDIF, it is possible to assign
  78 arbitrary text to port names. The EDIF code generator therefore does
  79 not resort to the mangling that is needed for internal symbols. The
  80 base name of the signal that is an input or output is used as the name
  81 of the port, complete with the proper case.
  82
  83 However, since the ports are single bit ports, the name of vectors
  84 includes the string "[0]" where the number is the bit number. For
  85 example, the module:
  86
  87 .nf
  88         module main(out, in);
  89             output out;
  90             input [2:0] in;
  91             [...]
  92         endmodule
  93 .fi
  94
  95 creates these ports:
  96
  97 .nf
  98         out   OUTPUT
  99         in[0] INPUT
 100         in[1] INPUT
 101         in[2] INPUT
 102 .fi
 103
 104 Target tools, including Xilinx Foundation tools, understand the []
 105 characters in the name and recollect the signals into a proper bus
 106 when presenting the vector to the user.
 107
 108 .SH "PADS AND PIN ASSIGNMENT"
 109
 110 The ports of a root module may be assigned to specific pins, or to a
 111 generic pad. If a signal (that is a port) has a PAD attribute, then
 112 the value of that attribute is a list of locations, one for each bit
 113 of the signal, that specifies the pin for each bit of the signal. For
 114 example:
 115
 116 .nf
 117         module main( (* PAD = "P10" *) output out,
 118                      (* PAD = "P20,P21,P22" *) input [2:0] in);
 119
 120             [...]
 121
 122         endmodule
 123 .fi
 124
 125 In this example, port ``out'' is assigned to pin 10, and port ``in''
 126 is assigned to pins 20-22. If the architecture supports it, a pin
 127 number of 0 means let the back end tools choose a pin. The format of
 128 the pin number depends on the architecture family being targeted, so
 129 for example Xilinx family devices take the name that is associated
 130 with the "LOC" attribute.
 131
 132 NOTE: If a module port is assigned to a pin (and therefore attached to
 133 a PAD) then it is *not* connected to a port of the EDIF file. This is
 134 because the PAD (and possibly IBUF or OBUF) would become an extra
 135 driver to the port. An error.
 136
 137 .SH "SPECIAL DEVICES"
 138
 139 The code generator supports the "cellref" attribute attached to logic
 140 devices to cause specific device types be generated, instead of the
 141 usual device that the code generator might generate. For example, to
 142 get a clock buffer out of a Verilog buf:
 143
 144 .nf
 145         buf my_gbuf(out, in);
 146         $attribute(my_buf, "cellref", "GBUF:O,I");
 147 .fi
 148
 149 The "cellref" attribute tells the code generator to use the given
 150 cell. The syntax of the value is:
 151
 152 .nf
 153         <cell type>:<pin name>,...
 154 .fi
 155
 156 The cell type is the name of the library part to use. The pin names
 157 are the names of the type in the library, in the order that the logic
 158 device pins are connected.
 159
 160 .SH EXAMPLES
 161
 162 .TB 8
 163 .I COMPILING WITH XILINX FOUNDATION/iSE
 164 Compile a single-file design with command line tools like so:
 165
 166 .nf
 167         % iverilog -parch=virtex -o foo.edf foo.vl
 168         % edif2ngd foo.edf foo.ngo
 169         % ngdbuild -p v50-pq240 foo.ngo foo.ngd
 170         % map -o map.ncd foo.ngd
 171         % par -w map.ncd foo.ncd
 172 .fi
 173
 174 .SH "AUTHOR"
 175 .nf
 176 Steve Williams (steve@icarus.com)
 177
 178 .SH SEE ALSO
 179 iverilog(1),
 180 .BR "<http://www.icarus.com/eda/verilog/>"
 181
 182 .SH COPYRIGHT
 183 .nf
 184 Copyright \(co  2003 Stephen Williams
 185
 186 This document can be freely redistributed according to the terms of the
 187 GNU General Public License version 2.0