Merge branch 'master' into temp_net_cost_ref

Author: soheilshahrouz

.github/workflows/nightly_test.yml

@@ -62,9 +62,9 @@ jobs:
           - {test: "vtr_reg_strong",             cores: "16", options: "",          cmake: "-DVTR_ASSERT_LEVEL=3",                                         extra_pkgs: "libeigen3-dev"}
           - {test: "vtr_reg_strong_odin",        cores: "16", options: "",          cmake: "-DVTR_ASSERT_LEVEL=3 -DWITH_ODIN=ON",                          extra_pkgs: "libeigen3-dev"}
           - {test: "vtr_reg_strong_odin",        cores: "16", options: "-skip_qor", cmake: "-DVTR_ASSERT_LEVEL=3 -DVTR_ENABLE_SANITIZE=ON -DWITH_ODIN=ON", extra_pkgs: "libeigen3-dev"}
-          - {test: "vtr_reg_system_verilog",     cores: "16", options: "",          cmake: "-DYOSYS_F4PGA_PLUGINS=ON",                                     extra_pkgs: ""}
+          # - {test: "vtr_reg_system_verilog",     cores: "16", options: "",          cmake: "-DYOSYS_F4PGA_PLUGINS=ON",                                     extra_pkgs: ""} # Test turned off -> F4PGA conflicts with Yosys (version 42)
           - {test: "odin_reg_strong",            cores: "16", options: "",          cmake: "-DWITH_ODIN=ON",                                               extra_pkgs: ""}
-          - {test: "parmys_reg_strong",          cores: "16", options: "",          cmake: "-DYOSYS_F4PGA_PLUGINS=ON",                                     extra_pkgs: ""}
+          - {test: "parmys_reg_strong",          cores: "16", options: "",          cmake: "-DYOSYS_F4PGA_PLUGINS=OFF",                                     extra_pkgs: ""}
 
     env:
       DEBIAN_FRONTEND: "noninteractive"

doc/src/arch/reference.rst

@@ -2031,17 +2031,40 @@ The ``<segment>`` tag and its contents are described below.
 .. arch:tag:: <mux name="string"/>
 
     :req_param name: Name of the mux switch type used to drive this type of segment by default, from both block outputs and other wires. This information is used during rr-graph construction, and a custom switch block can override this switch type for specific connections if desired.
+                     The switch type specified with the <mux> tag will be used for both the incrementing and decrementing wires within this segment. 
+                     If more control is needed, the mux_inc and mux_dec tags can be used to assign different muxes to drive incremental and decremental wires within the segment.
 
     .. note:: For UNIDIRECTIONAL only.
 
     Tag must be included and ``name`` must be the same as the name you give in ``<switch type="mux" name="...``
 
+.. arch:tag:: <mux_inc name="string"/>
+
+    :req_param name: 
+        Name of the mux switch type used to drive the incremental wires in this segment from both block outputs and other wires.
+        Incremental wires are tracks within this segment that are heading in the "right" direction on the x-axis and the "top" direction on the y-axis.
+        This information is used during rr-graph construction, and a custom switch block can override this switch type for specific connections if desired.
+
+    .. note:: For UNIDIRECTIONAL only.
+
+.. arch:tag:: <mux_dec name="string">
+    
+    :req_param name: 
+        Name of the mux switch type used to drive the decremental wires in this segment from both block outputs and other wires.
+        Incremental wires are tracks within this segment that are heading in the "left" direction on the x-axis and the "bottom" direction on the y-axis.
+        This information is used during rr-graph construction, and a custom switch block can override this switch type for specific connections if desired.
+
+    .. note:: For UNIDIRECTIONAL only.
+
+    .. note:: For unidirectional segments, either <mux> tag or both <mux_inc> and <mux_dec> should be defined in the architecture file. If only the <mux> tag is defined, we assume that the same mux drives both incremental and decremental wires within this segment.     
+
 .. arch:tag:: <mux_inter_die name="string"/>
 
     :req_param name: Name of the mux switch type used to drive this segment type when the driver (block outputs and other wires) is located on a different die than the segment. This information is utilized during rr-graph construction.
 
     Tag must be included and ``name`` must be the same as the name you give in ``<switch type="mux" name="...``
 
