Merge branch 'master' into temp_organize_place_timng

Author: AlexandreSinger

.github/workflows/test.yml

@@ -439,7 +439,6 @@ jobs:
         - { name: 'GCC 11 (Ubuntu Noble - 24.04)',    eval: 'CC=gcc-11 && CXX=g++-11',           }
         - { name: 'GCC 12 (Ubuntu Noble - 24.04)',    eval: 'CC=gcc-12 && CXX=g++-12',         }
         - { name: 'GCC 14 (Ubuntu Noble - 24.04)',    eval: 'CC=gcc-14 && CXX=g++-14',         }
-        - { name: 'Clang 15 (Ubuntu Noble - 24.04)',  eval: 'CC=clang-15 && CXX=clang++-15',   }
         - { name: 'Clang 16 (Ubuntu Noble - 24.04)',  eval: 'CC=clang-16 && CXX=clang++-16',   }
         - { name: 'Clang 17 (Ubuntu Noble - 24.04)',  eval: 'CC=clang-17 && CXX=clang++-17',   }
         - { name: 'Clang 18 (Ubuntu Noble - 24.04)',  eval: 'CC=clang-18 && CXX=clang++-18',   }

CHANGELOG.md

@@ -47,6 +47,64 @@ _The following are changes which have been implemented in the VTR master branch
 
 ### Removed
 
+
+## v9.0.0 - 2024-12-23
+
+### Added
+  * Support for Advanced Architectures:
+    * 3D FPGA and RAD architectures.
+    * Architectures with hard Networks-on-Chip (NoCs).
+    * Distinct horizontal and vertical channel widths and types.
+    * Diagonal routing wires and other complex wire shapes (L-shaped, T-shaped, ....).
+  
+  * New Benchmark Suites:
+    * Koios: A deep-learning-focused benchmark suite with various design sizes.
+    * Hermes: Benchmarks utilizing hard NoCs.
+    * TitanNew: Large benchmarks targeting the Stratix 10 architecture.
+
+  * Commercial FPGAs Architecture Captures:
+    * Intel’s Stratix 10 FPGA architecture.
+    * AMD’s 7-series FPGA architecture.
+
+  * Parmys Logic Synthesis Flow:
+    * Better Verilog language coverage
+    * More efficient hard block mapping
+
+  * VPR Graphics Visualizations:
+    * New interface for improved usability and underlying graphics rewritten using EZGL/GTK to allow more UI widgets.
+    * Algorithm breakpoint visualizations for placement and routing algorithm debugging.
+    * User-guided (manual) placement optimization features.
+    * Enabled a live connection for client graphical application to VTR engines through sockets (server mode).
+    * Interactive timing path analysis (IPA) client using server mode.
+   
+  * Performance Enhancements:
+    * Parallel router for faster inter-cluster routing or flat routing.
+
+  * Re-clustering API to modify packing decisions during the flow.
+  * Support for floorplanning and placement constraints.
+  * Unified intra- and inter-cluster (flat) routing.
+  * Comprehensive web-based VTR utilities and API documentation.
+  
+### Changed
+  * The default values of many command line options (e.g. inner_num is 0.5 instead of 1.0)
+  * Changes to placement engine
+    * Smart centroid initial placement algorithm.
+    * Multiple smart placement directed moves.
+    * Reinforcement learning-based placement algorithm.
+  * Changes to routing engine
+    * Faster lookahead creation.
+    * More accurate lookahead for large blocks.
+    * More efficient heap and pruning strategies.
+    * max `pres_fac` capped to avoid possible numeric issues.
+    
+    
+### Fixed
+  * Many algorithmic and coding bugs are fixed in this release
+   
+### Removed
+  * Breadth-first (non-timing-driven) router.
+  * Non-linear congestion placement cost.
+
 ## v8.0.0 - 2020-03-24
 
 ### Added

CMakeLists.txt

@@ -62,8 +62,8 @@ option(ODIN_SANITIZE "Enable building odin with sanitize flags" OFF)
 option(WITH_PARMYS "Enable Yosys as elaborator and parmys-plugin as partial mapper" ON)
 option(YOSYS_F4PGA_PLUGINS "Enable building and installing Yosys SystemVerilog and UHDM plugins" OFF)
 
