docs: Strip trailing white space.

CONTRIBUTING.md

@@ -15,7 +15,7 @@ That way someone (perhaps your future self!) will be able to quickly find the an
 ### I found a bug!
 While we strive to make VTR reliable and robust, bugs are inevitable in large-scale software projects.
 
-Please file a [detailed bug report](#filling-bug-reports). 
+Please file a [detailed bug report](#filling-bug-reports).
 This ensures we know about the problem and can work towards fixing it.
 
 
@@ -61,7 +61,7 @@ This information helps us to quickly reproduce (and hopefully fix) the issue:
  *This is key to getting your bug fixed.*
 
  Provided *detailed steps* to reproduce the bug, including the exact commands to reproduce the bug.
- Attach all relevant files (e.g. FPGA architecture files, benchmark circuits, log files). 
+ Attach all relevant files (e.g. FPGA architecture files, benchmark circuits, log files).
 
  If we can't re-produce the issue it is very difficult to fix.
 
@@ -89,7 +89,7 @@ If not feature request exists you will need to describe your enhancement:
  How your proposed enhancement will work (from a user's perspective).
 
 * Contrast with current behaviour
- 
+
  How will your enhancement differ from the current behaviour (from a user's perspective).
 
 * Potential Implementation
@@ -139,7 +139,7 @@ Code-changes should also describe:
  This ensures any future changes which break your feature will be detected.
  It is also best to add tests when fixing bugs, for the same reason
 
- See [Adding Tests](README.developers.md#adding-tests) for details on how to create new regression tests. 
+ See [Adding Tests](README.developers.md#adding-tests) for details on how to create new regression tests.
  If you aren't sure what tests are needed, ask a maintainer.
 
 * How the feature has been documented

LICENSE.md

@@ -4,25 +4,25 @@ The software package "VTR" includes the software tools ODIN II, ABC, and VPR as
 well as additional benchmarks, documentation, libraries and scripts. The authors
 of the various components of VTR retain their ownership of their tools.
 
-* Unless otherwise noted (in particular ABC, the benchmark circuits and some libraries), 
+* Unless otherwise noted (in particular ABC, the benchmark circuits and some libraries),
 all software, documents, and scripts in VTR, follows the standard MIT license described
 [here](http://www.opensource.org/licenses/mit-license.php) copied below for
 your convenience:
 
-> The MIT License (MIT) 
+> The MIT License (MIT)
 >
 > Copyright 2012 VTR Developers
-> 
+>
 > Permission is hereby granted, free of charge, to any person obtaining a copy of
 > this software and associated documentation files (the "Software"), to deal in
 > the Software without restriction, including without limitation the rights to
 > use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
 > of the Software, and to permit persons to whom the Software is furnished to do
 > so, subject to the following conditions:
-> 
+>
 > The above copyright notice and this permission notice shall be included in all
 > copies or substantial portions of the Software.
-> 
+>
 > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 > IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 > FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
@@ -36,17 +36,17 @@ your convenience:
 for your convenience:
 
 > Copyright (c) The Regents of the University of California. All rights reserved.
-> 
+>
 > Permission is hereby granted, without written agreement and without license or
 > royalty fees, to use, copy, modify, and distribute this software and its
 > documentation for any purpose, provided that the above copyright notice and the
 > following two paragraphs appear in all copies of this software.
-> 
+>
 > IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR
 > DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF
 > THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF
 > CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-> 
+>
 > THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING,
 > BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 > A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS,

README.developers.md

@@ -10,7 +10,7 @@ In the event that you are responsible for "breaking the build", fix the build at
 
 We have some guidelines in place to help catch most of these problems:
 
-1. Before you push code to the central repository, your code MUST pass the check-in regression test.  
+1. Before you push code to the central repository, your code MUST pass the check-in regression test. 
  The check-in regression test is a quick way to test if any part of the VTR flow is broken.
 
  At a minimum you must run:
@@ -37,9 +37,9 @@ We have some guidelines in place to help catch most of these problems:
  See [Adding Tests](#adding-tests) for details.
 
 4. In the event a regression test is broken, the one responsible for having the test pass is in charge of determining:
- * If there is a bug in the source code, in which case the source code needs to be updated to fix the bug, or 
- * If there is a problem with the test (perhaps the quality of the tool did in fact get better or perhaps there is a bug with the test itself), in which case the test needs to be updated to reflect the new changes.  
-  
+ * If there is a bug in the source code, in which case the source code needs to be updated to fix the bug, or
+ * If there is a problem with the test (perhaps the quality of the tool did in fact get better or perhaps there is a bug with the test itself), in which case the test needs to be updated to reflect the new changes. 
+
  If the golden results need to be updated and you are sure that the new golden results are better, use the command `../scripts/parse_vtr_task.pl -create_golden your_regression_test_name_here`
 
 5. Keep in sync with the master branch as regularly as you can (i.e. `git pull` or `git pull --rebase`).
@@ -88,9 +88,9 @@ There are 4 main regression tests:
  * MCNC20 benchmarks
  * VTR benchmarks
  * Titan 'other' benchmarks (smaller than Titan23)
-  
+ 
  **Architectures:** A wider variety of architectures
-  
+ 
 * `vtr_reg_weekly`: ~30 hours with `-j2`
 
  **Goal:** Full QoR and Performance evaluation.
@@ -101,7 +101,7 @@ There are 4 main regression tests:
 
  * VTR benchmarks
  * Titan23 benchmarks
-  
+ 
  **Architectures:** A wide variety of architectures
 
 These can be run with `run_reg_test.pl`:
@@ -171,7 +171,7 @@ regression_tests/vtr_reg_basic/basic_no_timing
 k4_N10_memSize16384_memData64/ch_intrinsics...failed: vpr
 k4_N10_memSize16384_memData64/diffeq1...failed: vpr
 #Output trimmed...
-regression_tests/vtr_reg_basic/basic_no_timing...[Fail] 
+regression_tests/vtr_reg_basic/basic_no_timing...[Fail]
  k4_N10_memSize16384_memData64.xml/ch_intrinsics.v vpr_status: golden = success result = exited
 #Output trimmed...
 Error: 10 tests failed!
@@ -255,7 +255,7 @@ This describes adding a test to `vtr_reg_strong`, but the process is similar for
  $ cp strong_timing/config/config.txt strong_mytest/config/.
  ```
  You can now edit `strong_mytest/config/config.txt` to customize your test.
-  
+
 2. Generate golden reference results
 
  Now we need to test our new test and generate 'golden' reference results.
@@ -411,7 +411,7 @@ To submit a build to coverity do the following:
 Note that we explicitly asked for gcc and g++, the coverity build tool defaults to these compilers, and may not like the default 'cc' or 'c++' (even if they are linked to gcc/g++).
 
 3. Run the coverity build tool
-  
+
  ```shell
  #From the build directory where we ran cmake
  cov-build --dir cov-int make -j8
@@ -437,7 +437,7 @@ You may need to configure coverity to 'know' about your compiler. For example:
  ```shell
  cov-configure --compiler `which gcc-7`
  ```
-  
+
 On unix-like systems run `scan-build make` from the root VTR directory.
 to output the html analysis to a specific folder, run `scan-build make -o /some/folder`
 

README.md

@@ -1,5 +1,5 @@
 # Introduction
-The Verilog-to-Routing (VTR) project is a world-wide collaborative effort to provide a open-source framework for conducting FPGA architecture and CAD research and development. 
+The Verilog-to-Routing (VTR) project is a world-wide collaborative effort to provide a open-source framework for conducting FPGA architecture and CAD research and development.
 The VTR design flow takes as input a Verilog description of a digital circuit, and a description of the target FPGA architecture.
 It then perfoms:
  * Elaboration & Synthesis (ODIN II)
@@ -33,9 +33,9 @@ Bibtex:
  author={Luu, Jason and Goeders, Jeff and Wainberg, Michael and Somerville, Andrew and Yu, Thien and Nasartschuk, Konstantin and Nasr, Miad and Wang, Sen and Liu, Tim and Ahmed, Norrudin and Kent, Kenneth B. and Anderson, Jason and Rose, Jonathan and Betz, Vaughn},
  journal = {ACM Trans. Reconfigurable Technol. Syst.},
  month={June},
- volume={7}, 
- number={2}, 
- pages={6:1--6:30}, 
+ volume={7},
+ number={2},
+ pages={6:1--6:30},
  year={2014}
 }
 ```
@@ -61,16 +61,16 @@ If you have questions, or want to keep up-to-date with VTR, consider joining our
 [VTR-Commits](https://groups.google.com/forum/#!forum/vtr-commits): VTR revision control commits
 
 # Development
-This is the development trunk for the Verilog-to-Routing project. 
-Unlike the nicely packaged releases that we create, you are working with code in a constant state of flux. 
+This is the development trunk for the Verilog-to-Routing project.
+Unlike the nicely packaged releases that we create, you are working with code in a constant state of flux.
 You should expect that the tools are not always stable and that more work is needed to get the flow to run.
 
-For new developers, please [do the tutorial](dev/tutorial/NewDeveloperTutorial.txt). 
+For new developers, please [do the tutorial](dev/tutorial/NewDeveloperTutorial.txt).
 You will be directed back here once you ramp up.
 
-VTR development follows a classic centralized repository (svn-like) workflow. 
-The 'master' branch is supposed to be the most current stable version of the project. 
-Developers checkout a local copy of the code at the start of development, then do regular updates (e.g. `git pull --rebase`) to keep in sync with the GitHub master. 
+VTR development follows a classic centralized repository (svn-like) workflow.
+The 'master' branch is supposed to be the most current stable version of the project.
+Developers checkout a local copy of the code at the start of development, then do regular updates (e.g. `git pull --rebase`) to keep in sync with the GitHub master.
 When a developer has a tested, working change to put back into the trunk, he/she performs a `git push` operation.
 Unstable code should remain in the developer's local copy.