Merge branch 'master' into openfpga

Author: tangxifan

.github/workflows/nightly_test.yml

@@ -4,20 +4,23 @@ on:
   # We want to run the CI when anything is pushed to master.
   # Since master is a protected branch this only happens when a PR is merged.
   # This is a double check in case the PR was stale and had some issues.
-  push:
-    branches:
-      - master
-    paths-ignore: # Prevents from running if only docs are updated
-      - 'doc/**'
-      - '**/*README*'
-      - '**.md'
-      - '**.rst'
-  pull_request:
-    paths-ignore: # Prevents from running if only docs are updated
-      - 'doc/**'
-      - '**/*README*'
-      - '**.md'
-      - '**.rst'
+  # NOTE: This was turned off in late October 2024 since the Nightly Tests were
+  #       no longer working on the self-hosted runners. Will turn this back on
+  #       once the issue is resolved.
+  # push:
+  #   branches:
+  #     - master
+  #   paths-ignore: # Prevents from running if only docs are updated
+  #     - 'doc/**'
+  #     - '**/*README*'
+  #     - '**.md'
+  #     - '**.rst'
+  # pull_request:
+  #   paths-ignore: # Prevents from running if only docs are updated
+  #     - 'doc/**'
+  #     - '**/*README*'
+  #     - '**.md'
+  #     - '**.rst'
   workflow_dispatch:
   schedule:
   - cron: '0 0 * * *' # daily

doc/src/vpr/command_line_usage.rst

@@ -1074,12 +1074,16 @@ The following options are only used when FPGA device and netlist contain a NoC r
 
     .. note:: noc_flows_file are required to specify if NoC optimization is turned on (--noc on).
 
-.. option:: --noc_routing_algorithm {xy_routing | bfs_routing}
+.. option:: --noc_routing_algorithm {xy_routing | bfs_routing | west_first_routing | north_last_routing | negative_first_routing | odd_even_routing}
 
     Controls the algorithm used by the NoC to route packets.
 
     * ``xy_routing`` Uses the direction oriented routing algorithm. This is recommended to be used with mesh NoC topologies.
-    * ``bfs_routing`` Uses the breadth first search algorithm. The objective is to find a route that uses a minimum number of links. This can be used with any NoC topology.
+    * ``bfs_routing`` Uses the breadth first search algorithm. The objective is to find a route that uses a minimum number of links. This algorithm is not guaranteed to generate deadlock-free traffic flow routes, but can be used with any NoC topology.
+    * ``west_first_routing`` Uses the west-first routing algorithm. This is recommended to be used with mesh NoC topologies.
+    * ``north_last_routing`` Uses the north-last routing algorithm. This is recommended to be used with mesh NoC topologies.
+    * ``negative_first_routing`` Uses the negative-first routing algorithm. This is recommended to be used with mesh NoC topologies.
+    * ``odd_even_routing`` Uses the odd-even routing algorithm. This is recommended to be used with mesh NoC topologies.
 
     **Default:** ``bfs_routing``
 
@@ -1091,28 +1095,45 @@ The following options are only used when FPGA device and netlist contain a NoC r
     * ``noc_placement_weighting = 1`` means noc placement is considered equal to timing and wirelength.
     * ``noc_placement_weighting > 1`` means the placement is increasingly dominated by NoC parameters.
 
-    **Default:** ``0.6``
+    **Default:** ``5.0``
+
+.. option:: --noc_aggregate_bandwidth_weighting <float>
+
+    Controls the importance of minimizing the NoC aggregate bandwidth. This value can be >=0, where 0 would mean the aggregate bandwidth has no relevance to placement.
+    Other positive numbers specify the importance of minimizing the NoC aggregate bandwidth compared to other NoC-related cost terms.
+    Weighting factors for NoC-related cost terms are normalized internally. Therefore, their absolute values are not important, and
+    only their relative ratios determine the importance of each cost term.
+
+    **Default:** ``0.38``
 
 .. option:: --noc_latency_constraints_weighting <float>
 
-    Controls the importance of meeting all the NoC traffic flow latency constraints.
+    Controls the importance of meeting all the NoC traffic flow latency constraints. This value can be >=0, where 0 would mean latency constraints have no relevance to placement.
+    Other positive numbers specify the importance of meeting latency constraints compared to other NoC-related cost terms.
+    Weighting factors for NoC-related cost terms are normalized internally. Therefore, their absolute values are not important, and
+    only their relative ratios determine the importance of each cost term.
 