-set(VTR_VERSION_MAJOR 8)
-set(VTR_VERSION_MINOR 1)
+set(VTR_VERSION_MAJOR 9)
+set(VTR_VERSION_MINOR 0)
 set(VTR_VERSION_PATCH 0)
 set(VTR_VERSION_PRERELEASE "dev")
 
@@ -93,9 +93,9 @@ add_definitions("-DVTR_ASSERT_LEVEL=${VTR_ASSERT_LEVEL}")
 include(CheckCXXCompilerFlag)
 
 #
-# We require c++17 support
+# We require c++20 support
 #
-set(CMAKE_CXX_STANDARD 17)
+set(CMAKE_CXX_STANDARD 20)
 set(CMAKE_CXX_STANDARD_REQUIRED ON)
 set(CMAKE_CXX_EXTENSIONS OFF) #No compiler specific extensions
 
@@ -160,7 +160,7 @@ else()
         "-Wcast-align"                  #Warn if a cast causes memory alignment changes
         "-Wshadow"                      #Warn if local variable shadows another variable
         "-Wformat=2"                    #Sanity checks for printf-like formatting
-        "-Wno-format-nonliteral"        # But don't worry about non-literal formtting (i.e. run-time printf format strings)
+        "-Wno-format-nonliteral"        # But don't worry about non-literal formatting (i.e. run-time printf format strings)
         "-Wlogical-op"                  #Checks for logical op when bit-wise expected
         "-Wmissing-declarations"        #Warn if a global function is defined with no declaration
         "-Wmissing-include-dirs"        #Warn if a user include directory is missing
@@ -178,10 +178,10 @@ else()
         "-Wduplicated-cond"             #Warn about identical conditions in if-else chains
         "-Wduplicated-branches"         #Warn when different branches of an if-else chain are equivalent
         "-Wnull-dereference"            #Warn about null pointer dereference execution paths
-        "-Wuninitialized"               #Warn about unitialized values
+        "-Wuninitialized"               #Warn about uninitialized values
         "-Winit-self"                   #Warn about self-initialization
         "-Wcatch-value=3"               #Warn when catch statements don't catch by reference
-        "-Wextra-semi"                  #Warn about redudnant semicolons
+        "-Wextra-semi"                  #Warn about redundant semicolons
         "-Wimplicit-fallthrough=3"      #Warn about case fallthroughs, but allow 'fallthrough' comments to suppress warnings
         #GCC-like optional
         #"-Wsuggest-final-types"         #Suggest where 'final' would help if specified on a type methods

README.developers.md

@@ -637,6 +637,10 @@ They can be used for FPGA architecture exploration for DL and also for tuning CA
 
 A typical approach to evaluating an algorithm change would be to run `koios_medium` (or `koios_medium_no_hb`) tasks from the nightly regression test (vtr_reg_nightly_test4), the `koios_large` (or `koios_large_no_hb`) and the `koios_proxy` (or `koios_proxy_no_hb`) tasks from the weekly regression test (vtr_reg_weekly). The nightly test contains smaller benchmarks, whereas the large designs are in the weekly regression test. To measure QoR for the entire benchmark suite, both nightly and weekly tests should be run and the results should be concatenated.
 
+As 3 of the `koios_large` circuits require special settings due to having long DSP chains, they are split in separate tasks as follows:
+  * `bwave_like.float.large.v` and `bwave_like.fixed.large.v` are in `vtr_reg_weekly/koios_bwave_large` task
+  * `dla_like.large.v` is in `vtr_reg_weekly/koios_dla_large` task
+
 For evaluating an algorithm change in the Odin frontend, run `koios_medium` (or `koios_medium_no_hb`) tasks from the nightly regression test (vtr_reg_nightly_test4_odin) and the `koios_large_odin` (or `koios_large_no_hb_odin`) tasks from the weekly regression test (vtr_reg_weekly).
 
 The `koios_medium`, `koios_large`, and `koios_proxy` regression tasks run these benchmarks with complex_dsp functionality enabled, whereas `koios_medium_no_hb`, `koios_large_no_hb` and `koios_proxy_no_hb` regression tasks run these benchmarks without complex_dsp functionality. Normally, only the `koios_medium`, `koios_large`, and `koios_proxy` tasks should be enough for QoR.
