Merge pull request verilog-to-routing#3636 from verilog-to-routing/update_bus_based_mux

Adding bus attribute to mux tag

Author: amin1377

doc/src/arch/reference.rst

@@ -1668,13 +1668,16 @@ The following describes the tags that are accepted in the ``<interconnect>`` tag
 
         Direct interconnect example.
 
-.. arch:tag:: <mux name="string" input="string" output="string"/>
+.. arch:tag:: <mux name="string" input="string" output="string" bus="{true|false}"/>
 
     :req_param name: Identifier for the interconnect.
     :req_param input: Pins that are inputs to this interconnect. Different data lines are separated by a space.
     :req_param output: Pins that are outputs of this interconnect.
+    :opt_param bus: Whether this mux selects between multi-bit (bus) data lines.
 
-    This tag supports both single-bit muxes and bus-based muxes. Note that the bit width of each mux input must match the bit width of the mux output.
+        When ``true``, each data line may be a multi-bit bus and the bit width of every mux input must match the bit width of the mux output.
+
+        When ``false`` (the default), every data line and the output must be a single pin.
 
     **Example:**
 
@@ -1686,6 +1689,34 @@ The following describes the tags that are accepted in the ``<interconnect>`` tag
 
         Mux interconnect example.
 
+    **Bus-based example:**
+
+    With ``bus="true"`` each data line may be a multi-bit bus. Every input data
+    line and the output must have the same bit width. In the example below the
+    27-bit buses ``one_mult_27x27.a`` and ``one_mult_27x27.b`` are the two data
+    lines selected onto the 27-bit output ``mult_27x27.a``:
+
+    .. code-block:: xml
+
+        <mux name="a2a" input="one_mult_27x27.a one_mult_27x27.b" output="mult_27x27.a" bus="true"/>
+
+    A data line may also be a bit-slice of a wider port, or a concatenation of
+    pins using ``{...}``; in every case the width of each data line must match
+    the output width. Here each data line is a 27-bit slice of the 54-bit
+    ``mult_27.datain`` bus:
+
+    .. code-block:: xml
+
+        <mux name="datain2a" input="mult_27.datain[26:0] mult_27.datain[53:27]" output="one_mult_27x27.a" bus="true"/>
+
+    .. note::
+
+        ``bus="true"`` is currently a convenience shorthand: VPR expands it into a
+        set of independent single-bit muxes (one per output bit), rather than
+        modeling a true multi-bit bus. This means each single-bit mux gets its own
+        separate config bit, whereas in a true bus-based mux all of the bit-level
+        muxes would share a single config bit.
+
 
 
 A ``<complete>``, ``<direct>``, or ``<mux>`` tag may take one or more additional, optional, ``<pack_pattern>`` tags that are used to describe *molecules*.

libs/libarchfpga/src/physical_types.h

