Fix typos

README.md

@@ -35,7 +35,7 @@ full list of system requirements and installation instructions in the
 ### Quick start
 
 To check if FuseSoC is working, and to get an initial feeling for how FuseSoC
-works, you can try to simulate a simple hardware design from our core libray.
+works, you can try to simulate a simple hardware design from our core library.
 
 First, create and enter an empty workspace
 
@@ -61,7 +61,7 @@ add e.g. `--tool=modelsim` or `--tool=xcelium` between `run` and `i2c`.
 Did it work? Great! FuseSoC can be used to create FPGA images, perform
 linting, manage your IP libraries or do formal verification as well.
 Check out the [online documentation](https://fusesoc.readthedocs.io/en/stable/)
-documentation to learn more about creating your own core files and using
+to learn more about creating your own core files and using
 existing ones. If it didn't work, please get in touch (see below).
 
 ## Next steps

doc/source/index.rst

@@ -8,7 +8,7 @@ This documentation contains material for different audiences.
 
 The :doc:`User Guide <user/index>` explains how to get started with FuseSoC, starting from the installation.
 
-The :doc:`Reference Guide <ref/index>` provides a detailled description of all file formats and APIs.
+The :doc:`Reference Guide <ref/index>` provides a detailed description of all file formats and APIs.
 
 The :doc:`Developer's Guide <dev/index>` is aimed at developers of FuseSoC itself.
 It explains how to set up a development environment, how the source code is structured, and how patches and bug reports can be submitted to the project.

doc/source/ref/capi1.rst

@@ -361,7 +361,7 @@ main
      - Supported simulators. Valid values are
        icarus, modelsim, verilator, isim and
        xsim. Each simulator have a dedicated
-       section desribed elsewhere in this
+       section described elsewhere in this
        document
 
 

doc/source/ref/migrations.rst

@@ -278,7 +278,7 @@ Why
 ---
 As an aid for scripts executed during the build process, a number of environment variables were defined. Unfortunately this was done without too much thought and as time moved on, some of these turned out to be a maintenance burden without bringing much benefit, and in some cases without ever being used.
 
-At the same time, the introduction of VLNV and dependency ranges has introduced non-determinism in where the output of a build ends up. For these reasons, it was determined to redefine the rarely used `build_root` variable to point to the the directory containing the work root and exported files. A `--build-root` command-line switch is introduced to explictly set a build_root. Setting `build_root` in `fusesoc.conf` will keep working the same way as before, but the command-line switch takes precedence. CAPI1 cores will no longer export the `BUILD_ROOT` environment variable.
+At the same time, the introduction of VLNV and dependency ranges has introduced non-determinism in where the output of a build ends up. For these reasons, it was determined to redefine the rarely used `build_root` variable to point to the the directory containing the work root and exported files. A `--build-root` command-line switch is introduced to explicitly set a build_root. Setting `build_root` in `fusesoc.conf` will keep working the same way as before, but the command-line switch takes precedence. CAPI1 cores will no longer export the `BUILD_ROOT` environment variable.
 
 These changes affects the following cases:
 

doc/source/user/build_system/core_files.rst

@@ -168,9 +168,9 @@ Source files
 Source files are resolved relative to the location of the core file and must be stored in the same directory as the core file, or in a subdirectory of it.
 Source file names cannot be absolute paths, or start with ``../``.
 
-Optionally, source files can have attributes; the file ``macros.vh`` is an example of that.
+Optionally, source files can have attributes; the file ``macros.svh`` is an example of that.
 When specifying attributes, end the file name with a colon (``:``), and specify attributes as key-value pairs below it.
-(Alternatively, the equivalent short form syntax can be used, e.g. ``macros.vh: {is_include_file: true}``.)
+(Alternatively, the equivalent short form syntax can be used, e.g. ``macros.svh: {is_include_file: true}``.)
 
 The most common attributes are:
 

doc/source/user/build_system/dependencies.rst

@@ -12,7 +12,7 @@ This section explains how dependencies are specified, how they are resolved by F
 A dependency example: DualBlinky
 --------------------------------
 
-We introduced the basic FuseSoC features by creating an reusable core called Blinky.
+We introduced the basic FuseSoC features by creating a reusable core called Blinky.
 To illustrate the concept of dependencies in FuseSoC we employ another example: DualBlinky, the "dual-core" version of Blinky.
 Again, all source code is available in the `FuseSoC source tree <https://github.com/olofk/fusesoc>`_ in the ``tests/userguide/dualblinky`` directory.
 
@@ -71,14 +71,14 @@ The following rules apply.
 
 * Files from dependencies are inserted into the file list before the files in the file set where the dependency is declared.
 * The order in which dependencies are listed in the ``depend`` section does not imply any ordering.
-  That is, specifiying ``depend: [A, B]`` does not guarantee that files from core ``A`` are included before the ones from core ``B``.
+  That is, specifying ``depend: [A, B]`` does not guarantee that files from core ``A`` are included before the ones from core ``B``.
   (If such an order is desired, make core ``B`` depend on ``A``.)
 
 What happens if a dependency is specified?
 ------------------------------------------
 
 Declaring a dependency includes the dependent core in the build.
-More specificially, the following sections specified in the ``default`` target of the dependent core are included:
+More specifically, the following sections specified in the ``default`` target of the dependent core are included:
 
 * ``filesets``: File sets to include.
 * ``hooks``: A list of hooks to execute.
@@ -94,7 +94,7 @@ Version constraints
 
 Version constraints specify which version of a dependent core can be used, and which versions are incompatible.
 
-Within a :term:`core file`, version constraints are expressed by prefixing a core name with a version comparision operator.
+Within a :term:`core file`, version constraints are expressed by prefixing a core name with a version comparison operator.
 The following version comparison operators are available.
 
 .. list-table:: Version comparison operators

doc/source/user/build_system/flow_options.rst

@@ -11,7 +11,7 @@ At the same time, a certain level of tool-specific configurability is required t
 
 There are two categories of options available for the Edalize flows. *Flow options* that affect how the tools are chained together (the flow graph) and *tool options* for the individual tools to be run as part of the flow. This means that since the flow options influence which tools that will be run, some tool options only become available for certain combinations of flow options.
 
-Only one flow can be defined for a target, but the flow it self can be configured in different ways. The example below shows how the `test` target selects and configures a flow. The `flow` key selectes the flow itself. The selected `sim` flow has a *flow option* called `tool` that decides which simulator to use. `iverilog_options` and `vlog_options` are tool options for Icarus Verilog and Siemens QuestaSim/ModelSim and will be passed to the approriate tool if it is present in the flow graph.
+Only one flow can be defined for a target, but the flow itself can be configured in different ways. The example below shows how the `test` target selects and configures a flow. The `flow` key selects the flow itself. The selected `sim` flow has a *flow option* called `tool` that decides which simulator to use. `iverilog_options` and `vlog_options` are tool options for Icarus Verilog and Siemens QuestaSim/ModelSim and will be passed to the appropriate tool if it is present in the flow graph.
 
 This setup selects icarus as the tool, which means the `vlog_options` will not be used. However, all *flow options* and *tool options* are also automatically available on the command-line, which means that passing `--tool=modelsim` as a backend parameter will override the tool setting from the target. The same can be done for the two tool options, with the difference that for flow or tool option that are lists, any additional values passed on the command-line will append rather than replace the values in the core description file.
 

doc/source/user/build_system/generators.rst

@@ -135,7 +135,7 @@ The final piece of the generators machinery is to run a generator with some spec
               offset: 0xf0000000
               size: 1024
 
-The above core file snippet will register a parametrized generator instance with the name wb_intercon. It will use the generator called `wb_intercon_gen` which FuseSoC has previously found in the depedency tree. Everything listed under the `parameters` key is instance-specific configuration to be sent to the generator.
+The above core file snippet will register a parametrized generator instance with the name wb_intercon. It will use the generator called `wb_intercon_gen` which FuseSoC has previously found in the dependency tree. Everything listed under the `parameters` key is instance-specific configuration to be sent to the generator.
 
 Just registering a generate section will not cause the generator to be invoked. It must also be listed in the target and the generator to be used must be in the dependency tree. The following snippet adds the parameterized generator to the `default` target and adds an explicit dependency on the core that contains the generator. As CAPI2 cores only allow filesets to have dependencies, an empty fileset for this purpose must be created
 
@@ -169,7 +169,7 @@ Generator Cache
 ---------------
 Instead of fusesoc rerunning a generator each time and producing the same result it is possible to configure fusesoc to cache generator output and try to detect if a new run would produce the same output. Since there is no generic way of doing this that will fit all generators a couple of different methods for caching and detecting changes are available.
 
-The `generators` option `cache_type` is used for configuring type of caching. If set to `none` (or if option is omitted) no caching will be used. If set to `input` fusesoc will calculate a SHA256 hash of the generator input yaml file data and use this hash for detecting if something has changed and a rerun would be needed. This would happen if some data in the core file `generate` section, for instance `paramaters`, has changed.
+The `generators` option `cache_type` is used for configuring type of caching. If set to `none` (or if option is omitted) no caching will be used. If set to `input` fusesoc will calculate a SHA256 hash of the generator input yaml file data and use this hash for detecting if something has changed and a rerun would be needed. This would happen if some data in the core file `generate` section, for instance `parameters`, has changed.
 
 If `cache_type` is set to `generator` fusesoc will pass the responsibility for detecting if the previous run to the generator is still up to date. In this mode the generator will always be called and the output directory will be saved.
 

doc/source/user/build_system/tool_options.rst

@@ -26,7 +26,7 @@ Typically, these keys are called ``BINARYNAME_options``, and they take a list of
 The example below shows how tool options for Icarus Verilog (``icarus``) and Mentor ModelSim (``modelsim``) are set.
 
 * The ``iverilog`` binary will be called with the ``-g2012`` command-line argument, indicating that SystemVerilog 2012 support should be enabled.
-* Similarily, for ModelSim the argument ``-timescale=1ns/1ns`` will be passed to the ``vlog`` binary, which elaborates the design.
+* Similarly, for ModelSim the argument ``-timescale=1ns/1ns`` will be passed to the ``vlog`` binary, which elaborates the design.
 
 .. code-block:: yaml
 

doc/source/user/introduction.rst

@@ -20,7 +20,7 @@ Its main purpose is to increase reuse of IP (Intellectual Property) cores and be
 
 - set up continuous integration
 
-**FuseSoC is non-intrusive** Most existing designs doesn't need any changes to work with FuseSoC. Any FuseSoC-specific patches can be applied on the fly during implementation or simulation
+**FuseSoC is non-intrusive** Most existing designs don't need any changes to work with FuseSoC. Any FuseSoC-specific patches can be applied on the fly during implementation or simulation
 
 **FuseSoC is modular** It can be used as an end-to-end flow, to create initial project files for an EDA tool or integrate with your custom workflow
 

doc/source/user/package_manager/index.rst

@@ -54,7 +54,7 @@ FuseSoC is launched. The library locations specified from the
 command-line will be parsed after those in ``fusesoc.conf``
 
 For each library location, FuseSoC will recursively search for files
-with a *.core* suffix. Each of these files will be parsed and addded to
+with a *.core* suffix. Each of these files will be parsed and added to
 the in-memory FuseSoC database if they are valid ``.core`` files.
 
 Several ``.core`` files can reside in the same directory and they will all be parsed.

fusesoc/capi2/json_schema.py

@@ -379,7 +379,7 @@
       }
     },
     "^scripts$": {
-      "description": "A script specifies how to run an external command that is called by the hooks section together with the actual files needed to run the script. Scripts are alway executed from the work root",
+      "description": "A script specifies how to run an external command that is called by the hooks section together with the actual files needed to run the script. Scripts are always executed from the work root",
       "type": "object",
       "patternProperties": {
         "^.+$": {

fusesoc/main.py

@@ -649,7 +649,7 @@ def args_to_config(args, config):
     if hasattr(args, "resolve_env_vars_early") and args.resolve_env_vars_early:
         setattr(config, "args_resolve_env_vars_early", args.resolve_env_vars_early)
 
-    if hasattr(args, "allow_additional_propertis") and args.allow_additional_properties:
+    if hasattr(args, "allow_additional_properties") and args.allow_additional_properties:
         setattr(
             config, "args_allow_additional_properties", args.allow_additional_properties
         )