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