Merge pull request #3258 from verilog-to-routing/doc_typos

Minor typo fixes and clarifications to the documentation

Author: vaughnbetz

doc/src/.DS_Store

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

doc/src/abc/index.rst

@@ -239,10 +239,12 @@
           <T_clock_to_Q max="7.732e-11" port="ff.Q" clock="clk"/>
         </pb_type>
         <interconnect>
-          <!-- Two ff, make ff available to only corresponding luts -->
+          <!-- Connect BLE input to LUT input and LUT output to FF in -->
           <direct name="direct1" input="ble.in" output="soft_logic.in"/>
           <direct name="direct2" input="soft_logic.out" output="ff.D"/>
+          <!-- Connect BLE clock to FF clock -->
           <direct name="direct4" input="ble.clk" output="ff.clk"/>
+          <!-- Connect the output of a MUX selecting between LUT output and FF output to the BLE output -->
           <mux name="mux1" input="ff.Q soft_logic.out" output="ble.out"/>
         </interconnect>
       </pb_type>

doc/src/arch/example_arch.xml

@@ -33,10 +33,6 @@ Available parameters
 
     To enable mixing hard block and soft logic implementation of adders
 
-.. option:: -vtr_prim
-
-    No additional passes will be executed.
-
 .. option:: -vtr_prim
 
     loads vtr primitives as modules, if the design uses vtr primitives then this flag is mandatory for first run

doc/src/arch/reference.rst

@@ -877,8 +877,6 @@ If any of init_t, exit_t or alpha_t is specified, the user schedule, with a fixe
 
     This place location file is in the same format as a :ref:`.place file <vpr_place_file>`, but does not require the first two lines which are normally at the top     of a placement file that specify the netlist file, netlist ID, and array size.
 
-    **Default:** ````.
-
 .. option:: --place_algorithm {bounding_box | criticality_timing | slack_timing}
 
     Controls the algorithm used by the placer.
@@ -1055,7 +1053,7 @@ The following options are only valid when the placement engine is in timing-driv
     Controls how critical a connection is considered as a function of its slack, at the start of the anneal.
 
     If this value is 0, all connections are considered equally critical.
-    If this value is large, connections with small slacks are considered much more critical than connections with small slacks.
+    If this value is large, connections with small slacks are considered much more critical than connections with large slacks.
     As the anneal progresses, the exponent used in the criticality computation gradually changes from its starting value of td_place_exp_first to its final value of :option:`--td_place_exp_last`.
 
     **Default:** ``1.0``
@@ -1072,7 +1070,7 @@ The following options are only valid when the placement engine is in timing-driv
 
     Controls how the timing-driven placer estimates delays.
 
