diff --git a/BUILDING.md b/BUILDING.md index 5b6d6b6eb4f..49d4be84627 100644 --- a/BUILDING.md +++ b/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 diff --git a/CHANGELOG.md b/CHANGELOG.md index d86dda1c83d..03179b3f84e 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,13 +1,13 @@ # VTR Change Log @@ -157,7 +157,7 @@ - + diff --git a/doc/src/arch/index.rst b/doc/src/arch/index.rst index ec59b26cac0..7bb724f4c63 100644 --- a/doc/src/arch/index.rst +++ b/doc/src/arch/index.rst @@ -6,7 +6,7 @@ FPGA Architecture Description VTR uses an XML-based architecture description language to describe the targeted FPGA architecture. This flexible description language allows the user to describe a large number of hypothetical and commercial-like FPGA architectures. -See the :ref:`arch_tutorial` for an introduction to the architecture description langauge. +See the :ref:`arch_tutorial` for an introduction to the architecture description language. For a detailed reference on the supported options see the :ref:`arch_reference`. .. toctree:: diff --git a/doc/src/arch/reference.rst b/doc/src/arch/reference.rst index 9ef24a8df97..956dc373f94 100644 --- a/doc/src/arch/reference.rst +++ b/doc/src/arch/reference.rst @@ -196,12 +196,12 @@ The layer tag is an optional tag to specify multi-die FPGAs. If not specified, a - + - + @@ -493,16 +493,16 @@ Grid Location Tags .. note:: ``endx`` and ``endy`` are included in the region - If ``repeatx`` is specified the region will be repeated wherever :math:`x = startx + k_1*repeatx`, is satisified for any positive integer :math:`k_1`. + If ``repeatx`` is specified the region will be repeated wherever :math:`x = startx + k_1*repeatx`, is satisfied for any positive integer :math:`k_1`. - If ``repeaty`` is specified the region will be repeated wherever :math:`y = starty + k_2*repeaty`, is satisified for any positive integer :math:`k_2`. + If ``repeaty`` is specified the region will be repeated wherever :math:`y = starty + k_2*repeaty`, is satisfied for any positive integer :math:`k_2`. Example: .. code-block:: xml - + .. figure:: region_single_fpga_grid.* @@ -513,7 +513,7 @@ Grid Location Tags .. code-block:: xml - @@ -650,7 +650,7 @@ The tags within the ```` tag are: Used for an area estimate of the amount of area taken by all the functional blocks. - .. note:: This value can be overriden for specific ```` s with the ``area`` attribute. + .. note:: This value can be overridden for specific ```` s with the ``area`` attribute. .. arch:tag:: @@ -750,7 +750,7 @@ The tags within the ```` tag specifies the switches used to connect Since multiplexers and tristate buffers are modeled as a parallel stream of pass transistors feeding into a buffer, we would expect an additional "internal capacitance" to arise when the - pass transistor is enabled and the signal must propogate to + pass transistor is enabled and the signal must propagate to the buffer. See diagram of one stream below:: Pass Transistor @@ -872,7 +872,7 @@ Physical Tiles -------------- The content within the ```` describes the physical tiles available in the FPGA. -Each tile type is specified with the ```` tag withing the ```` tag. +Each tile type is specified with the ```` tag within the ```` tag. Tile ~~~~ @@ -935,7 +935,7 @@ The following tags are common to all ```` tags: .. arch:tag:: Defines an input port. - Multple input ports are described using multiple ```` tags. + Multiple input ports are described using multiple ```` tags. :req_param name: Name of the input port. :req_param num_pins: Number of pins the input port has. @@ -951,7 +951,7 @@ The following tags are common to all ```` tags: Input pins can not be swapped by the router. (Generates a unique SINK rr-node for each block input port pin.) - * ``full``: All input pins are considered logically equivalent (e.g. due to logical equivalance or a full-crossbar within the cluster). + * ``full``: All input pins are considered logically equivalent (e.g. due to logical equivalence or a full-crossbar within the cluster). All input pins can be swapped without limitation by the router. (Generates a single SINK rr-node shared by all input port pins.) @@ -969,7 +969,7 @@ The following tags are common to all ```` tags: .. arch:tag:: Defines an output port. - Multple output ports are described using multiple ```` tags + Multiple output ports are described using multiple ```` tags :req_param name: Name of the output port. :req_param num_pins: Number of pins the output port has. @@ -1099,7 +1099,7 @@ The following tags are common to all ```` tags: .. arch:tag:: - Allows :math:`F_c` values to be overriden on a port or wire/segment type basis. + Allows :math:`F_c` values to be overridden on a port or wire/segment type basis. :req_param fc_type: Indicates how the override :math:`F_c` value should be interpreted. @@ -1441,7 +1441,7 @@ The following tags are common to all tags: .. arch:tag:: Defines an input port. - Multple input ports are described using multiple ```` tags. + Multiple input ports are described using multiple ```` tags. :req_param name: Name of the input port. :req_param num_pins: Number of pins the input port has. @@ -1459,7 +1459,7 @@ The following tags are common to all tags: Input pins can not be swapped by the router. (Generates a unique SINK rr-node for each block input port pin.) - * ``full``: All input pins are considered logically equivalent (e.g. due to logical equivalance or a full-crossbar within the cluster). + * ``full``: All input pins are considered logically equivalent (e.g. due to logical equivalence or a full-crossbar within the cluster). All input pins can be swapped without limitation by the router. (Generates a single SINK rr-node shared by all input port pins.) @@ -1477,7 +1477,7 @@ The following tags are common to all tags: .. arch:tag:: Defines an output port. - Multple output ports are described using multiple ```` tags + Multiple output ports are described using multiple ```` tags :req_param name: Name of the output port. :req_param num_pins: Number of pins the output port has. @@ -1508,7 +1508,7 @@ The following tags are common to all tags: .. arch:tag:: Describes a clock port. - Multple clock ports are described using multiple ```` tags. + Multiple clock ports are described using multiple ```` tags. *See above descriptions on inputs* .. arch:tag:: @@ -1967,7 +1967,7 @@ The ```` tag and its contents are described below. be an approximate value. :req_param connections: - Specifies a list of numbers seperated by spaces which are the user IDs supplied to other + Specifies a list of numbers separated by spaces which are the user IDs supplied to other ```` tags. This describes how the current physical Noc router that this tag is identifying is connected to the other physical NoC routers on the device. @@ -2140,7 +2140,7 @@ Both methods should not be used in tandem. .. _clock_power_format: -Specifing Clocking Purely for Power Estimation +Specifying Clocking Purely for Power Estimation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The clocking configuration is specified with ```` tags within the ```` section. @@ -2157,7 +2157,7 @@ The clocking configuration is specified with ```` tags within the ```` contains three sub-elements that collectively describe the clock architecture: the wiring parameters ````, the clock distribution ````, and the clock connectivity ````. @@ -2230,7 +2230,7 @@ Clock Architecture Tags ^^^^^^^^^^^^^^^^^^^^^^^ The ```` element describes the per unit length electrical parameters, resistance (``Rmetal``) and capacitance (``Cmetel``), used to implement the clock distribution wires. -Wires are modeled soley based on ``Rmetal`` and ``Cmetal`` parameters which are derived from the physical implementation of the metal layer width and spacing. +Wires are modeled solely based on ``Rmetal`` and ``Cmetal`` parameters which are derived from the physical implementation of the metal layer width and spacing. There can be one or more wiring implementation options (metal layer, width and spacing) that are used by the later clock network specification and each is described in a separate ```` sub-element. The syntax of the wiring electrical information is: @@ -2250,8 +2250,8 @@ The high-level start tag for a clock network is as follows: :req_param num_inst: which describes the number of parallel instances of the clock distribution types described in the ```` sub-elements. .. note:: - Many paramters used in the following clock architecture tags take an espression (``expr``) as an argument simular to :ref:`grid_expressions`. - However, only a subset of special variables are suported: ``W`` (device width) and ``H`` (device height). + Many parameters used in the following clock architecture tags take an espression (``expr``) as an argument similar to :ref:`grid_expressions`. + However, only a subset of special variables are supported: ``W`` (device width) and ``H`` (device height). The supported clock distribution types are ```` and ````. *Spines* are used to describe vertical clock distribution wires. @@ -2292,10 +2292,10 @@ The high-level start tag for a clock network is as follows: * ``tap`` -- Tap points are where it can drive a routing switch or buffer to send a signal to a different ``clock_network`` or logicblock. :opt_param xoffset: (Only for ``rib`` network) Offset from the ``startx`` of a rib network. :opt_param yoffset: (Only for ``spine`` network) Offset from the ``starty`` of a spine network. - :opt_param xinc: (Only for rib ``tap`` points) Descibes the repeat factor of a series of evenly spaced tap points. - :opt_param yinc: (Only for spine ``tap`` points) Descibes the repeat factor of a series of evenly spaced tap points. + :opt_param xinc: (Only for rib ``tap`` points) Describes the repeat factor of a series of evenly spaced tap points. + :opt_param yinc: (Only for spine ``tap`` points) Describes the repeat factor of a series of evenly spaced tap points. :req_param buffer: - (Required only for ``drive`` points) A reference to a pre-defined routing switch; specfied by ```` tag, see Section :ref:`arch_switches`. + (Required only for ``drive`` points) A reference to a pre-defined routing switch; specified by ```` tag, see Section :ref:`arch_switches`. This switch will be used at the drive point. The clock architecture generator uses two of these buffers to drive the two portions of this ``clock_network`` wire when it is split at the drive point, see Figures :numref:`rib_visual` and :numref:`spine_visual`. @@ -2337,7 +2337,7 @@ The tap element and its attribute sare as follows: .. note:: - ``locationx`` and ``locationy`` describe an (x,y) grid loction where all the wires passing this location source the source the clock network connection depending on the ``fc_val`` + ``locationx`` and ``locationy`` describe an (x,y) grid location where all the wires passing this location source the source the clock network connection depending on the ``fc_val`` For more information you may wish to consult :cite:`mustafa_masc` which introduces the clock modeling language. @@ -2680,7 +2680,7 @@ The full format is documented below. :opt_param to_order: Specifies the order in which ``to_switchpoint``s are selected when creating edges. - .. note:: See ``from_switchpoint_order`` for value descritpions. + .. note:: See ``from_switchpoint_order`` for value descriptions. :opt_param switch_override: @@ -2742,7 +2742,7 @@ Scatter-Gather Patterns The content under the ```` tag consists of one or more ```` tags that are used to specify a scatter-gather pattern. Scatter-gather patterns can be used to specify multi-level switch patterns, rather than the direct wire-to-wire switch patterns of conventional switch blocks. -These additional switches, wires and/or muxes will be added to the architecture, augmenting wires created using segment specifications and swiches created using switch box specifications. +These additional switches, wires and/or muxes will be added to the architecture, augmenting wires created using segment specifications and switches created using switch box specifications. The number of any additional wires or muxes created by scatter-gather specifications will not vary with routing channel width. .. figure:: scatter_gather_images/scattergather_diagram.svg diff --git a/doc/src/dev/tutorials/timing_graph_debug/index.rst b/doc/src/dev/tutorials/timing_graph_debug/index.rst index 0732564c19c..999260e8645 100644 --- a/doc/src/dev/tutorials/timing_graph_debug/index.rst +++ b/doc/src/dev/tutorials/timing_graph_debug/index.rst @@ -67,7 +67,7 @@ where the first line of each entry is the type of timing information (e.g. data the second line indicates the related launching and capture clocks (with ``*`` acting as a wildcard) and the relevant timing graph node which originated the value, and the third line is the actual time value (in seconds). -The edges in the timing graph are also annoated with their Edge IDs and delays. +The edges in the timing graph are also annotated with their Edge IDs and delays. Special edges related to setup/hold (``tsu``, ``thld``) and clock-to-q delays (``tcq``) of sequential elements (e.g. Flip-Flops) are also labeled and drawn with different colors. diff --git a/doc/src/glossary.rst b/doc/src/glossary.rst index fb263200be9..f4605389335 100644 --- a/doc/src/glossary.rst +++ b/doc/src/glossary.rst @@ -9,7 +9,7 @@ Glossary For instance, if you extracted/cloned the VTR source into ``/home/myusername/vtr``, your ``$VTR_ROOT`` would be ``/home/myusername/vtr``. MWTA - Minimum Width Transitor Area (MWTA) is a simple process technology independent unit for measuring circuit area. + Minimum Width Transistor Area (MWTA) is a simple process technology independent unit for measuring circuit area. It corresponds to the size the smallest (minimum width) transistor area. For example, a 1x (unit-sized) CMOS inverter consists of two minimum width transistors (a PMOS pull-up, and NMOS pull-down). diff --git a/doc/src/odin/dev_guide/contributing.md b/doc/src/odin/dev_guide/contributing.md index 9fd5632e352..63a887fdc0e 100644 --- a/doc/src/odin/dev_guide/contributing.md +++ b/doc/src/odin/dev_guide/contributing.md @@ -31,7 +31,7 @@ Continue to work on the branch, pushing the commits regularly. Like a PR, test cases must be included through the use of benchmarks. See [regression tests](regression_test.md) for further instruction. -### Formating +### Formatting Odin II shares the same contributing philosophy as [VPR](https://docs.verilogtorouting.org/en/latest/dev/contributing/contributing/). Most importantly PRs will be rejected if they do not respect the coding standard: see [VPRs coding standard](https://docs.verilogtorouting.org/en/latest/dev/developing/#code-formatting) diff --git a/doc/src/odin/dev_guide/regression_test.md b/doc/src/odin/dev_guide/regression_test.md index f3e2d22ab8b..e46d0e8d8b2 100644 --- a/doc/src/odin/dev_guide/regression_test.md +++ b/doc/src/odin/dev_guide/regression_test.md @@ -139,7 +139,7 @@ The following key = value are available for configuration files: |script_simulation_params |[see exec_wrapper.sh options] | |synthesis_params |[see Odin options] | |simulation_params |[see Odin options] | -|regression_params |[see Regression Parameters bellow] +|regression_params |[see Regression Parameters below] Regression Parameters: @@ -158,7 +158,7 @@ The following diagram illustrates the structure of regression tests. Each regression test needs a corresponding folder in the task directory containing the configuration file. The \ should have the same name as the verilog file group in the verilog directory. This folder is where the synthesis results and simulation results will be stored. -The task diplay name and the verilog file group should share the same title. +The task display name and the verilog file group should share the same title. ```bash └── odin_ii @@ -319,7 +319,7 @@ This regression test targets the function of keywords. It has a folder or child ### preprocessor -This set of regression test includes benchmarks targetting compiler directives available in Verilog. +This set of regression test includes benchmarks targeting compiler directives available in Verilog. ### Regression Tests Directory Tree diff --git a/doc/src/odin/user_guide.md b/doc/src/odin/user_guide.md index 7697eba77d9..c39ce25ad2f 100644 --- a/doc/src/odin/user_guide.md +++ b/doc/src/odin/user_guide.md @@ -21,7 +21,7 @@ - `-g ` - `-t ` -Simulation always produces the folowing files: +Simulation always produces the following files: - input\_vectors - output\_vectors @@ -34,11 +34,11 @@ Simulation always produces the folowing files: | `-T` | output vector file|The output vectors is verified against the supplied predefined output vector file | | `-E` | |Output after both edges of the clock. (Default is to output only after the falling edge.) | | `-R` | |Output after rising edge of the clock only. (Default is to output only after the falling edge.)| -| `-p` |comma seperated list|Comma-separated list of additional pins/nodes to monitor during simulation. (view NOTES) | +| `-p` |comma separated list|Comma-separated list of additional pins/nodes to monitor during simulation. (view NOTES) | | `-U0` | |initial register value to 0 | | `-U1` | |initial resigster value to 1 | | `-UX` | |initial resigster value to X (unknown) (DEFAULT) | -| `-L` | Comma seperated list|Comma-separated list of primary inputs to hold high at cycle 0, and low for all subsequent cycles.| +| `-L` | Comma separated list|Comma-separated list of primary inputs to hold high at cycle 0, and low for all subsequent cycles.| | `-3` | |Generate three valued logic. (Default is binary.) | ## Examples @@ -161,7 +161,7 @@ To do this the command line should be: ./odin_ii -v -t -T ``` -An error will arrise if the output vector files do not match. +An error will arise if the output vector files do not match. Without an expected vector output file the command line would be: diff --git a/doc/src/quickstart/index.rst b/doc/src/quickstart/index.rst index f69eb39b077..1e81d3de6d1 100644 --- a/doc/src/quickstart/index.rst +++ b/doc/src/quickstart/index.rst @@ -238,10 +238,10 @@ This will produce a large amount of output as VPR implements the circuit, but yo Geometric mean non-virtual intra-domain period: 6.22409 ns (160.666 MHz) Fanout-weighted geomean non-virtual intra-domain period: 6.22409 ns (160.666 MHz) - VPR suceeded + VPR succeeded The entire flow of VPR took 3.37 seconds (max_rss 40.7 MiB) -which shows that VPR as successful (``VPR suceeded``), along with how long VPR took to run (~3 seconds in this case). +which shows that VPR as successful (``VPR succeeded``), along with how long VPR took to run (~3 seconds in this case). You will also see various result files generated by VPR which define the circuit implementation: diff --git a/doc/src/tutorials/arch/classic_soft_logic.rst b/doc/src/tutorials/arch/classic_soft_logic.rst index 602cb9002a3..be2696bc7be 100644 --- a/doc/src/tutorials/arch/classic_soft_logic.rst +++ b/doc/src/tutorials/arch/classic_soft_logic.rst @@ -1,7 +1,7 @@ Classic Soft Logic Block Tutorial --------------------------------- -The following is an example on how to use the VPR architecture description langauge to describe a classical academic soft logic block. +The following is an example on how to use the VPR architecture description language to describe a classical academic soft logic block. First we provide a step-by-step explanation on how to construct the logic block. Afterwards, we present the complete code for the logic block. diff --git a/doc/src/tutorials/arch/configurable_memory_bus.rst b/doc/src/tutorials/arch/configurable_memory_bus.rst index 160c6c27779..83dd823fd99 100644 --- a/doc/src/tutorials/arch/configurable_memory_bus.rst +++ b/doc/src/tutorials/arch/configurable_memory_bus.rst @@ -13,7 +13,7 @@ Configurable memories are found in today's commercial FPGAs for two primary reas #. Implementing memories in soft logic (LUTs and flip-flops) is very costly in terms of area. Thus it is important for modern FPGA architects be able to describe the specific properties of the configurable memory that they want to investigate. -The following is an example on how to use the langauge to describe a configurable memory block. +The following is an example on how to use the language to describe a configurable memory block. First we provide a step-by-step explanation on how to construct the memory block. Afterwards, we present the complete code for the memory block. diff --git a/doc/src/tutorials/arch/fracturable_multiplier_bus.rst b/doc/src/tutorials/arch/fracturable_multiplier_bus.rst index 9c8a850e3a7..7238cd6de22 100644 --- a/doc/src/tutorials/arch/fracturable_multiplier_bus.rst +++ b/doc/src/tutorials/arch/fracturable_multiplier_bus.rst @@ -13,7 +13,7 @@ Configurable multipliers are found in today's commercial FPGAs for two primary r #. Implementing multipliers in soft logic is very area expensive. Thus it is important for modern FPGA architects be able to describe the specific properties of the configurable multiplier that they want to investigate. -The following is an example on how to use the VPR architecture description langauge to describe a common type of configurable multiplier called a fracturable multiplier shown in :numref:`fig_fracturable_multiplier`. +The following is an example on how to use the VPR architecture description language to describe a common type of configurable multiplier called a fracturable multiplier shown in :numref:`fig_fracturable_multiplier`. We first give a step-by-step description on how to construct the multiplier block followed by a complete example. .. _fig_fracturable_multiplier: @@ -22,8 +22,8 @@ We first give a step-by-step description on how to construct the multiplier bloc Model of a fracturable multiplier block -The large ``block_mult`` can implement one 36x36 multiplier cluster called a ``mult_36x36_slice`` or it can implement two divisble 18x18 multipliers. -A divisible 18x18 multiplier can implement a 18x18 multiplier cluster called a ``mult_18x18_slice`` or it can be fractured into two 9x9 mulitplier clusters called ``mult_9x9_slice``. +The large ``block_mult`` can implement one 36x36 multiplier cluster called a ``mult_36x36_slice`` or it can implement two divisible 18x18 multipliers. +A divisible 18x18 multiplier can implement a 18x18 multiplier cluster called a ``mult_18x18_slice`` or it can be fractured into two 9x9 multiplier clusters called ``mult_9x9_slice``. :numref:`fig_fracturable_multiplier_slice` shows a multiplier slice. Pins belonging to the same input or output port of a multiplier slice must be either all registered or none registered. Pins belonging to different ports or different slices may have different register configurations. @@ -132,7 +132,7 @@ After the mode containing the 36x36 multiplier slice is described, the mode cont -This mode has two additional modes which are the actual 18x18 multiply block or two 9x9 mulitplier blocks. +This mode has two additional modes which are the actual 18x18 multiply block or two 9x9 multiplier blocks. Both follow a similar description as the ``mult_36x36_slice`` with just the number of pins halved so the details are not repeated. .. code-block:: xml @@ -185,7 +185,7 @@ Fracturable Multiplier Bus-Based Complete Example .. code-block:: xml - diff --git a/doc/src/tutorials/arch/multi_mode_ble.rst b/doc/src/tutorials/arch/multi_mode_ble.rst index 2139226d3c4..0dd9855dd06 100644 --- a/doc/src/tutorials/arch/multi_mode_ble.rst +++ b/doc/src/tutorials/arch/multi_mode_ble.rst @@ -11,7 +11,7 @@ Definition Modern FPGA logic blocks are designed to operate in various modes, so as to provide best performance for different applications. VPR offers enriched syntax to support highly flexible multi-mode logic block architecture. -:numref:`fig_frac_lut_le` shows the physical implemenation of a Fracturable Logic Element (FLE), which consists of a fracturable 6-input Look-Up Table (LUT), two Flip-flops (FFs) and routing multiplexers to select between combinational and sequential outputs. +:numref:`fig_frac_lut_le` shows the physical implementation of a Fracturable Logic Element (FLE), which consists of a fracturable 6-input Look-Up Table (LUT), two Flip-flops (FFs) and routing multiplexers to select between combinational and sequential outputs. .. _fig_frac_lut_le: diff --git a/doc/src/tutorials/arch/timing_modeling/index.rst b/doc/src/tutorials/arch/timing_modeling/index.rst index dbf9ee3d927..e8aa95e7c4d 100644 --- a/doc/src/tutorials/arch/timing_modeling/index.rst +++ b/doc/src/tutorials/arch/timing_modeling/index.rst @@ -12,7 +12,7 @@ This involves two key steps: #. Specifying the physical delay values -These two steps separate the logical timing characteristics of a primitive, from the physically dependant delays. +These two steps separate the logical timing characteristics of a primitive, from the physically dependent delays. This enables a single logical netlist primitive type (e.g. Flip-Flop) to be mapped into different physical locations with different timing characteristics. The :ref:`FPGA architecture description ` describes the logical timing characteristics in the :ref:`models section `, while the physical timing information is specified on ``pb_types`` within :ref:`complex block `. @@ -31,7 +31,7 @@ A typical combinational block is a full adder, where ``a``, ``b`` and ``cin`` are combinational inputs, and ``sum`` and ``cout`` are combinational outputs. -We can model these timing dependencies on the model with the ``combinational_sink_ports``, which specifies the output ports which are dependant on an input port: +We can model these timing dependencies on the model with the ``combinational_sink_ports``, which specifies the output ports which are dependent on an input port: .. code-block:: xml @@ -86,7 +86,7 @@ DFFs have no internal timing paths between their input and output ports. DFF Sequential model ports are specified by providing the ``clock=""`` attribute, where ```` is the name of the associated clock ports. -The assoicated clock port must have ``is_clock="1"`` specified to indicate it is a clock. +The associated clock port must have ``is_clock="1"`` specified to indicate it is a clock. .. code-block:: xml @@ -455,8 +455,8 @@ It is also possible to specify in SDC that there is a phase shift between the tw Clock Buffers & Muxes ~~~~~~~~~~~~~~~~~~~~~ -Some architectures contain special primitives for buffering or controling clocks. -VTR supports modelling these using the ``is_clock`` attritube on the model to differentiate between 'data' and 'clock' signals, allowing users to control how clocks are traced through these primitives. +Some architectures contain special primitives for buffering or controlling clocks. +VTR supports modelling these using the ``is_clock`` attribute on the model to differentiate between 'data' and 'clock' signals, allowing users to control how clocks are traced through these primitives. When VPR traces through the netlist it will propagate clocks from clock inputs to the downstream combinationally connected pins. @@ -562,7 +562,7 @@ For the clock mux example above, if the user specified the following :ref:`SDC t VPR would propagate both ``clka`` and ``clkb`` through the clock mux. Therefore the logic connected to ``clk_downstream`` would be analyzed for both the ``clka`` and ``clkb`` constraints. -Most likely (unless ``clka`` and ``clkb`` are used elswhere) the user should additionally specify: +Most likely (unless ``clka`` and ``clkb`` are used elsewhere) the user should additionally specify: .. code-block:: tcl diff --git a/doc/src/tutorials/timing_analysis/index.rst b/doc/src/tutorials/timing_analysis/index.rst index 20c6e2aef67..92356118cbb 100644 --- a/doc/src/tutorials/timing_analysis/index.rst +++ b/doc/src/tutorials/timing_analysis/index.rst @@ -35,7 +35,7 @@ Generating the Post-Implementation Netlist for STA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For this tutorial, we will be using the ``clma`` :ref:`benchmark ` -targetting the ``k6_frac_N10_frac_chain_mem32K_40nm.xml`` architecture. +targeting the ``k6_frac_N10_frac_chain_mem32K_40nm.xml`` architecture. We will first create a working directory to hold all the timing analysis files: @@ -112,7 +112,7 @@ First, install OpenSTA onto your system. Building from source is a good option, which can be done using the following instructions: https://github.com/parallaxsw/OpenSTA?tab=readme-ov-file#build-from-source -After OpenSTA is installed, we can perfrom static timing analysis on the post-implementation +After OpenSTA is installed, we can perform static timing analysis on the post-implementation netlist generated by VPR. It is easiest to write a ``sdf_delays.tcl`` file to setup and configure the timing analysis: diff --git a/doc/src/tutorials/timing_simulation/index.rst b/doc/src/tutorials/timing_simulation/index.rst index 6cc96f791c6..5a60ecaf07c 100644 --- a/doc/src/tutorials/timing_simulation/index.rst +++ b/doc/src/tutorials/timing_simulation/index.rst @@ -108,7 +108,7 @@ Different circuits may produce other types of netlist primitives corresponding t .. note:: The different primitives produced by VPR are defined in ``$VTR_ROOT/vtr_flow/primitives.v`` -Lets now take a look at the Standard Delay Fromat (SDF) file: +Lets now take a look at the Standard Delay Format (SDF) file: .. code-block:: none :linenos: diff --git a/doc/src/utils/fasm.rst b/doc/src/utils/fasm.rst index 4c14efeec6a..20b8b303ccf 100644 --- a/doc/src/utils/fasm.rst +++ b/doc/src/utils/fasm.rst @@ -234,7 +234,7 @@ can also be used with the ```` tag in the same way, example: If multiple FASM features are required for a mux, they can be specified using -comma's as a seperator. Example: +comma's as a separator. Example: .. code-block:: xml @@ -282,6 +282,6 @@ spelling of the metadata, and create tests that the mapping is working as expected. Also note that "genfasm" will not accept "x" (unknown/don't care) or "z" -(high impedence) values in parameters. Prior to emitting the eblif for place +(high impedance) values in parameters. Prior to emitting the eblif for place and route, ensure that all parameters that will be mapped to FASM have a valid "1" or "0". diff --git a/doc/src/vpr/basic_flow.rst b/doc/src/vpr/basic_flow.rst index 00cd3a96661..317ad08318b 100644 --- a/doc/src/vpr/basic_flow.rst +++ b/doc/src/vpr/basic_flow.rst @@ -3,7 +3,7 @@ Basic flow The Place and Route process in VPR consists of several steps: -- Packing (combinines primitives into complex blocks) +- Packing (combines primitives into complex blocks) - Placement (places complex blocks within the FPGA grid) - Routing (determines interconnections between blocks) - Analysis (analyzes the implementation) diff --git a/doc/src/vpr/command_line_usage.rst b/doc/src/vpr/command_line_usage.rst index 88c982993c8..57d5723e143 100644 --- a/doc/src/vpr/command_line_usage.rst +++ b/doc/src/vpr/command_line_usage.rst @@ -142,7 +142,7 @@ Graphics Options .. option:: --graphics_commands - A set of semi-colon seperated graphics commands. + A set of semi-colon separated graphics commands. Graphics commands must be surrounded by quotation marks (e.g. --graphics_commands "save_graphics place.png;") * save_graphics @@ -218,7 +218,7 @@ General Options Controls how many parallel workers VPR may use: * ``1`` implies VPR will execute serially, - * ``>1`` implies VPR may execute in parallel with up to the specified concurency + * ``>1`` implies VPR may execute in parallel with up to the specified concurrency * ``0`` implies VPR may execute with up to the maximum concurrency supported by the host machine If this option is not specified it may be set from the ``VPR_NUM_WORKERS`` environment variable; otherwise the default is used. @@ -251,8 +251,8 @@ General Options Checks that any intermediate files loaded (e.g. previous packing/placement/routing) are consistent with the current netlist/architecture. - If set to ``on`` will error if any files in the upstream dependancy have been modified. - If set to ``off`` will warn if any files in the upstream dependancy have been modified. + If set to ``on`` will error if any files in the upstream dependency have been modified. + If set to ``off`` will warn if any files in the upstream dependency have been modified. **Default:** ``on`` @@ -315,7 +315,7 @@ General Options Controls whether VPR enforces some consistency checks strictly (as errors) or treats them as warnings. - Usually these checks indicate an issue with either the targetted architecture, or consistency issues with VPR's internal data structures/algorithms (possibly harming optimization quality). + Usually these checks indicate an issue with either the targeted architecture, or consistency issues with VPR's internal data structures/algorithms (possibly harming optimization quality). In specific circumstances on specific architectures these checks may be too restrictive and can be turned off. .. warning:: Exercise extreme caution when turning this option off -- be sure you completely understand why the issue is being flagged, and why it is OK to treat as a warning instead of an error. @@ -472,7 +472,7 @@ Use the options below to override this default naming behaviour. The ``sub_tile`` is a clustered placement construct: which cluster-level location at a given (x, y, layer) should these atoms go at (relevant when multiple clusters can be stacked there). A sub-tile of -1 may be used when - the sub-tile of an atom is unkown (allowing the packing algorithm to choose + the sub-tile of an atom is unknown (allowing the packing algorithm to choose any sub-tile at the given (x, y, layer) location). .. warning:: @@ -512,7 +512,7 @@ By default VPR will remove buffer LUTs, and iteratively sweep the netlist to rem Usually buffer LUTS are introduced in BLIF circuits by upstream tools in order to rename signals (like ``assign`` statements in Verilog). Absorbing these buffers reduces the number of LUTs required to implement the circuit. - Ocassionally buffer LUTs are inserted for other purposes, and this option can be used to preserve them. + Occasionally buffer LUTs are inserted for other purposes, and this option can be used to preserve them. Disabling buffer absorption can also improve the matching between the input and post-synthesis netlist/SDF. **Default**: ``on`` @@ -574,7 +574,7 @@ By default VPR will remove buffer LUTs, and iteratively sweep the netlist to rem Packing Options ^^^^^^^^^^^^^^^ AAPack is the packing algorithm built into VPR. -AAPack takes as input a technology-mapped blif netlist consisting of LUTs, flip-flops, memories, mulitpliers, etc and outputs a .net formatted netlist composed of more complex logic blocks. +AAPack takes as input a technology-mapped blif netlist consisting of LUTs, flip-flops, memories, multipliers, etc and outputs a .net formatted netlist composed of more complex logic blocks. The logic blocks available on the FPGA are specified through the FPGA architecture file. For people not working on CAD, you can probably leave all the options to their default values. @@ -590,7 +590,7 @@ For people not working on CAD, you can probably leave all the options to their d Unrelated clustering can increase packing density (decreasing the number of blocks required to implement the circuit), but can significantly impact routability. - When set to ``auto`` VPR automatically decides whether to enable unrelated clustring based on the targetted device and achieved packing density. + When set to ``auto`` VPR automatically decides whether to enable unrelated clustring based on the targeted device and achieved packing density. **Default**: ``auto`` @@ -648,7 +648,7 @@ For people not working on CAD, you can probably leave all the options to their d Controls how the packer selects the block type to which a primitive will be mapped if it can potentially map to multiple block types. - * ``on`` : Try to balance block type utilization by picking the block type with the (currenty) lowest utilization. + * ``on`` : Try to balance block type utilization by picking the block type with the (currently) lowest utilization. * ``off`` : Do not try to balance block type utilization * ``auto``: Dynamically enabled/disabled (based on density) @@ -911,7 +911,7 @@ If any of init_t, exit_t or alpha_t is specified, the user schedule, with a fixe .. option:: --place_bounding_box_mode {auto_bb | cube_bb | per_layer_bb} Specifies the type of the wirelength estimator used during placement. For single layer architectures, cube_bb (a 3D bounding box) is always used (and is the same as per_layer_bb). - For 3D architectures, cube_bb is appropriate if you can cross between layers at switch blocks, while if you can only cross between layers at output pins per_layer_bb (one bouding box per layer) is more accurate and appropriate. + For 3D architectures, cube_bb is appropriate if you can cross between layers at switch blocks, while if you can only cross between layers at output pins per_layer_bb (one bounding box per layer) is more accurate and appropriate. ``auto_bb``: The bounding box type is determined automatically based on the cross-layer connections. @@ -1351,7 +1351,7 @@ Analytical Placement is generally split into three stages: thought of as the number of bits stored. This target density parameter lowers the mass capacity of tiles. - When this option is set ot auto, VPR will select good values for the + When this option is set to auto, VPR will select good values for the target density of tiles. reasonable values are between 0.0 and 1.0, with negative values not being allowed. @@ -1604,7 +1604,7 @@ VPR uses a negotiated congestion algorithm (based on Pathfinder) to perform rout The algorithm is robust to incorrect hints (i.e. it continues to binary search), so the hint does not need to be precise. - This option may ocassionally produce a different minimum channel width due to the different initialization. + This option may occasionally produce a different minimum channel width due to the different initialization. .. seealso:: :option:`--verify_binary_search` @@ -1612,7 +1612,7 @@ VPR uses a negotiated congestion algorithm (based on Pathfinder) to perform rout Force the router to check that the channel width determined by binary search is the minimum. - The binary search ocassionally may not find the minimum channel width (e.g. due to router sub-optimality, or routing pattern issues at a particular channel width). + The binary search occasionally may not find the minimum channel width (e.g. due to router sub-optimality, or routing pattern issues at a particular channel width). This option attempts to verify the minimum by routing at successively lower channel widths until two consecutive routing failures are observed. @@ -1634,7 +1634,7 @@ VPR uses a negotiated congestion algorithm (based on Pathfinder) to perform rout Incrementally re-route nets with fanout above the specified threshold. - This attempts to re-use the legal (i.e. non-congested) parts of the routing tree for high fanout nets, with the aim of reducing router execution time. + This attempts to reuse the legal (i.e. non-congested) parts of the routing tree for high fanout nets, with the aim of reducing router execution time. To disable, set value to a value higher than the largest fanout of any net. @@ -1724,7 +1724,7 @@ The following options are only valid when the router is in timing-driven mode (t Sets how aggressive the directed search used by the timing-driven router is. It is a subtractive adjustment to the lookahead heuristic. - Values between 0 and 1e-9 are resonable; higher values may increase quality at the expense of run-time. + Values between 0 and 1e-9 are reasonable; higher values may increase quality at the expense of run-time. **Default:** ``0.0`` @@ -1732,7 +1732,7 @@ The following options are only valid when the router is in timing-driven mode (t Controls the directedness of the timing-driven router's exploration when doing router delay profiling of an architecture. The router delay profiling step is currently used to calculate the place delay matrix lookup. - Values between 1 and 2 are resonable; higher values trade some quality for reduced run-time. + Values between 1 and 2 are reasonable; higher values trade some quality for reduced run-time. **Default:** ``1.2`` @@ -2289,7 +2289,7 @@ Analysis Options Global nets are unrouted nets, and their route trees happen to be null. - Finally, is interesting to note that the consecutive channel components may not seem to connect. There are two types of occurences: + Finally, is interesting to note that the consecutive channel components may not seem to connect. There are two types of occurrences: 1. The preceding channel's ending coordinates extend past the following channel's starting coordinates (example from a different path): @@ -2365,7 +2365,7 @@ The following options are used to enable power estimation in VPR. .. option:: --activity_file - File containing signal activites for all of the nets in the circuit. The file must be in the format:: + File containing signal activities for all of the nets in the circuit. The file must be in the format:: diff --git a/doc/src/vpr/file_formats.rst b/doc/src/vpr/file_formats.rst index 79b8100b53d..e7a2056db6b 100644 --- a/doc/src/vpr/file_formats.rst +++ b/doc/src/vpr/file_formats.rst @@ -327,7 +327,7 @@ since the ``.names`` and ``.latch`` primitives are named ``f`` and ``h`` :ref:`b Extended BLIF (.eblif) ---------------------- -VPR also supports several extentions to :ref:`structural BLIF ` to address some of its limitations. +VPR also supports several extensions to :ref:`structural BLIF ` to address some of its limitations. .. note:: By default VPR assumes file with ``.eblif`` are in extneded BLIF format. The format can be controlled with :option:`vpr --circuit_format`. @@ -499,7 +499,7 @@ A ``block`` tag has the following attributes: In all other situations, the name is arbitrary. * ``instance`` - The phyiscal block in the FPGA architecture that the current block represents. + The physical block in the FPGA architecture that the current block represents. Should be of format: architecture_instance_name[instance #]. For example, the 5th index BLE in a CLB should have ``instance="ble[5]"`` @@ -515,7 +515,7 @@ The names of these connections use the following format: #. Unused pins are identified with the keyword open. #. The name of an input pin to a complex logic block is the same as the name of the net using that pin. -#. The name of an output pin of a primitve (leaf block) is the same as the name of the net using that pin. +#. The name of an output pin of a primitive (leaf block) is the same as the name of the net using that pin. #. The names of all other pins are specified by describing their immediate drivers. This format is ``[name_of_immediate_driver_block].[port_name][pin#]->interconnect_name``. For primitives with equivalent inputs VPR may rotate the input pins. @@ -540,9 +540,9 @@ For example, consider a netlist contains a 2-input LUT named ``c``, which is imp ... -In the original netlist the two LUT inputs were connected to pins at indicies 0 and 1 (the only input pins). -However during clustering the inputs were rotated, and those nets now connect to the pins at indicies 2 and 4 (line 4). -The ```` tag specified the port name it applies to (``name`` attribute), and its contents lists the pin indicies each pin in the port list is associated with in the original netlist (i.e. the pins ``lut5.in[2]->direct:lut5`` and ``lut5.in[4]->direct:lut5`` respectively correspond to indicies 1 and 0 in the original netlist). +In the original netlist the two LUT inputs were connected to pins at indices 0 and 1 (the only input pins). +However during clustering the inputs were rotated, and those nets now connect to the pins at indices 2 and 4 (line 4). +The ```` tag specified the port name it applies to (``name`` attribute), and its contents lists the pin indices each pin in the port list is associated with in the original netlist (i.e. the pins ``lut5.in[2]->direct:lut5`` and ``lut5.in[4]->direct:lut5`` respectively correspond to indices 1 and 0 in the original netlist). .. note:: Use :option:`vpr --net_file` to override the default net file name. @@ -647,7 +647,7 @@ The placement files output by VPR also include (as a comment) an extra field: th .. figure:: fpga_coordinate_system.* - FPGA co-ordinate system. + FPGA coordinate system. :numref:`fig_fpga_coord_system` shows the coordinate system used by VPR for a small 2 x 2 CLB FPGA. The number of CLBs in the x and y directions are denoted by ``nx`` and ``ny``, respectively. @@ -724,7 +724,7 @@ the positions to grid locations. For 2D FPGA architectures, the ``layer`` should The ``sub_tile`` is a clustered placement construct: which cluster-level location at a given (x, y, layer) should these atoms go at (relevant when multiple clusters can be stacked there). A sub-tile of -1 may be used when -the sub-tile of an atom is unkown (allowing the packing algorithm to choose +the sub-tile of an atom is unknown (allowing the packing algorithm to choose any sub-tile at the given (x, y, layer) location). When used with ``flat-recon`` full legalizer (see :option:`vpr --ap_full_legalizer`), @@ -820,7 +820,7 @@ Each of these sections are separated into separate tags as described below. Top Level Tags ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The first tag in all rr graph files is the ```` tag that contains detailed subtags for each catagory in the rr graph. +The first tag in all rr graph files is the ```` tag that contains detailed subtags for each category in the rr graph. Each tag has their subsequent subtags that describes one entity. For example, ```` includes all the segments in the graph where each ```` tag outlines one type of segment. The ``rr_graph`` tag contains the following tags: @@ -890,7 +890,7 @@ A ``switches`` tag contains all the switches and its information within the FPGA .. rrgraph:tag:: ` section, the name defined as an attribute in the virtual sink of the clock network should be used to reference that clock network. @@ -105,4 +105,4 @@ The ``"CHANY"`` node with the ``id="12746"`` has ``segment_id="1"``, which means - \ No newline at end of file + diff --git a/doc/src/vpr/graphics.rst b/doc/src/vpr/graphics.rst index db1dd315025..56fa1d8b17d 100644 --- a/doc/src/vpr/graphics.rst +++ b/doc/src/vpr/graphics.rst @@ -253,7 +253,7 @@ Button Description Table | | | | pin utilization | +-------------------+-------------------+------------------------------+------------------------------+ | Cong. Cost | Routing | Visualizes the congestion | | -| | | costs of routing resouces | | +| | | costs of routing resources | | | | | | | | | | | | +-------------------+-------------------+------------------------------+------------------------------+ diff --git a/doc/src/vpr/sdc_commands.rst b/doc/src/vpr/sdc_commands.rst index aa1c8e81687..288a174d256 100644 --- a/doc/src/vpr/sdc_commands.rst +++ b/doc/src/vpr/sdc_commands.rst @@ -586,7 +586,7 @@ Sample using all remaining SDC commands. set_max_delay 17 -from [get_clocks{input_clk}] -to [get_clocks{output_clk}] set_min_delay 2 -from [get_clocks{input_clk}] -to [get_clocks{output_clk}] set_multicycle_path -setup -from [get_clocks{clk}] -to [get_clocks{clk2}] 3 - #For multicycle_path, if setup is specified then hold is also implicity specified + #For multicycle_path, if setup is specified then hold is also implicitly specified set_clock_uncertainty -from [get_clocks{clk}] -to [get_clocks{clk2}] 0.75 #For set_clock_uncertainty, if neither setup nor hold is unspecified then uncertainty is applied to both set_disable_timing -from [get_pins {FFA.Q[0]}] -to [get_pins {to_FFD.in[0]}] diff --git a/doc/src/vpr/timing_constraints.rst b/doc/src/vpr/timing_constraints.rst index fe57265a9f8..5eb894f59dc 100644 --- a/doc/src/vpr/timing_constraints.rst +++ b/doc/src/vpr/timing_constraints.rst @@ -12,7 +12,7 @@ Additional SDC examples are shown in :ref:`sdc_examples`. Default Timing Constraints -------------------------- -If no timing constriants are specified, VPR assumes default constraints based on the type of circuit being analyzed. +If no timing constraints are specified, VPR assumes default constraints based on the type of circuit being analyzed. Combinational Circuits ~~~~~~~~~~~~~~~~~~~~~~ @@ -58,5 +58,5 @@ Optimizes all clocks, including I/O clocks, to run as fast as possible. set_output_delay -clock virtual_io_clock -max 0 [get_ports {*}] Where ``clk`` and ``clk2`` are the netlist clocks in the design. -This is similarily extended if there are more than two netlist clocks. +This is similarly extended if there are more than two netlist clocks. diff --git a/doc/src/vtr/benchmarks.rst b/doc/src/vtr/benchmarks.rst index e011657eed2..9e7a3661a18 100644 --- a/doc/src/vtr/benchmarks.rst +++ b/doc/src/vtr/benchmarks.rst @@ -200,7 +200,7 @@ Once downloaded and extracted, benchmarks are provided as post-synthesized blif NoC Benchmarks ---------------- NoC benchmarks are composed of synthetic and MLP benchmarks and target NoC-enhanced FPGA architectures. Synthetic -benchmarks include a wide variety of traffic flow patters and are divided into two groups: 1) simple and 2) complex +benchmarks include a wide variety of traffic flow patterns and are divided into two groups: 1) simple and 2) complex benchmarks. As their names imply, simple benchmarks use very simple and small logic modules connected to NoC routers, while complex benchmarks implement more complicated functionalities like encryption. These benchmarks do not come from real application domains. On the other hand, MLP benchmarks include modules that perform matrix-vector multiplication diff --git a/doc/src/vtr/index.rst b/doc/src/vtr/index.rst index 4b02b7fe432..f2bbbc9b80e 100644 --- a/doc/src/vtr/index.rst +++ b/doc/src/vtr/index.rst @@ -22,7 +22,7 @@ VTR The Verilog-to-Routing (VTR) project :cite:`luu_vtr,luu_vtr_7` 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: +It then performs: * Elaboration & Synthesis (:ref:`odin_ii`) * Logic Optimization & Technology Mapping (:ref:`abc`) diff --git a/doc/src/vtr/optional_build_info.md b/doc/src/vtr/optional_build_info.md index e841ccdb563..b0935c17b3f 100644 --- a/doc/src/vtr/optional_build_info.md +++ b/doc/src/vtr/optional_build_info.md @@ -21,7 +21,7 @@ It is tested against the default compilers of all Debian and Ubuntu releases wit * GCC/G++: 9, 10, 11, 12 * Clang/Clang++: 11, 12, 13, 14 -Other compilers may work but are untested (your milage may vary). +Other compilers may work but are untested (your mileage may vary). ### Package Dependencies @@ -118,7 +118,7 @@ $ make ## Other platforms CMake supports a variety of operating systems and can generate project files for a variety of build systems and IDEs. -While VTR is developed primarily on Linux, it should be possible to build on different platforms (your milage may vary). +While VTR is developed primarily on Linux, it should be possible to build on different platforms (your mileage may vary). See the [CMake documentation](https://cmake.org) for more details about using cmake and generating project files on other platforms and build systems (e.g. Eclipse, Microsoft Visual Studio). @@ -182,10 +182,10 @@ These are usually found under /usr/lib/gcc on the Linux host machine. See the [toolchain file](https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/master/cmake/toolchains/mingw-linux-cross-compile-to-windows.cmake) for more details. #### Microsoft Visual Studio #### -CMake can generate a Microsft Visual Studio project, enabling VTR to be built with the Microsoft Visual C++ (MSVC) compiler. +CMake can generate a Microsoft Visual Studio project, enabling VTR to be built with the Microsoft Visual C++ (MSVC) compiler. ##### Installing additional tools ##### -VTR depends on some external unix-style tools during it's buid process; in particular the `flex` and `bison` parser generators. +VTR depends on some external unix-style tools during it's build process; in particular the `flex` and `bison` parser generators. One approach is to install these tools using [MSYS2](http://www.msys2.org/), which provides up-to-date versions of many unix tools for MS Windows. diff --git a/doc/src/vtr/pass_requirements.rst b/doc/src/vtr/pass_requirements.rst index 8c1f48aeb30..aef58356130 100644 --- a/doc/src/vtr/pass_requirements.rst +++ b/doc/src/vtr/pass_requirements.rst @@ -29,7 +29,7 @@ Each line of the file indicates a single metric, data type and allowable values * ****: The metric's pass requirement. - Valid requiremnt types are: + Valid requirement types are: * ``Equal()``: The metric value must exactly match the golden reference result. * ``Range(,)``: The metric value (normalized to the golden result) must be between ```` and ````. @@ -53,6 +53,6 @@ Example File vpr_status;Equal() #Pass if precisely equal vpr_seconds;RangeAbs(0.80,1.40,2) #Pass if within -20%, or +40%, or absolute value less than 2 - num_pre_packed_nets;Range(0.90,1.10) #Pass if withing +/-10% + num_pre_packed_nets;Range(0.90,1.10) #Pass if within +/-10% %include "routing_metrics.txt" #Import all pass requirements from the file 'routing_metrics.txt' diff --git a/doc/src/vtr/power_estimation/index.rst b/doc/src/vtr/power_estimation/index.rst index 4d5258f3d6e..3f3094f142c 100644 --- a/doc/src/vtr/power_estimation/index.rst +++ b/doc/src/vtr/power_estimation/index.rst @@ -103,7 +103,7 @@ where: * ````: Supply voltage in Volts. - * ````: Operating temperature, in Celcius. + * ````: Operating temperature, in Celsius. .. _power_ace: @@ -128,7 +128,7 @@ This ativity information consists of two values: The default tool used to perform activity estimation in VTR is ACE 2.0 :cite:`lamoureux_activity_estimation`. This tool was originally designed to work with the (now obsolete) Berkeley SIS tool -ACE 2.0 was modifed to use ABC, and is included in the VTR package here:: +ACE 2.0 was modified to use ABC, and is included in the VTR package here:: $VTR_ROOT/ace2 @@ -148,7 +148,7 @@ where User’s may with to use their own activity estimation tool. The produced activity file must contain one line for each net in the BLIF file, in the following format:: - + .. _power_arch_modeling: @@ -160,7 +160,7 @@ The following section describes the architectural assumptions made by the power Complex Blocks ~~~~~~~~~~~~~~ -The VTR architecture description language supports a hierarchichal description of blocks. In the architecture file, each block is described as a ``pb_type``, which may includes one or more children of type ``pb_type``, and interconnect structures to connect them. +The VTR architecture description language supports a hierarchical description of blocks. In the architecture file, each block is described as a ``pb_type``, which may includes one or more children of type ``pb_type``, and interconnect structures to connect them. The power estimation algorithm traverses this hierarchy recursively, and performs power estimation for each ``pb_type``. The power model supports multiple power estimation methods, and the user specifies the desired method in the architecture file: @@ -249,7 +249,7 @@ The wire and buffer attributes can be set using the following options. If no options are set, it is assumed that the wire capacitance is zero, and there are no buffers present. Keep in mind that the port construct allows for multiple pins per port. These attributes will be applied to each pin in the port. -If necessary, the user can seperate a port into multiple ports with different wire/buffer properties. +If necessary, the user can separate a port into multiple ports with different wire/buffer properties. * ``wire_capacitance=1.0e-15``: The absolute capacitance of the wire, in Farads. @@ -476,7 +476,7 @@ In order to determine the wire length that connects a parent entity to its child In this figure, the square on the left represents the area used by the transistors of the interconnect multiplexers. It is assumed that all connections from parent to child will pass through this area. Real wire lengths could me more or less than this estimate; some pins in the parent may be directly adjacent to child entities, or they may have to traverse a distance greater than just the interconnect area. -Unfortuantely, a more rigorous estimation would require some information about the transistor layout. +Unfortunately, a more rigorous estimation would require some information about the transistor layout. .. _fig_power_local_interconnect: diff --git a/doc/src/vtr/run_vtr_flow.rst b/doc/src/vtr/run_vtr_flow.rst index aa3f164a580..04ef0928fc1 100644 --- a/doc/src/vtr/run_vtr_flow.rst +++ b/doc/src/vtr/run_vtr_flow.rst @@ -258,7 +258,7 @@ Detailed Command-line Options .. note:: - Parmys is a Yosys plugin which provides intelligent partial mapping features (inference, binding, and hard/soft logic trade-offs) from Odin-II for Yosys. For more information on available paramters see the `Parmys `_ plugin page. + Parmys is a Yosys plugin which provides intelligent partial mapping features (inference, binding, and hard/soft logic trade-offs) from Odin-II for Yosys. For more information on available parameters see the `Parmys `_ plugin page. .. Universal Hardware Data Model (UHDM) is a complete modeling of the IEEE SystemVerilog Object Model with VPI Interface, Elaborator, Serialization, Visitor and Listener. .. UHDM is used as a compiled interchange format in between SystemVerilog tools. Typical inputs to the UHDM flow are files with ``.v`` or ``.sv`` extensions. diff --git a/doc/src/vtr/run_vtr_task.rst b/doc/src/vtr/run_vtr_task.rst index c68ba0b9711..57e5d86fc9c 100644 --- a/doc/src/vtr/run_vtr_task.rst +++ b/doc/src/vtr/run_vtr_task.rst @@ -118,7 +118,7 @@ Detailed Command-line Options regression_tests/vtr_reg_basic/basic_timing: k6_N10_mem32K_40nm.xml/ch_intrinsics.v/common OK (took 2.11 seconds) regression_tests/vtr_reg_basic/basic_timing: k6_N10_mem32K_40nm.xml/diffeq1.v/common OK (took 10.94 seconds) - where ``{}`` is a special variable interpretted by the ``parallel`` command to represent the input line (i.e. a script, see ``parallel``'s documentation for details). + where ``{}`` is a special variable interpreted by the ``parallel`` command to represent the input line (i.e. a script, see ``parallel``'s documentation for details). This will run the scripts generated by run_vtr_task.py in parallel (up to 4 at-a-time due to ``-j4``). Each script is invoked in the script's containing directory (``cd $(dirname {})``), which mimics the behaviour of ``-system local -j4``. @@ -127,7 +127,7 @@ Detailed Command-line Options **Determining Resource Requirements** - Often, when running in a cluster computing enviroment, it is useful to know what compute resources are required for each flow invocation. + Often, when running in a cluster computing environment, it is useful to know what compute resources are required for each flow invocation. Each generated ``vtr_flow.sh`` scripts contains the expected run-time and memory use of each flow invocation (derived from golden reference results). These can be inspected to determine compute requirements: @@ -141,4 +141,4 @@ Detailed Command-line Options VTR_MEMORY_ESTIMATE_BYTES=63422464 .. note:: - If the resource estimates are unkown they will be set to ``0`` + If the resource estimates are unknown they will be set to ``0`` diff --git a/doc/src/vtr/tasks.rst b/doc/src/vtr/tasks.rst index d819c3d7af5..78a8d65d546 100644 --- a/doc/src/vtr/tasks.rst +++ b/doc/src/vtr/tasks.rst @@ -18,7 +18,7 @@ Example Tasks * ``regression_mcnc``: Runs VTR on the historical MCNC benchmarks on a legacy architecture file. (Note: This is only useful for comparing to the past, it is not realistic in the modern world) -* ``regression_titan/titan_small``: Runs a small subset of the Titan benchmarks targetting a simplified Altera Stratix IV (commercial FPGA) architecture capture +* ``regression_titan/titan_small``: Runs a small subset of the Titan benchmarks targeting a simplified Altera Stratix IV (commercial FPGA) architecture capture * ``regression_fpu_hard_block_arch``: Custom hard FPU logic block architecture @@ -130,7 +130,7 @@ Optional Fields * **script_params_list_add**: Adds a set of command-line arguments - Multiple `script_params_list_add` can be provided which are addded to the cartesian product of configurations to be evaluated. + Multiple `script_params_list_add` can be provided which are added to the cartesian product of configurations to be evaluated. * **sdc_dir**: Directory path to benchmark SDC files. diff --git a/doc/src/vtr_version.py b/doc/src/vtr_version.py index 063f1665d3b..feeab0c4c07 100644 --- a/doc/src/vtr_version.py +++ b/doc/src/vtr_version.py @@ -12,14 +12,14 @@ def __init__(self, major, minor, patch, prerelease): self.prerelease = prerelease def version_str(self): - version_str = "" + version_str = "" if self.major != None and self.minor != None: version_str = "{}.{}".format(self.major, self.minor) return version_str def release_str(self): - release_str = "" + release_str = "" if self.major != None and self.minor != None and self.patch != None: release_str = "{}.{}.{}".format(self.major, self.minor, self.patch) diff --git a/doc/src/z_references.bib b/doc/src/z_references.bib index 7c04b202c8a..c877a191fa3 100644 --- a/doc/src/z_references.bib +++ b/doc/src/z_references.bib @@ -452,7 +452,7 @@ @ARTICLE{Viswanathan2005_FastPlace @article{Kim2013_SimPL, author = {Kim, Myung-Chul and Lee, Dong-Jin and Markov, Igor L.}, - journal = {Commun. ACM}, + journal = {Communications of the ACM}, title = {{SimPL}: an algorithm for placing {VLSI} circuits}, year = {2013}, issue_date = {June 2013}, diff --git a/libs/README.md b/libs/README.md index 54fabb2de83..335981c5478 100644 --- a/libs/README.md +++ b/libs/README.md @@ -1,5 +1,5 @@ This directory contains common utility libraries used by VTR. -Libraries included under the EXTERNAL/ directory are developed outside of the VTR repository and are included for convienience. +Libraries included under the EXTERNAL/ directory are developed outside of the VTR repository and are included for convenience. -EXTERNAL libaries should not be modified in the VTR source tree because it will diverge from their mainline implementations. +EXTERNAL libraries should not be modified in the VTR source tree because it will diverge from their mainline implementations. diff --git a/run_reg_test.py b/run_reg_test.py index 5539ed99506..152ec31cb62 100755 --- a/run_reg_test.py +++ b/run_reg_test.py @@ -376,7 +376,7 @@ def parse_single_test(task_lists, check=True, calculate=True, create=False): def print_header(heading, divider="=", print_first_line=True): - """Print heading formated in the center of two lines""" + """Print heading formatted in the center of two lines""" if print_first_line: print(divider * len(heading) * 2) print(" " * int((len(heading) / 2)), end="") diff --git a/utils/fasm/test/test_fasm.cpp b/utils/fasm/test/test_fasm.cpp index fce0b59e931..a44040d6456 100644 --- a/utils/fasm/test/test_fasm.cpp +++ b/utils/fasm/test/test_fasm.cpp @@ -179,7 +179,7 @@ equivalent port pins rotation. The output pin description format is: "PIN_____" -Pin decriptions returned by this functions are injected as FASM features to the +Pin descriptions returned by this functions are injected as FASM features to the edges of a rr graph that are immediately connected with pins from "outside" (not to from/to a SOURCE or SINK). Then, after genfasm is run they are identified, and decoded to get all the pin information. This allows to get information