Merge branch 'dev-use-github-actions-plus-circle-ci' of https://github.com/ucb-bar/chipyard into dev-use-github-actions-plus-circle-ci

docs/Advanced-Concepts/Debugging-RTL.rst

@@ -22,8 +22,8 @@ make target. For example:
 
    make CONFIG=CustomConfig debug
 
-The ``run-binary-debug`` rule will also automatically build a simulator,
-run it on a custom binary, and generate a waveform. For example, to run a
+The ``run-binary-debug`` rule uses the prebuilt simulator to run a custom binary
+and generate a waveform. For example, to run a
 test on ``helloworld.riscv``, use
 
 .. code-block:: shell

docs/Customization/Dsptools-Blocks.rst

@@ -120,6 +120,7 @@ Now we can run our simulation.
 .. code-block:: shell
 
     cd sims/verilator
+    make CONFIG=StreamingFIRRocketConfig
     make CONFIG=StreamingFIRRocketConfig BINARY=../../tests/streaming-fir.riscv run-binary
 
 .. [#] ``ReadQueue`` and ``WriteQueue`` are good illustrations of how to write a ``DspBlock`` and how they can be integrated into rocket, but in a real design a DMA engine would be preferred. ``ReadQueue`` will stall the processor if you try to read an empty queue, and ``WriteQueue`` will stall if you try to write to a full queue, which a DMA engine can more elegantly avoid. Furthermore, a DMA engine can do the work of moving data, freeing the processor to do other useful work (or sleep).

docs/Customization/MMIO-Peripherals.rst

@@ -137,6 +137,7 @@ Now with all of that done, we can go ahead and run our simulation.
 .. code-block:: shell
 
     cd sims/verilator
+    make CONFIG=GCDTLRocketConfig
     make CONFIG=GCDTLRocketConfig BINARY=../../tests/gcd.riscv run-binary