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