Merge pull request #2637 from Wang-Yuanqi-source/patch-1

[WIP] VIB Upgrades for Tileable Routing Resource Graph on OpenFPGA

doc/src/vpr/VIB.rst

@@ -0,0 +1,173 @@
+.. _VIB:
+
+VIB
+============
+The VIB architecture adds modeling support for double-level MUX topology and bent wires.
+
+.. figure:: ../Images/VIB.png
+    :align: center 
+    :height: 300
+
+    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
+
+    Double-level MUX topology.
+
+.. figure:: ../Images/bent_wires.png
+    :align: center
+
+    Presentation for bent wires.
+
+FPGA Architecture File Modification (.xml)
+--------------------------
+For original tags of FPGA architecture file see :ref:`fpga_architecture_description`.
+
+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.
+
+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. 
+
+    :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.
+
+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.
+
+For example:
+
+.. code-block:: xml
+
+    <first_stage switch_name="mux0">
+        <mux name="f_mux_0">
+            <from>clb.O[0] clb.O[8] clb.O[12:16]</from>
+        </mux>
+        <mux name="f_mux_1">
+            <from>L1.E2 L1.W2 L1.S8 L1.N8</from>
+        </mux>
+        ...
+    </first_stage>
+    
+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.
+
+.. arch:tag:: <second_stage>content</second_stage>
+ 	
+    :req_param content:
+    	The details of each MUX.
+
+For example:
+
+.. code-block:: xml
+
+    <second_stage switch_name="mux0">
+        <mux name="s_mux_0">
+            <to>clb.I[0]</to>
+            <from>clb.O[0] clb.O[8] f_mux_0</from>
+        </mux>
+        <mux name="s_mux_1">
+            <to>L1.S1</to>
+            <from>L1.E1 L1.W1 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.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.
+
+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`

doc/src/vpr/index.rst

@@ -60,3 +60,5 @@ The purpose of VPR is to make the packing, placement, and routing stages of the
 
    file_formats
    debug_aids
+
+   VIB

libs/libarchfpga/src/physical_types.h

@@ -47,6 +47,8 @@
 #include "logic_types.h"
 #include "clock_types.h"
 
+#include "vib_inf.h"
+
 //Forward declarations
 struct t_clock_arch;
 struct t_clock_network;
@@ -1629,7 +1631,16 @@ enum e_Fc_type {
  *           For backward compatibility, this attribute is optional. If not  *
  *           specified, the resource type for the segment is considered to   *
  *           be GENERAL.                                                     *
- * meta: Table storing extra arbitrary metadata attributes.                  */
+ * meta: Table storing extra arbitrary metadata attributes.                  *
+ * 
+ * 
+ * New added parameters for bend wires:                                      *
+ * isbend: This segment is bend or not                                       *
+ * bend: The bend type of the segment, "-"-0, "U"-1, "D"-2                   *
+ *       For example: bend pattern <- - U ->; corresponding bend: [0,0,1,0]  *
+ * part_len: Divide the segment into several parts based on bend position.   *
+ *           For example: length-5 bend segment: <- - U ->;                  *
+ *           Corresponding part_len: [3,2]                                   */
 struct t_segment_inf {
     std::string name;
     int frequency;
@@ -1648,6 +1659,9 @@ struct t_segment_inf {
     enum e_parallel_axis parallel_axis;
     std::vector<bool> cb;
     std::vector<bool> sb;
+    bool isbend;                                 
+    std::vector<int> bend;
+    std::vector<int> part_len;
     int seg_index;
     enum SegResType res_type = SegResType::GENERAL;
     //float Cmetal_per_m; /* Wire capacitance (per meter) */
@@ -2048,7 +2062,9 @@ struct t_noc_inf {
     std::string noc_router_tile_name;
 };
 
-/*   Detailed routing architecture */
+
+
+/* Detailed routing architecture */
 struct t_arch {
     /** Stores unique strings used as key and values in <metadata> tags,
      * i.e. implements a flyweight pattern to save memory.*/
@@ -2133,10 +2149,16 @@ struct t_arch {
     //If the layout is not specified in the command line options, this variable will be set to "auto"
     std::string device_layout; 
 
+    std::vector<t_vib_grid_def> vib_grid_layouts;
+
     t_clock_arch_spec clock_arch; // Clock related data types
 
     /// Stores NoC-related architectural information when there is an embedded NoC
     t_noc_inf* noc = nullptr;
+
+    // added for vib
+    //bool is_vib_arch = false;
+    std::vector<VibInf> vib_infs;
 };
 
 #endif