| blob | 6b2ca099822e36646456f2efa37d83cefe2887c2 |
5 <head>
12 <link rel="search" type="application/opensearchdescription+xml" href="http://geda.seul.org/wiki/lib/exe/opensearch.php" title="geda Wiki" />
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:icarus_xnf" />
18 <link rel="alternate" type="text/plain" title="Wiki Markup" href="http://geda.seul.org/wiki/_export/raw/geda:icarus_xnf" />
22 </head>
23 <body>
32 XNF is the Xilinx Netlist Format. This is somewhat specific to the
33 Xilinx tool chain, but it is sufficiently ubiquitous that it's still
34 worth it. This format can be fed to place and route tools and
35 simulators. Since some third party simulators accept XNF, the format
36 may be useful even independent of Xilinx parts.
38 Icarus Verilog supports XNF as specified by the Xilinx Netlist Format
39 Specification, Version 6.1.
41 GENERATE XNF OUTPUT -- THE SHORT STORY
44 command (man verilog) and the -X switch:
46 % iverilog -fpart=4010e -fncf=prog.ncf -txnf prog.v
48 This generates from the prog.v Verilog source file the prog.xnf output
49 and the prog.ncf netlist constraints file. The verilog program
50 arranges to call the preprocessor and the ivl compiler with all the
51 correct switches for generating XNF.
53 GENERATING XNF MACROS
55 Icarus Verilog can be used to generate XNF implementations of devices
56 that are written in Verilog and used by schematic editors such as
57 OrCAD. The trick here is that the code generator automatically notices
58 ports to the root module and generates the PIN= attributes needed so
59 that external tools can link to the generated XNF.
61 Icarus Verilog chooses a name for the pin. The name it chooses is the
62 port name of the module. If the port is a vector, a pin is generated
63 for all the bits of the vector with the bit number appended. For
64 example:
66 module foo(in);
70 generated. Internally, the XNF file uses the bussed names instead of
71 the pin name.
73 The implication of this is that there is a chance of name collision
74 with the generated XNF macro if the port names are chosen badly. It is
75 best to not end a port name with decimal digits, as that can cause
76 trouble at link time. Also, XNF is not case sensitive and that should
77 be accounted for as well.
79 XNF PADS IN VERILOG SOURCE
81 You can assign wires to pads using the Icarus Verilog $attribute
82 extension. Attach to a scalar signal (wire or register) the PAD
83 attribute with the value that specifies the direction and pin
84 number. For example:
86 wire foo, bar, bid;
91 The XNFIO function uses these attributes to locate signals that are
92 connected to pads, and generates XNF I/O block devices to connect to
93 the pad to do the FPGA pin buffering that is needed. So the Verilog
94 programmer need not in general specify the IBUF/OBUF buffers.
96 If the programmer does connect buffers to pads, the compiler will
97 notice them and convert them to I/OBUFs automatically. For example:
99 buf b1 (sig, foo);
101 connects to pad foo, so will be converted into an XNF IBUF
102 device. Also:
104 bufif1 bt (bar, value, en);
106 connects to pad bar so will automatically be converted into an OBUFT
107 device. Icarus Verilog understands OBUF, IBUF and OBUFT (with optionally
108 inverted enable) devices and will convert Verilog devices from the
109 source, or generate missing devices.
111 In addition, the Verilog programmer may explicitly declare a device as
112 an I/OBUF by attaching an attribute to the device, like so:
114 buf b1 (sig, foo);
117 This latter feature is not entirely recommended as it expects that the
118 programmer really knows how the pins of the XNF device are to be
119 connected. It also bypasses the efforts of the compiler, so is not
120 checked for correctness.
122 XNF STORAGE ELEMENTS
124 Storage elements in XNF include flip-flops, latches and CLB
125 rams. These devices are generated from the LPM equivalents that the
126 -Fsynth functor synthesizes from behavioral descriptions.
128 Flip-flops, or more specifically DFF devices, are generated to
129 implement behavioral code like this:
131 reg Q;
134 The edge can be positive or negative, and the expression can be any
136 width, which will cause the appropriate number of flip-flops to be
137 created. A clock enable expression can also be added like so:
139 reg Q;
144 With or without the CE, the generated DFF devices are written into the
145 XNF output one bit at a time, with the clock input inverted if necessary.
147 Xilinx parts also support CLB circuitry as synchronous RAMS. These
148 devices are created from Verilog memories if the properties are
149 right. The behavioral description that the -Fsynth functor matches to
150 get a synchronous RAM looks very similar to that for a DFF:
155 Note that in this case the l-value of the assignment is an addressed
156 memory. This statement models writes into the memory. Reads from the
157 device can be modeled with ordinary structural code, i.e.:
161 For the memory to be synthesizable in the XNF target, the address
162 lines for writes and reads must be connected. This corresponds to the
163 limitations of the real hardware.
165 OTHER XNF SPECIAL DEVICES
167 There are certain special devices in XNF that Verilog does not
168 naturally represent, although there are similar more generic Verilog
169 devices. The most obvious and useful example is the clock driver,
170 otherwise known as the global buffer BUFG. As with pads, Icarus
171 Verilog uses the $attribute extension to allow you to specify special
172 devices.
174 The $attribute statement can be applied to devices much the same way
175 one applies them to wires. For example, to turn a buffer into a clock
176 buffer:
178 wire iclk, clk;
179 buf BUFG (clk, iclk);
183 The above statements cause the buffer BUFG to be emitted in the XNF
186 BUFG to a signal from the input pin #1 and connects the output to the
188 be generated to connect the iclk signal to input pin #1.
190 SUMMARY OF IVL SUPPORT FOR XNF
192 Icarus Verilog has a code generator and synthesis functions that
193 support generation of XNF netlists. The XNF modules also allow the
194 programmer to use $attributes to control certain aspects of code
195 generation.
197 XNF code generation is enabled with the ``-t xnf'' flag on the command
198 line. The code generator needs to know the type of part to generate
200 to generate code for the 4010E the command line might start out as:
202 ivl -txnf -fpart=4010e -Fsynth -Fnodangle -Fxnfio [...]
205 perform transformations and optimizations on the design before code is
206 generated. The ``synth'' function matches certain behavioral constructs
207 to structural components, and the xnfio function generates pads and
208 fills the IOBs.
210 SUPPORTED FLAGS
213 Specify the type of part to target. This string is written
214 literally into the PART, record of the XNF, and may also be
215 used to control synthesis and placement.
219 constraints needed for controlling placement and timing. This
220 switch is required if pin assignments are assigned in the
221 Verilog source.
223 THE SYNTH FUNCTION
225 This function does synthesis transformations on the entered design,
226 making it possible to generate XNF netlist components from certain
227 behavioral constructs. This is needed in Verilog for example to model
228 some of the synchronous components of the XNF library.
230 It is a bit much to expect a Verilog compiler in general to generate
231 components from arbitrary behavioral descriptions, so the synth
232 function works by matching statements that have some documented
233 structure, and substituting them for the equivalent XNF component. A
234 fully synthesize-able design, then, is one where the behavioral
235 statements can all be matched and substituted by the synth function.
237 THE XNFIO FUNCTION
240 concerned. The signals with PAD attributes are checked, and
241 surrounding circuitry generated to conform to the logic available in
242 the IOB.
244 If the pad is an OPAD, the function will look for an existing buf or
245 not gate connected to the PAD signal. If the gate is appropriately
246 connected, the buf or not gate will be turned into an OBUF. This pulls
247 the buf or inverter into the IOB, freeing a CLB and providing the
248 required pin circuitry.
250 If the pad is an IPAD, the function will look for a buf, and convert
251 that to an IBUF. Since Xilinx IOBs cannot invert the output from an
252 IBUF, NOT gates cannot be absorbed as in the OPAD case.
255 /*
257 *
258 * This source code is free software; you can redistribute it
259 * and/or modify it in source code form under the terms of the GNU
260 * General Public License as published by the Free Software
261 * Foundation; either version 2 of the License, or (at your option)
262 * any later version.
263 *
264 * This program is distributed in the hope that it will be useful,
265 * but WITHOUT ANY WARRANTY; without even the implied warranty of
266 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
267 * GNU General Public License for more details.
268 *
269 * You should have received a copy of the GNU General Public License
270 * along with this program; if not, write to the Free Software
272 */
275 $Log: xnf.txt,v $
277 Spelling fixes.
280 Spelling fixes.
283 Use the iverilog command in documentation.
286 Support <= in synthesis of DFF and ram devices.
289 memory is not a data type in verilog.
292 automatically generate macro interface code.
295 Generate XNF RAMS from synthesized memories.
298 Turn NetTmp objects into normal local NetNet objects,
299 and add the nodangle functor to clean up the local
300 symbols generated by elaboration and other steps.
303 Support writing some XNF things into an NCF file.
306 XNF synthesis now uses the synth functor.
309 Fix iobuf and iobufif handling.
312 support XNF OBUFT devices.
315 Mention the sigfold function.
318 is_constant method for PEConcat.
321 Add support for CE input to XNF DFF, and do
322 complete cleanup of replaced design nodes.
325 XNF target documentation.</pre>
327 </div>
328 </div>
329 </body>
330 </html>