@@ -651,6 +655,8 @@ The following table provides details on available Koios settings in VTR flow:
 | Nightly       | Medium designs     | k6FracN10LB_mem20K_complexDSP_customSB_22nm.xml | ✓ | vtr_reg_nightly_test4_odin/koios_medium | Odin | |
 | Nightly       | Medium designs     | k6FracN10LB_mem20K_complexDSP_customSB_22nm.xml |          | vtr_reg_nightly_test4_odin/koios_medium_no_hb | Odin | |
 | Weekly        | Large designs      | k6FracN10LB_mem20K_complexDSP_customSB_22nm.xml | ✓ | vtr_reg_weekly/koios_large | Parmys | |
+| Weekly        | Large designs      | k6FracN10LB_mem20K_complexDSP_customSB_22nm.xml | ✓ | vtr_reg_weekly/koios_dla_large | Parmys | |
+| Weekly        | Large designs      | k6FracN10LB_mem20K_complexDSP_customSB_22nm.xml | ✓ | vtr_reg_weekly/koios_bwave_large | Parmys | |
 | Weekly        | Large designs      | k6FracN10LB_mem20K_complexDSP_customSB_22nm.xml |          | vtr_reg_weekly/koios_large_no_hb | Parmys | |
 | Weekly        | Large designs      | k6FracN10LB_mem20K_complexDSP_customSB_22nm.xml | ✓ | vtr_reg_weekly/koios_large_odin | Odin | |
 | Weekly        | Large designs      | k6FracN10LB_mem20K_complexDSP_customSB_22nm.xml |          | vtr_reg_weekly/koios_large_no_hb_odin | Odin | |
@@ -661,7 +667,15 @@ The following table provides details on available Koios settings in VTR flow:
 
 For more information refer to the [Koios benchmark home page](vtr_flow/benchmarks/verilog/koios/README.md).
 
-The following steps show a sequence of commands to run the `koios` tasks on the Koios benchmarks:
+To make running all the koios benchmarks easier, especially with thos circuits scattered between different tasks, there is an overall task list that runs all the 40 circuits of Koios as follows (this will run all the circuits with complex DSP functionality enabled. If you want to disable the complex DSP, edit the file to point to the `koios_*_no_hb` tasks):
+
+```shell
+$ ../scripts/run_vtr_task.py -l koios_task_list.txt 
+
+#Several hours later... they complete
+#
+
+If you want to run a subset of the koios benchmarks or run them without hard DSP blocks, you can run lower-level 'koios' tasks as follows:
 
 ```shell
 #From the VTR root
@@ -681,17 +695,6 @@ $ ../scripts/run_vtr_task.py regression_tests/vtr_reg_weekly/koios_sv_no_hb &
 
 #Several hours later... they complete
 
