| blob | 523fb4984e4dc092b0f71d40450d83d744eefcfc |
3 <html>
4 <head>
5 <title></title>
11 </head>
12 <body>
15 <h1 class="sectionedit859"><a name="xilinx_netlist_format" id="xilinx_netlist_format">Xilinx Netlist Format</a></h1>
19 XNF is the Xilinx Netlist Format. This is somewhat specific to the
20 Xilinx tool chain, but it is sufficiently ubiquitous that it's still
21 worth it. This format can be fed to place and route tools and
22 simulators. Since some third party simulators accept XNF, the format
23 may be useful even independent of Xilinx parts.
25 Icarus Verilog supports XNF as specified by the Xilinx Netlist Format
26 Specification, Version 6.1.
28 GENERATE XNF OUTPUT -- THE SHORT STORY
31 command (man verilog) and the -X switch:
33 % iverilog -fpart=4010e -fncf=prog.ncf -txnf prog.v
35 This generates from the prog.v Verilog source file the prog.xnf output
36 and the prog.ncf netlist constraints file. The verilog program
37 arranges to call the preprocessor and the ivl compiler with all the
38 correct switches for generating XNF.
40 GENERATING XNF MACROS
42 Icarus Verilog can be used to generate XNF implementations of devices
43 that are written in Verilog and used by schematic editors such as
44 OrCAD. The trick here is that the code generator automatically notices
45 ports to the root module and generates the PIN= attributes needed so
46 that external tools can link to the generated XNF.
48 Icarus Verilog chooses a name for the pin. The name it chooses is the
49 port name of the module. If the port is a vector, a pin is generated
50 for all the bits of the vector with the bit number appended. For
51 example:
53 module foo(in);
57 generated. Internally, the XNF file uses the bussed names instead of
58 the pin name.
60 The implication of this is that there is a chance of name collision
61 with the generated XNF macro if the port names are chosen badly. It is
62 best to not end a port name with decimal digits, as that can cause
63 trouble at link time. Also, XNF is not case sensitive and that should
64 be accounted for as well.
66 XNF PADS IN VERILOG SOURCE
68 You can assign wires to pads using the Icarus Verilog $attribute
69 extension. Attach to a scalar signal (wire or register) the PAD
70 attribute with the value that specifies the direction and pin
71 number. For example:
73 wire foo, bar, bid;
78 The XNFIO function uses these attributes to locate signals that are
79 connected to pads, and generates XNF I/O block devices to connect to
80 the pad to do the FPGA pin buffering that is needed. So the Verilog
81 programmer need not in general specify the IBUF/OBUF buffers.
83 If the programmer does connect buffers to pads, the compiler will
84 notice them and convert them to I/OBUFs automatically. For example:
86 buf b1 (sig, foo);
88 connects to pad foo, so will be converted into an XNF IBUF
89 device. Also:
91 bufif1 bt (bar, value, en);
93 connects to pad bar so will automatically be converted into an OBUFT
94 device. Icarus Verilog understands OBUF, IBUF and OBUFT (with optionally
95 inverted enable) devices and will convert Verilog devices from the
96 source, or generate missing devices.
98 In addition, the Verilog programmer may explicitly declare a device as
99 an I/OBUF by attaching an attribute to the device, like so:
101 buf b1 (sig, foo);
104 This latter feature is not entirely recommended as it expects that the
105 programmer really knows how the pins of the XNF device are to be
106 connected. It also bypasses the efforts of the compiler, so is not
107 checked for correctness.
109 XNF STORAGE ELEMENTS
111 Storage elements in XNF include flip-flops, latches and CLB
112 rams. These devices are generated from the LPM equivalents that the
113 -Fsynth functor synthesizes from behavioral descriptions.
115 Flip-flops, or more specifically DFF devices, are generated to
116 implement behavioral code like this:
118 reg Q;
121 The edge can be positive or negative, and the expression can be any
123 width, which will cause the appropriate number of flip-flops to be
124 created. A clock enable expression can also be added like so:
126 reg Q;
131 With or without the CE, the generated DFF devices are written into the
132 XNF output one bit at a time, with the clock input inverted if necessary.
134 Xilinx parts also support CLB circuitry as synchronous RAMS. These
135 devices are created from Verilog memories if the properties are
136 right. The behavioral description that the -Fsynth functor matches to
137 get a synchronous RAM looks very similar to that for a DFF:
142 Note that in this case the l-value of the assignment is an addressed
143 memory. This statement models writes into the memory. Reads from the
144 device can be modeled with ordinary structural code, i.e.:
148 For the memory to be synthesizable in the XNF target, the address
149 lines for writes and reads must be connected. This corresponds to the
150 limitations of the real hardware.
152 OTHER XNF SPECIAL DEVICES
154 There are certain special devices in XNF that Verilog does not
155 naturally represent, although there are similar more generic Verilog
156 devices. The most obvious and useful example is the clock driver,
157 otherwise known as the global buffer BUFG. As with pads, Icarus
158 Verilog uses the $attribute extension to allow you to specify special
159 devices.
161 The $attribute statement can be applied to devices much the same way
162 one applies them to wires. For example, to turn a buffer into a clock
163 buffer:
165 wire iclk, clk;
166 buf BUFG (clk, iclk);
170 The above statements cause the buffer BUFG to be emitted in the XNF
173 BUFG to a signal from the input pin #1 and connects the output to the
175 be generated to connect the iclk signal to input pin #1.
177 SUMMARY OF IVL SUPPORT FOR XNF
179 Icarus Verilog has a code generator and synthesis functions that
180 support generation of XNF netlists. The XNF modules also allow the
181 programmer to use $attributes to control certain aspects of code
182 generation.
184 XNF code generation is enabled with the ``-t xnf'' flag on the command
185 line. The code generator needs to know the type of part to generate
187 to generate code for the 4010E the command line might start out as:
189 ivl -txnf -fpart=4010e -Fsynth -Fnodangle -Fxnfio [...]
192 perform transformations and optimizations on the design before code is
193 generated. The ``synth'' function matches certain behavioral constructs
194 to structural components, and the xnfio function generates pads and
195 fills the IOBs.
197 SUPPORTED FLAGS
200 Specify the type of part to target. This string is written
201 literally into the PART, record of the XNF, and may also be
202 used to control synthesis and placement.
206 constraints needed for controlling placement and timing. This
207 switch is required if pin assignments are assigned in the
208 Verilog source.
210 THE SYNTH FUNCTION
212 This function does synthesis transformations on the entered design,
213 making it possible to generate XNF netlist components from certain
214 behavioral constructs. This is needed in Verilog for example to model
215 some of the synchronous components of the XNF library.
217 It is a bit much to expect a Verilog compiler in general to generate
218 components from arbitrary behavioral descriptions, so the synth
219 function works by matching statements that have some documented
220 structure, and substituting them for the equivalent XNF component. A
221 fully synthesize-able design, then, is one where the behavioral
222 statements can all be matched and substituted by the synth function.
224 THE XNFIO FUNCTION
227 concerned. The signals with PAD attributes are checked, and
228 surrounding circuitry generated to conform to the logic available in
229 the IOB.
231 If the pad is an OPAD, the function will look for an existing buf or
232 not gate connected to the PAD signal. If the gate is appropriately
233 connected, the buf or not gate will be turned into an OBUF. This pulls
234 the buf or inverter into the IOB, freeing a CLB and providing the
235 required pin circuitry.
237 If the pad is an IPAD, the function will look for a buf, and convert
238 that to an IBUF. Since Xilinx IOBs cannot invert the output from an
239 IBUF, NOT gates cannot be absorbed as in the OPAD case.
242 /*
244 *
245 * This source code is free software; you can redistribute it
246 * and/or modify it in source code form under the terms of the GNU
247 * General Public License as published by the Free Software
248 * Foundation; either version 2 of the License, or (at your option)
249 * any later version.
250 *
251 * This program is distributed in the hope that it will be useful,
252 * but WITHOUT ANY WARRANTY; without even the implied warranty of
253 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
254 * GNU General Public License for more details.
255 *
256 * You should have received a copy of the GNU General Public License
257 * along with this program; if not, write to the Free Software
259 */
262 $Log: xnf.txt,v $
264 Spelling fixes.
267 Spelling fixes.
270 Use the iverilog command in documentation.
273 Support <= in synthesis of DFF and ram devices.
276 memory is not a data type in verilog.
279 automatically generate macro interface code.
282 Generate XNF RAMS from synthesized memories.
285 Turn NetTmp objects into normal local NetNet objects,
286 and add the nodangle functor to clean up the local
287 symbols generated by elaboration and other steps.
290 Support writing some XNF things into an NCF file.
293 XNF synthesis now uses the synth functor.
296 Fix iobuf and iobufif handling.
299 support XNF OBUFT devices.
302 Mention the sigfold function.
305 is_constant method for PEConcat.
308 Add support for CE input to XNF DFF, and do
309 complete cleanup of replaced design nodes.
312 XNF target documentation.</pre>
314 </div>
315 </body>
316 </html>