User Tools

Site Tools



This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
geda:icarus_xnf [2011/01/07 18:22]
peterb Update FSF address.
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.
 +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.
 +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
 + 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.
 +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.
 +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.
 +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
 +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
 + 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.
 +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
 +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.
 +    -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.
 +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 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 (
 + *
 + ​* ​   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
 + ​* ​   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>​