-    * ``latency_constraints = 0`` means the latency constraints have no relevance to placement.
-    * ``0 < latency_constraints < 1`` means the latency constraints are weighted equally to the sum of other placement cost components. 
-    * ``latency_constraints > 1`` means the placement is increasingly dominated by reducing the latency constraints of the traffic flows.
-    
-    **Default:** ``1``
+    **Default:** ``0.6``
 
 .. option:: --noc_latency_weighting <float>
 
     Controls the importance of reducing the latencies of the NoC traffic flows.
-    This value can be >=0, 
+    This value can be >=0, where 0 would mean the latencies have no relevance to placement
+    Other positive numbers specify the importance of minimizing aggregate latency compared to other NoC-related cost terms.
+    Weighting factors for NoC-related cost terms are normalized internally. Therefore, their absolute values are not important, and
+    only their relative ratios determine the importance of each cost term.
 
-    * ``latency = 0`` means the latencies have no relevance to placement.
-    * ``0 < latency < 1`` means the latencies are weighted equally to the sum of other placement cost components. 
-    * ``latency > 1`` means the placement is increasingly dominated by reducing the latencies of the traffic flows.
-    
-    **Default:** ``0.05``
+    **Default:** ``0.02``
+
+.. option:: --noc_congestion_weighting <float>
+
+    Controls the importance of reducing the congestion of the NoC links.
+    This value can be >=0, where 0 would mean the congestion has no relevance to placement.
+    Other positive numbers specify the importance of minimizing congestion compared to other NoC-related cost terms.
+    Weighting factors for NoC-related cost terms are normalized internally. Therefore, their absolute values are not important, and
+    only their relative ratios determine the importance of each cost term.
+
+    **Default:** ``0.25``
 
 .. option:: --noc_swap_percentage <float>
 
@@ -1122,7 +1143,7 @@ The following options are only used when FPGA device and netlist contain a NoC r
     * ``0`` means NoC blocks will be moved at the same rate as other blocks. 
     * ``100`` means all swaps attempted by the placer are NoC router blocks.
 
-    **Default:** ``40``    
+    **Default:** ``0``
 
 .. option:: --noc_placement_file_name <file>
 

libs/libvtrutil/src/vtr_vector.h

@@ -4,6 +4,8 @@
 #include <cstddef>
 #include <iterator>
 #include <algorithm>