-     * ``simple`` The placement delay estimator is built from the router lookahead. This takes less CPU time to build and it and still as accurate as the ``delta` model.
+     * ``simple`` The placement delay estimator is built from the router lookahead. This takes less CPU time to build and it is still as accurate as the ``delta`` model.
      * ``delta`` The router is used to profile delay from various locations in the grid for various differences in position.
      * ``delta_override`` Like ``delta`` but also includes special overrides to ensure effects of direct connects between blocks are accounted for.
        This is potentially more accurate but is more complex and depending on the architecture (e.g. number of direct connects) may increase place run-time.
@@ -1108,7 +1106,7 @@ The following options are only valid when the placement engine is in timing-driv
 
     Specifies the scaling factor for 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 1.1 corresponds to requesting 10%% setup margin.
+    For example a value of 1.1 corresponds to requesting 10% setup margin.
 
     **Default:** ``1.0``
 
@@ -1142,7 +1140,7 @@ The following options are only used when FPGA device and netlist contain a NoC r
 
     XML file containing the list of traffic flows within the NoC (communication between routers).
 
-    .. note:: noc_flows_file are required to specify if NoC optimization is turned on (--noc on).
+    .. note:: It is required to specify a ``noc_flows_file`` if NoC optimization is turned on (``--noc on``).
 
 .. option:: --noc_routing_algorithm {xy_routing | bfs_routing | west_first_routing | north_last_routing | negative_first_routing | odd_even_routing}
 
@@ -1872,14 +1870,14 @@ The following options are only valid when the router is in timing-driven mode (t
 
     **Default:** ``off``
 
-.. option:: --congested_routing_iteration_threshold CONGESTED_ROUTING_ITERATION_THRESHOLD
+.. option:: --congested_routing_iteration_threshold <float>
 
     Controls when the router enters a high effort mode to resolve lingering routing congestion.
     Value is the fraction of max_router_iterations beyond which the routing is deemed congested.
 
     **Default:** ``1.0`` (never)
 
-.. option:: --route_bb_update {static, dynamic}
+.. option:: --route_bb_update {static | dynamic}
 
     Controls how the router's net bounding boxes are updated:
 
@@ -1888,14 +1886,14 @@ The following options are only valid when the router is in timing-driven mode (t
 
      **Default:** ``dynamic``
 
-.. option:: --router_high_fanout_threshold ROUTER_HIGH_FANOUT_THRESHOLD
+.. option:: --router_high_fanout_threshold <int>
 
     Specifies the net fanout beyond which a net is considered high fanout.
     Values less than zero disable special behaviour for high fanout nets.
 
     **Default:** ``64``
 
-.. option:: --router_lookahead {classic, map}
+.. option:: --router_lookahead {classic | map | compressed_map | extended_map | simple}
 
     Controls what lookahead the router uses to calculate cost of completing a connection.
 
@@ -1980,7 +1978,7 @@ The following options are only valid when the router is in timing-driven mode (t
 
     **Default:** ``-2``
 
-.. option:: --router_debug_sink_rr ROUTER_DEBUG_SINK_RR
+.. option:: --router_debug_sink_rr <int>
 
     .. note:: This option is likely only of interest to developers debugging the routing algorithm
 
@@ -2290,7 +2288,7 @@ Analysis Options
 
             It is possible that by opening a switch between (1,2) to (1,1), CHANY:2113 actually only extends from (1,3) to (1,2).
 
-            1. The preceding channel's ending coordinates have no relation to the following channel's starting coordinates.
+            2. The preceding channel's ending coordinates have no relation to the following channel's starting coordinates.
                There is no logical contradiction, but for clarification, it is best to see an explanation of the VPR coordinate system.
                The path can also be visualized by VPR graphics, as an illustration of this point:
 
@@ -2302,17 +2300,17 @@ Analysis Options
 
             :numref:`fig_path_2` shows the routing resources used in Path #2 and their locations on the FPGA.
 
-            1. The signal emerges from near the top-right corner of the block to_FFC (OPIN:1479)  and joins the topmost horizontal segment of length 1 (CHANX:2073).
+            3. The signal emerges from near the top-right corner of the block to_FFC (OPIN:1479)  and joins the topmost horizontal segment of length 1 (CHANX:2073).
 
-            2. The signal proceeds to the left, then connects to the outermost, blue vertical segment of length 0 (CHANY:2139).
+            4. The signal proceeds to the left, then connects to the outermost, blue vertical segment of length 0 (CHANY:2139).
 
-            3. The signal continues downward and attaches to the horizontal segment of length 1 (CHANX:2040).
+            5. The signal continues downward and attaches to the horizontal segment of length 1 (CHANX:2040).
 
-            4. Of the aforementioned horizontal segment, after travelling one linear unit to the right, the signal jumps on a vertical segment of length 0 (CHANY:2166).
+            6. Of the aforementioned horizontal segment, after travelling one linear unit to the right, the signal jumps on a vertical segment of length 0 (CHANY:2166).
 
-            5. The signal travels upward and promptly connects to a horizontal segment of length 0 (CHANX:2076).
+            7. The signal travels upward and promptly connects to a horizontal segment of length 0 (CHANX:2076).
 
-            6. This segment connects to the green destination io (3,4).
+            8. This segment connects to the green destination io (3,4).
 
         * ``debug``: Like ``detailed``, but includes additional VPR internal debug information such as timing graph node IDs (``tnode``) and routing SOURCE/SINK nodes.
 

doc/src/parmys/parmys_plugin.rst

@@ -11,7 +11,8 @@ To access detailed echo files from VPR’s operation, use the command-line optio
 After parsing the netlist and architecture files, VPR dumps out an image of its internal data structures into echo files (typically ending in ``.echo``).
 These files can be examined to be sure that VPR is parsing the input files as you expect.
 
-You ca visualize and control the placement move generator whenever the placement engine is paused in the UI. Run with graphics and VTR_ENABLE_DEBUG_LOGGONG enabled and set a breakpoint to stop placement. The new location of the moving block for each proposed move will be highlighted with GREEN and the old location will be highlighted with GOLD. The fanin and fanout blocks will also be highlighted. The move type, move outcome and delta cost will be printed in the status bar.
+You can visualize and control the placement move generator whenever the placement engine is paused in the UI. Run with graphics and VTR_ENABLE_DEBUG_LOGGING enabled and set a breakpoint to stop placement. The new location of the moving block for each proposed move will be highlighted with GREEN and the old location will be highlighted with GOLD. The fanin and fanout blocks will also be highlighted. The move type, move outcome and delta cost will be printed in the status bar.
+
 .. warning:: VPR must have been compiled with `VTR_ENABLE_DEBUG_LOGGING` on to get any debug output from this flag.   
 
 If the preprocessor flag ``DEBUG`` is defined in ``vpr_types.h``, some additional sanity checks are performed during a run.

doc/src/vpr/command_line_usage.rst

@@ -304,7 +304,7 @@ Consider the following:
 
     .latch g h re clk 0
 
-The ``.names``' pin names are:
+The ``.names`` pin names are:
 
 - ``f.in[0]`` (driven by net ``a``)
 - ``f.in[1]`` (driven by net ``b``)
@@ -1074,7 +1074,7 @@ An example of what a generated routing resource graph file would look like is sh
             <y_list index="2" info="5"/>
         </channels>
         <switches>
-            <switch id="0" name="my_switch" buffered="1">
+            <switch id="0" name="my_switch" type="mux">
                 <timing R="100" Cin="1233-12" Cout="123e-12" Tdel="1e-9"/>
                 <sizing mux_trans_size="2.32" buf_size="23.54"/>
             </switch>
@@ -1086,24 +1086,24 @@ An example of what a generated routing resource graph file would look like is sh
         </segments>
         <block_types>
             <block_type id="0" name="io" width="1" height="1">
-                <pin_class type="input">
+                <pin_class type="INPUT">
                     <pin ptc="0">DATIN[0]</pin>
                     <pin ptc="1">DATIN[1]</pin>
                     <pin ptc="2">DATIN[2]</pin>
                     <pin ptc="3">DATIN[3]</pin>
                 </pin_class>
-                <pin_class type="output">
+                <pin_class type="OUTPUT">
                     <pin ptc="4">DATOUT[0]</pin>
                     <pin ptc="5">DATOUT[1]</pin>
                     <pin ptc="6">DATOUT[2]</pin>
                     <pin ptc="7">DATOUT[3]</pin>
                 </pin_class>
             </block_type>
             <block_type id="1" name="buf" width="1" height="1">
-                <pin_class type="input">
+                <pin_class type="INPUT">
                     <pin ptc="0">IN</pin>
                 </pin_class>
-                <pin_class type="output">
+                <pin_class type="OUTPUT">
                     <pin ptc="1">OUT</pin>
                 </pin_class>
             </block_type>
@@ -1190,7 +1190,7 @@ Single Flow
 A given traffic flow information is contained within the ``single_flow`` tag. There can be 0 or more single flow tags.
 0 would indicate that an application does not have any traffic flows.
 
-.. rrgraph:tag:: <channel src="logical_router_name" dst="logical_router_name" bandwidth="float" latency_cons="float" priority="int"/>
+.. rrgraph:tag:: <single_flow src="logical_router_name" dst="logical_router_name" bandwidth="float" latency_cons="float" priority="int"/>
 
     :opt_param latency_cons:
         A floating point number which indicates the upper bound
@@ -1206,28 +1206,28 @@ A given traffic flow information is contained within the ``single_flow`` tag. Th
 
     :req_param src:
         A string which represents a logical router name in an application.
-        This logical router is the source endpoint for the traffic flow being described by the cor-
-        responding single flow tag. The logical router name must match the name of the router
+        This logical router is the source endpoint for the traffic flow being described by the corresponding 
+        single flow tag. The logical router name must match the name of the router
         as found in the clustered netlist; since this name assigned by the CAD tool, instead of
         having the designer go through the clustered netlist to retrieve the exact name we instead
         allow designers to use regex patters in the logical router name. For example, instead of
-        ”noc_router_adapter_block:noc_router_layer1_mvm2:slave_tready_reg0” user could pro-
-        vide ”.*noc_router_layer1_mvm2.*”. This allows users to provide the instance name for a given logical router
+        ``noc_router_adapter_block:noc_router_layer1_mvm2:slave_tready_reg0`` user could provide 
+        ``.*noc_router_layer1_mvm2.*``. This allows users to provide the instance name for a given logical router
         module in the design. This is a required attribute.
 
     :req_param dst:
         A string which represents a logical router name in an application.
-        This logical router is the deastination endpoint for the traffic flow being described by the cor-
-        responding single flow tag. The logical router name must match the name of the router
+        This logical router is the deastination endpoint for the traffic flow being described by the corresponding 
+        single flow tag. The logical router name must match the name of the router
         as found in the clustered netlist; since this name assigned by the CAD tool, instead of
         having the designer go through the clustered netlist to retrieve the exact name we instead
         allow designers to use regex patters in the logical router name. For example, instead of
-        ”noc_router_adapter_block:noc_router_layer1_mvm3:slave_tready_reg0” user could pro-
-        vide ”.*noc_router_layer1_mvm3.*”. This allows users to provide the instance name for a given logical router
+        ``noc_router_adapter_block:noc_router_layer1_mvm3:slave_tready_reg0`` user could provide 
+        ``.*noc_router_layer1_mvm3.*``. This allows users to provide the instance name for a given logical router
         module in the design. This is a required attribute.
 
     :req_param bandwidth:
-        A floating point number which indicates the data size in the
+        A floating point number which indicates the data bandwidth in the
         traffic flow communication. This is in units of bits-per-second (bps) and is a required
         attribute.
 
@@ -1253,9 +1253,9 @@ Block types usage summary (.txt .xml or .json)
 Block types usage summary is a file written in human or machine readable format.
 It describes types and the amount of cluster-level FPGA resources that are used
 by implemented design. This file is generated after the placement step with
-option: `--write_block_usage <filename>`. It can be saved as a human readable
+option: ``--write_block_usage <filename>``. It can be saved as a human readable
 text file or in XML or JSON file to provide machine readable output. Format is
-selected based on the extension of the `<filename>`.
+selected based on the extension of the ``<filename>``.
 
 The summary consists of 4 parameters: