-
Notifications
You must be signed in to change notification settings - Fork 419
Add tileable RR Graph #3134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Add tileable RR Graph #3134
Changes from all commits
b6371d2
77781b4
cf95e2c
431923c
d62fb79
02a56e9
204a794
7edf56d
f5e8061
14064c7
49b04b0
c6df91a
bf19150
3970db7
797b488
cf2dbc8
0e03dc7
f8fae78
5462ccd
7cdf5bf
5ad8303
c79ab8f
8eccbcc
0cc6f10
5a492c8
1fd866e
5580c86
a27f6ba
8625ff0
57c1919
29c9677
b6fdda3
2b68252
65102b9
757e2f7
2b2fbb4
6e5070c
43ac8b4
5436025
09c90f2
e3df5b5
e08cd8c
9c87418
0df7730
837278b
7c6a979
ca95008
bb9a338
af27706
4194e81
561a0d5
07d4bac
4e38274
f324567
1f929ea
bc7ffcd
9cf3775
5f1939c
bd62d9f
1d1318d
4c60c9d
70836c5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,254 @@ | ||
.. _VIB: | ||
|
||
VIB Architecture | ||
============ | ||
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. | ||
|
||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it would be a good idea to spell out what the acronym "VIB" means in this context. "Versatile Interconnect Block (VIB)" or something just so its written down somewhere on this page. |
||
|
||
.. figure:: Images/VIB.png | ||
:align: center | ||
:height: 300 | ||
|
||
Figure 1. VIB architecture. The connections between the inputs and outputs of the LB and the routing wires are all implemented within the VIB. | ||
|
||
.. figure:: Images/double-level.png | ||
:align: center | ||
|
||
Figure 2. Double-level MUX topology. | ||
|
||
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. | ||
|
||
.. figure:: Images/bent_wires.png | ||
:align: center | ||
|
||
Figure 3. Presentation for bent wires. | ||
|
||
FPGA Architecture File Modification (.xml) | ||
-------------------------- | ||
For original tags of FPGA architecture file see :ref:`fpga_architecture_description`. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I suggest: "For the original tags available for the standard FPGA architecture file see" I feel like it can get confusing with all the architecture file words being thrown around. |
||
|
||
Modification for ``<segmentlist>`` Tag | ||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
The content within the ``<segmentlist>`` tag consists of a group of ``<segment>`` tags. | ||
The ``<segment>`` tag and its contents are described below. | ||
|
||
.. 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> | ||
:req_param content: | ||
The switch names and the depopulation pattern as described below. | ||
|
||
.. arch:tag:: <sb type="pattern">int list</sb> | ||
.. arch:tag:: <cb type="pattern">int list</cb> | ||
.. arch:tag:: <mux name="string"/> | ||
For bent wires, a new content ``<bent>`` is added in the ``<segment>`` tag. | ||
|
||
.. arch:tag:: <cb type="pattern">bent pattern list</cb> | ||
This tag describes the bent pattern for this particular wire segment. | ||
For example, a length 4 wire has a bent pattern of ``- - U``. | ||
A ``-`` indicates no bent at this position and a ``U`` indicates a conterclockwise bent at the position. (``D`` indicates a clockwise bent.) | ||
|
||
.. note:: A bent wire should remain consistent in both the x and y axes. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What does consistent mean in this context? If you know it may be a good idea to expand on this if this is important. |
||
|
||
New Added Top Level Tag ``<vib_arch>`` | ||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
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. | ||
|
||
.. arch:tag:: <vib name="vib_name" pbtype_name="pbtype_name" vib_seg_group="int" arch_vib_switch="string">content</vib> | ||
:req_param name: | ||
A unique alphanumeric name to identify this VIB type. | ||
|
||
:req_param pbtype_name: | ||
The name of the block type (e.g. clb, memory) that this VIB connects to. | ||
|
||
.. 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. | ||
|
||
:req_param vib_seg_group: | ||
The number of the segment types in this VIB. | ||
|
||
:req_param arch_vib_switch: | ||
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. | ||
|
||
:req_param content: | ||
The segment groups and the multistage MUX topology as described below. | ||
|
||
The ``content`` of ``<vib>`` tag consists of several ``<seg_group>`` tags and a ``<multistage_muxs>`` tag. | ||
For example: | ||
|
||
.. code-block:: xml | ||
<vib_arch> | ||
<vib name="vib0" pbtype_name="clb" vib_seg_group="4" arch_vib_switch="mux0"> | ||
<seg_group name="L1" track_nums="12"/> | ||
<seg_group name="L2" track_nums="20"/> | ||
<seg_group name="L4" track_nums="16"/> | ||
<seg_group name="L8" track_nums="16"/> | ||
<multistage_muxs> | ||
<first_stage switch_name="mux0"> | ||
... | ||
</first_stage> | ||
<second_stage> | ||
... | ||
</second_stage> | ||
</multistage_muxs> | ||
</vib> | ||
<vib name="vib1" pbtype_name="dsp" vib_seg_group="4" arch_vib_switch="mux0"> | ||
... | ||
</vib> | ||
</vib_arch> | ||
.. arch:tag:: <seg_group name="seg_name" track_nums="int"/> | ||
:req_param name: | ||
The name of the segment in this VIB described in ``<segmentlist>``. | ||
|
||
:req_param track_nums: | ||
The track number of the segment in this VIB. | ||
|
||
.. 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. | ||
|
||
.. arch:tag:: <multistage_muxs>content</multistage_muxs> | ||
:req_param content: | ||
The detaild information for first and second MUXes. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "detaild" -> "detailed" |
||
|
||
The ``content`` of ``<multistage_muxs>`` tag consists of a ``<first_stage>`` tag and a ``<secong_stage>`` tag. | ||
|
||
.. arch:tag:: <first_stage switch_name="switch_name">content</first_stage> | ||
:req_param switch_name: | ||
Name of the mux switch type used to drive first stage MUXes in the VIB. | ||
|
||
:req_param content: | ||
The details of each MUX. | ||
|
||
The ``content`` of ``<first_stage>`` tag consists of many ``<mux>`` tags. | ||
|
||
.. arch:tag:: <mux name="mux_name">content</mux> | ||
:req_param name: | ||
Name of the MUX. | ||
|
||
:req_param content: | ||
A ``<from>`` tag to describe what pins and wires connect to this MUX. | ||
|
||
For example: | ||
|
||
.. code-block:: xml | ||
<first_stage switch_name="mux0"> | ||
<mux name="f_mux_0"> | ||
<from>clb.O[0] clb.O[1:3] clb.O[4]</from> | ||
</mux> | ||
<mux name="f_mux_1"> | ||
<from>L1.E1 L1.S1 L2.E0</from> | ||
</mux> | ||
... | ||
</first_stage> | ||
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. | ||
|
||
.. arch:tag:: <second_stage>content</second_stage> | ||
:req_param content: | ||
The details of each MUX. | ||
|
||
The ``content`` of ``<second_stage>`` tag consists of many ``<mux>`` tags. | ||
|
||
.. arch:tag:: <mux name="mux_name">content</mux> | ||
:req_param name: | ||
Name of the MUX. | ||
|
||
:req_param content: | ||
A ``<to>`` tag to describe where this MUX connect to and a ``<from>`` tag to describe what pins and wires connect to this MUX. | ||
|
||
For example: | ||
|
||
.. code-block:: xml | ||
<second_stage switch_name="mux0"> | ||
<mux name="s_mux_0"> | ||
<to>clb.I[0]</to> | ||
<from>clb.O[4] f_mux_0 f_mux_1</from> | ||
</mux> | ||
<mux name="s_mux_1"> | ||
<to>L1.E1</to> | ||
<from>L1.S2 f_mux_0 f_mux_1</from> | ||
</mux> | ||
... | ||
</second_stage> | ||
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. | ||
|
||
Here is a complete example of the ``<vib>`` tag: | ||
|
||
.. code-block:: xml | ||
<vib name="vib_clb" pbtype_name="clb" vib_seg_group="2" arch_vib_switch="mux0"> | ||
<seg_group name="L1" track_nums="12"/> | ||
<seg_group name="L2" track_nums="20"/> | ||
<multistage_muxs> | ||
<first_stage switch_name="mux0"> | ||
<mux name="f_mux_0"> | ||
<from>clb.O[0] clb.O[1:3] clb.O[4]</from> | ||
</mux> | ||
<mux name="f_mux_1"> | ||
<from>L1.E1 L1.S1 L2.E0</from> | ||
</mux> | ||
</first_stage> | ||
<second_stage> | ||
<mux name="s_mux_0"> | ||
<to>clb.I[0]</to> | ||
<from>clb.O[4] f_mux_0 f_mux_1</from> | ||
</mux> | ||
<mux name="s_mux_1"> | ||
<to>L1.E1</to> | ||
<from>L1.S2 f_mux_0 f_mux_1</from> | ||
</mux> | ||
</second_stage> | ||
</multistage_muxs> | ||
</vib> | ||
Its corresponding detailed architecture is shown in Figure 4. | ||
|
||
.. figure:: Images/vib_example.png | ||
:align: center | ||
:height: 600 | ||
|
||
Figure 4. The corresponding detaied architecture of the example. | ||
|
||
New Added Top Level Tag ``<vib_layout>`` | ||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
Content inside this tag specifies VIB grid layout to describe different VIBs applied on different locations. | ||
|
||
.. arch:tag:: <fixed_layout name="string">content</fixed_layout> | ||
:req_param name: | ||
The name identifying this VIB grid layout. It should be the same as the corresponding layout name inside the ``<layout>`` tag. | ||
|
||
:req_param content: | ||
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` | ||
|
||
For example: | ||
|
||
.. code-block:: xml | ||
<vib_layout> | ||
<fixed_layout name="fixed_layout"> | ||
<perimeter type="vib_IO" priority="101"/> | ||
<fill type="vib_clb" priority="10"/> | ||
<col type="vib_memory" startx="5" starty="1" priority="100"/> | ||
... | ||
</fixed_layout> | ||
</vib_layout> | ||
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>``. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "attibute" -> "attribute" |
||
Besides, the ``pbtype_name`` of corresponding ``<vib>`` must be the same as the physical block type at this position. | ||
|
||
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"In past" -> "In the past"
"switch blocks have" -> "switch blocks had"
"whose inputs are driven" -> "whose inputs were driven"