This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
geda:icarus_xnf [2007/05/24 22:27] 127.0.0.1 external edit |
geda:icarus_xnf [2012/02/20 15:14] (current) |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Xilinx Netlist Format ====== | ||
+ | <code>WHAT IS XNF | ||
+ | XNF is the Xilinx Netlist Format. This is somewhat specific to the | ||
+ | Xilinx tool chain, but it is sufficiently ubiquitous that it's still | ||
+ | worth it. This format can be fed to place and route tools and | ||
+ | simulators. Since some third party simulators accept XNF, the format | ||
+ | may be useful even independent of Xilinx parts. | ||
+ | |||
+ | Icarus Verilog supports XNF as specified by the Xilinx Netlist Format | ||
+ | Specification, Version 6.1. | ||
+ | |||
+ | GENERATE XNF OUTPUT -- THE SHORT STORY | ||
+ | |||
+ | The easiest way to compile for XNF output is with the "verilog" | ||
+ | command (man verilog) and the -X switch: | ||
+ | |||
+ | % iverilog -fpart=4010e -fncf=prog.ncf -txnf prog.v | ||
+ | |||
+ | This generates from the prog.v Verilog source file the prog.xnf output | ||
+ | and the prog.ncf netlist constraints file. The verilog program | ||
+ | arranges to call the preprocessor and the ivl compiler with all the | ||
+ | correct switches for generating XNF. | ||
+ | |||
+ | GENERATING XNF MACROS | ||
+ | |||
+ | Icarus Verilog can be used to generate XNF implementations of devices | ||
+ | that are written in Verilog and used by schematic editors such as | ||
+ | OrCAD. The trick here is that the code generator automatically notices | ||
+ | ports to the root module and generates the PIN= attributes needed so | ||
+ | that external tools can link to the generated XNF. | ||
+ | |||
+ | Icarus Verilog chooses a name for the pin. The name it chooses is the | ||
+ | port name of the module. If the port is a vector, a pin is generated | ||
+ | for all the bits of the vector with the bit number appended. For | ||
+ | example: | ||
+ | |||
+ | module foo(in); | ||
+ | input [3:0] in; | ||
+ | |||
+ | causes the single bit ports ``in0'' through ``in3'' be | ||
+ | generated. Internally, the XNF file uses the bussed names instead of | ||
+ | the pin name. | ||
+ | |||
+ | The implication of this is that there is a chance of name collision | ||
+ | with the generated XNF macro if the port names are chosen badly. It is | ||
+ | best to not end a port name with decimal digits, as that can cause | ||
+ | trouble at link time. Also, XNF is not case sensitive and that should | ||
+ | be accounted for as well. | ||
+ | |||
+ | XNF PADS IN VERILOG SOURCE | ||
+ | |||
+ | You can assign wires to pads using the Icarus Verilog $attribute | ||
+ | extension. Attach to a scalar signal (wire or register) the PAD | ||
+ | attribute with the value that specifies the direction and pin | ||
+ | number. For example: | ||
+ | |||
+ | wire foo, bar, bid; | ||
+ | $attribute(foo, "PAD", "i1"); // Input pad on pin 1 | ||
+ | $attribute(bar, "PAD", "o2"); // Output pad on pin 2 | ||
+ | $attribute(bid, "PAD", "b3"); // Bi-directional pad on pin 3 | ||
+ | |||
+ | The XNFIO function uses these attributes to locate signals that are | ||
+ | connected to pads, and generates XNF I/O block devices to connect to | ||
+ | the pad to do the FPGA pin buffering that is needed. So the Verilog | ||
+ | programmer need not in general specify the IBUF/OBUF buffers. | ||
+ | |||
+ | If the programmer does connect buffers to pads, the compiler will | ||
+ | notice them and convert them to I/OBUFs automatically. For example: | ||
+ | |||
+ | buf b1 (sig, foo); | ||
+ | |||
+ | connects to pad foo, so will be converted into an XNF IBUF | ||
+ | device. Also: | ||
+ | |||
+ | bufif1 bt (bar, value, en); | ||
+ | |||
+ | connects to pad bar so will automatically be converted into an OBUFT | ||
+ | device. Icarus Verilog understands OBUF, IBUF and OBUFT (with optionally | ||
+ | inverted enable) devices and will convert Verilog devices from the | ||
+ | source, or generate missing devices. | ||
+ | |||
+ | In addition, the Verilog programmer may explicitly declare a device as | ||
+ | an I/OBUF by attaching an attribute to the device, like so: | ||
+ | |||
+ | buf b1 (sig, foo); | ||
+ | $attribute(b1, "XNF-LCA", "OBUF:O,I"); | ||
+ | |||
+ | This latter feature is not entirely recommended as it expects that the | ||
+ | programmer really knows how the pins of the XNF device are to be | ||
+ | connected. It also bypasses the efforts of the compiler, so is not | ||
+ | checked for correctness. | ||
+ | |||
+ | XNF STORAGE ELEMENTS | ||
+ | |||
+ | Storage elements in XNF include flip-flops, latches and CLB | ||
+ | rams. These devices are generated from the LPM equivalents that the | ||
+ | -Fsynth functor synthesizes from behavioral descriptions. | ||
+ | |||
+ | Flip-flops, or more specifically DFF devices, are generated to | ||
+ | implement behavioral code like this: | ||
+ | |||
+ | reg Q; | ||
+ | always @(posedge clk) Q <= <expr>; | ||
+ | |||
+ | The edge can be positive or negative, and the expression can be any | ||
+ | synthesizable expression. Furthermore, the register "Q" can have | ||
+ | width, which will cause the appropriate number of flip-flops to be | ||
+ | created. A clock enable expression can also be added like so: | ||
+ | |||
+ | reg Q; | ||
+ | always @(posedge clk) if (<ce>) Q <= <expr>; | ||
+ | |||
+ | The <ce> expression can be any synthesizable expression. | ||
+ | |||
+ | With or without the CE, the generated DFF devices are written into the | ||
+ | XNF output one bit at a time, with the clock input inverted if necessary. | ||
+ | |||
+ | Xilinx parts also support CLB circuitry as synchronous RAMS. These | ||
+ | devices are created from Verilog memories if the properties are | ||
+ | right. The behavioral description that the -Fsynth functor matches to | ||
+ | get a synchronous RAM looks very similar to that for a DFF: | ||
+ | |||
+ | reg [15:0] M; | ||
+ | always @(posedge clk) if (<we>) M[<addr>] <= <expr>; | ||
+ | |||
+ | Note that in this case the l-value of the assignment is an addressed | ||
+ | memory. This statement models writes into the memory. Reads from the | ||
+ | device can be modeled with ordinary structural code, i.e.: | ||
+ | |||
+ | assign foo <= M[<addr>]; | ||
+ | |||
+ | For the memory to be synthesizable in the XNF target, the address | ||
+ | lines for writes and reads must be connected. This corresponds to the | ||
+ | limitations of the real hardware. | ||
+ | |||
+ | OTHER XNF SPECIAL DEVICES | ||
+ | |||
+ | There are certain special devices in XNF that Verilog does not | ||
+ | naturally represent, although there are similar more generic Verilog | ||
+ | devices. The most obvious and useful example is the clock driver, | ||
+ | otherwise known as the global buffer BUFG. As with pads, Icarus | ||
+ | Verilog uses the $attribute extension to allow you to specify special | ||
+ | devices. | ||
+ | |||
+ | The $attribute statement can be applied to devices much the same way | ||
+ | one applies them to wires. For example, to turn a buffer into a clock | ||
+ | buffer: | ||
+ | |||
+ | wire iclk, clk; | ||
+ | buf BUFG (clk, iclk); | ||
+ | $attribute(iclk, "PAD", "i1"); | ||
+ | $attribute(BUFG, "XNF-LCA", "BUFG:O,I"); | ||
+ | |||
+ | The above statements cause the buffer BUFG to be emitted in the XNF | ||
+ | output as a BUFG device with the first signal called "O" and the | ||
+ | second called "I". The rest of this example connects the input of the | ||
+ | BUFG to a signal from the input pin #1 and connects the output to the | ||
+ | internal wire "clk". Incidentally, this example will cause an IBUF to | ||
+ | be generated to connect the iclk signal to input pin #1. | ||
+ | |||
+ | SUMMARY OF IVL SUPPORT FOR XNF | ||
+ | |||
+ | Icarus Verilog has a code generator and synthesis functions that | ||
+ | support generation of XNF netlists. The XNF modules also allow the | ||
+ | programmer to use $attributes to control certain aspects of code | ||
+ | generation. | ||
+ | |||
+ | XNF code generation is enabled with the ``-t xnf'' flag on the command | ||
+ | line. The code generator needs to know the type of part to generate | ||
+ | code for, so the ``-fpart=<type>'' flag is also needed. For example, | ||
+ | to generate code for the 4010E the command line might start out as: | ||
+ | |||
+ | ivl -txnf -fpart=4010e -Fsynth -Fnodangle -Fxnfio [...] | ||
+ | |||
+ | Icarus Verilog includes the functions ``synth'' and ``xnfio'' to | ||
+ | perform transformations and optimizations on the design before code is | ||
+ | generated. The ``synth'' function matches certain behavioral constructs | ||
+ | to structural components, and the xnfio function generates pads and | ||
+ | fills the IOBs. | ||
+ | |||
+ | SUPPORTED FLAGS | ||
+ | |||
+ | -fpart=<part> | ||
+ | Specify the type of part to target. This string is written | ||
+ | literally into the PART, record of the XNF, and may also be | ||
+ | used to control synthesis and placement. | ||
+ | |||
+ | -fncf=<path> | ||
+ | Cause the code generator to write into <path> the netlist | ||
+ | constraints needed for controlling placement and timing. This | ||
+ | switch is required if pin assignments are assigned in the | ||
+ | Verilog source. | ||
+ | |||
+ | THE SYNTH FUNCTION | ||
+ | |||
+ | This function does synthesis transformations on the entered design, | ||
+ | making it possible to generate XNF netlist components from certain | ||
+ | behavioral constructs. This is needed in Verilog for example to model | ||
+ | some of the synchronous components of the XNF library. | ||
+ | |||
+ | It is a bit much to expect a Verilog compiler in general to generate | ||
+ | components from arbitrary behavioral descriptions, so the synth | ||
+ | function works by matching statements that have some documented | ||
+ | structure, and substituting them for the equivalent XNF component. A | ||
+ | fully synthesize-able design, then, is one where the behavioral | ||
+ | statements can all be matched and substituted by the synth function. | ||
+ | |||
+ | THE XNFIO FUNCTION | ||
+ | |||
+ | The "xnfio" function transforms the netlist where the IOBs are | ||
+ | concerned. The signals with PAD attributes are checked, and | ||
+ | surrounding circuitry generated to conform to the logic available in | ||
+ | the IOB. | ||
+ | |||
+ | If the pad is an OPAD, the function will look for an existing buf or | ||
+ | not gate connected to the PAD signal. If the gate is appropriately | ||
+ | connected, the buf or not gate will be turned into an OBUF. This pulls | ||
+ | the buf or inverter into the IOB, freeing a CLB and providing the | ||
+ | required pin circuitry. | ||
+ | |||
+ | If the pad is an IPAD, the function will look for a buf, and convert | ||
+ | that to an IBUF. Since Xilinx IOBs cannot invert the output from an | ||
+ | IBUF, NOT gates cannot be absorbed as in the OPAD case. | ||
+ | |||
+ | |||
+ | /* | ||
+ | * Copyright (c) 1998-1999 Stephen Williams (steve@icarus.com) | ||
+ | * | ||
+ | * This source code is free software; you can redistribute it | ||
+ | * and/or modify it in source code form under the terms of the GNU | ||
+ | * General Public License as published by the Free Software | ||
+ | * Foundation; either version 2 of the License, or (at your option) | ||
+ | * any later version. | ||
+ | * | ||
+ | * This program is distributed in the hope that it will be useful, | ||
+ | * but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
+ | * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
+ | * GNU General Public License for more details. | ||
+ | * | ||
+ | * You should have received a copy of the GNU General Public License | ||
+ | * along with this program; if not, write to the Free Software | ||
+ | * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA | ||
+ | */ | ||
+ | |||
+ | |||
+ | $Log: xnf.txt,v $ | ||
+ | Revision 1.16 2003/07/15 03:49:22 steve | ||
+ | Spelling fixes. | ||
+ | |||
+ | Revision 1.15 2003/01/30 16:23:08 steve | ||
+ | Spelling fixes. | ||
+ | |||
+ | Revision 1.14 2000/08/01 21:32:40 steve | ||
+ | Use the iverilog command in documentation. | ||
+ | |||
+ | Revision 1.13 2000/08/01 02:48:42 steve | ||
+ | Support <= in synthesis of DFF and ram devices. | ||
+ | |||
+ | Revision 1.12 2000/07/25 22:49:32 steve | ||
+ | memory is not a data type in verilog. | ||
+ | |||
+ | Revision 1.11 2000/04/23 23:03:13 steve | ||
+ | automatically generate macro interface code. | ||
+ | |||
+ | Revision 1.10 1999/12/05 19:30:43 steve | ||
+ | Generate XNF RAMS from synthesized memories. | ||
+ | |||
+ | Revision 1.9 1999/11/18 03:52:20 steve | ||
+ | Turn NetTmp objects into normal local NetNet objects, | ||
+ | and add the nodangle functor to clean up the local | ||
+ | symbols generated by elaboration and other steps. | ||
+ | |||
+ | Revision 1.8 1999/11/06 04:51:42 steve | ||
+ | Support writing some XNF things into an NCF file. | ||
+ | |||
+ | Revision 1.7 1999/11/03 05:18:18 steve | ||
+ | XNF synthesis now uses the synth functor. | ||
+ | |||
+ | Revision 1.6 1999/11/02 01:43:55 steve | ||
+ | Fix iobuf and iobufif handling. | ||
+ | |||
+ | Revision 1.5 1999/10/09 17:52:27 steve | ||
+ | support XNF OBUFT devices. | ||
+ | |||
+ | Revision 1.4 1999/08/14 22:48:21 steve | ||
+ | Mention the sigfold function. | ||
+ | |||
+ | Revision 1.3 1999/07/22 02:05:20 steve | ||
+ | is_constant method for PEConcat. | ||
+ | |||
+ | Revision 1.2 1999/07/18 21:17:51 steve | ||
+ | Add support for CE input to XNF DFF, and do | ||
+ | complete cleanup of replaced design nodes. | ||
+ | |||
+ | Revision 1.1 1999/05/01 02:57:11 steve | ||
+ | XNF target documentation.</code> |