Skip to content

Commit ea2cea2

Browse files
AlexandreSingerAlexandreSinger
committed
Merge remote-tracking branch 'origin/master' into feature-ap-partial-legalizer
2 parents 32b4629 + 4bea231 commit ea2cea2

File tree

150 files changed

+29408
-1093
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

150 files changed

+29408
-1093
lines changed

‎README.developers.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1644,23 +1644,23 @@ to output the html analysis to a specific folder, run `scan-build make -o /some/
16441644
## General Principles
16451645

16461646
We periodically make 'official' VTR releases.
1647-
While we aim to keep the VTR master branch stable through-out development some users prefer to work of off an official release.
1647+
While we aim to keep the VTR master branch stable through-out development some users prefer to work off of an official release of VTR.
16481648
Historically this has coincided with the publishing of a paper detailing and carefully evaluating the changes from the previous VTR release.
1649-
This is particularly helpful for giving academics a named baseline version of VTR to which they can compare which has a known quality.
1649+
This is particularly helpful for giving academics a named, baseline version of VTR to which they can compare which has a known quality.
16501650

1651-
In preparation for a release it may make sense to produce 'release candidates' which when fully tested and evaluated (and after any bug fixes) become the official release.
1651+
In preparation for a release it may make sense to produce 'release candidates' which, when fully tested and evaluated (and after any bug fixes), become the official release.
16521652

16531653
## Checklist
16541654

16551655
The following outlines the procedure to following when making an official VTR release:
16561656

1657-
* Check the code compiles on the list of supported compilers
1657+
* Check that the code compiles on the list of supported compilers
16581658
* Check that all regression tests pass functionality
16591659
* Update regression test golden results to match the released version
16601660
* Check that all regression tests pass QoR
16611661
* Create a new entry in the CHANGELOG.md for the release, summarizing at a high-level user-facing changes
1662-
* Increment the version number (set in root CMakeLists.txt)
1663-
* Create a git annotated tag (e.g. `v8.0.0`) and push it to github
1662+
* Increment the version number (set in the root CMakeLists.txt)
1663+
* Create a git annotated tag (e.g. `v8.0.0`) and push it to github. Note: tagged releases should always be off of Master, and not off of any other branch. Tagging releases off of other branches can be dangerous since that branch may be deleted in the future and git tools (such as git describe) may rely on tags being on the main development branch (which is master in our case).
16641664
* GitHub will automatically create a release based on the tag
16651665
* Add the new change log entry to the [GitHub release description](https://github.com/verilog-to-routing/vtr-verilog-to-routing/releases)
16661666
* Update the [ReadTheDocs configuration](https://readthedocs.org/projects/vtr/versions/) to build and serve documentation for the relevant tag (e.g. `v8.0.0`)

‎doc/src/Images/VIB.png

28 KB
Loading

‎doc/src/Images/bent_wires.png

356 KB
Loading

‎doc/src/Images/double-level.png

12.6 KB
Loading

‎doc/src/Images/vib_example.png

42.4 KB
Loading

‎doc/src/VIB.rst

Lines changed: 254 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,254 @@
1+
.. _VIB:
2+
3+
VIB Architecture
4+
============
5+
The Versatile Interconnect Block (VIB) architecture adds modeling support for double-level MUX topology and bent wires. In the past, switch blocks had only one level of routing MUXes, whose inputs were 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.
8+
9+
.. figure:: Images/VIB.png
10+
:align: center
11+
:height: 300
12+
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.
14+
15+
.. figure:: Images/double-level.png
16+
:align: center
17+
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.
21+
22+
.. figure:: Images/bent_wires.png
23+
:align: center
24+
25+
Figure 3. Presentation for bent wires.
26+
27+
FPGA Architecture File Modification (.xml)
28+
--------------------------
29+
For the original tags available for the standard FPGA architecture file see :ref:`fpga_architecture_description`.
30+
31+
Modification for ``<segmentlist>`` Tag
32+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
33+
The content within the ``<segmentlist>`` tag consists of a group of ``<segment>`` tags.
34+
The ``<segment>`` tag and its contents are described below.
35+
36+
.. arch:tag:: <segment axis="{x|y}" name="unique_name" length="int" type="{bidir|unidir}" res_type="{GCLK|GENERAL}" freq="float" Rmetal="float" Cmetal="float">content</segment>
37+
38+
:req_param content:
39+
The switch names and the depopulation pattern as described below.
40+
41+
.. arch:tag:: <sb type="pattern">int list</sb>
42+
43+
.. arch:tag:: <cb type="pattern">int list</cb>
44+
45+
.. arch:tag:: <mux name="string"/>
46+
47+
For bent wires, a new content ``<bent>`` is added in the ``<segment>`` tag.
48+
49+
.. arch:tag:: <cb type="pattern">bent pattern list</cb>
50+
51+
This tag describes the bent pattern for this particular wire segment.
52+
For example, a length 4 wire has a bent pattern of ``- - U``.
53+
A ``-`` indicates no bent at this position and a ``U`` indicates a conterclockwise bent at the position. (``D`` indicates a clockwise bent.)
54+
55+
.. note:: A bent wire should remain consistent in both the x and y axes.
56+
57+
New Added Top Level Tag ``<vib_arch>``
58+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
59+
The content within the ``<vib_arch>`` tag consists of a group of ``<vib>`` tags. Different ``<vib>`` tags describe the paradigms of VIB, which apply to different positions.
60+
61+
.. arch:tag:: <vib name="vib_name" pbtype_name="pbtype_name" vib_seg_group="int" arch_vib_switch="string">content</vib>
62+
63+
:req_param name:
64+
A unique alphanumeric name to identify this VIB type.
65+
66+
:req_param pbtype_name:
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.
70+
71+
:req_param vib_seg_group:
72+
The number of the segment types in this VIB.
73+
74+
:req_param arch_vib_switch:
75+
Name of the mux switch type used to drive wires in the VIB by default, and a custom switch can override this switch type for specific connections if desired.
76+
77+
:req_param content:
78+
The segment groups and the multistage MUX topology as described below.
79+
80+
The ``content`` of ``<vib>`` tag consists of several ``<seg_group>`` tags and a ``<multistage_muxs>`` tag.
81+
For example:
82+
83+
.. code-block:: xml
84+
85+
<vib_arch>
86+
<vib name="vib0" pbtype_name="clb" vib_seg_group="4" arch_vib_switch="mux0">
87+
<seg_group name="L1" track_nums="12"/>
88+
<seg_group name="L2" track_nums="20"/>
89+
<seg_group name="L4" track_nums="16"/>
90+
<seg_group name="L8" track_nums="16"/>
91+
<multistage_muxs>
92+
<first_stage switch_name="mux0">
93+
...
94+
</first_stage>
95+
<second_stage>
96+
...
97+
</second_stage>
98+
</multistage_muxs>
99+
</vib>
100+
<vib name="vib1" pbtype_name="dsp" vib_seg_group="4" arch_vib_switch="mux0">
101+
...
102+
</vib>
103+
</vib_arch>
104+
105+
.. arch:tag:: <seg_group name="seg_name" track_nums="int"/>
106+
107+
:req_param name:
108+
The name of the segment in this VIB described in ``<segmentlist>``.
109+
110+
:req_param track_nums:
111+
The track number of the segment in this VIB.
112+
113+
.. note:: When using unidirectional segments, the track number of the segment represents the number for one direction. For example, the ``track_nums`` is ``10``, which means total ``20`` tracks of the segment in the channel for both (INC & DEC) directions.
114+
115+
.. arch:tag:: <multistage_muxs>content</multistage_muxs>
116+
117+
:req_param content:
118+
The detailed information for first and second MUXes.
119+
120+
The ``content`` of ``<multistage_muxs>`` tag consists of a ``<first_stage>`` tag and a ``<secong_stage>`` tag.
121+
122+
.. arch:tag:: <first_stage switch_name="switch_name">content</first_stage>
123+
124+
:req_param switch_name:
125+
Name of the mux switch type used to drive first stage MUXes in the VIB.
126+
127+
:req_param content:
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.
139+
140+
For example:
141+
142+
.. code-block:: xml
143+
144+
<first_stage switch_name="mux0">
145+
<mux name="f_mux_0">
146+
<from>clb.O[0] clb.O[1:3] clb.O[4]</from>
147+
</mux>
148+
<mux name="f_mux_1">
149+
<from>L1.E1 L1.S1 L2.E0</from>
150+
</mux>
151+
...
152+
</first_stage>
153+
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.
155+
156+
.. arch:tag:: <second_stage>content</second_stage>
157+
158+
:req_param content:
159+
The details of each MUX.
160+
161+
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.
170+
171+
For example:
172+
173+
.. code-block:: xml
174+
175+
<second_stage switch_name="mux0">
176+
<mux name="s_mux_0">
177+
<to>clb.I[0]</to>
178+
<from>clb.O[4] f_mux_0 f_mux_1</from>
179+
</mux>
180+
<mux name="s_mux_1">
181+
<to>L1.E1</to>
182+
<from>L1.S2 f_mux_0 f_mux_1</from>
183+
</mux>
184+
...
185+
</second_stage>
186+
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.
188+
189+
Here is a complete example of the ``<vib>`` tag:
190+
191+
.. code-block:: xml
192+
193+
<vib name="vib_clb" pbtype_name="clb" vib_seg_group="2" arch_vib_switch="mux0">
194+
<seg_group name="L1" track_nums="12"/>
195+
<seg_group name="L2" track_nums="20"/>
196+
<multistage_muxs>
197+
<first_stage switch_name="mux0">
198+
<mux name="f_mux_0">
199+
<from>clb.O[0] clb.O[1:3] clb.O[4]</from>
200+
</mux>
201+
<mux name="f_mux_1">
202+
<from>L1.E1 L1.S1 L2.E0</from>
203+
</mux>
204+
</first_stage>
205+
<second_stage>
206+
<mux name="s_mux_0">
207+
<to>clb.I[0]</to>
208+
<from>clb.O[4] f_mux_0 f_mux_1</from>
209+
</mux>
210+
<mux name="s_mux_1">
211+
<to>L1.E1</to>
212+
<from>L1.S2 f_mux_0 f_mux_1</from>
213+
</mux>
214+
</second_stage>
215+
</multistage_muxs>
216+
</vib>
217+
218+
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.
225+
226+
New Added Top Level Tag ``<vib_layout>``
227+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
228+
Content inside this tag specifies VIB grid layout to describe different VIBs applied on different locations.
229+
230+
.. arch:tag:: <fixed_layout name="string">content</fixed_layout>
231+
232+
:req_param name:
233+
The name identifying this VIB grid layout. It should be the same as the corresponding layout name inside the ``<layout>`` tag.
234+
235+
:req_param content:
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`
237+
238+
For example:
239+
240+
.. code-block:: xml
241+
242+
<vib_layout>
243+
<fixed_layout name="fixed_layout">
244+
<perimeter type="vib_IO" priority="101"/>
245+
<fill type="vib_clb" priority="10"/>
246+
<col type="vib_memory" startx="5" starty="1" priority="100"/>
247+
...
248+
</fixed_layout>
249+
</vib_layout>
250+
251+
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 attribute ``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

Comments
 (0)