You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/src/vpr/VIB.rst
+93-12Lines changed: 93 additions & 12 deletions
Original file line number
Diff line number
Diff line change
@@ -1,24 +1,28 @@
1
1
.. _VIB:
2
2
3
-
VIB
3
+
VIB Architecture
4
4
============
5
-
The VIB architecture adds modeling support for double-level MUX topology and bent wires.
5
+
The VIB architecture adds modeling support for double-level MUX topology and bent wires. In past, switch blocks have only one level of routing MUXes, whose inputs are driven by outputs of programmable blocks and routing tracks. Now outputs of programmable blocks can shape the first level of routing MUXes, while the inputs of second level involves the outputs of first level and other routing tracks. This can reduce the number and input sizes of routing MUXes.
6
+
7
+
Figure 1 shows the proposed VIB architecture which is tile-based. Each tile is composed of a CLB and a VIB. Each CLB can interact with the corresponding VIB which contains all the routing programmable switches in one tile. Figure 2 shows an example of the detailed interconnect architecture in VIB. The CLB input muxes and the driving muxes of wire segments can share the same fanins. A routing path of a net with two sinks is presented red in the Figure.
6
8
7
9
.. figure:: ../Images/VIB.png
8
10
:align:center
9
11
:height:300
10
12
11
-
VIB architecture. The connections between the inputs and outputs of the LB and the routing wires are all implemented within the VIB.
13
+
Figure 1. VIB architecture. The connections between the inputs and outputs of the LB and the routing wires are all implemented within the VIB.
12
14
13
15
.. figure:: ../Images/double-level.png
14
16
:align:center
15
17
16
-
Double-level MUX topology.
18
+
Figure 2. Double-level MUX topology.
19
+
20
+
Figure 3 shows the modeling for bent wires. A bent L-length wire is modeled as two segments in CHANX and CHANY respectively connected by a delayless switch. The orange and red arrows represent conterclockwise and clockwise bent wires respectively. The bent wires can connect to both bent and straight wire segments.
17
21
18
22
.. figure:: ../Images/bent_wires.png
19
23
:align:center
20
24
21
-
Presentation for bent wires.
25
+
Figure 3. Presentation for bent wires.
22
26
23
27
FPGA Architecture File Modification (.xml)
24
28
--------------------------
@@ -61,6 +65,8 @@ The content within the ``<vib_arch>`` tag consists of a group of ``<vib>`` tags.
61
65
62
66
:req_param pbtype_name:
63
67
The name of the block type (e.g. clb, memory) that this VIB connects to.
68
+
69
+
.. note:: A block (e.g. clb, dsp) is connected to the VIB on its top-right side, so the input and output pins of the block should be on the top or right side.
64
70
65
71
:req_param vib_seg_group:
66
72
The number of the segment types in this VIB.
@@ -120,27 +126,47 @@ The ``content`` of ``<multistage_muxs>`` tag consists of a ``<first_stage>`` tag
120
126
121
127
:req_param content:
122
128
The details of each MUX.
129
+
130
+
The ``content`` of ``<first_stage>`` tag consists of many ``<mux>`` tags.
131
+
132
+
.. arch:tag:: <mux name="mux_name">content</mux>
133
+
134
+
:req_param name:
135
+
Name of the MUX.
136
+
137
+
:req_param content:
138
+
A ``<from>`` tag to describe what pins and wires connect to this MUX.
123
139
124
140
For example:
125
141
126
142
.. code-block:: xml
127
143
128
144
<first_stageswitch_name="mux0">
129
145
<muxname="f_mux_0">
130
-
<from>clb.O[0] clb.O[8] clb.O[12:16]</from>
146
+
<from>clb.O[0] clb.O[1:3] clb.O[4]</from>
131
147
</mux>
132
148
<muxname="f_mux_1">
133
-
<from>L1.E2 L1.W2 L1.S8 L1.N8</from>
149
+
<from>L1.E1 L1.S1 L2.E0</from>
134
150
</mux>
135
151
...
136
152
</first_stage>
137
153
138
-
The ``<from>`` tag in ``<mux>`` describes nodes that connects to the MUX. ``clb.O[*]`` means output pin(s); ``L1.E2`` means the track ``2`` in the ``East`` direction of ``L1`` segment.
154
+
The ``<from>`` tag in ``<mux>`` describes nodes that connects to the MUX. ``clb.O[*]`` means output pin(s); ``L1.E1`` means the track ``1`` in the ``East`` direction of ``L1`` segment.
The ``content`` of ``<second_stage>`` tag consists of many ``<mux>`` tags.
162
+
163
+
.. arch:tag:: <mux name="mux_name">content</mux>
164
+
165
+
:req_param name:
166
+
Name of the MUX.
167
+
168
+
:req_param content:
169
+
A ``<to>`` tag to describe where this MUX connect to and a ``<from>`` tag to describe what pins and wires connect to this MUX.
144
170
145
171
For example:
146
172
@@ -149,16 +175,53 @@ For example:
149
175
<second_stageswitch_name="mux0">
150
176
<muxname="s_mux_0">
151
177
<to>clb.I[0]</to>
152
-
<from>clb.O[0] clb.O[8] f_mux_0</from>
178
+
<from>clb.O[4] f_mux_0 f_mux_1</from>
153
179
</mux>
154
180
<muxname="s_mux_1">
155
-
<to>L1.S1</to>
156
-
<from>L1.E1 L1.W1 f_mux_0 f_mux_1</from>
181
+
<to>L1.E1</to>
182
+
<from>L1.S2 f_mux_0 f_mux_1</from>
157
183
</mux>
158
184
...
159
185
</second_stage>
160
186
161
-
The ``<to>`` tag describes the node this MUX connects to. ``clb.I[*]`` means input pin(s); ``L1.S1`` means the track ``1`` in the ``South`` direction of ``L1`` segment. The ``<from>`` tag in ``<mux>`` describes nodes that connects to the MUX. ``clb.O[*]`` means output pin(s); ``L1.E2`` means the track ``2`` in the ``East`` direction of ``L1`` segment. ``f_mux_0`` means the name of the specific first stage MUX.
187
+
The ``<to>`` tag describes the node this MUX connects to. ``clb.I[*]`` means input pin(s); ``L1.E1`` means the track ``1`` in the ``East`` direction of ``L1`` segment. The ``<from>`` tag in ``<mux>`` describes nodes that connects to the MUX. ``clb.O[*]`` means output pin(s); ``L1.S2`` means the track ``2`` in the ``South`` direction of ``L1`` segment. ``f_mux_0`` means the name of the specific first stage MUX.
Its corresponding detailed architecture is shown in Figure 4.
219
+
220
+
.. figure:: ../Images/vib_example.png
221
+
:align:center
222
+
:height:600
223
+
224
+
Figure 4. The corresponding detaied architecture of the example.
162
225
163
226
New Added Top Level Tag ``<vib_layout>``
164
227
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -171,3 +234,21 @@ Content inside this tag specifies VIB grid layout to describe different VIBs app
171
234
172
235
:req_param content:
173
236
The content should contain a set of grid location tags. For grid location tags of vib_layout see :ref:`fpga_architecture_description`; ref:`grid_expressions`
In this VIB grid layout, ``perimeter``, ``fill``, ``col`` and so on are tags in original ``<layout>`` tag to describe positions of each type of VIB block. The attibute ``type`` should correspond to the ``name`` of a ``<vib>`` tag in ``<vib_arch>``.
252
+
Besides, the ``pbtype_name`` of corresponding ``<vib>`` must be the same as the physical block type at this position.
253
+
254
+
In this example, IO blocks are located on the perimeter of the layout. Memory blocks are on column 5 and CLBs are on the rest positions. The ``vib_io``, ``vib_clb`` and ``vib_memory`` are different types of vib blocks corresponding to IO, CLB and memory blocks respectively.
0 commit comments