Differences

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

@@ Line 1: / Line 1: @@
+====== FPGA Loadable Code Generator for Icarus Verilog ======
+<code>FPGA LOADABLE CODE GENERATOR FOR Icarus Verilog
+  Copyright 2001 Stephen Williams
+  $Id: fpga.txt,v 1.12 2005/09/19 21:45:36 steve Exp $
+The FPGA code generator supports a variety of FPGA devices, writing
+XNF or EDIF depending on the target. You can select the architecture
+of the device, and the detailed part name. The architecture is used to
+select library primitives, and the detailed part name is written into
+the generated file for the use of downstream tools.
+INVOKING THE FPGA TARGET
+The code generator is invoked with the -tfpga flag to iverilog. It
+understands the part= and the arch= parameters, which can be set with
+the -p flag of iverilog:
+	iverilog -parch=virtex -ppart=v50-pq240-6 -tfpga foo.vl
+This example selects the Virtex architecture, and give the detailed
+part number as v50-pq240-6. The output is written into a.out unless a
+different output file is specified with the -o flag.
+The following is a list of architecture types that this code generator
+supports.
+* arch=lpm
+This is a device independent format, where the gates are device types
+as defined by the LPM 2 1 0 specification. Some backend tools may take
+this format, or users may write interface libraries to connect these
+netlists to the device in question.
+* arch=generic-edif (obsolete)
+This is generic EDIF code. It doesn't necessarily work because the
+external library is not available to the code generator. But, what it
+does is generate generic style gates that a portability library can
+map to target gates if desired.
+* arch=generic-xnf (obsolete)
+If this is selected, then the output is formatted as an XNF file,
+suitable for most any type of device. The devices that it emits
+are generic devices from the unified library. Some devices are macros,
+you may need to further resolve the generated XNF to get working
+code for your part.
+* arch=virtex
+If this is selected, then the output is formatted as an EDIF 200 file,
+suitable for Virtex class devices. This is supposed to know that you
+are targeting a Virtex part, so can generate primitives instead of
+using external macros. It includes the VIRTEX internal library, and
+should work properly for any Virtex part.
+* arch=virtex2
+If this is selected, then the output is EDIF 2 0 0 suitable for
+Virtex-II and Virtex-II Pro devices. It uses the VIRTEX2 library, but
+is very similar to the Virtex target.
+XNF ROOT PORTS
+  NOTE: As parts are moved over to EDIF format, XNF support will be
+  phased out. Current Xilinx implementation tools will accept EDIF
+  format files even for the older parts, and non-Xilinx implementation
+  tools accept nothing else.
+When the output format is XNF, the code generator will generate "SIG"
+records for the signals that are ports of the root module. The name is
+declared as an external pin that this macro makes available.
+The name given to the macro pin is generated from the base name of the
+signal. If the signal is one bit wide, then the pin name is exactly
+the module port name. If the port is a vector, then the pin number is
+given as a vector. For example, the module:
+	module main(out, in);
+	    output out;
+	    input [2:0] in;
+	    [...]
+	endmodule
+leads to these SIG, records:
+	SIG, main/out, PIN=out
+	SIG, main/in<2>, PIN=in2
+	SIG, main/in<1>, PIN=in1
+	SIG, main/in<0>, PIN=in0
+EDIF ROOT PORTS
+The EDIF format is more explicit about the interface into an EDIF
+file. The code generator uses that control to generate an explicit
+interface definition into the design. (This is *not* the same as the
+PADS of a part.) The generated EDIF interface section contains port
+definitions, including the proper direction marks.
+With the (rename ...) s-exp in EDIF, it is possible to assign
+arbitrary text to port names. The EDIF code generator therefore does
+not resort to the mangling that is needed for the XNF target. The base
+name of the signal that is an input or output is used as the name of
+the port, complete with the proper case.
+However, since the ports are single bit ports, the name of vectors
+includes the string "[0]" where the number is the bit number. For
+example, the module:
+	module main(out, in);
+	    output out;
+	    input [2:0] in;
+	    [...]
+	endmodule
+creates these ports:
+	out   OUTPUT
+	in[0] INPUT
+	in[1] INPUT
+	in[2] INPUT
+Target tools, including Xilinx Foundation tools, understand the []
+characters in the name and recollect the signals into a proper bus
+when presenting the vector to the user.
+PADS AND PIN ASSIGNMENT
+The ports of a root module may be assigned to specific pins, or to a
+generic pad. If a signal (that is a port) has a PAD attribute, then
+the value of that attribute is a list of locations, one for each bit
+of the signal, that specifies the pin for each bit of the signal. For
+example:
+	module main( (* PAD = "P10" *)         output out,
+		     (* PAD = "P20,P21,P22" *) input [2:0] in);
+	    [...]
+	endmodule
+In this example, port ``out'' is assigned to pin 10, and port ``in''
+is assigned to pins 20-22. If the architecture supports it, a pin
+number of 0 means let the back end tools choose a pin. The format of
+the pin number depends on the architecture family being targeted, so
+for example Xilinx family devices take the name that is associated
+with the "LOC" attribute.
+NOTE: If a module port is assigned to a pin (and therefore attached to
+a PAD) then it is *not* connected to a port of the EDIF file. This is
+because the PAD (and possibly IBUF or OBUF) would become an extra
+driver to the port. An error.
+SPECIAL DEVICES
+The code generator supports the "cellref" attribute attached to logic
+devices to cause specific device types be generated, instead of the
+usual device that the code generator might generate. For example, to
+get a clock buffer out of a Verilog buf:
+	buf my_gbuf(out, in);
+	$attribute(my_buf, "cellref", "GBUF:O,I");
+The "cellref" attribute tells the code generator to use the given
+cell. The syntax of the value is:
+	<cell type>:<pin name>,...
+The cell type is the name of the library part to use. The pin names
+are the names of the type in the library, in the order that the logic
+device pins are connected.
+COMPILING WITH XILINX FOUNDATION
+Compile a single-file design with command line tools like so:
+	% iverilog -parch=virtex -o foo.edf foo.vl
+	% edif2ngd foo.edf foo.ngo
+	% ngdbuild -p v50-pq240 foo.ngo foo.ngd
+	% map -o map.ncd foo.ngd
+	% par -w map.ncd foo.ncd
+---
+$Log: fpga.txt,v $
+Revision 1.12  2005/09/19 21:45:36  steve
+ Spelling patches from Larry.
+Revision 1.11  2003/08/07 05:17:34  steve
+ Add arch=lpm to the documentation.
+Revision 1.10  2003/07/04 03:57:19  steve
+ Allow attributes on Verilog 2001 port declarations.
+Revision 1.9  2003/07/04 01:08:03  steve
+ PAD attribute can be used to assign pins.
+Revision 1.8  2003/07/02 00:26:49  steve
+ Fix spelling of part= flag.
+Revision 1.7  2003/03/24 02:28:38  steve
+ Document the virtex2 architecture.
+Revision 1.6  2003/03/24 00:47:54  steve
+ Add new virtex2 architecture family, and
+ also the new edif.h EDIF management functions.
+Revision 1.5  2002/04/30 04:26:42  steve
+ Spelling errors.
+Revision 1.4  2001/09/16 22:26:47  steve
+ Support the cellref attribute.
+Revision 1.3  2001/09/16 01:48:16  steve
+ Suppor the PAD attribute on signals.
+Revision 1.2  2001/09/06 04:28:40  steve
+ Separate the virtex and generic-edif code generators.
+Revision 1.1  2001/09/02 23:58:49  steve
+ Add documentation for the code generator.
+</code>

gEDA Project Wiki

User Tools

Site Tools

Differences

Page Tools