tgt-fpga/fpga.txt

   1
   2 FPGA LOADABLE CODE GENERATOR FOR Icarus Verilog
   3
   4   Copyright 2001 Stephen Williams
   5   $Id: fpga.txt,v 1.12 2005/09/19 21:45:36 steve Exp $
   6
   7 The FPGA code generator supports a variety of FPGA devices, writing
   8 XNF or EDIF depending on the target. You can select the architecture
   9 of the device, and the detailed part name. The architecture is used to
  10 select library primitives, and the detailed part name is written into
  11 the generated file for the use of downstream tools.
  12
  13 INVOKING THE FPGA TARGET
  14
  15 The code generator is invoked with the -tfpga flag to iverilog. It
  16 understands the part= and the arch= parameters, which can be set with
  17 the -p flag of iverilog:
  18
  19         iverilog -parch=virtex -ppart=v50-pq240-6 -tfpga foo.vl
  20
  21 This example selects the Virtex architecture, and give the detailed
  22 part number as v50-pq240-6. The output is written into a.out unless a
  23 different output file is specified with the -o flag.
  24
  25 The following is a list of architecture types that this code generator
  26 supports.
  27
  28 * arch=lpm
  29
  30 This is a device independent format, where the gates are device types
  31 as defined by the LPM 2 1 0 specification. Some backend tools may take
  32 this format, or users may write interface libraries to connect these
  33 netlists to the device in question.
  34
  35 * arch=generic-edif (obsolete)
  36
  37 This is generic EDIF code. It doesn't necessarily work because the
  38 external library is not available to the code generator. But, what it
  39 does is generate generic style gates that a portability library can
  40 map to target gates if desired.
  41
  42 * arch=generic-xnf (obsolete)
  43
  44 If this is selected, then the output is formatted as an XNF file,
  45 suitable for most any type of device. The devices that it emits
  46 are generic devices from the unified library. Some devices are macros,
  47 you may need to further resolve the generated XNF to get working
  48 code for your part.
  49
  50 * arch=virtex
  51
  52 If this is selected, then the output is formatted as an EDIF 200 file,
  53 suitable for Virtex class devices. This is supposed to know that you
  54 are targeting a Virtex part, so can generate primitives instead of
  55 using external macros. It includes the VIRTEX internal library, and
  56 should work properly for any Virtex part.
  57
  58 * arch=virtex2
  59
  60 If this is selected, then the output is EDIF 2 0 0 suitable for
  61 Virtex-II and Virtex-II Pro devices. It uses the VIRTEX2 library, but
  62 is very similar to the Virtex target.
  63
  64 XNF ROOT PORTS
  65
  66   NOTE: As parts are moved over to EDIF format, XNF support will be
  67   phased out. Current Xilinx implementation tools will accept EDIF
  68   format files even for the older parts, and non-Xilinx implementation
  69   tools accept nothing else.
  70
  71 When the output format is XNF, the code generator will generate "SIG"
  72 records for the signals that are ports of the root module. The name is
  73 declared as an external pin that this macro makes available.
  74
  75 The name given to the macro pin is generated from the base name of the
  76 signal. If the signal is one bit wide, then the pin name is exactly
  77 the module port name. If the port is a vector, then the pin number is
  78 given as a vector. For example, the module:
  79
  80         module main(out, in);
  81             output out;
  82             input [2:0] in;
  83             [...]
  84         endmodule
  85
  86 leads to these SIG, records:
  87
  88         SIG, main/out, PIN=out
  89         SIG, main/in<2>, PIN=in2
  90         SIG, main/in<1>, PIN=in1
  91         SIG, main/in<0>, PIN=in0
  92
  93
  94 EDIF ROOT PORTS
  95
  96 The EDIF format is more explicit about the interface into an EDIF
  97 file. The code generator uses that control to generate an explicit
  98 interface definition into the design. (This is *not* the same as the
  99 PADS of a part.) The generated EDIF interface section contains port
 100 definitions, including the proper direction marks.
 101
 102 With the (rename ...) s-exp in EDIF, it is possible to assign
 103 arbitrary text to port names. The EDIF code generator therefore does
 104 not resort to the mangling that is needed for the XNF target. The base
 105 name of the signal that is an input or output is used as the name of
 106 the port, complete with the proper case.
 107
 108 However, since the ports are single bit ports, the name of vectors
 109 includes the string "[0]" where the number is the bit number. For
 110 example, the module:
 111
 112
 113         module main(out, in);
 114             output out;
 115             input [2:0] in;
 116             [...]
 117         endmodule
 118
 119 creates these ports:
 120
 121         out   OUTPUT
 122         in[0] INPUT
 123         in[1] INPUT
 124         in[2] INPUT
 125
 126 Target tools, including Xilinx Foundation tools, understand the []
 127 characters in the name and recollect the signals into a proper bus
 128 when presenting the vector to the user.
 129
 130
 131 PADS AND PIN ASSIGNMENT
 132
 133 The ports of a root module may be assigned to specific pins, or to a
 134 generic pad. If a signal (that is a port) has a PAD attribute, then
 135 the value of that attribute is a list of locations, one for each bit
 136 of the signal, that specifies the pin for each bit of the signal. For
 137 example:
 138
 139         module main( (* PAD = "P10" *)         output out,
 140                      (* PAD = "P20,P21,P22" *) input [2:0] in);
 141
 142             [...]
 143
 144         endmodule
 145
 146 In this example, port ``out'' is assigned to pin 10, and port ``in''
 147 is assigned to pins 20-22. If the architecture supports it, a pin
 148 number of 0 means let the back end tools choose a pin. The format of
 149 the pin number depends on the architecture family being targeted, so
 150 for example Xilinx family devices take the name that is associated
 151 with the "LOC" attribute.
 152
 153 NOTE: If a module port is assigned to a pin (and therefore attached to
 154 a PAD) then it is *not* connected to a port of the EDIF file. This is
 155 because the PAD (and possibly IBUF or OBUF) would become an extra
 156 driver to the port. An error.
 157
 158
 159 SPECIAL DEVICES
 160
 161 The code generator supports the "cellref" attribute attached to logic
 162 devices to cause specific device types be generated, instead of the
 163 usual device that the code generator might generate. For example, to
 164 get a clock buffer out of a Verilog buf:
 165
 166         buf my_gbuf(out, in);
 167         $attribute(my_buf, "cellref", "GBUF:O,I");
 168
 169 The "cellref" attribute tells the code generator to use the given
 170 cell. The syntax of the value is:
 171
 172         <cell type>:<pin name>,...
 173
 174 The cell type is the name of the library part to use. The pin names
 175 are the names of the type in the library, in the order that the logic
 176 device pins are connected.
 177
 178
 179 COMPILING WITH XILINX FOUNDATION
 180
 181 Compile a single-file design with command line tools like so:
 182
 183         % iverilog -parch=virtex -o foo.edf foo.vl
 184         % edif2ngd foo.edf foo.ngo
 185         % ngdbuild -p v50-pq240 foo.ngo foo.ngd
 186         % map -o map.ncd foo.ngd
 187         % par -w map.ncd foo.ncd
 188
 189 ---
 190 $Log: fpga.txt,v $
 191 Revision 1.12  2005/09/19 21:45:36  steve
 192  Spelling patches from Larry.
 193
 194 Revision 1.11  2003/08/07 05:17:34  steve
 195  Add arch=lpm to the documentation.
 196
 197 Revision 1.10  2003/07/04 03:57:19  steve
 198  Allow attributes on Verilog 2001 port declarations.
 199
 200 Revision 1.9  2003/07/04 01:08:03  steve
 201  PAD attribute can be used to assign pins.
 202
 203 Revision 1.8  2003/07/02 00:26:49  steve
 204  Fix spelling of part= flag.
 205
 206 Revision 1.7  2003/03/24 02:28:38  steve
 207  Document the virtex2 architecture.
 208
 209 Revision 1.6  2003/03/24 00:47:54  steve
 210  Add new virtex2 architecture family, and
 211  also the new edif.h EDIF management functions.
 212
 213 Revision 1.5  2002/04/30 04:26:42  steve
 214  Spelling errors.
 215
 216 Revision 1.4  2001/09/16 22:26:47  steve
 217  Support the cellref attribute.
 218
 219 Revision 1.3  2001/09/16 01:48:16  steve
 220  Suppor the PAD attribute on signals.
 221
 222 Revision 1.2  2001/09/06 04:28:40  steve
 223  Separate the virtex and generic-edif code generators.
 224
 225 Revision 1.1  2001/09/02 23:58:49  steve
 226  Add documentation for the code generator.
 227