<commit_before>
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:

	% verilog -fpart=4010e -X prog.v

This generates from the prog.v Verilog source file the prog.xnf
output. The verilog program arranges to call the preprocessor and the
ivl compiler with all the correct switches for generating XNF.

XNF PADS IN VERILOG SOURCE

You can assign wires to pads using the Icarus Verilog $attribute
extension. Attach to a scaler 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 recomended 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 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 -Fxnfsyn -Fsigfold -Fxnfio [...]

Icarus Verilog includes the functions ``xnfsyn'' and ``xnfio'' to
perform transformations and optimizations on the design before code is
generated. The xnfsyn function matches certain behavioral constructs
to XNF components, and the xnfio function generates pads and fills the
IOBs.

XNFSYN 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 xnfsyn
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 xnfsyn function.

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 <NAME> (<EMAIL>)
 *
 *    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., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
 */


 $Log: xnf.txt,v $
 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.<commit_msg> XNF synthesis now uses the synth functor.<commit_after>
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:

	% verilog -fpart=4010e -X prog.v

This generates from the prog.v Verilog source file the prog.xnf
output. The verilog program arranges to call the preprocessor and the
ivl compiler with all the correct switches for generating XNF.

XNF PADS IN VERILOG SOURCE

You can assign wires to pads using the Icarus Verilog $attribute
extension. Attach to a scaler 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 recomended 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 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 -Fsigfold -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.

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 <NAME> (<EMAIL>)
 *
 *    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., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
 */


 $Log: xnf.txt,v $
 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.
{'fraction_non_alphanumeric': 0.04709426199397546, 'fraction_numerical': 0.013224597751818383, 'mean_word_length': 4.107692307692307, 'pattern_counts': {'":': 0, '<': 9, '<?xml version=': 0, '>': 9, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2378899', 'n_tokens_mistral': 3983, 'n_tokens_neox': 3680, 'n_words': 2180}