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/VIB.rst
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
3
3
VIB Architecture
4
4
============
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.
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
6
7
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
8
@@ -26,7 +26,7 @@ Figure 3 shows the modeling for bent wires. A bent L-length wire is modeled as t
26
26
27
27
FPGA Architecture File Modification (.xml)
28
28
--------------------------
29
-
For original tags of FPGA architecture file see :ref:`fpga_architecture_description`.
29
+
For the original tags available for the standard FPGA architecture file see :ref:`fpga_architecture_description`.
The detaild information for first and second MUXes.
118
+
The detailed information for first and second MUXes.
119
119
120
120
The ``content`` of ``<multistage_muxs>`` tag consists of a ``<first_stage>`` tag and a ``<secong_stage>`` tag.
121
121
@@ -248,7 +248,7 @@ For example:
248
248
</fixed_layout>
249
249
</vib_layout>
250
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 attibute ``type`` should correspond to the ``name`` of a ``<vib>`` tag in ``<vib_arch>``.
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
252
Besides, the ``pbtype_name`` of corresponding ``<vib>`` must be the same as the physical block type at this position.
253
253
254
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.
Turn ``on``/``off`` the tileable routing resource graph generator.
2699
2699
2700
-
Tileable routing architecture can minimize the number of unique modules in FPGA fabric to be physically implemented.
2700
+
The tileable routing architecture can minimize the number of unique modules in FPGA fabric to be physically implemented.
2701
2701
2702
2702
Technical details can be found in :cite:`XTang_FPT_2019`.
2703
2703
2704
-
.. note:: It is strongly recommended to to enable the tileable routing architecture when you want to PnR large FPGA fabrics, which can effectively reduce the runtime.
2704
+
.. note:: It is strongly recommended to enable the tileable routing architecture when you want to PnR large FPGA fabrics, which can effectively reduce the runtime.
2705
2705
2706
2706
.. option:: through_channel="<bool>"
2707
2707
@@ -2718,11 +2718,11 @@ Layout
2718
2718
2719
2719
.. warning:: Do NOT enable ``through_channel`` if you are not using the tileable routing resource graph generator!
2720
2720
2721
-
.. warning:: You cannot use ``spread`` pin location for the ``height > 1`` or ``width >1`` tiles when using the tileable routing resource graph!!! Otherwise, it will cause undriven pins in your device!!!
2721
+
.. warning:: You cannot use ``spread`` pin location for the ``height > 1`` or ``width >1`` tiles when using the tileable routing resource graph. Otherwise, it will cause undriven pins in your device!!!
2722
2722
2723
2723
.. option:: shrink_boundary="<bool>"
2724
2724
2725
-
Remove all the routing wires in empty regions. This is mainly used in non-rectangle FPGAs to avoid redundant routing wires in blank area, as illustrated in :numref:`fig_shrink_boundary`.
2725
+
Remove all the routing wires in empty regions. This is mainly used in non-rectangular FPGAs to avoid redundant routing wires in blank area, as illustrated in :numref:`fig_shrink_boundary`.
2726
2726
By default, it is ``false``.
2727
2727
2728
2728
.. _fig_shrink_boundary:
@@ -2737,10 +2737,11 @@ Layout
2737
2737
2738
2738
.. option:: perimeter_cb="<bool>"
2739
2739
2740
-
Allow connection blocks to appear around the perimeter programmable block (mainly I/Os). This is designed to enhance routability of I/Os on perimeter. Also strongly recommended when programmable clock network is required to touch clock pins on I/Os. As illustrated in :numref:`fig_perimeter_cb`, routing tracks can access three sides of each I/O when perimeter connection blocks are created.
2741
-
By default, it is ``false``.
2740
+
Allow connection blocks to appear around the blocks on the perimeter of the device (mainly I/Os). This is designed to enhance routability of I/Os on perimeter. It is also strongly recommended when a programmable clock network is required to touch clock pins on I/Os. As illustrated in :numref:`fig_perimeter_cb`, routing tracks can access three sides of each I/O when perimeter connection blocks are created.
2741
+
2742
+
**Default:** ``false``
2742
2743
2743
-
.. warning:: When enabled, please only place outputs at one side of I/Os. For example, outputs of an I/O on the top side can only occur on the bottom side of the I/O tile. Otherwise, routability loss may be expected, leading to some pins cannot be reachable. Enable the ``opin2all_sides`` to recover routability loss.
2744
+
.. warning:: When enabled, please only place outputs at one side of I/Os. For example, outputs of an I/O on the top side can only occur on the bottom side of the I/O tile. Otherwise, routability loss may be expected, leading to some pins being unreachable. Enable the ``opin2all_sides`` to recover routability loss.
2744
2745
2745
2746
.. _fig_perimeter_cb:
2746
2747
@@ -2755,7 +2756,8 @@ Layout
2755
2756
.. option:: opin2all_sides="<bool>"
2756
2757
2757
2758
Allow each output pin of a programmable block to drive the routing tracks on all the sides of its adjacent switch block (see an illustrative example in :numref:`fig_opin2all_sides`). This can improve the routability of an FPGA fabric with an increase in the sizes of routing multiplexers in each switch block.
2758
-
By default, it is ``false``.
2759
+
2760
+
**Default:** ``false``
2759
2761
2760
2762
.. _fig_opin2all_sides:
2761
2763
@@ -2770,7 +2772,8 @@ Layout
2770
2772
.. option:: concat_wire="<bool>"
2771
2773
2772
2774
In each switch block, allow each routing track which ends to drive another routing track on the opposite side, as such a wire can be continued in the same direction (see an illustrative example in :numref:`fig_concat_wire`). In other words, routing wires can be concatenated in the same direction across an FPGA fabric. This can improve the routability of an FPGA fabric with an increase in the sizes of routing multiplexers in each switch block.
2773
-
By default, it is ``false``.
2775
+
2776
+
**Default:** ``false``
2774
2777
2775
2778
.. _fig_concat_wire:
2776
2779
@@ -2785,9 +2788,8 @@ Layout
2785
2788
.. option:: concat_pass_wire="<bool>"
2786
2789
2787
2790
In each switch block, allow each routing track which passes to drive another routing track on the opposite side, as such a pass wire can be continued in the same direction (see an illustrative example in :numref:`fig_concat_pass_wire`). This can improve the routability of an FPGA fabric with an increase in the sizes of routing multiplexers in each switch block.
2788
-
By default, it is ``false``.
2789
-
2790
-
.. warning:: Please enable this option if you are looking for device support which is created by any release which is before v1.1.541!!!
2791
+
2792
+
**Default:** ``false``
2791
2793
2792
2794
.. _fig_concat_wire:
2793
2795
@@ -2813,14 +2815,14 @@ Switch Block
2813
2815
2814
2816
.. option:: sub_type="<string>"
2815
2817
2816
-
Connecting type for pass tracks in each switch block
2817
-
The supported connecting patterns are ``subset``, ``universal`` and ``wilton``, being the same as VPR capability
2818
-
If not specified, the pass tracks will the same connecting patterns as start/end tracks, which are defined in ``type``
2818
+
Connecting type for pass tracks in each switch block.
2819
+
The supported connecting patterns are ``subset``, ``universal`` and ``wilton``, being the same as the capability of VPR.
2820
+
If not specified, the pass tracks will have the same connecting patterns as start/end tracks, which are defined in ``type``
2819
2821
2820
2822
.. option:: sub_Fs="<int>"
2821
2823
2822
2824
Connectivity parameter for pass tracks in each switch block. Must be a multiple of 3.
2823
-
If not specified, the pass tracks will the same connectivity as start/end tracks, which are defined in ``fs``
2825
+
If not specified, the pass tracks will have the same connectivity as start/end tracks, which are defined in ``fs``.
2824
2826
2825
2827
A quick example which defines a switch block
2826
2828
- Starting/ending routing tracks are connected in the ``wilton`` pattern
@@ -2837,7 +2839,8 @@ A quick example which defines a switch block
2837
2839
Routing Segments
2838
2840
~~~~~~~~~~~~~~~~
2839
2841
2840
-
OpenFPGA suggests users to give explicit names for each routing segement in ``<segmentlist>``
2842
+
When using tileable architecture, it is strongly recommended to give explicit names
2843
+
for each routing segment in ``<segmentlist>``.
2841
2844
This is used to link ``circuit_model`` to routing segments.
2842
2845
2843
2846
A quick example which defines a length-4 uni-directional routing segment called ``L4`` :
@@ -2848,7 +2851,7 @@ A quick example which defines a length-4 uni-directional routing segment called
2848
2851
<segmentname="L4"freq="1"length="4"type="undir"/>
2849
2852
</segmentlist>
2850
2853
2851
-
.. note:: Currently, OpenFPGA only supports uni-directional routing architectures
2854
+
.. note:: Currently, tileable architecture only supports uni-directional routing architectures.
2852
2855
2853
2856
Direct Interconnect
2854
2857
~~~~~~~~~~~~~~~~~~~
@@ -2868,7 +2871,7 @@ The original direct connections in the directlist section are documented in :ref
2868
2871
2869
2872
.. note:: These options are required
2870
2873
2871
-
In the OpenFPGA architecture file, you may define additional attributes for each VPR's direct connection:
2874
+
In the tileable architecture file, you may define additional attributes for each VPR's direct connection:
2872
2875
2873
2876
.. code-block:: xml
2874
2877
@@ -2926,7 +2929,7 @@ In the OpenFPGA architecture file, you may define additional attributes for each
2926
2929
Enhanced Connection Block
2927
2930
~~~~~~~~~~~~~~~~~~~~~~~~~
2928
2931
2929
-
The direct connection can also drive routing multiplexers of connection blocks. When such connection occures in a connection block, it is called enhanced connection block.
2932
+
A direct connection can also drive routing multiplexers of connection blocks. When such connection occurs in a connection block, it is called an enhanced connection block.
2930
2933
:numref:`fig_ecb` illustrates the difference between a regular connection block and an enhanced connection block.
2931
2934
2932
2935
.. _fig_ecb:
@@ -2956,7 +2959,7 @@ Direct connections can be inside a tile or across two tiles. Currently, across m
2956
2959
2957
2960
Example of feedback connections inside a tile for enhanced connection block
2958
2961
2959
-
For instance, VPR architecture defines feedback connections like:
2962
+
For instance, a non-tileable VPR architecture defines:
2960
2963
2961
2964
.. code-block:: xml
2962
2965
@@ -2987,15 +2990,15 @@ Inter-tile Connections
2987
2990
2988
2991
For this example, we will study a scan-chain implementation. The description could be:
In this figure, the red arrows represent the initial direct connection. The green arrows represent the point to point connection to connect all the columns of CLB.
3016
3019
3017
-
A point to point connection can be applied in different ways than showed in the example section. To help the designer implement his point to point connection, a truth table with our new parameters id provided below.
3020
+
A point to point connection can be applied in different ways than showed in the example section. To help the designer implement their point to point connection, a truth table with our new parameters is provided below.
3018
3021
3019
3022
:numref:`fig_p2p_trtable` provides all possible variable combination and the connection it will generate.
0 commit comments