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
Next revision
Previous revision
geda:icarus_xnf [2007/05/24 22:27] 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.
 +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>​
geda/icarus_xnf.txt ยท Last modified: 2012/02/20 15:14 (external edit)