[Spelling] Fixed Spelling Mistakes in VTR Flow

Fixed the spelling mistakes in the VTR flow. We exclude the pearl
libraries and benchtracker since these projects are not being maintained
at this time.

We also ignore the benchmarks and tasks directories since these are
mainly used for testing and contain a lot of false positives. We do not
want to make it challenging to add more tests.

Author: AlexandreSinger

.codespellrc

@@ -7,6 +7,10 @@ skip = ./build,
        *.log,
        *.vqm,
        *.blif,
+       *.xml,
+       *.pm,
+       # Special case: Pearl scripts are not being maintained.
+       *.pl,
        # External projects that do not belong to us.
        ./libs/EXTERNAL,
        ./parmys,
@@ -16,8 +20,11 @@ skip = ./build,
        ./ace2,
        ./blifexplorer,
        ./verilog_preprocessor,
-       # WIP spelling cleanups.
-       ./vtr_flow,
+       ./vtr_flow/scripts/perl_libs,
+       ./vtr_flow/scripts/benchtracker,
+       # Large testing directories.
+       ./vtr_flow/benchmarks,
+       ./vtr_flow/tasks,
        # Temporary as we wait for some PRs to merge.
        *_graph_uxsdcxx_capnp.h,
        ./vpr/src/route/rr_graph_generation/rr_graph.cpp,

vtr_flow/arch/titan/README.rst

@@ -103,7 +103,7 @@ Adding Support for New Architectures
 Support can be added for additional Quartus II supported FPGA architectures 
 (Cyclone III, Stratix II etc), by defining models for the architecture's VQM
 primitives.  Good places to look for this information include:
-   * Altera's Quartus Univeristy Interface Program (QUIP) documentation
+   * Altera's Quartus University Interface Program (QUIP) documentation
    * The 'fv_lib' directory under a Quartus installation
 
 For more details see vqm_to_blif's README.txt

vtr_flow/arch/zeroasic/README.md

@@ -2,7 +2,7 @@
 
 These are the VTR captures of the Zero ASIC architectures.
 
-The orginal Zero ASIC architectures can be found in logiklib here:
+The original Zero ASIC architectures can be found in logiklib here:
 https://github.com/siliconcompiler/logiklib
 
 These architectures have been slightly modified to work with VTR's CAD flow

vtr_flow/parse/pass_requirements/common/pass_requirements.vpr_route_fixed_chan_width.txt

@@ -11,6 +11,6 @@ crit_path_route_time;RangeAbs(0.10,10.0,2)
 
 #Peak memory
 #We set a 100MiB minimum threshold since the memory 
-#alloctor (e.g. TBB vs glibc) can cause a difference
+#allocator (e.g. TBB vs glibc) can cause a difference
 #particularly on small benchmarks
 max_vpr_mem;RangeAbs(0.8,1.35,102400)

vtr_flow/parse/pass_requirements/common/pass_requirements.vpr_route_fixed_chan_width_small.txt

@@ -11,6 +11,6 @@ crit_path_route_time;RangeAbs(0.10,10.0,2)
 
 #Peak memory
 #We set a 100MiB minimum threshold since the memory 
-#alloctor (e.g. TBB vs glibc) can cause a difference
+#allocator (e.g. TBB vs glibc) can cause a difference
 #particularly on small benchmarks
 max_vpr_mem;RangeAbs(0.8,1.203,102400)

vtr_flow/parse/pass_requirements/common/pass_requirements.vpr_route_min_chan_width.txt

@@ -15,13 +15,13 @@ min_chan_width_route_time;RangeAbs(0.10,15.0,3)
 
 #Peak memory
 #We set a 100MiB minimum threshold since the memory 
-#alloctor (e.g. TBB vs glibc) can cause a difference
+#allocator (e.g. TBB vs glibc) can cause a difference
 #particularly on small benchmarks
 #
 #Note that due to different binary search path, peak memory
 #can differ significantly during binary search (e.g. a larger
 #or smaller channel width explored during the search can
 #significantly affect the size of the RR graph, and correspondingly
-#peak mememory usage in VPR. As a result we just a larger permissible
+#peak memory usage in VPR. As a result we just a larger permissible
 #range for peak memory usage.
 max_vpr_mem;RangeAbs(0.5,2.0,102400)

vtr_flow/parse/pass_requirements/common/pass_requirements.vpr_route_min_chan_width_small.txt

@@ -16,13 +16,13 @@ min_chan_width_route_time;RangeAbs(0.05,15.0,4)
 
 #Peak memory
 #We set a 100MiB minimum threshold since the memory 
-#alloctor (e.g. TBB vs glibc) can cause a difference
+#allocator (e.g. TBB vs glibc) can cause a difference
 #particularly on small benchmarks
 #
 #Note that due to different binary search path, peak memory
 #can differ significantly during binary search (e.g. a larger
 #or smaller channel width explored during the search can
 #significantly affect the size of the RR graph, and correspondingly
-#peak mememory usage in VPR. As a result we just a larger permissible
+#peak memory usage in VPR. As a result we just a larger permissible
 #range for peak memory usage.
 max_vpr_mem;RangeAbs(0.5,2.0,102400)

vtr_flow/parse/pass_requirements/common/pass_requirements.vpr_route_relaxed_chan_width.txt

@@ -1 +1 @@
-#VPR metrix at relaxed (relative to minimum) channel width
+#VPR metrics at relaxed (relative to minimum) channel width

vtr_flow/parse/pass_requirements/timing/pass_requirements.vpr_route_relaxed_chan_width.txt

@@ -1,4 +1,4 @@
-#VPR metrix at relaxed (relative to minimum) channel width with timing
+#VPR metrics at relaxed (relative to minimum) channel width with timing
 %include "../common/pass_requirements.vpr_route_relaxed_chan_width.txt"
 
 #Routing Metrics

vtr_flow/parse/pass_requirements/timing/pass_requirements.vpr_route_relaxed_chan_width_small.txt

@@ -1,4 +1,4 @@
-#VPR metrix at relaxed (relative to minimum) channel width with timing
+#VPR metrics at relaxed (relative to minimum) channel width with timing
 %include "../common/pass_requirements.vpr_route_relaxed_chan_width_small.txt"
 
 #Routing Metrics