Merge pull request #533 from antmicro/umarcor/docs/update

docs: update 'how' and 'glossary'

docs/community.rst

@@ -1,3 +1,5 @@
+.. _Community:
+
 Community
 #########
 

docs/conf.py

@@ -140,6 +140,7 @@
 intersphinx_mapping = {
     "python": ("https://docs.python.org/3/", None),
     "arch-defs": ("https://f4pga.readthedocs.io/projects/arch-defs/en/latest/", None),
+    "interchange": ("https://fpga-interchange-schema.readthedocs.io/", None),
     "fasm": ("https://fasm.readthedocs.io/en/latest/", None),
     "prjtrellis": ("https://prjtrellis.readthedocs.io/en/latest/", None),
     "prjxray": ("https://f4pga.readthedocs.io/projects/prjxray/en/latest/", None),

docs/glossary.rst

@@ -2,6 +2,129 @@ Glossary
 ########
 
 .. glossary::
+  :sorted:
 
-  File
-    A representation of a physical file.
+  HDL
+    A Hardware Description Language (HDL) is a computer language used for describing hardware designs.
+    HDLs in the scope of F4PGA include established (such as Verilog and `VHDL ➚ <https://IEEE-P1076.gitlab.io/>`__) or
+    emerging software-inspired paradigms like
+    `Chisel ➚ <https://chisel.eecs.berkeley.edu/>`_,
+    `SpinalHDL ➚ <https://spinalhdl.github.io/SpinalDoc-RTD/>`_,
+    `Migen ➚ <https://m-labs.hk/gateware/migen/>`_, or
+    :gh:`Amaranth ➚ <amaranth-lang>`.
+
+  Tool
+    * A software application available as a CLI entrypoint, a shared library or an (interpreted) script.
+
+    * Within :term:`f4pga <F4PGA>`, a *tool* is a Python abstraction that wraps a software application:
+
+    .. image:: _static/images/tool.png
+      :align: center
+
+  Step
+    Within :term:`f4pga <F4PGA>`, a *step* is a unit of execution, which is characterized by a set of
+    :term:`dependencies <Dependency>` and a set of :term:`artifacts <Artifact>`,
+    and it is composable in a :term:`flow <Flow>`.
+    *Steps* might wrap a single or multiple :term:`tools <Tool>`.
+
+    .. image:: _static/images/step.png
+      :align: center
+
+  Flow
+    Within :term:`f4pga <F4PGA>`, a *flow* is a :wikipedia:`directed graph ➚ <Directed_graph>` of :term:`steps <Step>`, which
+    describes end-to-end sequences to achieve specific tasks.
+    A *flow* might used as a step within another *flow*.
+    In such cases, terms *subflow* or *partial flow* are used.
+
+    .. image:: _static/images/flow.png
+      :align: center
+
+  CLI
+    A :wikipedia:`Command-Line Interface (CLI) ➚ <Command-line_interface>` is an application that processes commands to
+    a computer program in the form of lines of text, typically interactively (through a terminal) or in batch mode
+    (through scripts).
+    Most of the applications used in F4PGA are meant to be used through CLIs.
+    Precisely, :term:`f4pga <F4PGA>` :term:`tools <Tool>` provide Python abstractions around the CLIs.
+
+  Module
+    :ref:`The Python Tutorial » Modules ➚ <python:tut-modules>` are files containing Python statements and definitions
+    (variables, functions, clases,...).
+    The file name is the module name with the suffix ``.py`` appended.
+
+    Within :term:`f4pga <F4PGA>`, user-defined *modules* allow extending the built-in :term:`flows <Flow>` and
+    :term:`steps <Step>` to achieve custom and/or complex tasks.
+
+  Dependency
+    A *dependency* is a prerequisite to execute a :term:`f4pga <F4PGA>` :term:`step <Step>` in a :term:`flow <Flow>`.
+    *Dependencies* might be files (such as HDL sources, constraints, etc.), :term:`artifacts <Artifact>` from previous
+    *steps* or :term:`tools <Tool>`.
+
+  Artifact
+    An *artifact* is a result produced by a :term:`step <Step>` when executed.
+    Typically, *artifacts* are files and logs generated by the :term:`tools <Tool>`.
+    However, within :term:`f4pga <F4PGA>` :term:`flows <Flow>`, (meta)data can be passed across *steps* without saving
+    it to disk.
+
+  Target
+    Within :term:`f4pga <F4PGA>`, :term:`flows <Flow>` can have multiple leaf *steps*, producing different results off some
+    shared previous *steps*.
+    The *target* of a *flow* specifies which *steps* to execute in a run.
+
+  F4PGA
+
+    * *Uppercase*:
+
+      * FOSS Flows For FPGA (F4PGA), the name of the project as a whole.
+
+      * A Workgroup under the CHIPS Alliance.
+        See :ref:`Community`.
+
+    * *Lowercase*:
+
+      * Python package providing utilities.
+
+      * The main CLI entrypoint provided by the Python package.
+
+  Cache
+    Within :term:`f4pga <F4PGA>`, the content of :term:`dependencies <Dependency>` and :term:`artifacts <Artifact>` can
+    be tracked to optimize consecutive executions of the same :term:`flow <Flow>`.
+    The *cache* contains the :wikipedia:`hash ➚ <Hash_function>` of the assets.
+
+  Resolution
+    Relations between :term:`f4pga <F4PGA>` :term:`steps <Step>`, :term:`dependencies <Dependency>` and :term:`artifacts <Artifact>`
+    can get complex easily.
+    On top of computing the topological sorting, :term:`f4pga <F4PGA>` checks the existence of the assets, and supports
+    displaying the status.
+
+  Definition
+    Within :term:`f4pga <F4PGA>`, a :term:`flow <Flow>` *definition* is the description of which :term:`steps <Step>`
+    are to be executed and which :term:`dependencies <Dependency>` and :term:`artifacts <Artifact>` are to be passed
+    along.
+
+  Constraints
+    Set of parameters that allow users to select/specify certain physical characteristics of the FPGA device, such as
+    the pins/pads or the logic standard to use.
+
+  Project
+    A set of :term:`HDL` sources, constraints and other assets used in a hardware :term:`design <Design>` or set of
+    designs.
+
+  Design
+    Required :term:`HDL` sources, constraints and other assets to execute a :term:`flow <Flow>` and achieve a task.
+
+  Configuration
+    Within :term:`f4pga <F4PGA>`, a *project configuration* is the set of parameters needed for executing a
+    :term:`flow <Flow>` on a given :term:`design <Design>`.
+    The *configuration* might be provided through a Python API, or through a file using declarative format (such as JSON,
+    YAML, INI,...).
+
+  Model
+    * *Project model*: a generic description of an EDA project, independent of vendor and tools.
+      It reflects multiple design variants, grouping of source files into file sets or linking testbenches to
+      components or subsystems in a design.
+    * *Simulation model*: :term:`HDL <HDL>` sources interpreted as programming languages by simulators, which can
+      generate interpeted or executable :term:`artifacts <Artifact>`.
+
+  Toolchain
+    :wikipedia:`Toolchain ➚ <Toolchain>` is a generic term used to refer to a set of programming tools used
+    consecutively to perform a complex software development task.

docs/how.rst

@@ -3,65 +3,66 @@ How it works
 
 To understand how F4PGA works, it is best to start with an overview of the general EDA tooling ecosystem and then
 proceed to see what the F4PGA project consists of.
-
-EDA Tooling Ecosystem
-=====================
-
-For both ASIC- and FPGA-oriented EDA tooling, there are three major areas that
-the workflow needs to cover: hardware description, frontend and backend.
-
-Hardware description languages are generally open, with both established HDLs
-such as Verilog and VHDL and emerging software-inspired paradigms like
-`Chisel <https://chisel.eecs.berkeley.edu/>`_,
-`SpinalHDL <https://spinalhdl.github.io/SpinalDoc-RTD/>`_ or
-`Migen <https://m-labs.hk/gateware/migen/>`_.
-The major problem lies however in the front- and backend, where previously
-there was no established standard, vendor-neutral tooling that would cover
-all the necessary components for an end-to-end flow.
-
-This pertains both to ASIC and FPGA workflows, although F4PGA focuses
-on the latter (some parts of F4PGA will also be useful in the former).
-
-.. figure:: _static/images/EDA.svg
-
-Project structure
-=================
+For both ASIC- and FPGA-oriented EDA tooling, there are three major areas that the workflows need to cover: description,
+frontend and backend.
+
+.. image:: _static/images/EDA.svg
+  :align: center
+
+Hardware description languages are either established (such as Verilog and `VHDL ➚ <https://IEEE-P1076.gitlab.io/>`__) or
+emerging software-inspired paradigms like
+`Chisel ➚ <https://chisel.eecs.berkeley.edu/>`_,
+`SpinalHDL ➚ <https://spinalhdl.github.io/SpinalDoc-RTD/>`_,
+`Migen ➚ <https://m-labs.hk/gateware/migen/>`_, or
+:gh:`Amaranth ➚ <amaranth-lang>`.
+Since early 2000s, free and open source tools allow simulating HDLs.
+However, for several decades the major problem lied in the frontend and backend, where there was no established
+standard vendor-neutral tooling that would cover all the necessary components for an end-to-end flow.
+This pertains both to ASIC and FPGA workflows.
+Although F4PGA focuses on the latter, some parts of F4PGA will also be useful in the former.
 
 To achieve F4PGA's goal of a complete FOSS FPGA toolchain, a number of tools and projects are necessary to provide all
 the needed components of an end-to-end flow.
-Thus, F4PGA serves as an umbrella project for several activities, the central of which pertains to the creation of
-so-called FPGA "architecture definitions", i.e. documentation of how specific FPGAs work internally.
-More information can be found in the :doc:`F4PGA Architecture Definitions <arch-defs:index>` project.
+The F4PGA toolchains consist of logic synthesis and implementation tools, as well as chip documentation projects for
+chips of various vendors.
+Thus, F4PGA serves as an umbrella project for several activities.
+
+.. image:: _static/images/parts.svg
+  :align: center
 
-Those definitions and serve as input to backend tools like :gh:`nextpnr <YosysHQ/nextpnr>` and `Verilog to Routing <https://verilogtorouting.org/>`_,
-and frontend tools like `Yosys <http://www.clifford.at/yosys/>`_.
+The central resources are the so-called FPGA "architecture definitions" (i.e. documentation of how specific FPGAs work
+internally) and the "interchange schema" (for logical and physical netlists).
+Those definitions serve as input to frontend and backend tools, such as
+`Yosys ➚ <http://www.clifford.at/yosys/>`__,
+:gh:`nextpnr ➚ <YosysHQ/nextpnr>` and `Verilog to Routing ➚ <https://verilogtorouting.org/>`_.
 They are created within separate collaborating projects targeting different FPGAs:
 
-* :doc:`Project X-Ray <prjxray:index>` for Xilinx 7-Series
-* `Project IceStorm <http://www.clifford.at/icestorm/>` for Lattice iCE40
-* :doc:`Project Trellis <prjtrellis:index>` for Lattice ECP5 FPGAs
+* :doc:`Project X-Ray ➚ <prjxray:index>` for Xilinx 7-Series
+* `Project IceStorm ➚ <http://www.clifford.at/icestorm/>`__ for Lattice iCE40
+* :doc:`Project Trellis ➚ <prjtrellis:index>` for Lattice ECP5 FPGAs
 
-.. figure:: _static/images/parts.svg
+More information can be found at :doc:`F4PGA Architecture Definitions ➚ <arch-defs:index>` and :doc:`FPGA Interchange ➚ <interchange:index>`.
 
-The F4PGA toolchain consists of logic synthesis and implementation tools, as well as chip documentation projects for
-chips of various vendors.
 To prepare a working bitstream for a particular FPGA chip, the toolchain goes through the following stages:
 
-* First, a description of the FPGA chip is created with the information from the relevant bitstream documentation
+* A description of the FPGA chip is created with the information from the relevant bitstream documentation
   project.
-  This part is done within the :gh:`F4PGA Architecture Definitions <chipsalliance/f4pga-arch-defs>`.
+  This part is done within the :gh:`F4PGA Architecture Definitions ➚ <chipsalliance/f4pga-arch-defs>`.
   The project prepares information about the timings and resources available in the chip needed at the implementation
   stage, as well as techmaps for the synthesis tools.
 
-* The second step is logic synthesis.
-  It is carried out in the Yosys framework, which expresses the input Verilog file by means of the block and connection
-  types available in the chosen chip.
+  .. NOTE::
+    This stage is typically pre-built and installed as assets.
+    However, developers contributing to the bitstream documentation might build it.
+
+* Then, logic synthesis is carried out in the `Yosys ➚ <http://www.clifford.at/yosys/>`__ framework, which expresses the
+  user-provided hardware description by means of the block and connection types available in the chosen chip.
 
 * The next step is implementation.
-  Placement and routing tools put individual blocks from the synthesis description in the specific chip locations and
-  create paths between them.
-  To do that, F4PGA uses either :gh:`nextpnr <YosysHQ/nextpnr>` or `Verilog to Routing :gh:<verilog-to-routing/vtr-verilog-to-routing>`.
+  Placement and routing tools put individual blocks from the synthesis description in specific chip locations and create
+  paths between them.
+  To do that, F4PGA uses either :gh:`nextpnr ➚ <YosysHQ/nextpnr>` or :gh:`Verilog to Routing ➚ <verilog-to-routing/vtr-verilog-to-routing>`.
 
 * Finally, the design properties are translated into a set of features available in the given FPGA chip.
-  These features are saved in the :gh:`fasm format <chipsalliance/fasm>`, which is developed as part of F4PGA.
-  The fasm file is then translated to bitstream using the information from the bitstream documentation projects.
+  These features are saved in the :gh:`FASM format ➚ <chipsalliance/fasm>`, which is developed as part of F4PGA.
+  The FASM file is then translated to a bitstream, using the information from the bitstream documentation projects.