diff --git a/docs/Advanced-Concepts/Debugging-RTL.rst b/docs/Advanced-Concepts/Debugging-RTL.rst index 6831cc4a..678ab33a 100644 --- a/docs/Advanced-Concepts/Debugging-RTL.rst +++ b/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 diff --git a/docs/Customization/Dsptools-Blocks.rst b/docs/Customization/Dsptools-Blocks.rst index bdf68fc1..52109a75 100644 --- a/docs/Customization/Dsptools-Blocks.rst +++ b/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). diff --git a/docs/Customization/MMIO-Peripherals.rst b/docs/Customization/MMIO-Peripherals.rst index 15ed5a00..bffe6f26 100644 --- a/docs/Customization/MMIO-Peripherals.rst +++ b/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