update the docs up to tools

docs/Chipyard-Basics/Chipyard-Components.rst

@@ -88,6 +88,13 @@ Toolchains
   A fork of riscv-tools, designed to work with the Hwacha non-standard RISC-V extension.
   This fork can also be used as an example demonstrating how to add additional RoCC accelerators to the ISA-level simulation (Spike) and the higher-level software toolchain (GNU binutils, riscv-opcodes, etc.)
 
+Software
+-------------------------------------------
+
+**FireMarshal**
+  FireMarshal is the default workload generation tool that Chipyard uses to create software to run on its platforms.
+  See :ref:`fire-marshal` for more information.
+
 Sims
 -------------------------------------------
 

docs/Chipyard-Basics/Configs-Parameters-Mixins.rst

@@ -103,7 +103,7 @@ implementation (ex. ``HasPeripherySerialModuleImp`` where ``Imp`` refers to impl
 all the logical connections between generators and exchanges configuration information among them, while the
 lazy module implementation performs the actual Chisel RTL elaboration.
 
-In the MySoC example class, the "outer" ``MySoC`` instantiates the "inner"
+In the ``MySoC`` example class, the "outer" ``MySoC`` instantiates the "inner"
 ``MySoCModuleImp`` as a lazy module implementation. This delays immediate elaboration
 of the module until all logical connections are determined and all configuration information is exchanged.
 The ``RocketSubsystem`` outer base class, as well as the
@@ -118,10 +118,10 @@ the ``SerialAdapter`` module, and instantiates queues.
 
 In the test harness, the SoC is elaborated with
 ``val dut = Module(LazyModule(MySoC))``.
-After elaboration, the result will be a MySoC module, which contains a
-SerialAdapter module (among others).
+After elaboration, the result will be a ``MySoC`` module, which contains a
+``SerialAdapter`` module (among others).
 
-From a high level, classes which extend LazyModule *must* reference
+From a high level, classes which extend ``LazyModule`` *must* reference
 their module implementation through ``lazy val module``, and they
 *may* optionally reference other lazy modules (which will elaborate
 as child modules in the module hierarchy). The "inner" modules
@@ -135,7 +135,7 @@ Mix-in
 
 A mix-in is a Scala trait, which sets parameters for specific system components, as well as enabling instantiation and wiring of the relevant system components to system buses.
 The naming convention for an additive mix-in is ``Has<YourMixin>``.
-This is shown in the MySoC class where things such as ``HasPeripherySerial`` connect a RTL component to a bus and expose signals to the top-level.
+This is shown in the ``MySoC`` class where things such as ``HasPeripherySerial`` connect a RTL component to a bus and expose signals to the top-level.
 
 Additional References
 ---------------------------

docs/Chipyard-Basics/Initial-Repo-Setup.rst

@@ -5,8 +5,10 @@ Requirements
 -------------------------------------------
 
 Chipyard is developed and tested on Linux-based systems.
-It is possible to use this on macOS or other BSD-based systems, although GNU tools will need to be installed; it is also recommended to install the RISC-V toolchain from ``brew``.
-Working under Windows is not recommended.
+
+.. Warning:: It is possible to use this on macOS or other BSD-based systems, although GNU tools will need to be installed; it is also recommended to install the RISC-V toolchain from ``brew``.
+
+.. Warning:: Working under Windows is not recommended.
 
 Checking out the sources
 ------------------------
@@ -37,4 +39,4 @@ To get a basic installation (which is the only thing needed for most Chipyard us
 
 Once the script is run, a ``env.sh`` file is emitted that sets the ``PATH``, ``RISCV``, and ``LD_LIBRARY_PATH`` environment variables.
 You can put this in your ``.bashrc`` or equivalent environment setup file to get the proper variables.
-These variables need to be set for the make system to work properly.
+These variables need to be set for the ``make`` system to work properly.

docs/Chipyard-Basics/index.rst

@@ -1,11 +1,11 @@
 Chipyard Basics
 ================================
 
-These guides will walk you through the basics of the Chipyard framework:
+These sections will walk you through the basics of the Chipyard framework:
 
 - First, we will go over the components of the framework.
 
-- Next, we will go over the different configurations available.
+- Next, we will go over how to understand how Chipyard configures its designs.
 
 - Then, we will go over initial framework setup.
 

docs/Generators/Rocket-Chip.rst

@@ -2,7 +2,7 @@ Rocket Chip
 ===========
 
 Rocket Chip generator is an SoC generator developed at Berkeley and now supported by
-SiFive. Chipyard uses the Rocket Chip generator as the basis for producing a RISC-V SoC.
+`SiFive <https://www.sifive.com>`__. Chipyard uses the Rocket Chip generator as the basis for producing a RISC-V SoC.
 
 `Rocket Chip` is distinct from `Rocket core`, the in-order RISC-V CPU generator.
 Rocket Chip includes many parts of the SoC besides the CPU. Though Rocket Chip

docs/Generators/SHA3.rst

@@ -68,7 +68,7 @@ Using a SHA3 Accelerator
 ------------------------
 Since the SHA3 accelerator is designed as a RoCC accelerator,
 it can be mixed into a Rocket or BOOM core by overriding the
-BuildRoCC key. The configuration mixin is defined in the SHA3
+``BuildRoCC`` key. The configuration mixin is defined in the SHA3
 generator. An example configuration highlighting the use of
 this mixin is shown here:
 

docs/Generators/index.rst

@@ -9,7 +9,7 @@ A standard RTL design is essentially just a single instance of a design coming f
 However, by using meta-programming and parameter systems, generators can allow for integration of complex hardware designs in automated ways.
 The following pages introduce the generators integrated with the Chipyard framework.
 
-Chipyard bundles the source code for the generators, under the ``generators`` directory.
+Chipyard bundles the source code for the generators, under the ``generators/`` directory.
 It builds them from source each time (although the build system will cache results if they have not changed),
 so changes to the generators themselves will automatically be used when building with Chipyard and propagate to software simulation, FPGA-accelerated simulation, and VLSI flows.
 

docs/Quick-Start.rst

@@ -21,7 +21,7 @@ Start by fetching Chipyard's sources. Run:
     cd chipyard
     ./scripts/init-submodules-no-riscv-tools.sh
 
-This will have initialized the git submodules.
+This will initialize and checkout all of the necessary git submodules.
 
 Installing the RISC-V Tools
 -------------------------------------------
@@ -34,7 +34,7 @@ To build the toolchains, you should run:
 
     ./scripts/build-toolchains.sh
 
-.. Note:: If you are planning to use the Hwacha vector unit, or other RoCC-based accelerators, you should build the esp-tools toolchains by adding the ``esp-tools`` argument to the script above.
+.. Note:: If you are planning to use the Hwacha vector unit, or other RoCC-based accelerators, you should build the esp-tools toolchain by adding the ``esp-tools`` argument to the script above.
   If you are running on an Amazon Web Services EC2 instance, intending to use FireSim, you can also use the ``--ec2fast`` flag for an expedited installation of a pre-compiled toolchain.
 
 Finally, set up Chipyard's environment variables and put the newly built toolchain on your path:
@@ -60,6 +60,6 @@ This depends on what you are planning to do with Chipyard.
 
 * If you intend to change the generators (BOOM, Rocket, etc) themselves, see :ref:`generator-index`.
 
-* If you intend to run a VLSI flow using one of the vanilla Chipyard examples, go to <> and follow the instructions.
+* If you intend to run a tutorial VLSI flow using one of the Chipyard examples, go to :ref:`tutorial` and follow the instructions.
 
 * If you intend to build a chip using one of the vanilla Chipyard examples, go to :ref:`build-a-chip` and follow the instructions.

docs/Simulation/FPGA-Accelerated-Simulation.rst

@@ -37,7 +37,7 @@ Finally, source the following environment at the root of the firesim directory:
     # (Recommended) The default manager environment (includes env.sh)
     source sourceme-f1-manager.sh
 
-`Every time you want to use FireSim with a fresh shell, you must source this sourceme.sh`
+.. Note:: Every time you want to use FireSim with a fresh shell, you must source this ``sourceme-f1-manager.sh``
 
 At this point you're ready to use FireSim with Chipyard. If you're not already
 familiar with FireSim, please return to the `FireSim Docs
@@ -63,7 +63,7 @@ config looks as following:
     new DefaultRocketConfig
   )
 
-Then the equivalent FireChip config (in `generators/firechip/src/main/scala/TargetConfigs.scala`) based on `FireSimRocketChipConfig`
+Then the equivalent FireChip config (in ``generators/firechip/src/main/scala/TargetConfigs.scala``) based on ``FireSimRocketChipConfig``
 will look as follows:
 
 .. code-block:: scala

docs/Simulation/Software-RTL-Simulation.rst

@@ -58,7 +58,7 @@ For instance, to run one of the riscv-tools assembly tests.
 
     ./simulator-example-RocketConfig $RISCV/riscv64-unknown-elf/share/riscv-tests/isa/rv64ui-p-simple
 
-.. Note:: in a VCS simulator, the simulator name will be ``simv-example-RocketConfig`` ``instead of simulator-example-RocketConfig``.
+.. Note:: In a VCS simulator, the simulator name will be ``simv-example-RocketConfig`` instead of ``simulator-example-RocketConfig``.
 
 Alternatively, we can run a pre-packaged suite of RISC-V assembly or benchmark tests, by adding the make target ``run-asm-tests`` or ``run-bmark-tests``.
 For example:
@@ -69,7 +69,7 @@ For example:
     make run-bmark-tests
 
 
-.. Note:: Before running the pre-packaged suites, you must run the plain ``make`` command, since the elaboration command generates a Makefile fragment that contains the target for the pre-packaged test suites. Otherwise, you will likely encounter a Makefile target error.
+.. Note:: Before running the pre-packaged suites, you must run the plain ``make`` command, since the elaboration command generates a ``Makefile`` fragment that contains the target for the pre-packaged test suites. Otherwise, you will likely encounter a ``Makefile`` target error.
 
 
 .. _sw-sim-custom:
@@ -114,7 +114,7 @@ Therefore, in order to simulate a simple Rocket-based example system we can use:
     ./simulator-<yourproject>-<yourconfig> ...
 
 
-All `Make` targets that can be applied to the default example, can also be applied to custom project using the custom environment variables. For example, the following code example will run the RISC-V assembly benchmark suite on the Hwacha subproject:
+All ``make`` targets that can be applied to the default example, can also be applied to custom project using the custom environment variables. For example, the following code example will run the RISC-V assembly benchmark suite on the Hwacha subproject:
 
 .. code-block:: shell
 
@@ -130,11 +130,9 @@ Generating Waveforms
 
 If you would like to extract waveforms from the simulation, run the command ``make debug`` instead of just ``make``.
 
-
 For a Verilator simulation, this will generate a vcd file (vcd is a standard waveform representation file format) that can be loaded to any common waveform viewer.
 An open-source vcd-capable waveform viewer is `GTKWave <http://gtkwave.sourceforge.net/>`__.
 
-
 For a VCS simulation, this will generate a vpd file (this is a proprietary waveform representation format used by Synopsys) that can be loaded to vpd-supported waveform viewers.
 If you have Synopsys licenses, we recommend using the DVE waveform viewer.
 

docs/Software/FireMarshal.rst

@@ -1,3 +1,4 @@
+.. _fire-marshal:
 FireMarshal
 =================
 ``software/firemarshal``

docs/conf.py

@@ -97,6 +97,7 @@ html_theme = 'sphinx_rtd_theme'
 #
 html_theme_options = {
     'collapse_navigation': False,
+    'logo_only': True,
 #    'display_version': True,
 #    'navigation_depth': 4,
 }