From 1d3d8e4e0151030d1c35d6ca609307e9d18376e3 Mon Sep 17 00:00:00 2001 From: abejgonzalez Date: Mon, 25 Oct 2021 22:29:38 -0700 Subject: [PATCH] Reverse documentation on breaking prereqs --- docs/Advanced-Concepts/Debugging-RTL.rst | 20 ++++++++++++++++---- docs/Customization/Dsptools-Blocks.rst | 1 - docs/Customization/MMIO-Peripherals.rst | 1 - 3 files changed, 16 insertions(+), 6 deletions(-) diff --git a/docs/Advanced-Concepts/Debugging-RTL.rst b/docs/Advanced-Concepts/Debugging-RTL.rst index 678ab33a..79b9428e 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 uses the prebuilt simulator to run a custom binary -and generate a waveform. For example, to run a +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 test on ``helloworld.riscv``, use .. code-block:: shell @@ -83,8 +83,20 @@ Torture tests The RISC-V torture utility generates random RISC-V assembly streams, compiles them, runs them on both the Spike functional model and the SW simulator, and verifies identical program behavior. The torture utility can also be configured to run -continuously for stress-testing. The torture utility exists within the ``utilities`` -directory. +continuously for stress-testing. The torture utility exists within the ``tools`` +directory. To run torture tests, run ``make`` in the simulation directories: + +.. code-block:: shell + + make CONFIG=CustomConfig torture + +To run overnight tests (repeated random tests), run + +.. code-block:: shell + + make CONFIG=CustomConfig TORTURE_ONIGHT_OPTIONS= torture-overnight + +You can find the overnight options in `overnight/src/main/scala/main.scala` in the torture repo. Firesim Debugging --------------------------- diff --git a/docs/Customization/Dsptools-Blocks.rst b/docs/Customization/Dsptools-Blocks.rst index 52109a75..bdf68fc1 100644 --- a/docs/Customization/Dsptools-Blocks.rst +++ b/docs/Customization/Dsptools-Blocks.rst @@ -120,7 +120,6 @@ 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 bffe6f26..15ed5a00 100644 --- a/docs/Customization/MMIO-Peripherals.rst +++ b/docs/Customization/MMIO-Peripherals.rst @@ -137,7 +137,6 @@ 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