@@ -1110,6 +1110,9 @@ struct t_pin_to_pin_annotation {
  *      annotations: Annotations for delay, power, etc
  *      infer_annotations: This interconnect is autogenerated, if true, infer pack_patterns
  *                         such as carry-chains and forced packs based on interconnect linked to it
+ *      bus: For MUX_INTERC only: when true, each data line may be a multi-bit bus
+ *           (the bit width of every input set must match the output width). When
+ *           false, every input set and the output must be a single pin.
  *      parent_mode_index: Mode of parent as int
  */
 struct t_interconnect {
@@ -1122,6 +1125,8 @@ struct t_interconnect {
     std::vector<t_pin_to_pin_annotation> annotations;
     bool infer_annotations;
 
+    bool bus;
+
     int line_num; /* Interconnect is processed later, need to know what line number it messed up on to give proper error message */
 
     int parent_mode_index;
@@ -1135,6 +1140,7 @@ struct t_interconnect {
     t_interconnect() {
         type = (e_interconnect)0;
         infer_annotations = false;
+        bus = false;
         line_num = 0;
         parent_mode_index = 0;
         parent_mode = nullptr;

libs/libarchfpga/src/read_xml_arch_file.cpp

@@ -1847,17 +1847,26 @@ static void process_interconnect(vtr::string_internment& strings,
     for (auto child_name : {"complete", "direct", "mux"}) {
         pugi::xml_node cur = get_first_child(Parent, child_name, loc_data, ReqOpt::OPTIONAL);
 
+        const bool is_mux = (std::string_view(child_name) == "mux");
+
+        // The optional 'bus' attribute is only valid on <mux> tags
+        std::vector<std::string> expected_attributes = {"name", "input", "output"};
+        if (is_mux) {
+            expected_attributes.emplace_back("bus");
+        }
+
         while (cur != nullptr) {
-            expect_only_attributes(cur, {"name", "input", "output"}, loc_data);
+            expect_only_attributes(cur, expected_attributes, loc_data);
             expect_only_children(cur, {"delay_constant", "delay_matrix", "C_constant", "C_matrix", "pack_pattern", "metadata"}, loc_data);
 
             if (0 == strcmp(cur.name(), "complete")) {
                 mode->interconnect[interconnect_idx].type = COMPLETE_INTERC;
             } else if (0 == strcmp(cur.name(), "direct")) {
                 mode->interconnect[interconnect_idx].type = DIRECT_INTERC;
             } else {
-                VTR_ASSERT(0 == strcmp(cur.name(), "mux"));
+                VTR_ASSERT(is_mux);
                 mode->interconnect[interconnect_idx].type = MUX_INTERC;
+                mode->interconnect[interconnect_idx].bus = get_attribute(cur, "bus", loc_data, ReqOpt::OPTIONAL).as_bool(false);
             }
 
             mode->interconnect[interconnect_idx].line_num = loc_data.line(cur);

vpr/src/pack/pb_type_graph.cpp

@@ -1239,6 +1239,11 @@ static void alloc_and_load_mux_interc_edges(t_interconnect* interconnect,
         }
     }
 
+    if (!interconnect->bus && num_output_ptrs[0] != 1) {
+        vpr_throw(VPR_ERROR_ARCH, get_arch_file_name(), interconnect->line_num,
+                  "Bus-based mux requires the 'bus' attribute to be set to true on the <mux> tag\n");
+    }
+
     /* One edge per (input_set, pin) pair so every edge remains single-pin.
      * For a 1-bit mux this is identical to the original behaviour. */
     const int pins_per_set = num_output_ptrs[0];

vtr_flow/arch/timing/k6_frac_N10_tileable_4add_2chains_depop50_mem20K_22nm.xml

@@ -726,8 +726,8 @@
             <delay_constant max="1.848e-9" in_port="mult_27x27.b" out_port="mult_27x27.out"/>
           </pb_type>
           <interconnect>
-            <mux name="a2a" input="one_mult_27x27.a one_mult_27x27.b" output="mult_27x27.a"/>
-            <mux name="b2b" input="one_mult_27x27.a one_mult_27x27.b" output="mult_27x27.b"/>
+            <mux name="a2a" input="one_mult_27x27.a one_mult_27x27.b" output="mult_27x27.a" bus="true"/>
+            <mux name="b2b" input="one_mult_27x27.a one_mult_27x27.b" output="mult_27x27.b" bus="true"/>
             <direct name="out2out" input="mult_27x27.out" output="one_mult_27x27.out"/>
           </interconnect>
           <power method="pin-toggle">
@@ -741,11 +741,11 @@
               Subtract 72.5 ps delay, which is already in the connection block input mux, leading
               to a 134 ps delay.
                  -->
-          <mux name="datain2a" input="mult_27.datain[26:0] mult_27.datain[53:27]" output="one_mult_27x27.a">
+          <mux name="datain2a" input="mult_27.datain[26:0] mult_27.datain[53:27]" output="one_mult_27x27.a" bus="true">
             <delay_constant max="134e-12" in_port="mult_27.datain[26:0]" out_port="one_mult_27x27.a"/>
             <delay_constant max="134e-12" in_port="mult_27.datain[53:27]" out_port="one_mult_27x27.a"/>
           </mux>
-          <mux name="datain2b" input="mult_27.datain[26:0] mult_27.datain[53:27]" output="one_mult_27x27.b">
+          <mux name="datain2b" input="mult_27.datain[26:0] mult_27.datain[53:27]" output="one_mult_27x27.b" bus="true">
             <delay_constant max="134e-12" in_port="mult_27.datain[26:0]" out_port="one_mult_27x27.b"/>
             <delay_constant max="134e-12" in_port="mult_27.datain[53:27]" out_port="one_mult_27x27.b"/>
           </mux>