[Spelling] Fixed Spelling in Documentation

BUILDING.md

@@ -44,7 +44,7 @@ If you download a different version of those tools, then those versions may not
 
 ## Verifying Installation
 
-To verfiy that VTR has been installed correctly run::
+To verify that VTR has been installed correctly run::
 
     ./vtr_flow/scripts/run_vtr_task.py ./vtr_flow/tasks/regression_tests/vtr_reg_basic/basic_timing
 

CHANGELOG.md

@@ -1,13 +1,13 @@
 # VTR Change Log
 <!-- 
 This file documents user-facing changes between releases of the VTR
-project. The goal is to concicely communicate to end users what is new
+project. The goal is to concisely communicate to end users what is new
 or has changed in a particular release. It should *NOT* just be a dump
 of the commit log, as that is far too detailed. Most code re-factoring
 does not warrant a change log entry unless it has a significant impact
 on the end users (e.g. substantial performance improvements).
 
-Each release's change log should include headings (where releveant) with
+Each release's change log should include headings (where relevant) with
 bullet points listing what was: 
   - added           (new feature)
   - changed         (change to existing feature behaviour)
@@ -16,7 +16,7 @@ bullet points listing what was:
   - removed         (previous features which have been removed)
 
 Changes which have landed in the master/trunk but not been released
-should be included in the 'Unreleased' section and moved to the releveant
+should be included in the 'Unreleased' section and moved to the relevant
 releases' section when released.
 
 In the case of release candidates (e.g. v8.0.0-rc1) the current
@@ -146,7 +146,7 @@ _The following are changes which have been implemented in the VTR master branch
  * Improved a wide variety of error messages
  * Improved STA timing reports (more details, clearer format)
  * VPR now uses Tatum as its STA engine
- * VPR now detects missmatched architecture (.xml) and implementation (.net/.place/.route) files more robustly
+ * VPR now detects mismatched architecture (.xml) and implementation (.net/.place/.route) files more robustly
  * Improved router run-time and quality through incremental re-routing and improved handling of high-fanout nets
  * The timing edges within each netlist primitive must now be specified in the <models> section of the architecture file
  * All interconnect tags must have unique names in the architecture file
@@ -164,8 +164,8 @@ _The following are changes which have been implemented in the VTR master branch
  * Various other changes since VTR 7
 
 ### Fixed
- * FPGA Architecture file tags can be in arbitary orders
- * SDC command arguments can be in arbitary orders
+ * FPGA Architecture file tags can be in arbitrary orders
+ * SDC command arguments can be in arbitrary orders
  * Numerous other fixes since VTR 7
 
 ### Removed
@@ -229,7 +229,7 @@ $ sudo docker run -it mohamedelgammal/vtr8:latest
  * Improved a wide variety of error messages
  * Improved STA timing reports (more details, clearer format)
  * VPR now uses Tatum as its STA engine
- * VPR now detects missmatched architecture (.xml) and implementation (.net/.place/.route) files more robustly
+ * VPR now detects mismatched architecture (.xml) and implementation (.net/.place/.route) files more robustly
  * Improved router run-time and quality through incremental re-routing and improved handling of high-fanout nets
  * The timing edges within each netlist primitive must now be specified in the <models> section of the architecture file
  * All interconnect tags must have unique names in the architecture file
@@ -245,8 +245,8 @@ $ sudo docker run -it mohamedelgammal/vtr8:latest
  * Various other changes since VTR 7
 
 ### Fixed
- * FPGA Architecture file tags can be in arbitary orders
- * SDC command arguments can be in arbitary orders
+ * FPGA Architecture file tags can be in arbitrary orders
+ * SDC command arguments can be in arbitrary orders
  * Numerous other fixes since VTR 7
 
 ### Deprecated

CONTRIBUTING.md