-#Parse the results
-$ ../scripts/python_libs/vtr/parse_vtr_task.py regression_tests/vtr_reg_nightly_test4/koios_medium
-$ ../scripts/python_libs/vtr/parse_vtr_task.py regression_tests/vtr_reg_weekly/koios_large
-$ ../scripts/python_libs/vtr/parse_vtr_task.py regression_tests/vtr_reg_weekly/koios_proxy
-$ ../scripts/python_libs/vtr/parse_vtr_task.py regression_tests/vtr_reg_weekly/koios_sv
-
-$ ../scripts/python_libs/vtr/parse_vtr_task.py regression_tests/vtr_reg_nightly_test4/koios_medium_no_hb
-$ ../scripts/python_libs/vtr/parse_vtr_task.py regression_tests/vtr_reg_weekly/koios_large_no_hb
-$ ../scripts/python_libs/vtr/parse_vtr_task.py regression_tests/vtr_reg_weekly/koios_proxy_no_hb
-$ ../scripts/python_libs/vtr/parse_vtr_task.py regression_tests/vtr_reg_weekly/koios_sv_no_hb
-
 #The run directory should now contain a summary parse_results.txt file
 $ head -5 vtr_reg_nightly_test4/koios_medium/<latest_run_dir>/parse_results.txt
 arch	  circuit	  script_params	  vtr_flow_elapsed_time	  vtr_max_mem_stage	  vtr_max_mem	  error	  odin_synth_time	  max_odin_mem	  parmys_synth_time	  max_parmys_mem	  abc_depth	  abc_synth_time	  abc_cec_time	  abc_sec_time	  max_abc_mem	  ace_time	  max_ace_mem	  num_clb	  num_io	  num_memories	  num_mult	  vpr_status	  vpr_revision	  vpr_build_info	  vpr_compiler	  vpr_compiled	  hostname	  rundir	  max_vpr_mem	  num_primary_inputs	  num_primary_outputs	  num_pre_packed_nets	  num_pre_packed_blocks	  num_netlist_clocks	  num_post_packed_nets	  num_post_packed_blocks	  device_width	  device_height	  device_grid_tiles	  device_limiting_resources	  device_name	  pack_mem	  pack_time	  placed_wirelength_est	  place_mem	  place_time	  place_quench_time	  placed_CPD_est	  placed_setup_TNS_est	  placed_setup_WNS_est	  placed_geomean_nonvirtual_intradomain_critical_path_delay_est	  place_delay_matrix_lookup_time	  place_quench_timing_analysis_time	  place_quench_sta_time	  place_total_timing_analysis_time	  place_total_sta_time	  min_chan_width	  routed_wirelength	  min_chan_width_route_success_iteration	  logic_block_area_total	  logic_block_area_used	  min_chan_width_routing_area_total	  min_chan_width_routing_area_per_tile	  min_chan_width_route_time	  min_chan_width_total_timing_analysis_time	  min_chan_width_total_sta_time	  crit_path_routed_wirelength	  crit_path_route_success_iteration	  crit_path_total_nets_routed	  crit_path_total_connections_routed	  crit_path_total_heap_pushes	  crit_path_total_heap_pops	  critical_path_delay	  geomean_nonvirtual_intradomain_critical_path_delay	  setup_TNS	  setup_WNS	  hold_TNS	  hold_WNS	  crit_path_routing_area_total	  crit_path_routing_area_per_tile	  router_lookahead_computation_time	  crit_path_route_time	  crit_path_total_timing_analysis_time	  crit_path_total_sta_time	 

doc/src/vpr/command_line_usage.rst

@@ -408,6 +408,50 @@ Use the options below to override this default naming behaviour.
 
     Prefix for output files
 
+.. option:: --read_flat_place <file>
+
+    Reads a file containing the locations of each atom on the FPGA.
+    This is used by the packer to better cluster atoms together.
+
+    The flat placement file (which often ends in ``.fplace``) is a text file
+    where each line describes the location of an atom. Each line in the flat
+    placement file should have the following syntax:
+
+    .. code-block:: none
+
+        <atom_name : str> <x : float> <y : float> <layer : float> <atom_sub_tile : int> <atom_site_idx? : int>
+
+    For example:
+
+    .. code-block:: none
+
+        n523  6 8 0 0 3
+        n522  6 8 0 0 5
+        n520  6 8 0 0 2
+        n518  6 8 0 0 16
+
+    The position of the atom on the FPGA is given by 3 floating point values
+    (``x``, ``y``, ``layer``). We allow for the positions of atom to be not
+    quite legal (ok to be off-grid) since this flat placement will be fed into
+    the packer and placer, which will snap the positions to grid locations. By
+    allowing for off-grid positions, the packer can better trade-off where to
+    move atom blocks if they cannot be placed at the given position.
+    For 2D FPGA architectures, the ``layer`` should be 0.
+
+    The ``sub_tile`` is a clustered placement construct: which cluster-level
+    location at a given (x, y, layer) should these atoms go at (relevant when
+    multiple clusters can be stacked there). A sub-tile of -1 may be used when
+    the sub-tile of an atom is unkown (allowing the packing algorithm to choose
+    any sub-tile at the given (x, y, layer) location).
+
+    The ``site_idx`` is an optional index into a linearized list of primitive
+    locations within a cluster-level block which may be used as a hint to
+    reconstruct clusters.
+
+    .. warning::
+
+        This interface is currently experimental and under active development.
+
 .. option:: --write_flat_place <file>
 
     Writes the post-placement locations of each atom into a flat placement file.
@@ -830,55 +874,9 @@ If any of init_t, exit_t or alpha_t is specified, the user schedule, with a fixe
 
     **Default:** ``0.0``
 
