Grammatical/spelling corrections

Name addition to Contributors

Signed-off-by: Harpreet Kaur <[email protected]>

Author: harpreetbamrah

ODIN_II/SRC/netlist_create_from_ast.cpp

@@ -2745,7 +2745,7 @@ signal_list_t* create_pins(ast_node_t* var_declare, char* name, char* instance_n
 
 /*---------------------------------------------------------------------------------------------
  * (function: create_output_pin)
- * 	Create OUTPUT pin creates a pin representing this naming isntance, adds it to the input
+ * 	Create OUTPUT pin creates a pin representing this naming instance, adds it to the input
  * 	nets list (if not already there) and adds the pin to the list.
  * 	Note: only for output drivers...
  *-------------------------------------------------------------------------------------------*/

ODIN_II/SRC/odin_ii.cpp

@@ -108,7 +108,7 @@ static ODIN_ERROR_CODE synthesize_verilog() {
     module_names_to_idx = sc_new_string_cache();
 
     /* parse to abstract syntax tree */
-    printf("Parser starting - we'll create an abstract syntax tree. Note this tree can be viewed using Grap Viz (see documentation)\n");
+    printf("Parser starting - we'll create an abstract syntax tree. Note this tree can be viewed using GraphViz (see documentation)\n");
     verilog_ast = init_parser();
     parse_to_ast();
     /**

README.md

@@ -98,7 +98,7 @@ Professors: Kenneth Kent, Vaughn Betz, Jonathan Rose, Jason Anderson, Peter Jami
 Research Assistants: Aaron Graham
 
 
-Graduate Students: Kevin Murray, Jason Luu, Oleg Petelin, Xifian Tang, Mohamed Elgammal, Mohamed Eldafrawy, Jeffrey Goeders, Chi Wai Yu, Andrew Somerville, Ian Kuon, Alexander Marquardt, Andy Ye, Wei Mark Fang, Tim Liu, Charles Chiasson, Panagiotis (Panos) Patros, Jean-Philippe Legault, Aaron Graham, Nasrin Eshraghi Ivari, Maria Patrou, Scott Young, Sarah Khalid, Seyed Alireza Damghani
+Graduate Students: Kevin Murray, Jason Luu, Oleg Petelin, Xifian Tang, Mohamed Elgammal, Mohamed Eldafrawy, Jeffrey Goeders, Chi Wai Yu, Andrew Somerville, Ian Kuon, Alexander Marquardt, Andy Ye, Wei Mark Fang, Tim Liu, Charles Chiasson, Panagiotis (Panos) Patros, Jean-Philippe Legault, Aaron Graham, Nasrin Eshraghi Ivari, Maria Patrou, Scott Young, Sarah Khalid, Seyed Alireza Damghani, Harpreet Kaur
 
 
 Summer Students: Opal Densmore, Ted Campbell, Cong Wang, Peter Milankov, Scott Whitty, Michael Wainberg, Suya Liu, Miad Nasr, Nooruddin Ahmed, Thien Yu, Long Yu Wang, Matthew J.P. Walker, Amer Hesson, Sheng Zhong, Hanqing Zeng, Vidya Sankaranarayanan, Jia Min Wang, Eugene Sha, Jean-Philippe Legault, Richard Ren, Dingyu Yang, Alexandrea Demmings, Hillary Soontiens, Julie Brown, Bill Hu, David Baines, Mahshad Farahani, Helen Dai, Daniel Zhai

doc/src/odin/dev_guide/contributing.md

@@ -8,7 +8,7 @@ To fix issues or add a new feature submit a PR or WIP PR following the provided
 **Important** Before creating a Pull Request (PR), if it is a bug you have happened upon and intend to fix make sure you create an issue beforehand.
 
 Pull requests are intended to correct bugs and improve Odin's performance.
-To create a pull request, clone the vtr-verilog-rooting repository and branch from the master.
+To create a pull request, clone the [vtr-verilog-to-routing repository](https://github.com/verilog-to-routing/vtr-verilog-to-routing) and branch from the master.
 Make changes to the branch that improve Odin II and correct the bug.
 **Important** In addition to correcting the bug, it is required that test cases (benchmarks) are created that reproduce the issue and are included in the regression tests.
 An example of a good test case could be the benchmark found in the "Issue" being addressed.
@@ -21,9 +21,9 @@ Add a description of the changes made and reference the "issue" that it corrects
 **Important** Before creating a WIP PR, if it is a bug you have happened upon and intend to fix make sure you create an issue beforehand.
 
 A "work in progress" PR is a pull request that isn't complete or ready to be merged.
-It is intended to demonstrate that an Issue is being addressed and indicates to other developpers that they don't need to fix it.
-Creating a WIP PR is similar to a regular PR with a few adjustements.
-First, clone the [vtr-verilog-rooting repository](https://github.com/verilog-to-routing/vtr-verilog-to-routing) and branch from the master.
+It is intended to demonstrate that an Issue is being addressed and indicates to other developers that they don't need to fix it.
+Creating a WIP PR is similar to a regular PR with a few adjustments.
+First, clone the [vtr-verilog-to-routing repository](https://github.com/verilog-to-routing/vtr-verilog-to-routing) and branch from the master.
 Make changes to that branch.
 Then, create a pull request with that branch and **include WIP in the title.**
 This will automatically indicate that this PR is not ready to be merged.

doc/src/odin/dev_guide/regression_test.md

@@ -5,30 +5,30 @@ Each regression test targets a specific function of Odin II.
 There are two main components of a regression test; benchmarks and a configuration file.
 The benchmarks are comprised of verilog files, input vector files and output vector files.
 The configuration file calls upon each benchmark and synthesizes them with different architectures.
-The current regression tests of Odin II can be found in regression_test/benchmarks.
+The current regression tests of Odin II can be found in regression_test/benchmark.
 
 ## Benchmarks
 
 Benchmarks are used to test the functionality of Odin II and ensure that it runs properly.
-Benchmarks of Odin II can be found in regression_test/benchmarks/verilog/any_folder.
+Benchmarks of Odin II can be found in regression_test/benchmark/verilog/any_folder.
 Each benchmark is comprised of a verilog file, an input vector file, and an output vector file.
 They are called upon during regression tests and synthesized with different architectures to be compared against the expected results.
-These tests are usefull for developers to test the functionality of Odin II after implementing changes.
+These tests are useful for developers to test the functionality of Odin II after implementing changes.
 The command `make test` runs through all these tests, comparing the results to previously generated results, and should be run through when first installing.
 
 ### Unit Benchmarks
 
-Unit Benchmarks are the simplest of benchmarks. They are meant to isolate different functions of Odin II.
+Unit benchmarks are the simplest of benchmarks. They are meant to isolate different functions of Odin II.
 The goal is that if it does not function properly, the error can be traced back to the function being tested.
 This cannot always be achieved as different functions depend on others to work properly.
-It is ideal that these benchmarks test bit size capacity, errorenous cases, as well as standards set by the IEEE Standard for Verilog® Hardware Description Language - 2005.
+It is ideal that these benchmarks test bit size capacity, erroneous cases, as well as standards set by the IEEE Standard for Verilog® Hardware Description Language - 2005.
 
 ### Micro Benchmarks
 
-Micro benchmark's are precise, like unit benchmarks, however are more syntactic.
+Micro benchmarks are precise, like unit benchmarks, however are more syntactic.
 They are meant to isolate the behaviour of different functions.
 They trace the behaviour of functions to ensure they adhere to the IEEE Standard for Verilog® Hardware Description Language - 2005.
-Like micro benchmarks, they should check errorenous cases and behavioural standards et by the IEEE Standard for Verilog® Hardware Description Language - 2005.
+Like unit benchmarks, they should check erroneous cases and behavioural standards set by the IEEE Standard for Verilog® Hardware Description Language - 2005.
 
 ### Macro Benchmarks
 
@@ -38,10 +38,10 @@ These tests are designed to test things like syntax and more complicated standar
 
 ### External Benchmarks
 
-External Benchmarks are benchmarks created by outside users to the project.
+External benchmarks are benchmarks created by outside users to the project.
 It is possible to pull an outside directory and build them on the fly thus creating a benchmark for Odin II.
 
-## Creating Regression tests
+## Creating Regression Tests
 
 ### New Regression Test Checklist
 
@@ -50,7 +50,7 @@ It is possible to pull an outside directory and build them on the fly thus creat
 * Create a folder in the task directory for the configuration file [here](#creating-a-task)
 * Generate the results [here](#regenerating-results)
 * Add the task to a suite (large suite if generating the results takes longer than 3 minutes, otherwise put in light suite) [here](#creating-a-suite)
-* Update the documentation by providing a summary in Regression Test Summary section and updating the Directory tree [here](#regression-test-summaries)
+* Update the documentation by providing a summary in Regression Test Summary section and updating the Directory Tree [here](#regression-test-summaries)
 
 ### New Benchmarks added to Regression Test Checklist
 
@@ -61,22 +61,22 @@ It is possible to pull an outside directory and build them on the fly thus creat
 
 * verilog file
 * input vector file
-* expected ouptut vector file
+* expected output vector file
 * configuration file (conditional)
 * architecture file (optional)
 
 ### Creating Benchmarks
 
 If only a few benchmarks are needed for a PR, simply add the benchmarks to the appropriate set of regression tests.
-[The Regression Test Summary](#regression-test-summaries) summarizes the target of each regression test which may be helpful.
+The [Regression Test Summary](#regression-test-summaries) summarizes the target of each regression test which may be helpful.
 
 The standard of naming the benchmarks are as follows:
 
 * verilog file: meaningful_title.v
 * input vector file: meaningful_title_input
 * output vector file: meaningful_title_output
 
-If the tests needed do not fit in an already existing set of regression tests or need certain architecture(s), create a seperate folder in the verilog directory and label appropriately.
+If the tests needed do not fit in an already existing set of regression tests or need certain architecture(s), create a separate folder in the verilog directory and label appropriately.
 Store the benchmarks in that folder.
 Add the architecture (if it isn't one that already exists) to ../vtr_flow/arch.
 
@@ -147,12 +147,12 @@ Regression Parameters:
 * `--concat_circuit_list`    concatenate the circuit list and pass it straight through to odin
 * `--generate_bench`         generate input and output vectors from scratch
 * `--disable_simulation`     disable the simulation for this task
-* `--disable_parallel_jobs`  disable running circuit/task pairs in parralel
-* `--randomize`             performs a dry run randomly to check the validity of the task and flow                        |
-* `--regenerate_expectation`regenerates expectation and overrides thee expected value only if there's a mismatch          |
-* `--generate_expectation`   generate the expectation and overrides the expectation file                                  |
+* `--disable_parallel_jobs`  disable running circuit/task pairs in parallel
+* `--randomize`             perform a dry run randomly to check the validity of the task and flow                        |
+* `--regenerate_expectation`regenerate expectation and override the expected value only if there's a mismatch          |
+* `--generate_expectation`   generate the expectation and override the expectation file                                  |
 
-### Creating a task
+### Creating a Task
 
 The following diagram illustrates the structure of regression tests.
 Each regression test needs a corresponding folder in the task directory containing the configuration file.
@@ -179,7 +179,7 @@ The task diplay name and the verilog file group should share the same title.
 
 There are times where multiple configuration files are needed in a regression test due to different commands wanted or architectures.
 The task cmd_line_args is an example of this.
-If that is the case, each configuration file will still need its own folder, however these folder's should be placed in a parent folder.
+If that is the case, each configuration file will still need its own folder, however these folders should be placed in a parent folder.
 
 ```bash
 └── ODIN_II
@@ -205,7 +205,7 @@ If that is the case, each configuration file will still need its own folder, how
 
 Suites are used to call multiple tasks at once. This is handy for regenerating results for multiple tasks.
 In the diagram below you can see the structure of the suite.
-The suite contains a configuration file that calls upon the different tasks **named task_list.conf**.  
+The suite contains a configuration file that calls upon the different tasks named **task_list.conf**.
 
 ```bash
 └── ODIN_II
@@ -266,7 +266,7 @@ then: where N is the number of processors in the computer, and the path followin
 
 > **NOTE**
 >
-> **DO NOT** run the `make sanitize` if regenerating the large test. It is probable that the computer will not have a enough ram to do so and it will take a long time. Instead run `make build`
+> **DO NOT** run the `make sanitize` if regenerating the large test. It is probable that the computer will not have enough ram to do so and it will take a long time. Instead run `make build`
 
 For more on regenerating results, refer to the [Verify Script](./verify_script.md) section.
 
@@ -299,19 +299,19 @@ This regression test targets cases that require a lot of ram and time.
 
 ### micro
 
-The micro regression tests targets hards blocks and pieces that can be easily instantiated in architectures.
+The micro regression test targets hards blocks and pieces that can be easily instantiated in architectures.
 
 ### mixing_optimization
 
-The mixing optimization regression tests targets mixing implementations for operations implementable in hard blocks and their soft logic counterparts that can be can be easily instantiated in architectures. The tests support extensive command line coverage, as well as provide infrastructure to enable the optimization from an .xml configuration file, require for using the optimization as a part of VTR synthesis flow.
+The mixing optimization regression test targets mixing implementations for operations implementable in hard blocks and their soft logic counterparts that can be can be easily instantiated in architectures. The tests support extensive command line coverage, as well as provide infrastructure to enable the optimization from an .xml configuration file, require for using the optimization as a part of VTR synthesis flow.
 
 ### operators
 
-This regression test targets the functionality of different opertators. It checks bit size capacity and behaviour.  
+This regression test targets the functionality of different operators. It checks bit size capacity and behaviour.
 
 ### syntax
 
-The syntax regression tests targets syntactic behaviour. It checks that functions work cohesively together and adhere to the verilog standard.
+The syntax regression test targets syntactic behaviour. It checks that functions work cohesively together and adhere to the verilog standard.
 
 ### keywords
 

doc/src/odin/dev_guide/verify_script.md

@@ -47,7 +47,7 @@ make sanitize
 ```
 
 A synthesis_result.json and a simulation_result.json will be generated in the task's folder.
-The simulation results for each benchmark are only generated if they syntehsize correctly (no exit error), thus if none of the benchmarks synthesize there will be no simulation_result.json generated.
+The simulation results for each benchmark are only generated if they synthesize correctly (no exit error), thus if none of the benchmarks synthesize there will be no simulation_result.json generated.
 
 ### Regenerating Results for a Changed Test