@@ -27,7 +27,7 @@ If VTR does not support your use case, consider [filling an enhancement](#fillin
 
 ### I have a bug-fix/feature I'd like to include in VTR
 Great! Submitting bug-fixes and features is a great way to improve VTR.
-See the guidlines for [submitting code](#submitting-code-to-vtr).
+See the guidelines for [submitting code](#submitting-code-to-vtr).
 
 ## The Details
 

Makefile

@@ -1,7 +1,7 @@
 # This is a simple wrapper which hides cmake (for convenience, and from non-expert end users).
 #
 # It supports the targets:
-#   'make'           - builds everything (all libaries/executables)
+#   'make'           - builds everything (all libraries/executables)
 #   'make clean'     - removes generated build objects/libraries/executables etc.
 #   'make distclean' - will clean everything including the cmake generated build files
 #

README.developers.md

@@ -2,7 +2,7 @@
 
 For general guidance on contributing to VTR see [Submitting Code to VTR](CONTRIBUTING.md#submitting-code-to-vtr).
 
-The actual machanics of submitting code are outlined below.
+The actual mechanics of submitting code are outlined below.
 
 However they differ slightly depending on whether you are:
  * an **internal developer** (i.e. you have commit access to the main VTR repository at `github.com/verilog-to-routing/vtr-verilog-to-routing`) or, 
@@ -149,7 +149,7 @@ To provide quick context, some VTR developers also tag the first line with the m
 ## Commit Structure
 Generally, you should strive to keep commits atomic (i.e. they do one logical change to the code).
 This often means keeping commits small and focused in what they change.
-Of course, a large number of miniscule commits is also unhelpful (overwhelming and difficult to see the structure), and sometimes things can only be done in large changes -- so use your judgement.
+Of course, a large number of minuscule commits is also unhelpful (overwhelming and difficult to see the structure), and sometimes things can only be done in large changes -- so use your judgement.
 A reasonable rule of thumb is to try and ensure VTR will still compile after each commit.
 
 For those familiar with history re-writing features in git (e.g. rebase) you can sometimes use these to clean-up your commit history after the fact.
@@ -627,7 +627,7 @@ stratixiv_arch.timing.xml	cholesky_mc_stratixiv_arch_timing.blif  	0208312
 ```
 
 ### Example: NoC Benchmarks QoR Measurements
-NoC benchmarks currently include synthetic and MLP benchmarks. Synthetic benchmarks have various NoC traffic patters,
+NoC benchmarks currently include synthetic and MLP benchmarks. Synthetic benchmarks have various NoC traffic patterns,
 bandwidth utilization, and latency requirements. High-quality NoC router placement solutions for these benchmarks are
 known. By comparing the known solutions with NoC router placement results, the developer can evaluate the sanity of 
 the NoC router placement algorithm. MLP benchmarks are the only realistic netlists included in this benchmark set.
@@ -702,7 +702,7 @@ 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).
 
-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):
+To make running all the koios benchmarks easier, especially with those 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 
@@ -1099,7 +1099,7 @@ Introduce a test case using the `TEST_CASE` macro, and include a name and a tag.
 #include "catch2/catch_test_macros.hpp"
 
 // To choose a tag (written with square brackets "[tag]"), see examples from when you run ./test_vpr
-// --list-tests in the tester exectuable directory, as shown earlier. A good default tag name is the name
+// --list-tests in the tester executable directory, as shown earlier. A good default tag name is the name
 // of the tester: in this case, [vpr].
 TEST_CASE("a_vpr_test_name", "[vpr]") {
   int x = 0;
@@ -1467,7 +1467,7 @@ exists on a different branch).
    commit.
 
 5. Recreate the local changes from step 2 above, such that the library builds
-   without issue; preferrably in a concise way such that the library can be
+   without issue; preferably in a concise way such that the library can be
    easily updated in the future.
 
 ## Adding a new Subtree

cmake/toolchains/mingw-linux-cross-compile-to-windows.cmake

@@ -1,17 +1,17 @@
 # the name of the target operating system
 SET(CMAKE_SYSTEM_NAME Windows)
 
-option(STATIC_LIBGCC_LIBSTDCPP "Link to libgcc and libstdc++ statically. If not set, requires libgcc and libstdc++ DLLs to be installed on the target machines. Note that static linking libgcc means exceptions will not propagate accross shared library boundaries." OFF) 
+option(STATIC_LIBGCC_LIBSTDCPP "Link to libgcc and libstdc++ statically. If not set, requires libgcc and libstdc++ DLLs to be installed on the target machines. Note that static linking libgcc means exceptions will not propagate across shared library boundaries." OFF) 
 
 #Note that if libgcc and libstdcpp are NOT statically linked the appropriate
 #DLL's should be installed on the target Windows machine, or distributed with
-#the generated executables (e.g. in the same directory as the exectuable). 
+#the generated executables (e.g. in the same directory as the executable). 
 #
 #They are usually installed under:
 #   /usr/lib/gcc/${COMPILER_PEFIX}/*-win32/libgcc*.dll
 #   /usr/lib/gcc/${COMPILER_PEFIX}/*-win32/libstdc++*.dll
 #
-#For example targetting x86_64 with MingW based on gcc 5.3
+#For example targeting x86_64 with MingW based on gcc 5.3
 #   /usr/lib/gcc/x86_64-w64-mingw32/5.3-win32/libstdc++*.dll
 #   /usr/lib/gcc/x86_64-w64-mingw32/5.3-win32/libgcc*.dll
 
@@ -52,7 +52,7 @@ set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
 add_definitions(-DHAVE_STRUCT_TIMESPEC=1)
 
 #This forces ABC to use the stdint types (e.g. ptrdiff_t) instead of its platform
-#dependant type look-up. This avoids 'unkown platform' compilation errors.
+#dependent type look-up. This avoids 'unkown platform' compilation errors.
 add_definitions(-DABC_USE_STDINT_H=1)
 
 if (STATIC_LIBGCC_LIBSTDCPP)

dev/BROKEN_ENV/alpine/Dockerfile

@@ -34,7 +34,7 @@ RUN git clone https://github.com/c9/core.git /cloud9
 RUN curl -s -L https://raw.githubusercontent.com/c9/install/master/link.sh | bash
 RUN /cloud9/scripts/install-sdk.sh
 
-# Tweak standlone.js conf
+# Tweak standalone.js conf
 RUN sed -i -e 's_127.0.0.1_0.0.0.0_g' /cloud9/configs/standalone.js
 
 RUN touch /etc/supervisor.conf
@@ -60,4 +60,4 @@ VOLUME /workspace
 
 EXPOSE 8080
 
-CMD ["supervisord", "-c", "/etc/supervisor.conf"]
+CMD ["supervisord", "-c", "/etc/supervisor.conf"]

dev/DOCKER_DEPLOY.md

@@ -3,7 +3,7 @@
 ## Overview
 Docker creates an isolated container on your system so you know that VTR will run without further configurations nor affecting any other work.
 
-Our Docker file sets up this enviroment by installing all necessary Linux packages and applications as well as Perl modules.
+Our Docker file sets up this environment by installing all necessary Linux packages and applications as well as Perl modules.
 
 ## Setup
 
@@ -38,7 +38,7 @@ The project root directory from the docker build process is copied and placed in
     docker exec -it vtr /bin/bash
     ```
 
-1. Verfiy that VTR has been installed correctly:
+1. Verify that VTR has been installed correctly:
 
     ```sh
     # in container

dev/README.md

@@ -1 +1 @@
-This folder contains addtional development related tools and documentation
+This folder contains additional development related tools and documentation

dev/Running_On_ARM(raspberry_pi).txt

@@ -30,5 +30,5 @@ RUN apt-get install -y nodejs
 RUN git clone https://github.com/c9/core.git /cloud9
 RUN /cloud9/scripts/install-sdk.sh
 
-# Tweak standlone.js conf
+# Tweak standalone.js conf
 RUN sed -i -e 's_127.0.0.1_0.0.0.0_g' /cloud9/configs/standalone.js

dev/ammend-format.sh

@@ -1,5 +1,5 @@
 #!/usr/bin/env bash
-#Reformats and then ammends the currently checked-out commit
+#Reformats and then amends the currently checked-out commit
 #
 #Usually used by rebase-format.sh
 

dev/gen_arch/gen_c_chain_arch_sweep.c

@@ -52,7 +52,7 @@ static void print_header(FILE *fpout) {
 	fprintf(fpout, "  - General purpose logic block: \n");
 	fprintf(fpout, "    K = 6, N = 10, fracturable 6 LUTs (can operate as one 6-LUT or two 5-LUTs with all 5 inputs shared) \n");
 	fprintf(fpout, "    with optionally registered outputs\n");
-	fprintf(fpout, "    Each 5-LUT has an arithemtic mode that converts it to a single-bit adder with both inputs driven by 4-LUTs (both 4-LUTs share all 4 inputs)\n");
+	fprintf(fpout, "    Each 5-LUT has an arithmetic mode that converts it to a single-bit adder with both inputs driven by 4-LUTs (both 4-LUTs share all 4 inputs)\n");
 	fprintf(fpout, "    Carry chain links to vertically adjacent logic blocks\n");
 	fprintf(fpout, "  - Memory size 32 Kbits, memory aspect ratios vary from a data width of 1 to data width of 64.  \n");
 	fprintf(fpout, "    Height = 6, found on every (8n+2)th column\n");
@@ -100,7 +100,7 @@ static void print_header(FILE *fpout) {
 	fprintf(fpout, "  & delay of the Stratix IV crossbar as a good approximation of our crossbar.\n");
 	fprintf(fpout, "\n");
 	fprintf(fpout, "  For LUTs, we include LUT \n");
-	fprintf(fpout, "  delays measured from Stratix IV which is dependant on the input used (ie. some \n");
+	fprintf(fpout, "  delays measured from Stratix IV which is dependent on the input used (ie. some \n");
 	fprintf(fpout, "  LUT inputs are faster than others).  The CAD tools at the time of VTR 7 does \n");
 	fprintf(fpout, "  not consider differences in LUT input delays.\n");
 	fprintf(fpout, "\n");

dev/gen_arch/gen_frac_arch_sweep.c

@@ -51,7 +51,7 @@ static void print_header(FILE *fpout) {
 	fprintf(fpout, "  - General purpose logic block: \n");
 	fprintf(fpout, "    K = 6, N = 10, fracturable 6 LUTs (can operate as one 6-LUT or two 5-LUTs with all 5 inputs shared) \n");
 	fprintf(fpout, "    with optionally registered outputs\n");
-	fprintf(fpout, "    Each 5-LUT has an arithemtic mode that converts it to a single-bit adder with both inputs driven by 4-LUTs (both 4-LUTs share all 4 inputs)\n");
+	fprintf(fpout, "    Each 5-LUT has an arithmetic mode that converts it to a single-bit adder with both inputs driven by 4-LUTs (both 4-LUTs share all 4 inputs)\n");
 	fprintf(fpout, "    Carry chain links to vertically adjacent logic blocks\n");
 	fprintf(fpout, "  - Memory size 32 Kbits, memory aspect ratios vary from a data width of 1 to data width of 64.  \n");
 	fprintf(fpout, "    Height = 6, found on every (8n+2)th column\n");
@@ -99,7 +99,7 @@ static void print_header(FILE *fpout) {
 	fprintf(fpout, "  & delay of the Stratix IV crossbar as a good approximation of our crossbar.\n");
 	fprintf(fpout, "\n");
 	fprintf(fpout, "  For LUTs, we include LUT \n");
-	fprintf(fpout, "  delays measured from Stratix IV which is dependant on the input used (ie. some \n");
+	fprintf(fpout, "  delays measured from Stratix IV which is dependent on the input used (ie. some \n");
 	fprintf(fpout, "  LUT inputs are faster than others).  The CAD tools at the time of VTR 7 does \n");
 	fprintf(fpout, "  not consider differences in LUT input delays.\n");
 	fprintf(fpout, "\n");

dev/odin2_helper/verilog_preprocessor.c++

@@ -1,6 +1,6 @@
 /* TODOS:
  * - find constants in not base 12 that have implicit length - add 32 to front
- * - convert multidim wire thing to use pure indicies
+ * - convert multidim wire thing to use pure indices
  * - generate loops
  * - add #(...) to defparam conversion
  * - remove signed, arithmetic shifts?

dev/pylint_check.py

@@ -149,9 +149,9 @@ def expand_paths():
             for glob_path in path.glob(glob_str):
                 paths.append(glob_path)
 
-        # Non-existant paths, and unhanlded file types error
+        # Non-existent paths, and unhanlded file types error
         elif not path.exists():
-            error("Non-existant path:", path)
+            error("Non-existent path:", path)
         else:
             error("Unhandled path:", path)
     return paths

dev/rebase-format.sh

@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 
-#Reformat and ammend each commit since the provided 
+#Reformat and amend each commit since the provided 
 #commit-sh argument
 #
 #NOTE: Only use on local branches!

dev/tutorial/ToNewVTRAdmin.txt

@@ -22,7 +22,7 @@ Whenever anyone commits code, our buildbot setup will automatically compile the
 code then run some regression tests.  Buildbot flags problems and reports who 
 made which commit.  The VTR buildbot website is located here: 
 http://canucks.eecg.toronto.edu:8080/ It gives you regular updates on the state 
-of thet trunk. As the administrator, you should check buildbot regularly (eg. 
+of the trunk. As the administrator, you should check buildbot regularly (eg. 
 once a day in the morning). When the trunk breaks, e-mail the person who broke 
 it.  Details of the management of the buildbot system itself should already be 
 e-mailed out.

dev/vtr_test_suite_verifier/verify_test_suites.py

@@ -228,7 +228,7 @@ def verify_test_suites():
 
     # If any failures were found in any suite, return exit code 1.
     if num_failures != 0:
-        print(f"Failure: Test suite verifcation failed with {num_failures} failures")
+        print(f"Failure: Test suite verification failed with {num_failures} failures")
         print(f"Please fix the failing test suites found in {args.vtr_regression_tests_dir}")
         print(f"If necessary, update the test suites info found here: {args.test_suite_info}")
         sys.exit(1)

doc/README

@@ -6,7 +6,7 @@ The VTR documentation is generated using sphinx, a python based documentation ge
 The documentation itself is written in re-structured text (files ending in .rst), which
 is a lightweight mark-up language for text documents.
 
-Currently VTR's documenation is automatically built by https://readthedocs.org/projects/vtr/ and is served at:
+Currently VTR's documentation is automatically built by https://readthedocs.org/projects/vtr/ and is served at:
 
     https://docs.verilogtorouting.org/
 
@@ -56,7 +56,7 @@ The root of the VTR documentation is the 'src/index.rst' file.
 
 This file references other files using the toctree directive.
 
-Key sub-systems of VTR have their documentation located in a sub-directory (e.g. vpr, arch), with thier own index.rst.
+Key sub-systems of VTR have their documentation located in a sub-directory (e.g. vpr, arch), with their own index.rst.
 
 Within each sub-directory there are usually several other .rst files which containing actual documentation for the subsystem.
 Each of these files must be referred to in the sub-system's index.rst in order to be included in the generated documentation.

doc/src/abc/index.rst

@@ -3,6 +3,6 @@
 ABC
 ===
 
-ABC is included within VTR to perform technology independant logic optimization and technology mapping.
+ABC is included within VTR to perform technology independent logic optimization and technology mapping.
 
 ABC is developed at UC Berkeley, see the `ABC homepage <http://www.eecs.berkeley.edu/~alanmi/abc/>`_ for details.