+
 .. arch:tag:: <wire_switch name="string"/>
 
     :req_param name: Name of the switch type used by other wires to drive this type of segment by default. This information is used during rr-graph construction, and a custom switch block can override this switch type for specific connections if desired.

doc/src/vpr/file_formats.rst

@@ -616,27 +616,32 @@ The io pad is set to inpad mode and is driven by the inpad:
 
 Placement File Format (.place)
 ------------------------------
+The placement file format is used to specify the position of cluster-level blocks in an FPGA design. It includes information about the netlist and architecture files, the size of the logic block array, and the placement details of each block in the CLB netlist..
+
 The first line of the placement file lists the netlist (.net) and architecture (.xml) files used to create this placement.
-This information is used to ensure you are warned if you accidentally route this placement with a different architecture or netlist file later.
+This information is used to ensure you are warned if you accidentally route this placement with a different architecture or netlist file later. 
 The second line of the file gives the size of the logic block array used by this placement.
-All the following lines have the format::
 
-    block_name    x        y   subtile_number
+All subsequent lines follow this format:
+
+    block_name    x    y    subblk    [layer_number]    [#block_number]
+
+- **block_name**: Refers to either:
+  - The name of a clustered block, as given in the input .net formatted netlist.
+  - The name of a primitive within a clustered block.
 
-The ``block_name`` can refer to either:
+- **x** and **y**: Represent the row and column in which the block is placed, respectively.
 
-- The name of a clustered block, as given in the input .net formatted netlist.
-- The name of a primitive within a clustered block.
+- **subblk**: Specifies which of several possible subtile locations in row **x** and column **y** contains this block, which is useful when the tile capacity is greater than 1. The subtile number should be in the range `0` to `(grid[i][j].capacity - 1)`. The subtile numbers for a particular **x, y** location do not have to be used in order.
 
-``x`` and ``y`` are the row and column in which the block is placed, respectively.
+- **layer_number**: Indicates the layer (or die) on which the block is placed. If omitted, the block is assumed to be placed on layer `0` (a single die system). In 3D FPGA architectures, multiple dies can be stacked, with the bottom die considered as layer `0`.
+
+The placement files output by VPR also include (as a comment) an extra field: the id (number) of the block in the CLB netlist. This is the internal index used by VPR to identify a CLB level block -- it may be useful to know this index if you are modifying VPR and trying to debug something.
 
 .. note:: The blocks in a placement file can be listed in any order.
 
-Since we can have more than one block in a row or column when the block capacity is set to be greater than 1 in the architecture file, the subtile number specifies which of the several possible subtile locations in row x and column y contains this block.
-Note that the subtile number used should be in the range 0 to (grid[i][j].capacity - 1). The subtile numbers for a particular x,y location do not have to be used in order.
 
-The placement files output by VPR also include (as a comment) a fifth field:  the block number.
-This is the internal index used by VPR to identify a block -- it may be useful to know this index if you are modifying VPR and trying to debug something.
+.. note:: A `#` character on a line indicates that all text after the `#` to the end of a line is a comment.
 
 .. _fig_fpga_coord_system:
 
@@ -653,10 +658,10 @@ All pads either have x equal to ``0`` or ``nx + 1`` or y equal to ``0`` or ``ny
 
 Placement File Format Example
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-An example placement file is:
+
 
 .. code-block:: none
-    :caption: Example placement file.
+    :caption: Example 2D Placement File
     :linenos:
 
     Netlist file: xor5.net   Architecture file: sample.xml
@@ -673,6 +678,23 @@ An example placement file is:
     xor5        1       2       0       #6
     [1]         1       1       0       #7
 
+.. code-block:: none
+    :caption: Example 3D Placement File with Layer Column
+    :linenos:
+
+    Netlist file: xor5.net   Architecture file: sample.xml
+    Array size: 2 x 2 logic blocks
+
+    #block name x       y       subblk  layer  block number
+    #---------- --      --      ------- ------ -----------
+    a           0       1       0       0      #0  -- NB: block number is a comment.
+    b           1       0       0       1      #1
+    c           0       2       1       0      #2
+    d           1       3       0       1      #3
+    e           1       3       1       0      #4
+    out:xor5    0       2       0       1      #5
+    xor5        1       2       0       0      #6
+    [1]         1       1       0       1      #7
 
 .. _vpr_route_file:
 

libs/libarchfpga/src/physical_types.h

@@ -1567,7 +1567,16 @@ enum e_Fc_type {
  *                   relation to the switches from the architecture file,    *
  *                   not the expanded list of switches that is built         *
  *                   at the end of build_rr_graph                            *
- *                                                                           *
+ * @param arch_wire_switch_dec: Same as arch_wire_switch but used only for   *
+ *                   decremental tracks if it is specified in the            *
+ *                   architecture file. If -1, this value was not set in     *
+ *                   the architecture file and arch_wire_switch should be    *
+ *                   used for "DEC_DIR" wire segments.                       *
+ * @param arch_opin_switch_dec: Same as arch_opin_switch but used only for   *
+ *                   decremental tracks if it is specified in the            *
+ *                   architecture file. If -1, this value was not set in     * 
+ *                   the architecture file and arch_opin_switch should be    *
+ *                   used for "DEC_DIR" wire segments.                       * 
  * @param arch_opin_between_dice_switch: Index of the switch type that       *
  *                   connects output pins (OPINs) *to* this segment from     *
  *                   *another die (layer)*. Note that this index is in       *
@@ -1585,14 +1594,14 @@ enum e_Fc_type {
  * Cmetal: Capacitance of a routing track, per unit logic block length.      *
  * Rmetal: Resistance of a routing track, per unit logic block length.       *
  * (UDSD by AY) drivers: How do signals driving a routing track connect to   *
- *                       the track?  
+ *                       the track?                                          *
  * seg_index: The index of the segment as stored in the appropriate Segs list*
  *            Upon loading the architecture, we use this field to keep track *
  *            the segment's index in the unified segment_inf vector. This is *
  *            useful when building the rr_graph for different Y & X channels *
- *            in terms of track distribution and segment type.                *
+ *            in terms of track distribution and segment type.               *
  * res_type: Determines the routing network to which the segment belongs.    *
- *           Possible values are:
+ *           Possible values are:                                            *
  *              - GENERAL: The segment is part of the general routing        *
  *                         resources.                                        *
  *              - GCLK: The segment is part of the global routing network.   *
@@ -1606,6 +1615,8 @@ struct t_segment_inf {
     int length;
     short arch_wire_switch;
     short arch_opin_switch;
+    short arch_wire_switch_dec = -1;
+    short arch_opin_switch_dec = -1;
     short arch_opin_between_dice_switch = -1;
     float frac_cb;
     float frac_sb;

libs/libarchfpga/src/read_xml_arch_file.cpp

@@ -3766,6 +3766,10 @@ static void ProcessSegments(pugi::xml_node Parent,
             //Unidir requires the following tags
             expected_subtags.emplace_back("mux");
             expected_subtags.emplace_back("mux_inter_die");
+            //with the following two tags, we can allow the architecture file to define
+            //different muxes with different delays for wires with different directions
+            expected_subtags.emplace_back("mux_inc");
+            expected_subtags.emplace_back("mux_dec");
         }
 
         else {
@@ -3796,28 +3800,78 @@ static void ProcessSegments(pugi::xml_node Parent,
         /* Get the wire and opin switches, or mux switch if unidir */
         if (UNI_DIRECTIONAL == Segs[i].directionality) {
             //Get the switch name for same die wire and track connections
-            SubElem = get_single_child(Node, "mux", loc_data);
-            tmp = get_attribute(SubElem, "name", loc_data).value();
-
-            /* Match names */
-            for (j = 0; j < NumSwitches; ++j) {
-                if (0 == strcmp(tmp, Switches[j].name.c_str())) {
-                    break; /* End loop so j is where we want it */
+            SubElem = get_single_child(Node, "mux", loc_data, ReqOpt::OPTIONAL);
+            tmp = get_attribute(SubElem, "name", loc_data, ReqOpt::OPTIONAL).as_string(nullptr);
+
+            //check if <mux> tag is defined in the architecture, otherwise we should look for <mux_inc> and <mux_dec>
+            if(tmp){
+                /* Match names */
+                for (j = 0; j < NumSwitches; ++j) {
+                    if (0 == strcmp(tmp, Switches[j].name.c_str())) {
+                        break; /* End loop so j is where we want it */
+                    }
                 }
+                if (j >= NumSwitches) {
+                    archfpga_throw(loc_data.filename_c_str(), loc_data.line(SubElem),
+                                "'%s' is not a valid mux name.\n", tmp);
+                }
+
+                /* Unidir muxes must have the same switch
+                * for wire and opin fanin since there is
+                * really only the mux in unidir. */
+                Segs[i].arch_wire_switch = j;
+                Segs[i].arch_opin_switch = j;
             }
-            if (j >= NumSwitches) {
-                archfpga_throw(loc_data.filename_c_str(), loc_data.line(SubElem),
-                               "'%s' is not a valid mux name.\n", tmp);
-            }
+            else { //if a general mux is not defined, we should look for specific mux for each direction in the architecture file
+                SubElem = get_single_child(Node, "mux_inc", loc_data, ReqOpt::OPTIONAL);
+                tmp = get_attribute(SubElem, "name", loc_data, ReqOpt::OPTIONAL).as_string(nullptr);
+                if(!tmp){
+                    archfpga_throw(loc_data.filename_c_str(), loc_data.line(SubElem),
+                                "if mux is not specified in a wire segment, both mux_inc and mux_dec should be specified");
+                } else{
+                    /* Match names */
+                    for (j = 0; j < NumSwitches; ++j) {
+                        if (0 == strcmp(tmp, Switches[j].name.c_str())) {
+                            break; /* End loop so j is where we want it */
+                        }
+                    }
+                    if (j >= NumSwitches) {
+                        archfpga_throw(loc_data.filename_c_str(), loc_data.line(SubElem),
+                                    "'%s' is not a valid mux name.\n", tmp);
+                    }
 
-            /* Unidir muxes must have the same switch
-             * for wire and opin fanin since there is
-             * really only the mux in unidir. */
-            Segs[i].arch_wire_switch = j;
-            Segs[i].arch_opin_switch = j;
+                    /* Unidir muxes must have the same switch
+                    * for wire and opin fanin since there is
+                    * really only the mux in unidir. */
+                    Segs[i].arch_wire_switch = j;
+                    Segs[i].arch_opin_switch = j;
+                }
 
-        }
+                SubElem = get_single_child(Node, "mux_dec", loc_data, ReqOpt::OPTIONAL);
+                tmp = get_attribute(SubElem, "name", loc_data, ReqOpt::OPTIONAL).as_string(nullptr);
+                if(!tmp){
+                    archfpga_throw(loc_data.filename_c_str(), loc_data.line(SubElem),
+                                "if mux is not specified in a wire segment, both mux_inc and mux_dec should be specified");
+                } else{
+                    /* Match names */
+                    for (j = 0; j < NumSwitches; ++j) {
+                        if (0 == strcmp(tmp, Switches[j].name.c_str())) {
+                            break; /* End loop so j is where we want it */
+                        }
+                    }
+                    if (j >= NumSwitches) {
+                        archfpga_throw(loc_data.filename_c_str(), loc_data.line(SubElem),
+                                    "'%s' is not a valid mux name.\n", tmp);
+                    }
 
+                    /* Unidir muxes must have the same switch
+                    * for wire and opin fanin since there is
+                    * really only the mux in unidir. */
+                    Segs[i].arch_wire_switch_dec = j;
+                    Segs[i].arch_opin_switch_dec = j;
+                }
+            }
+        }
         else {
             VTR_ASSERT(BI_DIRECTIONAL == Segs[i].directionality);
             SubElem = get_single_child(Node, "wire_switch", loc_data);

parmys/regression_test/benchmark/suite/koios_weekly_suite/task_list.conf

@@ -2,5 +2,5 @@ regression_test/benchmark/task/koios/koios_large
 regression_test/benchmark/task/koios/koios_large_no_hb
 regression_test/benchmark/task/koios/koios_proxy
 regression_test/benchmark/task/koios/koios_proxy_no_hb
-regression_test/benchmark/task/koios/koios_sv
-regression_test/benchmark/task/koios/koios_sv_no_hb
+#regression_test/benchmark/task/koios/koios_sv
+#regression_test/benchmark/task/koios/koios_sv_no_hb