-.. _dusty_sa_options:
-Setting any of the following 5 options selects :ref:`Dusty's annealing schedule <dusty_sa>` .
-
-.. option:: --alpha_min <float>
-
-    The minimum (starting) update factor (alpha) used.
-    Ranges between 0 and alpha_max.
-
-    **Default:** ``0.2``
-
-.. option:: --alpha_max <float>
-
-    The maximum (stopping) update factor (alpha) used after which simulated annealing will complete.
-    Ranges between alpha_min and 1.
-
-    **Default:** ``0.9``
-
-.. option:: --alpha_decay <float>
-
-    The rate at which alpha will approach 1: alpha(n) = 1 - (1 - alpha(n-1)) * alpha_decay
-    Ranges between 0 and 1.
-
-    **Default:** ``0.7``
-
-.. option:: --anneal_success_min <float>
-
-   The minimum success ratio after which the temperature will reset to maintain the target success ratio.
-   Ranges between 0 and anneal_success_target.
-
-    **Default:** ``0.1``
-
-.. option:: --anneal_success_target <float>
-
-   The temperature after each reset is selected to keep this target success ratio.
-   Ranges between anneal_success_target and 1.
-
-    **Default:** ``0.25``
-
-.. option:: --place_cost_exp <float>
-
-    Wiring cost is divided by the average channel width over a net's bounding box
-    taken to this exponent. Only impacts devices with different channel widths in 
-    different directions or regions. 
-
-    **Default:** ``1``
-
 .. option:: --RL_agent_placement {on | off}
 
-    Uses a Reinforcement Learning (RL) agent in choosing the appropiate move type in placement.
+    Uses a Reinforcement Learning (RL) agent in choosing the appropriate move type in placement.
     It activates the RL agent placement instead of using a fixed probability for each move type.
 
     **Default:** ``on``
@@ -907,7 +905,7 @@ Setting any of the following 5 options selects :ref:`Dusty's annealing schedule
 
     Controls how quickly the agent's memory decays. Values between [0., 1.] specify
     the fraction of weight in the exponentially weighted reward average applied to moves
-    which occured greater than moves_per_temp moves ago. Values < 0 cause the
+    which occurred greater than moves_per_temp moves ago. Values < 0 cause the
     unweighted reward sample average to be used (all samples are weighted equally)
 
     **Default:** ``0.05``
@@ -926,6 +924,8 @@ Setting any of the following 5 options selects :ref:`Dusty's annealing schedule
 
     **Default:** ``move_block_type``
 
+
+
 .. option:: --placer_debug_block <int>
 
     .. note:: This option is likely only of interest to developers debugging the placement algorithm
@@ -1023,7 +1023,7 @@ The following options are only valid when the placement engine is in timing-driv
 
 .. option:: --place_delay_model_reducer {min, max, median, arithmean, geomean}
 
-    When calculating delta delays for the placment delay model how are multiple values combined?
+    When calculating delta delays for the placement delay model how are multiple values combined?
 
     **Default:** ``min``
 
@@ -1056,15 +1056,15 @@ The following options are only valid when the placement engine is in timing-driv
 
 .. option:: --place_tsu_abs_margin <float>
 
-    Specifies an absolute offest added to cell setup times used by the placer.
+    Specifies an absolute offset added to cell setup times used by the placer.
     This effectively controls whether the placer should try to achieve extra margin on setup paths.
     For example a value of 500e-12 corresponds to requesting an extra 500ps of setup margin.
 
     **Default:** ``0.0``
 
 .. option:: --post_place_timing_report <file>
 
-    Name of the post-placement timing report file to generate (not generated if unspecfied).
+    Name of the post-placement timing report file to generate (not generated if unspecified).
 
 
 .. _noc_placement_options:

libs/EXTERNAL/libezgl/include/ezgl/point.hpp

@@ -36,7 +36,7 @@ class point2d {
   /**
    * Create a point at the given x and y position.
    */
-  point2d(double x_coord, double y_coord) : x(x_coord), y(y_coord)
+  point2d(double x_coord, double y_coord) noexcept : x(x_coord), y(y_coord)
   {
   }
 

libs/EXTERNAL/libezgl/include/ezgl/rectangle.hpp

@@ -33,7 +33,7 @@ class rectangle {
   /**
    * Default constructor: Create a zero-sized rectangle at {0,0}.
    */
-  rectangle() : m_first({0, 0}), m_second({0, 0})
+  rectangle() noexcept : m_first({0, 0}), m_second({0, 0})
   {
   }