docs/wiki/geda-igarus_fpga_lcg.html

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