+#include <tuple>
+
 #include "vtr_range.h"
 
 namespace vtr {
@@ -56,9 +58,6 @@ class vector : private std::vector<V, Allocator> {
     class key_iterator;
     typedef vtr::Range<key_iterator> key_range;
 
-    class pair_iterator;
-    typedef vtr::Range<pair_iterator> pair_range;
-
   public:
     //Pass through std::vector's types
     using typename storage::allocator_type;
@@ -157,16 +156,41 @@ class vector : private std::vector<V, Allocator> {
     }
 
     /**
-     * @brief Returns a range containing the key-value pairs.
+     * @brief Provides an iterable object to enumerate the vector.
+     *
+     * This function allows for easy enumeration, yielding a tuple of (index, element)
+     * pairs in each iteration. It is similar in functionality to Python's `enumerate()`.
+     * This function can be used in range-based with structured binding to iterate over
+     * indices and values at the same time.
      *
-     * This function returns a range object that represents the sequence of key-value
-     * pairs within the vector. The range can be used to iterate over the pairs using
-     * standard range-based loops or algorithms.
+     *      vtr::vector<IdType, ValueType> vec;
+     *      for (const auto& [idx, value] : vec) {
+     *          ...
+     *      }
+     * It should be noted that value is returned by reference even if "&"
+     * does not appear after auto keyword. However, it is recommended to use "&"
+     * explicitly to avoid any confusion about value's scope.
      *
-     * @return A `pair_range` object representing the range of key-value pairs.
+     * @ return An iterable wrapper that can be used in a range-based for loop to obtain
+     * (index, element) pairs.
      */
-    pair_range pairs() const {
-        return vtr::make_range(pair_begin(), pair_end());
+    auto pairs() const {
+        struct enumerated_iterator {
+            key_type i;
+            vector::const_iterator iter;
+
+            bool operator!=(const enumerated_iterator& other) const { return iter != other.iter; }
+            void operator++() { i = key_type(size_t(i) + 1); iter++; }
+            std::tuple<key_type, decltype(*iter)&> operator*() { return std::tie(i, *iter); }
+        };
+
+        struct enumerated_wrapper {
+            const vector& vec;
+            auto begin() { return enumerated_iterator{ key_type(0), vec.begin() }; }
+            auto end() { return enumerated_iterator{ key_type(vec.size()), vec.end() }; }
+        };
+
+        return enumerated_wrapper{ *this };
     }
 
   public:
@@ -218,59 +242,9 @@ class vector : private std::vector<V, Allocator> {
         value_type value_;
     };
 
-        /**
-         * @brief A bidirectional iterator for a vtr:vector object.
-         *
-         * The `pair_iterator` class provides a way to iterate over key-value pairs
-         * within a vtr::vector container. It supports bidirectional iteration,
-         * allowing the user to traverse the container both forwards and backwards.
-         */
-        class pair_iterator {
-          public:
-            using iterator_category = std::bidirectional_iterator_tag;
-            using difference_type = std::ptrdiff_t;
-            using value_type = std::pair<key_type, V>;
-            using pointer = value_type*;
-            using reference = value_type&;
-
-            /// @brief constructor
-            pair_iterator(vector<K, V, Allocator>& vec, key_type init)
-                : vec_(vec), value_(init, vec[init]) {}
-
-            /// @brief ++ operator
-            pair_iterator& operator++() {
-                value_ = std::make_pair(key_type(size_t(value_.first) + 1), vec_[key_type(size_t(value_.first) + 1)]);
-                return *this;
-            }
-            /// @brief -- operator
-            pair_iterator& operator--() {
-                value_ = std::make_pair(key_type(size_t(value_.first) - 1), vec_[key_type(size_t(value_.first) - 1)]);
-                return *this;
-            }
-            /// @brief dereference operator
-            reference operator*() { return value_; }
-            /// @brief -> operator
-            pointer operator->() { return &value_; }
-
-            /// @brief == operator
-            friend bool operator==(const pair_iterator& lhs, const pair_iterator& rhs) { return lhs.value_.first == rhs.value_.first; }
-            /// @brief != operator
-            friend bool operator!=(const pair_iterator& lhs, const pair_iterator& rhs) { return !(lhs == rhs); }
-
-          private:
-            /// @brief Reference to the vector of key-value pairs.
-            vector<K, V, Allocator>& vec_;
-            // @brief The current key-value pair being pointed to by the iterator.
-            value_type value_;
-        };
-
   private:
     key_iterator key_begin() const { return key_iterator(key_type(0)); }
     key_iterator key_end() const { return key_iterator(key_type(size())); }
-
-    pair_iterator pair_begin() const { return pair_iterator(*const_cast<vector<K, V, Allocator>*>(this), key_type(0)); }
-    pair_iterator pair_end() const { return pair_iterator(*const_cast<vector<K, V, Allocator>*>(this), key_type(size())); }
 };
-
 } // namespace vtr
 #endif

vpr/test/test_odd_even_routing.cpp

@@ -5,6 +5,7 @@
 #include "channel_dependency_graph.h"
 
 #include <random>
+#include <iostream>
 
 namespace {
 
@@ -225,7 +226,7 @@ TEST_CASE("test_route_flow", "[vpr_noc_odd_even_routing]") {
         compare_routes(golden_path, found_path, noc_model);
     }
 
-    SECTION("Test case where multiple traffic flows are router, and routes are checked for turn legality and deadlock freedom.") {
+    SECTION("Test case where multiple traffic flows are routed, and routes are checked for turn legality and deadlock freedom.") {
         std::random_device device;
         std::mt19937 rand_num_gen(device());
         std::uniform_int_distribution<std::mt19937::result_type> dist(0,  99);
@@ -248,7 +249,6 @@ TEST_CASE("test_route_flow", "[vpr_noc_odd_even_routing]") {
         vtr::vector<NocTrafficFlowId, std::vector<NocLinkId>> traffic_flow_routes(traffic_flow_storage.get_number_of_traffic_flows());
 
         for (const auto& [id, traffic_flow] : traffic_flow_storage.get_all_traffic_flows().pairs()) {
-
             NocRouterId src_router_id = noc_model.get_router_at_grid_location(block_locs[traffic_flow.source_router_cluster_id].loc);
             NocRouterId dst_router_id = noc_model.get_router_at_grid_location(block_locs[traffic_flow.sink_router_cluster_id].loc);