From 6299b9d6b635e1d01980ce2314adfb673548dd4e Mon Sep 17 00:00:00 2001 From: Nazar Kazakov Date: Thu, 4 Apr 2024 14:43:52 +0100 Subject: [PATCH] Fix typos --- README.md | 4 ++-- doc/source/index.rst | 2 +- doc/source/ref/capi1.rst | 2 +- doc/source/ref/migrations.rst | 2 +- doc/source/user/build_system/core_files.rst | 4 ++-- doc/source/user/build_system/dependencies.rst | 8 ++++---- doc/source/user/build_system/flow_options.rst | 2 +- doc/source/user/build_system/generators.rst | 4 ++-- doc/source/user/build_system/tool_options.rst | 2 +- doc/source/user/introduction.rst | 2 +- doc/source/user/package_manager/index.rst | 2 +- fusesoc/capi2/json_schema.py | 2 +- fusesoc/main.py | 2 +- 13 files changed, 19 insertions(+), 19 deletions(-) diff --git a/README.md b/README.md index 74a911ff..d8c91288 100644 --- a/README.md +++ b/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 diff --git a/doc/source/index.rst b/doc/source/index.rst index 3f8cd9b1..f1c85ad1 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -8,7 +8,7 @@ This documentation contains material for different audiences. The :doc:`User Guide ` explains how to get started with FuseSoC, starting from the installation. -The :doc:`Reference Guide ` provides a detailled description of all file formats and APIs. +The :doc:`Reference Guide ` provides a detailed description of all file formats and APIs. The :doc:`Developer's Guide ` 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. diff --git a/doc/source/ref/capi1.rst b/doc/source/ref/capi1.rst index ef003dde..2f464ea9 100644 --- a/doc/source/ref/capi1.rst +++ b/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 diff --git a/doc/source/ref/migrations.rst b/doc/source/ref/migrations.rst index 5de84f97..5857209e 100644 --- a/doc/source/ref/migrations.rst +++ b/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: diff --git a/doc/source/user/build_system/core_files.rst b/doc/source/user/build_system/core_files.rst index 8efecb53..29ce756f 100644 --- a/doc/source/user/build_system/core_files.rst +++ b/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: diff --git a/doc/source/user/build_system/dependencies.rst b/doc/source/user/build_system/dependencies.rst index 1068fde7..426ed869 100644 --- a/doc/source/user/build_system/dependencies.rst +++ b/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 `_ 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 diff --git a/doc/source/user/build_system/flow_options.rst b/doc/source/user/build_system/flow_options.rst index 0837fa72..b4cf7427 100644 --- a/doc/source/user/build_system/flow_options.rst +++ b/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. diff --git a/doc/source/user/build_system/generators.rst b/doc/source/user/build_system/generators.rst index 4d4b0fc5..4bca8257 100644 --- a/doc/source/user/build_system/generators.rst +++ b/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. diff --git a/doc/source/user/build_system/tool_options.rst b/doc/source/user/build_system/tool_options.rst index 64d66489..f9e58287 100644 --- a/doc/source/user/build_system/tool_options.rst +++ b/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 diff --git a/doc/source/user/introduction.rst b/doc/source/user/introduction.rst index c88c43cd..4fb094d0 100644 --- a/doc/source/user/introduction.rst +++ b/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 diff --git a/doc/source/user/package_manager/index.rst b/doc/source/user/package_manager/index.rst index 11121cfe..0c7befb1 100644 --- a/doc/source/user/package_manager/index.rst +++ b/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. diff --git a/fusesoc/capi2/json_schema.py b/fusesoc/capi2/json_schema.py index 591e4e77..0b16c053 100644 --- a/fusesoc/capi2/json_schema.py +++ b/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": { "^.+$": { diff --git a/fusesoc/main.py b/fusesoc/main.py index 81301587..7318fa73 100644 --- a/fusesoc/main.py +++ b/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 )