forked from steveicarus/iverilog
-
Notifications
You must be signed in to change notification settings - Fork 1
/
fpga.txt
183 lines (130 loc) · 5.75 KB
/
fpga.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
FPGA LOADABLE CODE GENERATOR FOR Icarus Verilog
Copyright 2001 Stephen Williams
$Id: fpga.txt,v 1.4 2001/09/16 22:26:47 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 -fpart=v50-pq240-6 -tfpga foo.vl
This example selects the virtext 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=generic-edif
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
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 will 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.
XNF ROOT PORTS
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, include 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 numbers, one for each bit of
the signal, that specifies the pin for each bit of the signal. For
example:
module main(out, in);
output out;
input [2:0] in;
[...]
$attribute(out, "PAD", "10");
$attribute(in, "PAD", "20,21,22");
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, then a pin
number of 0 means let the back end tools choose a pin.
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.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.